RFC 7045 - Transmission and Processing of IPv6 Extension Headers 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7045
タイトル : RFC 7045 - IPv6拡張ヘッダーの送信と処理
翻訳編集 : 自動生成

[要約] RFC 7045は、IPv6拡張ヘッダーの送信と処理に関するガイドラインです。その目的は、IPv6ネットワークでの拡張ヘッダーの使用方法を明確にし、ネットワークのパフォーマンスとセキュリティを向上させることです。

Internet Engineering Task Force (IETF)                      B. Carpenter
Request for Comments: 7045                             Univ. of Auckland
Updates: 2460, 2780                                             S. Jiang
Category: Standards Track                  Huawei Technologies Co., Ltd.
ISSN: 2070-1721                                            December 2013

Transmission and Processing of IPv6 Extension Headers

IPv6拡張ヘッダーの送信と処理

Abstract

概要

Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.

IPv6標準が最初に公開されて以来、さまざまなIPv6拡張ヘッダーが標準化されています。このドキュメントはRFC 2460を更新して、中間ノードがこのような拡張ヘッダーと将来定義される拡張ヘッダーをどのように処理するかを明確にします。また、IANAが拡張ヘッダーを登録する方法も指定し、対応するRFC 2780のマイナーアップデートを行います。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、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/rfc7045.

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

著作権表示

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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction and Problem Statement  . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Requirement to Transmit Extension Headers . . . . . . . . . .   5
     2.1.  All Extension Headers . . . . . . . . . . . . . . . . . .   5
     2.2.  Hop-by-Hop Options  . . . . . . . . . . . . . . . . . . .   6
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8

1. Introduction and Problem Statement

1. 概要と問題の説明

In IPv6, an extension header is any header that follows the initial 40 bytes of the packet and precedes the upper-layer header (which might be a transport header, an ICMPv6 header, or a notional "No Next Header").

IPv6では、拡張ヘッダーは、パケットの最初の40バイトに続き、上位層ヘッダー（トランスポートヘッダー、ICMPv6ヘッダー、または概念的な「次のヘッダーなし」の可能性があります）に先行するヘッダーです。

An initial set of IPv6 extension headers was defined by [RFC2460], which also described how they should be handled by intermediate nodes, with the exception of the Hop-by-Hop Options header:

IPv6拡張ヘッダーの最初のセットは[RFC2460]によって定義され、ホップバイホップオプションヘッダーを除いて、中間ノードによるそれらの処理方法も記述されていました。

...extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.

...拡張ヘッダーは、パケットがIPv6ヘッダーの宛先アドレスフィールドで識別されたノード（またはマルチキャストの場合はノードのセットのそれぞれ）に到達するまで、パケットの配信パスに沿ったノードによって検査または処理されません。。

This provision meant that forwarding nodes should be completely transparent to extension headers. There was no provision for forwarding nodes to modify them, remove them, insert them, or use them to affect forwarding behaviour. Thus, new extension headers could be introduced progressively and used only by hosts that have been updated to create and interpret them [RFC6564]. The extension header mechanism is an important part of the IPv6 architecture, and several new extension headers have been standardised since RFC 2460 was published.

この規定により、転送ノードは拡張ヘッダーに対して完全に透過的である必要があります。転送ノードがそれらを変更、削除、挿入、または転送動作に影響を与えるために使用するためのプロビジョニングはありませんでした。したがって、新しい拡張ヘッダーは段階的に導入され、それらを作成および解釈するように更新されたホストによってのみ使用される可能性があります[RFC6564]。拡張ヘッダーメカニズムはIPv6アーキテクチャの重要な部分であり、RFC 2460が公開されて以来、いくつかの新しい拡張ヘッダーが標準化されています。

Today, IPv6 packets are not always forwarded by straightforward IP routing based on their first 40 bytes. Some routers, and a variety of intermediate nodes often referred to as middleboxes, such as firewalls, load balancers, or packet classifiers, might inspect other parts of each packet. Indeed, such middlebox functions are often embedded in routers. However, experience has shown that as a result, the network is not transparent to IPv6 extension headers. Contrary to Section 4 of RFC 2460, middleboxes sometimes examine and process the entire IPv6 packet before making a decision to either forward or discard the packet. This means that they need to traverse the chain of extension headers, if present, until they find the transport header (or an encrypted payload). Unfortunately, because not all IPv6 extension headers follow a uniform TLV format, this process is clumsy and requires knowledge of each extension header's format. A separate problem is that the header chain may even be fragmented [HEADER-CHAIN].

現在、IPv6パケットは、最初の40バイトに基づく単純なIPルーティングによって常に転送されるとは限りません。一部のルーター、およびファイアウォール、ロードバランサー、パケット分類子など、ミドルボックスと呼ばれることがあるさまざまな中間ノードは、各パケットの他の部分を検査する場合があります。実際、このようなミドルボックス機能は、ルーターに組み込まれていることがよくあります。ただし、経験上、その結果、ネットワークはIPv6拡張ヘッダーに対して透過的ではないことがわかっています。 RFC 2460のセクション4とは異なり、ミドルボックスは、パケットを転送するか破棄するかを決定する前に、IPv6パケット全体を調べて処理することがあります。つまり、トランスポートヘッダー（または暗号化されたペイロード）が見つかるまで、拡張ヘッダー（存在する場合）のチェーンを走査する必要があります。残念ながら、すべてのIPv6拡張ヘッダーが統一されたTLV形式に従うわけではないため、このプロセスは扱いにくく、各拡張ヘッダーの形式の知識が必要です。別の問題は、ヘッダーチェーンが断片化されることさえあることです[HEADER-CHAIN]。

The process is potentially slow as well as clumsy, possibly precluding its use in nodes attempting to process packets at line speed. The present document does not intend to solve this problem, which is caused by the fundamental architecture of IPv6 extension headers. This document focuses on clarifying how the header chain should be handled in the current IPv6 architecture.

プロセスは潜在的に低速で扱いにくいため、回線速度でパケットを処理しようとするノードでの使用が妨げられる可能性があります。このドキュメントは、IPv6拡張ヘッダーの基本的なアーキテクチャーによって引き起こされるこの問題を解決することを意図していません。このドキュメントでは、現在のIPv6アーキテクチャでヘッダーチェーンを処理する方法を明確にすることに焦点を当てています。

If they encounter an unrecognised extension header type, some firewalls treat the packet as suspect and drop it. Unfortunately, it is an established fact that several widely used firewalls do not recognise some or all of the extension headers standardised since RFC 2460 was published. It has also been observed that certain firewalls do not even handle all the extension headers standardised in RFC 2460, including the fragment header [FRAGDROP], causing fundamental problems of end-to-end connectivity. This applies in particular to firewalls that attempt to inspect packets at very high speed, since they cannot take the time to reassemble fragmented packets, especially when under a denial-of-service attack.

認識されない拡張ヘッダータイプに遭遇した場合、一部のファイアウォールはパケットを疑わしいものとして扱い、ドロップします。残念ながら、広く使用されているいくつかのファイアウォールは、RFC 2460の公開以降に標準化された拡張ヘッダーの一部またはすべてを認識しないことが確立された事実です。また、特定のファイアウォールは、RFC 2460で標準化されているすべての拡張ヘッダー（フラグメントヘッダー[FRAGDROP]を含む）を処理しないこともあり、エンドツーエンド接続の根本的な問題を引き起こしています。これは特に、非常に高速でパケットを検査しようとするファイアウォールに当てはまります。特にサービス拒否攻撃を受けている場合、断片化されたパケットを再構成するのに時間がかかることがないためです。

Other types of middleboxes, such as load balancers or packet classifiers, might also fail in the presence of extension headers that they do not recognise.

ロードバランサーやパケット分類子などの他のタイプのミドルボックスも、認識しない拡張ヘッダーがあると失敗する可能性があります。

A contributory factor to this problem is that because extension headers are numbered out of the existing IP Protocol Number space, there is no collected list of them. For this reason, it is hard for an implementor to quickly identify the full set of standard extension headers. An implementor who consults only RFC 2460 will miss all extension headers defined subsequently.

この問題の原因の1つは、拡張ヘッダーが既存のIPプロトコル番号スペースから番号付けされるため、それらの収集されたリストがないことです。このため、標準の拡張ヘッダーの完全なセットを実装者がすばやく特定することは困難です。 RFC 2460のみを参照する実装者は、後で定義されるすべての拡張ヘッダーを見逃します。

This combination of circumstances creates a "Catch-22" situation [Heller] for the deployment of any newly standardised extension header except for local use. It cannot be widely deployed because existing middleboxes will drop it on many paths through the Internet. However, most middleboxes will not be updated to allow the new header to pass until it has been proved safe and useful on the open Internet, which is impossible until the middleboxes have been updated.

このような状況の組み合わせにより、ローカルでの使用を除いて、新しく標準化された拡張ヘッダーを展開するための「Catch-22」シチュエーション[Heller]が作成されます。既存のミドルボックスはインターネット経由の多くのパスにドロップするため、広く展開することはできません。ただし、ほとんどのミドルボックスは、オープンインターネットで安全かつ有用であることが証明されるまで、新しいヘッダーの通過を許可するように更新されません。これは、ミドルボックスが更新されるまで不可能です。

The uniform TLV format now defined for extension headers [RFC6564] will improve the situation, but only for future extensions. Some tricky and potentially malicious cases will be avoided by forbidding very long chains of extension headers that need to be fragmented [HEADER-CHAIN]. This will alleviate concerns that stateless firewalls cannot locate a complete header chain as required by the present document.

拡張ヘッダー[RFC6564]に定義された統一TLV形式は状況を改善しますが、将来の拡張に対してのみです。断片化が必要な拡張ヘッダーの非常に長いチェーンを禁止することで、いくつかのトリッキーで潜在的に悪意のあるケースを回避できます[HEADER-CHAIN]。これにより、ステートレスファイアウォールが現在のドキュメントで要求されている完全なヘッダーチェーンを見つけられないという懸念が軽減されます。

However, these changes are insufficient to correct the underlying problem. The present document clarifies that the above requirement from RFC 2460 applies to all types of nodes that forward IPv6 packets and to all extension headers standardised now and in the future. It also requests that IANA create a subsidiary registry that clearly identifies extension header types and updates RFC 2780 accordingly. Fundamental changes to the IPv6 extension header architecture are out of scope for this document.

ただし、これらの変更は根本的な問題を修正するには不十分です。このドキュメントでは、RFC 2460の上記の要件が、IPv6パケットを転送するすべてのタイプのノードと、現在および将来標準化されるすべての拡張ヘッダーに適用されることを明確にしています。また、拡張ヘッダータイプを明確に識別し、それに応じてRFC 2780を更新する補助レジストリをIANAに作成することも要求します。 IPv6拡張ヘッダーアーキテクチャに対する基本的な変更は、このドキュメントの範囲外です。

Also, hop-by-hop options are not handled by many high-speed routers or are processed only on a slow path. This document also updates the requirements for processing the Hop-by-Hop Options header to make them more realistic.

また、ホップバイホップオプションは、多くの高速ルーターでは処理されないか、低速パスでのみ処理されます。このドキュメントでは、ホップバイホップオプションヘッダーを処理するための要件も更新して、より現実的なものにしています。

1.1. Terminology

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

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

In the remainder of this document, the term "forwarding node" refers to any router, firewall, load balancer, prefix translator, or any other device or middlebox that forwards IPv6 packets with or without examining the packet in any way.

このドキュメントの残りの部分では、「転送ノード」という用語は、ルーター、ファイアウォール、ロードバランサー、プレフィックストランスレーター、またはパケットを検査するかどうかにかかわらずIPv6パケットを転送するその他のデバイスまたはミドルボックスを指します。

In this document, "standard" IPv6 extension headers are those specified in detail by IETF Standards Actions [RFC5226]. "Experimental" extension headers include those defined by any Experimental RFC and the header values 253 and 254 defined by [RFC3692] and [RFC4727] when used as experimental extension headers. "Defined" extension headers are the "standard" extension headers plus the "experimental" ones.

このドキュメントでは、「標準」IPv6拡張ヘッダーは、IETF標準アクション[RFC5226]で詳細に指定されているヘッダーです。「実験的」拡張ヘッダーには、実験的RFCで定義されたものと、実験的拡張ヘッダーとして使用される場合に[RFC3692]および[RFC4727]で定義されたヘッダー値253および254が含まれます。「定義済み」拡張ヘッダーは、「標準」拡張ヘッダーと「実験的」拡張ヘッダーです。

2. Requirement to Transmit Extension Headers

2. 拡張ヘッダーを送信するための要件

2.1. All Extension Headers

2.1. すべての拡張ヘッダー

As mentioned above, forwarding nodes that discard packets containing extension headers are known to cause connectivity failures and deployment problems. Therefore, it is important that forwarding nodes that inspect IPv6 headers be able to parse all defined extension headers and deal with them appropriately, as specified in this section.

上記のように、拡張ヘッダーを含むパケットを破棄する転送ノードは、接続障害と展開の問題を引き起こすことが知られています。したがって、IPv6ヘッダーを検査する転送ノードが、このセクションで指定されているように、定義されたすべての拡張ヘッダーを解析して適切に処理できることが重要です。

Any forwarding node along an IPv6 packet's path, which forwards the packet for any reason, SHOULD do so regardless of any extension headers that are present, as required by RFC 2460. Exceptionally, if a forwarding node is designed to examine extension headers for any reason, such as firewalling, it MUST recognise and deal appropriately with all standard IPv6 extension header types and SHOULD recognise and deal appropriately with experimental IPv6 extension header types. The list of standard and experimental extension header types is maintained by IANA (see Section 4), and implementors are advised to check this list regularly for updates.

何らかの理由でパケットを転送するIPv6パケットのパスに沿った転送ノードは、RFC 2460で要求されているように、存在する拡張ヘッダーに関係なく転送する必要があります。例外として、転送ノードが何らかの理由で拡張ヘッダーを検査するように設計されている場合ファイアウォールなどのように、すべての標準IPv6拡張ヘッダータイプを認識して適切に処理する必要があり、実験的なIPv6拡張ヘッダータイプを適切に認識して処理する必要があります（SHOULD）。標準および試験的な拡張ヘッダータイプのリストはIANAによって維持され（セクション4を参照）、実装者はこのリストを定期的にチェックして更新を確認することをお勧めします。

RFC 2460 requires destination hosts to discard packets containing unrecognised extension headers. However, intermediate forwarding nodes SHOULD NOT do this, since that might cause them to inadvertently discard traffic using a recently standardised extension header not yet recognised by the intermediate node. The exceptions to this rule are discussed next.

RFC 2460では、宛先ホストが認識できない拡張ヘッダーを含むパケットを破棄する必要があります。ただし、中間転送ノードはこれを行わないでください。中間ノードでまだ認識されていない最近標準化された拡張ヘッダーを使用して、トラフィックを誤って破棄する可能性があるためです。このルールの例外については、次に説明します。

If a forwarding node discards a packet containing a standard IPv6 extension header, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. This means that the discard policy for each standard type of extension header MUST be individually configurable. The default configuration SHOULD allow all standard extension headers.

転送ノードが標準IPv6拡張ヘッダーを含むパケットを破棄する場合、それは構成可能なポリシーの結果である必要があり、そのようなヘッダーの認識の失敗の結果だけではありません。つまり、各標準タイプの拡張ヘッダーの破棄ポリシーは、個別に構成可能でなければなりません。デフォルトの設定では、すべての標準拡張ヘッダーを許可する必要があります（SHOULD）。

Experimental IPv6 extension headers SHOULD be treated in the same way as standard extension headers, including an individually configurable discard policy. However, the default configuration MAY drop experimental extension headers.

実験的なIPv6拡張ヘッダーは、個別に構成可能な破棄ポリシーを含め、標準の拡張ヘッダーと同じ方法で処理する必要があります（SHOULD）。ただし、デフォルトの設定では、実験的な拡張ヘッダーが削除される場合があります。

Forwarding nodes MUST be configurable to allow packets containing unrecognised extension headers, but the default configuration MAY drop such packets.

転送ノードは、認識されない拡張ヘッダーを含むパケットを許可するように構成可能でなければなりません（MUST）が、デフォルトの構成では、そのようなパケットをドロップしてもよい（MAY）。

