> I actually wouldn't have any objection to some mechanism built into NAT that > allowed for a requesting host/application to be informed of the Public > Address it would be assigned by the NAT device. My only caveat would be that > the Administrator SHOULD be able to disable such functionality on a given > interface if they choose. It could be enabled by default, but there should be > an option to turn it off if you explicitly choose to do so.
Why are you trying to cripple apps? If you don't want certain apps to function across your network border, disable their traffic at the firewall. You're trying way too hard to make NATs do a firewall's job. > Note that I understand the reluctance for applications to rely overly on DNS. > For practical purposes with propagation and caching issues, TTL's are often > not respected. True, but there's a lot more to it than that. Here's a quick example: Say you want to write an app that needs to do referrals. Say further that the app needs to be port-agile because of the potential for NAPTs in the signal path. Let's say further that the app uses ICE or some other heuristic to find its external/global transport address. Where in DNS is the app going to store that transport address? (Don't say that the application vendor should provide zones and servers for that purpose - that's basically tantamount to saying that every app needs to have its own referral servers in the public network. Also don't say that the app should be able to use the host's DNS zones, because admins are highly unlikely to allow that.) How is it going to reliably store/update that transport address given that some ISPs intercept port 53? How does the app get credentials to allow it to write RRs to that zone? And how much does that really help the referral problem? Sure it provides some insulation against the transport add ress changing - assuming the app notices the change it can update the transport address in DNS. But there is the TTL problem, as you point out. DNS is fundamentally designed for storing data that doesn't change often, and where the changes are managed events. And even if you can use small TTLs and get all of the parties involved to respect those TTLs, that doesn't fix TCP connections that break when the transport address changes. And that's just one example. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
