On Mar 10, 2009, at 3:52 PM, james woodyatt wrote:
On Mar 10, 2009, at 15:20, Fred Baker wrote:
On Mar 10, 2009, at 3:13 PM, Brian E Carpenter wrote:
But of course prefix translation doesn't provide the "benefit"
described in RFC4864 section 2.4.
Very explicitly, which in my opinion is quite important.
Specifically, under Margaret's model, an end host behind a N**66
can directly and predictably address another host behind a
different N**66 and exchange any application's data flows with it.
That's not true of the other N words...
They cannot exchange *ALL* application data flows. Only *SOME*.
More specifically, only those application data flows in which nodes
either A) do not exchange global scope IPv6 interface addresses with
one another for callbacks, or B) coordinate by some as-yet-
unimagined protocol with all the prefix-translating middleboxes in
any given path between peers to make sure that each remote node uses
the appropriate callback address to the local node for its routing
realm.
OK, yes. You can't do routing exchanges across this if they assume a
common address space.
That we keep forgetting this is a dismaying forewarning of the
future architectural problems we will bring upon the Internet by
advancing this proposal in the standards track.
For the record, the issues with NAT came, and it was not on the
standards track. It wasn't initially even documented in an RFC. Trying
to kill the discussion isn't going to kill the concept.
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
