On Oct 29, 2010, at 9:16 AM, Rémi Després wrote:
1.
- Some consider that some form of NAT66 is useful for some real
customer needs.
- Clear descriptions of which scenarios benefit from which type of
NAT66 are however still missing. (At this stage, this seems to only
be scenarios where baring all incoming connectivity is found
desirable, but more precisions are lacking.)
- If, once documented, such scenarios are convincing, documenting in
IETF NAT66 characteristics that fit them will make sense.
I do not consider this to be an accurate summary of arguments in favor
of publishing NAT66.
The NAT66 document clearly states a use case for NAT66 that does _not_
rely on blocking all incoming connections: address independence In
discussions on the nat66 list, enterprise administrators have
confirmed that this is a valid need, and that NAT66 would allow some
enterprises that are currently blocking on the need for NAT in IPv6 to
deploy IPv6 in their enterprises.
There _also_ seem to be use cases where enterprise administrators use
NAT specifically for the purpose of blocking (most or all?) incoming
connections. I do not know if we have explored that use cases well
enough to know if it could be served by a stateful firewall and/or a
combination of NAT66 and a stateful firewall. I think it would make
sense for the IETF to look into those use cases in more detail, as was
already done for CPE equipment.
2
- Some contributors advocate that "NAT66" should only designate
*stateless NAT66*.
You are the only person I have heard make that statement. If others
hold this opinion, they should share it with me.
- 6to4-PMT is a proposal to add stateless NAT66's to 6to4 relays
(without tool available for customers to know that their 6to4
addresses are now translated).
I am unfamiliar with this proposal, so I can't comment on it.
Margaret
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
