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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf