[RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc.

Robin Whittle <rw@firstpr.com.au> Fri, 03 August 2007 02:37 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGn2f-00032E-FC; Thu, 02 Aug 2007 22:37:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGn2e-000328-JP for ram@iab.org; Thu, 02 Aug 2007 22:37:28 -0400
Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGn2c-00013B-FJ for ram@iab.org; Thu, 02 Aug 2007 22:37:28 -0400
Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id D3E9F59DA2; Fri, 3 Aug 2007 12:37:22 +1000 (EST)
Message-ID: <46B294D6.7070700@firstpr.com.au>
Date: Fri, 03 Aug 2007 12:37:10 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: ram@iab.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Subject: [RAM] Renumbering impossibility: TSL/SSL certs, DNS delegation etc.
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

Here is something further to the discussion in the "First cut at
routing & addressing problem statement" thread on whether or not it
will ever be possible to have a completely automated method of
renumbering a network, here more arguments that it will never be
possible.

In that thread I argue that the RADIR Problem Statement should not
be written as if there was even a slight possibility that new
technologies could make today's networks reliably renumbered by some
automated means.

Even with arbitrary architectural refinements in the networks of
tomorrow, as long as we are still working with IPv4 or IPv6 as we
know them today, reliable automated renumbering is not going to be
possible.

Even if end-users didn't care about portability, many of them need
multihoming.  As far as I know, the only way to cope with SSL
certificates and IP addresses of nameservers programmed into other
nameservers is to implement multihoming with genuine portability so
the servers and the entire multihomed netork keeps operating on the
same addresss.


Not all the occurrences of actual IP addresses occur in the network
itself.

If a server as an SSL certificate, that is specific to its physical
IP address.  No amount of automation can help with that, or the cost
and time-delay of getting another certificate.

Likewise, if the network contains nameservers, the IP addresses of
those will be written into other nameservers.  This takes time and
effort to change, and could result in disruption if the actual
change of address doesn't closely match the change in the next
highest DNS level.

For a substantial network to be able to move to another ISP without
near-certain disruption and without excessive costs, I believe it
simply has to take its address space with it.  Portability is the
only solution.


As far as I know, this notion of IPv6 end-users supposedly being
happy with PA space and automated renumbering has been going on for
ten years or so.  Hadn't anyone thought of all the config files
(named, httpd, imapd, firewall etc.), SSL certs, DNS delegation etc.?


  - Robin



_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram