RFC4840 日本語訳
4840 Multiple Encapsulation Methods Considered Harmful. B. Aboba, Ed.,E. Davies, D. Thaler. April 2007. (Format: TXT=65287 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Aboba, Ed.
Request for Comments: 4840 E. Davies
Category: Informational D. Thaler
Internet Architecture Board
April 2007
ワーキンググループB.Aboba、エドをネットワークでつないでください。コメントのために以下を要求してください。 4840年のE.デイヴィースカテゴリ: 情報のD.ターレルインターネット・アーキテクチャ委員会2007年4月
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).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods.
このドキュメントは複数のインターネットプロトコルがカプセル化メソッドであるとサポートするリンク層プロトコルから起こる建築していて操作上の問題について説明します。
Aboba, et al. Informational [Page 1] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[1ページ]RFC4840倍数カプセル化メソッド
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
1. 序論…3 1.1. 用語…3 1.2. イーサネット経験…4 1.2.1. IEEE802.2/802.3LLCタイプ1カプセル化…6 1.2.2. トレーラカプセル化…7 1.3. ppp経験…10 1.4. 潜在的緩和…10 2. 複数のカプセル化のための議論の評価…11 2.1. 効率…11 2.2. マルチキャスト/放送…12 2.3. 複数の用途…13 3. 追加問題…15 3.1. 一般性…15 3.2. 相互依存を層にしてください…16 3.3. 有効搭載量コンテンツの点検…17 3.4. 相互運用性指導…17 3.5. 一貫性を修理してください…19 3.6. 実装の複雑さ…19 3.7. 交渉…19 3.8. ローミング…20 4. セキュリティ問題…20 5. 結論…21 6. 参照…22 6.1. 標準の参照…22 6.2. 有益な参照…22 7. 承認…25 この書くこと時点の付録A.IABメンバー…26
Aboba, et al. Informational [Page 2] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[2ページ]RFC4840倍数カプセル化メソッド
1. Introduction
1. 序論
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)がカプセル化メソッドであると通常サポートしますが、これはいつもそうであるというわけではありません。 例えば、同じケーブルでは、IPv4パケットをカプセルに入れるのは、「イーサネットネットワークの上のIPデータグラムの送信の規格」[RFC894]、「IEEE802.3ネットワークの上のIPデータグラムの送信のための2つのメソッド」[RFC948]で定義されたIEEE802.2/802.3LLC[IEEE-802.3.2002]タイプ1カプセル化、または「IEEE802ネットワークの上のIPデータグラムの送信の規格」[RFC1042]で定義されたIEEE802[IEEE-802.1A.1990]カプセル化で定義されるようにイーサネット[DIX]カプセル化を使用することで可能です。 歴史的に、さらなるカプセル化メソッドは「トレーラカプセル化」[RFC893]における指定されるとしてのいくつかのイーサネットシステムの上で使用されました。 また、同様に、ATM(例えば、[RFC2684]を見る)、Pointからポイントへのプロトコル(PPP)[RFC1661]、およびIEEE802.16[IEEE-802.16e.2005]は、複数のカプセル化がメカニズムであるとサポートします。
1.1. Terminology
1.1. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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](Medium Access Control(MAC)サービスData Unit(SDU)がMAC同輩の間のトランスミッションのための特定の輸送接続に写像されるプロセス)で定義された分類As。
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]接続識別子における接続Identifier(CID)は輸送接続を特定する16ビットの値か関連管理接続のアップリンク(UL)/ダウンリンク(DL)組です。 接続は基地局(BS)と加入者設備(SS)のMAC同輩の間の単方向のマッピングです。 それぞれの輸送接続には、サービスのciphersuiteや品質などの特性を示す特定のセットの関連パラメタがあります。
Aboba, et al. Informational [Page 3] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[3ページ]RFC4840倍数カプセル化メソッド
Link
A communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately below
IP.
A通信機器かノードがリンクレイヤで交信できる媒体をリンクしてください、すなわち、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.
概念的なLayerが層にするリンクのコントロールを維持するのに原因となるコントロールか処理論理のリンク。 リンクレイヤ機能は、より高い層の論理とリンクとのインタフェースを提供します。 リンクレイヤはIPのすぐ下の層です。
1.2. Ethernet Experience
1.2. イーサネット経験
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]は同じ物理ケーブルにおけるイーサネットとIEEE802.3のカプセル化の同時性の使用から生じる潜在的問題について説明しました:
Interoperation with Ethernet
イーサネットがあるInteroperation
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.
同じ物理ケーブルの上でIEEE802.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.
802.3ネットワークが1492年の八重奏IPデータグラムだけを許容するので、MTUと共にイーサネットのためのMTUが1500年の八重奏IPデータグラムを許容することに注意してください。
Aboba, et al. Informational [Page 4] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[4ページ]RFC4840倍数カプセル化メソッド
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 SHOULDはRFC-1042パケットを受けることができて、RFC-894パケットと共に混ぜました。 そして
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]は、イーサネットが支配的なカプセル化であると認めました、潜在的相互運用性問題を避けて。
Aboba, et al. Informational [Page 5] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[5ページ]RFC4840倍数カプセル化メソッド
1.2.1. IEEE 802.2/802.3 LLC Type 1 Encapsulation
1.2.1. IEEE802.2/802.3LLCタイプ1カプセル化
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]:
IEEE802.2ヘッダーのSource Service Access Point(SSAP)とDestination Service Access Point(DSAP)分野で6を利用することでの中のIEEE802カプセル化[RFC1042]、IEEE802.2/802.3LLC Typeの規格化[RFC948]1つのカプセル化が指定された前。 しかしながら、SSAPとDSAP分野が唯一のaただ一つの八重奏であり、それぞれのIP、ARP[RFC826]、およびRARP[RFC903]のためのEthertype値が1500以上であるので、SSAPとDSAP分野にこれらの値を表すことができません。 その結果、[RFC948]で説明されたカプセル化はARPかRARPなどの異なったEthertypesを必要とするプロトコルをサポートしませんでした、そして、実装はProbe[PROBE]プロトコルなどのARPへの代替手段のサポートを通常含んでいました。 アルプ、RARP、および異なったEthertypesを利用する他のIPプロトコルのサポートは[RFC1042]で扱われました。(それは、[RFC948]を時代遅れにしました)。 [RFC1042]はSSAPと共にIEEE802.2Logical Link Control(LLC)のSub-ネットワークAccessプロトコル(SNAP)フォームを利用しました、そして、DSAP分野は170にセットしました、Ethertype分野のサポートを含んでいて。 「規定番号」[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 Vendors Workshop(1986年8月)の間に保持された「IEEE802ネットワークとARP」の臨時の特別なセッションのときに、DoD-IPデータグラムと他のIPの関連するプロトコルを802のネットワークに送る一貫した方法へのアプローチは開発されました。
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をする標準の方法に備える必要性はプロトコルを関係づけました。どれが古い方針を置き換えるだろうか。(Address Resolutionプロトコル(ARP)としてIEEE802ネットワークであれほどです、以下の新しい政策が確立される、(RFC960とRFC948[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ビットがEtherTypeコードを指定するのを示しているSNAPを使用することによって802.3、802.4、および802.5のネットワークのIEEE802.2カプセル化を使用する(IPが2048(0800年の十六進法)と等しいところでは、Interestのイーサネット民数記を見てください)ことです。
Aboba, et al. Informational [Page 6] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[6ページ]RFC4840倍数カプセル化メソッド
Header
...--------+--------+--------+
MAC Header| Length | 802.{3/4/5} MAC
...--------+--------+--------+
ヘッダー…--------+--------+--------+ MACヘッダー| 長さ| 802. 3/4/5、Mac…--------+--------+--------+
+--------+--------+--------+
| Dsap=K1| Ssap=K1| control| 802.2 SAP
+--------+--------+--------+
+--------+--------+--------+ | Dsap=K1| Ssap=K1| コントロール| 802.2 SAP+--------+--------+--------+
+--------+--------+---------+--------+--------+
|protocol id or org code =K2| Ether Type | 802.2 SNAP
+--------+--------+---------+--------+--------+
+--------+--------+---------+--------+--------+ |プロトコルイドかorgコードがケーツーと等しいです。| エーテル型| 802.2 スナップ+--------+--------+---------+--------+--------+
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 HeaderとSNAPヘッダーの全長は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の2進の小数、AA十六進法、または170小数になります。
K2 is 0 (zero).
ケーツーは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とProbeなどの代替アドレス解決メカニズムであると実装する必要であるのを含意しました。 また、[RFC948]実装のためのアドレス解決メカニズムが標準化されなかったので、[RFC948]が広く実装されたなら、相互運用性問題はおそらく起こったでしょうに。
1.2.2. Trailer Encapsulation
1.2.2. トレーラカプセル化
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
「トレーラカプセル化」[RFC893]で注意されるように、トレーラカプセル化はレセプションでメモリからメモリへのコピーを最小にするために開発された最適化でした。 可変長のIPと輸送ヘッダーをパケットの端に置くことによって、データのページがえは、より容易にそうであるかもしれません。
Aboba, et al. Informational [Page 7] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[7ページ]RFC4840倍数カプセル化メソッド
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.
維持にされる。 トレーラは特に4.2バークレーSystem Distribution(BSD)で実装されました。 トレーラカプセル化は理論上イーサネット[RFC894]かIEEE802[RFC1042]カプセル化(IP!の4つの潜在的カプセル化を作成する)に適用されたかもしれませんでしたが、実際には、トレーラカプセル化はイーサネットのためにサポートされただけです。 別々のEthertypeは、トレーラカプセル化におけるIPパケットが[RFC894]カプセル化と区別されるのを可能にするのに利用されました。 [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キャッシュにおける対応するエントリーを示すことによって。
Aboba, et al. Informational [Page 8] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[8ページ]RFC4840倍数カプセル化メソッド
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回答パケットを使用して、この体系は、どんな仕様や常識とは逆にIPのためにトレーラのための別のARP回答によるARP回答に応じたふらちな事をしているホストとのARPパケットの連続した交換を避けるように設計されました。 この問題はIP ARP回答が傑出している要求に答えるときだけIP ARP回答に対応してトレーラARP回答を送ることによって、避けられます。 IP ARP回答が受け取られているとき、ホストのためのハードウェア・アドレスがまだ未知であるときに、これは本当です。 IP ARP要求に応じるIP ARP回答と共にトレーラ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]とトレーラ[RFC893]カプセル化とのイーサネットとIEEE802カプセル化とのその交渉は必要でなかったことの交渉だけを標準のイーサネットカプセル化[RFC894]における送受信ARPパケットにサポートしたと思われました。 また、トレーラカプセル化をサポートするホストが、1IEEE802の縁どりがメカニズムであるとサポートしたなら、交渉はまださらに複雑だったでしょうに。 例えば、[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.
リンク層通信にかかわる両方のシステム(ホストかゲートウェイ)がトレーラを実装することが確かめられたときだけ、リンクレイヤカプセル化のためのトレーラプロトコルは使用されるかもしれません。 システムがダイナミックに1目的地あたり1個のベースにおけるトレーラプロトコルの使用を交渉しないなら、デフォルト設定はプロトコルを無効にしなければなりません。
Aboba, et al. Informational [Page 9] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[9ページ]RFC4840倍数カプセル化メソッド
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]はトレーラカプセル化がデフォルトでそれらのシステムの上で無効にされるのを必要としました。
1.3. PPP Experience
1.3. ppp経験
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]で定義されるIEEE802フレーム、および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(0×0021)、IPv6(0×0057)、およびBridging PDU(0×0031)のために割り当てられたPPP Data Link Layer(DLL)プロトコル番号に加えて、以下のcodepointsは割り当てられました:
o two for RObust Header Compression (ROHC) [RFC3095]:
ROHC small-CID (0x0003) and ROHC large-CID (0x0005)
o RObust Header Compression(ROHC)[RFC3095]のための2: ROHCの小さいCid(0×0003)とROHCの大きいCid(0×0005)
o two for Van Jacobson compression [RFC1144]:
Compressed TCP/IP (0x002d) and Uncompressed TCP/IP (002f)
o ヴァンジェーコブソン圧縮[RFC1144]のための2: 圧縮されたTCP/IP(0x002d)と解凍されたTCP/IP(002f)
o one for IPv6 Header Compression [RFC2507]: (0x004f)
o IPv6 Header Compression[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 RTP IP Header Compression[RFC3544]のための9: 完全なヘッダー(0×0061)(圧縮されたTCP(0×0063))は非TCP(0×0065)、UDP8(0×0067)、RTP8(0×0069)、圧縮されたTCPいいえデルタ(0×2063)、文脈状態(0×2065)、UDP16(0×2067)、およびRTP16を圧縮しました。(0×2069)
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]で定義されるIEEE802フレーム、およびIPv4のカプセル化とIPv6[RFC2472]パケットの両方をサポートすることができますが、実際には、複数のカプセル化メカニズムは同じリンクで操作上ではありません。 同様に、ただ一つの圧縮技術だけがリンクにおける使用のために通常交渉されます。
1.4. Potential Mitigations
1.4. 潜在的緩和
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]かルータを使用するか、または使用されるべきカプセル化メソッドを交渉するのを試みるのが可能であるかもしれません。 以下で説明されるように、どちらのアプローチも完全に満足できるかもしれないというわけではありません。
Aboba, et al. Informational [Page 10] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[10ページ]RFC4840倍数カプセル化メソッド
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.
交渉自体が、複数のカプセル化を使用することで行われる必要があるかもしれないので、リンクレイヤを超えてカプセル化を交渉するのは潜在的に問題が多いです。 理論上、すべてのカプセル化メソッドの上の交渉パケットが各あて先ホストのために状態をサポートされて、維持するのを送ることによってカプセル化メソッドを交渉するのは可能です。 しかしながら、ダイナミックにリンクの上のそれぞれの新しい目的地とカプセル化メソッドを交渉しなければならないなら、新しい目的地へのコミュニケーションは遅れるかもしれません。 ほとんどのコミュニケーションが不足して、交渉がリンクレイヤアドレス解決を超えて付加的な周遊旅行を必要とするなら、これは性能のめぼしい要素になることができます。 また、交渉は追加帯域幅の消費をもたらすかもしれません。
2. Evaluation of Arguments for Multiple Encapsulations
2. 複数のカプセル化のための議論の評価
There are several reasons often given in support of multiple encapsulation methods. We discuss each in turn, below.
しばしば複数のカプセル化メソッドを支持してあげられたいくつかの理由があります。 私たちは以下で順番にそれぞれについて議論します。
2.1. Efficiency
2.1. 効率
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のIEEE802かイーサネットカプセル化がデータフレームヘッダーのサイズによる過度のオーバーヘッドをもたらして、これがワイヤレス・ネットワークに関する性能に悪影響を与えることができると主張されました、特にボイス・オーバー 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カプセル化メソッドを定義するのを必要としないソリューションが存在しています。 例えば、リンクが、イーサネットがフレーム圧縮であるとサポートするかもしれないので、あらゆるパケットと共にイーサネットSourceとDestination Address野原を送るというわけではありません。
It is possible for link layers to negotiate compression without requiring higher-layer awareness; the Point-to-Point Protocol (PPP)
リンクレイヤに、より高い層の認識を必要としないで圧縮を交渉するのは可能です。 二地点間プロトコル(ppp)
Aboba, et al. Informational [Page 11] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[11ページ]RFC4840倍数カプセル化メソッド
[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 Compression Controlプロトコル(CCP)」[RFC1962]はデータ圧縮メカニズムの交渉を可能にします、そして、「pppの上の体力を要しているヘッダー圧縮(ROHC)」[RFC3241]と「pppの上の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.
複数のカプセル化の使用がパケット損失で性能か結果を下げることができる状況もあります。 異なったMaximum Transfer Units(MTUs)との複数のカプセル化メソッドの使用はリンクの上の目的地への異なったMTUsをもたらすことができます。 リンク層のプロトコルが1目的地あたりのMTUsをIP層に供給しないと、デフォルト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が同じリンクで目的地の中で異なるかもしれないところに、リンク層プロトコルがaを提供するべきである、-、IPへの目的地MTU。
2.2. Multicast/Broadcast
2.2. マルチキャスト/放送
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パケットはリンクの上のすべての潜在的受信機に達する必要があります。 どうそれに会うことができるかのかなりの柔軟性がありますが、代替のカプセル化の使用はこの要件を取り除くことができません。 非放送Multiple Access(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
また、テクニックもワイヤレス・ネットワークにおける、IPマルチキャスト/ブロードキャスト配信の効率を高めるのに利用可能です。 受け取ることができるには、いずれでも、中で聴いている範囲、IPを接待してください。
Aboba, et al. Informational [Page 12] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[12ページ]RFC4840倍数カプセル化メソッド
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マルチキャスト/放送パケットを提供できます。 例えば、IEEE802.11では、ユニキャスト、およびそれぞれのSTAの交渉されたレートのAP道としていつも駅(STA)からAccess Point(AP)に送られたマルチキャスト/放送トラフィックを送ります、各ステーションに、適切なレートでユニキャストフレームを送ることができるように。
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のための問題」[RFC4541]で説明されるようにインターネットGroup Managementプロトコル(IGMP)とMulticast Listenerディスカバリー(MLD)トラフィックについて詮索することによって。
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]では、リンクレイヤユニキャストでクライアントステーション(STA)からAccess Point(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.
推薦: リンクレイヤマルチキャスト/放送のサポートが問題が多いところでは、ホストへの別々の接頭語の課題でリンク範囲マルチキャストと放送トラフィックの伝播を制限してください。 いくつかの事情では、同じくらい複数のリンクレイヤユニキャストが縁どるマルチキャスト/放送トラフィックを分配するのは、より効率的であるかもしれません。
2.3. Multiple Uses
2.3. 複数の用途
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)は以下を述べます。
Aboba, et al. Informational [Page 13] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[13ページ]RFC4840倍数カプセル化メソッド
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].
既存のカプセル化は、自分たちが、異種の用法がシナリオであるとサポートすることができると立証しました。 例えば、Pointからポイントへのプロトコル(PPP)は汎用パケット無線システム(GPRS)などのワイヤレスのリンクレイヤ、およびアプリケーションにおける、「Sonet/SDHの上のppp」[RFC2615]などの有線ネットワークで利用されました。 PPPは「コントロールがプロトコル(BCP)であるとブリッジする二地点間プロトコル(ppp)」[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].
同様に、イーサネットカプセル化はIEEE802.11など[IEEE-802.11.2003]のWirelessローカル・エリア・ネットワーク(WLANs)と同様に有線ネットワークに使用されました。 また、イーサネットはService(QoS)[IEEE-802.1Q.2003]のVirtual LAN(VLANs)とQualityをサポートすることができます。
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.
Pointからポイントの上のIPプロトコル(PPP)[RFC1661]以外のカプセル化、イーサネット、またはIEEE802がサポートされるところでは、オペレーティングシステム統合における困難は相互運用性問題を引き起こすことができます。
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、イーサネット、またはIEEE802の上でIPカプセル化のオペレーティングシステムサポートを利用して、それは、ドライバーのためにPPP、イーサネット、またはIEEE802サポートを見習うように代替のカプセル化をサポートするのに誘惑しているかもしれません。 通常、PPPエミュレーションは、ドライバー道具PPP、PPPコントロールに関する翻訳を可能にして、およびデータが同等なネイティブの施設に縁どられるのを必要とします。 同様に、イーサネットかIEEE802エミュレーションが、ドライバーが、施設と、そして、ネイティブの施設からこれらのフレームに関する翻訳を可能にするためにDynamic Host Configuration Protocol(DHCP)がv4、v6、Router Solicitation/ルータAdvertisement(RS/RA)、Address Resolutionプロトコル(ARP)、またはIPv6 Neighborディスカバリー(ノースダコタ)であると実装するのを通常必要とします。
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.
ドライバーがカーネルモードで実装されるところでは、忠実なエミュレーションを提供するのに必要である仕事は実質的であるかもしれません。 潜在的に相互運用性問題をもたらして、これは手を抜く誘惑を作成します。
Aboba, et al. Informational [Page 14] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[14ページ]RFC4840倍数カプセル化メソッド
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 ControlがIPCPv6ではなく、プロトコル(IPCP)であるとサポートするかもしれません。 イーサネットを見習っているドライバーかIEEE802がDHCPv6、RS/RA、またはノースダコタではなく、DHCPv4とARPだけをサポートするかもしれません。 その結果、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、イーサネット、またはIEEE802のエミュレーションは避けられるべきです。
3. Additional Issues
3. 追加設定
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でほのめかされるように複数のカプセル化メソッドの使用から起こる多くの追加設定があります。 私たちはそれぞれの以下のこれらについて議論します。
3.1. Generality
3.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.
IEEE802.16[IEEE-802.16.2004]はメディアAccess Control(MAC)層を多くの副層に分けます。 これらの最高に関しては、規格はサービス特有のConvergence Sublayer(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]は生のIPv4、生のIPv6、およびイーサネットのために6つの異なったクラシファイアの選択でAsynchronous Transfer Mode(ATM)CSとPacket CSのサポートを定義しましたが、[IEEE-802.16e.2005]は生の、そして、イーサネットで縁どられたROHC Enhanced Compressed RTP(ECRTP)の圧縮されたパケットのサポートを加えました。 その結果、[IEEE-802.16e.2005]は生のIPv4、生のIPv6、802.3/イーサネット、802.1Q VLAN、IPv4 802.3以上/イーサネット、IPv6 802.3以上/イーサネット、802.1Q VLANの上のIPv4、802.1Q VLANの上のIPv6、生のROHCによって圧縮されたパケット、生のECRTPによって圧縮されたパケット(ROHCによって圧縮されたパケット802.3以上/イーサネット)、およびECRTPによって圧縮されたパケット802.3以上/イーサネットの送信のためにPacket CSのATM CSと複数のバージョンを定義します。
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]は規格が、新しいパケットタイプをサポートするように変更される必要であるのを含意するように見えます:
Aboba, et al. Informational [Page 15] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[15ページ]RFC4840倍数カプセル化メソッド
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空気インタフェースの上で新しいプロトコルを輸送するために容易に「広げ-可能」であるはずがないことを心配しています。 Convergence Sublayerが802.16MACの上で輸送されたすべてのタイプのプロトコルに必要であるように見えるでしょう。 新しいプロトコルタイプが、802.16空気インタフェースの上で輸送される必要があるときはいつも、802.16規格は、新しいCSタイプを定義するように変更される必要があります。 私たちは、新しいプロトコルをサポートするためにマルチプロトコルをサポートできて、802.16規格へのさらなる変更を必要としないジェネリックPacket Convergence Sublayerを必要とします。 私たちは、これがPacket CSのオリジナルの意志であったと信じています。 その上、私たちは、産業がすべてのデバイスが「承諾」を要求するために実装しなければならないCSのものの1セットに同意するのが、難しいと信じています。
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パケットを扱うことができると仮定します。 その結果、IPv6のために0×0800のTypeがIPv4に使用されるIEEE802メディア、および0x86DDでして、異なったプロトコルタイプを選任するのなどようにそのままなリンクレイヤの中に「反-マルチプレックス」プロトコルには、より強健なデザインがあります。
Recommendations: Link-layer protocols should enable network packets (IPv4, IPv6, ARP, etc.) to be demultiplexed in the link layer.
推薦: リンク層プロトコルは、ネットワークパケット(IPv4、IPv6、ARPなど)がリンクレイヤの中で反多重送信されるのを可能にするべきです。
3.2. Layer Interdependence
3.2. 層の相互依存
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.
IEEE802.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
リンクレイヤ分類でIP、そして/または、上側の層のヘッダーを利用するのはほぼ必然的にリンクレイヤと上側の層の仕様の間の相互依存性に通じるでしょう。 この力が、見える
Aboba, et al. Informational [Page 16] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[16ページ]RFC4840倍数カプセル化メソッド
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.
リンクレイヤ(例えば、サービスの質サポート)で提供された能力と上側の層によって必要とされるものの間に非常に特定の、そして、(したがって、共同利用できる)のマッピングを提供するのにおいて望ましいです、より包括的なサービスインタフェース(アプリケーションProgramming Interface)でたぶんただ一つのカプセル化メカニズムに関連してこの種類の能力を提供するほうがよいです。
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.
推薦: 上側の層の詳細分類体系は避けられるべきです。
3.3. Inspection of Payload Contents
3.3. 有効搭載量コンテンツの点検
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].
より高い層のヘッダーを利用する分類体系が、(例えば、使用する接続識別子(CID)がパケットを伝えることを決定するためのIEEE802.16IP CSメカニズム)であることがカプセルに入れられるパケットのコンテンツを点検するよう提案するなら、パケットがリンクレイヤに通る前に圧縮されるか、または暗号化されるなら、点検に利用可能な分野は制限されるかもしれません。 これは、リンクレイヤが既存の圧縮機構を利用するのを防ぐかもしれません、ヴァンジェーコブソンCompression[RFC1144]、ROHC[RFC3095][RFC3759]、Compressed RTP(CRTP)[RFC2508]、Enhanced Compressed RTP(ECRTP)[RFC3545]、またはIP Header Compression[RFC2507]などのように。
Recommendations: Link-layer classification schemes should not rely on the contents of higher-layer headers.
推薦: リンクレイヤ分類体系は、より高い層のヘッダーのコンテンツを当てにするべきではありません。
3.4. Interoperability Guidance
3.4. 相互運用性指導
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.
IEEE802.16では、Subscriber駅(SS)はそれが基地の駅(BS)にサポートするConvergence Sublayersを示します。それは、それがリンクの上にサポートするより多くのリスト1から選び抜きます。 したがって、複数のCSesが操作上であることは、可能です。
Note that IEEE 802.16 does not provide multiple encapsulation methods for the same kind of data payload; it defines exactly one
IEEE802.16が同じ種類のデータペイロードに複数のカプセル化メソッドを供給しないことに注意してください。 それはちょうど1つを定義します。
Aboba, et al. Informational [Page 17] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[17ページ]RFC4840倍数カプセル化メソッド
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:
それぞれのデータペイロードのカプセル化体系。 例えば、IEEE802.16MACフレームに生のIPv4パケットをカプセルに入れる1つの方法があります、生のIPv6パケットなどの1つのカプセル化体系 また、イーサネットフレームをカプセル化する1つの方法があります、接続識別子の上で(CID)を進めるためにイーサネットフレームを分類するための複数の可能性ありさえするときさえ。 以来、複数のCSesのサポートは、IEEE802.16が層2にフレームをカプセル化して、層の3パケット、パケットがまた、MACがイーサネットヘッダーと共にIEEEで縁どられるように縁どるIEEE802.16で直接カプセルに入れられるかもしれないIPに802.16個のMACフレームをカプセル化するのを可能にします。 層2のフレームと層の両方に3つのパケットをサポートするCSesが同じリンクで操作上であるところでは、多くの問題が起こるかもしれません、である:
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の両方が同じリンクで操作上であるAddress Resolutionプロトコル(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.
データFrame Encapsulation WhenがIPパケットを送る場合、どのCSが使用されるべきですか? 複数であるところでは、カプセル化が操作上である、また、複数の接続識別子(CIDs)も存在するでしょう。 したがって、それ自身のインタフェースを構成する各CIDに関するマルチホーミング問題として問題を扱うことができます。 与えられたCIDには関連帯域幅かサービスの品質規制があるかもしれないので、これを考慮に入れるようにルーティング測定基準を調整できました、どのCID(そして、カプセル化)が、より魅力的に見えるかに基づいてルーティング層が選ばれるのを許容して。
This could lead to interoperability problems or routing asymmetry. For example, consider the effects on IPv6 Neighbor Discovery:
これは相互運用性問題かルーティング非対称を引き起こすかもしれません。 例えば、IPv6 Neighborディスカバリーへの効果を考えてください:
(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) ホストが、異なったCSesでディスカバリートラフィックをIPv6 Neighborに送るのを選ぶなら、IPv6 Neighborディスカバリーパケットを送るホストが回答を受け取らないのは、可能です、目標ホストが別の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.
ホストがCSesの同じセットを皆、支えますが、異なったルーティング好みを持っている(b)、ホストがIPv6 Neighborディスカバリーパケットを1CSの上に送って、別の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の1種類だけが特定のリンクで使用可能であるべきであることが強く推薦されます。
Aboba, et al. Informational [Page 18] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[18ページ]RFC4840倍数カプセル化メソッド
3.5. Service Consistency
3.5. サービスの一貫性
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パケットのための'ネイティブ'のカプセル化とイーサネットカプセル化の両方を提供します。 生の場合では、直接トランスミッションがチャネルを開設するIEEE802.16のサービスの質(QoS)能力にIP層を写像できますが、イーサネットカプセル化を使用して、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パケットのための複数のカプセル化メソッドが必要であると考えられるなら、できるだけ密接にカプセル化メソッドの間で利用可能なサービスに合うように注意するべきです。
3.6. Implementation Complexity
3.6. 実装の複雑さ
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.
推薦: 発信と受信の両方のために実装するために義務的なただ一つのカプセル化メカニズムを選んでください、そして、そのカプセル化メカニズムを送付のためのデフォルトにしてください。
3.7. Negotiation
3.7. 交渉
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
しかしながら、あるカプセル化以上が当然のことで可能であり、リンクレイヤがどんな2人のホストの間のカプセル化の交渉を許さない場合、相互運用性問題はまだ結果として生じることができます。
Aboba, et al. Informational [Page 19] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[19ページ]RFC4840倍数カプセル化メソッド
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.
リンクしてください。 一般に、ホストは、リンクの上の他のすべてのホストが同じセットのカプセル化メソッドをサポートすると仮定できません、リンク層プロトコルが二地点間コミュニケーションをサポートするだけではないなら、複数の潜在的カプセル化メソッドの交渉が問題が多くなるように。 この問題を避けるために、どのカプセル化メソッドが可能であるかを単に示すのではなく、リンクレイヤカプセル化交渉がただ一つの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.
推薦: リンクレイヤの中でカプセル化交渉を扱うのは最も良いです。 データフレームカプセル化メカニズムの上で依存を避けるために、交渉が行われるのは、管理フレームを使用することで望ましいです、それらがサポートされるなら。 複数のカプセル化を必要として、交渉を提供するなら、交渉はリンクに関して交渉されるただ一つのカプセル化メソッドをもたらすべきです。
3.8. Roaming
3.8. ローミング
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パケットのために複数のカプセル化メソッドを提供するなら、これらのカプセル化メソッドの1つだけがどんな与えられたリンクの上、または、ただ一つの放送ドメインの中で使用中であるべきであることが強く推薦されます。
4. Security Considerations
4. セキュリティ問題
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.
攻撃者は、サービス不能攻撃で引き起こすのにリンクの上に通常、使用中でなかったカプセル化メソッドを利用できるかもしれません。(サービス不能攻撃に、捨てられる前にこのカプセル化を利用するパケットがスタックでどんな重要な度合いにも通過されるなら、インタフェースの処理リソースはくたくたになるでしょうに)。
Aboba, et al. Informational [Page 20] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[20ページ]RFC4840倍数カプセル化メソッド
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つの終点の間により厄介なカプセル化メソッドを強制できるかもしれません、より軽い重り1が利用可能であるときにさえ、したがって、リンクの上と、そして、それらの終点の中で、より高いリソース消費を強制するか、または断片化を引き起こして。 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トンネルモード)の暗号化が必要であるところでは、これは分類に必要であるヘッダーを見えなくするかもしれません。 その結果、すべての暗号化されたトラフィックが単独結合の上を流れるのが必要であるかもしれません。
5. Conclusion
5. 結論
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の経験の反復を避けて、802.3のメディア、IEEEイーサネットだけにおけるカプセル化が定義されたIPv6の操作のために、「イーサネットネットワークの上のIPv6パケットのトランスミッションのためのメソッド」[RFC1972]は後で中で[RFC2464]をアップデートしました。
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パケットのために複数のカプセル化メソッドを提供するなら、これらのカプセル化メソッドの1つだけがどんな与えられたリンクの中にも使用中であるべきであることが強く推薦されます。
Where multiple encapsulation methods are supported on a link, a
single encapsulation should be mandatory to implement for send and
receive.
ただ一つのカプセル化が複数のカプセル化メソッドがリンクの上にサポートされるのが道具に義務的であるべきところに、発信してください、そして、受信してください。
Aboba, et al. Informational [Page 21] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[21ページ]RFC4840倍数カプセル化メソッド
6. References
6. 参照
6.1. Normative Reference
6.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
6.2. Informative References
6.2. 有益な参照
[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]ディジタルイクイップメント社、インテル社、およびゼロックス社、「イーサネット--ローカル・エリア・ネットワーク:、」 1982年11月に「データ・リンク層と身体検査は(バージョン2.0)を層にします」。
[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)」、IEEE802.16gへのSubmission: 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 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規格: 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.
[IEEE-802.3.2002] 米国電気電子技術者学会、「衝突検出型搬送波検知多重アクセス(CSMA/CD)はメソッドと物理的な層の仕様にアクセスします」、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)
Aboba, et al. Informational [Page 22] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[22ページ]RFC4840倍数カプセル化メソッド
[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] 米国電気電子技術者学会、「情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク、Part16:」 「固定広帯域のワイヤレス・アクセスシステムのための空気インタフェース」、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]米国電気電子技術者学会、「情報技術--システムの間のテレコミュニケーションと情報交換--ローカルとMetropolitan Area Networks--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.
1993年7月の[PROBE]ヒューレットパッカード、「hp徹底的調査に関する入門書」 http://www.hp.com/rnd/support/manuals/pdf/ hp_probe.pdf。
[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.bitに扱う」STD37、RFC826、1982年11月。
[RFC893] Leffler, S. and M. Karels, "Trailer
encapsulations", RFC 893, April 1984.
[RFC893] レフラーとS.とM.Karels、「トレーラカプセル化」、RFC893、1984年4月。
[RFC894] Hornig, C., "A Standard for the Transmission of
IP Datagrams over Ethernet Networks", STD 41, RFC
894, April 1984.
[RFC894] ホーニッグ、C.、「イーサネットネットワークの上のIPデータグラムの送信の規格」、STD41、RFC894、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、「逆アドレス解決プロトコル」STD38、RFC903(1984年6月)。
[RFC948] Winston, I., "Two Methods for the Transmission of
IP Datagrams over IEEE 802.3 Networks", RFC 948,
June 1985.
[RFC948] ウィンストン、I.、「IEEE802.3ネットワークの上のIPデータグラムの送信のための2つのメソッド」、RFC948、1985年6月。
[RFC1010] Reynolds, J. and J. Postel, "Assigned Numbers",
RFC 1010, May 1987.
[RFC1010] レイノルズ、J.、およびJ.ポステル(「規定番号」、RFC1010)は1987がそうするかもしれません。
Aboba, et al. Informational [Page 23] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[23ページ]RFC4840倍数カプセル化メソッド
[RFC1042] Postel, J. and J. Reynolds, "Standard for the
transmission of IP datagrams over IEEE 802
networks", STD 43, RFC 1042, February 1988.
[RFC1042] ポステルとJ.とJ.レイノルズ、「IEEE802ネットワークの上のIPデータグラムのトランスミッションの規格」、STD43、RFC1042、1988年2月。
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October
1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for
Low-Speed Serial Links", RFC 1144, February 1990.
1990年2月の[RFC1144]ジェーコブソン対「低速連続のリンクへのTCP/IPヘッダーを圧縮すること」でのRFC1144
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC1958] 1996年6月の大工、B.、「インターネットの建築プリンシプルズ」RFC1958。
[RFC1962] Rand, D., "The PPP Compression Control Protocol
(CCP)", RFC 1962, June 1996.
D.、「ppp圧縮制御プロトコル(CCP)」、RFC1962 1996年6月の[RFC1962]底ならし革。
[RFC1972] Crawford, M., "A Method for the Transmission of
IPv6 Packets over Ethernet Networks", RFC 1972,
August 1996.
[RFC1972]クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッションのためのメソッド」、RFC1972、1996年8月。
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2472, December 1998.
[RFC2472] ハスキンとD.とE.アレン、「pppの上のIPバージョン6」、RFC2472、1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[RFC2464] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、1998年12月。
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP
Header Compression", RFC 2507, February 1999.
[RFC2507] デーゲルマルクとM.とNordgren、B.とS.ピンク、「IPヘッダー圧縮」、RFC2507、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.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH",
RFC 2615, June 1999.
[RFC2615] MalisとA.とW.シンプソン、「Sonet/SDHの上のppp」、RFC2615、1999年6月。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol
Encapsulation over ATM Adaptation Layer 5", RFC
2684, September 1999.
[RFC2684] グロースマン、D.、およびJ.Heinanen、「気圧適合の上のMultiprotocolカプセル化は1999年9月に5インチ、RFC2684を層にします」。
[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.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.
Aboba, et al. Informational [Page 24] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[24ページ]RFC4840倍数カプセル化メソッド
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust
Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP, and uncompressed", RFC
3095, July 2001.
Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 フレームワークと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日
[RFC3241] Bormann, C., "Robust Header Compression (ROHC)
over PPP", RFC 3241, April 2002.
[RFC3241]ボルマン、2002年4月のC.、「pppの上の体力を要しているヘッダー圧縮(ROHC)」RFC3241。
[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.リャオ、「ポイントへのコントロールがプロトコル(BCP)であるとブリッジするポイントプロトコル(ppp)」、RFC3518、2003年4月。
[RFC3544] Koren, T., Casner, S., and C. Bormann, "IP Header
Compression over PPP", RFC 3544, July 2003.
2003年7月の[RFC3544]コーレンとT.とCasner、S.とC.ボルマン、「pppの上のIPヘッダー圧縮」RFC3544。
[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. 非常に、「パケット損失とReordering、高値とのリンクへの高められた圧縮されたRTP(CRTP)は延着します」、RFC3545、2003年7月。
[RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC):
Terminology and Channel Mapping Examples", RFC
3759, April 2004.
[RFC3759]イェンソン、L-E.、「体力を要しているヘッダー圧縮(ROHC):」 「用語とチャンネルの写像している例」、RFC3759、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、「スイッチについて詮索して、インターネット集団経営のための問題は(IGMP)とマルチキャストリスナー発見(MLD)について議定書の中で述べます」、RFC4541、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.
SecurityとPrivacy、ページの2006IEEE Symposiumの[WEP]BittauとA.とハンドレー、M.とJ.Lackey、「WEPの棺の最終的な釘」Proceedings 386-400.
7. Acknowledgments
7. 承認
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、およびフィル・ロバーツを承認したがっています。
Aboba, et al. Informational [Page 25] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[25ページ]RFC4840倍数カプセル化メソッド
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 Loaアンデションブライアン大工レスリーDaigle ElwynデイヴィースケビンFallオラフ・Kolkmanカーティス・リンクヴィスト・デヴィッド・マイヤー・デヴィッド・オラン・エリック・レスコラ・デーヴ・ターレル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、6605Fax: +1 425 936 7329
Elwyn B. Davies Consultant Soham, Cambs UK
CambsイギリスのElwyn B.デイヴィースコンサルタントSoham
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
Aboba, et al. Informational [Page 26] RFC 4840 Multiple Encapsulation Methods Harmful April 2007
Aboba、他 2007年4月に有害な情報の[26ページ]RFC4840倍数カプセル化メソッド
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Aboba, et al. Informational [Page 27]
Aboba、他 情報[27ページ]
一覧
スポンサーリンク
