[ppml] an interesting debate about v6 [was sort of about 2005-1]

[Owen DeLong]

> I think it is relevant to the policy.  If Michael Dillon is claiming that
> v6 is different from v4 then the policies between the two are different.
> If he's wrong, then why do we have a v4 track and a v6 track.
> 
Michael is neither right or wrong in this case, it's a question of degree.

v6 has bigger addresses than v4.  There are some other differences, but, by
and large, they are more subtle than the address size.  Micahel is arguing
that the difference in address size warrants a whole new paradigm of how
we consider addresses, and, that the abundance of them means that we should
look for other efficiencies no matter how many of them we waste.

Of course, if you read all of Michael's postings, you discover that part
of his apparent motification for this is a desire to exhaust the IPv6
address space in favor of sparking the next innovation.  Personally, I
don't share this particular desire.  

> The point he states and my questioning it are related to the very need
> for the policy.  Perhaps not the contents of the policy, but whether it
> is needed at all.
> 

Well... There are two competing theories on this:

	1.	V6 must provide all the capabilities of V4 and some
		advantage, or, people will not adopt V6.  There is
		reason to believe that the internet should move towards
		V6 because a lot of the current hacks to keep V4 alive
		are starting to bulge at the seams.  As such, there are
		good reasons to encourage V6 deployment.

	2.	V6 must remain architecturally pure and we must never
		again create a non-aggregatable swamp of address space
		that will cause routers to overflow when the DFZ prefix
		table becomes too large.

I believe that number 1 is the more compelling argument.  Not that there
isn't some validity to number 2, but, it has, in my opinion, a number
of fallacies.

	+	The only limit in the current policies is a 2^32 (~4 billion)
		route table, which, no conceivable router is capable of
		supporting.

	+	Provider lockin and other problems of PA space are why
		there was support for 2002-3, 2003-15 (IPv4 Microallocation
		policies), and, these problems are identical in V6.

	+	Operational experience has already taught us that 2002-3 did
		not create a run on IPv4 space as was predicted by the
		anti-PI crowd.  Therefore, the claim that 2005-1 would
		create a run on ASNs is specious.  I doubt it will even
		create a significant run on V6 implementation.  However,
		it will allow a number of organizations which, under the
		current circumstances are saying "IPv6 -- Hell NO" to
		implement v6 because this is their primary problem
		with v6.  Why give up capabilities (tied to PI) that
		I have in v4 in order to migrate to v6?

>> The polciy is about trying to provide PI space to end sites because no
>> practical alternative has been developed or deployed.  The differences
>> between V6 and V4 are marginally relevant at best, and, the debate
>> about prefixes smaller than /48 doesn't seem particularly useful, as the
>> major oppositions to this policy were:
>> 
>>	+	Concern that too many routing slots would be used
>>		(longer prefixes only exacerbate this possibility)
>> 
>>	+	Concern that the policy would create a run on ASNs
>>		(prefix length does nothing about this concern)
> 
> And whether the policy is needed at all.
> 
Well... I would say that this policy is the v6 equivalent to 2002-1,
and, the community felt that 2002-1 was needed.  I guess the real
question is do we want to see v6 deployed, or, let it die on the
vine?  If we want to watch it die, then, rejecting this policy is
a good idea.  If we want to see it deployed, then, I think this
policy, or, some equivalent is absolutely necessary.

Worst of all, I think that some equivalent is already taking shape
in the form of ULA.

>> Yes... I read RFCs all the time.  I also review IETF mailing list
>> archives. If an ID is no longer archived, then, said ID was superceeded
>> by another ID or an RFC, so, most of what you need should be in the new
>> ID or RFC.
> 
> Time to pick in the IETF...
> 
> Not all IDs are superceeded.
> 
True... Some are simply abandoned as a bad idea, but, in that case, they're
still not particularly relevant.

> When I was asked to put in a writing requirement into my networks class,
> I had students try to summarize current activity in a WG or area.  When
> grading time came, I found that the students were up against a larger
> task than I imagined.
> 
Interesting.  I haven't found it to be that much of a problem for any
currently active WG.


> Relying on personal contacts is not scaleable, and is no way to build a
> solid technology or society.  This is why the IETF is dying off. BTW, I
> am a very active person in the DNS area - still, I think the organization
> is moribund.
> 
Agreed.

> Enough of me picking on the IETF.
> 
I was not defending the IETF.  There are lots of things wrong with the
IETF.  However, my point was that PPML is not the place to repair IETF.

>> Sure, IDs and RFCs could be improved.  However, these are the resources
>> that are available.  PPML certainly isn't the place to learn why the
>> IETF did or didn't do something in a particular way.
> 
> PPML is there to vet the results of the IETF.  We are not slaves to the
> IETF...
> 
We are not slaves to IETF.

However, neither is the role of PPML intended to be vetting the results
of IETF.  PPML is to set resource allocation policy in the ARIN region.
There is some overlap between this and the output of IETF, and, sometimes
when the output of IETF doesn't make sense, we have to say something and
make contrary policy accordingly.  However, it is not on topic for PPML
to:
	+	Try to fix IETF
	+	Try to replace the resources lacking in IETF educational
		areas
	+	Debate protocol design or make changes to protocols

>> Huh?  I haven't killed the thread.  My mind isn't made up on the topic.
>> I simply asked us to refocus on the parts of the discussion that are
>> relevant to 2005-1.  I'm not trying to silence you or kill anything.
>> I'm just trying to focus one particular discussion on it's original
>> intent.
> 
> (The "huh?" stuff is a bit off-putting.)
> 
It was an expression of confusion and utter dismay at your statement.

> I'd suggest then asking questions about what you think need to be
> discussed instead of trying to silence discussions others think need to
> be aired.
> 
I wasn't trying to silence anything.  I was trying to get the discussion
about a policy I wrote back onto the topic of the policy.  I'm taking
this back to the list at this point, but, I've changed the topic.

> My point of view is - the fewer policies the better, and the fewer unique
> policies, even better.  Why should there be a policy that is specific to
> v6?  That is what I'm trying learn in this discussion.

However, that's not a 2005-1 question.  That's a much more general question.
There ALREADY is specific and separate V6 policy.  There are a number of
differences in V6 (address size for one) which require different policy.
Different policy already exists.  This proposal, if anything, makes V6
policy more like V4 policy than current V6 policy.

That's why I think your questions, while relevant, are off topic for 2005-1.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050426/475fc137/attachment.sig>