[ppml] IPv6>>32

[Leo Bicknell]

In a message written on Mon, May 09, 2005 at 02:26:09PM -0700, Tony Hain wrote:
> I am not suggesting we change 2000::/3 ever. On the other hand we would not
> have to change protocol versions to adjust the allocation policies for other
> /3 prefixes.

The problem with changing things later to be tighter is that it
creates a first mover advantage, where as changing it to be loser
later creates a level playing field.

I will provide a concrete example, picking on BBN since they are
no longer around.  During some of the "bust" hard times BBN would
sell you a T1 with a "free" /24 thrown in.  No justification required.
They had 4/8, it would be a long time until they had to pay the
piper.  Many late comers, without a /8 to toss around were going
back to ARIN every 6 months.  Sales, and the customer wanted to
know why when BBN was giving away a /24, they had to make the
customer fill out a justification form, and then the customer only
got a /28.

If in the future we have to tighten IPv6 allocation policies for
future /3's we stand a chance of doing the exact same thing again.
We reward a company for being around at the beginning, and we create
an artificial advantage for that type of business.

On the other hand, if we start with a more restrictive policy, and
it turns out that later we have more room than we thought we than
then make an intelligent decision to either open up the field equally
to all participants at that time, or to continue with the more
restrictive policy in an effort to extend the life in the protocol.

In short, with the IETF's proposal we have the potential upside of
"something no one has thought of yet" (innovation), and the potential
downside of artificially biasing the business landscape and running
out of address space before we have some other need to replace the
protocol.  With a more conservative approach we have the potential
upside of having a choice later between "roomy" allocations and
extending the life of the protocol and a level business playing
field, and the potential down side of holding back innovation.

We know what the IETF is comfortable with, what is the comfort level
of everyone else involved?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050509/9eccff6b/attachment.sig>