Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Owen DeLong]

> On Apr 13, 2020, at 08:55 , Andrew Dul  wrote:
> 
> David, Thanks for your comments.   
> 
> On 3/26/2020 4:08 PM, David Farmer wrote:
>> I support this policy as written. 
>> 
>> However, I recommend a minor editorial change and a small change to the 
>> policy;
>> 
>> 1. I would prefer to not use "smaller" or "less" when referring to /24 or 
>> longer prefixes, such use is somewhat ambiguous, this has been discussed 
>> many times on PPML.
> Noted.
>> 
>> 2. I really like the idea of automatically increasing the IPv6 allocation to 
>> /36 when the IPv4 allocation increases beyond /24. How about also 
>> automatically increasing the IPv6 allocation to /32 when the IPv4 allocation 
>> increases beyond /22?
> The goal of this policy is to create IPv6 allocation sizes such that a 
> current IPv4 organization which is currently 3X-small can obtain an IPv6 
> allocation without their fees going up.  Today this issue only occurs with 
> 3x-small.  If we were to implement this other change I believe this would 
> cause the text to move beyond the current problem statement.  
> 

I don’t entirely agree. The goal of the /36 policy was very similar to the goal 
here for /40s. Prior to the implementation of the /36 policy, the situation was 
similar.

As such, I do think it makes sense to extend the auto-bump language up to /32 
as part of this policy. TBH, the only reason it isn’t already there for /36s 
IMHO is that we didn’t think of it at the time.
> I will also like to note, that this issue could also be remedied by the board 
> adopting a small change to the fee schedule such that the 3x-small IPv6 
> holdings do not force a change in category for 3x-small organizations. This 
> would cause 3x-small organization's fees to be primarily determined by their 
> IPv4 holdings not their IPv6 holdings.
> 
Yep… And I hope they’ll finally do something about this, but let’s see what 
happens. I think this policy proposal is a good backstop to that.

> While the community doesn't have purview over fees we have input into that 
> process.  If this is something that we would strongly like to prefer as a 
> solution to this problem.  We can make this as a strong suggestion to the 
> board for their consideration.
> 
I believe this has been communicated to the board on more than one occasion.

Owen

> Andrew
> 
> 
> 
>> 
>> Thanks
>> 
>> On Tue, Mar 24, 2020 at 12:22 PM ARIN mailto:i...@arin.net>> 
>> wrote:
>> Draft Policy ARIN-2020-3: IPv6 Nano-allocations
>> 
>> Problem Statement:
>> 
>> ARIN's fee structure provides a graduated system wherein organizations
>> pay based on the amount of number resources they consume.
>> 
>> In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or 
>> smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36), 
>> its annual fees will double from $250 to $500/year.
>> 
>> According to a Policy Experience Report presented by Registration 
>> Services to the AC at its annual workshop in January 2020, this 
>> represents a disincentive to IPv6 adoption with a substantial fraction 
>> of so-situated ISPs saying "no thanks" and abandoning their request for 
>> IPv6 number resources when informed of the impact on their annual fees.
>> 
>> This can be addressed by rewriting subsection 6.5.2(b). Initial 
>> Allocation Size to allow allocation of a /40 to only the smallest ISPs 
>> upon request, and adding a new clause 6.5.2(g) to cause an automatic 
>> upgrade to at least a /36 in the case where the ISP is no longer 3X-Small.
>> 
>> Reserving /40s only for organizations initially expanding into IPv6 from 
>> an initial sliver of IPv4 space will help to narrowly address the 
>> problem observed by Registration Services while avoiding unintended 
>> consequences by accidentally giving a discount for undersized allocations.
>> 
>> Policy Statement:
>> 
>> Replace the current 6.5.2(b) with the following:
>> 
>> b. In no case shall an LIR receive smaller than a /32 unless they
>> specifically request a /36 or /40.
>> 
>> In order to be eligible for a /40, an ISP must meet the following 
>> requirements:
>>   * Hold IPv4 direct allocations totaling a /24 or less (to include zero)
>>   * Hold IPv4 reassignments/reallocations totaling a /22 or less (to 
>> include zero)
>> 
>> In no case shall an ISP receive more than a /16 initial allocation.
>> 
>> Add 6.5.2(g) as follows:
>> 
>> g. An LIR that requests a smaller /36 or /40 allocation is entitled to 
>> expand the allocation to any nibble aligned size up to /32 at any time 
>> without renumbering or additional justification.  /40 allocations shall 
>> be automatically upgraded to /36 if at any time said LIR's IPv4 direct 
>> allocations exceed a /24. Expansions up to and including a /32 are not 
>> considered subsequent allocations, however any expansions beyond /32 are 
>> considered subsequent allocations and must conform to section 6.5.3. 
>> Downgrades of any IPv6 allocation to less than a /36 are not permitted 
>> 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Owen DeLong]

> On Apr 19, 2020, at 08:33 , Fernando Frediani  wrote:
> 
> On 19/04/2020 05:07, Owen DeLong wrote:
>> 
>> Right… IETF designed a good architecture and then came under pressure from a 
>> bunch of people with an IPv4 mindset and given the modern state of the IETF 
>> decided to just punt on the whole thing rather than waste more time on an 
>> argument where people were determined to do what they were going to do 
>> anyway. RFC 6177 is more of a cop-out than a legitimate standards document.
> We cannot just choose the RFCs we will follow from those we like and 
> disregard those which we don't. Imagine if vendors start to do the same !

The RFC you are holding out as gospel states that it is a BCOP, not a standards 
track document.

It also supports /48s while admitting that other choices are available.

Your characterization of my attitude is not correct, sir.

> Since it correctly (in my view) does putting that /48 for residential 
> customers should be treated as an exception therefore no RIRs should have to 
> adapt their policies to it. If ISPs assign /48 to these customers in 
> exceptional basis (not as default) then they would have less or none of of 
> the problems discussed here.
> 

It does NOT make /48s for residential customers an exception. Please show any 
language which does so. It states that longer than /48s are possible without 
structural harm to IPv6 itself. That’s as far as it goes.

You’re also wrong about the nature of the problem being discussed.

ISPs cannot under current policy obtain an allocation smaller than a /36. The 
policy language here would make /40s available (on an exceptional basis).

As such, the concern is not to turn reduced price /40s into an incentive for 
bad addressing policy. You may think that the bad addressing policy I advocate 
avoiding is good address policy, but, that doesn’t change the nature of the 
initial problem in any way and is orthogonal to it.

> 
> 
>> 
>> There’s absolutely noting in RFC6177 that says /48s should not be given out 
>> to residential customers. It punts it to the operational community and says 
>> it really shouldn’t
>> be up to the IETF. That’s generally true, but that does come with a 
>> responsibility that the operational community doesn’t arbitrarily create 
>> negative impacts without good
>> reason.
> One of the main points of the document, if not the most, is that /48 is no 
> longer the default and not recommended as well. Therefore if it still 
> possible to assign to a residential customer it should then be considered an 
> exception not a normal thing as the others.
> Let me quote an important part of it within section 2: "Hence, it is strongly 
> intended that even home sites be given multiple subnets worth of space, by 
> default.  Hence, this document still recommends giving home sites 
> significantly more than a single /64, but does not recommend that every home 
> site be given a /48 either.”

That’s _NOT_ what it says.

It says that /48 no longer needs to be a one-size-fits-all default.

It goes no further than that. It does not advocate for longer prefixes, it 
merely says that they could be acceptable or desirable in some cases and that 
the decision is left to the operational community and no longer a matter for 
the IETF.

> Furthermore at the time of the write of the document it also mentions: "Since 
> then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE], and RIPE [RIPE-ENDSITE] 
> have revised the end site assignment policy to encourage the assignment of 
> smaller (i.e., /56) blocks to end sites.". Although some of these might have 
> been retired in their manuals it is possible to notice the spirit of  the 
> change RFC6177 brings, and is still valid.
> 
ARIN has never had a policy that encouraged the assignment of smaller blocks to 
end sites. Currently ARIN most definitely has policy language that is intended 
to (admittedly subtly) encourage the assignment of /48s to end sites.

Owen

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Owen DeLong]

> On Apr 19, 2020, at 02:16 , JORDI PALET MARTINEZ via ARIN-PPML 
>  wrote:
> 
> LACNIC and AFRINIC have similar problems in the fee structure that doesn’t 
> incentivize the right deployment of IPv6. I’ve already made proposals to the 
> relevant boards to change that (it is not a matter of policies in those 
> cases).
>  
> Many management departments of ISPs make the numbers about the right prefix 
> for customers, not according to technical reasons, but to:
> By default, I get a /32 without justification (in all the other RIRs), done, 
> this must work for any number of customers. Even if I give them a single /64 …
> I want to make sure that the “cost” of each customer prefix is as lower as I 
> can.

True.


> 
> I think we should do this:
> The cost of “every” /48 out of a /40 must be proportional to the cost of 
> “every” /48 out of a /40, /36, /32 and so on. It makes a lot of sense that as 
> larger is the block that you get from ARIN, the proportional cost of each /48 
> gets cheaper and cheaper. You can do the same “proportionality” with each 
> /128, /64, /56, or whatever. It is not related to the size of the prefix you 
> provide, just having some symmetry.
> Right one in ARIN, if you assume that you’re using a /48 for each customer 
> you pay for each /48 out of each /40, 0,97656 USD, out of a /36 0,12207 USD, 
> in the case of the /32 0,01526, and in the case of the /28 0,00191 USD. I 
> think the “jump” in between each category and the following ones is not good, 
> especially for the smaller ISPs.

We already have this effectively.

For every 16x increase in number of /48s, your fees double, so your cost per 
/48 goes down by 87.5% each time you increase the size of your allocation by 
one nibble.

> The fee structure for IPv4, needs to be “disconnected” from the IPv6 one. 
> IPv4 must become more expensive. IPv6 must become cheaper.

Unfortunately this isn’t economically sustainable…

RIRs are not-for-profit organizations that are (supposedly) operating on a 
cost-recovery basis. If you make IPv4 artificially more expensive, you have 
legal problems.

If you make IPv6 artificially less expensive, you have economic problems.


> If an ISP is doing a right addressing plan and provides the justification for 
> it, even if it is providing /48 to every customer (including residential 
> customer) that should be supported. In fact, I always tell my customers, you 
> must go for /48 and make persistent prefixes to customers (unless they move 
> to a different location). RIPE-690 provides explanations for that.

That’s great… It’s really the best way to do things.
 
> However, the problem is probably better resolved by the board, making a 
> better fee structure than by a policy. Policy may help to facilitate the 
> usage of /48, but if we also change the fee structure it will be much logic.

I don’t think there is anyone, including those of us who are advocating for the 
policy who disagrees here. Unfortunately, so far, our repeated attempts to get 
the bard to address this have not resulted in a useful resolution, so now we 
look at policy as the art of the possible.
 
> The case about $CABLECO it is clearly a *BAD* designed addressing plan. I 
> still see lots of people doing *terribly bad* addressing plans with IPv6, and 
> there is no need for that. You can still provide a /48 for each customer, 
> even for millions of customers, and still not *waste* a lot of addresses and 
> no require a complex interior routing setup. Many documents and trainings do 
> a really really bad work in that. I’ve started several months ago, to write a 
> BCOP for telling people how this can be done correctly, but I’d not the 
> sufficient time/tranquility to finish it. Hopefully I can do it soon (happy 
> to get in touch, in private, with other people that is interested in 
> contributing to it).

I wouldn’t say it’s a *BAD* designed addressing plan so much as a combination 
of unnecessarily lazy pragmatism and failure to consider longer-term 
implications.
 
> I believe it is rare the case where an ISP may need /16, but because they 
> need to justify it, and I’m sure ARIN will be stricter with a justification 
> for a /16 or /20 than for a /32, I think this restriction should not be put 
> in place. If there is a single case, we must support it, otherwise, we are 
> asking that ISP to provide customers a smaller block that what he will like 
> to do.

Will it be rare? Of course, as it should be. Are there ISPs who should have no 
trouble justifying a /16 or even several /16s? Absolutely. I can think of 
probably 3 or 4 in the US alone that I have no trouble envisioning getting at 
least 8 if not 16 /16s.

Point is, however, if you extrapolate that to the rest of the world, the US is 
roughly 5% of world population so 20x that is still only 80 /12s given out to 
mega-ISPs.
 
> Giving each “human” (not household) a /48 is perfectly valid. There is no 
> IPv6 scarcity. I’ve done this numbers several times, 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[David Farmer]

On Sun, Apr 19, 2020 at 4:20 PM John Santos  wrote:

>
> On 4/19/2020 3:08 PM, David Farmer wrote:
>
>
> On Sun, Apr 19, 2020 at 12:28 PM John Santos  wrote:
>
>> Is there any way to ensure that an ISP requesting a /40 has fewer than
>> 250 customers, so they can assign each a /48 in order to be eligible for
>> the smallest allocation at commensurate cost with a /24 of IPv4?
>>
> I don't think there is anything ARIN can reasonably do to require that
> 3X-Small ISPs have fewer than 250 customers. However, I'll note that even
> 3X-Small ISPs probably wants to grow their business, eventually moving them
> into the 2X-Small ISP category. Once they have something like 150 to 200
> customers they should be able to justify an additional /24 moving them into
> the 2X-Small ISP category.* Further, even for an ISP with 150 to 200
> customers the additional $250 in ARIN fees annually shouldn't be a
> significant roadblock to their growth. *So, I think the natural
> incentives for the growth of their business will be sufficient to regulate
> this issue, and I don't think we need to micromanage this issue
> through policy.
>
> If the bolded statement is true, why did 26 out of 30 3X-Small ISPs elect
> not to double their fees?  I posit they all have significantly less than
> 150 to 200 customers to spread the cost over, and their customers are
> extremely cost-sensitive.  If they have, say, 150 customers on  average,
> the increased cost would be less than 14 cents per month.  If they only
> have 10 customers, then the annual ARIN fees for each customer would double
> from $25 to $50.
>
> It would be useful to hear from some of these 26 nano-ISPs about what
> their customer base is and why they are so cost-sensitive.  I suspect most
> of us techies are completely oblivious to the real-world concerns of these
> customers and that they aren't just being incredible cheapskates.  As in
> "$25, that won't even pay for a decent meal" vs. "$25, I could feed my
> family for a week!"
>
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
>
>
You asked, "If the bolded statement is true, why did 26 out of 30 3X-Small
ISPs elect not to double their fees?" I speculate because most of the
3X-Small ISPs that elected to not double their fees to get IPv6 have less
than 150 to 200 customers.

You asked, "Is there any way to ensure that an ISP requesting a /40 has
fewer than 250 customers". I'm suggesting that we don't need to worry about
that because once they exceed somewhere between 150-200 users, nature will
take its course, they will want to ensure they can continue to expand and
they will get an additional /24 of IPv4 moving them to the 2X-Small
category.  In this case, they are moving into the 2X-Small category because
they want to continue to expand their customer base, not because they want
to deploy IPv6, these are significantly different business cases.

As you point out if they are 3X-Small regardless of the size of their
customer base they don't want to double their fees to deploy IPv6 and they
shouldn't have too. I think we agree. I'm simply pointing out that once
they exceed 150 to 200 users they will want to ensure they can continue to
expand and are likely to get another /24 of IPv4 doubling their fees as a
result of their desire to ensure they can expand and not because they want
to deploy IPv6. Further, this policy will also automatically expand their
IPv6 allocation to /36 as a result of their desire to expand.

Thanks

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[JORDI PALET MARTINEZ via ARIN-PPML]

Hi Chris,

 

I guess you missed this at the end of my previous email:

 

https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis-02. I need to update 
it!

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 19/4/20 21:32, "ARIN-PPML en nombre de Chris Woodfield" 
 escribió:

 

I’ll admit to having skimmed some of this thread, so apologies in advance if 
I've missed prior discussion of the point below.

 

The guidance against assigning /48s by default described in RFC6177 made sense 
at the time, particularly for an individual residential subscriber site, given 
the assumption that a residential site would rarely, if ever, have a second 
layer of L3 forwarding beyond the broadband router - that is, each /64 within 
the customer’s allocation would be attached to the edge gateway (i.e. multiple 
VLANs, WiFi SSIDs with L3 separation, etc.) In that world, allowing 65K unique 
/64s gateways to exist on a home broadband router was rightly seen as 
unnecessarily wasteful, regardless of sparse addressing design patterns. As is, 
even the 256 /64 prefixes in the /56 I can route to my broadband edge device 
seems like overkill, and I’d like to think I’m much savvier than the typical 
residential subscriber :)

 

That said, RFC8273, published 6 years after 6177, now recommends that instead 
of assigning individual /128s to hosts within a shared /64, prefix delegation 
should be utilized instead to assign a /64 *per host* by default within an IPv6 
network. This practice unlocks the ability for any end host to become a 
downstream “virtual” L3 router, allowing individually addressed software 
components to be uniquely addressed within a host (obvious candidates here 
would be virtual machines and docker containers, but also individual servers or 
clients living on the host), all numbered from a /64 with a known physical* 
location for policy/security purposes.

 

Given this recommendation, I believe it absolutely makes sense now to 
standardize as best practice the default assignment of a /48 to even 
residential subscribers, given that IETF-codified best practices now recommend 
exactly that two-layer routing model that the lack of which provided the 
original justification for RFC6177. 

 

(Side note: Happy to work with any interested parties on a new RFC re-codifying 
the recommendations from RFC3177, informed by 8273, and obsoleting 6177 given 
the above).

 

Thanks,

 

-Chris

 

*Yes, I’m aware the host itself could be virtual as well. Turtles all the way 
down, folks.



On Apr 19, 2020, at 10:28 AM, John Santos  wrote:

 

Policy should not prohibit doing what many regard as best practice.  Just 
because SOME ISPs might find a /48 unnecessarily large doesn't mean that ALL 
will, or that the recommendation of a /48 is always WRONG and that nano-ISPs 
should be punished (financially) for doing so.

There is obviously a huge scaling issue with fees, when a giant ISP is paying 
less than a penny per year for addresses and a very small ISP is paying close 
to a dollar per year, but I don't think we can fix that with policy.  But we 
can make it less worse by allowing the tiniest ISPs to allocate what they need 
and not orders of magnitude more than they need at exponentially larger cost.

Is there any way to ensure that an ISP requesting a /40 has fewer than 250 
customers, so they can assign each a /48 in order to be eligible for the 
smallest allocation at commensurate cost with a /24 of IPv4?

On 4/19/2020 11:33 AM, Fernando Frediani wrote:

On 19/04/2020 05:07, Owen DeLong wrote:

 

Right… IETF designed a good architecture and then came under pressure from a 
bunch of people with an IPv4 mindset and given the modern state of the IETF 
decided to just punt on the whole thing rather than waste more time on an 
argument where people were determined to do what they were going to do anyway. 
RFC 6177 is more of a cop-out than a legitimate standards document.

We cannot just choose the RFCs we will follow from those we like and disregard 
those which we don't. Imagine if vendors start to do the same !

Since it correctly (in my view) does putting that /48 for residential customers 
should be treated as an exception therefore no RIRs should have to adapt their 
policies to it. If ISPs assign /48 to these customers in exceptional basis (not 
as default) then they would have less or none of of the problems discussed here.



 

There’s absolutely noting in RFC6177 that says /48s should not be given out to 
residential customers. It punts it to the operational community and says it 
really shouldn’t

be up to the IETF. That’s generally true, but that does come with a 
responsibility that the operational community doesn’t arbitrarily create 
negative impacts without good

reason.

One of the main points of the document, if not the most, is that /48 is no 
longer the default and not recommended as well. Therefore if it still possible 
to assign to a residential customer it should then be considered an exception 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[John Santos]

On 4/19/2020 3:08 PM, David Farmer wrote:


On Sun, Apr 19, 2020 at 12:28 PM John Santos > wrote:


Is there any way to ensure that an ISP requesting a /40 has fewer than 250
customers, so they can assign each a /48 in order to be eligible for the
smallest allocation at commensurate cost with a /24 of IPv4?

I don't think there is anything ARIN can reasonably do to require that 
3X-Small ISPs have fewer than 250 customers. However, I'll note that even 
3X-Small ISPs probably wants to grow their business, eventually moving them 
into the 2X-Small ISP category. Once they have something like 150 to 200 
customers they should be able to justify an additional /24 moving them into 
the 2X-Small ISP category.*Further, even for an ISP with 150 to 200 customers 
the additional $250 in ARIN fees annually shouldn't be a significant roadblock 
to their growth. *So, I think the natural incentives for the growth of 
their business will be sufficient to regulate this issue, and I don't think 
we need to micromanage this issue through policy.


If the bolded statement is true, why did 26 out of 30 3X-Small ISPs elect not to 
double their fees?  I posit they all have significantly less than 150 to 200 
customers to spread the cost over, and their customers are extremely 
cost-sensitive.  If they have, say, 150 customers on  average, the increased 
cost would be less than 14 cents per month.  If they only have 10 customers, 
then the annual ARIN fees for each customer would double from $25 to $50.


It would be useful to hear from some of these 26 nano-ISPs about what their 
customer base is and why they are so cost-sensitive.  I suspect most of us 
techies are completely oblivious to the real-world concerns of these customers 
and that they aren't just being incredible cheapskates.  As in "$25, that won't 
even pay for a decent meal" vs. "$25, I could feed my family for a week!"


--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Chris Woodfield]

I’ll admit to having skimmed some of this thread, so apologies in advance if 
I've missed prior discussion of the point below.

The guidance against assigning /48s by default described in RFC6177 made sense 
at the time, particularly for an individual residential subscriber site, given 
the assumption that a residential site would rarely, if ever, have a second 
layer of L3 forwarding beyond the broadband router - that is, each /64 within 
the customer’s allocation would be attached to the edge gateway (i.e. multiple 
VLANs, WiFi SSIDs with L3 separation, etc.) In that world, allowing 65K unique 
/64s gateways to exist on a home broadband router was rightly seen as 
unnecessarily wasteful, regardless of sparse addressing design patterns. As is, 
even the 256 /64 prefixes in the /56 I can route to my broadband edge device 
seems like overkill, and I’d like to think I’m much savvier than the typical 
residential subscriber :)

That said, RFC8273, published 6 years after 6177, now recommends that instead 
of assigning individual /128s to hosts within a shared /64, prefix delegation 
should be utilized instead to assign a /64 *per host* by default within an IPv6 
network. This practice unlocks the ability for any end host to become a 
downstream “virtual” L3 router, allowing individually addressed software 
components to be uniquely addressed within a host (obvious candidates here 
would be virtual machines and docker containers, but also individual servers or 
clients living on the host), all numbered from a /64 with a known physical* 
location for policy/security purposes.

Given this recommendation, I believe it absolutely makes sense now to 
standardize as best practice the default assignment of a /48 to even 
residential subscribers, given that IETF-codified best practices now recommend 
exactly that two-layer routing model that the lack of which provided the 
original justification for RFC6177. 

(Side note: Happy to work with any interested parties on a new RFC re-codifying 
the recommendations from RFC3177, informed by 8273, and obsoleting 6177 given 
the above).

Thanks,

-Chris

*Yes, I’m aware the host itself could be virtual as well. Turtles all the way 
down, folks.

> On Apr 19, 2020, at 10:28 AM, John Santos  wrote:
> 
> Policy should not prohibit doing what many regard as best practice.  Just 
> because SOME ISPs might find a /48 unnecessarily large doesn't mean that ALL 
> will, or that the recommendation of a /48 is always WRONG and that nano-ISPs 
> should be punished (financially) for doing so.
> 
> There is obviously a huge scaling issue with fees, when a giant ISP is paying 
> less than a penny per year for addresses and a very small ISP is paying close 
> to a dollar per year, but I don't think we can fix that with policy.  But we 
> can make it less worse by allowing the tiniest ISPs to allocate what they 
> need and not orders of magnitude more than they need at exponentially larger 
> cost.
> 
> Is there any way to ensure that an ISP requesting a /40 has fewer than 250 
> customers, so they can assign each a /48 in order to be eligible for the 
> smallest allocation at commensurate cost with a /24 of IPv4?
> 
> On 4/19/2020 11:33 AM, Fernando Frediani wrote:
>> On 19/04/2020 05:07, Owen DeLong wrote:
>>> 
>>> Right… IETF designed a good architecture and then came under pressure from 
>>> a bunch of people with an IPv4 mindset and given the modern state of the 
>>> IETF decided to just punt on the whole thing rather than waste more time on 
>>> an argument where people were determined to do what they were going to do 
>>> anyway. RFC 6177 is more of a cop-out than a legitimate standards document.
>> We cannot just choose the RFCs we will follow from those we like and 
>> disregard those which we don't. Imagine if vendors start to do the same !
>> Since it correctly (in my view) does putting that /48 for residential 
>> customers should be treated as an exception therefore no RIRs should have to 
>> adapt their policies to it. If ISPs assign /48 to these customers in 
>> exceptional basis (not as default) then they would have less or none of of 
>> the problems discussed here.
>> 
>> 
>> 
>>> 
>>> There’s absolutely noting in RFC6177 that says /48s should not be given out 
>>> to residential customers. It punts it to the operational community and says 
>>> it really shouldn’t
>>> be up to the IETF. That’s generally true, but that does come with a 
>>> responsibility that the operational community doesn’t arbitrarily create 
>>> negative impacts without good
>>> reason.
>> One of the main points of the document, if not the most, is that /48 is no 
>> longer the default and not recommended as well. Therefore if it still 
>> possible to assign to a residential customer it should then be considered an 
>> exception not a normal thing as the others.
>> Let me quote an important part of it within section 2: "Hence, it is 
>> strongly intended that even home sites be given multiple subnets 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[David Farmer]

On Sun, Apr 19, 2020 at 12:28 PM John Santos  wrote:

> Is there any way to ensure that an ISP requesting a /40 has fewer than 250
> customers, so they can assign each a /48 in order to be eligible for the
> smallest allocation at commensurate cost with a /24 of IPv4?
>
I don't think there is anything ARIN can reasonably do to require that
3X-Small ISPs have fewer than 250 customers. However, I'll note that even
3X-Small ISPs probably wants to grow their business, eventually moving them
into the 2X-Small ISP category. Once they have something like 150 to 200
customers they should be able to justify an additional /24 moving them into
the 2X-Small ISP category. Further, even for an ISP with 150 to 200
customers the additional $250 in ARIN fees annually shouldn't be a
significant roadblock to their growth. So, I think the natural incentives
for the growth of their business will be sufficient to regulate this issue,
and I don't think we need to micromanage this issue through policy.

Thanks

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[John Santos]

Policy should not prohibit doing what many regard as best practice.  Just 
because SOME ISPs might find a /48 unnecessarily large doesn't mean that ALL 
will, or that the recommendation of a /48 is always WRONG and that nano-ISPs 
should be punished (financially) for doing so.


There is obviously a huge scaling issue with fees, when a giant ISP is paying 
less than a penny per year for addresses and a very small ISP is paying close to 
a dollar per year, but I don't think we can fix that with policy.  But we can 
make it less worse by allowing the tiniest ISPs to allocate what they need and 
not orders of magnitude more than they need at exponentially larger cost.


Is there any way to ensure that an ISP requesting a /40 has fewer than 250 
customers, so they can assign each a /48 in order to be eligible for the 
smallest allocation at commensurate cost with a /24 of IPv4?


On 4/19/2020 11:33 AM, Fernando Frediani wrote:

On 19/04/2020 05:07, Owen DeLong wrote:


Right… IETF designed a good architecture and then came under pressure from a 
bunch of people with an IPv4 mindset and given the modern state of the IETF 
decided to just punt on the whole thing rather than waste more time on an 
argument where people were determined to do what they were going to do 
anyway. RFC 6177 is more of a cop-out than a legitimate standards document.
We cannot just choose the RFCs we will follow from those we like and disregard 
those which we don't. Imagine if vendors start to do the same !


Since it correctly (in my view) does putting that /48 for residential 
customers should be treated as an exception therefore no RIRs should have to 
adapt their policies to it. If ISPs assign /48 to these customers in 
exceptional basis (not as default) then they would have less or none of of the 
problems discussed here.






There’s absolutely noting in RFC6177 that says /48s should not be given out 
to residential customers. It punts it to the operational community and says 
it really shouldn’t
be up to the IETF. That’s generally true, but that does come with a 
responsibility that the operational community doesn’t arbitrarily create 
negative impacts without good

reason.
One of the main points of the document, if not the most, is that /48 is no 
longer the default and not recommended as well. Therefore if it still possible 
to assign to a residential customer it should then be considered an exception 
not a normal thing as the others.
Let me quote an important part of it within section 2: "/Hence, it is strongly 
intended that even home sites be given multiple subnets worth of space, by 
default.  Hence, this document still recommends giving home sites 
significantly more than a single /64, but does not recommend that every home 
site be given a /48 either./"


Furthermore at the time of the write of the document it also mentions: "Since 
then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE], and RIPE [RIPE-ENDSITE] have 
revised the end site assignment policy to encourage the assignment of smaller 
(i.e., /56) blocks to end sites.". Although some of these might have been 
retired in their manuals it is possible to notice the spirit of  the change 
RFC6177 brings, and is still valid.


Regards
Fernando


___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.


--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[John Osmon]

On Thu, Apr 16, 2020 at 10:32:40AM -0400, Brian Jones wrote:
> Looking at the numbers John posted concerning this issue, it tends to *look
> like* some of these 3x small folks decided to drop their request once they
> encountered the price increase. If this is the case then we should move
> forward with this proposal. We do not want to create a situation where
> folks are continuing to use only IPv4 because of costs.


I support then intent of ARIN-2020-3.

As a data point, I thought I'd get my story in here.  The point to the
story is that there are entities that have legitimate need for
resources, but are stymied by the costs.  Even at 3x and 2x small sizes.


Onto my story:

I'm often asked to work on interesting projects.  I have used my
resources to bootstrap a number of organizations.  It's never been a lot
of money, and has has lost money in many years.

I was originally an end-user, not an ISP, due to financial issues.  I
often used the resources I had to help other bootstrap their services
until they were ready to obtain their own.  I held an ASN, a /22 of
IPv4, and a /48 of IPv6 by 2007.

End-user fees went from a flat $100/year to $100/resource and I dropped
the IPv6 block to reduce my costs in 2014.  (So, while I'm an
aberration, it should be noted that ARIN policies drove IPv6 adoption
lower with the fee increase.)

When End-User fees went up to $150/resource, I was very happy to see the
3x-small category.  I was able to pickup a /44, transfer my /22 to a
a client that needed the space more than I did, and pickup a /24 to
continue the work I'd been doing.  Plus, the new designation gave me
voting privileges I didn't formerly have.

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Fernando Frediani]

On 19/04/2020 05:07, Owen DeLong wrote:


Right… IETF designed a good architecture and then came under pressure 
from a bunch of people with an IPv4 mindset and given the modern state 
of the IETF decided to just punt on the whole thing rather than waste 
more time on an argument where people were determined to do what they 
were going to do anyway. RFC 6177 is more of a cop-out than a 
legitimate standards document.
We cannot just choose the RFCs we will follow from those we like and 
disregard those which we don't. Imagine if vendors start to do the same !


Since it correctly (in my view) does putting that /48 for residential 
customers should be treated as an exception therefore no RIRs should 
have to adapt their policies to it. If ISPs assign /48 to these 
customers in exceptional basis (not as default) then they would have 
less or none of of the problems discussed here.






There’s absolutely noting in RFC6177 that says /48s should not be 
given out to residential customers. It punts it to the operational 
community and says it really shouldn’t
be up to the IETF. That’s generally true, but that does come with a 
responsibility that the operational community doesn’t arbitrarily 
create negative impacts without good

reason.
One of the main points of the document, if not the most, is that /48 is 
no longer the default and not recommended as well. Therefore if it still 
possible to assign to a residential customer it should then be 
considered an exception not a normal thing as the others.
Let me quote an important part of it within section 2: "/Hence, it is 
strongly intended that even home sites be given multiple subnets worth 
of space, by default.  Hence, this document still recommends giving home 
sites significantly more than a single /64, but does not recommend that 
every home site be given a /48 either./"


Furthermore at the time of the write of the document it also mentions: 
"Since then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE], and RIPE 
[RIPE-ENDSITE] have revised the end site assignment policy to encourage 
the assignment of smaller (i.e., /56) blocks to end sites.". Although 
some of these might have been retired in their manuals it is possible to 
notice the spirit of  the change RFC6177 brings, and is still valid.


Regards
Fernando

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Betty Fausta - IPEOS via ARIN-PPML]

hi/bonjour, 

+1 with @JORDI [..] strategy, increase IPV4 cost (even if there is a black 
market of opportunities effect of those can deal) and have an affordable price 
for IPV6. That could be fix for a "transition period" of 3 or 5 years to manage 
ROI of investors. 

sorry if my sharing is out of the box, i'm new and don't really know all 
exchanges rules 

regards and stay safe at home from people under lockdown program 

regards from Guadeloupe, French caribbean 

-- 
Betty FAUSTA— CEO IPEOS I-Solutions 
Mobile: +590 690 497 309 
Twitter/Instagram: @betfau 

www.ipeos.com | www.ipeos.net 
Sales: +590 590 228 020 - i...@ipeos.com - Fax (0)972 337 124 
Hotline: +590 590 227 217 - https://support.ipeos.com 
[ https://docmail.apps-ipeos.com/ | Découvrez la messagerie collaborative par 
IPEOS  ] 


De: "JORDI PALET MARTINEZ via ARIN-PPML"  
À: arin-ppml@arin.net 
Envoyé: Dimanche 19 Avril 2020 05:16:12 
Objet: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations 



LACNIC and AFRINIC have similar problems in the fee structure that doesn’t 
incentivize the right deployment of IPv6. I’ve already made proposals to the 
relevant boards to change that (it is not a matter of policies in those cases). 



Many management departments of ISPs make the numbers about the right prefix for 
customers, not according to technical reasons, but to: 

1. By default, I get a /32 without justification (in all the other RIRs), 
done, this must work for any number of customers. Even if I give them a single 
/64 … 
2. I want to make sure that the “cost” of each customer prefix is as lower 
as I can. 




I think we should do this: 

1. The cost of “every” /48 out of a /40 must be proportional to the cost of 
“every” /48 out of a /40, /36, /32 and so on. It makes a lot of sense that as 
larger is the block that you get from ARIN, the proportional cost of each /48 
gets cheaper and cheaper. You can do the same “proportionality” with each /128, 
/64, /56, or whatever. It is not related to the size of the prefix you provide, 
just having some symmetry. 



Right one in ARIN, if you assume that you’re using a /48 for each customer you 
pay for each /48 out of each /40, 0,97656 USD, out of a /36 0,12207 USD, in the 
case of the /32 0,01526, and in the case of the /28 0,00191 USD. I think the 
“jump” in between each category and the following ones is not good, especially 
for the smaller ISPs. 

1. The fee structure for IPv4, needs to be “disconnected” from the IPv6 
one. IPv4 must become more expensive. IPv6 must become cheaper. 
2. If an ISP is doing a right addressing plan and provides the 
justification for it, even if it is providing /48 to every customer (including 
residential customer) that should be supported. In fact, I always tell my 
customers, you must go for /48 and make persistent prefixes to customers 
(unless they move to a different location). RIPE-690 provides explanations for 
that. 




However, the problem is probably better resolved by the board, making a better 
fee structure than by a policy. Policy may help to facilitate the usage of /48, 
but if we also change the fee structure it will be much logic. 



The case about $CABLECO it is clearly a * BAD * designed addressing plan. I 
still see lots of people doing * terribly bad * addressing plans with IPv6, and 
there is no need for that. You can still provide a /48 for each customer, even 
for millions of customers, and still not * waste * a lot of addresses and no 
require a complex interior routing setup. Many documents and trainings do a 
really really bad work in that. I’ve started several months ago, to write a 
BCOP for telling people how this can be done correctly, but I’d not the 
sufficient time/tranquility to finish it. Hopefully I can do it soon (happy to 
get in touch, in private, with other people that is interested in contributing 
to it). 



I believe it is rare the case where an ISP may need /16, but because they need 
to justify it, and I’m sure ARIN will be stricter with a justification for a 
/16 or /20 than for a /32, I think this restriction should not be put in place. 
If there is a single case, we must support it, otherwise, we are asking that 
ISP to provide customers a smaller block that what he will like to do. 



Giving each “human” (not household) a /48 is perfectly valid. There is no IPv6 
scarcity. I’ve done this numbers several times, here is one more. 



Each /3 has 35.184.372.088.832 /48’s. 

Assuming that we are so terrible with the utilization of IPv6, that we waste 
50% of it, we have only 17.592.186.044.416 /48’s . 

Assuming that in the earth we can get 2^35 inhabitants ( 34.359.738.368). 

Assuming that each person lives 100 years and we don’t recover the IPv6 space 
when they are buried. 

If we give each person a /48, then we have sufficient number of them for the 
next 51.200 years. 

If we give each person 4 /48’s, then we have sufficient number of them only 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[JORDI PALET MARTINEZ via ARIN-PPML]

LACNIC and AFRINIC have similar problems in the fee structure that doesn’t 
incentivize the right deployment of IPv6. I’ve already made proposals to the 
relevant boards to change that (it is not a matter of policies in those cases).

 

Many management departments of ISPs make the numbers about the right prefix for 
customers, not according to technical reasons, but to:
By default, I get a /32 without justification (in all the other RIRs), done, 
this must work for any number of customers. Even if I give them a single /64 …
I want to make sure that the “cost” of each customer prefix is as lower as I 
can.
 

I think we should do this:
The cost of “every” /48 out of a /40 must be proportional to the cost of 
“every” /48 out of a /40, /36, /32 and so on. It makes a lot of sense that as 
larger is the block that you get from ARIN, the proportional cost of each /48 
gets cheaper and cheaper. You can do the same “proportionality” with each /128, 
/64, /56, or whatever. It is not related to the size of the prefix you provide, 
just having some symmetry.
Right one in ARIN, if you assume that you’re using a /48 for each customer you 
pay for each /48 out of each /40, 0,97656 USD, out of a /36 0,12207 USD, in the 
case of the /32 0,01526, and in the case of the /28 0,00191 USD. I think the 
“jump” in between each category and the following ones is not good, especially 
for the smaller ISPs.
The fee structure for IPv4, needs to be “disconnected” from the IPv6 one. IPv4 
must become more expensive. IPv6 must become cheaper.
If an ISP is doing a right addressing plan and provides the justification for 
it, even if it is providing /48 to every customer (including residential 
customer) that should be supported. In fact, I always tell my customers, you 
must go for /48 and make persistent prefixes to customers (unless they move to 
a different location). RIPE-690 provides explanations for that.
 

However, the problem is probably better resolved by the board, making a better 
fee structure than by a policy. Policy may help to facilitate the usage of /48, 
but if we also change the fee structure it will be much logic.

 

The case about $CABLECO it is clearly a *BAD* designed addressing plan. I still 
see lots of people doing *terribly bad* addressing plans with IPv6, and there 
is no need for that. You can still provide a /48 for each customer, even for 
millions of customers, and still not *waste* a lot of addresses and no require 
a complex interior routing setup. Many documents and trainings do a really 
really bad work in that. I’ve started several months ago, to write a BCOP for 
telling people how this can be done correctly, but I’d not the sufficient 
time/tranquility to finish it. Hopefully I can do it soon (happy to get in 
touch, in private, with other people that is interested in contributing to it).

 

I believe it is rare the case where an ISP may need /16, but because they need 
to justify it, and I’m sure ARIN will be stricter with a justification for a 
/16 or /20 than for a /32, I think this restriction should not be put in place. 
If there is a single case, we must support it, otherwise, we are asking that 
ISP to provide customers a smaller block that what he will like to do.

 

Giving each “human” (not household) a /48 is perfectly valid. There is no IPv6 
scarcity. I’ve done this numbers several times, here is one more.

 

Each /3 has 35.184.372.088.832 /48’s.

Assuming that we are so terrible with the utilization of IPv6, that we waste 
50% of it, we have only 17.592.186.044.416 /48’s.

Assuming that in the earth we can get 2^35 inhabitants (34.359.738.368).

Assuming that each person lives 100 years and we don’t recover the IPv6 space 
when they are buried.

If we give each person a /48, then we have sufficient number of them for the 
next 51.200 years.

If we give each person 4 /48’s, then we have sufficient number of them only for 
the next 12.800 years.

 

If we start using the other 7/8 of the addressing space, then we have IPv6 for 
the next 409.600 or 102.400 years (depending on if we provide a single /48 or 4 
of them).

 

I know those figures look an exaggeration, but they are just numbers. The issue 
here is that we need to understand that the next big “problem” in Internet is 
not the number of addresses (even if addressing plans need to be done in such 
way that they are not wasteful), but may other issues to come.

 

 

See https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis-02. I need to 
update it!

 

Regards,

Jordi

@jordipalet

 

 

 

El 18/4/20 10:42, "ARIN-PPML en nombre de Fernando Frediani" 
 escribió:

 

On 18/04/2020 05:26, Owen DeLong wrote:

... 

 

Admittedly, /48s for everyone still isn’t gaining as much traction as we’d like 
due to a combination of IPv4-think at some ISPs and other reasons I have 
trouble understanding.

Thankfully it is not !

 

E.G. I once had a discussion with the IPv6 project manager for a major $CABLECO 
about why they were 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[David Farmer]

On Sun, Apr 19, 2020 at 12:21 AM Fernando Frediani 
wrote:

> On 19/04/2020 01:38, David Farmer wrote:
>
> I support this policy as written, as I said previously, I recommend a
> couple of changes, but I won't repeat the details of those changes here.
>
> Regarding the current discussion of /48 assignments to
> residential customers, that is the architecture as defined by the IETF, and
> ARIN policy MUST NOT create situations where its necessary or that
> incentivizes ISPs to make assignments longer than /48. Further, this policy
> is at least minimally consistent with the IPv6 architecture, and /48 IPv6
> assignments, when considering a 3X-Small ISP, with a /24 of IPv4 and a /40
> of IPv6, both address families will reasonably support 250 or fewer
> customers.
>
> Can you please quote exactly where IETF defines that way ?
>
> RFC6177 in its abstract says: "*RFC 3177 argued that in IPv6, end sites
> should be assigned /48 blocks in most cases.  The Regional Internet
> Registries (RIRs) adopted that recommendation in 2002, but began
> reconsidering the policy in 2005. This document obsoletes the RFC 3177
> recommendations on the  assignment of IPv6 address space to end sites. The
> exact choice of how much address space to assign end sites is an issue for
> the operational community.  The IETF's role in this case is limited to
> providing guidance on IPv6 architectural and operational considerations.*"
> ...
> "*This document reviews the architectural and operational considerations
> of end site assignments as well as the motivations behind the original
> recommendations in RFC 3177. Moreover, this document clarifies that a
> one-size-fits-all recommendation of /48 is not nuanced enough for the broad
> range of end sites and is no longer recommended as a single default.*"
>
>
> The number of customers and the size of IPv6 customer assignments actually
> deployed in reality are outside the scope and control of ARIN, the other
> RIRs, and even the IETF. It is solely in the scope and control of the ISP
> deploying a network. Furthermore, RFC 6177 recognizes longer end-site
> assignments between /48 and /64 could be reasonable.
>
> Recognizes as an exception and it clearly states that is not the
> recommendation anymore, talks about all the issues and why it was reviewed
> and mentions that if someone justify can get it, so as an exception.
>
No, it doesn't eliminate /48 as a recommendation, it clarifies that /48 is
not a requirement of the IPv6 architecture, it eliminates /48 as the
default, eliminating the idea of /48 as a one-size-fits-all. However, /48
effectively remains as the maximum recommended end-site assignment, with
/64 as the minimum, reaffirming that "in practice, that means at least one
/64, and in most cases significantly more." So, even after RFC 6177, /48
still plays an important part in the IPv6 architecture, it just more
nuanced than it was in RFC 3177.

So, if you want to assign /56s or /60s, or /48s for that matter, you are in
compliance with RFC 6177 and ARIN policy, at least in my opinion.

> Given all above I cannot agree and have the same view that /48 to
> residential customers indistinctly is a normal thing and that RIRs should
> necessarily adapt to allow ISPs to make these assignments the way is being
> suggested in this discussion.
>
> Regards
>
Even with RFC 6177, /48 is still relevant in the context of, and
instructive to, ARIN policy, in helping to determine the size of
allocations ARIN makes. In that, if ARIN policy assumed only /56
assignments, let's say, then it would be impossible for ISPs to make /48
assignments, as they wouldn't have enough space to do so. Therefore, ARIN
policy needs to assume /48 for assignments, allowing ISPs to make the
assignments sizes they wish to, between /48 and /64. Nothing in ARIN policy
requires /48 assignments by ISPs, it simply allows up to /48 without
additional justification.

There are reasons to assign /48s even to residential customers, Owen
articulates them well, but nothing in ARIN policy requires this, however,
ARIN policy needs to allow for /48 assignments as an option. In the case of
this policy, relating to /40 allocations for 3X-Small ISPs, if you were to
make /48 assignments you can still make a sufficiently large number of them
for the expected customer base of 3X-Small ISPs, and you can make even more
if you make /56 or /60 assignments. However, if instead of a /40
allocation, we made it a /44 allocation, then you could only make 16 /48
assignments, and this is not a reasonable number of customer assignments
even for a 3X-Small ISP.

Thanks.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Owen DeLong]

> On Apr 18, 2020, at 22:20 , Fernando Frediani  wrote:
> 
> On 19/04/2020 01:38, David Farmer wrote:
>> I support this policy as written, as I said previously, I recommend a couple 
>> of changes, but I won't repeat the details of those changes here.
>> 
>> Regarding the current discussion of /48 assignments to residential 
>> customers, that is the architecture as defined by the IETF, and ARIN policy 
>> MUST NOT create situations where its necessary or that incentivizes ISPs to 
>> make assignments longer than /48. Further, this policy is at least minimally 
>> consistent with the IPv6 architecture, and /48 IPv6 assignments, when 
>> considering a 3X-Small ISP, with a /24 of IPv4 and a /40 of IPv6, both 
>> address families will reasonably support 250 or fewer customers.
> Can you please quote exactly where IETF defines that way ? 
> 
> RFC6177 in its abstract says: "RFC 3177 argued that in IPv6, end sites should 
> be assigned /48 blocks in most cases.  The Regional Internet Registries 
> (RIRs) adopted that recommendation in 2002, but began reconsidering the 
> policy in 2005. This document obsoletes the RFC 3177 recommendations on the  
> assignment of IPv6 address space to end sites. The exact choice of how much 
> address space to assign end sites is an issue for the operational community.  
> The IETF's role in this case is limited to providing guidance on IPv6 
> architectural and operational considerations."
> 
> ...
> "This document reviews the architectural and operational considerations of 
> end site assignments as well as the motivations behind the original 
> recommendations in RFC 3177. Moreover, this document clarifies that a 
> one-size-fits-all recommendation of /48 is not nuanced enough for the broad 
> range of end sites and is no longer recommended as a single default.”

Right… IETF designed a good architecture and then came under pressure from a 
bunch of people with an IPv4 mindset and given the modern state of the IETF 
decided to just punt on the whole thing rather than waste more time on an 
argument where people were determined to do what they were going to do anyway. 
RFC 6177 is more of a cop-out than a legitimate standards document.

>> The number of customers and the size of IPv6 customer assignments actually 
>> deployed in reality are outside the scope and control of ARIN, the other 
>> RIRs, and even the IETF. It is solely in the scope and control of the ISP 
>> deploying a network. Furthermore, RFC 6177 recognizes longer end-site 
>> assignments between /48 and /64 could be reasonable.
> Recognizes as an exception and it clearly states that is not the 
> recommendation anymore, talks about all the issues and why it was reviewed 
> and mentions that if someone justify can get it, so as an exception.
> 
It recognizes LONGER assignments as an exception, yes. It does not clearly 
state that /48 is no longer the recommendation.

Specifically:
Moreover, this document clarifies that a one-size-fits-all
   recommendation of /48 is not nuanced enough for the broad range of
   end sites and is no longer recommended as a single default.


Recognizes that perhaps there are some end sites where a /48 does not 
necessarily make sense. At the time of writing, IIRC, the major target of this 
was cell phones.

Residential end users remained controversial throughout the discussion and 
there was never a consensus reached (one of the main reasons 6177 uses so much 
weasel wording) for longer prefix assignments to residential end sites.
> Given all above I cannot agree and have the same view that /48 to residential 
> customers indistinctly is a normal thing and that RIRs should necessarily 
> adapt to allow ISPs to make these assignments the way is being suggested in 
> this discussion.
> 
I’m sorry, I cannot parse your actual intent from this statement. Can you try 
rewording it?

Section 2 basically states that if you ignore the goals of automated hierarchy, 
you can fudge home sites down to /56 and still meat the remaining goals. It 
narrowly interprets RFC3177 and ignores any use cases not previously documented 
in that RFC.

Section 4.1 all but admits that any site using RFC3056 addressing and sparse 
allocation (also recommended back then and still good practice today) would 
potentially be negatively impacted by longer assignments.

Section 5 is worth a read, tooo.

- Although a /64 can (in theory) address an almost unlimited
number of devices, sites should be given sufficient address
space to be able to lay out subnets as appropriate, and not be
forced to use address conservation techniques such as using
bridging.  Whether or not bridging is an appropriate choice is
an end site matter.

  - assigning a longer prefix to an end site, compared with the
existing prefixes the end site already has assigned to it, is
likely to increase operational costs and complexity for the end
site, with insufficient 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Fernando Frediani]

On 19/04/2020 01:38, David Farmer wrote:
I support this policy as written, as I said previously, I recommend a 
couple of changes, but I won't repeat the details of those changes here.


Regarding the current discussion of /48 assignments to 
residential customers, that is the architecture as defined by 
the IETF, and ARIN policy MUST NOT create situations where its 
necessary or that incentivizes ISPs to make assignments longer 
than /48. Further, this policy is at least minimally consistent with 
the IPv6 architecture, and /48 IPv6 assignments, when considering a 
3X-Small ISP, with a /24 of IPv4 and a /40 of IPv6, both address 
families will reasonably support 250 or fewer customers.


Can you please quote exactly where IETF defines that way ?

RFC6177 in its abstract says: "/RFC 3177 argued that in IPv6, end sites 
should be assigned /48 blocks in most cases.  The Regional Internet 
Registries (RIRs) adopted that recommendation in 2002, but began 
reconsidering the policy in 2005. This document obsoletes the RFC 3177 
recommendations on the assignment of IPv6 address space to end sites. 
The exact choice of how much address space to assign end sites is an 
issue for the operational community.  The IETF's role in this case is 
limited to providing guidance on IPv6 architectural and operational 
considerations./"


...
"/This document reviews the architectural and operational considerations 
of end site assignments as well as the motivations behind the original 
recommendations in RFC 3177. Moreover, this document clarifies that a 
one-size-fits-all recommendation of /48 is not nuanced enough for the 
broad range of end sites and is no longer recommended as a single default./"




The number of customers and the size of IPv6 customer assignments 
actually deployed in reality are outside the scope and control of 
ARIN, the other RIRs, and even the IETF. It is solely in the scope and 
control of the ISP deploying a network. Furthermore, RFC 6177 
recognizes longer end-site assignments between /48 and /64 could be 
reasonable.


Recognizes as an exception and it clearly states that is not the 
recommendation anymore, talks about all the issues and why it was 
reviewed and mentions that if someone justify can get it, so as an 
exception.


Given all above I cannot agree and have the same view that /48 to 
residential customers indistinctly is a normal thing and that RIRs 
should necessarily adapt to allow ISPs to make these assignments the way 
is being suggested in this discussion.


Regards


___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[David Farmer]

I support this policy as written, as I said previously, I recommend a
couple of changes, but I won't repeat the details of those changes here.

Regarding the current discussion of /48 assignments to
residential customers, that is the architecture as defined by the IETF, and
ARIN policy MUST NOT create situations where its necessary or that
incentivizes ISPs to make assignments longer than /48. Further, this policy
is at least minimally consistent with the IPv6 architecture, and /48 IPv6
assignments, when considering a 3X-Small ISP, with a /24 of IPv4 and a /40
of IPv6, both address families will reasonably support 250 or fewer
customers.

The number of customers and the size of IPv6 customer assignments actually
deployed in reality are outside the scope and control of ARIN, the other
RIRs, and even the IETF. It is solely in the scope and control of the ISP
deploying a network. Furthermore, RFC 6177 recognizes longer end-site
assignments between /48 and /64 could be reasonable.

https://tools.ietf.org/html/rfc6177

So can we please stop arguing about things that are outside of the scope
and control of ARIN policy.

ARIN's IPv6 policy needs to enable all ISPs to make /48 assignments if they
wish to do so, what size assignments they actually make are outside the
scope and control of ARIN policy and mostly irrelevant to this discussion.
What is relevant to this discussion is that this policy enables 3X-Small
ISPs to make a minimally sufficient number of /48 IPv6 assignments, without
incurring additional fees, based on the current ARIN fee structure.

If a 3X-Small ISP tries to support significantly more than about 250
customers, the size of the IPv6 assignments they are making will be the
least of their problems, at least in my opinion.

While I fully support this policy, I would also support, and probably even
prefer, a permanent fee waiver for 3X-Small ISPs to receive a /36 of IPv6
at no additional cost based on the current IPv6 policy.

However, one way or another this needs to get fixed, NOW! It should have
been fixed a long time ago, and it's not been from a lack of trying by many
of us. Please support this policy as it fixes the problem, is in the scope
of the Policy Development Process (PDP), and in the ARIN policy community's
control. Whereas, the alternative of a fee waiver, while possibly
preferred, is not in the scope of the PDP or the policy community's
control.

Thanks.

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Owen DeLong]

> On Apr 18, 2020, at 15:20 , William Herrin  wrote:
> 
> On Sat, Apr 18, 2020 at 2:44 PM Owen DeLong  wrote:
>> Handing out a /48 to each end site is a core engineering design that was put 
>> into IPv6 for many valid reasons.
> 
> Hi Owen,
> 
> If I understand correctly, the /32, /48 and /64 size recommendations
> were originally discussed on public, now-archived IETF mailing lists.
> At the time, dynamic dialups were the equivalent of what we today
> consider residential customers (as opposed to business and hobbyist
> end sites). Have you found some citations among those discussions
> which clarify that /48 was intended to apply to all ISP customers
> explicitly including individual end users of the ISP, not just network
> clients of the ISP.

While I don’t have citations, I can say that you aren’t entirely correct. While 
not as ubiquitous
as they are today, both CMTS and DSL systems were known residential ISP 
technologies
at the time those boundaries were established and the idea of automatic 
hierarchical
topologies through layered DHCP-PD was very much something that was considered 
as
applicable to a potential future residential context. It would take some time 
to find any
citations for this, but I personally recall participating in some of those 
discussions.

By the time we were establishing those boundaries, it was already assumed that 
an
always-on broadband connection via DSL, CMTS, or other future technology with
similar or even greater capabilities would become the norm for residential 
internet
services.

Not that all of the assumptions came true. It was assumed that IPv6 would be an 
enabling
technology helping to drive deployment of that infrastructure, rather than the 
other way
around.

There are others on this list who were there. I’m sure someone will correct any
misstatements I may have made or any incorrect details.


Owen

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Owen DeLong]

> On Apr 18, 2020, at 15:01 , Fernando Frediani  wrote:
> 
> On 18/04/2020 18:44, Owen DeLong wrote:
>> ...
>> Handing out a /48 to each end site is a core engineering design that was put 
>> into IPv6 for many valid reasons.
>> 
>> You continue to rail against it, yet you’ve provided no reason or basis for 
>> your claim that it is “an exaggeration” or that it is in any way detrimental.
> Yes /48 to a site absolutely no problem.

A residential customer is just one kind of end site.

From NRPM section 2.10:
The term End Site shall mean a single structure or service delivery address, 
or, in the case of a multi-tenant structure, a single tenant within said 
structure (a single customer location).

> To a residential customers is an truly absurd. /56 or /60 is broadly fine for 
> this and you can always treat the exceptions and easily give out a /48 to 
> customers who justify or really have a need of it, like some corporate 
> customers for instance. But not for all indistinctly.

No, it isn’t… For all of the reasons I’ve outlined before and others.

> I am trying not to go too much into this topic because I fear to to divert 
> from the policy discussion. Yes, in order to discuss this we have to put up 
> technical considerations and it's fine, but I guess a more elaborated 
> technical discussion wouldn't be beneficial to this list.

It is a crucial part of the reasoning behind this policy. Were it not for the 
need for /48s for all, I would not be supporting the policy, so it isn’t a 
diversion, it’s a central and key part of justifying this policy proposal.

If you’re worried about whether it’s beneficial to the list, feel free to send 
it to me directly. My email address is in the From: line.

I will even respect your wishes about whether I can quote what you say with or 
without attribution.

>> 
>> In terms of any concerns or fears about running out if we use such an 
>> address allocation policy, consider the following:
>> 
>>  1.  Current earth population is approximately 7,000,000,000 (7e9).
>>  2.  Let’s assume that within the lifetime of IPv6 we are somehow 
>> able to double that population to 14e9.
>>  3.  Let’s further assume that each individual resides in a solitary 
>> end site (average density is 2.3 humans per household).
>>  4.  Let’s also give each individual a separate /48 for their place 
>> of work and an additional /48 for their share of the various
>>  services and companies they communicate with as well as network 
>> infrastructure they use.
>>  5.  If we bake in all of those exaggerated assumptions, we need a 
>> total of 42e9 /48s.
>>  6.  There are 2^45 /48s in 2000::/3 (the current IETF/IANA 
>> designated IPv6 GUA pool (which can be expanded several times).
>>  7.  2^25 is 35,184,372,088,832 (more than 35e12).
>>  8.  So, in fact, without exhausting the current pool of address 
>> space, we can give every individual on earth 6 /48s and we
>>  still only consume 0.1% of 1/8th of the address space, leaving 
>> 99.9% of the current 2000::/3 still available.
> I never worry about running out of IPv6 addresses. This isn't really the 
> issue.

OK.

> We must use them reasonably and intelligently and as mentioned above nowadays 
> a /48 for a residential customer is way too much and the vast majority will 
> not use even a tiny portion of it, even in a near future. I'd rather the 
> technologies to develop around the usage of a for example a /56 which are 256 
> x /64 networks and still a lot for a residential proposes. Again, if really 
> necessary it's not hard to give out /48 to someone who justify for *real 
> needs* not for *perhaps in the future*.

A /64 is way too much too by that reasoning. I mean what residential (or even 
business) will ever use even a tiny portion of 18+ quintillion IPv6 addresses?

Your logic is flawed and it ignores the design principles of IPv6.

If you believe that what you are saying works in the real world, you are sadly 
mistaken. ISPs will not give /48s to residential customers who ask for them 
unless that’s the standard size they give to every residential customer. 
Residential internet access is a volume business that depends on avoiding 
one-offs and custom solutions in order to be profitable. What you get is what 
you get. Don’t like it, go buy your internet access from their non-existent 
competitor.

If minimal end-site assignments to residential customers becomes the norm, then 
that will define software development into the future. I can prove this with 
modern day examples…

Once upon a time, applications were developed on the basis that each end host 
was uniquely addressed and could be reached simply by sending a packet to that 
end host. Today, applications are built with the built-in assumption that you 
can’t reach back into a residential network except through a rendezvous host on 
the outside.

Consider for example, a popular video 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[William Herrin]

On Sat, Apr 18, 2020 at 2:44 PM Owen DeLong  wrote:
> Handing out a /48 to each end site is a core engineering design that was put 
> into IPv6 for many valid reasons.

Hi Owen,

If I understand correctly, the /32, /48 and /64 size recommendations
were originally discussed on public, now-archived IETF mailing lists.
At the time, dynamic dialups were the equivalent of what we today
consider residential customers (as opposed to business and hobbyist
end sites). Have you found some citations among those discussions
which clarify that /48 was intended to apply to all ISP customers
explicitly including individual end users of the ISP, not just network
clients of the ISP.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/
___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Michael Sinatra]

I oppose the policy *as worded* for the reason(s) expressed below.

On 2020-03-24 10:20, ARIN wrote:
> On 19 March 2020, the ARIN Advisory Council (AC) accepted
> "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.

[snip]

> Draft Policy ARIN-2020-3: IPv6 Nano-allocations
> 
> Problem Statement:
> 
> ARIN's fee structure provides a graduated system wherein organizations
> pay based on the amount of number resources they consume.

The wording of this problem statement is, IMO, incorrect.  ARIN's RSA,
Section 7, explicitly states that number resources are not the property
of the holder.  As such, I don't see how a reasonable person can view
them as being "consumed" by the registrant.

This may seem like a semantic issue, but part of the problem is that the
statement is really correct inasmuch as the ARIN fee schedule does scale
based on the amount of IP addresses registered to an organization,
rather than based on the registration services actually provided by ARIN.

The elephant in the room is that ARIN's fee schedule treats IP addresses
as some sort of scarce property rather than properly recovering the
costs of the services ARIN provides.  And yes, I understand how hard
this is: I was on an ARIN fee schedule committee about 5-6 years ago.
That experience taught me that creating a fee schedule that properly
accounts for the costs that accrue to ARIN for the services it provides
to the community is really hard.  But it also gave me an inkling that
there might be a better way than treating IP addresses as consumable
property and charging for their scarcity.  The alignment between that
and ARIN's operating costs is just too tenuous.

The policy is represents good intent, and from a technical perspective,
I don't have a problem with it.  /40s-/48s appear in the IPv6 DFZ as a
result of direct assignments obtained by end sites via the "PIv6"
policies ratified by ARIN and other RIRs over a decade ago (which I
supported).  I agree that ship has sailed.  I also acknowledge, as I did
during the PIv6 debates and despite my support for PIv6, that the costs
of micro-allocations are actually borne by the operator community who
must provision additional FIB capacity to support bigger routing tables.
 I would state that routing capacity has arguably scaled better than we
