[NAIPR] ARIN Proposal

Fri Jan 24 17:51:53 EST 1997

(Note:  I do *NOT* make it a practice of replying to private mail
back to a mailing list.  However, I feel the point is sufficiently
important that we may wish to explicitly re-address it).  I also
probably botched my commentary, which *should* have left the impression
that "the historic context is important because it mostly works, and
you need to at least understand it to intelligently discuss what
its shortcomings are....

On Fri, 24 Jan 1997 11:36:53 PST, Jerry Scharf said:
> How many times do we have to say that the allocation policy is controlled by
> the IANA (well kindof mostly...) and documented RFC2050. That is not open for
> debate; what is used in the Internic, RIPE and APNIC now will be used by ARIN.
> What is open for debate is how ARIN is organized and how costs are recovered
> for doing this work.

Well, the only problem with RFC2050 is that saying "We comply with RFC2050"
leaves a few policy issues open.  The basic problem is that 2050 is only
a BCP document, and not a full set of guidelines.  As you read the following,
remember that the registry has to make judgement calls on some things, and
the registry is free within the context of RFC2050 to say "yes" or "no"
to some things.  Much of the recent discussion has in fact pivoted around
the fact that some things within RFC2050 are either not fully discussed,
or arguably less than perfect.  Also, remember that RFC2050 is a
"Best Current Practice", and *not* a Standard - as such, it *is* subject
to being modified if somebody suggests a Better Way.

For instance, in section 2.1 (point 4), it talks about "slow-start" allocation
for ISP's.  As has been pointed out, this may *NOT* be a "best practice"
given the growth of multihomed small-medium sized ISPs.  Feel free to
please flame *EVERYBODY* who participated in that discussion (if you already
have, apologies for suggesting it ;)

In particular, point 4 says:
       .....
       registry.  Please note that projected customer base has little
       impact on the address allocations made by the parent registries.
       Initial allocation will not be based on any current or future
       routing restrictions but on demonstrated requirements.

This may need to be relaxed a bit - unless you are going to *ENFORCE*
a requirement that *EVERY* start-up ISP *WILL* go through a renumbering
phase (as when they start up, they will only qualify for a /24 - when they
get big enough for a /19, they *will* get hit).  Remember - they can't
get a *routable* /19 until they can qualify.  Should make trying to
get multihomed quite challenging.  A "Denninger Commando" could probably
make a strong case that in a geographic locality where there exist
a number of ISP's who are *already* (a) multihomed and (b) grandfathered,
a requirement that prohibits a startup ISP from multihoming until
they grow (when not multihoming is a competitive weakness), is
an unfair restraint of free trade.

Is that to be an explicit intention?

And yes, I see part (b) in section 3, discussing if "the organization is
multi-homed with no favored connection".  This only says that you can't even
*talk* to the regional registry unless you qualify under the rules.  It doesn't
say anything about the registry rejecting your request because you're not big
enough, multihomed or not.

Section 3.1 talks about "25% immediate utilization rate".  This means that to
get that magic /19, you need 2,000 addresses *in use*.  And Section 2.1, point
7, says you should use DHCP or similar when at all possible, which means that
(for instance, making up numbers) if 90% of your users use DHCP and dynamic
SLIP/PPP, and only 10% are active at a given time, you'll need 20K customers or
so before you get big enough for that /19 so you can multihome effectively.
Especially in smaller, rural areas, it may be *quite* difficult to get to
20K customers if you drop everybody's access when your ONE upstream
provider loses their connectivity, if your 3 local competitors who got
grandfathered in are multihomed and don't lose until 2 or 3 upstream
providers simultaneously Lose Big.

I think we need some verbiage someplace regarding multi-homing and its
requirements.  Note that said verbiage can easily be written without
violating anything in RFC2050. As a straw-man proposal, just saying
the following as policy would probably suffice to cover most of
these points:

"ARIN will allocate a /19 to an ISP, even if their current requirements
only warrant a /22, if the ISP submits a business plan indicating
a move to multihoming within the next ?? months".

Would this address most of the issues re: multihoming?

Also, RFC2050 et al never really *do* address the issue of recovery of CIDR
space - as has been noted, "current practice" is that some large ISP's will
cheerfully announce blocks that came along with a customer who got them from a
competitor.  This can be Particularly Bad if for instance, ISP1 gets a CIDR
block,  splits it 4 ways, gives it to 4 customers.  2 customers leave for ISP2,
who starts announcing their part of the original CIDR block.  ISP1 reports the
half block as "freed".  What does ARIN do in this situation?  Do they register
the block on behalf of ISP2 when they see an announcement for it?  Do they
blindly re-assign the block?  Do they wait for ISP2 to *tell* them?  Is there
a procedure planned for dealing with this?

--
                                Valdis Kletnieks
                                Computer Systems Engineer
                                Virginia Tech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/naipr/attachments/19970124/1a59ac24/attachment.sig>