Jeroen Massar wrote:
If you have problem with those policies then write up a new policy and submit it, that is an appropriate thing to do on this list.
Poor aggregation is a problem of protocol, not policy.
That is not a essential problem of NAT, because situation is no worse than with IPv6 ISPs not giving stable addresses to its customers.
DynDNS solves that problem perfectly fine.
As you are assuming cooperation between your server and an external relay of DynDNS servers, you can do anything with your server even if it is located behind legacy NAT with no port forwarding.
If you pay some ISP enough amount of money, the ISP will give you a fixed IPv6 address or a fixed IPv4 address+port.
This seems to be a CASH issue then, not a technical issue.
If you assume DynDNS free, you can also assume fixed IPv4 address+port free.
What is an issue though is that at one point there will not be any IPv4 addresses for new organizations to use.
That is the point. Unless NAT is mandated and IPv4 allocation is reduced, there will be the point, before we are ready to migrate to new Internet protocol to solve aggregation problem.
IPv6 then still keeps on working.
In the real world, IPv6 Internet is not yet working at all.
A fundamental problem of NAT was that end hosts did not know its public address and that end hosts did not restrict source port numbers, both of which are solvable and were solved.
Indeed, IPv6 has been solving these issues for a long time already.
Not at all. As dual stack approach being abandoned, NAT between 6 and 4 causes the same problem. The only solution is to use end to end NAT or equivalent technology (such as port-wise routing) with modified end hosts in pure IPv4 world. Masataka Ohta