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

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.

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

<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

Thus spake "Alec H. Peterson" <ahp@hilander.com>

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

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

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

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

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

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

[ Cc ppml, Bcc nanog ]

Thus spake "Bill Woodcock" <woody@pch.net>

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

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

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.