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

[michael.dillon at bt.com]

Would you two please stop this!!!
Either get an email client that supports proper quoting of messages or reformat
the lines with > characters manually. It is all but impossible to follow what
you two are saying in your fractured messages.

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Thursday, October 14, 2010 8:06 PM
> To: Mark Townsley
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Opposed to 2010-9 and 2010-12
> 
> 
> On Oct 14, 2010, at 9:56 AM, Mark Townsley wrote:
> 
> 
> 	On 10/14/10 5:02 PM, Owen DeLong wrote:
> 
> 
> 			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.
> 
> 
> 
> 		However, this is not the first time the IETF has made the
> mistake of stepping over the line from Architectureal
> 		design to address policy. ARIN sets address policy for the
> ARIN service region, the IETF does not.
> 
> 		Another example of ARIN policy correcting this error on the
> part of IETF would be 2005-1, prior to which
> 		there was no facility for Provider Independent End User
> assignments in ANY region. Today there is
> 		policy to support those assignments in all 5 regions.
> 
> 
> 			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.
> 
> 
> 
> 		Yes... Those operational considerations are hazardous to
> address policy and would prevent any ability to
> 		ensure the eventual deprecation of this "transitional"
> technology at the expense of vast amounts of address
> 		space which would have been distributed in an excessively
> (even by IPv6 standards) wasteful manner.
> 
> 		I'm all for 6rd as a temporary fix, but, as a permanent
> institution, it is pretty awful. Even if we ignore the
> 		issue of deprecation and assume that providers would switch
> to native without additional motivation,
> 		allowing them to have their native and 6rd deployments to
> co-exist in the same space would result
> 		in sparse allocation of their native blocks across the
> oversized prefix granted for 6rd which would
> 		prevent future reclamation of that oversized prefix.
> 
> 
> 		By requiring the native deployments to go in a separate
> prefix which is more appropriately sized for
> 		the ISPs native deployment, we ensure the ability to
> eventually reclaim and re-use these oversized
> 		blocks for other purposes.
> 
> 	6rd is just getting deployed now, so precisely how to transition
> it to native is still speculative. But, I know that technically it is
> quite possible (with equipment that will be available in 2011, if not
> today) to allow 6rd and native exist alongside one another in a very
> transparent manner to the end-user. Native can be brought up (or back
> down if there is a problem) one CPE, one head-end or one DSLAM at a
> time in whatever order the network operations folks want without having
> to alert the customer-care folks that have to deal with IPv6 being
> renumbered within the house, nor dealing with the well-known issues of
> multihoming towards two disparate address blocks. Once, say, a region
> of the network has transitioned appropriately (something that may only
> happen after the last end-user goes out and buys the right CPE, or the
> operator deploys enough native gear), a move to a more aggregated space
> and disabling of 6rd within the region can be scheduled appropriately.
> Policy should not disallow nor even discourage such an approach.
> 
> 
> 
> Nothing in what I have proposed prevents that. The operator can use the
> 6rd space to do the transition and then renumber after the transition
> is done if they want. The key is not to believe that the 6rd space is
> in any way permanent.
> 
> The policy sent to last call by the AC merely requires that the 6rd
> allocations be done from a specific prefix for that purpose and conveys
> that the 6rd allocations are transitional and temporary in nature.
> It doesn't do anything to interfere with the approach you describe, so
> long as the provider does eventually get to that renumber point.
> 
> 
> 	Again, I'm trying to make it *easier* for the operator to move to
> native. I want the operator to have tools available to make that as
> easy as possible, with the fewest moving parts. The incentive to have
> native v6 customers within an aggregated space will still be there,
> even if native and 6rd interfaces are allowed to exist at the same
> time, but that move can be staged and scheduled with appropriate
> advance notice and care independent of getting the user on native as
> soon as physically possible.
> 
> 
> 
> We're in agreement there to a certain extent. However, it has to be
> done with responsible address management in mind as well. Making the
> 6rd prefixes permanent would be irresponsible.
> 
> 
> 	We agree that 6rd should be temporary. I think we even agree that
> it might take 10 years to move completely from 6rd to native. I'm even
> be OK with asking the provider to give back the block when they are
> done with it if we are demonstrably on track towards some new global
> IPv6 address exhaustion problem. We aren't far away from one another
> here.
> 
> 
> 
> Agreed.
> 
> 
> 
> 			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.
> 
> 
> 
> 		There is no threat of that block expiring. The intent is to
> allow for a mechanism by which to signal the following:
> 
> 		1. Native deployments should go in a separate appropriately
> sized block.
> 		2. 6rd is temporary and transitional in nature. It is not
> to be considered permanent.
> 		Temporary in this case may well span a decade, but, there
> should eventually be an end date.
> 		3. The sooner you migrate your customers from 6rd to
> native, the better. There is value in pressuring
> 		your vendors to make this possible.
> 
> 	I think #2 and #3 are reasonable, and you don't need #1 to make
> that clear.
> 
> 
> 
> No, but, you do need #1 to make it possible to enforce #2 and #3 later.
> 
> 
> 
> 		The CGN FUD really is overplayed here. Even with this
> limitation, CGN remains far less attractive to
> 		any provider.
> 
> 	Then why are so many looking to buy them? Why the policy
> proposals for a shared-SP space?
> 
> 
> 
> There are no policy proposals for shared-SP space. There is an IETF
> draft. The IETF draft in question is generally opposed in the address
> policy community, to the best of my knowledge.
> Most of the discussions I've been involved in where it was a subject
> were about the number of different ways in which said draft was a bad
> idea.
> 
> Frankly, I'm betting that the providers that buy CGNs will be very
> dissatisfied with them in relatively short order. I also think that
> they will be encouraging their customers to switch to other providers.
> 
> 
> 		Even a provider which doesn't see this, I am pretty sure
> that their customers will see it
> 		in short order.
> 
> 
> 	I heard the same argument 10 years ago about the NAT the
> customers now claim they NEED. Perhaps your view is tainted by being so
> close to the IPv6-enabled world. From my vantage, we are still very
> much in a battle.
> 
> 
> 
> I tend to doubt it. NAT was pretty bad, but, CGN/LSN/whatever you want
> to call it is far less attractive from the SP and the customer
> perspective than NAT was. It's all the problems of NAT amplified many
> many times over with some additional new unique problems.
> 
> I think that the odds of CGN/LSN making it to wide-scale deployment are
> near zero.
> Notice that nobody has even tested CGN/LSN on real end users yet.
> 
> 
> 
> 			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.
> 
> 
> 
> 		The point of this aspect of the policy is not that we are
> assuming the operator will migrate. We are
> 		requiring that they eventually do. Allowing them to hang on
> to these oversized 6rd blocks beyond
> 		the point where a switch to native is practicable is not
> good stewardship of the address space.
> 
> 		If you can get 6rd to fit in  single /16, then, perhaps we
> could consider allowing it to be permanent.
> 
> 		However, if ~3,000 ARIN members deploy 6rd /24s, then,
> you're talking about the vast majority
> 		of an entire /12 just in the ARIN region. Since most of
> them could deploy native and give their
> 
> 	"most of them could deploy native"?? Wishing this to be true will
> not make it happen. The problem is that they evaluated deploying native
> and realized the could not and only then did we come along with 6rd and
> turn things around. That's where we are, like it or not. But I think
> you agree with this as your report on which technologies work and which
> do not on this thread was quite accurate.
> 
> 
> 
> You misunderstand me... I wasn't saying they can deploy native now. I
> was saying that once native is a possibility, the required address size
> for native is several orders of magnitude smaller while providing a
> couple of orders of magnitude more address space to their customers.
> 
> Please take this paragraph only in the context of measuring the
> relative address consumption/ unit of customer space and not as a
> statement of current abilities.
> 
> Owen
> 
> 
> 	- Mark
> 
> 
> 		customers much larger (256x) assignments and fit within
> 1/16th of the proposed address space
> 		for 6rd, (IOW, a 4096x gain in addressing efficiency), I
> believe that the ARIN community has
> 		a valid interest in ensuring that this is a temporary use
> of address resources.
> 
> 
> 
> 
> 
> 
> 		Owen
> 
> 
>