Christian, I don't see the advantages of doing encapsulation from the hosts. Instead of going to the trouble of upgrading endpoints with all of the capabilities to determine appropriate site egress points and monitor their liveness so the endpoint's traffic only exits from one site egress point, why not just upgrade the endpoints with a locator/identifier separation mechanism so the endpoints can use all egress points? This will also make it possible for endpoints to take advantage of being multi-homed across multiple domains. This is independent of whether we need NAT66 for the site.
Scott Excerpts from Christian Huitema on Sat, Apr 04, 2009 08:17:53AM -0700: > > 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 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
