Re: Dealing with ARIN.. my experiences & tips
Also Sprach Brian Johnson
OK. Let's all assume that Reform is necessary.
Please state, in detail, how you would reform ARIN and all of the policy changes that you would instate (asside from giving you whatever you want) to make ARIN "reformed" in the yes of it's membership.
I await, with baited breath, the answers form the Maha-Jeffy. :-)
Alas...I agree with what some others have said. The answers aren't easy, and I don't have them all easily at hand. I think there are some steps that could be taken. Some comments off the top of my head... First and foremost...ARIN seems disconnected from the realities of running an ISP...particularly a smaller ISP. There needs to be more effort to understand the business needs of ISPs in general (again, particularly smaller ISPs) to understand *why* so many people (even those that do it on a regular basis and are "experts" in it) find dealing with ARIN to be such a PITA. They need to consider whether the policies that they have in place really and truly do accomplish the goals that they are supposed to accomplish. I think its pretty clear at this point that they don't. They need some common sense discussion about really how to accomplish the goals, the current policies clearly aren't doing it...even can be counter-productive wrt to the whole point of why ARIN was created (ie, more common sense policies would have resulted in me advertising half the number of routes in BGP than I am now...the goal of reducing routing table growth has most definitely not been accomplished in my case...and, as I've pointed out...I'm really *trying* to do the Right Thing...not all ISPs do). They need to "normalize" (for lack of a better word) their published policies...as well as "normalize" their actual policies with what's published. The feel that I get (this is a perception...not much hard evidence to back it up...but I'd be surprised if I'm alone in this) is that ARIN has put policies up on its web site, and then totally independantly, developed policies for operation...with the same basic set of goals in mind. The result being policies in real life that are similar, but not the same, as what's published. If there's a change in the real-life policy, that needs to be reflected on their website. As for some specific policy points that I think are bogus. Obviously, I feel the allocating for 3-months needs to be expanded...I'd say probably to a year would be reasonable. Basing it on past usage growth...ok...I don't have any inherent problems with that, but specific situations, such as a desire to renumber out of PA space, should be considered much more strongly than it is currently. Limiting SWIP to /29 or shorter prefixes doesn't seem to have much merit to me...I imagine a lot of ISPs wouldn't want to SWIP longer prefixes because of the administrative overhead (of which there certainly would be some)...our system allows us to do it pretty easily, so it wouldn't be a big deal here. And, as bdragon pointed out, circuit size (and I'll add network size) doesn't correlate precisely with ip address space consumption (ie, the idea that you can put a very large corporate network behind a single, or very small number of ip addresses). Certainly, large networks like that, should probably have their own records...even if only a single public IP address is in use. So, what guideline would I come up for this? As a discussion starting point, require anything shorter than /29 to be SWIP'ed, but leave longer up to the ISP...yes, not many ISPs would SWIP anything longer than /29, but we would, *particularly* if it made dealing with ARIN easier (which is should). Anyway...some starting points...I'm sure...with more thought and more experience dealing with ARIN, I could come up with some more suggestions...but I'll be the first to admit that I don't have all the answers. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Thus spake "Jeff McAdams" <jeffm@iglou.com>
As for some specific policy points that I think are bogus. ... but specific situations, such as a desire to renumber out of PA space, should be considered much more strongly than it is currently.
Let me throw in one policy I've been wanting for years, which would fix most/all of Jeff's problems: RIRs should allow a member to voluntarily renumber several disparate allocations into a single prefix. The original allocations would be forfeit after a reasonable renumbering period, e.g. 6 months. If the member has at least one PI allocation, they should be allowed to combine it with PA allocations into a new, larger PI allocation. More importantly, a quick study in logic shows there should be no requirement for the existing space to meet RFC2050 requirements -- the space is already allocated. After the renumbering period there's no net damage to the IPv4 "shortage" since similar amounts of space would be assigned, but it would be a great help to the global routing system. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
--On Monday, April 14, 2003 16:20 -0500 Stephen Sprunk <stephen@sprunk.org> wrote:
RIRs should allow a member to voluntarily renumber several disparate allocations into a single prefix. The original allocations would be forfeit after a reasonable renumbering period, e.g. 6 months. If the member has at least one PI allocation, they should be allowed to combine it with PA allocations into a new, larger PI allocation.
<http://www.arin.net/policy/2002_6.html> This proposal will be coming out for final call on ppml@arin.net shortly, slightly modified to address concerns raised on the mailing list and at the public policy meeting last week in Memphis. Alec ARIN AC Member
--On Monday, April 14, 2003 16:20 -0500 Stephen Sprunk <stephen@sprunk.org> wrote:
RIRs should allow a member to voluntarily renumber several disparate allocations into a single prefix. The original allocations would be forfeit after a reasonable renumbering period, e.g. 6 months. If the member has at least one PI allocation, they should be allowed to combine it with PA allocations into a new, larger PI allocation.
<http://www.arin.net/policy/2002_6.html>
This proposal will be coming out for final call on ppml@arin.net shortly, slightly modified to address concerns raised on the mailing list and at
Thus spake "Alec H. Peterson" <ahp@hilander.com> the
public policy meeting last week in Memphis.
Not bad, but there's two specific things I'd add: 1. Entities should be able to trade in PA blocks as well, provided they are trading in at least one PI block. 2. The policy should explicitly state that no justification is required beyond that necessary to establish tenancy in the returned blocks. I'll wander over to ppml@arin.net, as it's apparently become more productive than it was in the past. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Mon, 14 Apr 2003, Stephen Sprunk wrote: > 1. Entities should be able to trade in PA blocks as well, provided they are > trading in at least one PI block. They can. I'm sure their provider will be happy to oblige, for a small fee. > 2. The policy should explicitly state that no justification is required > beyond that necessary to establish tenancy in the returned blocks. How do you perceive that as being different from what's there? > I'll wander over to ppml@arin.net, as it's apparently become more productive > than it was in the past. Oh, I wouldn't say that. -Bill
[ Cc ppml, Bcc nanog ] Thus spake "Bill Woodcock" <woody@pch.net>
On Mon, 14 Apr 2003, Stephen Sprunk wrote:
1. Entities should be able to trade in PA blocks as well, provided they are trading in at least one PI block.
They can. I'm sure their provider will be happy to oblige, for a small fee.
No, I mean that you should be able to trade in both PI and PA blocks for a single new PI block. The policy, as written, only allows trade-ins of PI blocks. See my replies to David Conrad in this thread.
2. The policy should explicitly state that no justification is required beyond that necessary to establish tenancy in the returned blocks.
How do you perceive that as being different from what's there?
I don't see any explicit reference to what justification is or isn't necessary. My fear is that the folks actually processing trade-in requests will insist on efficiency documentation (a la RFC2050) before proceeding. While I'd love to take your word that won't happen, why not make it part of the policy and eliminate any possible confusion? S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
They can. I'm sure their provider will be happy to oblige, for a small fee.
No, I mean that you should be able to trade in both PI and PA blocks for a single new PI block. The policy, as written, only allows trade-ins of PI blocks. See my replies to David Conrad in this thread.
Been there and done exactly that. After submitting a request to renumber a number of PA blocks and a small PI block into a /18 in order to achieve some aggregation, it was processed by ARIN almost instantly. On that occasion at least, they exercised good stewardship in not only address management, but helping the route table, an area which they have explicitly stated is somewhat at odds with address conservation. I was impressed.
My fear is that the folks actually processing trade-in requests will insist on efficiency documentation (a la RFC2050) before proceeding. While I'd love to take your word that won't happen, why not make it part of the policy and eliminate any possible confusion?
That's reasonable.
Could anybody with significant experience, comments, recommendations, etc. etc. (positive/negative) on the Engineering Toolset of SolarWinds email me off list. Much obliged. -- Bert hostmaster@nso.org Ft. Myers
As of this morning, neither DCA-ANS-01.INET.WWEST.NET nor SVL-ANS-01.INET.QWEST.NET no longer server up our two domains petsmart.com and statelinetack.com. If there is anyone from the Qwest DNS Group that can read this, this is a problem, please contact me offline... -Aaron Senior Network Engineer 623-587-2701 desk 480-495-2779 cell -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mark Borchers Sent: Tuesday, April 15, 2003 7:06 AM To: nanog@merit.edu Cc: Stephen Sprunk Subject: RE: Dealing with ARIN.. my experiences & tips
They can. I'm sure their provider will be happy to oblige, for a small fee.
No, I mean that you should be able to trade in both PI and PA blocks for a single new PI block. The policy, as written, only allows trade-ins of PI blocks. See my replies to David Conrad in this thread.
Been there and done exactly that. After submitting a request to renumber a number of PA blocks and a small PI block into a /18 in order to achieve some aggregation, it was processed by ARIN almost instantly. On that occasion at least, they exercised good stewardship in not only address management, but helping the route table, an area which they have explicitly stated is somewhat at odds with address conservation. I was impressed.
My fear is that the folks actually processing trade-in requests will insist on efficiency documentation (a la RFC2050) before proceeding. While I'd love to take your word that won't happen, why not make it part of the policy and eliminate any possible confusion?
That's reasonable.
On Tue, Apr 15, 2003 at 10:02:59AM -0700, Aaron D. Britt wrote:
As of this morning, neither DCA-ANS-01.INET.WWEST.NET nor SVL-ANS-01.INET.QWEST.NET no longer server up our two domains petsmart.com and statelinetack.com.
This is really not an operational issue worthy of a NANOG post.
If there is anyone from the Qwest DNS Group that can read this, this is a problem, please contact me offline...
I think there are a wide variety of addresses ending with "@qwest.net" that reach more Qwest people than NANOG. Try them. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RIRs should allow a member to voluntarily renumber several disparate allocations into a single prefix. The original allocations would be forfeit after a reasonable renumbering period, e.g. 6 months. If the member has at least one PI allocation, they should be allowed to combine it with PA allocations into a new, larger PI allocation.
<http://www.arin.net/policy/2002_6.html>
This proposal will be coming out for final call on ppml@arin.net shortly, slightly modified to address concerns raised on the mailing list and at the public policy meeting last week in Memphis.
Alec ARIN AC Member
Within my finite sphere of experience, they are quite accomodating to this type of numbers trade-in, even in the absence of the official policy.
On Mon, 14 Apr 2003, Stephen Sprunk wrote: > Let me throw in one policy I've been wanting for years, which would fix > most/all of Jeff's problems: > RIRs should allow a member to voluntarily renumber several disparate > allocations into a single prefix. So why are you so damned talkative now, but had nothing to say in defense of that policy when it got fillibustered in the PPML? -Bill
Thus spake "Bill Woodcock" <woody@pch.net>
So why are you so damned talkative now, but had nothing to say in defense of that policy when it got fillibustered in the PPML?
I proposed this policy years ago when ARIN first started up. After seeing the utter lack of concern ARIN had for members' opinions at that time, I gave up and spent my free time on more productive projects. Now that it appears ARIN is more receptive to input, I'm back on PPML. We'll see if it does any good. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
More importantly, a quick study in logic shows there should be no requirement for the existing space to meet RFC2050 requirements -- the space is already allocated. After the renumbering period there's no net damage to the IPv4 "shortage" since similar amounts of space would be assigned, but it would be a great help to the global routing system.
The problem is that PA space is questionable. As you stated, if the only way to do something one wants to do is to lie/cheat/steal/kill, many people will do it. Some of the "P" in the PA will break the rules in order to drive sales. So, the inherent assumption that a provider is already compliant is not a given, which strikes down the argument. I'ld advocate for mandatory compliance checking on each allocation request or biannually, whichever is more frequent. Of course, I'ld also advocate that it a provider is below 25% usage, that they have address space rescinded, including blocks not presently assigned to any RIR. If an entity can not be contacted for 2 compliance periods (for example, a swamp /24 to some long-dead company) that they be considered defunct, and the space rescinded. But, then again, I'm fairly liberal. I'm sure the more conservative among us (and those hanging onto former customer /24s, /8s, etc) would absolutely hate this, since they are getting something for nothing and don't like having to play by the same rules as the rest of us.
On Tue, 15 Apr 2003 bdragon@gweep.net wrote:
More importantly, a quick study in logic shows there should be no requirement for the existing space to meet RFC2050 requirements -- the space is already allocated. After the renumbering period there's no net damage to the IPv4 "shortage" since similar amounts of space would be assigned, but it would be a great help to the global routing system.
The problem is that PA space is questionable. As you stated, if the only way to do something one wants to do is to lie/cheat/steal/kill, many people will do it.
Can you quote an example of someone who was killed in the name of PA space?
Some of the "P" in the PA will break the rules in order to drive sales. So, the inherent assumption that a provider is already compliant is not a given, which strikes down the argument.
I'ld advocate for mandatory compliance checking on each allocation request or biannually, whichever is more frequent. Of course, I'ld also advocate that it a provider is below 25% usage, that they have address space rescinded, including blocks not presently assigned
even where over-allocation is concerned you cant seriously expect folks to renumber in order to give space back. renumbering has to be a no-no.
to any RIR. If an entity can not be contacted for 2 compliance periods (for example, a swamp /24 to some long-dead company) that they be considered defunct, and the space rescinded.
i assume dead space is recovered anyway? surely the provider isnt providing space and services to a company that is dead and not paying bills?
But, then again, I'm fairly liberal. I'm sure the more conservative
liberal compared to stalin maybe ;p
among us (and those hanging onto former customer /24s, /8s, etc) would absolutely hate this, since they are getting something for nothing and don't like having to play by the same rules as the rest of us.
you have a slightly different point here, i agree. theres a number of legacy /8s out there, they need fixing. i dont have any answers tho! Steve
: On Tue, 15 Apr 2003 bdragon@gweep.net wrote: : : > > More importantly, a quick study in logic shows there should be no : > > requirement for the existing space to meet RFC2050 requirements -- the space : > > is already allocated. After the renumbering period there's no net damage to : > > the IPv4 "shortage" since similar amounts of space would be assigned, but it : > > would be a great help to the global routing system. : > : > The problem is that PA space is questionable. As you stated, if the only way : > to do something one wants to do is to lie/cheat/steal/kill, many people : > will do it. : : Can you quote an example of someone who was killed in the name of PA space? I can name plenty who have done the other 3... scott
On Tue, 15 Apr 2003 bdragon@gweep.net wrote:
More importantly, a quick study in logic shows there should be no requirement for the existing space to meet RFC2050 requirements -- the space is already allocated. After the renumbering period there's no net damage to the IPv4 "shortage" since similar amounts of space would be assigned, but it would be a great help to the global routing system.
The problem is that PA space is questionable. As you stated, if the only way to do something one wants to do is to lie/cheat/steal/kill, many people will do it.
Can you quote an example of someone who was killed in the name of PA space?
Can you state with certainty that no one has been killed? (We could certainly go around that point circularly for awhile). I know I've wanted to kill some of my customers, even if I haven't actually followed through with it. in any event, I'll assume you accept the illustrative point by only taking on the severity of what people will stoop to.
Some of the "P" in the PA will break the rules in order to drive sales. So, the inherent assumption that a provider is already compliant is not a given, which strikes down the argument.
I'ld advocate for mandatory compliance checking on each allocation request or biannually, whichever is more frequent. Of course, I'ld also advocate that it a provider is below 25% usage, that they have address space rescinded, including blocks not presently assigned
even where over-allocation is concerned you cant seriously expect folks to renumber in order to give space back. renumbering has to be a no-no.
Why not?
to any RIR. If an entity can not be contacted for 2 compliance periods (for example, a swamp /24 to some long-dead company) that they be considered defunct, and the space rescinded.
i assume dead space is recovered anyway? surely the provider isnt providing space and services to a company that is dead and not paying bills?
what provider? a swamp /24 would have been allocated by InterNIC along with your single domain name. The domains, by virtue of a periodic reregistration process, are cleaned up. The swamp space isn't (yet).
But, then again, I'm fairly liberal. I'm sure the more conservative
liberal compared to stalin maybe ;p
among us (and those hanging onto former customer /24s, /8s, etc) would absolutely hate this, since they are getting something for nothing and don't like having to play by the same rules as the rest of us.
you have a slightly different point here, i agree. theres a number of legacy /8s out there, they need fixing. i dont have any answers tho!
As well as /16s, and /24s. A periodic communication of some kind is really needed to cull out the silent lost. Similarly those who are so far out of whack from the rest of us due to fortunate circumstance should be brought to something approaching in-line. As someone else mentioned, there should not be a MAX function on registry dues.
Steve
On Tue, 15 Apr 2003 bdragon@gweep.net wrote:
On Tue, 15 Apr 2003 bdragon@gweep.net wrote:
More importantly, a quick study in logic shows there should be no requirement for the existing space to meet RFC2050 requirements -- the space is already allocated. After the renumbering period there's no net damage to the IPv4 "shortage" since similar amounts of space would be assigned, but it would be a great help to the global routing system.
The problem is that PA space is questionable. As you stated, if the only way to do something one wants to do is to lie/cheat/steal/kill, many people will do it.
Can you quote an example of someone who was killed in the name of PA space?
Can you state with certainty that no one has been killed? (We could certainly go around that point circularly for awhile). I know I've wanted to kill some of my customers, even if I haven't actually followed through with it.
no .. you win!
in any event, I'll assume you accept the illustrative point by only taking on the severity of what people will stoop to.
Some of the "P" in the PA will break the rules in order to drive sales. So, the inherent assumption that a provider is already compliant is not a given, which strikes down the argument.
I'ld advocate for mandatory compliance checking on each allocation request or biannually, whichever is more frequent. Of course, I'ld also advocate that it a provider is below 25% usage, that they have address space rescinded, including blocks not presently assigned
even where over-allocation is concerned you cant seriously expect folks to renumber in order to give space back. renumbering has to be a no-no.
Why not?
you've not done this then i assume?
to any RIR. If an entity can not be contacted for 2 compliance periods (for example, a swamp /24 to some long-dead company) that they be considered defunct, and the space rescinded.
i assume dead space is recovered anyway? surely the provider isnt providing space and services to a company that is dead and not paying bills?
what provider? a swamp /24 would have been allocated by InterNIC along with your single domain name. The domains, by virtue of a periodic reregistration process, are cleaned up. The swamp space isn't (yet).
if its a direct allocation from arin then you have membership fees, if they arent paid surely thats an indication theres a problem? if its some sort of pre-arin stuff then we've jumped off-thread.
But, then again, I'm fairly liberal. I'm sure the more conservative
liberal compared to stalin maybe ;p
among us (and those hanging onto former customer /24s, /8s, etc) would absolutely hate this, since they are getting something for nothing and don't like having to play by the same rules as the rest of us.
you have a slightly different point here, i agree. theres a number of legacy /8s out there, they need fixing. i dont have any answers tho!
As well as /16s, and /24s. A periodic communication of some kind is really needed to cull out the silent lost. Similarly those who are so far out of whack from the rest of us due to fortunate circumstance should be brought to something approaching in-line.
hmm, if its dead then presumably you could achieve this by watching the routing table over a period of a few months and considering blocks older than a couple of years that are consistently not appearing to be dead and automatically reusable maybe? Steve
As someone else mentioned, there should not be a MAX function on registry dues.
Steve
On Tue, 15 Apr 2003 bdragon@gweep.net wrote:
On Tue, 15 Apr 2003 bdragon@gweep.net wrote:
no .. you win!
It isn't about winning or losing, but how you play the game :)
even where over-allocation is concerned you cant seriously expect folks to renumber in order to give space back. renumbering has to be a no-no.
Why not?
you've not done this then i assume?
I have, including once at breakneck speed, due to "circumstances" it isn't fun, much like writing reports, doing cost-analysis, and taking the garbage out aren't fun, but you do them anyways because they have to be done from time to time.
what provider? a swamp /24 would have been allocated by InterNIC along with your single domain name. The domains, by virtue of a periodic reregistration process, are cleaned up. The swamp space isn't (yet).
if its a direct allocation from arin then you have membership fees, if they arent paid surely thats an indication theres a problem?
if its some sort of pre-arin stuff then we've jumped off-thread.
Perhaps it was me, but somewhere along the road the pre-ARIN /8s were brought into the mix, which opened up (to me) the entire swamp including 128/2 and the swampy bits of 192/3.
you have a slightly different point here, i agree. theres a number of legacy /8s out there, they need fixing. i dont have any answers tho!
As well as /16s, and /24s. A periodic communication of some kind is really needed to cull out the silent lost. Similarly those who are so far out of whack from the rest of us due to fortunate circumstance should be brought to something approaching in-line.
hmm, if its dead then presumably you could achieve this by watching the routing table over a period of a few months and considering blocks older than a couple of years that are consistently not appearing to be dead and automatically reusable maybe?
I think some kind of contact method would be necessary. as others have and will point out, not all address space allocated under IANA is in/for use on the public Internet.
Steve
[ Cc ppml, Bcc nanog ] Thus spake <bdragon@gweep.net>
The problem is that PA space is questionable. As you stated, if the only way to do something one wants to do is to lie/cheat/steal/kill, many people will do it.
One could falsify efficiency documentation on your PI space as well; PA space isn't inherently more susceptible to fraud.
Some of the "P" in the PA will break the rules in order to drive sales. So, the inherent assumption that a provider is already compliant is not a given, which strikes down the argument.
ARIN's policies rely on the assumption that all SWIPs to customers are legitimate -- in practice if not in theory. If you are going to throw rocks at that assumption, you're going to have to redesign the whole RIR system.
I'ld also advocate that it a provider is below 25% usage, that they have address space rescinded, including blocks not presently assigned to any RIR.
There is currently no precedent for revoking any allocation made by an RIR, InterNIC, or IANA. While your intentions are probably good, the consequences of this are so staggering you'll never get consensus.
If an entity can not be contacted for 2 compliance periods (for example, a swamp /24 to some long-dead company) that they be considered defunct, and the space rescinded.
Bill Manning/ISI already has been working for several years now to reclaim unused address space.
But, then again, I'm fairly liberal. I'm sure the more conservative among us (and those hanging onto former customer /24s, /8s, etc) would absolutely hate this, since they are getting something for nothing and don't like having to play by the same rules as the rest of us.
There are significant legal obstacles to recovering fees from allocations made during the InterNIC days, and this would only be viable if we agreed that RIRs can revoke unpaid legacy allocations. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
participants (11)
-
Aaron D. Britt -
Alec H. Peterson -
bdragon＠gweep.net -
Bill Woodcock -
hostmaster -
Jeff McAdams -
Mark Borchers -
Richard A Steenbergen -
Scott Weeks -
Stephen J. Wilcox -
Stephen Sprunk