On Feb 4, 2009, at 6:08 AM, Jari Arkko wrote:
James,
Recommend rewriting this section as follows: "1) A Best Current
Practices (BCP) RFC, which is to be intended for residential
gateway manufacturers and other standards bodies that define
functional requirements of residential gateways, that describes why
NAT66 is neither necessary nor advised, and also references
existing and forthcoming RFCs that describe how residential IPv6
gateways with simple security should function."
I didn't like the original wording too much, but perhaps you are
taking it to the other extreme. In any case, *if* we create a WG for
NAT66, I would very much like to see a document that explains what
people should be using for various purposes. When it comes to
replicating NAT44's connections-can-only-be-opened-to-outside, it is
clear to me at least that firewall functionality is the way to
provide that feature. (But I also happen to believe that NAT66 would
be useful to document for other reasons.)
I agree. One of the goals of this effort, IMO, should be to avoid
conflating NAT and stateful firewall functionality. A firewall is
much more manageable/configurable than a N:1 or port translating NAT.
So, I am hopeful that we can explain this well, make it clear how one
would provide a stateful firewall with this benefit and also define a
1:1 algorithmic, non-port-mapping NAT algorithm that can be used when
translation is actually _wanted_, not as a poor man's substitute for a
firewall.
Recommend rewriting this section as follows: "2) An Experimental
(EXP) RFC that describes an IPv6 Network Address Translation
mechanism that provides some address independence at the expense of
some of the familiar problems caused by NAT with IPv4. This
experimental solution is expected to involve a one-to-one,
algorithmic address mapping mechanism with no port mapping. It may
or may not include a checksum-neutral mapping algorithm and/or a
cryptographic mapping mechanism."
s/some/some but not all/ and I'd be happy with this.
Why experimental? I am not going to object if that is what the group
wants to do, but my understanding was that experimental RFCs were
supposed to define an experiment, and I don't think we would need to
run an experiment to understand this technology, as it is already
widely deployed in IPv4.
Margaret
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