The IPv6 Routing Header Types 0 and 1 have been deprecated. Note that Type 0 was deprecated by [RFC5095]. However, this does not mean that the IPv6 Routing Header can be unconditionally dropped by forwarding nodes. Packets containing standardised and undeprecated Routing Headers SHOULD be forwarded by default. At the time of writing, these include Type 2 [RFC6275], Type 3 [RFC6554], and the experimental Routing Header Types 253 and 254 [RFC4727]. Others may be defined in the future.

IPv6ルーティングヘッダータイプ0および1は非推奨になりました。タイプ0は[RFC5095]によって廃止されたことに注意してください。ただし、これはIPv6ルーティングヘッダーが転送ノードによって無条件にドロップされる可能性があることを意味しません。標準化され、非推奨のルーティングヘッダーを含むパケットは、デフォルトで転送する必要があります。これを書いている時点では、タイプ2 [RFC6275]、タイプ3 [RFC6554]、実験的なルーティングヘッダータイプ253および254 [RFC4727]が含まれています。他のものは将来定義されるかもしれません。

2.2. Hop-by-Hop Options

2.2. ホップバイホップオプション

The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in [RFC2460]. However, it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path. Designers planning to use a hop-by-hop option need to be aware of this likely behaviour.

IPv6ホップバイホップオプションヘッダーは、[RFC2460]で説明されているように、中間転送ノードによって処理される必要があります（SHOULD）。ただし、高性能ルーターはそれを無視するか、それを含むパケットを低速の処理パスに割り当てることが予想されます。ホップバイホップオプションの使用を計画している設計者は、この可能性のある動作に注意する必要があります。

As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options header, if present, must be first.

注意として、RFC 2460では、Hop-by-Hop Optionsヘッダーが存在する場合は、それを最初にする必要があると規定されています。

3. Security Considerations

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

Forwarding nodes that operate as firewalls MUST conform to the requirements in the previous section in order to respect the IPv6 extension header architecture. In particular, packets containing standard extension headers are only to be discarded as a result of an intentionally configured policy.

ファイアウォールとして動作する転送ノードは、IPv6拡張ヘッダーアーキテクチャを尊重するために、前のセクションの要件に準拠する必要があります。特に、標準の拡張ヘッダーを含むパケットは、意図的に構成されたポリシーの結果としてのみ破棄されます。

These changes do not affect a firewall's ability to filter out traffic containing unwanted or suspect extension headers, if configured to do so. However, the changes do require firewalls to be capable of permitting any or all extension headers, if configured to do so. The default configurations are intended to allow normal use of any standard extension header, avoiding the connectivity issues described in Sections 1 and 2.1.

これらの変更は、必要に応じて、または疑わしい拡張ヘッダーを含むトラフィックをフィルタリングするように構成されている場合、ファイアウォールの機能に影響を与えません。ただし、変更を行うように構成されている場合、ファイアウォールが拡張ヘッダーの一部またはすべてを許可できるようにする必要があります。デフォルト構成は、セクション1および2.1で説明されている接続の問題を回避し、標準の拡張ヘッダーを通常どおり使用できるようにすることを目的としています。

As noted above, the default configuration might drop packets containing experimental extension headers. There is no header length field in an IPv6 header, and header types 253 and 254 might be used either for experimental extension headers or for experimental payload types. Therefore, there is no generic algorithm by which a firewall can distinguish these two cases and analyze the remainder of the packet. This should be considered when deciding on the appropriate default action for header types 253 and 254.

上記のように、デフォルトの設定では、実験的な拡張ヘッダーを含むパケットがドロップされる場合があります。 IPv6ヘッダーにはヘッダー長フィールドはありません。ヘッダータイプ253および254は、試験的な拡張ヘッダーまたは試験的なペイロードタイプのいずれかに使用できます。したがって、ファイアウォールがこれら2つのケースを区別し、残りのパケットを分析するための一般的なアルゴリズムはありません。これは、ヘッダータイプ253および254の適切なデフォルトアクションを決定するときに考慮する必要があります。

When new extension headers are standardised in the future, those implementing and configuring forwarding nodes, including firewalls, will need to take them into account. A newly defined header will exercise new code paths in a host that does recognise it, so caution may be required. Additional security issues with experimental values or new extension headers are to be found in [RFC4727] and [RFC6564]. As a result, it is to be expected that the deployment process will be slow and will depend on satisfactory operational experience. Until deployment is complete, the new extension will fail in some parts of the Internet. This aspect needs to be considered when deciding to standardise a new extension. Specific security considerations for each new extension should be documented in the document that defines it.

新しい拡張ヘッダーが将来的に標準化されるとき、ファイアウォールを含む転送ノードを実装および構成するものは、それらを考慮する必要があります。新しく定義されたヘッダーは、それを認識するホストで新しいコードパスを実行するため、注意が必要な場合があります。試験的な値または新しい拡張ヘッダーに関する追加のセキュリティ問題は、[RFC4727]と[RFC6564]にあります。その結果、展開プロセスが遅くなり、満足できる運用経験に依存することが予想されます。展開が完了するまで、新しい拡張機能はインターネットの一部で失敗します。新しい拡張機能を標準化することを決定するときは、この側面を考慮する必要があります。新しい各拡張機能の特定のセキュリティに関する考慮事項は、それを定義するドキュメントに文書化する必要があります。

4. IANA Considerations

4. IANAに関する考慮事項

IANA has added an extra column titled "IPv6 Extension Header" to the "Assigned Internet Protocol Numbers" registry to clearly mark those values that are also IPv6 extension header types defined by an IETF Standards Action or IESG Approval (see list below). This also applies to IPv6 extension header types defined in the future.

IANAは、「割り当てられたインターネットプロトコル番号」レジストリに「IPv6拡張ヘッダー」というタイトルの列を追加して、IETF標準アクションまたはIESG承認によって定義されたIPv6拡張ヘッダータイプでもある値を明確にマークしています（以下のリストを参照）。これは、将来定義されるIPv6拡張ヘッダータイプにも適用されます。

Additionally, IANA has closed the existing empty "Next Header Types" registry to new entries and is redirecting its users to a new "IPv6 Extension Header Types" registry. This registry contains only those protocol numbers that are also marked as IPv6 Extension Header types in the "Assigned Internet Protocol Numbers" registry. Experimental values will be marked as such. The initial list will be as follows:

さらに、IANAは既存の空の「次のヘッダータイプ」レジストリを新しいエントリに閉じ、ユーザーを新しい「IPv6拡張ヘッダータイプ」レジストリにリダイレクトしています。このレジストリには、「割り当てられたインターネットプロトコル番号」レジストリでIPv6拡張ヘッダータイプとしてマークされているプロトコル番号のみが含まれています。実験値はそのようにマークされます。最初のリストは次のようになります。

o 0, IPv6 Hop-by-Hop Option, [RFC2460]

o 0、IPv6ホップバイホップオプション、[RFC2460]

o 43, Routing Header for IPv6, [RFC2460], [RFC5095]

o 43、IPv6のルーティングヘッダー、[RFC2460]、[RFC5095]

o 44, Fragment Header for IPv6, [RFC2460]

o 44、IPv6のフラグメントヘッダー、[RFC2460]

o 50, Encapsulating Security Payload, [RFC4303]

o 50、セキュリティペイロードのカプセル化、[RFC4303]

o 51, Authentication Header, [RFC4302]

o 51、認証ヘッダー、[RFC4302]

o 60, Destination Options for IPv6, [RFC2460]

o 60、IPv6の宛先オプション、[RFC2460]

o 135, Mobility Header, [RFC6275]

o 135、モビリティヘッダー、[RFC6275]

o 139, Experimental use, Host Identity Protocol [RFC5201]

o 139、実験的使用、ホストIDプロトコル[RFC5201]

o 140, Shim6 Protocol, [RFC5533]

o 140、Shim6プロトコル、[RFC5533]

o 253, Use for experimentation and testing, [RFC3692], [RFC4727]

o 253、実験とテストのための使用、[RFC3692]、[RFC4727]

o 254, Use for experimentation and testing, [RFC3692], [RFC4727]

o 254、実験とテストに使用、[RFC3692]、[RFC4727]

This list excludes type 59, No Next Header, [RFC2460], which is not an extension header as such.

このリストは、タイプ59、次のヘッダーなし、[RFC2460]を除外します。これは、拡張ヘッダー自体ではありません。

The references to the IPv6 Next Header field in [RFC2780] are to be interpreted as also applying to the IPv6 Extension Header field, and the "IPv6 Extension Header Types" registry will be managed accordingly.

