RFC2337 日本語訳
2337 Intra-LIS IP multicast among routers over ATM using Sparse ModePIM. D. Farinacci, D. Meyer, Y. Rekhter. April 1998. (Format: TXT=16357 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Farinacci Request for Comments: 2337 Cisco Systems Category: Experimental D. Meyer Cisco Systems Y. Rekhter Cisco Systems April 1998
コメントを求めるワーキンググループD.ファリナッチの要求をネットワークでつないでください: 2337年のシスコシステムズカテゴリ: 実験的なD.のマイヤーシスコシステムズY.Rekhterシスコシステムズ1998年4月
Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM
Sparse Mode PIMを使用するATMの上のルータの中のイントラ-LIS IPマルチキャスト
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
2. Abstract
2. 要約
This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). The method described here is specific to Sparse Mode PIM [PIM-SM], and relies on the explicit join mechanism inherent in PIM-SM to notify routers when they should create group specific point-to-multipoint VCs.
このドキュメントはATMの上のルータの中でどう効率的にMulticast Address Resolution Server(火星)を使用しないでイントラ-LIS IPマルチキャストをサポートすることができるかを説明します。 ここで説明されたメソッドは、Sparse Mode PIM[PIM-SM]に特定であり、明白を当てにします。PIM-SMの固有であるメカニズムを接合して、グループの特定のポイントツーマルチポイントVCsを作成するべきであるとき、ルータに通知してください。
3. Overall model
3. 全体的に見て、モデル化してください。
This document focuses on forwarding of multicast traffic among PIM-SM routers connected to an ATM network. Routers on an ATM network are partitioned into Logical IP Subnets, or LISs. This document deals with handling multicast within a single LIS. Handling inter-LIS multicast traffic, including handling shortcuts, is outside the scope of this document. In addition, this document does not address forwarding of multicast traffic to or from hosts connected to an ATM network.
このドキュメントはATMネットワークに関連づけられたPIM-SMルータの中でマルチキャストトラフィックの推進に集中します。 ATMネットワークのルータはLogical IPのSubnets、またはLISsに仕切られます。 このドキュメントは独身のLISの中で取り扱いマルチキャストに対処します。 このドキュメントの範囲の外に近道を扱うのを含む取り扱い相互LISマルチキャストトラフィックがあります。 さらに、このドキュメントはホスト、または、ATMネットワークに接続されたホストからマルチキャストトラフィックの推進を扱いません。
Farinacci, et. al. Experimental [Page 1] RFC 2337 IP multicast over ATM using PIM April 1998
etファリナッチ、アル。 1998年4月にPIMを使用するATMの上の実験的な[1ページ]RFC2337IPマルチキャスト
4. Router behavior
4. ルータの振舞い
This document requires that each router within a LIS knows IP and ATM addresses of all other routers within the LIS. The mapping between IP and ATM addresses may be provided by an ARP server [RFC2225], or by any other means (e.g., static configuration).
このドキュメントは、LISの中の各ルータがLISの中で他のすべてのルータのIPとATMアドレスを知っているのを必要とします。 ARPサーバ[RFC2225]、またはいかなる他の手段(例えば、静的な構成)でもIPとATMアドレスの間のマッピングを提供するかもしれません。
Each PIM router within a LIS is required to maintain a single (shared) point-to-multipoint distribution VC rooted at the router with all other PIM routers in the LIS as the leaf nodes. The VC is expected to be used for forwarding of multicast traffic (both data and control) among routers within the LIS. For example, this VC would be used for distributing PIM [PIM-SM] control messages (Join/Prune messages).
LISの中のそれぞれのPIMルータが、他のすべてのPIMルータがLISにある状態で葉のノードとしてルータで根づいているのに(共有されます)ただ一つのポイントツーマルチポイント分配VCを維持するのに必要です。 マルチキャストトラフィック(データとコントロールの両方)の推進にLISの中のルータの中でVCが使用されると予想されます。 例えば、このVCは、PIM[PIM-SM]コントロールメッセージを分配するのに使用されるでしょう(メッセージを接合するか、または剪定してください)。
In addition, if a PIM router receives a IGMP report from an non-PIM neighbor, then the router may add the reporter to the existing shared distribution VC or to the group specific distribution VC (if it exists). The PIM router may also create a specific VC for this IGMP proxy.
さらに、PIMルータが非PIM隣人からIGMPレポートを受け取るなら、ルータは既存の共有された分配VC、または、グループ特定の分配VCにレポーターを加えるかもしれません(存在しているなら)。 また、PIMルータはこのIGMPプロキシのために特定のVCを作成するかもしれません。
4.1. Establishing Dedicated, Per Group Point-to-Multipoint VCs
4.1. グループポイントツーマルチポイントVCs単位で捧げられた設立
Routers may also maintain group specific, dedicated point-to- multipoint VCs. In particular, an upstream router for a group may choose to become the root of a group specific point-to-multipoint VC whose leaves are the downstream routers that have directly connected or downstream receivers for the group. While the criteria for establishing a group specific point-to-multipoint VC are local to a router, issues such as the volume of traffic associated with the group and the fanout factor within the LIS should be considered. Finally, note that a router must minimally support a single shared point-to-multipoint VC for distribution of control messages and data (to all group addresses).
また、ルータはグループ特定の、そして、専用であるポイントから多点へのVCsを維持するかもしれません。 特に、グループのための上流のルータは、葉がグループのための直接接続されたか川下の受信機がある川下のルータであるグループ特定のポイントツーマルチポイントVCの根になるのを選ぶかもしれません。 グループを設立する評価基準である間、特定のポイントツーマルチポイントVCがルータに地方である、LISの中でグループとfanout要素に関連している交通量などの問題は考えられるべきです。 最終的に、ルータが、コントロールメッセージとデータ(すべてのグループアドレスへの)の分配のためにただ一つの共有されたポイントツーマルチポイントがVCであると最少量でサポートしなければならないことに注意してください。
A router can choose to establish a dedicated point-to-multipoint VC (or add another leaf to an already established dedicated point-to- multipoint VC) when it receives a PIM Join or IGMP report messages from another device in the same LIS. When a router that is the root of a point-to-multipoint VC receives PIM Prune message or IGMP leave, it removes the originator of the message from its dedicated point- to-multipoint VC.
ルータは、同じLISの別のデバイスからPIM JoinかIGMPレポートメッセージを受け取るとき、ひたむきなポイントツーマルチポイントVC(既に確立した専用ポイントから多点へのVCに別の葉を加える)を設立するのを選ぶことができます。 VCが受けるポイントツーマルチポイントの根であるルータであるときに、PIM PruneメッセージかIGMPがいなくなって、それは専用ポイントから多点までのメッセージVCの創始者を免職します。
Farinacci, et. al. Experimental [Page 2] RFC 2337 IP multicast over ATM using PIM April 1998
etファリナッチ、アル。 1998年4月にPIMを使用するATMの上の実験的な[2ページ]RFC2337IPマルチキャスト
4.2. Switching to a Source-Rooted Tree
4.2. ソースが根づいている木に切り替わること。
If at least one of the routers within a LIS decides to switch to a source-rooted tree (by sending (S,G) PIM Joins), then all other routers within the LIS that have downstream members for G should switch to that source-rooted tree as well. Since a router that switches to a source-rooted tree sends PIM Join messages for (S,G) over its shared point-to-multipoint VC, the other routers within the LIS are able to detect this. Once a router that has downstream members for G detects this, the router should send (S,G) PIM Join message as well (otherwise the router may receive duplicate traffic from S).
少なくともLISの中のルータのひとりが、ソースが根づいている木(PIM Joinsを送るのによる(S、G))に切り替わると決めるなら、Gのための川下のメンバーがいるLISの中の他のすべてのルータがまた、そのソースが根づいている木に切り替わるべきです。 ソースが根づいている木に切り替わるルータが共有されたポイントツーマルチポイントVCの上で(S、G)へのメッセージをPIM Joinに送るので、LISの中の他のルータはこれを検出できます。 Gのための川下のメンバーがいるルータがいったんこれを検出すると、ルータはまた、PIM Joinメッセージを送るべきです(S、G)(さもなければ、ルータはSから写しトラフィックを受けるかもしれません)。
Note that it is possible for a non-PIM router in the LIS to fail to receive data if the injection point moves to router to which there is not an existing VC.
注射ポイントが既存のVCがないルータに移行するなら、LISの非PIMルータがデータを受け取らないのが、可能であることに注意してください。
4.2.1. Adding New Members to a Source-Rooted Tree
4.2.1. ソースが根づいている木に新しいメンバーを加えます。
As mentioned above, this document requires that once one router in a LIS decides to switch to the source tree for some (S,G), all routers in the LIS that have downstream members must also switch to the (S,G) source tree. Now, when a new router wants to receive traffic from G, it starts sending (*,G)-Joins on it's shared point-to-multipoint VC toward the RP for G. The root of the (S,G)-source-rooted tree will know to add the new router to the point-to-multipoint VC servicing the (S,G)-source-rooted tree by observing the (*,G)-joins on it's shared point-to-multipoint VC. However, the new router must also switch to the (S,G)-source-rooted tree. In order to accomplish this, the newly added router must:
以上のように、このドキュメントは、また、LISの1つのルータが、いくつか(S、G)のためにソース木に切り替わるといったん決めると、川下のメンバーがいるLISのすべてのルータが(S、G)ソース木に切り替わらなければならないのを必要とします。 受信するa新しいルータ必需品がGから取引して、それが発信(*、G)がG. 根のためのRPに向かったそれの共有されたポイントツーマルチポイントVCで接合する始動である現在、(S、G)ソースが根づいている木が多点へのポイントへの新しいルータVC整備点検を加えるのを知る、(S、見るのによるG)ソースが根づいている木、(*、G)はそれの分配しているポイントツーマルチポイントVCで接合します。 しかしながら、また、新しいルータが切り替わらなければならない、(S、G)ソースが根づいている木。 これを達成するために、新たに加えられたルータは達成しなければなりません:
(i). Notice that it has been added to a new point-to-multipoint VC
(i)。 それが新しいポイントツーマルチポイントVCに加えられるのに注意してください。
(ii). Notice (S,G) traffic coming down this new point-to-multipoint VC
(ii。) この新しいポイントツーマルチポイントVCで来る通知(S、G)トラフィック
(iii). Send (S,G) joins toward S, causing it to switch to the source-rooted tree. The router learns that the VC is used to distribute (S,G) traffic in the previous steps.
(iii。) Sに向かって接合して、それがソースが根づいている木に切り替わることを引き起こして、発信してください(S、G)。 ルータは、VCが前のステップでトラフィックを分配すること(S、G)に使用されることを学びます。
Farinacci, et. al. Experimental [Page 3] RFC 2337 IP multicast over ATM using PIM April 1998
etファリナッチ、アル。 1998年4月にPIMを使用するATMの上の実験的な[3ページ]RFC2337IPマルチキャスト
4.3. Handing the "Packet Reflection" Problem
4.3. 「パケット反射」問題を手渡します。
When a router receives a multicast packet from another router in its own LIS, the router should not send the packet on any of the routers distribution point-to-multipoint VCs associate with the LIS. This eliminates the problem of "packet reflection". Sending the packet on the routers' distribution VCs associated with other LISs is controlled by the multicast routing procedures.
ルータがそれ自身のLISの別のルータからマルチキャストパケットを受けるとき、ルータはVCsがLISに関連づけるルータ分配ポイントツーマルチポイントのどれかのパケットを送るべきではありません。 これは「パケット反射」の問題を解決します。 他のLISsに関連しているルータの分配VCsにパケットを送るのはマルチキャストルーティング手順で制御されます。
5. Brief Comparison with MARS
5. 火星との簡潔な比較
The intra-LIS multicast scheme described in this document is intended to be a less complex solution to an important subset of the functionality provided by the Multicast Address Resolution Server, or MARS [MARS]. In particular, it is designed to provide intra-LIS multicast between routers using PIM-SM, and does not consider the case of host-rooted point-to-multicast multicast distribution VCs.
本書では説明されたイントラ-LISマルチキャスト体系はMulticast Address Resolution Serverによって提供された、機能性の重要な部分集合、または火星[火星]へのそれほど複雑でない解決であることを意図します。 それは、特に、PIM-SMを使用することでイントラ-LISマルチキャストをルータの間に提供するように設計されていて、ポイントからマルチキャストへのマルチキャストホストが根づいている分配VCsに関するケースを考えません。
Although MARS supports both of the current schemes for mapping the IP multicast service model to ATM (multicast server and meshes of point-to-multipoint VCs), it does so at at cost and complexity higher than of the scheme described in this document. In addition, MARS requires new encapsulations, whereas this proposal works with either LLC/SNAP or with NLPID encapsulation. Another important difference is that MARS allows point-to-multipoint VCs rooted either at a source or at a multicast server (MCS). The approach taken here is to constrain complexity by focusing on PIM-SM (taking advantage of information available in explicit joins), and by allowing point-to-multipoint VCs to be rooted only at the routers (which is roughly analogous to the complexity and functionality of rooting point-to-multipoint VCs at the sources).
火星はIPマルチキャストサービスを写像することの現在の体系の両方をサポートしますが、ATM(ポイントツーマルチポイントVCsのマルチキャストサーバとメッシュ)にモデル化してください、と費用でそうして、体系より高い複雑さは本書では説明しました。 さらに、火星は新しいカプセル化を必要としますが、この提案はLLC/SNAPかNLPIDカプセル化で働いています。 別の重要な違いは火星がソースにおいて、または、マルチキャストサーバにおいて根づいているポイントツーマルチポイントVCs(MCS)を許容するということです。 ここに取られたアプローチはPIM-SM(明白で利用可能な情報を利用するのは接合する)に焦点を合わせて、ポイントツーマルチポイントVCsが単にルータに根づくのを許容することによって複雑さを抑制する(ソースでおよそ応援ポイントツーマルチポイントVCsの複雑さと機能性に類似しています)ことです。
In summary, the method described in this document is designed for the router-to-router case, and takes advantage of the explicit-join mechanism inherent in PIM-SM to provide a simple mechanism for intra-LIS multicast between routers. MARS, on the other hand, accepts different tradeoffs in complexity-functionality design space. In particular, while the MARS paradigm provides a general neighbor discovery mechanism, allows host to participate, and is protocol independent, it does so at considerable cost.
概要では、メソッドがこのドキュメントがルータからルータへのケースのために設計されていて、利点を活用するコネについて説明した、明白である、-接合してください、ルータの間でイントラ-LISマルチキャストに簡単なメカニズムを提供するPIM-SMの固有であるメカニズム。 他方では、火星は複雑さ機能性デザインスペースで異なった見返りを受け入れます。 火星パラダイムは、一般的な隣人発見メカニズムを提供して、ホストが参加するのを許容して、プロトコル独立者ですが、特に、それは巨額の費用でそうします。
Farinacci, et. al. Experimental [Page 4] RFC 2337 IP multicast over ATM using PIM April 1998
etファリナッチ、アル。 1998年4月にPIMを使用するATMの上の実験的な[4ページ]RFC2337IPマルチキャスト
6. Security Considerations
6. セキュリティ問題
In general, the security issues relevant to the proposal outlined in the memo are subsumed by those faced by PIM-SM. While work in proceeding on security for PIM-SM, it is worthwhile noting that several issues have been raised in conjunction with multicast routing and with PIM-SM in particular. These issues include but are not limited to:
一般に、メモに概説された提案に関連している安全保障問題はPIM-SMによって面していたものによって包括されています。 PIM-SMのためのセキュリティで続くことにおける仕事である間、いくつかの問題がマルチキャストルーティングに関連した特にPIM-SMと共に提起されたことに注意する価値があります。 含んでいますが、これらの問題は制限されません:
(i). Unauthorized Senders
(i)。 権限のないSenders
(ii). Unauthorized Receivers
(ii。) 権限のない受信機
(iii). Unauthorized use of the RP
(iii。) RPの無断使用
(iv). Unauthorized "last hop" switching to shortest path tree.
(iv。) 最短パス木との権限のない「最後のホップ」の切り換え。
6.1. General Comments on Multicast Routing Protocol Security
6.1. マルチキャストルーティング・プロトコルセキュリティの概評
Historically, routing protocols used within the Internet have lacked strong authentication mechanisms [RFC1704]. In the late 1980s, analysis revealed that there were a number of security problems in Internet routing protocols then in use [BELLOVIN89]. During the early 1990s it became clear that adversaries were selectively attacking various intra-domain and inter-domain routing protocols (e.g. via TCP session stealing of BGP sessions) [CERTCA9501, RFC1636]. More recently, cryptographic authentication mechanisms have been developed for RIPv2, OSPF, and the proprietary EIGRP routing protocols. BGP protection, in the form of a Keyed MD5 option for TCP, has also become widely deployed.
歴史的に、インターネットの中で使用されたルーティング・プロトコルは強い認証機構[RFC1704]を欠いていました。 1980年代後半に、分析は、次に、使用中のインターネットルーティング・プロトコル[BELLOVIN89]には多くの警備上の問題があったのを明らかにしました。 1990年代前半の間、敵が選択的に、様々なイントラドメインと相互ドメインルーティング・プロトコル(例えば、BGPセッションのTCPセッション横取りを通した)[CERTCA9501、RFC1636]を攻撃していたのは明確になりました。 より最近、暗号の認証機構はRIPv2、OSPF、および独占EIGRPルーティング・プロトコルのために開発されました。 また、BGP保護はTCPのためのKeyed MD5オプションの形で広く配布されるようになりました。
At present, most multicast routing protocols lack strong cryptographic protection. One possible approach to this is to incorporate a strong cryptographic protection mechanism (e.g. Keyed HMAC MD5 [RFC2104]) within the routing protocol itself. Alternately, the routing protocol could be designed and specified to use the IP Authentication Header (AH) [RFC1825, RFC1826, RFC2085] to provide cryptographic authentication.
現在のところ、ほとんどのマルチキャストルーティング・プロトコルが強い暗号の保護を欠いています。 これへの1つの可能なアプローチはルーティング・プロトコル自体の中に強い暗号の保護メカニズム(例えば、Keyed HMAC MD5[RFC2104])を組み込むことです。 交互に、暗号の認証を提供するのに、IP Authentication Header(AH)[RFC1825、RFC1826、RFC2085]を使用するためにルーティング・プロトコルを設計して、指定できました。
Because the intent of any routing protocol is to propagate routing information to other parties, confidentiality is not generally required in routing protocols. In those few cases where local security policy might require confidentiality, the use of the IP Encapsulating Security Payload (ESP) [RFC1825, RFC1827] is recommended.
どんなルーティング・プロトコルの意図もルーティング情報を相手に伝播することであるので、一般に、秘密性はルーティング・プロトコルで必要ではありません。 ローカルの安全保障政策が秘密性を必要とするかもしれないそれらのわずかな場合では、IP Encapsulating Security有効搭載量(超能力)[RFC1825、RFC1827]の使用はお勧めです。
Farinacci, et. al. Experimental [Page 5] RFC 2337 IP multicast over ATM using PIM April 1998
etファリナッチ、アル。 1998年4月にPIMを使用するATMの上の実験的な[5ページ]RFC2337IPマルチキャスト
Scalable dynamic multicast key management is an active research area at this time. Candidate technologies for scalable dynamic multicast key management include CBT-based key management [RFC1949] and the Group Key Management Protocol (GKMP) [RFC2093,RFC2094]. The IETF IP Security Working Group is actively working on GKMP extensions to the standards-track ISAKMP key management protocol being developed in the same working group.
このとき、スケーラブルなダイナミックなマルチキャストかぎ管理はアクティブな研究領域です。 スケーラブルなダイナミックなマルチキャストかぎ管理のための候補技術はCBTを拠点とするかぎ管理[RFC1949]とGroup Key Managementプロトコル(GKMP)[RFC2093、RFC2094]を含んでいます。 IETF IP Security作業部会は活発に同じワーキンググループで開発される標準化過程ISAKMPかぎ管理プロトコルへのGKMP拡張子に取り組んでいます。
7. References
7. 参照
[BELLOVIN89] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, pp. 32-48, April 1989.
[BELLOVIN89]S.Bellovin、「TCP/IPプロトコル群の警備上の問題」、ACMコンピュータCommunications Review、Volume19、Number2、ページ 32-48と、1989年4月。
[CERTCA9501] CERT, "IP Spoofing Attacks and Hijacked Terminal Connections", ftp://ftp.cert.org/cert_advisories/, January 1995.
[CERTCA9501]本命、「IPは攻撃とハイジャックされた端末のコネクションズを偽造する」 ftp://ftp.cert.org/cert_advisories/ 、1月1995日
[MARS] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks.", RFC 2022, November 1996.
[火星] アーミテージ、G.が「Multicastのために、UNIの上で3.0/3.1ベースのATM Networksをサポートする」、RFC2022、11月1996日
[PIM-SM] Estrin, D, et. al., "Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specification", Work in Progress.
[PIM-SM] et Estrin、D、アル、「独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください」 「プロトコル仕様」、処理中の作業。
[RFC1636] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture February 8-10, 1994", RFC 1636, June 1994.
[RFC1636] ブレーデン、R.、クラーク、D.、クロッカー、S.、およびC.Huitema、「インターネットアーキテクチャ1994年2月8日〜10日のセキュリティに関するIABワークショップのレポート」、RFC1636(1994年6月)。
[RFC1704] Haller, N., and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[RFC1704] ハラー、N.とR.アトキンソン、「インターネット認証」、RFC1704、1994年10月。
[RFC1825] Atkinson, R., "IP Security Architecture", RFC 1825, August 1995.
[RFC1825] アトキンソン、R.、「IPセキュリティー体系」、RFC1825、1995年8月。
[RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[RFC1826] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、1995年8月。
[RFC1827] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, August 1995.
[RFC1827]アトキンソン、R.、「セキュリティが有効搭載量であるとカプセル化するIP」、RFC1827、1995年8月。
[RFC1949] Ballardie, A., "Scalable Multicast Key Distribution", RFC1949, June 1996.
[RFC1949] Ballardie、A.、「スケーラブルなマルチキャスト主要な分配」、RFC1949、1996年6月。
[RFC2085] Oehler, M., and R. Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", RFC 2085, February 1997.
1997年2月の[RFC2085]オーラー、M.とR.グレン、「再生防止とのHMAC-MD5IP認証」RFC2085。
Farinacci, et. al. Experimental [Page 6] RFC 2337 IP multicast over ATM using PIM April 1998
etファリナッチ、アル。 1998年4月にPIMを使用するATMの上の実験的な[6ページ]RFC2337IPマルチキャスト
[RFC2093] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC2093] ハーニー、H.、およびC.Muckenhirn、「グループKey Managementプロトコル(GKMP)仕様」、RFC2093、1997年7月。
[RFC2094] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
[RFC2094] ハーニー、H.、およびC.Muckenhirn、「グループKey Managementプロトコル(GKMP)アーキテクチャ」、RFC2094、1997年7月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2225] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
[RFC2225] Laubach、M.、J.アルペルン、および「気圧での古典的なIPとARP」、RFC2225、4月1998日
8. Acknowledgments
8. 承認
Petri Helenius provided several insightful comments on earlier versions of this document.
ペトリHeleniusはこのドキュメントの以前のバージョンのいくつかの洞察に満ちたコメントを提供しました。
9. Author Information
9. 作者情報
Dino Farinacci Cisco Systems 170 Tasman Dr. San Jose, CA 95134
サンノゼ、ディーノファリナッチシスコシステムズ170タスマン博士カリフォルニア 95134
Phone: (408) 526-4696 EMail: dino@cisco.com
以下に電話をしてください。 (408) 526-4696 メールしてください: dino@cisco.com
David Meyer Cisco Systems 170 Tasman Dr. San Jose, CA 95134
サンノゼ、デヴィッドマイヤーシスコシステムズ170タスマン博士カリフォルニア 95134
Phone: (541) 687-2581 EMail: dmm@cisco.com
以下に電話をしてください。 (541) 687-2581 メールしてください: dmm@cisco.com
Yakov Rekhter cisco Systems, Inc. 170 Tasman Dr. San Jose, CA 95134
サンノゼ、ヤコフRekhterコクチマスSystems Inc.170タスマン博士カリフォルニア 95134
Phone: (914) 528-0090 EMail: yakov@cisco.com
以下に電話をしてください。 (914) 528-0090 メールしてください: yakov@cisco.com
Farinacci, et. al. Experimental [Page 7] RFC 2337 IP multicast over ATM using PIM April 1998
etファリナッチ、アル。 1998年4月にPIMを使用するATMの上の実験的な[7ページ]RFC2337IPマルチキャスト
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Farinacci, et. al. Experimental [Page 8]
etファリナッチ、アル。 実験的[8ページ]
一覧
スポンサーリンク