ietf
[Top] [All Lists]

Re: Consensus Call: draft-weil-shared-transition-space-request

2011-12-05 09:28:18


--On Monday, December 05, 2011 09:59 +0100 Måns Nilsson
<mansaxel(_at_)besserwisser(_dot_)org> wrote:

Subject: Re: Consensus Call:
draft-weil-shared-transition-space-request Date: Mon, Dec 05,
2011 at 12:28:56AM -0500 Quoting John C Klensin
(john-ietf(_at_)jck(_dot_)com):

      (John, this is more of a general rant than a reply directly 
       to you. Please accept apologies for the kidnapping..) 
 
If you advise using some piece of the 1918 space, you can only
say "We aren't aware of anyone using this space under
so-and-so circumstances" and not "We can prove that no one is
using that space".

We can also say "This space is quite possibly used on the
inside of customer-managed devices and thus might create
routing system confusion. As with all use of non-unique
address space, the responsibility falls on the communicating
parties to coordinate their address block utilisation so as to
avoid damaging amounts of ambiguity."

I did 1918 coordination in joint venture networks 12 years
ago, and felt the pain. If I did, then,  being the
wet-behind-the-ears can-do optimist that I was, why is it that
nobody more sane in the industry realised it?
...

Måns,

No apology needed; I certainly agree with the general thrust of
your rant... and that is part of what makes me impatient with
this discussion.

I'll let the co-authors speak for themselves, but the issues
with overlapping "private" spaces and the problems that would
occur with mergers and acquisitions, with attempts to use such
networks as semi-private arrangements among organizations as
well as edge network for the public Internet (including joint
ventures), etc., were certainly discussed when 1918 was adopted
and, I think, pretty well understood at the time.    Before we
started worrying actively about address conservation and
aggregation in the early 90s, the general advice to users of
TCP/IP was that they obtain and use "public" space because
networks that were designed to be isolated from the public
network often ended up attached to it, mergers, joint ventures,
and the like happened, and so on -- precisely to avoid this set
of issues.  The argument for 1918 came down to the belief that
people who saw themselves as running private networks and who
perceived it is being too hard to get public space would do bad
things (like address squatting) if address ranges were not
reserved for private use.  

From my point of view, that leads to two conclusions: (1)
Implementations of devices that are designed around 1918 ranges
but that cannot handle the same ranges "inside" and "outside"
are defective and have been defective since day 1.  (2) Trying
to compensate for those deficiencies by adding more dedicated
shared-private space (or even trying to repurpose existing
shared-private space) will accomplish very little in the grand
scheme of things: as soon as someone tries to layer CGN
arrangements or two ISPs merge and try to merge infrastructures,
we will back into either the difficult problems to which you
refer, a demand for yet another address pool, or forced
renumbering.  My belief --which this discussion has only
strengthened -- is not only that we need to stop trying to
support old and broken-since-birth implementations, but, when
address conflicts are discovered, the only healthy solution is
to fix the problems, not layer kludges on kludges in the hope
that it will be "long enough" before another layer is needed.

While I recognize the off-repeated costs of replacing CPE, we've
been telling people for years that forced-renumbering is a
plausible option.   If we believe it, then renumbering either
the "outside" or the "inside" networks or both should be
practical.  If it is expensive and/or painful, perhaps it is
sensible to give affected end-network customers a choice between
renumbering and paying some of the costs of upgraded equipment
(or of rapid migration to IPv6, even if that effectively
involves both renumbering and new CPE).

    john





_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>