thought back in the mid-00s, and we have dealt with that, as is our job
as operators.

But it underscores that ARIN's fee schedule doesn't account for such
externalities.  One could argue that it shouldn't, but if that's the
case, why does it try to account for the externality of scarcity of
number resources?  Why doesn't it just account for ARIN's costs?

And more broadly, how many more band-aids are we willing to put on the
current fee structure?  If the answer is "oh, we can handle at least a
few more band-aids," then fine.  Change the word "consume" to something
else, and prepend the problem statement with "For better or worse," and
we're done.  But I feel like we should at least think about the larger
question.

michael

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Fernando Frediani]

On 18/04/2020 18:44, Owen DeLong wrote:

...
Handing out a /48 to each end site is a core engineering design that was put 
into IPv6 for many valid reasons.

You continue to rail against it, yet you’ve provided no reason or basis for 
your claim that it is “an exaggeration” or that it is in any way detrimental.

Yes /48 to a site absolutely no problem.

To a residential customers is an truly absurd. /56 or /60 is broadly 
fine for this and you can always treat the exceptions and easily give 
out a /48 to customers who justify or really have a need of it, like 
some corporate customers for instance. But not for all indistinctly.


I am trying not to go too much into this topic because I fear to to 
divert from the policy discussion. Yes, in order to discuss this we have 
to put up technical considerations and it's fine, but I guess a more 
elaborated technical discussion wouldn't be beneficial to this list.




In terms of any concerns or fears about running out if we use such an address 
allocation policy, consider the following:

1.  Current earth population is approximately 7,000,000,000 (7e9).
2.  Let’s assume that within the lifetime of IPv6 we are somehow 
able to double that population to 14e9.
3.  Let’s further assume that each individual resides in a solitary 
end site (average density is 2.3 humans per household).
4.  Let’s also give each individual a separate /48 for their place 
of work and an additional /48 for their share of the various
services and companies they communicate with as well as network 
infrastructure they use.
5.  If we bake in all of those exaggerated assumptions, we need a 
total of 42e9 /48s.
6.  There are 2^45 /48s in 2000::/3 (the current IETF/IANA 
designated IPv6 GUA pool (which can be expanded several times).
7.  2^25 is 35,184,372,088,832 (more than 35e12).
8.  So, in fact, without exhausting the current pool of address 
space, we can give every individual on earth 6 /48s and we
still only consume 0.1% of 1/8th of the address space, leaving 
99.9% of the current 2000::/3 still available.
I never worry about running out of IPv6 addresses. This isn't really the 
issue.
We must use them reasonably and intelligently and as mentioned above 
nowadays a /48 for a residential customer is way too much and the vast 
majority will not use even a tiny portion of it, even in a near future. 
I'd rather the technologies to develop around the usage of a for example 
a /56 which are 256 x /64 networks and still a lot for a residential 
proposes. Again, if really necessary it's not hard to give out /48 to 
someone who justify for *real needs* not for *perhaps in the future*.


Otherwise in a few years someone will start to propose to give out /32 
to residential customers because, otherwise this may limit innovation. 
Sorry I cannot agree with this reasoning.


Fernando





___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Owen DeLong]

> On Apr 18, 2020, at 14:11 , Fernando Frediani  wrote:
> 
> On 18/04/2020 17:49, Owen DeLong wrote:
>> ...
>> It would depend on the nature of the fee waiver. If they perceived it as a 
>> temporary stall resulting in the same fee increase in 3-5 years, I think 
>> you’d get mixed results. If it was a permanent “we won’t charge you extra 
>> until your IPv4 holdings expand or 10+ years, whichever comes first”, I 
>> suspect you’d see a majority of takers.
>> 
>> As to /48s, hard to say… Certainly, with /40s, they are more likely to be 
>> hyper-conservative in their assignments than with /36s. I certainly would 
>> not mind making said waiver conditional on compliance with a /48 PAU.
> My view is that this type of waiver should not exist and this type situation 
> should not be incentivized.
> 
> I see the mentioned "we won't charge you extra until your IPv4 holdings 
> expand or 10+ years" as something more interesting.
> It is necessary to differentiate when an organization has really grown, 
> justify for more space and is able to be paying a higher fee than when they 
> just request more and more Ipv6 space because they are giving away /48 to 
> everyone indistinctly which in my view is an exaggeration. We cannot base 
> ourselves on future technology that maybe will make use of that for most 
> cases, otherwise we will be treating the vast majority of exceptions as the 
> rule.

Handing out a /48 to each end site is a core engineering design that was put 
into IPv6 for many valid reasons.

You continue to rail against it, yet you’ve provided no reason or basis for 
your claim that it is “an exaggeration” or that it is in any way detrimental.

I’ve provided you multiple reasons why /48s are a good and beneficial idea. 
There’s a great deal of IETF history behind the ideal of handing out /48s to 
all end sites.

In general, application and product developers create products for the broadest 
possible user base. This results in products being built to the lowest common 
denominator (or something close to it).

If we restrict networks of the future based on modeling the requirements of 
today, we will forever limit the probability of improvements.

If, on the other hand, we recognize the potential benefits of assigning shorter 
prefixes to end users, we create a future where innovation and creativity can 
bring us products not yet imagined.

In IPv6, it’s not about having enough bits to address each host. It’s not about 
the current model of every host at an end-site being on a single common subnet. 
This model is necessary in IPv4 residential environments due to the 
complexities of administering more sophisticated more capable topologies. In 
IPv6, using core technologies such as DHCP Prefix Delegation, SLAAC, etc. we 
have the foundation to build products that can automate and dynamically create 
and adapt these more capable topologies without requiring manual intervention 
by the user. Concepts which are in their infancy such as intent-based 
networking require wider bit fields to be able to optimally and automatically 
delegate prefixes. Simply put, a 4-bit wide subnet field for a site, even a 
residential site will be utterly and completely inadequate if this future is to 
be realized. An 8-bit wide subnet field will be quite limiting, but may allow 
some innovation. A 16-bit wide field provides a best guess at a good balance 
between the amount of address space consumed and an attempt to avoid limiting 
future innovation.

In terms of any concerns or fears about running out if we use such an address 
allocation policy, consider the following:

1.  Current earth population is approximately 7,000,000,000 (7e9).
2.  Let’s assume that within the lifetime of IPv6 we are somehow 
able to double that population to 14e9.
3.  Let’s further assume that each individual resides in a solitary 
end site (average density is 2.3 humans per household).
4.  Let’s also give each individual a separate /48 for their place 
of work and an additional /48 for their share of the various
services and companies they communicate with as well as network 
infrastructure they use.
5.  If we bake in all of those exaggerated assumptions, we need a 
total of 42e9 /48s.
6.  There are 2^45 /48s in 2000::/3 (the current IETF/IANA 
designated IPv6 GUA pool (which can be expanded several times).
7.  2^25 is 35,184,372,088,832 (more than 35e12).
8.  So, in fact, without exhausting the current pool of address 
space, we can give every individual on earth 6 /48s and we
still only consume 0.1% of 1/8th of the address space, leaving 
99.9% of the current 2000::/3 still available.

There are two ways we can waste address space:

1.  Distribute addresses for no practical purpose (I have shown 
some of the practical purposes of /48s above).
2.  Place artificial limitations on people’s use of 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Fernando Frediani]

On 18/04/2020 17:49, Owen DeLong wrote:

...
It would depend on the nature of the fee waiver. If they perceived it as a 
temporary stall resulting in the same fee increase in 3-5 years, I think you’d 
get mixed results. If it was a permanent “we won’t charge you extra until your 
IPv4 holdings expand or 10+ years, whichever comes first”, I suspect you’d see 
a majority of takers.

As to /48s, hard to say… Certainly, with /40s, they are more likely to be 
hyper-conservative in their assignments than with /36s. I certainly would not 
mind making said waiver conditional on compliance with a /48 PAU.
My view is that this type of waiver should not exist and this type 
situation should not be incentivized.


I see the mentioned "we won't charge you extra until your IPv4 holdings 
expand or 10+ years" as something more interesting.
It is necessary to differentiate when an organization has really grown, 
justify for more space and is able to be paying a higher fee than when 
they just request more and more Ipv6 space because they are giving away 
/48 to everyone indistinctly which in my view is an exaggeration. We 
cannot base ourselves on future technology that maybe will make use of 
that for most cases, otherwise we will be treating the vast majority of 
exceptions as the rule.


Fernando



Owen

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Owen DeLong]

> On Apr 18, 2020, at 06:10 , John Curran  wrote:
> 
> On 18 Apr 2020, at 5:32 AM, Owen DeLong  wrote:
>> Policy as written definitely favors /48s for everyone.
> 
> Owen - 
> 
> To bring it back to the policy matter under discussion, do you expect that 
> ISPs (who presently do not proceed with their IPv6 /36 application due to 
> resulting increase of their annual fees from $250 to $500) would proceed if 
> there were a fee waiver that prevented the increase?  Also, do you believe 
> that these ISPs would indeed be assigning /48’s to customers if given the 
> larger /36 IPv6 allocation and should doing so be a provision of any such fee 
> waiver?

It would depend on the nature of the fee waiver. If they perceived it as a 
temporary stall resulting in the same fee increase in 3-5 years, I think you’d 
get mixed results. If it was a permanent “we won’t charge you extra until your 
IPv4 holdings expand or 10+ years, whichever comes first”, I suspect you’d see 
a majority of takers.

As to /48s, hard to say… Certainly, with /40s, they are more likely to be 
hyper-conservative in their assignments than with /36s. I certainly would not 
mind making said waiver conditional on compliance with a /48 PAU.

Owen

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Andrew Dul]

On 4/18/2020 9:40 AM, hostmas...@uneedus.com wrote:

I look at it this way:

An ISP with only a /24 of IPv4 space only has 254 addresses to hand 
out to its customers.  If they receive a /40 of IPv6 space, they can 
assign up to 256 /48's to its customers, almost an exact match. 
Someone with so little IPv4 either has few customers or is using CGnat.


Something needs to be done to stop that $250 to $500 increase for 
accepting IPv6 in this population, as the facts seem to show that 
these businesses are simply rejecting the future (IPv6) simply because 
of the current ARIN fee schedule. The provided data clearly show the 
majority are rejecting IPv6, likely because of the fees.  The 
population is so small that if there is a question as to why, why not 
drop them an email and ask?


I would have no problem instead simply giving this population a /36 or 
even a /32 at the same $250 price, simply because I think the goal of 
universal IPv6 is worth it.


I support this /40 policy simply because it addresses the identifed 
issue.


I would also support other ideas, such as going ahead and giving them 
the /36 and waving the price increase.


I also would not have a problem changing the fee schedule to be based 
solely on IPv4, or in the alternative maybe not considering IPv6 
holdings at all in the fee schedule unless they exceed a /32, since a 
/32 is effectively the default for ISP members.


I realize that this would effectively make those with no IPv4 holdings 
fit in most cases into the 3x small bucket.


In the end, if we allow /40's, I have no problem allowing those above 
3X Small to use them, even though they would be able to receive more 
under the fee schedules.  I am no understanding as to why they would 
want a smaller allocation, but who am I to question such a decision of 
others.


How many members of ARIN have no IPv4 holdings, but instead have only 
IPv6? 


There are a number of organizations which only have IPv6.  Likely 
because they are legacy organizations and their IPv4 is held as legacy 
and their IPv6 is held in a different org-id.  Slide 9 & 10 from this 
presentation from the last meeting has some details about the number of 
orgs with various holdings.


https://www.arin.net/vault/participate/meetings/reports/ARIN_44/PDF/MEM/sweeting_rsd.pdf

Hope this helps,

Andrew

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[hostmaster]

I look at it this way:

An ISP with only a /24 of IPv4 space only has 254 addresses to hand out to 
its customers.  If they receive a /40 of IPv6 space, they can assign up to 
256 /48's to its customers, almost an exact match. Someone with so little 
IPv4 either has few customers or is using CGnat.


Something needs to be done to stop that $250 to $500 increase for 
accepting IPv6 in this population, as the facts seem to show that these 
businesses are simply rejecting the future (IPv6) simply because of the 
current ARIN fee schedule. The provided data clearly show the majority are 
rejecting IPv6, likely because of the fees.  The population is so small 
that if there is a question as to why, why not drop them an email and ask?


I would have no problem instead simply giving this population a /36 or 
even a /32 at the same $250 price, simply because I think the goal of 
universal IPv6 is worth it.


I support this /40 policy simply because it addresses the identifed issue.

I would also support other ideas, such as going ahead and giving them the 
/36 and waving the price increase.


I also would not have a problem changing the fee schedule to be based 
solely on IPv4, or in the alternative maybe not considering IPv6 holdings 
at all in the fee schedule unless they exceed a /32, since a /32 is 
effectively the default for ISP members.


I realize that this would effectively make those with no IPv4 holdings fit 
in most cases into the 3x small bucket.


In the end, if we allow /40's, I have no problem allowing those above 3X 
Small to use them, even though they would be able to receive more under 
the fee schedules.  I am no understanding as to why they would want a 
smaller allocation, but who am I to question such a decision of others.


How many members of ARIN have no IPv4 holdings, but instead have only 
IPv6?


Albert Erdmann
Network Administrator
Paradise On Line Inc.


On Sat, 18 Apr 2020, John Curran wrote:


On 18 Apr 2020, at 5:32 AM, Owen DeLong  wrote:

Policy as written definitely favors /48s for everyone.


Owen -

To bring it back to the policy matter under discussion, do you expect that ISPs 
(who presently do not proceed with their IPv6 /36 application due to resulting 
increase of their annual fees from $250 to $500) would proceed if there were a 
fee waiver that prevented the increase?  Also, do you believe that these ISPs 
would indeed be assigning /48’s to customers if given the larger /36 IPv6 
allocation and should doing so be a provision of any such fee waiver?

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers


___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[John Curran]

On 18 Apr 2020, at 5:32 AM, Owen DeLong  wrote:
> Policy as written definitely favors /48s for everyone.

Owen - 

To bring it back to the policy matter under discussion, do you expect that ISPs 
(who presently do not proceed with their IPv6 /36 application due to resulting 
increase of their annual fees from $250 to $500) would proceed if there were a 
fee waiver that prevented the increase?  Also, do you believe that these ISPs 
would indeed be assigning /48’s to customers if given the larger /36 IPv6 
allocation and should doing so be a provision of any such fee waiver?

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers


___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Owen DeLong]

> On Apr 18, 2020, at 01:41 , Fernando Frediani  wrote:
> 
> On 18/04/2020 05:26, Owen DeLong wrote:
>> ...
>> 
>> Admittedly, /48s for everyone still isn’t gaining as much traction as we’d 
>> like due to a combination of IPv4-think at some ISPs and other reasons I 
>> have trouble understanding.
> Thankfully it is not !

How so? What’s the advantage to not doing so?

>> 
>> E.G. I once had a discussion with the IPv6 project manager for a major 
>> $CABLECO about why they were sticking it to their residential customers with 
>> a maximum /60 instead of a /48. His answer perplexed me… He said that the 
>> problem was that if they gave out /48s to all their customers the way their 
>> network is structured, they’d need a /12. Now I realize that policy only 
>> allows ARIN to give out a /16 at a time, but I’m quite certain this 
>> particular organization could easily qualify for 16 /16s without any issue 
>> whatsoever. When I pointed this out, he just walked away shaking his head.
> And he is right. I still fail to understand from where this idea of giving 
> residential customers a /48 came from. And this is not thinking with IPv4's 
> mind really.

Really?

What is the benefit to NOT giving residential customers /48s? Please explain it 
to me because so far, I haven’t heard an explanation for this limitation that 
makes any sense.

>> 
>> Now I realize a /12 sounds like a ridiculous amount of space, but if you 
>> think about it, this is an organization that has several /8s worth of IPv4, 
>> so it’s not actually all that far fetched. Also, I seriously doubt that 
>> there are anywhere near 100 organizations with the number of customers this 
>> $CABLECO has. There are 512 /12s in 2000::/3 which is just the first 1/8th 
>> of IPv6 address space designated as GUA (Global Unicast Addresses). The math 
>> works. We have the address space to do this and give everyone /48s without 
>> any issue of running out.
> Well, I hear this every time I talk against this "/48 for all" idea. And I 
> don't think because of this justification 'we have plenty so let's give them' 
> should be broadly and always applied. Give people whatever is reasonable for 
> their usage, but not a tremendous exaggeration. And a /48 for a residential 
> customer is an exaggeration that will hardly ever be used. If one day this 
> changes we can adapt to the new scenario.
> 
That’s not the justification. That’s the rebuttal to the IPv4-Think mentality 
of let’s pretend there’s scarcity and put unnecessary limitations in place as a 
result.

The reason we want /48s everywhere is so that future applications involving 
automatic topologies with multiple layers of DHCP-PD can be brought to 
fruition. So that in-home network segmentation without user intervention can 
eventually become a reality. So that we can actually develop plug-and-play 
secure networking with proper segmentation working in an automated fashion.

You simply cannot do that with a  /60. It’s marginal with a /56 and you run 
into a number of walls.


>> 
>> So… we have a circumstance of competing tradeoffs in policy:
>> 
>>  1.  We don’t want policy to create perverse incentives to not give 
>> /48s to customers. That’s one of the reasons
>>  for the particular wording of the PAU text in the IPv6 ISP 
>> policy (which staff doesn’t do a particularly good
>>  job of following in my observation).
>> 
>>  2.  We don’t want to create economic disincentives to IPv6 
>> deployment.
> I can see the intents of this proposal specially for point 2 and perhaps 
> there are adjustments to be done, but certainly not with the idea of giving 
> /48 everywhere in mind.
> 
Well… I think policy and engineering wise, you’re in the minority (fortunately).

Policy as written definitely favors /48s for everyone.

Owen

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Fernando Frediani]

On 18/04/2020 05:26, Owen DeLong wrote:

...

Admittedly, /48s for everyone still isn’t gaining as much traction as 
we’d like due to a combination of IPv4-think at some ISPs and other 
reasons I have trouble understanding.

Thankfully it is not !


E.G. I once had a discussion with the IPv6 project manager for a major 
$CABLECO about why they were sticking it to their residential 
customers with a maximum /60 instead of a /48. His answer perplexed 
me… He said that the problem was that if they gave out /48s to all 
their customers the way their network is structured, they’d need a 
/12. Now I realize that policy only allows ARIN to give out a /16 at a 
time, but I’m quite certain this particular organization could easily 
qualify for 16 /16s without any issue whatsoever. When I pointed this 
out, he just walked away shaking his head.
And he is right. I still fail to understand from where this idea of 
giving residential customers a /48 came from. And this is not thinking 
with IPv4's mind really.


Now I realize a /12 sounds like a ridiculous amount of space, but if 
you think about it, this is an organization that has several /8s worth 
of IPv4, so it’s not actually all that far fetched. Also, I seriously 
doubt that there are anywhere near 100 organizations with the number 
of customers this $CABLECO has. There are 512 /12s in 2000::/3 which 
is just the first 1/8th of IPv6 address space designated as GUA 
(Global Unicast Addresses). The math works. We have the address space 
to do this and give everyone /48s without any issue of running out.


Well, I hear this every time I talk against this "/48 for all" idea. And 
I don't think because of this justification 'we have plenty so let's 
give them' should be broadly and always applied. Give people whatever is 
reasonable for their usage, but not a tremendous exaggeration. And a /48 
for a residential customer is an exaggeration that will hardly ever be 
used. If one day this changes we can adapt to the new scenario.




So… we have a circumstance of competing tradeoffs in policy:

1.We don’t want policy to create perverse incentives to not give /48s 
to customers. That’s one of the reasons
for the particular wording of the PAU text in the IPv6 ISP policy 
(which staff doesn’t do a particularly good

job of following in my observation).

2.We don’t want to create economic disincentives to IPv6 deployment.


I can see the intents of this proposal specially for point 2 and perhaps 
there are adjustments to be done, but certainly not with the idea of 
giving /48 everywhere in mind.


Fernando






___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Owen DeLong]

> On Apr 16, 2020, at 08:42 , John Curran  wrote:
> 
> On 24 Mar 2020, at 1:20 PM, ARIN mailto:i...@arin.net>> wrote:
>> ...
>> Reserving /40s only for organizations initially expanding into IPv6 from an 
>> initial sliver of IPv4 space will help to narrowly address the problem 
>> observed by Registration Services while avoiding unintended consequences by 
>> accidentally giving a discount for undersized allocations.
> 
> ARIN tries to provide as much flexibility as possible in dealing with 
> requests, so it is important that the community document the reasoning behind 
> policy language that constrains the choices available to those requesting 
> resources.   ARIN staff will certainly get asked about such restrictions, so 
> we best understand the motivation. 
> 
> For this reason, would it be possible for the advocates of the policy to 
> elaborate (on the list) on the perceived "unintended consequences by 
> accidentally giving a discount for undersized allocations”?   (In particular, 
> if a party specifically sought a /40 IPv6 allocation but they held more than 
> /24 of IPv4, is the desire that ARIN would deny the request if they failed to 
> agree to a larger IPv6 allocation or agree to divesture of IPv4 resources 
> down to the /24 maximum?) 

Frankly, I wouldn’t even want to allow access to this option through 
divestiture of their IPv4 holdings.

I look at it this way.. Originally, we wanted ISPs to have a minimum /32 in 
order to maximize aggregation while still providing reasonably good support for 
handing out /48s to every subscriber end site regardless of size.

Then, because there were unintended consequences of IPv4<->IPv6 fee structure 
alignment, we put in place a mechanism to allow that down to /36 if the ISP 
really wanted to do that to avoid the fee increase.

Now, we’re talking about going down another nibble.

A /40 is only 256 /48s and you have to account for the ISPs infrastructure 
within that too.

For an ISP running their entire customer base on a single /24, that might not 
have any unintended consequences, but even in that case, there’s the risk that 
said ISP has more than a couple hundred customers behind that /24 via various 
forms of address sharing (NAT and worse), in which case a /40 simply won’t 
provide the desired IPv6 policy outcome of /48s for everyone.

Admittedly, /48s for everyone still isn’t gaining as much traction as we’d like 
due to a combination of IPv4-think at some ISPs and other reasons I have 
trouble understanding.

E.G. I once had a discussion with the IPv6 project manager for a major $CABLECO 
about why they were sticking it to their residential customers with a maximum 
/60 instead of a /48. His answer perplexed me… He said that the problem was 
that if they gave out /48s to all their customers the way their network is 
structured, they’d need a /12. Now I realize that policy only allows ARIN to 
give out a /16 at a time, but I’m quite certain this particular organization 
could easily qualify for 16 /16s without any issue whatsoever. When I pointed 
this out, he just walked away shaking his head.

Now I realize a /12 sounds like a ridiculous amount of space, but if you think 
about it, this is an organization that has several /8s worth of IPv4, so it’s 
not actually all that far fetched. Also, I seriously doubt that there are 
anywhere near 100 organizations with the number of customers this $CABLECO has. 
There are 512 /12s in 2000::/3 which is just the first 1/8th of IPv6 address 
space designated as GUA (Global Unicast Addresses). The math works. We have the 
address space to do this and give everyone /48s without any issue of running 
out.

So… we have a circumstance of competing tradeoffs in policy:

1.  We don’t want policy to create perverse incentives to not give 
/48s to customers. That’s one of the reasons
for the particular wording of the PAU text in the IPv6 ISP 
policy (which staff doesn’t do a particularly good
job of following in my observation).

2.  We don’t want to create economic disincentives to IPv6 
deployment.

This policy is an effort to reduce issue number 2 at the cost of potentially 
exacerbating issue number 1. We’d very much like to minimize the extent to 
which that unintended exacerbation of issue number 1 occurs.

Owen

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[William Herrin]

On Thu, Apr 16, 2020 at 8:42 AM John Curran  wrote:
> ARIN tries to provide as much flexibility as possible in dealing with 
> requests, so it is important that the community document the reasoning behind 
> policy language that constrains the choices available to those requesting 
> resources.   ARIN staff will certainly get asked about such restrictions, so 
> we best understand the motivation.


Hi John,

My problem with the proposal is that it extends an ARIN practice which
is not technically sound, namely allocating less than 2^96 IPv6
addresses to ISPs, all in order to solve what is frankly a stupid
billing problem. With it's fee selection, ARIN has needlessly
exacerbated a chicken-and-egg problem where the fees obstruct the
adoption of IPv6 which prevents the resources from gaining the value
that would justify the fees. The correct solution to the problem is:
don't do that. Just stop.

ARIN has itself twisted in a knot around the idea that IPv6 billing
has to be equitable in relation to the other number resources *right
now*. It does not, and these goofy efforts to make it so have harmed
the community for something like a decade now.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/
___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Brian Jones]

No one is going to want to sell off their v4 space and if they did they
could certainly afford the IPv6 allocation charges. Possibly the
presentation of this option could change their view? They certainly need to
understand the importance of beginning to use IPv6...

—
Brian


On Thu, Apr 16, 2020 at 11:42 AM John Curran  wrote:

> On 24 Mar 2020, at 1:20 PM, ARIN  wrote:
>
> ...
> Reserving /40s only for organizations initially expanding into IPv6 from
> an initial sliver of IPv4 space will help to narrowly address the problem
> observed by Registration Services while avoiding unintended consequences by
> accidentally giving a discount for undersized allocations.
>
>
> ARIN tries to provide as much flexibility as possible in dealing with
> requests, so it is important that the community document the reasoning
> behind policy language that constrains the choices available to those
> requesting resources.   ARIN staff will certainly get asked about such
> restrictions, so we best understand the motivation.
>
> For this reason, would it be possible for the advocates of the policy to
> elaborate (on the list) on the perceived "unintended consequences by
> accidentally giving a discount for undersized allocations”?   (In
> particular, if a party specifically sought a /40 IPv6 allocation but they
> held more than /24 of IPv4, is the desire that ARIN would deny the request
> if they failed to agree to a larger IPv6 allocation or agree to divesture
> of IPv4 resources down to the /24 maximum?)
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
> ___
> ARIN-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:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[John Curran]

On 24 Mar 2020, at 1:20 PM, ARIN mailto:i...@arin.net>> wrote:
...
Reserving /40s only for organizations initially expanding into IPv6 from an 
initial sliver of IPv4 space will help to narrowly address the problem observed 
by Registration Services while avoiding unintended consequences by accidentally 
giving a discount for undersized allocations.

ARIN tries to provide as much flexibility as possible in dealing with requests, 
so it is important that the community document the reasoning behind policy 
language that constrains the choices available to those requesting resources.   
ARIN staff will certainly get asked about such restrictions, so we best 
understand the motivation.

For this reason, would it be possible for the advocates of the policy to 
elaborate (on the list) on the perceived "unintended consequences by 
accidentally giving a discount for undersized allocations”?   (In particular, 
if a party specifically sought a /40 IPv6 allocation but they held more than 
/24 of IPv4, is the desire that ARIN would deny the request if they failed to 
agree to a larger IPv6 allocation or agree to divesture of IPv4 resources down 
to the /24 maximum?)

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[hostmaster]

Looks to me not some but MOST.  I agree, we should not put a fee doubling 
in the way of these 3x folks doing the right thing and getting IPv6.


Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Thu, 16 Apr 2020, Brian Jones wrote:


Looking at the numbers John posted concerning this issue, it tends to look like 
some of these 3x small folks decided to drop their request once they
encountered the price increase. If this is the case then we should move forward 
with this proposal. We do not want to create a situation where folks are
continuing to use only IPv4 because of costs.

I support this proposal.

—
Brian


On Thu, Apr 16, 2020 at 7:19 AM  wrote:
  Is that very much because they found out if they accepted the IPv6 space,
  their fees would double???

  If so, this PROVES the need to adopt this plan.  We should not have things
  in place that prevent IPv6 adoption.  We have already decided that IPv6
  should be cost neutral.  Lets fix this glitch and let these 3x small
  people have IPv6 without doubling their cost.

  Albert Erdmann
  Network Administrator
  Paradise On Line Inc.

  On Thu, 16 Apr 2020, John Sweeting wrote:

  > Yes that is exactly what it means. After approval they decided for 
whatever reason they no longer wanted the resource.
  >
  > Sent from my iPhone
  >
  >> On Apr 16, 2020, at 1:56 AM, John Santos  wrote:
  >>
  >> What does "closed with no action" mean?  Does it mean the RSP 
abandoned the request?
  >>
  >>
  >>> On 4/15/2020 7:18 PM, John Sweeting wrote:
  >>> Hi Andrew,
  >>>
  >>> The numbers around this are:
  >>>
  >>> 320 3x small RSPs
  >>> 30 have applied and been approved for IPv6 of which 26 closed with no 
action to complete by the requester. The other 4 are currently still
  open and pending action.
  >>>
  >>> Thanks,
  >>> John S.
  >>>
  >>> On 4/15/20, 11:30 AM, "Andrew Dul"  wrote:
  >>>
  >>>     John,
  >>>          Could you provide the community with a rough magnitude of 
this issue?
  >>>          Approximately how many of these 3x-small ISP organizations 
have come to
  >>>     ARIN and requested IPv6?  How many accepted the block and how many
  >>>     refused because of the fee issue?  How many 3x-small ISP 
organizations
  >>>     does ARIN currently serve.
  >>>          Thanks,
  >>>     Andrew
  >>>          On 4/14/2020 2:29 PM, John Sweeting wrote:
  >>>    > All,
  >>>    >
  >>>    > For anyone interested in the content of the "Policy Experience 
Report presented by Registration
  >>>    > Services to the AC at its annual workshop in January 2020" 
referenced in the problem statement you can see that report here:
  >>>    >
  >>>    > 
https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
  >>>    >
  >>>    > Thank you.
  >>>    >
  >>>    > On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" 
 wrote:
  >>>    >
  >>>    >     On 19 March 2020, the ARIN Advisory Council (AC) accepted
  >>>    >     "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
  >>>    >
  >>>    >     Draft Policy ARIN-2020-3 is below and can be found at:
  >>>    >
  >>>    >     https://www.arin.net/participate/policy/drafts/2020_3/
  >>>    >
  >>>    >     You are encouraged to discuss all Draft Policies on PPML. 
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 Policy Development Process (PDP). 
Specifically, these
  >>>    >     principles are:
  >>>    >
  >>>    >     * Enabling Fair and Impartial Number Resource Administration
  >>>    >     * Technically Sound
  >>>    >     * Supported by the Community
  >>>    >
  >>>    >     The PDP can be found at:
  >>>    >     https://www.arin.net/participate/policy/pdp/
  >>>    >
  >>>    >     Draft Policies and Proposals under discussion can be found 
at:
  >>>    >     https://www.arin.net/participate/policy/drafts/
  >>>    >
  >>>    >     Regards,
  >>>    >
  >>>    >     Sean Hopkins
  >>>    >     Policy Analyst
  >>>    >     American Registry for Internet Numbers (ARIN)
  >>>    >
  >>>    >
  >>>    >
  >>>    >     Draft Policy ARIN-2020-3: IPv6 Nano-allocations
  >>>    >
  >>>    >     Problem Statement:
  >>>    >
  >>>    >     ARIN's fee structure provides a graduated system wherein 
organizations
  >>>    >     pay based on the amount of number resources they consume.
  >>>    >
  >>>    >     In the case of the very smallest ISPs, if a 3X-Small ISP 
(with a /24 or
  >>>    >     smaller of IPv4) gets the present 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[John Santos]

Support


On 4/16/2020 10:32 AM, Brian Jones wrote:
Looking at the numbers John posted concerning this issue, it tends to /look 
like/ some of these 3x small folks decided to drop their request once they 
encountered the price increase. If this is the case then we should move 
forward with this proposal. We do not want to create a situation where folks 
are continuing to use only IPv4 because of costs.


I support this proposal.

—
Brian


On Thu, Apr 16, 2020 at 7:19 AM > wrote:


Is that very much because they found out if they accepted the IPv6 space,
their fees would double???

If so, this PROVES the need to adopt this plan.  We should not have things
in place that prevent IPv6 adoption.  We have already decided that IPv6
should be cost neutral.  Lets fix this glitch and let these 3x small
people have IPv6 without doubling their cost.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Thu, 16 Apr 2020, John Sweeting wrote:

> Yes that is exactly what it means. After approval they decided for
whatever reason they no longer wanted the resource.
>
> Sent from my iPhone
>
>> On Apr 16, 2020, at 1:56 AM, John Santos mailto:j...@egh.com>> wrote:
>>
>> What does "closed with no action" mean?  Does it mean the RSP
abandoned the request?
>>
>>
>>> On 4/15/2020 7:18 PM, John Sweeting wrote:
>>> Hi Andrew,
>>>
>>> The numbers around this are:
>>>
>>> 320 3x small RSPs
>>> 30 have applied and been approved for IPv6 of which 26 closed with no
action to complete by the requester. The other 4 are currently still open
and pending action.
>>>
>>> Thanks,
>>> John S.
>>>
>>> On 4/15/20, 11:30 AM, "Andrew Dul" mailto:andrew@quark.net>> wrote:
>>>
>>>     John,
>>>          Could you provide the community with a rough magnitude of
this issue?
>>>          Approximately how many of these 3x-small ISP organizations
have come to
>>>     ARIN and requested IPv6?  How many accepted the block and how many
>>>     refused because of the fee issue?  How many 3x-small ISP 
organizations
>>>     does ARIN currently serve.
>>>          Thanks,
>>>     Andrew
>>>          On 4/14/2020 2:29 PM, John Sweeting wrote:
>>>    > All,
>>>    >
>>>    > For anyone interested in the content of the "Policy Experience
Report presented by Registration
>>>    > Services to the AC at its annual workshop in January 2020"
referenced in the problem statement you can see that report here:
>>>    >
>>>    >

https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
>>>    >
>>>    > Thank you.
>>>    >
>>>    > On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN"
mailto:arin-ppml-boun...@arin.net> on behalf
of i...@arin.net > wrote:
>>>    >
>>>    >     On 19 March 2020, the ARIN Advisory Council (AC) accepted
>>>    >     "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
>>>    >
>>>    >     Draft Policy ARIN-2020-3 is below and can be found at:
>>>    >
>>>    > https://www.arin.net/participate/policy/drafts/2020_3/
>>>    >
>>>    >     You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically,
these
>>>    >     principles are:
>>>    >
>>>    >     * Enabling Fair and Impartial Number Resource Administration
>>>    >     * Technically Sound
>>>    >     * Supported by the Community
>>>    >
>>>    >     The PDP can be found at:
>>>    > https://www.arin.net/participate/policy/pdp/
>>>    >
>>>    >     Draft Policies and Proposals under discussion can be found at:
>>>    > https://www.arin.net/participate/policy/drafts/
>>>    >
>>>    >     Regards,
>>>    >
>>>    >     Sean Hopkins
>>>    >     Policy Analyst
>>>    >     American Registry for Internet Numbers (ARIN)
>>>    >
>>>    >
>>>    >
>>>    >     Draft Policy ARIN-2020-3: IPv6 Nano-allocations
>>>    >
>>>    >     Problem Statement:
>>>    >
>>>    >     ARIN's fee structure provides a graduated system wherein
organizations
>>>    >     pay based on the amount of number resources they consume.
>>>    >
>>>    >     In the case of the very smallest ISPs, if a 3X-Small ISP
(with a /24 or
>>>    >     smaller of IPv4) gets the present minimal-sized IPv6
allocation (a /36),
>>>    >     its annual fees will double from $250 to $500/year.
>>>    >
>>>    >     According to a Policy 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Brian Jones]

Looking at the numbers John posted concerning this issue, it tends to *look
like* some of these 3x small folks decided to drop their request once they
encountered the price increase. If this is the case then we should move
forward with this proposal. We do not want to create a situation where
folks are continuing to use only IPv4 because of costs.

I support this proposal.

—
Brian


On Thu, Apr 16, 2020 at 7:19 AM  wrote:

> Is that very much because they found out if they accepted the IPv6 space,
> their fees would double???
>
> If so, this PROVES the need to adopt this plan.  We should not have things
> in place that prevent IPv6 adoption.  We have already decided that IPv6
> should be cost neutral.  Lets fix this glitch and let these 3x small
> people have IPv6 without doubling their cost.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Thu, 16 Apr 2020, John Sweeting wrote:
>
> > Yes that is exactly what it means. After approval they decided for
> whatever reason they no longer wanted the resource.
> >
> > Sent from my iPhone
> >
> >> On Apr 16, 2020, at 1:56 AM, John Santos  wrote:
> >>
> >> What does "closed with no action" mean?  Does it mean the RSP
> abandoned the request?
> >>
> >>
> >>> On 4/15/2020 7:18 PM, John Sweeting wrote:
> >>> Hi Andrew,
> >>>
> >>> The numbers around this are:
> >>>
> >>> 320 3x small RSPs
> >>> 30 have applied and been approved for IPv6 of which 26 closed with no
> action to complete by the requester. The other 4 are currently still open
> and pending action.
> >>>
> >>> Thanks,
> >>> John S.
> >>>
> >>> On 4/15/20, 11:30 AM, "Andrew Dul"  wrote:
> >>>
> >>> John,
> >>>  Could you provide the community with a rough magnitude of
> this issue?
> >>>  Approximately how many of these 3x-small ISP organizations
> have come to
> >>> ARIN and requested IPv6?  How many accepted the block and how many
> >>> refused because of the fee issue?  How many 3x-small ISP
> organizations
> >>> does ARIN currently serve.
> >>>  Thanks,
> >>> Andrew
> >>>  On 4/14/2020 2:29 PM, John Sweeting wrote:
> >>>> All,
> >>>>
> >>>> For anyone interested in the content of the "Policy Experience
> Report presented by Registration
> >>>> Services to the AC at its annual workshop in January 2020"
> referenced in the problem statement you can see that report here:
> >>>>
> >>>>
> https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
> >>>>
> >>>> Thank you.
> >>>>
> >>>> On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" <
> arin-ppml-boun...@arin.net on behalf of i...@arin.net> wrote:
> >>>>
> >>>> On 19 March 2020, the ARIN Advisory Council (AC) accepted
> >>>> "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
> >>>>
> >>>> Draft Policy ARIN-2020-3 is below and can be found at:
> >>>>
> >>>> https://www.arin.net/participate/policy/drafts/2020_3/
> >>>>
> >>>> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically,
> these
> >>>> principles are:
> >>>>
> >>>> * Enabling Fair and Impartial Number Resource Administration
> >>>> * Technically Sound
> >>>> * Supported by the Community
> >>>>
> >>>> The PDP can be found at:
> >>>> https://www.arin.net/participate/policy/pdp/
> >>>>
> >>>> Draft Policies and Proposals under discussion can be found at:
> >>>> https://www.arin.net/participate/policy/drafts/
> >>>>
> >>>> Regards,
> >>>>
> >>>> Sean Hopkins
> >>>> Policy Analyst
> >>>> American Registry for Internet Numbers (ARIN)
> >>>>
> >>>>
> >>>>
> >>>> Draft Policy ARIN-2020-3: IPv6 Nano-allocations
> >>>>
> >>>> Problem Statement:
> >>>>
> >>>> ARIN's fee structure provides a graduated system wherein
> organizations
> >>>> pay based on the amount of number resources they consume.
> >>>>
> >>>> In the case of the very smallest ISPs, if a 3X-Small ISP
> (with a /24 or
> >>>> smaller of IPv4) gets the present minimal-sized IPv6
> allocation (a /36),
> >>>> its annual fees will double from $250 to $500/year.
> >>>>
> >>>> According to a Policy Experience Report presented by
> Registration
> >>>> Services to the AC at its annual workshop in January 2020,
> this
> >>>> represents a disincentive to IPv6 adoption with a substantial
> fraction
> >>>> of so-situated ISPs saying "no thanks" and abandoning their
> request for
> >>>> IPv6 number resources when informed of the impact on their
> annual 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Andrew Dul]

When in the application process are the isps informed that their fees will 
increase if they accept the ipv6 block?  Is that in the ipv6 approved email and 
then the tickets are abandoned?

.Andrew

> On Apr 16, 2020, at 4:19 AM, hostmas...@uneedus.com wrote:
> 
> Is that very much because they found out if they accepted the IPv6 space, 
> their fees would double???
> 
> If so, this PROVES the need to adopt this plan.  We should not have things in 
> place that prevent IPv6 adoption.  We have already decided that IPv6 should 
> be cost neutral.  Lets fix this glitch and let these 3x small people have 
> IPv6 without doubling their cost.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
>> On Thu, 16 Apr 2020, John Sweeting wrote:
>> 
>> Yes that is exactly what it means. After approval they decided for whatever 
>> reason they no longer wanted the resource.
>> 
>> Sent from my iPhone
>> 
>>> On Apr 16, 2020, at 1:56 AM, John Santos  wrote:
>>> 
>>> What does "closed with no action" mean?  Does it mean the RSP abandoned 
>>> the request?
>>> 
>>> 
 On 4/15/2020 7:18 PM, John Sweeting wrote:
 Hi Andrew,
 
 The numbers around this are:
 
 320 3x small RSPs
 30 have applied and been approved for IPv6 of which 26 closed with no 
 action to complete by the requester. The other 4 are currently still open 
 and pending action.
 
 Thanks,
 John S.
 
 On 4/15/20, 11:30 AM, "Andrew Dul"  wrote:
 
John,
 Could you provide the community with a rough magnitude of this 
 issue?
 Approximately how many of these 3x-small ISP organizations have 
 come to
ARIN and requested IPv6?  How many accepted the block and how many
refused because of the fee issue?  How many 3x-small ISP organizations
does ARIN currently serve.
 Thanks,
Andrew
 On 4/14/2020 2:29 PM, John Sweeting wrote:
   > All,
   >
   > For anyone interested in the content of the "Policy Experience Report 
 presented by Registration
   > Services to the AC at its annual workshop in January 2020" referenced 
 in the problem statement you can see that report here:
   >
   > 
 https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
   >
   > Thank you.
   >
   > On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" 
  wrote:
   >
   > On 19 March 2020, the ARIN Advisory Council (AC) accepted
   > "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
   >
   > Draft Policy ARIN-2020-3 is below and can be found at:
   >
   > https://www.arin.net/participate/policy/drafts/2020_3/
   >
   > You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these
   > principles are:
   >
   > * Enabling Fair and Impartial Number Resource Administration
   > * Technically Sound
   > * Supported by the Community
   >
   > The PDP can be found at:
   > https://www.arin.net/participate/policy/pdp/
   >
   > Draft Policies and Proposals under discussion can be found at:
   > https://www.arin.net/participate/policy/drafts/
   >
   > Regards,
   >
   > Sean Hopkins
   > Policy Analyst
   > American Registry for Internet Numbers (ARIN)
   >
   >
   >
   > Draft Policy ARIN-2020-3: IPv6 Nano-allocations
   >
   > Problem Statement:
   >
   > ARIN's fee structure provides a graduated system wherein 
 organizations
   > pay based on the amount of number resources they consume.
   >
   > In the case of the very smallest ISPs, if a 3X-Small ISP (with a 
 /24 or
   > smaller of IPv4) gets the present minimal-sized IPv6 allocation (a 
 /36),
   > its annual fees will double from $250 to $500/year.
   >
   > According to a Policy Experience Report presented by Registration
   > Services to the AC at its annual workshop in January 2020, this
   > represents a disincentive to IPv6 adoption with a substantial 
 fraction
   > of so-situated ISPs saying "no thanks" and abandoning their 
 request for
   > IPv6 number resources when informed of the impact on their annual 
 fees.
   >
   > This can be addressed by rewriting subsection 6.5.2(b). Initial
   > Allocation Size to allow allocation of a /40 to only the smallest 
 ISPs
   > upon request, and adding a new clause 6.5.2(g) to cause an 
 automatic
   > upgrade to at 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[hostmaster]

Is that very much because they found out if they accepted the IPv6 space, 
their fees would double???


If so, this PROVES the need to adopt this plan.  We should not have things 
in place that prevent IPv6 adoption.  We have already decided that IPv6 
should be cost neutral.  Lets fix this glitch and let these 3x small 
people have IPv6 without doubling their cost.


Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Thu, 16 Apr 2020, John Sweeting wrote:


Yes that is exactly what it means. After approval they decided for whatever 
reason they no longer wanted the resource.

Sent from my iPhone


On Apr 16, 2020, at 1:56 AM, John Santos  wrote:

What does "closed with no action" mean?  Does it mean the RSP abandoned the 
request?



On 4/15/2020 7:18 PM, John Sweeting wrote:
Hi Andrew,

The numbers around this are:

320 3x small RSPs
30 have applied and been approved for IPv6 of which 26 closed with no action to 
complete by the requester. The other 4 are currently still open and pending 
action.

Thanks,
John S.

On 4/15/20, 11:30 AM, "Andrew Dul"  wrote:

John,
 Could you provide the community with a rough magnitude of this issue?
 Approximately how many of these 3x-small ISP organizations have come to
ARIN and requested IPv6?  How many accepted the block and how many
refused because of the fee issue?  How many 3x-small ISP organizations
does ARIN currently serve.
 Thanks,
Andrew
 On 4/14/2020 2:29 PM, John Sweeting wrote:
   > All,
   >
   > For anyone interested in the content of the "Policy Experience Report 
presented by Registration
   > Services to the AC at its annual workshop in January 2020" referenced in 
the problem statement you can see that report here:
   >
   > 
https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
   >
   > Thank you.
   >
   > On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" 
 wrote:
   >
   > On 19 March 2020, the ARIN Advisory Council (AC) accepted
   > "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
   >
   > Draft Policy ARIN-2020-3 is below and can be found at:
   >
   > https://www.arin.net/participate/policy/drafts/2020_3/
   >
   > You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these
   > principles are:
   >
   > * Enabling Fair and Impartial Number Resource Administration
   > * Technically Sound
   > * Supported by the Community
   >
   > The PDP can be found at:
   > https://www.arin.net/participate/policy/pdp/
   >
   > Draft Policies and Proposals under discussion can be found at:
   > https://www.arin.net/participate/policy/drafts/
   >
   > Regards,
   >
   > Sean Hopkins
   > Policy Analyst
   > American Registry for Internet Numbers (ARIN)
   >
   >
   >
   > Draft Policy ARIN-2020-3: IPv6 Nano-allocations
   >
   > Problem Statement:
   >
   > ARIN's fee structure provides a graduated system wherein organizations
   > pay based on the amount of number resources they consume.
   >
   > In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or
   > smaller of IPv4) gets the present minimal-sized IPv6 allocation (a 
/36),
   > its annual fees will double from $250 to $500/year.
   >
   > According to a Policy Experience Report presented by Registration
   > Services to the AC at its annual workshop in January 2020, this
   > represents a disincentive to IPv6 adoption with a substantial fraction
   > of so-situated ISPs saying "no thanks" and abandoning their request for
   > IPv6 number resources when informed of the impact on their annual fees.
   >
   > This can be addressed by rewriting subsection 6.5.2(b). Initial
   > Allocation Size to allow allocation of a /40 to only the smallest ISPs
   > upon request, and adding a new clause 6.5.2(g) to cause an automatic
   > upgrade to at least a /36 in the case where the ISP is no longer 
3X-Small.
   >
   > Reserving /40s only for organizations initially expanding into IPv6 
from
   > an initial sliver of IPv4 space will help to narrowly address the
   > problem observed by Registration Services while avoiding unintended
   > consequences by accidentally giving a discount for undersized 
allocations.
   >
   > Policy Statement:
   >
   > Replace the current 6.5.2(b) with the following:
   >
   > b. In no case shall an LIR receive smaller than a /32 unless they
   > specifically request a /36 or /40.
   >
   > In order to be eligible for a /40, an ISP must meet the following
   > requirements:
   >   * Hold IPv4 direct allocations totaling a /24 or less (to 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[John Sweeting]

Yes that is exactly what it means. After approval they decided for whatever 
reason they no longer wanted the resource. 

Sent from my iPhone

> On Apr 16, 2020, at 1:56 AM, John Santos  wrote:
> 
> What does "closed with no action" mean?  Does it mean the RSP abandoned the 
> request?
> 
> 
>> On 4/15/2020 7:18 PM, John Sweeting wrote:
>> Hi Andrew,
>> 
>> The numbers around this are:
>> 
>> 320 3x small RSPs
>> 30 have applied and been approved for IPv6 of which 26 closed with no action 
>> to complete by the requester. The other 4 are currently still open and 
>> pending action.
>> 
>> Thanks,
>> John S.
>> 
>> On 4/15/20, 11:30 AM, "Andrew Dul"  wrote:
>> 
>> John,
>>  Could you provide the community with a rough magnitude of this 
>> issue?
>>  Approximately how many of these 3x-small ISP organizations have 
>> come to
>> ARIN and requested IPv6?  How many accepted the block and how many
>> refused because of the fee issue?  How many 3x-small ISP organizations
>> does ARIN currently serve.
>>  Thanks,
>> Andrew
>>  On 4/14/2020 2:29 PM, John Sweeting wrote:
>> > All,
>> >
>> > For anyone interested in the content of the "Policy Experience Report 
>> presented by Registration
>> > Services to the AC at its annual workshop in January 2020" referenced 
>> in the problem statement you can see that report here:
>> >
>> > 
>> https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
>> >
>> > Thank you.
>> >
>> > On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" 
>>  wrote:
>> >
>> > On 19 March 2020, the ARIN Advisory Council (AC) accepted
>> > "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
>> >
>> > Draft Policy ARIN-2020-3 is below and can be found at:
>> >
>> > https://www.arin.net/participate/policy/drafts/2020_3/
>> >
>> > You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these
>> > principles are:
>> >
>> > * Enabling Fair and Impartial Number Resource Administration
>> > * Technically Sound
>> > * Supported by the Community
>> >
>> > The PDP can be found at:
>> > https://www.arin.net/participate/policy/pdp/
>> >
>> > Draft Policies and Proposals under discussion can be found at:
>> > https://www.arin.net/participate/policy/drafts/
>> >
>> > Regards,
>> >
>> > Sean Hopkins
>> > Policy Analyst
>> > American Registry for Internet Numbers (ARIN)
>> >
>> >
>> >
>> > Draft Policy ARIN-2020-3: IPv6 Nano-allocations
>> >
>> > Problem Statement:
>> >
>> > ARIN's fee structure provides a graduated system wherein 
>> organizations
>> > pay based on the amount of number resources they consume.
>> >
>> > In the case of the very smallest ISPs, if a 3X-Small ISP (with a 
>> /24 or
>> > smaller of IPv4) gets the present minimal-sized IPv6 allocation (a 
>> /36),
>> > its annual fees will double from $250 to $500/year.
>> >
>> > According to a Policy Experience Report presented by Registration
>> > Services to the AC at its annual workshop in January 2020, this
>> > represents a disincentive to IPv6 adoption with a substantial 
>> fraction
>> > of so-situated ISPs saying "no thanks" and abandoning their 
>> request for
>> > IPv6 number resources when informed of the impact on their annual 
>> fees.
>> >
>> > This can be addressed by rewriting subsection 6.5.2(b). Initial
>> > Allocation Size to allow allocation of a /40 to only the smallest 
>> ISPs
>> > upon request, and adding a new clause 6.5.2(g) to cause an 
>> automatic
>> > upgrade to at least a /36 in the case where the ISP is no longer 
>> 3X-Small.
>> >
>> > Reserving /40s only for organizations initially expanding into 
>> IPv6 from
>> > an initial sliver of IPv4 space will help to narrowly address the
>> > problem observed by Registration Services while avoiding unintended
>> > consequences by accidentally giving a discount for undersized 
>> allocations.
>> >
>> > Policy Statement:
>> >
>> > Replace the current 6.5.2(b) with the following:
>> >
>> > b. In no case shall an LIR receive smaller than a /32 unless they
>> > specifically request a /36 or /40.
>> >
>> > In order to be eligible for a /40, an ISP must meet the following
>> > requirements:
>> >   * Hold IPv4 direct allocations totaling a /24 or less (to 
>> include 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[John Santos]

What does "closed with no action" mean?  Does it mean the RSP abandoned the 
request?


On 4/15/2020 7:18 PM, John Sweeting wrote:

Hi Andrew,

The numbers around this are:

320 3x small RSPs
30 have applied and been approved for IPv6 of which 26 closed with no action to 
complete by the requester. The other 4 are currently still open and pending 
action.

Thanks,
John S.

On 4/15/20, 11:30 AM, "Andrew Dul"  wrote:

 John,
 
 Could you provide the community with a rough magnitude of this issue?
 
 Approximately how many of these 3x-small ISP organizations have come to

 ARIN and requested IPv6?  How many accepted the block and how many
 refused because of the fee issue?  How many 3x-small ISP organizations
 does ARIN currently serve.
 
 Thanks,

 Andrew
 
 On 4/14/2020 2:29 PM, John Sweeting wrote:

 > All,
 >
 > For anyone interested in the content of the "Policy Experience Report 
presented by Registration
 > Services to the AC at its annual workshop in January 2020" referenced in 
the problem statement you can see that report here:
 >
 > 
https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
 >
 > Thank you.
 >
 > On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" 
 wrote:
 >
 > On 19 March 2020, the ARIN Advisory Council (AC) accepted
 > "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
 >
 > Draft Policy ARIN-2020-3 is below and can be found at:
 >
 > https://www.arin.net/participate/policy/drafts/2020_3/
 >
 > You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these
 > principles are:
 >
 > * Enabling Fair and Impartial Number Resource Administration
 > * Technically Sound
 > * Supported by the Community
 >
 > The PDP can be found at:
 > https://www.arin.net/participate/policy/pdp/
 >
 > Draft Policies and Proposals under discussion can be found at:
 > https://www.arin.net/participate/policy/drafts/
 >
 > Regards,
 >
 > Sean Hopkins
 > Policy Analyst
 > American Registry for Internet Numbers (ARIN)
 >
 >
 >
 > Draft Policy ARIN-2020-3: IPv6 Nano-allocations
 >
 > Problem Statement:
 >
 > ARIN's fee structure provides a graduated system wherein 
organizations
 > pay based on the amount of number resources they consume.
 >
 > In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 
or
 > smaller of IPv4) gets the present minimal-sized IPv6 allocation (a 
/36),
 > its annual fees will double from $250 to $500/year.
 >
 > According to a Policy Experience Report presented by Registration
 > Services to the AC at its annual workshop in January 2020, this
 > represents a disincentive to IPv6 adoption with a substantial 
fraction
 > of so-situated ISPs saying "no thanks" and abandoning their request 
for
 > IPv6 number resources when informed of the impact on their annual 
fees.
 >
 > This can be addressed by rewriting subsection 6.5.2(b). Initial
 > Allocation Size to allow allocation of a /40 to only the smallest 
ISPs
 > upon request, and adding a new clause 6.5.2(g) to cause an automatic
 > upgrade to at least a /36 in the case where the ISP is no longer 
3X-Small.
 >
 > Reserving /40s only for organizations initially expanding into IPv6 
from
 > an initial sliver of IPv4 space will help to narrowly address the
 > problem observed by Registration Services while avoiding unintended
 > consequences by accidentally giving a discount for undersized 
allocations.
 >
 > Policy Statement:
 >
 > Replace the current 6.5.2(b) with the following:
 >
 > b. In no case shall an LIR receive smaller than a /32 unless they
 > specifically request a /36 or /40.
 >
 > In order to be eligible for a /40, an ISP must meet the following
 > requirements:
 >   * Hold IPv4 direct allocations totaling a /24 or less (to include 
zero)
 >   * Hold IPv4 reassignments/reallocations totaling a /22 or less (to
 > include zero)
 >
 > In no case shall an ISP receive more than a /16 initial allocation.
 >
 > Add 6.5.2(g) as follows:
 >
 > g. An LIR that requests a smaller /36 or /40 allocation is entitled 
to
 > expand the allocation to any nibble aligned size up to /32 at any 
time
 > without renumbering or additional justification.  /40 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[John Sweeting]

Hi Andrew,

The numbers around this are:

320 3x small RSPs
30 have applied and been approved for IPv6 of which 26 closed with no action to 
complete by the requester. The other 4 are currently still open and pending 
action. 

Thanks,
John S. 

On 4/15/20, 11:30 AM, "Andrew Dul"  wrote:

John,

Could you provide the community with a rough magnitude of this issue? 

Approximately how many of these 3x-small ISP organizations have come to
ARIN and requested IPv6?  How many accepted the block and how many
refused because of the fee issue?  How many 3x-small ISP organizations
does ARIN currently serve.

Thanks,
Andrew

On 4/14/2020 2:29 PM, John Sweeting wrote:
> All,
>
> For anyone interested in the content of the "Policy Experience Report 
presented by Registration 
> Services to the AC at its annual workshop in January 2020" referenced in 
the problem statement you can see that report here:
>
> 
https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
>
> Thank you.
>
> On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" 
 wrote:
>
> On 19 March 2020, the ARIN Advisory Council (AC) accepted 
> "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
> 
> Draft Policy ARIN-2020-3 is below and can be found at:
> 
> https://www.arin.net/participate/policy/drafts/2020_3/
> 
> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these 
> principles are:
> 
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
> 
> The PDP can be found at:
> https://www.arin.net/participate/policy/pdp/
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
> 
> Regards,
> 
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
> Draft Policy ARIN-2020-3: IPv6 Nano-allocations
> 
> Problem Statement:
> 
> ARIN's fee structure provides a graduated system wherein organizations
> pay based on the amount of number resources they consume.
> 
> In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 
or 
> smaller of IPv4) gets the present minimal-sized IPv6 allocation (a 
/36), 
> its annual fees will double from $250 to $500/year.
> 
> According to a Policy Experience Report presented by Registration 
> Services to the AC at its annual workshop in January 2020, this 
> represents a disincentive to IPv6 adoption with a substantial 
fraction 
> of so-situated ISPs saying "no thanks" and abandoning their request 
for 
> IPv6 number resources when informed of the impact on their annual 
fees.
> 
> This can be addressed by rewriting subsection 6.5.2(b). Initial 
> Allocation Size to allow allocation of a /40 to only the smallest 
ISPs 
> upon request, and adding a new clause 6.5.2(g) to cause an automatic 
> upgrade to at least a /36 in the case where the ISP is no longer 
3X-Small.
> 
> Reserving /40s only for organizations initially expanding into IPv6 
from 
> an initial sliver of IPv4 space will help to narrowly address the 
> problem observed by Registration Services while avoiding unintended 
> consequences by accidentally giving a discount for undersized 
allocations.
> 
> Policy Statement:
> 
> Replace the current 6.5.2(b) with the following:
> 
> b. In no case shall an LIR receive smaller than a /32 unless they
> specifically request a /36 or /40.
> 
> In order to be eligible for a /40, an ISP must meet the following 
> requirements:
>   * Hold IPv4 direct allocations totaling a /24 or less (to include 
zero)
>   * Hold IPv4 reassignments/reallocations totaling a /22 or less (to 
> include zero)
> 
> In no case shall an ISP receive more than a /16 initial allocation.
> 
> Add 6.5.2(g) as follows:
> 
> g. An LIR that requests a smaller /36 or /40 allocation is entitled 
to 
> expand the allocation to any nibble aligned size up to /32 at any 
time 
> without renumbering or additional justification.  /40 allocations 
shall 
> be automatically upgraded to /36 if at any time said LIR's IPv4 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Brian Jones]

Good questions Andrew.I was wondering the same thing, what is the magnitude
of this issue.
—
Brian


On Wed, Apr 15, 2020 at 11:30 AM Andrew Dul  wrote:

> John,
>
> Could you provide the community with a rough magnitude of this issue?
>
> Approximately how many of these 3x-small ISP organizations have come to
> ARIN and requested IPv6?  How many accepted the block and how many
> refused because of the fee issue?  How many 3x-small ISP organizations
> does ARIN currently serve.
>
> Thanks,
> Andrew
>
> On 4/14/2020 2:29 PM, John Sweeting wrote:
> > All,
> >
> > For anyone interested in the content of the "Policy Experience Report
> presented by Registration
> > Services to the AC at its annual workshop in January 2020" referenced in
> the problem statement you can see that report here:
> >
> >
> https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
> >
> > Thank you.
> >
> > On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" <
> arin-ppml-boun...@arin.net on behalf of i...@arin.net> wrote:
> >
> > On 19 March 2020, the ARIN Advisory Council (AC) accepted
> > "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
> >
> > Draft Policy ARIN-2020-3 is below and can be found at:
> >
> > https://www.arin.net/participate/policy/drafts/2020_3/
> >
> > You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these
> > principles are:
> >
> > * Enabling Fair and Impartial Number Resource Administration
> > * Technically Sound
> > * Supported by the Community
> >
> > The PDP can be found at:
> > https://www.arin.net/participate/policy/pdp/
> >
> > Draft Policies and Proposals under discussion can be found at:
> > https://www.arin.net/participate/policy/drafts/
> >
> > Regards,
> >
> > Sean Hopkins
> > Policy Analyst
> > American Registry for Internet Numbers (ARIN)
> >
> >
> >
> > Draft Policy ARIN-2020-3: IPv6 Nano-allocations
> >
> > Problem Statement:
> >
> > ARIN's fee structure provides a graduated system wherein
> organizations
> > pay based on the amount of number resources they consume.
> >
> > In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24
> or
> > smaller of IPv4) gets the present minimal-sized IPv6 allocation (a
> /36),
> > its annual fees will double from $250 to $500/year.
> >
> > According to a Policy Experience Report presented by Registration
> > Services to the AC at its annual workshop in January 2020, this
> > represents a disincentive to IPv6 adoption with a substantial
> fraction
> > of so-situated ISPs saying "no thanks" and abandoning their request
> for
> > IPv6 number resources when informed of the impact on their annual
> fees.
> >
> > This can be addressed by rewriting subsection 6.5.2(b). Initial
> > Allocation Size to allow allocation of a /40 to only the smallest
> ISPs
> > upon request, and adding a new clause 6.5.2(g) to cause an automatic
> > upgrade to at least a /36 in the case where the ISP is no longer
> 3X-Small.
> >
> > Reserving /40s only for organizations initially expanding into IPv6
> from
> > an initial sliver of IPv4 space will help to narrowly address the
> > problem observed by Registration Services while avoiding unintended
> > consequences by accidentally giving a discount for undersized
> allocations.
> >
> > Policy Statement:
> >
> > Replace the current 6.5.2(b) with the following:
> >
> > b. In no case shall an LIR receive smaller than a /32 unless they
> > specifically request a /36 or /40.
> >
> > In order to be eligible for a /40, an ISP must meet the following
> > requirements:
> >   * Hold IPv4 direct allocations totaling a /24 or less (to include
> zero)
> >   * Hold IPv4 reassignments/reallocations totaling a /22 or less (to
> > include zero)
> >
> > In no case shall an ISP receive more than a /16 initial allocation.
> >
> > Add 6.5.2(g) as follows:
> >
> > g. An LIR that requests a smaller /36 or /40 allocation is entitled
> to
> > expand the allocation to any nibble aligned size up to /32 at any
> time
> > without renumbering or additional justification.  /40 allocations
> shall
> > be automatically upgraded to /36 if at any time said LIR's IPv4
> direct
> > allocations exceed a /24. Expansions up to and including a /32 are
> not
> > considered subsequent allocations, however any expansions beyond /32
> are
> > considered subsequent allocations and must conform to section 6.5.3.
> > Downgrades of any IPv6 allocation to less than a /36 are not
> permitted
> > regardless of the ISP's current or former IPv4 number resource
> holdings.
> >

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Andrew Dul]

John,

Could you provide the community with a rough magnitude of this issue? 

Approximately how many of these 3x-small ISP organizations have come to
ARIN and requested IPv6?  How many accepted the block and how many
refused because of the fee issue?  How many 3x-small ISP organizations
does ARIN currently serve.

Thanks,
Andrew

On 4/14/2020 2:29 PM, John Sweeting wrote:
> All,
>
> For anyone interested in the content of the "Policy Experience Report 
> presented by Registration 
> Services to the AC at its annual workshop in January 2020" referenced in the 
> problem statement you can see that report here:
>
> https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
>
> Thank you.
>
> On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" 
>  wrote:
>
> On 19 March 2020, the ARIN Advisory Council (AC) accepted 
> "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
> 
> Draft Policy ARIN-2020-3 is below and can be found at:
> 
> https://www.arin.net/participate/policy/drafts/2020_3/
> 
> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these 
> principles are:
> 
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
> 
> The PDP can be found at:
> https://www.arin.net/participate/policy/pdp/
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
> 
> Regards,
> 
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
> Draft Policy ARIN-2020-3: IPv6 Nano-allocations
> 
> Problem Statement:
> 
> ARIN's fee structure provides a graduated system wherein organizations
> pay based on the amount of number resources they consume.
> 
> In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or 
> smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36), 
> its annual fees will double from $250 to $500/year.
> 
> According to a Policy Experience Report presented by Registration 
> Services to the AC at its annual workshop in January 2020, this 
> represents a disincentive to IPv6 adoption with a substantial fraction 
> of so-situated ISPs saying "no thanks" and abandoning their request for 
> IPv6 number resources when informed of the impact on their annual fees.
> 
> This can be addressed by rewriting subsection 6.5.2(b). Initial 
> Allocation Size to allow allocation of a /40 to only the smallest ISPs 
> upon request, and adding a new clause 6.5.2(g) to cause an automatic 
> upgrade to at least a /36 in the case where the ISP is no longer 3X-Small.
> 
> Reserving /40s only for organizations initially expanding into IPv6 from 
> an initial sliver of IPv4 space will help to narrowly address the 
> problem observed by Registration Services while avoiding unintended 
> consequences by accidentally giving a discount for undersized allocations.
> 
> Policy Statement:
> 
> Replace the current 6.5.2(b) with the following:
> 
> b. In no case shall an LIR receive smaller than a /32 unless they
> specifically request a /36 or /40.
> 
> In order to be eligible for a /40, an ISP must meet the following 
> requirements:
>   * Hold IPv4 direct allocations totaling a /24 or less (to include zero)
>   * Hold IPv4 reassignments/reallocations totaling a /22 or less (to 
> include zero)
> 
> In no case shall an ISP receive more than a /16 initial allocation.
> 
> Add 6.5.2(g) as follows:
> 
> g. An LIR that requests a smaller /36 or /40 allocation is entitled to 
> expand the allocation to any nibble aligned size up to /32 at any time 
> without renumbering or additional justification.  /40 allocations shall 
> be automatically upgraded to /36 if at any time said LIR's IPv4 direct 
> allocations exceed a /24. Expansions up to and including a /32 are not 
> considered subsequent allocations, however any expansions beyond /32 are 
> considered subsequent allocations and must conform to section 6.5.3. 
> Downgrades of any IPv6 allocation to less than a /36 are not permitted 
> regardless of the ISP's current or former IPv4 number resource holdings.
> 
> Comments:
> 
> The intent of this policy proposal is to make IPv6 adoption at the very 
> bottom end expense-neutral for the ISP and revenue-neutral for ARIN. The 
> author looks forward to a future era wherein IPv6 is the dominant 
> technology and IPv4 is well in decline and 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Mike Burns]

Hi Lisa,

Thank you.
So a single organization can do multiple swaps within 12 months.

In practice we sometimes see /16 sellers who need to keep some of their block, 
but in doing so will lose money as the per-address price is higher for 
contiguous /16s. Many times they want to keep just a /24 and that atomizes the 
rest of the /16.
They could do the separate ORG workaround and purchase a /24, but if the buyer 
has other blocks, that buyer could offer a /24  to the /16 seller in a swap, 
and buy the contiguous /16. 

Might be rare, but nice to know about, thanks again.

Regards,
Mike



-Original Message-
From: Lisa Liedel  
Sent: Wednesday, April 15, 2020 9:05 AM
To: Mike Burns ; John Sweeting ; 
arin-ppml@arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

Hi Mike,

The 12 month waiting period is not imposed at the time of the block swap. 
However, any policy restrictions the organizations previously had will still be 
applicable if a block swap is approved. 

One additional note for clarification, the 12 month waiting period is when a 
Recipient of a transfer must wait for 12 months before they can transfer 
anything out, or become a Source. However, an organization can receive multiple 
transfers in a 12 month period.

Regards,

Lisa

On 4/15/20, 8:05 AM, "ARIN-PPML on behalf of Mike Burns" 
 wrote:

Hi John,

Thank you.
Are they both then subject to the 12 month waiting period before another 
receipt?

Regards,
Mike



-Original Message-
From: John Sweeting  
Sent: Tuesday, April 14, 2020 6:36 PM
To: Mike Burns ; arin-ppml@arin.net
    Subject: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

Sure Mike, they are approved on a case-by-case basis as described below:

Blocks swaps are conducted via 8.3 Specified Recipient Transfer process. 
Both parties need to submit two tickets each; a Source ticket to release a 
block and a Recipient to receive the other block. All four tickets need to be 
submitted and reviewed by the Director of RSD before approval. It is strongly 
recommended notation is made in each ticket that it is related to a block swap.

Note that their cannot be a net gain for either organization. 

On 4/14/20, 5:43 PM, "Mike Burns"  wrote:

Hi John,

Thanks for sharing the policy report.
How do we do a block swap?
Can you provide some more details on that process and its requirements?

Regards,
Mike

-Original Message-
From: ARIN-PPML  On Behalf Of John Sweeting
Sent: Tuesday, April 14, 2020 5:29 PM
To: arin-ppml@arin.net
    Subject: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

All,

For anyone interested in the content of the "Policy Experience Report 
presented by Registration Services to the AC at its annual workshop in January 
2020" referenced in the problem statement you can see that report here:


https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf

Thank you.

On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" 
 wrote:

On 19 March 2020, the ARIN Advisory Council (AC) accepted 
"ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.

Draft Policy ARIN-2020-3 is below and can be found at:

https://www.arin.net/participate/policy/drafts/2020_3/

You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these 
principles are:

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

The PDP can be found at:
https://www.arin.net/participate/policy/pdp/

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/participate/policy/drafts/

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)



Draft Policy ARIN-2020-3: IPv6 Nano-allocations

Problem Statement:

ARIN's fee structure provides a graduated system wherein 
organizations
pay based on the amount of number resources they consume.

In the case of the very smallest ISPs, if a 3X-Smal

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Lisa Liedel]

Hi Mike,

The 12 month waiting period is not imposed at the time of the block swap. 
However, any policy restrictions the organizations previously had will still be 
applicable if a block swap is approved. 

One additional note for clarification, the 12 month waiting period is when a 
Recipient of a transfer must wait for 12 months before they can transfer 
anything out, or become a Source. However, an organization can receive multiple 
transfers in a 12 month period.

Regards,

Lisa

On 4/15/20, 8:05 AM, "ARIN-PPML on behalf of Mike Burns" 
 wrote:

Hi John,

Thank you.
Are they both then subject to the 12 month waiting period before another 
receipt?

Regards,
Mike



-Original Message-
From: John Sweeting  
Sent: Tuesday, April 14, 2020 6:36 PM
To: Mike Burns ; arin-ppml@arin.net
    Subject: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

Sure Mike, they are approved on a case-by-case basis as described below:

Blocks swaps are conducted via 8.3 Specified Recipient Transfer process. 
Both parties need to submit two tickets each; a Source ticket to release a 
block and a Recipient to receive the other block. All four tickets need to be 
submitted and reviewed by the Director of RSD before approval. It is strongly 
recommended notation is made in each ticket that it is related to a block swap.

Note that their cannot be a net gain for either organization. 

On 4/14/20, 5:43 PM, "Mike Burns"  wrote:

Hi John,

Thanks for sharing the policy report.
How do we do a block swap?
Can you provide some more details on that process and its requirements?

Regards,
Mike

-Original Message-
From: ARIN-PPML  On Behalf Of John Sweeting
Sent: Tuesday, April 14, 2020 5:29 PM
To: arin-ppml@arin.net
    Subject: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

All,

For anyone interested in the content of the "Policy Experience Report 
presented by Registration Services to the AC at its annual workshop in January 
2020" referenced in the problem statement you can see that report here:


https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf

Thank you.

On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" 
 wrote:

On 19 March 2020, the ARIN Advisory Council (AC) accepted 
"ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.

Draft Policy ARIN-2020-3 is below and can be found at:

https://www.arin.net/participate/policy/drafts/2020_3/

You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these 
principles are:

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

The PDP can be found at:
https://www.arin.net/participate/policy/pdp/

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/participate/policy/drafts/

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)



Draft Policy ARIN-2020-3: IPv6 Nano-allocations

Problem Statement:

ARIN's fee structure provides a graduated system wherein 
organizations
pay based on the amount of number resources they consume.

In the case of the very smallest ISPs, if a 3X-Small ISP (with a 
/24 or 
smaller of IPv4) gets the present minimal-sized IPv6 allocation (a 
/36), 
its annual fees will double from $250 to $500/year.

According to a Policy Experience Report presented by Registration 
Services to the AC at its annual workshop in January 2020, this 
represents a disincentive to IPv6 adoption with a substantial 
fraction 
of so-situated ISPs saying "no thanks" and abandoning their request 
for 
IPv6 number resources when informed of the impact on their annual 
fees.

This can be addressed by rewriting subsection 6.5.2(b). Initial 
Allocation Size to allow allocation of a /40 to only the smallest 
ISPs 
upon requ

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Mike Burns]

Hi John,

Thank you.
Are they both then subject to the 12 month waiting period before another 
receipt?

Regards,
Mike



-Original Message-
From: John Sweeting  
Sent: Tuesday, April 14, 2020 6:36 PM
To: Mike Burns ; arin-ppml@arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

Sure Mike, they are approved on a case-by-case basis as described below:

Blocks swaps are conducted via 8.3 Specified Recipient Transfer process. Both 
parties need to submit two tickets each; a Source ticket to release a block and 
a Recipient to receive the other block. All four tickets need to be submitted 
and reviewed by the Director of RSD before approval. It is strongly recommended 
notation is made in each ticket that it is related to a block swap.

Note that their cannot be a net gain for either organization. 

On 4/14/20, 5:43 PM, "Mike Burns"  wrote:

Hi John,

Thanks for sharing the policy report.
How do we do a block swap?
Can you provide some more details on that process and its requirements?

Regards,
Mike

-Original Message-
From: ARIN-PPML  On Behalf Of John Sweeting
Sent: Tuesday, April 14, 2020 5:29 PM
To: arin-ppml@arin.net
    Subject: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

All,

For anyone interested in the content of the "Policy Experience Report 
presented by Registration Services to the AC at its annual workshop in January 
2020" referenced in the problem statement you can see that report here:


https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf

Thank you.

On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" 
 wrote:

On 19 March 2020, the ARIN Advisory Council (AC) accepted 
"ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.

Draft Policy ARIN-2020-3 is below and can be found at:

https://www.arin.net/participate/policy/drafts/2020_3/

You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these 
principles are:

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

The PDP can be found at:
https://www.arin.net/participate/policy/pdp/

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/participate/policy/drafts/

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)



Draft Policy ARIN-2020-3: IPv6 Nano-allocations

Problem Statement:

ARIN's fee structure provides a graduated system wherein organizations
pay based on the amount of number resources they consume.

In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or 
smaller of IPv4) gets the present minimal-sized IPv6 allocation (a 
/36), 
its annual fees will double from $250 to $500/year.

According to a Policy Experience Report presented by Registration 
Services to the AC at its annual workshop in January 2020, this 
represents a disincentive to IPv6 adoption with a substantial fraction 
of so-situated ISPs saying "no thanks" and abandoning their request for 
IPv6 number resources when informed of the impact on their annual fees.

This can be addressed by rewriting subsection 6.5.2(b). Initial 
Allocation Size to allow allocation of a /40 to only the smallest ISPs 
upon request, and adding a new clause 6.5.2(g) to cause an automatic 
upgrade to at least a /36 in the case where the ISP is no longer 
3X-Small.

Reserving /40s only for organizations initially expanding into IPv6 
from 
an initial sliver of IPv4 space will help to narrowly address the 
problem observed by Registration Services while avoiding unintended 
consequences by accidentally giving a discount for undersized 
allocations.

Policy Statement:

Replace the current 6.5.2(b) with the following:

b. In no case shall an LIR receive smaller than a /32 unless they
specifically request a /36 or /40.

In order to be eligible for a /40, an ISP must meet the following 
requirements:
  * Hold IPv4 direct allocations totaling a /24 or less (to include 
zero)
  * Hold IPv4 reassignments/reallocations totaling a /22 or less (to 
incl

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[John Sweeting]

Sure Mike, they are approved on a case-by-case basis as described below:

Blocks swaps are conducted via 8.3 Specified Recipient Transfer process. Both 
parties need to submit two tickets each; a Source ticket to release a block and 
a Recipient to receive the other block. All four tickets need to be submitted 
and reviewed by the Director of RSD before approval. It is strongly recommended 
notation is made in each ticket that it is related to a block swap.

Note that their cannot be a net gain for either organization. 

On 4/14/20, 5:43 PM, "Mike Burns"  wrote:

Hi John,

Thanks for sharing the policy report.
How do we do a block swap?
Can you provide some more details on that process and its requirements?

Regards,
Mike

-Original Message-
From: ARIN-PPML  On Behalf Of John Sweeting
Sent: Tuesday, April 14, 2020 5:29 PM
To: arin-ppml@arin.net
    Subject: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

All,

For anyone interested in the content of the "Policy Experience Report 
presented by Registration Services to the AC at its annual workshop in January 
2020" referenced in the problem statement you can see that report here:


https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf

Thank you.

On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" 
 wrote:

On 19 March 2020, the ARIN Advisory Council (AC) accepted 
"ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.

Draft Policy ARIN-2020-3 is below and can be found at:

https://www.arin.net/participate/policy/drafts/2020_3/

You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these 
principles are:

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

The PDP can be found at:
https://www.arin.net/participate/policy/pdp/

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/participate/policy/drafts/

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)



Draft Policy ARIN-2020-3: IPv6 Nano-allocations

Problem Statement:

ARIN's fee structure provides a graduated system wherein organizations
pay based on the amount of number resources they consume.

In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or 
smaller of IPv4) gets the present minimal-sized IPv6 allocation (a 
/36), 
its annual fees will double from $250 to $500/year.

According to a Policy Experience Report presented by Registration 
Services to the AC at its annual workshop in January 2020, this 
represents a disincentive to IPv6 adoption with a substantial fraction 
of so-situated ISPs saying "no thanks" and abandoning their request for 
IPv6 number resources when informed of the impact on their annual fees.

This can be addressed by rewriting subsection 6.5.2(b). Initial 
Allocation Size to allow allocation of a /40 to only the smallest ISPs 
upon request, and adding a new clause 6.5.2(g) to cause an automatic 
upgrade to at least a /36 in the case where the ISP is no longer 
3X-Small.

Reserving /40s only for organizations initially expanding into IPv6 
from 
an initial sliver of IPv4 space will help to narrowly address the 
problem observed by Registration Services while avoiding unintended 
consequences by accidentally giving a discount for undersized 
allocations.

Policy Statement:

Replace the current 6.5.2(b) with the following:

b. In no case shall an LIR receive smaller than a /32 unless they
specifically request a /36 or /40.

In order to be eligible for a /40, an ISP must meet the following 
requirements:
  * Hold IPv4 direct allocations totaling a /24 or less (to include 
zero)
  * Hold IPv4 reassignments/reallocations totaling a /22 or less (to 
include zero)

In no case shall an ISP receive more than a /16 initial allocation.

Add 6.5.2(g) as follows:

g. An LIR that requests a smaller /36 or /40 allocation is entitled to 
expand the allocation to any nibble aligned size up to /32 at any time 
wit

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Mike Burns]

Hi John,

Thanks for sharing the policy report.
How do we do a block swap?
Can you provide some more details on that process and its requirements?

Regards,
Mike

-Original Message-
From: ARIN-PPML  On Behalf Of John Sweeting
Sent: Tuesday, April 14, 2020 5:29 PM
To: arin-ppml@arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

All,

For anyone interested in the content of the "Policy Experience Report presented 
by Registration Services to the AC at its annual workshop in January 2020" 
referenced in the problem statement you can see that report here:

https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf

Thank you.

On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN"  wrote:

On 19 March 2020, the ARIN Advisory Council (AC) accepted 
"ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.

Draft Policy ARIN-2020-3 is below and can be found at:

https://www.arin.net/participate/policy/drafts/2020_3/

You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these 
principles are:

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

The PDP can be found at:
https://www.arin.net/participate/policy/pdp/

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/participate/policy/drafts/

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)



Draft Policy ARIN-2020-3: IPv6 Nano-allocations

Problem Statement:

ARIN's fee structure provides a graduated system wherein organizations
pay based on the amount of number resources they consume.

In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or 
smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36), 
its annual fees will double from $250 to $500/year.

According to a Policy Experience Report presented by Registration 
Services to the AC at its annual workshop in January 2020, this 
represents a disincentive to IPv6 adoption with a substantial fraction 
of so-situated ISPs saying "no thanks" and abandoning their request for 
IPv6 number resources when informed of the impact on their annual fees.

This can be addressed by rewriting subsection 6.5.2(b). Initial 
Allocation Size to allow allocation of a /40 to only the smallest ISPs 
upon request, and adding a new clause 6.5.2(g) to cause an automatic 
upgrade to at least a /36 in the case where the ISP is no longer 3X-Small.

Reserving /40s only for organizations initially expanding into IPv6 from 
an initial sliver of IPv4 space will help to narrowly address the 
problem observed by Registration Services while avoiding unintended 
consequences by accidentally giving a discount for undersized allocations.

Policy Statement:

Replace the current 6.5.2(b) with the following:

b. In no case shall an LIR receive smaller than a /32 unless they
specifically request a /36 or /40.

In order to be eligible for a /40, an ISP must meet the following 
requirements:
  * Hold IPv4 direct allocations totaling a /24 or less (to include zero)
  * Hold IPv4 reassignments/reallocations totaling a /22 or less (to 
include zero)

In no case shall an ISP receive more than a /16 initial allocation.

Add 6.5.2(g) as follows:

g. An LIR that requests a smaller /36 or /40 allocation is entitled to 
expand the allocation to any nibble aligned size up to /32 at any time 
without renumbering or additional justification.  /40 allocations shall 
be automatically upgraded to /36 if at any time said LIR's IPv4 direct 
allocations exceed a /24. Expansions up to and including a /32 are not 
considered subsequent allocations, however any expansions beyond /32 are 
considered subsequent allocations and must conform to section 6.5.3. 
Downgrades of any IPv6 allocation to less than a /36 are not permitted 
regardless of the ISP's current or former IPv4 number resource holdings.

