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

[Mark Townsley]

 On 10/13/10 4:00 PM, Owen DeLong wrote:
>
> Regardless of the IPv4 address assignment method, 	the most common
> and most likely 6rd deployment mechanisms are incredibly wasteful
> of IPv6 address space. Further, limiting end customers to /56 is
> also a suboptimal IPv6 deployment.
If you don't like /56, wait until you have tasted /64. That is what is
coming to North America if ISPs in the ARIN region are forced to deploy
within a /32 here. Make no mistake, the Residential Gateway vendors will
figure out how to operate within this restriction, they have over a
decade of experience faking things out for you with IPv4 -- it just will
end up being more brittle and more expensive for the end-user.
> Unfortunately, the current state of last-mile technologies being the
> abysmal mess that it is, we basically have not choice other than
> providing for 6rd as an immediate deployment mechanism. As
> such, it should be done with the following safeguards:
>
> +	Allocations from a specific prefix to facilitate a community decision
> 	to deprecate the technology when it is no longer necessary.
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.

> +	Native deployments should not be shared among the same
> 	IPv6 prefix.
Be careful of unintended consequences here. This kind of directive, if
followed, could actually _discourage_ a smooth transition from 6rd to
native, as well as wasting perfectly usable IPv6 space within the 6rd
block based on hope of future reclamation by ARIN.
> +	We should make strong efforts to communicate and preserve
> 	the notion that this is a transitional and therefore temporary
> 	solution. That last mile technologies must catch up and
> 	provide reasonable and workable native IPv6 solutions.
If ARIN really wanted to take a step forward towards helping the quality
of IPv6 deployment on the Internet via deprecation of IPv6 space, it
would start efforts to see 2002::/16 deprecated. First things first.

- Mark

> Owen
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.