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 RFC 1149 の 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 Editor によって公開を承認をされた文書はイ ンターネット標準のいかなるレベルの候補でもない。RFC 5714 の第２章参照。 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. 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 トラストの法律 条項の対象である。この文書に関連する読者の権利と制限が記述されている ので、これらの条項は注意深く読んでほしい。 Carpenter & Hinden Informational [Page 1] RFC 6214 IPv6 and RFC 1149 1 April 2011 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 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. Introduction 1. はじめに 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 データグラ ムを転送する方法を規定することの方が必要だ。この文書ではそのような仕様 を提供する。 2. Normative Notation 2. 標準的表記法 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"(必須)、"SHALL"(すること)、"SHALL NOT" (しないこと)、"SHOULD"(した方が良い)、"SHOULD NOT"(しない方が良い)、 "RECOMMENDED"(推奨)、"MAY"(しても良い)、"OPTIONAL"(省略可能)は [RFC 2119] で記述されている意味で解釈するものとする。 3. Detailed Specification 3. 詳細な仕様 Unless otherwise stated, the provisions of [RFC1149] and [RFC2460] apply throughout. 特記なき場合、[RFC1149] と [RFC2460] の規定は完全に適用される。 3.1. Maximum Transmission Unit 3.1. 最大転送単位 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 Carpenter & Hinden Informational [Page 2] RFC 6214 IPv6 and RFC 1149 1 April 2011 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 ミリグラムが 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 のパフォーマンスにも影響する。 3.2. Frame Format 3.2. フレームフォーマット 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. これによる一つの重要な結果として、２つのプロトコルスタックの実装が必要 となり [RFC4213]、受信者は IPv4 パケットと IPv6 パケットの分離のためだ けに、全てのパケットの最初の４ビットが示す IP プロトコルのバージョンを 調査 *しなければならない* 。 3.3. Address Configuration 3.3. アドレス構成 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 で指定された伝送要素は、通常はこのため には十分に安定しておらず、横風があるときわめて不安定になるかもしれない。 Carpenter & Hinden Informational [Page 3] RFC 6214 IPv6 and RFC 1149 1 April 2011 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. ほとんどの実装では、リンクの両端は unnumbered のままであり、あるいは /127 プリフィックスと静的アドレスが割り当てられても *良い* 。 さらなる議論については [IPv6-PREFIXLEN] を見ること。 3.4. Multicast 3.4. マルチキャスト 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 マルチキャストマッピングはそのような問題の回避のために定義されて いない。 4. Quality-of-Service Considerations 4. サービス品質の考察 [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 に従って、異なるキャリアは異なるホップ単位の挙動が 実装されるだろう。 5. Routing and Tunneling Considerations 5. ルーティングとトンネリングの考察 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 パケットをトンネルする新しい方法を提供するかもしれないし、逆も 同様である。 Carpenter & Hinden Informational [Page 4] RFC 6214 IPv6 and RFC 1149 1 April 2011 However, the decapsulation mechanism is unclear at the time of this writing. しかし、カプセル化解除のメカニズムは、この執筆時点では明確ではない。 6. Multihoming Considerations 6. マルチホーミングの考察 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 と、実装可能な現仕様の 両方でのトポロジー上の基本的な制限と思われる。 7. Internationalization Considerations 7. 国際化の考察 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. ニュージーランドのような各所において、光子放射の背景レベルが極めて低い ときだけは、キャリアの多くは短いホップしかできない。これは、そのような 場所において、この方法の可用性やスループットに影響があるだろう。 8. Security Considerations 8. セキュリティについての考察 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 と呼ばれるウィルスによる感染のリスクが知られている。 適切な検出と隔離の方法を利用可能に *しなければならない* 。 9. IANA Considerations 9. IANA の意見 This document requests no action by IANA. However, registry clean-up may be necessary after interoperability testing, especially if multicast has been attempted. この文書は IANA が行動しないことを要求する。しかしながら、特にマルチキ ャストが試される場合は、相互運用テストの後で登録簿の清掃が必要とされる かもしれない。 10. Acknowledgements 10. 謝辞 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 によって報告されるであろうこの文 書の正誤表に対し、事前に謝意を表明します。 This document was produced using the xml2rfc tool [RFC2629]. このドキュメントは xml2rfc tool [RFC2629] を使って作製された。 Carpenter & Hinden Informational [Page 5] RFC 6214 IPv6 and RFC 1149 1 April 2011 11. References 11. 参照 11.1. Normative References 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. Informative References 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. Carpenter & Hinden Informational [Page 6] RFC 6214 IPv6 and RFC 1149 1 April 2011 [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. Authors' Addresses 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 Carpenter & Hinden Informational [Page 7]