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
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.
著作権（C）インターネット協会（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アドレス空間を節約するために絶えず増加圧力で、それは比較的軽微な変更はナンバリング効率を改善するために擁立実際に行うことができる場所を検討することは理にかなって。この文書で提案した一つのそのような変化は、非常に限られた方法で、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].
- IANAに準拠したアドレスの数が少ない位相幾何学NATボックス[RFC1631]の後ろにアドレスをルーティングされた民間の非グローバルの大きなプールで共有されている場合、ネットワークの使用は、翻訳者（NATのを）アドレス。
- 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.
- アドレス空間のサイズを大きくするために、新しいインターネットプロトコルの展開。そのようなプロトコルは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つのオプションは、ルータ間だけではない数のポイントツーポイントリンクです。この練習は手近に問題を解決するために、最初に、見えるかもしれませんが、それは一貫しアンナンバードリンクを管理したり、それを介してルータに到達できない、管理、およびそれらのリンクのデバッグの難しさを含め、独自の問題の数を引き起こし、そして、標準化の欠如[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.
2つのホストアドレス、1すべてゼロネットワーク、および放送1すべてのもの - 現在実際には、番号がインターネットのサブネットは、リンクごとに4つのアドレスが必要です（ほとんどの場合）30ビットのサブネットマスク、より長く使用しないでください。リンクの一方の端部によって送信されるすべてのパケットは、常に他で受信される - 彼らは唯一の可能性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.
第三のオプションは、ポイントツーポイントリンクの両端にホストアドレスを使用することです。このオプションは、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.
ここで、<ホスト番号>は、アドレスのマスクされていない部分を表し、それは、少なくとも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ビットのサブネットマスクは、ポイントツーポイントリンクに割り当てられている場合、それは1ビットのみで<ホスト番号>を残します。その結果、2つだけの可能なアドレスがつながることがあります。
{<Network-number>, 0} and {<Network-number>, -1}
{<ネットワーク番号>、0}と{<ネットワーク番号>、-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}
{<ネットワーク番号>、-1}
{<Network-number>, 0}
{<ネットワーク番号>、0}
The network address itself {<Network-number>, 0} is an obsolete form of directed broadcast, but it may still be used by older hosts.
ネットワークアドレス自体{<ネットワーク番号>、0}向け放送の廃止形態であり、それはまだ古いホストによって使用されてもよいです。
(b) the link local (or limited) broadcast
（b）は、リンクローカル（または限定）放送
{-1, -1}
｛ー１、 ー１｝
{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.
<ネットワーク番号>はローカルルーティングドメインへなどユニークなネットワーク管理者によって割り当てられます。宛先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 }
（E）{<ネットワーク番号>、<サブネット番号>、-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 }
（H）{<ネットワーク番号>、<サブネット番号>、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}
（E）{<ネットワーク番号>、<サブネット番号>、-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 }
（D）{<ネットワークプレフィックス>、-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つである場合を除いて、送信元アドレスとして使用してはいけません。ルータはNetwork Directed Broadcastパケットを生じてもよいです。ルータは、それがダイレクトブロードキャストパケットを受信できるようにする設定オプションがあるかもしれません、しかし、このオプションはデフォルトで無効にされなければならない、具体的には、エンドユーザーによって構成されていない限りのでルータはNetwork Directed Broadcastパケットを受信することもできません。
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 }
（F）{<ネットワーク番号>、<サブネット番号>、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 }.
IPブロードキャストパケットが255.255.255.255または宛（1）治療しなければならない{<ネットワークプレフィックス>、-1}。
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ビット・マスクを持つポイントツーポイントリンクでは、パケットは、{<ネットワークプレフィックス> -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.0宛又は（即ち、偶数ルータ内のアプリケーションに配信していない）受信時に廃棄すべきです。これらのパケットは黙って破棄されていない場合は、（セクション[5.3.5]を参照）IPブロードキャストとして扱わなければなりません。これらのパケットの受信を許可する設定オプションがあるかもしれません。このオプションは、それらを破棄をデフォルトとすべきです。
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ビット・マスクを持つポイントツーポイントリンクで、パケットが宛て{<ネットワークプレフィックス>、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宛または{<ネットワークプレフィックス>、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ビット・マスクを持つポイントツーポイントリンクでは、このようなマスクの構成は、データグラムの生成が宛てを可能にすべきである{<ネットワークプレフィックス>、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.
この文書の勧告はベータ版のコード内のいくつかのルータベンダーによって実装されています。実装は、陽性の結果（すなわち、何の問題が発見されていない）と少なくとも三つの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]モーグル、J.およびJ.ポステル、 "インターネット標準サブネット手順"、STD 5、RFC 950、1985年8月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー、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]フラー、V.、李、T.、ゆう、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.フランシス、 "IPネットワークアドレス変換（NAT）"、RFC 1631、1994年5月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
[RFC2050]ハバード、K.、Kosters、M.、コンラッド、D.、Karrenberg、D.およびJ.ポステル、 "インターネット登録IP配分ガイドライン"、BCP 12、RFC 2050、1996年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、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.、「サービス拒否攻撃で最新： 『スマーフィング』：説明と情報の影響を最小限にするために」、URL：http://users.quadrunner.com/chuegen/smurf.cgi
Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709
アルバロRetanaシスコシステムズ株式会社7025キットクリークRdを。リサーチトライアングルパーク、NC 27709
EMail: aretana@cisco.com
メールアドレス：aretana@cisco.com
Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709
ラスホワイトシスコシステムズ株式会社7025キットクリークRdを。リサーチトライアングルパーク、NC 27709
EMail: riw@cisco.com
メールアドレス：riw@cisco.com
Vince Fuller GTE Internetworking 3801 E. Bayshore Rd. Palo Alto, CA, 94303
ビンスフラーGTEインターネットワーキング3801 E.ベイショアRdを。パロアルト、CA、94303
EMail: vaf@valinor.barrnet.net
メールアドレス：vaf@valinor.barrnet.net
Danny McPherson Amber Networks 2465 Augustine Drive Santa Clara, CA 95054
ダニー・マクファーソンアンバー・ネットワーク2465オーガスティンドライブサンタクララ、CA 95054
EMail: danny@ambernetworks.com
メールアドレス：danny@ambernetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。