[arin-ppml] Multihomed Microallocations

[Owen DeLong]

On Aug 4, 2009, at 5:56 AM, William Herrin wrote:

> On Mon, Aug 3, 2009 at 11:43 PM, Owen DeLong<owen at delong.com> wrote:
>> 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.
>
> Hi Owen,
>
> Lots of comments. I'll try to take them one at a time.
>
> The way I see it, there is no compelling reason to pre-suppose what
> the ISP's needs are. If he needs a /21 and can document that need,
> he'll surely ask for a /21. If he's a co-op serving a neighborhood,
> maybe he only needs a /24.
>
You again miss my point.  A co-op serving a neighborhood who only
needs a /24 will not likely need to SWIP portions of said /24, so,
does not need to register with ARIN as an ISP and pay the (much
higher) ISP fee schedule instead of the end-user fee schedule
($100/year).

I tend to think that such a small ISP is thoroughly unlikely to pay
fees they don't need, and, as such, think that there are not likely
to be ISPs that would fall into this policy.


>
>> 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.
>
> These folks are not excluded; they're just given extra work. Instead
> of merely claiming they're going to multihome as they start up, they
> have to actually do it. 24 hours after they first announce the ISP /24
> they can apply for an ARIN /24 and ARIN is pretty zippy about
> completing allocations.
>
Again, this seems absurd to me.  ARIN already asks for copies of
transit contracts to prove multihomed status on existing policy. I think
that is adequate.
>
>> 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.
>
> That only applies to end users and is, IMHO, a defect in the IPv6
> policy. The appropriate place to correct it is in the IPv6 policy but
> the AC will have to actually carry such a proposal to a meeting and
> seek consensus before that can happen.
>
It's not currently a defect.  The existing IPv6 policy does just fine in
this area for end users. The only barrier on this for ISPs is the 200
site requirement which I am strongly in favor of eliminating, but,
which is still controversial. I think that number will get relaxed in
the near future, but, probably not eliminated.

In any case, an organization which qualified for an ISP IPv4
allocation under existing policy would at that point count as an
existing known ISP in the ARIN region.

>> Noteworthy, it also excludes organizations holding more than one AS  
>> number,
>> but, that is presumably to discourage fragmentation of the  
>> allocation/assignment.
>
> My point of view was that if you're holding more than one AS number
> then you're already past the point where you should be seeking
> allocations and assignments below the existing minimums.
>
There are lots of reasons for holding multiple AS numbers that have
almost nothing to do with the size of your network.

>
>> 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.
>
> I'm open to altering 4.4.3.3 or dropping it entirely if folks feel
> it's unwanted and unneeded. But I'd offer two points:
>
> 1. The existing minimums are a harmful and backwards way of applying a
> limit on how much money you have to spend to participate. We know that
> routing slots are an expensive resource, so why not tackle that issue
> more directly instead of placing odd technical requirements that hit
> it only indirectly?
>
I guess we'll just agree to disagree here.

> 2. The number isn't arbitrary; it's based on the only available
> estimate of the cost of BGP routing which for all its faults has
> actually been reviewed by a professional cost analyst. It could become
> anachronistic over time, but so what? Like any ARIN policy its subject
> to update at need.
>
We've already been through my issues with your cost analysis of a BGP
routing table slot, and, again, I suppose we should agree to disagree
there as well.

>
>
>> 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.
>
> If the consensus is 12 months I'm fine with moving it there.
>
>
>> 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?
>
>> From my "implementation notes" towards the end of the rationale  
>> section:
>
> Verifying that there's a BGP announcement is trivial: go to any of the
> hundreds of looking glasses. For the four-month rule, staff may want
> to let it be practiced in the breach for now. That is, don't go out
> and look unless someone complains. Writing software that actively
> checks for it can be part of the address recovery strategy after
> depletion.
>
There are lots of reasons that lots of routes are in one looking glass
and not others. Go to any looking glass creates the potential for
lots of controversy as recipients verify against one looking glass
while ARIN verifies against another and the complainer(s) verify
against yet a third view of a routing table.
>
> As for how you'd write the software down the road, getting copies of
> various table views is not particularly hard. A number of researchers
> currently do it. If the route isn't in any of them then whatever the
> registrant is doing, it isn't what the policy intended.
>
So ARIN should spend resources keeping some rolling >4-month
historical view of the routing table and build software to validate
that a particular prefix was/was not there during a given period?

>
>
>> 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.
>
> You can go to Vegas, stay in the discounted rooms in the casino hotels
> and play the quarter slots. You can also sit at the high stakes table,
> but if you do you have to ante up.
>
> BGP on the backbone is the Internet's high stakes table. Arranging for
> your connectivity costs to rise to $8k/year is always trivially done.
> Instead of counting computers, I suggest using your willingness to
> ante up to determine whether you're allowed to sit at the table.
>
> Of course, if you can somehow justify a /22 without spending at least
> $8k per year on connectivity then more power to you.
>
You can justify a /22 by purchasing something north of 500 nodes or
creating a justification for something north of 500 addresses on some
smaller number of nodes.

While I won't enumerate them here, there are lots of ways to justify
multiple addresses per node. Combine that with some creative
subnetting, and, artificially creating the need for a /22 isn't  
particularly
hard.

> Besides, if you live in a carrier hotel, you're paying for cross
> connects or access to the peering switch. That's generally not cheap
> and is very obviously part of the connectivity costs.
>
Depends on the carrier hotel, actually.  All the world is not Equinix
or Core Site.

>
>> 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.
>
> That's not a defect with this policy proposal per se. Rather it's a
> defect with the IPv6 policy for end users which should be addressed
> there. Here it's just a red herring like the spammer issue was for
> proposal 2007-6.
>
I suppose we can agree to disagree here. It does, actually impact
ISP allocations.  As soon as a person qualifies for a /24 under this
policy as an ISP, it would immediately convert them to a known
ISP in the ARIN service region and make them eligible to receive
a /32 of IPv6 in addition to their IPv4 /24. While I'm all for removing
unnecessary barriers to multi-homing, I think giving an IPv6 /32
to every user that justifies a /24 as an ISP opens up a serious
hole in policy.

Further, it could be construed (although I don't think it likely) that
you need to (under this policy) return your IPv4 resources to get
IPv6 resources within 6 months since it does not make allowance
for IPv6 resources to be treated separately.

> This particular policy proposal need not outlive IPv4.
>
But it will unless it is cancelled exactly at IPv4 runout or before.
The former is unlikely to be possible and the latter is not, in my
opinion, desirable.

Owen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090804/f79aa956/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090804/f79aa956/attachment.p7s>