Independent Submission B. Carpenter
Request for Comments: 6214 Univ. of Auckland
Category: Informational R. Hinden
ISSN: 2070-1721 Check Point Software
1 April 2011
Adaptation of for IPv6
Abstract
抽象
This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149.
この文書は、RFC 1149でのIPv4データグラムのために指定されたものと同じ媒体を介したIPv6データグラムの送信のための方法を指定します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6214.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6214で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 2
3. Detailed Specification . . . . . . . . . . . . . . . . . . . . 2
3.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . . 2
3.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Address Configuration . . . . . . . . . . . . . . . . . . . 3
3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Quality-of-Service Considerations . . . . . . . . . . . . . . . 4
5. Routing and Tunneling Considerations . . . . . . . . . . . . . 4
6. Multihoming Considerations . . . . . . . . . . . . . . . . . . 5
7. Internationalization Considerations . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . . 6
As shown by [RFC6036], many service providers are actively planning to deploy IPv6 to alleviate the imminent shortage of IPv4 addresses. This will affect all service providers who have implemented [RFC1149]. It is therefore necessary, indeed urgent, to specify a method of transmitting IPv6 datagrams [RFC2460] over the RFC 1149 medium, rather than obliging those service providers to migrate to a different medium. This document offers such a specification.
[RFC6036]で示したように、多くのサービスプロバイダーは、積極的にIPv4アドレスの差し迫った不足を緩和するためにIPv6を導入することを計画しています。これは、[RFC1149]を実装しているすべてのサービスプロバイダに影響を与えます。 RFC 1149媒体を介してIPv6データグラム[RFC2460]を送信するのではなく、異なる媒体に移行するものサービスプロバイダを義務付ける方法を指定するために、実際に緊急、が必要です。この文書では、このような仕様を提供しています。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Unless otherwise stated, the provisions of [RFC1149] and [RFC2460] apply throughout.
特に明記しない限り、[RFC1149]と[RFC2460]の規定は、全体に適用されます。
As noted in RFC 1149, the MTU is variable, and generally increases with increased carrier age. Since the minimum link MTU allowed by RFC 2460 is 1280 octets, this means that older carriers MUST be used for IPv6. RFC 1149 does not provide exact conversion factors between age and milligrams, or between milligrams and octets. These conversion factors are implementation dependent, but as an illustrative example, we assume that the 256 milligram MTU suggested in RFC 1149 corresponds to an MTU of 576 octets. In that case, the typical MTU for the present specification will be at least 256*1280/576, which is approximately 569 milligrams. Again as an illustrative example, this is likely to require a carrier age of at least 365 days.
RFC 1149に述べたように、MTUは可変であり、そして一般的に増加したキャリア年齢と共に増加します。 RFC 2460で許可された最小リンクMTUは1280オクテットであるので、これは古いキャリアがIPv6のために使用されなければならないことを意味しています。 RFC 1149には、年齢やミリグラムの間、またはミリグラムとオクテットとの間の正確な変換係数を提供していません。これらの変換係数は、実装依存であるが、説明のための例として、我々は、MTUは、RFC 1149で提案256ミリグラムが576オクテットのMTUに対応すると仮定する。その場合には、本明細書のための典型的なMTUは約569ミリグラム、少なくとも256×576分の1280を、あろう。ここでも説明のための例として、これは、少なくとも365日間のキャリア年齢を必要とする可能性が高いです。
Furthermore, the MTU issues are non-linear with carrier age. That is, a young carrier can only carry small payloads, an adult carrier can carry jumbograms [RFC2675], and an elderly carrier can again carry only smaller payloads. There is also an effect on transit time depending on carrier age, affecting bandwidth-delay product and hence the performance of TCP.
さらに、MTUの問題は、キャリア、年齢とともに非直線的です。それは若いキャリアはわずかなペイロードを運ぶことができる、大人のキャリアはジャンボグラム[RFC2675]を運ぶことができる、で、高齢者のキャリアは小さいペイロードを再び運ぶことができます。通過時間、キャリア、年齢に応じた帯域幅遅延積ので、TCPのパフォーマンスに影響を与える上の効果もあります。
RFC 1149 does not specify the use of any link layer tag such as an Ethertype or, worse, an OSI Link Layer or SNAP header [RFC1042]. Indeed, header snaps are known to worsen the quality of service provided by RFC 1149 carriers. In the interests of efficiency and to avoid excessive energy consumption while packets are in flight through the network, no such link layer tag is required for IPv6 packets either. The frame format is therefore a pure IPv6 packet as defined in [RFC2460], encoded and decoded as defined in [RFC1149].
RFC 1149は、イーサタイプまたは、悪化、OSIリンク層またはSNAPヘッダ[RFC1042]などの任意のリンク層タグの使用を指定していません。実際、ヘッダスナップは、RFC 1149個のキャリアによって提供されるサービスの品質を悪化させることが知られています。効率の利益のために、パケットがネットワーク経由で飛行している間に、過剰なエネルギー消費を避けるために、そのようなリンク層タグは、いずれかのIPv6パケットのために必要とされません。 [RFC1149]で定義されるように符号化され、復号化され、[RFC2460]で定義されるようにフレームフォーマットは、したがって、純粋なIPv6パケットです。
One important consequence of this is that in a dual-stack deployment [RFC4213], the receiver MUST inspect the IP protocol version number in the first four bits of every packet, as the only means to demultiplex a mixture of IPv4 and IPv6 packets.
これの一つの重要な結果は、デュアルスタック配備[RFC4213]に、受信機は、IPv4およびIPv6パケットの混合物を分離するための唯一の手段として、すべてのパケットの最初の4ビットにIPプロトコルのバージョン番号を検査しなければならないことです。
The lack of any form of link layer protocol means that link-local addresses cannot be formed, as there is no way to address anything except the other end of the link.
リンク層プロトコルの任意の形式の欠如は、リンクのもう一方の端以外のものに対処する方法がないよう、リンクローカルアドレスは、形成することができないことを意味します。
Similarly, there is no method to map an IPv6 unicast address to a link layer address, since there is no link layer address in the first place. IPv6 Neighbor Discovery [RFC4861] is therefore impossible.
同様に、最初の場所にはリンク層アドレスが存在しないので、リンク層アドレスにIPv6ユニキャストアドレスをマッピングする方法はありません。 IPv6の近隣探索[RFC4861]はことは不可能です。
Implementations SHOULD NOT even try to use stateless address auto-configuration [RFC4862]. This recommendation is because this mechanism requires a stable interface identifier formed in a way compatible with [RFC4291]. Unfortunately the transmission elements specified by RFC 1149 are not generally stable enough for this and may become highly unstable in the presence of a cross-wind.
実装はさえ[RFC4862]ステートレスアドレス自動設定を使用しないようにしてください。このメカニズムは[RFC4291]と互換性のある方法で形成された安定したインタフェース識別子を必要とするため、この勧告です。残念ながら、RFC 1149で指定された伝達要素は、一般に、このために十分に安定ではなく、クロス風の存在下で非常に不安定になることがあります。
In most deployments, either the end points of the link remain unnumbered, or a /127 prefix and static addresses MAY be assigned. See [IPv6-PREFIXLEN] for further discussion.
ほとんどの展開では、リンクのエンドポイントのいずれかが非番号のまま、または/ 127プレフィックスと静的アドレスを割り当てることもできます。さらなる議論のための[IPv6対応のprefixlen]を参照してください。
RFC 1149 does not specify a multicast address mapping. It has been reported that attempts to implement IPv4 multicast delivery have resulted in excessive noise in transmission elements, with subsequent drops of packet digests. At the present time, an IPv6 multicast mapping has not been specified, to avoid such problems.
RFC 1149は、マルチキャストアドレスのマッピングを指定していません。パケット・ダイジェストの後続液滴で、伝達要素に過度のノイズをもたらしたIPv4マルチキャスト配信を実現しようとすることが報告されています。現時点では、IPv6マルチキャストマッピングは、このような問題を回避するために、指定されていません。
[RFC2549] is also applicable in the IPv6 case. However, the author of RFC 2549 did not take account of the availability of the Differentiated Services model [RFC2474]. IPv6 packets carrying a non-default Differentiated Services Code Point (DSCP) value in their Traffic Class field [RFC2460] MUST be specially encoded using green or blue ink such that the DSCP is externally visible. Note that red ink MUST NOT be used to avoid confusion with the usage of red paint specified in RFC 2549.
[RFC2549]はIPv6のケースにも適用可能です。しかし、RFC 2549の作者は、差別化サービスモデル[RFC2474]の可用性を考慮していませんでした。それらのトラフィッククラスフィールドのデフォルト以外の差別化サービスコードポイント（DSCP）値[RFC2460]を運ぶIPv6パケットは、特別にDSCPを外部見えるように緑色または青色インクを使用して符号化されなければなりません。赤インクはRFC 2549で指定された赤ペンキの使用との混同を避けるために使用してはいけないことに注意してください。
RFC 2549 did not consider the impact on quality of service of different types of carriers. There is a broad range. Some are very fast but can only carry small payloads and transit short distances, others are slower but carry large payloads and transit very large distances. It may be appropriate to select the individual carrier for a packet on the basis of its DSCP value. Indeed, different carriers will implement different per-hop behaviors according to RFC 2474.
RFC 2549は、キャリアの異なる種類のサービスの品質への影響を考慮していませんでした。幅広い範囲があります。いくつかは他の人が遅くなりますが、大きなペイロードトランジット非常に長い距離を運ぶ、非常に高速ですが、わずかなペイロード及び通過短い距離を運ぶことができます。そのDSCP値に基づいてパケットのための個々のキャリアを選択することが適切であろう。実際に、異なるキャリアは、RFC 2474に応じて異なるホップごとの動作を実装します。
Routing carriers through the territory of similar carriers, without peering agreements, will sometimes cause abrupt route changes, looping packets, and out-of-order delivery. Similarly, routing carriers through the territory of predatory carriers may potentially cause severe packet loss. It is strongly recommended that these factors be considered in the routing algorithm used to create carrier routing tables. Implementers should consider policy-based routing to ensure reliable packet delivery by routing around areas where territorial and predatory carriers are prevalent.
契約をピアリングせずに、同様のキャリアの領土を通じてキャリアルーティング、時には突然のルート変更、ループパケット、およびアウトオブオーダー配信を引き起こします。同様に、略奪キャリアの領土を介してキャリアをルーティングすることは、潜在的に厳しいパケット損失を引き起こし得ます。強く、これらの要因は、キャリアルーティングテーブルを作成するために使用されるルーティングアルゴリズムにおいて考慮されることをお勧めします。実装者は領土と捕食キャリアが流行している地域を中心にルーティングすることにより、信頼性の高いパケット配信を保証するために、ポリシーベースルーティングを検討すべきです。
There is evidence that some carriers have a propensity to eat other carriers and then carry the eaten payloads. Perhaps this provides a new way to tunnel an IPv4 packet in an IPv6 payload, or vice versa.
一部のキャリアが他のキャリアを食べた後、食べペイロードを運ぶための傾向を持っているという証拠があります。おそらくこれは、IPv6ペイロードにトンネルにIPv4パケットを新たな方法を提供し、またはその逆。
However, the decapsulation mechanism is unclear at the time of this writing.
しかし、カプセル化解除メカニズムは、この記事の執筆時点では不明です。
Some types of carriers are notoriously good at homing. Surprisingly, this property is not mentioned in RFC 1149. Unfortunately, they prove to have no talent for multihoming, and in fact enter a routing loop whenever multihoming is attempted. This appears to be a fundamental restriction on the topologies in which both RFC 1149 and the present specification can be deployed.
キャリアの種類によってはホーミングで悪名高い良いです。驚くべきことに、このプロパティはRFC 1149に記載されていませんが残念ながら、彼らは、マルチホーミングのための才能を持っていないと証明する、としようとしているマルチホーミングいつでも実際には、ルーティングループを入力します。これは、両方のRFC 1149本明細書は、展開可能なトポロジ上の根本的な制限であるように見えます。
In some locations, such as New Zealand, a significant proportion of carriers are only able to execute short hops, and only at times when the background level of photon emission is extremely low. This will impact the availability and throughput of the solution in such locations.
光子放出のバックグラウンドレベルが極端に低い場合、このようなニュージーランドのようないくつかの場所では、キャリアのかなりの割合は、短いホップを実行することができる、唯一の時間です。これは、このような場所で溶液の可用性とスループットに影響を与えます。
The security considerations of [RFC1149] apply. In addition, recent experience suggests that the transmission elements are exposed to many different forms of denial-of-service attacks, especially when perching. Also, the absence of link layer identifiers referred to above, combined with the lack of checksums in the IPv6 header, basically means that any transmission element could be mistaken for any other, with no means of detecting the substitution at the network layer. The use of an upper-layer security mechanism of some kind seems like a really good idea.
[RFC1149]のセキュリティ上の考慮事項が適用されます。また、最近の経験が止まった場合は特に、伝送要素は、サービス拒否攻撃の多くの異なる形態にさらされていることを示唆しています。また、リンク層識別子が存在しないことは、基本的に任意の伝達要素は、ネットワーク層での置換を検出するためのない手段を、他と間違われることができることを意味し、IPv6ヘッダ内のチェックサムの欠如と組み合わせて、上記に言及しました。いくつかの種類の上位レイヤのセキュリティメカニズムの使用は本当に良いアイデアのように思えます。
There is a known risk of infection by the so-called H5N1 virus. Appropriate detection and quarantine measures MUST be available.
いわゆるH5N1ウイルスによる感染の既知の危険があります。適切な検出および検疫措置が利用可能でなければなりません。
This document requests no action by IANA. However, registry clean-up may be necessary after interoperability testing, especially if multicast has been attempted.
この文書は、IANAによって何のアクションを要求しません。しかし、レジストリのクリーンアップは、マルチキャストが試みられている場合は特に、相互運用性テストの後に必要になることがあります。
Steve Deering was kind enough to review this document for conformance with IPv6 requirements. We acknowledge in advance the many errata in this document that will be reported by Alfred Hoenes.
スティーブデアリングは、IPv6の要件への適合のために、この文書をレビューする親切でした。私たちは、事前にアルフレッドHoenesによって報告されます。この文書に記載されている多くの正誤表を認めます。
This document was produced using the xml2rfc tool [RFC2629].
この文書は、xml2rfcツール[RFC2629]を使用して製造しました。
[RFC1149] Waitzman, D., "Standard for the transmission of IP datagrams on avian carriers", RFC 1149, April 1990.
[RFC1149] Waitzman、D.、RFC 1149、1990年4月 "標準鳥類のキャリア上のIPデータグラムの送信のために"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC2675]ボーマン、D.、デアリング、S.、およびR. Hindenと "IPv6のジャンボグラム"、RFC 2675、1999年8月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[IPv6-PREFIXLEN] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-bit IPv6 Prefixes on Inter-Router Links", Work in Progress, October 2010.
[IPv6の-のprefixlen]河野、M.、Nitzan、B.、ブッシュ、R.、松崎、Y.、Colitti、L.、及びT. Narten氏、 "ルータ間のリンク上の127ビットのIPv6プレフィックスを使用する"、仕事プログレス10月2010インチ
[RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, February 1988.
"IEEE 802ネットワーク上でIPデータグラムの送信の規格" [RFC1042]ポステル、J.、およびJ.レイノルズ、STD 43、RFC 1042、1988年2月。
[RFC2549] Waitzman, D., "IP over Avian Carriers with Quality of Service", RFC 2549, April 1999.
[RFC2549] Waitzman、D.、 "サービスの品質を持つ鳥類キャリアによるIP"、RFC 2549、1999年4月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]ローズ、M.、 "ライティングI-DSおよびXMLを使用しているRFC"、RFC 2629、1999年6月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, October 2010.
[RFC6036]大工、B.とS.江、 "IPv6の展開のための新興サービスプロバイダーのシナリオ"、RFC 6036、2010年10月。
Authors' Addresses
著者のアドレス
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand
オークランドPB 92019オークランド、1142年ニュージーランドのコンピュータサイエンス大学のブライアン・カーペンター部門
EMail: brian.e.carpenter@gmail.com
メールアドレス：brian.e.carpenter@gmail.com
Robert M. Hinden Check Point Software Technologies, Inc. 800 Bridge Parkway Redwood City, CA 94065 US
ロバートM. Hindenとは、ポイント・ソフトウェア・テクノロジーズ株式会社800橋パークウェイレッドウッドシティ、CA 94065米国をチェック
Phone: +1.650.387.6118 EMail: bob.hinden@gmail.com
電話：+1.650.387.6118電子メール：bob.hinden@gmail.com