> ...
> I've argued strongly against NAT, but he's one of those people who seem
> to be willing to accept arbitrary amounts of pain ("we don't need to
> use [protocols that put IP addresses in payload]",
how about DNS? two of the extra years that got tacked onto the decade
of DNSSEC were due specifically to "middleboxes" who intercept/regenerate
DNS transactions. this has also slowed the deployment of EDNS. anyone
who deploys NAT is freezing their DNS protocol competence at "today's"
level, which is not only bad for the people behind that particular NAT
but will be bad for the standards people who are trying to evolve the DNS.
(or did folks generally just not know that DNS includes IP addresses in
its payload, and that a successful NAT box has to intercept/regenerate DNS,
and that NAT boxes who don't understand EDNS just cause timeouts due to
improper end-to-end signalling of feature levels, and that this regeneration
activity has been absolutely fatal to several proposed DNSSEC designs?)
> ... I'm now pointing him at some relevant RFCs. My question for the
> list is is there a web page or other document anywhere that
> comprehensively states the case against NAT?
eliot's answer to this part was so good that it bears repeating:
"This organization makes its opinions known through not only
standards but RFCs that have been reviewed by IETF working groups,
the community, and the IESG. RFC 2663 is the one you want. See in
particular scaling issues, multihoming, DNS, and IPsec, just to
name a few."
my own summary of the issues is that the internet's architecture has a
number of constraints and that if we want to continue to "scale the design"
we all have to operate within those constraints. operating outside of the
generally accepted constraints, or adding new constraints that aren't
generally accepted (or even generally known) makes evolution just stop.
(this issue came up during the verisign sitefinder debates, and i'd like
to thank klensin and bellovin for clarifying my thoughts on this topic.)
--
Paul Vixie