Independent Submission M. Luckie Request for Comments: 7514 CAIDA Category: Experimental 1 April 2015 ISSN: 2070-1721 本当の明示的輻輳通知(RECN) 概要 この文章は、ホストがパケットロスおよび明示的輻輳通知 (ECN)によって提供されるシグナルを無視した場合に、ルータあるいはホストが、そのホストに送信する速度を下げるように伝えるために使われるかも知れない新しいICMPメッセージを提案します。 このメモの位置付け この文書では、インターネット標準化過程の仕様ではありません、それは調査、実験的な実装および評価のために公開されています。 このドキュメントはインターネットコミュニティのための実験的なプロトコルを定義します。 これは、他のいかなるRFCストリームに関係なく、RFCシリーズに貢献をしています。 RFC Editor は自らの裁量でこのドキュメントを公開することを選択しました。そして、実装や展開においてのその価値に関して何らかの声明を出すことはありません。 RFC Editorによって公表の承認をされたドキュメントはインターネット標準のいかなるレベルの候補でもありません。RFC5714のセクション2を見てください。 このドキュメントの現在の状況、正誤表、フィードバックの提供の仕方の情報については、http://www.rfc-editor.org/info/rfc7168 で得られるでしょう。 http://www.rfc-editor.org/info/rfc7514. 著作権 Copyright (c) 2015 IETF Trust and the persons identified as the document authors. 無断転載禁ず このドキュメントはBCP78とこのドキュメントの公表日に実施されているIETFドキュメントに関するIETF信託の法律条項 (http://trustee.ietf.org/license-info) の適用を受けます。 それらにこの文章に関する権利と制限が記述されていますので、慎重にこれらの文章を確認してください。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. 言語要件 . . . . . . . . . . . . . . . . . . 2 2. RECN メッセージ書式 . . . . . . . . . . . . . . . . . . . . . 2 2.1. 実装のアドバイス . . . . . . . . . . . . . . . . . 3 2.2. ICMP ソース クエンチとの関係 . . . . . . . . . . . 4 3. IANA 問題. . . . . . . . . . . . . . . . . . . . 4 4. セキュリティ問題. . . . . . . . . . . . . . . . . . 4 5. 参照する参考文献. . . . . . . . . . . . . . . . . . . 4 著者のアドレス . . . . . . . . . . . . . . . . . . . . . . . . 5 1. はじめに 明示的輻輳通知 (ECN) [RFC3168] の配備は停滞しています。 ほとんどのOSは ECN をサポートしますが、ECNを有効にすると転送プロトコルを破壊するという恐れから、現在のところデフォルトでは無効にされています。 この文章は、ホストがパケットロスおよび ECNのようなシグナルを無視した場合に、ルータあるいはホストが、そのホストに送信する速度を下げるように伝えるために使われるかも知れない新しいICMPメッセージを提案します。 パケットロスおよびECNよりわずかに少ない輻輳の指標を届けるので、このメッセージを "本当に明示的輻輳通知" と呼びます。 1.1. 必要条件 この文章中の「しなければならない(MUST)」、「してはならない(MUST NOT)」、「必須である(REQUIRED)」、「SHALL(するものとする)」、「しないものとする(SHALL NOT)」、「すべきである(SHOULD)」、「すべきではない(SHOULD NOT)」、「推奨される(RECOMMENDED)」、「してもよい(MAY)」および「任意である(OPTIONAL)」のキーワードは、[RFC2119]に記述されているとおりに解釈すべきである。[RFC2119] 2. RECN メッセージフォーマット 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Explicit Notification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As much of the invoking packet as possible | + without the ICMP packet exceeding 576 bytes | | in IPv4 or the minimum MTU in IPv6 | 種類 IPv4: 4 IPv6: 201 Code 0 チェックサム The checksum is the 16-bit ones's complement of the one's complement sum of the ICMP message starting with the ICMP type field. RECNメッセージが IPv6パケットの中にカプセル化される場合、計算には [RFC2460]のセクション8.1で定義される IPv6ヘッダの ”pseudo-header" が含まれます。 チェックサムの計算のために、チェックサムフィールドは最初は0に設定されます。 明示的な通知 明示的な通知を運ぶ[RFC20]で定義されたアスキーフォーマットの4バイト。 フィールドは0に設定してはいけません。 解説 An RECN message SHOULD be sent by a router in response to a host that is generating traffic at a rate persistently unfair to other competing flows and that has not reacted to previous packet losses or ECN marks. RECNメッセージの内容はトラフィックに責任があるユーザへ運ばれなければなりません。 これをどう行うかの詳細は、ホストの機能によるでしょう。 もし text-to-speech 機能が利用可能であれば、内容は音の形式に変換され聞こえるように表現されなければなりません。 システムが現在のところ静かであれば、ポップアップメッセージで十分でしょう。 2.1. 実装のアドバイス 明示的通知フィールドは4バイトだけのため、nullで終わる単語は必要ありません。 クライアントの実装は4バイトより多くを使わないように注意すべきです。 ルータが4バイトより少ないサイズの単語を選択した場合は、単語の終わりにnullを入れるべきです。 ルータは、輻輳によるパケットを破棄する度にRECNメッセージを送信する必要はありません。 むしろ、ルータは単一の送信者からの急激なパケットの増加を破棄するたびに、これらのメッセージを送信すべきです。 ルータが一つの急激な増加を破棄したパケットごとに、ルータはRECNメッセージを送信すべきです。 ルータは異なる4バイトの単語からなる短い文章を形成するかも知れません。ホストはそれらの文章をユーザに提示すべきです。 A router may escalate the content in the Explicit Notification field if it determines that a sender has not adjusted its transmission rate in response to previous RECN messages. There is no upper bound on the intensity of the escalation, either in content or sentence length. 2.2. ICMP ソース クエンチとの関係 RECNメッセージはICMPソース クエンチによって着想されました。これは今では非推奨です [RFC6633] RECNメッセージは似たような方法を使用しているため、IPv4にカプセル化する場合は ICMPソースクエンチメッセージで使われたのと同じICMPタイプをRECNメッセージは使用しなければなりません。 3. IANA問題 これは実験的なRFCです; 実験はこのRFCが公開された後で2年で完了するでしょう。 実験の間、実装者は自身が選択した単語(4文字まで)をRECNメッセージの中で自由に使うことができます。RECN がなんからの標準になった場合、許可された単語のリストがIANAレジストリで整備されるでしょう。 現在のところ、IANAの動きは要求されていません。 4. セキュリティ問題 ICMP メッセージは様々な攻撃に使われるかもしれません [RFC5927]。 攻撃者は、意味も無くホストの転送を減らすためにRECNメッセージを使用するかも知れません。 To prevent such an attack, a host must ensure the quoted message corresponds to an active flow on the system, and an attacker MUST set the security flag defined in [RFC3514] to 1 when the RECN message is carried in an IPv4 packet. 5. 参照する参考文献 [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969, . [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, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001, . [RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 2003, . [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010, . [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, May 2012, . Author's Address Matthew Luckie CAIDA University of California, San Diego 9500 Gilman Drive La Jolla, CA 92093-0505 United States EMail: mjl@caida.org