[arin-ppml] IPv4 Fragment Management policy proposal

Scott Leibrand scottleibrand at gmail.com
Wed Apr 28 17:44:03 EDT 2010


2010-1 is intended to prevent this for free pool addresses, and 8.3 
transfer policy disallows it for transfers.

Do you feel that either of those are insufficient?


On Wed 4/28/2010 2:38 PM, Owen DeLong wrote:
> At ARIN XXV, one of the discussions pointed out that under current
> ARIN policy, after IANA runout, a justified request for a /10 could
> (and would) be satisfied, if necessary, by issuing 1024 disjoint /20s.
> I believe there is a need for policy to prevent this kind of
> gathering of the last breadcrumbs by a small number of large
> entities. As such, I offer the following proposal for the discussion
> of the community.
> Owen
> 1.      Policy Proposal Name: IPv4 Fragment Management
> 2.      Proposal Originator
>         a.      name: Owen DeLong
>         b.      email: owen at delong.com <mailto:owen at delong.com>
>         c.      telephone: 408-890-7992
>         d.      organization: Hurricane Electric
> 3.      Proposal Version: 0.8
> 4.      Date: 2010-04-28
> 5.      Proposal type: New
>         new, modify, or delete.
> 6.      Policy term: Permanent
>         temporary, permanent, or renewable.
> 7.      Policy statement:
> Add the following to the NRPM as new sections et. seq.
> Each time ARIN approves an IPv4 request which it cannot
> satisfy from 4 or fewer bit-aligned blocks of free address
> space, ARIN shall notify the requestor that there is
> insufficient free address space to meet their request and
> shall offer the requestor their choice of the following
> alternatives:
> a. They can have the largest 4 available bit-aligned
> blocks of free addresses.
> b. This section reserved -- (in case we implement the
> waiting list for unmet requests policy)
> c. They can seek resources through the directed
> transfer policy in section 8.3 of the NRPM.
> 8.      Rationale:
> When the ARIN free pool begins to diminish, the free space
> will become fragmented into smaller and smaller remaining
> contiguous spaces. This policy attempts to ensure that a
> large number of remaining disjoint small blocks are not
> consumed by a single large request.
> While this policy could be regarded as unfair to larger
> entities, it is consistent with the safeguards adopted in
> section 8.3 which require an exact match or full fill
> style of resource transfer.  As such, I believe the policy
> is fair and in line with the consensus will of the community.
> 9.      Timetable for implementation: Immediate, although it has no
> actual effect until some time after IANA runout.
> _______________________________________________
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100428/1dcc2534/attachment-0001.html>

More information about the ARIN-PPML mailing list