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

[David Farmer]

On 10/13/10 11:38 CDT, 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.

Actually I believe most of us agree that, 6rd is probably the best of 
the currently available IPv6 transition solutions for most broadband 
access providers and therefore extremely important for the actual 
deployment of IPv6.

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

I'm not sure that 6rd should be deprecated in the future or when. 
However, I do think preserving a valid option to deprecate it in the 
future is a reasonable precaution, especially given the necessity that 
we move forward with 6rd deployment and not debate the best 6rd endgame 
for an additional 6 months or a year.  And for that matter probably get 
it wrong anyway.

So, I think preserving 6rd endgame options for a future debate and 
moving on to the deployment of 6rd is the most sensible course of action 
for our community at this time.  Making 6rd allocations from a defined 
prefix preserves an option for the community to cleanly deprecate 6rd if 
or when it deems that necessary.  I believe the time to actually start 
the discussion of the proper 6rd endgame is in about 3 to 5 years, not now.

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

Yes, this one cuts both ways, personally I believe this will be the crux 
of the 6rd endgame debate, but only time is going to really tell.  I 
propose we not debate the 6rd endgame now and get 6rd deployed and bring 
up then issue when it is time to start a 6rd endgame discussion in 3 to 
5 years, with a 6rd endgame probably happening 5 to 10 years from now.

>> +	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 think you may have a fair point there, maybe 6to4 should be deprecated 
before 6rd.  Maybe deprecating 6to4 could be used and a pilot project 
for deprecating 6rd.  However, we are still probably a little early to 
be talking about the endgame for either of these transition solutions.

It is important to note, that since 6to4 uses a clearly defined prefix 
it should be possible to deprecate 6to4 when that time comes. I think 
all we are saying is that as a community we want that option for 6rd too.

> - Mark
>
>> Owen

So, I support a designated prefix for transition allocations.  Not 
because I believe it is clear that 6rd or other transition allocations 
must be deprecated in the future, but because I'm not sure they won't 
need to be deprecated.   Without a designated prefix it will be 
virtually impossible to deprecate them in future, if community were to 
desire to do that in the future.

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================