We entered into a contract with Cogent for service, and were assigned a /22 for our use. This reassignment was listed in Cogent's rwhois server (they don't SWIP). They also gave written permission to another transit provider (Peer1) to accept our BGP announcements for the /22. We have been announcing them to our Peer1 and over a dozen peers for a few months now. After paying Cogent $11K, a billing dispute developed. On Friday May 3 we terminated our service with Cogent, and on May 5 Cogent contacted our main internet connection provder to stop routing these IPs. Cogent did not contact us first. There is still an RADB entry for this block with our AS21936 as the origin. Under pressure from Cogent Peer1 complied, though I think I have them convinced that a few hours notice on a Sunday evg is not a reasonable amount of time to renumber from a /22. What is the generally accpted timeframe for renumbering? My reading of ARIN policy would seem to imply at least 30 days. Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.
> What is the generally accpted timeframe for renumbering? My reading of > ARIN policy would seem to imply at least 30 days. I'm not sure it's fair to say that there's an "accepted timeframe" per se... I've seen 30 days. I've more commonly seen 90 days. I've seen 18 months. I've also seen immediate, like happened to you, when the customer stops paying and leaves on hostile terms. In short, you can't expect anything from someone you're not willing to pay, and who has no future prospect of doing business with you again. If you want a longer period to renumber, pay them for it. -Bill
On Sun, 5 May 2002, Bill Woodcock wrote:
> What is the generally accpted timeframe for renumbering? My reading of > ARIN policy would seem to imply at least 30 days.
I'm not sure it's fair to say that there's an "accepted timeframe" per se... I've seen 30 days. I've more commonly seen 90 days. I've seen 18 months. I've also seen immediate, like happened to you, when the customer stops paying and leaves on hostile terms. In short, you can't expect anything from someone you're not willing to pay, and who has no future prospect of doing business with you again. If you want a longer period to renumber, pay them for it.
Well how am I supposed to arrange a payment on a Sunday afternoon? As well I'd say I've already paid them more than enough to use their IPs - I never brought up a BGP session with them and never passed a single packet to them. I'm surprised to hear that such extortion techniques are considered acceptable. -Ralph
Well how am I supposed to arrange a payment on a Sunday afternoon?
As well I'd say I've already paid them more than enough to use their IPs - I never brought up a BGP session with them and never passed a single packet to them. I'm surprised to hear that such extortion techniques are considered acceptable.
somehow, i suspect that we're hearing only one side of a, quite likely messy and unhappy, story. and i doubt it all happened on a sunny sunday afternoon. randy
Well how am I supposed to arrange a payment on a Sunday afternoon?
As well I'd say I've already paid them more than enough to use their IPs - I never brought up a BGP session with them and never passed a single packet to them. I'm surprised to hear that such extortion techniques are considered acceptable.
somehow, i suspect that we're hearing only one side of a, quite likely messy and unhappy, story. and i doubt it all happened on a sunny sunday afternoon.
That's why I can't believe Cogent actually did this. 14:46 eastern, May 2 my Cogent rep Scott Elrod emailed me indicating there would be no resolution to the dispute, and to contact him should I wish to have Cogent service in the future. Since then we received *NO* contact from Cogent. I first heard that Cogent was expecting an immediate renumbering from the /22 was when I got an email from Peer1 (as I was watching Montreal beat Carolina). -Ralph
Well how am I supposed to arrange a payment on a Sunday afternoon?
As well I'd say I've already paid them more than enough to use their IPs - I never brought up a BGP session with them and never passed a single packet to them. I'm surprised to hear that such extortion techniques are considered acceptable.
Read your contract with Cogent carefully. I know our contract states that any IP addresses allocated must be returned at termination of contract. As with all PA address space, I would suspect this is the norm. Simon -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart@bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/
Well how am I supposed to arrange a payment on a Sunday afternoon?
As well I'd say I've already paid them more than enough to use their IPs - I never brought up a BGP session with them and never passed a single packet to them. I'm surprised to hear that such extortion techniques are considered acceptable.
Read your contract with Cogent carefully. I know our contract states that any IP addresses allocated must be returned at termination of contract. As with all PA address space, I would suspect this is the norm.
Ours too but we'd still be reasonable, even with a company we had a major dispute with (altho we might give them 1 month instead of 6 to return them!). I think they're on dangerous ground, whether or not their contract says the IPs should be returned if they not only stop routing them but then start contacting third parties that they have no relationship with and ask them to stop routing them with the end result being that your business cannot function then I'd say this looks more malicious than pure business and I'd suggest to them a courtroom might view it that way too. I dont like legal battles tho, so I'd probably contact them.. suggest they are harming your business illegally and that a month or two is not unreasonable to get alternative arrangements in place, dispute or not. Steve
On Mon, 6 May 2002, Stephen J. Wilcox wrote:
I think they're on dangerous ground, whether or not their contract says the IPs should be returned if they not only stop routing them but then start contacting third parties that they have no relationship with and ask them to stop routing them with the end result being that your business cannot function then I'd say this looks more malicious than pure business and I'd suggest to them a courtroom might view it that way too.
This whole thing sounds fishy. He never passed any traffic to cogent, but he was using their IPs. Why wasn't he using Peer1's IPs? Cogent tried to get them shut down on a sunday? Is there a serious BOFH in Cogent's network monitoring group? I doubt the billing department would be open sunday afternoon to order the disconnect, much less know to suggest contacting Peer1 to ask them to stop routing the space. It sounds like there's an awful lot missing from the story. This is why using provider IP space sucks...but you have to plan accordingly. If you're in dispute and plan to terminate service, start renumbering. I've been there and done that. I've also been on the other end and let a customer have several months to renumber, but that was a special case and they left on relatively good terms. A customer who left without paying their bill would likely not be treated so well. -- ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Its interesting that such a vicious dispute has taken place. It has been my experience with Cogent infact that when issues exist that they are quite willing to at least listen and arrive at some reasonable solution. I know when I have had issues all be it more technical than billing they acted quite quickly and responsibly. My advise in dealing with them as it would be in dealing with a nybody is be reasonable and very calm. Most of the engineers and upper management have really good heads on their shoulders and seem willing to work things out. That's been my experienc anyway. Scott On Mon, 6 May 2002, Stephen J. Wilcox wrote:
Well how am I supposed to arrange a payment on a Sunday afternoon?
As well I'd say I've already paid them more than enough to use their IPs - I never brought up a BGP session with them and never passed a single packet to them. I'm surprised to hear that such extortion techniques are considered acceptable.
Read your contract with Cogent carefully. I know our contract states that any IP addresses allocated must be returned at termination of contract. As with all PA address space, I would suspect this is the norm.
Ours too but we'd still be reasonable, even with a company we had a major dispute with (altho we might give them 1 month instead of 6 to return them!).
I think they're on dangerous ground, whether or not their contract says the IPs should be returned if they not only stop routing them but then start contacting third parties that they have no relationship with and ask them to stop routing them with the end result being that your business cannot function then I'd say this looks more malicious than pure business and I'd suggest to them a courtroom might view it that way too.
I dont like legal battles tho, so I'd probably contact them.. suggest they are harming your business illegally and that a month or two is not unreasonable to get alternative arrangements in place, dispute or not.
Steve
On Mon, 6 May 2002, Ralph Doncaster wrote:
What is the generally accpted timeframe for renumbering? My reading of ARIN policy would seem to imply at least 30 days.
I've read some of your other notes so I'm aware there may be extenuating circumstances. That said, I want to mention normal policies as far as I can see here.... If you have a /22 from a provider, then your right to use it generally terminates with the end of the contract with that provider. If you knew this relationship was going bad, the correct thing would have been to renumber out of that space as soon as you "saw the writing on the wall" so to speak and prepare for this event. The bottom line is the space is theirs and they can do whatever they want with it. I know that if I terminate service to a customer (or the customer disconnects with me), I expect an immediate return of the space. If they want to keep it they need to keep service with me. Evidentally, there is no current service arrangement between you and Cogent. It sounds like you've got some stuff for the lawyers to fight about. Most likely cogent has done what a lot of us on the list would expect to be the right thing in relation to the space - immediately revoke use of address space upon termination of service. About the only leg you might have to stand on as far as this is concerned is the termination notice term language in the contract you signed with them ... I.E. they may have to give you 30 days notice of termination of service, or if you gave them notice, they might have to provide service for the remainder of the notice term. That said, I'd recommend you get runumbering as it will probably be faster to renumber than to work something out with cogent as it sounds like you aren't on the best of terms with them. - Forrest W. Christian (forrestc@imach.com) AC7DE ---------------------------------------------------------------------- The Innovation Machine Ltd. P.O. Box 5749 http://www.imach.com/ Helena, MT 59604 Home of PacketFlux Technogies and BackupDNS.com (406)-442-6648 ---------------------------------------------------------------------- Protect your personal freedoms - visit http://www.lp.org/
On Mon, 6 May 2002, Forrest W. Christian wrote:
On Mon, 6 May 2002, Ralph Doncaster wrote:
What is the generally accpted timeframe for renumbering? My reading of ARIN policy would seem to imply at least 30 days. [...] The bottom line is the space is theirs and they can do whatever they want with it.
Is that true? I thought the space belongs to ARIN, and they loan it to certain parties. Those parties can use the IPs in accordance with ARIN rules. -Ralph
Hello Ralph,
Is that true? I thought the space belongs to ARIN, and they loan it to certain parties. Those parties can use the IPs in accordance with ARIN rules.
The way you've written the above statements makes them true. However, such a relationship does not extend to the issue you're dealing with. ARIN cannot dictate the business practices of its constituents. ARIN's policy on renumbering only relates to providers renumbering out of their existing upstream blocks to obtain virgin blocks from ARIN. The renumbering policies of ARIN are not applied, explicitly or implicitly, to the provider's downstream assignment policies. [I guess they would be in theory if you were seeking a larger assignment from your upstream and wanted to renumber out of your existing assignment to obtain that space...] What others have told you here is correct: when you terminated your contract with Cogent [any contract language nonwithstanding] you gave up your "right" to use any portion of their address space. As one person on here already pointed out, this is a good thing. Think about it. /david
What others have told you here is correct: when you terminated your contract with Cogent [any contract language nonwithstanding] you gave up your "right" to use any portion of their address space.
As one person on here already pointed out, this is a good thing. Think about it.
What it tells me is I should have wasted enough space to consume 8 /24s long ago, so I could get a /20 directly from ARIN. I assign IPs to customers very conservatively. Multiple DSL customers with static IPs are put on a shared subnet instead of one subnet per customer. I easily could have used 8 /24's a year ago and still conformed to ARIN rules. At the time I was only using 3 /24's. We recently reached 8 /24s and applied to ARIN a few weeks ago for a /20, but it sounds like the best thing to do is to use IPs in the most inefficient way possible (while still conforming to ARIN policy) in order to quickly qualify for PI space. -Ralph
On Monday 06 May 2002 10:00 am, Ralph Doncaster wrote:
What others have told you here is correct: when you terminated your contract with Cogent [any contract language nonwithstanding] you gave up your "right" to use any portion of their address space.
As one person on here already pointed out, this is a good thing. Think about it.
What it tells me is I should have wasted enough space to consume 8 /24s long ago, so I could get a /20 directly from ARIN. I assign IPs to customers very conservatively. Multiple DSL customers with static IPs are put on a shared subnet instead of one subnet per customer. I easily could have used 8 /24's a year ago and still conformed to ARIN rules. At the time I was only using 3 /24's. We recently reached 8 /24s and applied to ARIN a few weeks ago for a /20, but it sounds like the best thing to do is to use IPs in the most inefficient way possible (while still conforming to ARIN policy) in order to quickly qualify for PI space.
-Ralph
<rant> I'm sorry, but ARIN's policy practically _encourages_ the "efficient wasting" of space to qualify for PI space. This is one of the most frustrating things to deal with. What's a startup ISP/MSP/ASP-type to do? You want PI space for the benefit of your customers (for obvious reasons), but ARIN requires that you start with an upstream's space. So you generate B.S. justification for 8 /24s, slap a zillion IPs on some dumb 386 somewhere, then request PI space from ARIN. Then two years later your upstream ISP realizes you don't need the space anymore, then MAYBE assigns it elsewhere. This just seems counter-productive to me. There really should be a vehicle for these types of situations. Grant -- Grant A. Kirkwood - grant@tnarg.org Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED
Hmmm, maybe my experience with Arin is differnet but it wasn't all that difficult for me. I received a /19 initial allocation and never had to use upstream space at all!!! It took a little more paperwork and perhaps my case was unique but it was quite painless. Scott On Mon, 6 May 2002, Grant A. Kirkwood wrote:
On Monday 06 May 2002 10:00 am, Ralph Doncaster wrote:
What others have told you here is correct: when you terminated your contract with Cogent [any contract language nonwithstanding] you gave up your "right" to use any portion of their address space.
As one person on here already pointed out, this is a good thing. Think about it.
What it tells me is I should have wasted enough space to consume 8 /24s long ago, so I could get a /20 directly from ARIN. I assign IPs to customers very conservatively. Multiple DSL customers with static IPs are put on a shared subnet instead of one subnet per customer. I easily could have used 8 /24's a year ago and still conformed to ARIN rules. At the time I was only using 3 /24's. We recently reached 8 /24s and applied to ARIN a few weeks ago for a /20, but it sounds like the best thing to do is to use IPs in the most inefficient way possible (while still conforming to ARIN policy) in order to quickly qualify for PI space.
-Ralph
<rant>
I'm sorry, but ARIN's policy practically _encourages_ the "efficient wasting" of space to qualify for PI space. This is one of the most frustrating things to deal with. What's a startup ISP/MSP/ASP-type to do? You want PI space for the benefit of your customers (for obvious reasons), but ARIN requires that you start with an upstream's space. So you generate B.S. justification for 8 /24s, slap a zillion IPs on some dumb 386 somewhere, then request PI space from ARIN. Then two years later your upstream ISP realizes you don't need the space anymore, then MAYBE assigns it elsewhere.
This just seems counter-productive to me. There really should be a vehicle for these types of situations.
Grant
On 5/6/02 10:20 AM, "Grant A. Kirkwood" <grant@tnarg.org> wrote:
I'm sorry, but ARIN's policy practically _encourages_ the "efficient wasting" of space to qualify for PI space. This is one of the most frustrating things to deal with.
As someone who used to run a registry, one of the most frustrating things to deal with was watching ISPs pee in their own pool and then scream at the registries 'cause the water was yellow. Just how big should the DFZ be? Given the Internet is not (yet, at least) a fascist state, the registries rely on ISPs to be aware of the environment in which they are operating. As it is unlikely any of the registries will be hiring independent auditing firms to verify true utilization, there is need for a certain level of trust. If an ISP is too small to justify the allocation of a /20, then they should obtain address space from an upstream provider so that they do not add yet another entry to the DFZ. The term "tragedy" in "the tragedy of the commons" is not a mistake... Rgds, -drc
On Monday 06 May 2002 10:41 am, David Conrad wrote:
On 5/6/02 10:20 AM, "Grant A. Kirkwood" <grant@tnarg.org> wrote:
I'm sorry, but ARIN's policy practically _encourages_ the "efficient wasting" of space to qualify for PI space. This is one of the most frustrating things to deal with.
As someone who used to run a registry, one of the most frustrating things to deal with was watching ISPs pee in their own pool and then scream at the registries 'cause the water was yellow.
Just how big should the DFZ be?
What are we trying to solve here? AFAIK, the policy exists because of the supposed "shortage" of IP space. Let's not regurgitate the "basement-multihomers" discussion. -- Grant A. Kirkwood - grant@tnarg.org Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED
Grant, On 5/6/02 11:03 AM, "Grant A. Kirkwood" <grant@tnarg.org> wrote:
Just how big should the DFZ be? What are we trying to solve here?
Solve? I wasn't under the impression that anyone was trying to solve anything. Venting of unhappiness, perhaps? But perhaps I'm too cynical...
AFAIK, the policy exists because of the supposed "shortage" of IP space.
That is not my understanding. Or rather, this wasn't the basis of policies defined in RFC 2050 or any subsequent policies that I'm aware of (perhaps to the chagrin of those pushing IPv6). IPv4 address space is a _limited_ resource, not necessarily (currently) a scarce resource. The policies described in RFC 2050 documented existing registry address delegation policies established in a (sometimes excruciatingly painful) free-for-all with the ISPs, the IEPG, the IETF CIDRD and ALE working groups, and the various local, national, and regional registries. Look at the introduction of RFC 2050, in particular, the three goals listed.
Let's not regurgitate the "basement-multihomers" discussion.
Ah yes, number 2'ing in the pool. I won't mention it if you won't. In any event, the whole point here is that if everybody and their brother start announcing (and withdrawing) routes into the DFZ, ISPs will have two choices: A) watch their routers become non-responsive or crash and (hopefully) reboot B) filter announcements to keep the routing tables and thrash within reason Historically, ISPs have chosen "B" (Hi Sean! :-)). You'll note that it is the ISPs (not the registries) that have control over what gets into routing tables. Make life hard for the folks that have full routes and they'll make life hard for you. Yes, you can lie through your teeth on address space allocation requests. You'll probably even get away with it (although in my experience, it is surprising how difficult people find staying consistent with their lies). However, as with dumping dioxins into the water table, the end result is somewhat less than appealing. Rgds, -drc
On Mon, May 06, 2002 at 10:41:09AM -0700, David Conrad wrote:
On 5/6/02 10:20 AM, "Grant A. Kirkwood" <grant@tnarg.org> wrote:
I'm sorry, but ARIN's policy practically _encourages_ the "efficient wasting" of space to qualify for PI space. This is one of the most frustrating things to deal with.
As someone who used to run a registry, one of the most frustrating things to deal with was watching ISPs pee in their own pool and then scream at the registries 'cause the water was yellow.
Just how big should the DFZ be?
Given the Internet is not (yet, at least) a fascist state, the registries rely on ISPs to be aware of the environment in which they are operating. As it is unlikely any of the registries will be hiring independent auditing firms to verify true utilization, there is need for a certain level of trust. If an ISP is too small to justify the allocation of a /20, then they should obtain address space from an upstream provider so that they do not add yet another entry to the DFZ.
A multi-homed ISP who advertises PA space to multiple transit providers adds state to the DFZ. It is common practice for PA-delegating transit providers to punch a whole in their covering supernet advertisements in order to facilitate this. The PI/PA distinction seems unhelpful in the case of a multi-homed ISP.
The term "tragedy" in "the tragedy of the commons" is not a mistake...
It would be interesting to see multi-homed ISPs take the time to classify the parts of the infrastructure which are hard to renumber, versus those that are easy to renumber. It may be quite trivial to renumber large dial/cable/DSL address pools every now and then, as and when transit providers change. It may be a minor nightmare to renumber nameservers that report authoritatively for domains in a large collection of separately-managed TLDs. I wonder whether the average small, multi-homed ISP who currently lusts after PI space would find all their renumbering nightmares reduced to entirely manageable levels by the delegation of (say) 1 x /24 PI netblock to number nameservers and mail exchangers, and n x /whatever netblocks to number everything else. If the justification requirements for PI space were relaxed to accommodate this kind of scenario (or if ISPs were more inclined to use the existing requirements in this way), perhaps fewer multi- omed ISPs would feel obliged to tell lies to RIRs to obtain address delegations they don't really need. But the DFZ still accumulates additional state every time an edge network multi-homes. It would be interesting to compare the growth in the numbers of single-homed vs. multi-homed edge networks. If the edge of the network is becoming predominantly multi-homed, the goals of the RIRs wrt DFZ state containment might usefully be modified to better serve other objectives. Joe
In a message written on Mon, May 06, 2002 at 02:14:34PM -0400, Joe Abley wrote:
I wonder whether the average small, multi-homed ISP who currently lusts after PI space would find all their renumbering nightmares reduced to entirely manageable levels by the delegation of (say) 1 x /24 PI netblock to number nameservers and mail exchangers, and n x /whatever netblocks to number everything else.
This just gave me an interesting idea. What if a /8 was set aside from one of the reserved pools, and each ASN got one /24 out of that /8 automatically and predictably (8 bits net + 16 bits of ASN = 24 bits) when getting an ASN? Since you have to connect to two or more providers to get an ASN, and since the whole reason to have an ASN is to inject things into the DFZ it doesn't seem like it would increase routing table size by a huge amount. It would eliminate one whole paperwork/justification step (for your first address allocation). For subsequent allocations there is an example (that /24) of how efficiently the ISP uses the space. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Thu, 30 May 2002 09:20:17 EDT, Leo Bicknell <bicknell@ufp.org> said:
Since you have to connect to two or more providers to get an ASN, and since the whole reason to have an ASN is to inject things into the DFZ it doesn't seem like it would increase routing table size by a huge amount. It would eliminate one whole paperwork/justification step (for your first address allocation). For subsequent allocations there is an example (that /24) of how efficiently the ISP uses the space.
Unless I'm missing something, it will double the size of it, since that /24 out of that /8 won't aggregate with their other address space. (Hint - our AS has 198.82/16 and 128.173/16 and some other small blocks - how many routes do YOU see for us?) Also, there's no real reason to think that address space usage in that bootstrap /24 will accurately reflect usage in a /20 allocated to them, since THAT /20 will probably be sub-allocated to users/customers. Heck, in our AS, the nameservers and mailservers and the like would probably fit into a /27 (maybe a /26), and wouldn't tell you anything about the /20 that covers Torgeson Hall.... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
On Thu, 30 May 2002 09:48:50 -0400 Valdis.Kletnieks@vt.edu wrote:
On Thu, 30 May 2002 09:20:17 EDT, Leo Bicknell <bicknell@ufp.org> said:
Since you have to connect to two or more providers to get an ASN, and since the whole reason to have an ASN is to inject things into the DFZ it doesn't seem like it would increase routing table size by a huge amount. It would eliminate one whole paperwork/justification step (for your first address allocation). For subsequent allocations there is an example (that /24) of how efficiently the ISP uses the space.
Unless I'm missing something, it will double the size of it, since that /24 out of that /8 won't aggregate with their other address space. (Hint - our AS has 198.82/16 and 128.173/16 and some other small blocks - how many routes do YOU see for us?)
Dear Valdis; If you mean AS 1312 VA-TECH-AS , we see 4 routes : * 63.164.28.0/22 160.81.38.225 9 0 1239 7066 1312 i * 166.61.8.89 0 145 11537 7066 1312 i * 157.130.46.53 300 701 1239 7066 1312 i *> 216.177.55.5 500 15076 1239 7066 1312 i * 128.173.0.0 157.130.46.53 300 701 1239 7066 1312 i * 166.61.8.89 0 145 11537 7066 1312 i *> 216.177.55.5 500 15076 1239 7066 1312 i * 160.81.38.225 9 0 1239 7066 1312 i * 192.70.187.0 157.130.46.53 300 701 1239 7066 1312 i * 166.61.8.89 0 145 11537 7066 1312 i *> 216.177.55.5 500 15076 1239 7066 1312 i * 160.81.38.225 9 0 1239 7066 1312 i * 198.82.0.0/16 157.130.46.53 300 701 1239 7066 1312 i * 166.61.8.89 0 145 11537 7066 1312 i *> 216.177.55.5 500 15076 1239 7066 1312 i * 160.81.38.225 9 0 1239 7066 1312 i If you mean AS 13546 VT-RICHMOND-AS, only one in BGP from AS 16517 : 208.16.73.0/24 In MBGP, we only see two of these routes. Two others are aggregated into Sprint address blocks : 63.164.28.0 208.16.73.0 while 192.70.187.0 does not appear at all and is not MBGP routable from us. Regards Marshall
Also, there's no real reason to think that address space usage in that bootstrap /24 will accurately reflect usage in a /20 allocated to them, since THAT /20 will probably be sub-allocated to users/customers. Heck, in our AS, the nameservers and mailservers and the like would probably fit into a /27 (maybe a /26), and wouldn't tell you anything about the /20 that covers Torgeson Hall.... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
On Thu, 30 May 2002 09:20:17 -0400 Leo Bicknell <bicknell@ufp.org> wrote:
In a message written on Mon, May 06, 2002 at 02:14:34PM -0400, Joe Abley wrote:
I wonder whether the average small, multi-homed ISP who currently lusts after PI space would find all their renumbering nightmares reduced to entirely manageable levels by the delegation of (say) 1 x /24 PI netblock to number nameservers and mail exchangers, and n x /whatever netblocks to number everything else.
This just gave me an interesting idea. What if a /8 was set aside from one of the reserved pools, and each ASN got one /24 out of that /8 automatically and predictably (8 bits net + 16 bits of ASN = 24 bits) when getting an ASN?
This is just the "GLOP" multicast address assignment idea of RFC 2770 http://www.ietf.org/rfc/rfc2770.txt where a /24 is assigned automatically. It would add 30% to the number of BGP address blocks pretty much automatically. Regards Marshall Eubanks
Since you have to connect to two or more providers to get an ASN, and since the whole reason to have an ASN is to inject things into the DFZ it doesn't seem like it would increase routing table size by a huge amount. It would eliminate one whole paperwork/justification step (for your first address allocation). For subsequent allocations there is an example (that /24) of how efficiently the ISP uses the space.
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
In a message written on Thu, May 30, 2002 at 10:40:47AM -0400, Marshall Eubanks wrote:
It would add 30% to the number of BGP address blocks pretty much automatically.
How do you come up with that number? Of course, we have an issue with reclaiming existing space, but I think there are a number of people who have /20's today who only need a /24. Also, only allocated ASN's could anounce (what's that, 24k today?), and probably half or more of those would choose not to use this /24. Why would say, UUnet with /12's need a /24? So I'm thinking worst case this might be 5-15k new routes, which is probably 3-13% of the total space already announced. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Thu, May 30, 2002 at 10:58:31AM -0400, Leo Bicknell wrote:
In a message written on Thu, May 30, 2002 at 10:40:47AM -0400, Marshall Eubanks wrote:
It would add 30% to the number of BGP address blocks pretty much automatically.
How do you come up with that number? Of course, we have an issue with reclaiming existing space, but I think there are a number of people who have /20's today who only need a /24. Also, only allocated ASN's could anounce (what's that, 24k today?), and probably half or more of those would choose not to use this /24. Why would say, UUnet with /12's need a /24? So I'm thinking worst case this might be 5-15k new routes, which is probably 3-13% of the total space already announced.
To quote Philip Smith's routing table analysis: Total ASes present in the Internet Routing Table: 13122 Origin-only ASes present in the Internet Routing Table: 11366 Origin ASes announcing only one prefix: 4997 Transit ASes present in the Internet Routing Table: 1756 Transit-only ASes present in the Internet Routing Table: 53 So, only around 50% of the allocated ASNs are actually used, and 5000 of them are announcing only one prefix. So lets just take a rough guess and say the number of people who could benefit from having a single region to get /24s is around 5000, perhaps lower. I'd be mildly concerned that people would see "free IP blocks" and start using them even when not necessary. I think allocating them a /24 from this block only when they have demonstrated need, and don't have any other ARIN assigned blocks, would be far more efficient. To further quote Philip Smith's routing table analysis: Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:6 /10:7 /11:13 /12:34 /13:85 /14:231 /15:408 /16:7203 /17:1431 /18:2592 /19:7576 /20:7155 /21:5081 /22:7761 /23:9421 /24:62582 /25:219 /26:186 /27:83 /28:87 /29:47 /30:92 /31:0 /32:42 SIXTY TWO THOUSAND /24s (72000 if you count /23s as well)! And how many of them do you think have a legitimate need? Not that many, according to my analysis. The vast majority are people announcing something like 200 /24s in a /16 they have been allocated, all with the exact same attributes, but with just enough "holes" to prevent showing up in simple CIDR scanners. I've tried preparing lists of the worst offenders and emailing them, and the vast majority don't answer and do nothing about it. If we could seperate the people with legitimate needs from the net polluters, we could then proceed to filter with a vengence. 5000 for 62000 sounds like a good tradeoff to me. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
In a message written on Thu, May 30, 2002 at 11:27:49AM -0400, Richard A Steenbergen wrote:
I'd be mildly concerned that people would see "free IP blocks" and start using them even when not necessary. I think allocating them a /24 from this block only when they have demonstrated need, and don't have any other ARIN assigned blocks, would be far more efficient.
Since the goal is to reduce paperwork, I'm not sure about 'demonstrated need', but I could definately endorse "you get a /24 with your ASN if and only if you have no other registry assigned space assigned to you". I specifically exclude provider allocated space, as I'm assuming the ASN goal is to multihome. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Thu, May 30, 2002 at 01:10:58PM -0400, Leo Bicknell wrote:
In a message written on Thu, May 30, 2002 at 11:27:49AM -0400, Richard A Steenbergen wrote:
I'd be mildly concerned that people would see "free IP blocks" and start using them even when not necessary. I think allocating them a /24 from this block only when they have demonstrated need, and don't have any other ARIN assigned blocks, would be far more efficient.
Since the goal is to reduce paperwork, I'm not sure about 'demonstrated need', but I could definately endorse "you get a /24 with your ASN if and only if you have no other registry assigned space assigned to you". I specifically exclude provider allocated space, as I'm assuming the ASN goal is to multihome.
Yes, "demonstrating" things to ARIN is remarkably annoying. Perhaps something along the lines of a /21 to /24 available just for being multihomed. If you qualify for more IP space, you have to give it back. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
On Thu, 30 May 2002 16:21:36 PDT, Vadim Antonov said:
On Thu, 30 May 2002, Richard A Steenbergen wrote:
Yes, "demonstrating" things to ARIN is remarkably annoying. "Demonstrating" as in "getting rid of monstrosities"? :)
Only in the same sense as "defenestrate" means "requesting that everybody named Fenster leave the room" ;)
Since I run a small AS : I like this idea. Since I believe in living dangerously : I also think that a /64 should be reserved in the IPv6 address space, and (32 bit) ASN's should be given their own /32 in a GLOP like fashion for IPv6. Leo Bicknell wrote:
In a message written on Thu, May 30, 2002 at 11:27:49AM -0400, Richard A Steenbergen wrote:
I'd be mildly concerned that people would see "free IP blocks" and start using them even when not necessary. I think allocating them a /24 from this block only when they have demonstrated need, and don't have any other ARIN assigned blocks, would be far more efficient.
Since the goal is to reduce paperwork, I'm not sure about 'demonstrated need', but I could definately endorse "you get a /24 with your ASN if and only if you have no other registry assigned space assigned to you". I specifically exclude provider allocated space, as I'm assuming the ASN goal is to multihome.
-- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com 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
Marshall Eubanks wrote:
Since I run a small AS :
I like this idea.
Since I believe in living dangerously :
I also think that a /64 should be reserved in the IPv6 address space,
A /64 would have no use in the proposed scheme since it identifies a single subnet. I suspect you really want a /32 set aside since that would provide routable space to allocate /48's to each 16 bit AS.
and (32 bit) ASN's should be given their own /32 in a GLOP like fashion for IPv6.
I don't think the concept scales to 32 bit AS. Tony
Leo Bicknell wrote:
In a message written on Thu, May 30, 2002 at 11:27:49AM -0400, Richard A Steenbergen wrote:
I'd be mildly concerned that people would see "free IP blocks" and start using them even when not necessary. I think allocating them a /24 from this block only when they have demonstrated need, and don't have any other ARIN assigned blocks, would be far more efficient.
Since the goal is to reduce paperwork, I'm not sure about 'demonstrated need', but I could definately endorse "you get a /24 with your ASN if and only if you have no other registry assigned space assigned to you". I specifically exclude provider allocated space, as I'm assuming the ASN goal is to multihome.
-- Regards Marshall Eubanks
T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com 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
On Thu, 30 May 2002 17:52:55 -0700 "Tony Hain" <alh-ietf@tndh.net> wrote:
Marshall Eubanks wrote:
Since I run a small AS :
I like this idea.
Since I believe in living dangerously :
I also think that a /64 should be reserved in the IPv6 address space,
A /64 would have no use in the proposed scheme since it identifies a single subnet. I suspect you really want a /32 set aside since that would provide routable space to allocate /48's to each 16 bit AS.
OK
and (32 bit) ASN's should be given their own /32 in a GLOP like fashion for IPv6.
I don't think the concept scales to 32 bit AS.
Why not ? /32 with 32 bit ASN still leaves a /64 for each ASN. Marshall
Tony
Leo Bicknell wrote:
In a message written on Thu, May 30, 2002 at 11:27:49AM -0400, Richard A Steenbergen wrote:
I'd be mildly concerned that people would see "free IP blocks" and start using them even when not necessary. I think allocating them a /24 from this block only when they have demonstrated need, and don't have any other ARIN assigned blocks, would be far more efficient.
Since the goal is to reduce paperwork, I'm not sure about 'demonstrated need', but I could definately endorse "you get a /24 with your ASN if and only if you have no other registry assigned space assigned to you". I specifically exclude provider allocated space, as I'm assuming the ASN goal is to multihome.
-- Regards Marshall Eubanks
T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com 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
Marshall Eubanks wrote:
On Thu, 30 May 2002 17:52:55 -0700 "Tony Hain" <alh-ietf@tndh.net> wrote:
Marshall Eubanks wrote:
Since I run a small AS :
I like this idea.
Since I believe in living dangerously :
I also think that a /64 should be reserved in the IPv6 address space,
A /64 would have no use in the proposed scheme since it identifies a single subnet. I suspect you really want a /32 set aside since that would provide routable space to allocate /48's to each 16 bit AS.
OK
and (32 bit) ASN's should be given their own /32 in a GLOP like fashion for IPv6.
I don't think the concept scales to 32 bit AS.
Why not ? /32 with 32 bit ASN still leaves a /64 for each ASN.
See above... What is the point of an ASN if all you are multi-homing is a single subnet? Also, since mechanisms like rfc3041 somewhat rely on a sparse utilization to quickly converge on a usable address, you would never be able to demonstrate the efficiency you need to justify a larger block.
Marshall
Tony
Leo Bicknell wrote:
In a message written on Thu, May 30, 2002 at 11:27:49AM -0400, Richard A Steenbergen wrote:
I'd be mildly concerned that people would see "free IP blocks" and start using them even when not necessary. I think allocating them a /24 from this block only when they have demonstrated need, and don't have any other ARIN assigned blocks, would be far more efficient.
Since the goal is to reduce paperwork, I'm not sure about 'demonstrated need', but I could definately endorse "you get a /24 with your ASN if and only if you have no other registry assigned space assigned to you". I specifically exclude provider allocated space, as I'm assuming the ASN goal is to multihome.
-- Regards Marshall Eubanks
T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com 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
On Fri, 31 May 2002, Tony Hain wrote:
What is the point of an ASN if all you are multi-homing is a single subnet?
Tony, I'm missing the correlation between the amount of address space announced and multihoming. (Beyond the prefix being too long and potentially filtered). Care to elaborate? andy -- PGP Key Available at http://www.tigerteam.net/andy/pgp
Andy Walden wrote:
On Fri, 31 May 2002, Tony Hain wrote:
What is the point of an ASN if all you are multi-homing is a single subnet?
Tony,
I'm missing the correlation between the amount of address space announced and multihoming. (Beyond the prefix being too long and potentially filtered). Care to elaborate?
andy
The only reason for an ASN is the need to globally announce routing policy due to multihoming. Unless policy changes, this community tends to insist that the prefix length announced via that ASN corresponds to a site, not a single subnet. For IPv6 that means a /48 makes sense as an initial allocation with a new ASN, and a /64 does not. Tony
This is described in rfc2373 and rfc2374. The 128 bit address space is separated into a /64 for each "site" and the remaining 64 bits for the MAC address, etc, for interfaces on the site. The "public" topology is 48 bits, and this is what is supposed to be routable. This would work with a 32 bit ASN based automatic assignment - one /16 could be allocated to this, with 32 bits for the ASN, 16 bits for "site" assignments and 64 bits for interface assignments. This is _not_ the service model of RFC2374, which envisions 8192 top level routing aggregators (TLA's), with other entities getting their address blocks from one of the TLA blocks. Regards Marshall Tony Hain wrote:
Andy Walden wrote:
On Fri, 31 May 2002, Tony Hain wrote:
What is the point of an ASN if all you are multi-homing is a single subnet?
Tony,
I'm missing the correlation between the amount of address space announced and multihoming. (Beyond the prefix being too long and potentially filtered). Care to elaborate?
andy
The only reason for an ASN is the need to globally announce routing policy due to multihoming. Unless policy changes, this community tends to insist that the prefix length announced via that ASN corresponds to a site, not a single subnet. For IPv6 that means a /48 makes sense as an initial allocation with a new ASN, and a /64 does not.
Tony
-- Regards Marshall Eubanks This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com 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
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.tx t is the replacement for 2373 http://www.ripe.net/ipv6/global-ipv6-assign-2002-04-25.html is the replacement for 2374 Yes a /16 would allow for 32 bit ASNs. The prior note was looking for a /32. Tony
-----Original Message----- From: Marshall Eubanks [mailto:tme@multicasttech.com] Sent: Friday, May 31, 2002 3:09 PM To: Tony Hain Cc: Andy Walden; nanog Subject: Re: IP renumbering timeframe
This is described in rfc2373 and rfc2374. The 128 bit address space is separated into a /64 for each "site" and the remaining 64 bits for the MAC address, etc, for interfaces on the site. The "public" topology is 48 bits, and this is what is supposed to be routable.
This would work with a 32 bit ASN based automatic assignment - one /16 could be allocated to this, with 32 bits for the ASN, 16 bits for "site" assignments and 64 bits for interface assignments.
This is _not_ the service model of RFC2374, which envisions 8192 top level routing aggregators (TLA's), with other entities getting their address blocks from one of the TLA blocks.
Regards Marshall
Tony Hain wrote:
Andy Walden wrote:
On Fri, 31 May 2002, Tony Hain wrote:
What is the point of an ASN if all you are multi-homing is a single subnet?
Tony,
I'm missing the correlation between the amount of address space announced and multihoming. (Beyond the prefix being too long and potentially filtered). Care to elaborate?
andy
The only reason for an ASN is the need to globally announce routing policy due to multihoming. Unless policy changes, this community tends to insist that the prefix length announced via that ASN corresponds to a site, not a single subnet. For IPv6 that means a /48 makes sense as an initial allocation with a new ASN, and a /64 does not.
Tony
-- Regards Marshall Eubanks
This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements
T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com 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
Being picky... IDs are possible RFCs RIR documents don't even get that far... :)
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.tx t is the replacement for 2373
http://www.ripe.net/ipv6/global-ipv6-assign-2002-04-25.html is the replacement for 2374
Yes a /16 would allow for 32 bit ASNs. The prior note was looking for a /32.
Tony
-----Original Message----- From: Marshall Eubanks [mailto:tme@multicasttech.com] Sent: Friday, May 31, 2002 3:09 PM To: Tony Hain Cc: Andy Walden; nanog Subject: Re: IP renumbering timeframe
This is described in rfc2373 and rfc2374. The 128 bit address space is separated into a /64 for each "site" and the remaining 64 bits for the MAC address, etc, for interfaces on the site. The "public" topology is 48 bits, and this is what is supposed to be routable.
This would work with a 32 bit ASN based automatic assignment - one /16 could be allocated to this, with 32 bits for the ASN, 16 bits for "site" assignments and 64 bits for interface assignments.
This is _not_ the service model of RFC2374, which envisions 8192 top level routing aggregators (TLA's), with other entities getting their address blocks from one of the TLA blocks.
Regards Marshall
Tony Hain wrote:
Andy Walden wrote:
On Fri, 31 May 2002, Tony Hain wrote:
What is the point of an ASN if all you are multi-homing is a single subnet?
Tony,
I'm missing the correlation between the amount of address space announced and multihoming. (Beyond the prefix being too long and potentially filtered). Care to elaborate?
andy
The only reason for an ASN is the need to globally announce routing policy due to multihoming. Unless policy changes, this community tends to insist that the prefix length announced via that ASN corresponds to a site, not a single subnet. For IPv6 that means a /48 makes sense as an initial allocation with a new ASN, and a /64 does not.
Tony
-- Regards Marshall Eubanks
This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements
T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com 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
In a message written on Fri, May 31, 2002 at 02:35:18PM -0700, Tony Hain wrote:
The only reason for an ASN is the need to globally announce routing policy due to multihoming. Unless policy changes, this community tends to insist that the prefix length announced via that ASN corresponds to a site, not a single subnet. For IPv6 that means a /48 makes sense as an initial allocation with a new ASN, and a /64 does not.
In IPv4 land people generally filter on what the registries assign, or on some looser policy. In my /24 per ASN proposal for IPv4, I expected that /8 to be filtered on a /24 boundry. Similarly in IPv6, I would expect the /32 to be filtered on a /64 boundry. In a message written on Fri, May 31, 2002 at 06:09:03PM -0400, Marshall Eubanks wrote:
This is _not_ the service model of RFC2374, which envisions 8192 top level routing aggregators (TLA's), with other entities getting their address blocks from one of the TLA blocks.
This is an excellent point. I'll be the first to step forward to say that while this is all good in theory, the likelyhood that the market will accept the structure imposed by the IPv6 designers is near zero. That's not saying we might be able to do things more intelligent with a new system, but the grand goal is a pipe dream. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
Leo Bicknell wrote:
In a message written on Fri, May 31, 2002 at 02:35:18PM -0700, Tony Hain wrote:
The only reason for an ASN is the need to globally announce routing policy due to multihoming. Unless policy changes, this community tends to insist that the prefix length announced via that ASN corresponds to a site, not a single subnet. For IPv6 that means a /48 makes sense as an initial allocation with a new ASN, and a /64 does not.
In IPv4 land people generally filter on what the registries assign, or on some looser policy. In my /24 per ASN proposal for IPv4, I expected that /8 to be filtered on a /24 boundry.
Similarly in IPv6, I would expect the /32 to be filtered on a /64 boundry.
And the result would be a multi-homed single subnet. I don't really care if that is the goal, but you will have a hell of a time filling that 64 bits in a way that justifies more address space. If the allocation were a /48 the chances of demonstrating reasonable use are much better.
In a message written on Fri, May 31, 2002 at 06:09:03PM -0400, Marshall Eubanks wrote:
This is _not_ the service model of RFC2374, which envisions 8192 top level routing aggregators (TLA's), with other entities getting their address blocks from one of the TLA blocks.
This is an excellent point. I'll be the first to step forward to say that while this is all good in theory, the likelyhood that the market will accept the structure imposed by the IPv6 designers is near zero. That's not saying we might be able to do things more intelligent with a new system, but the grand goal is a pipe dream.
This is written as if the design were done in a vacuum. This was not something being imposed by the designers. The response at the time of RFC2374, from both the operators involved and the registries, was that strict provider aggregation was the right course, and that means you get blocks allocated from your upstream. At that time it was not expected that there would ever be more than 8k top level transit providers, but space was left to grow that number if necessary. In any case, over the last couple of years it has been recognized that address allocation policy should not be in the architecture document, and that is why those original documents are being reworked as: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.tx t is the replacement for 2373 http://www.ripe.net/ipv6/global-ipv6-assign-2002-04-25.html is the replacement for 2374 As Bill pointed out, RIR docs don't always make it to RFC, but the important thing is that the policy is documented. As long as the allocation policy stays within the scope of the architecture, there shouldn't be any operational issues. Tony
On Thu, 30 May 2002, Richard A Steenbergen wrote:
Total ASes present in the Internet Routing Table: 13122 Origin-only ASes present in the Internet Routing Table: 11366 Origin ASes announcing only one prefix: 4997 Transit ASes present in the Internet Routing Table: 1756 Transit-only ASes present in the Internet Routing Table: 53
So, only around 50% of the allocated ASNs are actually used, and 5000 of them are announcing only one prefix. So lets just take a rough guess and
That is because once an ASN is allocated it almost never is recovered by the 3 RIRs (RIPE is probably the best organized of the 3 and it never gets around to reclaiming "dead" IP address space as well). I have revoked quite a few ASNs: http://www.isoc.org.il/ipolicy.html but it involves quarterly checking at major NAPs, emails to the contacts, finding new contacts, registered postal letters and plenty of followup. Most LIRs just don't bother since reclaiming a "dead" ASN is a non-revenue affair.
say the number of people who could benefit from having a single region to get /24s is around 5000, perhaps lower.
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177(67 29 D7 BC E8 18 3E DAB2 46 B3 D8 14 36 FE B6)
Hank Nussbacher
On Thu, 30 May 2002 10:58:31 -0400 Leo Bicknell <bicknell@ufp.org> wrote:
In a message written on Thu, May 30, 2002 at 10:40:47AM -0400, Marshall Eubanks wrote:
It would add 30% to the number of BGP address blocks pretty much automatically.
How do you come up with that number? Of course, we have an issue with reclaiming existing space, but I think there are a number of people who have /20's today who only need a /24. Also, only allocated ASN's could anounce (what's that, 24k today?), and probably half or more of those would choose not to use this /24. Why would say, UUnet with /12's need a /24? So I'm thinking worst case this might be 5-15k new routes, which is probably 3-13% of the total space already announced.
I was assuming that every ASN would claim its space and not renounce any. However, in my BGP tables total number of Active Unicast AS = 13077 so, I think you are right - about 10K new routes at present, or roughly 10%. Marshall
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
Randy is right. We don't know both sides. That having been said... Ralph Doncaster wrote:
What it tells me is I should have wasted enough space to consume 8 /24s long ago, so I could get a /20 directly from ARIN.
Right. What ISPs need to realize is that whatever benefit that is gained from provider-based addressing can be negated by people not having faith that they can transition from one set of addresses to another. Being excessively strict benefits no one. And so each side needs to be reasonable. Otherwise we'll have end customers going to ARIN -- or EBay. In other words, this might be another instance of a frog in the pot. Eliot
Indeed, you have hit upon one of the significant weaknesses of the ARIN IP registry system - that it relies largely upon the integrity of it's members, in order to properly issue and conserve address space. ARIN is largely based upon the honor system, with one "check" on the potentially dishonest being a general unwilling to be branded an IP address cheat or poor internet citizen. Of course, should one choose to be somewhat less upstanding of an internet citizen, posting one's intentions to do so on NANOG, frequented as it is by various ARIN people, might not be such a good idea. - Daniel Golding
Ralph Doncaster angrily ruminated....
What it tells me is I should have wasted enough space to consume 8 /24s long ago, so I could get a /20 directly from ARIN. I assign IPs to customers very conservatively. Multiple DSL customers with static IPs are put on a shared subnet instead of one subnet per customer. I easily could have used 8 /24's a year ago and still conformed to ARIN rules. At the time I was only using 3 /24's. We recently reached 8 /24s and applied to ARIN a few weeks ago for a /20, but it sounds like the best thing to do is to use IPs in the most inefficient way possible (while still conforming to ARIN policy) in order to quickly qualify for PI space.
-Ralph
But it would seem that given the attitude many have expressed here of "if they're not your customer any more, screw 'em.", then relying on the honor system is unwise. Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc. On Mon, 6 May 2002, Daniel Golding wrote:
Indeed, you have hit upon one of the significant weaknesses of the ARIN IP registry system - that it relies largely upon the integrity of it's members, in order to properly issue and conserve address space. ARIN is largely based upon the honor system, with one "check" on the potentially dishonest being a general unwilling to be branded an IP address cheat or poor internet citizen.
Of course, should one choose to be somewhat less upstanding of an internet citizen, posting one's intentions to do so on NANOG, frequented as it is by various ARIN people, might not be such a good idea.
- Daniel Golding
Ralph Doncaster angrily ruminated....
What it tells me is I should have wasted enough space to consume 8 /24s long ago, so I could get a /20 directly from ARIN. I assign IPs to customers very conservatively. Multiple DSL customers with static IPs are put on a shared subnet instead of one subnet per customer. I easily could have used 8 /24's a year ago and still conformed to ARIN rules. At the time I was only using 3 /24's. We recently reached 8 /24s and applied to ARIN a few weeks ago for a /20, but it sounds like the best thing to do is to use IPs in the most inefficient way possible (while still conforming to ARIN policy) in order to quickly qualify for PI space.
-Ralph
Well don't forget its a two way street. If a customer isn't paying their bill then its the provider getting screwed. There is no insentive or in fact good reason to be helpful to this person. I won't be helpful to someone who decides to switch services and not pay me, ever! On the other hand if they are reasonable and if there is a friendly split both sides are more likely bo be reasonable. If someone buys a product say a computer from you, and doesn't pay you will you still service them? Better still if I'm the telephone company and you stiff me for x# of dollars and switch to another carrier do you really expect me to release the same telephone number for you so that you can switch uneffected. Its totally unreasonable to assume when someone isn't paid for their services that they will allow you to continue using their resources. And we're only talking a /20 here not to large a task. On Mon, 6 May 2002, Ralph Doncaster wrote:
But it would seem that given the attitude many have expressed here of "if they're not your customer any more, screw 'em.", then relying on the honor system is unwise.
Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.
On Mon, 6 May 2002, Daniel Golding wrote:
Indeed, you have hit upon one of the significant weaknesses of the ARIN IP registry system - that it relies largely upon the integrity of it's members, in order to properly issue and conserve address space. ARIN is largely based upon the honor system, with one "check" on the potentially dishonest being a general unwilling to be branded an IP address cheat or poor internet citizen.
Of course, should one choose to be somewhat less upstanding of an internet citizen, posting one's intentions to do so on NANOG, frequented as it is by various ARIN people, might not be such a good idea.
- Daniel Golding
Ralph Doncaster angrily ruminated....
What it tells me is I should have wasted enough space to consume 8 /24s long ago, so I could get a /20 directly from ARIN. I assign IPs to customers very conservatively. Multiple DSL customers with static IPs are put on a shared subnet instead of one subnet per customer. I easily could have used 8 /24's a year ago and still conformed to ARIN rules. At the time I was only using 3 /24's. We recently reached 8 /24s and applied to ARIN a few weeks ago for a /20, but it sounds like the best thing to do is to use IPs in the most inefficient way possible (while still conforming to ARIN policy) in order to quickly qualify for PI space.
-Ralph
As I already pointed out, I never passed a packet to Cogent. They were ready to provide service before I was ready to start using it. I paid setup, 1st month service, and then some. And your computer analogy is totally ridiculous. The only "service" I ever actually used was a /22 of IP space. A /19 from ARIN is $2500 for a year, so if Cogent wanted a couple hundred for my continued use of the /22 for 90 days I would have happily paid it. Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc. On Mon, 6 May 2002, Scott Granados wrote:
Well don't forget its a two way street. If a customer isn't paying their bill then its the provider getting screwed. There is no insentive or in fact good reason to be helpful to this person. I won't be helpful to someone who decides to switch services and not pay me, ever! On the other hand if they are reasonable and if there is a friendly split both sides are more likely bo be reasonable. If someone buys a product say a computer from you, and doesn't pay you will you still service them? Better still if I'm the telephone company and you stiff me for x# of dollars and switch to another carrier do you really expect me to release the same telephone number for you so that you can switch uneffected. Its totally unreasonable to assume when someone isn't paid for their services that they will allow you to continue using their resources. And we're only talking a /20 here not to large a task.
On Mon, 6 May 2002, Ralph Doncaster wrote:
But it would seem that given the attitude many have expressed here of "if they're not your customer any more, screw 'em.", then relying on the honor system is unwise.
Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.
On Mon, 6 May 2002, Daniel Golding wrote:
Indeed, you have hit upon one of the significant weaknesses of the ARIN IP registry system - that it relies largely upon the integrity of it's members, in order to properly issue and conserve address space. ARIN is largely based upon the honor system, with one "check" on the potentially dishonest being a general unwilling to be branded an IP address cheat or poor internet citizen.
Of course, should one choose to be somewhat less upstanding of an internet citizen, posting one's intentions to do so on NANOG, frequented as it is by various ARIN people, might not be such a good idea.
- Daniel Golding
Ralph Doncaster angrily ruminated....
What it tells me is I should have wasted enough space to consume 8 /24s long ago, so I could get a /20 directly from ARIN. I assign IPs to customers very conservatively. Multiple DSL customers with static IPs are put on a shared subnet instead of one subnet per customer. I easily could have used 8 /24's a year ago and still conformed to ARIN rules. At the time I was only using 3 /24's. We recently reached 8 /24s and applied to ARIN a few weeks ago for a /20, but it sounds like the best thing to do is to use IPs in the most inefficient way possible (while still conforming to ARIN policy) in order to quickly qualify for PI space.
-Ralph
On Mon, 6 May 2002 09:59:24 -0400 (EDT), David R Huberman wrote:
Is that true? I thought the space belongs to ARIN, and they loan it to certain parties. Those parties can use the IPs in accordance with ARIN rules.
The way you've written the above statements makes them true. However, such a relationship does not extend to the issue you're dealing with. ARIN cannot dictate the business practices of its constituents.
Actually, ARIN can dictate how its constituents allocate IP space because conforming to ARIN's policies is one of the conditions of an IP allocation and no ownership rights to the IP space are transferred in the assignment process. This argument has worked successfully for myself and others when negotiations with an address space provider turned hostile. (To my knowledge, it's never been tested in court.) DS
In the referenced message, Ralph Doncaster said:
On Mon, 6 May 2002, Forrest W. Christian wrote:
On Mon, 6 May 2002, Ralph Doncaster wrote:
What is the generally accpted timeframe for renumbering? My reading of ARIN policy would seem to imply at least 30 days. [...] The bottom line is the space is theirs and they can do whatever they want with it.
Is that true? I thought the space belongs to ARIN, and they loan it to certain parties. Those parties can use the IPs in accordance with ARIN rules.
-Ralph
s/ARIN/IANA/ but yes, registries allocate based upon rules (most ISPs are registries). In theory, IANA could revoke 192.0.0.0/8, forcing the RiR's to revoke the space, forcing the LiR's to revoke the space, and so on until Joe Blow's /29 gets revoked. In practice, this has not to my knowledge ever occured. If we ever do reach a point where exhaustion of IPv4 is imminent, I would expect this to occur. Presently, there is a voluntary request for unused address space, but as long as it is voluntary, I don't expect there being any meaningful return of unused space.
For all intense and purposes its up to the end user. In the case of an isp getting space from Arin it is allocated to them which in their terminology is different than assigned. Isps by having space allocated can then assign or remove the assignment of space they hold pretty much as they see fit as long as the meet the arin suggested minimums. My experienc has been Arin is most concerned with proper use of space fbefore allocating more space than how specific space is assigned and de-assigned. On Mon, 6 May 2002, Ralph Doncaster wrote:
On Mon, 6 May 2002, Forrest W. Christian wrote:
On Mon, 6 May 2002, Ralph Doncaster wrote:
What is the generally accpted timeframe for renumbering? My reading of ARIN policy would seem to imply at least 30 days. [...] The bottom line is the space is theirs and they can do whatever they want with it.
Is that true? I thought the space belongs to ARIN, and they loan it to certain parties. Those parties can use the IPs in accordance with ARIN rules.
-Ralph
Pressure from Cogent? I'm not sure Cogent had to apply any pressure to Peer1. Cogent could simply have null routed small aggregates of the block, rendering it useless. i.e. /24s of the /22 all static routed to one of their loopback addresses, then redistributed into BGP and sent on to their peers. By contacting Peer1, they actually did you something of a favor, as they allowed you to gracefully stop advertising the block, rather than null routing you. Of course, the amount of time you have to renumber, should it prove necessary, should be specified in the Terms and Conditions of your transit contract. If you feel wronged, you can file suit against Cogent. ARIN can publish guidelines about what others should do, and they can specify policies that govern their interaction with specific organizations, but they don't have the kind of authority to do what you are looking for. I suppose the moral of the story is, if you get into a billing dispute with an upstream, be cognizant of what's on the line, including issues like IP space, circuit term liability, etc. - Daniel Golding
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Ralph Doncaster Sent: Monday, May 06, 2002 1:19 AM To: nanog@merit.edu Subject: IP renumbering timeframe
We entered into a contract with Cogent for service, and were assigned a /22 for our use. This reassignment was listed in Cogent's rwhois server (they don't SWIP). They also gave written permission to another transit provider (Peer1) to accept our BGP announcements for the /22. We have been announcing them to our Peer1 and over a dozen peers for a few months now. After paying Cogent $11K, a billing dispute developed. On Friday May 3 we terminated our service with Cogent, and on May 5 Cogent contacted our main internet connection provder to stop routing these IPs. Cogent did not contact us first. There is still an RADB entry for this block with our AS21936 as the origin. Under pressure from Cogent Peer1 complied, though I think I have them convinced that a few hours notice on a Sunday evg is not a reasonable amount of time to renumber from a /22.
What is the generally accpted timeframe for renumbering? My reading of ARIN policy would seem to imply at least 30 days.
Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.
participants (25)
-
Andy Walden -
Bill Woodcock -
bmanning＠karoshi.com -
Daniel Golding -
David Conrad -
David R Huberman -
David Schwartz -
Eliot Lear -
Forrest W. Christian -
Grant A. Kirkwood -
Hank Nussbacher -
jlewis＠lewis.org -
Joe Abley -
Leo Bicknell -
Marshall Eubanks -
Ralph Doncaster -
Randy Bush -
Richard A Steenbergen -
Scott Granados -
Simon Lockhart -
Stephen Griffin -
Stephen J. Wilcox -
Tony Hain -
Vadim Antonov -
Valdis.Kletnieks＠vt.edu