[Joke-RFC] RFC8136 IPv6への追加の移行機能

# はじめに

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

# Additional Transition Functionality for IPv6（IPv6への追加の移行機能）

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

- B. Carpenter
- Univ. of Auckland
- R. Hinden
- Check Point Software
- 1 April 2017

## Abstract（概要）

> This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy.

本書では、IPv4からIPv6への移行を容易にし、かつIPv6のセキュリティとプライバシーを向上させることを目的とした追加機構を提案する。

## 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 a candidate 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 http://www.rfc-editor.org/info/rfc8136.

この文書の現在の状態、正誤表、それに対するフィードバックの方法に関する情報は、http://www.rfc-editor.org/info/rfc8136 で入手できる。

## Copyright Notice

```
   Copyright (c) 2017 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Required Function of All IPv4 Nodes . . . . . . . . . . . . .   2
   3.  Security Flag for IPv6 Packets  . . . . . . . . . . . . . . .   3
   4.  Advanced Solution . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Privacy Extension . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7
```

## 1.  Introduction（はじめに）

> In a recent statement [IABv6], the Internet Architecture Board deemed that the Internet Engineering Task Force is expected to "stop requiring IPv4 compatibility in new or extended protocols" and that future work will "optimize for and depend on IPv6".
> In the interest of promoting these goals, this memo makes an important change to IPv4 node requirements [RFC1122] and adds a missing security feature to IPv6 [RFC2460].

最近の声明 [IABv6] で、Internet Architecture Boardは、Internet Engineering Task Forceが「新規または拡張プロトコルにおけるIPv4互換性の要求を停止」し、今後の作業を「IPv6に最適化し依存する」ことが期待されるとみなした。
これらの目標を促進するために、このメモはIPv4ノード要件 [RFC1122] に重要な変更を加え、IPv6に欠けているセキュリティ機能を追加する [RFC2460]。


### 1.1.  Terminology（用語解説）

> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are not to be interpreted as described in [RFC2119].

本文書におけるキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、 [RFC2119] に記述されているように解釈してはいけない。

## 2.  Required Function of All IPv4 Nodes（全IPv4ノードの必須機能）

> To ensure that all routers, firewalls, load balancers, and other forms of middleboxes can readily identify IPv4 packets and deal with them appropriately (selective dropping, switching to the slow path through a router, sending them to the longest path first, etc.), all IPv4 nodes MUST set the security flag defined by [RFC3514] to 1.
> This should be sufficient to ensure that implementers of dual stack applications prefer IPv6 when given the choice, and that the Happy Eyeballs algorithm [RFC6555] will usually favour the IPv6 path.

すべてのルータ、ファイアウォール、ロードバランサ、および他の形態のミドルボックスがIPv4パケットを容易に識別し、それらを適切に処理できるようにするために(選択的ドロップ、ルータを通る遅いパスへの切り替え、最長パスへの最初の送信など)、すべてのIPv4ノードは [RFC3514] で定義されるセキュリティフラッグを1に設定しなければならない(MUST)。
デュアルスタックアプリケーションの実装者がIPv6を選択し、Happy Eyeballsアルゴリズム [RFC6555] が通常IPv6パスを優先することを保証するには、これで十分であるはずである。

https://qiita.com/yoshi389111/items/56e1724ca3d3a3d03351

## 3.  Security Flag for IPv6 Packets（IPv6パケットのセキュリティフラグ）

> The above requirement will somewhat nullify the practical effect of the IPv4 security flag for benign traffic, but this disadvantage can readily be overcome by adding an equivalent flag for IPv6; in fact, this is highly desirable to maintain feature equivalence between IPv4 and IPv6.
> Fortunately, this can easily be achieved since IPv6 supplies so many bits.
> The solution defined here is that the Security Flag bit for an IPv6 packet is simply the parity of the source address of the packet.
> In other words, if the source address contains an odd number of 1s, the flag is True; otherwise, it's False.
> All other considerations for the flag are exactly as described in [RFC3514].

上記の要件は、良性トラフィックに対するIPv4セキュリティフラグの実用的な効果をいくらか無効にするが、この欠点はIPv6に同等のフラグを追加することによって容易に克服することが可能である。
幸いなことに、IPv6では非常に多くのビットが提供されるため、これは容易に達成できる。
ここで定義されたソリューションは、IPv6パケットのセキュリティフラグビットは、単にパケットのソースアドレスのパリティであるということである。
言い換えれば、送信元アドレスに奇数の1が含まれていれば、フラグはTrueになり、そうでなければFalseになる。
このフラグに関する他のすべての考慮事項は、[RFC3514] に記述されている通りである。

> For an interface whose IPv6 address is set by Stateless Address Autoconfiguration [RFC4862], it is the host itself that determines the state of its security flag, by choosing an appropriate Interface Identifier value.
> Fortunately this is now possible and compatible with [RFC7136], [RFC7217], [RFC7421], and [RFC7721].

ステートレスアドレス自動設定 [RFC4862] によってIPv6アドレスが設定されるインターフェースでは、適切なインターフェース識別子の値を選択することによって、 そのセキュリティフラグの状態を決定するのはホスト自身である。
幸いなことに、これは現在可能であり、[RFC7136], [RFC7217], [RFC7421], [RFC7721] と互換性を持っている。

> For an interface whose IPv6 address is set by DHCPv6 [RFC3315] or manually, the network administrator is free to choose an Interface Identifier that provides the desired security flag that is also compatible with [RFC7721].

IPv6アドレスがDHCPv6 [RFC3315] または手動で設定されるインターフェイスの場合、 ネットワーク管理者は、[RFC7721] と互換性があり、望ましいセキュリティフラグを 提供するインターフェイス識別子を自由に選択することができる。

> An exception case is a link with a 127-bit prefix [RFC6164].
> Since there is only one bit available as an Interface Identifier, one end or the other will inevitably have its security flag set, and the other won't.
> In this case, the node at one end will simply interpret the other end's security flag to mean the opposite of what it says, and vice versa.

例外的なケースとして、127ビットのプレフィックスを持つリンクがある [RFC6164]。
インターフェイス識別子として使用できるビットは1つだけなので、必然的にどちらかの端にセキュリティフラグが設定され、もう一方には設定されないことになる。
この場合、一方の端のノードは、他方の端のセキュリティフラグを単純に逆の意味に解釈し、その逆もまた同様である。

> Since RFC 6164 is designed for links between routers, in the case where different ISPs are at each end of the link, it is normal operational practice for one ISP to consider the other ISP to be evil.

RFC 6164 はルーター間のリンクのために設計されているので、異なるISPがリンクの両端にある場合、一方のISPが他方のISPをEvilと見なすのは通常の運用方法である。

## 4.  Advanced Solution（高度な解決策）

> In the event that the previous solution proves too simple to deploy in practice, a more advanced solution is also defined.
> It uses a new IPv6 hop-by-hop User Security Flag Option (UFO).

また、従来のソリューションがシンプルすぎて実際に展開できない場合に備えて、より高度なソリューションも定義されている。
これは新しいIPv6ホップバイホップ ユーザーセキュリティフラグオプション(UFO)を使用する。

> The UFO is a hop-by-hop option that can be included in any IPv6 packet.
> Multiple UFOs MUST NOT be present in the packet.
> The UFO has no alignment requirement.
> Its format is as follows:

UFOは、任意のIPv6パケットに含めることができるホップバイホップオプションである。
複数のUFOがパケット内に存在してはならない(MUST NOT)。
UFOにはアライメントの要件はない。
その形式は次のとおり。

```
     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
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |  Option Type  | Option Length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | UserSecFlag   |
    +-+-+-+-+-+-+-+-+

                  User Security Flag Option Layout
```

> Option Type

オプションタイプ

> 8-bit identifier of the type of option.
> The option identifier for the User Security Flag Option (0x7g) has not been allocated by the IANA.

オプションの種類を示す8ビットの識別子。
ユーザーセキュリティフラグオプション(`0x7g`)のオプション識別子は、IANAによって割り当てられていない。

> Option Length

オプション長

> 8-bit unsigned integer.
> The length of the option (excluding the Option Type and Option Length fields).
> The value MUST be 1.

8ビットの符号なし整数である。
オプションの長さ(オプションタイプおよびオプション長フィールドを除く)。
値は1でなければならない(MUST)。

> UserSecFlag

ユーザーセキュリティフラグ

> 8-bit unsigned integer.
> Bit 0 has the functionality defined in [RFC3514].
> The other bits are reserved and MUST be zero or one.

8ビットの符号なし整数である
ビット0は [RFC3514] で定義された機能を持つ。
他のビットは予約されており、0または1でなければならない(MUST)。

### 4.1.  Privacy Extension（プライバシー拡張）

> The mechanism can be extended to add a privacy flag.
> With the mechanism of Section 3, the privacy flag could be encoded by using quaternary parity (CRC-2) to obtain an extra bit.
> However, this would waste considerable amounts of address space and SHOULD NOT be done.
> With the UFO mechanism, bit 1 of UserSecFlag is defined as the privacy flag.
> If set, it means that the packet contains private information and MUST NOT be inspected en route.
> All firewalls, monitoring devices, and government agencies MUST respect this rule.
> This option is expected to be much more computationally efficient than conventional privacy techniques like IPsec and Transport Layer Security (TLS) as no encryption or key management is required to achieve the desired privacy.

この仕組みを拡張して、プライバシーフラグを追加することも可能である。
3章のメカニズムでは、プライバシーフラグは4次パリティ(CRC-2)を使用して余分なビットを得ることによって符号化することができる。
しかし、これはかなりの量のアドレス空間を浪費するので、行うべきでない。
UFOメカニズムでは、UserSecFlagのビット1がプライバシーフラグとして定義されている。
このフラグが設定されている場合、パケットはプライベートな情報を含んでおり、経路上で検査されてはならない(MUST NOT)ことを意味する。
すべてのファイアウォール、監視装置、および政府機関はこの規則を尊重しなければならない(MUST)。
このオプションは、IPsecやTLS (Transport Layer Security)のような従来のプライバシー技術よりも、望ましいプライバシーを実現するために暗号化や鍵管理が必要ないため、はるかに計算効率が良いと予想される。

## 5.  Security Considerations（セキュリティに関する考察）

> The security considerations of [RFC3514] now apply to IPv6.
> However, with the security flag being set for all IPv4 packets, there is a risk that all IPv4 traffic will now be treated as a very distributed denial-of-service attack.

[RFC3514] のセキュリティに関する考慮事項がIPv6にも適用されるようになった。
しかし、セキュリティフラグがすべてのIPv4パケットに設定されることで、すべてのIPv4トラフィックが非常に分散したサービス拒否攻撃として扱われるようになる危険性がある。

> Given the recent experience with very large scale DDoS attacks from Internet of Things (IoT) devices like IP Cameras, phishing attacks, malware, etc., that occur on the IPv4 Internet, it is a safe assumption that all IPv4 packets are evil.

最近、IPカメラなどのIoT（Internet of Things）機器からの非常に大規模なDDoS攻撃、フィッシング攻撃、マルウェアなどがIPv4インターネット上で発生していることを考えると、IPv4パケットはすべてEvilだと考えてよいだろう。

> Since the mechanism described in Section 3 is compatible with [RFC7721], address privacy is not impacted.
> Also, with that mechanism, exactly half the IPv6 address space will indicate that the security flag is set, so we can assert that the IPv6 Internet is only half evil.

3章の仕組みは [RFC7721] と互換性があるため、アドレスのプライバシーに影響はない。
また、そのメカニズムでは、IPv6アドレス空間のちょうど半分がセキュリティフラグが設定されていることを示すので、IPv6インターネットは半分だけEvilであると断言することができる。

## 6.  IANA Considerations（IANAに関する考察）

> This document does not require any IANA actions.

この文書は、IANA のアクションを必要としない。

## 7.  References

### 7.1.  Normative References

```
   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <http://www.rfc-editor.org/info/rfc1122>.

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

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

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <http://www.rfc-editor.org/info/rfc4862>.

   [RFC6164]  Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
              L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
              Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011,
              <http://www.rfc-editor.org/info/rfc6164>.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
              2012, <http://www.rfc-editor.org/info/rfc6555>.

   [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
              Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
              February 2014, <http://www.rfc-editor.org/info/rfc7136>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <http://www.rfc-editor.org/info/rfc7217>.
```

### 7.2.  Informative References

```
   [IABv6]    IAB, "IAB Statement on IPv6", November 2016,
              <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>.

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

   [RFC7421]  Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
              Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
              Boundary in IPv6 Addressing", RFC 7421,
              DOI 10.17487/RFC7421, January 2015,
              <http://www.rfc-editor.org/info/rfc7421>.

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,
              <http://www.rfc-editor.org/info/rfc7721>.
```

## 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
   959 Skyway Road
   San Carlos  CA 94070
   United States of America

   Email: bob.hinden@gmail.com
```