[arin-ppml] Set aside round deux

[Hannigan, Martin]

And a minor correction please. I meant proposal 116 v. 109 when I referenced it.


On 7/26/10 4:37 PM, "cja at daydream.com" <packetgrrl at gmail.com> wrote:

Owen,

So do you feel that this is bad all around or just the minimum allocation unit needs to be changed to something smaller?  Others out there?  What are your thoughts regarding a minimum/maximum allocation size for this last /8?

----Cathy

On Mon, Jul 26, 2010 at 2:31 PM, Owen DeLong <owen at delong.com> wrote:
Marty,
        How do you expect anyone but the largest of the large and extra large
organizations to qualify for a /20 of IPv4 space under this proposal?

        This is a really interesting way to attempt to reserve the last /8 for use
only by the largest organizations ARIN serves, but, I really don't think that
is good policy.

Owen

On Jul 26, 2010, at 1:22 PM, Hannigan, Martin wrote:

>
>
> Hello PPML:
>
>
> Since it seemed to have been very helpful to vet the global policy idea on
> the list, I thought it might be helpful to use it to frame my non-support
> for 109. This is, just like the last time, very raw, but I expect to solicit
> some time during open policy hour to discuss a more polished version.
>
> A few points.
>
> - This idea takes us in the direction of actual transition
> - Define an acceptable use list
> - Seeks to address COSTS
> - Levels the playing field between small and large
> - Reserves an entire /8 for transition, not for business as usual
> - Counters the high priced "market" that is emerging by deferring it's need
>
> May not get us all the way through, but every month that we can avoid
> sending people to markets is a month of reduced costs IMHO. And it is about
> costs at this point. It's a given that it is going to happen.
>
> Too soon for "for" or "against", but most definitely open to feedback. Don't
> focus on the words, focus on the ideas. Feedback very much appreciated.
>
>
> --draft, group working comments removed for ease of read
>
> 1. Transition Pool
>
> ARIN will set-aside the final /8 allocated form the IANA to facilitate
> transition from IPv4 to IPv6. The resulting "transition pool" will become
> immediately available for allocations under this policy. This pool will be
> known as the "transition pool".
>
> 2. Minimum and Maximum Allocation Unit
>
> The minimum allocation unit will be a /20. The maximum allocation unit will
> be /15.
>
> 2. Allocation Method
>
> ARIN will determine and utilize the best method possible for allocations
> with the goal of maximizing what can be allocated balanced by minimum
> deaggregation.
>
> 3. Eligibility
>
> An applicant will become eligible to receive IPv4 addresses from this pool
> when they meet the following requirements:
>
> 1. Applicant will provide a written plan detailing how the addresses will be
> used and on what devices.
>
> 2. Previous allocations or assignments under this policy must continue to
> meet the justification requirements of this policy.
>
> 3. Must have applied for, been approved, received and be utilizing an ARIN
> allocated IPv6 allocation or assignment.
>
> 4. All allocations or assignments made under this policy must be efficiently
> utilized to a rate of 80%.
>
> 5. Applicant must demonstrate that no other allocations or assignments that
> they have received will meet their requirements.
>
> 6. Applicants must provide documentation that demonstrates that the
> addresses received under this policy will be used only on dual stack devices
> that will have both an IPv4 and IPv6 address that will both be reachable
> natively.
>
> 7. Be in compliance with Section 4, Acceptable Use of Addresses.
>
>
> 4. Acceptable Use of Addresses
>
> 1. A single IPv4 /32 for providers to assign to 6 to 4 NAT gateways for each
> each layer 3 contagious v6 only customer networks thereby enabling IPv4
> connectivity for an IPv6-only customer networks. Customers must not have
> available IPv4 addresses.
>
> 2. A single IPv4 /32 for providers to assign to 4 to 4 NAT gateways for each
> each layer 3 contagious v6 customer networks to deploy IPv4 RFC-1918 in
> addition to (and NOT instead of) IPv6 thereby enabling IPv4 connectivity for
> an IPv6-only customer networks.. Customers must not have available IPv4
> addresses.
>
> 3. Customer networks qualifying under 4.1 or 4.2 (above) may qualify for
> additional IPv4 address to meet multi-homing traffic engineering needs or to
> address stand-alone NAT devices as specified below:
>
> A. A single IPv4 /32 for each interconnect for each mult-homed layer 3
> contiguous customer network that requires traffic engineering. For example a
> network with two interconnects to a single upstream provider can get one
> IPv4 /32 for each of their two interconnects, and distribute their internal
> hosts between the two outside NAT addresses for traffic engineering.
>
> B. Customer networks that require stand-alone NAT devices (not integrated
> into their CPE router) qualify for enough IPv4 addresses to number the
> loopback addresses (if needed) for all edge routers that have one or more
> connections to a transit provider, enough IPv4 addresses to number each of
> the point-to-point links between those routers and their transit provider,
> as well as the point to point links between those routers and directly
> connected NAT appliances. As well as one IPv4 address for each of these
> directly connected NAT appliances.
>
>
> 4. Loopback addresses for edge routers that have one or more connections to
> transit providers and/or peers
>
> 5. Address for point to point links between edge routers and their transit
> providers [why does it need to be unique v. 1918?] [that is an interesting
> point... We use globally unique as a matter of not breaking routing by
> accident. I have to think about if it would be generally acceptable to use
> RFC-1918. Interesting question!]
>
> 7. A /32 for routers in a greenfield network that are dual stacked.
> [redundant to 3/5?] [this is not redundant... In this case I need an IPv4
> routerID to make BGP work. If I want to be a green-filed IPv6 transit
> provider I need one IPv4 address for each router]
>
> 8. /32 for public facing name servers, NTP servers, SMTP servers and Web
> servers which are dual stacked and reachable on IPv4 and IPv6 networks.
>
> 9. Dual stacked VPN aggregation ex. v6 -> v4 one IPv4 /32 per VPN aggregator
>
>
> 5. Reservation Forecasting
>
> An applicant may provide ARIN with a thirty-month forecast of IPv4 address
> need. ARIN will reserve the requested size in compliance with Section 2 and
> 3. When a reservation forecast is approved by ARIN, the applicant will then
> be authorized to draw down from the forecast quarterly. Prior to requesting
> reserved addresses, applicant will provide documentation to ARIN that they
> have maintained utilization requirements for previous allocation. If
> applicant fails to meet utilization requirements for two consecutive
> quarters, ARIN will cancel the reservation and return unused addresses to
> the pool.
>
>
> Example:
>
> Applicant applies to ARIN under this policy and submits a thirty-month
> forecast requesting a /16. Using criteria established in the NRPM and this
> policy, ARIN will determine if applicant is eligible and has need. If the
> applicant meets the requirements for the allocation, they will reserve a
> /16. The applicant will then be allocated 3/30th of the forecasted
> requirement in a CIDR block or equivalent number of IPv4 addresses. ARIN
> will round down allocations or assignments to the closest CIDR single block.
> Rounding errors will be applied to the last allocation of the last quarter
> of the thirty month period and allocated then.
>
>
> 6. Dual Stack Requirement
>
> Addresses from this pool may only be used on dual stack devices that are to
> be reachable via both IPv4 and IPv6 networks.
>
>
> 7. Application Frequency
>
> Applicants may apply for address space from the transition pool once per
> quarter. If an applicant has an existing thirty-month forecast that has been
> approved by ARIN, they are ineligible to apply for more address space until
> their reservation has been exhausted. If an applicant has had a reservation
> cancelled due to policy compliance issues including utilization, they are
> not eligble to apply for addresses.
>
>
> 8. Post Exhaustion Refresh
>> From the point of the issuance of the final /8 from the IANA, ARIN will
> dispose of all address space that it may receive using this policy.
>
> _______________________________________________
> PPML
> 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.

_______________________________________________
PPML
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/20100726/56de59f9/attachment.htm>