On Jan 23, 2009, at 17:52, Christian Huitema wrote:
The provider independence feature is what Fred alluded to in his
previous message. The idea is to get some kind of static internal
structure, and then present different external addresses depending
on the provider of the day. It certainly has some advantages,
although provider independent addresses provide pretty much the same
result to customers. (Not to providers, of course.)
The multi-homing feature combines some aspects of provider
independence with the old 8+8 idea. It has pros and cons, e.g.
simpler than SHIM6 but also less robust to changes in multi-homing
configuration.
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.
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.
Shorter james: I think the expected benefits in Provider Independence
and Multi-homing are red herrings, and the real argument for NAT66 is
that it Applies No Pressure To Upgrade Existing Node Implementations.
I don't think this concern is worth having.
We have already decided that an update to existing node
implementations -- e.g. for something like NAT64, etc. instead of
standardizing on NAT-PT -- will be necessary to facilitate IPv6
transition in the presence of both IPv4-only and IPv6-only endpoints.
I say we should just find a better tunnel/shim mechanism than SHIM6 at
the same time we are going about the NAT64 thing and revise the IPv6
node and router requirements in one big document drop.
Call it "IPv6-2010: Attack Of The Shims" or something and use it to
drive a whole new upgrade cycle.
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
