Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
Basically, the current task is one of supporting a dual-stack
networking environment.
I would _like_ to talk about that.
That's a challenge for all Internet use, not just email.
Agreed.
Solutions for it need to be universal, not specific to email.
Alas, the "universal" solutions I've seen don't seem to be adequate.
(Off-topic opportunity: I'm observing some work intended to make
TCP itself address-agile, even to the extent of continuing a TCP
session started within IPv4 over IPv6, and vice-versa.)
The SMTP specification should be modified in the smallest and most
localized fashion possible
Minimizing the change _does_ tend to ease implementation...
and particularly should not make any changes to its registration model.
That really doesn't follow.
In particular, there are a number of possible gateway-like options
for communication between an IPv4-only host and an IPv6-only host.
It might be _very_ helpful to register preferences on which to use.
The current 2821bis discusses this issue in Section 5.1:
]
] When a domain name associated with an MX RR is looked up and the
] associated data field obtained, the data field of that response MUST
] contain a domain-name. That domain-name, when queried, MUST return
] at least one address record (e.g., A or AAAA RR) that gives the IP
] address of the SMTP server to which the message should be directed.
]...
] When the lookup succeeds, the mapping can result in a list of
] alternative delivery addresses rather than a single address, because
] of multiple MX records, multihoming, or both. To provide reliable
] mail transmission, the SMTP client MUST be able to try (and retry)
] each of the relevant addresses in this list in order, until a
] delivery attempt succeeds. However, there MAY also be a configurable
] limit on the number of alternate addresses that can be tried. In any
] case, the SMTP client SHOULD try at least two addresses.
I'm guessing that this indicates that an IPv4-only host may
"try" an IPv6 address by failing to open an IPv6 socket.
I find it unfortunate that there's no mention of continuing the
search in hopes of finding an IPv4 address...
] Two types of information are used to rank the host addresses:
] multiple MX records, and multihomed hosts.
]
] MX records contain a preference indication that MUST be used in
] sorting if more than one such record appears (see below). Lower
] numbers are more preferred than higher ones. If there are multiple
] destinations with the same preference and there is no clear reason to
] favor one (e.g., by recognition of an easily-reached address), then
] the sender-SMTP MUST randomize them to spread the load across
] multiple mail exchangers for a specific organization.
This seems to _prohibit_ preferring the address family the host
prefers.
] The destination host (perhaps taken from the preferred MX record) may
] be multihomed, in which case the domain name resolver will return a
] list of alternative IP addresses. It is the responsibility of the
] domain name resolver interface to have ordered this list by
] decreasing preference if necessary, and the SMTP sender MUST try them
] in the order presented.
]
] Although the capability to try multiple alternative addresses is
] required, specific installations may want to limit or disable the use
] of alternative addresses. The question of whether a sender should
] attempt retries using the different addresses of a multihomed host
] has been controversial. The main argument for using the multiple
] addresses is that it maximizes the probability of timely delivery,
] and indeed sometimes the probability of any delivery; the counter-
] argument is that it may result in unnecessary resource use. Note
] that resource use is also strongly determined by the sending strategy
] discussed in Section 4.5.4.1.
If I move on to Section 5.2, however, there's contradictory
language:
]
] In the contemporary Internet, SMTP clients and servers may be hosted
] on IPv4 systems, IPv6 systems, or dual-stack systems that are
] compatible with either version of the Internet Protocol. The host
] domains to which MX records point may, consequently, contain "A RR"s
] (IPv4), "AAAA RR"s (IPv6), or any combination of them. While RFC
] 3974 [11] discusses some operational experience in mixed
] environments, it was not comprehensive enough to justify
] standardization and some of its recommendations appear to be
] inconsistent with this specification. The appropriate actions to be
] taken will either depend on local circumstances, such as performance
] of the relevant networks and any conversions that might be necessary,
] or will be obvious (e.g., an IPv6-only client need not attempt to
] look up A RRs or attempt to reach IPv4-only servers).
(I would like to believe that such a major shift would have gotten
at least a "but see Section 5.2" note back in Section 5.1.)
This text worries me! It would seem to permit IPv6 clients to make
no actual attempt to deliver email to IPv4-only domains, not even by
use of a gateway.
] Designers of
] SMTP implementations that might run in IPv6 or dual stack
] environments should study the procedures above, especially the
] comments about multihomed hosts, and, preferably, provide mechanisms
] to facilitate operational tuning and mail interoperability between
] IPv4 and IPv6 systems while considering local circumstances.
Does this text help? I can't tell... :^(
--
John Leslie <john(_at_)jlc(_dot_)net>