Lets start with a few design principles.
1) No application protocol has any business being tied to a particular
packet transport.
If your application transport is passing raw IP addresses about as a
means of forming connections it is broken. IP is the Inter-NETWORK
protocol. The original architecture made no assumption that IP would
run end to end, let alone that the IP address would be constant end to
end.
We have seen the result of designing IPSEC to be intentionally NAT
unfriendly. I was there in the IPSEC WG meeting when folk were
laughing about the problems they would cause for NAT. As a result
IPSEC was a botched protocol and has required ad hoc, proprietary and
in many cases patented tweaks to make it fit for its intended purpose.
Remote access over SSL or SSH works a lot better in practice than
IPSEC does.
I do not see any architectural value in insisting that applications
assume that the IP address is constant from one end of a communication
to the other. It is not a necessary assumption, it is not a helpful
assumption, it is not one that any application protocol can rely on if
it is to work on 99% of the Internet deployed today.
2) IPv6 should be as little different to deployed IPv4 as possible.
IPv4 has NAT, get over it. NAT will be essential to enable the
transition from 4 to 6, get over it. NAT is part of the IP stack and
people will insist that the functionality remains in IPv6, get over
it.
3) You can't force contractual obligations through technology standards.
IPv6 is a hard enough transition without people trying to use it as an
opportunity to refight battles they lost with IPv4. The only rationale
that I have heard for the resistance to NAT that makes the least sense
to me is Keith Moore's point that he would like to force ISPs to
provide functionality necessary for server/peer support.
Whether or not you think that is a good idea, you cannot push with a
piece of string. If Comcast does not want to support certain
functions, they will do that.
Remember that the first rule of the Internet is: You are SO NOT in
charge here (for all values of YOU). The US govt is not in charge,
ICANN is not in charge, Comcast is not in charge, the UN is not in
charge and that even goes for the IETF.
The Internet got the way it was because it did not make unnecessary rules.
Thirty odd years ago, IP address consistency might have mattered. But
the consistency of the Internet is not determined by IP address
consistency any more, it is determined by intersubjective agreement of
DNS address authority.
Asking why would people want to do X is not the way the Internet got here.
NAT66 may not be essential as a security control, but it is mighty
useful as a security audit tool. And auditing the security of a
network is at least as hard as securing one. So I would want someone
who thinks I should not NAT66 to give me a really good reason why not
and an equally effective audit control.
And no, 'I do not have a good feeling in my gut about this' is not an
argument, not even when the person making it is incredibly eminent.
If I sound somewhat testy on this subject, it is because I think that
the anti-NAT camp have been the biggest barrier to deployment of IPv6
by cutting off the only viable technical transition strategy.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf