この文書はRFC3639の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
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.
この文書は、ポート番号やプロトコル番号と結び付くかもしれない特定のサー
ビスを識別するための、ＩＰプロトコル番号フィールドとペイロードプロト
コル（例えば、ＴＣＰ）ポートフィールドの使用に関連する考察を記述しま
す。
1. Introduction
1. はじめに
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.
この文書は、ポート番号やプロトコル番号と結び付くかもしれない特定のサー
ビスを識別するための、ＩＰプロトコル番号フィールドとペイロードプロト
コル（例えば、ＴＣＰ）ポートあるいはサービスフィールドの使用に関連す
る考察を記述します。これは中間システムによる適切な処理とサービス識別
子の使用に関係する一般的な記述です。
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.
このメモはトラフィック流の中でサービス識別子に基づくトラフィック伝送
のフィルタや排除を意図する、中間システムによる様々な方法が、限定され
た効果を持つことを指摘します。これは同じく影響を受けたサービスが、固
定したサービス識別子をＩＰパケットヘッダから取り除くためにカプセル化
や動的ポート交渉の種々な方法を使うように、デザインを変更することの主
な副作用を指摘します。ＩＡＢはこれが、単純で信頼性が高いインターネッ
トアプリケーションのデザインと関係するインターネット共同体の一般的な
利害関係をサポートすると信じません。この文書はパケットのサービス識別
子と実際のサービスの間の仮定された関係に基づく中間システム動作に依存
しない制御メカニズムが与えられることを示唆します。
2. Service Identifiers
2. サービス識別子
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:
ＩＰプロトコル群でのＩＰトラフィック流の中サービス識別に関連するある
特定の慣習が、必ずしも計画的にではなく、進展しました：
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 ＩＰプロトコル群の中で、終端点識別子（例えば、ＴＣＰ／ＵＤＰ／ＳＣ
ＴＰポート番号やＩＰプロトコル番号）が終端サービスを識別するよう意
図されます。特に、ＴＣＰやＵＤＰやＳＣＴＰ（ストリームコントロール
送信プロトコル）ポート番号が宛先終端点のソースサービスの場所と宛先
サービスエンティティーを識別するように意図されます。
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 ＩＰ[2]データグラムヘッダは、データグラムのソースと宛先アドレスと、
上位レベルプロトコルの表示（ＵＬＰ）をデータグラムの中に含んでいま
す。もしＵＬＰがＴＣＰ[3]かＵＤＰ[1]かＳＣＴＰ[8]であるなら、ペイ
ロードはソースポートと宛先ポート番号を含み、これはサービス間の区別
（例えば、ＴＥＬＮＥＴとＨＴＴＰ）と、ソースアドレスと宛先アドレス
で示される一対のホストの同じサービスの複数の接続の区別を許します。
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 習慣によって、少なくともＴＣＰとＵＤＰで、ある特定のポート番号が接
続点として用いられ、そして通信のソースあるいは宛先側で「既知」と考
えられています。このような接続点は現在[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 与えられた「既知」ポートにもかかわらず、ポート番号はエンドシステム
で意味を持つことを保証されるだけです。中間システムはある、（例えば、
資源予約プロトコル（ＲＳＶＰ）［４］によって）エンドシステムが特別
に指定しない限り、あるいは、（例えば、ＩＰセキュリティプロトコル
（ＩＰＳＥＣ）のファイアウォール通過[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 あるサービスが動的に特定の通信にサービス識別子（すなわち、ポート番
号）を割り当てるためにプロトコル作用を利用します。この１つの事例は
セッション開始プロトコル（ＳＩＰ）[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 今日存在する種々な製品とサービス関連のメカニズムが種々なことをする
ために（例えば、ファイアウォールフィルタや、ＱｏＳマーク付け）、あ
るサービス識別子が比較的安定した（そして既知である）という事実を利
用します。
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 パケットカプセル化（例えば、トンネル）と暗号化の種々な形式のような、
ある特定のネットワークオペレーションは、ＩＰパケットをネットワーク
で転送中に、このポート番号（あるいはサービス識別子）を見えなくでき
ます。例えば、ＩＰＳＥＣ暗号化セキュリティペイロード（ＥＳＰ）[6]
と一般的なルーティングカプセル化（ＧＲＥ）[7]の両方が、他のＩＰデー
タグラム内にＩＰデータグラムをトンネルする手段を用意します。サービ
ス情報が不明瞭にされ、そして、いくつかの場合には暗号化されます。
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.
中間システムが課したサービスベース管理は、利用者の正しい使用を妨害す
るかもしれません。例えば、あるサービスプロバイダがスパムを妨げる目的
でポート２５（通常はＳＭＴＰ）トラフィックを阻止します、しかしこれは
エンドユーザの正当な電子メールを阻止します。
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]。サービスが他のサービス上にト
ンネルされたり、協同外部ホスト（例えば匿名リダイレクタ）でプロキシさ
れたり、代替ポート（例えば、ＨＴＴＰでポート８０８０の対ポート８０）
上で動作するかもしれませんん。もう１つの迂回の手段が静的ポートアドレ
スの使用を避けるために、動的ポート交渉フェーズを使うためのサービス動
作の変更です。
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.
もし中間システムが通信者のためあるいは通信に影響を与える行動を行うな
ら、経験から得られる事は、サービス固有プロトコルの運用パラメータでい
ずれかの通信者に利益があるか理解がされる行動を取る事か、そうでなけれ
ばユーザ共同体による広範囲の回避を導くきそうにない行動をする事です。
3. Ramifications
3. 成り行き
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.
ＩＡＢはエンドシステム以外の場所でグローバルに安定して認識できる意味
のあるサービス識別子を持つことは、マクロレベルのネットワーク行動とネッ
トワーク負荷を決定する目的で役立ち得ると述べます。ＩＡＢは同じく、両
方の接続終端での動的ポート交渉を含むアプリケーションプロトコルは、ア
プリケーションの複雑さを加える傾向があると述べます。
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.
サービスプロバイダ（例えばＩＳＰや雇用者）がポートブロックメカニズム
を通してある形式のサービスフィルタリングを設定した状況で、プロトコル
のための動的ポート交渉はその使用を制限されるか禁止されるかもしれませ
ん。
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.
このネットワークとアプリケーションユーティリティの見地から、エンドユー
ザとプロトコル設計者がＩＰパケットヘッダからサービス識別子情報を隠す
ことになるような、政府機関やキャリアやサービスプロバイダや組織による
行動あるいは活動が着手されないことは望ましいです。
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.
この主張は、カプセル化や、アプリケーションセキュリティや、エンドエン
ド暗号化や、あるいは特にエンドユーザが望む他の処理に反対していると解
釈されるべきではありません。
4. Security Considerations
4. セキュリティの考察
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.
この文書は中間システムによるサービス識別子の適切な処理と使用に関係す
る一般的な主張です。もし多数の政府機関やキャリアやサービスプロバイダ
や組織がここで言った懸念を無視するなら、ポート番号とプロトコル番号の
ユーティリティや一般的なネットワーク分析やエンドユーザに有利なフィル
タ（例えば、分散サービス妨害攻撃の排除）やこれらのサービス識別子の他の
共通の使用に、不利に影響を及ぼすかもしれません。
5. References
5. 参考文献
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[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.
[5] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[7] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[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.
[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.
[10] New York Times, "STUDENTS EVADE UNIVERSITY TACTICS TO PROTECT
MEDIA FILES", 27th November 2002.
[11] IANA, "IANA Protocol Numbers and Assignment Services", May
2003, <http://www.iana.org/numbers.htm>.
[12] IANA, "IANA Protocol Number Registry", May 2003, <http://
www.iana.org/assignments/protocol-numbers>.
[13] IANA, "IANA Port Number Registry", May 2003, <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.
この文書に記述された実装や技術に関して主張される知的財産や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する調査をしたとは述べません。ＩＥＴＦ標準手続きと標準関連文書で
の権利に関しての手順の情報はＢＣＰ１１を見てください。出版に利用する
権利の利用可能性とライセンスの保証の利用可能性か、あるいはこの仕様書
の実装者や利用者のこの様な所有権の一般的ライセンスや許可を得る試みの
結果はＩＥＴＦ事務局で得られます。
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.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかＩＥＴＦ専務に情報を伝えてください。
Appendix A. IAB Members
付録Ａ ＩＡＢメンバ
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
Editors' Addresses
著者のアドレス
Mike St Johns
Internet Architecture Board
EMail: mstjohns@mindspring.com
Geoff Huston
Internet Architecture Board
EMail: gih@telstra.net
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００３）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。