[arin-ppml] Set aside round deux

cja@daydream.com packetgrrl at gmail.com
Mon Jul 26 16:37:35 EDT 2010


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-0001.html>


More information about the ARIN-PPML mailing list