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

[Owen DeLong]

On Oct 12, 2010, at 8:55 PM, Mark Andrews wrote:

> 
> There is a increadable amount of bad information being spouted here.
> 
> To deploy 6rd in parallel with a native deployment you roughly need
> double the IPv6 address space of a straight native deployment.
> 
> You need a /56 (/48) for every address in the DHCPv4 pools.  For
> each DHCP pool you specify a 6rd prefix and set the IPv4MaskLen and
> 6rdPrefixlen so you are not wasting IPv6 space.
> 
That is not the common practice.

> e.g.
> If you have a 2 disjoint /16's spead over, multiple pops, then you
> will have 2 6rd prefixes in use both with a IPv4MaskLen of 16.  Only
> one of these will be handed out to a specific customer.  If you are
> handing out /56's then the 6rdPrefixLen would be 40.  Each of these
> 6rd prefixes would be a /40.
> 
For the handful  of providers that have only 2 prefixes, that may be.
For the vast majority of providers, the common practice (having more
than a couple of prefixes) is to map the entire IPV4 space onto
a customer prefix size (e.g. /56) yielding a need for a /24 (56-32)
prefix for the ISP. Since no ISP has a significant fraction of the
IPv4 space, much of that /24 is wasted.

> If you are handing out NATed addresses to your customers then you
> may need to be more conservative in your DHCP pool sizes as the
> pool size impacts on the amount of IPv6 address space needed.
> 
> If you are not using DHCPv4 for this you will most probably want to
> code up a web page that returns custom 6rd parameter result based
> on the IPv4 address the query came from plus the ablity to manually
> specify the address that you want the 6rd parameters for.
> 
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.

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.

+	Native deployments should not be shared among the same
	IPv6 prefix.

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

Owen