> This is why I think we'll *lose* if we propose a 6AI solution that > relies on translators, even translators that MUST be augmented with a > SAF mechanism. I don't think we can solve this problem while avoiding > an upgrade for hosts to support an encapsulation.
I agree. I don't believe that a multi-homing system can work reliably without cooperation from the hosts. The good point is that we conceptually understand what is needed: 1) Isolate an edge network and its routers from changes of global addresses: this can be achieved with either a PI prefix or an ULA prefix for the edge network. 2) Hide the internal topology: this can be achieved by using a tunnel between the host and the edge router. This tunnel defines an interface for the host, combining a prefix chosen by the gateway and a unique host identifier. Only the prefix chosen for the edge router be visible outside the edge network, effectively hiding the topology. The host is aware of the external address, thus enabling publication in DNS, etc. 3) Enable multi-homing without relying on PI addresses: use several edge routers and several tunnels. Hosts that have several tunnels can see several addresses and publish them in DNS. The problem becomes the same as other forms of host multi-homing, e.g. combining a broadband connection and a 3G modem. We know that a base line works: pick a working address pair for new TCP connections using DNS, or pick a working pair for RTP connections using ICE. SHIM6, SCTP and other developments allow for harnessing multiple address pairs during a single connection. Of course, tunnels have a cost. Two costs, in fact: transmission cost, due to overhead, and administrative cost, due to setup and management. As James points out, the transmission overhead can be reduced with header compression, so I will look at the administrative cost, and specifically at two costs, establishment and fault resolution. Tunnels have to be established. The hosts have to discover the gateway and configure an "external" address with that gateway. The simplest solution is to use a reserved DNS name for the gateway, and then rely on either RS/RA or DHCPv6 for configuring the address. There can be more complex solutions, e.g. explicit configuration and some form of access control. The good news there is that since there is a form of management, administrators can make sure the computers in New York do not use the Internet access in London, and other such things. Tunnels can fail. NAT can also fail. Some of the failure modes are shared: failures of links and routers in the path between host and edge router, failure of the edge router itself. Tunnel add two specific failure modes: using the wrong tunnel, and using tunnel connectivity for internal communication. Both can be addressed, by managing the edge points and by managing route selection. The good news is that tunnels can be managed explicitly, by opposition to NAT that rely on the vagaries of routing. Explicit management tends to lower the administrative cost in the long run. So, I would suggest that we study a tunnel solution to enable topology hiding and large site multi-homing. -- Christian Huitema _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
