[要約] RFC 6214は、IPv6におけるRFC 1149の適応に関するものであり、IPパケットの転送を鳥による物理的な運搬によって行うことを提案しています。その目的は、ユニークなネットワーキングソリューションを提供し、ユーザーに新たな通信手段を提供することです。
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 RFC 1149 for IPv6
IPv6のRFC 1149の適応
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エディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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は、年齢とミリグラム、またはミリグラムとオクテットの間で正確な変換係数を提供しません。これらの変換係数は実装依存ですが、例として、RFC 1149で示唆されている256ミリグラムMTUが576オクテットのMTUに対応すると仮定します。その場合、現在の仕様の典型的なMTUは、少なくとも256*1280/576で、これは約569ミリグラムです。繰り返しになりますが、これには少なくとも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は、EtherTypeまたはさらに悪いことに、OSIリンクレイヤーまたはSNAPヘッダー[RFC1042]などのリンクレイヤータグの使用を指定していません。実際、ヘッダースナップは、RFC 1149キャリアが提供するサービスの質を悪化させることが知られています。効率性のために、ネットワークを介してパケットが飛行中に過度のエネルギー消費を回避するために、IPv6パケットにもそのようなリンクレイヤータグは必要ありません。したがって、フレーム形式は[RFC2460]で定義されている純粋なIPv6パケットであり、[RFC1149]で定義されているようにエンコードおよびデコードされます。
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.
これの重要な結果の1つは、デュアルスタックの展開[RFC4213]で、受信者はすべてのパケットの最初の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.
ほとんどの展開では、リンクのエンドポイントのいずれかが自己負担のままであるか、A /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]。トラフィッククラスフィールド[RFC2460]に非デフォルト差別化サービスコードポイント（DSCP）値を運ぶ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.
Steve Deeringは、IPv6要件に準拠してこのドキュメントをレビューするのに十分親切でした。Alfred Hoenesによって報告されるこのドキュメントの多くのErrataを事前に認めます。
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。、「鳥類のキャリアでのIPデータグラムの送信の標準」、RFC 1149、1990年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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.ヒンデン、「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. Gilligan、「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] Kohno、M.、Nitzan、B.、Bush、R.、Matsuzaki、Y.、Colitti、L。、およびT. Narten、「ルーター間リンクで127ビットIPv6プレフィックスを使用」、作業進行中、2010年10月。
[RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, February 1988.
[RFC1042] Postel、J。およびJ. Reynolds、「IEEE 802ネットワークを介したIPデータグラムの送信の標準」、STD 43、RFC 1042、1988年2月。
[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] Rose、M。、「XMLを使用したI-DSおよびRFCの書き込み」、RFC 2629、1999年6月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「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.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, October 2010.
[RFC6036] Carpenter、B。およびS. Jiang、「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
Robert M. Hinden Check Point Software Technologies, Inc. 800 Bridge Parkway Redwood City, CA 94065 US
Robert M. Hinden Check Point Software Technologies、Inc。800 Bridge Parkway Redwood City、CA 94065 US
Phone: +1.650.387.6118
EMail: bob.hinden@gmail.com