[ppml] those pesky users...
tedm at ipinc.net
Tue Mar 27 17:04:15 EDT 2007
>From: Owen DeLong [mailto:owen at delong.com]
>Sent: Tuesday, March 27, 2007 1:35 PM
>To: Ted Mittelstaedt
>Cc: Howard, W. Lee; Johnson, Ron; ppml at arin.net
>Subject: Re: [ppml] those pesky users...
>> Lee, ARIN and the other RIR's need to admit a huge mistake was made
>> over the IPv6 allocations and then go forward with correcting it.
> ARIN and the RIRs are not the ones who made this mistake. This
>was originally in the plan and the IETF scrapped it from IPv6 for
>I still don't understand (some alleged privacy concerns).
My mistake for blaming the RIR's then. So I take it you do agree that
it was a mistake to not put in the assumption of easy upgrade into IPv6.
That was my point.
>Short of a reserved v6 prefix which maps to v4 numbering, this doesn't
>make sense to me. If we're going to go to the trouble of maintaining
>registrations, then, not everyone who has v4 needs v6
Not now, but in the future IF we switch to IPv6 then everyone WILL need
IPv6 who has IPv4 assigned.
> and there's no
>reason for the RIRs to provide free registration services on this basis.
Exactly, that is why this wavier on IPv6 is a bad idea. Every year it
is going to get renewed, in the name of "encouraging" people to switch to
IPv6, and every year more and more IPv6-only freeloaders will be out there.
By the time that we have reached the point that there is more IPv6 assigned
than IPv4, there will be heavy political pressure to not get rid of the
It's better now to just get rid of it. I believe there is sufficient
proof that monetary incentives have not encouraged much growth in
IPv6 assignments. Just assign everyone IPv6 and be done with it.
>> The best thing going forward would be for ARIN and the other RIR's to
>> drop the IPv4 and IPv6 fee schedules (the wavier is a joke anyway,
>> is the point of an IPv6 fee schedule with a fee of $0) and replace it
>> with a single IP allocation fee schedule that applies to both kinds of
>> numbering, then for all current IPv4 holders that the numbering
>> have assigned numbering for, just go ahead and assign IPv6 allocations
>> at a 1 to 1 ratio. (for every single IPv4 address you get an IPv6
>> It's not like there's any shortage of IPv6.
>That's not feasible with the IPv6 architecture. To take this a bit
>minimum allocation unit in IPv6 is a /64 network. The RIR minimum is a
>/48 with very few exceptions. A /64 is approximately 4 billion times
>number of IP addresses in the entire IPv4 internet, so, a 1:1 assignment
>ratio simply isn't possible even at the smallest possible network block.
>A single /64 would be more IPv6 addresses than ANY IPv4 holder
>currently has. However, many IPv4 holders really need the ability
>to create multiple distinct networks. IPv6 (for better or worse, and,
>this is the IETF and not the RIRs decision) has returned to classful
>addressing, at least to some extent. The new format has been set
>up as NNNN:NNNN:OOOO:SSSS:HHHH:HHHH:HHHH:HHHH:HHHH
>where NNNN:NNNN is a 32 bit network number, mostly intended
>to represent the LIR. OOOO is 16 bits which would generally
>represent which Organization the LIR assigned the subordinate
>addresses. SSSS is 16 bits for the organization to use for
>subnetting. The remaining 64 bits are host address because for
>some reason, the IETF thought that having really sparse host
>assignments on a subnet was somehow valuable.
Excellent analysis. So, given all the above, what ratio do you think
>Given the significant differences in address structure, subnet size, and
>implementation, i just don't see that as a feasible plan.
Owen, what do you want? Do you want the Internet to stay IPv4 forever?
Or do you want it to go to IPv6?
If you want it to go to IPv6 then your going to have to come to grasp with
the FACT that IF the Internet goes to IPv6 that eventually EVERY IPv4
holder WILL HAVE AN IPv6 ASSIGNMENT.
You are saying it isn't feasable now to assign all IPv4 holders IPv6. Well
if it isn't feasible now, it won't be feasible in the future, either.
More information about the ARIN-PPML