RFC 8136 - Additional Transition Functionality for IPv6 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8136
タイトル : RFC 8136 - IPv6の追加の移行機能
翻訳編集 : 自動生成

[要約] RFC 8136は、IPv6の追加の移行機能に関する要件とガイドラインを提供するものであり、IPv4からIPv6への移行を支援することを目的としています。

Independent Submission                                      B. Carpenter
Request for Comments: 8136                             Univ. of Auckland
Category: Informational                                        R. Hinden
ISSN: 2070-1721                                     Check Point Software
                                                            1 April 2017

Additional Transition Functionality for IPv6

IPv6の追加の移行機能

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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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で入手できます。

著作権表示

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

1. はじめに

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]で、インターネットアーキテクチャーボードは、インターネット技術特別調査委員会が「新規または拡張プロトコルでのIPv4互換性の要求を停止する」と予想され、将来の作業が「IPv6に最適化され、IPv6に依存する」とみなした。これらの目標を促進するために、このメモはIPv4ノード要件[RFC1122]に重要な変更を加え、欠落しているセキュリティ機能をIPv6 [RFC2460]に追加します。

1.1. Terminology

1.1. 用語

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

2. すべての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に設定する必要があります。これは、デュアルスタックアプリケーションの実装者が選択肢を与えられたときにIPv6を優先し、通常Happy Eyeballsアルゴリズム[RFC6555]がIPv6を優先することを保証するのに十分でなければなりません。道。

3. Security Flag for IPv6 Packets

3. 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に同等のフラグを追加することで簡単に克服できます。実際、これは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].

DHCPv6 [RFC3315]または手動でIPv6アドレスが設定されているインターフェースの場合、ネットワーク管理者は、[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を悪であると見なすことは通常の運用慣行です。

4. Advanced Solution

4. 高度なソリューション

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が存在してはいけません。 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ビットID。ユーザーセキュリティフラグオプション（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でなければなりません。

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でなければなりません。

4.1. Privacy Extension

4.1. プライバシー拡張

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がプライバシーフラグとして定義されています。設定されている場合、パケットにはプライベート情報が含まれており、途中で検査してはならないことを意味します。すべてのファイアウォール、監視デバイス、および政府機関は、このルールを遵守する必要があります。このオプションは、IPsecやトランスポート層セキュリティ（TLS）などの従来のプライバシー技術よりもはるかに計算効率が高くなることが期待されています。

5. Security Considerations

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

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.

IPv4インターネット上で発生するIPカメラ、フィッシング攻撃、マルウェアなどのモノのインターネット（IoT）デバイスからの非常に大規模なDDoS攻撃の最近の経験を考えると、すべてのIPv4パケットが悪であるというのは安全な前提です。

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インターネットは半分だけ悪であると断言できます。

6. IANA Considerations

6. IANAに関する考慮事項

This document does not require any IANA actions.

このドキュメントでは、IANAアクションは必要ありません。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

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

[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<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>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.

[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<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>.

[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、2003年7月、<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>.

[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<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>.

[RFC6164]河野雅夫、ニッサン、B。、ブッシュ、R。、松崎、Y。、コリッティ、L。、およびT.ナルテン、「ルーター間リンクでの127ビットIPv6プレフィックスの使用」、RFC 6164、 DOI 10.17487 / RFC6164、2011年4月、<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>.

[RFC6555] Wing、D.、A。Yourtchenko、「Happy Eyeballs：Success with Dual-Stack Hosts」、RFC 6555、DOI 10.17487 / RFC6555、2012年4月、<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>.

[RFC7136] Carpenter、B。およびS. Jiang、「Significance of IPv6 Interface Identifiers」、RFC 7136、DOI 10.17487 / RFC7136、2014年2月、<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>.

[RFC7217] Gont、F。、「IPv6ステートレスアドレス自動構成（SLAAC）を使用してセマンティックに不透明なインターフェース識別子を生成する方法」、RFC 7217、DOI 10.17487 / RFC7217、2014年4月、<http://www.rfc-editor.org / info / rfc7217>。

7.2. Informative References

7.2. 参考引用

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

[IABv6] IAB、「IAB Statement on IPv6」、2016年11月、<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>.

[RFC3514] Bellovin、S。、「IPv4ヘッダーのセキュリティフラグ」、RFC 3514、DOI 10.17487 / RFC3514、2003年4月、<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>.

[RFC7421] Carpenter、B.、Ed。、Chown、T.、Gont、F.、Jiang、S.、Petrescu、A。、およびA. Yourtchenko、「IPv6アドレッシングの64ビット境界の分析」、RFC 7421、DOI 10.17487 / RFC7421、2015年1月、<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>.

[RFC7721]クーパー、A。、ゴント、F。、およびD.ターラー、「IPv6アドレス生成メカニズムのセキュリティとプライバシーに関する考慮事項」、RFC 7721、DOI 10.17487 / RFC7721、2016年3月、<http：//www.rfc- editor.org/info/rfc7721>。

Authors' Addresses

著者のアドレス

Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand

ブライアンカーペンターコンピュータサイエンス学部オークランド大学PB 92019オークランド1142ニュージーランド

   Email: brian.e.carpenter@gmail.com

Robert M. Hinden Check Point Software 959 Skyway Road San Carlos CA 94070 United States of America

Robert M. Hinden Check Point Software 959 Skyway Road San Carlos CA 94070アメリカ合衆国

   Email: bob.hinden@gmail.com