IPv4-only hosts cannot communicate directly with IPv6-only hosts.
This should be obvious to anyone who has read the specifications:
the packet formats are completely different . An IPv4-only host
will not understand IPv6 packets without a software upgrade, and
even if an IPv6-only host had a means of sending packets to IPv4
hosts, an IPv4-only host would not be able to reply to them.
Depending on the application, translation between IPv4 and IPv6
may be possible at either the IP level (by translating individual
packets in a manner similar to NAT-PT) or at the application level
(as in a SMTP MTA on a host with both IPv4 and IPv6 connectivity,
a simple TCP-to-TCP gateway that speaks IPv4 on one side and IPv6
on the other, or a simple SMTP-aware shim similar to that provided
by some firewalls). Any of these works for SMTP. But for for the
same reasons that some protocols do not work in the presence of NAT,
a completely general translation between IPv4 and IPv6 - one that
works for all applications - is impossible.
For SMTP operation, the method by which translation is done is
generally irrelevant - either a packet translator box or a
TCP translator or a dual-stack firewall or a dual-stack MTA will
work just fine. The only caveats I have identified so far are these:
1. if packets are received via a translator, received headers
will show an incorrect source address.
2. if there are two addresses for an SMTP server - one which is
routed via NAT-PT and another which goes directly to the server,
those two addresses should be listed as alternate addresses for
the same domain, rather than as separate domains, for the following
- if a dual-stack relaying MTA is trying to send to that server
and it responds with a "temporary failure" error, the relaying
MTA should not immediately attempt to retry to the same host,
but it might reasonably try to relay the message to a different
mail exchanger. if the relaying MTA sees multiple addresses
for the same MX domain it will know to fail over to another
mail exchanger, but if it sees separate domains in separate
MX records it may well fail over to the same host.
- similarly, if the relaying MTA is using STARTTLS and authenticating
the SMTP server, the domain that appears in the server certificate
should match the domain under which that MTA appears in the MX record.
if the NAT-PT address and the actual address are listed under separate
domains, this will fail for one case or the other.
However, if the same host that is used for an SMTP server is also
used to serve applications that are incompatible with NAT-PT, it
would cause problems for such applications for both the IPv4 and IPv6
addresses to be listed under the same domain, if that domain was used
by those applications. for this reason it may be necessary to list
the same host under multiple domains. for instance:
multi-purpose-server.example.com IN A xxx.xxx.xxx.xxx
mail-server.example.com IN A xxx.xxx.xxx.xxx
example.com IN MX 10 mail-server.example.com.
in this example, multi-purpose-server and mail-server are the same
host. a translator has been set up which will translate between IPv4
and IPv6 packets for traffic forwarded to and from the IPv4 address
of this host. incoming mail will get routed to mail-server.example.com
either directly or via the packet translator, which is fine since
SMTP (modulo received headers) doesn't have any problems with address
translators. however other applications that do not work in the
presence of packet translators will need to use the
multi-purpose-server.example.com domain name.
Apparently there is some dispute about the RFC 2893 transition plan. Are
IPv4 addresses going to be able to talk to IPv6 addresses, or is every
existing Internet site going to have to acquire IPv6 addresses?
Neither. IPv4-to-IPv6 packet level translation will be used in some cases
but it requires someone to set up a translator, and is not a general
solution that works for all applications. Nor does anybody who has
thought much about the problem believe that "every existing Internet site"
will acquire IPv6 support - at least, not very soon. (however 6to4 makes
this fairly easy for any host that already has a global IPv4 address -
an OS upgrade is all that is needed - so IPv6 is easier to deploy than
many seem to think).
My view is that there will be a long period of coexistence, and the
choice of (probably NATted) IPv4 or (non NATted) IPv6 will often
depend on the particular application being used.