On Feb 11, 2012, at 12:27 AM 2/11/12, Doug Barton wrote:
On 02/10/2012 20:44, Noel Chiappa wrote:
From: Doug Barton <dougb(_at_)dougbarton(_dot_)us>
You snipped the bit of the my post that you're responding to where I
specifically disallowed this as a reasonable argument.
What an easy way to win a debate: 'I hereby disallow the following
counter-arguments {A, B, C}, and since you have no other
counter-arguments, I win.'
Just because you don't think much of it, doesn't mean the rest of us have
to agree with you on that.
I understand that. Do you understand that I understand what you're
saying, and I don't agree with you?
The new block's purpose is to make collisions impossible.
Ah, no.
If you were to say 'to make collisions very unlikely if it is used in the
way it is specified', then I could agree with that.
Ok, let's go with that. We already have a way to make collisions "very
unlikely," don't use either of 192.168.[01]. Fortunately this method
doesn't require allocation of a new block.
But, what we've been told by operators in the discussion about this draft is
that "very unlikely" is not "sufficiently unlikely", and that no /10 within the
set of RFC 1918 addresses makes the probability of a collision sufficiently
unlikely. You may disagree with that claim, but I think we have to respect it.
So now what we're talking about is how much we're willing to pay to make
the collisions how much more unlikely?
I would certainly feel more comfortable with better data, but it seems highly
unlikely that we can generate it.
- Ralph
But to take a
straw-man absolutist position like "impossible", and then knock it down
with great pomp:
It cannot fulfill that purpose.
I was using shorthand (or argumentum ad absurdum if you prefer) to point
out that given the fact that this new block can't fix the whole problem,
and also given the fact that there are already solutions available that
fix most of the problem for free, allocating the new block is a bad idea.
it's a very irresponsible way for an SDO to conduct themselves.
What, to say 'if you use this in a way that we specifically direct it not
be used, any problems are your fault'?
Again, you snipped the bit where I answered this. Go back and re-read my
previous post if you're confused.
And that's assuming that this action doesn't have a cost, whereas
the truth is that it has several, both direct and indirect.
And that would be...? How exactly does simply allocating a chunk of
address space - something the Internet engineering community does every
day - for a specific purpose "have a cost ... both direct and indirect"?
Again, I'm really trying not to dive back into the "should we" question,
but just as an example, there are 4,096 /22s in a /10. That's 4k new
SMBs that cannot get IPv4 space if this block is allocated.
If you want more, go look at the archives.
If you're actually thinking of 'deploying CGNAT' in the text above, this
discussion is not about that. That's going to happen no matter what the
IETF says/does.
Yep, I get that.
(Just like all those other NAT boxes the IETF huffed and
puffed until it turned blue in the face about.)
FWIW I always said that the IETF sticking its collective fingers in its
ears and singing "la la la la la" instead of acknowledging the reality
of NAT and trying to figure out how to do it right was a big mistake.
This is only about allocating a chunk of address space.
I wish that were true. :)
Doug
--
It's always a long day; 86400 doesn't fit into a short.
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf