I am in agreement with Keith here, I don't think the names are helpful.
What I want is a network protocol transition box, the ANYBOX which:
1) Bridges a local network A to the Internet B
2) Can accept either IPv4 or IPv6 on either side of the box
3) Provides seamless Internet connectivity for the principle legacy Internet
applications (SMTP, HTTP, FTP, NNTP) regardless of whether IPv4 or IPv6 is
running on either side of the box
4) Provides seamless Internet connectivity for all applications written to a
set of clear and concise architectural / discovery requirements regardless of
whether IPv4 or IPv6 is running on either side of the box.
5) Addresses some major user requirement so as to give users an incentive to
buy it (no IPv6 connectivity is not in itself a user requirement, it is a
means, not an end)
I know that we are going to have to engage in some form of fixup to gate IPv4
to IPv6, the question is how much and where we put the fixup technology.
I want to concentrate that fixup technology at the network gateway.
________________________________
From: Keith Moore [mailto:moore(_at_)cs(_dot_)utk(_dot_)edu]
Sent: Wed 14/11/2007 3:45 PM
To: Rémi Després
Cc: RJ Atkinson; ietf(_at_)ietf(_dot_)org
Subject: Re: terminology proposal: NAT+PT (or NAT64 ?)
Alain Durand proposed in 2002 :
- NAT64 for IPv6 -> IPv4
- NAT46 for IPv4 -> IPv6
Practically speaking, any box that translates between v4 and v6 has to
be able to translate in both directions. Which side is "to" and which
is "from" then? You don't want to make the assumption that the apps are
all client-server.
I agree that there are differences in the best way to provide
connectivity to the public IPv4 network from a private IPv4 or isolated
IPv6 network, and the best way to provide connectivity to the public
IPv6 network from an IPv4 network. But I don't see these as inherently
different problems requiring a different box or a different protocol.
I think it makes more sense for there to be a common protocol which can
run over either IPv4 or IPv6 and which supports multiple services.
Also I don't think NAT64 or NAT46 are good names because there are
several different ways of providing the connectivity in each direction,
with advantages and disadvantages to each.
IMHO it would be better to talk in terms of specific proposals than to
debate about names.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf