> 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. I really hope you aren't correct about this, but I fear you are. > So the real question for App designers is: > 1) Should they design protocols that assume no NAT66 > 2) Should they regard the assumption that there is no NAT6 as a design > fault that may lead to lack of interoperability. > 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. Unfortunately, protocol-unfriendly middleboxes are a fact of life even for protocols that have no specific issues with NAT. In the case of email, for example, NAT rarely presents problems even though a significant fraction of message submission occurs from NATted systems. Firewalls are another matter. They cause all sorts of operational problems - so much so that malfunctioning and misconfigured firewalls create a noticeable fraction of our support calls. Frankly, I think it would be good if some of this anti-NAT fervor were to be generalized to other sorts of application-hostile midldeboxes. BUt I've been able to get essentially zero traction on that over the years in the IETF. > 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. I'm sure there will. That said, perhaps one alternative is to attempt to reduce the extent to which NAT66 will be needed by doing what Fred Baker suggests and looking clearly and carefully at the reasons for NAT use. But it is very hard to do this in the present climte of what amounts to religious hysteria on both sides. > 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. Bingo. That's exactly the reason long-term I'll probably do it too. And even this assumes that renumbering support of any kind manifests in a useful way. The absolutely dismal state of support for IPv6 in SOHO-grade routers is IMO one of the orimary current impediments for IPv6 deployment. And when IPv6 support does start to show up in these boxes, I really have to wonder if they'll get automatic renumbering right, assuming it's supported at all. > 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. I went for something like 10 years without having to renumber, and as a result IP addresses got put in all sorts of nooks and crannies on my network. Then suddenly and without warning my ISP announced an emeergency numbering change due to an upstream provider switch. The announcement went out at 11:00PM Sunday night; the renumbering occurred the next morning. It is a bit of an understatement to say I was not a happy camper. And then it happened again a week or so later - easier because I had notes on all the stuff that needed changing plus I'd switched to DHCP as much as possible, but still no picnic. And then I had to renumber again when I switched ISPs ;-) But that should be the last time because I took the opportunity to switch to 1:1 NAT and private address space. In any case, I think getting renumbering right and getting it deployed is an essential step in minimizing the use of NAT66. Ned _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf