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

[Mark Andrews]

In message <2376C0DA-2491-40D4-B509-8C643C507A61 at delong.com>, Owen DeLong write
s:
> 
> 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.

And encoding the full 32 bits is not "best practice".  I also really
doubt that there is enough experience to actually define "common
practice" yet.

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

And doing what I suggests works for any number of prefixes.
 
> > 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.

If you don't do wasteful assignment you can do /48 customer assignement
just as easily.

> 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 an
> 	provide reasonable and workable native IPv6 solutions.
>
> Owen
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org