[arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments

Mon Oct 12 11:42:26 EDT 2015

Hello Jason,

Thank you for your inquiry regarding ARIN staff review of IPv6 customer reassignments as utilization.

To begin, we have not reviewed many requests for additional IPv6 address space from ISPs, to date. Most 2nd requests from ISPs to ARIN involve a declaration that their previous block (usually a /32 or /36) had not been utilized yet, but now that they are actively involved in their deployment they realize the /32 or /36 was not large enough. This results in a new review from ARIN staff for a larger allocation size for the organization.

More specific to your questions, we do have some limited experience with reviewing requests for additional IPv6 address space from ISPs. In those cases we always consider a /48 assignment to a customer as 100% utilized. In the case an ISP mixes /48s and /56s to customers, they typically state they issue the /56s from specific /48s (either in general, or per market area). In those cases we consider the /48s from which they issue the /56s to be 100% utilized. In cases that the ISP chooses to only assign /56s to customers, we consider any /56 they assign to a customer 100% utilized.

Warm regards,

Richard Jimmerson
CIO & Interim Director of Registration Services
American Registry for Internet Numbers

From: Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>>
Date: Friday, October 9, 2015 at 12:04 PM
To: Owen DeLong <owen at delong.com<mailto:owen at delong.com>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments

Can ARIN staff please comment?

If an ISP give out a mix of /48 and /56 which of the following is true:

A. each unique customer end site given a /56 counts as a single /56 at
100% utilized
     and each unique customer end site given a /48 counts as 256 /56s
at 100% utilized

B. each unique customer end site given a /56 counts as a single /56 at
100% utilized
     and each unique customer end site given a /48 counts as one /56
at 100% utilization
        unless there is specific justification why each /48 customer
needs more than 256 /64s

If B, then how strong does said justification have to be for example
do any of the following work:

1. We give all customers of type X a /56 and of type Y a /48.
2. all customers with a /48 said a /56 wasn't enough
3. we give /56 or /48 based on which box they check on the install survey
4. customer xyz said they plan to have 300 subnets in the next 10 years,
    customer abc said they have 16 sub-nets per building,
       each build is 4 geographical zones, and each zone has 4
subnets, student, staff, guest, wifi
      They have 20 buildings
    customer def said ...

___Jason

On Thu, Oct 8, 2015 at 5:59 PM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:

On Oct 8, 2015, at 9:43 AM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> wrote:

Owen,

You left out the part where you have to justify issuing that many /56s to each of those large customers.

I believe if an ISP gives N number of /64s to a single end-site
transit customer, so long a N < 65537 it is justified under ARIN
policy.

I don’t think that is true under the policy as written.

So for an ISP that assigns a mix of /48 and /56 no additional
justification is required to count all of the /56s given to a /48
sized customer.

That is not the way the policy is written. Staff may be misinterpreting it that
way (wouldn’t be the first time), but that is not the way it is written.

The PAU is the unit of measure for ALL of your utilization. You get a blanket
justification for up to a /48 as your PAU, but if you choose a smaller PAU, then
you have to justify any site issued more than one PAU based on its need for
more than one PAU.

Owen

6.5.4. Assignments from LIRs/ISPs

Assignments to end users shall be governed by the same practices
adopted by the community in section 6.5.8 except that the requirements
in 6.5.8.1 do not apply.

6.5.8.2. Initial assignment size

Organizations that meet at least one of the initial assignment
criteria above are eligible to receive an initial assignment of /48.

I think the final point that you agree with is the meet of the
proposal... you don't get to count any utilization by customers if
they take smaller than a /56.

__Jason

__Jason

On Thu, Oct 8, 2015 at 1:40 AM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:

On Oct 7, 2015, at 10:00 PM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> wrote:

I'm not sure I follow the impact of the change here.

Under current policy if an ISP assigns only /48s to each customer, then I
count the number of customer and consider than many /48s as fully utilized.

Under current policy if an ISP assigns only /56s to each customer, then I
count the number of customer and consider than many /56s as fully utilized.

Under current policy if an ISP assigns a mix of /48s to each large customer,
and /56s to each small customer
then I count the number of small customer and consider than many /56s as
fully utilized and,
I count the number of large customers time 256 and count that many /56s as
fully used.
(this means unused /56s out of a /48 are counted against you thus
discouraging mixed sizes).

You left out the part where you have to justify issuing that many /56s to
each of those large customers.

Under current policy if an ISP assigns only /60s to each customer, then I
count the number of customer and consider that number divided by 16 as the
number of  /56s as fully utilized.

Well, actually, you just count everything as /60s in this case under current
policy.

Under the proposed policy only the last case changes.

Under the proposed policy if an ISP assigns only /60s to each customer, then
those customers having a /60 (smaller than a /56) are not counted as
utilized by the ISP.

Correct.

Owen

Is that correct?

In general I am not opposed to discouraging ISPs from giving out smaller
than a /56, unless the customer specifically requests a small block.

___Jason

On Mon, Sep 28, 2015 at 11:35 AM, John Springer <springer at inlandnet.com<mailto:springer at inlandnet.com>>
wrote:

Thanks, Matt

This is precisely the subject on which I hoped to get community feedback.

John Springer

On Sat, 26 Sep 2015, Matthew Petach wrote:

OPPOSED

How I subdivide and allocate addresses
internally and downstream is not a matter
for the community to vote on; that's between
me and my customers.

Matt

On Wed, Sep 23, 2015 at 1:54 PM, ARIN <info at arin.net<mailto:info at arin.net>> wrote:

Draft Policy ARIN-2015-10
Minimum IPv6 Assignments

On 17 September 2015 the ARIN Advisory Council (AC) accepted
"ARIN-prop-224
Minimum IPv6 Assignments" as a Draft Policy.

Draft Policy ARIN-2015-10 is below and can be found at:
https://www.arin.net/policy/proposals/2015_10.html

You are encouraged to discuss the merits and your concerns of Draft
Policy 2015-10 on the Public Policy Mailing List.

The AC will evaluate the discussion in order to assess the conformance
of this draft policy with ARIN's Principles of Internet Number Resource
Policy as stated in the PDP. Specifically, these principles are:

   * Enabling Fair and Impartial Number Resource Administration
   * Technically Sound
   * Supported by the Community

The ARIN Policy Development Process (PDP) can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)

