Sam Hartman wrote:
I think that real ISPs will ship NATs that comply with behave. If you
think that address independent and endpoint independent mapping
behavior with endpoint dependent filtering behavior counts as punching
holes then I disagree with you.
Establishing persistent state on an ISP infrastructure device is punching a
hole. It doesn't matter if that is a nat, or a STUN relay, the fact that a
customer locked it down will raise the potential for contention, and in fact
creates a routing entry that is not under the ISP's control.
Why will ISPs support this? Because their customers voip phones and
games will want it.
They are more likely to want to force the phone traffic through a call
control point so they can count bits and bill minutes.
I am willing to conceded on the behave point because client side actions
really don't matter, but I want to see multiple people running mta's and
independent web servers on the nat'd IETF network, with active connection
attempts to them from the outside. Nobody can physically configure the most
public nat, and no signaling of it is allowed because it is operated by a
third party that doesn't trust you. If you want a real indication of future
problems, run real services from behind the magic solution and document its
complete failure.
Tony
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf