RFC3069 日本語訳
3069 VLAN Aggregation for Efficient IP Address Allocation. D.McPherson, B. Dykes. February 2001. (Format: TXT=14891 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. McPherson
Request for Comments: 3069 Amber Networks, Inc.
Category: Informational B. Dykes
Onesecure, Inc.
February 2001
コメントを求めるワーキンググループD.マクファーソン要求をネットワークでつないでください: 3069 こはくはInc.カテゴリをネットワークでつなぎます: 情報のB.堤防Onesecure Inc.2001年2月
VLAN Aggregation for Efficient IP Address Allocation
効率的なIPアドレス配分のためのVLAN集合
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document introduces the concept of Virtual Local Area Network (VLAN) aggregation as it relates to IPv4 address allocation. A mechanism is described by which hosts that reside in the same physical switched infrastructure, but separate virtual broadcast domains, are addressed from the same IPv4 subnet and share a common default gateway IP address, thereby removing the requirement of a dedicated IP subnet for each virtual Local Area Network (LAN) or Metropolitan Area Network (MAN).
このドキュメントはIPv4アドレス配分に関係づけるようにVirtualローカル・エリア・ネットワーク(VLAN)集合の概念を紹介します。 メカニズムは同じ物理的な切り換えられたインフラストラクチャで住んでいるどのホストによって説明されるか、仮想の放送ドメインを切り離して、同じIPv4サブネットから扱われて、一般的なデフォルトゲートウェイIPアドレスを共有するのを除いて、その結果、各仮想のローカル・エリア・ネットワーク(LAN)かMetropolitan Area Network(MAN)のためにひたむきなIPサブネットの要件を取り除きます。
Employing such a mechanism significantly decreases IPv4 address consumption in virtual LANs and MANs. It may also ease administration of IPv4 addresses within the network.
そのようなメカニズムを使うと、IPv4アドレス消費はバーチャルLANとMANsをかなり下がります。 また、それはネットワークの中で管理からIPv4アドレスを除くかもしれません。
1. Introduction
1. 序論
The VLAN [802.1Q] aggregation technique described in this document provides a mechanism by which hosts that reside within the same physical switched infrastructure, but separate virtual broadcast domains, may be addressed from the same IPv4 subnet and may share a common default gateway IPv4 address.
本書では説明されたVLAN[802.1Q]集合のテクニックは同じ物理的な切り換えられたインフラストラクチャの中に住んでいますが、仮想の放送ドメインを切り離すホストが同じIPv4サブネットから扱われて、一般的なデフォルトゲートウェイIPv4アドレスを共有するかもしれないメカニズムを提供します。
Such a mechanism provides several advantages over traditional IPv4 addressing architectures employed in large switched LANs today. The primary advantage, that of IPv4 address space conservation, can be realized when considering the diagram in Figure 1:
そのようなメカニズムは今日大きい切り換えられたLANで使われている伝統的なIPv4アドレッシング体系よりいくつかの利点を提供します。 図1のダイヤグラムを考えるとき、プライマリ利点(IPv4アドレス空間保護のもの)を実現できます:
McPherson & Dykes Informational [Page 1] RFC 3069 VLAN Aggregation for IP Address Allocation February 2001
IPのためのマクファーソンとダイクス情報[1ページ]のRFC3069VLAN Aggregationは、配分2月が2001であると扱います。
Figure 1:
図1:
+------+ +------+ +------+ +------+ +------+
| | | | | | | | | |
| A.1 | | A.2 | | B.1 | | C.1 | | B.2 |
| | | | | | | | | |
+------+ +------+ +------+ +------+ +------+
\ | | | /
\ | | | /
\ +-----------------------------------+ /
| |
| Ethernet Switch(es) |
| |
+-----------------------------------+
|
|
+--------+
| |
| Router |
| |
+--------+
+------+ +------+ +------+ +------+ +------+ | | | | | | | | | | | A.1| | A.2| | B.1| | C.1| | B.2| | | | | | | | | | | +------+ +------+ +------+ +------+ +------+ \ | | | / \ | | | / \ +-----------------------------------+ / | | | イーサネットスイッチ(es)| | | +-----------------------------------+ | | +--------+ | | | ルータ| | | +--------+
In the Figure 1 hosts A.1 and A.2 belong to customer A, VLAN A. Hosts B.1 and B.2 belong to customer B, VLAN B. Host C.1 belongs to customer C and resides in it's own virtual LAN, VLAN C.
顧客A、VLAN A.Hosts B.1、およびB.2がA.1とA.2がものである図1ホストでは、顧客Bのものであり、VLAN B.Host C.1は顧客Cのものて、それの自己のバーチャルLAN(VLAN C)で住んでいます。
Traditionally, an IP subnet would be allocated for each customer, based on initial IP requirements for address space utilization, as well as on projections of future utilization. For example, a scheme such as that illustrated in Table 1 may be used.
伝統的に、各顧客のためにIPサブネットを割り当てるでしょう、アドレス空間利用、および今後の利用の映像に関する初期のIP要件に基づいて。 例えば、Table1で例証されたそれなどの体系は使用されるかもしれません。
Table 1:
Gateway Usable Customer
Customer IP Subnet Address Hosts Hosts
======== ============ ======= ====== ========
A 1.1.1.0/28 1.1.1.1 14 13
B 1.1.1.16/29 1.1.1.17 6 5
C 1.1.1.24/30 1.1.1.25 2 1
テーブル1: ゲートウェイの使用可能な顧客顧客IPサブネットアドレスはホストを接待します。======== ============ ======= ====== ======== 1.1.1.0/28 1.1.1.1 14 13B1.1.1.16/29 1.1.1.17 6 5C1.1.1.24/30 1.1.1.25 2 1
Customer A's initial deployment consists of 2 hosts, though they project growth of up to 10 hosts. As a result, they're allocated the IP subnet 1.1.1.0/28 which provides 16 IP addresses. The first IP address, 1.1.1.0, represents the subnetwork number. The last IP address, 1.1.1.15, represents the directed broadcast address. The first usable address of the subnet, 1.1.1.1, is assigned to the router and serves as the default gateway IP address for the subnet. The customer is left 13 IP addresses, even though their requirement was only for 10 IP addresses.
彼らは最大10人のホストの成長を映し出しますが、顧客Aの初期の展開は2人のホストから成ります。 その結果、IPサブネット1.1をそれらに割り当てます。.1 16のIPアドレスを提供する.0/28。 最初のIPアドレス、1.1 .1 .0 サブネットワーク番号を表します。 最後のIPアドレス、1.1 .1 .15 指示された放送演説を表します。 サブネットの最初の使用可能なアドレス、1.1 .1 .1 ルータに割り当てられて、サブネットのためのデフォルトゲートウェイIPアドレスとして機能します。 それらの要件は10のIPアドレスのためだけのものでしたが、顧客は13のIPアドレスに置き去りにされます。
McPherson & Dykes Informational [Page 2] RFC 3069 VLAN Aggregation for IP Address Allocation February 2001
IPのためのマクファーソンとダイクス情報[2ページ]のRFC3069VLAN Aggregationは、配分2月が2001であると扱います。
Customer B's initial deployment consists of 2 hosts, though they project growth of up to 5 hosts. As a result, they're allocated the IP subnet 1.1.1.16/29 which provides 8 IP addresses. The first IP address, 1.1.1.16, represents the subnetwork number. The last IP address, 1.1.1.23, represents the directed broadcast address. The first usable address of the subnet, 1.1.1.17, is assigned to the router and serves as the default gateway IP address for the subnet. The customer is left 5 with IP addresses.
彼らは最大5人のホストの成長を映し出しますが、顧客のビーズの初期の展開は2人のホストから成ります。 その結果、IPサブネット1.1をそれらに割り当てます。.1 8つのIPアドレスを提供する.16/29。 最初のIPアドレス、1.1 .1 .16 サブネットワーク番号を表します。 最後のIPアドレス、1.1 .1 .23 指示された放送演説を表します。 サブネットの最初の使用可能なアドレス、1.1 .1 .17 ルータに割り当てられて、サブネットのためのデフォルトゲートウェイIPアドレスとして機能します。 顧客はIPアドレスがある5に置き去りにされます。
Customer C's initial deployment consists of 1 host, and they have no plans of deploying additional hosts. As a result, they're allocated the IP subnet 1.1.1.24/30 which provides 4 IP addresses. The first IP address, 1.1.1.24, represents the subnetwork number. The last IP address, 1.1.1.27, represents the directed broadcast address. The first usable address of the subnet, 1.1.1.25, is assigned to the router and serves as the default gateway IP address for the subnet. The customer is left 1 IP address.
顧客Cの初期の展開は1人のホストから成ります、そして、彼らには、追加ホストを配布するプランが全くありません。 その結果、IPサブネット1.1をそれらに割り当てます。.1 4つのIPアドレスを提供する.24/30。 最初のIPアドレス、1.1 .1 .24 サブネットワーク番号を表します。 最後のIPアドレス、1.1 .1 .27 指示された放送演説を表します。 サブネットの最初の使用可能なアドレス、1.1 .1 .25 ルータに割り当てられて、サブネットのためのデフォルトゲートウェイIPアドレスとして機能します。 顧客は1つのIPアドレスに置き去りにされます。
The sum of address requirements for all three customers is 16. The most optimal address allocation scheme here requires 28 IP addresses.
すべての3人の顧客のためのアドレス要件の合計は16です。 ここの最も最適のアドレス配分体系は28のIPアドレスを必要とします。
Now, if customer A only grows to use 3 of his available address, the additional IP addresses can't be used for other customers.
現在、顧客Aが彼の3つの利用可能なアドレスを使用するようになるだけであるなら、他の顧客に追加IPアドレスを使用できません。
Also, assume customer C determines the need to deploy one additional host, and as such, requires one additional IP address. Because all of the addresses within the existing IP subnet 1.1.1.24/30 are used, and the following address space has been allocated to other customers, a new subnet is required. Ideally, the customer would be allocated a /29 and renumber host C.1 into the new subnet. However, the customer is of the opinion that renumbering is not a viable option. As such, another IP subnet is allocated to the customer, this time perhaps a /29, providing two additional addresses for future use.
また、顧客がCであると仮定してください。そういうものとして1人の追加ホストを配布する必要性を決定して、1つの追加IPアドレスを必要とします。 既存のIPサブネット1.1.1.24/30の中のアドレスのすべてが使用されていて、以下のアドレス空間を他の顧客に割り当てたので、新しいサブネットが必要です。 理想的に、顧客は、/29を割り当てて、新しいサブネットにホストC.1に番号を付け替えさせるでしょう。 しかしながら、顧客は番号を付け替えるのが実行可能なオプションでないという意見です。 そういうものとして、別のIPサブネットを顧客に割り当てて、今回は恐らく/29です、今後の使用のための2つの追加アドレスを提供して。
As you can see, the number of IP addresses consumed by the subnetwork number, directed broadcast address, and a unique gateway address for each subnet is quite significant. Also, the inherent constraints of the addressing architecture significantly reduce flexibility.
お分かりのように、各サブネットのためのサブネットワーク番号、指示された放送演説、およびユニークなゲートウェイアドレスによって消費されたIPアドレスの数はかなり重要です。 また、アドレッシング体系の固有の規制は柔軟性をかなり減少させます。
2. Discussion
2. 議論
If within the switched environment, on the routed side of the network, we introduce the notion of sub-VLANs and super-VLANs, a much more optimal approach to IP addressing can be realized.
私たちがネットワークの発送された側面で切り換えられた環境の中でサブVLANsと超VLANsの概念を紹介するなら、IPアドレシングへのはるかに最適のアプローチを実現できます。
McPherson & Dykes Informational [Page 3] RFC 3069 VLAN Aggregation for IP Address Allocation February 2001
IPのためのマクファーソンとダイクス情報[3ページ]のRFC3069VLAN Aggregationは、配分2月が2001であると扱います。
Essentially, what occurs is that each sub-VLAN (customer) remains within a separate broadcast domain. One or more sub-VLANs belong to a super-VLAN, and utilize the default gateway IP address of the super-VLAN. Hosts within the sub-VLANs are numbered out of IP subnets associated with the super-VLAN, and their IP subnet masking information reflects that of the super-VLAN subnet.
本質的には、起こることはそれぞれのサブVLAN(顧客)が別々の放送ドメインに残っているということです。 1サブVLANsが超VLANに属して、超VLANのデフォルトゲートウェイIPアドレスを利用します。 サブVLANsの中のホストは超VLANに関連しているIPサブネットから付番されます、そして、それらのIPサブネットマスキング情報は超VLANサブネットのものを反映します。
If desired, the super-VLAN router performs functions similar to Proxy ARP to enable communication between hosts that are members of different sub-VLANs.
望まれているなら、超VLANルータは、異なったサブVLANsのメンバーであるホストのコミュニケーションを可能にするためにProxy ARPと同様の機能を実行します。
This model results in a much more efficient address allocation architecture. It also provides network operators with a mechanism to provide standard default gateway address assignments.
このモデルははるかに効率的なアドレス配分アーキテクチャをもたらします。 また、それは、標準省略時解釈ゲートウェイアドレス課題を提供するためにメカニズムをネットワーク・オペレータに提供します。
Let's again consider Figure 1, now utilizing the super-VLAN sub-VLAN model. Table 2 provides the new addressing model.
再び、現在超VLANサブVLANモデルを利用して、図1を考えましょう。 テーブル2は新しいアドレシングモデルを提供します。
Table 2:
Gateway Usable Customer
Customer IP Subnet Address Hosts Hosts
======== ============ ======= ====== ========
A 1.1.1.0/24 1.1.1.1 10 .2-.11
B 1.1.1.0/24 1.1.1.1 5 .12-.16
C 1.1.1.0/24 1.1.1.1 1 .17
テーブル2: ゲートウェイの使用可能な顧客顧客IPサブネットアドレスはホストを接待します。======== ============ ======= ====== ======== 1.1.1.0/24 1.1.1.1 10.2.11B1.1.1.0/24 1.1.1.1 5.12.16C1.1.1.0/24 1.1.1.1 1.17
Customer A's initial deployment consists of 2 hosts, though they project growth of up to 10 hosts. As a result, they're allocated the IP address range 1.1.1.2 - 1.1.1.11. The gateway address for the customer is 1.1.1.1, the subnet is 1.1.1.0/24.
彼らは最大10人のホストの成長を映し出しますが、顧客Aの初期の展開は2人のホストから成ります。 その結果、.2--1.1にIPアドレス範囲1.1.1をそれらに割り当てます。.1 .11。 .1、サブネットはそうです。顧客のためのゲートウェイアドレスが1.1である、.1、1.1 .1 .0/24。
Customer B's initial deployment consists of 2 hosts, though they project growth of up to 5 hosts. As a result, they're allocated the IP address range 1.1.1.12 - 1.1.1.16. The gateway address for the customer is 1.1.1.1, the subnet is 1.1.1.0/24.
彼らは最大5人のホストの成長を映し出しますが、顧客のビーズの初期の展開は2人のホストから成ります。 その結果、.12--1.1にIPアドレス範囲1.1.1をそれらに割り当てます。.1 .16。 .1、サブネットはそうです。顧客のためのゲートウェイアドレスが1.1である、.1、1.1 .1 .0/24。
Customer C's initial deployment consists of 1 host, and they have no plans of deploying additional hosts. As a result, they're allocated the IP address 1.1.1.17. The gateway address for the customer is 1.1.1.1, the subnet is 1.1.1.0/24.
顧客Cの初期の展開は1人のホストから成ります、そして、彼らには、追加ホストを配布するプランが全くありません。 その結果、.17にIPアドレス1.1.1にそれらを割り当てます。 .1、サブネットはそうです。顧客のためのゲートウェイアドレスが1.1である、.1、1.1 .1 .0/24。
The sum of address requirements for all three customers is 16. As a result, only 16 addresses are allocated within the subnet. These 16 addresses, combined with the global default gateway address of 1.1.1.1, as well as the subnetwork number of 1.1.1.0 and directed broadcast of 1.1.1.255, result in a total of 19 addresses used. This leaves 236 additional usable hosts address with the IP subnet.
すべての3人の顧客のためのアドレス要件の合計は16です。 その結果、サブネットの中に16のアドレスだけを割り当てます。 1.1の1.1の.1の.0と指示された放送のサブネットワーク番号として噴出してください。.1がデフォルトゲートウェイが1.1を扱うグローバルに結合されたこれらの16のアドレス、.1、.1 .255、使用される合計19のアドレスの結果。 これは236人の追加使用可能なホストにIPサブネットがあるアドレスを残します。
McPherson & Dykes Informational [Page 4] RFC 3069 VLAN Aggregation for IP Address Allocation February 2001
IPのためのマクファーソンとダイクス情報[4ページ]のRFC3069VLAN Aggregationは、配分2月が2001であると扱います。
Now, if customer A only grows to use 3 of his available addresses, the additional IP addresses can be used for other customers.
現在、顧客Aが彼の3つの利用可能なアドレスを使用するようになるだけであるなら、他の顧客に追加IPアドレスを使用できます。
Also, assume customer C determines the need to deploy one additional host, and as such, requires one additional IP address. The customer is simply allocated the next available IP address within the subnet, their default gateway remains the same.
また、顧客がCであると仮定してください。そういうものとして1人の追加ホストを配布する必要性を決定して、1つの追加IPアドレスを必要とします。 サブネットの中に単に次の利用可能なIPアドレスを顧客に割り当てて、それらのデフォルトゲートウェイは同じままで残っています。
The benefits of such a model are obvious, especially when employed in large LANs or MANs.
特に大きいLANかMANsで使われると、そのようなモデルの利益は明白です。
3. Use of Directed Broadcasts
3. 指示された放送の使用
This specification provides no support for directed broadcasts. Specifically, the <net, subnet, -1> directed broadcast address can only apply to one of the Layer 2 broadcast domains.
この仕様は指示された放送のサポートを全く提供しません。 <ネット、サブネット、明確に指示された放送演説がLayer2放送ドメインの1つに当てはまることができるだけである-1>。
Though use of directed broadcast is frowned upon in the Internet today, there remain a number of applications, primarily in the enterprise arena, that continue to use them. As such, care should be taken to understand the implications of using these applications in conjunction with the addressing model outlined in this specification.
指示された放送の使用は今日インターネットで反対されますが、主として企業アリーナのそれらを使用し続けている応募件数は残っています。 そういうものとして、この仕様に概説されたアドレシングモデルに関連してこれらのアプリケーションを使用する含意を理解するために注意するべきです。
4. Multicast Considerations
4. マルチキャスト問題
It is assumed that the Layer 2 multicast domain will be the same as the Layer 2 broadcast domain (i.e., VLAN). As such, this means that for an IP multicast packet to reach all potential receivers in the IP subnet the multicast router(s) attached to the IP subnet need to employ something akin to IP host routes for the sender in order for the Reverse Path Forwarding check to work.
Layer2マルチキャストドメインがLayer2放送ドメイン(すなわち、VLAN)と同じになると思われます。 そういうものとして、IPマルチキャストパケットが扱うIPサブネットに付けられたマルチキャストルータがIPホストルートと何か同系であるものを使うのにReverse Path Forwardingチェックにおいて、整然としている送付者が必要があるIPサブネットですべての潜在的受信機に達するように、これはそれを意味します。
5. Deployment Considerations
5. 展開問題
Extreme Networks has a working implementation of this model that has been deployed in service provider data center environments for over a year now. Other vendors are rumored to be developing similar functionality.
極端なNetworksには、現在、1年間以上使用中のプロバイダーデータセンター環境であると配布されたこのモデルの働く実装があります。 他のベンダーは展開している同様の機能性であると噂されています。
6. Security Considerations
6. セキュリティ問題
One obvious issue that does arise with this model is the vulnerabilities created by permitting arbitrary allocation of addresses across disparate broadcast domains. It is advised that address space ranges be made sticky. That is, when an address or range of addresses is allocated to a given sub-VLAN, reception of IP
このモデルと共に起こる明白な1冊は異種の放送ドメインの向こう側にアドレスの任意の配分を可能にすることによって作成された脆弱性です。 アドレス空間範囲をねばねばするようにすると忠告されます。 アドレスのアドレスか範囲を与えられたサブVLANに割り当てるとき、それはIPの受付です。
McPherson & Dykes Informational [Page 5] RFC 3069 VLAN Aggregation for IP Address Allocation February 2001
IPのためのマクファーソンとダイクス情報[5ページ]のRFC3069VLAN Aggregationは、配分2月が2001であると扱います。
or ARP packets on a sub-VLAN with a source IP address that isn't allocated to the sub-VLAN should be discarded, and perhaps trigger a logging message or other administrative event.
または、サブVLANに割り当てられないソースIPアドレスがあるサブVLANの上のARPパケットは、捨てられて、恐らく伐採メッセージか他の管理イベントの引き金となるはずです。
Implementation details are intentionally omitted as all functions in this document should remain local to the super-VLAN router. As such, no interoperability issues with existing protocols should result.
すべての機能が本書では超VLANルータに地方のままで残るべきであるので、実装の詳細は故意に省略されます。 そういうものとして、既存のプロトコルの相互運用性問題は全く結果として生じるべきではありません。
7. Acknowledgements
7. 承認
Thanks to Mike Hollyman and Erik Nordmark for their feedback.
それらのフィードバックをマイクHollymanとエリックNordmarkをありがとうございます。
8. References
8. 参照
[802.1Q] IEEE 802.1Q, "Virtual LANs".
[802.1Q]IEEE 802.1Q、「仮想のLAN。」
9. Authors' Addresses
9. 作者のアドレス
Danny McPherson Amber Networks, Inc. 48664 Milmont Drive Fremont, CA 94538
ダニーマクファーソンこはくはInc.48664Milmont Driveフレモント、カリフォルニア 94538をネットワークでつなぎます。
EMail: danny@ambernetworks.com
メール: danny@ambernetworks.com
Barry Dykes OneSecure, Inc. 2000 S. Colorado Blvd Suite 2-1100 Denver, CO. 80222
2000秒間バリトンサックス堤防OneSecure Inc.コロラドBlvd Suite2-1100デンバー、CO80222
EMail: bdykes@onesecure.com
メール: bdykes@onesecure.com
McPherson & Dykes Informational [Page 6] RFC 3069 VLAN Aggregation for IP Address Allocation February 2001
IPのためのマクファーソンとダイクス情報[6ページ]のRFC3069VLAN Aggregationは、配分2月が2001であると扱います。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 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機能のための基金は現在、インターネット協会によって提供されます。
McPherson & Dykes Informational [Page 7]
マクファーソンとダイクスInformationalです。[7ページ]
一覧
スポンサーリンク
