Mohacsi Janos wrote:
Or, better, in a way that does not cause the bad luck for foreseeable future, which is possible by reducing amount of address allocation assuming extensive use of NAT and start working on using Classes E and part of D for unicast.
This hardly work: you have to change protocol stack of billions of device.
For network devices and class E, it is no difficult than subnetting. Class D may needs some more time. For end hosts, hosts within leagacy NAT does not need any change.
Note that NAT can be end to end tranparent.
Can you explain how?
How, do you think, legacy NAT is NOT end to end? The below is explanation on it in draft-ohta-e2e-nat-00.txt. According to the end to end argument [SALTZER]: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) NAT can completely and correctly be implemented only with the knowledge and help of the end hosts behind a NAT gateway. That is, by let end hosts cooperate with NAT gateways, NAT can be and actually is end to end, which requires modification on end hosts. Note that an unmodified end host can operate just as an end host behind regacy NAT and that, with the modification, end hosts may also be modified to treat class E and part of class D for unicast. Masataka Ohta