[RFC2780]のIPv6 Next Headerフィールドへの参照は、IPv6拡張ヘッダーフィールドにも適用されると解釈され、それに応じて「IPv6拡張ヘッダータイプ」レジストリが管理されます。

5. Acknowledgements

5. 謝辞

This document was triggered by mailing list discussions including John Leslie, Stefan Marksteiner, and others. Valuable comments and contributions were made by Dominique Barthel, Tim Chown, Lorenzo Colitti, Fernando Gont, C. M. Heard, Bob Hinden, Ray Hunter, Suresh Krishnan, Marc Lampo, Sandra Murphy, Michael Richardson, Dan Romascanu, Dave Thaler, Joe Touch, Bjoern Zeeb, and others.

このドキュメントは、ジョンレスリー、ステファンマークシュタイナーなどを含むメーリングリストのディスカッションによってトリガーされました。貴重なコメントと寄稿は、ドミニクバルテル、ティムチョン、ロレンゾコリッティ、フェルナンドゴン、CMハード、ボブヒンデン、レイハンター、スレッシュクリシュナン、マークランポ、サンドラマーフィー、マイケルリチャードソン、ダンローマスカヌ、デイブターラー、ジョータッチ、ビョルンによって行われました。 Zeeb、その他。

Brian Carpenter was a visitor at the Computer Laboratory at Cambridge University during part of this work.

ブライアンカーペンターは、この作業の一環として、ケンブリッジ大学のコンピューターラボの訪問者でした。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。

[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.

[RFC2780] Bradner、S。およびV. Paxson、「IANA Allocation Allocation Guidelines for Values in the Internet Protocol and Related Headers」、BCP 37、RFC 2780、2000年3月。

[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.

[RFC3692]ナルテン、T。、「実験的およびテスト番号の割り当ては有用と見なされた」、BCP 82、RFC 3692、2004年1月。

[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.

[RFC4727] Fenner、B。、「IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値」、RFC 4727、2006年11月。

[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, April 2012.

[RFC6564]クリシュナン、S。、ウッディアット、J。、クライン、E。、ホアグランド、J。、およびM.バティア、「IPv6拡張ヘッダーの統一フォーマット」、RFC 6564、2012年4月。

6.2. Informative References

6.2. 参考引用

[FRAGDROP] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, M., and T. Taylor, "Why Operators Filter Fragments and What It Implies", Work in Progress, June 2013.

[FRAGDROP] Jaeggli、J.、Colitti、L.、Kumari、W.、Vyncke、E.、Kaeo、M。、およびT. Taylor、「なぜ演算子はフラグメントをフィルタリングし、何を意味するのか」、2013年6月、作業中。

[HEADER-CHAIN] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", Work in Progress, October 2013.

[HEADER-CHAIN] Gont、F.、Manral、V。、およびR. Bonica、「特大のIPv6ヘッダーチェーンの影響」、作業中、2013年10月。

[Heller] Heller, J., "Catch-22", Simon and Schuster, November 1961.

[ヘラー]ヘラー、J。、「キャッチ22」、サイモンとシュースター、1961年11月。

[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.

[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.

[RFC5095] Abley、J.、Savola、P。、およびG. Neville-Neil、「Deprecation of Type 0 Routing Headers in IPv6」、RFC 5095、2007年12月。

[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.

[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。

[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.

[RFC5533] Nordmark、E.およびM. Bagnulo、「Shim6：Level 3 Multihoming Shim Protocol for IPv6」、RFC 5533、2009年6月。

[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.

[RFC6275] Perkins、C.、Johnson、D。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 6275、2011年7月。

[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, March 2012.

[RFC6554] Hui、J.、Vasseur、JP。、Culler、D.、and V. Manral、 "An IPv6 Routing Header for Source Routes with the Routing Protocol for Routing-Power and Lossy Networks（RPL）"、RFC 6554、 2012年3月。

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

Sheng Jiang Huawei Technologies Co., Ltd. Q14, Huawei Campus No. 156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China

S横Jiang hu Aはテクノロジー株式会社です。Q14、hu Aはキャンパス番号156です。i青道路H艾-Dイアン地区、北京100095 P.R.中国

   EMail: jiangsheng@huawei.com