## * ##

Draft Policy ARIN-2015-10
Minimum IPv6 Assignments

Date: 23 September 2015

Problem Statement:

ISPs may believe that they have an incentive to obtain smaller blocks
than
they really need, and once they receive their allocation may
subsequently
issue blocks smaller than their customers may need in the future. This
policy seeks to encourage the correct behavior by reiterating the
smallest
reasonable sub-allocation size and by discounting any space which has
been
subdivided more finely from any future utilization analysis.

Policy statement:

Modify section 2.15 from "When applied to IPv6 policies, the term
"provider
assignment unit" shall mean the prefix of the smallest block a given ISP
assigns to end sites (recommended /48)." to "When applied to IPv6
policies,
the term "provider assignment unit" shall mean the prefix of the
smallest
block a given ISP assigns to end sites. A /48 is recommended as this
smallest block size. In no case shall a provider assignment unit for the
purpose of this policy be smaller than /56."

Modify section 2.16.1 from "A provider assignment unit shall be
considered
fully utilized when it is assigned to an end-site" to "A provider
assignment
unit shall be considered fully utilized when it is assigned in full (or
as
part of a larger aggregate) to a single end-site. If a provider
assignment
unit (which shall be no smaller than /56) is split and assigned to
multiple
end-sites that entire provider assignment unit shall be considered NOT
utilized."

Comments:
Timetable for implementation: IMMEDIATE
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto: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<mailto: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<mailto:info at arin.net> if you experience any issues.

--
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006<mailto:Schiller|NetOps|jschiller at google.com|571-266-0006>

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.

--
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006<mailto:Schiller|NetOps|jschiller at google.com|571-266-0006>

--
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006<mailto:Schiller|NetOps|jschiller at google.com|571-266-0006>
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto: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<mailto: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/20151012/e7179642/attachment.htm>