[要約] 要約：RFC 3443は、MPLSネットワークでのTTL（Time To Live）処理に関するガイドラインを提供しています。 目的：このRFCの目的は、MPLSネットワークでのTTLの適切な処理方法を定義し、ネットワークのパフォーマンスとセキュリティを向上させることです。
Network Working Group P. Agarwal
Request for Comments: 3443 Brocade
Updates: 3032 B. Akyol
Category: Standards Track Cisco Systems
January 2003
Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks
マルチプロトコルラベルスイッチング（MPLS）ネットワークでのライブ（TTL）処理
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks.
このドキュメントでは、階層的マルチプロトコルラベルスイッチング（MPLS）ネットワークでのライブ（TTL）処理について説明し、MPLSラベルスイッチパスのTTL透明操作モードを正式化する必要性によって動機付けられています。RFC 3032、「MPLSラベルスタックエンコード」を更新します。パイプと均一なモデルモデルの両方の階層トンネルの両方のTTL処理は、「プッシュ」と「POP」ケースの両方の例で指定されています。このドキュメントは、RFC 3270、「MPLSサポートの差別化サービスのサポート」を補完し、階層MPLSネットワークでTTL処理でそのドキュメントで導入された用語を結び付けます。
Conventions used in this document
このドキュメントで使用されている規則
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC-2119]に記載されているように解釈される。
This document describes Time To Live (TTL) processing in hierarchical MPLS networks. We believe that this document adds details that have not been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods presented in this document complement [MPLS-DS].
このドキュメントでは、階層的なMPLSネットワークでのライブ（TTL）処理について説明します。このドキュメントは、[MPLS-ARCH、MPLS-ENCAPS]で対処されていない詳細を追加し、このドキュメント補完[MPLS-DS]に示されている方法が追加されていると考えています。
In particular, a new mode of operation (referred to as the Pipe Model) is introduced to support the practice of configuring MPLS LSPs such that packets transiting the LSP see the tunnel as a single hop regardless of the number of intermediary label switch routers (LSR). The Pipe Model for TTL is currently being used in multiple networks and is provided as an option configurable by the network operator by several vendors.
特に、LSPを通過するパケットが中間ラベルスイッチルーターの数に関係なくトンネルを単一のホップと見なすように、MPLS LSPの構成の実践をサポートするために、新しい動作モード（パイプモデルと呼ばれる）が導入されています（LSR）。TTLのパイプモデルは現在、複数のネットワークで使用されており、いくつかのベンダーがネットワークオペレーターが構成できるオプションとして提供されています。
This document formalizes the TTL processing in MPLS networks and ties it with the terminology introduced in [MPLS-DS].
このドキュメントは、MPLSネットワークのTTL処理を形式化し、[MPLS-DS]で導入された用語と結び付けます。
a) [MPLS-ENCAPS] only covers the Uniform Model and does NOT address the Pipe Model or the Short Pipe Model. This document addresses these two models and for completeness will also address the Uniform Model.
a) [MPLS-ENCAPS]は均一なモデルのみをカバーし、パイプモデルまたは短いパイプモデルに対処しません。このドキュメントは、これら2つのモデルに対応し、完全性のために均一なモデルにも対処されます。
b) [MPLS-ENCAPS] does not cover hierarchical LSPs. This document addresses this issue.
b) [MPLS-ENCAPS]は階層LSPをカバーしていません。このドキュメントはこの問題に対処します。
c) [MPLS-ENCAPS] does not define TTL processing in the presence of Penultimate Hop Popping (PHP). This document addresses this issue.
c) [MPLS-ENCAPS]は、最後から2番目のホップポップ（PHP）の存在下でTTL処理を定義しません。このドキュメントはこの問題に対処します。
As defined in [MPLS-ENCAPS], MPLS packets use a MPLS shim header that indicates the following information about a packet:
[MPLS-ENCAPS]で定義されているように、MPLSパケットは、パケットに関する次の情報を示すMPLSシムヘッダーを使用します。
a) MPLS Label (20 bits) b) TTL (8 bits) c) Bottom of stack (1 bit) d) Experimental bits (3 bits)
a) MPLSラベル（20ビット）B）TTL（8ビット）C）スタックの底（1ビット）D）実験ビット（3ビット）
The experimental bits were later redefined in [MPLS-DS] to indicate the scheduling and shaping behavior that could be associated with an MPLS packet.
実験ビットは後に[MPLS-DS]で再定義されて、MPLSパケットに関連付けられる可能性のあるスケジューリングおよび形成動作を示しました。
[MPLS-DS] also defined two models for MPLS tunnel operation: Pipe and Uniform Models. In the Pipe Model, a MPLS network acts like a circuit when MPLS packets traverse the network such that only the LSP ingress and egress points are visible to nodes that are outside the tunnel. A Short variation of the Pipe Model is also defined in [MPLS-DS] to differentiate between different egress forwarding and QoS treatments. On the other hand, the Uniform Model makes all the nodes that a LSP traverses visible to nodes outside the tunnel. We will extend the Pipe and Uniform Models to include TTL processing in the following sections. Furthermore, TTL processing, when performing PHP, is also described in this document. For a detailed description of Pipe and Uniform Models, please see [MPLS-DS].
[MPLS-DS]は、MPLSトンネル操作の2つのモデル、パイプモデルと均一モデルも定義しました。パイプモデルでは、MPLSパケットがネットワークを通過すると、MPLSネットワークが回路のように機能し、LSPの侵入ポイントと出口点のみがトンネルの外側のノードに表示されます。パイプモデルの短いバリエーションも[MPLS-DS]で定義されており、異なる出力転送とQOS治療を区別します。一方、均一なモデルは、LSPがトンネルの外側のノードに見えるすべてのノードを作成します。パイプと均一なモデルを拡張して、次のセクションにTTL処理を含めます。さらに、PHPを実行する場合、TTL処理についてもこのドキュメントで説明します。パイプモデルと均一なモデルの詳細な説明については、[MPLS-DS]を参照してください。
TTL processing in MPLS networks can be broken down into two logical blocks: (i) the incoming TTL determination to take into account any tunnel egress due to MPLS Pop operations; (ii) packet processing of (possibly) exposed packets and outgoing TTLs.
MPLSネットワークでのTTL処理は、2つの論理ブロックに分解できます。（i）MPLS POP操作によるトンネル出力を考慮する登録TTLの決定。（ii）（おそらく）露出したパケットと発信TTLのパケット処理。
We also note here that signaling the LSP type (Pipe, Short Pipe or Uniform Model) is out of the scope of this document, and that is also not addressed in the current versions of the label distribution protocols, e.g. LDP [MPLS-LDP] and RSVP-TE [MPLS-RSVP]. Currently, the LSP type is configured by the network operator manually by means of either a command line or network management interface.
また、LSPタイプ（パイプ、ショートパイプ、または均一モデル）を信号することは、このドキュメントの範囲外であり、ラベル分布プロトコルの現在のバージョンでも対処されていないことに注意してください。LDP [MPLS-LDP]およびRSVP-TE [MPLS-RSVP]。現在、LSPタイプは、コマンドラインまたはネットワーク管理インターフェイスのいずれかによって、ネットワーク演算子によって手動で構成されています。
iTTL: The TTL value to use as the incoming TTL. No checks are performed on the iTTL.
ITTL：着信TTLとして使用するTTL値。ITTLではチェックは実行されません。
oTTL: This is the TTL value used as the outgoing TTL value (see section 3.5 for exception). It is always (iTTL - 1) unless otherwise stated.
OTTL：これは、発信TTL値として使用されるTTL値です（例外についてはセクション3.5を参照）。特に明記しない限り、常に（ittl -1）です。
oTTL Check: Check if oTTL is greater than 0. If the oTTL Check is false, then the packet is not forwarded. Note that the oTTL check is performed only if any outgoing TTL (either IP or MPLS) is set to oTTL (see section 3.5 for exception).
OTTLチェック：OTTLが0を超えるかどうかを確認します。OTTLチェックが偽の場合、パケットは転送されません。OTTLチェックは、発信TTL（IPまたはMPLSのいずれか）がOTTLに設定されている場合にのみ実行されることに注意してください（例外についてはセクション3.5を参照）。
This section describes the TTL processing for LSPs conforming to each of the 3 models (Uniform, Short Pipe and Pipe) in the presence/absence of PHP (where applicable).
このセクションでは、PHPの存在/存在下（該当する場合）の3つのモデル（均一、ショートパイプ、パイプ）のそれぞれに準拠するLSPのTTL処理について説明します。
(consistent with [MPLS-ENCAPS]):
（[MPLS-ENCAPS]と一致）：
========== LSP =============================>
+--Swap--(n-2)-...-swap--(n-i)---+
/ (outer header) \
(n-1) (n-i)
/ \
>--(n)--Push...............(x).....................Pop--(n-i-1)->
(I) (inner header) (E or P)
(n) represents the TTL value in the corresponding header (x) represents non-meaningful TTL information (I) represents the LSP ingress node (P) represents the LSP penultimate node (E) represents the LSP Egress node
(n) 対応するヘッダー（x）のTTL値を表します。
This picture shows TTL processing for a Uniform Model MPLS LSP. Note that the inner and outer TTLs of the packets are synchronized at tunnel ingress and egress.
この写真は、均一なモデルMPLS LSPのTTL処理を示しています。パケットの内側と外側のTTLは、トンネルイングレスと出口で同期されていることに注意してください。
========== LSP =============================>
+--Swap--(N-1)-...-swap--(N-i)-----+
/ (outer header) \
(N) (N-i)
/ \
>--(n)--Push...............(n-1).....................Pop--(n-2)->
(I) (inner header) (E)
(N) represents the TTL value (may have no relationship to n) (n) represents the tunneled TTL value in the encapsulated header (I) represents the LSP ingress node (E) represents the LSP Egress node
（n）はTTL値を表します（nと関係がない場合があります）（n）カプセル化されたヘッダーのトンネルされたTTL値を表します（i）はLSP侵入ノード（e）を表します。
The Short Pipe Model was introduced in [MPLS-DS]. In the Short Pipe Model, the forwarding treatment at the egress LSR is based on the tunneled packet, as opposed to the encapsulating packet.
短いパイプモデルは[MPLS-DS]で導入されました。短いパイプモデルでは、出口LSRでの転送処理は、カプセル化パケットとは対照的に、トンネルパケットに基づいています。
3.2.2. TTL Processing for Short Pipe Model with PHP:
3.2.2. PHPを使用した短いパイプモデルのTTL処理：
========== LSP =====================================>
+-Swap-(N-1)-...-swap-(N-i)-+
/ (outer header) \
(N) (N-i)
/ \
>--(n)--Push.............(n-1)............Pop-(n-1)-Decr.-(n-2)->
(I) (inner header) (P) (E)
(N) represents the TTL value (may have no relationship to n) (n) represents the tunneled TTL value in the encapsulated header (I) represents the LSP ingress node (P) represents the LSP penultimate node (E) represents the LSP egress node.
（n）はTTL値を表します（nと関係がない場合がある場合）ノード。
Since the label has already been popped by the LSP's penultimate node, the LSP egress node just decrements the header TTL.
ラベルはすでにLSPの最後から2番目のノードによってポップされているため、LSP EgressノードはヘッダーTTLを減少させるだけです。
Also note that at the end of the Short Pipe Model LSP, the TTL of the tunneled packet has been decremented by two, with or without PHP.
また、短いパイプモデルLSPの終わりに、トンネルパケットのTTLは、PHPの有無にかかわらず、2人で減少していることに注意してください。
3.3. TTL Processing for Pipe Model LSPs (without PHP only):
3.3. パイプモデルLSPのTTL処理（PHPのみ）：
========== LSP =============================>
+--Swap--(N-1)-...-swap--(N-i)-----+
/ (outer header) \
(N) (N-i)
/ \
>--(n)--Push...............(n-1)....................Pop--(n-2)->
(I) (inner header) (E)
(N) represents the TTL value (may have no relationship to n) (n) represents the tunneled TTL value in the encapsulated header (I) represents the LSP ingress node (E) represents the LSP Egress node
（n）はTTL値を表します（nと関係がない場合があります）（n）カプセル化されたヘッダーのトンネルされたTTL値を表します（i）はLSP侵入ノード（e）を表します。
From the TTL perspective, the treatment for a Pipe Model LSP is identical to the Short Pipe Model without PHP.
TTLの観点から見ると、パイプモデルLSPの処理は、PHPのない短いパイプモデルと同一です。
If the incoming packet is an IP packet, then the iTTL is the TTL value of the incoming IP packet.
着信パケットがIPパケットの場合、ITTLは着信IPパケットのTTL値です。
If the incoming packet is an MPLS packet and we are performing a Push/Swap/PHP, then the iTTL is the TTL of the topmost incoming label.
着信パケットがMPLSパケットであり、プッシュ/スワップ/PHPを実行している場合、ITTLは最上位の着信ラベルのTTLです。
If the incoming packet is an MPLS packet and we are performing a Pop (tunnel termination), the iTTL is based on the tunnel type (Pipe or Uniform) of the LSP that was popped. If the popped label belonged to a Pipe Model LSP, then the iTTL is the value of the TTL field of the header, exposed after the label was popped (note that for the purpose of this document, the exposed header may be either an IP header or an MPLS label). If the popped label belonged to a Uniform Model LSP, then the iTTL is equal to the TTL of the popped label. If multiple Pop operations are performed sequentially, then the procedure given above is repeated with one exception: the iTTL computed during the previous Pop is used as the TTL of subsequent labels being popped; i.e. the TTL contained in the subsequent label is essentially ignored and replaced with the iTTL computed during the previous pop.
着信パケットがMPLSパケットであり、POP（トンネル終了）を実行している場合、ITTLはポップされたLSPのトンネルタイプ（パイプまたは均一）に基づいています。ポップされたラベルがパイプモデルLSPに属している場合、ITTLはヘッダーのTTLフィールドの値であり、ラベルがポップされた後に露出します（このドキュメントの目的のために、露出したヘッダーはIPヘッダーである可能性があることに注意してくださいまたはMPLSラベル）。ポップされたラベルが均一なモデルLSPに属している場合、ITTLはポップされたラベルのTTLに等しくなります。複数のPOP操作が順番に実行される場合、上記の手順は1つの例外で繰り返されます。前のPOPで計算されたITTLは、後続のラベルのTTLとして使用されます。つまり、後続のラベルに含まれるTTLは本質的に無視され、前のPOPで計算されたITTLに置き換えられます。
After the iTTL computation is performed, the oTTL check is performed. If the oTTL check succeeds, then the outgoing TTL of the (labeled/unlabeled) packet is calculated and packet headers are updated as defined below.
ITTL計算が実行された後、OTTLチェックが実行されます。OTTL Checkが成功した場合、（ラベル/ラベル付き）パケットの発信TTLが計算され、以下に定義されているようにパケットヘッダーが更新されます。
If the packet was routed as an IP packet, the TTL value of the IP packet is set to oTTL (iTTL - 1). The TTL value(s) for any pushed label(s) is determined as described in section 3.6.
パケットがIPパケットとしてルーティングされた場合、IPパケットのTTL値はOTTL（ITTL -1）に設定されます。プッシュされたラベルのTTL値は、セクション3.6で説明されているように決定されます。
For packets that are routed as MPLS, we have four cases:
MPLSとしてルーティングされるパケットの場合、4つのケースがあります。
1) Swap-only: The routed label is swapped with another label and the TTL field of the outgoing label is set to oTTL.
1) スワップのみ：ルーティングされたラベルは別のラベルと交換され、発信ラベルのTTLフィールドはOTTLに設定されます。
2) Swap followed by a Push: The swapped operation is performed as described in (1). The TTL value(s) of any pushed label(s) is determined as described in section 3.6.
2) スワップに続いてプッシュ：（1）に記載されているように、交換操作が実行されます。プッシュされたラベルのTTL値は、セクション3.6で説明されているように決定されます。
3) Penultimate Hop Pop (PHP): The routed label is popped. The oTTL check should be performed irrespective of whether the oTTL is used to update the TTL field of the outgoing header. If the PHPed label belonged to a Short Pipe Model LSP, then the TTL field of the PHP exposed header is neither checked nor updated. If the PHPed label was a Uniform Model LSP, then the TTL field of the PHP exposed header is set to the oTTL. The TTL value(s) of additional labels are determined as described in section 3.6
3) Penultimate Hop Pop（PHP）：ルーティングされたラベルがポップされます。OTTLチェックは、OTTLが発信ヘッダーのTTLフィールドを更新するために使用されるかどうかに関係なく実行する必要があります。PHPEDラベルが短いパイプモデルLSPに属している場合、PHP露出ヘッダーのTTLフィールドはチェックも更新もありません。PHPedラベルが均一なモデルLSPである場合、PHP露出ヘッダーのTTLフィールドがOTTLに設定されます。追加のラベルのTTL値は、セクション3.6で説明されているように決定されます
4) Pop: The pop operation happens before routing and hence it is not considered here.
4) POP：ポップ操作はルーティング前に行われるため、ここでは考慮されません。
For each pushed Uniform Model label, the TTL is copied from the label/IP-packet immediately underneath it.
プッシュされた均一なモデルラベルごとに、TTLはそのすぐ下のラベル/IPパケットからコピーされます。
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に設定されます。
1) Although iTTL can be decremented by a value larger than 1 while it is being updated or oTTL is being determined, this feature should be only used for compensating for network nodes that are not capable of decrementing TTL values.
1) ITTLは、更新されている間、またはOTTLが決定されている間に1より大きな値によって減少することができますが、この機能は、TTL値を減らすことができないネットワークノードを補正するためにのみ使用する必要があります。
2) Whenever iTTL is decremented, the implementer must make sure that the value does not become negative.
2) ITTLが減少するたびに、実装者は値が負にならないことを確認する必要があります。
3) In the Short Pipe Model with PHP enabled, the TTL of the tunneled packet is unchanged after the PHP operation.
3) PHPが有効になっている短いパイプモデルでは、PHP操作後にトンネルパケットのTTLが変更されていません。
This Internet Document describes how the TTL field can be processed in an MPLS network. We clarified the various methods that are applied in the presence of hierarchical tunnels and completed the integration of Pipe and Uniform Models with TTL processing.
このインターネットドキュメントでは、TTLフィールドをMPLSネットワークでどのように処理できるかについて説明します。階層的なトンネルの存在下で適用されるさまざまな方法を明確にし、TTL処理を使用したパイプモデルと均一モデルの統合を完了しました。
This document does not add any new security issues other than the ones defined in [MPLS-ENCAPS, MPLS-DS]. In particular, the document does not define a new protocol or expand an existing one and does not introduce security problems into the existing protocols. The authors believe that clarification of TTL handling in MPLS networks benefits service providers and their customers since troubleshooting is simplified.
このドキュメントでは、[MPLS-Encaps、MPLS-DS]で定義されているもの以外の新しいセキュリティ問題は追加されません。特に、ドキュメントは新しいプロトコルを定義したり、既存のプロトコルを展開したりしず、既存のプロトコルにセキュリティの問題を導入しません。著者は、トラブルシューティングが簡素化されて以来、MPLSネットワークでのTTLハンドリングの明確化にサービスプロバイダーとその顧客に利益をもたらすと考えています。
[RFC-2119] Bradner, S. "Key words for use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner、S。
[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-ARCH] Rosen、E.、Viswanathan、A。and R. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、2001年1月。
[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-ENCAPS] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「MPLS Label Stack Encoding」、RFC 3032、1月2001年。
[MPLS-DS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[MPLS-DS] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。and J. Heinanen、 "Multi-Protocol Label差別化されたサービスの切り替え（MPLS）サポート」、RFC 3270、2002年5月。
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[MPLS-LDP] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。and B. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[MPLS-RSVP] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[MPLS-RSVP] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
The authors would like to thank the members of the MPLS working group for their feedback. We would especially like to thank Shahram Davari and Loa Andersson for their careful review of the document and their comments.
著者は、MPLSワーキンググループのメンバーのフィードバックに感謝したいと思います。特に、Shahram DavariとLoa Anderssonに、ドキュメントとコメントを慎重に確認してくれたことに感謝します。
Puneet Agarwal Brocade Communications Systems, Inc. 1745 Technology Drive San Jose, CA 95110
Puneet Agarwal Brocade Communications Systems、Inc。1745 Technology Drive San Jose、CA 95110
EMail: puneet@acm.org
Bora Akyol Cisco Systems 170 W. Tasman Drive San Jose, CA 95134
Bora Akyol Cisco Systems 170 W. Tasman Drive San Jose、CA 95134
EMail: bora@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。