![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
| Nowadays people often act as if NATs were the way the Internet was supposed | to work, and that it's the applications and the users of those applications | who are broken if they want a network that supports a global address space. Well, the genie is out of the bottle, and if NAT is winning the fight against NAT-hostile applications, I'd think that applications writers would be better off taking the existence of NAT into account, no matter what their NAT politics are. If a compelling application comes along that is NAT-hostile, that will be interesting, but I can't imagine it's in anyone's interest to provoke such a conflict when there are well-known NAT-friendly ways of replacing embedded IP addresses in most higher-level protocols that use them... For those that are unremittingly unable to use things like the DNS, perhaps the NSRG will cough up an RFC-822 someday soon, and that will let you sleep better at night. :-) | Now you're suggesting that we need yet another layer, presumably something | that runs over NATs. No, something that runs over a catenet of every conceivable type of network, including ones which are IP or v6 based. Why should you care whether routers are making decisions based on tags, 32-bit addresses, 128-bit addresses (or only 64 bits of a 128 bit address), or fully variable-length addresses, or even whether some routers along the way are using one of these and other routers are doing something completely different? Surely you're happy as long as your TCP segment or UDP datagram gets to the right host with a destination address which can be used to get a TCP segment or UDP datagram back to you? IPv4ever ultimately is a UNI philosophy; the NNI is totally up in the air. For now, it's pretty clearly IPv4. Sean.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.