RFC 7514 - Really Explicit Congestion Notification (RECN) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7514
タイトル : RFC 7514 - Really Explicit Congestion Notification（RECN）
翻訳編集 : 自動生成

[要約] RFC 7514は、RECN（Really Explicit Congestion Notification）に関する規格であり、ネットワークの過負荷状態を明示的に通知するための手法を提供します。その目的は、ネットワークの適切な制御とパフォーマンスの向上を実現することです。

Independent Submission                                         M. Luckie
Request for Comments: 7514                                         CAIDA
Category: Experimental                                      1 April 2015
ISSN: 2070-1721

Really Explicit Congestion Notification (RECN)

Really Explicit Congestion Notification（RECN）

Abstract

概要

This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals provided by packet loss and Explicit Congestion Notification (ECN).

このドキュメントは、パケット損失と明示的輻輳通知（ECN）によって提供される他の信号をホストが無視する場合に、ルーターまたはホストがホストに送信速度を下げるようにアドバイスするために使用できる新しいICMPメッセージを提案します。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. 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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7514.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7514で入手できます。

著作権表示

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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  RECN Message Format . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Advice to Implementers  . . . . . . . . . . . . . . . . .   3
     2.2.  Relationship to ICMP Source Quench  . . . . . . . . . . .   4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1. Introduction

1. はじめに

The deployment of Explicit Congestion Notification (ECN) [RFC3168] remains stalled. While most operating systems support ECN, it is currently disabled by default because of fears that enabling ECN will break transport protocols. This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals such as packet loss and ECN. We call this message the "Really Explicit Congestion Notification" (RECN) message because it delivers a less subtle indication of congestion than packet loss and ECN.

明示的輻輳通知（ECN）[RFC3168]の展開は停止したままです。ほとんどのオペレーティングシステムはECNをサポートしていますが、ECNを有効にするとトランスポートプロトコルが機能しなくなる恐れがあるため、現在デフォルトでは無効になっています。このドキュメントは、ホストがパケット損失やECNなどの他の信号を無視する場合に、ルーターまたはホストがホストに送信速度を下げるようにアドバイスするために使用できる新しいICMPメッセージを提案します。このメッセージは、「Really Explicit Congestion Notification」（RECN）メッセージと呼ばれます。これは、パケット損失やECNよりも輻輳の微妙な兆候が少ないためです。

1.1. Requirements Language

1.1. 要件言語

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 RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

2. RECN Message Format

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              |

Type

タイプ

IPv4: 4

IPv4：4

IPv6: 201

IPv6：201

Code

コード

０

Checksum

チェックサム

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. When an RECN message is encapsulated in an IPv6 packet, the computation includes a "pseudo-header" of IPv6 header fields as specified in Section 8.1 of [RFC2460]. For computing the checksum, the checksum field is first set to zero.

チェックサムは、ICMPタイプフィールドで始まるICMPメッセージの1の補数合計の16ビットの1の補数です。 [RFC2460]のセクション8.1で指定されているように、RECNメッセージがIPv6パケットにカプセル化されている場合、計算にはIPv6ヘッダーフィールドの「疑似ヘッダー」が含まれます。チェックサムを計算するために、チェックサムフィールドは最初にゼロに設定されます。

Explicit Notification

明示的な通知

A 4-byte value that conveys an explicit notification in the ASCII format defined in [RFC20]. This field MUST NOT be set to zero.

[RFC20]で定義されているASCII形式で明示的な通知を伝える4バイトの値。このフィールドはゼロに設定してはいけません。

Description

説明

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メッセージは、他の競合するフローに対して永続的に不公平なレートでトラフィックを生成し、以前のパケット損失またはECNマークに反応していないホストに応答して、ルーターによって送信される必要があります（SHOULD）。

The contents of an RECN message MUST be conveyed to the user responsible for the traffic. Precisely how this is accomplished will depend on the capabilities of the host. If text-to-speech capabilities are available, the contents should be converted to sound form and audibly rendered. If the system is currently muted, a pop-up message will suffice.

RECNメッセージの内容は、トラフィックを担当するユーザーに伝達する必要があります。正確にこれがどのように達成されるかは、ホストの機能に依存します。テキスト読み上げ機能が利用可能な場合は、コンテンツをサウンド形式に変換し、音声でレンダリングする必要があります。システムが現在ミュートされている場合は、ポップアップメッセージで十分です。

2.1. Advice to Implementers

2.1. 実装者へのアドバイス

As the Explicit Notification field is only 4 bytes, it is not required that the word be null terminated. A client implementation should be careful not to use more than those 4 bytes. If a router chooses a word less than 4 bytes in size, it should null-terminate that word.

明示的通知フィールドは4バイトしかないため、ワードをヌルで終了する必要はありません。クライアントの実装では、これらの4バイトを超えて使用しないように注意する必要があります。ルーターがサイズが4バイト未満の単語を選択した場合、その単語はnullで終了する必要があります。

A router should not necessarily send an RECN message every time it discards a packet due to congestion. Rather, a router should send these messages whenever it discards a burst of packets from a single sender. For every packet a router discards in a single burst, it should send an RECN message. A router may form short sentences composed of different 4-byte words, and a host should play these sentences back to the user. 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.

ルーターは、輻輳のためにパケットを破棄するたびに、必ずしもRECNメッセージを送信する必要はありません。むしろ、ルーターは、単一の送信者からのパケットのバーストを破棄するたびにこれらのメッセージを送信する必要があります。ルーターが単一のバーストで破棄するすべてのパケットに対して、ルーターはRECNメッセージを送信する必要があります。ルーターは、異なる4バイトの単語で構成される短い文章を形成する場合があり、ホストはこれらの文章をユーザーに再生する必要があります。ルータは、送信者が以前のRECNメッセージに応答して送信レートを調整していないと判断した場合、明示通知フィールドのコンテンツをエスカレートする場合があります。内容または文の長さのいずれかで、エスカレーションの強度に上限はありません。

2.2. Relationship to ICMP Source Quench

2.2. ICMPソースクエンチとの関係

The RECN message was inspired by the ICMP Source Quench message, which is now deprecated [RFC6633]. Because the RECN message uses a similar approach, an RECN message uses the same ICMP type when encapsulated in IPv4 as was used by the ICMP Source Quench message.

RECNメッセージはICMP Source Quenchメッセージに触発されましたが、現在は非推奨です[RFC6633]。 RECNメッセージは同様のアプローチを使用するため、RECNメッセージは、IPv4でカプセル化されるときに、ICMPソースクエンチメッセージで使用されたものと同じICMPタイプを使用します。

3. IANA Considerations

3. IANAに関する考慮事項

This is an Experimental RFC; the experiment will conclude two years after the publication of this RFC. During the experiment, implementers are free to use words of their own choosing (up to four letters) in RECN messages. If RECN becomes a Standard of any kind, a list of allowed words will be maintained in an IANA registry. There are no IANA actions required at this time.

これは試験的なRFCです。実験は、このRFCの公開から2年後に終了します。実験中、実装者はRECNメッセージ内で自由に選択した単語（最大4文字）を自由に使用できます。 RECNが何らかの標準になると、許可された単語のリストがIANAレジストリに保持されます。現在、IANAのアクションは必要ありません。

4. Security Considerations

4. セキュリティに関する考慮事項

ICMP messages may be used in various attacks [RFC5927]. An attacker may use the RECN message to cause a host to reduce their transmission rate for no reason. 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.

ICMPメッセージはさまざまな攻撃で使用される可能性があります[RFC5927]。攻撃者はRECNメッセージを使用して、ホストに理由なく送信レートを低下させる可能性があります。このような攻撃を防ぐには、ホストは引用されたメッセージがシステムのアクティブフローに対応していることを確認する必要があり、RECNメッセージがIPv4パケットで運ばれる場合、攻撃者は[RFC3514]で定義されたセキュリティフラグを1に設定する必要があります。

5. Normative References

5. 引用文献

[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>.

[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、1969年10月、<http://www.rfc-editor.org/info/rfc20>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月、<http://www.rfc-editor.org/info/rfc2460>。

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.

[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、2001年9月、<http://www.rfc-editor.org / info / rfc3168>。

[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 2003, <http://www.rfc-editor.org/info/rfc3514>.

[RFC3514] Bellovin、S。、「IPv4ヘッダーのセキュリティフラグ」、RFC 3514、2003年4月、<http://www.rfc-editor.org/info/rfc3514>。

[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010, <http://www.rfc-editor.org/info/rfc5927>.

[RFC5927] Gont、F。、「TCPに対するICMP攻撃」、RFC 5927、2010年7月、<http://www.rfc-editor.org/info/rfc5927>。

[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, May 2012, <http://www.rfc-editor.org/info/rfc6633>.

[RFC6633] Gont、F。、「Deprecation of ICMP Source Quench Messages」、RFC 6633、May 2012、<http://www.rfc-editor.org/info/rfc6633>。

Author's Address

著者のアドレス

Matthew Luckie CAIDA University of California, San Diego 9500 Gilman Drive La Jolla, CA 92093-0505 United States

マシューラッキーCAIDAカリフォルニア大学サンディエゴ9500ギルマンドライブラホーヤCA 92093-0505アメリカ合衆国

   EMail: mjl@caida.org