[要約] RFC 7676は、IPv6をサポートするためのGeneric Routing Encapsulation（GRE）に関する仕様です。このRFCの目的は、IPv6ネットワーク上でGREトンネルを使用するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) C. Pignataro
Request for Comments: 7676 Cisco Systems
Category: Standards Track R. Bonica
ISSN: 2070-1721 Juniper Networks
S. Krishnan
Ericsson
October 2015
IPv6 Support for Generic Routing Encapsulation (GRE)
Generic Routing Encapsulation（GRE）のIPv6サポート
Abstract
概要
Generic Routing Encapsulation (GRE) can be used to carry any network-layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6.
Generic Routing Encapsulation（GRE）を使用して、任意のネットワークレイヤーペイロードプロトコルを任意のネットワークレイヤー配信プロトコルで伝送できます。現在、GREプロシージャは、ペイロードまたは配信プロトコルのいずれかとして使用されるIPv4用に指定されています。ただし、GREの手順はIPv6では指定されていません。
This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol.
このドキュメントでは、ペイロードまたは配信プロトコルとして使用されるIPv6のGRE手順を指定します。
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/rfc7676.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7676で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. GRE Header Fields . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Checksum Present . . . . . . . . . . . . . . . . . . . . 4
3. IPv6 as GRE Payload . . . . . . . . . . . . . . . . . . . . . 5
3.1. GRE Protocol Type Considerations . . . . . . . . . . . . 5
3.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 5
3.3. Fragmentation Considerations . . . . . . . . . . . . . . 5
4. IPv6 as GRE Delivery Protocol . . . . . . . . . . . . . . . . 6
4.1. Next Header Considerations . . . . . . . . . . . . . . . 6
4.2. Checksum Considerations . . . . . . . . . . . . . . . . . 6
4.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890] can be used to carry any network-layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4 [RFC791], used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6 [RFC2460].
Generic Routing Encapsulation（GRE）[RFC2784] [RFC2890]を使用して、任意のネットワーク層ペイロードプロトコルを任意のネットワーク層配信プロトコル上で伝送できます。現在、GREの手順は、ペイロードまたは配信プロトコルとして使用されるIPv4 [RFC791]に対して指定されています。ただし、GREの手順はIPv6 [RFC2460]では指定されていません。
This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol. Like RFC 2784, this document describes how GRE has been implemented by several vendors.
このドキュメントでは、ペイロードまたは配信プロトコルとして使用されるIPv6のGRE手順を指定します。 RFC 2784と同様に、このドキュメントでは、GREが複数のベンダーによってどのように実装されているかについて説明します。
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]で説明されているように解釈されます。
The following terms are used in this document:
このドキュメントでは、次の用語が使用されています。
o GRE delivery header: An IPv4 or IPv6 header whose source address represents the GRE ingress node and whose destination address represents the GRE egress node. The GRE delivery header encapsulates a GRE header.
o GRE配信ヘッダー：ソースアドレスがGRE入力ノードを表し、宛先アドレスがGRE出力ノードを表すIPv4またはIPv6ヘッダー。 GRE配信ヘッダーは、GREヘッダーをカプセル化します。
o GRE header: The GRE protocol header. The GRE header is encapsulated in the GRE delivery header and encapsulates the GRE payload.
o GREヘッダー：GREプロトコルヘッダー。 GREヘッダーはGRE配信ヘッダーにカプセル化され、GREペイロードをカプセル化します。
o GRE payload: A network-layer packet that is encapsulated by the GRE header.
o GREペイロード：GREヘッダーによってカプセル化されるネットワーク層パケット。
o GRE overhead: The combined size of the GRE delivery header and the GRE header, measured in octets.
o GREオーバーヘッド：オクテットで測定された、GRE配信ヘッダーとGREヘッダーの合計サイズ。
o Path MTU (PMTU): The minimum MTU of all the links in a path between a source node and a destination node. If the source and destination node are connected through Equal-Cost Multipath (ECMP), the PMTU is equal to the minimum link MTU of all links contributing to the multipath.
o パスMTU（PMTU）：ソースノードと宛先ノード間のパス内のすべてのリンクの最小MTU。送信元ノードと宛先ノードが等コストマルチパス（ECMP）を介して接続されている場合、PMTUはマルチパスに関与するすべてのリンクの最小リンクMTUに等しくなります。
o Path MTU Discovery (PMTUD): A procedure for dynamically discovering the PMTU between two nodes on the Internet. PMTUD procedures for IPv6 are defined in [RFC1981].
o パスMTU検出（PMTUD）：インターネット上の2つのノード間のPMTUを動的に検出するための手順。 IPv6のPMTUD手順は[RFC1981]で定義されています。
o GRE MTU (GMTU): The maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed over a GRE tunnel without fragmentation of any kind. The GMTU is equal to the PMTU associated with the path between the GRE ingress and the GRE egress, minus the GRE overhead.
o GRE MTU（GMTU）：あらゆる種類の断片化なしでGREトンネルを介して伝達できる最大伝送単位、つまりオクテット単位の最大パケットサイズ。 GMTUは、GREの入口とGREの出口の間のパスに関連付けられたPMTUからGREオーバーヘッドを引いたものに等しい。
This document does not change the GRE header format or any behaviors specified by RFC 2784 or RFC 2890.
このドキュメントでは、GREヘッダー形式や、RFC 2784またはRFC 2890で指定されている動作は変更されません。
The GRE ingress node SHOULD set the Checksum Present field in the GRE header to zero. However, implementations MAY support a configuration option that causes the GRE ingress node to set the Checksum Present field to one.
GRE入力ノードは、GREヘッダーのチェックサム存在フィールドをゼロに設定する必要があります（SHOULD）。ただし、実装は、GRE入力ノードにチェックサム存在フィールドを1に設定させる構成オプションをサポートする場合があります。
As per Section 2.2 of RFC 2784, the GRE egress node uses the Checksum Present field to calculate the length of the GRE header. If the Checksum Present field is set to one, the GRE egress node MUST use the GRE Checksum to verify the integrity of the GRE header and payload.
RFC 2784のセクション2.2に従って、GRE出力ノードはチェックサム存在フィールドを使用してGREヘッダーの長さを計算します。チェックサム存在フィールドが1に設定されている場合、GRE出力ノードはGREチェックサムを使用して、GREヘッダーとペイロードの整合性を検証する必要があります。
Setting the Checksum Present field to zero reduces the computational cost of GRE encapsulation and decapsulation. In many cases, the GRE Checksum is partially redundant with other checksums. For example:
[チェックサムの存在]フィールドをゼロに設定すると、GREカプセル化およびカプセル化解除の計算コストが削減されます。多くの場合、GREチェックサムは他のチェックサムと部分的に冗長です。例えば：
o If the payload protocol is IPv4, the IPv4 header is protected by both the GRE Checksum and the IPv4 Checksum.
o ペイロードプロトコルがIPv4の場合、IPv4ヘッダーはGREチェックサムとIPv4チェックサムの両方によって保護されます。
o If the payload carries TCP [RFC793], the TCP pseudo header, TCP header, and TCP payload are protected by both the GRE Checksum and TCP Checksum.
o ペイロードがTCP [RFC793]を伝送する場合、TCP疑似ヘッダー、TCPヘッダー、およびTCPペイロードは、GREチェックサムとTCPチェックサムの両方によって保護されます。
o If the payload carries UDP [RFC768], the UDP pseudo header, UDP header, and UDP payload are protected by both the GRE Checksum and UDP Checksum.
o ペイロードがUDP [RFC768]を伝送する場合、UDP疑似ヘッダー、UDPヘッダー、およびUDPペイロードは、GREチェックサムとUDPチェックサムの両方によって保護されます。
However, if the GRE Checksum Present field is set to zero, the GRE header is not protected by any checksum. Furthermore, depending on which of the above-mentioned conditions are true, selected portions of the GRE payload will not be protected by any checksum.
ただし、GREチェックサム存在フィールドがゼロに設定されている場合、GREヘッダーはチェックサムによって保護されません。さらに、上記のどの条件に該当するかに応じて、GREペイロードの選択された部分はチェックサムによって保護されません。
Network operators should evaluate risk factors in their networks and configure GRE ingress nodes appropriately.
ネットワークオペレーターは、ネットワークのリスク要因を評価し、GRE入力ノードを適切に構成する必要があります。
The following considerations apply to GRE tunnels that carry an IPv6 payload.
次の考慮事項は、IPv6ペイロードを伝送するGREトンネルに適用されます。
The Protocol Type field in the GRE header MUST be set to Ether Type [RFC7042] 0x86DD (IPv6).
GREヘッダーのプロトコルタイプフィールドは、イーサタイプ[RFC7042] 0x86DD（IPv6）に設定する必要があります。
A GRE tunnel MUST be able to carry a 1280-octet IPv6 packet from ingress to egress, without fragmenting the payload packet. All GRE tunnels with a GMTU of 1280 octets or greater satisfy this requirement. GRE tunnels that can fragment and reassemble delivery packets also satisfy this requirement, regardless of their GMTU. However, the ability to fragment and reassemble delivery packets is not a requirement of this specification. This specification requires only that GRE ingress nodes refrain from activating GRE tunnels that do not satisfy the above-mentioned requirement.
GREトンネルは、ペイロードパケットをフラグメント化することなく、入力から出力まで1280オクテットのIPv6パケットを伝送できる必要があります。 GMTUが1280オクテット以上のすべてのGREトンネルは、この要件を満たしています。配信パケットをフラグメント化して再構成できるGREトンネルも、GMTUに関係なく、この要件を満たします。ただし、配信パケットをフラグメント化して再構成する機能は、この仕様の要件ではありません。この仕様は、GRE入力ノードが上記の要件を満たさないGREトンネルをアクティブ化しないことを要求するだけです。
Before activating a GRE tunnel and periodically thereafter, the GRE ingress node MUST verify the tunnel's ability to carry a 1280-octet IPv6 payload packet from ingress to egress, without fragmenting the payload. Having executed those procedures, the GRE ingress node MUST activate or deactivate the tunnel accordingly.
GREトンネルをアクティブ化する前、およびその後定期的に、GRE入力ノードは、ペイロードをフラグメント化せずに、入力から出力まで1280オクテットのIPv6ペイロードパケットを伝送するトンネルの能力を確認する必要があります。これらの手順を実行すると、GRE入力ノードはそれに応じてトンネルをアクティブまたは非アクティブにする必要があります。
Implementation details regarding the above-mentioned verification procedures are beyond the scope of this document. However, a GRE ingress node can verify tunnel capabilities by sending a 1280-octet IPv6 packet addressed to itself through the tunnel under test.
上記の検証手順に関する実装の詳細は、このドキュメントの範囲外です。ただし、GRE入力ノードは、テスト中のトンネルを介して自身にアドレス指定された1280オクテットのIPv6パケットを送信することにより、トンネル機能を確認できます。
Many existing implementations [RFC7588] do not support the above-mentioned verification procedures. Unless deployed in environments where the GMTU is guaranteed to be greater than 1280, these implementations MUST be configured so that the GRE endpoints can fragment and reassemble the GRE delivery packet.
多くの既存の実装[RFC7588]は、上記の検証手順をサポートしていません。 GMTUが1280より大きいことが保証されている環境に展開されない限り、これらの実装は、GREエンドポイントがGRE配信パケットをフラグメント化して再構成できるように構成する必要があります。
When the GRE ingress receives an IPv6 payload packet whose length is less than or equal to the GMTU, it can encapsulate and forward the packet without fragmentation of any kind. In this case, the GRE ingress router MUST NOT fragment the payload or delivery packets.
GRE入力は、長さがGMTU以下のIPv6ペイロードパケットを受信すると、パケットをカプセル化して、いかなる種類の断片化も行わずに転送できます。この場合、GRE入力ルーターはペイロードまたは配信パケットをフラグメント化してはなりません（MUST NOT）。
When the GRE ingress receives an IPv6 payload packet whose length is greater than the GMTU, and the GMTU is greater than or equal to 1280 octets, the GRE ingress router MUST:
GRE入力が、長さがGMTUより大きいIPv6ペイロードパケットを受信し、GMTUが1280オクテット以上である場合、GRE入力ルーターは次の条件を満たしている必要があります。
o discard the IPv6 payload packet
o IPv6ペイロードパケットを破棄する
o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6 payload packet source. The MTU field in the ICMPv6 PTB message is set to the GMTU.
o ICMPv6 Packet Too Big（PTB）[RFC4443]メッセージをIPv6ペイロードパケットソースに送信します。 ICMPv6 PTBメッセージのMTUフィールドはGMTUに設定されています。
When the GRE ingress receives an IPv6 payload packet whose length is greater than the GMTU, and the GMTU is less than 1280 octets, the GRE ingress router MUST:
GRE入力がGMTUより長いIPv6ペイロードパケットを受信し、GMTUが1280オクテット未満の場合、GRE入力ルータは次の処理を行う必要があります。
o encapsulate the entire IPv6 packet in a single GRE header and IP delivery header
o IPv6パケット全体を単一のGREヘッダーとIP配信ヘッダーにカプセル化する
o fragment the delivery header, so that it can be reassembled by the GRE egress
o 配信ヘッダーをフラグメント化して、GRE出力で再構成できるようにする
The following considerations apply when the delivery protocol is IPv6.
配信プロトコルがIPv6の場合、次の考慮事項が適用されます。
When the GRE delivery protocol is IPv6, the GRE header MAY immediately follow the GRE delivery header. Alternatively, IPv6 extension headers MAY be inserted between the GRE delivery header and the GRE header.
GRE配信プロトコルがIPv6の場合、GREヘッダーはGRE配信ヘッダーの直後に続く場合があります。あるいは、IPv6拡張ヘッダーをGRE配信ヘッダーとGREヘッダーの間に挿入してもよい（MAY）。
If the GRE header immediately follows the GRE delivery header, the Next Header field in the IPv6 header of the GRE delivery packet MUST be set to 47. If extension headers are inserted between the GRE delivery header and the GRE header, the Next Header field in the last IPv6 extension header MUST be set to 47.
GREヘッダーがGRE配信ヘッダーの直後に続く場合、GRE配信パケットのIPv6ヘッダーの次のヘッダーフィールドを47に設定する必要があります。拡張ヘッダーがGRE配信ヘッダーとGREヘッダーの間に挿入されている場合、次のヘッダーフィールド最後のIPv6拡張ヘッダーは47に設定する必要があります。
As stated in [RFC2784], the GRE header can contain a checksum. If present, the GRE header checksum can be used to detect corruption of the GRE header and GRE payload.
[RFC2784]で述べられているように、GREヘッダーにはチェックサムを含めることができます。存在する場合、GREヘッダーチェックサムを使用して、GREヘッダーとGREペイロードの破損を検出できます。
The GRE header checksum cannot be used to detect corruption of the IPv6 delivery header. Furthermore, the IPv6 delivery header does not contain a checksum of its own. Therefore, no available checksum can be used to detect corruption of the IPv6 delivery header.
GREヘッダーチェックサムを使用して、IPv6配信ヘッダーの破損を検出することはできません。さらに、IPv6配信ヘッダーには独自のチェックサムが含まれていません。したがって、IPv6配信ヘッダーの破損を検出するために使用できるチェックサムはありません。
In one failure scenario, the destination address in the IPv6 delivery header is corrupted. As a result, the IPv6 delivery packet is delivered to a node other than the intended GRE egress node. Depending upon the state and configuration of that node, it will either:
1つの失敗シナリオでは、IPv6配信ヘッダーの宛先アドレスが破損しています。その結果、IPv6配信パケットは、目的のGRE出力ノード以外のノードに配信されます。そのノードの状態と構成に応じて、次のいずれかになります。
a. Drop the packet
a. パケットをドロップする
b. Decapsulate the payload and forward it to its intended destination
b. ペイロードのカプセル化を解除し、目的の宛先に転送します
c. Decapsulate the payload and forward it to a node other than its intended destination.
c. ペイロードのカプセル化を解除し、目的の宛先以外のノードに転送します。
Behaviors a) and b) are acceptable. Behavior c) is not acceptable.
a）およびb）の動作は許容されます。行動c）は許容されません。
Behavior c) is possible only when the following conditions are true:
動作c）は、次の条件に該当する場合にのみ可能です。
1. The intended GRE egress node is a Virtual Private Network (VPN) Provider Edge (PE) router.
1. 目的のGRE出力ノードは、仮想プライベートネットワーク（VPN）プロバイダーエッジ（PE）ルーターです。
2. The node to which the GRE delivery packet is mistakenly delivered is also a VPN PE router.
2. GRE配信パケットが誤って配信されるノードも、VPN PEルータです。
3. VPNs are attached to both of the above-mentioned nodes. At least two of these VPN's number hosts are from a non-unique (e.g., [RFC1918]) address space.
3. 上記の両方のノードにVPNが接続されています。これらのVPNのナンバーホストのうち少なくとも2つは、一意ではない（[RFC1918]など）アドレス空間からのものです。
4. The intended GRE egress node maintains state that causes it to decapsulate the packet and forward the payload to its intended destination
4. 目的のGRE出力ノードは、パケットのカプセル化を解除し、ペイロードを目的の宛先に転送する状態を維持します
5. The node to which the GRE delivery packet is mistakenly delivered maintains state that causes it to decapsulate the packet and forward the payload to an identically numbered host in another VPN.
5. GRE配信パケットが誤って配信されるノードは、パケットのカプセル化を解除し、ペイロードを別のVPNの同じ番号のホストに転送する状態を維持します。
While the failure scenario described above is extremely unlikely, a single misdelivered packet can adversely impact applications running on the node to which the packet is misdelivered. Furthermore, leaking packets across VPN boundaries also constitutes a security breach. The risk associated with behavior c) could be mitigated with end-to-end authentication of the payload.
上記の障害シナリオは非常にまれですが、単一の誤って配信されたパケットは、パケットが誤って配信されたノードで実行されているアプリケーションに悪影響を与える可能性があります。さらに、VPN境界を越えてパケットをリークすることも、セキュリティ違反となります。動作c）に関連するリスクは、ペイロードのエンドツーエンド認証で軽減できます。
Before deploying GRE over IPv6, network operators should consider the likelihood of behavior c) in their network. GRE over IPv6 MUST NOT be deployed other than where the network operator deems the risk associated with behavior c) to be acceptable.
IPv6を介してGREを展開する前に、ネットワークオペレーターはネットワークでの動作の可能性c）を考慮する必要があります。 IPv6を介したGREは、ネットワークオペレーターが行動c）に関連するリスクを許容できると見なす場合以外には展開してはなりません。
By default, the GRE ingress node cannot fragment the IPv6 delivery header. However, implementations MAY support an optional configuration in which the GRE ingress node can fragment the IPv6 delivery header.
デフォルトでは、GRE入力ノードはIPv6配信ヘッダーをフラグメント化できません。ただし、実装は、GRE入力ノードがIPv6配信ヘッダーをフラグメント化できるオプションの構成をサポートする場合があります。
Also by default, the GRE egress node cannot reassemble the IPv6 delivery header. However, implementations MAY support an optional configuration in which the GRE egress node can reassemble the IPv6 delivery header.
また、デフォルトでは、GRE出力ノードはIPv6配信ヘッダーを再構成できません。ただし、実装は、GRE出力ノードがIPv6配信ヘッダーを再構成できるオプションの構成をサポートする場合があります。
The Security Considerations section of [RFC4023] identifies threats encountered when MPLS is delivered over GRE. These threats apply to any GRE payload. As stated in RFC 4023, these various threats can be mitigated through options such as authenticating and/or encrypting the delivery packet using IPsec [RFC4301]. Alternatively, when the payload is IPv6, these threats can also be mitigated by authenticating and/or encrypting the payload using IPsec, instead of the delivery packet. Otherwise, the current specification introduces no security considerations beyond those mentioned in RFC 2784.
[RFC4023]の[セキュリティに関する考慮事項]セクションでは、MPLSがGRE経由で配信されるときに遭遇する脅威を特定しています。これらの脅威は、GREペイロードに適用されます。 RFC 4023で述べられているように、これらのさまざまな脅威は、IPsec [RFC4301]を使用した配信パケットの認証や暗号化などのオプションによって軽減できます。または、ペイロードがIPv6の場合、配信パケットの代わりにIPsecを使用してペイロードを認証または暗号化することで、これらの脅威を軽減することもできます。それ以外の場合、現在の仕様では、RFC 2784で言及されている以外のセキュリティに関する考慮事項は導入されていません。
More generally, security considerations for IPv6 are discussed in [RFC4942]. Operational security for IPv6 is discussed in [OPSEC-V6], and security concerns for tunnels in general are discussed in [RFC6169].
より一般的には、IPv6のセキュリティに関する考慮事項は[RFC4942]で説明されています。 IPv6の運用上のセキュリティは[OPSEC-V6]で議論されており、一般的なトンネルのセキュリティ問題は[RFC6169]で議論されています。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<http://www.rfc-editor.org/info/rfc768>。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<http://www.rfc-editor.org/info/rfc791>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「Path MTU Discovery for IP version 6」、RFC 1981、DOI 10.17487 / RFC1981、1996年8月、<http：//www.rfc-editor。 org / info / rfc1981>。
[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>。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <http://www.rfc-editor.org/info/rfc2784>.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、DOI 10.17487 / RFC2784、2000年3月、<http ：//www.rfc-editor.org/info/rfc2784>。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, <http://www.rfc-editor.org/info/rfc2890>.
[RFC2890] Dommety、G。、「GREのキーとシーケンス番号の拡張」、RFC 2890、DOI 10.17487 / RFC2890、2000年9月、<http://www.rfc-editor.org/info/rfc2890>。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, <http://www.rfc-editor.org/info/rfc4023>.
[RFC4023] Worster、T.、Rekhter、Y。、およびE. Rosen、編、「IPまたはGeneric Routing Encapsulation（GRE）でのMPLSのカプセル化」、RFC 4023、DOI 10.17487 / RFC4023、2005年3月、<http：/ /www.rfc-editor.org/info/rfc4023>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、編、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）」、RFC 4443、DOI 10.17487 / RFC4443、3月2006、<http://www.rfc-editor.org/info/rfc4443>。
[OPSEC-V6] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Security Considerations for IPv6 Networks", Work in Progress, draft-ietf-opsec-v6-07, September 2015.
[OPSEC-V6] Chittimaneni、K.、Kaeo、M。、およびE. Vyncke、「IPv6ネットワークの運用上のセキュリティの考慮事項」、作業中、draft-ietf-opsec-v6-07、2015年9月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<http://www.rfc-editor.org/info/rfc1918>。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, DOI 10.17487/RFC4942, September 2007, <http://www.rfc-editor.org/info/rfc4942>.
[RFC4942] Davies、E.、Krishnan、S。、およびP. Savola、「IPv6移行/共存セキュリティの考慮事項」、RFC 4942、DOI 10.17487 / RFC4942、2007年9月、<http：//www.rfc-editor .org / info / rfc4942>。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, DOI 10.17487/RFC6169, April 2011, <http://www.rfc-editor.org/info/rfc6169>.
[RFC6169] Krishnan、S.、Thaler、D。、およびJ. Hoagland、「IPトンネリングに関するセキュリティ上の懸念」、RFC 6169、DOI 10.17487 / RFC6169、2011年4月、<http://www.rfc-editor.org/ info / rfc6169>。
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <http://www.rfc-editor.org/info/rfc7042>.
[RFC7042] Eastlake 3rd、D。およびJ. Abley、「IANAの考慮事項およびIEEE 802パラメータのIETFプロトコルおよびドキュメントの使用法」、BCP 141、RFC 7042、DOI 10.17487 / RFC7042、2013年10月、<http：//www.rfc -editor.org/info/rfc7042>。
[RFC7588] Bonica, R., Pignataro, C., and J. Touch, "A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem", RFC 7588, DOI 10.17487/RFC7588, July 2015, <http://www.rfc-editor.org/info/rfc7588>.
[RFC7588]ボニカ、R。、ピグナタロ、C.、J。タッチ、「Generic Routing Encapsulation（GRE）フラグメンテーション問題に対する広く展開されたソリューション」、RFC 7588、DOI 10.17487 / RFC7588、2015年7月、<http：/ /www.rfc-editor.org/info/rfc7588>。
Acknowledgements
謝辞
The authors would like to thank Fred Baker, Stewart Bryant, Benoit Claise, Ben Campbell, Carlos Jesus Bernardos Cano, Spencer Dawkins, Dino Farinacci, David Farmer, Brian Haberman, Tom Herbert, Kathleen Moriarty, Fred Templin, Joe Touch, Andrew Yourtchenko, and Lucy Yong for their thorough review and useful comments.
著者は、フレッドベイカー、スチュワートブライアント、ブノワクレイズ、ベンキャンベル、カルロスジーザスベルナルドスカノ、スペンサードーキンス、ディノファリナッチ、デビッドファーマー、ブライアンハーバーマン、トムハーバート、キャスリーンモリアーティ、フレッドテンプリン、ジョータッチ、アンドリューユアチェンコ、徹底的なレビューと有益なコメントをしてくれたLucy Yong。
Authors' Addresses
著者のアドレス
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, North Carolina 27709 United States
カルロスピグナタロCisco Systems 7200-12 Kit Creek Road Research Triangle Park、North Carolina 27709 United States
Email: cpignata@cisco.com
Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia United States
Ron Bonica Juniper Networks 2251 Corporate Park Driveハーンドン、バージニア州アメリカ合衆国
Email: rbonica@juniper.net
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
Suresh Krishnan Ericsson 8400 Decarie Blvd.マウントロイヤルの町、QCカナダ
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com