Subject: Re: Last Call: <draft-weil-shared-transition-space-request-14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

From: [email-masked] (Noel Chiappa)
Date: Fri, 10 Feb 2012 23:44:42 -0500 (EST)

> From: Doug Barton <[email-masked]>

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

    > 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. But to take a
straw-man absolutist position like "impossible", and then knock it down
with great pomp:

    > It cannot fulfill that purpose.

is not exactly a plausible argument. Outlawing cell-phone use while driving
may make accidents caused by cell-phone usage less likely, but it can't make
them impossible. Only physics (and math) make things _absolutely_ impossible

    > 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'?

That's odd, because my lawnmower says much the same thing: 'Don't use this
as a hedge-trimmer. If you do, and cut off your arm, don't even bother
thinking of suing us, because we warned you not to.' (OK, so I translated
the legalese into something more amusing, but the basic message is exactly
that.)

    > 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"?

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. (Just like all those other NAT boxes the IETF huffed and
puffed until it turned blue in the face about.)

This is only about allocating a chunk of address space.

	Noel

---

From: Doug Barton <[email-masked]>
Date: Fri, 10 Feb 2012 21:27:17 -0800

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

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

So now what we're talking about is how much we're willing to pay to make
the collisions how much more unlikely?

> But to take a

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.

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

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

> IETF says/does.

Yep, I get that.

> (Just like all those other NAT boxes the IETF huffed and

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/

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 11 Feb 2012 09:32:04 +0100

> This is only about allocating a chunk of address space.

For which there is better use than prolonging bad technical solutions. 

Address translation has set the state of consumer computing back severely.
It might be all nice and proper according to those who desire to keep the
power of owning a TV transmitter, a printing press or a transaction broker
service.

Do keep in mind that the real driver in IP technology is the ability
for end-nodes to communicate in a manner they chose without prior
coordination with some kind of protocol gateway. NAT and more so CGN
explicitly disables this key feature.

And this is not what the IETF should be doing. The IETF should seek
to maximise the technical capabilities of the Internet protocol
suite so that it may continue to enable new uses of the key feature,
ie. end-node reachability.

Allocating CGN-blessing address space is a clear violation of this.

-- 
Måns

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 11 Feb 2012 12:31:22 +0100

> Allocating CGN-blessing address space is a clear violation of this.

Is that true?
And if so, why and how can it be formulated or find support it earlier work?
And if it is not true. Why and where do you find support for that view?

I ask because you might touch something quite fundamental there... can
IETF support something that will break/limit reachability on Internet.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 11 Feb 2012 15:15:39 +0100

> IETF support something that will break/limit reachability on Internet.

IMNSHO, the answer should only be NO to that question.  Where can I search
support for this view? I believe, for starters, that:

a/ The original IPv4 Internet was designed with a flat reachability
   model, as seen from the host IP-stack. (routers are a different thing,
   but indeed the flatness repeats itself, technically, in the DFZ.)

b/ When the Internet faced an address shortage there were two solutions
   put forward; one being CIDR and the other being IPv6 (nee IPng,
   IIRC). While it is true that there was work codified in RFC 1631 etc that
   makes the IETF one of the culprits behind NAT, it is also written that

   The short-term
   solution is CIDR (Classless InterDomain Routing) [2]. The long-term
   solutions consist of various proposals for new internet protocols
   with larger addresses.

   Until the long-term solutions are ready an easy way to hold down the
   demand for IP addresses is through address reuse. 

	....

   This solution has the disadvantage of taking away the end-to-end
   significance of an IP address, and making up for it with increased
   state in the network.

		(RFC 1631, p1)

   We here clearly see that the authors tasked with describing address
   translation were fully aware that they were breaking E2E, and that
   they saw address translation as an intermediate measure to be retired
   as soon as suitable long-term measures were available.

   Reading further in the sequence of IETF documents describing NAT,
   we discover something of a more defaitist position in 3022. The
   discussion on disadvantages is still there, but there is less talk
   of replacing NAT with v6. Apparently the massive success of broadband
   routers was showing.

So. With this little historical research made, I think that we can see
a couple of  things:

1. The IETF knew the drawbacks. 

2. NAT was only a desperate measure. 

3. NAT was to be retired when IPv6 was ready. 

4. The IETF failed to predict the massive market penetration of broadband
   routers and similar solutions.

The key question then becomes, are  the market lemmings throwing
themselves over the NAT cliff reason enough to give up sound engineering
principles? I think that numbering critical devices in a sunset phase
(where IPv4 is, resource-wise) uniquely is a more prudent use for address
space than giving it away to people who've made bad business decisions
(which doing any network business without v6 firmly on the 1-year roadmap
is, post say 2006). Especially since it will be used to keep running a
system that the IETF has known for 18 years to be severely deficient.

-- 
Måns

---

From: Ralph Droms <[email-masked]>
Date: Sat, 11 Feb 2012 07:52:50 -0500

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

> 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

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 12 Feb 2012 08:51:53 +0900

> For which there is better use than prolonging bad technical solutions.

A problem is that IPv6 is a bad technical solution.

For examples, its bloated address space is bad, ND with full
of bloated useless features is bad and multicast PMTUD only
to cause ICMP implosions is bad.

> Address translation has set the state of consumer computing back severely.

No, not at all.

> explicitly disables this key feature.

Wrong. Nat can be end to end transparent, if hosts recognize
existence of NAT and cooperate with NAT gateways to reverse
address (and port) translation.

See RFC3102 and draft-ohta-e2e-nat-00.txt. I have confirmed
that PORT command of unmodified ftp client just work.

Though my draft assumes special NAT gateway, I recently
noticed that similar thing is possible with UPnP capable
existing NAT gateways.

> ie. end-node reachability.

Yes. So, let's abandon IPv6, a bad technical solution, and
deploy NAT with UPnP or PCP (if designed properly) capabilities.

					Masataka Ohta

---

From: Doug Barton <[email-masked]>
Date: Sat, 11 Feb 2012 16:10:28 -0800

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

Why do we have to respect it? Completely aside from the issue of
trusting the fox to report on the security conditions of the henhouse,
we haven't been provided any data to support the claim. What they're
saying is, "We don't have data for this, and we won't generate it. But
we want you to trust us anyway that doing this thing that overwhelmingly
benefits us is the right thing to do."

Now on its face that's a bad deal no matter how you look at it. Now add
in the fact that this issue has been created by the same foxes refusing
to invest in IPv6, AND the assertion from people who know better than I
that most of the problem can be dealt with by avoiding 2 1918 /24s, it
just keeps getting worse.

Make no mistake, I understand what they are asking for, and I'm very
confident that I understand why they're asking for it. It makes their
job infinitely easier if they can be given a /10 that, at least in the
short term, they can be close to 100% certain will not be used inside a
customer network. That way they don't have to think hard about their
network design (and don't have to take as many customer service calls),
and they will have N more years to diddle away until customers start
using that block internally. And then the whole thing goes pear-shaped
again.

So no, I don't have to respect what they're telling us.

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

Generating the data on what CPEs use what blocks by default and how
prevalent each of them are in the market is simply a matter of time and
money. These types of surveys have already been done for DNSSEC, so we
know exactly what it takes to do them. The fact that the same people who
want us to spend valuable public IPv4 addresses so that they can save
time and money with their CGN deployments are also refusing to spend the
time and money necessary to back up their claims should, really, be
making more people angry than it seems already are.

And while I'm at it, John Klensin's post today about the "get everyone a
new CPE" topic was a much more thorough treatment than I'm capable of,
so I'll just add a +1.

Doug

--

---

From: Randy Bush <[email-masked]>
Date: Sat, 11 Feb 2012 16:25:14 -0800

> But, what we've been told by operators in the discussion about this
                              ^ some
> 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.

aside from inter-operator acquisitions, this space will be used as 1918
and will soon have the same collision properties.

but we have had this discussion many times.  no one is changing anyone's
minds.  the iesg is simply trying to justify a bad position, where no
position is particularly good.  how much email do we all have to read to
paper over the iesg's lack of guts?

randy

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 11 Feb 2012 23:11:38 -0800

> with that claim, but I think we have to respect it.

Given a provisioning system with two pools  of address for a given set
of customers, it can likely be demonstrated that no deployed consumer
cpe is internally numbered in both of them.

Managing breakage due to an address collision with existing cpe is one
kind of support cost. Managing breakage due to a new formerly
non-private scope address range now being employed is another support cost.

It's entirely possible that reasonable people with experience operating
consumer facing networks can disagree on which cost is more onerous.