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

[Robin Whittle <[e-mail]>]

I was wrong to assume that TLS/SSL certificates necessarily involved
IP addresses.  I understand they can bind hostnames too.  I made
this mistake because I knew TLS/SSL required a different IP address
for each logical website.  Gert Doering clarified this for me.  The
restriction is not in the TLS/SSL certificate, but in the way the
server has to use a single certificate at the moment a TCP
connection is established, which means only one certificate can be
used for any IP address.

Gert wrote:

>> 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.?
> 
> Most end user networks neither run name servers nor SSL certs, etc., in
> their network range - they delegate that task to their service providers.

I can't cite counter examples, but I would have thought that many
networks would be running their own mailserver, with integrated IMAP
and probably web-based email software, which should run via TLS/SSL.

Also, they would be running links to other offices, which would all
need to be broken and re-established on new IP addresses if
multihoming meant getting new addresses.

What about SSHing from outside into a server in the network?  It
would be not such a good thing to find the server suddenly on
another IP address from last time, due to a multihoming service
restoration operation.  I assume SSH would be fussy about that, but
perhaps I am wrong about that too.  This wouldn't prevent a
connection, its just that there would be warnings etc. - which
should ideally only occur something really is wrong.

If the network suddenly winds up on a different set of addresses, I
don't see how it would be possible to automatically update the DNS
records for all relevant hostnames.  The master nameserver could be
in the current network, or anywhere in the world.

That and the slaves have caching times to reduce their load, so this
will leave some hosts with the old IP address for an hour or
whatever after the MH service restoration event.

I like running my own master nameserver at home, and having a slave
in a server on the other side of the world.

Having the whole network suddenly adopt new addresses due to some
multihoming service restoration event sounds like 100% trouble and
0% convenience and elegance.  It would be far better to have
portable IP addresses which remained the same no matter what
happened with multihoming.


> "all the config files" should contain host names, not IP addresses
> (that's what DNS has been invented for, half a century ago).

I agree.  But how could an automated system update the zone files,
restart the nameservers, and then wait for an appropriate time
(maybe restarting local caching nameservers to clear their cache)
before somehow automatically reloading configurations, re-running
start-up scripts or whatever - in an order which is not going to
cause some troubles?


> Of course there are larger "end users" (corporate networks) that have
> local servers in their network - but even then, with proper planning
> in the setup phase (and that means "not putting IP addresses in places
> that should have server names"), renumbering is not painless, but also
> not impossible.  It mostly boils down to firewall rules, and changing
> glue for a few name servers (again, the "proper planning" thing).

Every one of these administrators would surely prefer to have
portability and to keep the same addresses during multihoming
service restoration.

There are various arguments about why something might be possible,
or why it would be feasible if only programmers did the right thing,
and why it would be best to do this thing for the Greater Good.

But the argument is against a network keeping its own IP addresses
no matter what, people might nod in general agreement - but they
would be nuts to say that there is no cost, no risk etc. making
their network suddenly switch to a new set of addresses just because
one multihomed link went down, or because they want another ISP.

I am adamant that end-users need portability and portability based
multihoming, not some supposedly easy renumbering process and
multihoming which automagically renumbers their network.


 - Robin


_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram