ietf-smtp
[Top] [All Lists]

Re: (ngtrans) Re: ipv6-smtp-requirement comments?

2001-11-10 16:02:24

Dan,

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
reasons:

- 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
                                        IN AAAA 
YYYY:YYYY:YYYY:YYYY:YYYY:YYYY:YYYY:YYYY

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.

Keith