RE: Operational Issues with 69.0.0.0/8 - or, does the Army read NANOG posts?
Yes, but can you help us get it fixed, since you know about their inner workings? This is continually using valuable resources of ours and the others out there that have been kind enough to help. New sites are hitting the "inaccessible" list every day. I try to post only sites like this one, or ones that seem to have a common thread between them - i.e. they use the same transit... This is why we posted to NANOG for help - in the hopes that someone somewhere in the community is either involved or knows people involved with these networks. Todd -Original Message- From: Brad Knowles [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 5:11 AM To: Todd A. Blank Subject: Re: Operational Issues with 69.0.0.0/8 - or, does the Army read NANOG posts? At 8:05 PM -0500 on 2002/12/10, you wrote: > Another site that is filtering 69.0.0.0/8: > > www.army.mil > > If anybody has any way to reach anyone responsible for this, or if the > people who run this site are reading this, > > PLEASE STOP THE MADNESS! The US military is well-known for firewalling all non-US IP addresses around the world. This makes it kind of hard for people in NATO (served by Belgacom Skynet, and issued IP space from them) to contact people in the US military. This is one of those standard "Oops" situations that periodically crops up whenever they get some new 16 year-old firewall operator that doesn't understand why the moron before him had a non-US IP address in the "allowed" list, and promptly decides to remove it without checking with anyone. Doing martian filtering for 69/8 is nothing compared to the kind of stupidity we see from them on a regular basis. I say this as a former DISA.MIL Technical POC, so I have seen the kind of stupid stuff they do, first-hand and from the inside. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++)
Re: Operational Issues with 69.0.0.0/8 - or, does the Army read NANOG posts?
Another site that is filtering 69.0.0.0/8: www.army.mil If anybody has any way to reach anyone responsible for this, or if the people who run this site are reading this, PLEASE STOP THE MADNESS! Sincerely, Todd A. Blank 614.207.5853
Re: Operational Issues with 69.0.0.0/8...
On Tue, 10 Dec 2002, Harsha Narayan wrote: > > > Using cryptography to authenticate routing updates gets messy very soon. > > > Then, there will again be the same problem of the Public Key Infrastucture > > > not getting updated or something like that. > It would require a PKI and also require every router to support it. Not every... borders are enough. PKI is not that complicated, too; and routers already have some implementation of it embedded (in VPN parts). --vadim
Re: Operational Issues with 69.0.0.0/8...
Hi, It would require a PKI and also require every router to support it. Harsha. On Tue, 10 Dec 2002, Vadim Antonov wrote: > > On Tue, 10 Dec 2002, Harsha Narayan wrote: > > > Key databases: > > Using cryptography to authenticate routing updates gets messy very soon. > > Then, there will again be the same problem of the Public Key Infrastucture > > not getting updated or something like that. > > Hard to do it right, yes, but not impossible. (Actually I did strong > crypto for a living last few years, so I think I have somewhat informed > opinion on the subject :) > > --vadim >
Re: Operational Issues with 69.0.0.0/8...
On Tue, 10 Dec 2002, Harsha Narayan wrote: > Key databases: > Using cryptography to authenticate routing updates gets messy very soon. > Then, there will again be the same problem of the Public Key Infrastucture > not getting updated or something like that. Hard to do it right, yes, but not impossible. (Actually I did strong crypto for a living last few years, so I think I have somewhat informed opinion on the subject :) --vadim
Re: Operational Issues with 69.0.0.0/8...
> H. Didn't this entire thread start with "just aggravation of new > customers" - to wit, folks in 69/8 having problems reaching places with > filters that haven't been updated? > > s/filters that haven't been updated/key databases that have not been > updated/, and it looks like we're right back where we started... Key databases: Using cryptography to authenticate routing updates gets messy very soon. Then, there will again be the same problem of the Public Key Infrastucture not getting updated or something like that. Harsha.
Re: Operational Issues with 69.0.0.0/8...
On Tue, Dec 10, 2002 at 06:24:42AM -0800, Vadim Antonov wrote: > There's a big difference: address allocation (and key distribution) is > off-line, and is not involved in operation of the routing system. > Its failure doesn't cause network malfunction, just aggravation of new > customers. H. Didn't this entire thread start with "just aggravation of new customers" - to wit, folks in 69/8 having problems reaching places with filters that haven't been updated? s/filters that haven't been updated/key databases that have not been updated/, and it looks like we're right back where we started... -- *** Joel Baker System Administrator - lightbearer.com [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ msg07329/pgp0.pgp Description: PGP signature
Re: HTTP proxies, was Re: Operational Issues with 69.0.0.0/8...
> >> How do we get software vendors (free, pay, virus) to distribute > >> software with appropriate defaults? > michael> Second step, publish a directory. I.e. detect the > michael> non-conforming devices and publish their IP addresses in an > michael> LDAP server. > Let me get this straight, you are suggesting that the way to fix the > problem that there are potentially millions of insecure machines > connected to the Internet is to *PUBLISH* the IP addresses of all of > them in an easy to parse format? Cute. Yes, more or less. I am suggesting that people who have *detected* a vulnerability and wish to publicize this fact should publish their lists in a standard format and make it available via a standard protocol like LDAP. Since the number of *detected* vulnerable hosts is a lot lower than the total number of vulnerable hosts this is not as big as you think. And since one has to *detect* the vulnerability before publishing it, the scaling issue with detection is more of an issue than with publishing. Besides LDAP has proven to be scalable to very large databases. LDAP was developed as a light-weight system so that it could be scaled massively. > Don't tell me...we'll be able to pull the vulnerability that got the > hosts in the list too, so we can verify that "our" machines are, > indeed, misconfigured? ;-) Sure, why not? If someone is going to the trouble of collecting the information and publishing it, then they should publish this as well. After all, when you query an LDAP server you can specify which fields you want to retrieve. Applications that don't need the vulnerability info won't bother asking for it. --Michael Dillon
Re: Operational Issues with 69.0.0.0/8...
Hi, Rafi. ] 1) I'd take your "lousy" >>>working<<< over "clean" ... Thanks. :) ] 2) Would you _really_ want official authority ? No, not really. The way I look at it, I'm filling a niche until such time as the official authorities take on the task. That might be two days, or two decades. I'm willing and happy to do it until that day comes. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: HTTP proxies, was Re: Operational Issues with 69.0.0.0/8...
"michael" == Michael Dillon <[EMAIL PROTECTED]> writes: >> How do we get software vendors (free, pay, virus) to distribute >> software with appropriate defaults? michael> Second step, publish a directory. I.e. detect the michael> non-conforming devices and publish their IP addresses in an michael> LDAP server. Let me get this straight, you are suggesting that the way to fix the problem that there are potentially millions of insecure machines connected to the Internet is to *PUBLISH* the IP addresses of all of them in an easy to parse format? Cute. Don't tell me...we'll be able to pull the vulnerability that got the hosts in the list too, so we can verify that "our" machines are, indeed, misconfigured? ;-) baffled, Michael
Re: Operational Issues with 69.0.0.0/8...
On Tue, 10 Dec 2002, Stephen J. Wilcox wrote: > > The better way of dealing with the problem of bogus routes is strong > > authentication of the actual routing updates, whith key being allocated > > together with the address block. Solves unused address space reclaimation > > problem, too - when the key expires, it becomes unroutable. > > Of course, who would maintain the key databases and do you mean every route > would need a key with the central registrar or would it be carved up to eg > authority on /8 level or lir level which could be /22s.. seems at some point you > still have to go back to a central resource and if you dont have a single > resource you make it complicated? There's a big difference: address allocation (and key distribution) is off-line, and is not involved in operation of the routing system. Its failure doesn't cause network malfunction, just aggravation of new customers. OTOH, invalid RADB data can easily prevent network from operating, on a massive scale. --vadim
Re: Operational Issues with 69.0.0.0/8...
> We've already tried the RADB/RPSL/IRRD/whois/rwhois route for years and it > has failed. Only a few people have bothered to learn most of these > technologies and many network operators don't use any of it in an > automated fashion. Just recently there was a lot of discussion about the I bothered to learn it and use it in a very automated fashion, thank you very much. It really wasn't that hard and it works quite well. I'm curious to hear why it has taken you years to come up with only failure. -brent
Re: Operational Issues with 69.0.0.0/8...
On Tue, 10 Dec 2002, Vadim Antonov wrote: > > > On Tue, 10 Dec 2002 [EMAIL PROTECTED] wrote: > > > >Yakhov, Elise, Mark, and Bill - 1994 as part of the RA > > >project, bringers of the RAdb. > > > > This gets to the heart of the matter. It is now 8 years later and RADB is > > not catching on. > > It doesn't have anything to do with query serialization method. > > RADB is a kludge forcing ISPs to make their routing infrastructure to > depend on an external and centralized resource, and introducing an extra > step (which takes non-negligible amount of time) to their customer > installation process. > > The better way of dealing with the problem of bogus routes is strong > authentication of the actual routing updates, whith key being allocated > together with the address block. Solves unused address space reclaimation > problem, too - when the key expires, it becomes unroutable. Of course, who would maintain the key databases and do you mean every route would need a key with the central registrar or would it be carved up to eg authority on /8 level or lir level which could be /22s.. seems at some point you still have to go back to a central resource and if you dont have a single resource you make it complicated? Steve
Re: Operational Issues with 69.0.0.0/8...
On Tue, 10 Dec 2002 [EMAIL PROTECTED] wrote: > >Yakhov, Elise, Mark, and Bill - 1994 as part of the RA > >project, bringers of the RAdb. > > This gets to the heart of the matter. It is now 8 years later and RADB is > not catching on. It doesn't have anything to do with query serialization method. RADB is a kludge forcing ISPs to make their routing infrastructure to depend on an external and centralized resource, and introducing an extra step (which takes non-negligible amount of time) to their customer installation process. The better way of dealing with the problem of bogus routes is strong authentication of the actual routing updates, whith key being allocated together with the address block. Solves unused address space reclaimation problem, too - when the key expires, it becomes unroutable. I always thought that RADB was a temporary band-aid, but it seems that there was no progress in the field for quite a few years. Unfortunately, trying to do some new stuff in the field is nearly impossible - when VCs hear "backbone routing" they slam the door. --vadim
Re: Operational Issues with 69.0.0.0/8...
On Tue, 10 Dec 2002 [EMAIL PROTECTED] wrote: > I disagree. LDAP is a widespread technology and RPSL/IRRD/RADB is not. The > registries can hire people with LDAP experience or send people on LDAP > training courses. They can get advice and support from LDAP consultants. > And if the registries tell their staff to learn LDAP, then the staff will > be motivated to do it well since LDAP knowledge is a marketable skill. Besides LDAP, there's also SOAP / XML thingie :) All of that is pretty much trivial, and horribly overengineered (admittedly, not as horribly as X.500 or whatever that kludge was called). If a method of serializing tree-like data structures and performing request-reply protocol requires consultants to support, one may safely assume that there's something seriously wrong. To my ears "LDAP expert" sounds too much like "operator if-then-else expert". In any case, there's a bunch of public-domain thingies around which do LDAP or SOAP, so just pick any. --vadim
Re: Operational Issues with 69.0.0.0/8...
> This gets to the heart of the matter. It is now 8 years later and RADB is > not catching on. But during the same time period some other UMich people > worked on a more general purpose directory service called LDAP and that > one is catching on. LDAP technology can be made to do the job that we need > done and instead of having to create tools from scratch we can leverage a > lot of commercial tools to deal with the core functions. you are confusing an application service, radb, with an underlying store protocol, ldap. e.g., show me a routing db in ldap that has 10% the use of radb. by your reckoning, sql is the technology, as ripe, apnic, and many others use it as the *store* for their routing databases. randy
Re: Operational Issues with 69.0.0.0/8...
> > > Sean Donelan, May 14 1998 (three employers ago, so this should not be > > > taken as representing the official position any of my past, present or > > > future employers) > > >Yakhov, Elise, Mark, and Bill - 1994 as part of the RA > >project, bringers of the RAdb. > > This gets to the heart of the matter. It is now 8 years later and RADB is > not catching on. But during the same time period some other UMich people > worked on a more general purpose directory service called LDAP and that > one is catching on. LDAP technology can be made to do the job that we need > done and instead of having to create tools from scratch we can leverage a > lot of commercial tools to deal with the core functions. > > --Michael Dillon The implementation (RAdb/RPSL/IRR/LDAP/SWIP/rwhois) is, to a large degree, immaterial. The idea of publishing the IANA/RIR/ISP reserved pool in a tagged format that is machine parsable is the key. That we are unable to get to that point is telling. Its fairly easy to identify the IANA reserved /8 blocks. Its harder to identify the RIR reserved space (space delegated to RIRs that is not yet delegated to downstreams). Harder yet, identifying ISP reserved space (space delegated to ISPs that is not yet delegated to downstreams/endsystems). You should ask yourself, why is it important at one level and not important elsewhere? If you want a comprehensive map of IP space not in active use, then make the compelling case for it and build the tools that are so easy to use, everyone will adopt them. I've not seen a compelling case for just the IANA and not the RIRs or just the IANA and RIRs but not the ISPs. I've seen a compelling case for -EVERYONE- to participate in tracking IP space in use, but the tools that cover the range of useage are jsut not here. LDAP is not the cureall. Its a tool and some folks can make it work. Its too much overhead for most folks and for some parts of the delegation heirarchy. Now we could have the debate on -WHY- ldap/whois is considered so important. The applications use things like DNS mappings and routing announcements. These are critical for network operations. ldap/whois are not. --bill
Re: Operational Issues with 69.0.0.0/8...
> > Sean Donelan, May 14 1998 (three employers ago, so this should not be > > taken as representing the official position any of my past, present or > > future employers) >Yakhov, Elise, Mark, and Bill - 1994 as part of the RA >project, bringers of the RAdb. This gets to the heart of the matter. It is now 8 years later and RADB is not catching on. But during the same time period some other UMich people worked on a more general purpose directory service called LDAP and that one is catching on. LDAP technology can be made to do the job that we need done and instead of having to create tools from scratch we can leverage a lot of commercial tools to deal with the core functions. --Michael Dillon
Re: Operational Issues with 69.0.0.0/8...
> > I wouldn't be surprised to see this picked up in the Cook Report and some > > of the trade press because of your postings. The more people become aware > > of how the system is broken, the sooner we can fix it. > People actually read that? Yes. The people who don't read NANOG do read the Cook Report and the trade press. If you want to reach everyone in charge of operating a network then you need to use more media than just NANOG. > A simple solution: > 1) IANA creates an IANA-RESERVED IRR object > 2) Entities switch to using this for their filters, and the > updates happen automagically This is essentially what I am suggesting except using LDAP rather than RADB/IRR technology. I don't believe that RADB will ever be used by the majority of North American network operators but I do believe that LDAP has a chance of 100% penetration in the same way that 100% of network operators use UNIX servers and scripting languages in their network operations. --Michael Dillon
Re: Operational Issues with 69.0.0.0/8...
> > I'd like to see RIPE, APNIC and LACNIC also set up authoritative LDAP > > directories for unallocated IP space at the largest aggregate level. I'd > > also like to see them all dump the quirky and antiquated whois protocol > > and move to LDAP as the standard way of querying their directories. The > Insisting on LDAP is likely to kill your proposal before it gets off the > ground. RPSL works fine. If you want LDAP, you can certainly mirror > via the IRRD mirroring protocol, and store however is most useful > to you. I disagree. LDAP is a widespread technology and RPSL/IRRD/RADB is not. The registries can hire people with LDAP experience or send people on LDAP training courses. They can get advice and support from LDAP consultants. And if the registries tell their staff to learn LDAP, then the staff will be motivated to do it well since LDAP knowledge is a marketable skill. The RIRs should be looking at LDAP as the core technology for offering their directory services. We've already tried the RADB/RPSL/IRRD/whois/rwhois route for years and it has failed. Only a few people have bothered to learn most of these technologies and many network operators don't use any of it in an automated fashion. Just recently there was a lot of discussion about the new ARIN whois format and a lot of this revolved around how to make it easier to parse for automated systems. That's like running a mailing list by typing in messages, printing them out, faxing them to UMich where they are scanned and run through OCR, and then emailed to you. Here's how an LDAP directory works. There is a SWIP template form on an ARIN web page. You type the appropriate bits of info into the appropriate boxes and press the submit button. An ARIN CGI or webapp places each field into a relational database. Once a day, they dump any database changes into their LDAP directory. Now when you or your admin scripts query the LDAP directory, each bit of data is received as a separate identifiable field. No more parsing. In fact, you can tell the LDAP server to only send the bits of data that you are interested in. Rather than trying to reinvent LDAP by ourselves it makes an awful lot more sense to leverage the efforts of the hundreds of people at Netscape, SUN, IBM and many universities who have worked over many years to make LDAP version 3 into a very usable tool. LDAP directories are already integral parts of running many large networks in universities and corporations. We should use it in the global Internet as well. -- Michael Dillon
Re: Operational Issues with 69.0.0.0/8...
## On 2002-12-09 20:19 -0600 Rob Thomas typed: RT> RT> Hi, Eddy. RT> RT> ] Give Rob Thomas official authority, a paycheck, and the necessary RT> ] bandwidth. ;-) RT> RT> Hehe! I'll second that! :) No one would support it, though, once they RT> saw my lousy code. :) Hi Rob 1) I'd take your "lousy" >>>working<<< over "clean" bug riddled code any day ... (and who says that "closed source" code isn't built from lousy source anyway?) 2) Would you _really_ want official authority ? -- Regards Rafi
Re: Operational Issues with 69.0.0.0/8...
On Mon, 09 Dec 2002 20:19:09 CST, Rob Thomas <[EMAIL PROTECTED]> said: > Hehe! I'll second that! :) No one would support it, though, once they > saw my lousy code. :) It beats lousy closed-source software. ;) msg07295/pgp0.pgp Description: PGP signature
Re: Operational Issues with 69.0.0.0/8...
Hi, Eddy. ] Give Rob Thomas official authority, a paycheck, and the necessary ] bandwidth. ;-) Hehe! I'll second that! :) No one would support it, though, once they saw my lousy code. :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: Operational Issues with 69.0.0.0/8...
> On Mon, 9 Dec 2002 [EMAIL PROTECTED] wrote: > > A simple solution: > > 1) IANA creates an IANA-RESERVED IRR object > > 2) Entities switch to using this for their filters, and the > > updates happen automagically > > > > (Didn't someone already suggest this many many messages ago?) > > > Sean Donelan, May 14 1998 (three employers ago, so this should not be > taken as representing the official position any of my past, present or > future employers) > > http://www.irbs.net/internet/nanog/9805/0315.html > > Yakhov, Elise, Mark, and Bill - 1994 as part of the RA project, bringers of the RAdb. -- bill
Re: Operational Issues with 69.0.0.0/8...
On Mon, 9 Dec 2002 [EMAIL PROTECTED] wrote: > A simple solution: > 1) IANA creates an IANA-RESERVED IRR object > 2) Entities switch to using this for their filters, and the > updates happen automagically > > (Didn't someone already suggest this many many messages ago?) Sean Donelan, May 14 1998 (three employers ago, so this should not be taken as representing the official position any of my past, present or future employers) http://www.irbs.net/internet/nanog/9805/0315.html
Re: Operational Issues with 69.0.0.0/8...
> > I think we can all agree that whoever's responsibility it is, the > > current system is broken. You can't actually count on people to read > > this list. > > Absolutely right! > And all of this discussion that you have sparked on the list will actually > help solve the problem. Unfortunately it ain't gonna happen fast. That's > why I would like to see some work done on a general solution to the > problem because that will get us a lot more benefit from the effort > expended. As a network operator, I don't see any tye of real-time feed for RIR allocations to be useful, esp. not via BGP. > I wouldn't be surprised to see this picked up in the Cook Report and some > of the trade press because of your postings. The more people become aware > of how the system is broken, the sooner we can fix it. People actually read that? > > Maybe if IANA and ARIN and the other organizations that are > > supposed to work together to make all this stuff work weren't so busy > > trying to pass the buck, someone might have time to figure something > > out... > > There are more than a few people in ARIN et al. and most of them really do > care about finding solutions to these issues. But the Internet is no > longer an old boys club which means that there has to be a certain amount > of public discussion and process before decisions are made and action is > taken. Sadly, this problem could have been predicted but there are too few > people willing to think about what we are doing and do some forward > planning. ARIN and other membership organizations are only as good as the > members themselves. When the members of an organization are apathetic, > then the organization doesn't do much more than the same old thing. > > -- Michael Dillon Hi! What is the problem you are seeking to solve? I thought the problem was that: 1) Folks like to filter IANA-RESERVED space 2) Apparently some entities out there haven't updated their filters in aeons. A simple solution: 1) IANA creates an IANA-RESERVED IRR object 2) Entities switch to using this for their filters, and the updates happen automagically (Didn't someone already suggest this many many messages ago?)
Re: Operational Issues with 69.0.0.0/8...
> Hello Everyone, > > I appreciate all of the discussion regarding this issue. Nothing has > changed. This is getting worse. We spoke to one network on Friday that > said they had cleared the problem, yet our users still can't go there. > > For those of you that feel this is not anyone's problem, and that the > internet should just "work it out"; > > I hereby challenge one of you to trade CIDRs with us. You take this > 69.1.192.0/19 ARIN assigned us and you go spend your valuable time, > resources, and money working out what seems to be "nobody's problem". > Also, if you would like to come over and answer the support calls and > explain to our customers why the competitor's networks can reach these > sites, but ours can't. Hey - after all, it's just CIDR - it's all the > same, right? Ok, you give back the address space to the RIR and get a /19 from your provider. There, problem solved.
Re: Operational Issues with 69.0.0.0/8...
> I'd like to see RIPE, APNIC and LACNIC also set up authoritative LDAP > directories for unallocated IP space at the largest aggregate level. I'd > also like to see them all dump the quirky and antiquated whois protocol > and move to LDAP as the standard way of querying their directories. The Insisting on LDAP is likely to kill your proposal before it gets off the ground. RPSL works fine. If you want LDAP, you can certainly mirror via the IRRD mirroring protocol, and store however is most useful to you.
Re: Operational Issues with 69.0.0.0/8...
You can add dvgarage to that list of domains not configured properly for 69.x.x.x as well. They use GBLX, who is properly configured but once it hits their internal network the problems start. On Mon, 9 Dec 2002 [EMAIL PROTECTED] wrote: > > On Mon, 9 Dec 2002, Todd A. Blank wrote: > > > I hereby challenge one of you to trade CIDRs with us. You take this > > 69.1.192.0/19 ARIN assigned us and you go spend your valuable time, > > resources, and money working out what seems to be "nobody's problem". > > Was this an initial allocation into which you're renumbering out of > provider space, or a trade-in (you gave some block back to ARIN and got > this one)? Based on the newness of your ASN and sho ip bg regex _26483, > I'm guessing it's your first allocation. Assuming you did this because > you were about out of the space allocated to you by your provider(s), have > you looked into getting some more space from your providers to keep things > running while the issues with 69.0.0.0/8 filters are worked out? Even if > they've already given you as much space as their policies allow, I suspect > you could talk them into bending the rules in a case like this. Creating > more networks to renumber sucks, but it beats losing customers, and you > have plenty of time...probably even more than the ARIN published > guidelines for renumbering due to the problems you've encountered...and > what can ARIN do if you go beyond their suggested deadline anyway? > > I don't have any spare CIDRs to trade you. In fact, I'll be doing the > ARIN dance again soon to get more space since we're running out. I'm > really not looking forward to being in the same boat as you, but at least > I know now to expect trouble, especially if we get a chunk of the same /8 > you did. > > In your first message, you posted a couple of web sites that were not > reachable from your IP space. It'd be more useful (to people in your > shoes) and more embarrassing (to the offending networks) if you could post > the names of the networks/backbones you've identified thus far that are > still filtering 69.0.0.0/8. > > Maybe someone reading this list will know someone who knows someone at > those networks and be able to get something done. If nothing else, it > gives the next guy who gets 69.0.0.0/8 space a starting point of networks > to check connectivity to and networks to contact if things don't work for > them. Then those networks will have multiple people pestering them to fix > their filters even if not everyone affected has customers that actually > care about reaching those nets. > > > Also, if you would like to come over and answer the support calls and > > explain to our customers why the competitor's networks can reach these > > sites, but ours can't. Hey - after all, it's just CIDR - it's all the > > same, right? > > Have you given customers in the affected space the option of renumbering > back into your previous IP space? > > > What all of you don't know, is that for the first month we had this > > CIDR, we could not register hosts on it at NetSol/Verisign, because > > their core registry did not recognize it. We have been getting F***ed > > That should have set off some alarm bells and prompted a post to nanog a > month ago. > > -- > Jon Lewis *[EMAIL PROTECTED]*| I route > System Administrator| therefore you are > Atlantic Net| > _ http://www.lewis.org/~jlewis/pgp for PGP public key_ > >
Re: Operational Issues with 69.0.0.0/8...
On Mon, 9 Dec 2002, Todd A. Blank wrote: > I hereby challenge one of you to trade CIDRs with us. You take this > 69.1.192.0/19 ARIN assigned us and you go spend your valuable time, > resources, and money working out what seems to be "nobody's problem". Was this an initial allocation into which you're renumbering out of provider space, or a trade-in (you gave some block back to ARIN and got this one)? Based on the newness of your ASN and sho ip bg regex _26483, I'm guessing it's your first allocation. Assuming you did this because you were about out of the space allocated to you by your provider(s), have you looked into getting some more space from your providers to keep things running while the issues with 69.0.0.0/8 filters are worked out? Even if they've already given you as much space as their policies allow, I suspect you could talk them into bending the rules in a case like this. Creating more networks to renumber sucks, but it beats losing customers, and you have plenty of time...probably even more than the ARIN published guidelines for renumbering due to the problems you've encountered...and what can ARIN do if you go beyond their suggested deadline anyway? I don't have any spare CIDRs to trade you. In fact, I'll be doing the ARIN dance again soon to get more space since we're running out. I'm really not looking forward to being in the same boat as you, but at least I know now to expect trouble, especially if we get a chunk of the same /8 you did. In your first message, you posted a couple of web sites that were not reachable from your IP space. It'd be more useful (to people in your shoes) and more embarrassing (to the offending networks) if you could post the names of the networks/backbones you've identified thus far that are still filtering 69.0.0.0/8. Maybe someone reading this list will know someone who knows someone at those networks and be able to get something done. If nothing else, it gives the next guy who gets 69.0.0.0/8 space a starting point of networks to check connectivity to and networks to contact if things don't work for them. Then those networks will have multiple people pestering them to fix their filters even if not everyone affected has customers that actually care about reaching those nets. > Also, if you would like to come over and answer the support calls and > explain to our customers why the competitor's networks can reach these > sites, but ours can't. Hey - after all, it's just CIDR - it's all the > same, right? Have you given customers in the affected space the option of renumbering back into your previous IP space? > What all of you don't know, is that for the first month we had this > CIDR, we could not register hosts on it at NetSol/Verisign, because > their core registry did not recognize it. We have been getting F***ed That should have set off some alarm bells and prompted a post to nanog a month ago. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Operational Issues with 69.0.0.0/8...
Alec H. Peterson wrote: > --On Monday, December 9, 2002 9:48 -0500 Leo Bicknell > <[EMAIL PROTECTED]> wrote: >> The problem here is that ARIN (and the other registries) are the >> ones who can contact the users. > > But Michael is not talking about the registries _contacting_ people > with a message about changes in unallocated blocks, he's talking > about one specific regional registry providing a list of all > unallocated space (that still 'belongs' to IANA/ICANN). IANA already maintains a public list of assigned space, and thus by negation a list of unassigned space. Anyone who cares enough to update their filters has all the information they need to. While sending gratuitous messages to ASN/SWIP contacts is a nice idea, it's still gratuitous. S
Re: Operational Issues with 69.0.0.0/8... (fwd)
LDAP is where this kind of technology is going, I agree. But until such time as this is deployed, we'll still be using email and publishing information on the website. It can also be noted that those that create filters, have to get the information from somewhere - they most likely got it from email and website and these are the places where updates should go (and on websites listing currently allocated blocks, there should be BIG notice that information here will change and those using it should come back and check on it every few months) Also in my view it is responsibility of whever has the filters to keep them updated - they are taking a chance that this might not remove legitimate traffic (and take their time to create and deply the filter) and so they should have the time to maintain the same filter. In my view the whole point of discussion here was that 1 month is NOT enough for everybody involved to know about new block being made available for allocations by RIR. What has been suggeted which is good is to have large RIRs (ARIN, APNIC, RIPE) keep one class-A on reserve ready for new allocations and when they begin allocating from such block, then there would be 6 month or year in advance notice about next block that allocation would be made from. Such policy of having one "extra" class-a allocated to RIRs should be discussed by either ICANN ASO or by yet-to-be-formed NRR (number resource registry). On Mon, 9 Dec 2002 [EMAIL PROTECTED] wrote: > > > That is a good point, but you are talking about a periodic notification > > when new blocks are allocated. Michael is talking about an automated > feed > > of all unallocated blocks. > > I'm talking first of all, about a directory listing all the unallocated > space that people can query. Secondly, I'm suggesting that this same set > of data could be published by ARIN using BGP to make it easier for people > to monitor changes. > > > If we were to invert this and say that ARIN > > will provide a list of all blocks that are allocated to it, then that > might > > be worth doing. > > I specifically suggested that ARIN provide a list of unallocated blocks > because otherwise everyone else has to suck down the entire database of > allocated blocks and invert it themselves. If they screw up their > inversion algorithm that creates further problems. > > In an ideal world, IANA would provide a top-level LDAP directory of the > entire IPv4 address space with referrals for each large allocation to the > RIR LDAP servers just like the DNS delegates a domain to other DNS > servers. But it is just as workable for the 4 RIRs to work out some other > way of synchronizing the top level of the IPv4 address space and for all 4 > of them to publish the entire data set in their local (topologically > speaking) servers. > > > However, I get back to my original question. For people who insist on > > filtering unallocated address space, is it too much to ask that they > either > > subscribe to NANOG, or potentially subscribe to an RIR-specific > > announce-only mailing list for such things? > > Yes. This is the 21st century. Mailing lists are a 19th century technology > (memorandums) dressed up with a bit of 20th century technology. We can do > better. If we can create routing protocols that dynamically distribute > routing topology data, then we can surely come up with an automated way of > distributing the IPv4 allocation data. People who are scared of automation > can insert the human being inside their own domains of control. But let's > use some network protocols for the core distribution of the data. > > > It seems really silly to me > > for the registries to spew a mailing to their entire contact database > just > > to reach a handful of people who actually do route filtering. > > Yes, spewing out email to solve a simple database synchronization problem > seems counter-productive to me. > Even a plain ASCII text file mirrored with rsync polling would be a vast > improvement over email. But LDAP is proving to be the direction that the > world is moving in for this type of directory service so why not leverage > the tools and expertise that are available out there? > > -- Michael Dillon >
Re: Operational Issues with 69.0.0.0/8...
OK, clearly this discussion has mutated into a couple of discussions. I was under the impression we were still talking about a published list of /8 delegations, since all of the prefix filters I've seen operate on that level. However, part of the discussion has mutated into how the RIRs should provide insight into unallocated space inside of delegations they have received from IANA. There are several issues. There is the operational issue relating to people who have received allocations inside of 69/8 and cannot get to backbones who are filtering announcements from that block. I'd say it's safe to assume that the backbones who are filtering 69/8 aren't reading NANOG, so the fact that the operational discussion is happening here probably isn't doing much good to help Todd's problem. As far as how to fix that, somebody probably needs to find the right person at these ISPs and use a clue-by-four appropriately. Then there is the registry issue of how to provide relevant information about which /8s belong to which RIRs. I respectfully suggest that people periodically query http://www.iana.org/assignments/ipv4-address-space for this information. Finally, there is the issue of providing information relating to unallocated blocks within each RIRs allocations. This discussion is far more relevant to the registry specific mailing lists. I suggest those interested in discussing that join the appropriate ARIN mailing list. The discussion is happening on [EMAIL PROTECTED], though it is probably more appropriate to the [EMAIL PROTECTED] mailing list. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
> I think we can all agree that whoever's responsibility it is, the > current system is broken. You can't actually count on people to read > this list. Absolutely right! And all of this discussion that you have sparked on the list will actually help solve the problem. Unfortunately it ain't gonna happen fast. That's why I would like to see some work done on a general solution to the problem because that will get us a lot more benefit from the effort expended. I wouldn't be surprised to see this picked up in the Cook Report and some of the trade press because of your postings. The more people become aware of how the system is broken, the sooner we can fix it. > Maybe if IANA and ARIN and the other organizations that are > supposed to work together to make all this stuff work weren't so busy > trying to pass the buck, someone might have time to figure something > out... There are more than a few people in ARIN et al. and most of them really do care about finding solutions to these issues. But the Internet is no longer an old boys club which means that there has to be a certain amount of public discussion and process before decisions are made and action is taken. Sadly, this problem could have been predicted but there are too few people willing to think about what we are doing and do some forward planning. ARIN and other membership organizations are only as good as the members themselves. When the members of an organization are apathetic, then the organization doesn't do much more than the same old thing. -- Michael Dillon
Re: Operational Issues with 69.0.0.0/8...
--On Monday, December 9, 2002 15:55 + [EMAIL PROTECTED] wrote: 1. Missing data. Your solution does not show the parts of 69/8 that ARIN has reserved or unallocated. Are you telling me that people are really going to update their filters every single time ARIN (or any other RIR) makes an allocation? 2. Referrals. Your solution provides no referral to another source for more detailed data. In another world, if I ask a .org server for www.ipv6.org it will "refer" me to the ipv6.org server who will "refer" me to www.ip6.org. With LDAP we have a directory service that can issue such referrals and have them automatically followed to provide as complete a view as we desire. The file has that data (which registry has which blocks). A simple search/replace can refer you to the next data source. 3. Not a crude hack. A UNIX shell script scraping data from a text file that was created as a human-readable document is not my idea of a directory service. We needed crude hacks like whois and RADB in the beginning when there were no other tools available and we had networks to build. But now we have lots of tools and technology available. Our companies are probably all spending money today on LDAP directories for internal use. It is becoming a standard IT technology and we should be leveraging it rather than continuing with crude hacks for old times sake. So put it in a perl script and make it look pretty. I'm just showing people that the data _IS_ out there, at least on the /8 level. If you want to wrap something fancy around it, write your own HTTP libraries to grab it yourself then go for it. But the data is there, at least on the /8 level. I would be very interested to hear how many people are generating filters for each and every allocation the RIRs make. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
--On Monday, December 9, 2002 15:43 + [EMAIL PROTECTED] wrote: Yes, spewing out email to solve a simple database synchronization problem seems counter-productive to me. Even a plain ASCII text file mirrored with rsync polling would be a vast improvement over email. But LDAP is proving to be the direction that the world is moving in for this type of directory service so why not leverage the tools and expertise that are available out there? lynx -dump http://www.iana.org/assignments/ipv4-address-space | grep "IANA - Reserved" ? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
> So here's a question for people. For those who filter, what about the > real-time feed that people want from the RIRs is different from this: > lynx -dump http://www.iana.org/assignments/ipv4-address-space | grep "IANA > - Reserved" 1. Missing data. Your solution does not show the parts of 69/8 that ARIN has reserved or unallocated. 2. Referrals. Your solution provides no referral to another source for more detailed data. In another world, if I ask a .org server for www.ipv6.org it will "refer" me to the ipv6.org server who will "refer" me to www.ip6.org. With LDAP we have a directory service that can issue such referrals and have them automatically followed to provide as complete a view as we desire. 3. Not a crude hack. A UNIX shell script scraping data from a text file that was created as a human-readable document is not my idea of a directory service. We needed crude hacks like whois and RADB in the beginning when there were no other tools available and we had networks to build. But now we have lots of tools and technology available. Our companies are probably all spending money today on LDAP directories for internal use. It is becoming a standard IT technology and we should be leveraging it rather than continuing with crude hacks for old times sake. --Michael Dillon
Re: Operational Issues with 69.0.0.0/8...
LB> Date: Mon, 9 Dec 2002 10:04:52 -0500 LB> From: Leo Bicknell LB> Right. Suggest a way IANA could reasonably notify all the LB> users. I personally don't see one. So, responsible or not, LB> they have no good way to notify people. The registries have LB> a way to notify people. Correct. Then the issue is whether or not people respond. I like Jeff Wheeler's post... people who don't update their filters lose GTLD (and root?) nameserver service. And, again, while we're at it -- let's let the NSen in question end in .0 and .255 to help rid the Net of broken "smurf filters". LB> Point is, end users don't deal with IANA. They deal with the LB> registries and for those in North America (this is nanog, LB> isn't it) ARIN is it. As the communities desigated LB> represenative to interface with IANA, I feel it is ARIN's LB> duty to collect and distribute information from IANA. Give Rob Thomas official authority, a paycheck, and the necessary bandwidth. ;-) 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 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>, or you are likely to be blocked.
Re: Operational Issues with 69.0.0.0/8...
> That is a good point, but you are talking about a periodic notification > when new blocks are allocated. Michael is talking about an automated feed > of all unallocated blocks. I'm talking first of all, about a directory listing all the unallocated space that people can query. Secondly, I'm suggesting that this same set of data could be published by ARIN using BGP to make it easier for people to monitor changes. > If we were to invert this and say that ARIN > will provide a list of all blocks that are allocated to it, then that might > be worth doing. I specifically suggested that ARIN provide a list of unallocated blocks because otherwise everyone else has to suck down the entire database of allocated blocks and invert it themselves. If they screw up their inversion algorithm that creates further problems. In an ideal world, IANA would provide a top-level LDAP directory of the entire IPv4 address space with referrals for each large allocation to the RIR LDAP servers just like the DNS delegates a domain to other DNS servers. But it is just as workable for the 4 RIRs to work out some other way of synchronizing the top level of the IPv4 address space and for all 4 of them to publish the entire data set in their local (topologically speaking) servers. > However, I get back to my original question. For people who insist on > filtering unallocated address space, is it too much to ask that they either > subscribe to NANOG, or potentially subscribe to an RIR-specific > announce-only mailing list for such things? Yes. This is the 21st century. Mailing lists are a 19th century technology (memorandums) dressed up with a bit of 20th century technology. We can do better. If we can create routing protocols that dynamically distribute routing topology data, then we can surely come up with an automated way of distributing the IPv4 allocation data. People who are scared of automation can insert the human being inside their own domains of control. But let's use some network protocols for the core distribution of the data. > It seems really silly to me > for the registries to spew a mailing to their entire contact database just > to reach a handful of people who actually do route filtering. Yes, spewing out email to solve a simple database synchronization problem seems counter-productive to me. Even a plain ASCII text file mirrored with rsync polling would be a vast improvement over email. But LDAP is proving to be the direction that the world is moving in for this type of directory service so why not leverage the tools and expertise that are available out there? -- Michael Dillon
Re: Operational Issues with 69.0.0.0/8...
Hello Everyone, I appreciate all of the discussion regarding this issue. Nothing has changed. This is getting worse. We spoke to one network on Friday that said they had cleared the problem, yet our users still can't go there. For those of you that feel this is not anyone's problem, and that the internet should just "work it out"; I hereby challenge one of you to trade CIDRs with us. You take this 69.1.192.0/19 ARIN assigned us and you go spend your valuable time, resources, and money working out what seems to be "nobody's problem". Also, if you would like to come over and answer the support calls and explain to our customers why the competitor's networks can reach these sites, but ours can't. Hey - after all, it's just CIDR - it's all the same, right? Some of you have accused others of being too lazy to call the networks that don't work - I assure all of you we have called the ones we know of - over and over. They still don't work. Some of you have suggested that all we need to do is talk to people. We have been calling and talking for a months (almost three to be exact), and the list of inaccessible sites continues to grow. We have called and talked until we are blue in the face. What all of you don't know, is that for the first month we had this CIDR, we could not register hosts on it at NetSol/Verisign, because their core registry did not recognize it. We have been getting F***ed by this CIDR since day one. We have only been successful with two networks in getting filters removed. How many more are out there? I think we can all agree that whoever's responsibility it is, the current system is broken. You can't actually count on people to read this list. Maybe if IANA and ARIN and the other organizations that are supposed to work together to make all this stuff work weren't so busy trying to pass the buck, someone might have time to figure something out... Somebody out there has to have a spare /19 lying around :-) You know - the good old IP numbers like the ones I used to get - they actually worked ;-) What we do know is that the number ARIN took from us sure worked for them. Do you think they would be calling us if their bank suddenly told them that even though they had delivered IP Addresses to us, they could not receive our 3,000.00 dollars because it originated from a bank that has a previously restricted routing code? Todd
Re: Operational Issues with 69.0.0.0/8...
So here's a question for people. For those who filter, what about the real-time feed that people want from the RIRs is different from this: lynx -dump http://www.iana.org/assignments/ipv4-address-space | grep "IANA - Reserved" ? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
--On Monday, December 9, 2002 10:04 -0500 Leo Bicknell <[EMAIL PROTECTED]> wrote: Point is, end users don't deal with IANA. They deal with the registries and for those in North America (this is nanog, isn't it) ARIN is it. As the communities desigated represenative to interface with IANA, I feel it is ARIN's duty to collect and distribute information from IANA. That is a good point, but you are talking about a periodic notification when new blocks are allocated. Michael is talking about an automated feed of all unallocated blocks. If we were to invert this and say that ARIN will provide a list of all blocks that are allocated to it, then that might be worth doing. Then each RIR could provide its own list and we don't run into the issues of a registry listing objects that it does not control. However, I get back to my original question. For people who insist on filtering unallocated address space, is it too much to ask that they either subscribe to NANOG, or potentially subscribe to an RIR-specific announce-only mailing list for such things? It seems really silly to me for the registries to spew a mailing to their entire contact database just to reach a handful of people who actually do route filtering. It does seem to me that this problem should have a really simple solution. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
In a message written on Mon, Dec 09, 2002 at 07:58:29AM -0700, Alec H. Peterson wrote: > But Michael is not talking about the registries _contacting_ people with a > message about changes in unallocated blocks, he's talking about one > specific regional registry providing a list of all unallocated space (that > still 'belongs' to IANA/ICANN). Right. Suggest a way IANA could reasonably notify all the users. I personally don't see one. So, responsible or not, they have no good way to notify people. The registries have a way to notify people. I'm sure these two groups can work together. Maybe ARIN, APNIC, and RIPE can get IANA mail their user mailing lists. Maybe IANA authorizes one (or all) of them to publish a list. That's up to them to work out. Point is, end users don't deal with IANA. They deal with the registries and for those in North America (this is nanog, isn't it) ARIN is it. As the communities desigated represenative to interface with IANA, I feel it is ARIN's duty to collect and distribute information from IANA. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: Operational Issues with 69.0.0.0/8...
--On Monday, December 9, 2002 9:48 -0500 Leo Bicknell <[EMAIL PROTECTED]> wrote: The problem here is that ARIN (and the other registries) are the ones who can contact the users. But Michael is not talking about the registries _contacting_ people with a message about changes in unallocated blocks, he's talking about one specific regional registry providing a list of all unallocated space (that still 'belongs' to IANA/ICANN). The registries already provide notification about new allocations they receive, though not to individual users. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
In a message written on Mon, Dec 09, 2002 at 07:29:58AM -0700, Alec H. Peterson wrote: > Why would ARIN specifically provide such a list? ARIN is not responsible > for the unallocated space, and there is more in the world than just ARIN. > There are liability issues with that, not to mention the fact that it is > more an IANA function (if for the sake of argument someone would implement > the list). The problem here is that ARIN (and the other registries) are the ones who can contact the users. When these things change all ISP's need to be notified. As much as many people on this list think that every ISP in the world reads Nanog it just isn't so. Who has a list of ISP's? Well, depending on your view of things I think a good argument can be made that it's either the list of everyone with an ASN (my preference, since those are the people who's route filtering matters), or everyone with IPv4 space allocated to them. The only entity with either of those lists is the registries, ARIN, RIPE, APNIC and soforth. If the offical notice needs to come from IANA that's fine, but it needs to go out to the list of members of the registries. IMHO it is there job to make sure IANA has a way to send those sorts of messages. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: Operational Issues with 69.0.0.0/8...
--On Monday, December 9, 2002 14:41 + [EMAIL PROTECTED] wrote: I consider this to be more of a minor technical issue. ARIN can certain provide an authoritative directory for the unallocated portions of its own allocations. And to answer your why question; because only ARIN has an authoritative and up-to-date view of exactly which addresses are and are not allocated. What on earth gives you that idea? Why does only ARIN have this information? Just because it happens to reside in their whois server? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
>Why would ARIN specifically provide such a list? ARIN is not responsible >for the unallocated space, and there is more in the world than just ARIN. >There are liability issues with that, not to mention the fact that it is >more an IANA function (if for the sake of argument someone would implement >the list). I consider this to be more of a minor technical issue. ARIN can certain provide an authoritative directory for the unallocated portions of its own allocations. And to answer your why question; because only ARIN has an authoritative and up-to-date view of exactly which addresses are and are not allocated. Rob Thomas is doing some fine work but he is just plugging a gap created by inaction on the part of the RIRs. I'd like to see RIPE, APNIC and LACNIC also set up authoritative LDAP directories for unallocated IP space at the largest aggregate level. I'd also like to see them all dump the quirky and antiquated whois protocol and move to LDAP as the standard way of querying their directories. The details of which data goes in which directory and whether or not to use referral LDAP or mirrored databases is something which I'm not concerned about. We know a lot about running a distributed directory from experience with DNS so I'm sure that a distributed LDAP hierarchy for the IP address space won't raise any major issues. There is a lot of LDAP expertise out there in the world, lots of books, multiple implementations with years of production experience and people running LDAP directories on a much larger scale than we need. There is no question that it would work, we just need the will to prevail against these problems instead of throwing up our hands and claiming it's too hard, it's impossible and it's not my problem. --Michael Dillon
Re: Operational Issues with 69.0.0.0/8...
--On Monday, December 9, 2002 9:52 + [EMAIL PROTECTED] wrote: Clearly you haven't been following the ppml mailing list. As I have already suggested on that list, ARIN could publish an authoritative directory of all unallocated IP address space at the largest aggregate level in a form that makes it easy for network operators to incorporate into their martian filters. I have been following it quite closely, actually. Why would ARIN specifically provide such a list? ARIN is not responsible for the unallocated space, and there is more in the world than just ARIN. There are liability issues with that, not to mention the fact that it is more an IANA function (if for the sake of argument someone would implement the list). And no, I'm not suggested that anyone connect their productions routers directly to an ARIN BGP feed. Smaller network operators will probably find such a direct BGP feed to be convenient but I expect all the larger network operators to use the BGP feed as a way of monitoring for changes which would be reviewed by some clueful operator before building the filters. That should not be a problem assuming that ARIN issues addresses every weekday. I guess monitoring NANOG or some other mailing list for announcements is somehow a lot more work. Oh well. Alec - Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: HTTP proxies, was Re: Operational Issues with 69.0.0.0/8...
> And don't forget about the biggest of them all, open BIND proxies. After > port 80, port 53 goes through almost as much. A lot of times you don't > need to hack anything, software comes with relay/proxy/recursion enabled. > How do we get software vendors (free, pay, virus) to distribute software > with appropriate defaults? Set up the Net Police. First step, learn from the RBL and other blacklists. Second step, publish a directory. I.e. detect the non-conforming devices and publish their IP addresses in an LDAP server. Third step, use these directories to dynamically configure filters and ACLs and blackhole routes. Fourth step, lean on the vendors to make more things dynamically configurable, i.e. make ACL configuration more like route distribution. That makes the 3rd step easier and will get more of the corporate networking people to police their neighborhoods. Finally, stop raving about how the net police would be bad. They already exist in the form of many disorganized private net police groups like the RBL people, spammer blacklists, NANOG mailing list, CIDR report, CERT, etc. The point is that policing the network itself and the devices that connect to the network is a good thing and should be done in a coordinated fashion. The purpose of publishing stuff using LDAP is because we are not policing people, we are policing machines therefore we need to talk to them in a language they can understand, i.e. a network protocol. And yes, I realize that there are lots of problems with this that need to be solved and slippery slopes that we have to be wary of, but that is not a reason for not trying. --Michael Dillon
Re: Operational Issues with 69.0.0.0/8...
> ARIN explicitly does not guarantee routability of prefixes it assigns. If > service providers choose to filter ARIN allocations, then that is an > operational decision. I really don't see what action you expect ARIN to > take along these lines. Clearly you haven't been following the ppml mailing list. As I have already suggested on that list, ARIN could publish an authoritative directory of all unallocated IP address space at the largest aggregate level in a form that makes it easy for network operators to incorporate into their martian filters. Fast forward to the time when everyone gets their filters directly or indirectly hooked up to the RIR's authoritative directory and this problem goes away. Yes, ARIN cannot directly make the problem go away but ARIN definitely can take action that will lead to a solution of the problem of martian filters. The only thing ARIN would have to guarantee is that their directory is authoritative, complete and updated at least once every 24 hours. The base directory could be published in LDAP form with a BGP version for people who find it easier to work with this. And no, I'm not suggested that anyone connect their productions routers directly to an ARIN BGP feed. Smaller network operators will probably find such a direct BGP feed to be convenient but I expect all the larger network operators to use the BGP feed as a way of monitoring for changes which would be reviewed by some clueful operator before building the filters. That should not be a problem assuming that ARIN issues addresses every weekday. --Michael Dillon
RE: Operational Issues with 69.0.0.0/8...
JSW> Date: 07 Dec 2002 14:16:46 -0500 JSW> From: Jeff S Wheeler JSW> I suggest moving all of the GTLD name servers into newly JSW> allocated blocks as they become available. This will JSW> certainly break networks which are low on operational clue, JSW> and force them to get fixed. Let the GTLD nameservers end in .0 and .255 while we're at it. 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 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>, or you are likely to be blocked.
RE: Operational Issues with 69.0.0.0/8...
On Sat, 2002-12-07 at 08:56, Todd A. Blank wrote: > 4) Listen to feedback from the first few people allocated space >and if it still is not properly routed send out another notice >to people and possibly delay additional allocations from the >block for another month. I disagree with this part of your suggestion. Delaying new allocations will only serve to delay acceptance of new spaces. If you implement all the other safeguards you have suggested, the multitude of notices should ensure that clued, well-informed, responsible networks have ample time to make adjustments in their networks. Networks not among those will most likely not respond until their downstream customers complain, and the best way to get those complaints started is to get more folks into those new networks. I suggest moving all of the GTLD name servers into newly allocated blocks as they become available. This will certainly break networks which are low on operational clue, and force them to get fixed. -- Jeff S Wheeler <[EMAIL PROTECTED]> 502-523-6989
Re: Operational Issues with 69.0.0.0/8...
> Force ISPs to register with the gov't and do > IRR built packet and routing filters. > > Distribute the data quarterly on a LERG-like CD > for startups to use and keep the people who can't keep > their routers up-to-date off the net. > > - jared > > (if you can't tell i'm joking ...) Jeeesh... Say that quietly, Jared. My boss actually thinks we -should- force ISPs to register with the government And he owns an ISP! $deity forbid he thinks he has a supporter... -j
RE: Operational Issues with 69.0.0.0/8...
This will never work - because it all makes way too much sense... -Original Message- From: Leo Bicknell [mailto:[EMAIL PROTECTED]] Sent: Friday, December 06, 2002 5:18 PM To: 'Adam Tauvix Debus'; [EMAIL PROTECTED] Subject: Re: Operational Issues with 69.0.0.0/8... In a message written on Fri, Dec 06, 2002 at 01:44:15PM -0700, Alec H. Peterson wrote: > ARIN announced the fact that it received the 69/8 delegation on August 8th. > ARIN received the delegation on August 6th. ARIN made its first > allocation/assignment (I don't know which it was, but that isn't important) > out of that block on September 19th. [snip] > Do people have any suggestions for ARIN (and other RIRs) on how they can > better dissemenate this information so that people will update their > filters? * One month from filtered to first use is too short. Should be 6 months, with multiple notices. To back this up I can point to a number of places that stopped all global changes from before thanksgiving to after christmas. (Not that I support such things.) * Mailing nanog is nice, but ARIN probably should mail all the ARIN members, or particularly people with ASN's. Far too many people view the nanog mailing list as entertainment, rather than operational necessity. * Space that goes from "reserved" to "in use" should be test routed first. Perhaps more of a job for ISI before they turn it over than ARIN. This allows people to make sure their changes actually worked. * Maintain an RADB object of reserved space, so those with automated tools can easily query it. * Perhaps offer a BGP feed (multi-hop, a-la RBL) of reserved space to ARIN members. If I were in charge it would be: 1) Notify all ARIN members 6 months in advance of the block being used. At the same time, announce the block from somewhere so people can check that they do in fact hear it as they open up their filters. 2) Notify people 3 months, 1 month, and 1 week before making the first allocation. 3) Drop the supernet test on the same day of the first allocation. 4) Listen to feedback from the first few people allocated space and if it still is not properly routed send out another notice to people and possibly delay additional allocations from the block for another month. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: Operational Issues with 69.0.0.0/8...
On Fri, 6 Dec 2002, Rob Thomas wrote: > I (and Steve Gill) am more than happy to create such a list. Heck, you > don't even have to bug me! :) I've even pondered the idea of hosting > a WHOIS server that contains only bogon ranges. So many martian lists, so little authority. > whois -h whois.radb.net rs-martians route-set:rs-martians descr:Martian networks members: 0.0.0.0/0^32, 10.0.0.0/8^+, 192.168.0.0/16^+, 128.0.0.0/16^+, 192.0.0.0/24^+, 224.0.0.0/3^+, 127.0.0.0/8^+, 172.16.0.0/20^+, 192.0.2.0/24^+, 191.255.0.0/16^+, 223.255.255.0/24^+, 0.0.0.0/0^26-32 remarks: these networks and any more-specific networks are not remarks: accepted by eu-X across any peering points admin-c: EUX-RIPE tech-c: EUX-RIPE notify: [EMAIL PROTECTED] mnt-by: VASNET-MNT changed: [EMAIL PROTECTED] 20011020 source: RIPE route-set:RS-MARTIANS descr:The ff. routes should be denied by all border router members: 0.0.0.0/0, 127.0.0.0/8^+, 10.0.0.0/8^+, 172.16.0.0/20^+, 192.168.0.0/16^+, 192.0.2.0/24^+, 128.0.0.0/16^+, 191.255.0.0/16^+, 192.0.0.0/24^+, 223.255.255.0/24^+, 224.0.0.0/3^+, 0.0.0.0/0^26-32 remarks: These routes are usually blocked by ISPs. tech-c: AP16-AP admin-c: AP16-AP notify: [EMAIL PROTECTED] mnt-by: MAINT-AU-BLUETOOTH changed: [EMAIL PROTECTED] 2002 source: APNIC route-set: rs-martians descr: Martian and IANA reserved networks members: 0.0.0.0/7, 2.0.0.0/8, 5.0.0.0/8, 10.0.0.0/8, 23.0.0.0/8, 27.0.0.0/8, 31.0.0.0/8, 36.0.0.0/7, 39.0.0.0/8, 41.0.0.0/8, 42.0.0.0/8, 58.0.0.0/7, 60.0.0.0/8, 70.0.0.0/7, 72.0.0.0/5, 83.0.0.0/8, 84.0.0.0/6, 88.0.0.0/5, 96.0.0.0/3, 127.0.0.0/8, 128.0.0.0/16, 128.66.0.0/16, 172.16.0.0/12, 191.255.0.0/16, 192.0.0.0/24, 192.0.2.0/24, 192.0.128.0/17, 192.31.196.0/24, 192.52.193.0/24, 192.67.23.0/24, 192.68.185.0/24, 192.70.192.0/21, 192.70.200.0/23, 192.94.77.0/24, 192.94.78.0/24, 192.168.0.0/16, 197.0.0.0/8, 198.97.38.0/24, 201.0.0.0/8, 222.0.0.0/7 remarks: these networks and any more-specific networks are not remarks: accepted by Level 3 across any peering points admin-c: LV3-LEVEL3 tech-c:LV3-LEVEL3 notify:[EMAIL PROTECTED] mnt-by:LEVEL3-MNT changed: [EMAIL PROTECTED] 20021125 source:LEVEL3 > The problem with all martian lists, going back to the very first one, is third-party maintainers eventually stop maintaining them after a few years while the lists themselves get embedded in many unexpected places. I'm sure Rob will do a great job for a few years, but no one does this forever. IANA is the source of the delegations, maintainer of the assignments, and is authoritative (i.e. if IANA gets it wrong, we're all screwed). The simpliest solution is when IANA delegates an IPv4/IPv6 block for something to post a message to the IETF-Announce, and the appropriate IANA and RIR list, much like the RFC-Editor does with RFCs.
Re: Operational Issues with 69.0.0.0/8...
Hi, NANOGers. ] Why don't we all go bug Rob Thomas for a bogon update mailing list, ] and stop pissing and moaning on this one. :) I (and Steve Gill) am more than happy to create such a list. Heck, you don't even have to bug me! :) I've even pondered the idea of hosting a WHOIS server that contains only bogon ranges. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: Operational Issues with 69.0.0.0/8...
On Fri, 6 Dec 2002 16:52:38 -0500, Richard A Steenbergen wrote: >You are under the delusion tht ARIN is selling goods. If they were, we'd >all have something to complain about. ARIN is selling you 5 bytes, a >couple records for contact info, a whois server, a template processing >system which takes 3 days to work, and meetings in tropical locations (for >$2500+, sounds fair right? :P). Then could you please explain this to ARIN. They seem to be under the misconception that they are allocating IPv4 address space for use on the global Internet. Once they understand that they're just selling you 5 bytes, they can stop all this nonsense about showing need for address space on the Internet and efficient use of same. DS
Re: Operational Issues with 69.0.0.0/8...
On Fri, Dec 06, 2002 at 12:14:51PM -0500, James Smith wrote: > One would think that operators not updating filters to permit > properly allocated space IS an operational issue. To quote a friend "public shaming will only go so far". At some point, you have to communicate to your customers and to the customers of the broken networks that the vendor shouldn't be used. This is one case where no attempt at finger-pointing could even remotely be made; when a customer/whoever protests, offer to conference in with $broken_network's technical people and have them admit they're broken. It's the same approach needed for fixing wildly random deaggregation. Actually *talking* to people works. I think I already pointed to the one hole that might be ARIN's problem to fix, but to be blunt about it... I wouldn't expect NO entry for properly activated/allocated space. Regardless if you choose the RIPE approach, the APNIC approach, or come up with a new one, the values returned for queries should at least differentiate from "space over which I have authority" and "space over which I do not have authority": prompt> whois -h rr.arin.net 69.0.0.0/8 % ARIN Internet Routing Registry Whois Interface % No entries found in ANS, ARCSTAR, ARIN, BCONNEX, % BELL, CANET, CW, FGC, KOREN, LEVEL3, POC, RADB, RIPE and VERIO database. prompt> whois -h rr.arin.net 70.0.0.0/8 % ARIN Internet Routing Registry Whois Interface % No entries found in ANS, ARCSTAR, ARIN, BCONNEX, % BELL, CANET, CW, FGC, KOREN, LEVEL3, POC, RADB, RIPE and VERIO database. prompt> -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: Operational Issues with 69.0.0.0/8...
In a message written on Fri, Dec 06, 2002 at 01:44:15PM -0700, Alec H. Peterson wrote: > ARIN announced the fact that it received the 69/8 delegation on August 8th. > ARIN received the delegation on August 6th. ARIN made its first > allocation/assignment (I don't know which it was, but that isn't important) > out of that block on September 19th. [snip] > Do people have any suggestions for ARIN (and other RIRs) on how they can > better dissemenate this information so that people will update their > filters? * One month from filtered to first use is too short. Should be 6 months, with multiple notices. To back this up I can point to a number of places that stopped all global changes from before thanksgiving to after christmas. (Not that I support such things.) * Mailing nanog is nice, but ARIN probably should mail all the ARIN members, or particularly people with ASN's. Far too many people view the nanog mailing list as entertainment, rather than operational necessity. * Space that goes from "reserved" to "in use" should be test routed first. Perhaps more of a job for ISI before they turn it over than ARIN. This allows people to make sure their changes actually worked. * Maintain an RADB object of reserved space, so those with automated tools can easily query it. * Perhaps offer a BGP feed (multi-hop, a-la RBL) of reserved space to ARIN members. If I were in charge it would be: 1) Notify all ARIN members 6 months in advance of the block being used. At the same time, announce the block from somewhere so people can check that they do in fact hear it as they open up their filters. 2) Notify people 3 months, 1 month, and 1 week before making the first allocation. 3) Drop the supernet test on the same day of the first allocation. 4) Listen to feedback from the first few people allocated space and if it still is not properly routed send out another notice to people and possibly delay additional allocations from the block for another month. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Re: Operational Issues with 69.0.0.0/8...
RD> Date: Fri, 6 Dec 2002 16:30:28 -0500 (EST) RD> From: Ralph Doncaster RD> People depend on ARIN's IP assignments being widely routable. As much as I get frustrated with ARIN, they don't have much control in this situation. Hang on. A guy with a badge that says "ARIN" is at the door; he says he's making a surprise filter audit. I'll finish posting later after he leaves... 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 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>, or you are likely to be blocked.
RE: Operational Issues with 69.0.0.0/8...
Oh, Ok. I was wondering if IANA, ARIN, RIPE, APNIC had an announce-only mailing alias for operational announcements. Rather than relying on finding the messages in the middle of the NANOG stream of thought. The RFC-Editor seems to have the process down for announcing new RFCs. On Fri, 6 Dec 2002, Alec H. Peterson wrote: > Sorry, the announcement was made on NANOG. > > Alec > > --On Friday, December 6, 2002 13:44 -0700 "Alec H. Peterson" > <[EMAIL PROTECTED]> wrote: > > > > > --On Friday, December 6, 2002 15:29 -0500 Sean Donelan <[EMAIL PROTECTED]> > > wrote: > > > >> > >> Sorry, which operational aliases did the RIRs announce before they > >> started allocating addreses? > > > > ARIN announced the fact that it received the 69/8 delegation on August > > 8th. ARIN received the delegation on August 6th. ARIN made its first > > allocation/assignment (I don't know which it was, but that isn't > > important) out of that block on September 19th. > > > > So, that's over 1 month that people had to fix their filters. We're in > > December now, and clearly some people still haven't updated their filters. > > > > Do people have any suggestions for ARIN (and other RIRs) on how they can > > better dissemenate this information so that people will update their > > filters? > > > > Alec > > > > -- > > Alec H. Peterson -- [EMAIL PROTECTED] > > Chief Technology Officer > > Catbird Networks, http://www.catbird.com > > > -- > Alec H. Peterson -- [EMAIL PROTECTED] > Chief Technology Officer > Catbird Networks, http://www.catbird.com >
Re: Operational Issues with 69.0.0.0/8...
On Fri, Dec 06, 2002 at 04:30:28PM -0500, Ralph Doncaster wrote: > > People depend on ARIN's IP assignments being widely routable. When 2 > different ARIN clients pay the same amount of money for leasing an IP > block, the "goods" they receive should be of the same quality. You are under the delusion tht ARIN is selling goods. If they were, we'd all have something to complain about. ARIN is selling you 5 bytes, a couple records for contact info, a whois server, a template processing system which takes 3 days to work, and meetings in tropical locations (for $2500+, sounds fair right? :P). Under this logic you would like them to sell you low ASNs because high ones don't get much respect and are therefore defective? How about refusing to take 3.1.33.7 because it got spoofed and/or packeted a lot? ARIN should make a good faith effort to hand out registrations which are going to be usable, but it is not their job to make sure noone else on the internet dislikes your IP. Besides, the policies usually follow ARIN, not the other way around. People design prefix length filters around the RIR allocation sizes, not arbitrary numbers the expect the RIR's to follow. People unfilter prefixes when they start getting allocated, not because they feel like they should so ARIN can allocate from it. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Operational Issues with 69.0.0.0/8...
On Fri, 6 Dec 2002, Ralph Doncaster wrote: > ARIN clients should have the ability to exchange defective "goods". It > seems ARIN won't do this. And posting to NANOG or similar lists doesn't > seem to fix the problem. Sooner or later someone's going to decide to let > the lawyers deal with it. I don't think ARIN's resources should be wasted > in the courts. ARIN can't change (or even detect) who's filtering what. They likely have no way of knowing in advance if any IP block is filtered anywhere. How many places need to block your IP before you declare the IP bad? Should ARIN announce and test connectivity with some standard suite before giving each allocation? Should the end-user be given some trial period during which they can do this? What happens when ARIN runs out of IPs that don't appear to be filtered by any recognized network? This is an unfortunate pitfall that goes along with portable IP space and BGP. When I got the company's first ARIN block at a previous employer (back in the late 90s), we ran into issues with several large/well known networks ignoring our BGP route. Some were fixed just by doing the RADB thing. Some had to be emailed or phone called before they fixed their filters. This isn't a new problem, and there's no magic solution ARIN can execute...at least not that anyone's come up with so far. ...wondering when we'll hear from Dalph on the matter. :) -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: Operational Issues with 69.0.0.0/8...
> > How would more registries help? It would just add more > voices, not the > > number of ears listening.. > > Canadians have a lot more influence on CIRA than on ARIN. Without the pressure from operators assigned out of new space no action would take place. If it was possible to return a block for a new one, there's only so much address space that a RIR could possibly hand out, we'll still come back to the problem of routing new blocks. Kris
RE: Operational Issues with 69.0.0.0/8...
> This type of problem is likely to spur interest in more regional > registries. There's been talk of CIRA seting up a Canadian IP there already has been a canadian ip address registry. there no longer is. learn from history. randy
RE: Operational Issues with 69.0.0.0/8...
On Fri, 6 Dec 2002, Kris Foster wrote: > > This type of problem is likely to spur interest in more regional > > registries. There's been talk of CIRA seting up a Canadian IP > > How would more registries help? It would just add more voices, not the > number of ears listening.. Canadians have a lot more influence on CIRA than on ARIN. -Ralph
RE: Operational Issues with 69.0.0.0/8...
> This type of problem is likely to spur interest in more regional > registries. There's been talk of CIRA seting up a Canadian IP How would more registries help? It would just add more voices, not the number of ears listening.. Kris
Re: Operational Issues with 69.0.0.0/8...
On Fri, 6 Dec 2002, Richard A Steenbergen wrote: > If you're going to filter, it is your job to keep the filters updated, not > ARIN's. Nor is it ARIN's job to move your blocks around every time some > idiot doesn't accept it, or after you manage to get it blacklisted, or > whatever. They need to allocate more space from 69 so anyone still > filtering it wonders why they can't get to their latest porn site (no > pun intended) and fix it. People depend on ARIN's IP assignments being widely routable. When 2 different ARIN clients pay the same amount of money for leasing an IP block, the "goods" they receive should be of the same quality. ARIN clients should have the ability to exchange defective "goods". It seems ARIN won't do this. And posting to NANOG or similar lists doesn't seem to fix the problem. Sooner or later someone's going to decide to let the lawyers deal with it. I don't think ARIN's resources should be wasted in the courts. This type of problem is likely to spur interest in more regional registries. There's been talk of CIRA seting up a Canadian IP registry. This has been handled by ARIN took over the work UofT was doing years ago. -Ralph
Re: Operational Issues with 69.0.0.0/8...
On Fri, Dec 06, 2002 at 01:44:15PM -0700, Alec H. Peterson wrote: > > Do people have any suggestions for ARIN (and other RIRs) on how they can > better dissemenate this information so that people will update their > filters? If you're going to filter, it is your job to keep the filters updated, not ARIN's. Nor is it ARIN's job to move your blocks around every time some idiot doesn't accept it, or after you manage to get it blacklisted, or whatever. They need to allocate more space from 69 so anyone still filtering it wonders why they can't get to their latest porn site (no pun intended) and fix it. Is it honestly that much work to send an email, "psst you're still filtering 69/8, stop it" whenever you run into that situation? Why don't we all go bug Rob Thomas for a bogon update mailing list, and stop pissing and moaning on this one. :) -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Operational Issues with 69.0.0.0/8...
On Fri, Dec 06, 2002 at 01:44:15PM -0700, Alec H. Peterson wrote: > > --On Friday, December 6, 2002 15:29 -0500 Sean Donelan <[EMAIL PROTECTED]> > wrote: > > > > >Sorry, which operational aliases did the RIRs announce before they started > >allocating addreses? > > ARIN announced the fact that it received the 69/8 delegation on August 8th. > ARIN received the delegation on August 6th. ARIN made its first > allocation/assignment (I don't know which it was, but that isn't important) > out of that block on September 19th. > > So, that's over 1 month that people had to fix their filters. We're in > December now, and clearly some people still haven't updated their filters. > > Do people have any suggestions for ARIN (and other RIRs) on how they can > better dissemenate this information so that people will update their > filters? > Force ISPs to register with the gov't and do IRR built packet and routing filters. Distribute the data quarterly on a LERG-like CD for startups to use and keep the people who can't keep their routers up-to-date off the net. - jared (if you can't tell i'm joking ...) -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: Operational Issues with 69.0.0.0/8...
Sorry, the announcement was made on NANOG. Alec --On Friday, December 6, 2002 13:44 -0700 "Alec H. Peterson" <[EMAIL PROTECTED]> wrote: --On Friday, December 6, 2002 15:29 -0500 Sean Donelan <[EMAIL PROTECTED]> wrote: Sorry, which operational aliases did the RIRs announce before they started allocating addreses? ARIN announced the fact that it received the 69/8 delegation on August 8th. ARIN received the delegation on August 6th. ARIN made its first allocation/assignment (I don't know which it was, but that isn't important) out of that block on September 19th. So, that's over 1 month that people had to fix their filters. We're in December now, and clearly some people still haven't updated their filters. Do people have any suggestions for ARIN (and other RIRs) on how they can better dissemenate this information so that people will update their filters? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: Operational Issues with 69.0.0.0/8...
--On Friday, December 6, 2002 15:29 -0500 Sean Donelan <[EMAIL PROTECTED]> wrote: Sorry, which operational aliases did the RIRs announce before they started allocating addreses? ARIN announced the fact that it received the 69/8 delegation on August 8th. ARIN received the delegation on August 6th. ARIN made its first allocation/assignment (I don't know which it was, but that isn't important) out of that block on September 19th. So, that's over 1 month that people had to fix their filters. We're in December now, and clearly some people still haven't updated their filters. Do people have any suggestions for ARIN (and other RIRs) on how they can better dissemenate this information so that people will update their filters? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: Operational Issues with 69.0.0.0/8...
Well, to increase chance of reachability of blocks immediately after RIRs start making assignments, RIRs should request new assignments from IANA well ahead of exhaustion of currently-held blocks. Possibly, considering that ARIN and RIPE run through 1 /8 a year, a "spare" /8 should be allocated to them (and filter-making folks dropping filtering). Smaller registries (APNIC, LACNIC), under this proposal, would request a /8 when their current /8 is 50% full. This should reduce frequency of required filter updates to once a year or less. -alex On Fri, 6 Dec 2002, Barry Raveendran Greene wrote: > > > IMHO - The RIRs are doing their part. They announce to the operations > aliases their intention to allocate a new block before they start doing > it. People like me (with the ingress-prefix-template), Rob Thomas (with > the bogon template), and Steve Gill (with the Junos flavor of the > ingress-prefix-template) start tweaking our templates and post them to > the community. > > After that, it would be up to each operations team to execute within > their own network. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > Adam "Tauvix" Debus > Sent: Friday, December 06, 2002 12:16 PM > To: [EMAIL PROTECTED] > Subject: Re: Operational Issues with 69.0.0.0/8... > > > > > > So for the sake of argument, in your proposal an ISP could filter all > of > > the blocks that the RIRs allocate out of and hamstring them > indefinitely? > > > > Perhaps not, but an X month period after the inital allocation to > the > RIR where they don't assign out of that pool might be wise. Perhaps > e-mails > can be sent to the registered contacts of existing IP space upon initial > allocation, on the first of each month, and then on the last day of the > hold. > > I know that I am sometimes a bit too busy to take care of something > like > that at the very instant I get the e-mail, and that it can fall to the > wayside. Many times a reminder e-mail has come at a moment where I was > able > do to something about it. > > Thanks, > > Adam "Tauvix" Debus > Linux Certified Professional, Linux Certified Administrator #447641 > Network Administrator, ReachONE Internet > [EMAIL PROTECTED] > >
RE: Operational Issues with 69.0.0.0/8...
Sorry, which operational aliases did the RIRs announce before they started allocating addreses? On Fri, 6 Dec 2002, Barry Raveendran Greene wrote: > IMHO - The RIRs are doing their part. They announce to the operations > aliases their intention to allocate a new block before they start doing > it. People like me (with the ingress-prefix-template), Rob Thomas (with > the bogon template), and Steve Gill (with the Junos flavor of the > ingress-prefix-template) start tweaking our templates and post them to > the community. > > After that, it would be up to each operations team to execute within > their own network. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of > Adam "Tauvix" Debus > Sent: Friday, December 06, 2002 12:16 PM > To: [EMAIL PROTECTED] > Subject: Re: Operational Issues with 69.0.0.0/8... > > > > > > So for the sake of argument, in your proposal an ISP could filter all > of > > the blocks that the RIRs allocate out of and hamstring them > indefinitely? > > > > Perhaps not, but an X month period after the inital allocation to > the > RIR where they don't assign out of that pool might be wise. Perhaps > e-mails > can be sent to the registered contacts of existing IP space upon initial > allocation, on the first of each month, and then on the last day of the > hold. > > I know that I am sometimes a bit too busy to take care of something > like > that at the very instant I get the e-mail, and that it can fall to the > wayside. Many times a reminder e-mail has come at a moment where I was > able > do to something about it. > > Thanks, > > Adam "Tauvix" Debus > Linux Certified Professional, Linux Certified Administrator #447641 > Network Administrator, ReachONE Internet > [EMAIL PROTECTED] > > >
Re: HTTP proxies, was Re: Operational Issues with 69.0.0.0/8...
On Fri, 6 Dec 2002, Rob Thomas wrote: > ] We now get to embark on another Five Year Plan to shut down > ] open HTTP proxies. > > Indeed. The number of open (and openly abused) proxies in my hacked > device database, just from this year, is 21255. That's just my own, > small view of the problem. Imagine the total number. :/ Watch out > for those TCP 1080, 3128, and 8080 flows. And don't forget about the biggest of them all, open BIND proxies. After port 80, port 53 goes through almost as much. A lot of times you don't need to hack anything, software comes with relay/proxy/recursion enabled. How do we get software vendors (free, pay, virus) to distribute software with appropriate defaults? We blocked port 25, and the spammers used other ports. Should we block IP protocols 0-255, and ports 0-65535? Should we move to the cable TV model, you can watch only what we decide you can watch? Users should be receive-only?
RE: Operational Issues with 69.0.0.0/8...
IMHO - The RIRs are doing their part. They announce to the operations aliases their intention to allocate a new block before they start doing it. People like me (with the ingress-prefix-template), Rob Thomas (with the bogon template), and Steve Gill (with the Junos flavor of the ingress-prefix-template) start tweaking our templates and post them to the community. After that, it would be up to each operations team to execute within their own network. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Adam "Tauvix" Debus Sent: Friday, December 06, 2002 12:16 PM To: [EMAIL PROTECTED] Subject: Re: Operational Issues with 69.0.0.0/8... > > So for the sake of argument, in your proposal an ISP could filter all of > the blocks that the RIRs allocate out of and hamstring them indefinitely? > Perhaps not, but an X month period after the inital allocation to the RIR where they don't assign out of that pool might be wise. Perhaps e-mails can be sent to the registered contacts of existing IP space upon initial allocation, on the first of each month, and then on the last day of the hold. I know that I am sometimes a bit too busy to take care of something like that at the very instant I get the e-mail, and that it can fall to the wayside. Many times a reminder e-mail has come at a moment where I was able do to something about it. Thanks, Adam "Tauvix" Debus Linux Certified Professional, Linux Certified Administrator #447641 Network Administrator, ReachONE Internet [EMAIL PROTECTED]
Re: Operational Issues with 69.0.0.0/8...
> > So for the sake of argument, in your proposal an ISP could filter all of > the blocks that the RIRs allocate out of and hamstring them indefinitely? > Perhaps not, but an X month period after the inital allocation to the RIR where they don't assign out of that pool might be wise. Perhaps e-mails can be sent to the registered contacts of existing IP space upon initial allocation, on the first of each month, and then on the last day of the hold. I know that I am sometimes a bit too busy to take care of something like that at the very instant I get the e-mail, and that it can fall to the wayside. Many times a reminder e-mail has come at a moment where I was able do to something about it. Thanks, Adam "Tauvix" Debus Linux Certified Professional, Linux Certified Administrator #447641 Network Administrator, ReachONE Internet [EMAIL PROTECTED]
Re: Operational Issues with 69.0.0.0/8...
--On Friday, December 6, 2002 13:48 -0600 Stephen Sprunk <[EMAIL PROTECTED]> wrote: This is a case of ARIN knowingly assigning unusable space to customers. There's a huge difference there. So for the sake of argument, in your proposal an ISP could filter all of the blocks that the RIRs allocate out of and hamstring them indefinitely? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
Thus spake "Alec H. Peterson" <[EMAIL PROTECTED]> > > I see this as purely an operational issue. > > ARIN explicitly does not guarantee routability of prefixes it assigns. This is a case of ARIN knowingly assigning unusable space to customers. There's a huge difference there. > If service providers choose to filter ARIN allocations, then that is an > operational decision. I really don't see what action you expect ARIN to > take along these lines. Assign him some temporarly space in a usable block while he tries to get the offending ASs to fix their filters, and stop assigning out of 69/8 until it actually works. This isn't rocket science. S
HTTP proxies, was Re: Operational Issues with 69.0.0.0/8...
Hi, NANOGers. ] We now get to embark on another Five Year Plan to shut down ] open HTTP proxies. Indeed. The number of open (and openly abused) proxies in my hacked device database, just from this year, is 21255. That's just my own, small view of the problem. Imagine the total number. :/ Watch out for those TCP 1080, 3128, and 8080 flows. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: Operational Issues with 69.0.0.0/8...
On Fri, 06 Dec 2002 13:17:56 EST, Joe Abley said: > If there was definitively no way to educate this community, or to > provide tools or methodologies which allowed members of it to > cooperate, the Internet would not exist. The problem is that there's a large trickle-down factor to deal with. Yes, after many years, we've *finally* gotten most sites to shut down their open SMTP relays. We now get to embark on another Five Year Plan to shut down open HTTP proxies. However, the people impacted by the 69.0.0.0/8 problem can't wait that long for people to fix their martian filters. msg07209/pgp0.pgp Description: PGP signature
RE: Operational Issues with 69.0.0.0/8...
Thanks for all of the suggestions we have received. If I had only known that talking about ARIN on NANOG was the hot button, I would have pressed it a long time ago :-) I do have some operational factoids to add - my prior post was incomplete. We are multi-homed in a carrier neutral data center. It is imperative that we have our own IP. I do have some small bits of CIDR from other ISPs and have already migrated some of the problem customers to other blocks, but I am not meeting my SLAs with those customers, because we guarantee multiple paths. On IP that belongs to an upstream of ours, traffic only comes inbound through that upstream. That is a problem. Sorry if talking about ARIN is off the topic of this list, but the 69/8 CIDR is "broken" (in customer terms) in lots of places on the internet. ARIN is the one assigning it. If they keep assigning it before everyone's access policies recognize it as valid, this "non-operational" issue is going to cost a lot of people a lot of money in wasted time, effort and resources. I know it has been very painful for us. -Original Message- From: Todd A. Blank Sent: Friday, December 06, 2002 10:23 AM To: [EMAIL PROTECTED] Subject: Re: Operational Issues with 69.0.0.0/8... The list of inaccessible sites continues to grow: Add to the list www.oandp.com - that looks like someone's firewall filtering in front of their DNS server, because we can't even resolve the DNS. We still can't get to www.ocas.com, www.lavalife.com, and www.indofilms.com even after calling and posting repeatedly. There are undoubtedly others out there. Repeated problems posted by myself and others show the extent of the problem with the 69.0.0.0/8 CIDR, and its lack of dependability - it's a human thing. It used to be restricted, so there are a lot of access lists out there - with all the stuff going on in the last year or so, half the people blocking it probably don't even know how to unblock it - i.e. that person no longer works here... If you look at the address space on IANA, http://www.iana.org/assignments/ipv4-address-space you will see that the last CIDR ARIN took before 69/8 was over a year prior to the 69/8 assignment. A lot happened in our industry in that year. Somewhere, this process is broken since the last CIDR was assigned to ARIN. My question is as follows - We are losing customers because of this problem. It is costing us reputation and money. It is out of our control. If you were us, what would you do? We have already asked ARIN to reassign us to a "friendlier" CIDR, and they refuse. Suggestions are welcome. Sincerely, Todd A. Blank CTO IPOutlet LLC 614.207.5853
Re: Operational Issues with 69.0.0.0/8...
On Friday, Dec 6, 2002, at 12:18 Canada/Eastern, [EMAIL PROTECTED] wrote: ARIN don't guarantee routability of the blocks they allocate, and it's difficult to see how they ever could. If you want to discuss what ARIN could or could not do, then please join the ARIN ppml list. I don't, but thank you for the advice. Perhaps this is an issue of community education, or one of needing better tools or methods for managing martian filters. Those issues are arguably both technical and operational. The original poster doesn't have a problem with the community. He has a problem with network operators who are not part of the community and that is a reality of today's Internet that cannot be dealt with by technical tools or operational methods. By "community" I meant "people who operate devices connected to the Internet". If there was definitively no way to educate this community, or to provide tools or methodologies which allowed members of it to cooperate, the Internet would not exist. Joe
Re: Operational Issues with 69.0.0.0/8...
--On Friday, December 6, 2002 16:57 + [EMAIL PROTECTED] wrote: This is no longer a technical operational issue so it is out of scope for this mailing list. But if you think that ARIN could do something to solve your problem then you should raise the issue on the ARIN public policy mailing list. You can find subscription information for that list here http://www.arin.net/mailing_lists/index.html I see this as purely an operational issue. ARIN explicitly does not guarantee routability of prefixes it assigns. If service providers choose to filter ARIN allocations, then that is an operational decision. I really don't see what action you expect ARIN to take along these lines. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: Operational Issues with 69.0.0.0/8...
>> My question is as follows - We are losing customers because of this >> problem. It is costing us reputation and money. It is out of our >> control. If you were us, what would you do? We have already asked >> ARIN >> to reassign us to a "friendlier" CIDR, and they refuse. >ARIN don't guarantee routability of the blocks they allocate, and it's >difficult to see how they ever could. If you want to discuss what ARIN could or could not do, then please join the ARIN ppml list. > Perhaps this is an issue of community education, or one of needing > better tools or methods for managing martian filters. Those issues are > arguably both technical and operational. The original poster doesn't have a problem with the community. He has a problem with network operators who are not part of the community and that is a reality of today's Internet that cannot be dealt with by technical tools or operational methods. But there are non-technical and non-operational actions actions that ARIN could take to help. The details of those actions and whether or not ARIN members want to act are matters for the ppml list. --Michael Dillon
RE: Operational Issues with 69.0.0.0/8...
Title: RE: Operational Issues with 69.0.0.0/8... One would think that operators not updating filters to permit properly allocated space IS an operational issue. True, there are some non-operational facets to the issue, but that is not sufficient to call this off-topic... I can think of no better place than NANOG to say "Hey, some of you still have not updated your filters, I still do not have the reachability I should have.". His problem is indicative of future problems to come as we expand the use of previously unallocated IPv4 space. If the community cannot solve his problem, what reachability assurance do we have on any future allocations out of spaces with a similar history? James H. Smith II NNCSE NNCDS Senior Systems Engineer First Call Response Center The Presidio Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, December 06, 2002 11:57 AM To: [EMAIL PROTECTED] Subject: Re: Operational Issues with 69.0.0.0/8... > My question is as follows - We are losing customers because of this > problem. It is costing us reputation and money. It is out of our > control. If you were us, what would you do? We have already asked ARIN > to reassign us to a "friendlier" CIDR, and they refuse. This is no longer a technical operational issue so it is out of scope for this mailing list. But if you think that ARIN could do something to solve your problem then you should raise the issue on the ARIN public policy mailing list. You can find subscription information for that list here http://www.arin.net/mailing_lists/index.html -- Michael Dillon
Re: Operational Issues with 69.0.0.0/8...
short term fix if its costing you would be to get an assigment from another LIR's allocation.. and hold of the 69/8 for a while.. now how much can i sell you a /20 for ;p On Fri, 6 Dec 2002, Joe Abley wrote: > > > On Friday, Dec 6, 2002, at 11:57 Canada/Eastern, > [EMAIL PROTECTED] wrote: > > >> My question is as follows - We are losing customers because of this > >> problem. It is costing us reputation and money. It is out of our > >> control. If you were us, what would you do? We have already asked > >> ARIN > >> to reassign us to a "friendlier" CIDR, and they refuse. > > > > This is no longer a technical operational issue so it is out of scope > > for > > this mailing list. > > ARIN don't guarantee routability of the blocks they allocate, and it's > difficult to see how they ever could. > > Perhaps this is an issue of community education, or one of needing > better tools or methods for managing martian filters. Those issues are > arguably both technical and operational. > > > Joe > >
Re: Operational Issues with 69.0.0.0/8...
On Friday, Dec 6, 2002, at 11:57 Canada/Eastern, [EMAIL PROTECTED] wrote: My question is as follows - We are losing customers because of this problem. It is costing us reputation and money. It is out of our control. If you were us, what would you do? We have already asked ARIN to reassign us to a "friendlier" CIDR, and they refuse. This is no longer a technical operational issue so it is out of scope for this mailing list. ARIN don't guarantee routability of the blocks they allocate, and it's difficult to see how they ever could. Perhaps this is an issue of community education, or one of needing better tools or methods for managing martian filters. Those issues are arguably both technical and operational. Joe
Re: Operational Issues with 69.0.0.0/8...
> My question is as follows - We are losing customers because of this > problem. It is costing us reputation and money. It is out of our > control. If you were us, what would you do? We have already asked ARIN > to reassign us to a "friendlier" CIDR, and they refuse. This is no longer a technical operational issue so it is out of scope for this mailing list. But if you think that ARIN could do something to solve your problem then you should raise the issue on the ARIN public policy mailing list. You can find subscription information for that list here http://www.arin.net/mailing_lists/index.html -- Michael Dillon
Re: Operational Issues with 69.0.0.0/8...
The list of inaccessible sites continues to grow: Add to the list www.oandp.com - that looks like someone's firewall filtering in front of their DNS server, because we can't even resolve the DNS. We still can't get to www.ocas.com, www.lavalife.com, and www.indofilms.com even after calling and posting repeatedly. There are undoubtedly others out there. Repeated problems posted by myself and others show the extent of the problem with the 69.0.0.0/8 CIDR, and its lack of dependability - it's a human thing. It used to be restricted, so there are a lot of access lists out there - with all the stuff going on in the last year or so, half the people blocking it probably don't even know how to unblock it - i.e. that person no longer works here... If you look at the address space on IANA, http://www.iana.org/assignments/ipv4-address-space you will see that the last CIDR ARIN took before 69/8 was over a year prior to the 69/8 assignment. A lot happened in our industry in that year. Somewhere, this process is broken since the last CIDR was assigned to ARIN. My question is as follows - We are losing customers because of this problem. It is costing us reputation and money. It is out of our control. If you were us, what would you do? We have already asked ARIN to reassign us to a "friendlier" CIDR, and they refuse. Suggestions are welcome. Sincerely, Todd A. Blank CTO IPOutlet LLC 614.207.5853
Re: Operational Issues with 69.0.0.0/8...
This topic came up on cisco-nsp, but was really more appropriate here. Been meaning to post summaries when I got enough round tuits. A suggestion was made there that the RIRs give a bgp feed of 'unused' routes to interested parties such that they can be blackholed, etc. Sounded like a lot of overhead and things which could go wrong to me. Skipping over the arguments about who would/wouldn't modify processes and would take such a feed, I wouldn't want to have to pay for that infrastructure, its support and maintenance out of my regsitry fees. I do think it makes LOADS of sense to have the (un)allocations clearly visible in the IRR. Some of the RIRs do it today for their 'greater aggregates' [eg, whois -h whois.ripe.net 82.0.0.0/8]. Sure, you'd still have providers ignoring the IRR, but it gets a lot harder for them to whine about the time it takes to update filters or the lack of automation if the data is in a standard format in globally distributed DBs for which there are umpty public tools. There's always the gripe about authentication. Perhaps the IANA should set up a routing registry which merely publishes in RPSL format the allocated/unallocated list (http://www.iana.org/assignments/ipv4-address-space) and the truly paranoid can just consult *only* that registry for their configuration magic? That would be a one-time hit for IANA [or volunteers] to make the flat-file-to-RPSL code, and being a single- source could be cyptographically signed/confirmed if needed. Cheers, Joe -- [EMAIL PROTECTED] * [EMAIL PROTECTED] * [EMAIL PROTECTED] RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
RE: Operational Issues with 69.0.0.0/8...
Some of this is beginning to clear up. The Cable and Wireless stuff
seems to be working now.
Still, when we source from the 69.0.0.0/8 CIDR, traffic can't go (http)
to the following destinations:
www.ocas.com
www.lavalife.com
www.indofilms.com
The first two are on AT&T and AT&T Canada. The last one is on
allegiance internet.
Any insight would be much appreciated. We are sure this is affecting
access to other destinations when using 69.0.0.0/8 as a source - we just
haven't found them all yet...
Thanks,
Todd A. Blank
614.207.5853
-Original Message-
From: Martin J. Levy [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 02, 2002 2:17 PM
To: Todd A. Blank; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Operational Issues with 69.0.0.0/8...
Todd,
If this helps. Do something like the following...
telnet route-views.oregon-ix.net > /tmp/file
term len 0
sh ip bgp 69.0.0.0 255.0.0.0 l
quit
cut -c62-2000 < /tmp/file | awk '{print $1}' | sort -n | uniq -c
| more
...your commands will vary.
You will see plenty of routes within 69/8.
A closer look with show that around 121 routes are seen in the 69/8
range via most of the feeds into Oregon. There is one big exception...
69.4.64.0/20
... it shows up via AS-2548 (Digex) and the other feeds, but it's the
only route within 69/8 that shows up via AS-2548. This is valuable
information.
It does not mean there is filtering within AS-2548, but I would
recommend you contact them to further this investigation.
BTW: This is exactly what Oregon is great for! It shows up issues like
this with ease. Thanks!
Martin
---
At 01:47 PM 12/2/2002 -0500, Todd A. Blank wrote:
>Thanks for the reply, James.
>
>I wish I could tell you the answer. We see traffic passing through
some
>of the routers (transit), but on each network, or their downstreams
>there seem to be different devices filtering. Sometimes it is a border
>or peering router. In other cases, it has been access devices, such as
>firewalls.
>
>One we resolved this morning (with some help from the good folks at
>ARIN) was a downstream provider from one of these transit providers
that
>was filtering in their devices as well.
>
>I am just trying to raise general awareness that the 69.0.0.0/8 block
is
>assigned and out there in use, and to get people to re-examine their
>filters, access lists, etc.
>
>You help and response is appreciated.
>
>Sincerely,
>
>Todd A. Blank
>614.207.5853
>
>-Original Message-
>From: Feger, James [mailto:[EMAIL PROTECTED]]
>Sent: Monday, December 02, 2002 1:35 PM
>To: Todd A. Blank
>Subject: Re: Operational Issues with 69.0.0.0/8...
>
>When you say 'Networks involved' do you mean those providers are
>blocking
>the traffic, or you see these networks in the transit?
>
>Thanks,
>James
>
>
>On Mon, 2 Dec 2002, Todd A. Blank wrote:
>
>>
>> To all concerned:
>>
>> We have been assigned a CIDR of 69.1.192.0/19.
>>
>> We have had numerous problems getting traffic through to various
>destinations.
>>
>> We are finding that many routers are still filtering 69.0.0.0/8.
>>
>> This block used to be restricted, but was assigned by IANA to ARIN in
>August of 2002.
>>
>> If anyone is still filtering this block in their routers, please
>remove the filters!
>>
>> Here are some of the destinations that are not reachable if your
>source is anywhere in the 69.0.0.0/8 CIDR:
>>
>> www.cplink2.com
>> www.ocas.com
>> www.indofilms.com
>> www.lavalife.com
>>
>>
>> Some of the Networks involved are Cable and Wireless, Allegiance
>Internet and AT&T.
>>
>> Thank you,
>>
>> Todd A. Blank
>> IPOutlet LLC
>> 614.207.5853
>>
Re: Operational Issues with 69.0.0.0/8...
Todd,
If this helps. Do something like the following...
telnet route-views.oregon-ix.net > /tmp/file
term len 0
sh ip bgp 69.0.0.0 255.0.0.0 l
quit
cut -c62-2000 < /tmp/file | awk '{print $1}' | sort -n | uniq -c | more
...your commands will vary.
You will see plenty of routes within 69/8.
A closer look with show that around 121 routes are seen in the 69/8 range via most of
the feeds into Oregon. There is one big exception...
69.4.64.0/20
... it shows up via AS-2548 (Digex) and the other feeds, but it's the only route
within 69/8 that shows up via AS-2548. This is valuable information.
It does not mean there is filtering within AS-2548, but I would recommend you contact
them to further this investigation.
BTW: This is exactly what Oregon is great for! It shows up issues like this with
ease. Thanks!
Martin
---
At 01:47 PM 12/2/2002 -0500, Todd A. Blank wrote:
>Thanks for the reply, James.
>
>I wish I could tell you the answer. We see traffic passing through some
>of the routers (transit), but on each network, or their downstreams
>there seem to be different devices filtering. Sometimes it is a border
>or peering router. In other cases, it has been access devices, such as
>firewalls.
>
>One we resolved this morning (with some help from the good folks at
>ARIN) was a downstream provider from one of these transit providers that
>was filtering in their devices as well.
>
>I am just trying to raise general awareness that the 69.0.0.0/8 block is
>assigned and out there in use, and to get people to re-examine their
>filters, access lists, etc.
>
>You help and response is appreciated.
>
>Sincerely,
>
>Todd A. Blank
>614.207.5853
>
>-Original Message-
>From: Feger, James [mailto:[EMAIL PROTECTED]]
>Sent: Monday, December 02, 2002 1:35 PM
>To: Todd A. Blank
>Subject: Re: Operational Issues with 69.0.0.0/8...
>
>When you say 'Networks involved' do you mean those providers are
>blocking
>the traffic, or you see these networks in the transit?
>
>Thanks,
>James
>
>
>On Mon, 2 Dec 2002, Todd A. Blank wrote:
>
>>
>> To all concerned:
>>
>> We have been assigned a CIDR of 69.1.192.0/19.
>>
>> We have had numerous problems getting traffic through to various
>destinations.
>>
>> We are finding that many routers are still filtering 69.0.0.0/8.
>>
>> This block used to be restricted, but was assigned by IANA to ARIN in
>August of 2002.
>>
>> If anyone is still filtering this block in their routers, please
>remove the filters!
>>
>> Here are some of the destinations that are not reachable if your
>source is anywhere in the 69.0.0.0/8 CIDR:
>>
>> www.cplink2.com
>> www.ocas.com
>> www.indofilms.com
>> www.lavalife.com
>>
>>
>> Some of the Networks involved are Cable and Wireless, Allegiance
>Internet and AT&T.
>>
>> Thank you,
>>
>> Todd A. Blank
>> IPOutlet LLC
>> 614.207.5853
>>
RE: Operational Issues with 69.0.0.0/8...
We feel your pain, Scott. We are just glad that we are able to verify that there are problems with this CIDR other than on our network. Now to get them resolved. Hopefully this conversation will end up in the proper inboxes to help clean this up. Does anyone besides me worry that because of the recent cutbacks in this industry that there are orphaned pieces of equipment out there causing some of these problems? Todd 614.207.5853 -Original Message- From: Scott Granados [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 1:52 PM To: Todd A. Blank Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Operational Issues with 69.0.0.0/8... I'd like to second this. We have ran in to problems as well. Usually this is a great place to get help however we have had very responsive actions taken by others out there who had filters in place. On Mon, 2 Dec 2002, Todd A. Blank wrote: > > Thanks for the reply, James. > > I wish I could tell you the answer. We see traffic passing through some > of the routers (transit), but on each network, or their downstreams > there seem to be different devices filtering. Sometimes it is a border > or peering router. In other cases, it has been access devices, such as > firewalls. > > One we resolved this morning (with some help from the good folks at > ARIN) was a downstream provider from one of these transit providers that > was filtering in their devices as well. > > I am just trying to raise general awareness that the 69.0.0.0/8 block is > assigned and out there in use, and to get people to re-examine their > filters, access lists, etc. > > You help and response is appreciated. > > Sincerely, > > Todd A. Blank > 614.207.5853 > > -Original Message- > From: Feger, James [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 02, 2002 1:35 PM > To: Todd A. Blank > Subject: Re: Operational Issues with 69.0.0.0/8... > > When you say 'Networks involved' do you mean those providers are > blocking > the traffic, or you see these networks in the transit? > > Thanks, > James > > > On Mon, 2 Dec 2002, Todd A. Blank wrote: > > > > > To all concerned: > > > > We have been assigned a CIDR of 69.1.192.0/19. > > > > We have had numerous problems getting traffic through to various > destinations. > > > > We are finding that many routers are still filtering 69.0.0.0/8. > > > > This block used to be restricted, but was assigned by IANA to ARIN in > August of 2002. > > > > If anyone is still filtering this block in their routers, please > remove the filters! > > > > Here are some of the destinations that are not reachable if your > source is anywhere in the 69.0.0.0/8 CIDR: > > > > www.cplink2.com > > www.ocas.com > > www.indofilms.com > > www.lavalife.com > > > > > > Some of the Networks involved are Cable and Wireless, Allegiance > Internet and AT&T. > > > > Thank you, > > > > Todd A. Blank > > IPOutlet LLC > > 614.207.5853 > > > > >
Re: Operational Issues with 69.0.0.0/8...
I'd like to second this. We have ran in to problems as well. Usually this is a great place to get help however we have had very responsive actions taken by others out there who had filters in place. On Mon, 2 Dec 2002, Todd A. Blank wrote: > > Thanks for the reply, James. > > I wish I could tell you the answer. We see traffic passing through some > of the routers (transit), but on each network, or their downstreams > there seem to be different devices filtering. Sometimes it is a border > or peering router. In other cases, it has been access devices, such as > firewalls. > > One we resolved this morning (with some help from the good folks at > ARIN) was a downstream provider from one of these transit providers that > was filtering in their devices as well. > > I am just trying to raise general awareness that the 69.0.0.0/8 block is > assigned and out there in use, and to get people to re-examine their > filters, access lists, etc. > > You help and response is appreciated. > > Sincerely, > > Todd A. Blank > 614.207.5853 > > -Original Message- > From: Feger, James [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 02, 2002 1:35 PM > To: Todd A. Blank > Subject: Re: Operational Issues with 69.0.0.0/8... > > When you say 'Networks involved' do you mean those providers are > blocking > the traffic, or you see these networks in the transit? > > Thanks, > James > > > On Mon, 2 Dec 2002, Todd A. Blank wrote: > > > > > To all concerned: > > > > We have been assigned a CIDR of 69.1.192.0/19. > > > > We have had numerous problems getting traffic through to various > destinations. > > > > We are finding that many routers are still filtering 69.0.0.0/8. > > > > This block used to be restricted, but was assigned by IANA to ARIN in > August of 2002. > > > > If anyone is still filtering this block in their routers, please > remove the filters! > > > > Here are some of the destinations that are not reachable if your > source is anywhere in the 69.0.0.0/8 CIDR: > > > > www.cplink2.com > > www.ocas.com > > www.indofilms.com > > www.lavalife.com > > > > > > Some of the Networks involved are Cable and Wireless, Allegiance > Internet and AT&T. > > > > Thank you, > > > > Todd A. Blank > > IPOutlet LLC > > 614.207.5853 > > > > >
