![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Eric,The problem here is that you assume that the IETF has decision power that can magic away NAT66. Clearly it did not for NAT44 and will not for NAT66.
The only way that the effort being expended to kill NAT66 makes any sense is if the idea is to allow this type of argument to be rulled out of scope as similar arguments were ruled out of scope when they were brought up in existing protocols that simply do not work properly because the design was intentionally made to be unfriendly to NAT.
If we recognize that there is no consensus that applications that are not NAT66-agile will work in future then we should agree that the reasonable default requirement for an apps WG should be that it should build a protocol that is NAT66 tolerant. But I suspect that there will be severe pushback against that.Peter Dambier is right in this case,I would NAT66 my network for the simple reason that very few endpoint devices actually tollerate a change in the IP address without at a minimum a service interruption. Since I cannot guarantee that my IPv6 address from my ISP will never change I am going to NAT66 my internal network for the sake of having static numbering inside the network.The more infrequent you posit the need for renumbering is, the greater my reluctance to allowing it will become. If you have a network event that happens only once a year it is going to mean a very serious disruption when it happens. DHCP only solves some of the problems, I am still effectively forced to perform a reboot, I will lose connections and this will cost me real time and money to fix.
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.