Ted,
I've been trying to stay out of this round of this debate too,
but...
--On Thursday, December 01, 2011 22:07 -0800 Ted Hardie
<ted.ietf@xxxxxxxxx> wrote:
>...
> An enterprise that has numbered into this space and gets put
> behind a CGN by a provider will have no direct control over
> this equipment, and it might happen in the *future* after the
> allocation we're discussing here has been made. Asking
> whether anyone has this pain right now presumes a steady state
> in the deployment of CGN, which, sadly, seems awfully unlikely.
Sure. But, IMO, that is the point at which "should we make this
allocation" segues into "what do you think of CGNs". Now,
personally, I've got a bad attitude toward CGNs. I share the
concerns others have expressed that CGNs (and this allocation
proposal) are not part of IPv6 deployment or transition plans
but are, instead, IPv4 preservation plans... or IPv6 delaying
plans, which, for many ISPs and equipment vendors, might be the
same thing. That bad attitude is driven less by love of IPv6
than it is by the belief that global addressing and [nearly]
end-to-end access are essential to what makes the Internet
technology valuable: that we can innovate easily precisely
because we don't need or have address and protocol-translation
mechanisms in the middle of the network that have to understand
(and effectively give permission for) the applications that are
going to traverse them.
The "data" networking community tried that (arguably a couple of
times) with protocols and addresses that worked up to a peering
point or national boundary and then got translated into
"something else". I'm sure there are still folks around who
think that was a good idea, but I'm not one of them. There are
others who didn't have that experience or don't understand its
implications; for them, old adages about repeating history may
be applicable.
But it is clear that some ISPs are going to deploy CGNs. Whether
they see that as "keeping IPv4 as long as possible", "arranging
a really long transition", or something else --and whether their
rationales actually make sense-- is largely irrelevant. So I
think that question for the IETF is whether it is better to make
this allocation or just let them squat (on 1918 addresses, on
addresses they already have, or on some other addresses they
don't believe will interfere with anything that they are doing).
It seems to me that there are two ways to address that question.
One is the question I think Pete is trying to ask. Restated to
address your "steady state" comment, I'd make it more like:
Assume that no vendor in its collective right mind would deploy
new address translation gear (or firmware) that couldn't cope
with having addresses from the same pool on the "inside" and
"outside" and that we are willing to let the marketplace punish
those who are not in their right minds, the topic of whether a
separate address range is needed to maintain inside/outside
distinctions becomes strictly one of legacy gear -- dealing with
deployed CPE gear that is hard or impossible to replace on a
near-term schedule and, quite bluntly, crappy.
In that context, questions like Pete's make perfect sense
because they are questions about how to patch around said legacy
gear while causing minimum damage to today's assumptions about,
e.g., routable and non-routable addresses.
Even if the answer is "no, there are no devices that both have
172.16/12 wired in and that can't handle overlapping 'inside'
and 'outside' address pools", it doesn't necessarily make
allocating an address pool to this use desirable. But that is
the other question:
Where is the stopping point? If 172.16/12 works for
carrier-grade NATs, will we need a new allocation (possibly the
one requested in the present I-D) for peering-point-grade NATs?
If that allocation is made, will we need another one for
country-boundary-NATs or RIR-boundary-NATs? Conversely, if we
make the requested allocation (rather than using 172.16/12 or
something else already reserved), does that fix anything or just
bring the "next NAT layer, next allocation" question a little
closer?
>From that point of view, this proposal doesn't improve things at
all and doesn't buy enough time to be worth the the trouble.
But one could then claim that any CGN that is deployed would be
able to deal with the same address pool "inside" and "outside"
even if the CPE gear cannot. Fair enough except that then turns
into an argument that providing a special, dedicated address
pool for CGN-CPE interactions just encourages long-term support
for that CPE gear and, worse, violation of the "no ISP in its
right mind" principle expressed above. On balance, a bad idea.
That is perhaps just a long way to say what Randy (I think)
expressed as NAT4444444444444...
> To put this another way, you can't solve the problem of
> equipment which cannot have internal and external interfaces
> being in the same pool by moving to this, in other words; you
> just move the pain from users of one RFC 1918 pool to users of
> another.
Right.
>...
> No, I think that premise is mis-stated. Premise 1: There
> exists equipment that can't handle identical addresses on the
> interior and exterior interface. Premise 2: it may be
> deployed now or in the future for customers using any part of
> the RFC 1918 allocation *because those using the RFC 1918
> allocations had no prior warning that this might create a
> collision*. Conclusion: You cannot avoid identical addresses
> on the interior and exterior interface by using any part of
> the RFC 1918 allocation.
Nor, in the long run, can one avoid it by using any other
allocation model other than public address space allocated and
dedicated to the relevant ISP for non-overlapping use.
>...
> CGNs are, in my humble opinion, an abomination unto Nuggan.
> Whether or not we throw ourselves onto this horn to enable
> them is, at best, a decision that keeping the abomination in a
> pen is better than having it flow over the countryside in
> squat space. But the worst decision we could make is to try
> to pull a /12 out of RFC 1918 space for this purpose; it will
> be at best simply ignored and at worst ensure yet another
> group's ox gets gored.
As you can deduce from the above, I see a --very slight and very
temporary-- advantage of using a slice of 1918 space in this
way, so I'm not certain it is the worst decision. But I think
it only postpones (for a short time) the need for a dedicated
allocation, and then another dedicated allocation, and then...
And, probably sooner rather than later, we get to squat space
anyway. So, if it isn't the worst decision, neither it nor a
new allocation are far off.
Another thing that is interesting about this and, in particular,
about the "do this to avoid squatting" position, is that it
isn't hard to lay out a set of rules that, if everyone would
follow, would make things work. "Use only these addresses for
this purpose, do not use them for anything else, and never,
ever, connect a CGN to a downstream device that has other than
public unique addresses on both sides" would probably top that
list. But every scaling argument that has been used to justify
this shared space proposal and its clones proves that is
impractical and unlikely to be feasible if this is the strategy
we try to follow.
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf