RFC5308 日本語訳

Network Working Group                                           C. Hopps
Request for Comments: 5308                                 Cisco Systems
Category: Standards Track                                   October 2008

コメントを求めるワーキンググループC.ホップスの要求をネットワークでつないでください: 5308年のシスコシステムズカテゴリ: 標準化過程2008年10月

                        Routing IPv6 with IS-IS

IPv6を発送する、-

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This document specifies a method for exchanging IPv6 routing
   information using the IS-IS routing protocol.  The described method
   utilizes two new TLVs: a reachability TLV and an interface address
   TLV to distribute the necessary IPv6 information throughout a routing
   domain.  Using this method, one can route IPv6 along with IPv4 and
   OSI using a single intra-domain routing protocol.

このドキュメントがIPv6ルーティング情報使用を交換するためのメソッドを指定する、-、ルーティング・プロトコル。 説明されたメソッドは2新しいTLVsを利用します: TLVとインタフェースが必要なIPv6情報を経路ドメインに分配するためにTLVであると扱う可到達性。 このメソッドを使用して、1つは、ただ一つのイントラドメインルーティング・プロトコルを使用することでIPv4とOSIに伴うIPv6を発送できます。

1.  Overview

1. 概要

   IS-IS is an extendible intra-domain routing protocol.  Each router in
   the routing domain issues an Link State Protocol Data Unit (LSP) that
   contains information pertaining to that router.  The LSP contains
   typed variable-length data, often referred to as TLVs (type-length-
   values).  We extend the protocol with two new TLVs to carry
   information required to perform IPv6 routing.

-、拡張可能なイントラドメインルーティング・プロトコルはそうです。 経路ドメインの各ルータはそのルータに関係する情報を含むLink州プロトコルData Unit(LSP)を発行します。 LSPはしばしばTLVs(タイプ長さ値)と呼ばれたタイプされた可変長のデータを含んでいます。 私たちは、IPv6ルーティングを実行するのに必要である情報を運ぶために2新しいTLVsと共にプロトコルを広げます。

   In [RFC1195], a method is described to route both OSI and IPv4.  We
   utilize this same method with some minor changes to allow for IPv6.
   To do so, we must define two new TLVs, namely "IPv6 Reachability" and
   "IPv6 Interface Address", and a new IPv6 protocol identifier.  In our
   new TLVs, we utilize the extended metrics and up/down semantics of
   [RFC5305].

[RFC1195]では、メソッドは、OSIとIPv4の両方を発送するために説明されます。 私たちは、IPv6を考慮するのにいくつかのマイナーチェンジがあるこの同じメソッドを利用します。 そうするために、私たちは2新しいTLVs、すなわち、「IPv6の可到達性」、「IPv6インターフェース・アドレス」、および新しいIPv6プロトコル識別子を定義しなければなりません。 新しいTLVsでは、私たちは、拡張測定基準を利用して、[RFC5305]の/下に意味論にそうします。

1.1.  Requirements Language

1.1. 要件言語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?

Hopps                       Standards Track                     [Page 1]

RFC 5308                Routing IPv6 with IS-IS             October 2008

ホップスStandardsがRFC5308ルート設定IPv6を追跡する、[1ページ]-、2008年10月

2.  IPv6 Reachability TLV

2. IPv6可到達性TLV

   The "IPv6 Reachability" TLV is TLV type 236 (0xEC).

「IPv6の可到達性」TLVはTLVタイプ236です(0xEC)。

   [RFC1195] defines two Reachability TLVs, "IP Internal Reachability
   Information" and "IP External Reachability Information".  We provide
   the equivalent IPv6 data with the "IPv6 Reachability" TLV and an
   "external" bit.

[RFC1195]は2Reachability TLVs、「IPの内部の可到達性情報」、および「IPの外部の可到達性情報」を定義します。 私たちは「IPv6の可到達性」TLVと「外部」のビットを同等なIPv6データに提供します。

   The "IPv6 Reachability" TLV describes network reachability through
   the specification of a routing prefix, metric information, a bit to
   indicate if the prefix is being advertised down from a higher level,
   a bit to indicate if the prefix is being distributed from another
   routing protocol, and OPTIONALLY the existence of Sub-TLVs to allow
   for later extension.  This data is represented by the following
   structure:

「IPv6の可到達性」TLVは接頭語が、より高いレベルから広告を出しているかどうかを少し示して、少し接頭語が別のルーティング・プロトコルから分配されているかどうかを示すためにルーティング接頭語、メートル法の情報の仕様でネットワークの可到達性について説明します、そして、OPTIONALLYは後の拡大のために許容するSub-TLVsの存在について説明します。 このデータは以下の構造によって表されます:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 236   |    Length     |          Metric ..            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          .. Metric            |U|X|S| Reserve |  Prefix Len   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Prefix ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sub-TLV Len(*) | Sub-TLVs(*) ...
   * - if present

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =236をタイプしてください。| 長さ| メートル法。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .. メートル法|U|X|S| 蓄え| レンを前に置いてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 前に置きます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |サブTLVレン(*)| サブTLVs(*)… * - 現在

   U - up/down bit
   X - external original bit
   S - subtlv present bit

U--/下にビットX--外部の元のビットS--subtlv現在のビットに

   The above IPv6 Reachability TLV MAY appear any number of times
   (including none) within an LSP.  Link-local prefixes MUST NOT be
   advertised using this TLV.

上のIPv6 Reachability TLVはLSPの中でどんな回数(なにも含んでいない)にも見えるかもしれません。 このTLVを使用して、リンクローカルの接頭語の広告を出してはいけません。

   As is described in [RFC5305]: "The up/down bit SHALL be set to 0 when
   a prefix is first injected into IS-IS.  If a prefix is advertised
   from a higher level to a lower level (e.g. level 2 to level 1), the
   bit SHALL be set to 1, indicating that the prefix has traveled down
   the hierarchy.  Prefixes that have the up/down bit set to 1 may only
   be advertised down the hierarchy, i.e., to lower levels".

[RFC5305]で説明されるように: 「上/下であるのが0への接頭語がそうであるセットが注がれた1番目であったならSHALLに噛み付いた、-、」 接頭語が、より高いレベルから下のレベル(例えば、レベル2からレベル1)まで広告に掲載されるなら、ビットSHALLが1に用意ができていて、接頭語が移動したのを示して、階層構造より倒してください。 「すなわち、レベルを下げるために1に設定されて、上がるか下がるのに噛み付く接頭語の階層構造の下側に広告を出すだけであるかもしれません。」

   If the prefix was distributed into IS-IS from another routing
   protocol, the external bit SHALL be set to 1.  This information is
   useful when distributing prefixes from IS-IS to other protocols.

別のルーティング・プロトコルから、外部はSHALLに噛み付きました。接頭語が分配された、-、1に、用意ができています。 接頭語を分配するとこの情報が役に立つ、-、他のプロトコルに。

Hopps                       Standards Track                     [Page 2]

RFC 5308                Routing IPv6 with IS-IS             October 2008

ホップスStandardsがRFC5308ルート設定IPv6を追跡する、[2ページ]-、2008年10月

   If the Sub-TLV bit is set to 0, then the octets of Sub-TLVs are not
   present.  Otherwise, the bit is 1 and the octet following the prefix
   will contain the length of the Sub-TLV portion of the structure.

Sub-TLVビットが0に設定されるなら、Sub-TLVsの八重奏は存在していません。 さもなければ、ビットは1です、そして、接頭語に従う八重奏は構造のSub-TLV部分の長さを含むでしょう。

   The prefix is "packed" in the data structure.  That is, only the
   required number of octets of prefix are present.  This number can be
   computed from the prefix length octet as follows:

接頭語はデータ構造で「梱包されます」。 すなわち、接頭語の八重奏の必要な数だけが存在しています。 以下の接頭語長さの八重奏からこの数を計算できます:

   prefix octets = integer of ((prefix length + 7) / 8)

八重奏が整数と等しい接頭語((接頭語長さ+7)/8)

   Just as in [RFC5305], if a prefix is advertised with a metric larger
   than MAX_V6_PATH_METRIC (0xFE000000), this prefix MUST not be
   considered during the normal Shortest Path First (SPF) computation.
   This will allow advertisement of a prefix for purposes other than
   building the normal IPv6 routing table.

接頭語がメートル法のマックス_V6_より大きいPATH_METRIC(0xFE000000)と共に広告に掲載されるなら、この接頭語が正常なShortest Path First(SPF)計算の間、[RFC5305]で考えられるだけでよくないように。 これは正常なIPv6経路指定テーブルを組立てるのを除いた目的のための接頭語の広告を許すでしょう。

   If Sub-TLVs are present, they have the same form as normal TLVs, as
   shown below.

Sub-TLVsが存在しているなら、彼らには、正常なTLVsと同じフォームが以下に示されるようにあります。

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |         Value(*) ..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   * - if present

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| (*)を評価してください。 +++++++++++++++++*--、現在

   Length indicates how many octets of value are present and can be 0.

長さは価値のいくつの八重奏が存在していて、0であるかもしれないかを示します。

3.  IPv6 Interface Address TLV

3. IPv6インターフェース・アドレスTLV

   The "IPv6 Interface Address" TLV is TLV type 232 (0xE8).

「IPv6インターフェース・アドレス」TLVはTLVタイプ232です(0xE8)。

   TLV 232 maps directly to "IP Interface Address" TLV in [RFC1195] .
   We necessarily modify the contents to be 0-15 16-octet IPv6 interface
   addresses instead of 0-63 4-octet IPv4 interface addresses.

TLV232は[RFC1195]で直接「IPインターフェース・アドレス」にTLVを写像します。私たちは、0-63 4八重奏のIPv4インターフェース・アドレスの代わりに0-15 16八重奏IPv6インターフェース・アドレスになるように必ずコンテンツを変更します。

Hopps                       Standards Track                     [Page 3]

RFC 5308                Routing IPv6 with IS-IS             October 2008

ホップスStandardsがRFC5308ルート設定IPv6を追跡する、[3ページ]-、2008年10月

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 232   |    Length     |   Interface Address 1(*) ..   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  .. Interface Address 1(*) ..                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  .. Interface Address 1(*) ..                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  .. Interface Address 1(*) ..                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Interface Address 1(*) ..   |   Interface Address 2(*) ..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   * - if present

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =232をタイプしてください。| 長さ| アドレス1(*)を連結してください。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .. アドレス1(*)を連結してください。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .. アドレス1(*)を連結してください。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .. アドレス1(*)を連結してください。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス1(*)を連結してください。 | アドレス2(*)を連結してください。 +++++++++++++++++++++++++++++++++*--、現在

   We further restrict the semantics of this TLV depending on where it
   is advertised.  For Hello PDUs, the "Interface Address" TLV MUST
   contain only the link-local IPv6 addresses assigned to the interface
   that is sending the Hello.  For LSPs, the "Interface Address" TLVs
   MUST contain only the non-link-local IPv6 addresses assigned to the
   IS.

私たちはさらにそれが広告に掲載されているところのによるこのTLVの意味論を制限します。 Hello PDUsに関しては、「インターフェース・アドレス」TLV MUSTはHelloを送るインタフェースに割り当てられたリンクローカルのIPv6アドレスだけを含んでいます。 LSPs、TLVsがIPv6アドレスが選任した非リンクのローカルだけを含まなければならない「インターフェース・アドレス」、あります。

4.  IPv6 NLPID

4. IPv6 NLPID

   The value of the IPv6 Network Layer Protocol ID (NLPID) is 142
   (0x8E).

IPv6 Network Layer Protocol ID(NLPID)の値は142(0x8E)です。

   As with [RFC1195] and IPv4, if the IS supports IPv6 routing using
   IS-IS, it MUST advertise this in the "NLPID" TLV by adding the IPv6
   NLPID.

[RFC1195]とIPv4のようにサポートがIPv6ルーティング使用である、-、それは、"NLPID"TLVにIPv6 NLPIDを加えることによって、これの広告を出さなければなりません。

5.  Operation

5. 操作

   We utilize the same changes to [RFC1195] as made in [RFC5305] for the
   processing of prefix information.  These changes are both related to
   the SPF calculation.

私たちは接頭語情報の処理のために[RFC5305]で作られているように[RFC1195]への同じ変化を利用します。 これらの変化はともにSPF計算に関連します。

   Since the metric space has been extended, we need to redefine the
   MAX_PATH_METRIC (1023) from the original specification in [RFC1195].
   This new value MAX_V6_PATH_METRIC is the same as in [RFC5305]
   (0xFE000000).  If, during the SPF, a path metric would exceed
   MAX_V6_PATH_METRIC, it SHALL be considered to be MAX_V6_PATH_METRIC.

距離空間を広げてあるので、私たちは、[RFC1195]の正式仕様書からマックス_PATH_METRIC(1023)を再定義する必要があります。 この新しい値の_マックス_V6PATH_METRICは[RFC5305](0xFE000000)と同じです。 SPFの間、a経路メートル法であるならマックス_V6_PATH_METRICを超えているだろう、それ、SHALL、マックス_V6_PATH_METRICであると考えられてください。

Hopps                       Standards Track                     [Page 4]

RFC 5308                Routing IPv6 with IS-IS             October 2008

ホップスStandardsがRFC5308ルート設定IPv6を追跡する、[4ページ]-、2008年10月

   The order of preference between paths for a given prefix MUST be
   modified to consider the up/down bit.  The new order of preference is
   as follows (from best to worst).

上がるか下がるのが噛み付かれると考えるように与えられた接頭語のための経路の間のよく使われる順を変更しなければなりません。 新しいよく使われる順は以下の通りです(最善から最悪までの)。

      1.  Level 1 up prefix

1. レベル1 接頭語に

      2.  Level 2 up prefix

2. レベル2 接頭語に

      3.  Level 2 down prefix

3. レベル2 接頭語の下側に

      4.  Level 1 down prefix

4. レベル1 接頭語の下側に

   If multiple paths have the same best preference, then selection
   occurs based on metric.  Any remaining multiple paths SHOULD be
   considered for equal-cost multi-path routing if the router supports
   this; otherwise, the router can select any one of the multiple paths.

複数の経路に同じ最も良い好みがあるなら、選択はメートル法に基づいて起こります。 いくらか、複数の経路SHOULDのままで残っていて、ルータがこれをサポートするなら、等しい費用マルチ経路ルーティングのために考えられてください。 さもなければ、ルータは複数の経路のいずれも選択できます。

6.  IANA Considerations

6. IANA問題

   IANA has updated the IS-IS codepoint registry so that TLV codes 232
   and 236 refer to this RFC.

IANAがアップデートした、-、そのTLVが232と236をコード化して、codepoint登録はこのRFCについて言及します。

   IANA has also created the following new codepoint registry for Sub-
   TLVs of TLV 236.  The range of values for Type is 0-255.  Allocations
   within the registry require documentation of the use and requires
   approval by the Designated Expert assigned by the IESG [RFC5226].
   All codepoints are currently unassigned.

また、IANAはTLV236のSub- TLVsのための以下の新しいcodepoint登録を作成しました。 Typeのための値の範囲は0-255です。 登録の中の配分は、使用のドキュメンテーションを必要として、IESG[RFC5226]によって割り当てられたDesignated Expertによる承認を必要とします。 すべてのcodepointsが現在、割り当てられるというわけではありません。

7.  Security Considerations

7. セキュリティ問題

   This document raises no new security considerations.  Security
   considerations for the IS-IS protocol are covered in [ISO10589] and
   in [RFC5304].

このドキュメントはどんな新しいセキュリティ問題も提起しません。 セキュリティ問題、-、プロトコル、[ISO10589]と[RFC5304]では、カバーされています。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [ISO10589] ISO, "Intermediate System to Intermediate System intra-
              domain routeing information exchange protocol for use in
              conjunction with the protocol for providing the
              connectionless-mode network service (ISO 8473)",
              International Standard 10589:2002, Second Edition, 2002.

[ISO10589]ISO、「Intermediate Systemイントラドメインrouteing情報交換への中間的Systemは使用のためにコネクションレスなモードネットワーク・サービス(ISO8473)を提供するためのプロトコルに関連して議定書を作ります」、国際規格。10589:2002 Second Edition、2002。

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

[RFC1195]Callon、R.、「使用、TCP/IPと二元的な環境におけるルーティングのためのOSI IS存在、」、RFC1195、12月1990日

Hopps                       Standards Track                     [Page 5]

RFC 5308                Routing IPv6 with IS-IS             October 2008

ホップスStandardsがRFC5308ルート設定IPv6を追跡する、[5ページ]-、2008年10月

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[RFC5226] Narten、T.、およびH.Alvestrand(「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。

   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, October 2008.

[RFC5304] 李、T.、およびR.アトキンソン、「-、暗号の認証、」、RFC5304、10月2008日

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, October 2008.

[RFC5305] 李、T.、およびH.スミット、「-、交通工学のための拡大、」、RFC5305、10月2008日

Author's Address

作者のアドレス

   Christian E. Hopps
   Cisco Systems
   170 W. Tasman Dr.
   San Jose, California  95134
   USA

クリスチャンのE.ホップスシスコシステムズ170w.タスマンサンノゼ博士、カリフォルニア95134米国

   EMail: chopps@cisco.com

メール: chopps@cisco.com

Hopps                       Standards Track                     [Page 6]

RFC 5308                Routing IPv6 with IS-IS             October 2008

ホップスStandardsがRFC5308ルート設定IPv6を追跡する、[6ページ]-、2008年10月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(2008)。

   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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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に情報を扱ってください。

Hopps                       Standards Track                     [Page 7]

ホップス標準化過程[7ページ]