Send ARIN-PPML mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(David Farmer)
2. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Jimmy Hess)
3. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(William Herrin)
4. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(John Curran)
5. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(John Curran)
6. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(David Farmer)
----------------------------------------------------------------------
Message: 1
Date: Wed, 27 Mar 2013 19:45:45 -0500
From: David Farmer <[email protected]>
To: Michael Sinatra <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 3/27/13 18:00 , Michael Sinatra wrote:
> Or, to put more bluntly, if ARIN's fee structure is itself creating
> disincentives for proper IPv6 adoption, then let's go back and (re-)fix
> that problem.
>
> Oppose 2013-3.
Michael and others opposed,
What about modifying the proposal to /40, require a minimum reservation
of /32 (or maybe /28) be held for ISPs that elect for /40 or /36
allocations, allow subsequent allocations to expansion from /40 to /36
and then to /32 without evaluating there current IPv6 usage. Thereby
ensuring they can grow their allocation in place and allowing policy
flexibility that enables the fee structure equity that the new xx-small
category seems to provided.
This policy doesn't change the fact anyone who whats it can get a /32.
We already allowed a optional /36. If we added a /40 option with
sufficient reservation and the ability to expand up to /32 without
justification of subsequent allocations, then this allow all ISPs to
deploy IPv6 for no change in their costs. Furthermore if their IPv6
growth causes them to need a larger allocation then by definition there
should be a business case that easily justifies the fee increase.
The idea would be every ISP is entitled to /32, but if you want
financial flexibility you can start with /40 or /36 and grow your
allocation as you need to. No one is forced to do this, but it ensures
IPv6 is available to all ISPs without effecting there current costs.
Finally, even if you continue to not support the proposal would you
support making the changes to the text about for the text to discuss at
the PPM?
Thanks
--
================================================
David Farmer Email: [email protected]
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
================================================
------------------------------
Message: 2
Date: Wed, 27 Mar 2013 19:40:29 -0500
From: Jimmy Hess <[email protected]>
To: John Curran <[email protected]>
Cc: "[email protected] PPML" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID:
<CAAAwwbU7h_mnzqn+9oVP=36CAdD1k-QWcZnM=+nqtwwsw7r...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 3/27/13, John Curran <[email protected]> wrote:
> On Mar 27, 2013, at 7:52 PM, Owen DeLong <[email protected]> wrote:
> How many customers does an typical xx-small ISP have today?
> (xx-small being those ISPs who hold a /22 of IPv4 space)
Well, logically they could have up to approximately1000 customers,
assuming no NAT
and an average of one /32 per customer.
The IPv6 equivalent of 1000 /48s = a /38
However, if ARIN restricts their assignment, with IPv6, they may be
tempted to seek ways of assigning their customers smaller IPv6
allocations such as /56 or /128, in order to prolong their ARIN
IPv6 allocation and retain small or x-small status.
Therefore, it is a very bad idea for ARIN to be attempting to create
artificial IP address scarcity by billing more for "enough" IPv6.
It actually creates pressure to forego IPv6 technical standards, and
attempt to deploy the protocol in a manner that may be less
successful in the long run.
What should happen, is... if ARIN wants to bill based on ISP size,
they should stop using number of IP addresses as a metric.
I would recommend switching to "Number of customers" or "Number of
dollars monthly subscription revenue"
And per-resource fees only for IPV4, or providers with _very_ large
allocations (such as more than a /20 of IPv6), but in all cases
technical justification still required.
Regardless of whether resources are IPv4 or IPv6.
This way, there are not artificial pressures created to excessively
conserve IPv6 through extreme tactics such as assigning each customer
a /128.
Because doing so does not cirucmvent ARIN fees, if the fees are based
on number of subscribers, or number of network connections.
> /John
--
-JH
------------------------------
Message: 3
Date: Wed, 27 Mar 2013 20:50:13 -0400
From: William Herrin <[email protected]>
To: John Curran <[email protected]>
Cc: "[email protected] PPML" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID:
<CAP-guGUs=drrdcfdnff0vnwphrtzyjesvut86ljpvb+ftr1...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Mar 27, 2013 at 8:09 PM, John Curran <[email protected]> wrote:
> On Mar 27, 2013, at 7:52 PM, Owen DeLong <[email protected]> wrote:
>>
>> Further, the fact that it will is detrimental to good IPv6 deployment
>> and we should, therefore, correct the errors in the fee structure rather
>> than create incentives to create end-user address poverty in IPv6.
>
> How many customers does an typical xx-small ISP have today?
> (xx-small being those ISPs who hold a /22 of IPv4 space)
>
> Based on that, how much IPv6 space are they likely to need
> (using reasonable management practices), and then presumingly
> we add a very large safety factor, what would the resulting
> IPv6 allocation be?
Hi John,
/32, just as the IETF recommends. Given sound technical reasons to
diverge from the IETF's suggestion, I'll lead the charge. But what
sound technical reason do we have for discouraging ISPs, any ISPs of
any size, from starting with at least a /32?
Instead, we intentionally want to avoid slow-starting ISPs with too
few IPv6 addresses as we allude to in NRPM 6.3.4 and 6.3.8.
Regards,
Bill Herrin
--
William D. Herrin ................ [email protected] [email protected]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
------------------------------
Message: 4
Date: Thu, 28 Mar 2013 00:55:38 +0000
From: John Curran <[email protected]>
To: Jimmy Hess <[email protected]>
Cc: "[email protected] PPML" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
On Mar 27, 2013, at 8:40 PM, Jimmy Hess <[email protected]> wrote:
> Well, logically they could have up to approximately1000 customers,
> assuming no NAT and an average of one /32 per customer.
>
> The IPv6 equivalent of 1000 /48s = a /38
Agreed.
Now the ISP could indeed assign a /52 per customer, which means that
/40 would provide for assignments for 4 thousand customers (and at
/56 per customer, well, they can serve quite bit more from /40...)
If we keep them serving 1024 customers, then a /40 provides them with
the ability to serve all of them using /52 size assignments, and an
ISP that feels strongly that a /48 is more appropriate for assignments
could opt for a /36 allocation, and move up to the x-small category
at $1000/year
(In either case, they are paying _far_ less than today's fee schedule
for x-small which is $1250/year if they don't have IPv6, and $1687 per
year if they do.)
FYI,
/John
John Curran
President and CEO
ARIN
------------------------------
Message: 5
Date: Thu, 28 Mar 2013 01:26:50 +0000
From: John Curran <[email protected]>
To: William Herrin <[email protected]>
Cc: "[email protected] PPML" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
On Mar 27, 2013, at 8:50 PM, William Herrin
<[email protected]<mailto:[email protected]>> wrote:
/32, just as the IETF recommends. Given sound technical reasons to
diverge from the IETF's suggestion, I'll lead the charge. But what
sound technical reason do we have for discouraging ISPs, any ISPs of
any size, from starting with at least a /32?
Bill -
The IETF does indeed note in RFC 4029 "Scenarios and Analysis for
Introducing IPv6 into ISP Networks" that the typical ISP would get
a /32, but also recognizes this might not be true for smaller ISPs:
"This document is not aimed at covering small ISPs, hosting providers,
or data centers; only the scenarios applicable to ISPs eligible for
at least a /32 IPv6 prefix allocation from an RIR are covered."
We certainly can have a fee table which ends at the bottom with a /32
of IPv6 space, but given the number of ISPs in that size allocation then
we would also likely have to carry with it very similar fees as today.
By recognizing smaller categories for smaller ISPs, we are enabling them
to get an IPv6 allocation with far lower fees than would otherwise be
possible, and would be quite ironic to deny them that opportunity in
the name of "encouraging IPv6" via one size fits all.
FYI,
/John
John Curran
President and CEO
ARIN
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130328/6a3dac2f/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 27 Mar 2013 20:34:06 -0500
From: David Farmer <[email protected]>
To: Jimmy Hess <[email protected]>
Cc: John Curran <[email protected]>, "[email protected] PPML"
<[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 3/27/13 19:40 , Jimmy Hess wrote:
> On 3/27/13, John Curran <[email protected]> wrote:
>> On Mar 27, 2013, at 7:52 PM, Owen DeLong <[email protected]> wrote:
>> How many customers does an typical xx-small ISP have today?
>> (xx-small being those ISPs who hold a /22 of IPv4 space)
>
> Well, logically they could have up to approximately1000 customers,
> assuming no NAT
> and an average of one /32 per customer.
>
> The IPv6 equivalent of 1000 /48s = a /38
Well technically 1024, but with an 80% rule that is 819 customers.
However, with a residential ISP using customer pools and lets say one
pool of /22 then 512 customers could justify more IPv4, I think. But
with /29 pools you would justify more address space with 80% of the /29
pools allocated or 103; and 50% or more usage in all pools, or 4
addresses; So that could be as little as 103 * 4 = 412 residential
customers. So the CPE for those residential customers are going to
request what size blocks using DHCPv6-PD, probably /64s mostly today,
but some might request /56s and hopefully some will request /48s.
Obviously a /40 wouldn't provide enough /48s, but I'm not sure /48s are
realistic.
While on the other had, you would only need 103 /29 business customers
to justify more IPv4 space. And a /40 provides more than enough /48s to
cover this business customer scenario.
So /40 isn't perfect, but it seems reasonable and would allow a business
case to be built before IPv6 is likely to be the cause of a change in
fee category.
That's my run of the numbers.
Thanks
--
================================================
David Farmer Email: [email protected]
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
================================================
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 93, Issue 16
*****************************************
