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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf