RFC 6214 "Adaptation of RFC 1149 for IPv6" 日本語訳 「IPv6のためのRFC 1149の適応「 Independent Submission B. Carpenter Request for Comments: 6214 Univ. of Auckland Category: Informational R. Hinden ISSN: 2070-1721 Check Point Software 1 April 2011 IPv6のためのRFC 1149の適応 概要 この文書は、RFC 1149のIPv4データグラムのための指定したのと同じ媒体を介してIPv6 データグラムの送信方法を指定します。 このメモの位置付け この文書では、インターネット標準化過程の仕様ではありません、それは情報目的のために 公開されています。 これは、他のいかなるRFCストリームに関係なく、RFCシリーズに貢献をしています。 RFC Editor は自らの裁量でこのドキュメントを公開することを選択しました。 そして、実装や展開においてのその価値に関して何らかの声明を出すことはありません。 RFC Editorによって公表の承認をされたドキュメントはインターネット標準のいかなる レベルの候補でもありません。RFC5714のセクション2を見てください。 このドキュメントの現在の状況、正誤表、フィードバックの提供の仕方の情報については、 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. このドキュメントはBCP78とこのドキュメントの公表日に実施されているIETFドキュメント に関するIETF信託の法律条項 (http://trustee.ietf.org/license-info) の適用を受けます。 それらにこの文章に関する権利と制限が記述されていますので、慎重にこれらの文章を 確認してください。 目次 1. はじめに .........................2 2. 標準の表記 ......................2 3. 詳細な仕様 ....................2 3.1. 最大伝送ユニット .................2 3.2. フレームの書式 .......................3 3.3. アドレス構成 ...................3 3.4. マルチキャスト .........................4 4. サービス品質の問題 ...............4 5. ルート設定とトンネリングの問題 .............4 6. マルチホーミングの問題 ..................5 7. 国際化問題 ..............5 8. セキュリティの問題 ....................5 9. IANA問題 ......................5 10. 謝辞 .......................5 11. 参照 ..........................6 11.1. 参照する参考文献 ...................6 11.2. 有益な参照文献 ..................6 1. はじめに [RFC6036]に示されるように、多くのサービスプロバイダーが積極的にIPv4アドレスの 差し迫った不足を軽減するためにIPv6を導入しようとしています。 これは、[RFC1149]を 実装している全てのサービスプロバイダに影響を与えるでしょう。 したがって、 サービスプロバイダが異なるメディアに移行せざるを得ないというよりは、実際のところ 緊急にRFC 1149メディアを介してIPv6データグラムを転送する方法を指定する必要があります。 このドキュメントではそのような仕様を提供しています。 2. 標準の表記 この文章中の「しなければならない(MUST)」、「してはならない(MUST NOT)」、 「必須である(REQUIRED)」、「SHALL(するものとする)」、「しないものとする(SHALL NOT)」、 「すべきである(SHOULD)」、「すべきではない(SHOULD NOT)」、「推奨される(RECOMMENDED)」、 「してもよい(MAY)」および「任意である(OPTIONAL)」のキーワードは、[RFC2119]に 記述されているとおりに解釈すべきである。 3. 詳細な仕様 特に断りのない限り、[RFC1149]と[RFC2460]の規定はあらゆる点で適用されます。 3.1. 最大転送ユニット RFC 1149で述べられたように、MTUは可変であり、一般にキャリアが年を取ると共に増加します。 RFC 2460で許可されている最小リンクMTUが1280オクテットなので、それより年を取った キャリアはIPv6に使わなければならないことを意味します。RFC 1149 では、年齢とミリグラム、 またはミリグラムとオクテットの正確な換算率を提供しません。換算率は実装に依存しますが、 ここでは例として、RFC1149で示された256ミリグラムが576オクテットのMTUに対応すると仮定します。 この場合、本仕様の典型的なMTUは少なくとも256*1280/576 でしょう(約569ミリグラムです)。 再び例に戻ると、これは少なくとも356日間以上のキャリア年齢を必要とするでしょう。 その上、MTU問題はキャリア年齢と非線形です。すなわち、若いキャリアはわずかなペイロードしか 運ぶことができません。大人のキャリアはジャンボグラム[RFC2675]を運ぶことができます。 そして、年を取ったキャリアは再びわずかなペイロードしか運ぶことができません。 また、キャリアの年齢や、製品の帯域幅への影響、したがってTCPの性能による輸送時間への 影響があります。 3.2. フレームの書式 RFC 1149 は、Ethertype更にはOSIリンクレイヤやSNAPヘッダ[RFC1042]などのどのような リンクレイヤタグの使用を指定していません。実際に、ヘッダスナップがRFC 1149キャリアに よって提供されたサービスの質を悪化させることが知られています。効率の観点から またネットワークの中を飛行する間のエネルギーの消費を防ぐために、そのような リンクタグレイヤーはIPv6パケットには不要です。したがってフレームフォーマットは [RFC2460]で定義される純粋はIPv6パケットであり、[RFC1149]で定義されるように エンコードとデコードされます。 このことによる重要な結果がdual-stack deployment[RFC4213]に使われています。 受け取り手は全てのパケットの最初の4ビットのIPプロトコルバージョンを調べなければならず、 IPv6とIPv6パケットが混合したものを分離するためにのみ使われます。 3.3. アドレス構成 リンク層プロトコルのいかなる形式の欠落も、リンクの一方の端を除いて何も対処する方法がないので、 リンクローカルアドレスを形成することができないことを意味します。 同様に、そもそもリンク層アドレスが存在しないため、IPv6ユニキャストアドレスを リンク層アドレスに写す方法がありません。ess to a link layer address, したがってIPv6 Neighbor Discovery [RFC4861] は不可能です。 実装にステートレスなアドレス自動設定[RFC4862]を使おうとすべきではありません。 このメカニズムは[RFC4291]と互換性のある方法で形成された安定したインタフェース識別子が 必要になることからの忠告です。 残念なことにRFC 1149で指定された伝送要素はこれをするのに十分には安定していないため、 横風に対してはきわめて不安定になるかも知れません。 ほとんどの配備では、リンクの両端は番号無しのままになるか、/127プリフィックの 静的アドレスが割り当てられるかも知れません。 さらなる議論に関しては[IPv6-PREFIXLEN] を見てください。 3.4. マルチキャスト RFC 1149 は、マルチキャストアドレスのマッピングを指定しません。 IPv4マルチキャスト配信の実装の試みは、パケットダイジェストの欠落により 転送エレメントに過大なノイズになることが報告されています。 現時点では、IPv6マルチキャストはそのような問題を避けるために指定されていません。 4. サービス品質の問題 [RFC2549] もIpv6の場合に適用されます。しかしながら、RFC 2549 の著者が差別化された サービスモデル[RFC2474]の有用性を考慮に入れていませんでした。 トラフィッククラスフィールド[RFC2460]にデフォルト以外の差分サービスコードポイント(DSCP)値を 入れて運んでいるIPv6パケットは、外部からDSCPが分かるように緑または青のインクを使って 特別にエンコードする必要があります。 RFC2549で指定される赤い塗料の使用法との混乱を避けるために、赤いインクを使用しては いけないことに注意してください。 RFC 2549は異なったタイプのキャリアのサービスの質への影響を考えていませんでした。 There is a broad range. あるものは非常に速いがわずかな貨物と短距離しか運べませんが、 またあるものは遅いですが大容量と長距離を運ぶことができます。 DSCP値に基づいてパケットの個々のキャリアを選択することが適切かも知れません。 実際に、異なったキャリアはRFC 2474に応じた異なるホップ単位の挙動が実装されるでしょう。 5. ルート設定とトンネリングの問題 ピアリング契約をせずに同じようなキャリアのテリトリをキャリアに通らせると、 不意のルート変更や、パケットのルーピング、配信の順番違いが発生することがあるでしょう。 同様に、捕食性のキャリアのなわばりを通るキャリアは潜在的にパケットをロスする可能性があります。 ルーティングテーブルを作成するために使われるルーティングアルゴリズムにそれらの要素を 考慮することをお勧めします。 実装者は、なわばりや捕食性のキャリアを迂回することで 信頼性の高いパケット配信を保障するポリシーに基づいたルーティングを考慮すべきです。 一部のキャリアには他のキャリアを捕食し、その食べた荷物を運ぶ傾向があるという証言があります。 ひょっとしたら、このことはIPv6ペイロードにIPv4パケットをトンネルする新しい方法を 提供するかも知れません。逆もまた同様です。 しかしながら、カプセル解除のメカニズムはこの執筆時点では明らかにされていません。 6. マルチホーミングの問題 あるキャリアは帰巣性が高いことで有名です。驚いたことにこの特性はRFC 1149では言及されていません。 残念ながら、彼らはマルチホーミングの才能がないことが判明しており、 実際マルチホーミングを試みるとループルーティングに陥ります。 これは RFC 1149と現在の仕様の両方で配備可能なトポロジ条の基本的な制限のように思われます。 7. 国際化問題 ニュージーランドのような場所では、ほとんどのキャリアはバックグラウンドの光子放射が 極めて低い時には短いホップしかできません。 このことは、そのような場所でのこの方法の可用性やスループットに影響があります。 8. セキュリティ問題 [RFC1149]のセキュリティ問題が適用されます。それに加えて、最近の経験では特に休んでいる時に 伝達要素が多くの異なった形式のサービス不能攻撃にさらされていることを示しています。 また、上で言及されたリンクレイヤーの識別子が存在しないことは、IPv6ヘッダにチェックサムが 存在しないこととあわせて、ネットワークレイヤーでの置き換えが検出する手段がないため、 基本的に伝達要素を他のものと区別できないことを意味します。 いくつかの種類の上位層でのセキュリティメカニズムを使用することが 本当に良い考えのように思えます。 いわゆるH5N1ウィルスによる既知の感染のリスクがあります。 適切な検出と隔離方法を利用可能にすべきです。 9. IANA問題 このドキュメントはIANAによるアクションを全く要求しません。 しかしながら、特にマルチキャストを考えている場合には相互運用テストの後で レジストリの清掃が必要になるかも知れません。 10. 謝辞 Steve Deering は親切なことにこのドキュメントがIPv6要件に準拠しているかどうかを精査してくれた。 このドキュメントの正誤表を報告してくれるであろうAlfred Hoenesに前もって謝辞を表します。 このドキュメントはxml2rfc tool [RFC2629]を使って製作されました。 11. 参照 11.1. 参照する参考文献 [RFC1149] Waitzman, D., "Standard for the transmission of IP datagrams on avian carriers", RFC 1149, April 1990. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [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. [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. 11.2. 有益な参考文献 [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. [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, February 1988. [RFC2549] Waitzman, D., "IP over Avian Carriers with Quality of Service", RFC 2549, April 1999. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, October 2010. 著者のアドレス Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand EMail: brian.e.carpenter@gmail.com 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