はじめに

この文書は RFC7514 を勉強と好奇心のため適当に訳したものです。
翻訳の正確さは全く保証しません。
誤字誤訳等の指摘はいつでも大歓迎です。

Really Explicit Congestion Notification (RECN)（本当の明示的輻輳通知）

Independent Submission
Request for Comments: 7514
Category: Experimental
ISSN: 2070-1721

M. Luckie
CAIDA
1 April 2015

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).

本書では、ルータやホストがパケットロスや明示的輻輳通知 (Explicit Congestion Notification; ECN) による他のシグナルを無視した場合に、送信レートを下げるようアドバイスするために使用する新しい ICMP メッセージを提案する。

Status of This Memo（このメモの位置づけ）

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

この文書は、インターネット標準過程の仕様ではなく、検討、実験的実装、評価のために公開されるものである。

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 エディターによって公開が承認された文書は、どのレベルのインターネット標準の候補にもならない。

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 で得ることができる。

Copyright Notice

   Copyright (c) 2015 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.

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（導入）

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.

明示的輻輳通知(Explicit Congestion Notification; ECN) [RFC3168] の展開は、依然として停滞している。
ほとんどのオペレーティングシステムが ECN をサポートしているが、ECN を有効にするとトランスポートプロトコルが破壊される恐れがあるため、現在はデフォルトで無効になっている。
この文書では、ホストがパケットロスや ECN などの他のシグナルを無視する場合に、ルータやホストが送信レートを下げるよう助言するために使用する新しい ICMP メッセージを提案する。
このメッセージは、パケットロスやECNよりも輻輳の微妙な兆候を伝えるため、「Really Explicit Congestion Notification」（RECN）メッセージと呼ぶ。

1.1. Requirements Language（要求仕様言語）

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（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 で 576 バイトあるいは IPv6 であれば最小 MTU を超えない範囲で、呼び出しパケットを可能な限り増やす）

Type（タイプ）

IPv4: 4

IPv6: 201

（略）

Code（コード）

0

（略）

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 の補数である。
RECN メッセージが IPv6 パケットにカプセル化されている場合、[RFC2460] の8.1節に規定されているように、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 バイトの値。
このフィールドはゼロに設定してはならない(MUST NOT)。

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メッセージのコンテンツは、トラフィックに責任を持つユーザーに伝えられなければならない(MUST)。
これをどのように行うかは、ホストの能力に依存する。
音声合成機能が利用できる場合は、内容を音声に変換し、音声でレンダリングする必要がある。
システムが現在ミュートされている場合は、ポップアップメッセージで十分である。

2.1. Advice to Implementers（実装者への助言）

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.

Explicit Notification フィールドは 4 バイトしかないので、NULL 終端である必要はない。
クライアントの実装では、これらの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メッセージを送信する必要はない。
そうではなく、ルーターは、単一の送信者からのパケットのバーストを破棄するたびに、これらのメッセージを送信する必要がある。
ルーターは1つのバーストで廃棄するパケットごとに、RECN メッセージを送信する必要がある。
ルーターは異なる4バイトの単語からなる短い文章を形成することができ、ホストはこれらの文章をユーザーに再生する必要がある。
ルーターは、送信者が以前の RECN メッセージに応答して送信レートを調整しなかったと判断した場合、Explicit Notification フィールドのコンテンツをエスカレートすることがある。
内容や文の長さなど、エスカレーションの強さには上限はない。

2.2. Relationship to ICMP Source Quench（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 メッセージは、現在では非推奨 [RFC6633] となっている ICMP ソースクエンチメッセージから着想を得ている。
RECN メッセージは同様のアプローチを採用しているため、IPv4 でカプセル化された RECN メッセージは、ICMP ソースクエンチメッセージと同じ ICMP タイプを使用する。

3. IANA Considerations（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（セキュリティに関する考慮事項）

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にセットしなければならない(MUST)。

5. Normative References

   [RFC20]    Cerf, V., "ASCII format for network interchange", STD 80,
              RFC 20, October 1969,
              <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>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998,
              <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>.

   [RFC3514]  Bellovin, S., "The Security Flag in the IPv4 Header", RFC
              3514, April 2003,
              <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>.

   [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

   EMail: mjl@caida.org