Network Working Group                                        M. Nakamura
Request for Comments: 3974                              Kyoto University
Category: Informational                                        J. Hagino
                                                 IIJ Research Laboratory
                                                            January 2005
Network Working Group                                        M. Nakamura
Request for Comments: 3974                              Kyoto University
Category: Informational                                        J. Hagino
                                                 IIJ Research Laboratory
                                                            January 2005

SMTP Operational Experience in Mixed IPv4/v6 Environments


Status of This Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Copyright Notice


Copyright (C) The Internet Society (2005).


IESG Note:


The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment.


This document contains a specific interpretation of the applicability of the MX processing algorithm in RFC 2821, Section 5, to dual-stack environments. Implementors are cautioned that they must reference RFC 2821 for the full algorithm; this document is not to be considered a full restatement of RFC 2821, and, in case of ambiguity, RFC 2821 is authoritative.

本文件包含RFC 2821第5节中MX处理算法适用于双堆栈环境的具体解释。提醒实施者,他们必须参考RFC 2821了解完整的算法;在RF2821的情况下,本文件被视为不完整的RF2821。



This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation.

本文档讨论IPv4/v6双堆栈环境中的SMTP操作经验。随着支持IPv6的SMTP服务器的部署,显然MX记录的某些配置对于稳定的双堆栈(IPv4和IPv6)SMTP操作是必要的。本文档澄清了IPv4 SMTP和IPv6 SMTP之间过渡期间存在的问题。它还定义了稳定的IPv4/v6 SMTP操作的操作要求。

This document does not define any new protocol.


1. Introduction
1. 介绍

Delivery of mail messages to the final mail drop is not always done by direct IP communication between the submitter and final receiver, and there may be some intermediate hosts that relay the messages. So it is difficult to know at message submission (also at receiver side) that all intermediate relay hosts are properly configured. It is not easy to configure all systems consistently since the DNS configuration used by mail message delivery systems is more complex than other Internet services. During the transition period from IPv4 to IPv6, more care should be applied to IPv4/v6 interoperability.


This document talks about SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation.


This document does not discuss the problems encountered when the sending MTA and the receiving MTA have no common protocol (e.g., the sending MTA is IPv4-only while the receiving MTA is IPv6-only). Such a situation can be resolved by making either side dual-stack or by making either side use a protocol translator (see Appendix A on issues with protocol translator).


2. Basic DNS Resource Record Definitions for Mail Routing
2. 邮件路由的基本DNS资源记录定义

Mail messages on the Internet are typically delivered based on the Domain Name System [Mockapetris]. MX RRs are looked up in DNS to retrieve the names of hosts running MTAs associated with the domain part of the mail address. DNS lookup uses IN class for both IPv4 and IPv6, and similarly IN MX records will be used for mail routing for both IPv4 and IPv6. Hosts which have IPv6 connectivity and also want to have the mails delivered using IPv6 must define IPv6 addresses for the host name as well as IPv4 addresses [Thomson].

互联网上的邮件通常基于域名系统[Mockapetris]进行传递。在DNS中查找MX RRs,以检索运行与邮件地址的域部分关联的MTA的主机的名称。DNS查找在类中用于IPv4和IPv6,类似地,在MX中,记录将用于IPv4和IPv6的邮件路由。具有IPv6连接并希望使用IPv6发送邮件的主机必须为主机名以及IPv4地址定义IPv6地址[Thomson]。

An MX RR has two parameters, a preference value and the name of destination host. The name of the destination host will be used to look up an IP address to initiate an SMTP connection [Partridge].

MX RR有两个参数,一个首选项值和目标主机的名称。目标主机的名称将用于查找IP地址以启动SMTP连接[Partridge]。

For example, an IPv6-only site may have the following DNS definitions:

例如,仅限IPv6的站点可能具有以下DNS定义:            IN MX   1
                              IN MX   10        IN AAAA 2001:db8:ffff::1       IN AAAA 2001:db8:ffff::2
                 IN MX   1
                              IN MX   10        IN AAAA 2001:db8:ffff::1       IN AAAA 2001:db8:ffff::2

In the transition period from IPv4 to IPv6, there are many IPv4-only sites, and such sites will not have mail interoperability with IPv6- only sites. For the transition period, all mail domains should have MX records such that MX targets with IPv4 and IPv6 addresses exist, e.g.,

在从IPv4到IPv6的过渡期间,有许多只使用IPv4的站点,这些站点将无法与只使用IPv6的站点进行邮件互操作。对于过渡期,所有邮件域都应具有MX记录,以便存在具有IPv4和IPv6地址的MX目标,例如。,            IN MX   1
                              IN MX   10        IN AAAA 2001:db8:ffff::1
                              IN A       IN AAAA 2001:db8:ffff::2
                              IN A
                 IN MX   1
                              IN MX   10        IN AAAA 2001:db8:ffff::1
                              IN A       IN AAAA 2001:db8:ffff::2
                              IN A

But, not every MX target may support dual-stack operation. Some host entries may have only A RRs or AAAA RRs:

但是,并非每个MX目标都支持双堆栈操作。某些主机条目可能只有RRs或AAAA RRs: IN MX 1 IN MX 10 IN AAAA 2001:db8:ffff::1 IN A。在MX 1 mx1.example.org中。在MX 10 mx10.example.org中。。在AAAA 2001:db8:ffff::1 mx10.example.org中。在192.0.2.1中

The following sections discuss how the sender side should operate with IPv4/v6 combined RRs (section 3), and how the receiver should define RRs to maintain interoperability between IPv4 and IPv6 networks (section 4).


3. SMTP Sender Algorithm in a Dual-Stack Environment
3. 双栈环境下的SMTP发送方算法

In a dual-stack environment, MX records for a domain resemble the following:

在双堆栈环境中,域的MX记录类似于以下内容:            IN MX   1
                              IN MX   10        IN A        ; dual-stack
                              IN AAAA 2001:db8:ffff::1       IN AAAA 2001:db8:ffff::2 ; IPv6-only
                 IN MX   1
                              IN MX   10        IN A        ; dual-stack
                              IN AAAA 2001:db8:ffff::1       IN AAAA 2001:db8:ffff::2 ; IPv6-only

For a single MX record, there are multiple possible final states, including: (a) one or more A records for the IPv4 destination, (b) one or more AAAA records for the IPv6 destination, (c) a mixture of A


and AAAA records. Because multiple MX records may be defined using different preference values, multiple addresses must be traversed based on multiple MXs. Domains without MX records and failure recovery cases must be handled properly as well.


The algorithm for a dual-stack 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 RFC 2821 [Klensin], section 5. When there is no destination address record found (i.e., 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, and deliveries should fail.

双栈SMTP发送方的算法基本上与仅IPv4发送方的算法相同,但它现在包括针对SMTP-over-IPv6传递的MX记录的AAAA查找。IPv4/v6双栈目的地应与多宿目的地一样对待,如RFC 2821[Klensin]第5节所述。如果没有找到目标地址记录(即,发件人MTA仅为IPv4,没有可用的A记录),则应将该情况视为没有地址记录的MX记录,并且传递应失败。

      ; if the sender MTA is IPv4-only, email delivery to
      ; should fail with the same error as deliveries to          IN MX   1      IN AAAA 2001:db8:ffff::1 ; IPv6-only          IN MX   1 ; no address
      ; if the sender MTA is IPv4-only, email delivery to
      ; should fail with the same error as deliveries to          IN MX   1      IN AAAA 2001:db8:ffff::1 ; IPv6-only          IN MX   1 ; no address

An algorithm for a dual-stack SMTP sender is as follows:


(1) Lookup the MX record for the destination domain. If a CNAME record is returned, go to the top of step (1) with replacing the destination domain by the query's result. If any MX records are returned, go to step (2) with the query's result (explicit MX). If NODATA (i.e., empty answer with NOERROR(0) RCODE) is returned, there is no MX record but the name is valid. Assume that there is a record like "name. IN MX 0 name." (implicit MX) and go to step (3). If HOST_NOT_FOUND (i.e., empty answer with NXDOMAIN(3) RCODE) is returned, there is no such domain. Raise a permanent email delivery failure. Finish. If SERVFAIL is returned, retry after a certain period of time.

(1) 查找目标域的MX记录。如果返回CNAME记录,请转到步骤(1)顶部,用查询结果替换目标域。如果返回了任何MX记录,请转到步骤(2)并显示查询结果(显式MX)。如果返回NODATA(即带有NOERROR(0)RCODE的空应答),则没有MX记录,但名称有效。假设存在类似“name.IN MX 0 name.”(隐式MX)的记录,并转至步骤(3)。如果未找到主机(即,返回带有NXDOMAIN(3)RCODE的空答案),则不存在此类域。引发永久性电子邮件传递失败。完成如果返回SERVFAIL,请在一段时间后重试。

(2) Compare each host name in MX records with the names of the sending host. If there is match, drop MX records which have an equal or larger value than the lowest-preference matching MX record (including itself). If multiple MX records remain, sort the MX records in ascending order based on their preference values. Loop over steps (3) to (9) on each host name in MX records in a sequence. If no MX records remain, the sending host must be the primary MX host. Other routing rules should be applied. Finish.

(2) 将MX记录中的每个主机名与发送主机的名称进行比较。如果存在匹配项,则删除值等于或大于最低首选项匹配MX记录(包括其本身)的MX记录。如果仍有多条MX记录,请根据其首选项值按升序对MX记录进行排序。按顺序在MX记录中的每个主机名上循环步骤(3)到(9)。如果没有MX记录保留,则发送主机必须是主MX主机。应应用其他路由规则。完成

(3) If the sending MTA has IPv4 capability, lookup the A records. Keep the resulting addresses until step (5).

(3) 如果发送MTA具有IPv4功能,请查找A记录。将结果地址保留到步骤(5)。

(4) If the sending MTA has IPv6 capability, lookup the AAAA records.

(4) 如果发送MTA具有IPv6功能,请查找AAAA记录。

NOTE: IPv6 addresses for hosts defined by MX records may be informed in an additional information section of the DNS queries' result as well as IPv4 addresses. If there is no additional address information for the MX hosts, separate queries for A or AAAA records should be sent. There is no way to query A and AAAA records at once in current DNS implementation.


(5) If there is no A and no AAAA record present, try the next MX record (go to step (3)). Note that the next MX record could have the same preference.

(5) 如果没有A和AAAA记录,请尝试下一条MX记录(转至步骤(3))。请注意,下一个MX记录可能具有相同的首选项。

NOTE: If one or more address records are found, an implementation may sort addresses based on the implementation's preference of A or AAAA records. To encourage the transition from IPv4 SMTP to IPv6 SMTP, AAAA records should take precedence. The sorting may only reorder addresses from MX records of the same preference. RFC 2821 section 5 paragraph 4 suggests randomization of destination addresses. Randomization should only happen among A records, and among AAAA records (do not mix A and AAAA records).

注意:如果找到一个或多个地址记录,则实现可以根据实现对A或AAAA记录的首选项对地址进行排序。为了鼓励从IPv4 SMTP过渡到IPv6 SMTP,应优先考虑AAAA记录。排序只能从相同首选项的MX记录中重新排序地址。RFC 2821第5节第4段建议对目的地址进行随机化。随机化只应发生在A记录和AAAA记录之间(不要混合A和AAAA记录)。

(6) For each of the addresses, loop over steps (7) to (9).

(6) 对于每个地址,循环步骤(7)到(9)。

(7) Try to make a TCP connection to the destination's SMTP port (25). The client needs to follow timeouts documented in RFC 2821 section If successful, go to step (9).

(7) 尝试与目标SMTP端口建立TCP连接(25)。客户需要遵守RFC 2821第4.5.3.2节中记录的超时。如果成功,请转至步骤(9)。

(8) If unsuccessful and there is another available address, try the next available address. Go to step (7). If all addresses are not reachable 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.

(8) 如果不成功且存在其他可用地址,请尝试下一个可用地址。转至步骤(7)。如果无法访问所有地址,并且正在遍历MX记录列表,请尝试下一条MX记录(转至步骤(3))。如果没有MX记录列表,或者如果已到达MX记录列表的末尾,则引发临时电子邮件发送失败。完成

(9) Attempt to deliver the email over the connection established, as specified in RFC 2821. If a transient failure condition is reported, try the next MX record (go to step (3)). If an error condition is reported, raise a permanent email delivery error, and do not try further MX records. Finish. If successful, SMTP delivery has succeeded. Finish.

(9) 按照RFC 2821中的规定,尝试通过已建立的连接发送电子邮件。如果报告了瞬态故障情况,请尝试下一个MX记录(转至步骤(3))。如果报告了错误情况,请引发永久性电子邮件传递错误,并且不要尝试进一步的MX记录。完成如果成功,SMTP传递已成功。完成

4. MX Configuration in the Recipient Domain
4. 收件人域中的MX配置
4.1. Ensuring Reachability for Both Protocol Versions
4.1. 确保两个协议版本的可达性

If a site has dual-stack reachability, the site should configure both A and AAAA records for its MX hosts (NOTE: MX hosts can be outside of the site). This will help both IPv4 and IPv6 senders in reaching the site efficiently.


4.2. Reachability Between the Primary and Secondary MX
4.2. 主MX和辅助MX之间的可达性

When registering MX records in a DNS database in a dual-stack environment, reachability between MX hosts must be considered carefully. Suppose all inbound email is to be gathered at the primary MX host, "":

在双堆栈环境中在DNS数据库中注册MX记录时,必须仔细考虑MX主机之间的可达性。假设所有入站电子邮件都收集在主MX主机“”上: IN MX 1 IN MX 10 IN MX 100。在MX 1 mx1.example.org中。在MX 10 mx10.example.org中。在MX 100 mx100.example.org中。

If "" is an IPv6-only node, and the others are IPv4- only nodes, there is no reachability between the primary MX host and the other MX hosts. When email reaches one of the lower MX hosts, it cannot be relayed to the primary MX host based on MX preferencing mechanism. Therefore, will not be able to collect all the emails (unless there is another transport mechanism(s) between lower-preference MX hosts and


; This configuration is troublesome. ; No secondary MX can reach IN MX 1 ; IPv6-only IN MX 10 ; IPv4-only IN MX 100 ; IPv4-only

; 这种配置很麻烦;没有辅助MX可以访问。。在MX 1 mx1.example.org中;仅在MX 10 mx10.example.org中使用IPv6;仅在MX 100 mx100.example.org中使用IPv4;仅IPv4

The easiest possible configuration is to configure the primary MX host as a dual-stack node. By doing so, secondary MX hosts will have no problem reaching the primary MX host.


      ; This configuration works well.
      ; The secondary MX hosts are able to relay email to the primary MX
      ; host without any problems.    IN MX   1     ; dual-stack
                      IN MX   10    ; IPv4-only
                      IN MX   100   ; IPv6-only
      ; This configuration works well.
      ; The secondary MX hosts are able to relay email to the primary MX
      ; host without any problems.    IN MX   1     ; dual-stack
                      IN MX   10    ; IPv4-only
                      IN MX   100   ; IPv6-only

It may not be necessary for the primary MX host and lower MX hosts to directly reach one another with IPv4 or IPv6 transport. For example, it is possible to establish a routing path with UUCP or an IPv4/v6


translator. It is also possible to drop messages into a single mailbox with shared storage using NFS or something else offered by a dual-stack server. It is the receiver site's responsibility that all messages delivered to MX hosts arrive at the recipient's mail drop. In such cases, a dual-stack MX host may not be listed in the MX list.


5. Operational Experience
5. 操作经验

Many of the existing IPv6-ready MTA's appear to work in the way documented in section 3.


There were, however, cases where IPv6-ready MTA's were confused by broken DNS servers. When attempting to obtain a canonical hostname, some broken name servers return SERVFAIL (RCODE 2), a temporary failure on AAAA record lookups. Upon this temporary failure, the email is queued for a later attempt. In the interest of IPv4/v6 interoperability, these broken DNS servers should be fixed. A document by Yasuhiro Morishita [Morishita] has more detail on misconfigured/misbehaving DNS servers and their negative side effects.

然而,在某些情况下,IPv6就绪MTA被损坏的DNS服务器搞混了。当尝试获取规范主机名时,一些断开的名称服务器返回SERVFAIL(RCODE 2),这是AAAA记录查找中的临时故障。一旦出现此临时故障,电子邮件将排队等待稍后的尝试。为了实现IPv4/v6的互操作性,应该修复这些损坏的DNS服务器。森田康弘(Yasuhiro Morishita)[Morishita]的一份文件更详细地介绍了错误配置/行为不当的DNS服务器及其负面影响。

6. Open Issues
6. 公开问题

o How should scoped addresses (i.e., link-local addresses) in email addresses be interpreted on MTA's? We suggest prohibiting the use of IPv6 address literals in destination specification.

o MTA应如何解释电子邮件地址中的作用域地址(即链接本地地址)?我们建议禁止在目标规范中使用IPv6地址文本。

o A future specification of SMTP (revision of RFC 2821) should be updated to include IPv6 concerns presented in this memo, such as (1) the additional query of AAAA RRs where A RRs and/or MX RRs are suggested, and (2) the ordering between IPv6 destination and IPv4 destination.

o 应更新SMTP的未来规范(RFC 2821的修订版),以包括本备忘录中提出的IPv6问题,例如(1)建议使用RRs和/或MX RRs的AAAA RRs的附加查询,以及(2)IPv6目标和IPv4目标之间的排序。

7. Security Considerations
7. 安全考虑

It could be problematic if the route-addr email address format [Crocker] (or "obs-route" address format in [Resnick]) is used across multiple scope zones. MTAs would need to reject email with route-addr email address formats that cross scope zone borders.

如果路由地址电子邮件地址格式[Crocker](或[Resnick]中的“obs路由”地址格式)跨多个作用域使用,则可能会出现问题。MTA将需要拒绝使用route addr电子邮件地址格式的跨作用域边界的电子邮件。

Appendix A. Considerations on Translators

IPv6-only MTA to IPv4-only MTA cases could use help from IPv6-to-IPv4 translators such as [Hagino]. Normally there are no special SMTP considerations for translators needed. 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.

仅限IPv6的MTA到仅限IPv4的MTA案例可以使用来自IPv6到IPv4转换器(如[Hagino])的帮助。通常,对于所需的翻译人员,没有特殊的SMTP注意事项。如果在IPv6到IPv4转换器上存在从IPv6 MTA到IPv4MTA的SMTP业务,则IPv4 MTA将考虑此正常IPv4 SMTP业务。

Protocols like IDENT [St.Johns] may require special consideration when translators are used. Also, there are MTAs which perform strict checks on the SMTP HELO/EHLO "domain" parameter (perform reverse/forward DNS lookups and see if the "domain" really associates to the SMTP client's IP address). In such a case, we need a special consideration when translators will be used (for instance, override "domain" parameter by translator's FQDN/address).

在使用翻译器时,像IDENT[St.Johns]这样的协议可能需要特别考虑。此外,还有MTA对SMTP HELO/EHLO“domain”参数执行严格检查(执行反向/正向DNS查找,查看“domain”是否真的与SMTP客户端的IP地址关联)。在这种情况下,我们需要特别考虑何时使用转换器(例如,通过转换器的FQDN/地址覆盖“domain”参数)。

Even without a translator, it seems that there are some MTA implementations in the wild which send IPv6 address literals in a HELO/EHLO message (like "HELO [IPv6:blah]"), even when it is using IPv4 transport, or vice versa. If the SMTP peer is IPv4-only, it won't understand the "[IPv6:blah]" syntax and mails won't go out of the (broken) MTA. These implementations have to be corrected.


Normative References


[Mockapetris] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[Mockapetris]Mockapetris,P.,“域名-实现和规范”,STD 13,RFC 10351987年11月。

[Thomson] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.

[Thomson]Thomson,S.,Huitema,C.,Ksinant,V.,和M.Souissi,“支持IP版本6的DNS扩展”,RFC 3596,2003年10月。

[Partridge] Partridge, C., "Mail routing and the domain system", STD 10, RFC 974, January 1986.

[鹧鸪]鹧鸪,C.,“邮件路由和域系统”,STD 10,RFC 974,1986年1月。

[Klensin] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

[Klensin]Klensin,J.,“简单邮件传输协议”,RFC 28212001年4月。

[Crocker] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.

[Crocker]Crocker,D.,“ARPA互联网文本信息格式标准”,STD 11,RFC 822,1982年8月。

[Resnick] Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[Resnick]Resnick,P.,“互联网信息格式”,RFC 2822,2001年4月。

[Hagino] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at Site Exit Routers", RFC 3178, October 2001.

[Hagino]Hagino,J.和H.Snyder,“站点出口路由器的IPv6多主支持”,RFC 3178,2001年10月。

[St.Johns] Johns, M. St., "Identification Protocol", RFC 1413, February 1993.

[圣约翰]约翰,M.圣约翰,“识别协议”,RFC 1413,1993年2月。

Informative References


[Morishita] Morishita, Y. and T. Jinmei, "Common Misbehavior against DNS Queries for IPv6 Addresses", Work in Progress, June 2003.




This document was written based on discussions with Japanese IPv6 users and help from the WIDE research group. Here is a (probably incomplete) list of people who contributed to the document: Gregory Neil Shapiro, Arnt Gulbrandsen, Mohsen Souissi, JJ Behrens, John C Klensin, Michael A. Patton, Robert Elz, Dean Strik, Pekka Savola, and Rob Austein.


Authors' Addresses


Motonori NAKAMURA Academic Center for Computing and Media Studies, Kyoto University Yoshida-honmachi, Sakyo, Kyoto 606-8501, JAPAN


   Fax:   +81-75-753-7450
   Fax:   +81-75-753-7450

Jun-ichiro itojun HAGINO Research Laboratory, Internet Initiative Japan Inc. 1-105, Kanda Jinbo-cho, Chiyoda-ku,Tokyo 101-0051, JAPAN

Jun ichiro itojun HAGINO研究实验室,日本互联网倡议公司,日本千代田区神田金波町1-105号,东京101-0051

   Phone: +81-3-5205-6464
   Fax:   +81-3-5205-6466
   Phone: +81-3-5205-6464
   Fax:   +81-3-5205-6466

Full Copyright Statement


Copyright (C) The Internet Society (2005).


This document is subject to the rights, licenses and restrictions contained in BCP 78, and at, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78和www.rfc-editor.org中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。



Intellectual Property


The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关ISOC文件中权利的ISOC程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at


The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at




Funding for the RFC Editor function is currently provided by the Internet Society.