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

[Owen DeLong]

On Oct 13, 2010, at 9:38 AM, Mark Townsley wrote:

> 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.

I'm not advocating /64. I'm advocating /48 which requires native rather
than 6rd deployment. I'm saying that 6rd is a necessary evil for the
moment, but, must be regarded as a temporary expedient and still
evil vs. native IPv6 deployment with /48s as was the proper design
of the IPv6 addressing space.

>> 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.
> 
The community is the entire global community. All of us that have to deal
with IP addressing issues. So, for some hold-out provider that failed
to evolve beyond 6rd in a timely manner, sure, they could get
overwhelmed by their competitors deciding not to continue routing
that space. However, if it's several large-scale deployments that
are still stuck with 6rd, I doubt that such filtration would occur on a
meaningful scale.

>> +	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.

I doubt it.  I think if we craft policy to make it clear that service providers
can easily get a separate prefix for native and 6rd purposes, the
6rd coming from space set aside for later deprecation, we have
a good mix in the situation. Providers can easily put their native
deployments on separate and more efficiently assigned address
space and when they no longer need to maintain the 6rd hack
and have migrated the last of their customers off of it, the space
can be reclaimed. When enough providers no longer need it,
6rd in its entirety can be deprecated and providers can start to
choose to filter that space if they wish.

>> +	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.
> 
I don't think we should deprecate 6to4 any faster than we should
deprecate 6rd. In reality, they share pretty much the same level of
problems and ugliness. 6rd has a few advantages in terms of
provider control. 6to4 has advantages in terms of addressing
efficiency. Both have more warts than benefit over all and both
are intended as short-term transitional solutions.

As Leo stated at the microphone. Temporary isn't. As such, we
must take steps to insure that it is or we will be stuck with this for
a very long time. That would be bad.

I will be able to make much better comments on this subject once
the output of the AC meeting last week is made public.


Owen