[要約] RFC 3021は、IPv4ポイントツーポイントリンクで31ビットプレフィックスを使用するためのガイドラインです。目的は、アドレス空間の効率的な使用と、ポイントツーポイントリンクのネットワーク設定の簡素化です。
Network Working Group A. Retana
Request for Comments: 3021 R. White
Category: Standards Track Cisco Systems
V. Fuller
GTE Internetworking
D. McPherson
Amber Networks
December 2000
Using 31-Bit Prefixes on IPv4 Point-to-Point Links
IPv4ポイントツーポイントリンクで31ビットプレフィックスを使用します
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way.
インターネット上のIPアドレススペースを節約するという圧倒的な圧力により、番号付けの効率を改善するために、フィールドプラクティスに対して比較的小さな変更を加えることができる場所を考慮することは理にかなっています。このドキュメントで提案されているそのような変更の1つは、31ビットサブネットマスクを非常に限られた方法で使用できるようにすることにより、ポイントツーポイントリンク（インターネットインフラ全体で共通）に割り当てられたアドレススペースの量を半分にすることです。
The perceived problem of a lack of Internet addresses has driven a number of changes in address space usage and a number of different approaches to solving the problem:
インターネットアドレスの欠如の知覚された問題は、アドレス空間使用量の多くの変更と、問題を解決するためのさまざまなアプローチを駆り立てました。
- More stringent address space allocation guidelines, enforced by the IANA and the regional address assignment authorities [RFC2050].
- IANAおよび地域住所の割り当て当局によって実施された、より厳しい住所スペース割り当てガイドライン[RFC2050]。
- Use of Network Address Translators (NATs), where a small number of IANA-compliant addresses are shared by a larger pool of private, non-globally routed addresses topologically behind a NAT box [RFC1631].
- ネットワークアドレス翻訳者（NAT）の使用。ここでは、IANAに準拠したアドレスが少数で、NATボックス[RFC1631]の後ろにトポロジカルに、非グロバシがルーティングされていないアドレスのより大きなプールによって共有されます。
- Deployment of a new Internet Protocol to increase the size of the address space. One such protocol, IPv6 [RFC2460], has been through the IETF process but has yet to see production deployment. Should it be, deployed, it will still face a many year transition period.
- アドレススペースのサイズを増やすための新しいインターネットプロトコルの展開。そのようなプロトコルの1つであるIPv6 [RFC2460]は、IETFプロセスを通過していますが、生産展開はまだ見ていません。展開した場合、それはまだ長年の移行期間に直面します。
Prior to the availability of a larger address space, it seems prudent to consider opportunities for making more efficient use of the existing address space.
より大きなアドレススペースが利用できる前に、既存のアドレススペースをより効率的に使用する機会を考慮することは賢明なようです。
One such (small) opportunity is to change the way that point-to-point links are numbered. One option, which is used today on some parts of the Internet, is to simply not number point-to-point links between routers. While this practice may seem, at first, to handily resolve the problem, it causes a number of problems of its own, including the inability to consistently manage the unnumbered link or reach a router through it, difficulty in management and debugging of those links, and the lack of standardization [RFC1812].
そのような（小さな）機会の1つは、ポイントツーポイントリンクに番号が付けられる方法を変更することです。現在、インターネットの一部の部分で使用されているオプションの1つは、ルーター間のポイントツーポイントリンクを単純にしないことです。このプラクティスは、最初は問題を便利に解決するように思われるかもしれませんが、それは、非数のリンクを一貫して管理できないこと、それを通してルーターに到達できないこと、管理の難しさとそれらのリンクのデバッグなど、独自の多くの問題を引き起こすように思われるかもしれませんが標準化の欠如[RFC1812]。
In current practice, numbered Internet subnets do not use longer than a 30-bit subnet mask (in most cases), which requires four addresses per link - two host addresses, one all-zeros network, and one all-ones broadcast. This is unfortunate for point-to-point links, since they can only possibly have two identifying endpoints and don't support the notion of broadcast - any packet which is transmitted by one end of a link is always received by the other.
現在の練習では、番号付きインターネットサブネットは、リンクごとに4つのアドレスを必要とする30ビットサブネットマスク（ほとんどの場合）を超えて使用しません。2つのホストアドレス、1つの全ゼロネットワーク、1つの全ゼロブロードキャストが必要です。これは、ポイントツーポイントリンクにとっては残念です。なぜなら、それらは2つの識別エンドポイントしか持っておらず、ブロードキャストの概念をサポートできない可能性があるため、リンクの一方の端で送信されるパケットは常に他方が受信します。
A third option is to use host addresses on both ends of a point-to-point link. This option provides the same address space savings as using a 31-bit subnet mask, but may only be used in links using PPP encapsulation [RFC1332]. The use of host addresses allows for the assignment of IP addresses belonging to different networks at each side of the link, causing link and network management not to be straight forward.
3番目のオプションは、ポイントツーポイントリンクの両端でホストアドレスを使用することです。このオプションは、31ビットサブネットマスクを使用するのと同じアドレススペースの節約を提供しますが、PPPカプセル化[RFC1332]を使用したリンクでのみ使用できます。ホストアドレスを使用すると、リンクの両側にある異なるネットワークに属するIPアドレスの割り当てが可能になり、リンクとネットワーク管理が簡単になりません。
This document is based on the idea that conserving IP addresses on point-to-point links (using longer than a 30-bit subnet mask) while maintaining manageability and standard interaction is possible. Existing documentation [RFC950] has already hinted at the possible use of a 1-bit wide host-number field.
このドキュメントは、管理性と標準的な相互作用を維持しながら、ポイントツーポイントリンクで（30ビットより長いサブネットマスクを使用する）ポイントツーポイントリンクでIPアドレスを保存することが可能であるという考えに基づいています。既存のドキュメント[RFC950]は、1ビットのワイドホスト番号フィールドの使用の可能性をすでに示唆しています。
The savings in address space resulting from this change is easily seen--each point-to-point link in a large network would consume two addresses instead of four. In a network with 500 point-to-point links, for example, this practice would amount to a savings of 1000 addresses (the equivalent of four class C address spaces).
この変更に起因するアドレススペースの節約は簡単に見られます。大きなネットワークでポイントツーポイントリンクは、4つではなく2つのアドレスを消費します。たとえば、500ポイントツーポイントリンクを持つネットワークでは、このプラクティスは1000のアドレス（4つのクラスCアドレススペースに相当）の節約になります。
This section discusses the possible effects, on Internet routing and operations, of using 31-bit prefixes on point-to-point links. The considerations made here are also reflected in Section 3.
このセクションでは、ポイントツーポイントリンクで31ビットプレフィックスを使用するインターネットルーティングと操作に対する可能な効果について説明します。ここで行われた考慮事項は、セクション3にも反映されています。
For the length of this document, an IP address will be interpreted as:
このドキュメントの長さについては、IPアドレスが次のように解釈されます。
<Network-number><Host-number>
where the <Host-number> represents the unmasked portion of the address and it SHOULD be at least 1 bit wide. The "-1" notation is used to mean that the field has all 1 bits. For purposes of this discussion, the routing system is considered capable of classless, or CIDR [RFC1519], routing.
<Host-Number>はアドレスのマスクされていない部分を表し、少なくとも1ビット幅である必要があります。「-1」表記は、フィールドにすべて1ビットがあることを意味するために使用されます。この議論の目的のために、ルーティングシステムはクラスレスまたはCIDR [RFC1519]がルーティングできると見なされます。
If a 31-bit subnet mask is assigned to a point-to-point link, it leaves the <Host-number> with only 1 bit. Consequently, only two possible addresses may result:
31ビットのサブネットマスクがポイントツーポイントリンクに割り当てられている場合、<Host-Number>は1ビットしか残りません。したがって、可能なアドレスは2つだけ生じる可能性があります。
{<Network-number>, 0} and {<Network-number>, -1}
These addresses have historically been associated with network and broadcast addresses (see Section 2.2). In a point-to-point link with a 31-bit subnet mask, the two addresses above MUST be interpreted as host addresses.
これらのアドレスは、歴史的にネットワークおよびブロードキャストアドレスに関連付けられてきました（セクション2.2を参照）。31ビットのサブネットマスクを使用したポイントツーポイントリンクでは、上記の2つのアドレスをホストアドレスとして解釈する必要があります。
There are several historically recognized broadcast addresses [RFC1812] on IP segments:
IPセグメントには、歴史的に認識されている放送アドレス[RFC1812]がいくつかあります。
(a) the directed broadcast
(a) 指示された放送
{<Network-number>, -1}
{<Network-number>, 0}
The network address itself {<Network-number>, 0} is an obsolete form of directed broadcast, but it may still be used by older hosts.
ネットワークアドレス自体{<Network-Number>、0}は、描かれた放送の時代遅れの形式ですが、古いホストではまだ使用される場合があります。
(b) the link local (or limited) broadcast
(b) Link Local（またはLimited）ブロードキャスト
{-1, -1}
{0, 0}
{0、0}
The {0, 0} form of a limited broadcast is obsolete, but may still be present in a network.
限られた放送の{0、0}形式は時代遅れですが、それでもネットワークに存在する可能性があります。
Using a 31-bit prefix length leaves only two numbering possibilities (see Section 2.1), eliminating the use of a directed broadcast to the link (see Section 2.2.1). The limited broadcast MUST be used for all broadcast traffic on a point-to-point link with a 31-bit subnet mask assigned to it.
31ビットのプレフィックスの長さを使用すると、2つの番号付けの可能性のみが残り（セクション2.1を参照）、リンクへの指示ブロードキャストの使用を排除します（セクション2.2.1を参照）。限られたブロードキャストは、31ビットのサブネットマスクが割り当てられたポイントツーポイントリンクのすべてのブロードキャストトラフィックに使用する必要があります。
The <Network-number> is assigned by the network administrator as unique to the local routing domain. The decision as to whether a destination IP address should be a directed broadcast or not is made by the router directly connected to the destination segment. Current forwarding schemes and algorithms are not affected in remote routers.
<Network-Number>は、ネットワーク管理者によってローカルルーティングドメインに固有のものとして割り当てられます。宛先IPアドレスが指示されたブロードキャストであるかどうかの決定は、宛先セグメントに直接接続されたルーターによって行われます。現在の転送スキームとアルゴリズムは、リモートルーターでは影響を受けません。
The intent of this document is to discuss the applicability and operation of 31-bit prefixes on point-to-point links. The effects (if any) on other types of interfaces are not considered.
このドキュメントの目的は、ポイントツーポイントリンクでの31ビットプレフィックスの適用性と操作について説明することです。他のタイプのインターフェイスに対する効果（ある場合）は考慮されません。
When a device wants to reach all the hosts on a given (remote, rather than directly connected) subnet, it may set the packet's destination address to the link's subnet broadcast address. This operation is not possible for point-to-point links with a 31-bit prefix.
デバイスが特定の（直接接続されていない）サブネットのすべてのホストに到達したい場合、パケットの宛先アドレスをリンクのサブネットブロードキャストアドレスに設定する場合があります。この操作は、31ビットプレフィックスを使用したポイントツーポイントリンクでは不可能です。
As discussed in Section 6, the loss of functionality of a directed broadcast may actually be seen as a beneficial side effect, as it slightly enhances the network's resistance to a certain class of DoS Attacks [RFC2644, SMURF].
セクション6で説明したように、指示された放送の機能の喪失は、特定のクラスのDOS攻撃に対するネットワークの抵抗をわずかに強化するため、実際に有益な副作用と見なされる可能性があります[RFC2644、Smurf]。
Networks with 31-bit prefixes have no impact on current routing protocols. Most of the currently deployed routing protocols have been designed to provide classless routing. Furthermore, the communication between peers is done using multicast, limited broadcast or unicast addresses (all on the local network), none of which are affected with the use of 31-bit subnet masks.
31ビットのプレフィックスを備えたネットワークは、現在のルーティングプロトコルに影響を与えません。現在展開されているルーティングプロトコルのほとんどは、クラスレスルーティングを提供するように設計されています。さらに、ピア間の通信は、マルチキャスト、限られたブロードキャスト、またはユニキャストアドレス（すべてローカルネットワーク上の）を使用して行われますが、どれも31ビットサブネットマスクの使用に影響されません。
The considerations presented in Section 2 affect other published work. This section details the updates made to other documents.
セクション2で提示された考慮事項は、他の公開された作品に影響します。このセクションでは、他のドキュメントに作成された更新について詳しく説明します。
Section 3.2.1.3 (e) is replaced with:
セクション3.2.1.3（e）は次のように置き換えられます。
(e) { <Network-number>, <Subnet-number>, -1 }
Directed broadcast to the specified subnet. It MUST NOT be used as a source address, except when the originator is one of the endpoints of a point-to-point link with a 31-bit mask.
指定されたサブネットへのブロードキャスト。オリジネーターが31ビットマスクを使用したポイントツーポイントリンクのエンドポイントの1つである場合を除き、ソースアドレスとして使用してはなりません。
A new section (numbered 3.2.1.3 (h)) is added:
新しいセクション（番号3.2.1.3（h））が追加されています。
(h) { <Network-number>, <Subnet-number>, 0 }
Subnetwork number. SHOULD NOT be used as a source address, except when the originator is one of the endpoints of a point-to-point link with a 31-bit mask. For other types of links, a packet with such a destination SHOULD be silently discarded. If these packets are not silently discarded, they MUST be treated as IP broadcasts [RFC1812].
サブネットワーク番号。オリジネーターが31ビットマスクを使用したポイントツーポイントリンクのエンドポイントの1つである場合を除き、ソースアドレスとして使用しないでください。他の種類のリンクの場合、そのような宛先を持つパケットは静かに廃棄する必要があります。これらのパケットが静かに廃棄されていない場合は、IP放送として扱わなければなりません[RFC1812]。
Sub-section (e) of the "Special Addresses" section in the "Introduction" is replaced with:
「はじめに」の「特別アドレス」セクションのサブセクション（e）は、次のものに置き換えられます。
(e) {<Network-number>, <Subnet-number>, -1}
Directed broadcast to specified subnet. Can only be used as a destination address. However, in the case where the originator is one of the endpoints of a point-to-point link with a 31-bit mask, it can also be used as a source address.
指定されたサブネットへのブロードキャスト。宛先アドレスとしてのみ使用できます。ただし、オリジネーターが31ビットマスクを使用したポイントツーポイントリンクのエンドポイントの1つである場合、ソースアドレスとしても使用できます。
Section 4.2.2.11 (d) is replaced with:
セクション4.2.2.11（d）は次のことに置き換えられます。
(d) { <Network-prefix>, -1 }
Directed Broadcast - a broadcast directed to the specified network prefix. It MUST NOT be used as a source address, except when the originator is one of the endpoints of a point- to-point link with a 31-bit mask. A router MAY originate Network Directed Broadcast packets. A router MAY have a configuration option to allow it to receive directed broadcast packets, however this option MUST be disabled by default, and thus the router MUST NOT receive Network Directed Broadcast packets unless specifically configured by the end user.
監督ブロードキャスト - 指定されたネットワークプレフィックスに向けられたブロードキャスト。オリジネーターが31ビットマスクを使用したポイントリンクのエンドポイントの1つである場合を除き、ソースアドレスとして使用してはなりません。ルーターは、ネットワーク指向ブロードキャストパケットを発信する場合があります。ルーターには、指示されたブロードキャストパケットを受信できるように設定オプションがある場合がありますが、このオプションはデフォルトで無効にする必要があるため、エンドユーザーが具体的に構成しない限り、ルーターはネットワーク指向ブロードキャストパケットを受信してはなりません。
The text above includes the update made by [RFC2644].
上記のテキストには、[RFC2644]によって作成された更新が含まれています。
A new section (numbered 4.2.2.11 (f)) is added:
新しいセクション（番号4.2.2.11（f））が追加されています。
(f) { <Network-number>, <Subnet-number>, 0 }
Subnetwork number. SHOULD NOT be used as a source address, except when the originator is one of the endpoints of a point-to-point link with a 31-bit mask. For other types of links, a packet with such a destination SHOULD be silently discarded. If these packets are not silently discarded, they MUST be treated as IP broadcasts.
サブネットワーク番号。オリジネーターが31ビットマスクを使用したポイントツーポイントリンクのエンドポイントの1つである場合を除き、ソースアドレスとして使用しないでください。他の種類のリンクの場合、そのような宛先を持つパケットは静かに廃棄する必要があります。これらのパケットが静かに破棄されていない場合、IP放送として扱う必要があります。
Sections 4.2.3.1 (1), (2) and (4) are replaced with:
セクション4.2.3.1（1）、（2）、および（4）は次のものに置き換えられます。
(1) MUST treat as IP broadcasts packets addressed to 255.255.255.255 or { <Network-prefix>, -1 }.
(1) 255.255.255.255または{<network -prefix>、-1}までアドレス指定されたIPブロードキャストパケットとして扱う必要があります。
In a point-to-point link with a 31-bit mask, a packet addressed to { <Network-prefix>, -1 } corresponds to one of the endpoints of such link, it MUST be treated as directed to the router on which the address is applied.
31ビットマスクを使用したポイントツーポイントリンクでは、{<Network-Prefix>、-1}にアドレス指定されたパケットは、そのようなリンクのエンドポイントの1つに対応しているため、ルーターに向けられたものとして扱われなければなりません。アドレスが適用されます。
(2) SHOULD silently discard on receipt (i.e., do not even deliver to applications in the router) any packet addressed to 0.0.0.0 or { <Network-prefix>, 0 }. If these packets are not silently discarded, they MUST be treated as IP broadcasts (see Section [5.3.5]). There MAY be a configuration option to allow receipt of these packets. This option SHOULD default to discarding them.
(2) 0.0.0.0または{<Network-Prefix>、0}にアドレス指定されたパケットは、領収書で静かに廃棄する必要があります（つまり、ルーター内のアプリケーションに配信しないでください）。これらのパケットが静かに廃棄されていない場合は、IP放送として扱わなければなりません（セクション[5.3.5]を参照）。これらのパケットの受領を許可する構成オプションがある場合があります。このオプションはデフォルトでそれらを破棄する必要があります。
In a point-to-point link with a 31-bit mask, a packet addressed to { <Network-prefix>, 0 } corresponds to one of the endpoints of such link, it MUST be treated as directed to the router on which the address is applied.
31ビットマスクを使用したポイントツーポイントリンクでは、{<Network-Prefix>、0}にアドレス指定されたパケットは、そのようなリンクのエンドポイントの1つに対応しているため、ルーターに向けられているように扱う必要があります。アドレスが適用されます。
(4) SHOULD NOT originate datagrams addressed to 0.0.0.0 or { <Network-prefix>, 0 }. There MAY be a configuration option to allow generation of these packets (instead of using the relevant 1s format broadcast). This option SHOULD default to not generating them.
(4) アドレス指定されたデータグラムを0.0.0.0または{<network-prefix>、0}に発信してはなりません。これらのパケットの生成を許可する構成オプションがある場合があります（関連する1S形式のブロードキャストを使用する代わりに）。このオプションはデフォルトで生成しないようにする必要があります。
In a point-to-point link with a 31-bit mask, the configuration of such a mask SHOULD allow for the generation of datagrams addressed to { <Network-prefix>, 0 }.
31ビットマスクを使用したポイントツーポイントリンクでは、このようなマスクの構成により、{<network-prefix>、0}にアドレス指定されたデータグラムの生成が可能になります。
The following text is added to section 4.3.3.9:
次のテキストをセクション4.3.3.9に追加します。
The 255.255.255.255 IP broadcast address MUST be used for broadcast Address Mask Replies in point-to-point links with 31-bit subnet masks
255.255.255.255 IPブロードキャストアドレスは、31ビットサブネットマスクを使用したポイントツーポイントリンクでのブロードキャストアドレスマスク応答に使用する必要があります
The recommendations presented in this document have been implemented by several router vendors in beta code. The implementation has been tested by at least three ISPs with positive results (i.e., no problems have been found). Among the routing protocols tested successfully are OSPF, IS-IS, BGP and EIGRP.
このドキュメントで提示された推奨事項は、ベータコードのいくつかのルーターベンダーによって実装されています。この実装は、少なくとも3つのISPによってテストされており、肯定的な結果が得られています（つまり、問題は見つかりませんでした）。正常にテストされたルーティングプロトコルの中には、OSPF、IS-IS、BGP、およびEIGRPがあります。
It is expected that the implementation will be officially released within the next few months and that other vendors will adopt it.
実装は今後数か月以内に公式にリリースされ、他のベンダーがそれを採用することが期待されています。
The intent of this document is to discuss the applicability and operation of 31-bit prefixes on point-to-point links. The effects (if any) on other types of interfaces are not considered. Note that a point-to-point link in which only one end supports the use of 31- bit prefixes may not operate correctly.
このドキュメントの目的は、ポイントツーポイントリンクでの31ビットプレフィックスの適用性と操作について説明することです。他のタイプのインターフェイスに対する効果（ある場合）は考慮されません。31ビットプレフィックスの使用をサポートする片端のみが正しく動作しない場合があるポイントツーポイントリンクであることに注意してください。
In the light of various denial of service (DoS) attacks on various networks within the Internet, security has become a major concern. The use of 31-bit subnet masks within the core of the Internet will reduce the number of physical links against which a DoS attack relying on packet replication through the use of directed broadcasts can be launched [RFC2644, SMURF].
インターネット内のさまざまなネットワークに対するさまざまなサービス拒否（DOS）攻撃に照らして、セキュリティが大きな関心事になりました。インターネットのコア内で31ビットサブネットマスクを使用すると、指示されたブロードキャストの使用を通じてパケットレプリケーションに依存するDOS攻撃が起動できる物理リンクの数を減らします[RFC2644、Smurf]。
Overall, implementation of this document recommendation will improve the Internet's resilience to these types of DoS attacks.
全体として、このドキュメントの推奨事項の実装により、これらのタイプのDOS攻撃に対するインターネットの回復力が向上します。
The authors of this document do not make any claims on the originality of the ideas described. Among other people, we would like to acknowledge Alex Zinin for his comments, and the many people who have tested 31 bit subnet masks in their labs and networks.
この文書の著者は、説明されているアイデアの独創性について主張していません。他の人たちの中でも、彼のコメントについてアレックス・ジニンと、ラボとネットワークで31ビットのサブネットマスクをテストした多くの人々を認めたいと思います。
[RFC950] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
[RFC950] Mogul、J。およびJ. Postel、「インターネット標準サブネット手順」、STD 5、RFC 950、1985年8月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332] McGregor、G。、「PPPインターネットプロトコル制御プロトコル（IPCP）」、RFC 1332、1992年5月。
[RFC1519] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[RFC1519] Fuller、V.、Li、T.、Yu、J。、およびK. Varadhan、「クラスレスインタードメインルーティング（CIDR）：アドレス割り当てと集約戦略」、RFC 1519、1993年9月。
[RFC1631] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
[RFC1631] Egevang、K。およびP. Francis、「The IP Networkアドレス翻訳者（NAT）」、RFC 1631、1994年5月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
[RFC2050] Hubbard、K.、Kosters、M.、Conrad、D.、Karrenberg、D。、およびJ. Postel、「インターネットレジストリIP割り当てガイドライン」、BCP 12、RFC 2050、1996年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[RFC2644] Senie、D。、「ルーターでの監督ブロードキャストのデフォルトの変更」、BCP 34、RFC 2644、1999年8月。
[SMURF] Huegen, C., "The Latest in Denial of Service Attacks: 'Smurfing': Description and Information to Minimize Effects", URL: http://users.quadrunner.com/chuegen/smurf.cgi
[Smurf] Huegen、C。、「最新のサービス攻撃攻撃：「Smurfing」：効果を最小限に抑えるための説明と情報」、http：//users.quadrunner.com/chuegen/smurf.cgi
Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709
Alvaro Retana Cisco Systems、Inc。7025 Kit Creek Rd。研究トライアングルパーク、ノースカロライナ州27709
EMail: aretana@cisco.com
Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709
Russ White Cisco Systems、Inc。7025 Kit Creek Rd。研究トライアングルパーク、ノースカロライナ州27709
EMail: riw@cisco.com
Vince Fuller GTE Internetworking 3801 E. Bayshore Rd. Palo Alto, CA, 94303
Vince Fuller GTE InternetWorking 3801 E. Bayshore Rd。カリフォルニア州パロアルト、94303
EMail: vaf@valinor.barrnet.net
Danny McPherson Amber Networks 2465 Augustine Drive Santa Clara, CA 95054
ダニーマクファーソンアンバーネットワーク2465オーガスティンドライブサンタクララ、カリフォルニア95054
EMail: danny@ambernetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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エディター機能の資金は現在、インターネット協会によって提供されています。