On Oct 27, 2010, at 8:57 AM, Rémi Després wrote: > Le 27 oct. 2010 à 14:14, Keith Moore a écrit : > >> IMO, a minimum requirement for any v6 NAT approved by IETF is that >> hosts/apps MUST have a way to determine the external/global addresses >> associated with a connection without needing an external server in global >> address space for ICE or similar tricks. >> This mechanism MUST be the same mechanism for all standard NATs. > > I agree with this, but then host modifications are needed anyway.
If the mechanism were defined carefully, an app could determine what the NAT was doing without host support. Apps that don't care about addresses could continue to work without any host changes; apps that do care about addresses would have a way to adapt to the NATted world without waiting for host OS to be upgraded. The trick is then for the OS vendor to figure out how to upgrade the network API without breaking apps that were working. This is nontrivial, but it can be done if people resist the temptation to try to create illusions for apps. If the OS wants to create an abstraction that apps can optionally use that provides a simpler programming model, that's fine, but trying to create the illusion of a simple addressing model on a NATted internet is certain to produce yet another set of very obscure failures which are difficult to diagnose and more difficult to fix. Having NATs in the network is certainly not my preferred solution, because it's *very* difficult to work out all of the cases so that things work well - and I don't have much faith in IETF's and vendors' ability to work out and implement those cases in sufficient detail. But having NATs with explicit visibility (and ideally control) by apps is much, much better than the traditional strategies of pretending that NATs don't break apps and/or trying to have the NATs act as ALGs for the apps. > Then a key supposed advantage of NAT66 (stateful or stateless) over solutions > that depend on host upgrades vanishes. > Do you agree? Any time you introduce NATs into the network you're going to break apps, and force those apps to try to cope. The solution doesn't necessarily require host upgrades so much as app upgrades for those apps that break, but host OS vendors will inevitably want to provide support for those apps. However the host upgrade doesn't have to be a prerequisite. In general, I agree that proposals that require simultaneous upgrades to both the host and the routing system are imposing too high a barrier. But if the two upgrades can be decoupled, I don't think that's too high a barrier. The necessary condition is that every upgrade (of a router or host or app) should not degrade existing operations, and also provide at least the potential for improved functionality. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
