[arin-discuss] IPv6 as justification for IPv4?

Owen DeLong owen at delong.com
Mon Apr 15 23:11:37 EDT 2013

On Apr 15, 2013, at 19:14 , "Jesse D. Geddis" <jesse at la-broadband.com> wrote:

> Below:
> Jesse Geddis
> LA Broadband LLC
> On Apr 15, 2013, at 5:42 PM, "John Curran" <jcurran at arin.net> wrote:
>> On Apr 15, 2013, at 6:41 PM, Jesse D. Geddis <jesse at la-broadband.com> wrote:
>>> John,
>>> Thank you. Here's my suggestion for fees. Comments are always welcome.
>>> Take the following pieces of data:
>>> Total assigned /24 for IPv4
>>> Total assigned /32 for IPv6
>> How do you wish to count ISP allocations and end-users assignments, 
>> i.e. separately or together?
>> Also, why /32 for IPv6 and not /48?  (presuming 1 /48 per end-user 
>> with IPv6, similar to 1 /32 IPv4 for end-user due to NAT use...)
> John, the only reason I suggested /32 vs /48 is because it seemed to me that the /36 and /48 allocations weren't particularly popular with the members on this list. Their future is unclear to me and I had to pick something :)

You are (potentially) missing the following issues:

1.	Allocations and assignments are distinct from one another.
	The argument on the list has been about ISP Allocations and </32 allocations are, indeed, unpopular.
	However, end-user assignments at /48 are very appropriate.

2.	It is unclear, but some of your earlier language implies you think that end-users and ISPs should pay
	the same linear fee per resource consumed. This brings into question whether an ISP with a /32 should
	pay for 65,536 /48s or a single /32 and whether an end users should pay for 0.000015 /32s or should
	pay for one allocation unit as well even though they'd then be getting a /48 for the price of a /32.

Bottom line, as has been repeatedly stated, ARIN's costs do not scale linearly with the size of the blocks being distributed or the aggregate total address space distributed, so it is unbalanced to have their fees do so.

This not only has foundation, it's been proven by ARIN.


More information about the ARIN-discuss mailing list