On 20 nov 2007, at 3:53, Brian E Carpenter wrote:
Further, at the recent RIPE meeting in Amsterdam, there seemed
to be very broad operator feedback in the hallways that this NAT+PT
approach is the only viable transition strategy left available to
operators at this late date.
Please can you explain this in some detail, because to me it's
just words. What services do these operators believe will work
reliably through NAT-PT and how will they handle the residual problems
of NAT-PT (which are detailed in RFC 4966)?
Maybe this is a good opportunity to point to the latest revision of my
draft:
http://www.ietf.org/internet-drafts/draft-van-beijnum-modified-nat-pt-02.txt
The two main parts are ditching the DNS ALG, IPv6 hosts must do
regular A record lookups and create a to-be-translated IPv6 address
from that themselves and a way for IPv6-only hosts to receive incoming
sessions from the IPv4-only world. There's also a way to do IPv4-IPv6-
IPv4 translation with only a single layer of IPv4 NAT.
There's no doubt that NAT-PT will work in well-defined scenarios for
which any necessary ALGs are in place. The concern is about how it
works in the general case or for unknown future applications.
I don't think we need to solve the unknown future applications case.
If something like 95% of the users have the same experience behind
(some kind of) NAT-PT as they would with their current typical setup
(which would probably be IPv4 NAT) that's good enough. NAT-PT comes
with full IPv6 so the other 5% can be done over IPv6. And if that
doesn't work, those users could get real IPv4 connectivity through
softwires or regular IPv4.
What we do need to solve are things in NAT-PT that negatively impact
IPv6 in general.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf