RFC3307 日本語訳
3307 Allocation Guidelines for IPv6 Multicast Addresses. B. Haberman. August 2002. (Format: TXT=15742 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Haberman Request for Comments: 3307 Consultant Category: Standards Track August 2002
コメントを求めるワーキンググループB.ハーバーマンの要求をネットワークでつないでください: 3307年のコンサルタントカテゴリ: 標準化過程2002年8月
Allocation Guidelines for IPv6 Multicast Addresses
IPv6マルチキャストアドレスのための配分ガイドライン
Status of this Memo
この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 Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document specifies guidelines that must be implemented by any entity responsible for allocating IPv6 multicast addresses. This includes, but is not limited to, any documents or entities wishing to assign permanent IPv6 multicast addresses, allocate dynamic IPv6 multicast addresses, and define permanent IPv6 multicast group identifiers. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the MAC layer address.
このドキュメントはマルチキャストアドレスをIPv6に割り当てるのに原因となるどんな実体でも実装しなければならないガイドラインを指定します。 どんなドキュメントや実体も永久的なIPv6マルチキャストアドレスを割り当てたがっていて、ダイナミックなIPv6マルチキャストアドレスを割り当てるために制限されないで、永久的なIPv6マルチキャストグループ識別子を定義するのを除いたこのインクルード。 これらのガイドラインの目的はIPv6層で減少するだけではなく、IP層のアドレスの部分をMAC層のアドレスにコード化するメディアのリンクレイヤでもIPv6マルチキャストアドレス衝突の確率を減少させることです。
Haberman Standards Track [Page 1] RFC 3307 IPv6 Multicast Addresses Guidelines August 2002
ハーバーマン標準化過程[1ページ]RFC3307IPv6マルチキャストは、ガイドライン8月が2002であると扱います。
Table of Contents
目次
1. Terminology.....................................................2 2. Introduction....................................................2 3. Applicability...................................................3 4. Group ID Selection Guidelines...................................3 4.1 Permanent IPv6 Multicast Addresses............................4 4.2 Permanent IPv6 Multicast Group Identifiers....................4 4.3 Dynamic IPv6 Multicast Addresses..............................4 4.3.1 Server Allocation............................................5 4.3.2 Host Allocation..............................................5 5. IANA Considerations.............................................5 6. Security Considerations.........................................6 7. Acknowledgements................................................6 8. References......................................................6 Author's Address...................................................7 Full Copyright Statement...........................................8
1. 用語…2 2. 序論…2 3. 適用性…3 4. ID選択ガイドラインを分類してください…3 4.1 永久的なIPv6マルチキャストアドレス…4 4.2 永久的なIPv6マルチキャストグループ識別子…4 4.3 ダイナミックなIPv6マルチキャストアドレス…4 4.3 .1 サーバ配分…5 4.3 .2 配分を主催してください…5 5. IANA問題…5 6. セキュリティ問題…6 7. 承認…6 8. 参照…6作者のアドレス…7 完全な著作権宣言文…8
1. Terminology
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
The term "group ID", throughout this document, conforms to the definition contained in [UNIMCAST], that is, the low-order 32 bits of the IPv6 multicast address.
「グループID」という用語はこのドキュメント中で[UNIMCAST](すなわち、IPv6マルチキャストアドレスの下位の32ビット)に含まれた定義に従います。
2. Introduction
2. 序論
This document specifies guidelines that MUST be implemented by any entity responsible for allocating IPv6 multicast addresses. This includes, but is not limited to, any documents or entities wishing to assign permanent IPv6 multicast addresses, allocate dynamic IPv6 multicast addresses, and define permanent IPv6 multicast group identifiers. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the link-layer address.
このドキュメントはマルチキャストアドレスをIPv6に割り当てるのに原因となるどんな実体でも実装しなければならないガイドラインを指定します。 どんなドキュメントや実体も永久的なIPv6マルチキャストアドレスを割り当てたがっていて、ダイナミックなIPv6マルチキャストアドレスを割り当てるために制限されないで、永久的なIPv6マルチキャストグループ識別子を定義するのを除いたこのインクルード。 これらのガイドラインの目的はIPv6層で減少するだけではなく、IP層のアドレスの部分をリンクレイヤアドレスにコード化するメディアのリンクレイヤでもIPv6マルチキャストアドレス衝突の確率を減少させることです。
With the current IPv6 address architecture [ADDRARCH] and the extension to the multicast address architecture specified in [UNIMCAST], a set of guidelines is needed for entities assigning any flavor of IPv6 multicast addresses.
現在のIPv6アドレス体系[ADDRARCH]と[UNIMCAST]で指定されたマルチキャストアドレス体系への拡大で、マニュアルがIPv6マルチキャストアドレスのどんな風味も割り当てる実体に必要です。
The current approach of several physical media [RFC 2464][RFC 2467] is to map a portion of the IPv6 multicast address into a link-layer destination address. This is accomplished by taking the low order 32
いくつかの物理的なメディア[RFC2464][RFC2467]の現在のアプローチはIPv6マルチキャストアドレスの部分をリンクレイヤ送付先アドレスに写像することです。 これは、下位32を取ることによって、達成されます。
Haberman Standards Track [Page 2] RFC 3307 IPv6 Multicast Addresses Guidelines August 2002
ハーバーマン標準化過程[2ページ]RFC3307IPv6マルチキャストは、ガイドライン8月が2002であると扱います。
bits (henceforth called the group ID) of the IPv6 multicast address and including them in the link-layer destination address. Group IDs, less than or equal to, 32 bits long will generate unique link-layer addresses within a given multicast scope.
リンクレイヤ送付先アドレスのIPv6マルチキャストアドレスとそれらを含むビット(今後は、IDにグループに電話をします)。 長さ32ビット以下のグループIDは、与えられたマルチキャスト範囲の中でユニークなリンクレイヤがアドレスであると生成するでしょう。
These guidelines specify how the group ID of the IPv6 multicast address are chosen and assigned. The guidelines specify several mechanisms that can be used to determine the group ID of the multicast address, based on the type of allocation being done.
これらのガイドラインはIPv6マルチキャストアドレスのグループIDが選ばれてどう割り当てられるかを指定します。 ガイドラインはマルチキャストアドレスのグループIDを決定するのに使用できる数個のメカニズムを指定します、行われる配分のタイプに基づいて。
3. Applicability
3. 適用性
These guidelines are designed to be used in any environment in which IPv6 multicast addresses are delegated, assigned, or selected. These guidelines are not limited to use by MADCAP [RFC 2730] servers. The following is a non-exhaustive list of applications of these guidelines:
これらのガイドラインは、IPv6マルチキャストアドレスを代表として派遣するか、割り当てるか、または選択するどんな環境でも使用されるように設計されています。 これらのガイドラインは、MADCAP[RFC2730]でサーバを使用するために制限されません。 ↓これはこれらのガイドラインのアプリケーションに関する非完全なりストです:
- Source-specific multicast application servers can generate an
SSM group address by generating a 96-bit multicast prefix, as
defined in [UNIMCAST] (i.e. FF3x::/96) and concatenating that
with a group ID, as defined in this document.
- ソース特有のマルチキャストアプリケーション・サーバーは、SSMグループがアドレスであると96ビットのマルチキャスト接頭語を生成することによって、生成することができます、[UNIMCAST](すなわち、FF3x: : /96)で定義されて、グループIDでそれを連結するとして、本書では定義されるように。
- A MADCAP server allocates IPv6 multicast addresses conforming
to section 2.7 of [ADDRARCH], creating the group ID using the
rules defined in this document.
- MADCAPサーバは[ADDRARCH]のセクション2.7に従うマルチキャストアドレスをIPv6に割り当てます、本書では定義された規則を使用することでグループIDを作成して。
- Nodes supplying multicast services in a zeroconf environment
generate multicast addresses without the need of centralized
control.
- zeroconf環境におけるマルチキャストサービスを供給するノードが集中制御の必要性なしでマルチキャストアドレスを作ります。
- IANA can assign permanent multicast addresses to fulfill
requests via the protocol standardization process.
- IANAは、プロトコル標準化過程で要求を実現させるために永久的なマルチキャストアドレスを割り当てることができます。
4. Group ID Selection Guidelines
4. グループID選択ガイドライン
The Group ID selection process allows for three types of multicast address assignments. These are permanent IPv6 multicast addresses, dynamic IPv6 multicast addresses, and permanent IPv6 multicast group IDs. The following guidelines assume that the prefix of the multicast address has been initialized according to [ADDRARCH] or [UNIMCAST].
Group ID選択プロセスは3つのタイプのマルチキャストアドレスのために課題を許容します。 これらは、永久的なIPv6マルチキャストアドレスと、ダイナミックなIPv6マルチキャストアドレスと、永久的なIPv6マルチキャストグループIDです。 以下のガイドラインは、[ADDRARCH]か[UNIMCAST]に従ってマルチキャストアドレスの接頭語が初期化されたと仮定します。
Haberman Standards Track [Page 3] RFC 3307 IPv6 Multicast Addresses Guidelines August 2002
ハーバーマン標準化過程[3ページ]RFC3307IPv6マルチキャストは、ガイドライン8月が2002であると扱います。
4.1 Permanent IPv6 Multicast Addresses
4.1 永久的なIPv6マルチキャストアドレス
Permanent multicast addresses, like those defined in [RFC 2375], are allocated by IANA. These addresses will be assigned with group ID's, in the range of 0x00000001 to 0x3FFFFFFF, on an Expert Review basis.
[RFC2375]で定義されたもののように、永久的なマルチキャストアドレスはIANAによって割り当てられます。 これらのアドレスはグループIDのものと共にExpert Reviewベースで0×00000001の範囲で0x3FFFFFFFに割り当てられるでしょう。
Multicast addresses assigned by IANA MUST have the T bit set to 0 and the P bit set to 0.
IANA MUSTによって割り当てられたマルチキャストアドレスでTビットを0に設定します、そして、Pビットは0にセットしました。
4.2 Permanent IPv6 Multicast Group Identifiers
4.2 永久的なIPv6マルチキャストグループ識別子
Permanent group IDs allow for a global identifier of a particular service (e.g. Network Time Protocol (NTP) being assigned the group ID 0x40404040). The use of permanent group IDs differs from permanent multicast addresses in that a permanent group ID offers a global identifier for a service being offered by numerous servers.
永久的なグループIDはグローバルな特定にサービス(例えば、グループID0x40404040が割り当てられるNetwork Timeプロトコル(NTP))の識別子を考慮します。 永久的なグループIDの使用は永久的なグループIDが多数のサーバによって提供されるサービスのためにグローバルな識別子を提供するという点において永久的なマルチキャストアドレスと異なっています。
As an example, consider the NTP example group ID of 0x40404040. An NTP client would be able to access multiple servers and multiple scopes. That is, the NTP client will know that the group ID 0x40404040 identifies an NTP multicast stream regardless of the upper 96 bits of the multicast address.
例として、NTP例のグループが0×40404040のIDであると考えてください。 NTPクライアントは複数のサーバと複数の範囲にアクセスできるでしょう。 すなわち、NTPクライアントは、グループID0x40404040がマルチキャストアドレスの上側の96ビットにかかわらずNTPマルチキャストストリームを特定するのを知るでしょう。
Permanent group IDs are allocated on an Expert Review basis, in the range 0x40000000 to 0x7FFFFFFF. These permanent group IDs are meant to be used in IPv6 multicast addresses, defined in [UNIMCAST].
範囲0x40000000にExpert Reviewベースに永久的なグループIDを0x7FFFFFFFに割り当てます。 これらの永久的なグループIDは[UNIMCAST]で定義されたIPv6マルチキャストアドレスで使用されることになっています。
4.3 Dynamic IPv6 Multicast Addresses
4.3 ダイナミックなIPv6マルチキャストアドレス
Dynamic IPv6 multicast addresses can be allocated by an allocation server or by an end-host. Regardless of the allocation mechanism, all dynamically allocated IPv6 multicast addresses MUST have the T bit set to 1. This will distinguish the dynamically allocated addresses from the permanently assigned multicast addresses, defined in [RFC 2375], at the link-layer on any media that maps the lower portion of the IPv6 multicast address into a link-layer address. It should be noted that the high-order bit of the Group ID will be the same value as the T flag.
配分サーバか終わりホストがダイナミックなIPv6マルチキャストアドレスを割り当てることができます。 配分メカニズムにかかわらず、すべてのダイナミックに割り当てられたIPv6マルチキャストアドレスはTビットを1に設定しなければなりません。 これはどんなメディアのIPv6マルチキャストアドレスの下位部をリンクレイヤアドレスに写像するリンクレイヤでも[RFC2375]で定義された永久に割り当てられたマルチキャストアドレスとダイナミックに割り当てられたアドレスを区別するでしょう。 Group IDの高位のビットがT旗と同じ値になることに注意されるべきです。
As an example, the permanent IPv6 multicast address FF02::9 maps to an Ethernet group address of 33-33-00-00-00-09. A dynamically allocated IPv6 multicast address of FF32::8000:9 would map to the Ethernet group address 33-33-80-00-00-09.
例、永久的なIPv6マルチキャストアドレスFF02として:、:イーサネットへの9つの地図が33-33-00-00-00-09のアドレスを分類します。 FF32のダイナミックに割り当てられたIPv6マルチキャストアドレス:、:8000:9 イーサネットグループアドレス33-33-80-00-00-09に写像するでしょう。
Haberman Standards Track [Page 4] RFC 3307 IPv6 Multicast Addresses Guidelines August 2002
ハーバーマン標準化過程[4ページ]RFC3307IPv6マルチキャストは、ガイドライン8月が2002であると扱います。
4.3.1 Server Allocation
4.3.1 サーバ配分
The allocation of IPv6 multicast addresses, by a server, is defined in [RFC 2730]. Address management is the responsibility of the allocation protocol and outside the scope of this document. Allocation servers MUST use the group ID range 0x80000000 to 0xFFFFFFFF.
サーバで、IPv6マルチキャストアドレスの配分は[RFC2730]で定義されます。 アドレス管理は配分プロトコルの責任であり、外部はこのドキュメントの範囲です。 配分サーバはグループID範囲0x80000000を0xFFFFFFFFに使用しなければなりません。
4.3.2 Host Allocation
4.3.2 ホスト配分
Host-based allocation allows hosts to self-select IPv6 multicast addresses. One example of host-based allocation is the Zeroconf Multicast Address Allocation Protocol [ZMAAPDOC]. Issues with collision detection, claim notification, etc. are outside the scope of this document and the responsibility of the protocol being used, such as [ZMAAPDOC].
ホストベースの配分で、ホストは自己にIPv6マルチキャストアドレスを選択できます。 ホストベースの配分に関する1つの例がZeroconf Multicast Address Allocationプロトコル[ZMAAPDOC]です。 このドキュメントの範囲と使用されるプロトコルの責任の外で衝突検出、クレーム通知などの問題があります、[ZMAAPDOC]などのように。
The group ID portion of the address is created using either a pseudo-random 32-bit number or a 32-bit number created using the guidelines in [RFC 1750]. The generated group ID MUST fall in the range 0x80000000 to 0xFFFFFFFF. This can be accomplished by setting the high-order bit of the generated number to 1.
アドレスのグループID部分は、[RFC1750]のガイドラインを使用することで作成された擬似ランダムの32ビットの番号か32ビットの数のどちらかを使用することで作成されます。 発生しているグループIDは範囲0x80000000で0xFFFFFFFFに落下しなければなりません。 発生している数の高位のビットを1に設定することによって、これを達成できます。
5. IANA Considerations
5. IANA問題
This document requests the creation of a new registry maintained by IANA. This new registry will maintain permanent group ID values. The premise of this new registry is to allow for permanent group IDs to be used across multiple domains utilizing the multicast address architecture defined in [UNIMCAST]. The permanent group IDs will fall in the range 0x40000000 to 0x7FFFFFFF.
このドキュメントはIANAによって維持された新しい登録の作成を要求します。 この新しい登録は永久的なグループID値を維持するでしょう。 この新しい登録の前提は、永久的なグループIDがマルチキャストアドレス体系を利用する複数のドメインの向こう側に使用されるのを[UNIMCAST]で定義されていた状態で許容することになっています。 永久的なグループIDは範囲0x40000000で0x7FFFFFFFに落下するでしょう。
In addition, this document also defines rules for the allocation of permanent IPv6 multicast addresses by IANA. These rules specify different ranges for multicast addresses that are IPv6-only and for IPv6 multicast addresses that have corresponding IPv4 multicast addresses.
また、さらに、このドキュメントはIANAによる永久的なIPv6マルチキャストアドレスの配分のための規則を定義します。 これらの規則はIPv6専用であるマルチキャストアドレスと対応するIPv4マルチキャストアドレスを持っているIPv6マルチキャストアドレスに異なった範囲を指定します。
Following the policies outlined in [RFC 2434]:
[RFC2434]に概説された方針に従います:
- Permanent IPv6 multicast addresses with corresponding IPv4
multicast addresses, like those defined in [RFC 2375], are
allocated with group ID's in the range of 1 to 0x3FFFFFFF on an
Expert Review basis, see Section 4.1.
- アドレスが[RFC2375]で定義されたもののように割り当てられる対応するIPv4マルチキャストがある永久的なIPv6マルチキャストアドレスはExpert Reviewベースで1の範囲でIDのものを0x3FFFFFFFに分類します、とセクション4.1は見ます。
Haberman Standards Track [Page 5] RFC 3307 IPv6 Multicast Addresses Guidelines August 2002
ハーバーマン標準化過程[5ページ]RFC3307IPv6マルチキャストは、ガイドライン8月が2002であると扱います。
- Permanent IPv6-only multicast addresses are allocated with
group ID's in the range 0x100 to 0x3FFFFFFF on an Expert Review
basis.
- Permanent group ID's are allocated on an Expert Review basis in
the range 0x40000000 to 0x7FFFFFFF, see Section 4.2.
- The range 0x80000000 to 0xFFFFFFFF is reserved for use by
dynamic multicast address allocation mechanisms, see Section
4.3.
- グループIDのものと共にExpert Reviewベースに範囲0x100に永久的なIPv6だけマルチキャストアドレスを0x3FFFFFFFに割り当てます。 - セクション4.2は、永久的なIDのグループものが範囲0x40000000のExpert Reviewベースに0x7FFFFFFFに割り当てられるのを見ます。 - セクション4.3は、0xFFFFFFFFへの範囲0x80000000が使用のためにダイナミックなマルチキャストアドレス配分メカニズムによって予約されるのを見ます。
All approved requests for a permanent IPv6 multicast address will result in the assignment of a unique group ID which shall be reserved in all valid IPv6 multicast scopes.
永久的なIPv6マルチキャストアドレスを求めるすべての承認された要求がすべての有効なIPv6マルチキャスト範囲で予約されるものとするユニークなグループIDの課題をもたらすでしょう。
6. Security Considerations
6. セキュリティ問題
The allocation mechanisms described in this document do not alter the security properties of either the Any Source or Source Specific multicast service models of IPv4 and IPv6.
本書では説明された配分メカニズムはAny Sourceのセキュリティの特性かIPv4とIPv6のSource Specificマルチキャストサービスモデルを変更しません。
The potential to allocate large blocks of addresses can lead to Denial-of-Service attacks. A more in-depth discussion of the security issues surrounding dynamic allocation of multicast addresses can be found in [RFC 2908].
大量株のアドレスを割り当てる可能性はサービス不能攻撃につながることができます。 [RFC2908]で安全保障問題がマルチキャストアドレスの動的割当てを囲むより徹底的な議論を見つけることができます。
7. Acknowledgements
7. 承認
The author would like to thank Dave Thaler, Steve Deering, Allison Mankin, Thomas Narten, and Erik Nordmark for their thorough review of this document.
作者は彼らのこのドキュメントの徹底的なレビューについてデーヴThaler、スティーブ・デアリング、アリソン・マンキン、トーマスNarten、およびエリックNordmarkに感謝したがっています。
8. References
8. 参照
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[UNIMCAST] Haberman, B. and D. Thaler, "Unicast Prefix-based IPv6
Multicast Addresses", RFC 3306, June 2002.
[UNIMCAST] ハーバーマンとB.とD.ターレル、「ユニキャストの接頭語ベースのIPv6マルチキャストアドレス」、RFC3306、2002年6月。
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[ADDRARCH] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1999.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1999年3月。
[RFC 2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
December 1999.
[RFC2730] ハンナとS.とパテルとB.とM.シャー、「マルチキャストのアドレスのダイナミックなクライアント配分プロトコル(向こう見ず)」、RFC2730、1999年12月。
Haberman Standards Track [Page 6] RFC 3307 IPv6 Multicast Addresses Guidelines August 2002
ハーバーマン標準化過程[6ページ]RFC3307IPv6マルチキャストは、ガイドライン8月が2002であると扱います。
[RFC 2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC2464] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、1998年12月。
[RFC 2467] Crawford, M., "Transmission of IPv6 over FDDI Networks",
RFC 2467, December 1998.
[RFC2467] クロフォード、M.、「FDDIネットワークの上のIPv6のトランスミッション」、RFC2467、1998年12月。
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[RFC1750] イーストレークとD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[RFC 2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, July 1998.
[RFC2375] HindenとR.とS.デアリング、「IPv6マルチキャストアドレス課題」、RFC2375、1998年7月。
[RFC 2908] Thaler, D., Handley, M. and D. Estrin, "The Internet
Multicast Address Allocation Architecture", RFC 2908,
September 2000.
[RFC2908] ターレルとD.とハンドレーとM.とD.Estrin、「インターネットマルチキャストアドレス配分アーキテクチャ」、RFC2908、2000年9月。
[ZMAAPDOC] Catrina, et al, "Zeroconf Multicast Address Allocation
Protocol (ZMAAP)", Work In Progress.
[ZMAAPDOC]Catrina、他、「Zeroconfマルチキャストアドレス配分プロトコル(ZMAAP)」Work In Progress。
Author's Address
作者のアドレス
Brian Haberman Consultant Phone: 1-919-949-4828 EMail: bkhabs@nc.rr.com
ブライアンハーバーマンコンサルタント電話: 1-919-949-4828 メールしてください: bkhabs@nc.rr.com
Haberman Standards Track [Page 7] RFC 3307 IPv6 Multicast Addresses Guidelines August 2002
ハーバーマン標準化過程[7ページ]RFC3307IPv6マルチキャストは、ガイドライン8月が2002であると扱います。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Haberman Standards Track [Page 8]
ハーバーマン標準化過程[8ページ]
一覧
スポンサーリンク
