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

[David Farmer]

On 10/14/10 08:39 CDT, Mark Townsley wrote:
>   On 10/14/10 2:52 PM, michael.dillon at bt.com wrote:
>
>>  Who says 6RD is bad? 6RD and RFC 5969 which documents it, are both
>>  GOOD things because they will accelerate the switch to IPv6. The
>>  discussions are about ARIN policies which SUPPORT and FACILITATE 6RD.
>>  But the fact is that 6RD is a temporary stopgap measure. That is not
>>  bad, that is just the facts. And we should be clear that we are only
>>  supporting and facilitating 6RD as a means to an end, namely native
>>  IPv6.
>
>>  In any case, ARIN is not involved with 6to4, but ARIN can play a role
>>  in facilitating 6RD.
>
> I am very glad to see such a healthy attitude of facilitation. We need
> it, as we still have quite a bit of hill to push the IPv6 rock up.
>
>>  ARIN is not the Architectural Regulator of Internet Networks. It is
>>  the American Registry of Internet Numbers. ARIN does not run the
>>  Internet, not even in the USA. ARIN does not specify the Internet's
>>  architecture and design.
>
> Classifying 6rd as a means to an end for native IPv6 is an architectural
> statement, though one that is at least consistent with the 6rd RFC.
> Limiting the space which 6rd can run, however, presupposes how the
> transition from 6rd to native is to be done.
>
>  From RFC 5969:
>
> The SP can choose to provision a separate IPv6 address block for
> native service, or reuse the 6rd prefix block itself.
>
> An ARIN policy that requires moving to a different block is, by the
> letter, an IETF standards-track RFC violation.

Lets be clear here nothing in the policy says you have to do 6rd from 
one of the transition blocks, or that you can't do 6rd from another 
block.  I believe the policy is saying that, if you want a very large 
block to do 6rd, one big enough to do 32+56, that you may not have 
justify otherwise, you can have one out of a special transition range, 
but you may be required to return it in the future.

However, If you have enough customers to justify a /24 under normal 
policy you can get a normal block and use it for 6rd and not have to 
return it ever.  Also, you could do 6rd in a normal block and not encode 
the full 32 bits of IPv4 in the IPv6 address.

The policy allow ISPs that may not have otherwise justified a /24 it get 
one to do 6rd.

> I'm calling this out only to underscore that there are serious
> operational considerations with respect to allowing native and 6rd to
> coexist within the same prefix while moving to native. Considerations
> that could actually discourage movement to native by ISPs. We want it to
> be as easy as possible for ISPs to move to native IPv6 from 6rd. This is
> why this sentence exists in the RFC.

Also, nothing is the RFC says that all ISPs should be able to get a /24 
regardless of how many customers they have and then keep it forever.  I 
believe allowing more ISPs to get /24s but out of a transition block 
that may be deprecated in the future is a reasonable compromise.

Realize in order to justify a /24 and giving /56s to customers you need 
more than 591,580,804 customers, remember that you are getting 4B /56s. 
  If you are planing for /48s per customer then you would need 
3,223,061 customers.  But then if you are going to give customers a /48 
after you are done with 6rd, you will still probably need to renumber 
most of your customers.  Because they are packed into a bunch of /56 
near each other.

> Putting 6rd into a segregated block, in particular with the threat of
> that block expiring, only adds to deployment hurdles. Today, it would be
> one more thing that the poor person at the ISP that actually wants to
> see IPv6 deployed before the CGNs take over has to convince his or her
> management is not a future risk factor. Tomorrow, it could be one more
> hurdle for the ISP to renumber their IPv6 customer when moving to native.

Yes, ISP are going to have to make a choice do 6rd probably in a block 
smaller than /24 for most ISPs, but not have to renumber.  Or, to do 6rd 
in a /24, but probably have to renumber their customers, if/when the 
community decides it is time to deprecate the transition block.  And, 
realistically they are going to have to renumber anyway if they ever 
need/want more than a /56.

Are you suggestion that all ISPs should just be able to get a /24 and 
never have to return it?

> I'm all for facilitation. Let's focus on that rather than assuming we
> know how the operator is going to migrate from 6rd to native and
> encoding that in the ARIN policy.
>
> - Mark

The more we talk about this the more I think we should split this into 
two parts a new IPv6 transition policy (like maybe in 6.12) allowing a 
/24 allocation to ISPs out of a transition pool.  Then a separate policy 
allowing subsequent allocations for new projects or other expansion of 
business that were not anticipated when an initial allocation was made. 
  We need to enable a lot of people to get bigger than /32 some of them 
may use this for 6rd, but as long as they justify it with there customer 
base then why not.  Remember the "don't penalize the pioneers" comment 
from the floor last week.

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