[ppml] Policy Proposal 2007-6 - Staff Assessment

[Owen DeLong]

On Apr 19, 2007, at 2:11 PM, Azinger, Marla wrote:

> Dave thanks for keeping discussion going.
>
> I oppose this policy for the following reasons.
>
I will restate my support for this policy since it's been several  
months...
> 1. From experience with spammers, I feel this could actually make  
> things easier on them as pointed out in an earlier string or just  
> simply give them another avenue.

 From my experience with spammers, although this might make things a  
little easier on them,
the reality is that they already have an easy enough time getting  
addresses, I just don't see
this making a significant difference to spammers.
> 2. I tend to believe that a rush of some size will be brought on if  
> this were to pass and that could lead to other negative effects  
> such as depletion and maybe more aggregation than what was already  
> needed, just because they can.
>
I think you mean de-aggregation, but, I'll point out that the most of  
the other RIRs have been
issuing /24s for quite a while without encountering either of these  
effects on a meaningful
scale.
> 3.One of the rationale from this proposal is "In addition, by  
> keeping the PI allocation size for multi-homed
> organizations at /22, organizations seeking PI space that don't  
> meet the requirements may be encouraged to exaggerate their address  
> usage. This is something that should clearly not be encouraged."  I  
> disagree with this rationale and here is why:
>
> I don't see proof of the exaggeration scam working or that it is  
> done alot.  For example, just this week I had a customer who tried  
> to do this with ARIN and they were told no and to get IP addresses  
> from me.  When I reviewed what they had, they could only justify  
> the use of a /23 and the rest of it was obvious "exaggeration".  So  
> I don't see the exaggeration thing working out so much.  They may  
> try it, but that doesn't mean they get away with it.  And another  
> point, if they were exaggerating /22's or let say /21's then what  
> is to stop others from exaggerating /24's?  And honestly, it would  
> be allot easier to exaggerate your way through a /24 justification  
> than it would be a /22.  Also, I like to think that the number of  
> people willing to "exaggerate" is smaller than those who are honest  
> (yes I know, fire away, rose colored glasses).
>
I am sure that it is possible to exaggerate in a manner that will  
pass muster with ARIN.
I am sure it has happened.
I do not have any data on how often this does or does not occur.
I suspect nobody does.

I will say that I know of networks who had choices of topologies and  
other
implementation details where they could have been implemented using
a smaller number of addresses, but, in order to have enough utilization
to meet ARIN minimums, chose more IP-utilization heavy designs.  This
can be done within the guidelines.  Having /24s available, or even /23s
would make this less likely to occur.

The bottom line is that if you have a significant number of VPNs to  
customers,
partners, suppliers, or vendors, or have any other need for your  
addresses to be
configured in a significant number of devices you do not control, the
inability to get portable addresses is a major issue.  So much so  
that it
would, in many cases I can think of, justify $90,000 it would take to
buy 300 extra servers if that's what it took to qualify for a /22 in an
environment that only needs a /24.

> So in a quick summary, I don't think the reasons for this proposal  
> outweigh potential spam issues or a run on IPv4 space and its  
> related issues and just may lead to an increase of those willing to  
> exaggerate justification because it is suddenly easier.
>
In summary, I think that both the SPAM and IPv4 run claims are red  
herrings with no
evidence to support them.  Given that this practice is already  
accepted in most of the
other RIRs without having either of these effects, I would say there  
is some evidence
to the contrary.

Owen

-------------- 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/20070419/c9a23e2f/attachment.p7s>