Terry/David,
Terry Gray wrote:
*without* pervasive PI, the future of NAT (or some other
mechanism for providing address autonomy to organizations)
is absolutely guaranteed forever (even with v6)?
To me, that seems obvious
Obvious it is to me too. Problem is: there are way too many people in
here who have successfully renumbered their 4-host home network and
never worked into a larger environment who think that because they
successfully renumbered their home network in an hour the same can
happen with an enterprise network. They've never been out in the real
world, no wonder why they still wonder why the real world has embraced
NAT.
It does make me wonder if there is any hope for resurrection of 8+8...
There is not. First, 8+8 had disadvantages. Second, even though GSE and
later MHAP tried to reduce the inconvenience, the fact if the matter is
that nothing is as simple as raw PI; any dual-space ID-LOC system
introduces yet another layer of complexity, bugs, incompatibilities,
etc.
In the end, it's all about money and timing is important: 8+8 was
written when a core router had less memory and processing power than the
cell phone I carry. As of today, it costs less to go PI than to go 8+8,
without the shortcomings of 8+8. No brainer.
David Conrad wrote:
The end point identifier's upper 48 (or whatever) bits is being
"network address translated" into the routing locator (the lower
80 bits would be untouched). But to avoid the soul-searing EVIL
(plain and simple, from beyond the 8th dimension) of NAT, you
simply reverse the translation, restoring the upper 48 bits
(which, conveniently, don't have to be carried around in the
packet since the destination is pretty much guaranteed to know
what end point identifier prefix it is at). The two EVILs cancel
each other out.
A while ago, I designed exactly what you are describing:
http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt
It's going the same place than 8+8 and GRE: in the grave. Nice idea, but
too much politics and money involved in deploying. Back to raw PI.
Michel.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf