Route Views
Hello, Some prefixes in the Route Views routing table do not have a prefix length specified. For example, 4.0.0.0 and 61.0.0.0 do not have a prefix length specified in the Route Views routing table. 61/8 belongs to APNIC. 4/8 belongs to Genuity. Why is this? How does one find out the prefix length in such cases? Harsha.
Re: Route Views
Hello, Some prefixes in the Route Views routing table do not have a prefix length specified. For example, 4.0.0.0 and 61.0.0.0 do not have a prefix length specified in the Route Views routing table. 61/8 belongs to APNIC. 4/8 belongs to Genuity. Its means its an old style natural classless network. And yeah it should be fixed in my view. -- Neil J. McRae - Alive and Kicking [EMAIL PROTECTED]
/8s and filtering
Hello, Currently APNIC's policy means that if an organization can fully use a /26 (since 25% of /24=/26 and to satisfy the multihoming requirement the organization will need to have a prefix advertised by two or more ISPs) it can get a multihoming assignment from APNIC. If Class C /8s are over and ISPs maintain their filtering policies, the bar would be raised to fully using a /24 instead (since 25% of /22 = /24 and filtering in Class A is done at /22). 8 of the 9 APNIC /8s are from the Class C space. Only one is from the Class A space. However there are only three untouched /8s left in the Class C space - 197/8, 222/8, 223/8. Actually, I wanted to know if the filtering policies will change to accommodate this - i.e. will /24s be allowed in the Class A space? I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. Do ISPs get to choose where the allocation comes from? Harsha.
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...
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: /8s and filtering
I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route. Do ISPs get to choose where the allocation comes from? Ask your ISP if they'll let you choose. But it usually doesn't matter, if you can only justify a /24, you'll find about the same filtering policies in both traditional class A space and class C space. But again, it doesn't matter. So long as each of your providers will honor your route (and why wouldn't they, you're paying them to) you shouldn't have a problem. Just pick your most reliable provider, and the one you're pretty sure you're going to stay with the longest, and get your IP space from them. Make sure they don't mind you advertising your block through other providers. And give some thought to hiring a competent consultant to help you. You can hire a consultant even if you are the consultant. In fact, no competent consultant would do otherwise outside his or her area of expertise. Don't learn to multihome at your client's expense. ;) DS
Re: Route Views
Some prefixes in the Route Views routing table do not have a prefix length specified. For example, because they are their 'natural' length, i.e. old style A/B/C
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...
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, 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: 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
Spam. Again.. -- and blocking net blocks?
Before the flame begins.. I'm not sure when this started.. Background: We have a downstream ISP, who hosts a website of questionable material. This customer (of our customer) used a third party to spam on their behalf.. Which is a violation of our AUP. (In fact we null0 the /32 in question). Problem: For some reason, spews has decided to now block one of our /19.. Ie no mail server in the /19 can send mail. Questions: 1) How do we smack some sense into spews? 2) Does anyone else see a HUGE problem with listing a /19 because there is one /32 of a spam advertised website? When did this start happening? Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570
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: Spam. Again.. -- and blocking net blocks?
On Tue, 2002-12-10 at 15:00, Mark Segal wrote: Before the flame begins.. I'm not sure when this started.. Background: We have a downstream ISP, who hosts a website of questionable material. This customer (of our customer) used a third party to spam on their behalf.. Which is a violation of our AUP. (In fact we null0 the /32 in question). Problem: For some reason, spews has decided to now block one of our /19.. Ie no mail server in the /19 can send mail. Questions: 1) How do we smack some sense into spews? Very difficult we had a similar problem. One bad customer and SPEWS blackholes not only our corporate LAN but also my HOME address range, and that of my home ISP, who was not even peripherally involved. We just had to sit it out, as SPEWS is not accountable, or contactable. Eventually the listing decayed, but it was a real problem for us while it lasted. 2) Does anyone else see a HUGE problem with listing a /19 because there is one /32 of a spam advertised website? When did this start happening? Since SPEWS, with its complete lack of accountability, started being used by respectable spam blocking software. Yes, its a massive problem. Nigel signature.asc Description: This is a digitally signed message part
Re: Spam. Again.. -- and blocking net blocks?
Problem: For some reason, spews has decided to now block one of our /19.. Ie no mail server in the /19 can send mail. Questions: 1) How do we smack some sense into spews? Make it easy for them to identify the fact that your downstream ISP customer has allocated that /32 to a separate organisation. This is what referral whois was supposed to do but it never happened because development of the tools fizzled out. If SPEWS could plug guilty IP addresses into an automated tool and come up with an accurate identification of which neighboring IP addresses were tainted and which were not, then they wouldn't use such crude techniques. Imagine a tool which queries the IANA root LDAP server for an IP address. The IANA server refers them to ARIN's LDAP server because this comes from a /8 that was allocated to ARIN. Now ARIN's server identifies that this address is in your /19 so it refers SPEWS to your own LDAP server. Your server identifies your customer ISP as the owner of the block, or if your customer has been keeping the records up to date with a simple LDAP client, your server would identify that the guilty party is indeed only on one IP address. Of course, this won't stop SPEWS from blacklisting you. But it enables SPEWS to quickly identify the organization (your customer ISP) that has a business relationship with the offender so that SPEWS is more likely to focus their attentions on these two parties. 2) Does anyone else see a HUGE problem with listing a /19 because there is one /32 of a spam advertised website? When did this start happening? It's a free country, you can't stop people like the SPEWS group from expressing their opinions. As long as people are satisfied with crude tools for mapping IP address to owner, this kind of thing will continue to happen. --Michael Dillon
RE: Spam. Again.. -- and blocking net blocks?
We did swip the block to the isp (as an assignment, not allocation).. That is the problem, they kept recursively looking up the assignment.. Maybe they should block 64/8 or maybe 0/0 :). Anybody interested in a coordinated denial of service attack? :). Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: December 10, 2002 10:36 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Spam. Again.. -- and blocking net blocks? Problem: For some reason, spews has decided to now block one of our /19.. Ie no mail server in the /19 can send mail. Questions: 1) How do we smack some sense into spews? Make it easy for them to identify the fact that your downstream ISP customer has allocated that /32 to a separate organisation. This is what referral whois was supposed to do but it never happened because development of the tools fizzled out. If SPEWS could plug guilty IP addresses into an automated tool and come up with an accurate identification of which neighboring IP addresses were tainted and which were not, then they wouldn't use such crude techniques. Imagine a tool which queries the IANA root LDAP server for an IP address. The IANA server refers them to ARIN's LDAP server because this comes from a /8 that was allocated to ARIN. Now ARIN's server identifies that this address is in your /19 so it refers SPEWS to your own LDAP server. Your server identifies your customer ISP as the owner of the block, or if your customer has been keeping the records up to date with a simple LDAP client, your server would identify that the guilty party is indeed only on one IP address. Of course, this won't stop SPEWS from blacklisting you. But it enables SPEWS to quickly identify the organization (your customer ISP) that has a business relationship with the offender so that SPEWS is more likely to focus their attentions on these two parties. 2) Does anyone else see a HUGE problem with listing a /19 because there is one /32 of a spam advertised website? When did this start happening? It's a free country, you can't stop people like the SPEWS group from expressing their opinions. As long as people are satisfied with crude tools for mapping IP address to owner, this kind of thing will continue to happen. --Michael Dillon
Re: Spam. Again.. -- and blocking net blocks?
On 10 Dec 2002, Nigel Titley wrote: 2) Does anyone else see a HUGE problem with listing a /19 because there is one /32 of a spam advertised website? When did this start happening? Since SPEWS, with its complete lack of accountability, started being used by respectable spam blocking software. Yes, its a massive problem. We had this problem a while back too. One particular problem is that the relays.osirusoft.com block-list - which seems to be used by an awful of people - aggregates data from several dozen sources, including spews.
Re: Spam. Again.. -- and blocking net blocks?
Questions: 1) How do we smack some sense into spews? Very difficult we had a similar problem. One bad customer and SPEWS blackholes not only our corporate LAN but also my HOME address range, and that of my home ISP, who was not even peripherally involved. We just had to sit it out, as SPEWS is not accountable, or contactable. Eventually the listing decayed, but it was a real problem for us while it lasted. There is no technical solution to spam. Regards, Neil.
Re: Spam. Again.. -- and blocking net blocks?
On Tue, 2002-12-10 at 17:03, Bryan Bradsby wrote: Check out www.antispews.org -kyle There are two SPEWS lists. SPEWS[1] lists direct spam sources as accurately as /32 Which is the list that our corporate servers and my home lan ended up on, despite never having sent direct spam SPEWS[2] includes SPEWS[1] plus collatteral damage. Which was the rest of our address range and that of my home ISP to clarify, nothing more. The intent of the double spews listing is good, but it isn't adhered to in practice. signature.asc Description: This is a digitally signed message part
Re: Spam. Again.. -- and blocking net blocks?
I tend to agree. We had the same issue a customer who we did not know was a spammer did something similar and they listed our blocks. I terminated the customer. I believe spews has a newsgroup that is listed on their site you can post to but more than that I'm not certain. Also its funny how they don't block all the blocks originated by cnw where the spam in my case originated but listed mine. Either way I think you did the correct thing the deal now is to post to the newsgroup and let them know you cleared the issue. That's all I have heard can be done. On Tue, 10 Dec 2002, Mark Segal wrote: Before the flame begins.. I'm not sure when this started.. Background: We have a downstream ISP, who hosts a website of questionable material. This customer (of our customer) used a third party to spam on their behalf.. Which is a violation of our AUP. (In fact we null0 the /32 in question). Problem: For some reason, spews has decided to now block one of our /19.. Ie no mail server in the /19 can send mail. Questions: 1) How do we smack some sense into spews? 2) Does anyone else see a HUGE problem with listing a /19 because there is one /32 of a spam advertised website? When did this start happening? Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570
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: /8s and filtering
Hello, Currently APNIC's policy means that if an organization can fully use a /26 (since 25% of /24=/26 and to satisfy the multihoming requirement the organization will need to have a prefix advertised by two or more ISPs) it can get a multihoming assignment from APNIC. If RIRs begin allocating really long prefixes, it would be best if they did it all from a single block. Allowing providers to allow long prefixes only from that block, rather than having to accept /24 willy nilly across the entire address space. Also, just because an RIR is allocating out of former class C does not necessarily mean providers will accept a /24, if the RIR allocation policy is shorter than /24. However, this is not a problem as long as the entity receiving the address space always announces their largest aggregate. It is only a problem when people only announce more-specifics.
Re: /8s and filtering
Here is one reason for some to care : If you want to do interdomain multicast, and your address space is not announced globally (say because you have a /24 that is not from the swamp), you are likely to be black-holed due to RPF failures (as your unicast and multicast routing is likely to be different). This has caused problems from time to time... Regards Marshall Eubanks Until such time as vendor C determines that RPF lookups should use the MRIB first, then the URIB, rather than the final RIB, the following will help: router bgp distance mbgp 19 19 19 ip mroute 0.0.0.0 0.0.0.0 bgp Null0 20 or if using 12.1: router bgp address-family ipv4 multicast distance bgp 19 19 19 ip mroute 0.0.0.0 0.0.0.0 bgp Null0 20 not having looked at vendor J's multicast, I can't speak to it. This does, however, make absolutely certain that only MBGP routes determine RPF choices. If you expect or desire unicast routes to drive multicast routing decisions, the above is not for you. I had to do this to get around a bunch of RPF hedge cases.
Re: FW: /8s and filtering
I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route. Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate. If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. Forrest
Re: FW: /8s and filtering
comments inline On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote: I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route. Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate. For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed. If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries. What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks. -- ,N ~Nathan - routing switching dude/fly-boy/sport biker - San Jose CA~
RE: FW: /8s and filtering
Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. -ej -Original Message- From: N [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: [EMAIL PROTECTED] Subject: Re: FW: /8s and filtering comments inline On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote: I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route. Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate. For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed. If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries. What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks. -- ,N ~Nathan - routing switching dude/fly-boy/sport biker - San Jose CA~
Re: futureway calls for DDOS on spews
http://www.merit.edu/mail.archives/nanog/msg05663.html smiley be damned; it is what it is: Anybody interested in a coordinated denial of service attack? :). Mark Yup... it is.SPEWS has DOS my network.. I was joking about it, they actually did it! Regards, Mark
Re: FW: /8s and filtering
On Tue, 10 Dec 2002, N wrote: comments inline If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries. That doesn't seem to be true, look at Verio's routing policies for example. http://info.us.bb.verio.net/routing.html SNIP In the traditional Class A space (i.e., 0/1), we accept /22 and shorter. In the traditional Class B space (i.e., 128/2), we accept /22 and shorter. In the traditional Class C space (i.e., 192/3), we accept /24 and shorter. /SNIP If people didn't accept /24's from the old Class C space then it seems like anyone still using swamp space would find themselves blackholed. Such as this block to pick one at random. 192.203.197.0/24 What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks. I guess I don't understand how allowing just anyone to multihome is going to double the BGP table size. With the current ASN setup you couldn't have more than ~65000 organizations multihoming. Personally, I think an organization announcing 100 more specifics on accident along with announcing their large aggregate is a much larger problem than the small amount of small organizations that want to multihome. In reality, all the filtering policies do is cause people to simply waste enough IP space in order to qualify for a block that won't get filtered. Have you seen the waste that goes on with some of these web hosting companies? I've seen web servers that have a /25 assigned to *ONE* server because the server owner was willing to pay the $5/IP or whatever that the ISP charges. And the server wasn't even running SSL or anything that required IP addresses, virtual hosting would have worked just fine. You think perhaps there might be another reason for why this is happening? Perhaps it's the only way a company can justify asking for a /19 that will make it past the filters. Forrest
RE: FW: /8s and filtering
Hello, No, this is not the case. I enquired and it seems multihoming is not a justification for a /24 in any RIR. Does a network have to be able to fully utilize a /26 (25% of /24) in order to multihome? Harsha. On Tue, 10 Dec 2002, Ejay Hire wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. -ej -Original Message- From: N [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: [EMAIL PROTECTED] Subject: Re: FW: /8s and filtering comments inline On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote: I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route. Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate. For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed. If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries. What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks. -- ,N ~Nathan - routing switching dude/fly-boy/sport biker - San Jose CA~
Re: FW: /8s and filtering
On Tue, 10 Dec 2002 12:36:39 -0600 (CST), Forrest wrote: Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate. Smaller multihomers elect to multihome for a variety of reasons. Those reasons typically include latency reduction and toleration of POP failures, router failures, and line failures. They're not looking to stay online is Sprint or MCI disappears entirely. If you multihomed to 2 providers in this manner and made a table of all your downtime and its causes, loss of the larger aggregate would the tiniest fraction of your downtime, which is already a tiny fraction of the time. We don't put parachutes on commuter jets. The failures where these would be helpful are but the tineiest fraction of the failures that occur. And any significant failure at all of such a redundant system is rare. If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? You're just biasing the question with the choice of words you use ... truly multihome. What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. Not only would this increase the size of the global routing table, but this would actually decrease reliability for most basement multihomers. Basement multihomers tend to flap their routes more often than their upstreams. By not being inside a larger aggregate, these flaps are likely to result in more significant pockets of unreachability than they would be otherwise. DS
RE: FW: /8s and filtering
many isps will automatically give a /24 if their client is multihoming, even if their usage is well below the 254 usable ips allocated by the above block size. Brian On Tue, 10 Dec 2002, Harsha Narayan wrote: Hello, No, this is not the case. I enquired and it seems multihoming is not a justification for a /24 in any RIR. Does a network have to be able to fully utilize a /26 (25% of /24) in order to multihome? Harsha. On Tue, 10 Dec 2002, Ejay Hire wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. -ej -Original Message- From: N [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: [EMAIL PROTECTED] Subject: Re: FW: /8s and filtering comments inline On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote: I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route. Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate. For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed. If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries. What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks. -- ,N ~Nathan - routing switching dude/fly-boy/sport biker - San Jose CA~
RE: FW: /8s and filtering
Interesting. Perhaps your source hasn't read the policy updates. Here is the link to ARIN's site, and I have successfully used this as justification for a customer. http://www.arin.net/policy/2001_2.html -ej -Original Message- From: Harsha Narayan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 1:15 PM To: Ejay Hire Cc: [EMAIL PROTECTED] Subject: RE: FW: /8s and filtering Hello, No, this is not the case. I enquired and it seems multihoming is not a justification for a /24 in any RIR. Does a network have to be able to fully utilize a /26 (25% of /24) in order to multihome? Harsha. On Tue, 10 Dec 2002, Ejay Hire wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. -ej -Original Message- From: N [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: [EMAIL PROTECTED] Subject: Re: FW: /8s and filtering comments inline On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote: I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route. Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate. For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed. If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries. What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks. -- ,N ~Nathan - routing switching dude/fly-boy/sport biker - San Jose CA~
RE: FW: /8s and filtering
Hello, But how will such an ISP justify this to the RIR? Thanks, Harsha. On Tue, 10 Dec 2002, Brian wrote: many isps will automatically give a /24 if their client is multihoming, even if their usage is well below the 254 usable ips allocated by the above block size. Brian On Tue, 10 Dec 2002, Harsha Narayan wrote: Hello, No, this is not the case. I enquired and it seems multihoming is not a justification for a /24 in any RIR. Does a network have to be able to fully utilize a /26 (25% of /24) in order to multihome? Harsha. On Tue, 10 Dec 2002, Ejay Hire wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. -ej -Original Message- From: N [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: [EMAIL PROTECTED] Subject: Re: FW: /8s and filtering comments inline On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote: I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route. Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate. For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed. If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries. What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks. -- ,N ~Nathan - routing switching dude/fly-boy/sport biker - San Jose CA~
RE: FW: /8s and filtering
--On Tuesday, December 10, 2002 13:08 -0600 Ejay Hire [EMAIL PROTECTED] wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. I am not aware of ARIN taking such action. To which policy are you referring? Alec, ARIN AC member -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: FW: /8s and filtering
--On Tuesday, December 10, 2002 13:08 -0600 Ejay Hire [EMAIL PROTECTED] wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. I was thinking about PI space. ARIN did in fact ratify a policy stating that a provider may allocate a customer a /24 of PA space if they are multihomed. Alec, red-faced AC member -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: FW: /8s and filtering
Hello, I asked if the multihomer has to be able to fully utilize a /26=25% of /24 to be able to multihome. I am sorry but the link doesn't help. Harsha. On Tue, 10 Dec 2002, Ejay Hire wrote: Interesting. Perhaps your source hasn't read the policy updates. Here is the link to ARIN's site, and I have successfully used this as justification for a customer. http://www.arin.net/policy/2001_2.html -ej -Original Message- From: Harsha Narayan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 1:15 PM To: Ejay Hire Cc: [EMAIL PROTECTED] Subject: RE: FW: /8s and filtering Hello, No, this is not the case. I enquired and it seems multihoming is not a justification for a /24 in any RIR. Does a network have to be able to fully utilize a /26 (25% of /24) in order to multihome? Harsha. On Tue, 10 Dec 2002, Ejay Hire wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. -ej -Original Message- From: N [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: [EMAIL PROTECTED] Subject: Re: FW: /8s and filtering comments inline On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote: I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route. Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate. For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed. If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries. What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks. -- ,N ~Nathan - routing switching dude/fly-boy/sport biker - San Jose CA~
RE: FW: /8s and filtering
Isn't it true that most bgp announcements with a mask longer than 24 bits hit the proverbial bit bucket? Brian On Tue, 10 Dec 2002, Harsha Narayan wrote: Hello, But how will such an ISP justify this to the RIR? Thanks, Harsha. On Tue, 10 Dec 2002, Brian wrote: many isps will automatically give a /24 if their client is multihoming, even if their usage is well below the 254 usable ips allocated by the above block size. Brian On Tue, 10 Dec 2002, Harsha Narayan wrote: Hello, No, this is not the case. I enquired and it seems multihoming is not a justification for a /24 in any RIR. Does a network have to be able to fully utilize a /26 (25% of /24) in order to multihome? Harsha. On Tue, 10 Dec 2002, Ejay Hire wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. -ej -Original Message- From: N [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: [EMAIL PROTECTED] Subject: Re: FW: /8s and filtering comments inline On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote: I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route. Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate. For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed. If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries. What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks. -- ,N ~Nathan - routing switching dude/fly-boy/sport biker - San Jose CA~
RE: FW: /8s and filtering
Of, you meant the PI micro-allocation for multihoming. That is still being discussed, and hasn't been approved or ratified. This policy states that an ISP can accept multihoming as justification for assigning a /24 to a customer even if they do not meet the immediate 25% 1 year 50% rule. -Original Message- From: Alec H. Peterson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 1:34 PM To: Ejay Hire; [EMAIL PROTECTED] Subject: RE: FW: /8s and filtering --On Tuesday, December 10, 2002 13:08 -0600 Ejay Hire [EMAIL PROTECTED] wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. I was thinking about PI space. ARIN did in fact ratify a policy stating that a provider may allocate a customer a /24 of PA space if they are multihomed. Alec, red-faced AC member -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: FW: /8s and filtering
Did they ? When ? (I was involved with such a proposal, and it was turned down at the last ARIN meeting, so I am curious if something else did get approved.) Regards Marshall Eubanks On Tuesday, December 10, 2002, at 02:08 PM, Ejay Hire wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. -ej -Original Message- From: N [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: [EMAIL PROTECTED] Subject: Re: FW: /8s and filtering comments inline On Tue, Dec 10, 2002 at 12:36:39PM -0600, Forrest wrote: I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route. Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate. For the assigned block to be part of the same aggregate(of both providers), that implys that the providers sharing the responsibility for the aggregate. It happens, but is rare. In this case, the providers must accept more specific routes from each other, that is within the space being aggregated. If they do not share specifics, one uplink down will cause a large percentage ~50% for the customer. This scenario is valid for load balancing, but redundancy is fragile. The only advantage I see is no limit to prefix length. You can do this with a /28 if you want... given the above caveats are addressed. If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? In today's VLSM world... the old classes have no bearing on filtering in my experience. Prefix length discrimination knows no classfull boundaries. What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. There is value in the current filtering of longest prefixes... Allowing anyone to multihome with BGP, using any network size, is going to double our BGP tables overnight. Perhaps its good that you must be of some size to participate in public BGP. Many providers offer redundancy that is more appropriate for the smaller networks. -- ,N ~Nathan - routing switching dude/fly-boy/sport biker - San Jose CA~ T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : [EMAIL PROTECTED] http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html
RE: FW: /8s and filtering
Hello, The policy says that a /24 of PA space can be given if the customer can show that it has an immediate requirement of 25% of the /24 = /26. That is the reason I asked if the multihomer has to be able to fully utilize a /26=25% of /24 to be able to multihome. Thanks, Harsha. On Tue, 10 Dec 2002, Alec H. Peterson wrote: --On Tuesday, December 10, 2002 13:08 -0600 Ejay Hire [EMAIL PROTECTED] wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. I was thinking about PI space. ARIN did in fact ratify a policy stating that a provider may allocate a customer a /24 of PA space if they are multihomed. Alec, red-faced AC member -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: FW: /8s and filtering
This policy allows a downstream customer's multi-homing requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements -ej -Original Message- From: Harsha Narayan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 1:41 PM To: Alec H. Peterson Cc: Ejay Hire; [EMAIL PROTECTED] Subject: RE: FW: /8s and filtering Hello, The policy says that a /24 of PA space can be given if the customer can show that it has an immediate requirement of 25% of the /24 = /26. That is the reason I asked if the multihomer has to be able to fully utilize a /26=25% of /24 to be able to multihome. Thanks, Harsha. On Tue, 10 Dec 2002, Alec H. Peterson wrote: --On Tuesday, December 10, 2002 13:08 -0600 Ejay Hire [EMAIL PROTECTED] wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. I was thinking about PI space. ARIN did in fact ratify a policy stating that a provider may allocate a customer a /24 of PA space if they are multihomed. Alec, red-faced AC member -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: FW: /8s and filtering
--On Tuesday, December 10, 2002 11:41 -0800 Harsha Narayan [EMAIL PROTECTED] wrote: Hello, The policy says that a /24 of PA space can be given if the customer can show that it has an immediate requirement of 25% of the /24 = /26. Policy 2001-2 was ratified recently, which is separate and says that if the customer is multihomed he may receive a /24 with multihoming being the only justification. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: FW: /8s and filtering
Yes, I just read that. But then APNIC's policy allows no such thing. http://www.apnic.net/docs/policy/add-manage-policy.html#10.1 Harsha. On Tue, 10 Dec 2002, Ejay Hire wrote: This policy allows a downstream customer's multi-homing requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements -ej -Original Message- From: Harsha Narayan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 1:41 PM To: Alec H. Peterson Cc: Ejay Hire; [EMAIL PROTECTED] Subject: RE: FW: /8s and filtering Hello, The policy says that a /24 of PA space can be given if the customer can show that it has an immediate requirement of 25% of the /24 = /26. That is the reason I asked if the multihomer has to be able to fully utilize a /26=25% of /24 to be able to multihome. Thanks, Harsha. On Tue, 10 Dec 2002, Alec H. Peterson wrote: --On Tuesday, December 10, 2002 13:08 -0600 Ejay Hire [EMAIL PROTECTED] wrote: Having a /24 doesn't indicate you are a network of any particular size, ARIN ratified a policy that allows multihoming as justification for a /24. I was thinking about PI space. ARIN did in fact ratify a policy stating that a provider may allocate a customer a /24 of PA space if they are multihomed. Alec, red-faced AC member -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: FW: /8s and filtering
Hello, Now I am confused because I have got two sets of contradicting answers. Some say that anyone can multihome, some say that you need to be of a certain minimum size to multihome. May I know what is the right answer? I agree that allowing anyone to multihome would increase the size of the routing table. So does this mean that someone has to be of a certain size to multihome? Harsha. anyone can multihome, with the cooperation of others. current practice seems to dictate that the standard operating procedures to protect the integrity of the routing system mandate that only prefixes of certain lengths are allowed at -SOME- isp boundaries. you seem to have the assumption that there is a single standard here. There is not. --bill
RE: FW: /8s and filtering
My original question was how does this interact with the filtering policies - especially when the Class C space is used up - there are only three /8s left there. Harsha. On Tue, 10 Dec 2002, Alec H. Peterson wrote: --On Tuesday, December 10, 2002 11:41 -0800 Harsha Narayan [EMAIL PROTECTED] wrote: Hello, The policy says that a /24 of PA space can be given if the customer can show that it has an immediate requirement of 25% of the /24 = /26. Policy 2001-2 was ratified recently, which is separate and says that if the customer is multihomed he may receive a /24 with multihoming being the only justification. Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: FW: /8s and filtering
Hello, No, this is not the case. I enquired and it seems multihoming is not a justification for a /24 in any RIR. Does a network have to be able to fully utilize a /26 (25% of /24) in order to multihome? Harsha. You do err, not knowing the scripture. To multihome, you need to get (at least) two other providers to listen to your routing announcement(s). Wango'z'tango! multihoming done. Your announcement can be as small as a /32 (although there was a time when at least one /33 was delegated...) What's that? you want everyone running IP to reach your gopher server? Tough luck. then you must somehow meet/pass the byzantine filtering rules (unpublished sometimes) that parties which are three and four hops away from your edge will impose on whatever announcements you happen to propogate. The dead hand of the CIDR mafia will eat your lunch and you'll have no recourse. So, whats a poor'lil player todo? Some say that this works: ) build a rich peering mesh. (reduces your dependence on any one transit provider) ) buy transit (where you -MUST-) and insist that you understand BGP, peering, and how to prevent leakage. Demand that they accept your announcement(s). [ note that this may turn transit into peering, which may trigger other unpleasent SOPs from the salesdroids but hey, multihoming is -worth- the effort...] as usual, YMMV. --bill (who is earning the sobriquet grumpy today)
RE: Spam. Again.. -- and blocking net blocks?
Quick Comment as a NANOG lurker and SPEWS lurker (news.admin.net-abuse.email). I'm not defending SPEWS, don't speak for SPEWS but will describe what I understand happens: SPEWS initially lists offending IP address blocks from non-repentant SPAM sources. If the upstream ISP does nothing about it, that block tends to expand to neighboring blocks to gain the attention of the ISP. High level concept: Block the SPAMMER - ISP Does nothing Block the SPAMMER's Neighboring Blocks (Collateral Damage) - Motivates neighbors to find new Upstream/Isp - Motivates neighbors to complain to upstream/ISP - Gains the attention of the Upstream/ISP Expand the Block - Ditto Block the ISP as a whole The SPEWS concept prevents an ISP from allowing spammers on some blocks while trying to service legitimate customers on others. For an ISP - it is either all or none over time, you support spammers and are blocked as a whole (to include innocent customers). If you do end up mistakenly on SPEWS or take care of your spamming customers - you can appeal to them at news.admin.net-abuse.email, get flamed pretty bad, and eventually fall off the list. I do personally like the idea of holding the ISP as a whole accountable over time. An ISP can stay off spews, I've never had a block listed - though when I'm in a decision making position, I've never tolerated a spammer. Hansel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 08:36 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Spam. Again.. -- and blocking net blocks? Problem: For some reason, spews has decided to now block one of our /19.. Ie no mail server in the /19 can send mail. Questions: 1) How do we smack some sense into spews? Make it easy for them to identify the fact that your downstream ISP customer has allocated that /32 to a separate organisation. This is what referral whois was supposed to do but it never happened because development of the tools fizzled out. If SPEWS could plug guilty IP addresses into an automated tool and come up with an accurate identification of which neighboring IP addresses were tainted and which were not, then they wouldn't use such crude techniques. Imagine a tool which queries the IANA root LDAP server for an IP address. The IANA server refers them to ARIN's LDAP server because this comes from a /8 that was allocated to ARIN. Now ARIN's server identifies that this address is in your /19 so it refers SPEWS to your own LDAP server. Your server identifies your customer ISP as the owner of the block, or if your customer has been keeping the records up to date with a simple LDAP client, your server would identify that the guilty party is indeed only on one IP address. Of course, this won't stop SPEWS from blacklisting you. But it enables SPEWS to quickly identify the organization (your customer ISP) that has a business relationship with the offender so that SPEWS is more likely to focus their attentions on these two parties. 2) Does anyone else see a HUGE problem with listing a /19 because there is one /32 of a spam advertised website? When did this start happening? It's a free country, you can't stop people like the SPEWS group from expressing their opinions. As long as people are satisfied with crude tools for mapping IP address to owner, this kind of thing will continue to happen. --Michael Dillon
Re: FW: /8s and filtering
Hello, Thank you very much everyone for all your replies. When Class C space gets used up, wouldn't the filtering policies have to change to allow the same kind of multihoming from the Class A space. Currently, a /24 from Class C is enough to get past filters. However later, a /22 (or is it /20) from Class A would be required to get past filters. Since there are only three /8s left in Class C, I was curious whether filtering policies would change to accommodate this. If filtering policies won't change ARIN will have to change its multihoming PA policy to giving away a /22 instead of a /24. Though officially it is RIR policy not to worry about the routability of an a prefix I guess they do worry about it? Thanks, Harsha. On Tue, 10 Dec 2002 [EMAIL PROTECTED] wrote: Hello, Now I am confused because I have got two sets of contradicting answers. Some say that anyone can multihome, some say that you need to be of a certain minimum size to multihome. May I know what is the right answer? I agree that allowing anyone to multihome would increase the size of the routing table. So does this mean that someone has to be of a certain size to multihome? Harsha. anyone can multihome, with the cooperation of others. current practice seems to dictate that the standard operating procedures to protect the integrity of the routing system mandate that only prefixes of certain lengths are allowed at -SOME- isp boundaries. you seem to have the assumption that there is a single standard here. There is not. --bill
RE: Spam. Again.. -- and blocking net blocks?
I agree.. Problem was it was a downstream ISP.. This all comes down to, we warn them since it is their customer, they don't deal with it, we black hole part of their network.. But it take 3-4 days to do that to a large downstream. Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -Original Message- From: Lee, Hansel [mailto:[EMAIL PROTECTED]] Sent: December 10, 2002 3:08 PM To: '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]' Subject: RE: Spam. Again.. -- and blocking net blocks? Quick Comment as a NANOG lurker and SPEWS lurker (news.admin.net-abuse.email). I'm not defending SPEWS, don't speak for SPEWS but will describe what I understand happens: SPEWS initially lists offending IP address blocks from non-repentant SPAM sources. If the upstream ISP does nothing about it, that block tends to expand to neighboring blocks to gain the attention of the ISP. High level concept: Block the SPAMMER - ISP Does nothing Block the SPAMMER's Neighboring Blocks (Collateral Damage) - Motivates neighbors to find new Upstream/Isp - Motivates neighbors to complain to upstream/ISP - Gains the attention of the Upstream/ISP Expand the Block - Ditto Block the ISP as a whole The SPEWS concept prevents an ISP from allowing spammers on some blocks while trying to service legitimate customers on others. For an ISP - it is either all or none over time, you support spammers and are blocked as a whole (to include innocent customers). If you do end up mistakenly on SPEWS or take care of your spamming customers - you can appeal to them at news.admin.net-abuse.email, get flamed pretty bad, and eventually fall off the list. I do personally like the idea of holding the ISP as a whole accountable over time. An ISP can stay off spews, I've never had a block listed - though when I'm in a decision making position, I've never tolerated a spammer. Hansel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 08:36 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Spam. Again.. -- and blocking net blocks? Problem: For some reason, spews has decided to now block one of our /19.. Ie no mail server in the /19 can send mail. Questions: 1) How do we smack some sense into spews? Make it easy for them to identify the fact that your downstream ISP customer has allocated that /32 to a separate organisation. This is what referral whois was supposed to do but it never happened because development of the tools fizzled out. If SPEWS could plug guilty IP addresses into an automated tool and come up with an accurate identification of which neighboring IP addresses were tainted and which were not, then they wouldn't use such crude techniques. Imagine a tool which queries the IANA root LDAP server for an IP address. The IANA server refers them to ARIN's LDAP server because this comes from a /8 that was allocated to ARIN. Now ARIN's server identifies that this address is in your /19 so it refers SPEWS to your own LDAP server. Your server identifies your customer ISP as the owner of the block, or if your customer has been keeping the records up to date with a simple LDAP client, your server would identify that the guilty party is indeed only on one IP address. Of course, this won't stop SPEWS from blacklisting you. But it enables SPEWS to quickly identify the organization (your customer ISP) that has a business relationship with the offender so that SPEWS is more likely to focus their attentions on these two parties. 2) Does anyone else see a HUGE problem with listing a /19 because there is one /32 of a spam advertised website? When did this start happening? It's a free country, you can't stop people like the SPEWS group from expressing their opinions. As long as people are satisfied with crude tools for mapping IP address to owner, this kind of thing will continue to happen. --Michael Dillon
Re: FW: /8s and filtering
2) Small multihomers must get the ISP that assigns them address space to allocate them at least a /24 (with multihoming as the justification if needed). The ISP must agree to allow them to advertise their allocation through other providers and must agree to hear and announce the block from the customer *and* *other* *ISPs*. Hello, Doesn't this mean that unless filtering policies change, after Class C space is used up, the multihomer will have to get a /22 from the ISP (since after Class C gets used up allocations will be made from Class A space). There are only three /8s left in the Class C space. Harsha.
RE: Spam. Again.. -- and blocking net blocks?
I could understand if an ISP was allowing spam from a portion of there network. But in this case the only thing that the ISP did is host a website, the SPAM was sent from from a third party's network. The ISP did terminate the customer but in the meantime the entire NSP's network has been blacklisted, for a rouge webhosting account does sound a bit harsh. At 12:08 -0800 12/10/2002, Lee, Hansel wrote: Quick Comment as a NANOG lurker and SPEWS lurker (news.admin.net-abuse.email). I'm not defending SPEWS, don't speak for SPEWS but will describe what I understand happens: SPEWS initially lists offending IP address blocks from non-repentant SPAM sources. If the upstream ISP does nothing about it, that block tends to expand to neighboring blocks to gain the attention of the ISP. High level concept: Block the SPAMMER - ISP Does nothing Block the SPAMMER's Neighboring Blocks (Collateral Damage) - Motivates neighbors to find new Upstream/Isp - Motivates neighbors to complain to upstream/ISP - Gains the attention of the Upstream/ISP Expand the Block - Ditto Block the ISP as a whole The SPEWS concept prevents an ISP from allowing spammers on some blocks while trying to service legitimate customers on others. For an ISP - it is either all or none over time, you support spammers and are blocked as a whole (to include innocent customers). If you do end up mistakenly on SPEWS or take care of your spamming customers - you can appeal to them at news.admin.net-abuse.email, get flamed pretty bad, and eventually fall off the list. I do personally like the idea of holding the ISP as a whole accountable over time. An ISP can stay off spews, I've never had a block listed - though when I'm in a decision making position, I've never tolerated a spammer. Hansel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 08:36 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Spam. Again.. -- and blocking net blocks? Problem: For some reason, spews has decided to now block one of our /19.. Ie no mail server in the /19 can send mail. Questions: 1) How do we smack some sense into spews? Make it easy for them to identify the fact that your downstream ISP customer has allocated that /32 to a separate organisation. This is what referral whois was supposed to do but it never happened because development of the tools fizzled out. If SPEWS could plug guilty IP addresses into an automated tool and come up with an accurate identification of which neighboring IP addresses were tainted and which were not, then they wouldn't use such crude techniques. Imagine a tool which queries the IANA root LDAP server for an IP address. The IANA server refers them to ARIN's LDAP server because this comes from a /8 that was allocated to ARIN. Now ARIN's server identifies that this address is in your /19 so it refers SPEWS to your own LDAP server. Your server identifies your customer ISP as the owner of the block, or if your customer has been keeping the records up to date with a simple LDAP client, your server would identify that the guilty party is indeed only on one IP address. Of course, this won't stop SPEWS from blacklisting you. But it enables SPEWS to quickly identify the organization (your customer ISP) that has a business relationship with the offender so that SPEWS is more likely to focus their attentions on these two parties. 2) Does anyone else see a HUGE problem with listing a /19 because there is one /32 of a spam advertised website? When did this start happening? It's a free country, you can't stop people like the SPEWS group from expressing their opinions. As long as people are satisfied with crude tools for mapping IP address to owner, this kind of thing will continue to happen. --Michael Dillon -- Scott A Silzer
Re: Spam. Again.. -- and blocking net blocks?
Hello Hansel, Tuesday, December 10, 2002, 3:08:20 PM, you wrote: LH The SPEWS concept prevents an ISP from allowing spammers on some blocks LH while trying to service legitimate customers on others. For an ISP - it is LH either all or none over time, you support spammers and are blocked as a LH whole (to include innocent customers). Not speaking for or against SPEWS, but couldn't this eventually work against people using the list? If I were a spammer I would keep signing up for accounts, and getting larger and larger blocks of IP Addresses added to the SPEWS list. Eventually, so many blocks would be added to the list, that it would make SPEWS worthless. Once SPEWS is worthless, people will stop using it, and the spammers win. allan -- Allan Liska [EMAIL PROTECTED] http://www.allan.org
Re: FW: /8s and filtering
On Tue, Dec 10, 2002 at 12:45:42PM -0800, Harsha Narayan wrote: 2) Small multihomers must get the ISP that assigns them address space to allocate them at least a /24 (with multihoming as the justification if needed). The ISP must agree to allow them to advertise their allocation through other providers and must agree to hear and announce the block from the customer *and* *other* *ISPs*. Hello, Doesn't this mean that unless filtering policies change, after Class C space is used up, the multihomer will have to get a /22 from the ISP (since after Class C gets used up allocations will be made from Class A space). There are only three /8s left in the Class C space. To be accepted into Verio's space per the URL that [EMAIL PROTECTED] pasted... you are correct. I still think this is a rare method of filtering... and perhaps Verio will change their policy to be /24 everywhere once the Classfull C ranges are gone. As others have mentioned... not all providers filter in the same way, and sometimes the methods are not published. Its relatively safe to make a *vague* judgement that a /24 will get you reachable via *most* of the net. -- ,N ~Nathan - routing switching dude/fly-boy/sport biker - San Jose CA~
Re: FW: /8s and filtering
Well, you can't easily multihome when announcing /23 or shorter but /24 will work fine for multihoming and that is why ARIN passed that policy. What is true, however, is that some isps will filter even /24s on their router, but in that case, there would still be a route to your netblock from your upstream (they would be announcing their entire /19, /18 or whatever with you as a customer getting /24 of that larger block and if your direct route is filtered by an isp, next larger route that includes your block that is not filtered would be used). And there are actually not that many isps that really do filter /24 announcements (I'd say 1% but I maybe wrong). However that some ISPs do filter /24s, would mean that if RIR is directly giving your an ip block it would need to be from the block where ISPs know that RIR is giving out small blocks. Up until now ARIN has not been giving any new small (/24 - /21) allocations, except micro allocations for exchange points and in the micro-allocations (policy 2001-3) it is specifically written that ARIN will do these kind of allocations from specific blocks reserved for that purpose. Now, however, that ARIN is discussing proposals such as 2002-5, 2002-6 and 2002-7 (with 2002-5 2002-6 most likely being passed within few months) ARIN maybe put in position of assigning smaller then /20 blocks and that is why I suggested on ARIN ppml mailing list that current micro-allocation wording about assiging small blocks from specifically designated larger blocks be made a separate policy that would apply to all small allocations asignments being made directly by ARIN. If you think its a good idea to make this a policy, please do send your feedback to ARIN or bring it up on ppml mailing list and then ARIN can work on this futher to make it a policy. On Tue, 10 Dec 2002, Forrest wrote: I was also curious about this - if I am a customer who wants to multihome and can justify only a /24, I would go to an ISP which has an allocation from the Class C space rather than one from the Class A space. It doesn't matter. For all practical purposes, basement multihomers only care that their two or three providers have their route. Maybe I'm missing something, but what good would it do for someone to multihome if only their own providers accept their route, but nobody else does? I realize that their block should be still announced with their ISP's larger aggregate, but what good does this do if your ISP goes down and can't announce the large aggregate. If you're a smaller organization, perhaps you'll only have a /23 from your upstream provider. With the filtering that seems to be in place, it seems like the only way you can truly multihome with a /23 is if it happens to be in the old Class C space. Or is this wrong? What seems to be needed is perhaps a /8 set aside by the RIR specifically to allocate to small organizations that wish to multihome that people would accept /24 and shorter from. Forrest
Re: FW: FW: /8s and filtering
Now, however, that ARIN is discussing proposals such as 2002-5, 2002-6 and 2002-7 (with 2002-5 2002-6 most likely being passed within few months) ARIN maybe put in position of assigning smaller then /20 blocks and that is why I suggested on ARIN ppml mailing list that current micro-allocation wording about assiging small blocks from specifically designated larger blocks be made a separate policy that would apply to all small allocations asignments being made directly by ARIN. If you think its a good idea to make this a policy, please do send your feedback to ARIN or bring it up on ppml mailing list and then ARIN can work on this futher to make it a policy. Proposal 2002-7 is exactly what is needed in my opinion. I wish I'd seen it before I posted here earlier, since it basically identifies every problem I mentioned. http://www.arin.net/policy/2002_7.html Forrest
Re: FW: /8s and filtering
but there is no class C space anymore. there is no class A space either. its all CIDR space and some providers have retained some vestigal classfull concepts in the creation/maintaince of their routing filters. a /24 may or may not get you past my filters. any you'll have no way to know until/unless you try to get to my sites or we develop a peering relationship. wrt the evolution of filters. yes, they do evolve. and so does ARIN policy. you presume too much to second guess that ARIN policy will evolve in the way you outline. Hello, Thank you very much everyone for all your replies. When Class C space gets used up, wouldn't the filtering policies have to change to allow the same kind of multihoming from the Class A space. Currently, a /24 from Class C is enough to get past filters. However later, a /22 (or is it /20) from Class A would be required to get past filters. Since there are only three /8s left in Class C, I was curious whether filtering policies would change to accommodate this. If filtering policies won't change ARIN will have to change its multihoming PA policy to giving away a /22 instead of a /24. Though officially it is RIR policy not to worry about the routability of an a prefix I guess they do worry about it? Thanks, Harsha. On Tue, 10 Dec 2002 [EMAIL PROTECTED] wrote: Hello, Now I am confused because I have got two sets of contradicting answers. Some say that anyone can multihome, some say that you need to be of a certain minimum size to multihome. May I know what is the right answer? I agree that allowing anyone to multihome would increase the size of the routing table. So does this mean that someone has to be of a certain size to multihome? Harsha. anyone can multihome, with the cooperation of others. current practice seems to dictate that the standard operating procedures to protect the integrity of the routing system mandate that only prefixes of certain lengths are allowed at -SOME- isp boundaries. you seem to have the assumption that there is a single standard here. There is not. --bill
Re: FW: /8s and filtering
On Tue, 10 Dec 2002 12:45:42 -0800 (PST), Harsha Narayan wrote: Doesn't this mean that unless filtering policies change, after Class C space is used up, the multihomer will have to get a /22 from the ISP (since after Class C gets used up allocations will be made from Class A space). There are only three /8s left in the Class C space. No. Providers who you don't pay to carry your route can reach you through the larger aggregate. In fact, even the /24 requirement can be ignored if all your providers reach each other directly or can convince their transit providers to carry smaller routes. DS
RE: FW: /8s and filtering
Thank you! I thought that was the whole point of CIDR... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 4:54 PM To: Harsha Narayan Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: FW: /8s and filtering but there is no class C space anymore. there is no class A space either. its all CIDR space and some providers have retained some vestigal classfull concepts in the creation/maintaince of their routing filters. a /24 may or may not get you past my filters. any you'll have no way to know until/unless you try to get to my sites or we develop a peering relationship. wrt the evolution of filters. yes, they do evolve. and so does ARIN policy. you presume too much to second guess that ARIN policy will evolve in the way you outline. Hello, Thank you very much everyone for all your replies. When Class C space gets used up, wouldn't the filtering policies have to change to allow the same kind of multihoming from the Class A space. Currently, a /24 from Class C is enough to get past filters. However later, a /22 (or is it /20) from Class A would be required to get past filters. Since there are only three /8s left in Class C, I was curious whether filtering policies would change to accommodate this. If filtering policies won't change ARIN will have to change its multihoming PA policy to giving away a /22 instead of a /24. Though officially it is RIR policy not to worry about the routability of an a prefix I guess they do worry about it? Thanks, Harsha. On Tue, 10 Dec 2002 [EMAIL PROTECTED] wrote: Hello, Now I am confused because I have got two sets of contradicting answers. Some say that anyone can multihome, some say that you need to be of a certain minimum size to multihome. May I know what is the right answer? I agree that allowing anyone to multihome would increase the size of the routing table. So does this mean that someone has to be of a certain size to multihome? Harsha. anyone can multihome, with the cooperation of others. current practice seems to dictate that the standard operating procedures to protect the integrity of the routing system mandate that only prefixes of certain lengths are allowed at -SOME- isp boundaries. you seem to have the assumption that there is a single standard here. There is not. --bill
Re: FW: /8s and filtering
Hello, Yes, it is all classless now, but I saw Verio's policies and thought that it is the way ISPs filter. Also, the Jippi group filters at /21 except in the 192.0/7 space (where it is a /24). I didn't have enough knowledge to realize that classful was vestigal. Thanks, Harsha. On Tue, 10 Dec 2002 [EMAIL PROTECTED] wrote: but there is no class C space anymore. there is no class A space either. its all CIDR space and some providers have retained some vestigal classfull concepts in the creation/maintaince of their routing filters. a /24 may or may not get you past my filters. any you'll have no way to know until/unless you try to get to my sites or we develop a peering relationship. wrt the evolution of filters. yes, they do evolve. and so does ARIN policy. you presume too much to second guess that ARIN policy will evolve in the way you outline. Hello, Thank you very much everyone for all your replies. When Class C space gets used up, wouldn't the filtering policies have to change to allow the same kind of multihoming from the Class A space. Currently, a /24 from Class C is enough to get past filters. However later, a /22 (or is it /20) from Class A would be required to get past filters. Since there are only three /8s left in Class C, I was curious whether filtering policies would change to accommodate this. If filtering policies won't change ARIN will have to change its multihoming PA policy to giving away a /22 instead of a /24. Though officially it is RIR policy not to worry about the routability of an a prefix I guess they do worry about it? Thanks, Harsha. On Tue, 10 Dec 2002 [EMAIL PROTECTED] wrote: Hello, Now I am confused because I have got two sets of contradicting answers. Some say that anyone can multihome, some say that you need to be of a certain minimum size to multihome. May I know what is the right answer? I agree that allowing anyone to multihome would increase the size of the routing table. So does this mean that someone has to be of a certain size to multihome? Harsha. anyone can multihome, with the cooperation of others. current practice seems to dictate that the standard operating procedures to protect the integrity of the routing system mandate that only prefixes of certain lengths are allowed at -SOME- isp boundaries. you seem to have the assumption that there is a single standard here. There is not. --bill
Re: FW: /8s and filtering
Clue! - as you know doubt are now aware, VERIO and Jippi are -two- of the tens of thousands of ISPs that make up the catanet that is the Internet. The published filtering policies of these two providers is a useful tool for others to determine why VERIO and Jippi are contributing to odd routing. WRT learning more, you may wish to review the IETF's CIDRd WG archives from 1993-1997. You may also wish to review RFC 2050 and the various RIR policies on the evolution of that work. Hello, Yes, it is all classless now, but I saw Verio's policies and thought that it is the way ISPs filter. Also, the Jippi group filters at /21 except in the 192.0/7 space (where it is a /24). I didn't have enough knowledge to realize that classful was vestigal. Thanks, Harsha. On Tue, 10 Dec 2002 [EMAIL PROTECTED] wrote: but there is no class C space anymore. there is no class A space either. its all CIDR space and some providers have retained some vestigal classfull concepts in the creation/maintaince of their routing filters. a /24 may or may not get you past my filters. any you'll have no way to know until/unless you try to get to my sites or we develop a peering relationship. wrt the evolution of filters. yes, they do evolve. and so does ARIN policy. you presume too much to second guess that ARIN policy will evolve in the way you outline. Hello, Thank you very much everyone for all your replies. When Class C space gets used up, wouldn't the filtering policies have to change to allow the same kind of multihoming from the Class A space. Currently, a /24 from Class C is enough to get past filters. However later, a /22 (or is it /20) from Class A would be required to get past filters. Since there are only three /8s left in Class C, I was curious whether filtering policies would change to accommodate this. If filtering policies won't change ARIN will have to change its multihoming PA policy to giving away a /22 instead of a /24. Though officially it is RIR policy not to worry about the routability of an a prefix I guess they do worry about it? Thanks, Harsha. On Tue, 10 Dec 2002 [EMAIL PROTECTED] wrote: Hello, Now I am confused because I have got two sets of contradicting answers. Some say that anyone can multihome, some say that you need to be of a certain minimum size to multihome. May I know what is the right answer? I agree that allowing anyone to multihome would increase the size of the routing table. So does this mean that someone has to be of a certain size to multihome? Harsha. anyone can multihome, with the cooperation of others. current practice seems to dictate that the standard operating procedures to protect the integrity of the routing system mandate that only prefixes of certain lengths are allowed at -SOME- isp boundaries. you seem to have the assumption that there is a single standard here. There is not. --bill
Re: Spam. Again.. -- and blocking net blocks?
Are you billing and presumably suing (if they don't pay) the owners of the website et al for the damages they've caused your business by all this? If not you're just subsidizing their attempt to profit off of mayhem at your expense. The question of course is rhetorical. On December 10, 2002 at 10:00 [EMAIL PROTECTED] (Mark Segal) wrote: Before the flame begins.. I'm not sure when this started.. Background: We have a downstream ISP, who hosts a website of questionable material. This customer (of our customer) used a third party to spam on their behalf.. Which is a violation of our AUP. (In fact we null0 the /32 in question). Problem: For some reason, spews has decided to now block one of our /19.. Ie no mail server in the /19 can send mail. Questions: 1) How do we smack some sense into spews? 2) Does anyone else see a HUGE problem with listing a /19 because there is one /32 of a spam advertised website? When did this start happening? Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570
Re: FW: /8s and filtering
quit trolling! you dont.. ask them, view their website, view their looking glass, phone their noc... the internet is a large group of networks under independent administrations, they can do as they please and frequently do! Steve On Tue, 10 Dec 2002, Harsha Narayan wrote: Hello, But how do you know how many of the rest filter where? Harsha. On Tue, 10 Dec 2002 [EMAIL PROTECTED] wrote: Clue! - as you know doubt are now aware, VERIO and Jippi are -two- of the tens of thousands of ISPs that make up the catanet that is the Internet. The published filtering policies of these two providers is a useful tool for others to determine why VERIO and Jippi are contributing to odd routing.
Re: Spam. Again.. -- and blocking net blocks?
Barry Shein wrote: The only solution to spam is to start charging for email (perhaps with reasonable included minimums if that calms you down for some large set of you) and thus create an economic incentive for all parties involved. Face it folks, the party is over, the free-for-all was a nice idea but it simply did not work. See The Tragedy of the Commons. Sure, because charging for postal mail has certainly stopped the deplorable practice of junk mailing./sarcasm As long as spamming is legal, people will do it, period. You cannot solve administrative problems with technical solutions. The key is for ISPs to form a political lobby (with the same power as the DMA) and push for reasonable laws to protect consumers. Until then, we're all pissing in the wind. S
Re: Spam. Again.. -- and blocking net blocks?
On Tue, 10 Dec 2002, Stephen Sprunk wrote: Barry Shein wrote: The only solution to spam is to start charging for email (perhaps with reasonable included minimums if that calms you down for some large set of you) and thus create an economic incentive for all parties involved. Face it folks, the party is over, the free-for-all was a nice idea but it simply did not work. See The Tragedy of the Commons. Sure, because charging for postal mail has certainly stopped the deplorable practice of junk mailing./sarcasm As long as spamming is legal, people will do it, period. You cannot solve administrative problems with technical solutions. The key is for ISPs to form a political lobby (with the same power as the DMA) and push for reasonable laws to protect consumers. Until then, we're all pissing in the wind. This discussion is very familiar! ... and that will stop for example the nigeria scams how? or the asian porn sites how? Steve
Re: Spam. Again.. -- and blocking net blocks?
Ok on a serious note can we not try to solve the spam problem here? its a never ending loop (tech problem or social problem who cares.. its a problem and we all know it, be a good operator and kill anyone who wants to spam on your network). On a not-so-serious note maybe if we just assigned spammers 69.0.0.0/8 ip space the problem would take care of itself. -Scotty - Original Message - From: hostmaster [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 10, 2002 1:00 PM Subject: Re: Spam. Again.. -- and blocking net blocks? The only solution for eliminating spam is a radical change in social behavior of those whom are causing, allowing and facilitating it. All reasonable attempts to do so have failed, mainly due to commercial interests. Thus only a primitive and for some painful interference helps. Though few want to admit it, as long as all the backbones - unanimously - are not seriously addressing this problem, and factually accept the financial consequences of cut off's, and forcefully propagate those policies to whomever is connected to them, only the hard way remains. I advocate that spews and others are tough, but apparently necessary means. The more spam, the harder the action-pack to combat it. The problem is not necessarily only Korea, Nigeria, Costa Rica, etc. We, in the US are a significant source of this activity ourselves, probably the biggest. Painfully enough we lack the initiative to set a standard for the rest for the World. best, Bert [EMAIL PROTECTED]
Re: FW: FW: /8s and filtering
I don't think even combined proposal would do it, best you can get is that everybody who supported at least one of the proposals would support the combined one and from last ARIN meeting number of large ISPs do not want any of these as they'd like to have more control over the customer so only 50% actually said there were interested in any proposal that reduced assignment size. How or why this could pass is influenced by ARIN process, only proposals that have concensus (not easily defined word, but probably around 3/4 of known participants or interested parties support would go to consenses) are passed by ARIN AC. However what is happening is that with proposals where there is no clear consensus, ARIN will be influenced too much by what is being represented at ARIN public meeting as opposed to discussion at mailing list. In my opinion this has to do with ability of ARIN to estimate support of proposals from public meeting by simple show of hands where as no such thing exist at mailing list. But ARIN public meeting is very poor representation of proposals that have more interest in smaller ISP community - based on my calculation only around 4% of participants of last ARIN meeting were from small ISPs, where are ARIN's own numbers show that 80% of ARIN members are actually small ISPs. So while I think at large majority of interested parties would be in support of one of the proposals that would decrease ARIN's minimum allocation/assignment size, this would not go far enough in ARINs's policy process because there is not enough support for this exist among large ISPs that are the ones sending participants to public meetings and having larger influence on ARIN's policy decision. In my opinion there are several ways to deal with this situation: 1. Work on having more smaller ISPs and interested parties come to ARIN public meetings. One positive approach it to held more meetings with NANOG but this is probably not quite enough. 2. Bring more equality into public policy decision process (i.e. between mailing list and public meeting). In my view this can be accomplished by allowing kind of show-hands on the ARIN mailing lists by doing web survey (possibly of only members of the maling list - I know many have opinion or stake in the process but only few are actually actively participating, same is true on public meeting but at least there majority votes and their vote is counted). 3. Change proposals to bring more support from large ISPs. (I do currently have an idea on that is kind of compromise between existing proposals and what large ISPs want as far as retaining control. The idea is a bit controversial and full of its own problems and I personally would greatly prefer current proposals but it would solve some problems and likely have better support from some large isps, so I will check by private emails with some other people who run ISPs and if I got some good response, I'll bring it up on ppml for everybody to think about). But as far as current situation, if you're interested in the proposal to bring ARIN's minimum allocation or assignment down as is done with other RIRs and you have have opinion or stake in the process (i.e. you're small isp or other company who would like to get ips directly from ARIN as opossed to relying on your upstream and in case of their ch11 wondering what you'd do...) then please do express your opinion at ARIN public policy mailing list - [EMAIL PROTECTED] See http://www.arin.net/mailing_lists/index.html#ppml for more information. P.S. If you're interested in survey approach, please send me private email. I was told this would not work but I do not agree with that and if there is enough interest we can try to at least convince ARIN to do a test survey for mailing list participants. On Tue, 10 Dec 2002, Marshall Eubanks wrote: Arin 2003-3 was a (less detailed) attempt to do the same thing http://www.arin.net/policy/2002_3.html I suspect that a suitable combination of all of these proposals would have a good chance of getting through. Regards Marshall Eubanks On Tuesday, December 10, 2002, at 04:52 PM, Forrest wrote: Now, however, that ARIN is discussing proposals such as 2002-5, 2002-6 and 2002-7 (with 2002-5 2002-6 most likely being passed within few months) ARIN maybe put in position of assigning smaller then /20 blocks and that is why I suggested on ARIN ppml mailing list that current micro-allocation wording about assiging small blocks from specifically designated larger blocks be made a separate policy that would apply to all small allocations asignments being made directly by ARIN. If you think its a good idea to make this a policy, please do send your feedback to ARIN or bring it up on ppml mailing list and then ARIN can work on this futher to make it a policy. Proposal 2002-7 is
Re: FW: /8s and filtering
Nope. Don't care either. thats their business. When/If we need to develop a business relationship with any of them, then we get to discuss our filtering policies as aligned with theirs. why do you care? Hello, But how do you know how many of the rest filter where? Harsha. On Tue, 10 Dec 2002 [EMAIL PROTECTED] wrote: Clue! - as you know doubt are now aware, VERIO and Jippi are -two- of the tens of thousands of ISPs that make up the catanet that is the Internet. The published filtering policies of these two providers is a useful tool for others to determine why VERIO and Jippi are contributing to odd routing.
RE: Spam. Again.. -- and blocking net blocks?
On Tue, 10 Dec 2002 15:45:29 -0500, Scott Silzer wrote: I could understand if an ISP was allowing spam from a portion of there network. But in this case the only thing that the ISP did is host a website, the SPAM was sent from from a third party's network. The ISP did terminate the customer but in the meantime the entire NSP's network has been blacklisted, for a rouge webhosting account does sound a bit harsh. A spam blocking service that worked that way would be useless. Anyone could get any site they didn't like blacklisted simply by spamvertising it. Anyone who uses a spam blocking list that works that way is DoSing themselves. DS
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...
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: Spam. Again.. -- and blocking net blocks?
On Tue, 10 Dec 2002, Barry Shein wrote: The only solution to spam is to start charging for email (perhaps with reasonable included minimums if that calms you down for some large set of you) and thus create an economic incentive for all parties involved. Absolutely unrealistic... micropayments never got off the ground for a number of good reasons - some of them having to do with unwillingness of national governments to forfeit financial surveillance. Even if e-mail will cost something, you'd still be getting a lot more spam than useful mail. Check your snail-mail box for empirical evidence :) I'd say strong authentication of e-mail sources and appropriate sorting at the receiving end should do the trick. When I give someone e-mail address, I may just as well get their fingerprint and put in my allowed database. The question is, as always, convinience and useability - with a good design that doesn't seem unsurmountable. Face it folks, the party is over, the free-for-all was a nice idea but it simply did not work. See The Tragedy of the Commons. Linux does not exist, science disappeared long time ago, etc, etc. Those are commons, too. In fact, the prevailing myth is that property system is the primary driver of progress. As if. It existed for several millenia (in fact, all higher animals exhibit behaviour consistent with notion of property, usually territory and females) and not much happened most of that time, aside from endless wars. Then the decidedly anti-proprietary gift economy of science comes along and in couple hundred years completely changes the world. The free-for-all is a nice idea. Should be preserved whereever possible. Spam is not tragedy of commons (i.e. depletion of shared resources because of uncontrolled cost-free accessibility) - the spam traffic does not kill the network, last I checked (in fact, TCP's congestion control provides a basic fairness enforcement in the Internet - which explains why the backbones aren't really prone to the tragedy of commons, even when demand is massively larger than supply). Spam is theft (i.e. unauthorized use of private resources), and should be fought as such - by prosecuting perps, by installing locks, and by checking ids before granting access. --vadim
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 - 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: Spam. Again.. -- and blocking net blocks?
That is exactly what was done to to Futureway a third party spammed for a site hosted by a downstream ISP and the result was there entire network begging blacklisted by SPEWS. At 15:41 -0800 12/10/2002, David Schwartz wrote: On Tue, 10 Dec 2002 15:45:29 -0500, Scott Silzer wrote: I could understand if an ISP was allowing spam from a portion of there network. But in this case the only thing that the ISP did is host a website, the SPAM was sent from from a third party's network. The ISP did terminate the customer but in the meantime the entire NSP's network has been blacklisted, for a rouge webhosting account does sound a bit harsh. A spam blocking service that worked that way would be useless. Anyone could get any site they didn't like blacklisted simply by spamvertising it. Anyone who uses a spam blocking list that works that way is DoSing themselves. DS -- Scott A Silzer
RE: Spam. Again.. -- and blocking net blocks?
I like Segal's DoS idea, except instead of the packet generators, let's be nice and just DDoS port 25 on the sunzofbiatches mail servers/load balancers... fight fire with fire... :) On Tue, 2002-12-10 at 20:39, Scott Silzer wrote: That is exactly what was done to to Futureway a third party spammed for a site hosted by a downstream ISP and the result was there entire network begging blacklisted by SPEWS. At 15:41 -0800 12/10/2002, David Schwartz wrote: On Tue, 10 Dec 2002 15:45:29 -0500, Scott Silzer wrote: I could understand if an ISP was allowing spam from a portion of there network. But in this case the only thing that the ISP did is host a website, the SPAM was sent from from a third party's network. The ISP did terminate the customer but in the meantime the entire NSP's network has been blacklisted, for a rouge webhosting account does sound a bit harsh. A spam blocking service that worked that way would be useless. Anyone could get any site they didn't like blacklisted simply by spamvertising it. Anyone who uses a spam blocking list that works that way is DoSing themselves. DS -- -JaL AFAIK, You think I'm a BOFH for continually bashing you over the head with a clue-by-four. OTOH, if you would just RTFM every once in a while, my life would suck *much* less.
Re: Spam. Again.. -- and blocking net blocks?
I'm not taking sides here, but do want to mention some other aspects: Unnamed Administration sources reported that Scott Silzer said: I could understand if an ISP was allowing spam from a portion of there (sic) network. But in this case the only thing that the ISP did is host a website, the SPAM was sent from from a third party's network. The ISP did terminate the customer but in the meantime the entire NSP's network has been blacklisted, for a rouge webhosting account does sound a bit harsh. Excuse me, the ONLY thing? I don't think it's quite fair to condemn a whole program because of a single slip-up. General Buck Turgidson Since 90% of the spam I get is relay-raped off of some .kr/cn site, It'd say the gonads^H^Hweb address is exactly the correct target. It's the asset in place. What's missing in your report is timeframes. How long was the spamsite up? When did the first report hit .sightings? Were there responses from abuse@, postmaster@ etc? For the record, my view on SPEWS is this 0) I'm less than comfortable with it but... 1) It would not exist if there was not a demand for it; after all, it's powerless if no mail host looks at it. 2) The fact there is so much heat over it is proving its impact. 3) Past, more moderate approaches proved very ineffective, for reasons of policy or getting sued into silence. 4) Like it or not, it IS waking up large carriers who have previously turned a blind eye. 5) No one has offered a better solution so far. As Perot said - I'm all ears.. -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
