ietf
[Top] [All Lists]

Re: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC

2007-03-01 01:53:25
Sam,
I disagree with this characterization of the document.  I think it is
more like we have existing NAT mechanisms; we have strategies for
making them work.  Dual stack nodes is a better way forward than
creating a new NAT mechanism to move from IPV6 to IPV4 and trying to
make that (with a different set of problems than traditional NAT)
work.

I don't think this document is anti-NAT.  Can you help me understand
why I'm wrong or reconsider how much of your argument still applies?


While I agree that use of NAT-PT for transition is probably not the best way forward, the overall NAT question hangs in the air when we deprecate this document. With IPv4 the impetus for NAT was a combination of address exhaustion concerns and routing issues. In the case of IPv6 the issues are far more operational in nature, and depend very much on a combination of RIR policies regarding PI addressing (currently in vogue) and an end network's need for ease of administration through a renumbering event. We can only address *some* of those problems, and the ones that remain may well encourage NAT.

So, for those who hate NAT, please consider the problem of enterprise administrators who face this decision. For example, improved programmatic linkage between service providers and the end nodes for secure allocation of networks. While prefix delegation is defined in DHCP, the linkage back to DNS is shaky at best, since both forward and reverse zone updates are required. See RFC 4192 for more on this.

Barring satisfactory resolution, enterprises and vendors will take the path of least resistance (again).

Eliot

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>