Comments:

The intent of this policy proposal is to make IPv6 adoption at the very 
bottom end expense-neutral for the ISP and revenue-neutral for ARIN. The 
author looks forward to a future era wherein IPv6 is the dominant 
technology and IPv4 is well in decline and considered optional leading 
the Community to conclude that sunsetting this policy is prudent in the 
interests of avoiding an incentive to request undersi

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[John Sweeting]

All,

For anyone interested in the content of the "Policy Experience Report presented 
by Registration 
Services to the AC at its annual workshop in January 2020" referenced in the 
problem statement you can see that report here:

https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf

Thank you.

On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN"  wrote:

On 19 March 2020, the ARIN Advisory Council (AC) accepted 
"ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.

Draft Policy ARIN-2020-3 is below and can be found at:

https://www.arin.net/participate/policy/drafts/2020_3/

You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these 
principles are:

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

The PDP can be found at:
https://www.arin.net/participate/policy/pdp/

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/participate/policy/drafts/

Regards,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)



Draft Policy ARIN-2020-3: IPv6 Nano-allocations

Problem Statement:

ARIN's fee structure provides a graduated system wherein organizations
pay based on the amount of number resources they consume.

In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or 
smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36), 
its annual fees will double from $250 to $500/year.

According to a Policy Experience Report presented by Registration 
Services to the AC at its annual workshop in January 2020, this 
represents a disincentive to IPv6 adoption with a substantial fraction 
of so-situated ISPs saying "no thanks" and abandoning their request for 
IPv6 number resources when informed of the impact on their annual fees.

This can be addressed by rewriting subsection 6.5.2(b). Initial 
Allocation Size to allow allocation of a /40 to only the smallest ISPs 
upon request, and adding a new clause 6.5.2(g) to cause an automatic 
upgrade to at least a /36 in the case where the ISP is no longer 3X-Small.

Reserving /40s only for organizations initially expanding into IPv6 from 
an initial sliver of IPv4 space will help to narrowly address the 
problem observed by Registration Services while avoiding unintended 
consequences by accidentally giving a discount for undersized allocations.

Policy Statement:

Replace the current 6.5.2(b) with the following:

b. In no case shall an LIR receive smaller than a /32 unless they
specifically request a /36 or /40.

In order to be eligible for a /40, an ISP must meet the following 
requirements:
  * Hold IPv4 direct allocations totaling a /24 or less (to include zero)
  * Hold IPv4 reassignments/reallocations totaling a /22 or less (to 
include zero)

In no case shall an ISP receive more than a /16 initial allocation.

Add 6.5.2(g) as follows:

g. An LIR that requests a smaller /36 or /40 allocation is entitled to 
expand the allocation to any nibble aligned size up to /32 at any time 
without renumbering or additional justification.  /40 allocations shall 
be automatically upgraded to /36 if at any time said LIR's IPv4 direct 
allocations exceed a /24. Expansions up to and including a /32 are not 
considered subsequent allocations, however any expansions beyond /32 are 
considered subsequent allocations and must conform to section 6.5.3. 
Downgrades of any IPv6 allocation to less than a /36 are not permitted 
regardless of the ISP's current or former IPv4 number resource holdings.

Comments:

The intent of this policy proposal is to make IPv6 adoption at the very 
bottom end expense-neutral for the ISP and revenue-neutral for ARIN. The 
author looks forward to a future era wherein IPv6 is the dominant 
technology and IPv4 is well in decline and considered optional leading 
the Community to conclude that sunsetting this policy is prudent in the 
interests of avoiding an incentive to request undersized IPv6 allocations.

Timetable for implementation: Immediate

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Paul Andersen]

> On Apr 13, 2020, at 11:55 AM, Andrew Dul  wrote:
> 
> I will also like to note, that this issue could also be remedied by the board 
> adopting a small change to the fee schedule such that the 3x-small IPv6 
> holdings do not force a change in category for 3x-small organizations. This 
> would cause 3x-small organization's fees to be primarily determined by their 
> IPv4 holdings not their IPv6 holdings.
> 
> While the community doesn't have purview over fees we have input into that 
> process.  If this is something that we would strongly like to prefer as a 
> solution to this problem.  We can make this as a strong suggestion to the 
> board for their consideration.
> 

We have reviewed similar suggestions before. Fees are always complex because we 
need to recover costs in a fair and equitable manner. The current fee structure 
has tried to ensure there is simplicity and predictability while accomplishing 
this and we’ve had a lot of feedback that is important. Adjusting the schedule 
to account for this starts to complicate things both for users of our services 
and ARIN. 

With that in mind we have taken suggestions like this seriously in the past and 
give them serious deliberation. Look forward to seeing the discussion and input.

Cheers,

Paul

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[William Herrin]

On Tue, Apr 14, 2020 at 9:42 AM Owen DeLong  wrote:
> > On Apr 14, 2020, at 00:38 , William Herrin  wrote:
> > On Mon, Apr 13, 2020 at 8:48 PM Owen DeLong  wrote
> >>> While the community doesn't have purview over fees we have input into 
> >>> that process.  If this is something that we would strongly like to prefer 
> >>> as a solution to this problem.  We can make this as a strong suggestion 
> >>> to the board for their consideration.
> >>
> >> Mr. Quixote, Windmill… Windmill, Mr. Quixote.
> >
> > If we have something approaching a consensus that it should happen,
> > maybe it should be a litmus test for the candidates this fall.
>
> If you can convince enough members, sure… However, it will take at least two 
> cycles of that (so October, 2021 to take effect January, 2022) to get a 
> majority of seats on the board affected.

Hi Owen,

Do we need to turn over a majority? Or do we just need to present the
remaining trustees with clear and convincing evidence that the members
want IPv6 to be cost-neutral to every existing IPv4 registrant?

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/
___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Owen DeLong]

> On Apr 14, 2020, at 00:38 , William Herrin  wrote:
> 
> On Mon, Apr 13, 2020 at 8:48 PM Owen DeLong  wrote
>>> While the community doesn't have purview over fees we have input into that 
>>> process.  If this is something that we would strongly like to prefer as a 
>>> solution to this problem.  We can make this as a strong suggestion to the 
>>> board for their consideration.
>> 
>> Mr. Quixote, Windmill… Windmill, Mr. Quixote.
> 
> If we have something approaching a consensus that it should happen,
> maybe it should be a litmus test for the candidates this fall.

If you can convince enough members, sure… However, it will take at least two 
cycles of that (so October, 2021 to take effect January, 2022) to get a 
majority of seats on the board affected.

Owen

___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[William Herrin]

On Mon, Apr 13, 2020 at 8:48 PM Owen DeLong  wrote
>> While the community doesn't have purview over fees we have input into that 
>> process.  If this is something that we would strongly like to prefer as a 
>> solution to this problem.  We can make this as a strong suggestion to the 
>> board for their consideration.
>
> Mr. Quixote, Windmill… Windmill, Mr. Quixote.

If we have something approaching a consensus that it should happen,
maybe it should be a litmus test for the candidates this fall.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/
___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Owen DeLong]

> On Apr 13, 2020, at 08:55 , Andrew Dul  wrote:
> 
> David, Thanks for your comments.   
> 
> On 3/26/2020 4:08 PM, David Farmer wrote:
>> I support this policy as written. 
>> 
>> However, I recommend a minor editorial change and a small change to the 
>> policy;
>> 
>> 1. I would prefer to not use "smaller" or "less" when referring to /24 or 
>> longer prefixes, such use is somewhat ambiguous, this has been discussed 
>> many times on PPML.
> Noted.

Yes, though I’m not 100% sure that the conversation settled on consensus for 
those particular approaches.

Personally, I think that when we are discussing amount of address space, we 
should use “More than”, “Less than”, “Larger than”, “Smaller than”, and refer 
not to “/24”, but “equivalent of /24” or “/24 equivalent(s)”.

However, when we are specifically talking about prefix length (i.e. exactly a 
specific prefix, not some collection of 1 or more blocks adding up to X amount 
of address space), we should use the terms “longer” or “shorter” (e.g. "The 
longest prefix ARIN will issue in IPv4 is a /24”, “Requests for IPv6 prefixes 
shorter than /16 will be treated as multiple /16s”).

>> 2. I really like the idea of automatically increasing the IPv6 allocation to 
>> /36 when the IPv4 allocation increases beyond /24. How about also 
>> automatically increasing the IPv6 allocation to /32 when the IPv4 allocation 
>> increases beyond /22?
> The goal of this policy is to create IPv6 allocation sizes such that a 
> current IPv4 organization which is currently 3X-small can obtain an IPv6 
> allocation without their fees going up.  Today this issue only occurs with 
> 3x-small.  If we were to implement this other change I believe this would 
> cause the text to move beyond the current problem statement.  
> 
I think this is actually a good idea. I suggest checking with RS on whether 
he’s amenable to amending the problem statement.

If not, I will work with David off line to create a second proposal to address 
this issue. The reason we have /36s in the first place is sort of the next rung 
up of the same problem, so applying the same automation to that situation 
really does make a lot of sense and, in my mind is within scope of the spirit 
of the problem statement, even if not within the letter of the law for same.
> I will also like to note, that this issue could also be remedied by the board 
> adopting a small change to the fee schedule such that the 3x-small IPv6 
> holdings do not force a change in category for 3x-small organizations. This 
> would cause 3x-small organization's fees to be primarily determined by their 
> IPv4 holdings not their IPv6 holdings.
> 
We/ve tried to ask the board to take this approach in the past with zero 
success. 
> While the community doesn't have purview over fees we have input into that 
> process.  If this is something that we would strongly like to prefer as a 
> solution to this problem.  We can make this as a strong suggestion to the 
> board for their consideration.
> 
Mr. Quixote, Windmill… Windmill, Mr. Quixote.

Owen

> Andrew
> 
> 
> 
>> 
>> Thanks
>> 
>> On Tue, Mar 24, 2020 at 12:22 PM ARIN mailto:i...@arin.net>> 
>> wrote:
>> Draft Policy ARIN-2020-3: IPv6 Nano-allocations
>> 
>> Problem Statement:
>> 
>> ARIN's fee structure provides a graduated system wherein organizations
>> pay based on the amount of number resources they consume.
>> 
>> In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or 
>> smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36), 
>> its annual fees will double from $250 to $500/year.
>> 
>> According to a Policy Experience Report presented by Registration 
>> Services to the AC at its annual workshop in January 2020, this 
>> represents a disincentive to IPv6 adoption with a substantial fraction 
>> of so-situated ISPs saying "no thanks" and abandoning their request for 
>> IPv6 number resources when informed of the impact on their annual fees.
>> 
>> This can be addressed by rewriting subsection 6.5.2(b). Initial 
>> Allocation Size to allow allocation of a /40 to only the smallest ISPs 
>> upon request, and adding a new clause 6.5.2(g) to cause an automatic 
>> upgrade to at least a /36 in the case where the ISP is no longer 3X-Small.
>> 
>> Reserving /40s only for organizations initially expanding into IPv6 from 
>> an initial sliver of IPv4 space will help to narrowly address the 
>> problem observed by Registration Services while avoiding unintended 
>> consequences by accidentally giving a discount for undersized allocations.
>> 
>> Policy Statement:
>> 
>> Replace the current 6.5.2(b) with the following:
>> 
>> b. In no case shall an LIR receive smaller than a /32 unless they
>> specifically request a /36 or /40.
>> 
>> In order to be eligible for a /40, an ISP must meet the following 
>> requirements:
>>   * Hold IPv4 direct allocations totaling a /24 or less (to include zero)
>>   * Hold IPv4 reassignments/reallocations totaling a /22 or 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[William Herrin]

On Tue, Mar 24, 2020 at 10:22 AM ARIN  wrote:
> Draft Policy ARIN-2020-3: IPv6 Nano-allocations
>
> Problem Statement:
>
> ARIN's fee structure provides a graduated system wherein organizations
> pay based on the amount of number resources they consume.
>
> In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or
> smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36),
> its annual fees will double from $250 to $500/year.
>
> According to a Policy Experience Report presented by Registration
> Services to the AC at its annual workshop in January 2020, this
> represents a disincentive to IPv6 adoption with a substantial fraction
> of so-situated ISPs saying "no thanks" and abandoning their request for
> IPv6 number resources when informed of the impact on their annual fees.
>
> This can be addressed by rewriting subsection 6.5.2(b). Initial
> Allocation Size to allow allocation of a /40 to only the smallest ISPs
> upon request, and adding a new clause 6.5.2(g) to cause an automatic
> upgrade to at least a /36 in the case where the ISP is no longer 3X-Small.
>
> Reserving /40s only for organizations initially expanding into IPv6 from
> an initial sliver of IPv4 space will help to narrowly address the
> problem observed by Registration Services while avoiding unintended
> consequences by accidentally giving a discount for undersized allocations.

Greetings,

This strikes me as an ass-backwards solution to a small fragment of a
bigger problem.

Is the problem that we think existing IPv4 registrants shouldn't
generally be asked to pay more to enter the IPv6 space? Do we think
seeking extra money is counterproductive?

If so, let's solve that problem. Directly, cleanly, and for all of our
registrants. Not by wagging the dog: jiggering technical details to
fit a faulty billing scheme.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/
___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Andrew Dul]

David, Thanks for your comments.  

On 3/26/2020 4:08 PM, David Farmer wrote:
> I support this policy as written. 
>
> However, I recommend a minor editorial change and a small change to
> the policy;
>
> 1. I would prefer to not use "smaller" or "less" when referring to /24
> or longer prefixes, such use is somewhat ambiguous, this has been
> discussed many times on PPML.
Noted.
>
> 2. I really like the idea of automatically increasing the IPv6
> allocation to /36 when the IPv4 allocation increases beyond /24. How
> about also automatically increasing the IPv6 allocation to /32 when
> the IPv4 allocation increases beyond /22?

The goal of this policy is to create IPv6 allocation sizes such that a
current IPv4 organization which is currently 3X-small can obtain an IPv6
allocation without their fees going up.  Today this issue only occurs
with 3x-small.  If we were to implement this other change I believe this
would cause the text to move beyond the current problem statement. 

I will also like to note, that this issue could also be remedied by the
board adopting a small change to the fee schedule such that the 3x-small
IPv6 holdings do not force a change in category for 3x-small
organizations. This would cause 3x-small organization's fees to be
primarily determined by their IPv4 holdings not their IPv6 holdings.

While the community doesn't have purview over fees we have input into
that process.  If this is something that we would strongly like to
prefer as a solution to this problem.  We can make this as a strong
suggestion to the board for their consideration.

Andrew


>
> Thanks
>
> On Tue, Mar 24, 2020 at 12:22 PM ARIN  > wrote:
>
> Draft Policy ARIN-2020-3: IPv6 Nano-allocations
>
> Problem Statement:
>
> ARIN's fee structure provides a graduated system wherein organizations
> pay based on the amount of number resources they consume.
>
> In the case of the very smallest ISPs, if a 3X-Small ISP (with a
> /24 or
> smaller of IPv4) gets the present minimal-sized IPv6 allocation (a
> /36),
> its annual fees will double from $250 to $500/year.
>
> According to a Policy Experience Report presented by Registration
> Services to the AC at its annual workshop in January 2020, this
> represents a disincentive to IPv6 adoption with a substantial
> fraction
> of so-situated ISPs saying "no thanks" and abandoning their
> request for
> IPv6 number resources when informed of the impact on their annual
> fees.
>
> This can be addressed by rewriting subsection 6.5.2(b). Initial
> Allocation Size to allow allocation of a /40 to only the smallest
> ISPs
> upon request, and adding a new clause 6.5.2(g) to cause an automatic
> upgrade to at least a /36 in the case where the ISP is no longer
> 3X-Small.
>
> Reserving /40s only for organizations initially expanding into
> IPv6 from
> an initial sliver of IPv4 space will help to narrowly address the
> problem observed by Registration Services while avoiding unintended
> consequences by accidentally giving a discount for undersized
> allocations.
>
> Policy Statement:
>
> Replace the current 6.5.2(b) with the following:
>
> b. In no case shall an LIR receive smaller than a /32 unless they
> specifically request a /36 or /40.
>
> In order to be eligible for a /40, an ISP must meet the following
> requirements:
>   * Hold IPv4 direct allocations totaling a /24 or less (to
> include zero)
>   * Hold IPv4 reassignments/reallocations totaling a /22 or less (to
> include zero)
>
> In no case shall an ISP receive more than a /16 initial allocation.
>
> Add 6.5.2(g) as follows:
>
> g. An LIR that requests a smaller /36 or /40 allocation is
> entitled to
> expand the allocation to any nibble aligned size up to /32 at any
> time
> without renumbering or additional justification.  /40 allocations
> shall
> be automatically upgraded to /36 if at any time said LIR's IPv4
> direct
> allocations exceed a /24. Expansions up to and including a /32 are
> not
> considered subsequent allocations, however any expansions beyond
> /32 are
> considered subsequent allocations and must conform to section 6.5.3.
> Downgrades of any IPv6 allocation to less than a /36 are not
> permitted
> regardless of the ISP's current or former IPv4 number resource
> holdings.
>
> Comments:
>
> The intent of this policy proposal is to make IPv6 adoption at the
> very
> bottom end expense-neutral for the ISP and revenue-neutral for
> ARIN. The
> author looks forward to a future era wherein IPv6 is the dominant
> technology and IPv4 is well in decline and considered optional
> leading
> the Community to conclude that sunsetting this policy is prudent
> in the
> interests of avoiding an incentive to request undersized IPv6
>   

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[David Farmer]

I support this policy as written.

However, I recommend a minor editorial change and a small change to the
policy;

1. I would prefer to not use "smaller" or "less" when referring to /24 or
longer prefixes, such use is somewhat ambiguous, this has been discussed
many times on PPML.

2. I really like the idea of automatically increasing the IPv6 allocation
to /36 when the IPv4 allocation increases beyond /24. How about
also automatically increasing the IPv6 allocation to /32 when the IPv4
allocation increases beyond /22?

Thanks

On Tue, Mar 24, 2020 at 12:22 PM ARIN  wrote:

> Draft Policy ARIN-2020-3: IPv6 Nano-allocations
>
> Problem Statement:
>
> ARIN's fee structure provides a graduated system wherein organizations
> pay based on the amount of number resources they consume.
>
> In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or
> smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36),
> its annual fees will double from $250 to $500/year.
>
> According to a Policy Experience Report presented by Registration
> Services to the AC at its annual workshop in January 2020, this
> represents a disincentive to IPv6 adoption with a substantial fraction
> of so-situated ISPs saying "no thanks" and abandoning their request for
> IPv6 number resources when informed of the impact on their annual fees.
>
> This can be addressed by rewriting subsection 6.5.2(b). Initial
> Allocation Size to allow allocation of a /40 to only the smallest ISPs
> upon request, and adding a new clause 6.5.2(g) to cause an automatic
> upgrade to at least a /36 in the case where the ISP is no longer 3X-Small.
>
> Reserving /40s only for organizations initially expanding into IPv6 from
> an initial sliver of IPv4 space will help to narrowly address the
> problem observed by Registration Services while avoiding unintended
> consequences by accidentally giving a discount for undersized allocations.
>
> Policy Statement:
>
> Replace the current 6.5.2(b) with the following:
>
> b. In no case shall an LIR receive smaller than a /32 unless they
> specifically request a /36 or /40.
>
> In order to be eligible for a /40, an ISP must meet the following
> requirements:
>   * Hold IPv4 direct allocations totaling a /24 or less (to include zero)
>   * Hold IPv4 reassignments/reallocations totaling a /22 or less (to
> include zero)
>
> In no case shall an ISP receive more than a /16 initial allocation.
>
> Add 6.5.2(g) as follows:
>
> g. An LIR that requests a smaller /36 or /40 allocation is entitled to
> expand the allocation to any nibble aligned size up to /32 at any time
> without renumbering or additional justification.  /40 allocations shall
> be automatically upgraded to /36 if at any time said LIR's IPv4 direct
> allocations exceed a /24. Expansions up to and including a /32 are not
> considered subsequent allocations, however any expansions beyond /32 are
> considered subsequent allocations and must conform to section 6.5.3.
> Downgrades of any IPv6 allocation to less than a /36 are not permitted
> regardless of the ISP's current or former IPv4 number resource holdings.
>
> Comments:
>
> The intent of this policy proposal is to make IPv6 adoption at the very
> bottom end expense-neutral for the ISP and revenue-neutral for ARIN. The
> author looks forward to a future era wherein IPv6 is the dominant
> technology and IPv4 is well in decline and considered optional leading
> the Community to conclude that sunsetting this policy is prudent in the
> interests of avoiding an incentive to request undersized IPv6 allocations.
>
> Timetable for implementation: Immediate
>
> ___
> ARIN-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:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.