On 18-apr-2006, at 2:22, Erik Nordmark wrote:
Either way, the proxy wouldprocess all shim6-tagged traffic for the host, de-shim it as normal, and then pass the traffic along to the host's IP instead of passing it up tothe ULP.
I think such a proxy could be built, but instead of relying on some complex DHCPv6 coordination of the address assigned to a host, it is much much easier to build and deploy and as IPv6 NAT + shim6 proxy.
I also see problems with getting shim-unaware hosts to receive HBA- or CGA-compatible addresses, but I don't think NAT is the solution. It just breaks too much stuff, and so far, we've managed to keep NAT out of IPv6. Also, what's the advantage of IPv6+NAT over IPv4+NAT?
I think a better way to handle this would be to introduce an alternative security mechanism, such as in the form of regular X.509 certificates that are already widely used for SSL today. (The fact that this allows people to get around HBA patent claims is a nice bonus.)
Although it sucks to add additional stuff to shim6, especially additional stuff of this complexity, I think it's probably worth it as this would allow fully functional proxies without strange tricks. The proxy would have a certificate that covers the DNS names used by the clients, which is a fairly straightforward thing to get off the ground operationally. Hosts would simply use existing address configuration techniques (note that most/all DHCPv6 servers/clients don't support address assignment today) and the proxy would just monitor regular communication without modifying anything, so backward compatibility would be good. Only when there seems to be a failure the proxy does a shim negotiation and starts remapping the actual address used by the client to a locator held by the proxy.
Being able to move multihoming processing to the edge of the network would make shim6 much more viable in enterprise networks. It may also be useful on content networks.
Iljitsch