RE: A new spin on multihoming: multihoming classes.

["Christian Huitema" <huitema@windows.microsoft.com>]

> Today, provider independence exits in IPv4. Its name
> is NAT. Even for small setups, and even if (in the US) they
> can get a PA block, most choose to get only a handful of
> public IPv4 addresses and use RFC1918 private addresses for
> all their hosts. Switching ISPs? simple, just change the
> outside address of the router and a few DNS entries.
> Lots of people have a PI block these days:
> 192.168.0.0/16.

This is an extremely naïve view of renumbering. If all it took was "change a few DNS entry", then we should not have any concern with switching IPv6 providers: just switch a few DNS entries and let automatic address configuration take care of the rest. The hard part of renumbering is keeping track of all occurrences of "your address" outside of the DNS, and maintaining existing connections.

The address of a host is typically copied in all kinds of configuration files, both inside and outside the local domains. These can be for example access control lists in firewalls and servers, or start-up lists in applications; we know it is a poor practice, but it is also a frequent practice, for all kinds of reasons. The NAT stuff only helps the internal configuration, i.e. the listing of local addresses inside a local domain; IPv6 "site local" addresses provide an equivalent service. But the RFC1918 addresses, or the IPv6 site local addresses, cannot be used outside of the local site; if you want to program a remote firewall or a remote server to accept incoming traffic from the "Example" corporation, you have to program in the "global" address of that network, i.e. the address assigned by a provider. This programming will have to be updated if the provider changes.

The TCP connection, IPSEC association, RTP streams, are identified by a pair of IP addresses, plus ports or other end-to-end identifier. In-site connections using the RFC1918 or IPv6 site local addresses will survive renumbering. External connection, on the other hand, will appear to the "other" side as being identified by the global address, as a result of the address translation in the NAT; changing providers will change the mappings, and the connections will be lost. A similar problem occurs in the case of "multi-homing through a NAT": if a flow is directed to an alternate provider as a consequence of load balancing or routing changes, then the mapping changes, and the connections could be lost. This problem is in fact addressed in IPv6 with two mechanisms, the notion of "preferred" and "deprecated" prefix that allows hosts to keep using the old prefix for some time and maintain the connections, and the "binding update" that allows hosts to notify corresponding hosts of a change in their address.

Let's please actually solve the problem, not evade in fantasy-land.

-- Christian Huitema