[要約] RFC 6092は、住宅向けIPv6インターネットサービスを提供するための顧客設備（CPE）における推奨される簡易セキュリティ機能についての要約です。このRFCの目的は、住宅ユーザーのセキュリティを向上させるために、CPEにおけるIPv6インターネットサービスのセキュリティ機能を提案することです。
Internet Engineering Task Force (IETF) J. Woodyatt, Ed.
Request for Comments: 6092 Apple
Category: Informational January 2011
ISSN: 2070-1721
Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service
住宅用IPv6インターネットサービスを提供するための顧客宅内機器（CPE）の推奨される単純なセキュリティ機能
Abstract
概要
This document identifies a set of recommendations for the makers of devices and describes how to provide for "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices.
このドキュメントでは、デバイスメーカー向けの一連の推奨事項を示し、インターネット対応の家庭や小規模オフィスのローカルエリアIPv6ネットワークの境界で「単純なセキュリティ」機能を提供する方法について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6092.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6092で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Special Language ...........................................3
1.2. Use of Normative Keywords ..................................3
2. Overview ........................................................4
2.1. Basic Sanitation ...........................................5
2.2. Internet Layer Protocols ...................................5
2.3. Transport Layer Protocols ..................................6
3. Detailed Recommendations ........................................6
3.1. Stateless Filters ..........................................7
3.2. Connection-Free Filters ....................................8
3.2.1. Internet Control and Management .....................8
3.2.2. Upper-Layer Transport Protocols .....................8
3.2.3. UDP Filters ........................................10
3.2.4. IPsec and Internet Key Exchange (IKE) ..............11
3.2.5. Mobility Support in IPv6 ...........................12
3.3. Connection-Oriented Filters ...............................13
3.3.1. TCP Filters ........................................14
3.3.2. SCTP Filters .......................................17
3.3.3. DCCP Filters .......................................20
3.3.4. Level 3 Multihoming Shim Protocol for IPv6
(Shim6) ............................................23
3.4. Passive Listeners .........................................23
3.5. Management Applications ...................................24
4. Summary of Recommendations .....................................25
5. Contributors ...................................................31
6. Security Considerations ........................................32
7. References .....................................................33
7.1. Normative References ......................................33
7.2. Informative References ....................................35
Some IPv6 gateway devices that enable delivery of Internet services in residential and small-office settings may be augmented with "simple security" capabilities as described in "Local Network Protection for IPv6" [RFC4864]. In general, these capabilities cause packets to be discarded in an attempt to make local networks and the Internet more secure. However, it is worth noting that some packets sent by legitimate applications may also be discarded in this process, affecting reliability and ease of use for these applications.
「IPv6のローカルネットワーク保護」[RFC4864]で説明されているように、住宅や小規模オフィスの設定でインターネットサービスの配信を可能にする一部のIPv6ゲートウェイデバイスは、「単純なセキュリティ」機能で拡張される場合があります。一般に、これらの機能により、ローカルネットワークとインターネットをより安全にするためにパケットが破棄されます。ただし、正当なアプリケーションによって送信された一部のパケットもこのプロセスで破棄され、これらのアプリケーションの信頼性と使いやすさに影響を与える可能性があることに注意してください。
There is a constructive tension between the desires of users for transparent end-to-end connectivity on the one hand, and the need for local-area network administrators to detect and prevent intrusion by unauthorized public Internet users on the other. This document is intended to highlight reasonable limitations on end-to-end transparency where security considerations are deemed important to promote local and Internet security.
一方で透過的なエンドツーエンドの接続性に対するユーザーの要望と、ローカルエリアネットワーク管理者が他方で無許可のパブリックインターネットユーザーによる侵入を検出および防止する必要性との間には建設的な緊張があります。このドキュメントは、ローカルおよびインターネットのセキュリティを促進するためにセキュリティの考慮事項が重要であると見なされるエンドツーエンドの透明性に関する合理的な制限を強調することを目的としています。
The reader is cautioned always to remember that the typical residential or small-office network administrator has no expertise whatsoever in Internet engineering. Configuration interfaces for router/gateway appliances marketed toward them should be easy to understand and even easier to ignore. In particular, extra care should be used in the design of baseline operating modes for unconfigured devices, since most devices will never be changed from their factory configurations.
読者は常に、一般的な住宅または小規模オフィスのネットワーク管理者は、インターネットエンジニアリングの専門知識を一切持っていないことを覚えておいてください。それらに向けて販売されているルーター/ゲートウェイアプライアンスの構成インターフェイスは、理解しやすく、無視しやすくする必要があります。特に、ほとんどのデバイスは工場出荷時の構成から変更されることはないため、未構成のデバイスのベースライン動作モードの設計には特別な注意を払う必要があります。
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]で説明されているように解釈されます。
Additionally, the key word "DEFAULT" is to be interpreted in this document as pertaining to a configuration as applied by a vendor, prior to the administrator changing it for its initial activation.
さらに、キーワード「デフォルト」は、このドキュメントでは、管理者が初期アクティベーションのために変更する前に、ベンダーによって適用される構成に関連するものとして解釈されます。
NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. It uses the normative keywords defined in the previous section only for precision.
注：このドキュメントは標準ではなく、IPv6のIETF標準への準拠を主張するために、このドキュメントに準拠する必要はありません。これは、前のセクションで定義された規範的なキーワードを精度のためだけに使用します。
Particular attention is drawn to recommendation REC-49, which calls for an easy way to set a gateway to a transparent mode of operation.
ゲートウェイを透過的な動作モードに設定する簡単な方法を求める勧告REC-49に特に注意が向けられています。
For the purposes of this document, residential Internet gateways are assumed to be fairly simple devices with a limited subset of the full range of possible features. They function as default routers [RFC4294] for a single local-area network, e.g., an Ethernet network, a Wi-Fi network, or a bridge between two or more such segments. They have only one interface by which they can access the Internet service at any one time, using any of several possible sub-IP mechanisms, including tunnels and transition mechanisms.
このドキュメントの目的のために、住宅用インターネットゲートウェイは、可能な機能の全範囲の限られたサブセットを持つかなり単純なデバイスであると想定されています。それらは、イーサネットネットワーク、Wi-Fiネットワーク、または2つ以上のそのようなセグメント間のブリッジなど、単一のローカルエリアネットワークのデフォルトルーター[RFC4294]として機能します。トンネルや遷移メカニズムを含むいくつかの可能なサブIPメカニズムのいずれかを使用して、インターネットサービスにいつでもアクセスできるインターフェイスは1つだけです。
In referring to the security capabilities of residential gateways, it is reasonable to distinguish between their "interior" network, i.e., the local-area network, and their "exterior" networks, e.g., the public Internet and the networks of Internet service providers. This document is concerned only with the behavior of IP packet filters that police the flow of traffic between the interior IPv6 network and the exterior IPv6 networks of residential Internet gateways.
レジデンシャルゲートウェイのセキュリティ機能を参照する場合、ローカルエリアネットワークなどの「内部」ネットワークと、パブリックインターネットやインターネットサービスプロバイダーのネットワークなどの「外部」ネットワークを区別するのが妥当です。このドキュメントは、住宅のインターネットゲートウェイの内部IPv6ネットワークと外部IPv6ネットワークの間のトラフィックのフローをポリシングするIPパケットフィルターの動作にのみ関係しています。
The operational goals of security capabilities in Internet gateways are described with more detail in "Local Network Protection for IPv6" [RFC4864], but they can be summarized as follows.
インターネットゲートウェイのセキュリティ機能の運用目標については、「IPv6のローカルネットワーク保護」[RFC4864]で詳しく説明していますが、それらは次のように要約できます。
o Check all traffic to and from the public Internet for basic sanity, e.g., filter for spoofs and misdirected (sometimes called "Martian") packets [RFC4949].
o 公衆インターネットとの間のすべてのトラフィックをチェックして、基本的な健全性を確認します。たとえば、なりすましや誤って送信された（「火星」と呼ばれることもある）パケットをフィルタします[RFC4949]
o Allow tracking of application usage by source and destination network addresses and ports.
o 送信元と宛先のネットワークアドレスとポートごとにアプリケーションの使用状況を追跡できます。
o Provide a barrier against untrusted external influences on the interior network by requiring filter state to be activated by traffic originating at interior network nodes.
o 内部ネットワークノードから発信されるトラフィックによってフィルター状態をアクティブにすることを要求することにより、内部ネットワークに対する信頼できない外部の影響に対する障壁を提供します。
o Allow manually configured exceptions to the stateful filtering rules according to network administrative policy.
o ネットワーク管理ポリシーに従って、ステートフルフィルタリングルールに手動で構成された例外を許可します。
o Isolate local network DHCPv6 and DNS resolver services from the public Internet.
o ローカルネットワークDHCPv6およびDNSリゾルバーサービスをパブリックインターネットから分離します。
Prior to the widespread availability of IPv6 Internet service, homes and small offices often used private IPv4 network address realms [RFC1918] with Network Address Translation (NAT) functions deployed to present all the hosts on the interior network as a single host to the Internet service provider. The stateful packet filtering behavior of NAT set user expectations that persist today with residential IPv6 service. "Local Network Protection for IPv6" [RFC4864] recommends applying stateful packet filtering at residential IPv6 gateways that conforms to the user expectations already in place.
IPv6インターネットサービスが広く利用できるようになる前は、家庭や小規模オフィスでプライベートIPv4ネットワークアドレスレルム[RFC1918]が使用されていました。これは、ネットワークアドレス変換（NAT）機能が導入されており、内部ネットワーク上のすべてのホストを単一のホストとしてインターネットサービスに提示していました。プロバイダー。 NATのステートフルパケットフィルタリング動作は、住宅IPv6サービスで今日も続くユーザーの期待を設定します。 「IPv6のローカルネットワーク保護」[RFC4864]は、すでに存在するユーザーの期待に適合する住宅用IPv6ゲートウェイでステートフルパケットフィルタリングを適用することを推奨しています。
Conventional stateful packet filters activate new states as a side effect of forwarding outbound flow initiations from interior network nodes. This requires applications to have advance knowledge of the addresses of exterior nodes with which they expect to communicate. Several proposals are currently under consideration for allowing applications to solicit inbound traffic from exterior nodes without advance knowledge of their addresses. While consensus within the Internet engineering community has emerged that such protocols are necessary to implement in residential IPv6 gateways, the best current practice has not yet been established.
従来のステートフルパケットフィルターは、内部ネットワークノードからのアウトバウンドフロー開始の転送の副作用として、新しい状態をアクティブにします。これには、アプリケーションが通信する予定の外部ノードのアドレスを事前に知っている必要があります。アプリケーションがアドレスを事前に知らなくても外部ノードからのインバウンドトラフィックを要求できるようにするために、現在いくつかの提案が検討されています。インターネットエンジニアリングコミュニティ内のコンセンサスは、住宅用IPv6ゲートウェイに実装するためにそのようなプロトコルが必要であることが明らかになりましたが、現在のところ最良の慣行はまだ確立されていません。
In addition to the functions required of all IPv6 routers [RFC4294], residential gateways are expected to have basic stateless filters for prohibiting certain kinds of traffic with invalid headers, e.g., "Martian" packets, spoofs, routing header type code zero, etc. (See Section 3.1 for more details.)
すべてのIPv6ルーター[RFC4294]に必要な機能に加えて、レジデンシャルゲートウェイには、「火星」パケット、スプーフ、ルーティングヘッダータイプコード0などの無効なヘッダーを持つ特定の種類のトラフィックを禁止する基本的なステートレスフィルターが必要です。 （詳細については、セクション3.1を参照してください。）
Conversely, simple Internet gateways are not expected to prohibit the development of new applications. In particular, packets with end-to-end network security and routing extension headers for mobility are expected to pass Internet gateways freely.
逆に、単純なインターネットゲートウェイは、新しいアプリケーションの開発を禁止するものではありません。特に、エンドツーエンドのネットワークセキュリティとモビリティ用のルーティング拡張ヘッダーを備えたパケットは、インターネットゲートウェイを自由に通過することが期待されています。
Finally, Internet gateways that route multicast traffic are expected to implement appropriate filters for multicast traffic to limit the scope of multicast groups that span the demarcation between residential networks and service provider networks.
最後に、マルチキャストトラフィックをルーティングするインターネットゲートウェイは、マルチキャストトラフィックに適切なフィルターを実装して、住宅用ネットワークとサービスプロバイダーネットワークの間の境界にまたがるマルチキャストグループのスコープを制限することが期待されています。
As virtual private networking tunnels are regarded as an unacceptably wide attack surface, this document recommends that the DEFAULT operating mode for residential IPv6 simple security be to treat Generic Packet Tunneling [RFC2473] and similar protocols as opaque transport layers, i.e., inbound tunnel initiations are denied and outbound tunnel initiations are accepted.
仮想プライベートネットワーキングトンネルは許容できないほど広い攻撃面と見なされるため、このドキュメントでは、住宅IPv6シンプルセキュリティのデフォルトの動作モードでGeneric Packet Tunneling [RFC2473]と同様のプロトコルを不透明なトランスポートレイヤーとして扱うことを推奨しています。つまり、インバウンドトンネルの開始は拒否され、送信トンネルの開始が受け入れられます。
IPsec transport and tunnel modes are explicitly secured by definition, so this document recommends that the DEFAULT operating mode permit IPsec. To facilitate the use of IPsec in support of IPv6 mobility, the Internet Key Exchange (IKE) protocol [RFC5996] and the Host Identity Protocol (HIP) [RFC5201] should also be permitted in the DEFAULT operating mode.
IPsecトランスポートモードとトンネルモードは定義によって明示的に保護されているため、このドキュメントでは、DEFAULT動作モードでIPsecを許可することを推奨しています。 IPv6モビリティをサポートするIPsecの使用を容易にするために、インターネットキーエクスチェンジ（IKE）プロトコル[RFC5996]とホストアイデンティティプロトコル（HIP）[RFC5201]もDEFAULT動作モードで許可する必要があります。
IPv6 simple security functions are principally concerned with the stateful filtering of the Internet Control Message Protocol (ICMPv6) [RFC4443] and transport layers like the User Datagram Protocol (UDP) [RFC0768], the Lightweight User Datagram Protocol (UDP-Lite) [RFC3828], the Transmission Control Protocol (TCP) [RFC0793], the Stream Control Transmission Protocol (SCTP) [RFC4960], the Datagram Congestion Control Protocol (DCCP) [RFC4340], and potentially any standards-track transport protocols to be defined in the future.
IPv6の単純なセキュリティ機能は主に、インターネット制御メッセージプロトコル（ICMPv6）[RFC4443]のステートフルフィルタリングと、ユーザーデータグラムプロトコル（UDP）[RFC0768]、軽量ユーザーデータグラムプロトコル（UDP-Lite）[RFC3828]などのトランスポート層に関係しています。 ]、伝送制御プロトコル（TCP）[RFC0793]、ストリーム制御伝送プロトコル（SCTP）[RFC4960]、データグラム輻輳制御プロトコル（DCCP）[RFC4340]、および潜在的に、未来。
The general operating principle is that transport layer traffic is not forwarded into the interior network of a residential IPv6 gateway unless it has been solicited explicitly by interior transport endpoints, e.g., by matching the reverse path for previously forwarded outbound traffic, or by matching configured exceptions set by the network administrator. All other traffic is expected to be discarded or rejected with an ICMPv6 error message to indicate the traffic is administratively prohibited.
一般的な動作原理は、トランスポートレイヤートラフィックは、内部トランスポートエンドポイントによって明示的に要求されていない限り、たとえば以前に転送された送信トラフィックのリバースパスを一致させることによって、または構成された例外を一致させることによって、住宅IPv6ゲートウェイの内部ネットワークに転送されないことです。ネットワーク管理者が設定します。他のすべてのトラフィックは、ICMPv6エラーメッセージで破棄または拒否され、トラフィックが管理上禁止されていることを示します。
This section describes the specific recommendations made by this document in full detail. Section 4 is a summary.
このセクションでは、このドキュメントによって作成された特定の推奨事項について詳しく説明します。セクション4は要約です。
Some recommended filters are to be applied to all traffic that passes through residential Internet gateways regardless of the direction they are to be forwarded. Other recommended filters are intended to be sensitive to the "direction" of traffic flows. Applied to bidirectional transport flows, "direction" has a specific meaning in this document.
一部の推奨フィルターは、転送される方向に関係なく、住宅用インターネットゲートウェイを通過するすべてのトラフィックに適用されます。その他の推奨フィルターは、トラフィックフローの「方向」に敏感であることを目的としています。このドキュメントでは、双方向のトランスポートフローに適用される「方向」に特定の意味があります。
Packets are said to be "outbound" if they originate at nodes located in the interior network for exterior destinations, and "inbound" if they arrive from exterior sources with interior destinations.
パケットは、外部宛先の内部ネットワークにあるノードで発信される場合は「送信」と呼ばれ、内部宛先の外部ソースから到着する場合は「受信」と呼ばれます。
Flows are said to be "outbound" if the originator of the initial packet in any given transport association is an interior node and one or more of the participants are located in the exterior. Flows are said to be "inbound" if the originator of the initial packet is an exterior node and one or more of the participants are nodes on the interior network.
特定のトランスポートアソシエーションの最初のパケットの発信者が内部ノードであり、1つ以上の参加者が外部にいる場合、フローは「アウトバウンド」であるといいます。最初のパケットの発信者が外部ノードであり、1つ以上の参加者が内部ネットワークのノードである場合、フローは「インバウンド」であるといいます。
Certain kinds of IPv6 packets MUST NOT be forwarded in either direction by residential Internet gateways regardless of network state. These include packets with multicast source addresses, packets to destinations with certain non-routable and/or reserved prefixes, and packets with deprecated extension headers.
特定の種類のIPv6パケットは、ネットワークの状態に関係なく、住宅用インターネットゲートウェイによってどちらの方向にも転送してはなりません（MUST NOT）。これには、マルチキャストの送信元アドレスを持つパケット、特定のルーティング不可または予約済みのプレフィックスを持つ宛先へのパケット、非推奨の拡張ヘッダーを持つパケットが含まれます。
Other stateless filters are recommended to implement ingress filtering (see [RFC2827] and [RFC3704]), to enforce multicast scope boundaries, and to isolate certain local network services from the public Internet.
入力フィルタリング（[RFC2827]および[RFC3704]を参照）を実装し、マルチキャストスコープの境界を適用し、特定のローカルネットワークサービスをパブリックインターネットから分離するには、他のステートレスフィルターをお勧めします。
REC-1: Packets bearing multicast source addresses in their outer IPv6 headers MUST NOT be forwarded or transmitted on any interface.
REC-1：外部IPv6ヘッダーにマルチキャスト送信元アドレスが含まれるパケットは、どのインターフェイスでも転送または送信してはなりません（MUST NOT）。
REC-2: Packets bearing multicast destination addresses in their outer IPv6 headers of equal or narrower scope (see "IPv6 Scoped Address Architecture" [RFC4007]) than the configured scope boundary level of the gateway MUST NOT be forwarded in any direction. The DEFAULT scope boundary level SHOULD be organization-local scope, and it SHOULD be configurable by the network administrator.
REC-2：ゲートウェイの構成されたスコープ境界レベルよりも等しいまたは狭いスコープ（「IPv6スコープアドレスアーキテクチャ」[RFC4007]を参照）の外部IPv6ヘッダーにマルチキャスト宛先アドレスを含むパケットは、どの方向にも転送してはなりません。 DEFAULTスコープの境界レベルは、組織ローカルスコープである必要があり（SHOULD）、ネットワーク管理者が構成可能である必要があります（SHOULD）。
REC-3: Packets bearing source and/or destination addresses forbidden to appear in the outer headers of packets transmitted over the public Internet MUST NOT be forwarded. In particular, site-local addresses are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use of address blocks of types IPv4-Mapped Addresses, IPv4-Compatible Addresses, Documentation Prefix, and Overlay Routable Cryptographic Hash IDentifiers (ORCHID).
REC-3：公衆インターネットを介して送信されるパケットの外部ヘッダーに出現することが禁止されている送信元アドレスまたは宛先アドレス、あるいはその両方を含むパケットは転送してはなりません。特に、サイトローカルアドレスは[RFC3879]で非推奨になり、[RFC5156]は、IPv4マッピングアドレス、IPv4互換アドレス、ドキュメントプレフィックス、およびオーバーレイルーティング可能な暗号化ハッシュID（ORCHID）タイプのアドレスブロックの使用を明示的に禁止しています。
REC-4: Packets bearing deprecated extension headers prior to their first upper-layer-protocol header SHOULD NOT be forwarded or transmitted on any interface. In particular, all packets with routing extension header type 0 [RFC2460] preceding the first upper-layer-protocol header MUST NOT be forwarded. See [RFC5095] for additional background.
REC-4：最初の上位層プロトコルヘッダーの前に廃止された拡張ヘッダーが付いたパケットは、どのインターフェイスでも転送または送信してはなりません（SHOULD NOT）。特に、最初の上位層プロトコルヘッダーに先行するルーティング拡張ヘッダータイプ0 [RFC2460]のすべてのパケットは転送してはなりません（MUST NOT）。追加の背景については、[RFC5095]を参照してください。
REC-5: Outbound packets MUST NOT be forwarded if the source address in their outer IPv6 header does not have a unicast prefix configured for use by globally reachable nodes on the interior network.
REC-5：外部IPv6ヘッダーのソースアドレスに、内部ネットワーク上のグローバルに到達可能なノードが使用するように構成されたユニキャストプレフィックスがない場合、送信パケットを転送してはなりません（MUST NOT）。
REC-6: Inbound packets MUST NOT be forwarded if the source address in their outer IPv6 header has a global unicast prefix assigned for use by globally reachable nodes on the interior network.
REC-6：外部IPv6ヘッダーのソースアドレスに、内部ネットワーク上のグローバルに到達可能なノードが使用するために割り当てられたグローバルユニキャストプレフィックスがある場合、受信パケットを転送してはなりません（MUST NOT）。
REC-7: By DEFAULT, packets with unique local source and/or destination addresses [RFC4193] SHOULD NOT be forwarded to or from the exterior network.
REC-7：デフォルトでは、一意のローカル送信元アドレスまたは宛先アドレス、あるいはその両方[RFC4193]を持つパケットは、外部ネットワークとの間で転送されるべきではない（SHOULD NOT）。
REC-8: By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server.
REC-8：デフォルトでは、外部インターフェースで受信されたインバウンドDNSクエリは、統合されたDNS解決サーバーによって処理されてはなりません（MUST NOT）。
REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on exterior interfaces MUST NOT be processed by any integrated DHCPv6 server or relay agent.
REC-9：外部インターフェースで受信されたインバウンドDHCPv6検出パケット[RFC3315]は、統合されたDHCPv6サーバーまたはリレーエージェントによって処理されてはなりません（MUST NOT）。
NOTE WELL: Nothing in this document relieves residential Internet gateways, when processing headers to identify valid sequences of upper-layer transport packets, from any of the requirements of the "Internet Protocol, Version 6 (IPv6) Specification" [RFC2460], including any and all future updates and revisions.
注：このドキュメントでは、「インターネットプロトコル、バージョン6（IPv6）仕様」[RFC2460]の要件のいずれかから、ヘッダーを処理して上位層のトランスポートパケットの有効なシーケンスを識別するときに、住宅用インターネットゲートウェイを緩和するものはありません。およびすべての将来の更新と改訂。
Some Internet applications use connection-free transport protocols with no release semantics, e.g., UDP. These protocols pose a special difficulty for stateful packet filters because most of the application state is not carried at the transport level. State records are created when communication is initiated and are abandoned when no further communication is detected after some period of time.
一部のインターネットアプリケーションは、UDPなどのリリースセマンティクスのないコネクションフリー転送プロトコルを使用します。これらのプロトコルは、ほとんどのアプリケーション状態がトランスポートレベルで伝送されないため、ステートフルパケットフィルターに特別な困難をもたらします。状態レコードは、通信が開始されたときに作成され、一定期間後にそれ以上の通信が検出されなくなったときに破棄されます。
Recommendations for filtering ICMPv6 messages in firewall devices are described separately in [RFC4890] and apply to residential gateways, with the additional recommendation that incoming "Destination Unreachable" and "Packet Too Big" error messages that don't match any filtering state should be dropped.
ファイアウォールデバイスでICMPv6メッセージをフィルタリングするための推奨事項は、[RFC4890]で個別に説明されており、レジデンシャルゲートウェイに適用されます。さらに、フィルタリング状態に一致しない「宛先到達不能」および「パケットが大きすぎます」というエラーメッセージを削除することを推奨します。 。
REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing IP headers that do not match generic upper-layer transport state records.
REC-10：IPv6ゲートウェイは、一般的な上位層のトランスポート状態レコードと一致しないIPヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージを転送しないでください。
Residential IPv6 gateways are not expected to prohibit the use of applications to be developed using future upper-layer transport protocols. In particular, transport protocols not otherwise discussed in subsequent sections of this document are expected to be treated consistently, i.e., as having connection-free semantics and no special requirements to inspect the transport headers.
住宅用IPv6ゲートウェイは、将来の上位層トランスポートプロトコルを使用して開発されるアプリケーションの使用を禁止することは期待されていません。特に、このドキュメントの後続のセクションで特に説明されていないトランスポートプロトコルは、一貫して扱われることが期待されます。
In general, upper-layer transport filter state records are expected to be created when an interior endpoint sends a packet to an exterior address. The filter allocates (or reuses) a record for the duration of communications, with an idle timer to delete the state record when no further communications are detected.
一般に、上位層のトランスポートフィルターの状態レコードは、内部エンドポイントがパケットを外部アドレスに送信するときに作成されると予想されます。フィルターは、通信が継続している間、レコードを割り当て（または再利用）し、アイドルタイマーを使用して、通信が検出されなくなったときに状態レコードを削除します。
One key aspect of how a packet filter behaves is the way it evaluates the exterior address of an endpoint when applying a filtering rule. A gateway is said to have "endpoint-independent filtering" behavior when the exterior address is not evaluated when matching a packet with a flow. A gateway is said to have "address-dependent filtering" behavior when the exterior address of a packet is required to match the exterior address for its flow.
パケットフィルターの動作の重要な側面の1つは、フィルタリングルールを適用するときにエンドポイントの外部アドレスを評価する方法です。パケットをフローと照合するときに外部アドレスが評価されない場合、ゲートウェイは「エンドポイントに依存しないフィルタリング」動作をしていると言われます。パケットの外部アドレスがそのフローの外部アドレスと一致する必要がある場合、ゲートウェイは「アドレス依存のフィルタリング」動作をすると言われています。
REC-11: If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for generic upper-layer transport protocols. If a more stringent filtering behavior is most important, then a filter SHOULD have "address-dependent filtering" behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.
REC-11：アプリケーションの透過性が最も重要な場合、ステートフルパケットフィルターは、一般的な上位層トランスポートプロトコルに対して「エンドポイントに依存しないフィルタリング」動作を持つ必要があります（SHOULD）。より厳格なフィルタリング動作が最も重要な場合、フィルターは「アドレス依存のフィルタリング」動作を持つ必要があります（SHOULD）。フィルタリング動作は、ネットワーク管理者が構成可能なオプションである場合があり、他のプロトコルのフィルタリング動作から独立している場合があります。フィルタリング動作は、サービスプロバイダー管理なしのプロビジョニングを目的としたゲートウェイで、DEFAULTによってエンドポイントに依存しないようにする必要があります。
REC-12: Filter state records for generic upper-layer transport protocols MUST NOT be deleted or recycled until an idle timer not less than two minutes has expired without having forwarded a packet matching the state in some configurable amount of time. By DEFAULT, the idle timer for such state records is five minutes.
REC-12：設定可能な時間内に状態に一致するパケットを転送せずに2分以上のアイドルタイマーが期限切れになるまで、一般的な上位層トランスポートプロトコルのフィルター状態レコードを削除またはリサイクルしてはなりません（MUST NOT）。デフォルトでは、そのような状態レコードのアイドルタイマーは5分です。
The Internet security community is never completely at rest. New attack surfaces, and vulnerabilities in them, are typically discovered faster than they can be patched by normal equipment upgrade cycles. It's therefore important for vendors of residential gateway equipment to provide automatic software updates to patch vulnerabilities as they are discovered.
インターネットセキュリティコミュニティが完全に停止することはありません。通常、新しい攻撃対象とその脆弱性は、通常の機器のアップグレードサイクルでパッチを適用するよりも早く発見されます。したがって、住宅用ゲートウェイ機器のベンダーは、脆弱性が発見されたときにパッチを適用するための自動ソフトウェアアップデートを提供することが重要です。
REC-13: Residential IPv6 gateways SHOULD provide a convenient means to update their firmware securely, for the installation of security patches and other manufacturer-recommended changes.
REC-13：レジデンシャルIPv6ゲートウェイは、セキュリティパッチのインストールやその他のメーカー推奨の変更のために、ファームウェアを安全に更新するための便利な手段を提供する必要があります（SHOULD）。
Vendors can expect users and operators to have differing viewpoints on the maintenance of patches, with some preferring automatic update and some preferring manual procedures. Those preferring automatic update may also prefer either to download from a vendor site or from one managed by their network provider. To handle the disparity, vendors are advised to provide both manual and automatic options. In the automatic case, they would do well to facilitate pre-configuration of the download URL and a means of validating the software image, such as a certificate.
ベンダーは、パッチのメンテナンスに関してユーザーとオペレーターが異なる見方をすることを期待できます。自動更新を好む人もいれば、手動手順を好む人もいます。自動更新を好むユーザーは、ベンダーサイトまたはネットワークプロバイダーが管理するサイトからダウンロードすることもできます。格差を処理するために、ベンダーは手動と自動の両方のオプションを提供することをお勧めします。自動の場合は、ダウンロードURLの事前設定と、証明書などのソフトウェアイメージを検証する手段を容易にするために役立ちます。
"Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" [RFC4787] defines the terminology and best current practice for stateful filtering of UDP applications in IPv4 with NAT, which serves as the model for behavioral requirements for simple UDP security in IPv6 gateways, notwithstanding the requirements related specifically to network address translation.
「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」[RFC4787]は、IPv6ゲートウェイでの単純なUDPセキュリティの動作要件のモデルとして機能する、NATを使用したIPv4でのUDPアプリケーションのステートフルフィルタリングの用語と現在のベストプラクティスを定義しています。特にネットワークアドレス変換に関連する要件にもかかわらず。
An interior endpoint initiates a UDP flow through a stateful packet filter by sending a packet to an exterior address. The filter allocates (or reuses) a filter state record for the duration of the flow. The state record defines the interior and exterior IP addresses and ports used between all packets in the flow.
内部エンドポイントは、パケットを外部アドレスに送信することにより、ステートフルパケットフィルターを介してUDPフローを開始します。フィルターは、フローの期間中、フィルター状態レコードを割り当てます（または再利用します）。状態レコードは、フロー内のすべてのパケット間で使用される内部および外部IPアドレスとポートを定義します。
State records for UDP flows remain active while they are in use and are only abandoned after an idle period of some time.
UDPフローの状態レコードは、使用中もアクティブのままであり、しばらくアイドル状態になった後にのみ破棄されます。
REC-14: A state record for a UDP flow where both source and destination ports are outside the well-known port range (ports 0-1023) MUST NOT expire in less than two minutes of idle time. The value of the UDP state record idle timer MAY be configurable. The DEFAULT is five minutes.
REC-14：送信元ポートと宛先ポートの両方が既知のポート範囲（ポート0〜1023）の外側にあるUDPフローの状態レコードは、アイドル時間の2分未満で期限切れになってはならない（MUST NOT）。 UDP状態レコードのアイドルタイマーの値は構成可能である場合があります。 DEFAULTは5分です。
REC-15: A state record for a UDP flow where one or both of the source and destination ports are in the well-known port range (ports 0-1023) MAY expire after a period of idle time shorter than two minutes to facilitate the operation of the IANA-registered service assigned to the port in question.
REC-15：送信元ポートと宛先ポートの一方または両方が既知のポート範囲（ポート0-1023）にあるUDPフローの状態レコードは、2分未満のアイドル時間が経過すると期限切れになり、問題のポートに割り当てられているIANA登録サービスの操作。
As [RFC4787] notes, outbound refresh is necessary for allowing the interior endpoint to keep the state record alive. Inbound refresh may be useful for applications with no outbound UDP traffic. However, allowing inbound refresh can allow an attacker in the exterior or a misbehaving application to keep a state record alive indefinitely. This could be a security risk. Also, if the process is repeated with different ports, over time, it could use up all the state record memory and resources in the filter.
[RFC4787]が指摘しているように、内部エンドポイントが状態レコードを維持できるようにするには、アウトバウンドリフレッシュが必要です。インバウンド更新は、アウトバウンドUDPトラフィックのないアプリケーションに役立つ場合があります。ただし、インバウンドリフレッシュを許可すると、外部の攻撃者または不正なアプリケーションが状態レコードを無期限に存続させる可能性があります。これはセキュリティ上のリスクになる可能性があります。また、異なるポートを使用してプロセスが繰り返されると、時間の経過とともに、フィルター内のすべての状態レコードのメモリとリソースを使い果たす可能性があります。
REC-16: A state record for a UDP flow MUST be refreshed when a packet is forwarded from the interior to the exterior, and it MAY be refreshed when a packet is forwarded in the reverse direction.
REC-16：UDPフローの状態レコードは、パケットが内部から外部に転送されるときに更新される必要があり、パケットが逆方向に転送されるときに更新される場合があります。
As described in Section 5 of [RFC4787], the connection-free semantics of UDP pose a difficulty for packet filters in trying to recognize which packets comprise an application flow and which are unsolicited. Various strategies have been used in IPv4/NAT gateways with differing effects.
[RFC4787]のセクション5で説明されているように、UDPの接続なしのセマンティクスは、パケットフィルターがアプリケーションフローを構成するパケットと非送信請求のパケットを認識しようとする際に困難をもたらします。 IPv4 / NATゲートウェイでは、さまざまな効果を持つさまざまな戦略が使用されています。
REC-17: If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for UDP. If a more stringent filtering behavior is most important, then a filter SHOULD have "address-dependent filtering" behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for TCP and other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.
REC-17：アプリケーションの透過性が最も重要である場合、ステートフルパケットフィルターは、UDPに対して「エンドポイントに依存しないフィルタリング」動作を持つ必要があります（SHOULD）。より厳格なフィルタリング動作が最も重要な場合、フィルターは「アドレス依存のフィルタリング」動作を持つ必要があります（SHOULD）。フィルタリング動作は、ネットワーク管理者が構成可能なオプションである場合があり、TCPおよびその他のプロトコルのフィルタリング動作から独立している場合があります。フィルタリング動作は、サービスプロバイダー管理なしのプロビジョニングを目的としたゲートウェイで、DEFAULTによってエンドポイントに依存しないようにする必要があります。
Application mechanisms may depend on the reception of ICMPv6 error messages triggered by the transmission of UDP messages. One such mechanism is path MTU discovery [RFC1981].
アプリケーションメカニズムは、UDPメッセージの送信によってトリガーされるICMPv6エラーメッセージの受信に依存する場合があります。そのようなメカニズムの1つは、パスMTU発見[RFC1981]です。
REC-18: If a gateway forwards a UDP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing UDP headers that match the flow state record.
REC-18：ゲートウェイがUDPフローを転送する場合、ゲートウェイは、フロー状態レコードと一致するUDPヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージも転送する必要があります。
REC-19: Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a UDP flow.
REC-19：あらゆる種類のICMPv6メッセージの受信は、UDPフローの状態レコードを終了してはなりません（MUST NOT）。
REC-20: UDP-Lite flows [RFC3828] SHOULD be handled in the same way as UDP flows, except that the upper-layer transport protocol identifier for UDP-Lite is not the same as UDP; therefore, UDP packets MUST NOT match UDP-Lite state records, and vice versa.
REC-20：UDP-Liteフロー[RFC3828] UDP-Liteの上位層のトランスポートプロトコル識別子がUDPと同じではないことを除いて、UDPフローと同じ方法で処理する必要があります（SHOULD）。したがって、UDPパケットはUDP-Lite状態レコードと一致してはならず、その逆も同様です。
The Internet Protocol security (IPsec) suite offers greater flexibility and better overall security than the simple security of stateful packet filtering at network perimeters. Therefore, residential IPv6 gateways need not prohibit IPsec traffic flows.
インターネットプロトコルセキュリティ（IPsec）スイートは、ネットワーク境界でのステートフルパケットフィルタリングの単純なセキュリティよりも優れた柔軟性と優れた全体的なセキュリティを提供します。したがって、住宅IPv6ゲートウェイはIPsecトラフィックフローを禁止する必要はありません。
REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with destination extension headers of type "Authentication Header (AH)" [RFC4302] in their outer IP extension header chain.
REC-21：デフォルトの動作モードでは、IPv6ゲートウェイは、外部のIP拡張ヘッダーチェーンに「認証ヘッダー（AH）」タイプの宛先拡張ヘッダー[RFC4302]を使用して、正当なノードアドレスとの間のパケットの転送を禁止してはなりません（MUST NOT）。 。
REC-22: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with an upper-layer protocol of type "Encapsulating Security Payload (ESP)" [RFC4303] in their outer IP extension header chain.
REC-22：デフォルトの動作モードでは、IPv6ゲートウェイは、外部IPにタイプ「カプセル化セキュリティペイロード（ESP）」[RFC4303]の上位層プロトコルを使用して、正当なノードアドレスとの間のパケットの転送を禁止してはなりません（MUST NOT）。拡張ヘッダーチェーン。
REC-23: If a gateway forwards an ESP flow, it MUST also forward (in the reverse direction) ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing ESP headers that match the flow state record.
REC-23：ゲートウェイがESPフローを転送する場合は、フロー状態レコードと一致するESPヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージも（逆方向に）転送する必要があります。
Internet Key Exchange (IKE) is a secure mechanism for performing mutual authentication, exchanging cryptographic material, and establishing IPsec Security Associations between peers. Residential IPv6 gateways are expected to facilitate the use of IPsec security policies by allowing inbound IKE flows.
インターネットキーエクスチェンジ（IKE）は、相互認証を実行し、暗号化情報を交換し、ピア間のIPsecセキュリティアソシエーションを確立するための安全なメカニズムです。住宅IPv6ゲートウェイは、着信IKEフローを許可することにより、IPsecセキュリティポリシーの使用を容易にすることが期待されています。
REC-24: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of any UDP packets, to and from legitimate node addresses, with a destination port of 500, i.e., the port reserved by IANA for the Internet Key Exchange (IKE) protocol [RFC5996].
REC-24：デフォルトの動作モードでは、IPv6ゲートウェイは、宛先ポート500、つまりIANAによってインターネットキーエクスチェンジ（IKE）のために予約されているポートを使用して、正当なノードアドレスとの間のUDPパケットの転送を禁止してはなりません（MUST NOT）。 ）プロトコル[RFC5996]。
REC-25: In all operating modes, IPv6 gateways SHOULD use filter state records for Encapsulating Security Payload (ESP) [RFC4303] that are indexable by a 3-tuple comprising the interior node address, the exterior node address, and the ESP protocol identifier. In particular, the IPv4/NAT method of indexing state records also by the security parameters index (SPI) SHOULD NOT be used. Likewise, any mechanism that depends on detection of Internet Key Exchange (IKE) [RFC5996] initiations SHOULD NOT be used.
REC-25：すべての動作モードで、IPv6ゲートウェイは、カプセル化セキュリティペイロード（ESP）[RFC4303]のフィルター状態レコードを使用する必要があります[RFC4303]。これは、内部ノードアドレス、外部ノードアドレス、およびESPプロトコル識別子で構成される3タプルでインデックス付けできます。 。特に、セキュリティパラメータインデックス（SPI）によって状態レコードにインデックスを付けるIPv4 / NAT方式は使用しないでください。同様に、インターネットキー交換（IKE）[RFC5996]の開始の検出に依存するメカニズムは使用しないでください。
The Host Identity Protocol (HIP) is a secure mechanism for establishing host identity and secure communications between authenticated hosts. Residential IPv6 gateways need not prohibit inbound HIP flows.
ホストアイデンティティプロトコル（HIP）は、ホストアイデンティティを確立し、認証されたホスト間の安全な通信を確立するための安全なメカニズムです。住宅IPv6ゲートウェイは、インバウンドHIPフローを禁止する必要はありません。
REC-26: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with destination extension headers of type "Host Identity Protocol (HIP)" [RFC5201] in their outer IP extension header chain.
REC-26：デフォルトの動作モードでは、IPv6ゲートウェイは、外部IP拡張ヘッダーにタイプ「ホストアイデンティティプロトコル（HIP）」[RFC5201]の宛先拡張ヘッダーがある正規のノードアドレスとの間のパケットの転送を禁止してはならない（MUST NOT）鎖。
Mobility support in IPv6 [RFC3775] relies on the use of an encapsulation mechanism in flows between mobile nodes and their correspondent nodes, involving the use of the Type 2 IPv6 Routing Header, the Home Address destination header option, and the Mobility extension header. In contrast to mobility support in IPv4, mobility is a standard feature of IPv6, and no security benefit is generally to be gained by denying communications with either interior or exterior mobile nodes.
IPv6 [RFC3775]でのモビリティサポートは、タイプ2 IPv6ルーティングヘッダー、ホームアドレス宛先ヘッダーオプション、およびモビリティ拡張ヘッダーの使用を含む、モバイルノードと対応するノード間のフローでのカプセル化メカニズムの使用に依存しています。 IPv4のモビリティサポートとは対照的に、モビリティはIPv6の標準機能であり、一般に、内部または外部のモバイルノードとの通信を拒否してもセキュリティ上の利点は得られません。
Not all usage scenarios of mobility support in IPv6 are expected to be compatible with IPv6 simple security. In particular, exterior mobile nodes are expected to be prohibited from establishing bindings with interior correspondent nodes by the filtering of unsolicited inbound Mobility Header messages, unless they are the subject of an IPsec security policy.
IPv6でのモビリティサポートのすべての使用シナリオがIPv6シンプルセキュリティと互換性があるとは限りません。特に、外部のモバイルノードは、IPsecセキュリティポリシーの対象でない限り、未承諾のインバウンドモビリティヘッダーメッセージをフィルタリングすることにより、内部のコレスポンデントノードとのバインディングの確立が禁止されることが予想されます。
REC-27: The state records for flows initiated by outbound packets that bear a Home Address destination option [RFC3775] are distinguished by the addition of the home address of the flow as well as the interior care-of address. IPv6 gateways MUST NOT prohibit the forwarding of any inbound packets bearing type 2 routing headers, which otherwise match a flow state record, and where A) the address in the destination field of the IPv6 header matches the interior care-of address of the flow, and B) the Home Address field in the Type 2 Routing Header matches the home address of the flow.
REC-27：ホームアドレス宛先オプション[RFC3775]を含むアウトバウンドパケットによって開始されたフローの状態レコードは、フローのホームアドレスと内部気付アドレスの追加によって区別されます。 IPv6ゲートウェイは、タイプ2ルーティングヘッダーを持つ受信パケットの転送を禁止してはなりません。これは、フローステートレコードと一致し、A）IPv6ヘッダーの宛先フィールドのアドレスがフローの内部気付アドレスと一致します。 B）タイプ2ルーティングヘッダーのホームアドレスフィールドがフローのホームアドレスと一致する。
REC-28: Valid sequences of Mobility Header [RFC3775] packets MUST be forwarded for all outbound and explicitly permitted inbound Mobility Header flows.
REC-28：モビリティヘッダー[RFC3775]パケットの有効なシーケンスは、すべてのアウトバウンドおよび明示的に許可されたインバウンドのモビリティヘッダーフローで転送される必要があります。
REC-29: If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward, in both directions, the IPv4 and IPv6 packets that are encapsulated in IPv6 associated with the tunnel between the home agent and the correspondent node.
REC-29：ゲートウェイがモビリティヘッダー[RFC3775]フローを転送する場合、ホームエージェントとコレスポンデントノード間のトンネルに関連付けられたIPv6にカプセル化されたIPv4パケットとIPv6パケットも両方向に転送する必要があります。
REC-30: If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward (in the reverse direction) ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing any headers that match the associated flow state records.
REC-30：ゲートウェイがモビリティヘッダー[RFC3775]フローを転送する場合、関連するフロー状態レコードと一致するヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージも（逆方向に）転送する必要があります。
Most Internet applications use connection-oriented transport protocols with orderly release semantics. These protocols include TCP, SCTP, DCCP, and potentially any future IETF Standards-Track transport protocols that use such semantics. Stateful packet filters track the state of individual transport flows and prohibit the forwarding of packets that do not match the state of an active flow and do not conform to a rule for the automatic creation of such state.
ほとんどのインターネットアプリケーションは、接続指向のトランスポートプロトコルを使用し、整然としたリリースセマンティクスを備えています。これらのプロトコルには、TCP、SCTP、DCCP、およびそのようなセマンティクスを使用する将来のIETF Standards-Track転送プロトコルが含まれる可能性があります。ステートフルパケットフィルターは、個々のトランスポートフローの状態を追跡し、アクティブフローの状態と一致せず、そのような状態の自動作成のルールに準拠しないパケットの転送を禁止します。
An interior endpoint initiates a TCP flow through a stateful packet filter by sending a SYN packet. The filter allocates (or reuses) a filter state record for the flow. The state record defines the interior and exterior IP addresses and ports used for forwarding all packets for that flow.
内部エンドポイントは、SYNパケットを送信することにより、ステートフルパケットフィルターを介してTCPフローを開始します。フィルターは、フローのフィルター状態レコードを割り当てます（または再利用します）。状態レコードは、そのフローのすべてのパケットの転送に使用される内部および外部IPアドレスとポートを定義します。
Some peer-to-peer applications use an alternate method of connection initiation termed "simultaneous-open" ([RFC0793], Figure 8) to traverse stateful filters. In the simultaneous-open mode of operation, both peers send SYN packets for the same TCP flow. The SYN packets cross in the network. Upon receiving the other end's SYN packet, each end responds with a SYN-ACK packet, which also cross in the network. The connection is established at each endpoint once the SYN-ACK packets are received.
一部のピアツーピアアプリケーションは、「同時オープン」と呼ばれる接続開始の代替方法（[RFC0793]、図8）を使用して、ステートフルフィルターを通過します。同時オープン動作モードでは、両方のピアが同じTCPフローのSYNパケットを送信します。 SYNパケットはネットワークを通過します。相手側のSYNパケットを受信すると、両端はSYN-ACKパケットで応答し、これもネットワークを通過します。 SYN-ACKパケットが受信されると、各エンドポイントで接続が確立されます。
To provide stateful packet filtering service for TCP, it is necessary for a filter to receive, process, and forward all packets for a flow that conform to valid transitions of the TCP state machine ([RFC0793], Figure 6).
TCPにステートフルパケットフィルタリングサービスを提供するには、TCPステートマシンの有効な遷移に準拠するフローのすべてのパケットをフィルターで受信、処理、および転送する必要があります（[RFC0793]、図6）。
REC-31: All valid sequences of TCP packets (defined in [RFC0793]) MUST be forwarded for outbound flows and explicitly permitted inbound flows. In particular, both the normal TCP 3-way handshake mode of operation and the simultaneous-open mode of operation MUST be supported.
REC-31：TCPパケットのすべての有効なシーケンス（[RFC0793]で定義）は、アウトバウンドフローおよび明示的に許可されたインバウンドフローに転送する必要があります。特に、通常のTCP 3ウェイハンドシェイク操作モードと同時オープン操作モードの両方がサポートされている必要があります。
It is possible to reconstruct enough of the state of a TCP flow to allow forwarding between an interior and exterior node, even when the filter starts operating after TCP enters the established state. In this case, because the filter has not seen the TCP window-scale option, it is not possible for the filter to enforce the TCP window invariant by dropping out-of-window segments.
TCPフローの状態を十分に再構築して、TCPが確立された状態になってからフィルターが動作を開始した場合でも、内部ノードと外部ノード間の転送を可能にすることができます。この場合、フィルターはTCPウィンドウスケールオプションを認識していないため、フィルターがウィンドウ外のセグメントを削除してTCPウィンドウを不変に強制することはできません。
REC-32: The TCP window invariant MUST NOT be enforced on flows for which the filter did not detect whether the window-scale option (see [RFC1323]) was sent in the 3-way handshake or simultaneous-open.
REC-32：ウィンドウスケールオプション（[RFC1323]を参照）が3ウェイハンドシェイクまたは同時オープンで送信されたかどうかをフィルターが検出しなかったフローに対して、TCPウィンドウの不変条件を強制してはなりません（MUST NOT）。
A stateful filter can allow an existing state record to be reused by an externally initiated flow if its security policy permits. Several different policies are possible, as described in [RFC4787] and extended in [RFC5382].
ステートフルフィルターでは、セキュリティポリシーで許可されている場合、既存の状態レコードを外部で開始されたフローで再利用できます。 [RFC4787]で説明され、[RFC5382]で拡張されるように、いくつかの異なるポリシーが可能です。
REC-33: If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for TCP. If a more stringent filtering behavior is most important, then a filter SHOULD have "address-dependent filtering" behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for UDP and other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.
REC-33：アプリケーションの透過性が最も重要である場合、ステートフルパケットフィルターは、TCPに対して「エンドポイントに依存しないフィルタリング」動作を持つ必要があります（SHOULD）。より厳格なフィルタリング動作が最も重要な場合、フィルターは「アドレス依存のフィルタリング」動作を持つ必要があります（SHOULD）。フィルタリング動作は、ネットワーク管理者が構成可能なオプションである場合があり、UDPおよびその他のプロトコルのフィルタリング動作から独立している場合があります。フィルタリング動作は、サービスプロバイダー管理なしのプロビジョニングを目的としたゲートウェイで、DEFAULTによってエンドポイントに依存しないようにする必要があります。
If an inbound SYN packet is filtered, either because a corresponding state record does not exist or because of the filter's normal behavior, a filter has two basic choices: to discard the packet silently, or to signal an error to the sender. Signaling an error through ICMPv6 messages allows the sender to detect that the SYN did not reach the intended destination. Discarding the packet, on the other hand, allows applications to perform simultaneous-open more reliably. A more detailed discussion of this issue can be found in [RFC5382], but the basic outcome of it is that filters need to wait on signaling errors until simultaneous-open will not be impaired.
対応する状態レコードが存在しないか、フィルターの通常の動作が原因で、着信SYNパケットがフィルター処理される場合、フィルターには2つの基本的な選択肢があります。パケットをサイレントに破棄するか、送信者にエラーを通知するかです。 ICMPv6メッセージを通じてエラーを通知すると、送信者はSYNが目的の宛先に到達しなかったことを検出できます。一方、パケットを破棄すると、アプリケーションで同時オープンをより確実に実行できます。この問題の詳細な説明は[RFC5382]にありますが、その基本的な結果は、同時オープンが損なわれないまでフィルターがシグナリングエラーを待機する必要があるということです。
REC-34: By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) to any unsolicited inbound SYN packet after waiting at least 6 seconds without first forwarding the associated outbound SYN or SYN/ACK from the interior peer.
REC-34：デフォルトでは、ゲートウェイはICMPv6 "Destination Unreachable"エラーコード1（宛先が管理上禁止されている通信）で、関連付けられた送信SYNまたはSYN /内部ピアからのACK。
A TCP filter maintains state associated with in-progress connections and established flows. Because of this, a filter is susceptible to a resource-exhaustion attack whereby an attacker (or virus) on the interior attempts to cause the filter to exhaust its capacity for creating state records. To defend against such attacks, a filter needs to abandon unused state records after a sufficiently long period of idleness.
TCPフィルターは、進行中の接続と確立されたフローに関連する状態を維持します。このため、フィルターはリソース枯渇攻撃の影響を受けやすく、内部の攻撃者（またはウイルス）がフィルターに状態レコードを作成する能力を使い果たしようと試みます。このような攻撃を防ぐために、十分に長いアイドル期間の後、フィルターは未使用の状態レコードを破棄する必要があります。
A common method used for TCP filters in IPv4/NAT gateways is to abandon preferentially flow state records for crashed endpoints, followed by closed flows and partially open flows. A gateway can check if an endpoint for a session has crashed by sending a TCP keep-alive packet on behalf of the other endpoint and receiving a TCP RST packet in response. If the gateway cannot determine whether the endpoint is active, then the associated state record needs to be retained until the TCP flow has been idle for some time.
IPv4 / NATゲートウェイのTCPフィルターに使用される一般的な方法は、クラッシュしたエンドポイントの状態レコードを優先的に放棄し、その後に閉じたフローと部分的に開いたフローを放棄することです。ゲートウェイは、他のエンドポイントに代わってTCPキープアライブパケットを送信し、応答としてTCP RSTパケットを受信することにより、セッションのエンドポイントがクラッシュしたかどうかを確認できます。ゲートウェイがエンドポイントがアクティブであるかどうかを判別できない場合は、TCPフローがしばらくアイドルになるまで、関連付けられた状態レコードを保持する必要があります。
Note: An established TCP flow can stay idle (but live) indefinitely; hence, there is no fixed value for an idle-timeout that accommodates all applications. However, a large idle-timeout motivated by recommendations in [RFC1122] and [RFC4294] can reduce the chances of abandoning a live flow.
注：確立されたTCPフローは、無期限にアイドル（ただし、ライブ）を維持できます。したがって、すべてのアプリケーションに対応するアイドルタイムアウトの固定値はありません。ただし、[RFC1122]および[RFC4294]の推奨事項が動機となっている大きなアイドルタイムアウトは、ライブフローを放棄する可能性を減らすことができます。
TCP flows can stay in the established phase indefinitely without exchanging packets. Some end-hosts can be configured to send keep-alive packets on such idle flows; by default, such packets are sent every two hours, if enabled [RFC1122]. Consequently, a filter that waits for slightly over two hours can detect idle flows with keep-alive packets being sent at the default rate. TCP flows in the partially open or closing phases, on the other hand, can stay idle for at most four minutes while waiting for in-flight packets to be delivered [RFC1122].
TCPフローは、パケットを交換することなく、無期限に確立されたフェーズにとどまることができます。一部のエンドホストは、このようなアイドルフローでキープアライブパケットを送信するように設定できます。デフォルトでは、このようなパケットは有効になっている場合、2時間ごとに送信されます[RFC1122]。その結果、2時間を少し超える時間待機するフィルターは、キープアライブパケットがデフォルトのレートで送信されているアイドルフローを検出できます。一方、部分的に開いたり閉じたりするフェーズのTCPフローは、処理中のパケットが配信されるのを待つ間、最大4分間アイドル状態を維持できます[RFC1122]。
The "established flow idle-timeout" for a stateful packet filter is defined as the minimum time a TCP flow in the established phase must remain idle before the filter considers the associated state record a candidate for collection. The "transitory flow idle-timeout" for a filter is defined as the minimum time a TCP flow in the partially open or closing phases must remain idle before the filter considers the associated state record a candidate for collection. TCP flows in the TIME-WAIT state are not affected by the "transitory flow idle-timeout" parameter.
ステートフルパケットフィルターの「確立されたフローのアイドルタイムアウト」は、フィルターが関連する状態レコードを収集の候補と見なす前に、確立されたフェーズのTCPフローがアイドル状態を維持する必要がある最小時間として定義されます。フィルターの「一時的なフローのアイドルタイムアウト」は、フィルターが関連付けられた状態レコードを収集の候補と見なす前に、部分的に開いたり閉じたりするフェーズのTCPフローがアイドル状態を維持する必要がある最小時間として定義されます。 TIME-WAIT状態のTCPフローは、「一時的なフローのアイドルタイムアウト」パラメータの影響を受けません。
REC-35: If a gateway cannot determine whether the endpoints of a TCP flow are active, then it MAY abandon the state record if it has been idle for some time. In such cases, the value of the "established flow idle-timeout" MUST NOT be less than two hours four minutes, as discussed in [RFC5382]. The value of the "transitory flow idle-timeout" MUST NOT be less than four minutes. The value of the idle-timeouts MAY be configurable by the network administrator.
REC-35：TCPフローのエンドポイントがアクティブであるかどうかをゲートウェイが判別できない場合、それがしばらくアイドル状態であった場合、ゲートウェイは状態レコードを放棄してもよい（MAY）。そのような場合、[RFC5382]で説明されているように、「確立されたフローのアイドルタイムアウト」の値は2時間4分未満であってはなりません。 「一時的なフローのアイドルタイムアウト」の値は、4分未満であってはなりません。アイドルタイムアウトの値は、ネットワーク管理者が設定できる場合があります。
Behavior for handling RST packets or TCP flows in the TIME-WAIT state is left unspecified. A gateway MAY hold state for a flow in the TIME-WAIT state to accommodate retransmissions of the last ACK. However, since the TIME-WAIT state is commonly encountered by interior endpoints properly closing the TCP flow, holding state for a closed flow can limit the throughput of flows through a gateway with limited resources. [RFC1337] discusses hazards associated with TIME-WAIT assassination.
TIME-WAIT状態のRSTパケットまたはTCPフローを処理する動作は、未指定のままになります。ゲートウェイは、最後のACKの再送信に対応するために、TIME-WAIT状態のフローの状態を保持してもよい（MAY）。ただし、TIME-WAIT状態は通常、TCPフローを適切に閉じる内部エンドポイントで発生するため、閉じたフローの保持状態は、リソースが限られたゲートウェイを通過するフローのスループットを制限する可能性があります。 [RFC1337]は、時間待ち暗殺に関連する危険について説明しています。
The handling of non-SYN packets for which there is no active state record is left unspecified. Such packets can be received if the gateway abandons a live flow, or abandons a flow in the TIME-WAIT state before the four-minute TIME-WAIT period expires. The decision either to discard or to respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) is left up to the implementation.
アクティブな状態レコードがないSYN以外のパケットの処理は、未指定のままになります。このようなパケットは、ゲートウェイがライブフローを放棄した場合、または4分のTIME-WAIT期間が終了する前にTIME-WAIT状態のフローを放棄した場合に受信される可能性があります。破棄するか、またはICMPv6 "Destination Unreachable"エラーコード1（管理上禁止された宛先との通信）で応答するかは、実装に任されています。
Behavior for notifying endpoints when abandoning live flows is left unspecified. When a gateway abandons a live flow, for example due to a timeout expiring, the filter MAY send a TCP RST packet to each endpoint on behalf of the other. Sending a RST notification allows endpoint applications to recover more quickly; however, notifying endpoints might not always be possible if, for example, state records are lost due to power interruption.
ライブフローを放棄するときにエンドポイントに通知する動作は、未指定のままになります。たとえばタイムアウトの期限切れが原因で、ゲートウェイがライブフローを放棄する場合、フィルターはTCP RSTパケットを他のエンドポイントに代わって各エンドポイントに送信してもよい（MAY）。 RST通知を送信すると、エンドポイントアプリケーションはより迅速に回復できます。ただし、たとえば、電源の中断により状態レコードが失われた場合、エンドポイントに通知することが常に可能であるとは限りません。
Several TCP mechanisms depend on the reception of ICMPv6 error messages triggered by the transmission of TCP segments. One such mechanism is path MTU discovery, which is required for correct operation of TCP.
いくつかのTCPメカニズムは、TCPセグメントの送信によってトリガーされるICMPv6エラーメッセージの受信に依存しています。そのようなメカニズムの1つは、パスMTU検出です。これは、TCPが正しく動作するために必要です。
REC-36: If a gateway forwards a TCP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing TCP headers that match the flow state record.
REC-36：ゲートウェイがTCPフローを転送する場合、ゲートウェイは、フロー状態レコードと一致するTCPヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージも転送する必要があります。
REC-37: Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a TCP flow.
REC-37：あらゆる種類のICMPv6メッセージの受信は、TCPフローの状態レコードを終了してはならない（MUST NOT）。
Because Stream Control Transmission Protocol (SCTP) [RFC4960] flows can be terminated at multiple network addresses, IPv6 simple security functions cannot achieve full transparency for SCTP applications. In multipath traversal scenarios, full transparency requires coordination between all the packet filter processes in the various paths between the endpoint network addresses. Such coordination is not "simple", and it is, therefore, beyond the scope of this recommendation.
ストリーム制御伝送プロトコル（SCTP）[RFC4960]フローは複数のネットワークアドレスで終了できるため、IPv6の単純なセキュリティ機能ではSCTPアプリケーションの完全な透過性を実現できません。マルチパストラバーサルシナリオでは、完全な透過性のために、エンドポイントネットワークアドレス間のさまざまなパスにあるすべてのパケットフィルタープロセス間の調整が必要です。このような調整は「単純」ではないため、この推奨の範囲を超えています。
However, some SCTP applications are capable of tolerating the inherent unipath restriction of IPv6 simple security, even in multipath traversal scenarios. They expect connection-oriented filtering behaviors similar to those for TCP, but at the level of SCTP associations, not stream connections. This section describes specific recommendations for SCTP filtering for such traversal scenarios.
ただし、一部のSCTPアプリケーションは、マルチパストラバーサルシナリオでも、IPv6シンプルセキュリティの固有のユニパス制限を許容できます。彼らは、TCPと同様の接続指向のフィルタリング動作を期待しますが、SCTPアソシエーションのレベルでは、ストリーム接続ではありません。このセクションでは、このようなトラバーサルシナリオに対するSCTPフィルタリングの具体的な推奨事項について説明します。
An interior endpoint initiates SCTP associations through a stateful packet filter by sending a packet comprising a single INIT chunk. The filter allocates (or reuses) a filter state record for the association. The state record defines the interior and exterior IP addresses and the observed verification tag used for forwarding packets in that association.
内部エンドポイントは、単一のINITチャンクで構成されるパケットを送信することにより、ステートフルパケットフィルターを通じてSCTPアソシエーションを開始します。フィルターは、関連付けにフィルター状態レコードを割り当てます（または再利用します）。状態レコードは、内部および外部IPアドレスと、その関連付けでパケットを転送するために使用される監視された検証タグを定義します。
Some peer-to-peer SCTP applications use an alternate method of association initiation, termed "simultaneous-open", to traverse stateful filters. In the simultaneous-open mode of operation, both peers send INIT chunks at the same time to establish an association. Upon receiving the other end's INIT chunk, each end responds with an INIT-ACK packet, which is expected to traverse the same path in reverse. Because only one SCTP association may exist between any two network addresses, one of the peers in the simultaneous-open mode of operation will send an ERROR or ABORT chunk along with the INIT-ACK chunk. The association is established at each endpoint once an INIT-ACK chunk without an ERROR or ABORT chunk is received at one end.
一部のピアツーピアSCTPアプリケーションは、「同時オープン」と呼ばれるアソシエーション開始の代替方法を使用して、ステートフルフィルターを通過します。同時オープン操作モードでは、両方のピアがINITチャンクを同時に送信して、関連付けを確立します。もう一方の端のINITチャンクを受信すると、各端はINIT-ACKパケットで応答します。これは、同じパスを逆方向に通過することが期待されています。 2つのネットワークアドレス間に存在できるSCTPアソシエーションは1つだけなので、同時オープンモードのピアの1つは、INIT-ACKチャンクとともにERRORまたはABORTチャンクを送信します。アソシエーションは、ERRORまたはABORTチャンクのないINIT-ACKチャンクが一端で受信されると、各エンドポイントで確立されます。
To provide stateful packet filtering service for SCTP, it is necessary for a filter to receive, process, and forward all packets for an association that conform to valid transitions of the SCTP state machine ([RFC4960], Figure 3).
SCTPにステートフルパケットフィルタリングサービスを提供するには、フィルターがSCTPステートマシンの有効な遷移に準拠するアソシエーションのすべてのパケットを受信、処理、および転送する必要があります（[RFC4960]、図3）。
REC-38: All valid sequences of SCTP packets (defined in [RFC4960]) MUST be forwarded for outbound associations and explicitly permitted inbound associations. In particular, both the normal SCTP association establishment and the simultaneous-open mode of operation MUST be supported.
REC-38：SCTPパケットのすべての有効なシーケンス（[RFC4960]で定義）は、発信アソシエーションおよび明示的に許可された着信アソシエーションに対して転送される必要があります。特に、通常のSCTPアソシエーションの確立と同時オープン動作モードの両方をサポートする必要があります。
If an inbound INIT packet is filtered, either because a corresponding state record does not exist or because of the filter's normal behavior, a filter has two basic choices: to discard the packet silently, or to signal an error to the sender. Signaling an error through ICMPv6 messages allows the sender to detect that the INIT packet did not reach the intended destination. Discarding the packet, on the other hand, allows applications to perform simultaneous-open more reliably. Delays in signaling errors can prevent the impairment of the simultaneous-open mode of operation.
対応する状態レコードが存在しないか、フィルターの通常の動作が原因で、受信INITパケットがフィルター処理された場合、フィルターには2つの基本的な選択肢があります。 ICMPv6メッセージを通じてエラーを通知すると、送信者はINITパケットが目的の宛先に到達しなかったことを検出できます。一方、パケットを破棄すると、アプリケーションで同時オープンをより確実に実行できます。シグナリングエラーの遅延により、同時オープン動作モードの障害を防ぐことができます。
REC-39: By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited), to any unsolicited inbound INIT packet after waiting at least 6 seconds without first forwarding the associated outbound INIT from the interior peer.
REC-39：デフォルトでは、ゲートウェイは、ICMPv6「宛先到達不能」エラーコード1（宛先との通信は管理上禁止されています）で応答しなければなりません。インテリアピア。
An SCTP filter maintains state associated with in-progress and established associations. Because of this, a filter is susceptible to a resource-exhaustion attack whereby an attacker (or virus) on the interior attempts to cause the filter to exhaust its capacity for creating state records. To defend against such attacks, a filter needs to abandon unused state records after a sufficiently long period of idleness.
SCTPフィルターは、進行中の確立された関連付けに関連付けられた状態を維持します。このため、フィルターはリソース枯渇攻撃の影響を受けやすく、内部の攻撃者（またはウイルス）がフィルターに状態レコードを作成する能力を使い果たしようと試みます。このような攻撃を防ぐために、十分に長いアイドル期間の後、フィルターは未使用の状態レコードを破棄する必要があります。
A common method used for TCP filters in IPv4/NAT gateways is to abandon preferentially sessions for crashed endpoints, followed by closed associations and partially opened associations. A similar method is an option for SCTP filters in IPv6 gateways. A gateway can check if an endpoint for an association has crashed by sending HEARTBEAT chunks and looking for the HEARTBEAT ACK response. If the gateway cannot determine whether the endpoint is active, then the associated state record needs to be retained until the SCTP association has been idle for some time.
IPv4 / NATゲートウェイのTCPフィルターに使用される一般的な方法は、クラッシュしたエンドポイントのセッションを優先的に破棄し、その後、関連付けを閉じ、関連付けを部分的に開くことです。同様の方法は、IPv6ゲートウェイのSCTPフィルターのオプションです。ゲートウェイは、HEARTBEATチャンクを送信し、HEARTBEAT ACK応答を探すことで、関連付けのエンドポイントがクラッシュしたかどうかを確認できます。ゲートウェイがエンドポイントがアクティブかどうかを判断できない場合、SCTPアソシエーションがしばらくアイドル状態になるまで、関連付けられた状態レコードを保持する必要があります。
Note: An established SCTP association can stay idle (but live) indefinitely; hence, there is no fixed value of an idle-timeout that accommodates all applications. However, a large idle-timeout motivated by recommendations in [RFC4294] can reduce the chances of abandoning a live association.
注：確立されたSCTPアソシエーションは、無期限にアイドル（ただし、ライブ）を維持できます。したがって、すべてのアプリケーションに対応するアイドルタイムアウトの固定値はありません。ただし、[RFC4294]の推奨事項が動機となっている大きなアイドルタイムアウトは、ライブアソシエーションを放棄する可能性を減らすことができます。
SCTP associations can stay in the ESTABLISHED state indefinitely without exchanging packets. Some end-hosts can be configured to send HEARTBEAT chunks on such idle associations, but [RFC4960] does not specify (or even suggest) a default time interval. A filter that waits for slightly over two hours can detect idle associations with HEARTBEAT packets being sent at the same rate as most hosts use for TCP keep-alive, which is a reasonably similar system for this purpose. SCTP associations in the partially open or closing states, on the other hand, can stay idle for at most four minutes while waiting for in-flight packets to be delivered (assuming the suggested SCTP protocol parameter values in Section 15 of [RFC4960]).
SCTPアソシエーションは、パケットを交換せずに無期限にESTABLISHED状態を維持できます。一部のエンドホストは、このようなアイドルアソシエーションでHEARTBEATチャンクを送信するように構成できますが、[RFC4960]はデフォルトの時間間隔を指定（または提案）していません。 2時間弱待機するフィルターは、ほとんどのホストがTCPキープアライブに使用するのと同じレートで送信されるHEARTBEATパケットとのアイドルアソシエーションを検出できます。これは、この目的のためのかなり類似したシステムです。一方、部分的に開いた状態または閉じた状態のSCTPアソシエーションは、処理中のパケットが配信されるのを待つ間、最大4分間アイドル状態を維持できます（[RFC4960]のセクション15で推奨されているSCTPプロトコルパラメータ値を想定）。
The "established association idle-timeout" for a stateful packet filter is defined as the minimum time an SCTP association in the established phase must remain idle before the filter considers the corresponding state record a candidate for collection. The "transitory association idle-timeout" for a filter is defined as the minimum time an SCTP association in the partially open or closing phases must remain idle before the filter considers the corresponding state record a candidate for collection.
ステートフルパケットフィルターの「確立されたアソシエーションアイドルタイムアウト」は、フィルターが対応する状態レコードを収集の候補と見なす前に、確立されたフェーズのSCTPアソシエーションがアイドル状態を維持する必要がある最小時間として定義されます。フィルターの「一時的なアソシエーションのアイドルタイムアウト」は、フィルターが対応する状態レコードを収集の候補と見なす前に、部分的に開いたり閉じたりするフェーズのSCTPアソシエーションがアイドル状態を維持する必要がある最小時間として定義されます。
REC-40: If a gateway cannot determine whether the endpoints of an SCTP association are active, then it MAY abandon the state record if it has been idle for some time. In such cases, the value of the "established association idle-timeout" MUST NOT be less than two hours four minutes. The value of the "transitory association idle-timeout" MUST NOT be less than four minutes. The value of the idle-timeouts MAY be configurable by the network administrator.
REC-40：ゲートウェイがSCTPアソシエーションのエンドポイントがアクティブであるかどうかを判断できない場合、それがしばらくアイドル状態だった場合、ゲートウェイは状態レコードを放棄する場合があります。このような場合、「確立された関連付けのアイドルタイムアウト」の値は、2時間4分未満であってはなりません。 「一時的な関連付けのアイドルタイムアウト」の値は4分未満であってはなりません。アイドルタイムアウトの値は、ネットワーク管理者が設定できる場合があります。
Behavior for handling ERROR and ABORT packets is left unspecified. A gateway MAY hold state for an association after its closing phases have completed to accommodate retransmissions of its final SHUTDOWN ACK packets. However, holding state for a closed association can limit the throughput of associations traversing a gateway with limited resources. The discussion in [RFC1337] regarding the hazards of TIME-WAIT assassination is relevant.
ERRORおよびABORTパケットを処理するための動作は未指定のままです。最終的なSHUTDOWN ACKパケットの再送信に対応するために、ゲートウェイの終了フェーズが完了した後、ゲートウェイは関連付けの状態を保持する場合があります。ただし、閉じた関連付けの状態を保持すると、リソースが制限されたゲートウェイを通過する関連付けのスループットが制限される可能性があります。 TIME-WAIT暗殺の危険性に関する[RFC1337]での議論は適合です。
The handling of inbound non-INIT packets for which there is no active state record is left unspecified. Such packets can be received if the gateway abandons a live flow, or abandons an association in the closing states before the transitory association idle-timeout expires. The decision either to discard or to respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) is left to the implementation.
アクティブな状態レコードがない受信非INITパケットの処理は、未指定のままになります。このようなパケットは、ゲートウェイがライブフローを放棄するか、一時的なアソシエーションのアイドルタイムアウトが終了する前にアソシエーションを終了状態で放棄した場合に受信される可能性があります。破棄するか、ICMPv6 "Destination Unreachable"エラーコード1（管理上禁止された宛先との通信）で応答するかは、実装に委ねられます。
Behavior for notifying endpoints when abandoning live associations is left unspecified. When a gateway abandons a live association, for example due to a timeout expiring, the filter MAY send an ABORT packet to each endpoint on behalf of the other. Sending an ABORT notification allows endpoint applications to recover more quickly; however, notifying endpoints might not always be possible if, for example, state records are lost due to power interruption.
ライブアソシエーションを放棄するときにエンドポイントに通知する動作は、未指定のままになります。たとえばタイムアウトの期限切れが原因で、ゲートウェイがライブアソシエーションを放棄する場合、フィルターは他のエンドポイントに代わって各エンドポイントにABORTパケットを送信できます（MAY）。 ABORT通知を送信すると、エンドポイントアプリケーションがより迅速に回復できます。ただし、たとえば、電源の中断により状態レコードが失われた場合、エンドポイントに通知することが常に可能であるとは限りません。
Several SCTP mechanisms depend on the reception of ICMPv6 error messages triggered by the transmission of SCTP packets.
いくつかのSCTPメカニズムは、SCTPパケットの送信によってトリガーされるICMPv6エラーメッセージの受信に依存しています。
REC-41: If a gateway forwards an SCTP association, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing SCTP headers that match the association state record.
REC-41：ゲートウェイがSCTPアソシエーションを転送する場合、ゲートウェイは、アソシエーション状態レコードと一致するSCTPヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージも転送する必要があります。
REC-42: Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for an SCTP association.
REC-42：あらゆる種類のICMPv6メッセージの受信は、SCTPアソシエーションの状態レコードを終了してはなりません（MUST NOT）。
The connection semantics described in the "Datagram Congestion Control Protocol (DCCP)" [RFC4340] are very similar to those of TCP. An interior endpoint initiates a DCCP flow through a stateful packet filter by sending a DCCP-Request packet. Simultaneous-open is not defined for DCCP.
「Datagram Congestion Control Protocol（DCCP）」[RFC4340]で説明されている接続セマンティクスは、TCPのセマンティクスと非常によく似ています。内部エンドポイントは、DCCP要求パケットを送信することにより、ステートフルパケットフィルターを介してDCCPフローを開始します。同時オープンは、DCCPでは定義されていません。
In order to provide stateful packet filtering service for DCCP, it is necessary for a filter to receive, process, and forward all packets for a flow that conform to valid transitions of the DCCP state machine ([RFC4340], Section 8).
DCCPにステートフルパケットフィルタリングサービスを提供するには、DCCPステートマシンの有効な遷移（[RFC4340]、セクション8）に適合するフローのすべてのパケットをフィルターが受信、処理、および転送する必要があります。
REC-43: All valid sequences of DCCP packets (defined in [RFC4340]) MUST be forwarded for all flows to exterior servers, and for any flows to interior servers that have explicitly permitted service codes.
REC-43：DCCPパケットのすべての有効なシーケンス（[RFC4340]で定義）は、外部サーバーへのすべてのフロー、および明示的に許可されたサービスコードを持つ内部サーバーへのフローに対して転送する必要があります。
It is possible to reconstruct enough of the state of a DCCP flow to allow forwarding between an interior and exterior node, even when the filter starts operating after DCCP enters the OPEN state. Also, a filter can allow an existing state record to be reused by an externally initiated flow if its security policy permits. As with TCP, several different policies are possible, with a good discussion of the issue involved presented in [RFC4787] and extended in [RFC5382].
DCCPがOPEN状態になった後でフィルターが動作を開始した場合でも、DCCPフローの状態を十分に再構築して、内部ノードと外部ノード間の転送を可能にすることができます。また、セキュリティポリシーで許可されている場合、フィルタを使用すると、既存の状態レコードを外部で開始されたフローで再利用できます。 TCPと同様に、[RFC4787]で提示され、[RFC5382]で拡張された、関連する問題の適切な議論により、いくつかの異なるポリシーが可能です。
If an inbound DCCP-Request packet is filtered, either because a corresponding state record does not already exist for it or because of the filter's normal behavior of refusing flows not explicitly permitted, then a filter has two basic choices: to discard the packet silently, or to signal an error to the sender. Signaling an error through ICMPv6 messages allows the sender to detect that the DCCP-Request did not reach the intended destination. Discarding the packet, on the other hand, only delays the failure to connect and provides no measurable security.
対応する状態レコードがまだ存在していないため、またはフローを拒否するフィルターの通常の動作が明示的に許可されていないために、インバウンドDCCP-Requestパケットがフィルター処理される場合、フィルターには2つの基本的な選択肢があります。または、送信者にエラーを通知します。 ICMPv6メッセージを介してエラーを通知すると、送信者はDCCP要求が目的の宛先に到達しなかったことを検出できます。一方、パケットの破棄は、接続の失敗を遅らせるだけで、測定可能なセキュリティは提供しません。
A DCCP filter maintains state associated with in-progress connections and established flows. Because of this, a filter is susceptible to a resource-exhaustion attack whereby an attacker (or virus) on the interior attempts to cause the filter to exhaust its capacity for creating state records. To prevent such an attack, a filter needs to abandon unused state records after a sufficiently long period of idleness.
DCCPフィルターは、進行中の接続と確立されたフローに関連する状態を維持します。このため、フィルターはリソース枯渇攻撃の影響を受けやすく、内部の攻撃者（またはウイルス）がフィルターに状態レコードを作成する能力を使い果たしようと試みます。このような攻撃を防ぐために、十分に長いアイドル期間の後、フィルターは未使用の状態レコードを破棄する必要があります。
A common method used for TCP filters in IPv4/NAT gateways is to abandon preferentially sessions for crashed endpoints, followed by closed TCP flows and partially open flows. No such method exists for DCCP, and flows can stay in the OPEN phase indefinitely without exchanging packets. Hence, there is no fixed value for an idle-timeout that accommodates all applications. However, a large idle-timeout motivated by recommendations in [RFC4294] can reduce the chances of abandoning a live flow.
IPv4 / NATゲートウェイでTCPフィルターに使用される一般的な方法は、クラッシュしたエンドポイントのセッションを優先的に破棄し、その後に閉じたTCPフローと部分的に開いたフローを破棄することです。 DCCPにはそのような方法はなく、フローはパケットを交換せずに無期限にOPENフェーズにとどまることができます。したがって、すべてのアプリケーションに対応するアイドルタイムアウトの固定値はありません。ただし、[RFC4294]の推奨事項が動機となっている大きなアイドルタイムアウトは、ライブフローを放棄する可能性を減らすことができます。
DCCP flows in the partially open or closing phases can stay idle for at most eight minutes while waiting for in-flight packets to be delivered.
部分的に開いたり閉じたりするフェーズのDCCPフローは、処理中のパケットが配信されるのを待つ間、最大8分間アイドル状態を維持できます。
The "open flow idle-timeout" for a stateful packet filter is defined as the minimum time a DCCP flow in the open state must remain idle before the filter considers the associated state record a candidate for collection. The "transitory flow idle-timeout" for a filter is defined as the minimum time a DCCP flow in the partially open or closing phases must remain idle before the filter considers the associated state record a candidate for collection. DCCP flows in the TIMEWAIT state are not affected by the "transitory flow idle-timeout" parameter.
ステートフルパケットフィルターの「オープンフローアイドルタイムアウト」は、フィルターが関連する状態レコードを収集の候補と見なす前に、オープンステートのDCCPフローがアイドル状態を維持する必要がある最小時間として定義されます。フィルターの「一時的なフローのアイドルタイムアウト」は、フィルターが関連する状態レコードを収集の候補と見なす前に、部分的に開いているフェーズまたは閉じるフェーズのDCCPフローがアイドル状態を維持する必要がある最小時間として定義されます。 TIMEWAIT状態のDCCPフローは、「一時的なフローのアイドルタイムアウト」パラメータの影響を受けません。
REC-44: A gateway MAY abandon a DCCP state record if it has been idle for some time. In such cases, the value of the "open flow idle-timeout" MUST NOT be less than two hours four minutes. The value of the "transitory flow idle-timeout" MUST NOT be less than eight minutes. The value of the idle-timeouts MAY be configurable by the network administrator.
REC-44：ゲートウェイがしばらくアイドル状態だった場合、DCCP状態レコードを放棄してもよい（MAY）。そのような場合、「オープンフローアイドルタイムアウト」の値は2時間4分未満であってはなりません。 「一時的なフローのアイドルタイムアウト」の値は、8分未満であってはなりません。アイドルタイムアウトの値は、ネットワーク管理者が設定できる場合があります。
Behavior for handling DCCP-Reset packets or flows in the TIMEWAIT state is left unspecified. A gateway MAY hold state for a flow in the TIMEWAIT state to accommodate retransmissions of the last DCCP-Reset. However, since the TIMEWAIT state is commonly encountered by interior endpoints properly closing the DCCP flow, holding state for a closed flow can limit the throughput of flows through a gateway with limited resources. [RFC1337] discusses hazards associated with TIME-WAIT assassination in TCP, and similar hazards exist for DCCP.
TIMEWAIT状態のDCCPリセットパケットまたはフローを処理するための動作は、指定されていません。ゲートウェイは、最後のDCCP-Resetの再送信に対応するために、TIMEWAIT状態のフローの状態を保持してもよい（MAY）。ただし、TIMEWAIT状態は通常、DCCPフローを適切に閉じる内部エンドポイントで発生するため、閉じたフローの保持状態は、リソースが限られたゲートウェイを通過するフローのスループットを制限する可能性があります。 [RFC1337]は、TCPでのTIME-WAIT暗殺に関連する危険について説明しており、DCCPにも同様の危険が存在します。
The handling of non-SYN packets for which there is no active state record is left unspecified. Such packets can be received if the gateway abandons a live flow, or abandons a flow in the TIMEWAIT state before the four-minute 2MSL period (two times the maximum segment lifetime [RFC4340]) expires. The decision either to discard or to respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) is left up to the implementation.
アクティブな状態レコードがないSYN以外のパケットの処理は、未指定のままになります。このようなパケットは、ゲートウェイがライブフローを放棄した場合、または4分の2MSL期間（最大セグメントライフタイム[RFC4340]の2倍）が経過する前にTIMEWAIT状態のフローを放棄した場合に受信されます。破棄するか、またはICMPv6 "Destination Unreachable"エラーコード1（管理上禁止された宛先との通信）で応答するかは、実装に任されています。
Behavior for notifying endpoints when abandoning live flows is left unspecified. When a gateway abandons a live flow, for example due to a timeout expiring, the filter MAY send a DCCP-Reset packet to each endpoint on behalf of the other. Sending a DCCP-Reset notification allows endpoint applications to recover more quickly; however, notifying endpoints might not always be possible if, for example, state records are lost due to power interruption.
ライブフローを放棄するときにエンドポイントに通知する動作は、未指定のままになります。たとえばタイムアウトの期限切れが原因で、ゲートウェイがライブフローを放棄する場合、フィルターは他のエンドポイントに代わって各エンドポイントにDCCPリセットパケットを送信する場合があります。 DCCPリセット通知を送信すると、エンドポイントアプリケーションがより迅速に回復できます。ただし、たとえば、電源の中断により状態レコードが失われた場合、エンドポイントに通知することが常に可能であるとは限りません。
Several DCCP mechanisms depend on the reception of ICMPv6 error messages triggered by the transmission of DCCP packets. One such mechanism is path MTU discovery, which is required for correct operation.
いくつかのDCCPメカニズムは、DCCPパケットの送信によってトリガーされるICMPv6エラーメッセージの受信に依存しています。そのようなメカニズムの1つは、パスMTUディスカバリーです。これは、正しい操作に必要です。
REC-45: If an Internet gateway forwards a DCCP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing DCCP headers that match the flow state record.
REC-45：インターネットゲートウェイがDCCPフローを転送する場合、フローステートレコードと一致するDCCPヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージも転送する必要があります。
REC-46: Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a DCCP flow.
REC-46：あらゆる種類のICMPv6メッセージの受信は、DCCPフローの状態レコードを終了してはなりません（MUST NOT）。
While IPv6 simple security is applicable to residential networks with only one Internet service provider at a time, the use of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] is necessary for communications with some multihomed exterior destinations. No special recommendations are made in this document for processing the Shim6 message format (protocol 140) beyond the recommendations in Section 3.2.2. The content of the Shim6 payload extension header may be ignored.
IPv6シンプルセキュリティは、インターネットサービスプロバイダーが一度に1つしかない住宅用ネットワークに適用できますが、一部のマルチホーム外部宛先との通信には、IPv6のレベル3マルチホーミングShimプロトコル（Shim6）[RFC5533]の使用が必要です。このドキュメントでは、セクション3.2.2の推奨事項を超えてShim6メッセージ形式（プロトコル140）を処理するための特別な推奨事項はありません。 Shim6ペイロード拡張ヘッダーの内容は無視されます。
REC-47: Valid sequences of packets bearing Shim6 payload extension headers in their outer IP extension header chains MUST be forwarded for all outbound and explicitly permitted flows. The content of the Shim6 payload extension header MAY be ignored for the purpose of state tracking.
REC-47：外部IP拡張ヘッダーチェーンにShim6ペイロード拡張ヘッダーを含むパケットの有効なシーケンスは、すべてのアウトバウンドフローおよび明示的に許可されたフローに転送する必要があります。 Shim6ペイロード拡張ヘッダーの内容は、状態追跡の目的で無視される場合があります。
Some applications expect to solicit traffic from exterior nodes without advance knowledge of the exterior addresses of their peers. This requirement is met by IPv4/NAT gateways, typically by the use of either the NAT Port Mapping Protocol [NAT-PMP] or the Universal Plug and Play Internet Gateway Device [UPnP-IGD] standardized device control protocol. On IPv4/NAT networks connected by gateways without such services, applications must use techniques like Session Traversal Utilities for NAT (STUN) [RFC5389] to obtain and maintain connectivity, despite the translation and filtering effects of NAT.
一部のアプリケーションは、ピアの外部アドレスを事前に知らなくても、外部ノードからのトラフィックを要求することを期待しています。この要件は、通常はNATポートマッピングプロトコル[NAT-PMP]またはユニバーサルプラグアンドプレイインターネットゲートウェイデバイス[UPnP-IGD]の標準化されたデバイス制御プロトコルを使用することにより、IPv4 / NATゲートウェイによって満たされます。そのようなサービスのないゲートウェイによって接続されたIPv4 / NATネットワークでは、アプリケーションはNATの変換およびフィルタリング効果にもかかわらず、接続を取得して維持するために、NAT用セッショントラバーサルユーティリティ（STUN）[RFC5389]などの手法を使用する必要があります。
While NAT for IPv6 is unlikely to be used in most residential gateways, the simple security functions recommended by this document, and their filtering effects, are derived from comparable functions already in widespread use on the IPv4 Internet. A similar barrier to communication at passive listeners is a natural outcome of the deployment of NAT for IPv6. To avoid the need for IPv6 applications to use techniques like STUN for opening and maintaining dynamic filter state, something similar to NAT-PMP and UPnP-IGD, but without actually supporting NAT, could be deployed. Alas, no consensus has yet emerged in the Internet engineering community as to what is most appropriate for residential IPv6 usage scenarios.
IPv6のNATはほとんどのレジデンシャルゲートウェイで使用される可能性は低いですが、このドキュメントで推奨されている単純なセキュリティ機能とそのフィルタリング効果は、IPv4インターネットですでに広く使用されている同等の機能から派生しています。パッシブリスナーでの通信に対する同様の障壁は、IPv6用のNATの展開の自然な結果です。 IPv6アプリケーションが動的フィルター状態を開いて維持するためにSTUNのような手法を使用する必要性を回避するために、NAT-PMPおよびUPnP-IGDに似ていますが、実際にはNATをサポートせずに、展開できます。残念ながら、インターネットエンジニアリングコミュニティでは、住宅IPv6の使用シナリオに最も適切なものについて、まだコンセンサスが得られていません。
One proposal that has been offered is the Application Listener Discovery Protocol [WOODYATT-ALD] document. It remains to be seen whether the Internet Gateway Device profile of the Universal Plug and Play protocol will be extended for IPv6. Other proposals of note include the Middlebox Communication Protocol [RFC5189] and the Next Steps in Signaling framework [RFC4080]. Until a consensus emerges around a specific method, the following recommendations are the best guidance available.
提案されている提案の1つは、Application Listener Discovery Protocol [WOODYATT-ALD]ドキュメントです。ユニバーサルプラグアンドプレイプロトコルのインターネットゲートウェイデバイスプロファイルがIPv6向けに拡張されるかどうかはまだ不明です。その他の注目すべき提案には、ミドルボックス通信プロトコル[RFC5189]とシグナリングフレームワークの次のステップ[RFC4080]があります。特定の方法について合意が得られるまで、次の推奨事項が利用可能な最良のガイダンスです。
REC-48: Internet gateways with IPv6 simple security capabilities SHOULD implement a protocol to permit applications to solicit inbound traffic without advance knowledge of the addresses of exterior nodes with which they expect to communicate.
REC-48：IPv6シンプルセキュリティ機能を備えたインターネットゲートウェイは、アプリケーションが通信する外部ノードのアドレスを事前に知らなくても、アプリケーションがインバウンドトラフィックを要求できるようにするプロトコルを実装する必要があります（SHOULD）。
REC-49: Internet gateways with IPv6 simple security capabilities MUST provide an easily selected configuration option that permits a "transparent mode" of operation that forwards all unsolicited flows regardless of forwarding direction, i.e., not to use the IPv6 simple security capabilities of the gateway. The transparent mode of operation MAY be the default configuration.
REC-49：IPv6シンプルセキュリティ機能を備えたインターネットゲートウェイは、転送方向に関係なくすべての非送信請求フローを転送する「透過モード」の操作を許可する、つまりゲートウェイのIPv6シンプルセキュリティ機能を使用しない、簡単に選択できる構成オプションを提供する必要があります。操作の透過モードがデフォルトの構成である場合があります。
In general, "transparent mode" will enable more flexibility and reliability for applications that require devices to be contacted inside the home directly, particularly in the absence of a protocol as described in REC-48. Operating in transparent mode may come at the expense of security if there are IPv6 nodes in the home that do not have their own host-based firewall capability and require a firewall in the gateway in order not to be compromised.
一般に、「透過モード」は、特にREC-48で説明されているプロトコルがない場合に、デバイスを家の中で直接接続する必要があるアプリケーションの柔軟性と信頼性を向上させます。独自のホストベースのファイアウォール機能を持たず、侵害されないようにゲートウェイにファイアウォールを必要とするIPv6ノードが家にある場合、透過モードでの動作はセキュリティを犠牲にする可能性があります。
Subscriber-managed residential gateways are unlikely ever to be completely zero-configuration, but their administrators will very often possess no particular expertise in Internet engineering. In general, the specification of management interfaces for residential gateways is out of scope for this document, but the security of subscriber-managed gateways merits special attention here.
加入者管理の住宅用ゲートウェイが完全にゼロ構成になることはほとんどありませんが、その管理者は、インターネットエンジニアリングに関する特定の専門知識を持たないことがよくあります。一般に、レジデンシャルゲートウェイの管理インターフェイスの仕様はこのドキュメントの範囲外ですが、サブスクライバー管理ゲートウェイのセキュリティは、ここで特に注意を払う必要があります。
REC-50: By DEFAULT, subscriber-managed residential gateways MUST NOT offer management application services to the exterior network.
REC-50：デフォルトでは、加入者管理の住宅用ゲートウェイは外部ネットワークに管理アプリケーションサービスを提供してはなりません。
This section collects all of the recommendations made in this document into a convenient list.
このセクションでは、このドキュメントで行ったすべての推奨事項を便利なリストにまとめています。
REC-1 Packets bearing multicast source addresses in their outer IPv6 headers MUST NOT be forwarded or transmitted on any interface.
マルチキャストソースアドレスが外部IPv6ヘッダーに含まれているREC-1パケットは、どのインターフェイスでも転送または送信してはなりません。
REC-2 Packets bearing multicast destination addresses in their outer IPv6 headers of equal or narrower scope (see "IPv6 Scoped Address Architecture" [RFC4007]) than the configured scope boundary level of the gateway MUST NOT be forwarded in any direction. The DEFAULT scope boundary level SHOULD be organization-local scope, and it SHOULD be configurable by the network administrator.
ゲートウェイの構成されたスコープ境界レベルよりも等しいか、または狭いスコープ（「IPv6スコープアドレスアーキテクチャ」[RFC4007]を参照）の外部IPv6ヘッダーにマルチキャスト宛先アドレスを含むREC-2パケットは、どの方向にも転送してはなりません（MUST NOT）。 DEFAULTスコープの境界レベルは、組織ローカルスコープである必要があり（SHOULD）、ネットワーク管理者が構成可能である必要があります（SHOULD）。
REC-3 Packets bearing source and/or destination addresses forbidden to appear in the outer headers of packets transmitted over the public Internet MUST NOT be forwarded. In particular, site-local addresses are deprecated by [RFC3879], and [RFC5156] explicitly forbids the use of address blocks of types IPv4-Mapped Addresses, IPv4-Compatible Addresses, Documentation Prefix, and Overlay Routable Cryptographic Hash IDentifiers (ORCHID).
公衆インターネットを介して送信されるパケットの外部ヘッダーに表示することが禁止されている送信元アドレスまたは宛先アドレス、あるいはその両方を含むREC-3パケットは転送してはなりません。特に、サイトローカルアドレスは[RFC3879]で非推奨になり、[RFC5156]は、IPv4マッピングアドレス、IPv4互換アドレス、ドキュメントプレフィックス、およびオーバーレイルーティング可能な暗号化ハッシュID（ORCHID）タイプのアドレスブロックの使用を明示的に禁止しています。
REC-4 Packets bearing deprecated extension headers prior to their first upper-layer-protocol header SHOULD NOT be forwarded or transmitted on any interface. In particular, all packets with routing extension header type 0 [RFC2460] preceding the first upper-layer-protocol header MUST NOT be forwarded. See [RFC5095] for additional background.
最初の上位層プロトコルヘッダーの前に廃止された拡張ヘッダーが付いたREC-4パケットは、どのインターフェースでも転送または送信してはなりません（SHOULD NOT）。特に、最初の上位層プロトコルヘッダーに先行するルーティング拡張ヘッダータイプ0 [RFC2460]のすべてのパケットは転送してはなりません（MUST NOT）。追加の背景については、[RFC5095]を参照してください。
REC-5 Outbound packets MUST NOT be forwarded if the source address in their outer IPv6 header does not have a unicast prefix configured for use by globally reachable nodes on the interior network.
外部IPv6ヘッダーの送信元アドレスに、内部ネットワーク上のグローバルに到達可能なノードで使用するように構成されたユニキャストプレフィックスがない場合、REC-5送信パケットを転送してはなりません（MUST NOT）。
REC-6 Inbound packets MUST NOT be forwarded if the source address in their outer IPv6 header has a global unicast prefix assigned for use by globally reachable nodes on the interior network.
内部IPv6ヘッダーの送信元アドレスに、内部ネットワーク上のグローバルに到達可能なノードが使用するために割り当てられたグローバルユニキャストプレフィックスがある場合、REC-6インバウンドパケットを転送してはなりません（MUST NOT）。
REC-7 By DEFAULT, packets with unique local source and/or destination addresses [RFC4193] SHOULD NOT be forwarded to or from the exterior network.
REC-7 DEFAULTにより、一意のローカル送信元アドレスまたは宛先アドレス、あるいはその両方[RFC4193]を持つパケットは、外部ネットワークとの間で転送されるべきではありません（SHOULD NOT）。
REC-8 By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server.
REC-8デフォルトでは、外部インターフェースで受信されたインバウンドDNSクエリは、統合されたDNS解決サーバーによって処理されてはなりません（MUST NOT）。
REC-9 Inbound DHCPv6 discovery packets [RFC3315] received on exterior interfaces MUST NOT be processed by any integrated DHCPv6 server or relay agent.
外部インターフェースで受信されたREC-9インバウンドDHCPv6ディスカバリーパケット[RFC3315]は、統合されたDHCPv6サーバーまたはリレーエージェントによって処理されてはなりません（MUST NOT）。
REC-10 IPv6 gateways SHOULD NOT forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing IP headers that do not match generic upper-layer transport state records.
REC-10 IPv6ゲートウェイは、一般的な上位層のトランスポート状態レコードと一致しないIPヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージを転送してはなりません（SHOULD NOT）。
REC-11 If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for generic upper-layer transport protocols. If a more stringent filtering behavior is most important, then a filter SHOULD have "address-dependent filtering" behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.
REC-11アプリケーションの透過性が最も重要である場合、ステートフルパケットフィルターは、一般的な上位層トランスポートプロトコルに対して「エンドポイントに依存しないフィルタリング」動作を行う必要があります（SHOULD）。より厳格なフィルタリング動作が最も重要な場合、フィルターは「アドレス依存のフィルタリング」動作を持つ必要があります（SHOULD）。フィルタリング動作は、ネットワーク管理者が構成可能なオプションである場合があり、他のプロトコルのフィルタリング動作から独立している場合があります。フィルタリング動作は、サービスプロバイダー管理なしのプロビジョニングを目的としたゲートウェイで、DEFAULTによってエンドポイントに依存しないようにする必要があります。
REC-12 Filter state records for generic upper-layer transport protocols MUST NOT be deleted or recycled until an idle timer not less than two minutes has expired without having forwarded a packet matching the state in some configurable amount of time. By DEFAULT, the idle timer for such state records is five minutes.
一般的な上位層トランスポートプロトコルのREC-12フィルター状態レコードは、構成可能な時間内に状態に一致するパケットを転送せずに2分以上のアイドルタイマーが期限切れになるまで、削除またはリサイクルしてはなりません。デフォルトでは、そのような状態レコードのアイドルタイマーは5分です。
REC-13 Residential IPv6 gateways SHOULD provide a convenient means to update their firmware securely, for the installation of security patches and other manufacturer-recommended changes.
REC-13レジデンシャルIPv6ゲートウェイは、セキュリティパッチのインストールやその他のメーカー推奨の変更のために、ファームウェアを安全に更新するための便利な手段を提供する必要があります（SHOULD）。
REC-14 A state record for a UDP flow where both source and destination ports are outside the well-known port range (ports 0-1023) MUST NOT expire in less than two minutes of idle time. The value of the UDP state record idle timer MAY be configurable. The DEFAULT is five minutes.
REC-14送信元ポートと宛先ポートの両方が既知のポート範囲（ポート0〜1023）の外側にあるUDPフローの状態レコードは、アイドル時間の2分未満で期限切れになってはならない（MUST NOT）。 UDP状態レコードのアイドルタイマーの値は構成可能である場合があります。 DEFAULTは5分です。
REC-15 A state record for a UDP flow where one or both of the source and destination ports are in the well-known port range (ports 0-1023) MAY expire after a period of idle time shorter than two minutes to facilitate the operation of the IANA-registered service assigned to the port in question.
REC-15送信元ポートと宛先ポートの一方または両方が既知のポート範囲（ポート0〜1023）にあるUDPフローの状態レコードは、操作を容易にするために、2分未満のアイドル時間後に期限切れになる場合があります。問題のポートに割り当てられているIANA登録サービスの。
REC-16 A state record for a UDP flow MUST be refreshed when a packet is forwarded from the interior to the exterior, and it MAY be refreshed when a packet is forwarded in the reverse direction.
REC-16 UDPフローの状態レコードは、パケットが内部から外部に転送されるときに更新される必要があり、パケットが逆方向に転送されるときに更新される場合があります。
REC-17 If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for UDP. If a more stringent filtering behavior is most important, then a filter SHOULD have "address-dependent filtering" behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for TCP and other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.
REC-17アプリケーションの透過性が最も重要な場合、ステートフルパケットフィルターは、UDPに対して「エンドポイントに依存しないフィルタリング」動作を持つ必要があります（SHOULD）。より厳格なフィルタリング動作が最も重要な場合、フィルターは「アドレス依存のフィルタリング」動作を持つ必要があります（SHOULD）。フィルタリング動作は、ネットワーク管理者が構成可能なオプションである場合があり、TCPおよびその他のプロトコルのフィルタリング動作から独立している場合があります。フィルタリング動作は、サービスプロバイダー管理なしのプロビジョニングを目的としたゲートウェイで、DEFAULTによってエンドポイントに依存しないようにする必要があります。
REC-18 If a gateway forwards a UDP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing UDP headers that match the flow state record.
REC-18ゲートウェイがUDPフローを転送する場合、ゲートウェイは、フロー状態レコードと一致するUDPヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージも転送する必要があります。
REC-19 Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a UDP flow.
REC-19あらゆる種類のICMPv6メッセージの受信は、UDPフローの状態レコードを終了してはならない（MUST NOT）。
REC-20 UDP-Lite flows [RFC3828] SHOULD be handled in the same way as UDP flows, except that the upper-layer transport protocol identifier for UDP-Lite is not the same as UDP; therefore, UDP packets MUST NOT match UDP-Lite state records, and vice versa.
REC-20 UDP-Liteフロー[RFC3828]は、UDP-Liteの上位層トランスポートプロトコル識別子がUDPと同じではないことを除いて、UDPフローと同じ方法で処理する必要があります（SHOULD）。したがって、UDPパケットはUDP-Lite状態レコードと一致してはならず、その逆も同様です。
REC-21 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with destination extension headers of type "Authentication Header (AH)" [RFC4302] in their outer IP extension header chain.
REC-21デフォルトの動作モードでは、IPv6ゲートウェイは、外部のIP拡張ヘッダーチェーンに「認証ヘッダー（AH）」タイプの宛先拡張ヘッダー[RFC4302]を使用して、正当なノードアドレスとの間のパケットの転送を禁止してはなりません（MUST NOT）。
REC-22 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with an upper-layer protocol of type "Encapsulating Security Payload (ESP)" [RFC4303] in their outer IP extension header chain.
REC-22デフォルトの動作モードでは、IPv6ゲートウェイは、外部IP拡張にタイプ「カプセル化セキュリティペイロード（ESP）」[RFC4303]の上位層プロトコルを使用して、正当なノードアドレスとの間のパケットの転送を禁止してはなりません（MUST NOT）ヘッダーチェーン。
REC-23 If a gateway forwards an ESP flow, it MUST also forward (in the reverse direction) ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing ESP headers that match the flow state record.
REC-23ゲートウェイがESPフローを転送する場合、フロー状態レコードと一致するESPヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージも（逆方向に）転送する必要があります。
REC-24 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of any UDP packets, to and from legitimate node addresses, with a destination port of 500, i.e., the port reserved by IANA for the Internet Key Exchange (IKE) Protocol [RFC5996].
REC-24デフォルトの動作モードでは、IPv6ゲートウェイは、500の宛先ポート、つまりIANAによってインターネットキーエクスチェンジ（IKE）用に予約されたポートを使用して、正当なノードアドレスとの間のUDPパケットの転送を禁止してはなりません（MUST NOT）。プロトコル[RFC5996]。
REC-25 In all operating modes, IPv6 gateways SHOULD use filter state records for Encapsulating Security Payload (ESP) [RFC4303] that are indexable by a 3-tuple comprising the interior node address, the exterior node address, and the ESP protocol identifier. In particular, the IPv4/NAT method of indexing state records also by security parameters index (SPI) SHOULD NOT be used. Likewise, any mechanism that depends on detection of Internet Key Exchange (IKE) [RFC5996] initiations SHOULD NOT be used.
REC-25すべての動作モードで、IPv6ゲートウェイは、内部ノードアドレス、外部ノードアドレス、およびESPプロトコル識別子を含む3タプルによってインデックス付け可能な、カプセル化セキュリティペイロード（ESP）[RFC4303]のフィルター状態レコードを使用する必要があります（SHOULD）。特に、セキュリティパラメータインデックス（SPI）によって状態レコードにインデックスを付けるIPv4 / NATメソッドは使用しないでください。同様に、インターネットキー交換（IKE）[RFC5996]の開始の検出に依存するメカニズムは使用しないでください。
REC-26 In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit the forwarding of packets, to and from legitimate node addresses, with destination extension headers of type "Host Identity Protocol (HIP)" [RFC5201] in their outer IP extension header chain.
REC-26デフォルトの動作モードでは、IPv6ゲートウェイは、外部IP拡張ヘッダーチェーンにタイプ「ホストアイデンティティプロトコル（HIP）」[RFC5201]の宛先拡張ヘッダーを持つ、正規のノードアドレスとの間のパケットの転送を禁止してはなりません（MUST NOT） 。
REC-27 The state records for flows initiated by outbound packets that bear a Home Address destination option [RFC3775] are distinguished by the addition of the home address of the flow as well as the interior care-of address. IPv6 gateways MUST NOT prohibit the forwarding of any inbound packets bearing type 2 routing headers, which otherwise match a flow state record, and where A) the address in the destination field of the IPv6 header matches the interior care-of address of the flow, and B) the Home Address field in the Type 2 Routing Header matches the home address of the flow.
REC-27ホームアドレス宛先オプション[RFC3775]を含むアウトバウンドパケットによって開始されたフローの状態レコードは、フローのホームアドレスと内部気付アドレスの追加によって区別されます。 IPv6ゲートウェイは、タイプ2ルーティングヘッダーを持つ受信パケットの転送を禁止してはなりません。これは、フローステートレコードと一致し、A）IPv6ヘッダーの宛先フィールドのアドレスがフローの内部気付アドレスと一致します。 B）タイプ2ルーティングヘッダーのホームアドレスフィールドがフローのホームアドレスと一致する。
REC-28 Valid sequences of Mobility Header [RFC3775] packets MUST be forwarded for all outbound and explicitly permitted inbound Mobility Header flows.
REC-28モビリティヘッダーの有効なシーケンス[RFC3775]パケットは、すべてのアウトバウンドおよび明示的に許可されたインバウンドのモビリティヘッダーフローで転送される必要があります。
REC-29 If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward, in both directions, the IPv4 and IPv6 packets that are encapsulated in IPv6 associated with the tunnel between the home agent and the correspondent node.
REC-29ゲートウェイがモビリティヘッダー[RFC3775]フローを転送する場合、ホームエージェントとコレスポンデントノード間のトンネルに関連付けられたIPv6にカプセル化されたIPv4パケットとIPv6パケットも両方向に転送する必要があります。
REC-30 If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward (in the reverse direction) ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing any headers that match the associated flow state records.
REC-30ゲートウェイがモビリティヘッダー[RFC3775]フローを転送する場合、関連するフロー状態レコードに一致するヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージも（逆方向に）転送する必要があります。
REC-31 All valid sequences of TCP packets (defined in [RFC0793]) MUST be forwarded for outbound flows and explicitly permitted inbound flows. In particular, both the normal TCP 3-way handshake mode of operation and the simultaneous-open mode of operation MUST be supported.
REC-31 TCPパケットのすべての有効なシーケンス（[RFC0793]で定義）は、アウトバウンドフローおよび明示的に許可されたインバウンドフローに転送する必要があります。特に、通常のTCP 3ウェイハンドシェイク操作モードと同時オープン操作モードの両方がサポートされている必要があります。
REC-32 The TCP window invariant MUST NOT be enforced on flows for which the filter did not detect whether the window-scale option (see [RFC1323]) was sent in the 3-way handshake or simultaneous-open.
REC-32ウィンドウスケールオプション（[RFC1323]を参照）が3ウェイハンドシェイクまたは同時オープンで送信されたかどうかをフィルターが検出しなかったフローでは、TCPウィンドウの不変条件を強制してはなりません（MUST NOT）。
REC-33 If application transparency is most important, then a stateful packet filter SHOULD have "endpoint-independent filtering" behavior for TCP. If a more stringent filtering behavior is most important, then a filter SHOULD have "address-dependent filtering" behavior. The filtering behavior MAY be an option configurable by the network administrator, and it MAY be independent of the filtering behavior for UDP and other protocols. Filtering behavior SHOULD be endpoint independent by DEFAULT in gateways intended for provisioning without service-provider management.
REC-33アプリケーションの透過性が最も重要である場合、ステートフルパケットフィルターは、TCPに対して「エンドポイントに依存しないフィルタリング」動作を持つ必要があります（SHOULD）。より厳格なフィルタリング動作が最も重要な場合、フィルターは「アドレス依存のフィルタリング」動作を持つ必要があります（SHOULD）。フィルタリング動作は、ネットワーク管理者が構成可能なオプションである場合があり、UDPおよびその他のプロトコルのフィルタリング動作から独立している場合があります。フィルタリング動作は、サービスプロバイダー管理なしのプロビジョニングを目的としたゲートウェイで、DEFAULTによってエンドポイントに依存しないようにする必要があります。
REC-34 By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited), to any unsolicited inbound SYN packet after waiting at least 6 seconds without first forwarding the associated outbound SYN or SYN/ACK from the interior peer.
REC-34デフォルトでは、ゲートウェイは、関連付けられたアウトバウンドSYNまたはSYN /を最初に転送せずに少なくとも6秒間待機した後、任意の非送信請求SYNパケットに対して、ICMPv6 "Destination Unreachable"エラーコード1（管理上の宛先との通信）で応答する必要があります。内部ピアからのACK。
REC-35 If a gateway cannot determine whether the endpoints of a TCP flow are active, then it MAY abandon the state record if it has been idle for some time. In such cases, the value of the "established flow idle-timeout" MUST NOT be less than two hours four minutes, as discussed in [RFC5382]. The value of the "transitory flow idle-timeout" MUST NOT be less than four minutes. The value of the idle-timeouts MAY be configurable by the network administrator.
REC-35ゲートウェイがTCPフローのエンドポイントがアクティブであるかどうかを判断できない場合、しばらくアイドル状態であった場合、ゲートウェイは状態レコードを放棄してもよい（MAY）。そのような場合、[RFC5382]で説明されているように、「確立されたフローのアイドルタイムアウト」の値は2時間4分未満であってはなりません。 「一時的なフローのアイドルタイムアウト」の値は、4分未満であってはなりません。アイドルタイムアウトの値は、ネットワーク管理者が設定できる場合があります。
REC-36 If a gateway forwards a TCP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing TCP headers that match the flow state record.
REC-36ゲートウェイがTCPフローを転送する場合、ゲートウェイは、フロー状態レコードと一致するTCPヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージも転送する必要があります。
REC-37 Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a TCP flow.
REC-37あらゆる種類のICMPv6メッセージの受信は、TCPフローの状態レコードを終了してはならない（MUST NOT）。
REC-38 All valid sequences of SCTP packets (defined in [RFC4960]) MUST be forwarded for outbound associations and explicitly permitted inbound associations. In particular, both the normal SCTP association establishment and the simultaneous-open mode of operation MUST be supported.
REC-38 SCTPパケットのすべての有効なシーケンス（[RFC4960]で定義）は、発信アソシエーションおよび明示的に許可された着信アソシエーションに対して転送する必要があります。特に、通常のSCTPアソシエーションの確立と同時オープン動作モードの両方をサポートする必要があります。
REC-39 By DEFAULT, a gateway MUST respond with an ICMPv6 "Destination Unreachable" error code 1 (Communication with destination administratively prohibited) to any unsolicited inbound INIT packet after waiting at least 6 seconds without first forwarding the associated outbound INIT from the interior peer.
REC-39 DEFAULTにより、ゲートウェイは、内部ピアから関連付けられたアウトバウンドINITを最初に転送せずに少なくとも6秒間待機した後、非送信請求インバウンドINITパケットに対して、ICMPv6 "Destination Unreachable"エラーコード1（管理上禁止された宛先との通信）で応答する必要があります。
REC-40 If a gateway cannot determine whether the endpoints of an SCTP association are active, then it MAY abandon the state record if it has been idle for some time. In such cases, the value of the "established association idle-timeout" MUST NOT be less than two hours four minutes. The value of the "transitory association idle-timeout" MUST NOT be less than four minutes. The value of the idle-timeouts MAY be configurable by the network administrator.
REC-40ゲートウェイがSCTPアソシエーションのエンドポイントがアクティブであるかどうかを判断できない場合、それがしばらくアイドル状態だった場合、ゲートウェイは状態レコードを放棄する場合があります。このような場合、「確立された関連付けのアイドルタイムアウト」の値は、2時間4分未満であってはなりません。 「一時的な関連付けのアイドルタイムアウト」の値は4分未満であってはなりません。アイドルタイムアウトの値は、ネットワーク管理者が設定できる場合があります。
REC-41 If a gateway forwards an SCTP association, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing SCTP headers that match the association state record.
REC-41ゲートウェイがSCTPアソシエーションを転送する場合、ゲートウェイは、アソシエーション状態レコードと一致するSCTPヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージも転送する必要があります。
REC-42 Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for an SCTP association.
REC-42あらゆる種類のICMPv6メッセージの受信は、SCTPアソシエーションの状態レコードを終了してはなりません（MUST NOT）。
REC-43 All valid sequences of DCCP packets (defined in [RFC4340]) MUST be forwarded for all flows to exterior servers, and for any flows to interior servers with explicitly permitted service codes.
REC-43 DCCPパケットのすべての有効なシーケンス（[RFC4340]で定義）は、外部サーバーへのすべてのフロー、および明示的に許可されたサービスコードを使用して内部サーバーへのすべてのフローに対して転送する必要があります。
REC-44 A gateway MAY abandon a DCCP state record if it has been idle for some time. In such cases, the value of the "open flow idle-timeout" MUST NOT be less than two hours four minutes. The value of the "transitory flow idle-timeout" MUST NOT be less than eight minutes. The value of the idle-timeouts MAY be configurable by the network administrator.
REC-44ゲートウェイがしばらくアイドル状態だった場合、ゲートウェイはDCCP状態レコードを破棄してもよい（MAY）。そのような場合、「オープンフローアイドルタイムアウト」の値は2時間4分未満であってはなりません。 「一時的なフローのアイドルタイムアウト」の値は、8分未満であってはなりません。アイドルタイムアウトの値は、ネットワーク管理者が設定できる場合があります。
REC-45 If an Internet gateway forwards a DCCP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing DCCP headers that match the flow state record.
REC-45インターネットゲートウェイがDCCPフローを転送する場合、フロー状態レコードと一致するDCCPヘッダーを含むICMPv6 "Destination Unreachable"および "Packet Too Big"メッセージも転送する必要があります。
REC-46 Receipt of any sort of ICMPv6 message MUST NOT terminate the state record for a DCCP flow.
REC-46あらゆる種類のICMPv6メッセージの受信は、DCCPフローの状態レコードを終了してはなりません（MUST NOT）。
REC-47 Valid sequences of packets bearing Shim6 payload extension headers in their outer IP extension header chains MUST be forwarded for all outbound and explicitly permitted flows. The content of the Shim6 payload extension header MAY be ignored for the purpose of state tracking.
REC-47外部IP拡張ヘッダーチェーンにShim6ペイロード拡張ヘッダーが含まれるパケットの有効なシーケンスは、すべての発信フローおよび明示的に許可されたフローに転送する必要があります。 Shim6ペイロード拡張ヘッダーの内容は、状態追跡の目的で無視される場合があります。
REC-48 Internet gateways with IPv6 simple security capabilities SHOULD implement a protocol to permit applications to solicit inbound traffic without advance knowledge of the addresses of exterior nodes with which they expect to communicate.
IPv6のシンプルなセキュリティ機能を備えたREC-48インターネットゲートウェイは、アプリケーションが通信する予定の外部ノードのアドレスを事前に知らなくても、アプリケーションが着信トラフィックを要求できるようにするプロトコルを実装する必要があります（SHOULD）。
REC-49 Internet gateways with IPv6 simple security capabilities MUST provide an easily selected configuration option that permits a "transparent mode" of operation that forwards all unsolicited flows regardless of forwarding direction, i.e., not to use the IPv6 simple security capabilities of the gateway. The transparent mode of operation MAY be the default configuration.
IPv6シンプルセキュリティ機能を備えたREC-49インターネットゲートウェイは、転送方向に関係なくすべての非送信請求フローを転送する「透過モード」の操作を許可する、つまりゲートウェイのIPv6シンプルセキュリティ機能を使用しない、簡単に選択できる構成オプションを提供する必要があります。操作の透過モードがデフォルトの構成である場合があります。
REC-50 By DEFAULT, subscriber-managed residential gateways MUST NOT offer management application services to the exterior network.
REC-50デフォルトでは、加入者管理の住宅用ゲートウェイは、外部ネットワークに管理アプリケーションサービスを提供してはなりません。
Comments and criticisms during the development of this document were received from the following IETF participants:
このドキュメントの作成中のコメントと批判は、次のIETF参加者から受けました。
+-------------------+----------------------------+
| Jari Arkko | Ran Atkinson |
| Fred Baker | Norbert Bollow |
| Cameron Byrne | Brian Carpenter |
| Remi Despres | Arnaud Ebalard |
| Fabrice Fontaine | Jun-ichiro "itojun" Hagino |
| Thomas Herbst | Christian Huitema |
| Joel Jaeggli | Cullen Jennings |
| Suresh Krishnan | Erik Kline |
| Julien Laganier | Kurt Erik Lindqvist |
| Mohamed Boucadair | Keith Moore |
| Robert Moskowitz | Teemu Savolainen |
| Hemant Singh | Yaron Sheffer |
| Mark Townsley | Iljitsch van Beijnum |
| Magnus Westerlund | Dan Wing |
+-------------------+----------------------------+
The editor thanks them all for their contributions.
編集者は彼らの貢献に感謝します。
It must be noted that a substantial portion of the text describing the detailed requirements for TCP and UDP filtering is derived or transposed from [RFC4787] and [RFC5382]. The editors of those documents, Francois Audet and Saikat Guha, also deserve substantial credit for the form of the present document.
TCPおよびUDPフィルタリングの詳細な要件を説明するテキストのかなりの部分は、[RFC4787]および[RFC5382]から派生または置き換えられていることに注意する必要があります。これらの文書の編集者であるFrancois AudetとSaikat Guhaも、現在の文書の形式にかなりの信用を置くに値します。
The IPv6 stateful filtering behavior described in this document is intended to be similar in function to the filtering behavior of commonly used IPv4/NAT gateways, which have been widely sold as a security tool for residential and small-office/home-office networks. As noted in the Security Considerations section of [RFC2993], the true impact of these tools may be a reduction in security. It may be generally assumed that the impacts discussed in that document related to filtering (and not translation) are to be expected with the simple IPv6 security mechanisms described here.
このドキュメントで説明されているIPv6ステートフルフィルタリング動作は、一般的に使用されているIPv4 / NATゲートウェイのフィルタリング動作と機能が類似していることを目的としています。これは、住宅および小規模オフィス/ホームオフィスネットワークのセキュリティツールとして広く販売されています。 [RFC2993]のセキュリティに関する考慮事項のセクションで述べたように、これらのツールの真の影響はセキュリティの低下である可能性があります。一般に、フィルタリングではなく変換に関連するそのドキュメントで説明されている影響は、ここで説明する単純なIPv6セキュリティメカニズムで予想されるものと想定されます。
In particular, it is worth noting that stateful filters create the illusion of a security barrier, but without the managed intent of a firewall. Appropriate security mechanisms implemented in the end nodes, in conjunction with the [RFC4864] local network protection methods, function without reliance on network layer hacks and transport filters that may change over time. Also, defined security barriers assume that threats originate in the exterior, which may lead to practices that result in applications being fully exposed to interior attack and which therefore make breaches much easier.
特に、ステートフルフィルターはセキュリティバリアのような錯覚を生み出しますが、ファイアウォールの管理された意図はありません。エンドノードに実装された適切なセキュリティメカニズムは、[RFC4864]ローカルネットワーク保護方法と連動して、時間の経過とともに変化する可能性のあるネットワークレイヤーハッキングやトランスポートフィルターに依存せずに機能します。また、定義されたセキュリティバリアは、脅威が外部から発生することを想定しているため、アプリケーションが内部攻撃に完全にさらされ、違反がはるかに容易になります。
The security functions described in this document may be considered redundant in the event that all IPv6 hosts using a particular gateway have their own IPv6 host firewall capabilities enabled. At the time of this writing, the vast majority of commercially available operating systems with support for IPv6 include IPv6 host firewall capability.
このドキュメントで説明するセキュリティ機能は、特定のゲートウェイを使用するすべてのIPv6ホストで独自のIPv6ホストファイアウォール機能が有効になっている場合、冗長であると見なされる場合があります。この記事の執筆時点で、IPv6をサポートする市販のオペレーティングシステムの大部分には、IPv6ホストファイアウォール機能が含まれています。
Also worth noting explicitly, a practical side-effect of the recommendations in Section 3.2.4, to allow inbound IPsec and IKE flows from exterior to interior, is to facilitate more transparent communication by the use of an unauthenticated mode of IPsec, as described in "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec" [RFC5386], and this may be a departure from expectations of transparency set by traditional IPv4/NAT residential gateways.
また、3.2.4の推奨事項の外部から内部への着信IPsecとIKEフローを許可する実際的な副作用は、非認証モードのIPsecを使用して、より透過的な通信を容易にすることです。 「Better-Than-Nothing-Security：Unauthenticated Mode of IPsec」[RFC5386]。これは、従来のIPv4 / NATレジデンシャルゲートウェイによって設定された透過性の期待からの脱却である可能性があります。
Finally, residential gateways that implement simple security functions are a bastion between the interior and the exterior, and therefore are a target of denial-of-service attacks against the interior network itself by processes designed to consume the resources of the gateway, e.g., a ping or SYN flood. Gateways should employ the same sorts of protection techniques as application servers on the Internet.
最後に、単純なセキュリティ機能を実装するレジデンシャルゲートウェイは、内部と外部の間の要塞であり、したがって、ゲートウェイのリソースを消費するように設計されたプロセスによる内部ネットワーク自体に対するサービス拒否攻撃の標的です。 pingまたはSYNフラッド。ゲートウェイは、インターネット上のアプリケーションサーバーと同じ種類の保護技術を採用する必要があります。
The IETF makes no statement, expressed or implied, as to whether using the capabilities described in this document ultimately improves security for any individual users or for the Internet community as a whole.
IETFは、このドキュメントで説明されている機能を使用すると、最終的に個々のユーザーのセキュリティが向上するのか、それともインターネットコミュニティ全体のセキュリティが向上するのかについて、明示的または黙示的に何も述べていません。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、B。、およびD. Borman、「TCP Extensions for High Performance」、RFC 1323、1992年5月。
[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月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 3775、2004年6月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828] Larzon、L-A。、Degermark、M.、Pink、S.、Jonsson、L-E。、G。Fairhurst、「The Lightweight User Datagram Protocol（UDP-Lite）」、RFC 3828、2004年7月。
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[RFC3879] Huitema、C。およびB. Carpenter、「Deprecating Site Local Addresses」、RFC 3879、2004年9月。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[RFC4007] Deering、S.、Haberman、B.、Jinmei、T.、Nordmark、E。、およびB. Zill、「IPv6 Scoped Address Architecture」、RFC 4007、2005年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月。
[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月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、2006年3月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネット制御メッセージプロトコル（ICMPv6）、インターネットプロトコルバージョン6（IPv6）仕様」、RFC 4443、2006年3月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]オーデットF.およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、2007年1月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890] Davies、E。およびJ. Mohacsi、「ファイアウォールでのICMPv6メッセージのフィルタリングに関する推奨事項」、RFC 4890、2007年5月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[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月。
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April 2008.
[RFC5156] Blanchet、M。、「Special-Use IPv6 Addresses」、RFC 5156、2008年4月。
[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月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキー交換プロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008.
[NAT-PMP] Cheshire、S.、Krochmal、M。、およびK. Sekar、「NAT Port Mapping Protocol（NAT-PMP）」、Work in Progress、2008年4月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.
[RFC1337] Braden、B。、「TCPでの時間待ちの暗殺ハザード」、RFC 1337、1992年5月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「Path MTU Discovery for IP version 6」、RFC 1981、1996年8月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「Generic Packet Tunneling in IPv6 Specification」、RFC 2473、1998年12月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを採用するサービス拒否攻撃の打破」、BCP 38、RFC 2827、2000年5月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、T。、「NATのアーキテクチャ上の影響」、RFC 2993、2000年11月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F。、およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[RFC4080]ハンコックR.、カラギアニスG.、ラフニーJ.、およびS.ヴァンデンボッシュ、「シグナリングの次のステップ（NSIS）：フレームワーク」、RFC 4080、2005年6月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294] Loughney、J。、「IPv6 Node Requirements」、RFC 4294、2006年4月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864] Van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年8月。
[RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communication (MIDCOM) Protocol Semantics", RFC 5189, March 2008.
[RFC5189] Stiemerling、M.、Quittek、J。、およびT. Taylor、「Middlebox Communication（MIDCOM）Protocol Semantics」、RFC 5189、2008年3月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「NAT Behavioral Requirements for TCP」、BCP 142、RFC 5382、2008年10月。
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008.
[RFC5386]ウィリアムズ、N。およびM.リチャードソン、「Better-Than-Nothing Security：An Unauthenticated Mode of IPsec」、RFC 5386、2008年11月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「Session Traversal Utilities for NAT（STUN）」、RFC 5389、2008年10月。
[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月。
[UPnP-IGD] UPnP Forum, "Universal Plug and Play Internet Gateway Device Standardized Device Control Protocol", September 2010, <http://upnp.org/specs/gw/igd2/>.
[UPnP-IGD] UPnPフォーラム、「ユニバーサルプラグアンドプレイインターネットゲートウェイデバイス標準化デバイスコントロールプロトコル」、2010年9月、<http://upnp.org/specs/gw/igd2/>。
[WOODYATT-ALD] Woodyatt, J., "Application Listener Discovery (ALD) for IPv6", Work in Progress, July 2008.
[WOODYATT-ALD] Woodyatt、J。、「Application Listener Discovery（ALD）for IPv6」、Work in Progress、2008年7月。
Author's Address
著者のアドレス
James Woodyatt (editor) Apple Inc. 1 Infinite Loop Cupertino, CA 95014 US
James Woodyatt（editor）Apple Inc. 1 Infinite Loop Cupertino、CA 95014 US
EMail: jhw@apple.com