draft-ietf-ngtrans-ipv6-smtp-requirement-03.txt   draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt 
Internet Engineering Task Force Motonori Nakamura Internet Engineering Task Force Motonori Nakamura
INTERNET-DRAFT Kyoto University INTERNET-DRAFT Kyoto University
Expires: April 24, 2002 Jun-ichiro itojun Hagino Expires: May 8, 2002 Jun-ichiro itojun Hagino
IIJ Research Laboratory IIJ Research Laboratory
October 24, 2001 November 8, 2001
IPv6 SMTP operational requirements IPv6 SMTP operational requirements
draft-ietf-ngtrans-ipv6-smtp-requirement-03.txt draft-ietf-ngtrans-ipv6-smtp-requirement-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.'' or to cite them other than as ``work in progress.''
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
The internet-draft will expire in 6 months. The date of expiration will The internet-draft will expire in 6 months. The date of expiration will
be April 24, 2002. be May 8, 2002.
Abstract Abstract
The memo lists operational requirements for IPv6 SMTP, and IPv6-capable This document lists operational requirements for IPv6 SMTP and
MX DNS records. As we deploy IPv6 SMTP servers, it became apparent that IPv6-capable MX DNS records. As IPv6 SMTP servers are deployed, it has
we need certain configuration in IPv6-capable MX DNS record, for stable become apparent that certain configurations are necessary in
dual-stack (IPv4 and IPv6) SMTP operations. The document tries to IPv6-capable MX DNS records for stable dual-stack (IPv4 and IPv6) SMTP
clarify the problems we have in transition period between IPv4 SMTP and operation. This document clarifies the problems that exist in the
IPv6 SMTP, and operational requirements for stable IPv4/v6 SMTP transition period between IPv4 SMTP and IPv6 SMTP. It also defines
operation. operational requirements for stable IPv4/v6 SMTP operation.
The document does not try to define any new protocol. This document does not define any new protocol.
1. Summary of IPv4 MX operation 1. Summary of IPv4 MX operation
For reference purpose, the section outlines how mail message delivery is For reference purposes, this section outlines how email message delivery
performed in IPv4-only environment [Partridge, 1986] . is performed in an IPv4-only environment [Partridge, 1986] .
DRAFT IPv6 SMTP operational requirements October 2001 DRAFT IPv6 SMTP operational requirements November 2001
In IPv4 SMTP operation, we register MX records like below, for In IPv4 SMTP operation, the MX record "example.org." would be registered
"example.org." domain: as follows:
example.org. IN MX 1 mx1.example.org. example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org. IN MX 10 mx10.example.org.
mx1.example.org. IN A 1.0.0.1 mx1.example.org. IN A 192.0.2.1
mx10.example.org. IN A 1.0.0.2 mx10.example.org. IN A 192.0.2.2
When an MTA delivers a message to a particular destination (say it is to When an MTA wishes to deliver a message to a particular destination
foo@example.org), the MTA would send DNS queries to lookup DNS database (e.g. "foo@example.org"), the MTA sends DNS queries in the following
in the following order: order:
o Lookup MX record for "example.org.". o Lookup MX record for "example.org.".
o If an MX record is returned, try to lookup A record on the righthand o If an MX record is returned, lookup an A record for the right-hand
side of the MX record. side of the MX record.
o If a CNAME record is returned, try to chase the CNAME chain. o If a CNAME record is returned, try to chase the CNAME chain.
Eventually we will reach some A record. Eventually an A record will be reached.
NOTE: from RFC2181 MX records must not point CNAME records [Elz, NOTE: RFC2181 [Elz, 1997] prohibits MX records from pointing to
1997] . However, it has been permitted in older RFCs [Partridge, CNAME records. However, this was not prohibited in earlier RFCs.
1986] . We mention CNAME chasing logic here just for backward [Partridge, 1986] CNAME chasing logic is mentioned here just for
compatibility. Implementers may want to avoid CNAME chasing to be backwards compatibility. Implementers may want to avoid CNAME
more conformant to RFC2181. chasing to better conform with RFC2181.
o If MX lookup failed with NO_DATA, it means that there is no MX o If the MX lookup fails with NO_DATA, it means that there is no MX
record but there can be other record for "example.org.". Lookup A record, but there may be other records (e.g. "example.org.").
record for "example.org.". Lookup the A record for "example.org.".
o If MX lookup failed with HOST_NOT_FOUND, it means that there is no o If the MX lookup fails with HOST_NOT_FOUND, it means that there is
record at all for "example.org.". This means a delivery failure. no record at all for "example.org.". This results in a delivery
failure.
2. MX records and IPv6 SMTP operation 2. MX records and IPv6 SMTP operation
The following sections talk about how to make IPv4 SMTP and IPv6 SMTP The following sections explain how to make IPv4 SMTP and IPv6 SMTP
coexist, under dual-stack environment during the transition period coexist in a dual-stack environment during the transition period between
between IPv4 to IPv6. In the future, when we have completely migrated an IPv4-only environment and an IPv6-only environment. In the future,
to IPv6-only network, we can forget about IPv4/v6 SMTP interaction. when the migration to an IPv6-only network is complete, IPv4/v6 SMTP
interaction will be ignored.
As IPv6 DNS lookup RFCs [Thomson, 1995; Crawford, 2000] use IN class for Similar to the way RFC's for IPv6 DNS lookup [Thomson, 1995; Crawford,
both IPv4 and IPv6, we will use IN MX records for both IPv4 and IPv6. 2000] use IN class for both IPv4 and IPv6, IN MX records will be used
for both IPv4 and IPv6.
For simplicity, the document lists DNS records for IPv6 address as AAAA For simplicity, this document lists DNS records for IPv6 addresses as
records, not as A6 records [Crawford, 2000] . In reality, we can use a AAAA records, not as A6 records [Crawford, 2000] . In reality, a chain
chain of A6 records, instead of AAAA records. of A6 records can be used, instead of AAAA records.
There are couple of technologies defined for IPv4 and IPv6 transition. DRAFT IPv6 SMTP operational requirements November 2001
The document concentrates on issues with dual stack environment.
Translators do not need special consideration from SMTP point of view;
If we have SMTP traffic from IPv6 MTA to IPv4 MTA over an IPv6-to-IPv4
DRAFT IPv6 SMTP operational requirements October 2001 There are several technologies defined for the transition from IPv4 to
IPv6. This document concentrates on SMTP issues in a dual-stack
environment. Afterall, there are no special SMTP considerations for
translators; If there is SMTP traffic from an IPv6 MTA to an IPv4 MTA
over an IPv6-to-IPv4 translator, the IPv4 MTA will consider this normal
IPv4 SMTP traffic. Protocols like IDENT [StJohns, 1993] , however, may
require special consideration when translators are used.
translator, the traffic will be considered as a normal IPv4 SMTP This document does not discuss the problems encountered when the sending
traffic, from the IPv4 MTA point of view. We may, however, need some MTA and the receiving MTA have no common protocol (e.g. the sending MTA
consideration on translators for protocols like IDENT [StJohns, 1993] . is IPv4-only while the receiving MTA is IPv6-only). Such a situation
should be resolved by making either side dual-stack or by making either
side use a protocol translator.
3. SMTP sender algorithm in dual stack environment 3. SMTP sender algorithm in a dual-stack environment
When we lookup MX records for the domain in IPv4/v6 dual stack In a dual-stack environment MX records for a domain resemble the
environment, we will see records like below: following:
example.org. IN MX 1 mx1.example.org. example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org. IN MX 10 mx10.example.org.
mx1.example.org. IN A 1.0.0.1 ; IPv4/v6 dual stack mx1.example.org. IN A 192.0.2.1 ; dual-stack
IN AAAA 3ffe:501:ffff::1 IN AAAA 3ffe:501:ffff::1
mx10.example.org. IN AAAA 3ffe:501:ffff::2 ; IPv6 only mx10.example.org. IN AAAA 3ffe:501:ffff::2 ; IPv6 only
For single MX record, we have many possibility for the final lookup For a single MX record there are many possible final states, including:
result, including: (a) single, or multiple A records for IPv4 (a) one or more A records for the IPv4 destination, (b) one or more AAAA
destination, (b) single, or multiple AAAA records for IPv6 destination, records for the IPv6 destination, (c) a mixture of A and AAAA records.
(c) mixture of A and AAAA records. As we can define multiple MX records Because multiple MX records may be defined using different preference
with different preference value, we also need to go through multiple values, multiple addresses based on multiple MX's must be traversed.
addresses based on multiple MXes. We need to cope with domains without Domains without MX records and failure recovery cases must be handled
MX records, and failure recovery cases too. properly as well.
The algorithm for a SMTP sender would be like this. The algorithm for an SMTP sender is basically the same as that for an
IPv4-only sender, but it now includes AAAA lookups of MX records for
SMTP-over-IPv6 delivery. IPv4/v6 dual stack destinations should be
treated just like multihomed destinations as described in RFC2821
[Klensin, 2001] section 5. When there is no reachable destionation
address record found (for example, the sender MTA is IPv4 only and there
are no A records available) the case should be treated just like MX
records without address records.
(1) Lookup MX record for the destination domain. If a CNAME record is ; if the sender MTA is IPv4 only, email delivery to a.example.org
returned, go back to step (1) with the queried result. If MX ; should fail with the same error as deliveries to b.example.org.
records are returned, go to step (2) with the result. If NO_DATA a.example.org. IN MX 1 mx1.a.example.org.
is returned, go to step (3) as there is no MX record. If mx1.a.example.org. IN AAAA 3ffe:501:ffff::1 ; IPv6 only
HOST_NOT_FOUND is returned, there is no domain, raise permanent b.example.org. IN MX 1 mx1.b.example.org.
email delivery failure (finish). mx1.b.example.org. IN HINFO "NO ADDRESS RECORDS"
NOTE: regarding to MX records pointing CNAME records, see a note in DRAFT IPv6 SMTP operational requirements November 2001
the previous section.
(2) We have multiple MX records with us. Loop steps from (3) to (8), (1) Lookup the MX record for the destination domain. If a CNAME record
based on MX preference values, in ascending order. is returned, go to step (1) with the query's result. If any MX
records are returned, go to step (2) with the query's result. If
NO_DATA is returned, there is no MX record. Go to step (3). If
HOST_NOT_FOUND is returned, there is no domain. Raise a permanent
email delivery failure. Finish.
(3) If the source MTA has IPv4 capability, lookup A record. Keep the NOTE: the previous section contains a note about MX records that
resulting address till step (5). point to CNAME records.
(4) If the source MTA has IPv6 capability, lookup AAAA record. (2) There are multiple MX records. Sort the MX records in ascending
order based on their preference values, and loop over steps (3) to
(8).
(5) Reorder queried result based on implementation-dependent preference (3) If the sending MTA has IPv4 capability, lookup the A record. Keep
between A and AAAA records. If you would like to encourage the the resulting address until step (5).
transition from IPv4 SMTP to IPv6 SMTP, AAAAs should take
precedence.
(6) Loop steps from (7) to (8), for all the addresses (or part of the (4) If the sending MTA has IPv6 capability, lookup the AAAA record.
list of addresses) we have. If no reachable destination is found,
and if we are going through a list of MX records, go back to (3)
DRAFT IPv6 SMTP operational requirements October 2001 (5) If there is no A or AAAA record present, try the next MX record (go
to step (3)). Sort the query's result based on the
implementation's preference of A or AAAA records. If it is
desirable to encourage the transition from IPv4 SMTP to IPv6 SMTP,
AAAA records should take precedence.
and try the next MX record. If we do not have a list of MX (6) For each of the addresses or each part of the list of addresses,
records, or we have reached the end of the list of MX records, loop over steps (7) to (8). If no reachable destination is found,
raise temporary delivery failure (finish). and if a list of MX records is being traversed, try the next MX
record (go to step (3)). If there is no list of MX records, or if
the end of the list of MX records has been reached, raise a
temporary email delivery failure. Finish.
(7) Try to make a TCP connection to the destination. If it fails, try (7) Try to make a TCP connection to the destination. If unsuccessful,
the next address we have. If it succeeds, go to step (8). try the next available address. If successful, go to step (8).
(8) Try a SMTP protocol negotiation. If SMTP protocol negotiation (8) Try an SMTP protocol negotiation. If the SMTP protocol negotiation
fails with TEMPFAIL (4xx), go back to (3) and try the next MX fails with TEMPFAIL (4xx), try the next MX record (go to step (3)).
record. If it succeeds, SMTP delivery was successful (finish). If successful, SMTP delivery has succeeded. Finish.
4. MX configuration in receipient domain 4. MX configuration in the recipient domain
4.1. Ensuring reachability for both protocol versions 4.1. Ensuring reachability for both protocol versions
If a site has IPv4/v6 dual stack reachability, the site SHOULD configure If a site has dual-stack reachability, the site SHOULD configure both A
both A and AAAA records onto its MX hosts. It will help both IPv4 and and AAAA records for its MX hosts. This will help both IPv4 and IPv6
IPv6 senders to reach the site efficienlty. senders to reach the site efficiently.
4.2. Reachability between primary and secondary MX 4.2. Reachability between the primary and secondary MX
When we configure MX records onto DNS database in dual-stack When entering MX records in a DNS database in a dual-stack environment,
environment, we need to be careful about reachability between MX hosts. reachability between MX hosts must be considered carefully. Suppose all
Suppose we try to gather all inbound email to primary MX host,
mx1.example.org. DRAFT IPv6 SMTP operational requirements November 2001
inbound email is to be gathered at the primary MX host,
"mx1.example.org.":
example.org. IN MX 1 mx1.example.org. example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org. IN MX 10 mx10.example.org.
IN MX 100 mx100.example.org. IN MX 100 mx100.example.org.
If mx1.example.org is an IPv6 only node and the rest are IPv4 only node, If "mx1.example.org" is an IPv6-only node, and the others are IPv4-only
we have no reachability between primary MX host and the rest. Once an nodes, there is no reachability between the primary MX host and the
email reaches one of secondary MX host, the email will never reach the other MX hosts. When email reaches one of the secondary MX hosts, it
primary MX. cannot be relayed to the primary MX host.
; the configuration is troublesome. ; This configuration is troublesome.
; no secondary MX can reach mx1.example.org. ; No secondary MX can reach mx1.example.org.
example.org. IN MX 1 mx1.example.org. ; IPv6 only example.org. IN MX 1 mx1.example.org. ; IPv6 only
IN MX 10 mx10.example.org. ; IPv4 only IN MX 10 mx10.example.org. ; IPv4 only
IN MX 100 mx100.example.org. ; IPv4 only IN MX 100 mx100.example.org. ; IPv4 only
The easiest possible configuration is to configure the primary MX host The easiest possible configuration is to configure the primary MX host
as an IPv4/v6 dual stack node. By doing so, secondaries will have no as a dual-stack node. By doing so, secondary MX hosts will have no
problem reaching the primary MX host. problem reaching the primary MX host.
; the configuration works just fine. ; This configuration works well.
; emails reaches from secondary MX to primary with no trouble. ; The secondary MX hosts are able to relay email to the primary MX host
example.org. IN MX 1 mx1.example.org. ; IPv4/v6 dual stack ; without any problems.
example.org. IN MX 1 mx1.example.org. ; dual-stack
IN MX 10 mx10.example.org. ; IPv4 only IN MX 10 mx10.example.org. ; IPv4 only
IN MX 100 mx100.example.org. ; IPv6 only IN MX 100 mx100.example.org. ; IPv6 only
DRAFT IPv6 SMTP operational requirements October 2001 There are many other ways to ensure that the primary MX host and the
secondary MX hosts can reach one another. For example, it is possible
to configure the secondary MX hosts to route email statically, i.e.
without considering the DNS MX configuration. It is also possible to
establish an alternate email routing path (e.g. UUCP or an IPv4/v6
translator) between the secondary MX host and the primary MX host.
There are many other ways to ensure the reachability between secondary 5. Operational experience
MX and primary MX. For example, we could configure secondary MX to
route emails statically, without considering DNS MX configuration. Or
we could estalish alternative email routing path (i.e. UUCP, or via
IPv4/v6 translator) between secondary MX and the primary MX.
5. Operational experiences Many of the existing IPv6-ready MTA's appear to work in the way
documented in section 3.
Many of the existing IPv6-ready MTAs seem to work in the way documented >From past experiments and operational experience, it is known that most
in section 3. of the existing IPv4-only MTA's will not be confused by AAAA records
that are registered for MX hostnames. No experiments were conducted
with A6 records.
>From past experiments and operational experiences, it is known that most There were, however, cases where IPv6-ready MTA's were confused by
of the existing IPv4-only MTAs will not get confused by AAAA records, broken DNS servers. When attempting to canonify a hostname, some broken
registered for MX hostnames. No experiments were conducted with A6 name servers return SERVFAIL, a temporary failure, on AAAA record
records. lookups. Upon this temporary failure, the email is queued for a later
attempt. In the interest of IPv4/v6 interoperability, these broken DNS
There were, however, cases where IPv6-ready MTAs get confused by broken DRAFT IPv6 SMTP operational requirements November 2001
DNS servers. When attempting to canonify a hostname, some broken name
servers will return SERVFAIL (a temporary failure) on AAAA record servers should be fixed.
lookups. Upon this temporary failure, the mail is queued up for a later
attempt. These broken DNS servers should get fixed, for this issue as
well as for other IPv6 operations.
6. Open issues 6. Open issues
o How to interpret scoped address in email addresses, on MTAs. As we o How should scoped addresses in email addresses be interpreted on
relay emails between MTAs, interpretation of scoped address can be MTA's? As email is relayed between MTA's, interpretation of scoped
different between MTAs, as intermediate MTAs may be in different scope addresses can be different between MTA's. Afterall, intermediate
zone as the originator. If we get scoped IPv6 address as a result of MTA's may be in different scope zones than the originator. If a
DNS lookups, how MTAs should behave? scoped IPv6 address is returned as the result of a DNS lookup, how
should MTA's behave?
If we consider scoped address in ``route-addr'' specification If scoped addresses in ``route-addr'' specifications [Crocker, 1982]
[Crocker, 1982] like are considered, e.g.
<@kame.net,@[fec0::1]:itojun@itojun.org> <@kame.net,@[fec0::1]:itojun@itojun.org>
it gets more trickier. Luckily, route-addr form was obsoleted by it gets even trickier. Luckily, the route-addr form was obsoleted by
RFC2822 [Resnick, 2001] . RFC2822 [Resnick, 2001] .
7. Security consideration 7. Security considerations
As presented in ``Open issues'' section, it could be problematical if
route-addr email address format is used across multiple scope zones.
MTAs would need to reject emails with improper route-addr email address
formats. A possible example of improper route-addr format would be like
this: an email from outside of the site border, which carries numeric
site-local address in route-addr format.
DRAFT IPv6 SMTP operational requirements October 2001 As mentioned in the ``Open issues'' section, it could be problematic if
the route-addr email address format is used across multiple scope zones.
MTA's would need to reject email with improper route-addr email address
formats. One example of an improper route-addr format is an email from
outside the site border which carries a numeric site-local address in
the route-addr format.
References References
Partridge, 1986. Partridge, 1986.
C. Partridge, "Mail routing and the domain system" in RFC974 (January C. Partridge, "Mail routing and the domain system" in RFC974 (January
1986). ftp://ftp.isi.edu/in-notes/rfc974.txt. 1986). ftp://ftp.isi.edu/in-notes/rfc974.txt.
Elz, 1997. Elz, 1997.
R. Elz and R. Bush, "Clarifications to the DNS Specification" in RFC2181 R. Elz and R. Bush, "Clarifications to the DNS Specification" in RFC2181
(July 1997). ftp://ftp.isi.edu/in-notes/rfc2181.txt. (July 1997). ftp://ftp.isi.edu/in-notes/rfc2181.txt.
skipping to change at page 6, line 28 skipping to change at page 7, line 4
S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt. RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt.
Crawford, 2000. Crawford, 2000.
M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6 M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6
Address Aggregation and Renumbering" in RFC2874 (July 2000). Address Aggregation and Renumbering" in RFC2874 (July 2000).
ftp://ftp.isi.edu/in-notes/rfc2874.txt. ftp://ftp.isi.edu/in-notes/rfc2874.txt.
StJohns, 1993. StJohns, 1993.
M. StJohns, "Identification Protocol" in RFC1413 (January 1993). M. StJohns, "Identification Protocol" in RFC1413 (January 1993).
DRAFT IPv6 SMTP operational requirements November 2001
ftp://ftp.isi.edu/in-notes/rfc1413.txt. ftp://ftp.isi.edu/in-notes/rfc1413.txt.
Klensin, 2001.
J. Klensin, Editor, "Simple Mail Transfer Protocol" in RFC2821 (April
2001). ftp://ftp.isi.edu/in-notes/rfc2821.txt.
Crocker, 1982. Crocker, 1982.
D. Crocker, "Standard for the format of ARPA Internet text messages" in D. Crocker, "Standard for the format of ARPA Internet text messages" in
RFC822 (August 1982). ftp://ftp.isi.edu/in-notes/rfc822.txt. RFC822 (August 1982). ftp://ftp.isi.edu/in-notes/rfc822.txt.
Resnick, 2001. Resnick, 2001.
P. Resnick, editor, "Internet Message Format" in RFC2822 (April 2001). P. Resnick, editor, "Internet Message Format" in RFC2822 (April 2001).
ftp://ftp.isi.edu/in-notes/rfc2822.txt. ftp://ftp.isi.edu/in-notes/rfc2822.txt.
Change history Change history
00 -> 01 00 -> 01
Correct email address notation for source-routed emails, based on a Corrected the email address notation for source-routed emails,
comment from Gregory Neil Shapiro. based on a comment from Gregory Neil Shapiro.
01 -> 02 01 -> 02
Refer RFC2822, not 822. Use example.org, not sample.org. Based on Change a reference to refer to RFC2822, not 822. Used
comments from Arnt Gulbrandse. Add Operational experiences "example.org", not "sample.org". These changes were based on
section. Clarify MX-points-to-CNAME, based on comments from Mohsen comments from Arnt Gulbrandsen. Added an ``Operational
Souissi. experiences'' section. Clarified the case where an MX record
points to a CNAME record, based on comments from Mohsen Souissi.
02 -> 03 02 -> 03
Some cases, IPv6-ready MTAs gets troubled by wrong DNS server In some cases, IPv6-ready MTA's are troubled by incorrect DNS
responses for AAAA queries. From Gregory Neil Shapiro. server responses for AAAA queries. This change was based on
comments from Gregory Neil Shapiro.
DRAFT IPv6 SMTP operational requirements October 2001 03 -> 04
Grammar cleanups by JJ Behrens. More text on the delivery error
cases.
Acknowledgements Acknowledgements
The draft was written based on discussions with Japanese IPv6 users, and This draft was written based on discussions with Japanese IPv6 users and
help from WIDE research group. Here are a (probably incomplete) list of help from the WIDE research group. Here is a (probably incomplete) list
people contributed to the draft: Gregory Neil Shapiro, Arnt Gulbrandse, of people who contributed to the draft: Gregory Neil Shapiro, Arnt
and Mohsen Souissi. Gulbrandsen, Mohsen Souissi, and JJ Behrens.
Author's address Author's address
DRAFT IPv6 SMTP operational requirements November 2001
Motonori NAKAMURA Motonori NAKAMURA
Center for Information and Multimedia Studies, Kyoto University Center for Information and Multimedia Studies, Kyoto University
Yoshida-nihonmatsu-cho, Sakyo, Kyoto 606-8501, JAPAN Yoshida-nihonmatsu-cho, Sakyo, Kyoto 606-8501, JAPAN
Tel: +81-75-753-9063 Tel: +81-75-753-9063
Fax: +81-75-753-9056 Fax: +81-75-753-9056
Email: motonori@media.kyoto-u.ac.jp Email: motonori@media.kyoto-u.ac.jp
Jun-ichiro itojun HAGINO Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc. Research Laboratory, Internet Initiative Japan Inc.
Takebashi Yasuda Bldg., Takebashi Yasuda Bldg.,
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/