[arin-ppml] Set aside round deux

[cja@daydream.com]

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/b89115e0/attachment.htm>