[ppml] Policy Proposal 2007-6 - Staff Assessment
ipgoddess at gmail.com
Mon Apr 16 18:39:06 EDT 2007
I oppose this policy.
First, I believe there is no better way to chew through the remainder
of the v4 space faster than to pass this policy.
Second, I support staff comments about spammers using this policy for
abuse of networks. In my experience, miscreants of this sort prefer
multiple /24s for their 'businesses' to force spam hunters to play
whack a mole with the blacklisting of space. A _former_ customer of
mine had more than 30 different business names, all with different
points of contact and physical addresses. Because we were the
upstream, we were notified of his violations of our AUP. If the only
contact were the miscreant himself, he would not have been held
accountable. Spammers would adore directly assigned space for this
For the good of the Internet, this policy must not be passed.
On 4/13/07, David Williamson <dlw+arin at tellme.com> wrote:
> I'll second the comment that it's great to get these assessments in
> advance of the meeting. Thanks!
> I wanted to take a moment to respond to the staff comments on this
> one. Comments inline.
> On Fri, Apr 13, 2007 at 02:21:49PM -0400, Member Services wrote:
> > 1. There is very little qualification criteria which could lead to
> > policy abuse by spammers. These entities could create many different
> > accounts over time as their existing space gets blacklisted or becomes
> > otherwise unusable.
> Do spammers take the time to become multihomed and then apply for IP
> space? If they do, I'm sure they can find a way to qualify under the
> existing policy for a /22. I'm not sure I understand the actual risk
> here. It seems to me that this could already be a problem, actually.
> Perhaps a process to identify or report spammers would help this
> problem, but I'm not convinced that spammers actually try to get valid
> IP space from RIRs. Do we (staff and or community) have any data on
> this possibility?
> > 2. This could significantly increase the number of requests for
> > ARIN services thereby requiring additional Registration Services
> > Department and Financial Services Department staff.
> This is true. It is likely that a small multi-homed enterprise would apply
> for space under this policy rather than applying for space via an ISP.
> > 3. Policy applies only to end users which could be perceived as
> > unfair to ISPs. This could also lead to potential abuse of the policy
> > if ISPs apply as end users for single /24 IPv4 address block.
> I respectfully disagree with the first sentence entirely. Existing
> policy is heavily biased towards ISPs, and is rather unfair for smaller
> entities that have a critical business need to be multi-homed, but wish
> to avoid being semi-permanently attached to a single ISP due to the
> need for address space. Indeed, the current lack of fairness is part of
> the desire to change the policy.
> On the second point - I agree that this could be an issue. I suspect
> it could be an issue now...there's nothing to stop an ISP from applying
> for a /22 as an end user, outside of the risk of getting caught by staff.
> > 4. It is unclear exactly how an organization can qualify for a /24
> > IPv4 address block under this policy. It appears that NRPM section
> > 4.3.3, Utilization rate, requires 25% immediate, 50% within 1 year,
> > would be the justification criteria. However, NRPM section 188.8.131.52,
> > Reassignments to multihomed downstream customers, indicates that an ISP
> > can reassign a /24 IPv4 address block without regard to planned host
> > counts as long as the customer is multi-homed. The question here is
> > does this policy allow ARIN to qualify a requestor for a /24 IPv4
> > address block based solely on multi-homing or should host counts also be
> > taken into account?
> Existing policy, as written, refers to section 4.3.3. That doesn't
> change with the proposed policy. ISPs can feel free to reassign a PA
> /24 via whatever policy they choose, but direct (PI) assignments should
> still be under the guidelines listed in 4.3.3, regardless of the
> minimum assignment size. There is explicitly no change in that.
> > 5. The policy does not address requests for more than one /24 IPv4
> > address block for multiple sites.
> My intention for this issue is that this is handled in the same way
> that multiple /22 requests are handled now. Is the request justified?
> There's no change in how this would be handled, outside of the
> differences in minimum assignement size.
> > 6. NRPM Section 4.4, Micro-allocation, should remain as is since it
> > is a policy section essential for micro-allocation for critical
> > infrastructure related requests.
> I'm happy to concede this point, and change the policy appropriately.
> I'd like more (as in any) community input on this point. To some
> extent, the IPv4 micro-allocation section is irrelevant if this policy
> is approved. On the other hand, it may be useful to explicitly call
> out the allocation policy for critical infrastructure. What that
> infrastructure is defined to be is an interesting question, but beyond
> the scope of the current proposal. More opinions solicted!
> Thanks again for the opportunity to get some of this discussed in
> advance of the meeting!
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
More information about the ARIN-PPML