Network Working Group V. Gill
Request for Comments: 5082 J. Heasley
Obsoletes: 3682 D. Meyer
Category: Standards Track P. Savola, Ed.
C. Pignataro
October 2007
The Generalized TTL Security Mechanism (GTSM)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682.
パケットが接続されているリンク上の隣接ノードによって発信されたかどうかを確認するために（TTL）（IPv4）のか、ホップリミット（IPv6）をライブするパケットのTimeの使用は、多くの最近のプロトコルで使用されてきました。この文書では、この手法を一般化します。この文書では、実験的RFC 3682を廃止します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Assumptions Underlying GTSM . . . . . . . . . . . . . . . . . 3
2.1. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . . 4
2.2. Assumptions on Attack Sophistication . . . . . . . . . . . 4
3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5.1. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . . 7
5.2. Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7
5.2.1. IP Tunneled over IP . . . . . . . . . . . . . . . . . 8
5.2.2. IP Tunneled over MPLS . . . . . . . . . . . . . . . . 9
5.3. Onlink Attackers . . . . . . . . . . . . . . . . . . . . . 11
5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11
5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12
6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Multi-Hop GTSM . . . . . . . . . . . . . . . . . . . 15
Appendix B. Changes Since RFC 3682 . . . . . . . . . . . . . . . 15
The Generalized TTL Security Mechanism (GTSM) is designed to protect a router's IP-based control plane from CPU-utilization based attacks. In particular, while cryptographic techniques can protect the router-based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide variety of attacks, many attacks based on CPU overload can be prevented by the simple mechanism described in this document. Note that the same technique protects against other scarce-resource attacks involving a router's CPU, such as attacks against processor-line card bandwidth.
一般TTLセキュリティメカニズム（GTSM）は、CPU使用率ベースの攻撃からルータのIPベースのコントロールプレーンを保護するように設計されています。暗号技術は、攻撃の様々なからルータベースのインフラストラクチャ（例えば、BGP [RFC4271]、[RFC4272]）を保護することができるが、特に、CPUの過負荷に基づいて、多くの攻撃は、この文書に記載され、簡単な機構により防止することができます。同技術は、プロセッサ、ラインカードの帯域幅に対する攻撃として、ルータのCPUを含む他の希少資源の攻撃から保護することに注意してください。
GTSM is based on the fact that the vast majority of protocol peerings are established between routers that are adjacent. Thus, most protocol peerings are either directly between connected interfaces or, in the worst case, are between loopback and loopback, with static routes to loopbacks. Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value can provide a simple and reasonably robust defense from infrastructure attacks based on forged protocol packets from outside the network. Note, however, that GTSM is not a substitute for authentication mechanisms. In particular, it does not secure against insider on-the-wire attacks, such as packet spoofing or replay.
GTSMは、プロトコルピアリングの大部分は隣接するルータとの間で確立されているという事実に基づいています。したがって、ほとんどのプロトコルピアリングは、直接接続されたインターフェイスとの間又は、最悪の場合、ループバックの静的ルートで、ループバックとループバックの間であるのいずれかです。 TTLスプーフィングはほぼ不可能であると考えられるので、予想されるTTL値に基づくメカニズムは、ネットワーク外部から偽造プロトコルパケットに基づいて、インフラストラクチャ攻撃から簡単かつ合理的に堅牢な防御を提供することができます。 GTSMは、認証メカニズムに代わるものではありませんただし、注意してください。特に、それは、パケットスプーフィングやリプレイなどインサイダーオン・ワイヤー攻撃に対して安全ではありません。
Finally, the GTSM mechanism is equally applicable to both TTL (IPv4) and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop Limit have identical semantics. As a result, in the remainder of this document the term "TTL" is used to refer to both TTL or Hop Limit (as appropriate).
最後に、GTSM機構はTTL（IPv4）とホップリミット（IPv6）の両方に等しく適用可能であり、そしてGTSM、TTL及びホップ限界の観点から同じ意味を有します。結果として、この文書の残りでは、用語「TTL」はTTL又はホップ限界（適宜）の両方を指すために使用されます。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
GTSM is predicated upon the following assumptions:
GTSMは、以下の仮定に基づくものです：
1. The vast majority of protocol peerings are between adjacent routers.
1.プロトコルピアリングの大半は、隣接ルータの間です。
2. Service providers may or may not configure strict ingress filtering [RFC3704] on non-trusted links. If maximal protection is desired, such filtering is necessary as described in Section 2.2.
2.サービスプロバイダは、信頼できないリンクに厳しいイングレスフィルタリング[RFC3704]を設定してもしなくてもよいです。最大の保護が所望される場合、セクション2.2で説明したように、そのようなフィルタリングは必要です。
3. Use of GTSM is OPTIONAL, and can be configured on a per-peer (group) basis.
GTSMの前記使用は任意であり、そして当たりピア（群）に基づいて構成することができます。
5. The router supports a method to use separate resource pools (e.g., queues, processing quotas) for differently classified traffic.
5.ルータは、異なる分類されたトラフィックのための別のリソースプール（例えば、キュー、処理クォータ）を使用する方法をサポートしています。
Note that this document does not prescribe further restrictions that a router may apply to packets not matching the GTSM filtering rules, such as dropping packets that do not match any configured protocol session and rate-limiting the rest. This document also does not suggest the actual means of resource separation, as those are hardware and implementation-specific.
この文書は、任意の構成プロトコルセッションと律速残りと一致しないパケットをドロップするようルータがGTSMフィルタリングルールに合致しないパケットにも適用することができるさらなる制限を規定していないことに留意されたいです。この文書はまた、これらのハードウェアおよび実装に固有のものとして、リソース分離の実際の手段を示唆していません。
However, the possibility of denial-of-service (DoS) attack prevention is based on the assumption that classification of packets and separation of their paths are done before the packets go through a scarce resource in the system. In practice, the closer GTSM processing is done to the line-rate hardware, the more resistant the system is to DoS attacks.
しかし、サービス拒否の可能性（DoS）攻撃の防止は、パケットは、システム内の希少資源を通過する前に、パケットとそのパスの分離の分類が行われているという仮定に基づいています。実際には、近いGTSM処理はラインレートハードウェアに行われ、より耐性システムは、DoS攻撃です。
This document assumes that, when used with existing protocols, GTSM will be manually configured between protocol peers. That is, no automatic GTSM capability negotiation, such as is provided by RFC 3392 [RFC3392], is assumed or defined.
この文書は、既存のプロトコルで使用される場合、GTSM手動プロトコルピア間で設定される、と仮定しています。 RFC 3392 [RFC3392]で提供され、想定されるか、または定義されたようすなわち、自動的なGTSM機能ネゴシエーション、このようではありません。
If a new protocol is designed with built-in GTSM support, then it is recommended that procedures are always used for sending and validating received protocol packets (GTSM is always on, see for example [RFC2461]). If, however, dynamic negotiation of GTSM support is necessary, protocol messages used for such negotiation MUST be authenticated using other security mechanisms to prevent DoS attacks.
新しいプロトコルが内蔵GTSMサポートして設計されている場合、（GTSMが常にオンである、例えば、[RFC2461]を参照）の手順を常に受信したプロトコル・パケットを送信し、検証のために使用されることが推奨されます。しかし、GTSMサポートの動的ネゴシエーションが必要な場合、このようなネゴシエーションのために使用されるプロトコルメッセージは、DoS攻撃を防ぐために、他のセキュリティ・メカニズムを使用して認証されなければなりません。
Also note that this specification does not offer a generic GTSM capability negotiation mechanism, so messages of the protocol augmented with the GTSM behavior will need to be used if dynamic negotiation is deemed necessary.
また、動的な交渉が必要と判断された場合にGTSMの振る舞いで拡張プロトコルのメッセージが使用する必要がありますので、この仕様は、一般的なGTSM能力交渉メカニズムを提供しないことに注意してください。
Throughout this document, we assume that potential attackers have evolved in both sophistication and access to the point that they can send control traffic to a protocol session, and that this traffic appears to be valid control traffic (i.e., it has the source/ destination of configured peer routers).
このドキュメントでは、我々は潜在的な攻撃者が洗練された彼らは、プロトコルセッションに制御トラフィックを送信できるポイントへのアクセスの両方で進化してきたことを想定し、このトラフィックは、（有効な制御トラフィックのように見えること、すなわち、それはの送信元/宛先を持っています構成ピアルータ）。
We also assume that each router in the path between the attacker and the victim protocol speaker decrements TTL properly (clearly, if either the path or the adjacent peer is compromised, then there are worse problems to worry about).
また、攻撃者と被害者のプロトコルスピーカー間のパス内の各ルータが適切にTTLをデクリメント（パスまたは隣接ピアのいずれかが侵害された場合、明らかに、そして心配するより悪い問題がある）ことを前提としています。
For maximal protection, ingress filtering should be applied before the packet goes through the scarce resource. Otherwise an attacker directly connected to one interface could disturb a GTSM-protected session on the same or another interface. Interfaces that aren't configured with this filtering (e.g., backbone links) are assumed to not have such attackers (i.e., are trusted).
パケットが希少資源を通過する前に、最大限の保護のために、イングレスフィルタリングを適用する必要があります。そうでなければ、攻撃者は直接、同じまたは別のインタフェース上GTSMで保護されたセッションを乱す可能性が一つのインタフェースに接続されています。このフィルタリング（例えば、バックボーン・リンク）を使用して構成されていないインターフェイス（すなわち、信頼されている）、このような攻撃を持っていないと仮定されます。
As a specific instance of such interfaces, we assume that tunnels are not a back-door for allowing TTL-spoofing on protocol packets to a GTSM-protected peering session with a directly connected neighbor. We assume that: 1) there are no tunneled packets terminating on the router, 2) tunnels terminating on the router are assumed to be secure and endpoints are trusted, 3) tunnel decapsulation includes source address spoofing prevention [RFC3704], or 4) the GTSM-enabled session does not allow protocol packets coming from a tunnel.
そのようなインターフェイスの特定のインスタンスとして、我々は、トンネルが直接接続されたネイバーとGTSM保護ピアリングセッションにプロトコルパケットにTTLスプーフィングを可能にするバックドアではないと仮定する。我々は仮定する：1）ルータで終端ないトンネルパケットが存在しない、2）ルータで終端するトンネルがセキュアであると仮定され、エンドポイントが信頼されている、3）トンネルカプセル化解除は、送信元アドレススプーフィング防止[RFC3704]を含む、または4） GTSM対応のセッションがトンネルから来るプロトコルパケットを許可していません。
Since the vast majority of peerings are between adjacent routers, we can set the TTL on the protocol packets to 255 (the maximum possible for IP) and then reject any protocol packets that come in from configured peers that do NOT have an inbound TTL of 255.
ピアリングの大半は、隣接ルータ間なので、我々は255（IPのための可能な最大）へのプロトコルパケットのTTLを設定し、255のインバウンドTTLを持っていないことに構成ピアから来る任意のプロトコルのパケットを拒否することができます。
GTSM can be disabled for applications such as route-servers and other multi-hop peerings. In the event that an attack comes in from a compromised multi-hop peering, that peering can be shut down.
GTSMは、ルートサーバや他のマルチホップピアリングなどのアプリケーションのために無効にすることができます。攻撃がピアリングをシャットダウンすることができ、侵害されたマルチホップピアリングから来た場合には。
If GTSM is not built into the protocol and is used as an additional feature (e.g., for BGP, LDP, or MSDP), it SHOULD NOT be enabled by default in order to remain backward-compatible with the unmodified protocol. However, if the protocol defines a built-in dynamic capability negotiation for GTSM, a protocol peer MAY suggest the use of GTSM provided that GTSM would only be enabled if both peers agree to use it.
GTSMは、プロトコルに組み込まれていないと（例えば、BGP、LDP、またはMSDPのための）追加の特徴として使用される場合、それは未修飾のプロトコルとの下位互換性を維持するために、デフォルトで有効にしないでください。プロトコルはGTSMのための組み込みの動的な能力交渉を定義する場合は、GTSMの使用を提案してもよいプロトコルピアは両方のピアがそれを使用することに同意するものとした場合GTSMにのみ有効にされることを提供します。
If GTSM is enabled for a protocol session, the following steps are added to the IP packet sending and reception procedures:
GTSMは、プロトコルセッションのために有効になっている場合は、次の手順では、手順を送信し、受信IPパケットに追加されます。
Sending protocol packets:
プロトコルパケットを送信します：
The TTL field in all IP packets used for transmission of messages associated with GTSM-enabled protocol sessions MUST be set to 255. This also applies to the related ICMP error handling messages.
GTSM対応のプロトコル・セッションに関連するメッセージの送信に使用されるすべてのIPパケット内のTTLフィールドには、これは、メッセージを処理し、関連するICMPエラーに適用される255に設定しなければなりません。
On some architectures, the TTL of control plane originated traffic is under some configurations decremented in the forwarding plane. The TTL of GTSM-enabled sessions MUST NOT be decremented.
いくつかのアーキテクチャでは、制御プレーンのTTLは、トラフィックが転送プレーンにデクリメントいくつかの構成の下で始まりました。 GTSM対応のセッションのTTLをデクリメントしてはなりません。
Receiving protocol packets:
プロトコルパケットを受信：
The GTSM packet identification step associates each received packet addressed to the router's control plane with one of the following three trustworthiness categories:
GTSMパケット識別工程会合は、それぞれ、受信したパケットは、次の3つの信頼性のカテゴリのいずれかで、ルータの制御プレーン宛て。
+ Unknown: these are packets that cannot be associated with any registered GTSM-enabled session, and hence GTSM cannot make any judgment on the level of risk associated with them.
+不明：これらは、登録されているすべてのGTSM対応のセッションに関連付けることができない、したがってGTSMは、それらに関連するリスクのレベルに何らかの判断を下すことができないパケットです。
+ Trusted: these are packets that have been identified as belonging to one of the GTSM-enabled sessions, and their TTL values are within the expected range.
+信頼できる：これらは、GTSM対応のセッションの1つに属するものとして同定されているパケットであり、そのTTL値が予想される範囲内にあります。
+ Dangerous: these are packets that have been identified as belonging to one of the GTSM-enabled sessions, but their TTL values are NOT within the expected range, and hence GTSM believes there is a risk that these packets have been spoofed.
+危険：これらは、GTSM対応のセッションの1つに属するものとして同定されているパケットですが、そのTTL値が予想される範囲内にない、ので、GTSMは、これらのパケットがスプーフィングされているおそれがあると考えています。
The exact policies applied to packets of different classifications are not postulated in this document and are expected to be configurable. Configurability is likely necessary in particular with the treatment of related messages (ICMP errors). It should be noted that fragmentation may restrict the amount of information available for classification.
異なる分類のパケットに適用される正確なポリシーは、このドキュメントで想定されていないと、設定可能であることが予想されます。構成可能性は、関連するメッセージ（ICMPエラー）の治療で特に可能性が必要です。断片化は、分類のために利用可能な情報の量を制限することができることに留意すべきです。
However, by default, the implementations:
ただし、デフォルトでは、インプリメンテーション：
+ SHOULD ensure that packets classified as Dangerous do not compete for resources with packets classified as Trusted or Unknown.
+危険として分類されたパケットが信頼できるか不明として分類されたパケットとのリソースの競合していないことを確認する必要があります。
+ MUST NOT drop (as part of GTSM processing) packets classified as Trusted or Unknown.
+（GTSM処理の一部として）信頼または未知として分類されたパケットをドロップしてはいけません。
+ MAY drop packets classified as Dangerous.
+危険として分類されたパケットをドロップすることがあります。
The use of the TTL field to protect BGP originated with many different people, including Paul Traina and Jon Stewart. Ryan McDowell also suggested a similar idea. Steve Bellovin, Jay Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk, and Alex Zinin also provided useful feedback on earlier versions of this document. David Ward provided insight on the generalization of the original BGP-specific idea. Alex Zinin, Alia Atlas, and John Scudder provided a significant amount of feedback for the newer versions of the document. During and after the IETF Last Call, useful comments were provided by Francis Dupont, Sam Hartman, Lars Eggert, and Ross Callon.
BGPを保護するために、TTLフィールドの使用は、ポールTrainaのとジョン・スチュワートを含む多くの異なる人々、と始まりました。ライアンマクドウェルも同様の考えを示唆しました。スティーブBellovin氏、ジェイBorkenhagen、ランディブッシュ、アルフレッドHoenes、バーンPaxon、ロバートRaszuk、およびアレックスジニンも、この文書の以前のバージョンで有用なフィードバックを提供します。デビッド・ウォードは、元のBGP固有の考え方の一般化についての洞察を提供しました。アレックスジニン、アリアアトラス、そしてジョン・スカダーは、ドキュメントの新しいバージョンのフィードバック、かなりの量を提供しました。 IETFラストコール中および後に、有益なコメントはフランシスデュポン、サム・ハートマン、ラースエッゲルト、とロスCallonによって提供されました。
GTSM is a simple procedure that protects single-hop protocol sessions, except in those cases in which the peer has been compromised. In particular, it does not protect against the wide range of on-the-wire attacks; protection from these attacks requires more rigorous security mechanisms.
GTSMピアが損なわれていたような場合を除いて、シングルホップ・プロトコル・セッションを保護する簡単な手順です。特に、オン・ザ・ワイヤー、幅広い攻撃から保護しません。これらの攻撃からの保護は、より厳格なセキュリティメカニズムが必要です。
The approach described here is based on the observation that a TTL (or Hop Limit) value of 255 is non-trivial to spoof, since as the packet passes through routers towards the destination, the TTL is decremented by one per router. As a result, when a router receives a packet, it may not be able to determine if the packet's IP address is valid, but it can determine how many router hops away it is (again, assuming none of the routers in the path are compromised in such a way that they would reset the packet's TTL).
ここで説明するアプローチは、パケットが宛先に向かってルータを通過する際に、TTLは、ルータごとにデクリメントされるので、255のTTL（又はホップ限界）値は、なりすましに非自明であるという観察に基づいています。ルータがパケットを受信したときにその結果、パケットのIPアドレスが有効であるかどうかは判断できないかもしれませんが、それはそれは、パス内のルータのどれもが危険にさらされていないと仮定すると、再び（どのように多くのルータがホップ離れ決定することができます彼らは、パケットのTTLをリセットするような方法で）。
Note, however, that while engineering a packet's TTL such that it has a particular value when sourced from an arbitrary location is difficult (but not impossible), engineering a TTL value of 255 from non-directly connected locations is not possible (again, assuming none of the directly connected neighbors are compromised, the packet has not been tunneled to the decapsulator, and the intervening routers are operating in accordance with RFC 791 [RFC0791]).
、再び（不可能であると仮定すると、非直接接続されている場所から255のTTL値を操作する、任意の場所から発信するとき、それは特定の値を有するようにパケットのTTLを操作しながらすることは難しい（しかし、不可能ではない）であること、しかし、注意してください直接接続されたネイバーのどれがパケットをカプセル開放装置にトンネリングされていない、及び介在ルータは、RFC 791 [RFC0791]に従って動作している、損なわれていません）。
The security of any tunneling technique depends heavily on authentication at the tunnel endpoints, as well as how the tunneled packets are protected in flight. Such mechanisms are, however, beyond the scope of this memo.
任意のトンネリング技術のセキュリティは、トンネルパケットが飛行中に保護されているかだけでなく、トンネルのエンドポイントでの認証に大きく依存します。このようなメカニズムは、このメモの範囲を超えて、しかし、です。
An exception to the observation that a packet with TTL of 255 is difficult to spoof may occur when a protocol packet is tunneled and the tunnel is not integrity-protected (i.e., the lower layer is compromised).
プロトコルパケットをトンネリング及びトンネルが完全性保護（即ち、下層が損なわれる）ではない場合255のTTLを持つパケットを偽装することは困難であるという観察に例外が発生し得ます。
When the protocol packet is tunneled directly to the protocol peer (i.e., the protocol peer is the decapsulator), the GTSM provides some limited added protection as the security depends entirely on the integrity of the tunnel.
プロトコルパケットは（すなわち、プロトコルピアがカプセル開放ある）プロトコルピアに直接トンネリングされたときにセキュリティトンネルの完全性に完全に依存するように、GTSMは、いくつかの限られた追加の保護を提供します。
For protocol adjacencies over a tunnel, if the tunnel itself is deemed secure (i.e., the underlying infrastructure is deemed secure, and the tunnel offers degrees of protection against spoofing such as keys or cryptographic security), the GTSM can serve as a check that the protocol packet did not originate beyond the head-end of the tunnel. In addition, if the protocol peer can receive packets for the GTSM-protected protocol session from outside the tunnel, the GTSM can help thwart attacks from beyond the adjacent router.
トンネル自体がセキュアであると考えられる場合にトンネルを介しプロトコル隣接のために、（すなわち、基礎となるインフラをセキュアとみなされ、トンネルは、キーや暗号化セキュリティなどのなりすましに対する保護の程度を提供しています）、GTSMを確認することとして機能することができますプロトコルパケットは、トンネルのヘッドエンドを超えて発信しませんでした。プロトコルピアがトンネル外部からGTSM保護プロトコルセッションのパケットを受信することができればまた、GTSMは、隣接ルータを超えてからの攻撃を阻止することができます。
When the tunnel tail-end decapsulates the protocol packet and then IP-forwards the packet to a directly connected protocol peer, the TTL is decremented as described below. This means that the tunnel decapsulator is the penultimate node from the GTSM-protected protocol peer's perspective. As a result, the GTSM check protects from attackers encapsulating packets to your peers. However, specific cases arise when the connection from the tunnel decapsulator node to the protocol peer is not an IP forwarding hop, where TTL-decrementing does not happen (e.g., layer-2 tunneling, bridging, etc). In the IPsec architecture [RFC4301], another example is the use of Bump-in-the-Wire (BITW) [BITW].
トンネルテールエンドは、プロトコルパケット及びIP-転送直接接続されているプロトコルのピアにパケットをデカプセル化する際、以下に記載されるように、TTLをデクリメントします。これは、トンネルカプセル開放装置は、GTSM保護プロトコルピアの観点から最後から二番目のノードであることを意味します。その結果、GTSMチェックは、あなたのピアにパケットをカプセル化攻撃から保護します。プロトコルピアにトンネル非カプセル化ノードからの接続はTTL-デクリメントが起こらないIP転送ホップ、（例えば、レイヤ2トンネリング、ブリッジなど）でない場合ただし、特定のケースが生じます。 IPsecのアーキテクチャ[RFC4301]に、別の例では、バンプ・イン・ザ・ワイヤ（BITW）BITW]の使用です。
Protocol packets may be tunneled over IP directly to a protocol peer, or to a decapsulator (tunnel endpoint) that then forwards the packet to a directly connected protocol peer. Examples of tunneling IP over IP include IP-in-IP [RFC2003], GRE [RFC2784], and various forms of IPv6-in-IPv4 (e.g., [RFC4213]). These cases are depicted below.
プロトコルパケットは、直接接続されたプロトコルのピアにパケットを転送すること（トンネルエンドポイント）プロトコル・ピア、またはカプセル開放装置に直接IP上にトンネリングすることができます。 IPオーバーIPトンネリングの例は、IP-IP [RFC2003]、GRE [RFC2784]、およびIPv6型のIPv4の様々な形態を含む（例えば、[RFC4213]）。これらの例は以下の描かれています。
Peer router ---------- Tunnel endpoint router and peer
TTL=255 [tunnel] [TTL=255 at ingress]
[TTL=255 at processing]
Peer router -------- Tunnel endpoint router ----- On-link peer
TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress]
[TTL=254 at egress]
In both cases, the encapsulator (origination tunnel endpoint) is the (supposed) sending protocol peer. The TTL in the inner IP datagram can be set to 255, since RFC 2003 specifies the following behavior:
両方の場合において、カプセル化（発信トンネルエンドポイント）が（想定）送信プロトコルピアです。 RFC 2003は、次の動作を指定しますので、内側のIPデータグラムでのTTLは、255に設定することができます。
When encapsulating a datagram, the TTL in the inner IP header is decremented by one if the tunneling is being done as part of forwarding the datagram; otherwise, the inner header TTL is not changed during encapsulation.
データグラムをカプセル化するときトンネリングがデータグラムの転送の一部として実行されている場合、内側のIPヘッダ内のTTLは1だけデクリメントされます。そうでなければ、内部ヘッダのTTLは、カプセル化の際に変更されません。
In the first case, the encapsulated packet is tunneled directly to the protocol peer (also a tunnel endpoint), and therefore the encapsulated packet's TTL can be received by the protocol peer with an arbitrary value, including 255.
最初のケースでは、カプセル化されたパケットは、プロトコルピア（また、トンネルエンドポイント）に直接トンネリングされ、したがって、カプセル化されたパケットのTTLは255を含む、任意の値とプロトコルピアによって受信することができます。
In the second case, the encapsulated packet is tunneled to a decapsulator (tunnel endpoint), which then forwards it to a directly connected protocol peer. For IP-in-IP tunnels, RFC 2003 specifies the following decapsulator behavior:
第二のケースでは、カプセル化されたパケットは、次に、直接接続されたプロトコルのピアに転送カプセル開放装置（トンネルエンドポイント）にトンネリングされます。 IP内IPトンネルでは、RFC 2003は、次のカプセル化を解くの動作を指定します。
The TTL in the inner IP header is not changed when decapsulating. If, after decapsulation, the inner datagram has TTL = 0, the decapsulator MUST discard the datagram. If, after decapsulation, the decapsulator forwards the datagram to one of its network interfaces, it will decrement the TTL as a result of doing normal IP forwarding. See also Section 4.4.
デカプセル化する際、内側IPヘッダのTTLは変更されません。 、デカプセル化した後、内部データグラムはTTL = 0を有する場合、カプセル開放装置は、データグラムを廃棄しなければなりません。 、カプセル化解除した後、カプセル化を解くには、そのネットワークインターフェイスのいずれかにデータグラムを転送する場合は、通常のIP転送を行うことの結果として、TTLをデクリメントします。また、4.4節を参照してください。
And similarly, for GRE tunnels, RFC 2784 specifies the following decapsulator behavior:
同様に、GREトンネルのために、RFC 2784には、次のカプセル化を解くの動作を指定します。
When a tunnel endpoint decapsulates a GRE packet which has an IPv4 packet as the payload, the destination address in the IPv4 payload packet header MUST be used to forward the packet and the TTL of the payload packet MUST be decremented.
トンネルエンドポイントは、ペイロードとしてIPv4パケットを有するGREパケットをデカプセル化する際、IPv4のペイロードパケットのヘッダの宛先アドレスは、パケットを転送するために使用する必要があり、ペイロードパケットのTTLをデクリメントしなければなりません。
Hence the inner IP packet header's TTL, as seen by the decapsulator, can be set to an arbitrary value (in particular, 255). If the decapsulator is also the protocol peer, it is possible to deliver the protocol packet to it with a TTL of 255 (first case). On the other hand, if the decapsulator needs to forward the protocol packet to a directly connected protocol peer, the TTL will be decremented (second case).
従って、内側IPパケットヘッダのTTLは、カプセル開放装置によって見られるように、（特に、255）の任意の値に設定することができます。カプセル開放装置はまた、プロトコルピアである場合、255のTTL（最初のケース）と、それにプロトコルパケットを配信することが可能です。カプセル開放装置が直接接続プロトコルピアにプロトコル・パケットを転送する必要がある一方、TTLは、（第2ケース）デクリメントします。
Protocol packets may also be tunneled over MPLS Label Switched Paths (LSPs) to a protocol peer. The following diagram depicts the topology.
プロトコルパケットは、プロトコルのピアへのパス（LSPを）スイッチMPLSラベル上にトンネリングすることができます。次の図は、トポロジを示しています。
Peer router -------- LSP Termination router and peer
TTL=255 MPLS LSP [TTL=x at ingress]
MPLS LSPs can operate in Uniform or Pipe tunneling models. The TTL handling for these models is described in RFC 3443 [RFC3443] that updates RFC 3032 [RFC3032] in regards to TTL processing in MPLS networks. RFC 3443 specifies the TTL processing in both Uniform and Pipe Models, which in turn can used with or without penultimate hop popping (PHP). The TTL processing in these cases results in different behaviors, and therefore are analyzed separately. Please refer to Section 3.1 through Section 3.3 of RFC 3443.
MPLS LSPは、制服やパイプトンネリングモデルで動作することができます。これらのモデルのための処理TTLは、MPLSネットワークにおけるTTL処理に関してはRFC 3032 [RFC3032]を更新するRFC 3443 [RFC3443]に記載されています。 RFC 3443は、順番に（PHP）をポッピングまたは最後から二番目のホップすることなく使用することができ、均一かつパイプ両モデルにおけるTTL処理を指定します。これらの場合にTTL処理は異なる動作になるので、別々に分析されます。 RFC 3443のセクション3.3を通じて3.1節を参照してください。
The main difference from a TTL processing perspective between Uniform and Pipe Models at the LSP termination node resides in how the incoming TTL (iTTL) is determined. The tunneling model determines the iTTL: For Uniform Model LSPs, the iTTL is the value of the TTL field from the popped MPLS header (encapsulating header), whereas for Pipe Model LSPs, the iTTL is the value of the TTL field from the exposed header (encapsulated header).
LSPの終端ノードで均一でパイプモデルとの間のTTL処理の観点から主な違いは、着信TTL（ITTL）を決定する方法にあります。トンネリングモデルはITTLを決定する：統一モデルのLSPについて、ITTLは、（ヘッダをカプセル化）ポップMPLSヘッダのTTLフィールドの値であり、パイプモデルのLSPのために、ITTLが露出ヘッダからのTTLフィールドの値であるのに対し（カプセル化ヘッダ）。
For Uniform Model LSPs, RFC 3443 states that at ingress:
制服モデルのLSPの場合は、RFC 3443には、その入口で述べています：
For each pushed Uniform Model label, the TTL is copied from the label/IP-packet immediately underneath it.
それぞれの統一モデルのラベルをプッシュするために、TTLはすぐ下にラベル/ IPパケットからコピーされます。
From this point, the inner TTL (i.e., the TTL of the tunneled IP datagram) represents non-meaningful information, and at the egress node or during PHP, the ingress TTL (iTTL) is equal to the TTL of the popped MPLS header (see Section 3.1 of RFC 3443). In consequence, for Uniform Model LSPs of more than one hop, the TTL at ingress (iTTL) will be less than 255 (x <= 254), and as a result the check described in Section 3 of this document will fail.
この点から、インナーTTL（すなわち、トンネル化IPデータグラムのTTL）は非意味のある情報を表しており、出口ノードにおいて、またはPHPの間、入口TTL（ITTL）は（ポップMPLSヘッダのTTLに等しいです。 RFC 3443のセクション3.1）を参照してください。これにより、複数のホップ、入口でのTTLの統一モデルのLSPのために（ITTL）が255未満（X <= 254）になり、その結果、このドキュメントのセクション3に記載のチェックが失敗します。
The TTL treatment is identical between Short Pipe Model LSPs without PHP and Pipe Model LSPs (without PHP only). For these cases, RFC 3443 states that:
TTL処理は、（PHPのみなし）PHPとパイプモデルのLSPなしショートパイプモデルのLSP間で同一です。これらのケースについては、RFC 3443には、と述べています：
For each pushed Pipe Model or Short Pipe Model label, the TTL field is set to a value configured by the network operator. In most implementations, this value is set to 255 by default.
各パイプモデルまたはショートパイプモデルラベルをプッシュするために、TTLフィールドは、ネットワークオペレータによって設定された値に設定されています。ほとんどの実装では、この値はデフォルトで255に設定されています。
In these models, the forwarding treatment at egress is based on the tunneled packet as opposed to the encapsulation packet. The ingress TTL (iTTL) is the value of the TTL field of the header that is exposed, that is the tunneled IP datagram's TTL. The protocol packet's TTL as seen by the LSP termination can therefore be set to an arbitrary value (including 255). If the LSP termination router is also the protocol peer, it is possible to deliver the protocol packet with a TTL of 255 (x = 255).
カプセル化パケットとは対照的に、これらのモデルでは、出口での転送処理は、トンネリングされたパケットに基づいています。入口TTL（ITTL）が露出されるヘッダのTTLフィールドの値であり、それは、トンネルのIPデータグラムのTTLです。 LSPの終端から見たプロトコル・パケットのTTLは、したがって、（255を含む）を任意の値に設定することができます。 LSP終端ルータは、プロトコルのピアである場合、255（X = 255）のTTLとプロトコル・パケットを配信することが可能です。
Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled packet is unchanged after the PHP operation. Therefore, the same conclusions drawn regarding the Short Pipe Model LSPs without PHP and Pipe Model LSPs (without PHP only) apply to this case. For Short Pipe Model LSPs, the TTL at egress has the same value with or without PHP.
最後に、PHPでのショートパイプモデルのLSPのために、トンネリングされたパケットのTTLは、PHPの動作の後に変更されていません。そのため、同じ結論が（のみPHPなし）PHPとパイプモデルのLSPずにショートパイプモデルのLSPについて描かれたこのような場合に適用されます。ショートパイプモデルのLSPのために、出口でのTTLはとか、PHPずに同じ値を持っています。
In conclusion, GTSM checks are possible for IP tunneled over Pipe model LSPs, but not for IP tunneled over Uniform model LSPs. Additionally, for all tunneling modes, if the LSP termination router needs to forward the protocol packet to a directly connected protocol peer, it is not possible to deliver the protocol packet to the protocol peer with a TTL of 255. If the packet is further forwarded, the outgoing TTL (oTTL) is calculated by decrementing iTTL by one.
結論として、GTSMチェックはパイプモデルのLSP上でトンネリングされたIPのために可能ですが、IPのための統一モデルのLSP上でトンネリングされません。 LSP終端ルータが直接接続されたプロトコルピアにプロトコル・パケットを転送する必要がある場合、パケットをさらに転送される場合に加えて、すべてのトンネリングモードのために、255のTTLとプロトコルピアにプロトコル・パケットを配信することは不可能です、発信TTL（オットル）は一つによってITTLをデクリメントすることによって計算されます。
As described in Section 2, an attacker directly connected to one interface can disturb a GTSM-protected session on the same or another interface (by spoofing a GTSM peer's address) unless ingress filtering has been applied on the connecting interface. As a result, interfaces that do not include such protection need to be trusted not to originate attacks on the router.
第2節で説明したようにイングレスフィルタリングは、接続インターフェイスに適用されていない限り、直接的に一つのインタフェースに接続されている攻撃者は、同じまたは（GTSMピアのアドレスをスプーフィングすることにより）別のインターフェイス上のGTSM、保護されたセッションを妨害することができます。その結果、このような保護が含まれていないインターフェイスは、ルータへの攻撃を発信しないように、信頼する必要があります。
As mentioned, fragmentation may restrict the amount of information available for classification. Since non-initial IP fragments do not contain Layer 4 information, it is highly likely that they cannot be associated with a registered GTSM-enabled session. Following the receiving protocol procedures described in Section 3, non-initial IP fragments would likely be classified with Unknown trustworthiness. And since the IP packet would need to be reassembled in order to be processed, the end result is that the initial-fragment of a GTSM-enabled session effectively receives the treatment of an Unknown-trustworthiness packet, and the complete reassembled packet receives the aggregate of the Unknowns.
上述したように、断片化は、分類のために利用可能な情報の量を制限することができます。非初期IPフラグメントは、レイヤ4の情報が含まれていないので、彼らが登録GTSM対応のセッションに関連付けることができない可能性が高いです。第3節で説明した受信プロトコル手順に従って、非初期IPフラグメントは、おそらく信頼性が不明で分類されます。 IPパケットを処理するために再組立される必要があるので、最終的な結果は、GTSM対応のセッションの最初のフラグメントが効果的に不明-信頼パケットの治療を受け、完全な再構成されたパケットは、集計を受信することです未知の。
In principle, an implementation could remember the TTL of all received fragments. Then when reassembling the packet, verify that the TTL of all fragments match the required value for an associated GTSM-enabled session. In the likely common case that the implementation does not do this check on all fragments, then it is possible for a legitimate first fragment (which passes the GTSM check) to be combined with spoofed non-initial fragments, implying that the integrity of the received packet is unknown and unprotected. If this check is performed on all fragments at reassembly, and some fragment does not pass the GTSM check for a GTSM-enabled session, the reassembled packet is categorized as a Dangerous-trustworthiness packet and receives the corresponding treatment.
原則として、実装は受信したすべてのフラグメントのTTLを覚えることができます。パケットを再組み立てときに、すべての断片のTTLが、関連するGTSM対応セッションに必要な値と一致することを検証します。実装はすべてのフラグメントに対してこのチェックを行っていない可能性が高い一般的なケースでは、それはそれを受信したの完全性を意味する、偽装された以外のフラグメントと組み合わされる（GTSMチェックを通過する）正当な最初のフラグメントのために可能ですパケットは不明と保護されていません。このチェックを再構築時にすべてのフラグメント上で実行され、そしていくつかの断片がGTSM対応のセッションのためのGTSMチェックに合格しない場合は、再構成されたパケットは、危険な、信頼性のパケットとして分類し、対応する治療を受けています。
Further, reassembly requires to wait for all the fragments and therefore likely invalidates or weakens the fifth assumption presented in Section 2: it may not be possible to classify non-initial fragments before going through a scarce resource in the system, when fragments need to be buffered for reassembly and later processed by a CPU. That is, when classification cannot be done with the required granularity, non-initial fragments of GTSM-enabled session packets would not use different resource pools.
さらに、再組み立ては、すべてのフラグメントを待つ必要があり、したがって、おそらく第2節で提示第五の仮定を無効にするか、弱める：断片がする必要がある場合には、システム内の希少資源を通過する前に、非初期フラグメントを分類することが可能ではないかもしれません再構築のためのバッファリングされ、以降のCPUによって処理されます。分類が異なるリソースプールを使用することはありませんGTSM対応のセッションパケットの必要な細かさ、非初期フラグメントで行うことができない場合には、あります。
Consequently, to get practical protection from fragment attacks, operators may need to rate-limit or discard all received fragments. As such, it is highly RECOMMENDED for GTSM-protected protocols to avoid fragmentation and reassembly by manual MTU tuning, using adaptive measures such as Path MTU Discovery (PMTUD), or any other available method [RFC1191], [RFC1981], or [RFC4821].
その結果、フラグメント攻撃から実用的な保護を得るために、事業者は制限をレートまたは受信したすべての断片を破棄する必要があるかもしれません。そのようなものとして、それは非常にそのようなパスMTUディスカバリ（PMTUD）、または任意の他の利用可能な方法[RFC1191]、[RFC1981]、または[RFC4821などの適応策を使用して、手動MTUチューニングによってフラグメンテーションおよび再組み立てを回避するGTSM保護プロトコルに推奨されます]。
GTSM could possibly offer some small, though difficult to quantify, degree of protection when used with multi-hop protocol sessions (see Appendix A). In order to avoid having to quantify the degree of protection and the resulting applicability of multi-hop, we only describe the single-hop case because its security properties are clearer.
マルチホッププロトコルセッションで使用する場合は難しい（付録Aを参照）、保護の程度を定量化するのにGTSMはおそらく、いくつかの小さなを提供することができます。そのセキュリティプロパティが明確であるため、保護の程度およびマルチホップの結果の適用性を定量化することを避けるために、我々は、単一ホップのケースを説明します。
GTSM is only applicable to environments with inherently limited topologies (and is most effective in those cases where protocol peers are directly connected). In particular, its application should be limited to those cases in which protocol peers are directly connected.
GTSMは、本質的に限られたトポロジーを持つ環境にのみ適用され（及びプロトコルピアが直接接続されているような場合に最も有効です）。具体的には、そのアプリケーションプロトコルピアが直接接続されているような場合に限定されるべきです。
GTSM will not protect against attackers who are as close to the protected station as its legitimate peer. For example, if the legitimate peer is one hop away, GTSM will not protect from attacks from directly connected devices on the same interface (see Section 2.2 for more).
GTSMは、その正当なピアとして保護された駅に近いある攻撃を防ぐことはできません。正規ピアが1ホップ離れている場合、例えば、GTSMは同じインターフェース（複数はセクション2.2を参照）に直接接続されたデバイスからの攻撃から保護しないであろう。
Experimentation on GTSM's applicability and security properties is needed in multi-hop scenarios. The multi-hop scenarios where GTSM might be applicable is expected to have the following characteristics: the topology between peers is fairly static and well-known, and in which the intervening network (between the peers) is trusted.
GTSMの適用性とセキュリティの特性に関する実験は、マルチホップのシナリオで必要とされます。 GTSMが適用かもしれないマルチホップシナリオは以下の特性を有することが期待される：ピアとの間のトポロジはかなり静的で周知であり、そしてここで（ピア間）に介在するネットワークが信頼されています。
RFC 3682 [RFC3682] did not specify how to handle "related messages" (ICMP errors). This specification mandates setting and verifying TTL=255 of those as well as the main protocol packets.
RFC 3682 [RFC3682]は、「関連メッセージ」（ICMPエラー）を処理する方法を指定しませんでした。 TTL =もの並びに主プロトコルパケット255を設定し、検証これは仕様義務。
Setting TTL=255 in related messages does not cause issues for RFC 3682 implementations.
関連メッセージにTTL = 255を設定すると、RFC 3682個の実装のための問題を引き起こすことはありません。
Requiring TTL=255 in related messages may have impact with RFC 3682 implementations, depending on which default TTL the implementation uses for originated packets; some implementations are known to use 255, while 64 or other values are also used. Related messages from the latter category of RFC 3682 implementations would be classified
関連メッセージにTTL = 255を必要とするどのデフォルトに応じて、RFC 3682個の実装との影響を有することができるTTL実装発信パケットに使用します。いくつかの実施態様は、64のまたは他の値も使用されている間、255を使用することが知られています。 RFC 3682個の実装の後者のカテゴリから関連のメッセージが分類されます
as Dangerous and treated as described in Section 3. This is not believed to be a significant problem because protocols do not depend on related messages (e.g., typically having a protocol exchange for closing the session instead of doing a TCP-RST), and indeed the delivery of related messages is not reliable. As such, related messages typically provide an optimization to shorten a protocol keepalive timeout. Regardless of these issues, given that related messages provide a significant attack vector to e.g., reset protocol sessions, making this further restriction seems sensible.
危険と治療第3節で説明したようにプロトコルは実際に（一般的にセッションを閉じる代わりにTCP-RSTを行うためのプロトコル交換を持つ、など）、および関連メッセージに依存しないため、これは重要な問題ではないと考えられます関連するメッセージの配信が信頼できるものではありません。そのため、関連するメッセージは、通常、プロトコルキープアライブタイムアウトを短くする最適化を提供します。関連するメッセージが、例えばこれをさらに制限が賢明なようだ作り、プロトコルセッションをリセットするための重要な攻撃手段を提供することを関係なく、これらの問題の、与えられました。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[RFC3392]チャンドラ、R.及びJ.スカダー、 "BGP-4との機能広告"、RFC 3392、2002年11月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443] Agarwalさん、P.とB. Akyol、 "（MPLS）ネットワークのマルチプロトコルラベルスイッチングにおける生存時間（TTL）処理"、RFC 3443、2003年1月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and BITW' on int-area list, Message-ID: <Pine.LNX.4.64.0606020830220.12705@netcore.fi>", June 2006, <http://www1.ietf.org/mail-archive/web/ int-area/current/msg00267.html>.
[BITW] "スレッド： 'で-IP IP-、TTLのデクリメント転送とBITW' INT-領域リストに、メッセージID：<Pine.LNX.4.64.0606020830220.12705@netcore.fi>"、2006年6月、<HTTP ：//www1.ietf.org/mail-archive/web/ INT-エリア/現在/ msg00267.html>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981、1996年8月 "IPバージョン6のパスMTUディスカバリー"。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3682]ギル、V.、Heasley、J.、およびD.マイヤー、 "一般TTLセキュリティメカニズム（GTSM）"、RFC 3682、2004年2月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272]マーフィー、S.、 "BGPセキュリティの脆弱性分析"、RFC 4272、2006年1月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
Appendix A. Multi-Hop GTSM
付録A.マルチホップGTSM
NOTE: This is a non-normative part of the specification.
注：これは仕様の非標準的な部分です。
The main applicability of GTSM is for directly connected peers. GTSM could be used for non-directly connected sessions as well, where the recipient would check that the TTL is within a configured number of hops from 255 (e.g., check that packets have 254 or 255). As such deployment is expected to have a more limited applicability and different security implications, it is not specified in this document.
GTSMの主な適用は、直接接続されたピアのためです。受信者がTTLが255からホップの構成数の範囲内であることを確認する場所GTSM（例えば、パケット254または255を持っていることを確認してください）、ならびに、非直接接続されたセッションのために使用することができます。こうした展開は、より限定された適用可能と異なるセキュリティへの影響を持つことが期待されているように、この文書で指定されていません。
Appendix B. Changes Since
付録B.変化するため
o Bring the work on the Standards Track (RFC 3682 was Experimental).
O標準化過程（RFC 3682は実験的だった）の作品を持参してください。
o New text on GTSM applicability and use in new and existing protocols.
GTSMの適用性に関する新しいテキストOと、新規および既存のプロトコルで使用しています。
o Restrict the scope to not specify multi-hop scenarios.
Oマルチホップシナリオを指定しないようにスコープを制限します。
o Explicitly require that related messages (ICMP errors) must also be sent and checked to have TTL=255. See Section 6.1 for discussion on backwards compatibility.
O明示的に関連するメッセージ（ICMPエラー）も送信され、TTL = 255を持つことが確認されなければならないことを要求しています。後方互換性に関する議論については、セクション6.1を参照してください。
o Clarifications relating to fragmentation, security with tunneling, and implications of ingress filtering.
Oトンネリングで断片化、セキュリティに関する明確化、およびイングレスフィルタリングの意味。
o A significant number of editorial improvements and clarifications.
O社説改善と明確化のかなりの数。
Authors' Addresses
著者のアドレス
Vijay Gill EMail: vijay@umbc.edu
ビジェイ・ギルEメール：vijay@umbc.edu
John Heasley EMail: heas@shrubbery.net
ジョンHeasley Eメール：heas@shrubbery.net
David Meyer EMail: dmm@1-4-5.net
デビッド・マイヤー電子メール：dmm@1-4-5.net
Pekka Savola (editor) Espoo Finland EMail: psavola@funet.fi
ペッカSavola（編集）エスポーフィンランドメール：psavola@funet.fi
Carlos Pignataro EMail: cpignata@cisco.com
カルロスPignataro Eメール：cpignata@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。