RFC5350 日本語訳
5350 IANA Considerations for the IPv4 and IPv6 Router Alert Options.J. Manner, A. McDonald. September 2008. (Format: TXT=17812 bytes) (Updates RFC2113, RFC3175) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Manner
Request for Comments: 5350 TKK
Updates: 2113, 3175 A. McDonald
Category: Standards Track Siemens/Roke
September 2008
コメントを求めるワーキンググループJ.方法要求をネットワークでつないでください: 5350のTKKアップデート: 2113、3175A.マクドナルドカテゴリ: 標準化過程シーメンス/Roke2008年9月
IANA Considerations for the IPv4 and IPv6 Router Alert Options
IPv4とIPv6ルータ警戒オプションのためのIANA問題
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
Abstract
要約
This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values.
このドキュメントはIPv4とIPv6 Router Alert Option ValuesのIANA配分規則と登録をアップデートします。
Table of Contents
目次
1. Introduction ....................................................2
2. Use of the Router Alert Option Value Field ......................2
3. IANA Considerations .............................................4
3.1. IANA Considerations for IPv4 Router Alert Option Values ....4
3.2. IANA Considerations for IPv6 Router Alert Option Values ....5
4. Security Considerations .........................................5
5. Acknowledgements ................................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
1. 序論…2 2. ルータ警戒オプション価値分野の使用…2 3. IANA問題…4 3.1. IPv4ルータのためのIANA問題はオプション価値を警告します…4 3.2. IPv6ルータのためのIANA問題はオプション価値を警告します…5 4. セキュリティ問題…5 5. 承認…6 6. 参照…6 6.1. 標準の参照…6 6.2. 有益な参照…6
Manner & McDonald Standards Track [Page 1] RFC 5350 IANA Considerations for Router Alert September 2008
方法とマクドナルドStandardsは注意深いルータ2008年9月にRFC5350IANA問題を追跡します[1ページ]。
1. Introduction
1. 序論
The IP Router Alert Option is defined for IPv4 in [RFC2113]. A similar IPv6 option is defined in [RFC2711]. When one of these options is present in an IP datagram, it indicates that the contents of the datagram may be interesting to routers. The Router Alert Option (RAO) is used by protocols such as the Resource Reservation Protocol (RSVP) [RFC2205] and IGMP [RFC3376].
IP Router Alert Optionは[RFC2113]のIPv4のために定義されます。 同様のIPv6オプションは[RFC2711]で定義されます。 これらのオプションの1つがIPデータグラムに存在しているとき、それは、データグラムのコンテンツがルータにおもしろいかもしれないのを示します。 Router Alert Option(RAO)はResource予約のプロトコル(RSVP)[RFC2205]やIGMP[RFC3376]などのプロトコルによって使用されます。
Both the IPv4 and IPv6 options contain a two-octet Value field to carry extra information. This information can be used, for example, by routers to determine whether or not the packet should be more closely examined by them.
IPv4とIPv6オプションの両方がValueがその他の情報を運ぶためにさばく2八重奏を含んでいます。 例えば、この情報はルータによって使用されて、パケットがそれらによって、より密接に調べられるべきであるかどうか決定できます。
There can be up to 65536 values for the RAO. Yet, currently there is only a registry for IPv6 values. No registry or allocation policies are defined for IPv4.
RAOのための最大65536の値があることができます。 しかし現在、IPv6値のための登録しかありません。 どんな登録も配分方針もIPv4のために定義されません。
This document updates the IANA registry for managing IPv4 and IPv6 Router Alert Option Values, and removes one existing IPv6 Router Alert Option Value.
このドキュメントは、IPv4とIPv6 Router Alert Option Valuesを管理するためにIANA登録をアップデートして、1既存のIPv6 Router Alert Option Valueを取り外します。
2. Use of the Router Alert Option Value Field
2. ルータ警戒オプション価値分野の使用
One difference between the specifications for the IPv4 and IPv6 Router Alert Options is the way values for the Value field are managed. In [RFC2113], the IPv4 Router Alert Option Value field has the value 0 assigned to "Router shall examine packet". All other values (1-65535) are reserved. Neither a management mechanism (e.g., an IANA registry) nor an allocation policy are provided for the IPv4 RAO values.
IPv4とIPv6 Router Alert Optionsのための仕様の1つの違いがValue分野への値が管理される方法です。 [RFC2113]では、IPv4 Router Alert Option Value分野で「ルータはパケットを調べるものとすること」に値0を割り当てます。 他のすべての値(1-65535)が予約されています。 管理メカニズム(例えば、IANA登録)も配分方針もIPv4 RAO値に提供されません。
The IPv6 Router Alert Option has an IANA-managed registry [IANA-IPv6RAO] containing allocations for the Value field.
IPv6 Router Alert Optionには、Value分野のための配分を含むIANAによって管理された登録[IANA-IPv6RAO]があります。
In [RFC3175], the IPv4 Router Alert Option Value is described as a parameter that provides "additional information" to the router in making its interception decision, rather than as a registry managed by IANA. As such, this aggregation mechanism makes use of the Value field to carry the reservation aggregation level. For the IPv6 option, IANA has assigned a set of 32 values to indicate reservation levels. However, since other registrations have already been made in that registry, these values are from 3-35 (which is actually a set of 33 values).
[RFC3175]では、IPv4 Router Alert Option Valueは妨害決定をする際に「追加情報」をルータに提供するパラメタとして記述されています、むしろIANAによって管理された登録より。 そういうものとして、この凝集機構は、予約集合レベルを運ぶのにValue分野を利用します。 IPv6オプションのために、IANAは予約レベルを示す32の値のセットを割り当てました。 しかしながら、その登録で既に他の登録証明書をしたので、これらの値は3-35(実際に33の値のセットである)から来ています。
Although it might have been desirable to have the same values used in both the IPv4 and IPv6 registries, the initial allocations in [RFC2711] and the aggregation-level allocations in [RFC3175] have
IPv4、IPv6登録、[RFC2711]での初期の配分、および[RFC3175]での集合レベル配分が持っている両方で同じ値を使用させるのが望ましかったかもしれませんが
Manner & McDonald Standards Track [Page 2] RFC 5350 IANA Considerations for Router Alert September 2008
方法とマクドナルドStandardsは注意深いルータ2008年9月にRFC5350IANA問題を追跡します[2ページ]。
made this impossible. The following table shows the allocations in the IPv6 registry and the values used in the IPv4 registry, where the latter have been deduced from [RFC2113] and [RFC3175] with the assumption that the number of aggregation levels can be limited to 32 as in the IPv6 case. Entries for values 6 to 31 have been elided for brevity.
これを不可能にしました。 以下のテーブルは、IPv6ケースのように集合レベルの数を32に制限できるのをIPv6登録での配分とIPv4登録で使用される値に示します。そこでは、後者が仮定がある[RFC2113]と[RFC3175]から推論されました。 値6〜31のためのエントリーは簡潔さのために削除されました。
+----------+-------------------------+------------------------------+ | Value | IPv4 RAO Meaning | IPv6 RAO Meaning | +----------+-------------------------+------------------------------+ | 0 | Router shall examine | Datagram contains a | | | packet [RFC2113] | Multicast Listener Discovery | | | [RFC2205] [RFC3376] | message [RFC2711] [RFC2710] | | | [RFC4286] | [RFC4286] | | 1 | Aggregated Reservation | Datagram contains RSVP | | | Nesting Level 1 | message [RFC2711] [RFC2205] | | | [RFC3175] | | | 2 | Aggregated Reservation | Datagram contains an Active | | | Nesting Level 2 | Networks message [RFC2711] | | | [RFC3175] | [Schwartz2000] | | 3 | Aggregated Reservation | Aggregated Reservation | | | Nesting Level 3 | Nesting Level 0 [RFC3175](*) | | | [RFC3175] | | | 4 | Aggregated Reservation | Aggregated Reservation | | | Nesting Level 4 | Nesting Level 1 [RFC3175] | | | [RFC3175] | | | 5 | Aggregated Reservation | Aggregated Reservation | | | Nesting Level 5 | Nesting Level 2 [RFC3175] | | | [RFC3175] | | | ... | ... | ... | | 32 | Aggregated Reservation | Aggregated Reservation | | | Nesting Level 32 | Nesting Level 29 [RFC3175] | | | [RFC3175] | | | 33 | Reserved | Aggregated Reservation | | | | Nesting Level 30 [RFC3175] | | 34 | Reserved | Aggregated Reservation | | | | Nesting Level 31 [RFC3175] | | 35 | Reserved | Aggregated Reservation | | | | Nesting Level 32(*) | | | | [RFC3175] | | 36-65534 | Reserved | Reserved to IANA for future | | | | assignment | | 65535 | Reserved | Reserved [IANA-IPv6RAO] | +----------+-------------------------+------------------------------+
+----------+-------------------------+------------------------------+ | 値| IPv4 RAO意味| IPv6 RAO意味| +----------+-------------------------+------------------------------+ | 0 | ルータは調べられるものとします。| データグラムはaを含んでいます。| | | パケット[RFC2113]| マルチキャストリスナー発見| | | [RFC2205][RFC3376]| メッセージ[RFC2711][RFC2710]| | | [RFC4286]| [RFC4286]| | 1 | 予約に集めます。| データグラムはRSVPを含んでいます。| | | 入れ子のレベル1| メッセージ[RFC2711][RFC2205]| | | [RFC3175]| | | 2 | 予約に集めます。| データグラムはActiveを含んでいます。| | | 入れ子のレベル2| メッセージ[RFC2711]をネットワークでつなぎます。| | | [RFC3175]| [Schwartz2000]| | 3 | 予約に集めます。| 予約に集めます。| | | 入れ子のレベル3| 入れ子のレベル0[RFC3175](*)| | | [RFC3175]| | | 4 | 予約に集めます。| 予約に集めます。| | | 入れ子のレベル4| 入れ子のレベル1[RFC3175]| | | [RFC3175]| | | 5 | 予約に集めます。| 予約に集めます。| | | 入れ子のレベル5| 入れ子のレベル2[RFC3175]| | | [RFC3175]| | | ... | ... | ... | | 32 | 予約に集めます。| 予約に集めます。| | | 入れ子のレベル32| 入れ子のレベル29[RFC3175]| | | [RFC3175]| | | 33 | 予約されます。| 予約に集めます。| | | | 入れ子のレベル30[RFC3175]| | 34 | 予約されます。| 予約に集めます。| | | | 入れ子のレベル31[RFC3175]| | 35 | 予約されます。| 予約に集めます。| | | | 入れ子のレベル32(*)| | | | [RFC3175]| | 36-65534 | 予約されます。| 未来のIANAに予約されます。| | | | 課題| | 65535 | 予約されます。| 予約されます[IANA-IPv6RAO]。| +----------+-------------------------+------------------------------+
Note (*): The entry in the above table for the IPv6 RAO Value of 35 (Aggregated Reservation Nesting Level 32) has been marked due to an inconsistency in the text of [RFC3175], and is consequently reflected
注意(*): 35(予約Nesting Level32に集める)のIPv6 RAO Valueのための上のテーブルのエントリーは、[RFC3175]のテキストにおける矛盾のためマークされて、その結果、反映されます。
Manner & McDonald Standards Track [Page 3] RFC 5350 IANA Considerations for Router Alert September 2008
方法とマクドナルドStandardsは注意深いルータ2008年9月にRFC5350IANA問題を追跡します[3ページ]。
in the IANA registry. In that document, the values 3-35 (i.e., 33 values) are defined for nesting levels 0-31 (i.e., 32 levels). Similarly, value 3 is a duplicate, because aggregation level 0 means end-to-end signaling, and this already has an IPv6 RAO value "1" assigned.
IANA登録で。 そのドキュメントでは、値3-35(すなわち、33の値)は入れ子のレベル0-31(すなわち、32のレベル)のために定義されます。 同様に、値3は写しです、集合レベル0が終わりから終わりへのシグナリングを意味して、これには「1インチは割り当てた」IPv6 RAO値が既にあるので。
Also note that nesting levels begin at 1 for IPv4 (described in Section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in Section 6 of [RFC3175]).
また、入れ子のレベルがIPv4(.9セクション1.4[RFC3175]では、説明される)のための1時とIPv6([RFC3175]のセクション6では、割り当てる)のための0時に始まることに注意してください。
Section 3.2 of this document redefines these so that for IPv6, value 3 is no longer used and values 4-35 represent levels 1-32. This removes the above inconsistencies.
このドキュメントのセクション3.2がこれらを再定義するので、値3はIPv6にもう使用されません、そして、値4-35はレベル1-32を表します。 これは上の矛盾を取り除きます。
3. IANA Considerations
3. IANA問題
This section contains the new procedures for managing IPv4 Router Alert Option Values. IANA has created a registry for IPv4 Router Alert Option Values (described in Section 3.1) and has updated the IPv6 Router Alert Option Values (described in Section 3.2).
このセクションはIPv4 Router Alert Option Valuesを管理するための新しい手順を含みます。 IANAはIPv4 Router Alert Option Valuesのための登録を作成して(セクション3.1では、説明されます)、IPv6 Router Alert Option Valuesをアップデートしました(セクション3.2では、説明されます)。
IP Router Alert Option Values are currently managed separately for IPv4 and IPv6. This document does not change this, as there is little value in forcing the two registries to be aligned.
IP Router Alert Option Valuesは現在、IPv4とIPv6のために別々に管理されます。 2つの登録が並べさせられるのにおいて値がほとんどないとき、このドキュメントはこれを変えません。
3.1. IANA Considerations for IPv4 Router Alert Option Values
3.1. IPv4ルータ警戒オプション価値のためのIANA問題
The Value field, as specified in [RFC2113], is two octets in length. The Value field is registered and maintained by IANA. The initial contents of this registry are:
[RFC2113]で指定されるValue分野は長さが2つの八重奏です。 Value分野は、IANAによって示されて、維持されます。 この登録の初期の内容は以下の通りです。
+-------------+--------------------------------------+-----------+ | Value | Description | Reference | +-------------+--------------------------------------+-----------+ | 0 | Router shall examine packet | [RFC2113] | | 1-32 | Aggregated Reservation Nesting Level | [RFC3175] | | 33-65502 | Available for assignment by the IANA | | | 65503-65534 | Available for experimental use | | | 65535 | Reserved | | +-------------+--------------------------------------+-----------+
+-------------+--------------------------------------+-----------+ | 値| 記述| 参照| +-------------+--------------------------------------+-----------+ | 0 | ルータはパケットを調べるものとします。| [RFC2113]| | 1-32 | 予約入れ子のレベルに集めます。| [RFC3175]| | 33-65502 | IANAによる課題に、利用可能です。| | | 65503-65534 | 実験用に、利用可能です。| | | 65535 | 予約されます。| | +-------------+--------------------------------------+-----------+
New values are to be assigned via IETF Review as defined in [RFC5226].
新しい値は[RFC5226]で定義されるようにIETF Reviewを通して割り当てられることです。
Manner & McDonald Standards Track [Page 4] RFC 5350 IANA Considerations for Router Alert September 2008
方法とマクドナルドStandardsは注意深いルータ2008年9月にRFC5350IANA問題を追跡します[4ページ]。
3.2. IANA Considerations for IPv6 Router Alert Option Values
3.2. IPv6ルータ警戒オプション価値のためのIANA問題
The registry for IPv6 Router Alert Option Values continues to be maintained as specified in [RFC2711]. In addition, the following value has been removed from the IANA registry and reserved for possible future use (not to be allocated currently). The reason is that it is a duplicate value; aggregation level 0 means end-to-end signaling, and this already has an IPv6 RAO value "1" assigned.
IPv6 Router Alert Option Valuesのための登録は、[RFC2711]で指定されるように維持され続けています。 さらに、以下の値は、IANA登録から取り除かれて、可能な今後の使用のために予約されました(現在割り当てられない)。 理由はそれが写し値であるということです。 集合レベル0は終わりから終わりへのシグナリングを意味します、そして、これには、「1インチは割り当てた」IPv6 RAO値が既にあります。
+-------+--------------------------+-----------+ | Value | Description | Reference | +-------+--------------------------+-----------+ | 3 | RSVP Aggregation level 0 | [RFC3175] | +-------+--------------------------+-----------+
+-------+--------------------------+-----------+ | 値| 記述| 参照| +-------+--------------------------+-----------+ | 3 | RSVP Aggregationレベル0| [RFC3175]| +-------+--------------------------+-----------+
The following IPv6 RAO values are available for experimental use:
以下のIPv6 RAO値は実験用に利用可能です:
+-------------+------------------+-----------+ | Value | Description | Reference | +-------------+------------------+-----------+ | 65503-65534 | Experimental use | | +-------------+------------------+-----------+
+-------------+------------------+-----------+ | 値| 記述| 参照| +-------------+------------------+-----------+ | 65503-65534 | 実験用| | +-------------+------------------+-----------+
4. Security Considerations
4. セキュリティ問題
Since this document is only concerned with the IANA management of the IPv4 and IPv6 Router Alert Option Values registry, it raises no new security issues beyond those identified in [RFC2113] and [RFC2711].
このドキュメントはIPv4とIPv6 Router Alert Option Values登録のIANA管理に関係があるだけであるので、それは[RFC2113]と[RFC2711]で特定されたものを超えてどんな新しい安全保障問題も提起しません。
Yet, as discussed in RFC 4727 [RFC4727], production networks do not necessarily support the use of experimental code points in IP option headers. The network scope of support for experimental values should be evaluated carefully before deploying any experimental RAO value across extended network domains, such as the public Internet. The potential to disrupt the stable operation of the network hosting the experiment through the use of unsupported experimental code points is a serious consideration when planning an experiment using such code points.
しかし、RFC4727[RFC4727]で議論するように、生産ネットワークは必ずIPオプションヘッダーにおける実験コード・ポイントの使用をサポートするというわけではありません。 実験値のサポートのネットワーク範囲は拡大ネットワークドメインの向こう側にどんな実験的なRAOも値であると配布する前に慎重に評価されるべきです、公共のインターネットなどのように。 そのようなコード・ポイントを使用することで実験を計画しているとき、サポートされない実験コード・ポイントの使用で実験を主催するネットワークの安定稼働を中断する可能性は真剣な考慮です。
When experimental RAO values are deployed within an administratively self-contained network domain, the network administrators should ensure that each value is used consistently to avoid interference between experiments. When experimental values are used in traffic that crosses multiple administrative domains, the experimenters should assume that there is a risk that the same values will be used simultaneously by other experiments, and thus that there is a
実験RAO値が行政上自己充足的なネットワークドメインの中で配布されるとき、ネットワーク管理者は、各値が実験の間の干渉を避けるのに一貫して使用されるのを保証するべきです。 実験値が複数の管理ドメインに交差するトラフィックに使用されるとき、実験者は同じくらいが同時に他の実験で使用されるのを評価する危険があって、その結果、aがあると仮定するべきです。
Manner & McDonald Standards Track [Page 5] RFC 5350 IANA Considerations for Router Alert September 2008
方法とマクドナルドStandardsは注意深いルータ2008年9月にRFC5350IANA問題を追跡します[5ページ]。
possibility that the experiments will interfere. Particular attention should be given to security threats that such interference might create.
実験に干渉する可能性。 そのような干渉が作成するかもしれない軍事的脅威に特別の注意を与えるべきです。
5. Acknowledgements
5. 承認
Thanks to Robert Hancock, Martin Stiemerling, Alan Ford, and Francois Le Faucheur for their helpful comments on this document.
彼らの役に立つコメントをこのドキュメントの上にロバートハンコック、マーチンStiemerling、アラン・フォード、およびフランソアLe Faucheurをありがとうございます。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.
[RFC2113] キャッツ、D.、「IPルータ警戒オプション」、RFC2113、1997年2月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert
Option", RFC 2711, October 1999.
[RFC2711] ヤマウズラとC.とA.ジャクソン、「IPv6ルータ警戒オプション」、RFC2711、1999年10月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B.
Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
[RFC3175] ベイカー、F.、イトゥラルデ、C.、Le Faucheur、F.、およびB.デイビー、「IPv4とIPv6予約のためのRSVPの集合」、RFC3175(2001年9月)。
[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がそうするかもしれません。
6.2. Informative References
6.2. 有益な参照
[IANA-IPv6RAO] "IANA Registry for Internet Protocol version 6 (IPv6)
Router Alert Option Values", <http://www.iana.org>.
[IANA-IPv6RAO] 「インターネットプロトコルバージョン6(IPv6)ルータAlert Option ValuesのためのIANA Registry」、<http://www.iana.org>。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,
and S. Jamin, "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2205]ブレーデン、R.(エド)、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC2710] デアリング、S.、フェナー、W.、およびB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
A. Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3376] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」
[RFC4286] Haberman, B. and J. Martin, "Multicast Router
Discovery", RFC 4286, December 2005.
[RFC4286] ハーバーマンとB.とJ.マーチン、「マルチキャストルータ発見」、RFC4286、2005年12月。
Manner & McDonald Standards Track [Page 6] RFC 5350 IANA Considerations for Router Alert September 2008
方法とマクドナルドStandardsは注意深いルータ2008年9月にRFC5350IANA問題を追跡します[6ページ]。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6,
ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727,
November 2006.
[RFC4727]フェナー、B.、「IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値」、RFC4727、2006年11月。
[Schwartz2000] Schwartz, B., Jackson, A., Strayer, W., Zhou, W.,
Rockwell, D., and C. Partridge, "Smart Packets:
Applying Active Networks to Network Management", ACM
Transactions on Computer Systems (TOCS), Volume 18,
Issue 1, February 2000.
[Schwartz2000] シュワルツ、B.、ジャクソン、A.、迷い人、W.、周、W.、ロックウェル、D.、およびC.ヤマウズラ、「賢いパケット:」 「活動的なネットワークをネットワークマネージメントに適用し」て、コンピュータシステムズ(トックス)のACMトランザクション(第18巻)は1、2000年2月を発行します。
Authors' Addresses
作者のアドレス
Jukka Manner Department of Communications and Networking (Comnet) Helsinki University of Technology (TKK) P.O. Box 3000 Espoo FIN-02015 TKK Finland
ユッカ方法コミュニケーションとネットワーク(Comnet)ヘルシンキ大学技術(TKK)P.O. Box3000エスポー部のフィン-02015TKKフィンランド
Phone: +358 9 451 2481 EMail: jukka.manner@tkk.fi
以下に電話をしてください。 +358 9 451 2481はメールされます: jukka.manner@tkk.fi
Andrew McDonald Roke Manor Research Ltd (a Siemens company) Old Salisbury Lane Romsey, Hampshire SO51 0ZN United Kingdom
アンドリューマクドナルドRoke Manor Research Ltd(シーメンス会社)古いソールズベリーLaneロムジー、ハンプシャーSO51 0ZNイギリス
EMail: andrew.mcdonald@roke.co.uk
メール: andrew.mcdonald@roke.co.uk
Manner & McDonald Standards Track [Page 7] RFC 5350 IANA Considerations for Router Alert September 2008
方法とマクドナルドStandardsは注意深いルータ2008年9月にRFC5350IANA問題を追跡します[7ページ]。
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に情報を扱ってください。
Manner & McDonald Standards Track [Page 8]
方法とマクドナルド標準化過程[8ページ]
一覧
スポンサーリンク
