[ppml] IPv6 initial allocation policy

[Owen DeLong]

--On March 13, 2006 4:02:04 PM -1000 Randy Bush <randy at psg.com> wrote:

>> 1) The number and density of hosts in IPv6 networks is & will be
>>    irrelevant.
>
> once upon a time, we thought that of v4.  luckily, history never
> repeats.
>
No, we didn't.  Once upon a time, we did not think that there would
ever be enough hosts for the 32 bit address space to be inadequate,
but, that's not the same thing.

>From the earliest days of IPv4, you were not able to get a class A
network for 20 hosts.

>> 3) As long as IPv4 is run in parallel, the number of subnets will
>>    be the same because it would be too hard to explain to ops how it
>>    works otherwise.
>
> this seems to assume that the v6 net is essentially congruent with
> the v4 network.  perhaps this assumption is worthy of exploration.
>
As long as they are run in parallel, at least the overlapping
sections generally will be.

>> 4) If a subsequent allocation needs to be made, it should
>>    aggregate the current one, not just be adjacent (6.5.8.3 needs
>>    work)
>
> like the thousands of de-aggregated adjascent /24s are aggregated
> today?  not.
>
v6 allows for better sparse allocation planning to facilitate this,
however.  v4 did not have sufficient space for sparse allocation planning.

>> 5) The need for PI space has absolutely nothing to do with the
>>    size of the network.
>
> this is a political, not an engineering statement.  while politics
> should not be ignored, social theories which are a radical
> departure, such as every home should be pi, deserve suspicion.
>
There is an engineering requirement for any business which considers
their network access mission critical to be able to multihome in a
way that does not depend on modifications to hosts they do not
control.  Whether we choose to meet this engineering requirement
or not is a political decision, but, that is an engineering
requirement.

>> 6) The only reason for having any measure is to preclude the
>>    masses from taking global routing slots; though specifically RIR
>>    policies 'say nothing about routability of the assignments'.
>
> the reasons for prudence have nothing to do with suppressing the
> proletariat.  they are based in a history of problems with address
> space turning out not to be infinite and routing churn turning out
> to be a serious problem.
>
Nonetheless, the current approach to solving those problems is to attempt
to control the number of organizations which obtain such resources
through some selection process.  Like it or not, the end result is,
essentially, the division of the network into two or more classes
of citizenship based on ability to obtain independently routable
IP space.

>> 8) The number of PI entries and the capabilities of routers will
>>    evolve over time, so whatever approach is taken now it should be
>>    clearly identifiable and allow for future aggregation of early
>>    assignments if/when/where the need arises.
>
> for us to bet on this, the protocols and engineering also "should
> be clearly identifiable and allow for future aggregation of early
> assignments."  are they?
>
Not yet to the best of my knowledge.  However, I don't see the long
term solution possibly including anything short of separation
between IDR Locator and End System Identifier.

>> In the mean time we could discuss the relative importance of
>> putting something in place before it becomes an issue for the ITU
>> to bolster their drive to take over global IPv6 assignments.
>
> or the chinese.  muslims.  or the christian right.  or the
> boogeyman.
>
> can we focus on the engineering discussion?
>
Perhaps you mistook this list for an IETF working group.  This _IS_
a public policy list.  As such, while the policies are engineering
related and thus, engineering is a factor in the discussions,
it is not entirely appropriate to ignore the political.

Owen

-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060313/8ab0ae60/attachment.sig>