[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
Hello,
in Asia there seem to be emerging _large_ IPv6 only networks that may
need some connectivity to the IPv4 Internet. Example of these is for
instance is CNGI. They have been extensively looking for a NAT-PT type
solution and are considering to use NAT-PT. I think we should have some
sort of proposal what to do if we decide that NAT-PT is not the way to
go.
I wish the people that are involved in these projects would speak up and
explain their requirements.
Cheers,
Jonne.
On Fri, 2004-10-15 at 16:46, ext Tim Chown wrote:
> Soohong Daniel Park wrote:
> >
> > Nevertheless, I know several sites are using NAT-PT efficiently on
> > their use cases.
>
> It would be interesting, with the enterprise analysis in mind, to know
> why these sites used NAT-PT, and what they could not solve in other ways.
>
> We used to run NAT-PT, but no longer do.
>
> As Pekka points out, we should also consider how IPv4 and IPv6 will be
> adopted. IPv4 may remain the protocol to access legacy apps (like web,
> mail, ftp). But these are also the ones that lend themselves to natural
> proxying (and sure FTP proxies are rare, but so are NAT-PT boxes :).
> IPv6 may become more popular for specific new applications, which do not
> require access to IPv4 services, as Pekka is hinting.
>
> Suresh wrote:
> > As Senthil points out, the assumption that NAT-PT deployment will stifle
> > innovation in v6 seems flawed. NAT-PT is a transition mechanism which is
> > essential for wider V6 deployment. Without NAT-PT, you will see bigger
> > resistance to deploying V6 . You need NAT-PT for legacy applications (ex:
> > e-mail, ftp) to work as is across V4 and V6 realms. No change to end-hosts or
> > applications. This is the attraction of NAT-PT. This is not the same as the
> > proxy solution that will require applications to be changed/recompiled.
>
> Proxies can be deployed transparently. SMTP naturally so, Web caches also,
> there doesn't necessarily have to be any client side alterations.
>
> Tim
--
Jonne Soininen
Nokia
Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com