[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
- [RAM] Renumbering impossibility: TSL/SSL certs, D… Robin Whittle
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Thomas Narten
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Gert Doering
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Stig Venaas
- [RAM] Re: Renumbering impossibility: TSL/SSL cert… Stephane Bortzmeyer
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Robin Whittle
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Olivier Bonaventure
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Robin Whittle
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Gert Doering
- [RAM] "End-users" & things I think warrant more a… Robin Whittle
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… JFC Morfin
- [RAM] Re: Renumbering impossibility: TSL/SSL cert… Stephane Bortzmeyer
- [RAM] Re: Renumbering impossibility: TSL/SSL cert… Stephane Bortzmeyer
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … Gert Doering
- [RAM] Re: Renumbering impossibility: TSL/SSL cert… Gert Doering
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … JFC Morfin
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … Thomas Narten
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … Gert Doering
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … JFC Morfin
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … JFC Morfin
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … Roland Dobbins
- Re: [RAM] Re: Renumbering impossibility: TSL/SSL … JFC Morfin
- Re: [RAM] Renumbering impossibility: TSL/SSL cert… Jari Arkko