[arin-ppml] Opposed to 2010-9 and 2010-12

[Leo Bicknell]

In a message written on Wed, Oct 13, 2010 at 06:38:14PM +0200, Mark Townsley wrote:
> If you don't like /56, wait until you have tasted /64. That is what is

I would be fine with requiring 6rd to provide a /64, while keeping
the standard that native connections get a /48.  This provides
incentive to the end user to pressure their ISP to move from 6rd
to native, and/or to switch providers to one with native connectivity.

Given the realities of 6rd needing 32 bits to map IPv4 into this
doesn't seem like such a bad thing.

> On one hand, you accept that some ISPs are stuck and need 6rd to deploy
> IPv6 now, but on the other hand you are saying that the community (i.e.,
> the ISP's competitors) have the power to rip their IPv6 deployment out
> from under them at any time. I know you want to be sure that 6rd goes
> away, but this is still throwing the baby out with the bathwater.

I too want to be sure the community can make 6rd go away, because
it is amazing waste of bits, and mapping all the old trash into 6rd
space.  Still, you make a valid point, no one should want to deploy
something that could be ripped out from under them at any time.

I would support making all 6rd prefixes have a minimum lifetime,
perhaps 7-10 years (which should cover even the longest equipment
refresh cycles), after which the community can pull support at any
time.  That way 6rd users have a guaranteed minimum, it can easily
be extended (by the community doing nothing and letting them keep
going), and the community can still pull the plug on this waste.

"ARIN will demand the return of all 6rd prefixes when the prefix is no
longer in use for 6rd services, or when the community decides that 6rd
is no longer a benefit to the community.  This cannot occur before
January 1st, 2020."

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101013/0a326e8d/attachment.sig>