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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf