On Jan 20, 2009, at 19:21, Margaret Wasserman wrote:
Here is a preliminary BOF request that I've put together for a NAT66-
related BOF at IETF 74. I'm sending it to all four of the Internet
and Transport ADs, as I am not sure it has been decided which area
would be the best home for this work.
Thoughts or comments on this BOF proposal?
Skipping past the summary (tl;dr)...
1) A Best Current Practices (BCP) RFC describing how to obtain
the Simple Gateway and Simple Security features of NAT without
performing address translation. This document is intended for home
gateway manufacturers and other standards bodies that define home
gateway functionality.
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."
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.
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."
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
