[arin-ppml] Multihomed Microallocations

[Owen DeLong]

The primary reason for applying as an ISP organization rather than an  
end-user
organization is to be able to reassign blocks to your customers in a  
manner which
can be recorded via SWIP.  The minimum amount of space subject to SWIP  
is
a /28, which there are only 16 in a /24 and 32 in a /23. That makes no  
allowance
for the ISP's internal infrastructure.

I'm not opposed to extending this ability to ISPs if there is a need,  
but, at present,
I think that when you are talking about reassignable space, a /21 is  
already a
pretty small chunk. If I'm wrong about this, I welcome people to set  
me straight.
(It won't be the first time).

> 4.4 IPv4 Allocations and Assignments to Small Multihomed Organizations
>
> 4.4.1 Section 4.4 specifies criteria for allocating /23 and /24 IPv4
> address blocks to end users and ISPs where the requesting organization
> is multihomed with multiple Internet vendors but does not meet the
> minimum usage criteria for address allocation or assignment under
> Sections 4.2 and 4.3.
>
> 4.4.2 Except as specified in section 4.4, the requesting organization
> must also meet all criteria for receiving addresses specified in
> section 4.2 if an ISP or section 4.3 if an end user.
>
> 4.4.3 Criteria for allocation or assignment
>
> 4.4.3.1 The requesting organization must hold exactly one AS number
> and must already announce IPv4 addresses to the Internet via BGP using
> its AS number.
>
I'm not sure I understand the need to exclude the following classes of
organizations from this policy:

1.	Organizations which are obtaining their AS number and IPv4 resources
	at the same time as part of a start-up process.

2.	Organizations which may wish to utilize their ability to qualify  
under
	IPv4 policy for obtaining IPv6 space, but, which have no desire to
	obtain or implement IPv4.

Noteworthy, it also excludes organizations holding more than one AS  
number,
but, that is presumably to discourage fragmentation of the allocation/ 
assignment.

> 4.4.3.2. The requesting organization must announce IPv4 addresses to
> the Internet via at least two distinct Internet vendors.
>
> 4.4.3.3. The requesting organization must spend at least $8000/year on
> the Internet services in 4.4.3.2.
>
I think this requirement is absurd.  First of all, as the price of  
transit continues
to fall (currently transit is available for as little as $2/mbps on 95th
%ile billing) requiring some arbitrary price per year
(here $333/provider/month) could easily become anachronistic.
Second, in general ARIN policy tries to avoid dictating business
models or practices, and, requiring paid transit at all (vs. settlement
free peering as a viable counter-example) seems odd.

[snip]
>
> 4.4.3.5. The requesting organization must agree to withdraw any other
> BGP routes it announces from the BGP table within 6 months of
> receiving an allocation or assignment under section 4.4. If the
> organization continues to receive IP addresses from its ISPs, those IP
> addresses will be single-homed within the ISP's larger aggregate
> announcement.
>
6 months might be  a bit hasty here.  I think current ARIN address
replacement policies allow a longer timeframe and I think this
should be consistent.

> 4.4.3.6. If the requesting organization fails to announce the
> allocation or assignment received under section 4.4 to the Internet
> using its AS number for at least 4 months total within a service year,
> the allocation or assignment is revoked and returned to ARIN.
>
Does this mean that ARIN is expected to monitor such announcements?
Is there a defined test point which is considered valid from which the
routes must be visible? By what objective mechanism and criteria
can this actually be measured?

> 4.4.3.7. If the requesting organization already holds IPv4 addresses
> directly from ARIN, from any other RIR or legacy addresses, the
> organization must agree to renumber out of those addresses and
> surrender them to the appropriate RIR within 6 months of receiving an
> allocation or assignment under section 4.4.
>
See above comment on 4.4.3.5

> 4.4.3.8. The requesting organization agrees to return the allocation
> or assignment received under section 4.4 to ARIN within 6 months of
> receiving another allocation or assignment from any RIR.
>
See above comment on 4.4.3.5

>
> Q. $8000? What's that all about?
>
> A. The best available estimate of the systemic cost of carrying a
> route in the Internet backbone table is around $8000/year. See
> http://bill.herrin.us/network/bgpcost.html for the cost estimate.
> If you're going to play in the backbone, you should really be putting
> more money into the system than you're taking out. If you have two
> $600 T1's then you're spending nearly twice that anyway. This  limits
> the folks who want to multihome their $50 DSL and cable modems.
>
Depending on where you measure this $8,000/year, it also could
eliminate folks who connect via exchange points or live in carrier
hotels and get inexpensive transit by other perfectly legitimate
means. I understand the theory here, but, in my opinion, it is not
the role of ARIN policy to dictate economics or business practices.

[snip]


> Besides, the $8k rule will probably turn out to be a non-operative
> part of the policy. Companies providing $50 DSL service are
> disinclined to set up BGP sessions with their customers anyway. I
> include it in the name of caution so that we're proof against a deluge
> of multihomed cable-modem users but I expect that with some experience
> under our belts we'll find that we can safely submit a follow-on
> policy proposal that removes the $8k requirement.
>
This is the best reason of all to strike the requirement.  It's  
unnecessary
and any place it would have effect is probably unintended.
>
>
> Q. Does this proposal affect IPv6 allocations and assignments?
>
> A. It does not appear to impact ISP allocations whose criteria is
> spelled out in NRPM section 6.5.1.1. It does impact end user
> assignments under NRPM section 6.5.8.1. End users who qualify for
> addresses under this policy will also be qualified for an IPv6 /48.
>
However, it also precludes a network from qualifying under this
policy and deploying IPv6 without IPv4 resources deployed.

While this may not be a significant issue today, it does shorten
the potential valid lifespan of this policy.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090803/be0f6102/attachment.htm>