- NANOG - lists.nanog.org

Re: Operational Issues with 69.0.0.0/8...
by Michael.Dillon＠radianz.com 11 Dec '02

11 Dec '02

> > Sean Donelan, May 14 1998 (three employers ago, so this should not be > > taken as representing the official position any of my past, present or > > future employers) > Yakhov, Elise, Mark, and Bill - 1994 as part of the RA > project, bringers of the RAdb. This gets to the heart of the matter. It is now 8 years later and RADB is not catching on. But during the same time period some other UMich people worked on a more general purpose directory service called LDAP and that one is catching on. LDAP technology can be made to do the job that we need done and instead of having to create tools from scratch we can leverage a lot of commercial tools to deal with the core functions. --Michael Dillon

7 10

Re: FW: /8s and filtering
by Harsha Narayan 10 Dec '02

10 Dec '02

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. On Tue, 10 Dec 2002, David Schwartz wrote: > > > 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 > >

4 9

Re: FW: FW: /8s and filtering
by Forrest 10 Dec '02

10 Dec '02

> 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

3 2

RE: FW: /8s and filtering
by Todd A. Blank 10 Dec '02

10 Dec '02

Thank you! I thought that was the whole point of CIDR... -----Original Message----- From: bmanning(a)vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Tuesday, December 10, 2002 4:54 PM To: Harsha Narayan Cc: bmanning(a)vacation.karoshi.com; nanog(a)merit.edu 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 bmanning(a)vacation.karoshi.com 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 > > > > > >

1 0

Re: FW: /8s and filtering
by Harsha Narayan 10 Dec '02

10 Dec '02

> > 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.

3 2

Re: FW: /8s and filtering
by Forrest 10 Dec '02

10 Dec '02

> > >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

5 5

RE: Spam. Again.. -- and blocking net blocks?
by Mark Segal 10 Dec '02

10 Dec '02

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:Hansel.Lee@corp.winfirst.com] > Sent: December 10, 2002 3:08 PM > To: 'nanog(a)nanog.org' > Cc: 'owner-nanog(a)merit.edu' > 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: Michael.Dillon(a)radianz.com [mailto:Michael.Dillon@radianz.com] > Sent: Tuesday, December 10, 2002 08:36 > To: MSegal(a)FUTUREWAY.CA > Cc: nanog(a)nanog.org; owner-nanog(a)merit.edu > 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 >

1 0

RE: FW: /8s and filtering
by Ejay Hire 10 Dec '02

10 Dec '02

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:nathan@stonekitty.net] Sent: Tuesday, December 10, 2002 1:01 PM To: Forrest Cc: nanog(a)merit.edu 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~

6 11

RE: FW: /8s and filtering
by Ejay Hire 10 Dec '02

10 Dec '02

"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:hnarayan@cs.ucsd.edu] Sent: Tuesday, December 10, 2002 1:41 PM To: Alec H. Peterson Cc: Ejay Hire; nanog(a)merit.edu 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 <ejay.hire(a)isdn.net> > 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 -- ahp(a)hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com >

2 1

RE: FW: /8s and filtering
by Ejay Hire 10 Dec '02

10 Dec '02

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:ahp@hilander.com] Sent: Tuesday, December 10, 2002 1:34 PM To: Ejay Hire; nanog(a)merit.edu Subject: RE: FW: /8s and filtering --On Tuesday, December 10, 2002 13:08 -0600 Ejay Hire <ejay.hire(a)isdn.net> 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 -- ahp(a)hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com

1 0