Network Working Group M. St. Johns, Ed.
Request for Comments: 3639 G. Huston, Ed.
Category: Informational IAB
October 2003
Network Working Group M. St. Johns, Ed.
Request for Comments: 3639 G. Huston, Ed.
Category: Informational IAB
October 2003
Considerations on the use of a Service Identifier in Packet Headers
关于在包头中使用服务标识符的考虑
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g., TCP) port fields to identify particular services that may be associated with that port number or protocol number.
本备忘录描述了与使用IP协议编号字段和有效负载协议（例如TCP）端口字段相关的一些注意事项，以识别可能与该端口编号或协议编号相关的特定服务。
This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g., TCP) port or service fields to identify particular services that may be associated with that port number or protocol number. It is a general statement regarding appropriate processing and use of service identifiers by intermediate systems.
本备忘录描述了与使用IP协议编号字段和有效负载协议（如TCP）端口或服务字段相关的一些注意事项，以识别可能与该端口编号或协议编号相关的特定服务。它是关于中间系统适当处理和使用服务标识符的一般性说明。
This memo points out that various measures by intermediate systems that are intended to filter or prevent the transmission of traffic based on the service identification within the traffic flow will have a limited effect. This will also have a major side-effect of forcing the affected services to be redesigned using various forms of encapsulation or dynamic port negotiation in order to remove the fixed service identification from the IP packet headers. The IAB does not believe this serves the general interests of the Internet community related to the design of simple and reliable Internet applications. This memo suggests some thought be given to control mechanisms that do not rely on intermediary systems taking actions based on an assumed relationship between the service identifier in the packet and the actual service of which the packet is a part.
该备忘录指出，中间系统旨在根据交通流中的服务标识过滤或阻止交通传输的各种措施的效果有限。这还将产生一个主要的副作用，即强制使用各种形式的封装或动态端口协商重新设计受影响的服务，以便从IP数据包头中删除固定服务标识。IAB认为，这不符合互联网社区在设计简单可靠的互联网应用程序方面的一般利益。该备忘录建议考虑一些控制机制，这些机制不依赖于中间系统，根据数据包中的服务标识符与数据包所属的实际服务之间的假定关系采取行动。
Although not necessarily by design, certain conventions have evolved with respect to the IP protocol suite relative to the identification of services within an IP traffic flow:
尽管设计上不一定如此，但与IP通信流中服务的标识相关的IP协议套件的某些约定已经演变：
o Within the IP protocol suite, end point identifiers (e.g., TCP/UDP/SCTP port numbers, IP protocol numbers) are designed to identify services to end points. In particular, TCP, UDP or SCTP (Stream Control Transmission Protocol) port numbers are intended to identify the source service location and the destination service entity to the destination end point.
o 在IP协议套件中，端点标识符（例如TCP/UDP/SCTP端口号、IP协议号）被设计用于标识到端点的服务。具体而言，TCP、UDP或SCTP（流控制传输协议）端口号旨在识别源服务位置和目标服务实体到目标端点。
o The IP [2] datagram header contains the source and destination address of the datagram as well as an indication of the upper-level protocol (ULP) carried within the datagram. If the ULP is either TCP [3], UDP [1], or SCTP [8] the payload will contain both source and destination port numbers which allows differentiation between services (e.g., TELNET, HTTP) and between multiple instances of the same service between the pair of hosts described by the source and destination address.
o IP[2]数据报报头包含数据报的源地址和目标地址，以及数据报中携带的上层协议（ULP）的指示。如果ULP是TCP[3]、UDP[1]或SCTP[8]，则有效负载将包含源端口号和目标端口号，这允许区分服务（例如TELNET、HTTP）之间以及源地址和目标地址描述的主机对之间相同服务的多个实例。
o By convention, for at least TCP and UDP, certain port numbers are used as rendezvous points and are considered "well known" on the source or destination side of the communication. Such rendezvous points are maintained in an IANA registry currently located at [11]. Specific registries for protocol and port numbers are at [12] and [13].
o 按照惯例，至少对于TCP和UDP，某些端口号被用作集合点，并且在通信的源端或目的端被认为是“众所周知的”。此类集合点保存在IANA登记册中，目前位于[11]。协议和端口号的具体注册表位于[12]和[13]。
o Notwithstanding the "well knownness" of any given port, port numbers are only guaranteed to be meaningful to the end systems. An intermediate system should generally not impute specific meaning to any given port number, unless specifically indicated by an end system (e.g., via the Resource Reservation Protocol (RSVP) [4]) or agreed to by convention among the end systems and one or more specific intermediate systems (e.g., firewall traversal for the IP Security Protocol (IPSEC) [5]).
o 尽管任何给定端口“众所周知”，但端口号仅保证对终端系统有意义。除非终端系统（例如，通过资源保留协议（RSVP）[4]）明确指示，或终端系统与一个或多个特定的中间系统（例如，IP安全协议的防火墙穿越）之间约定，否则中间系统通常不应将特定含义归于任何给定的端口号（IPSEC）[5]）。
o Some services make use of protocol interactions to dynamically allocate service identifiers (i.e., port numbers) to specific communications. One specific example of this is the Session Initiation Protocol (SIP) [9]. The implication of this is that intermediate systems cannot relate the service identifiers to the actual service unless they participate in the protocols which allocate the service identifiers, or are explicitly notified of the outcome of the allocation.
o 一些服务利用协议交互将服务标识符（即端口号）动态分配给特定的通信。这方面的一个具体示例是会话启动协议（SIP）[9]。这意味着中间系统不能将服务标识符与实际服务关联，除非它们参与分配服务标识符的协议，或者明确通知分配的结果。
o Various products and service-related mechanisms deployed today take advantage of the fact that some service identifiers are relatively stable (and well known) to do various things (e.g., firewall filtering, QOS marking).
o 今天部署的各种产品和服务相关机制利用了一个事实，即一些服务标识符相对稳定（并且众所周知）来执行各种操作（例如，防火墙过滤、QOS标记）。
o Certain network operations, such as various forms of packet encapsulation (e.g., tunneling) and encryption, can occlude this port number (or service identifier) while an IP packet is in transit within the network. For example, both the IPSEC Encapsulating Security Payload (ESP) [6] and Generic Routing Encapsulation (GRE) [7] both provide means for tunneling an IP datagram within another IP datagram. The service information becomes obscured and, in some instances, encrypted.
o 某些网络操作，例如各种形式的数据包封装（例如，隧道）和加密，可以在IP数据包在网络内传输时阻塞该端口号（或服务标识符）。例如，IPSEC封装安全有效负载（ESP）[6]和通用路由封装（GRE）[7]都提供了在另一个IP数据报中隧道传输IP数据报的方法。服务信息变得模糊，并且在某些情况下被加密。
o Cooperating end systems may elect to use arbitrarily selected port numbers for any service. The port numbers used in such cases may be statically defined, through coordinated configuration of the cooperating end systems through use of a common application or operating system, or by dynamic selection as an outcome of a rendezvous protocol.
o 协作终端系统可以选择为任何服务使用任意选择的端口号。在这种情况下使用的端口号可以是静态定义的，通过使用公共应用程序或操作系统对协作终端系统进行协调配置，或者通过动态选择作为会合协议的结果。
Intermediate system imposed service-based controls may block legitimate uses by subscribers. For example, some service providers are blocking port 25 (i.e., notionally SMTP) traffic for the stated purpose of trying to prevent SPAM, but which can also block legitimate email to the end user.
中间系统强制实施的基于服务的控制可能会阻止订阅者的合法使用。例如，一些服务提供商正在阻止端口25（即名义上的SMTP）通信量，以试图防止垃圾邮件，但这也会阻止发送给最终用户的合法电子邮件。
Attempts by intermediate systems to impose service-based controls on communications against the perceived interests of the end parties to the communication are often circumvented [10]. Services may be tunneled within other services, proxied by a collaborating external host (e.g., an anonymous redirector), or simply run over an alternate port (e.g., port 8080 vs port 80 for HTTP). Another means of circumvention is alteration of the service behavior to use a dynamic port negotiation phase, in order to avoid use of a constant port address.
中间系统试图对通信施加基于服务的控制，以对抗通信的最终方的感知利益，这种尝试通常是被规避的[10]。服务可以在其他服务中进行隧道传输，由协作的外部主机（例如，匿名重定向器）代理，或者简单地通过备用端口（例如，对于HTTP，端口8080与端口80）运行。另一种规避方法是改变服务行为以使用动态端口协商阶段，以避免使用常量端口地址。
For the purposes of this memo, a "party to a communication" is either the sender, receiver, or an authorized agent of the sender or receiver in the path.
就本备忘录而言，“通信一方”是路径中的发送方、接收方或发送方或接收方的授权代理人。
If intermediate systems take actions on behalf of one or more parties to the communication or affecting the communication, a good rule of thumb is they should only take actions that are beneficial to or approved by one or more of the parties, within the operational parameters of the service-specific protocol, or otherwise unlikely to lead to widespread evasion by the user community.
如果中间系统代表通信的一方或多方采取行动或影响通信，一个好的经验法则是，它们只应在服务特定协议的操作参数范围内采取对一方或多方有利或经一方或多方批准的行动，或者不太可能导致用户社区广泛逃避。
The IAB observes that having stable and globally meaningful service identifiers visible at points other than the end systems can be useful for the purposes of determining network behavior and network loading on a macro level. The IAB also observes that application protocols that include dynamic port negotiation for both ends of a connection tend to add to the complexity of the applications.
IAB观察到，在终端系统以外的点上具有稳定且具有全局意义的可见服务标识符对于在宏观层面上确定网络行为和网络负载是有用的。IAB还观察到，包括连接两端的动态端口协商的应用程序协议往往会增加应用程序的复杂性。
Dynamic port negotiation for a protocol may also limit or prohibit its use in situations where the service provider (e.g., ISP or employer) has instituted some form of service filtering through port blocking mechanisms.
协议的动态端口协商还可能限制或禁止在服务提供商（如ISP或雇主）通过端口阻塞机制实施某种形式的服务过滤的情况下使用该协议。
From this perspective of network and application utility, it is preferable that no action or activity be undertaken by any agency, carrier, service provider, or organization which would cause end-users and protocol designers to generally obscure service identification information from the IP packet header.
从网络和应用实用程序的这一角度来看，优选的是，任何机构、运营商、服务提供商或组织都不采取会导致最终用户和协议设计者通常从IP分组报头中隐藏服务标识信息的行动或活动。
Nothing in this statement should be construed as opposing encapsulation, application security, end-to-end encryption, or other processes beneficial or specifically desired by the end-users.
本声明中的任何内容都不应解释为反对封装、应用程序安全、端到端加密或最终用户有益或特别需要的其他过程。
This document is a general statement regarding appropriate processing and use of service identifiers by intermediate systems. If enough agencies, carriers, service providers, and organizations ignore the concerns voiced here, the utility of port and protocol numbers, general network analysis, end-user beneficial filtering (e.g., preventing DDOS attacks), and other common uses of these service identifiers might be adversely affected.
本文档是关于中间系统适当处理和使用服务标识符的一般说明。如果有足够多的机构、运营商、服务提供商和组织忽视此处提出的问题，则端口和协议编号、一般网络分析、最终用户有益过滤（例如，防止DDOS攻击）以及这些服务标识符的其他常用用途可能会受到不利影响。
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[1] Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[3] 《传输控制协议》，标准7，RFC 793，1981年9月。
[4] Braden, B., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[4] Braden，B.，Ed.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[6] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[7] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[7] Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[8] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[9] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[10] New York Times, "STUDENTS EVADE UNIVERSITY TACTICS TO PROTECT MEDIA FILES", 27th November 2002.
[10] 纽约时报，“学生逃避大学策略以保护媒体文件”，2002年11月27日。
[11] IANA, "IANA Protocol Numbers and Assignment Services", May 2003, <http://www.iana.org/numbers.htm>.
[11] IANA，“IANA协议编号和分配服务”，2003年5月<http://www.iana.org/numbers.htm>.
[12] IANA, "IANA Protocol Number Registry", May 2003, <http:// www.iana.org/assignments/protocol-numbers>.
[12] IANA，“IANA协议编号登记册”，2003年5月，<http://www.IANA.org/assignments/Protocol numbers>。
[13] IANA, "IANA Port Number Registry", May 2003, <http:// www.iana.org/assignments/port-numbers>.
[13] IANA，“IANA端口号注册”，2003年5月，<http://www.IANA.org/assignments/Port numbers>。
Intellectual Property Statement
知识产权声明
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Internet Architecture Board Members at the time this document was completed were:
本文件完成时，互联网体系结构委员会成员为：
Bernard Aboba Harald Alvestrand Rob Austein Leslie Daigle, Chair Patrik Faltstrom Sally Floyd Jun-ichiro Itojun Hagino Mark Handley Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Michael St Johns
Bernard Aboba Harald Alvestrand Rob Austein Leslie Daigle，主席Patrik Faltstrom Sally Floyd Jun ichiro Itojun Hagino Mark Handley Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Michael St Johns
Editors' Addresses
编辑地址
Mike St Johns Internet Architecture Board
Mike St Johns互联网架构委员会
EMail: mstjohns@mindspring.com
EMail: mstjohns@mindspring.com
Geoff Huston Internet Architecture Board
杰夫·休斯顿互联网架构委员会
EMail: gih@telstra.net
EMail: gih@telstra.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。