Dave Crocker <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
