[要約] 要約：RFC 4840は、複数のカプセル化方法がネットワークのパフォーマンスやセキュリティに悪影響を与える可能性があることを指摘している。 目的：このRFCの目的は、ネットワークデザイナーや開発者に対して、単一のカプセル化方法の使用を推奨し、複数のカプセル化方法の使用を避けることの重要性を認識させることである。
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）The IETF Trust（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）カプセル化方法のみをサポートしていますが、これは必ずしもそうではありません。たとえば、同じケーブルでは、「イーサネットネットワークを介したIPデータグラムの送信の標準」[RFC894]、IEEE 802.2/802.3 LLC [IEEE- [IEEE-]で定義されているイーサネット[DIX]カプセル化を使用してIPv4パケットをカプセル化することが可能です。802.3.2002]「IEEE 802.3ネットワークを介したIPデータグラムの送信の2つの方法」[RFC948]、またはIEEE 802 [IEEE-802.1A.1990]で定義された「IPの伝達の基準」で定義された「IEEE-802.1A.1990]で定義されたタイプ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]で定義されている分類は、MEDIOM ACCESS CONTROL（MAC）Service Data Unit（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ピアの間の単方向マッピングです。各輸送接続には、Ciphersuiteやサービス品質などの特性を示す特定の関連パラメーターセットがあります。
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.
同じリンク上の複数のカプセル化方法の基本的な問題は、[RFC1042]と「インターネットホストの要件 - 通信層」[RFC1122]で説明されています。このセクションでは、これらのドキュメントに明確にされた懸念を要約し、カプセル化交渉やルーターの使用など、問題を軽減するために提案されたアプローチの限界についても説明します。
[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.
ほとんどのコンピューターは1つのタイプのリンクプロトコルのみを使用して読み取りおよび送信すると想定する必要があるため、そのような環境（両方のリンクプロトコルを持つネットワーク）が必要な場合、IPゲートウェイは2つの異なるものがあるかのように使用することをお勧めしますネットワーク。
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 Octet 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イーサネットケーブルに接続されたすべてのインターネットホスト：
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.
sendと受信の両方に実装するためにイーサネットのカプセル化を義務付け、送信のデフォルトを実装することにより、[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）および宛先サービスアクセスポイント（DSAP）フィールドで6を利用しています。IEEE 802.2ヘッダー。ただし、SSAPフィールドとDSAPフィールドはそれぞれ単一のオクテットであり、IP、ARP [RFC826]、およびRARP [RFC903]のEtherType値は1500を超えるため、これらの値はSSAPおよびDSAPフィールドで表現することはできません。その結果、[RFC948]で説明されているカプセル化は、ARPやRARPなどの異なる倫理を必要とするプロトコルをサポートせず、実装には通常、プローブ[プローブ]プロトコルなどのARPの代替のサポートが含まれていました。ARP、RARP、およびその他の個別の倫理を利用したその他のIPプロトコルのサポートは、[RFC1042]で対処され、[RFC948]が廃止されました。[RFC1042]は、ETHERTYPEフィールドのサポートを含め、SSAPおよびDSAPフィールドが170に設定された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ネットワークでDOD-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標準のいくつかの進化と、追加のDOD-IP関連プロトコル（IEEE 802ネットワークのアドレス解像度プロトコル（ARP）などの標準的な方法を提供する必要性があるため、次の新しいポリシーが確立されます。古いポリシーを交換します（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).
新しいポリシーは、インターネットコミュニティがIEEE 802.2のカプセル化を802.3、802.4、および802.5ネットワークで使用することです。スナップを組織コードで使用して、次の16ビットがEtherTypeコード（IP = 2048（0800 HEX））を指定していることを示しています。イーサネット数の関心を参照してください）。
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ヘッダーとスナップヘッダーの全長は8オクテットで、802.2プロトコルオーバーヘッドが素晴らしい境界で出てきます。
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は170です。IEEEは、小さなエンディアンビット伝送順序で物事について話すのが好きで、この値を01010101として指定します。インターネット仕様で使用されるように、これは10101010バイナリ、またはAA HEX、または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のサポートの欠如により、追加の相互運用性と実装の問題が発生しました。たとえば、[RFC948]のARPのサポートの欠如は、[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 802 [RFC1042]カプセル（IPの4つの潜在的なカプセルの作成）に適用された可能性がありますが、実際には、トレーラーのカプセル化はイーサネットのみがサポートされていました。トレーラーのカプセル化のIPパケットを[RFC894]カプセル化と区別できるようにするために、別のEtherTypeが使用されました。[RFC948]カプセル化はEtherTypeフィールド（またはARP）をサポートしていなかったため、このメカニズムは[RFC948]の実装では使用できませんでした。
[RFC1122], Section 2.3.1, described the issues with trailer encapsulation:
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 Exchangeの要求または応答ホストのいずれかが、トレーラーを受信することを要求する場合があります。
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パケットの継続的な交換を回避するように設計されています。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に依存するため、リンク上のすべてのホストが同じブロードキャストドメイン内にある場合にのみ使用できます。すべてのホストが標準イーサネットカプセル化[RFC894]でARPパケットの送信と受信をサポートしているため、イーサネットとIEEE 802カプセルの交渉は必要ありませんでした。トレーラーのカプセル化をサポートするホストが1つ以上のIEEE 802フレーミングメカニズムをサポートしていた場合、交渉はさらに複雑になりました。たとえば、[RFC948]の実装はEtherTypeフィールドまたは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）、およびBridging PDU（0x0031）に割り当てられたPPPデータリンクレイヤー（DLL）プロトコル番号に加えて、次のコードポイントが割り当てられています。
o two for RObust Header Compression (ROHC) [RFC3095]: ROHC small-CID (0x0003) and ROHC large-CID (0x0005)
o 堅牢なヘッダー圧縮用2つ（ROHC）[RFC3095]：ROHC Small-CID（0x0003）とROHC Lage-CID（0x0005）
o two for Van Jacobson compression [RFC1144]: Compressed TCP/IP (0x002d) and Uncompressed TCP/IP (002f)
o Van Jacobson圧縮の2つ[RFC1144]：圧縮TCP/IP（0x002D）と非圧縮TCP/IP（002F）
o one for IPv6 Header Compression [RFC2507]: (0x004f)
o IPv6ヘッダー圧縮の1つ[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)
o 9つのRTP IPヘッダー圧縮[RFC3544]：フルヘッダー（0x0061）、圧縮TCP（0x0063）、圧縮非TCP（0x0065）、UDP 8（0x0067）、RTP 8（0x0069）、圧縮TCP No（0x2063）、Conputed TCP nota（0x0063）、圧縮状態（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]で定義されているIEEE 802フレームのカプセル化と、IPv4およびIPv6 [RFC2472]パケットの両方をサポートできますが、実際には、複数のカプセル化メカニズムは同じリンクで動作しません。同様に、通常、リンクで使用するために単一の圧縮スキームのみが交渉されます。
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.
複数のカプセル化方法を使用してホスト間の通信を有効にするためのスイッチまたはルーターの使用は、万能薬ではありません。各カプセル化に個別のユニキャストプレフィックスが使用される場合、カプセル化の選択をルーティングテーブルから決定できます。各カプセル化方法に同じユニキャストプレフィックスが使用されている場合、各宛先ホストの状態を維持する必要があります。ただし、これは、異なるカプセルを使用してホストが同じAnycastアドレスに応答する状況では機能しない場合があります。
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.
クレーム：複数のカプセル化方法により、効率が向上します。たとえば、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]は、データ圧縮メカニズムの交渉を可能にし、「PPPを超える堅牢なヘッダー圧縮（RFC3241」および「PPP上のIPヘッダー圧縮」[RFC3544] [RFC3544]ヘッダー圧縮の有効なネゴシエーションの「IPヘッダー圧縮」[RFC3544]、インターネットレイヤーの認識なし。フレームのコンテンツに基づいて、以前の制御メッセージまたはデータフレームに基づいて、以前の状態に基づいて、任意のフレームを「減圧」できます。圧縮の使用は、高層で問題を導入することなく、効率の問題を解決する良い方法です。
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が高すぎる場合、IP Path MTU発見を使用して正しい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.
説明：使用されたカプセル化に関係なく、マルチキャスト（IPv4/IPv6）またはブロードキャスト（IPv4）に送信されるIPパケットは、すべての潜在的なオンリンクレシーバーに到達する必要があります。代替カプセルの使用は、この要件を削除することはできませんが、どのように満たすことができるかにはかなりの柔軟性があります。非ブロードキャストマルチアクセス（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では、ステーション（STA）からアクセスポイント（AP）に送信されたマルチキャスト/ブロードキャストトラフィックは常にユニキャストとして送信され、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およびMLDスヌーピングスイッチの考慮事項」[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.11.2003]では、クライアントステーション（STA）からアクセスポイント（AP）へのマルチキャスト/ブロードキャストトラフィックは、リンク層ユニキャストを介して送信されます。
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.
同じことをする方法がいくつかある場合は、1つを選択してください。インターネットのコンテキストまたは他の場所で以前の設計が同じ問題を正常に解決した場合、適切な技術的理由がない限り、同じソリューションを選択します。もちろん、この引数を使用して改善を拒否することなく、同じプロトコル機能の複製を可能な限り回避する必要があります。
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は、「ポイントツーポイントプロトコル（PPP）制御プロトコル（BCP）」[RFC3518]で説明されているように、ブリッジングをサポートすることもできます。
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）で使用されています。イーサネットは、仮想LAN（VLAN）およびサービス品質（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）[RFC1661]、イーサネット、またはIEEE 802を超えるIP以外のカプセルがサポートされている場合、オペレーティングシステムの統合の難しさは相互運用性の問題につながる可能性があります。
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 Common Part SublayerとSecurity Sublayer）は、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.16.2004]は、RAW IPv4、RAW IPv6、およびイーサネットの非同期転送モード（ATM）CSおよびパケットCSのサポートを定義しました。生およびイーサネットフレームのROHCの場合、圧縮RTP（ECRTP）圧縮パケットを強化します。その結果、[IEEE-802.16E.2005]は、RAW IPv4、RAW IPv6、802.3/Ethernet、802.1Q VLAN、802.3/Ethernet、IPv4、IPv4、IPv4を超えるIPv4、802.3/Ethernet、IPv4の送信用のATM CSおよび複数のバージョンのパケットCSを定義します。/イーサネット、802.1Q VLANを超えるIPv4、802.1Q VLANを超えるIPv6、生のROHC圧縮パケット、生のECRTP圧縮パケット、802.3/イーサネットを超える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:
[generic]で述べたように、[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エアインターフェイスで輸送する必要がある場合は、802.16の標準を変更して、新しいCSタイプを定義する必要があります。マルチプロトコルをサポートできる一般的なパケットコンバージェンスサブレイヤーが必要であり、新しいプロトコルをサポートするために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、および使用中のその他のプロトコルの非gultiplexingがリンクレイヤーではサポートされていない場合、問題が発生する可能性があります。バージョンフィールド（パケットの最初の4ビット）に基づいてそのようなパケットを反映することは可能ですが、これはIPv4のみの実装がIPv6パケットを適切に処理できると仮定します。その結果、より堅牢な設計は、IPV4にタイプ0x0800が使用されているIEEE 802メディアで、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）を決定するためのメカニズム）リンクレイヤーに渡す前にパケットが圧縮または暗号化されている場合は制限されています。これにより、リンク層がヴァンジェイコブソン圧縮[RFC1144]、ROHC [RFC3095] [RFC3759]、圧縮RTP（CRTP）[RFC2508]などの既存の圧縮メカニズムを利用することを妨げる可能性があり、圧縮RTP（ECRTP）[RFC3545]またはIPの圧縮RTP（ECRTP）またはIPヘッダー圧縮[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）にサポートする収束サブレイヤーを示しています。これは、リストからリンクでサポートする1つ以上を選択します。したがって、複数の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つのカプセル化スキームを定義します。たとえば、生のIPv4パケットをIEEE 802.16 Macフレームにカプセル化する方法は1つあります。1つのカプセル化スキームの生のIPv6パケットなど。接続識別子（CID）を転送するためのイーサネットフレーム。複数のCSEのサポートにより、IEEE 802.16がレイヤー2フレームとレイヤー3パケットをカプセル化できるようにするため、IPパケットはIEEE 802.16 Macフレームで直接カプセル化され、IEEE 802.16 Macフレームのイーサネットヘッダーに囲まれています。レイヤー2フレームとレイヤー3パケットの両方をサポートするCSEが同じリンクで動作している場合、以下を含む多くの問題が発生する場合があります。
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.
データフレームのカプセル化IPパケットを送信するとき、どのCSを使用する必要がありますか？複数のカプセルが動作する場合、複数の接続識別子（CID）も存在します。したがって、この問題は、各CIDが独自のインターフェイスを構成するため、多競合の問題として扱うことができます。特定のCIDには関連する帯域幅またはサービス品質の制約がある可能性があるため、ルーティングメトリックを調整してこれを考慮して、どのCID（およびカプセル化）がより魅力的に見えるかに基づいてルーティングレイヤーを選択できるようにします。
This could lead to interoperability problems or routing asymmetry. For example, consider the effects on IPv6 Neighbor Discovery:
これにより、相互運用性の問題やルーティングの非対称性につながる可能性があります。たとえば、IPv6 Neighbor Discoveryへの影響を考慮してください。
(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.
(a) ホストがさまざまなCSEでIPv6 Neighbor Discoveryトラフィックを送信することを選択した場合、ターゲットホストが別のCSに到達可能である場合でも、IPv6 Neighbor Discoveryパケットを送信するホストが返信を受け取らない可能性があります。
(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.
(b) ホストがすべて同じセットのCSEをサポートするが、ルーティングの好みが異なる場合、ホストが1つのCSにIPv6 Neighbor Discoveryパケットを送信し、別のCSを介して返信を受信することができます。
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のみを使用できるようにすることを強くお勧めします。
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レイヤーはIEEE 802.16伝送チャネルのサービス品質（QOS）機能に直接マッピングできますが、イーサネットのカプセル化を使用すると、IPオーバーエテルネットCSを展開するために展開する必要があります。イーサネット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.
モバイルノードがベースステーション間または固定インフラストラクチャの間を歩き回る場合、およびベースステーションと固定インフラストラクチャがすべて同じカプセルのセットをサポートするわけではない場合、潜在的に中間の変換でカプセル化方法を変更する必要がある場合があります。さまざまなカプセルで提供されているサービスが同等でない限り（セクション3.5を参照）場合を除き、変更をリンクとIPレイヤーでシームレスに処理できる場合でも、アプリケーションが影響を受けないようにしてください。境界。サービスが大幅に異なる場合、ほとんどのアプリケーションが管理する装備が装備されていない「飛行中の」再交渉が必要になる場合さえあります。
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.
攻撃者は、リンクで正常に使用されていなかったカプセル化方法を利用してサービス拒否攻撃を引き起こす可能性があります。廃棄される前の学位。
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.
さまざまなメソッドにセキュリティプロパティが異なる場合、攻撃者は、他のリソースまたはデータにアクセスするための標高パスとして、より安全でないメソッドを強制することができます。同様に、1つの方法がめったに使用されない場合、その方法は、実装可能な実装バグを持つ可能性が高い可能性があります。
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の操作のために、イーサネットカプセル化のみが「イーサネットネットワークを介したIPv6パケットの送信方法」[RFC1972]で定義され、後に[RFC24644で更新されました。]。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Digital Equipment Corporation、Intel Corporation、およびXerox Corporation、「イーサネット - ローカルエリアネットワーク：データリンク層と物理レイヤー（バージョン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>.
[Generic] Wang、L。et al、「802.16エアインターフェイスを超えた複数のプロトコルをサポートするための一般的なパケット収束サブレイヤー（GPCS）」、IEEE 802.16Gへの提出：CB0216G_05_025R4.PDF、2005年11月、<http：///ww.ww..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 Standard 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基準：仮想ブリッジ型ローカルエリアネットワークのドラフト標準、P802.1Q-2003、2003年1月。
[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.
[IEEE-802.3.2002]電気およびエレクトロニクスエンジニアの研究所、「キャリアは衝突検出（CSMA/CD）アクセス方法と物理層の仕様による複数のアクセスを感知します」、IEEE Standard 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 Standard 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 Standard 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.
[プローブ] Hewlett Packard、「HP Probeのプライマー」、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] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレス」、STD 37、RFC 826、1982年11月。
[RFC893] Leffler, S. and M. Karels, "Trailer encapsulations", RFC 893, April 1984.
[RFC893] Leffler、S。およびM. Karels、「Trailer Encapsulations」、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] Finlayson、R.、Mann、T.、Mogul、J。、およびM. Theimer、「A Reverse Address Resolution Protocol」、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] Winston、I。、「IEEE 802.3ネットワークを介したIPデータグラムの送信のための2つの方法」、RFC 948、1985年6月。
[RFC1010] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1010, May 1987.
[RFC1010] Reynolds、J。およびJ. Postel、「割り当てられた番号」、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.
[RFC1042] Postel、J。およびJ. Reynolds、「IEEE 802ネットワークを介したIPデータグラムの送信の標準」、STD 43、RFC 1042、1988年2月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144] Jacobson、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] Rand、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] Crawford、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. Allen、「PPP上のIPバージョン6」、RFC 2472、1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464] Crawford、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. Pink、「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. Simpson、「PPP Over Sonet/SDH」、RFC 2615、1999年6月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684] Grossman、D。およびJ. Heinanen、「ATM適応層5に対するマルチプロトコルカプセル化」、RFC 2684、1999年9月。
[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., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[RFC3241] Bormann、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] Koren、T.、Casner、S。、およびC. Bormann、「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] Koren、T.、Casner、S.、Geevarghese、J.、Thompson、B。、およびP. Ruddy、「高い遅延、パケット損失、再注文を伴うリンクのための圧縮RTP（CRTP）の強化」、RFC 3545、2003年7月。
[RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[RFC3759] Jonsson、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] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、2006年5月。
[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.、Handley、M。、およびJ. Lackey、「WEP's Coffinの最後の爪」、セキュリティとプライバシーに関する2006年のIEEEシンポジウムの議事録、pp。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.
著者は、この文書への貢献について、ジェフ・マンディン、ボブ・ヒンデン、ジャリ・アークコ、マックス・リーゲル、アルフレッド・ホーネス、フィル・ロバーツに感謝します。
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
バーナード・アボバ・ロア・アンダーソン・ブライアン・カーペンター・レスリー・デイグル・エルウィン・デイヴィス・ケビン・フォール・フォール・オラフ・コルクマン・カルティス・リンドクヴィスト
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Elwyn B. Davies Consultant Soham, Cambs UK
Elwyn B. DaviesコンサルタントSoham、Cambs UK
EMail: elwynd@dial.pipex.com
Phone: +44 7889 488 335
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052
Dave Thaler Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。