Tony Hain wrote: > Cullen Jennings wrote: >> I'm sure that the IAB and IESG is keenly interested in this topic but >> everyone that cares is subscribed to behave. > > While I agree that everyone interested in defining nat behavior is > subscribed to Behave, I doubt that everyone in the application community is, > yet every one of them will be impacted by the fundamental architectural > implications of this backroom rush to market effort. There has been no > justification of the need for a 66nat, only wild claims that we need to do > something now because people will be shipping them in the next few months. > While I have no doubt that vendors will ship what their customers are asking > for, it is not clear that the IETF should endorse an effort with such a wide > ranging architectural impact. Never mind that if the vendors are really > shipping in the next few months there is no chance that an IETF document > would be published before there are products on the street.... > > Hosting this discussion in Behave assumes the outcome, and is absolutely the > wrong place for an architectural discussion. This should be held in the > Applications area, and only moved to Behave to resolve the implementation > details once it is decided that a 66nat is absolutely necessary. Trying to > do it by having people pre-disposed to an answer and without any concern for > the impact to the application community is guaranteed to result in > perpetuating an unnecessary architectural wart. Mumble. As usual in IETF when we are talking about issues that have a profound effect on the architecture, the discussion is fragmented. - The greatest concentration of NAT experts in the IETF are probably in the BEHAVE group. They do have a NAT-centered view of the problem/solution space. But don't discount them entirely, as many of the participants in that group have a deeper grasp of the implications of NAT (at least when viewed from that angle) than the average IETF participant. - Some of the pressure to have NATs (other than for IPv6 transition) seems to be coming from routing area people who can't figure out how to make the core routing scale, so they want to push part of the problem to the edges. So clearly we need input from routing people. (I'm not saying it's an inherently unreasonable approach, though sometimes I do wonder if it smacks of "let's make this somebody else's problem so we don't have to deal with it". And BTW, no area has a monopoly on this kind of wishful thinking.) - Other pressures to have NATs are from network operators who see it (and not entirely without justification, though in some cases it's marginal) as something that helps their security and/or decreases their management effort in the face of (a) renumbering and/or (b) reducing granularity of access control. So we need input from operations people also, though it's not clear (to me anyway) how well those people are represented in IETF. - And of course we also need input from applications people. But historically most IETF standard applications protocols have not been peer-to-peer or distributed apps. So IETF applications area people (in general) may actually not be adequately sensitive to the needs of apps outside of the two-party (i.e. client-server) space. This implies that moving this discussion to an apps area group would not automatically bring with it a lot of clue about how NATs affect apps. But we certainly need input from people with distributed / p2p apps expertise. -- I haven't followed IETF as closely for the past few years as I did for the decade or so before that. But in the past it used to be the case that ADs would deliberately narrow the scope of some of these discussions to avoid endless ratholes in discussion between people who could never learn to speak the same language, or respect one another's experience or needs. I don't know if that tactic is still being used, but my impression from some distance is that IETF is even more fragmented about architectural issues (particularly use of NATs) than it used to be - though today it seems that a bit more of the NAT discussion is coalescing in BEHAVE than it was, say, a year ago. And having the discussion in a single WG is IMO far better than having a half-dozen different groups all trying to solve more-or-less the same problem, from narrow points-of-view, in relative isolation from one another. I guess what I'm concluding is this: Yes, we need to have input from all of these different kinds of people. Yes, the BEHAVE group has a NAT-centric view. But unless we can find some way to get a more diverse set of interests into the same (virtual) room AND get them to actually speak the same language and respect one another's views, moving the discussion elsewhere isn't going to help convergence of any kind of solution - with or without NAT. But IF the discussion is going to happen there, what I'd really like is for the BEHAVE group to stop trying to enumerate and define in detail every possible solution to the NAT problem -- and instead focus on developing a single, common framework that would let NATs provide the functionality and visibility that both applications and operators need. If they were to take that approach, I think they could do a decent job at defining the "Optimal" NAT and also enumerating its warts. And then the rest of us could look at it and see how bad (or tolerable) it really is. And the routing people could look at it and see if it's really possible to use NATs to handle multihoming to stub networks, without painting the internet architecture into an undesirable corner. (Because at present the "we need NATs for routing" argument looks, to my intuition, a bit like handwaving. And I am not convinced that the proponents of using NATs to simplify the routing problem really understand the implications of doing that, either for the applications or for the internet architecture in general. But I do think that it's worth exploring that, and that the proponents of this approach need to be able to make the best case they can for it. And in order to do that they really need a definition of "optimal NAT" to work with.) Keith _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf