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

[Richard Jimmerson]

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 <jschil...@google.com<mailto:jschil...@google.com>>
Date: Friday, October 9, 2015 at 12:04 PM
To: Owen DeLong <o...@delong.com<mailto:o...@delong.com>>
Cc: "arin-ppml@arin.net<mailto:arin-ppml@arin.net>" 
<arin-ppml@arin.net<mailto:arin-ppml@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 
<o...@delong.com<mailto:o...@delong.com>> wrote:

On Oct 8, 2015, at 9:43 AM, Jason Schiller 
<jschil...@google.com<mailto:jschil...@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 
<o...@delong.com<mailto:o...@delong.com>> wrote:

On Oct 7, 2015, at 10:00 PM, Jason Schiller 
<jschil...@google.com<mailto:jschil...@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 a

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

[Jason Schiller]

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  wrote:
>
>> On Oct 8, 2015, at 9:43 AM, Jason Schiller  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  wrote:
>>>
>>> On Oct 7, 2015, at 10:00 PM, Jason Schiller  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 
>>> 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
>

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

[Randy Carpenter]

This is all getting complex, confusing, and is still encouraging ISPs to give 
out less than the recommended /48 to end users.

Why don't we just change policy so that every ISP gets an automatic IPv6 that 
approximates /32 IPv4 ~= /48 IPv6

Make it automatic, and at no additional cost. Also, make it the minimum, so 
that all ISPs have no reason not to hand out /48s.

If you have less than a /20, you get a /32
If you have a /20, you get a /28
If you have a /16, you get a /24
If you have a /8, you get a /16

Basically, aggregate all of the IPv4 resources, round up to the nearest single 
block, add 8 bits, then round to the nearest nibble.

If you need more, then it needs to be justified.

I've seen several cases of ISP with 100,000s or even millions of customers that 
have a /32 or similar. That doesn't do anyone any good. If and when they come 
to their senses, the result will be even more routes in the routing table, 
because they will have to go back and get more.

You could also just define the PAU as /48. The important part is that we make 
sure that there is no additional cost. IPv6 is plentiful enough that it 
shouldn't matter. If ARIN gives out N blocks of /20 instead of N blocks of /32, 
there should not be any financial impact. It is the same number of blocks.

thanks,
-Randy


- On Oct 9, 2015, at 12:04 PM, Jason Schiller jschil...@google.com wrote:

> 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  wrote:
>>
>>> On Oct 8, 2015, at 9:43 AM, Jason Schiller  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  wrote:

 On Oct 7, 2015, at 10:00 PM, Jason Schiller  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 

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

[Matthew Kaufman]

I'd support such an automatic allocation.

I'd support it even more if it was made available to legacy holders.

Matthew Kaufman

(Sent from my iPhone)

> On Oct 9, 2015, at 1:19 PM, Randy Carpenter  wrote:
> 
> 
> This is all getting complex, confusing, and is still encouraging ISPs to give 
> out less than the recommended /48 to end users.
> 
> Why don't we just change policy so that every ISP gets an automatic IPv6 that 
> approximates /32 IPv4 ~= /48 IPv6
> 
> Make it automatic, and at no additional cost. Also, make it the minimum, so 
> that all ISPs have no reason not to hand out /48s.
> 
> If you have less than a /20, you get a /32
> If you have a /20, you get a /28
> If you have a /16, you get a /24
> If you have a /8, you get a /16
> 
> Basically, aggregate all of the IPv4 resources, round up to the nearest 
> single block, add 8 bits, then round to the nearest nibble.
> 
> If you need more, then it needs to be justified.
> 
> I've seen several cases of ISP with 100,000s or even millions of customers 
> that have a /32 or similar. That doesn't do anyone any good. If and when they 
> come to their senses, the result will be even more routes in the routing 
> table, because they will have to go back and get more.
> 
> You could also just define the PAU as /48. The important part is that we make 
> sure that there is no additional cost. IPv6 is plentiful enough that it 
> shouldn't matter. If ARIN gives out N blocks of /20 instead of N blocks of 
> /32, there should not be any financial impact. It is the same number of 
> blocks.
> 
> thanks,
> -Randy
> 
> 
> - On Oct 9, 2015, at 12:04 PM, Jason Schiller jschil...@google.com wrote:
> 
>> 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  wrote:
>>> 
 On Oct 8, 2015, at 9:43 AM, Jason Schiller  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  wrote:
> 
> On Oct 7, 2015, at 10:00 PM, Jason Schiller  wrote:
> 
> I'm not sure I follow the impact of the change here.
> 
> Under current policy 

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

[Owen DeLong]

Every thing is already available to legacy holders if it is available to the 
rest of the community.

However, for any new resources, they will have to sign an RSA and their new 
resources will not be legacy.

Owen

> On Oct 9, 2015, at 3:14 PM, Matthew Kaufman  wrote:
> 
> I'd support such an automatic allocation.
> 
> I'd support it even more if it was made available to legacy holders.
> 
> Matthew Kaufman
> 
> (Sent from my iPhone)
> 
>> On Oct 9, 2015, at 1:19 PM, Randy Carpenter  wrote:
>> 
>> 
>> This is all getting complex, confusing, and is still encouraging ISPs to 
>> give out less than the recommended /48 to end users.
>> 
>> Why don't we just change policy so that every ISP gets an automatic IPv6 
>> that approximates /32 IPv4 ~= /48 IPv6
>> 
>> Make it automatic, and at no additional cost. Also, make it the minimum, so 
>> that all ISPs have no reason not to hand out /48s.
>> 
>> If you have less than a /20, you get a /32
>> If you have a /20, you get a /28
>> If you have a /16, you get a /24
>> If you have a /8, you get a /16
>> 
>> Basically, aggregate all of the IPv4 resources, round up to the nearest 
>> single block, add 8 bits, then round to the nearest nibble.
>> 
>> If you need more, then it needs to be justified.
>> 
>> I've seen several cases of ISP with 100,000s or even millions of customers 
>> that have a /32 or similar. That doesn't do anyone any good. If and when 
>> they come to their senses, the result will be even more routes in the 
>> routing table, because they will have to go back and get more.
>> 
>> You could also just define the PAU as /48. The important part is that we 
>> make sure that there is no additional cost. IPv6 is plentiful enough that it 
>> shouldn't matter. If ARIN gives out N blocks of /20 instead of N blocks of 
>> /32, there should not be any financial impact. It is the same number of 
>> blocks.
>> 
>> thanks,
>> -Randy
>> 
>> 
>> - On Oct 9, 2015, at 12:04 PM, Jason Schiller jschil...@google.com wrote:
>> 
>>> 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  wrote:
 
> On Oct 8, 2015, at 9:43 AM, Jason Schiller  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 

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

[Matthew Kaufman]

That is not necessarily true of the hypothetical automatic assignment discussed 
below

Matthew Kaufman

(Sent from my iPhone)

> On Oct 9, 2015, at 3:38 PM, Owen DeLong  wrote:
> 
> Every thing is already available to legacy holders if it is available to the 
> rest of the community.
> 
> However, for any new resources, they will have to sign an RSA and their new 
> resources will not be legacy.
> 
> Owen
> 
>> On Oct 9, 2015, at 3:14 PM, Matthew Kaufman  wrote:
>> 
>> I'd support such an automatic allocation.
>> 
>> I'd support it even more if it was made available to legacy holders.
>> 
>> Matthew Kaufman
>> 
>> (Sent from my iPhone)
>> 
>>> On Oct 9, 2015, at 1:19 PM, Randy Carpenter  wrote:
>>> 
>>> 
>>> This is all getting complex, confusing, and is still encouraging ISPs to 
>>> give out less than the recommended /48 to end users.
>>> 
>>> Why don't we just change policy so that every ISP gets an automatic IPv6 
>>> that approximates /32 IPv4 ~= /48 IPv6
>>> 
>>> Make it automatic, and at no additional cost. Also, make it the minimum, so 
>>> that all ISPs have no reason not to hand out /48s.
>>> 
>>> If you have less than a /20, you get a /32
>>> If you have a /20, you get a /28
>>> If you have a /16, you get a /24
>>> If you have a /8, you get a /16
>>> 
>>> Basically, aggregate all of the IPv4 resources, round up to the nearest 
>>> single block, add 8 bits, then round to the nearest nibble.
>>> 
>>> If you need more, then it needs to be justified.
>>> 
>>> I've seen several cases of ISP with 100,000s or even millions of customers 
>>> that have a /32 or similar. That doesn't do anyone any good. If and when 
>>> they come to their senses, the result will be even more routes in the 
>>> routing table, because they will have to go back and get more.
>>> 
>>> You could also just define the PAU as /48. The important part is that we 
>>> make sure that there is no additional cost. IPv6 is plentiful enough that 
>>> it shouldn't matter. If ARIN gives out N blocks of /20 instead of N blocks 
>>> of /32, there should not be any financial impact. It is the same number of 
>>> blocks.
>>> 
>>> thanks,
>>> -Randy
>>> 
>>> 
>>> - On Oct 9, 2015, at 12:04 PM, Jason Schiller jschil...@google.com 
>>> wrote:
>>> 
 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  wrote:
>> 
>> On Oct 8, 2015, at 9:43 AM, Jason Schiller  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 

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

[Owen DeLong]

Sure it is… There is nothing in ARIN policy ever that has made a distinction 
about legacy holders
or somehow excluded them from participating in or receiving any benefit of any 
ARIN policy if
they sign an RSA for their new resources.

Owen

> On Oct 9, 2015, at 3:43 PM, Matthew Kaufman  wrote:
> 
> That is not necessarily true of the hypothetical automatic assignment 
> discussed below
> 
> Matthew Kaufman
> 
> (Sent from my iPhone)
> 
>> On Oct 9, 2015, at 3:38 PM, Owen DeLong  wrote:
>> 
>> Every thing is already available to legacy holders if it is available to the 
>> rest of the community.
>> 
>> However, for any new resources, they will have to sign an RSA and their new 
>> resources will not be legacy.
>> 
>> Owen
>> 
>>> On Oct 9, 2015, at 3:14 PM, Matthew Kaufman  wrote:
>>> 
>>> I'd support such an automatic allocation.
>>> 
>>> I'd support it even more if it was made available to legacy holders.
>>> 
>>> Matthew Kaufman
>>> 
>>> (Sent from my iPhone)
>>> 
 On Oct 9, 2015, at 1:19 PM, Randy Carpenter  wrote:
 
 
 This is all getting complex, confusing, and is still encouraging ISPs to 
 give out less than the recommended /48 to end users.
 
 Why don't we just change policy so that every ISP gets an automatic IPv6 
 that approximates /32 IPv4 ~= /48 IPv6
 
 Make it automatic, and at no additional cost. Also, make it the minimum, 
 so that all ISPs have no reason not to hand out /48s.
 
 If you have less than a /20, you get a /32
 If you have a /20, you get a /28
 If you have a /16, you get a /24
 If you have a /8, you get a /16
 
 Basically, aggregate all of the IPv4 resources, round up to the nearest 
 single block, add 8 bits, then round to the nearest nibble.
 
 If you need more, then it needs to be justified.
 
 I've seen several cases of ISP with 100,000s or even millions of customers 
 that have a /32 or similar. That doesn't do anyone any good. If and when 
 they come to their senses, the result will be even more routes in the 
 routing table, because they will have to go back and get more.
 
 You could also just define the PAU as /48. The important part is that we 
 make sure that there is no additional cost. IPv6 is plentiful enough that 
 it shouldn't matter. If ARIN gives out N blocks of /20 instead of N blocks 
 of /32, there should not be any financial impact. It is the same number of 
 blocks.
 
 thanks,
 -Randy
 
 
 - On Oct 9, 2015, at 12:04 PM, Jason Schiller jschil...@google.com 
 wrote:
 
> 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  wrote:
>>> 
>>> On Oct 8, 2015, at 9:43 AM, Jason Schiller  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 

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

[Jason Schiller]

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.

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.


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  wrote:
>
> On Oct 7, 2015, at 10:00 PM, Jason Schiller  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 
> 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  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
 

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

[Owen DeLong]

> On Oct 8, 2015, at 9:43 AM, Jason Schiller  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  wrote:
>> 
>> On Oct 7, 2015, at 10:00 PM, Jason Schiller  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 
>> 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  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 

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

[james machado]

On Thu, Oct 8, 2015 at 2:59 PM, Owen DeLong  wrote:
>
>> On Oct 8, 2015, at 9:43 AM, Jason Schiller  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  wrote:
>>>
>>> On Oct 7, 2015, at 10:00 PM, Jason Schiller  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 
>>> 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  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

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

[Owen DeLong]

> On Oct 7, 2015, at 10:00 PM, Jason Schiller  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  > 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 > 
> 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 

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

[John Springer]

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  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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Owen DeLong]

I suspect that is the intent, but as I read the policy, I believe the actual 
effect would be to cause the PAU to be counted as a /56 no matter how small a 
block you stuck your downstreams with.

The current language already makes the PAU the smallest block you issue and 
requires you to justify all space issued to customers in units of that smallest 
size.

The changes to 2.16.1 do seem to create a situation where allocations smaller 
than /56 cannot be counted for utilization at all. It also opens the flood 
gates for assigning multiple PAUs to a site without requiring any justification 
for the multiple PAUs vs. a single one.

As such, I believe the text as written is actually contrary to solving the 
stated problem description is it allows (for example) an ISP to decide that 
their PAU is /56, issue /56s to customers that they want to treat as 
second-class citizens, and issue /48s to their higher paying customers without 
any additional justification for the larger blocks (or even something larger 
than a /48), thus eliminating the incentives codified into the original policy 
that require an ISP to treat all end-sites roughly the same or provide strong 
justification for the allocations and assignments that are larger than the 
smallest ones.

I remain opposed to the policy on that basis. I would not be opposed to a 
policy which met the stated intent of this policy, but as currently written, I 
do not believe this proposal does so.

Owen

> On Sep 25, 2015, at 20:48 , Mike Hammett <a...@ics-il.net> wrote:
> 
> Is this policy codifying that a /56 is the minimum acceptable assignment to 
> an end-user and that if I assign less, I'm not allowed to come back to the 
> IPv6 tough until I've filled up my space with whatever smaller than /56 
> allocations I decide to make? Not saying right or wrong, just seeking 
> clarification. 
> 
> Maybe it's more appropriate under a different group than policy, but I'm new 
> here, so this is the best spot I've seen so far (other than maybe 
> ARIN-2015-1). Anything about X-Small ISPs and initial IPv6 allocations for 
> them in the works? I know of many ISPs (personally, I know of dozens, though 
> I'm sure several hundred of them exist in NA) that are X-small under IPv4 and 
> don't have any IPv6 due to the added expense of moving up to small. yeah, 
> it's not a large sum of money, but with increasing regulatory and network 
> burdens, "bonus" areas like IPv6 are cast aside. Smaller blocks, smaller 
> fees, I dunno, I'll let someone else figure out what's best there. Just 
> trying to find ways of getting the little guys represented and brought into 
> IPv6.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com <http://www.ics-il.com/>
> 
>  <https://www.facebook.com/ICSIL> 
> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> 
> <https://www.linkedin.com/company/intelligent-computing-solutions> 
> <https://twitter.com/ICSIL>
> 
> Midwest Internet Exchange
> http://www.midwest-ix.com <http://www.midwest-ix.com/>
> 
>  <https://www.facebook.com/mdwestix> 
> <https://www.linkedin.com/company/midwest-internet-exchange> 
> <https://twitter.com/mdwestix>
> From: "ARIN" <i...@arin.net>
> To: arin-ppml@arin.net
> Sent: Wednesday, September 23, 2015 3:54:13 PM
> Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments
> 
> 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 hav

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

[Brian Jones]

I do not think this policy is unsound or unfair, however I do not believe
it will have the intended effect. Network Operators should have the ability
to subnet their address blocks as they see fit without being penalized when
they come back for more addresses. It seems that as long as the allocated
space has been utilized they should be able to successfully request more.

I agree that a /48 makes reasonable sense as an assignment block size for
end sites. It also makes more sense to limit the number of smaller routed
block sizes to keep Internet routing tables from unreasonable growth.

--
Brian

On Thu, Sep 24, 2015 at 3:37 PM, John Springer 
wrote:

> Hi PPML,
>
> There have been a number of public discussions regarding the ins and outs
> of IPV6 subnet allocation. One such starts here:
> http://mailman.nanog.org/pipermail/nanog/2014-October/070339.html
>
> My recollection of the outcomes of these discussions is a sort of rough
> consensus that /48 is a good idea and indeed, many of the calculations used
> to evaluate what size of V6 block an org should request, start with that
> assumtion.
>
> ARIN (speaking as myself, not a member of any group and roughly
> paraphrasing someone more authoritative than I) does not dictate what you
> do with addresses after the allocation has been received. In some cases,
> ARIN looks at what you do with addresses when you come back for more and
> might not give them to you depending on what choices you have made.
>
> That is what this Draft Proposal seeks to do.
>
> I think it is clear that we can do that. Should we?
>
> And if you have an opinion of no, are you able to say because it is
> technically unsound or unfair and partial?
>
> John Springer
>
>
> On Wed, 23 Sep 2015, ARIN 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@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
>>
>> ___
> PPML
> You are receiving this 

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

[Mike Hammett]

Is this policy codifying that a /56 is the minimum acceptable assignment to an 
end-user and that if I assign less, I'm not allowed to come back to the IPv6 
tough until I've filled up my space with whatever smaller than /56 allocations 
I decide to make? Not saying right or wrong, just seeking clarification. 

Maybe it's more appropriate under a different group than policy, but I'm new 
here, so this is the best spot I've seen so far (other than maybe ARIN-2015-1). 
Anything about X-Small ISPs and initial IPv6 allocations for them in the works? 
I know of many ISPs (personally, I know of dozens, though I'm sure several 
hundred of them exist in NA) that are X-small under IPv4 and don't have any 
IPv6 due to the added expense of moving up to small. yeah, it's not a large sum 
of money, but with increasing regulatory and network burdens, "bonus" areas 
like IPv6 are cast aside. Smaller blocks, smaller fees, I dunno, I'll let 
someone else figure out what's best there. Just trying to find ways of getting 
the little guys represented and brought into IPv6. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "ARIN" <i...@arin.net> 
To: arin-ppml@arin.net 
Sent: Wednesday, September 23, 2015 3:54:13 PM 
Subject: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments 

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@arin.net). 
Unsubscribe or manage your mailing list subscription at: 
http://lists.arin.net/mailman/listinfo/arin-ppml 
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Owen DeLong]

> On Sep 24, 2015, at 15:41 , John Springer  wrote:
> 
> Hi Owen,
> 
> On Thu, 24 Sep 2015, Owen DeLong wrote:
> 
>> 
>>> On Sep 24, 2015, at 12:37 , John Springer  wrote:
>>> 
>>> And if you have an opinion of no, are you able to say because it is 
>>> technically unsound or unfair and partial?
>> 
>> This isn?t really necessary, John. A proposal must be fair, technically 
>> sound, and have support of the community in order to be adopted.
>> 
>> Just because it is technically sound and/or fair does not mean that the 
>> community must support it.
>> 
>> People are free to reject a policy for any reason, though I admit a bias in 
>> favor of at least some rationale for rejection.
>> 
>> Owen
>> 
> 
> Oh, I think it is necessary for the community to comment on all three 
> criteria, Owen, and I thank you for inviting them to express support or 
> opposition.
> 
> BTW, do you support or oppose the Draft Policy?
> 
> John Springer


I think comments on all three criteria are welcome.

I don’t think anyone in particular is required to comment on any of the areas 
they don’t choose to.

Personally, I think that this policy is unnecessary and contrary to its stated 
intent as written, but I need to review it more thoroughly to see if I misread 
something.

Owen

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[John Springer]

Hi PPML,

There have been a number of public discussions regarding the ins and outs 
of IPV6 subnet allocation. One such starts here:

http://mailman.nanog.org/pipermail/nanog/2014-October/070339.html

My recollection of the outcomes of these discussions is a sort of rough 
consensus that /48 is a good idea and indeed, many of the calculations 
used to evaluate what size of V6 block an org should request, start with 
that assumtion.


ARIN (speaking as myself, not a member of any group and roughly 
paraphrasing someone more authoritative than I) does not dictate what you 
do with addresses after the allocation has been received. In some cases, 
ARIN looks at what you do with addresses when you come back for more and 
might not give them to you depending on what choices you have made.


That is what this Draft Proposal seeks to do.

I think it is clear that we can do that. Should we?

And if you have an opinion of no, are you able to say because it is 
technically unsound or unfair and partial?


John Springer

On Wed, 23 Sep 2015, ARIN 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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[John Springer]

Hi Owen,

On Thu, 24 Sep 2015, Owen DeLong wrote:




On Sep 24, 2015, at 12:37 , John Springer  wrote:

And if you have an opinion of no, are you able to say because it is technically 
unsound or unfair and partial?


This isn?t really necessary, John. A proposal must be fair, technically sound, 
and have support of the community in order to be adopted.

Just because it is technically sound and/or fair does not mean that the 
community must support it.

People are free to reject a policy for any reason, though I admit a bias in 
favor of at least some rationale for rejection.

Owen



Oh, I think it is necessary for the community to comment on all three 
criteria, Owen, and I thank you for inviting them to express support or 
opposition.


BTW, do you support or oppose the Draft Policy?

John Springer
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[ARIN]

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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.