[address-policy-wg] The final /8 policy proposals, part 3.2

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