[Joke-RFC] RFC8367 インターネットプロトコル（IP）パケットの不当破棄

# はじめに

* この文書は [RFC8367](https://www.rfc-editor.org/rfc/rfc8367.txt) を勉強と好奇心のため適当に訳したものです。
* 翻訳の正確さは全く保証しません。
* 誤字誤訳等の指摘はいつでも大歓迎です。

# Wrongful Termination of Internet Protocol (IP) Packets（インターネットプロトコル（IP）パケットの不当破棄）

* Independent Submission
* Request for Comments: 8367
* Category: Informational
* ISSN: 2070-1721

- T. Mizrahi
- Marvell
- J. Yallouz
- Intel
- 1 April 2018

## Abstract（要約）

> Routers and middleboxes terminate packets for various reasons.
> In some cases, these packets are wrongfully terminated.
> This memo describes some of the most common scenarios of wrongful termination of Internet Protocol (IP) packets and presents recommendations for mitigating them.

ルーターやミドルボックスは、さまざまな理由でパケットを破棄 [^1] する。
場合によっては、これらのパケットが不正に破棄されることがある。
このメモでは、インターネットプロトコル（IP）パケットの不正破棄の最も一般的なシナリオをいくつか説明し、それらを軽減するための推奨事項を示す。

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

> This document is not an Internet Standards Track specification; it is published for informational purposes.

この文書は、Internet Standards Track の仕様ではなく、情報提供を目的として公開している。

> 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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.

これは他のRFCストリームとは無関係に、RFCシリーズに貢献するものである。
RFCエディターは自らの裁量でこの文書の公開を選択し、その実装や配備の価値について何ら表明するものではない。
RFCエディターによって公開が承認された文書は、どのレベルのインターネット標準の候補にもならない。RFC 7841 の2章を参照のこと。

> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8367.

この文書の現在の状態、正誤表、それに対するフィードバックの提供方法に関する情報は、 https://www.rfc-editor.org/info/rfc8367 で得ることができる。

## Copyright Notice

```
   Copyright (c) 2018 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
   (https://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
   2. Abbreviations .................................................. 2
   3. Wrongful Termination Scenarios ................................. 3
      3.1. Color-Based Termination ................................... 3
      3.2. Age-Based Termination ..................................... 3
      3.3. Origin-Based Termination .................................. 4
      3.4. Length-Based Termination .................................. 4
      3.5. IP-Version-Based Termination .............................. 5
      3.6. Flag-Based Termination .................................... 5
   4. Security Considerations ........................................ 5
   5. IANA Considerations ............................................ 5
   6. Conclusion ..................................................... 6
   7. References ..................................................... 6
      7.1. Normative References ...................................... 6
      7.2. Informative References .................................... 6
   Authors' Addresses ................................................ 6
```

## 1.  Introduction（導入）

> IP packets are often terminated by network devices.
> In some cases, control-plane packets are terminated and processed by the local device, while in other cases packets are terminated (discarded) due to a packet filtering mechanism.
> Packet filtering is widely employed in network devices for sanity checking, policy enforcement, and security.
> IP routers and middleboxes, such as firewalls, often terminate packets that do not comply with a predefined policy.
> Unfortunately, some filtering policies cause false positive or unnecessary packet termination.
> Moreover, these wrongful terminations are sometimes biased and discriminate against packets based on their color, age, origin, length, or IP version.

IPパケットは、ネットワーク機器によって破棄されることが多い。
コントロールプレーンのパケットはローカルデバイスで破棄処理される場合もあれば、パケットフィルタリング機構によってパケットが破棄される場合もある。
パケットフィルタリングは、サニティチェック、ポリシーエンフォースメント、セキュリティのためにネットワーク機器に広く採用されている。
IPルーターやファイアウォールなどのミドルボックスは、事前に定義されたポリシーに従わないパケットを破棄することがよくある。
しかし、フィルタリングのポリシーによっては、誤検知や不要なパケット破棄が発生することがある。
さらに、これらの不正破棄は、色 [^2] 、年齢、出身、長さ、IPバージョンに基づいてパケットを差別する偏ったものであることがある。

> This memo discusses some of the most common scenarios of wrongful termination of IP packets and presents recommendations for preventing such discrimination.

このメモでは、IPパケットの不正破棄の最も一般的なシナリオについて説明し、そのような差別を防ぐための推奨事項を示す。

## 2.  Abbreviations（略語について）

> IP    Internet Protocol

IP インターネットプロトコル

> TTL   Time To Live

TTL データが破棄されるまでの時間（あるいは回数）

> OAM   Operations, Administration, and Maintenance

OAM 運用・管理・保守

## 3.  Wrongful Termination Scenarios（不当破棄のシナリオ）

### 3.1.  Color-Based Termination（色に基づく破棄）

#### Synopsis（概要説明）

> IP packets are terminated due to their color.

IPパケットは、その色によって破棄される。

#### Description（詳細説明）

> Routers often employ metering mechanisms [RFC4115].
> These mechanisms often support a color-aware mode, in which the packet's color (green, yellow, or red) is used as a criterion in the metering algorithm.
> This mode has been known to prefer green packets over red and yellow packets.

 ルータはしばしばメータリング機構 [RFC4115] を採用している。
 これらのメカニズムはしばしばカラーアウェアモードをサポートし、パケットの色(緑、黄、赤)をメータリングアルゴリズムの基準として使用する。
 このモードは、赤や黄色のパケットよりも緑のパケットを優先することが知られてる。

#### Recommendation（推奨事項）

> Use of color-blind metering is recommended, as it allows equal opportunity for packets of different colors.

異なる色のパケットに対し、均等に機会を与えるため、色消しメータリングの使用を推奨する。

### 3.2.  Age-Based Termination（年齢に基づく破棄）

#### Synopsis（概要説明）

> IP packets are terminated based on their TTL.

IPパケットは、そのTTLによって破棄される。

#### Description（詳細説明）

> The IPv4 TTL field [RFC791] and the IPv6 Hop Limit field [RFC8200] are used for loop prevention.
> These fields essentially represent the packet's age.
> A router that receives an IP packet with a TTL value of 0 or 1 typically terminates the packet.
> In this document, packets with a TTL or Hop Limit of 0 or 1 are referred to as 'senior packets'.

IPv4 TTLフィールド [RFC791] とIPv6 Hop Limitフィールド [RFC8200] は、ループ防止に使用される。
これらのフィールドは、基本的にパケットの年齢を表す。
TTL値が0または1のIPパケットを受信したルーターは、通常、そのパケットを破棄する。
この文書では、TTLまたはHop Limitが0または1のパケットを「シニアパケット」と呼ぶ。

#### Recommendation（推奨事項）

> When possible, the practice of reverse discrimination is recommended.
> Notably, senior packets have been known to be highly effective for OAM tasks, such as Hello [RFC2328] and Traceroute [RFC2151].
> Therefore, senior packets should not be easily dismissed; to the extent possible, senior packets should be used in control-plane protocols.

可能であれば、逆差別の実践が推奨される。
注目すべきは、Hello [RFC2328] や Traceroute [RFC2151] などのOAMタスクにおいて、シニアパケットが非常に効果的であることが知られていることである。
したがって、シニアパケットを簡単に破棄すべきではなく、可能な限り、シニアパケットはコントロール・プレーンのプロトコルで使用されるべきである。

### 3.3.  Origin-Based Termination（出身に基づく破棄）

#### Synopsis（概要説明）

> IP packets are terminated based on their origin (source IP address prefix).

IPパケットは、その出身（送信元IPアドレスのプレフィックス）に基づいて破棄される。

#### Description（詳細説明）

> Routers and middleboxes often perform IP address filtering.
> Packets are often discarded based on the prefix of their source IP address.
> In this memo, prefix-based source address filtering is referred to as origin-based filtering.
> While source IP address filtering is an acceptable technique for preventing security attacks performed by known attackers, filtering an entire prefix may lead to unnecessary termination of legitimate traffic.

ルーターやミドルボックスでは、IPアドレスのフィルタリングを行うことが多い。
パケットは、送信元IPアドレスのプレフィックスに基づいて破棄されることが多い。
このメモでは、プレフィックスに基づく送信元アドレスフィルタリングを出身に基づくフィルタリングと呼ぶ。
送信元 IP アドレスフィルタリングは、既知の攻撃者が行うセキュリティ攻撃を防ぐための手法として受け入れられるが、プレフィックス全体をフィルタリングすると、正当なトラフィックを不必要に破棄させることにつながる可能性がある。

#### Recommendation（推奨事項）

> Origin-based filtering should be limited, to the extent possible, so as not to punish an entire autonomous system for the crime of a single host.
> Individual address-based filtering should be preferred in cases where the address of the potential threat is well known.

出身に基づくフィルタリングは、単一のホストの犯罪によって自律システム全体が罰せられることのないよう、可能な限り制限されるべきである。
個々のアドレスに基づくフィルタリングは、潜在的な脅威のアドレスがよく知られている場合に優先されるべきだ。

### 3.4.  Length-Based Termination（長さに基づく破棄）

#### Synopsis（概要説明）

> Short IP packets are wrongfully terminated due to their length.

短いIPパケットは、その長さのために不正に破棄される。

#### Description（詳細説明）

> The minimum permissible size of an IPv4 [RFC791] packet is 20 octets, and the minimum size of an IPv6 [RFC8200] packet is 40 octets.
> However, due to the size limits of Ethernet, it is often the case that IP packets that are shorter than 46 octets are discarded.
> This is because the minimal Ethernet frame size is 64 octets, the minimal Ethernet header size is 14 octets, and the Ethernet Frame Check Sequence is 4 octets long (i.e., 64 - 14 - 4  = 46).
> In the context of this memo, legitimate IP packets that are less than 46 octets long are referred to as 'short IP packets'.

IPv4 [RFC791] のパケットの最小許容サイズは20オクテット、IPv6 [RFC8200] のパケットの最小許容サイズは40オクテットである。
しかし、イーサネットのサイズ制限により、46オクテットより短いIPパケットは破棄されることが多い。
これは、イーサネットフレームの最小サイズが64オクテット、イーサネットヘッダーの最小サイズが14オクテット、イーサネットフレームチェックシーケンスが4オクテット（つまり、 $64 - 14 - 4 = 46$ ）であることに起因している。
このメモでは、長さが46オクテット未満の正当なIPパケットを「短いIPパケット」と呼ぶ。

#### Recommendation（推奨事項）

> Short IP packets should not be discarded.
> The Ethernet frame length should be enforced at the Ethernet layer, while the IP layer should avoid discrimination of short IP packets.

短いIPパケットは廃棄されるべきではない。
イーサネットフレーム長はイーサネット層で強制され、IP層は短いIPパケットの差別を避けるべきである。

### 3.5.  IP-Version-Based Termination（IPバージョンに基づく破棄）

#### Synopsis（概要説明）

> IPv6 packets are terminated due to their version.

IPv6パケットはバージョンによって破棄される。

#### Description（詳細説明）

> Many routers and middleboxes are configured to process only IPv4 [RFC791] packets and to reject IPv6 [RFC8200] packets.

多くのルーターやミドルボックスは、IPv4 [RFC791] パケットのみを処理し、IPv6 [RFC8200] パケットを拒否するように設定されている。

#### Recommendation（推奨事項）

> It is quite unsettling that there are still networks in which IPv6 packets are deemed unwanted in the second decade of the 21st century.
> Indeed, IPv6 packets have a slightly shorter payload than IPv4 packets.
> However, they are essential to the future growth of the Internet.
> It is time for operators to finally give IPv6 its well-deserved opportunity.

21世紀になって20年近くも経っているにもかかわらず、IPv6パケットを不要と判断するネットワークが存在することは、非常に不安なことである。
確かに、IPv6パケットはIPv4パケットよりも若干ペイロードが少ない。
しかし、今後のインターネットの成長には欠かせないものである。
事業者は、ついにIPv6に当然の機会を与えるべき時が来たのだ。

### 3.6.  Flag-Based Termination（フラグに基づく破棄）

#### Synopsis（概要説明）

> IPv4 packets are terminated because their More Fragments (MF) flag is set.

IPv4パケットは、More Fragments (MF)フラグが設定されている場合、破棄される。

#### Description（詳細説明）

> Many routers and middleboxes are configured to discard fragmented packets.

多くのルーターやミドルボックスは、フラグメント化されたパケットを破棄するように設定されている。

#### Recommendation（推奨事項）

> A packet should not be discarded on the grounds of a flag it supports.
> All flags should be respected, as well as the features they represent.

パケットがサポートするフラグ [^3] を理由に破棄してはならない。
すべてのフラグは、それらが表す機能と同様に尊重されるべきである。

## 4.  Security Considerations（セキュリティに関する考慮事項）

> This memo proposes to practice liberality with respect to IP packet filtering in routers and middleboxes.
> Arguably, such a liberal approach may compromise security in some cases.
> Not only must security be done; it must also be seen to be done.

このメモでは、ルータやミドルボックスにおけるIPパケットフィルタリングに関して、自由な運用を提案している。
議論の余地なく、このような自由なアプローチは、場合によってはセキュリティを損なう可能性がある。
セキュリティは実行されなければならないだけでなく、実行されているように見えなければならない。

## 5.  IANA Considerations（IANAに関する考慮時候）

> This document has no IANA actions.

この文書にはIANAアクションはない。

## 6.  Conclusion（結論）

> This memo recommends that every router and middlebox be an Equal Opportunity Device, which does not discriminate on the basis of actual or perceived rate, color, age, origin, length, IP version, fragmentation characteristics, higher-layer protocols, or any other IP characteristic.

このメモでは、すべてのルーターとミドルボックスが、実際のレート、色、年齢、出身、長さ、IPバージョン、フラグメント特性、上位層プロトコル、またはその他のIP特性によって差別されない「機会均等装置」であることを推奨している。

## 7.  References

### 7.1.  Normative References

```
   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.
```

### 7.2.  Informative References

```
   [RFC2151]  Kessler, G. and S. Shepard, "A Primer On Internet and
              TCP/IP Tools and Utilities", FYI 30, RFC 2151,
              DOI 10.17487/RFC2151, June 1997,
              <https://www.rfc-editor.org/info/rfc2151>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <https://www.rfc-editor.org/info/rfc2328>.

   [RFC4115]  Aboul-Magd, O. and S. Rabie, "A Differentiated Service
              Two-Rate, Three-Color Marker with Efficient Handling of
              in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115,
              July 2005, <https://www.rfc-editor.org/info/rfc4115>.
```

## Authors' Addresses

```
   Tal Mizrahi
   Marvell
   Email: talmi@marvell.com


   Jose Yallouz
   Intel
   Email: jose@alumni.technion.ac.il
```

[^1]: おそらく「解雇」と掛けている
[^2]: おそらく「人種」「肌の色」と掛けている
[^3]: おそらく「国旗」「主義・主張」と掛けている