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

[Jari Arkko <jari.arkko at piuha.net>]

Robin,

I'm in catchup e-mail mode...

> 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.
>   

Just FYI...

IPsec VPNs are are capable of surviving address changes when
they are using either NAT traversal or IKE multihoming extensions
(RFC 4555).

> 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.

SSH could also be made resilient to address changes:

 
http://www.usenix.org/events/usenix06/tech/full_papers/koponen/koponen_html/index.html

This isn't used anywhere right now AFAIK and deals with the
client side movements rather than the server. In any case...

> 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.
>   

Sure -- I'm not advocating a model where all these things have to be
taken into account by the individual protocols such as the ones
above. However, given the state of the world right now, people
have found ways to get many of their applications working
despite IP address changes. Routing around damage, you
might say...

Jari


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