Network Working Group B. Aboba, Ed.
Request for Comments: 4840 E. Davies
Category: Informational D. Thaler
Internet Architecture Board
April 2007
Multiple Encapsulation Methods Considered Harmful
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 IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods.
この文書は、複数のインターネット・プロトコル・カプセル化方式をサポートするリンク層プロトコルから生ずる建築や運用上の問題について説明します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Ethernet Experience ........................................4
1.2.1. IEEE 802.2/802.3 LLC Type 1 Encapsulation ...........6
1.2.2. Trailer Encapsulation ...............................7
1.3. PPP Experience ............................................10
1.4. Potential Mitigations .....................................10
2. Evaluation of Arguments for Multiple Encapsulations ............11
2.1. Efficiency ................................................11
2.2. Multicast/Broadcast .......................................12
2.3. Multiple Uses .............................................13
3. Additional Issues ..............................................15
3.1. Generality ................................................15
3.2. Layer Interdependence .....................................16
3.3. Inspection of Payload Contents ............................17
3.4. Interoperability Guidance .................................17
3.5. Service Consistency .......................................19
3.6. Implementation Complexity .................................19
3.7. Negotiation ...............................................19
3.8. Roaming ...................................................20
4. Security Considerations ........................................20
5. Conclusion .....................................................21
6. References .....................................................22
6.1. Normative Reference .......................................22
6.2. Informative References ....................................22
7. Acknowledgments ................................................25
Appendix A. IAB Members at the Time of This Writing ...............26
This document describes architectural and operational issues arising from the use of multiple ways of encapsulating IP packets on the same link.
この文書では、同じリンク上にIPパケットをカプセル化する複数の方法の使用に起因する建築や運用上の問題について説明します。
While typically a link-layer protocol supports only a single Internet Protocol (IP) encapsulation method, this is not always the case. For example, on the same cable it is possible to encapsulate an IPv4 packet using Ethernet [DIX] encapsulation as defined in "A Standard for the Transmission of IP Datagrams over Ethernet Networks" [RFC894], the IEEE 802.2/802.3 LLC [IEEE-802.3.2002] Type 1 encapsulation defined in "Two Methods For The Transmission of IP Datagrams over IEEE 802.3 Networks" [RFC948], or the IEEE 802 [IEEE-802.1A.1990] encapsulation defined in "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks" [RFC1042]. Historically, a further encapsulation method was used on some Ethernet systems as specified in "Trailer Encapsulations" [RFC893]. Similarly, ATM (e.g., see [RFC2684]), the Point-to-Point Protocol (PPP) [RFC1661], and IEEE 802.16 [IEEE-802.16e.2005] also support multiple encapsulation mechanisms.
一般的に、リンク層プロトコルは、単一のインターネット・プロトコル（IP）カプセル化方式をサポートしていますが、これは必ずしもそうではありません。 [RFC894]、IEEE 802.2 / 802.3 LLC [IEEE-「イーサネット・ネットワーク上のIPデータグラムの送信の規格」で定義されるように、例えば、同一のケーブル上で、イーサネット[DIX]カプセル化を使用してIPv4パケットをカプセル化することが可能です802.3.2002] [RFC948]、またはIPの伝送のための基準」で定義されたIEEE 802 [IEEE-802.1A.1990]カプセル化「IEEE 802.3ネットワーク上のIPデータグラムの送信のための2つの方法」で定義された1カプセルを入力IEEE 802のネットワークを介してデータグラム」[RFC1042]。 「トレーラーのカプセル化」[RFC893]で指定されるように、歴史的に、さらにカプセル化方法は、いくつかのイーサネットシステムで使用されました。同様に、ATM（例えば、[RFC2684]を参照）、ポイントツーポイントプロトコル（PPP）[RFC1661]、およびIEEE 802.16は[IEEE-802.16e.2005]また、複数のカプセル化メカニズムをサポートします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Broadcast domain The set of all endpoints that receive broadcast frames sent by an endpoint in the set.
ブロードキャストドメインセット内のエンドポイントによって送られたブロードキャストフレームを受信するすべてのエンドポイントのセット。
Classification As defined in [IEEE-802.16e.2005], the process by which a Medium Access Control (MAC) Service Data Unit (SDU) is mapped into a particular transport connection for transmission between MAC peers.
[IEEE-802.16e.2005]、媒体アクセス制御（MAC）サービスデータユニット（SDU）をMACピア間の伝送のための特定のトランスポート接続にマッピングされるプロセスで定義されるように分類。
Connection Identifier (CID) In [IEEE-802.16e.2005] the connection identifier is a 16-bit value that identifies a transport connection or an uplink (UL)/downlink (DL) pair of associated management connections. A connection is a unidirectional mapping between base station (BS) and subscriber station (SS) MAC peers. Each transport connection has a particular set of associated parameters indicating characteristics such as the ciphersuite and quality-of-service.
[IEEE-802.16e.2005]接続識別子で接続識別子（CID）は、トランスポート接続または関連する管理接続のアップリンク（UL）/ダウンリンク（DL）対を識別する16ビット値です。接続は、基地局（BS）及び加入者局（SS）MACピア間の一方向マッピングです。各トランスポート接続は、暗号の組み合わせやサービス品質などの特性を示す関連するパラメータの特定のセットを有します。
Link A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP.
ノードはリンク層、直ちにIP以下即ち、層で通信を行う通信設備または媒体をリンクします。
Link Layer The conceptual layer of control or processing logic that is responsible for maintaining control of the link. The link-layer functions provide an interface between the higher-layer logic and the link. The link layer is the layer immediately below IP.
リンクは、リンクの制御を維持する責任がある制御または処理ロジックの概念層レイヤ。リンク層の機能は上位層の論理とリンクとの間のインタフェースを提供します。リンク層は、直ちにIP下の層です。
The fundamental issues with multiple encapsulation methods on the same link are described in [RFC1042] and "Requirements for Internet Hosts -- Communication Layers" [RFC1122]. This section summarizes the concerns articulated in those documents and also describes the limitations of approaches suggested to mitigate the problems, including encapsulation negotiation and use of routers.
[RFC1122] - 同じリンク上に複数のカプセル化方式を使用して基本的な問題は、[RFC1042]と「通信層をインターネットホストの要件」で説明されています。このセクションでは、それらの文書での関節の懸念を要約し、また、カプセル化交渉とルータの使用を含む問題を、軽減することが示唆アプローチの制限について説明します。
[RFC1042] described the potential issues resulting from contemporaneous use of Ethernet and IEEE 802.3 encapsulations on the same physical cable:
[RFC1042]は同じ物理ケーブル上のイーサネットとIEEE 802.3カプセル化の同時使用から生じる潜在的な問題を説明しました。
Interoperation with Ethernet
イーサネットとの相互運用
It is possible to use the Ethernet link level protocol [DIX] on the same physical cable with the IEEE 802.3 link level protocol. A computer interfaced to a physical cable used in this way could potentially read both Ethernet and 802.3 packets from the network. If a computer does read both types of packets, it must keep track of which link protocol was used with each other computer on the network and use the proper link protocol when sending packets.
IEEE 802.3リンクレベルプロトコルと同じ物理ケーブル上のイーサネットリンクレベルプロトコル[DIX]を使用することが可能です。このようにして使用される物理ケーブルにインターフェースコンピュータは、潜在的に、イーサネット、ネットワークから802.3パケットの両方を読み取ることができました。コンピュータは、パケットの両方のタイプを読んでない場合は、ネットワーク上の各他のコンピュータで使用してパケットを送信するときに、適切なリンクプロトコルを使用したリンクプロトコルを追跡する必要があります。
One should note that in such an environment, link level broadcast packets will not reach all the computers attached to the network, but only those using the link level protocol used for the broadcast.
一つは、このような環境では、リンクレベルのブロードキャストパケットがネットワークに接続されているすべてのコンピュータに達するが、放送に使用するリンクレベルのプロトコルを使用してのみしないことに注意すべきです。
Since it must be assumed that most computers will read and send using only one type of link protocol, it is recommended that if such an environment (a network with both link protocols) is necessary, an IP gateway be used as if there were two distinct networks.
ほとんどのコンピュータ読み取りおよびリンク・プロトコルの一種類のみを用いて送信することを想定しなければならないので、そのような環境（両方のリンクプロトコルとネットワーク）が必要であれば別個の二つがあったかのように、IPゲートウェイを使用することが推奨されますネットワーク。
Note that the MTU for the Ethernet allows a 1500 octet IP datagram, with the MTU for the 802.3 network allows only a 1492 octet IP datagram.
イーサネットのMTUは802.3ネットワークのMTUと、1500オクテットのIPデータグラムを可能にする唯一1492オクテットのIPデータグラムを許可することに注意してください。
When multiple IP encapsulation methods were supported on a given link, all hosts could not be assumed to support the same set of encapsulation methods. This in turn implied that the broadcast domain might not include all hosts on the link. Where a single encapsulation does not reach all hosts on the link, a host needs to determine the appropriate encapsulation prior to sending. While a host supporting reception of multiple encapsulations could keep track of the encapsulations it receives, this does not enable initiation of communication; supporting initiation requires a host to support sending of multiple encapsulations in order to determine which one to use. However, requiring hosts to send and receive multiple encapsulations is a potentially onerous requirement. [RFC1122], Section 2.3.3, notes the difficulties with this approach:
複数のIPカプセル化方式が与えられたリンク上でサポートされていた場合は、すべてのホストは、カプセル化メソッドの同じセットをサポートすると仮定することができませんでした。これは、順番にブロードキャストドメインは、リンク上のすべてのホストが含まれていない可能性があることを暗示しました。単一のカプセル化は、リンク上のすべてのホストに到達しない場合は、ホストは、送信前に適切なカプセル化を決定する必要があります。ホストが受信カプセル化を追跡することができ、複数のカプセル化の受信をサポートしているが、これは通信の開始を有効にしません。開始を支持することに使用するかを決定するために複数のカプセル化の送信をサポートするホストを必要とします。しかし、複数のカプセル化を送受信するホストを必要とする潜在的に不利な要件です。 [RFC1122]、セクション2.3.3は、このアプローチの難しさを指摘します：
Furthermore, it is not useful or even possible for a dual-format host to discover automatically which format to send, because of the problem of link-layer broadcasts.
さらに、あるため、リンク層ブロードキャストの問題により、送信するためにどのフォーマットを自動的に検出するデュアルフォーマットホストに役立つかさえできません。
To enable hosts that only support sending and receiving of a single encapsulation to communicate with each other, a router can be utilized to segregate the hosts by encapsulation. Here only the router needs to support sending and receiving of multiple encapsulations. This requires assigning a separate unicast prefix to each encapsulation, or else all hosts in the broadcast domain would not be reachable with a single encapsulation.
のみ送信および相互に通信するための単一のカプセル化の受信をサポートするホストを可能にするために、ルータは、カプセル化することによってホストを分離するために利用することができます。ここでは唯一のルータは、送信と複数のカプセル化の送受信をサポートする必要があります。これは、各カプセルに別々のユニキャストプレフィックスを割り当てる必要があり、または他のブロードキャストドメイン内のすべてのホストは、単一のカプセル化された到達可能ではないでしょう。
[RFC1122], Section 2.3.3, provided guidance on encapsulation support:
[RFC1122]、セクション2.3.3、カプセル化支援に関するガイダンスを提供します：
Every Internet host connected to a 10Mbps Ethernet cable:
10MbpsのEthernetケーブルに接続されているすべてのインターネットホスト：
o MUST be able to send and receive packets using RFC-894 encapsulation;
Oは、RFC-894のカプセル化を使用してパケットを送信および受信することができなければなりません。
o SHOULD be able to receive RFC-1042 packets, intermixed with RFC-894 packets; and
Oは、RFC-894パケットと混合RFC-1042パケットを受信することができるべきです。そして
o MAY be able to send packets using RFC-1042 encapsulation.
O RFC-1042のカプセル化を使用してパケットを送信することができるかもしれません。
An Internet host that implements sending both the RFC-894 and the RFC-1042 encapsulation MUST provide a configuration switch to select which is sent, and this switch MUST default to RFC-894.
RFC-894とRFC-1042のカプセル化の両方を送信して実装し、インターネットホストが送信されるかを選択し、設定スイッチを提供しなければならない、とこのスイッチは、RFC-894をデフォルトとしなければなりません。
By making Ethernet encapsulation mandatory to implement for both send and receive, and also the default for sending, [RFC1122] recognized Ethernet as the predominant encapsulation, heading off potential interoperability problems.
送信および受信し、また送信するためのデフォルトの両方に実装するイーサネットカプセル化が必須にすることにより、[RFC1122]は潜在的な相互運用性の問題をオフに見出し、主要なカプセル化として、イーサネットを認識しました。
Prior to standardization of the IEEE 802 encapsulation in [RFC1042], an IEEE 802.2/802.3 LLC Type 1 encapsulation was specified in [RFC948], utilizing 6 in the Source Service Access Point (SSAP) and Destination Service Access Point (DSAP) fields of the IEEE 802.2 header. However, since the SSAP and DSAP fields are each only a single octet, and the Ethertype values for IP, ARP [RFC826], and RARP [RFC903] are greater than 1500, these values cannot be represented in the SSAP and DSAP fields. As a result, the encapsulation described in [RFC948] did not support protocols requiring distinct Ethertypes such as ARP or RARP, and implementations typically included support for alternatives to ARP such as the Probe [PROBE] protocol. Support for ARP, RARP and other IP protocols utilizing distinct Ethertypes was addressed in [RFC1042], which obsoleted [RFC948]. [RFC1042] utilized the Sub-Network Access Protocol (SNAP) form of the IEEE 802.2 Logical Link Control (LLC) with the SSAP and DSAP fields set to 170, including support for the Ethertype field. As noted in "Assigned Numbers" [RFC1010]:
[RFC1042]でIEEE 802のカプセル化の標準化に先立ち、IEEE 802.2 / 802.3 LLCタイプ1カプセル化は[RFC948]、ソース・サービス・アクセス・ポイント（SSAP）に6を利用しての送信先サービスアクセスポイント（DSAP）フィールドに指定されましたIEEE 802.2ヘッダ。 SSAPとDSAPフィールドはそれぞれ単一オクテットであり、IPのためのEthertype値ので、ARP [RFC826]、およびRARPは[RFC903] 1500より大きい、これらの値は、SSAPおよびDSAPフィールドに表すことができないれます。結果として、[RFC948]に記載のカプセル化は、ARPまたはRARPなどの別個さらにEthertypeを必要とするプロトコルをサポートしておらず、実装は、典型的には、プローブ[PROBE]プロトコルとしてARPする代替のためのサポートを含んでいました。 ARP、RARPと明確なイーサタイプを利用する他のIPプロトコルのサポートは[RFC948]廃止[RFC1042]で取り上げられました。 [RFC1042]はEtherTypeフィールドのサポートを含む、170に設定SSAPとDSAPフィールドとIEEE 802.2論理リンク制御（LLC）のサブネットワークアクセスプロトコル（SNAP）形式を利用します。 「割り当て番号」[RFC1010]で述べたように：
At an ad hoc special session on "IEEE 802 Networks and ARP", held during the TCP Vendors Workshop (August 1986), an approach to a consistent way to send DoD-IP datagrams and other IP related protocols on 802 networks was developed.
TCPベンダーワークショップ（1986年8月）の間に開催された「IEEE 802ネットワークとARP」の臨時特別セッション、で、802ネットワーク上国防総省-IPデータグラムおよびその他のIP関連のプロトコルを送信するための一貫した方法へのアプローチを開発しました。
Due to some evolution of the IEEE 802.2 standards and the need to provide for a standard way to do additional DoD-IP related protocols (such as the Address Resolution Protocol (ARP) on IEEE 802 network, the following new policy is established, which will replace the old policy (see RFC 960 and RFC 948 [108]).
IEEE 802.2規格のいくつかの進化と、そのようなIEEE 802ネットワーク上のアドレス解決プロトコル（ARP）などの追加国防総省-IP関連のプロトコルを（行うための標準的な方法を提供する必要があるため、次の新しいポリシーがその意志、確立されています古いポリシーを置換（RFC 960およびRFC 948 [108]を参照してください）。
The new policy is for the Internet community to use the IEEE 802.2 encapsulation on 802.3, 802.4, and 802.5 networks by using the SNAP with an organization code indicating that the following 16 bits specify the EtherType code (where IP = 2048 (0800 hex), see Ethernet Numbers of Interest).
インターネットコミュニティは、次の16ビットは、イーサタイプコード（IP = 2048（0800進）を指定することを示す組織コードとSNAPを使用して、802.3、802.4、および802.5ネットワーク上のIEEE 802.2カプセル化を使用するための新しいポリシーは、あります）金利のイーサネット番号を参照してください。
Header
...--------+--------+--------+
MAC Header| Length | 802.{3/4/5} MAC
...--------+--------+--------+
+--------+--------+--------+
| Dsap=K1| Ssap=K1| control| 802.2 SAP
+--------+--------+--------+
+--------+--------+---------+--------+--------+
|protocol id or org code =K2| Ether Type | 802.2 SNAP
+--------+--------+---------+--------+--------+
The total length of the SAP Header and the SNAP header is 8-octets, making the 802.2 protocol overhead come out on a nice boundary.
SAPヘッダーおよびSNAPヘッダの全長は802.2プロトコルオーバーヘッドが良い境界に出てくるなって、8オクテットです。
K1 is 170. The IEEE likes to talk about things in little-endian bit transmission order and specifies this value as 01010101. In big-endian order, as used in Internet specifications, this becomes 10101010 binary, or AA hex, or 170 decimal.
K1は、IEEEがリトルエンディアンビットの送信順序で物事について話をするのが好きだし、インターネットの仕様で使用されるように、ビッグエンディアンのために01010101.としてこの値を指定し、これは10101010バイナリ、または単三進、または170小数になり170です。
K2 is 0 (zero).
K2は0（ゼロ）です。
The use of the IP LSAP (K1 = 6) is to be phased out as quickly as possible.
IP LSAP（K1 = 6）の使用は、可能な限り迅速に段階的に廃止されるべきです。
Many of the issues involved in coexistence of the [RFC948] and [RFC1042] encapsulations are similar to those described in Section 1.2. For example, due to use of different SSAP/DSAP values, the broadcast domain might not include all hosts on the link, and a host would need to determine the appropriate encapsulation prior to sending. However, the lack of support for ARP within the [RFC948] encapsulation created additional interoperability and implementation issues. For example, the lack of support for ARP in [RFC948] implied that implementations supporting both [RFC948] and [RFC894] or [RFC1042] encapsulations would need to implement both ARP and an alternative address resolution mechanism such as Probe. Also, since the address resolution mechanism for [RFC948] implementations was not standardized, interoperability problems would likely have arisen had [RFC948] been widely implemented.
[RFC948]と[RFC1042]カプセル化の共存に関わる問題の多くは、セクション1.2で説明したものと同様です。たとえば、違いによるSSAP / DSAP値の使用に、ブロードキャスト・ドメインは、リンク上のすべてのホストが含まれていない可能性があり、ホストが送信前に、適切なカプセル化を決定する必要があります。ただし、[RFC948]カプセル内のARPのサポートの欠如は、追加の相互運用性と実装の問題を作成しました。例えば、ARPのサポートの欠如は、[RFC948]暗黙にその支持実装が両方の[RFC948]と[RFC894]または[RFC1042]カプセル化は、このようなプローブとしてARPおよび代替アドレス解決メカニズムの両方を実装する必要があります。 [RFC948]実装のためのアドレス解決メカニズムが標準化されなかったので、また、相互運用性の問題は、おそらく[RFC948]広く実装されていたが生じたであろう。
As noted in "Trailer Encapsulations" [RFC893], trailer encapsulation was an optimization developed to minimize memory-to-memory copies on reception. By placing variable-length IP and transport headers at the end of the packet, page alignment of data could be more easily maintained. Trailers were implemented in 4.2 Berkeley System Distribution (BSD), among others. While, in theory, trailer encapsulation could have been applied to the Ethernet [RFC894] or IEEE 802 [RFC1042] encapsulations (creating four potential encapsulations of IP!), in practice, trailer encapsulation was only supported for Ethernet. A separate Ethertype was utilized in order to enable IP packets in trailer encapsulation to be distinguished from [RFC894] encapsulation. Since the [RFC948] encapsulation did not support the Ethertype field (or ARP), this mechanism could not have been used in [RFC948] implementations.
「トレーラーカプセル化」[RFC893]で述べたように、トレーラカプセル化は、受信のメモリ対メモリコピーを最小限にするために開発された最適化でした。パケットの終わりで可変長IPおよびトランスポート・ヘッダーを配置することによって、データのページの位置合わせをより容易に維持することができます。トレーラーは、とりわけ、4.2バークレーシステムのディストリビューション（BSD）で実施されました。 、理論的には、トレーラーのカプセル化はイーサネット[RFC894]またはIEEE（IPの4つの潜在的なカプセル化を作成する！）802 [RFC1042]カプセル化に適用されている可能性がありますが、実際には、トレーラーのカプセル化はイーサネットのためにサポートされていました。別のEthertypeは[RFC894]カプセル化と区別するためにトレーラーのカプセル化にIPパケットを可能にするために利用しました。 [RFC948]カプセル化のEthertypeフィールド（またはARP）をサポートしていませんでしたので、このメカニズムは[RFC948]実装で使用されていませんでした。
[RFC1122], Section 2.3.1, described the issues with trailer encapsulation:
[RFC1122]、セクション2.3.1は、トレーラーのカプセル化の問題を説明しました。
DISCUSSION
討論
The trailer protocol is a link-layer encapsulation technique that rearranges the data contents of packets sent on the physical network. In some cases, trailers improve the throughput of higher layer protocols by reducing the amount of data copying within the operating system. Higher layer protocols are unaware of trailer use, but both the sending and receiving host MUST understand the protocol if it is used. Improper use of trailers can result in very confusing symptoms. Only packets with specific size attributes are encapsulated using trailers, and typically only a small fraction of the packets being exchanged have these attributes. Thus, if a system using trailers exchanges packets with a system that does not, some packets disappear into a black hole while others are delivered successfully.
トレーラープロトコルは、物理ネットワーク上で送信されたパケットのデータ内容を並べ替えるリンク層のカプセル化技術です。いくつかのケースでは、トレーラーは、オペレーティングシステム内のデータのコピーの量を減少させることによって、より高い層のプロトコルのスループットを向上させます。上位層プロトコルは、トレーラーの使用を知らないが、それが使用されている場合は送信側と受信側ホストの両方は、プロトコルを理解する必要があります。トレーラーの不適切な使用は、非常に混乱症状につながることができます。特定のサイズ属性を持つパケットだけがトレーラーを使用してカプセル化されており、一般的に交換されるパケットのごく一部には、これらの属性を持っています。システムがないシステムとトレーラー交換パケットを使用する場合、他は正常に配信されつつ、いくつかのパケットはブラックホールに消えます。
IMPLEMENTATION:
実装：
On an Ethernet, packets encapsulated with trailers use a distinct Ethernet type [RFC893], and trailer negotiation is performed at the time that ARP is used to discover the link-layer address of a destination system.
イーサネット上、トレーラーでカプセル化されたパケットは、別個のイーサネットタイプ[RFC893]を使用し、トレーラネゴシエーションがARPは宛先システムのリンク層アドレスを発見するために使用される時に行われます。
Specifically, the ARP exchange is completed in the usual manner using the normal IP protocol type, but a host that wants to speak trailers will send an additional "trailer ARP reply" packet, i.e., an ARP reply that specifies the trailer encapsulation protocol type but otherwise has the format of a normal ARP reply. If a host configured to use trailers receives a trailer ARP reply message from a remote machine, it can add that machine to the list of machines that understand trailers, e.g., by marking the corresponding entry in the ARP cache.
具体的には、ARP交換は通常のIPプロトコルタイプを使用して通常の方法で終了したが、トレーラーを話すことを望んでいるホストが追加の「トレーラーARP応答」パケット、すなわち、ARPはそれがトレーラーカプセル化プロトコルの種類を指定する返信を送信しますが、そうでない場合は、通常のARP応答の形式があります。トレーラーを使用するように構成されたホストがリモートマシンからトレーラーARP応答メッセージを受信した場合、それはARPキャッシュ内の対応するエントリをマークすることによって、例えば、トレーラーを理解するマシンのリストにそのマシンを追加することができます。
Hosts wishing to receive trailers send trailer ARP replies whenever they complete exchanges of normal ARP messages for IP. Thus, a host that received an ARP request for its IP protocol address would send a trailer ARP reply in addition to the normal IP ARP reply; a host that sent the IP ARP request would send a trailer ARP reply when it received the corresponding IP ARP reply. In this way, either the requesting or responding host in an IP ARP exchange may request that it receive trailers.
トレーラーを受信したいホストは、彼らがIPのための通常のARPメッセージの交換を完了したときに、トレーラーARP応答を送信します。したがって、そのIPプロトコルアドレスのARP要求を受信したホストは、通常のIP ARP応答に加えてトレーラーARP応答を送信します。それは、対応するIP ARP応答を受信したときにIP ARPリクエストを送信したホストは、トレーラーARP応答を送信します。このように、IP ARP交換における要求や応答ホストのいずれかは、それがトレーラーを受けることを要求することができます。
This scheme, using extra trailer ARP reply packets rather than sending an ARP request for the trailer protocol type, was designed to avoid a continuous exchange of ARP packets with a misbehaving host that, contrary to any specification or common sense, responded to an ARP reply for trailers with another ARP reply for IP. This problem is avoided by sending a trailer ARP reply in response to an IP ARP reply only when the IP ARP reply answers an outstanding request; this is true when the hardware address for the host is still unknown when the IP ARP reply is received. A trailer ARP reply may always be sent along with an IP ARP reply responding to an IP ARP request.
この方式は、余分なトレーラーを使用すると、ARPは、むしろトレーラープロトコルタイプのARP要求を送信するよりも、応答パケットを任意の仕様や常識に反して、ARP応答に答えた、というふらちなホストとのARPパケットを連続的に交換を避けるように設計されましたIPのための別のARP応答とのトレーラーのため。この問題は、IP ARP応答が未処理の要求に応答する場合にのみ返信IP ARPに応じてトレーラーARP応答を送信することによって回避されます。 IP ARP応答を受信したときにホストのハードウェアアドレスはまだ不明であるとき、これは本当です。トレーラーARP応答は常にIP ARPと一緒に送信することができるIP ARP要求に応答する返信します。
Since trailer encapsulation negotiation depends on ARP, it can only be used where all hosts on the link are within the same broadcast domain. It was assumed that all hosts supported sending and receiving ARP packets in standard Ethernet encapsulation [RFC894], so that negotiation between Ethernet and IEEE 802 encapsulations was not required, only negotiation between standard Ethernet [RFC894] and trailer [RFC893] encapsulation. Had hosts supporting trailer encapsulation also supported one or more IEEE 802 framing mechanisms, the negotiation would have been complicated still further. For example, since [RFC948] implementations did not support the Ethertype field or ARP, the trailer negotiation mechanism could not have been utilized, and additional difficulty would have been encountered in distinguishing trailer encapsulated data frames from normally encapsulated frames.
トレーラーのカプセル化交渉は、ARPに依存しているため、リンク上のすべてのホストが同じブロードキャストドメイン内にある場合は、それだけで使用することができます。これは、イーサネットおよびIEEE 802カプセル化との間の交渉は、標準的なイーサネット（登録商標）[RFC894]とトレーラー[RFC893]カプセル化の間の唯一のネゴシエーションを必要とされなかったので、すべてのホストが、[RFC894]標準的なイーサネットカプセル化にARPパケットを送受信するサポートと仮定しました。トレーラーのカプセル化をサポートするホストは、1つ以上のIEEE 802フレーミングメカニズムをサポートしていたが、交渉はさらに、まだ複雑されていたであろう。 [RFC948]実装はイーサタイプフィールドまたはARPをサポートしていませんでしたので、例えば、トレーラー交渉メカニズムが利用されていない可能性があり、追加的な難しさは、通常はカプセル化フレームからトレーラーカプセル化されたデータフレームを区別する際に遭遇されていたであろう。
[RFC1122], Section 2.3.1, provided the following guidance for use of trailer encapsulation:
[RFC1122]、セクション2.3.1は、トレーラーのカプセル化を使用するための以下のガイダンスを提供します：
The trailer protocol for link-layer encapsulation MAY be used, but only when it has been verified that both systems (host or gateway) involved in the link-layer communication implement trailers. If the system does not dynamically negotiate use of the trailer protocol on a per-destination basis, the default configuration MUST disable the protocol.
リンク層のカプセル化のためのトレーラープロトコルを使用することができるが、リンク層通信に関与する両方のシステム（ホストまたはゲートウェイ）がトレーラーを実装することが確認された場合にのみ。システムが動的先ごとのベースでトレーラープロトコルの使用を交渉していない場合は、デフォルトの設定では、プロトコルを無効にする必要があります。
4.2BSD did not support dynamic negotiation, only configuration of trailer encapsulation at boot time, and therefore [RFC1122] required that the trailer encapsulation be disabled by default on those systems.
4.2BSDは、動的な交渉、ブート時にトレーラーのカプセル化の構成のみ、したがって、[RFC1122]をサポートするトレーラーのカプセル化は、これらのシステムではデフォルトで無効にすることを必要としませんでした。
PPP can support both encapsulation of IEEE 802 frames as defined in [RFC3518], as well as IPv4 and IPv6 [RFC2472] packets. Multiple compression schemes are also supported.
PPPは、[RFC3518]で定義されるようにIEEE 802フレーム、ならびにIPv4およびIPv6 [RFC2472]パケットの両方のカプセル化をサポートすることができます。複数の圧縮方式もサポートされています。
In addition to PPP Data Link Layer (DLL) protocol numbers allocated for IPv4 (0x0021), IPv6 (0x0057), and Bridging PDU (0x0031), the following codepoints have been assigned:
IPv4の（0x0021）、IPv6の（0x0057）、及びブリッジPDU（0x0031）のために割り当てられたPPPデータリンク層（DLL）プロトコル番号に加えて、以下のコードポイントが割り当てられています。
o two for RObust Header Compression (ROHC) [RFC3095]: ROHC small-CID (0x0003) and ROHC large-CID (0x0005)
ROHC小CID（0x0003）とROHC大CID（0x0005）：ロバストヘッダ圧縮（ROHC）[RFC3095]のためのO 2
o two for Van Jacobson compression [RFC1144]: Compressed TCP/IP (0x002d) and Uncompressed TCP/IP (002f)
圧縮されたTCP / IP（0x002d）と非圧縮TCP / IP（002F）：ヴァンヤコブソン圧縮[RFC1144]のための2つのO
o one for IPv6 Header Compression [RFC2507]: (0x004f)
IPv6のヘッダ圧縮のための1つのO [RFC2507]：（0x004f）
o nine for RTP IP Header Compression [RFC3544]: Full Header (0x0061), Compressed TCP (0x0063), Compressed Non TCP (0x0065), UDP 8 (0x0067), RTP 8 (0x0069), Compressed TCP No Delta (0x2063), Context State (0x2065), UDP 16 (0x2067), and RTP 16 (0x2069)
以下のための9 O RTP IPヘッダー圧縮[RFC3544]：フルヘッダー（0x0061）、圧縮されたTCP（0x0063）、圧縮された非TCP（0x0065）、UDP 8（0x0067）、RTP 8（0x0069）、圧縮されたTCPノーデルタ（0x2063）、コンテキスト状態（0x2065）、UDP 16（0x2067）、およびRTP 16（0x2069）
Although PPP can encapsulate IP packets in multiple ways, typically multiple encapsulation schemes are not operational on the same link, and therefore the issues described in this document rarely arise. For example, while PPP can support both encapsulation of IEEE 802 frames as defined in [RFC3518], as well as IPv4 and IPv6 [RFC2472] packets, in practice, multiple encapsulation mechanisms are not operational on the same link. Similarly, only a single compression scheme is typically negotiated for use on a link.
PPPは複数の方法でIPパケットをカプセル化することができますが、通常、複数のカプセル化方式は、同じリンク上で動作していないであるため、このドキュメントで説明する問題はほとんど発生しません。 PPPは、[RFC3518]で定義され、同様に、IPv4とIPv6 [RFC2472]パケットとしてIEEE 802フレームの両方のカプセル化をサポートすることができながら、例えば、実際には、複数のカプセル化メカニズムは、同じリンク上で動作していません。同様に、単一の圧縮方式は、一般的に、リンク上で使用するために交渉されています。
In order to mitigate problems arising from multiple encapsulation methods, it may be possible to use switches [IEEE-802.1D.2004] or routers, or to attempt to negotiate the encapsulation method to be used. As described below, neither approach may be completely satisfactory.
複数のカプセル化方法から生じる問題を軽減するためには、スイッチ[IEEE-802.1D.2004]またはルータを使用する、または使用されるカプセル化方法を交渉しようとすることも可能です。以下に説明するように、どちらのアプローチは完全に満足であってもよいです。
The use of switches or routers to enable communication between hosts utilizing multiple encapsulation methods is not a panacea. If separate unicast prefixes are used for each encapsulation, then the choice of encapsulation can be determined from the routing table. If the same unicast prefix is used for each encapsulation method, it is necessary to keep state for each destination host. However, this may not work in situations where hosts using different encapsulations respond to the same anycast address.
複数のカプセル化方法を利用してホスト間の通信を可能にするスイッチまたはルータの使用は万能薬ではありません。別のユニキャストプレフィックスが各カプセル化に使用される場合、カプセル化の選択は、ルーティングテーブルから決定することができます。同じユニキャストプレフィックスが各カプセル化方法に使用される場合、各宛先ホストの状態を保つ必要があります。しかし、これは別のカプセル化を使用してホストが同じエニーキャストアドレスへの対応の状況で動作しない場合があります。
In situations where multiple encapsulation methods are enabled on a single link, negotiation may be supported to allow hosts to determine how to encapsulate a packet for a particular destination host.
複数のカプセル化方法は、単一リンク上で有効になっている状況では、ネゴシエーションは、ホストが特定の宛先ホストにパケットをカプセル化する方法を決定できるように支持されていてもよいです。
Negotiating the encapsulation above the link layer is potentially problematic since the negotiation itself may need to be carried out using multiple encapsulations. In theory, it is possible to negotiate an encapsulation method by sending negotiation packets over all encapsulation methods supported, and keeping state for each destination host. However, if the encapsulation method must be dynamically negotiated for each new on-link destination, communication to new destinations may be delayed. If most communication is short, and the negotiation requires an extra round trip beyond link-layer address resolution, this can become a noticeable factor in performance. Also, the negotiation may result in consumption of additional bandwidth.
リンク層の上のカプセル化を交渉する交渉自体が複数のカプセル化を使用して実施する必要があるかもしれないので、潜在的に問題があります。理論的には、サポートされるすべてのカプセル化方法に比べネゴシエーションパケットを送信し、各宛先ホストの状態を保つことによってカプセル化方式を交渉することが可能です。カプセル化方式を動的にそれぞれの新しいオンリンク先のために交渉しなければならない場合は、新しい目的地への通信が遅れる場合があります。ほとんどの通信が短く、交渉がリンク層アドレスの解決を越えて余分なラウンドトリップを必要とする場合、これはパフォーマンスの著しい要因になることができます。また、交渉は追加の帯域幅の消費をもたらすことができます。
There are several reasons often given in support of multiple encapsulation methods. We discuss each in turn, below.
多くの場合、複数のカプセル化方式のサポートに与えられたいくつかの理由があります。我々は、以下の順番でそれぞれを議論します。
Claim: Multiple encapsulation methods allow for greater efficiency. For example, it has been argued that IEEE 802 or Ethernet encapsulation of IP results in excessive overhead due to the size of the data frame headers, and that this can adversely affect performance on wireless networks, particularly in situations where support of Voice over IP (VoIP) is required.
請求：複数のカプセル化方法は、より高い効率を可能にします。例えば、それが原因のデータフレームのヘッダのサイズに過大なオーバーヘッドでIP結果のIEEE 802またはイーサネットカプセル化を主張し、これが悪影響を特にボイスオーバーIPのサポートは（状況では、ワイヤレスネットワーク上のパフォーマンスに影響を与えることができるされていますVoIPの）が必要です。
Discussion: Even where these performance concerns are valid, solutions exist that do not require defining multiple IP encapsulation methods. For example, links may support Ethernet frame compression so that Ethernet Source and Destination Address fields are not sent with every packet.
ディスカッション：これらのパフォーマンスの問題が有効である場合であっても、解決策は、複数のIPカプセル化メソッドを定義する必要がないということが存在します。イーサネット送信元アドレスと宛先アドレスフィールドはすべてのパケットを送信しないように、例えば、リンクは、イーサネットフレームの圧縮をサポートすることができます。
It is possible for link layers to negotiate compression without requiring higher-layer awareness; the Point-to-Point Protocol (PPP)
リンク層は、上位層の認識を必要とすることなく、圧縮を交渉することが可能です。ポイントツーポイントプロトコル（PPP）
[RFC1661] is an example. "The PPP Compression Control Protocol (CCP)" [RFC1962] enables negotiation of data compression mechanisms, and "Robust Header Compression (ROHC) over PPP" [RFC3241] and "IP Header Compression over PPP" [RFC3544] enable negotiation of header compression, without Internet-layer awareness. Any frame can be "decompressed" based on the content of the frame, and prior state based on previous control messages or data frames. Use of compression is a good way to solve the efficiency problem without introducing problems at higher layers.
[RFC1661]は一例です。 「PPP圧縮制御プロトコル（CCP）」[RFC1962]は[RFC3544]ヘッダ圧縮のネゴシエーションを有効データ圧縮メカニズム、及び[RFC3241]及び「PPP上のIPヘッダー圧縮」「PPP上ロバストヘッダ圧縮（ROHC）」の交渉を可能にします、インターネット層の意識なし。任意のフレームは、前回の制御メッセージ又はデータフレームに基づいてフレームの内容、前の状態に基づいて「伸長」させることができます。圧縮の使用は、より高い層で問題を導入することなく、効率の問題を解決するための良い方法です。
There are also situations in which use of multiple encapsulations can degrade performance or result in packet loss. The use of multiple encapsulation methods with differing Maximum Transfer Units (MTUs) can result in differing MTUs for on-link destinations. If the link-layer protocol does not provide per-destination MTUs to the IP layer, it will need to use a default MTU; to avoid fragmentation, this must be less than or equal to the minimum MTU of on-link destinations. If the default MTU is too low, the full bandwidth may not be achievable. If the default MTU is too high, packet loss will result unless or until IP Path MTU Discovery is used to discover the correct MTU.
複数のカプセル化を使用すると、パフォーマンスが低下するか、パケット損失が発生することが可能な状況もあります。異なる最大転送単位（MTUの）を持つ複数のカプセル化方法の使用は、オンリンクの宛先のためのMTUが異なるにつながることができます。リンク層プロトコルはIP層に先ごとのMTUを提供していない場合は、デフォルトのMTUを使用する必要があります。断片化を避けるために、これは以下のリンク先を最小MTUに等しくなければなりません。デフォルトのMTUが低すぎる場合には、全帯域幅が達成できない場合があります。デフォルトのMTUが高すぎる場合は、パケット損失が正しいMTUを発見するために使用されていない限り、またはIPパスMTUディスカバリーまでとなります。
Recommendation: Where encapsulation is an efficiency issue, use header compression. Where the encapsulation method or the use of compression must be negotiated, negotiation should either be part of bringing up the link, or be piggybacked in the link-layer address resolution exchange; only a single compression scheme should be negotiated on a link. Where the MTU may vary among destinations on the same link, the link-layer protocol should provide a per-destination MTU to IP.
勧告：カプセル化は効率の問題であり、ヘッダ圧縮を使用しています。カプセル化方式または圧縮の使用をネゴシエートしなければならない場合、ネゴシエーションのいずれかのリンクを立ち上げるの一部でなければならない、またはリンク層アドレス解決交換に便乗します。単一の圧縮方式は、リンク上で交渉されるべきです。 MTUは、同じリンク上の宛先の間で変化することができる場合、リンク層プロトコルは、IPを毎宛先MTUを提供すべきです。
Claim: Support for Ethernet encapsulation requires layer 2 support for distribution of IP multicast/broadcast packets. In situations where this is difficult, support for Ethernet is problematic and other encapsulations are necessary.
クレーム：イーサネットカプセル化のサポートは、IPマルチキャスト/ブロードキャストパケットの配信のためのレイヤ2のサポートが必要です。これは困難である状況では、イーサネットのサポートが問題であり、他のカプセル化が必要です。
Discussion: Irrespective of the encapsulation used, IP packets sent to multicast (IPv4/IPv6) or broadcast (IPv4) addresses need to reach all potential on-link receivers. Use of alternative encapsulations cannot remove this requirement, although there is considerable flexibility in how it can be met. Non-Broadcast Multiple Access (NBMA) networks can still support the broadcast/multicast service via replication of unicast frames.
ディスカッション：かかわらず使用するカプセル化の、マルチキャストに送信されたIPパケット（IPv4の/ IPv6の）またはブロードキャスト（IPv4）のアドレスは、すべての潜在的なリンク上の受信機に到達する必要があります。それを満たすことができる方法にかなりの柔軟性があるが、代替のカプセル化の使用は、この要件を削除することはできません。非ブロードキャストマルチアクセス（NBMA）ネットワークでは、まだユニキャストフレームの複製を経由してブロードキャスト/マルチキャストサービスをサポートすることができます。
Techniques are also available for improving the efficiency of IP multicast/broadcast delivery in wireless networks. In order to be receivable by any host within listening range, an IP multicast/broadcast packet sent as link-layer multicast/broadcast over a wireless link needs to be sent at the lowest rate supported by listeners. If the sender does not keep track of the rates negotiated by group listeners, by default, multicast/broadcast traffic is sent at the lowest supported rate, resulting in increased overhead. However, a sender can also deliver an IP multicast/broadcast packet using unicast frame(s) where this would be more efficient. For example, in IEEE 802.11, multicast/broadcast traffic sent from the Station (STA) to the Access Point (AP) is always sent as unicast, and the AP tracks the negotiated rate for each STA, so that it can send unicast frames at a rate appropriate for each station.
技術はまた、無線ネットワークにおけるIPマルチキャスト/ブロードキャスト配信の効率を向上させるために用意されています。聴取範囲内の任意のホストによって受信可能にするために、無線リンクを介してブロードキャストリンク層マルチキャスト/として送信されたIPマルチキャスト/ブロードキャストパケットは、リスナーによってサポートされる最低レートで送信される必要があります。送信者がグループリスナーによって交渉料金を追跡していない場合は、デフォルトでは、マルチキャスト/ブロードキャストトラフィックが増加し、オーバーヘッドが生じ、最低のサポートレートで送信されます。しかし、送信者はまた、これは、より効率的であるユニキャストフレーム（複数可）を使用してIPマルチキャスト/ブロードキャストパケットを配信することができます。例えば、IEEE 802.11に、アクセスポイント（AP）とステーション（STA）から送信されたマルチキャスト/ブロードキャストトラフィックは常にユニキャストとして送信され、そしてそれはでユニキャストフレームを送信できるように、APは、各STAのためにネゴシエート速度を追跡します各ステーションのための適切なレート。
In order to limit the propagation of link-scope multicast or broadcast traffic, it is possible to assign a separate prefix to each host.
リンクスコープマルチキャストまたはブロードキャストトラフィックの伝播を制限するためには、各ホストに別個のプレフィックスを割り当てることが可能です。
Unlike broadcasts, which are received by all hosts on the link regardless of the protocol they are running, multicasts only need be received by those hosts belonging to the multicast group. In wired networks, it is possible to avoid forwarding multicast traffic on switch ports without group members, by snooping of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) traffic as described in "Considerations for IGMP and MLD Snooping Switches" [RFC4541].
かかわらず、彼らが実行されているプロトコルのリンク上のすべてのホストで受信される放送とは異なり、マルチキャストは、マルチキャストグループに属するそれらのホストによって受信される必要があります。 「IGMPおよびMLDスヌーピングスイッチの考慮事項」で説明したように有線ネットワークでは、インターネットグループ管理プロトコル（IGMP）およびMulticast Listener Discovery（MLD）トラフィックのスヌーピングによって、グループメンバーなしでスイッチポート上でマルチキャストトラフィックを転送しないようにすることができます[ RFC4541]。
In wireless media where data rates to specific destinations are negotiated and may vary over a wide range, it may be more efficient to send multiple frames via link-layer unicast than to send a single multicast/broadcast frame. For example, in [IEEE-802.11.2003] multicast/broadcast traffic from the client station (STA) to the Access Point (AP) is sent via link-layer unicast.
特定の宛先へのデータレートがネゴシエートされ、広い範囲にわたって変えることができる無線媒体では、単一のマルチキャスト/ブロードキャストフレームを送信するよりも、リンク層ユニキャストを介して複数のフレームを送信する方が効率的であり得ます。例えば、[IEEE-802.11.2003]マルチキャスト/ブロードキャストにアクセスポイント（AP）へのクライアントステーション（STA）からのトラフィックは、リンク層ユニキャストを介して送信されます。
Recommendation: Where support for link-layer multicast/broadcast is problematic, limit the propagation of link-scope multicast and broadcast traffic by assignment of separate prefixes to hosts. In some circumstances, it may be more efficient to distribute multicast/broadcast traffic as multiple link-layer unicast frames.
推奨：リンク層マルチキャスト/ブロードキャストのためのサポートがホストに別個のプレフィックスの割当によってリンクスコープのマルチキャスト及びブロードキャストトラフィックの伝播を制限し、問題があります。いくつかの状況では、複数のリンク層ユニキャストフレームとしてマルチキャスト/ブロードキャストトラフィックを分散するために、より効率的であってもよいです。
Claim: No single encapsulation is optimal for all purposes. Therefore, where a link layer is utilized in disparate scenarios (such as both fixed and mobile deployments), multiple encapsulations are a practical requirement.
クレーム：いいえ、単一のカプセル化は、すべての目的のために最適ではありません。したがって、ここでリンク層（例えば、両方の固定およびモバイル展開など）の異種シナリオで利用され、複数のカプセル化は、実用的な要件です。
Discussion: "Architectural Principles of the Internet" [RFC1958], point 3.2, states:
ディスカッション：「インターネットの建築原則」[RFC1958]、ポイント3.2は、状態：
If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements.
同じことをやっていくつかの方法がある場合は、いずれかを選択。以前のデザイン、インターネットのコンテキスト内または他の場所では、成功した同じ問題を解決した場合ではないとの良好な技術的な理由がない限り、同じソリューションを選択します。同じプロトコル機能の複製はもちろんの改善を拒否するために、この引数を使用せずに、可能な限り避けるべきです。
Existing encapsulations have proven themselves capable of supporting disparate usage scenarios. For example, the Point-to-Point Protocol (PPP) has been utilized by wireless link layers such as General Packet Radio Service (GPRS), as well as in wired networks in applications such as "PPP over SONET/SDH" [RFC2615]. PPP can even support bridging, as described in "Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)" [RFC3518].
既存のカプセル化は、異種の利用シナリオをサポート自体は可能であることが判明しました。例えば、ポイントツーポイントプロトコル（PPP）は、汎用パケット無線サービス（GPRS）のような無線リンク層によって、ならびに「SONET / SDH上PPP」[RFC2615]などの用途に有線ネットワークで利用されています。 「ポイントツーポイントプロトコル（PPP）ブリッジ制御プロトコル（BCP）」[RFC3518]に記載されているようにPPPも、ブリッジングをサポートすることができます。
Similarly, Ethernet encapsulation has been used in wired networks as well as Wireless Local Area Networks (WLANs) such as IEEE 802.11 [IEEE-802.11.2003]. Ethernet can also support Virtual LANs (VLANs) and Quality of Service (QoS) [IEEE-802.1Q.2003].
同様に、イーサネットカプセル化は、IEEE 802.11 [IEEE-802.11.2003]などの有線ネットワーク、ならびにワイヤレスローカルエリアネットワーク（WLAN）に使用されています。イーサネットはまた、VLAN（仮想LAN）とサービス品質（QoS）の[IEEE-802.1Q.2003]をサポートすることができます。
Therefore, disparate usage scenarios can be addressed by choosing a single encapsulation, rather than multiple encapsulations. Where an existing encapsulation is suitable, this is preferable to creating a new encapsulation.
したがって、異なる使用シナリオではなく、複数のカプセル化よりも、単一のカプセル化を選択することによって対処することができます。既存のカプセル化が適している場合、これは新しいカプセル化を作成することが好ましいです。
Where encapsulations other than IP over Point-to-Point Protocol (PPP) [RFC1661], Ethernet, or IEEE 802 are supported, difficulties in operating system integration can lead to interoperability problems.
ポイントツーポイントプロトコル（PPP）を超えるIP以外のカプセル化は[RFC1661]、イーサネット、またはIEEE 802がサポートされている場合は、オペレーティングシステム統合の難しさは、相互運用性の問題につながることができます。
In order to take advantage of operating system support for IP encapsulation over PPP, Ethernet, or IEEE 802, it may be tempting for a driver supporting an alternative encapsulation to emulate PPP, Ethernet, or IEEE 802 support. Typically, PPP emulation requires that the driver implement PPP, enabling translation of PPP control and data frames to the equivalent native facilities. Similarly, Ethernet or IEEE 802 emulation typically requires that the driver implement Dynamic Host Configuration Protocol (DHCP) v4 or v6, Router Solicitation/Router Advertisement (RS/RA), Address Resolution Protocol (ARP), or IPv6 Neighbor Discovery (ND) in order to enable translation of these frames to and from native facilities.
PPP、イーサネット（登録商標）、またはIEEE 802上にIPカプセル化のためのオペレーティング・システム・サポートを利用するためには、PPP、イーサネット（登録商標）、またはIEEE 802サポートをエミュレートする別のカプセル化をサポートするドライバの魅力的であってもよいです。典型的には、PPPエミュレーションドライバが同等のネイティブ施設にPPP制御およびデータフレームの翻訳を可能にする、PPPを実装することを必要とします。同様に、イーサネットまたはIEEE 802エミュレーションは通常、ドライバが動的ホスト構成プロトコル（DHCP）V4またはV6、ルータ要請/ルータ通知（RS / RA）、解決プロトコル（ARP）、または中のIPv6近隣探索（ND）のアドレスを実装する必要がありますネイティブの施設へとから、これらのフレームの翻訳を可能にするため。
Where drivers are implemented in kernel mode, the work required to provide faithful emulation may be substantial. This creates the temptation to cut corners, potentially resulting in interoperability problems.
ドライバがカーネルモードで実装されている場合は、忠実なエミュレーションを提供するために必要な作業はかなりのかもしれません。これは、潜在的に相互運用性の問題が生じ、コーナーをカットする誘惑を作成します。
For example, it might be tempting for driver implementations to neglect IPv6 support. A driver emulating PPP might support only IP Control Protocol (IPCP), but not IPCPv6; a driver emulating Ethernet or IEEE 802 might support only DHCPv4 and ARP, but not DHCPv6, RS/RA, or ND. As a result, an IPv6 host connecting to a network supporting IPv6 might find itself unable to use IPv6 due to lack of driver support.
ドライバの実装は、IPv6のサポートを無視するために例えば、それは魅力的かもしれません。 PPPをエミュレートするドライバは、IP制御プロトコル（IPCP）ではなく、IPCPv6をサポートするかもしれません。イーサネットまたはIEEE 802をエミュレートするドライバは、DHCPv4とARPをサポートしていますが、ないのDHCPv6、RS / RA、またはNDかもしれません。その結果、IPv6をサポートするネットワークに接続しているIPv6ホストが原因ドライバのサポートの欠如にIPv6を使用して、それ自体ができないかもしれません。
Recommendation: Support a single existing encapsulation where possible. Emulation of PPP, Ethernet, or IEEE 802 on top of alternative encapsulations should be avoided.
推奨：可能な単一の既存のカプセル化をサポートしています。代替のカプセル化の上にPPP、イーサネット、またはIEEE 802のエミュレーションは避けるべきです。
There are a number of additional issues arising from use of multiple encapsulation methods, as hinted at in Section 1. We discuss each of these below.
複数のカプセル化メソッドの使用に起因する追加的な問題がいくつかあり、ほのめかしとして第1節では、以下のこれらのそれぞれについて説明します。
Link-layer protocols such as [IEEE-802.1A.1990] and [DIX] inherently support the ability to add support for a new packet type without modification to the link-layer protocol.
こうした[IEEE-802.1A.1990]および[DIX]などのリンク層プロトコルは、本質的に、リンク層プロトコルに変更することなく、新たなパケットタイプのサポートを追加する機能をサポートしています。
IEEE 802.16 [IEEE-802.16.2004] splits the Media Access Control (MAC) layer into a number of sublayers. For the uppermost of these, the standard defines the concept of a service-specific Convergence Sublayer (CS). The two underlying sublayers (the MAC Common Part Sublayer and the Security Sublayer) provide common services for all instantiations of the CS.
IEEE 802.16は、[IEEE-802.16.2004]メディアアクセス制御（MAC）の副層の数に層分離します。これらの最上部には、標準では、サービス固有コンバージェンス副層（CS）の概念を定義します。 2つの基礎となるサブ層（MAC共通部分副層とセキュリティサブレイヤ）はCSのすべてのインスタンス化のための一般的なサービスを提供しています。
While [IEEE-802.16.2004] defined support for the Asynchronous Transfer Mode (ATM) CS and the Packet CS for raw IPv4, raw IPv6, and Ethernet with a choice of six different classifiers, [IEEE-802.16e.2005] added support for raw and Ethernet-framed ROHC Enhanced Compressed RTP (ECRTP) compressed packets. As a result, [IEEE-802.16e.2005] defines the ATM CS and multiple versions of the Packet CS for the transmission of raw IPv4, raw IPv6, 802.3/Ethernet, 802.1Q VLAN, IPv4 over 802.3/Ethernet, IPv6 over 802.3/Ethernet, IPv4 over 802.1Q VLAN, IPv6 over 802.1Q VLAN, raw ROHC-compressed packets, raw ECRTP-compressed packets, ROHC-compressed packets over 802.3/Ethernet. and ECRTP-compressed packets over 802.3/Ethernet.
六つの異なる分類、[IEEE-802.16e.2005]の選択と生のIPv4、IPv6の生、およびイーサネットの非同期転送モード（ATM）CSとCSパケットのための[IEEE-802.16.2004]定義された支持体は、支持体を添加しながら生とイーサネットフレームROHCのための圧縮RTP（ECRTP）圧縮されたパケットを強化。結果として、[IEEE-802.16e.2005] 802.3上、802.3 /イーサネット上ATM CS生のIPv4の送信のためにパケットCSの複数のバージョン、生のIPv6、802.3 /イーサネット（登録商標）、802.1Q VLAN、IPv4のを規定のIPv6 /イーサネット、802.1Q VLAN上のIPv4、802.1Q VLAN上のIPv6、802.3 /イーサネット上の生ROHC圧縮パケット、生ECRTP圧縮パケット、ROHC圧縮パケット。 802.3 /イーサネット上とECRTP-圧縮パケット。
As noted in [Generic], [IEEE-802.16.2004] appears to imply that the standard will need to be modified to support new packet types:
[全般]で述べたように、[IEEE-802.16.2004]は、標準的には、新たなパケットタイプをサポートするように変更する必要があることを暗示して表示されます。
We are concerned that the 802.16 protocol cannot easily be extendable to transport new protocols over the 802.16 air interface. It would appear that a Convergence Sublayer is needed for every type of protocol transported over the 802.16 MAC. Every time a new protocol type needs to be transported over the 802.16 air interface, the 802.16 standard needs to be modified to define a new CS type. We need to have a generic Packet Convergence Sublayer that can support multi-protocols and which does not require further modification to the 802.16 standard to support new protocols. We believe that this was the original intention of the Packet CS. Furthermore, we believe it is difficult for the industry to agree on a set of CS's that all devices must implement to claim "compliance".
私たちは、802.16プロトコルが簡単に802.16エアインタフェースを介し新しいプロトコルを輸送するために拡張することができないことを懸念しています。コンバージェンス副層が802.16 MAC上で転送プロトコルの種類ごとに必要とされているように思われます。たびに新しいプロトコルタイプは802.16エアインタフェース、新しいCSタイプを定義するために修正する802.16規格のニーズ上で転送する必要があります。我々は、マルチプロトコルをサポートすることができますし、その新しいプロトコルをサポートするために、802.16規格にさらに変更を必要としない一般的なパケットコンバージェンスサブレイヤを持っている必要があります。これは、パケットCSの本来の意図だったと信じています。さらに、我々は業界のすべてのデバイスが「遵守」を主張するために実装しなければならないCSのセットに同意することは困難であると考えています。
The use of IP and/or upper-layer protocol specific classification and encapsulation methods, rather than a 'neutral' general purpose encapsulation, may give rise to a number of undesirable effects explored in the following subsections.
IPの使用及び/又は上位層プロトコル固有の分類およびカプセル化方法ではなく、「ニュートラル」汎用カプセル化は、以下のサブセクションで検討望ましくない影響の数を生じさせ得ます。
If the link layer does not provide a general purpose encapsulation method, deployment of new IP and/or upper-layer protocols will be dependent on deployment of the corresponding new encapsulation support in the link layer.
リンク層は、汎用のカプセル化方式を提供していない場合は、新しいIPおよび/または上位層プロトコルの展開は、リンク層における対応する新しいカプセル化支援の展開に依存することになります。
Even if a single encapsulation method is used, problems can still occur if demultiplexing of ARP, IPv4, IPv6, and any other protocols in use, is not supported at the link layer. While it is possible to demultiplex such packets based on the Version field (first four bits on the packet), this assumes that IPv4-only implementations will be able to properly handle IPv6 packets. As a result, a more robust design is to demultiplex protocols in the link layer, such as by assigning a different protocol type, as is done in IEEE 802 media where a Type of 0x0800 is used for IPv4, and 0x86DD for IPv6.
単一のカプセル化方式を用いてもARPはIPv4、IPv6、および使用中の任意の他のプロトコルの分離は、リンク層でサポートされていない場合、問題が依然として発生する可能性があります。バージョンフィールド（パケットの最初の4ビット）に基づいて、そのようなパケットを逆多重化することは可能であるが、これは、IPv4のみの実装が適切にIPv6パケットを処理することができるであろうことを前提としています。その結果、より堅牢な設計は、0x0800でのTypeがIPv4の、およびIPv6の0x86DDために使用されるIEEE 802培地中で行われているように、異なるプロトコルタイプを割り当てることによって、リンク層におけるプロトコルを逆多重化することです。
Recommendations: Link-layer protocols should enable network packets (IPv4, IPv6, ARP, etc.) to be demultiplexed in the link layer.
推奨事項：リンク層プロトコルは、リンク層で分離されるネットワークパケット（などのIPv4、IPv6の、ARPを）有効にする必要があります。
Within IEEE 802.16, the process by which frames are selected for transmission on a connection identifier (CID) is known as "classification". Fields in the Ethernet, IP, and UDP/TCP headers can be used for classification; for a particular CS, a defined subset of header fields may be applied for that purpose.
IEEE 802.16内で、フレームは、接続識別子（CID）上の送信のために選択されるプロセスを「分類」として知られています。イーサネットのフィールド、IP、およびUDP / TCPヘッダは、分類のために使用することができます。特定のCSのために、ヘッダフィールドの定義されたサブセットは、その目的のために適用することができます。
Utilizing IP and/or upper layer headers in link-layer classification will almost inevitably lead to interdependencies between link-layer and upper-layer specifications. Although this might appear to be desirable in terms of providing a highly specific (and hence interoperable) mapping between the capabilities provided by the link layer (e.g., quality-of-service support) and those that are needed by upper layers, this sort of capability is probably better provided by a more comprehensive service interface (Application Programming Interface) in conjunction with a single encapsulation mechanism.
リンク層の分類にIPおよび/または上位層ヘッダを利用することはほぼ必然的にリンク層と上位層の仕様間の相互依存性につながります。これは、リンク層により提供される機能との間の高度に特異的な（したがって、相互運用可能な）マッピングを提供するという点で望ましいように見えるかもしれないが（例えば、サービス品質サポート）上位層によって必要とされ、それらの、この種の機能は、おそらくより良い、単一のカプセル化メカニズムと併せて、より総合的なサービス・インターフェース（アプリケーション・プログラミング・インタフェース）により提供されます。
IPv6, in particular, provides an extensible header system. An upper-layer-specific classification scheme would still have to provide a degree of generality in order to cope with future extensions of IPv6 that might wish to make use of some of the link layer services already provided.
IPv6は、具体的には、拡張可能なヘッダ・システムを提供します。上層特定の分類体系はまだ、すでに提供されたリンクレイヤサービスの一部を利用することを望むかもしれないのIPv6の将来の拡張に対応するために一般性の程度を提供しなければなりません。
Recommendations: Upper-layer-specific classification schemes should be avoided.
推奨事項：上層特定の分類体系は避けるべきです。
If a classification scheme utilizing higher-layer headers proposes to inspect the contents of the packet being encapsulated (e.g., IEEE 802.16 IP CS mechanisms for determining the connection identifier (CID) to use to transmit a packet), the fields available for inspection may be limited if the packet is compressed or encrypted before passing to the link layer. This may prevent the link layer from utilizing existing compression mechanisms, such as Van Jacobson Compression [RFC1144], ROHC [RFC3095][RFC3759], Compressed RTP (CRTP) [RFC2508], Enhanced Compressed RTP (ECRTP) [RFC3545], or IP Header Compression [RFC2507].
上位層ヘッダを利用する分類スキームが（パケットを送信するために使用するコネクション識別子を決定するための、例えば、IEEE 802.16 IP CS機構（CID））カプセル化されたパケットの内容を検査することを提案した場合、検査のために利用可能なフィールドであってもよいですパケットがリンク層に渡す前に圧縮または暗号化されている場合は制限されています。これは、圧縮RTP（ECRTP）[RFC3545]、またはIP拡張バン・ジェイコブソン圧縮[RFC1144]、ROHC [RFC3095]、[RFC3759]、圧縮RTP（CRTP）[RFC2508]のような既存の圧縮機構を利用からリンク層を防止することができますヘッダ圧縮[RFC2507]。
Recommendations: Link-layer classification schemes should not rely on the contents of higher-layer headers.
推奨事項：リンク層の分類スキーム上位層ヘッダの内容に依存しないでください。
In situations where multiple encapsulation methods are operational and capable of carrying IP traffic, interoperability problems are possible in the absence of clear implementation guidelines. For example, there is no guarantee that other hosts on the link will support the same set of encapsulation methods, or that if they do, that their routing tables will result in identical preferences.
複数のカプセル化メソッドが動作してIPトラフィックを運ぶことができるしている状況では、相互運用性の問題は、明確な実装ガイドラインが存在しない場合に可能です。例えば、リンク上の他のホストがカプセル化方式の同じセットをサポートする、またはそのルーティングテーブルが同一の好みになりますことを、彼らがしなければそのという保証はありません。
In IEEE 802.16, the Subscriber Station (SS) indicates the Convergence Sublayers it supports to the Base Station (BS), which selects from the list one or more that it will support on the link. Therefore, it is possible for multiple CSes to be operational.
IEEE 802.16では、加入者局（SS）は、それがリンクをサポートすることがリスト一つ以上から選択する基地局（BS）にサポート収束サブレイヤを示しています。複数のCSEは、運用するためにしたがって、それは可能です。
Note that IEEE 802.16 does not provide multiple encapsulation methods for the same kind of data payload; it defines exactly one encapsulation scheme for each data payload. For example, there is one way to encapsulate a raw IPv4 packet into an IEEE 802.16 MAC frame, one encapsulation scheme for a raw IPv6 packet, etc. There is also one way to encapsulate an Ethernet frame, even when there are multiple possibilities for classifying an Ethernet frame for forwarding over a connection identifier (CID). Since support for multiple CSes enables IEEE 802.16 to encapsulate layer 2 frames as well as layer 3 packets, IP packets may be directly encapsulated in IEEE 802.16 MAC frames as well as framed with Ethernet headers in IEEE 802.16 MAC frames. Where CSes supporting both layer 2 frames as well as layer 3 packets are operational on the same link, a number of issues may arise, including:
IEEE 802.16は、データペイロードの同じ種類の複数のカプセル化方法を提供していないことに留意されたいです。それは正確に各データペイロードのための1つのカプセル化方式を定義します。例えば、分類するための複数の可能性がある場合でも、IEEE 802.16 MACフレームに生のIPv4パケットをカプセル化する一つの方法、生のIPv6パケットのための1つのカプセル化方式、等のイーサネットフレームをカプセル化する一つの方法でもあるあります接続識別子（CID）を介して転送するためのイーサネットフレーム。複数のカスタム検索エンジンのためのサポートは、IEEE 802.16は、レイヤ2フレームならびに層3つのパケットをカプセル化することができるため、IPパケットは、直接MACは、フレームだけでなく、IEEE 802.16 MACフレーム内のイーサネットヘッダとフレームIEEE 802.16内にカプセル化されてもよいです。レイヤ2つのフレームならびに層の両方をサポートするCSEは、3つのパケットが同じリンク上で動作している場合、多くの問題には、発生する可能性があります。
Use of Address Resolution Protocol (ARP) Where both IPv4 CS and Ethernet CS are operational on the same link, it may not be obvious how address resolution should be implemented. For example, should an ARP frame be encapsulated over the Ethernet CS, or should alternative mechanisms be used for address resolution, utilizing the IPv4 CS?
IPv4のCSとイーサネットCSの両方が同じリンク上で動作している、アドレス解決が実装されるべきであるかは明らかではないかもしれないアドレス解決プロトコル（ARP）を使用します。例えば、ARPフレームは、イーサネット（登録商標）CS上にカプセル化されるべきである、または代替メカニズムがIPv4のCSを利用して、アドレス解決のために使用すべきか？
Data Frame Encapsulation When sending an IP packet, which CS should be used? Where multiple encapsulations are operational, multiple connection identifiers (CIDs) will also be present. The issue can therefore be treated as a multi-homing problem, with each CID constituting its own interface. Since a given CID may have associated bandwidth or quality-of-service constraints, routing metrics could be adjusted to take this into account, allowing the routing layer to choose based on which CID (and encapsulation) appears more attractive.
データフレームのカプセル化CSを使用すべきIPパケットを、送信？複数のカプセル化が動作している場合、複数の接続識別子（CIDを）も存在するであろう。問題は、したがって、各CIDが独自のインターフェースを構成すると、マルチホーミング問題として扱うことができます。与えられたCIDは、帯域幅やサービス品質制約に関連している可能性があるため、ルーティングメトリックは、ルーティング層は、どのCID（およびカプセル化）に基づいて選択することができ、これを考慮に入れるように調整することができ、より魅力的な表示されます。
This could lead to interoperability problems or routing asymmetry. For example, consider the effects on IPv6 Neighbor Discovery:
これは、相互運用性の問題やルーティングの非対称性につながる可能性があります。たとえば、IPv6近隣探索への影響を考慮してください。
(a) If hosts choose to send IPv6 Neighbor Discovery traffic on different CSes, it is possible that a host sending an IPv6 Neighbor Discovery packet will not receive a reply, even though the target host is reachable over another CS.
ホストが異なるのCSE上のIPv6近隣探索トラフィックを送信することを選択した場合（a）に、IPv6近隣探索パケットを送信するホストは、ターゲットホストが別のCSオーバー到達可能であるにも関わらず、応答を受信しない可能性があります。
(b) Where hosts all support the same set of CSes, but have different routing preferences, it is possible for a host to send an IPv6 Neighbor Discovery packet over one CS and receive a reply over another CS.
ホストはすべてのCSEの同じセットをサポートするが、異なるルーティング選好を有する場合、ホスト一CS上のIPv6近隣探索パケットを送信し、別のCSオーバー応答を受信する（b）に、それが可能です。
Recommendations: Given these issues, it is strongly recommended that only a single kind of CS supporting a single encapsulation method should be usable on a particular link.
推奨事項：これらの問題を考えると、強く、単一のカプセル化方式をサポートしているCSの1種類のみが特定のリンク上で使用可能でなければならないことをお勧めします。
If a link-layer protocol provides multiple encapsulation methods, the services offered to the IP-layer and upper-layer protocols may differ qualitatively between the different encapsulation methods. For example, the 802.16 [IEEE-802.16.2004] link-layer protocol offers both 'native' encapsulation for raw IPv4 and IPv6 packets, and Ethernet encapsulation. In the raw case, the IP layer can be directly mapped to the quality-of-service (QoS) capabilities of the IEEE 802.16 transmission channels, whereas using the Ethernet encapsulation, an IP-over-Ethernet CS has to be deployed to circumvent the mapping of the IP QoS to the Ethernet header fields to avoid the limitations of Ethernet QoS. Consequently, the service offered to an application depends on the classification method employed and may be inconsistent between sessions. This may be confusing for the user and the application.
リンク層プロトコルは、複数のカプセル化方法を提供する場合、IP層と上位層のプロトコルに提供されるサービスは、異なるカプセル化法の間に質的に異なっていてもよいです。例えば、802.16 [IEEE-802.16.2004]リンク層プロトコルは、「ネイティブ」生IPv4およびIPv6パケットのカプセル化、およびイーサネットカプセル化の両方を提供します。生の場合には、IP層を直接イーサネットカプセル化を使用し、一方、IPオーバーイーサネットCSを回避するために展開されなければならない、IEEE 802.16伝送チャネルのサービス品質（QoS）機能にマッピングすることができますイーサネットのQoSの制限を回避するために、イーサネットヘッダフィールドにIPのQoSのマッピング。これにより、アプリケーションに提供されるサービスは、使用分類方法に依存し、セッションの間に矛盾することができます。これは、ユーザーとアプリケーションのために混乱を招くことがあります。
Recommendations: If multiple encapsulation methods for IP packets on a single link-layer technology are deemed to be necessary, care should be taken to match the services available between encapsulation methods as closely as possible.
推奨事項：単一のリンク層技術上のIPパケットのために複数のカプセル化方式が必要であるとみなされる場合は、ケアをできるだけ密接にカプセル化法の間に利用可能なサービスを一致させるために取られるべきです。
Support of multiple encapsulation methods results in additional implementation complexity. Lack of uniform encapsulation support also results in potential interoperability problems. To avoid interoperability issues, devices with limited resources may be required to implement multiple encapsulation mechanisms, which may not be practical.
複数のカプセル化メソッドのサポートが追加実装の複雑になります。均一なカプセル化のサポートの欠如はまた、潜在的な相互運用性の問題につながります。相互運用性の問題を回避するには、リソースの限られたデバイスが実用的ではないかもしれない複数のカプセル化メカニズムを実装するために必要になることがあります。
When encapsulation methods require hardware support, implementations may choose to support different encapsulation sets, resulting in market fragmentation. This can prevent users from benefiting from economies of scale, precluding some uses of the technology entirely.
カプセル化方法は、ハードウェアのサポートを必要とする場合、実装は、市場の断片化をもたらす、異なるカプセル化セットをサポートすることを選択することができます。これは、規模の経済の恩恵を受け、完全に技術のいくつかの使用を排除するからユーザーを防ぐことができます。
Recommendations: Choose a single encapsulation mechanism that is mandatory to implement for both sending and receiving, and make that encapsulation mechanism the default for sending.
勧告は：送信と受信の両方のために実装するために必須である、単一のカプセル化メカニズムを選択し、送信するため、そのカプセル化メカニズムをデフォルトにします。
The complexity of negotiation within ARP or IP can be reduced by performing encapsulation negotiation within the link layer.
ARPまたはIP内の交渉の複雑さは、リンク層の中にカプセル化のネゴシエーションを実行することにより減少させることができます。
However, unless the link layer allows the negotiation of the encapsulation between any two hosts, interoperability problems can still result if more than one encapsulation is possible on a given link. In general, a host cannot assume that all other hosts on a link support the same set of encapsulation methods, so that unless a link-layer protocol only supports point-to-point communication, negotiation of multiple potential encapsulation methods will be problematic. To avoid this problem, it is desirable for link-layer encapsulation negotiation to determine a single IP encapsulation, not merely to indicate which encapsulation methods are possible.
リンク層は、任意の2つのホスト間のカプセル化の交渉を許可しない限り、複数のカプセル化が与えられたリンク上で可能である場合には、相互運用性の問題がまだ発生することができます。リンク層プロトコルは、唯一のポイントツーポイント通信をサポートしていない限り、複数の潜在的なカプセル化方法のネゴシエーションが問題になるように、一般的に、ホストは、リンク上の他のすべてのホストがカプセル化メソッドの同じセットをサポートすると仮定することができません。この問題を回避するために、それは単なる方法が可能であるカプセル化を示すため、単一のIPカプセル化を決定するためのリンク層カプセル化交渉のために望ましいです。
Recommendations: Encapsulation negotiation is best handled in the link layer. In order to avoid dependencies on the data frame encapsulation mechanism, it is preferable for the negotiation to be carried out using management frames, if they are supported. If multiple encapsulations are required and negotiation is provided, then the negotiation should result in a single encapsulation method being negotiated on the link.
推奨事項：カプセル化交渉がリンク層で最もよく処理されます。ネゴシエーションが管理フレームを使用して実施されるため、それらがサポートされている場合、データフレームのカプセル化メカニズムへの依存を回避するためには、好ましいです。複数のカプセル化が必要とされており、交渉が提供されている場合、交渉はリンク上で交渉中の単一のカプセル化方法を生じるはずです。
Where a mobile node roams between base stations or to a fixed infrastructure, and the base stations and fixed infrastructure do not all support the same set of encapsulations, then it may be necessary to alter the encapsulation method, potentially in mid-conversation. Even if the change can be handled seamlessly at the link and IP layer so that applications are not affected, unless the services offered over the different encapsulations are equivalent (see Section 3.5), the service experienced by the application may change as the mobile node crosses boundaries. If the service is significantly different, it might even require 'in-flight' renegotiation, which most applications are not equipped to manage.
モバイルノードは、基地局間又は固定されたインフラストラクチャにローミングすると、基地局と固定インフラストラクチャがカプセル化の同じセットをサポートしていないすべてのない、潜在的に半ば会話において、カプセル化方式を変更するために必要であってもよいです。変化がリンク及びIPレイヤでシームレスに扱うことができる場合でも、アプリケーションは、異なるカプセル化にわたって提供されるサービスが同等でない限り、アプリケーションが経験するサービスは、モバイルノード交雑として変更することができる（3.5節を参照）、影響を受けないように境界線。サービスが大幅に異なる場合は、それもほとんどのアプリケーションを管理するために装備されていない「飛行中の」再ネゴシエーションを、必要な場合があります。
Recommendations: Ensure uniformity of the encapsulation set (preferably only a single encapsulation) within a given mobile domain, between mobile domains, and between mobile domains and fixed infrastructure. If a link layer protocol offers multiple encapsulation methods for IP packets, it is strongly recommended that only one of these encapsulation methods should be in use on any given link or within a single wireless transmission domain.
推奨：モバイルドメイン間、およびモバイルドメインと固定インフラとの間に、所定の移動領域内にカプセル化セット（好ましくは単一カプセル）の均一性を確保。リンク層プロトコルは、IPパケットのために複数のカプセル化方法を提供する場合、強く、これらのカプセル化方法の一つは、任意のリンク上または単一の無線伝送ドメイン内で使用中であることをお勧めします。
The use of multiple encapsulation methods does not appear to have significant security implications.
複数のカプセル化方法の使用は重大なセキュリティ上の意味を持つように表示されません。
An attacker might be able to utilize an encapsulation method that was not in normal use on a link to cause a denial-of-service attack, which would exhaust the processing resources of interfaces if packets utilizing this encapsulation were passed up the stack to any significant degree before being discarded.
このカプセル化を利用したパケットは、任意の重要なのスタックを渡された場合、攻撃者は、インタフェースの処理リソースを使い果たしてしまうDoS攻撃を引き起こすことがリンク上で、通常の使用ではありませんでしたカプセル化方式を利用することができるかもしれません破棄される前程度。
An attacker might be able to force a more cumbersome encapsulation method between two endpoints, even when a lighter weight one is available, hence forcing higher resource consumption on the link and within those endpoints, or causing fragmentation. Since IP fragments are more difficult to classify than non-fragments, this may result in packet loss or may even expose security vulnerabilities [WEP].
攻撃者は、したがって、リンク上で高いリソース消費を強制し、これらのエンドポイント内、または断片化を引き起こし、軽量化が使用可能な場合でも、2つのエンドポイント間でより面倒カプセル化方式を強制することができるかもしれません。 IPフラグメントは、非断片よりも分類することがより困難であるので、これは、パケット損失をもたらすことができる、あるいはセキュリティの脆弱性[WEP]を公開することがあります。
If different methods have different security properties, an attacker might be able to force a less secure method as an elevation path to get access to some other resource or data. Similarly, if one method is rarely used, that method is potentially more likely to have exploitable implementation bugs.
別の方法が異なるセキュリティプロパティを持っている場合、攻撃者は、いくつかの他のリソースやデータへのアクセスを取得するには標高パスとして安全性の低い方法を強制することができるかもしれません。一つの方法はほとんど使用されていない場合は同様に、その方法は、潜在的に悪用可能な実装のバグを持っている可能性が高いです。
Since lower-layer classification methods may need to inspect fields in the packet being encapsulated, this might deter the deployment of end-to-end security, which is undesirable. Where encryption of upper layer headers (e.g., IPsec tunnel mode) is required, this may obscure headers required for classification. As a result, it may be necessary for all encrypted traffic to flow over a single connection.
下層の分類方法は、カプセル化されたパケットのフィールドを検査する必要があるかもしれないので、これは望ましくないエンドツーエンドのセキュリティの展開を阻止する可能性があります。上位層ヘッダ（例えば、IPsecトンネルモード）の暗号化が要求される場合、これは、分類に必要なヘッダを不明瞭にすることができます。その結果、単一の接続を介して流れるように、すべて暗号化されたトラフィックのために必要な場合があります。
The use of multiple encapsulation methods on the same link is problematic, as discussed above.
上述したように、同じリンク上の複数のカプセル化方法の使用は、問題があります。
Although multiple IP encapsulation methods were defined on Ethernet cabling, recent implementations support only the Ethernet encapsulation of IPv4 defined in [RFC894]. In order to avoid a repeat of the experience with IPv4, for operation of IPv6 on IEEE 802.3 media, only the Ethernet encapsulation was defined in "A Method for the Transmission of IPv6 Packets over Ethernet Networks" [RFC1972], later updated in [RFC2464].
複数のIPカプセル化方法は、イーサネットケーブルで定義されたが、最近の実装は[RFC894]で定義されたIPv4のみイーサネットカプセル化をサポートします。 IPv4の経験の繰り返しを避けるために、IEEE 802.3メディア上でのIPv6の動作のために、唯一のイーサネットカプセル化は、後で[RFC2464に更新され、「イーサネット・ネットワーク上のIPv6パケットの伝送のための方法」[RFC1972]で定義されました]。
In addition to the recommendations given earlier, we give the following general recommendations to avoid problems resulting from use of multiple IP encapsulation methods:
先に与えられた勧告に加えて、我々は、複数のIPカプセル化方法の使用に起因する問題を回避するには、次の一般的な推奨事項を与えます：
When developing standards for encapsulating IP packets on a link-layer technology, it is desirable that only a single encapsulation method should be standardized for each link-layer technology.
リンク層の技術にIPパケットをカプセル化するための標準を開発するとき、単一のカプセル化方式は、各リンク層技術のために標準化されることが望ましいです。
If a link-layer protocol offers multiple encapsulation methods for IP packets, it is strongly recommended that only one of these encapsulation methods should be in use within any given link.
リンク層プロトコルは、IPパケットのために複数のカプセル化方法を提供する場合、強く、これらのカプセル化方法の一つだけが任意のリンク内で使用中であることをお勧めします。
Where multiple encapsulation methods are supported on a link, a single encapsulation should be mandatory to implement for send and receive.
複数のカプセル化方式は、リンク上でサポートされている場合は、単一のカプセル化は、送信のために実装し、受け取るために必須である必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[DIX] Digital Equipment Corporation, Intel Corporation, and Xerox Corporation, "The Ethernet -- A Local Area Network: Data Link Layer and Physical Layer (Version 2.0)", November 1982.
[DIX]ディジタルイクイップメント社、インテル社、およびゼロックス・コーポレーション、「イーサネット - ローカルエリアネットワーク：データリンク層と物理層（バージョン2.0）」、1982年11月。
[Generic] Wang, L. et al, "A Generic Packet Convergence Sublayer (GPCS) for Supporting Multiple Protocols over 802.16 Air Interface", Submission to IEEE 802.16g: CB0216g_05_025r4.pdf, November 2005, <http://www.ieee802.org/16/netman/contrib/ C80216g-05_025r4.pdf>.
[一般]ワング、L.ら、「802.16エア・インターフェースを介して複数のプロトコルをサポートするための汎用パケット収束サブレイヤ（GPCS）」、IEEEの802.16グラムに提出：CB0216g_05_025r4.pdf 2005年11月、<HTTP：//www.ieee802 .ORG / 16 / NETMANに/ contrib / C80216g-05_025r4.pdf>。
[IEEE-802.1A.1990] Institute of Electrical and Electronics Engineers, "Local Area Networks and Metropolitan Area Networks: Overview and Architecture of Network Standards", IEEE Standard 802.1A, 1990.
電気電子技術、の[IEEE-802.1A.1990]研究所「ローカルエリアネットワークとメトロポリタンエリアネットワーク：ネットワーク規格の概要とアーキテクチャ」、IEEE標準802.1A、1990。
[IEEE-802.1D.2004] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local area networks - Media access control (MAC) bridges", IEEE Standard 802.1D, 2004.
[IEEE-802.1D.2004]電気電子技術者協会、「情報技術 - 電気通信及びシステム間の情報交換 - ローカルエリアネットワーク - メディアアクセス制御（MAC）ブリッジ」、IEEE標準802.1D、2004。
[IEEE-802.1Q.2003] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q-2003, January 2003.
ローカルおよびメトロポリタンエリアネットワークの[IEEE-802.1Q.2003] IEEE規格：2003年1月、仮想ブリッジローカルエリアネットワーク、P802.1Q-2003用標準案。
[IEEE-802.3.2002] Institute of Electrical and Electronics Engineers, "Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", IEEE Standard 802.3, 2002.
電気電子技術、「衝突検出（CSMA / CD）アクセス方法および物理層仕様搬送波感知多重アクセス」の[IEEE-802.3.2002]研究所、IEEE規格802.3、2002。
[IEEE-802.11.2003] Institute of Electrical and Electronics Engineers, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 2003.
電気電子技術者の[IEEE-802.11.2003]研究所、 "無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様"、IEEE規格802.11、2003年。
[IEEE-802.16.2004] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", IEEE Standard 802.16-2004, October 2004.
電気電子技術者の[IEEE-802.16.2004]研究所、「情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク、パート16：固定ブロードバンド無線アクセスシステムのためのエアインタフェース」、IEEE標準802.16-2004、 2004年10月。
[IEEE-802.16e.2005] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", IEEE P802.16e, September 2005.
電気の[IEEE-802.16e.2005]研究所電子技術、「情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - パート16：固定およびモバイルブロードバンドワイヤレスアクセスシステム、物理のための改正のためのエアインタフェースと許諾バンドで固定結合され、モバイル運用のための媒体アクセス制御層」、IEEE P802.16eは本稿、2005年9月。
[PROBE] Hewlett Packard, "A Primer on HP Probe", http://www.hp.com/rnd/support/manuals/pdf/ hp_probe.pdf, July 1993.
[PROBE]ヒューレット・パッカード、 "HPプローブの入門"、http://www.hp.com/rnd/support/manuals/pdf/ hp_probe.pdf、1993年7月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC826]プラマー、D.、「イーサネットアドレス解決プロトコル：またはイーサネットハードウェア上での送信のためにイーサネット（登録商標）アドレスを48ビットに、ネットワーク・プロトコル・アドレス変換」、STD 37、RFC 826、1982年11月。
[RFC893] Leffler, S. and M. Karels, "Trailer encapsulations", RFC 893, April 1984.
[RFC893]レフラー、S.及びM. Karels、 "トレーラーカプセル化"、RFC 893、1984年4月。
[RFC894] Hornig, C., "A Standard for the Transmission of IP Datagrams over Ethernet Networks", STD 41, RFC 894, April 1984.
[RFC894] Hornig、C.、 "イーサネットネットワークの上のIPデータグラムの送信の規格"、STD 41、RFC 894、1984年4月。
[RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.
[RFC903]フィンレイソン、R.、マン、T.、モーグル、J.、およびM. Theimer、 "逆アドレス解決プロトコル"、STD 38、RFC 903、1984年6月。
[RFC948] Winston, I., "Two Methods for the Transmission of IP Datagrams over IEEE 802.3 Networks", RFC 948, June 1985.
[RFC948]ウィンストン、I.、 "IEEE 802.3ネットワーク上のIPデータグラムの送信の2つの方法"、RFC 948、1985年6月。
[RFC1010] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1010, May 1987.
[RFC1010]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、RFC 1010、1987年5月。
[RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, February 1988.
"IEEE 802ネットワーク上でIPデータグラムの送信の規格" [RFC1042]ポステル、J.、およびJ.レイノルズ、STD 43、RFC 1042、1988年2月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]ジェーコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、1990年2月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、 "インターネットの建築原則"、RFC 1958、1996年6月。
[RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[RFC1962]ランド、D.、 "PPP圧縮制御プロトコル（CCP）"、RFC 1962、1996年6月。
[RFC1972] Crawford, M., "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 1972, August 1996.
[RFC1972]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットの伝送のための方法"、RFC 1972、1996年8月。
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[RFC2472] Haskin、D.およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 2472、1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットのトランスミッション"、RFC 2464、1998年12月。
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] Degermark、M.、Nordgren、B.、およびS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508] Casner、S.とV. Jacobson氏、 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"、RFC 2508、1999年2月。
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[RFC2615] Malis、A.とW.シンプソン、 "SONET / SDH上のPPP"、RFC 2615、1999年6月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684]グロスマン、D.とJ. Heinanen、RFC 2684、1999年9月 "ATMアダプテーションレイヤ5以上のマルチプロトコルカプセル化"。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
[RFC3095]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.ハンヌ、H.、ジョンソン、LE。、Hakeberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust
Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP, and uncompressed", RFC
3095, July 2001.
[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[RFC3241]ボルマン、C.、 "PPPオーバーロバストヘッダ圧縮（ROHC）"、RFC 3241、2002年4月。
[RFC3518] Higashiyama, M., Baker, F., and T. Liao, "Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)", RFC 3518, April 2003.
[RFC3518]東山、M.、ベイカー、F.、およびT.リャオ、 "ポイントツーポイントプロトコル（PPP）ブリッジ制御プロトコル（BCP）"、RFC 3518、2003年4月。
[RFC3544] Koren, T., Casner, S., and C. Bormann, "IP Header Compression over PPP", RFC 3544, July 2003.
[RFC3544]コレン、T.、Casner、S.、およびC.ボルマン、 "PPP上のIPヘッダー圧縮"、RFC 3544、2003年7月。
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003.
[RFC3545]コレン、T.、Casner、S.、Geevarghese、J.、トンプソン、B.、およびP.ルディ、RFC 3545 "高遅延、パケット損失、および並べ替えとリンクするための圧縮RTP（CRTP）を強化"、 2003年7月。
[RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[RFC3759]ヨンソン、L-E、 "ロバストヘッダ圧縮（ROHC）：用語とチャンネルマッピングの例"。、RFC 3759、2004年4月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541]クリステンセン、M.、キンボール、K.、およびF. Solensky、RFC 4541、2006年5月、 "インターネットグループ管理プロトコル（IGMP）とMulticast Listener Discovery（MLD）スヌーピングスイッチの考慮事項"。
[WEP] Bittau, A., Handley, M., and J. Lackey, "The Final Nail in WEP's Coffin", Proceedings of the 2006 IEEE Symposium on Security and Privacy, pp. 386-400.
[WEP] Bittau、A.、ハンドリー、M.、およびJ.ラッキー、セキュリティとプライバシー上の2006 IEEEシンポジウム「WEPの棺で最後の釘」、頁386から400まで。
The authors would like to acknowledge Jeff Mandin, Bob Hinden, Jari Arkko, Max Riegel, Alfred Hoenes, and Phil Roberts for contributions to this document.
作者はこのドキュメントへの貢献のためにジェフMandin、ボブHindenとヤリArkko、マックスリーゲル、アルフレッドHoenes、フィル・ロバーツを確認したいと思います。
Appendix A. IAB Members at the Time of This Writing
この記事の執筆時点では、付録A. IABメンバー
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
バーナードAbobaロア・アンダーソン、ブライアン・カーペンターレスリーDaigle氏エルウィン・デイビスケビン秋オラフKolkmanカーティスLindqvistデビッド・マイヤーデヴィッドオランエリックレスコラデーブターラーLixiaチャン
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329
メールアドレス：bernarda@microsoft.com電話：+1 425 706 6605ファックス：+1 425 936 7329
Elwyn B. Davies Consultant Soham, Cambs UK
エルウィンB.デイヴィスコンサルタントソーハム、Cambsの英国
EMail: elwynd@dial.pipex.com Phone: +44 7889 488 335
メールアドレス：elwynd@dial.pipex.com電話：+44 7889 488 335
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052
デーブターラーマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
EMail: dthaler@microsoft.com Phone: +1 425 703 8835
メールアドレス：dthaler@microsoft.com電話：+1 425 703 8835
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、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 http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
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 ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。