On Jan 24, 2009, at 7:29 PM, james woodyatt wrote:
I would say that it's only one of several available approaches to provider independence while preserving a static interior topology without requiring smaller sites to use PI allocations. It has the unique advantage of not requiring existing IPv6 node implementations to be revised, but it comes at the expense of the non-trivial and well-known consequences of network address translation.
In addition to avoiding the use of provider-allocated addresses inside the site, some network administrators also want to avoid the need for their ISP(s) to route their PI addresses. I am not 100% sure why, but given the problems that I've experienced in situations where my companies have asked our ISPs to route our IPv4 PI addresses (allocated from swamp space), it would seem that this type of configuration is less reliable and requires significantly more coordination than having the ISP route the ISP's own addresses and using a NAT box for provider-independent addressing within the site.
While SHIM6 is complicated, I would say that its main detraction as an alternative to NAT66 is that it doesn't have a very good incremental deployment story. It is, however, not the only way to design a shim layer aimed at giving us multi-homing and provider independence. I suspect there are better ways to address that problem, which would still require updates to existing IPv6 node implementations while allowing for a more incremental deployment than SHIM6 does.
I would very much like to see a multihoming solutions (based on SHIM6 or otherwise) that is as easy to deploy (and as incrementally deployable) as NAT. Even if we can figure out a way to do that, though, it will be a while before it is standardized and available, and I think we'll see IPv6 NAT deployment in the meantime (and perhaps in parallel).
Margaret _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
