On Jan 23, 2009, at 5:53 PM, james woodyatt wrote:
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 would certainly prefer to reference (rather than duplicate) existing
work, if possible. Which existing or forthcoming RFCs describe this?
2) A Standards-Track (PS) RFC that describes an IPv6 Network
Address Translation mechanism that provides the Simple Security and
Address Independence benefits of IPv4 NAT, while minimizing the
problems caused by IPv4 NAT. This 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.
Agree with Tony Hain. IPv6 Network Address Translation (NAT66) MUST
NOT be confused with IPv6 Simple Security (the topic of another
draft in V6OPS, i.e. draft-ietf-v6ops-cpe-simple-security, which
*does* attempt to mirror the stateful filtering behavior of IPv4
NAT). Also, since NAT66 doesn't provide the security features of
IPv6 Simple Security, and there is no consensus that a need exists
for the Address Independence facility it attempts to provide, I
don't see why NAT66 should be standards-track.
There are certainly a number of people who do believe that there is a
requirement for address independence, similar to the address
independence provided by IPv4 NAT. I don't think we know yet whether
there is any consensus on this yet, because we haven't really asked
the question.
If we do reach consensus that address independence is an important
requirement for network administrators that drives a significant
amount of IPv4 NAT deployment, we will need to reach a separate
consensus about whether it makes sense to document a translation-based
mechanism (such as NAT66) to meet that need.
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."
I definitely agree that a NAT66 document should outline the problems
that it is likely to cause. If we go with my current NAT66 mechanism,
it will cause some, but not all, of the problems associated with IPv4
NAT.
BTW, I also think that a stateful firewall document should describe
the problems that it will cause, many of which are also familiar to
NAT users, such as one-way-reachability that breaks referrals, etc.
Margaret
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
