RFC3021 日本語訳
3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links. A. Retana, R.White, V. Fuller, D. McPherson. December 2000. (Format: TXT=19771 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループA.レタナの要求をネットワークでつないでください: 3021年のR.の白いカテゴリ: 規格は2000年12月によりふくよかなシスコシステムズのGTEインターネットワーキングD.マクファーソンこはくのV.ネットワークを追跡します。
Using 31-Bit Prefixes on IPv4 Point-to-Point Links
IPv4ポイントツーポイント接続の上で31ビットの接頭語を使用します。
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 (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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ビットのサブネットマスクの使用を許すことによってポイントツーポイント接続(インターネット基盤中で一般的な)に割り当てられたアドレス空間の量を半分にすることになっています。
1. Introduction and Motivation
1. 序論と動機
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].
- Network Address Translators(NATs)の使用。そこで、少ない数のIANA対応することのアドレスがNAT箱[RFC1631]の後ろで個人的で、非グローバルに発送されたアドレスの、より大きいプールによって位相的に共有されます。
Retana, et al. Standards Track [Page 1] RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
レタナ、他 規格は2000年12月にIPv4リンクの上にRFC3021の31ビットの接頭語を追跡します[1ページ]。
- 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つはポイントツーポイント接続が番号付である方法を変えることです。 単にルータの間のどんな数のポイントツーポイント接続にはも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.
番号付のインターネットサブネットは1リンクあたり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アドレス空間の同等物)の貯蓄に達するでしょう。
Retana, et al. Standards Track [Page 2] RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
レタナ、他 規格は2000年12月にIPv4リンクの上にRFC3021の31ビットの接頭語を追跡します[2ページ]。
2. Considerations of 31-Bit Prefixes
2. 31ビットの接頭語の問題
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-番号>がアドレスとそれのむきだしの部分を表すところでは、SHOULDが少なくともそうです。幅1ビットです。 「-1インチの記法は分野にはすべての1ビットがあることを意味するのに使用されます。」 この議論の目的のために、ルーティングシステムは階級のないかCIDR[RFC1519]であることができて、掘ると考えられます。
2.1. Addressing
2.1. アドレシング
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ビットだけと共に<Host-番号を>に残します。 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つのアドレスを解釈しなければなりません。
2.2. Broadcast and Network Addresses
2.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.
ネットワークはそれ自体を記述します。使用するかもしれません、そして、<Network-番号>、0は時代遅れの形式の指示された放送ですが、それでも、より年取ったホストによって使用されてください。
Retana, et al. Standards Track [Page 3] RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
レタナ、他 規格は2000年12月にIPv4リンクの上にRFC3021の31ビットの接頭語を追跡します[3ページ]。
(b) the link local (or limited) broadcast
(b) リンク地方の、そして、(制限される)の放送
{-1, -1}
{-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-番号>は地方の経路ドメインにユニークであるとしてネットワーク管理者によって割り当てられます。 送付先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ビットの接頭語の適用性と操作について議論することです。 他のタイプのインタフェースへの効果(もしあれば)は考えられません。
2.2.1. Directed Broadcast
2.2.1. 指示された放送
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 Attacks[RFC2644、SMURF]のあるクラスへのネットワークの抵抗をわずかに機能アップするとき。
2.3. Impact on Current Routing Protocols
2.3. 現在のルーティング・プロトコルで影響を与えてください。
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ビットのサブネットマスクの使用で影響を受けません。
Retana, et al. Standards Track [Page 4] RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
レタナ、他 規格は2000年12月にIPv4リンクの上にRFC3021の31ビットの接頭語を追跡します[4ページ]。
3. Recommendations
3. 推薦
The considerations presented in Section 2 affect other published work. This section details the updates made to other documents.
セクション2に提示された問題は他の発行された仕事に影響します。 このセクションは他のドキュメントにされたアップデートを詳しく述べます。
3.1. "Requirements for Internet Hosts -- Communication Layers" [RFC1122]
3.1. 「インターネットホストのための要件--コミュニケーションは層にされます」[RFC1122]
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ビットのマスクとのポイントツーポイント接続の終点のひとりである時を除いて。
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].
サブネットワーク番号。 SHOULD NOTがソースアドレスとして使用されて、創始者が31ビットのマスクとのポイントへのポイントリンクの終点のひとりであるときには除いてください。 他のタイプのリンク、そのような目的地SHOULDが静かに捨てられているパケットのために。 これらのパケットが静かに捨てられないなら、IP放送[RFC1812]としてそれらを扱わなければなりません。
3.2. "Assigned Numbers" [RFC1700]
3.2. 「規定番号」[RFC1700]
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ビットのマスクとのポイントツーポイント接続の終点のひとりである場合では、また、ソースアドレスとしてそれを使用できます。
3.3. "Requirements for IP Version 4 Routers" [RFC1812]
3.3. 「IPバージョン4ルータのための要件」[RFC1812]
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-
指示されたBroadcast--指定されたネットワーク接頭語に向けられた放送。 ソースアドレスとしてそれを使用してはいけません、創始者がポイントの終点のひとりである時を除いて
Retana, et al. Standards Track [Page 5] RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
レタナ、他 規格は2000年12月にIPv4リンクの上にRFC3021の31ビットの接頭語を追跡します[5ページ]。
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ビットのマスクとのポイントへのリンク。 ルータは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.
サブネットワーク番号。 SHOULD NOTがソースアドレスとして使用されて、創始者が31ビットのマスクとのポイントへのポイントリンクの終点のひとりであるときには除いてください。 他のタイプのリンク、そのような目的地SHOULDが静かに捨てられているパケットのために。 これらのパケットが静かに捨てられないなら、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まで記述したので(1)が扱わなければならない、.255、<Network-接頭語>、-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ビットのマスク、記述されたパケットとのポイントツーポイント接続、<Network-接頭語>、-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) SHOULDが領収書(すなわち、ルータにおけるアプリケーションに配送さえしない)の上で静かに0.0まで記述されたどんなパケットも捨てる、.0、.0、<Network-接頭語>、0。 これらのパケットが静かに捨てられないなら、IP放送としてそれらを扱わなければならない、(セクションを見てください、[5.3、.5、) これらのパケットの領収書を許容する設定オプションがあるかもしれません。 このオプションSHOULDはそれらを捨てるのをデフォルトとします。
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-接頭語>、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) SHOULD NOTが0.0まで記述されたデータグラムを溯源する、.0、.0、<Network-接頭語>、0。 これらのパケット(関連1つの形式の放送を使用することの代わりに)の世代を許容する設定オプションがあるかもしれません。 このオプションSHOULDはそれらを発生させないのをデフォルトとします。
Retana, et al. Standards Track [Page 6] RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
レタナ、他 規格は2000年12月にIPv4リンクの上にRFC3021の31ビットの接頭語を追跡します[6ページ]。
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ビットのマスク、SHOULDが<Network-接頭語>、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
31ビットのサブネットマスクとの指すポイントの放送Address Mask Repliesリンクに255.255.255.255IP放送演説を使用しなければなりません。
4. Operational Experience
4. 運用経験
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である、-、BGPとEIGRP。
It is expected that the implementation will be officially released within the next few months and that other vendors will adopt it.
実現がこの数カ月以内に公式にリリースされて、他の業者がそれを採用すると予想されます。
5. Deployment Considerations
5. 展開問題
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ビットの使用を支持するかに注意してください。
6. Security Considerations
6. セキュリティ問題
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攻撃にインターネットの弾力を改良するでしょう。
7. Acknowledgements
7. 承認
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ビットのサブネットマスクを検査した多くの人々のためにアレックス・ジニンを承認したいと思います。
Retana, et al. Standards Track [Page 7] RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
レタナ、他 規格は2000年12月にIPv4リンクの上にRFC3021の31ビットの接頭語を追跡します[7ページ]。
8. References
8. 参照
[RFC950] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
[RFC950] ムガール人とJ.とJ.ポステル、「インターネットの標準のサブネッティング手順」、STD5、RFC950、1985年8月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー(G.、「pppインターネットプロトコル制御プロトコル(IPCP)」RFC1332)は1992がそうするかもしれません。
[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)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
[RFC1631] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
[RFC1631] EgevangとK.とP.フランシス、「IPネットワークアドレス変換機構(NAT)」(RFC1631)は1994がそうするかもしれません。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、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] ハバードとK.とKostersとM.とコンラッドとD.とKarrenbergとD.とJ.ポステル、「インターネット登録IP配分ガイドライン」、BCP12、RFC2050、1996年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[RFC2644] Senie、D.、「ルータにおける指示された放送のためのデフォルトを変えます」、BCP34、RFC2644、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します': 「効果を最小にする記述と情報」、URL: http://users.quadrunner.com/chuegen/smurf.cgi
Retana, et al. Standards Track [Page 8] RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
レタナ、他 規格は2000年12月にIPv4リンクの上にRFC3021の31ビットの接頭語を追跡します[8ページ]。
9. Authors' Addresses
9. 作者のアドレス
Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709
アルバロレタナシスコシステムズInc.7025キットCreek通り NC リサーチトライアングル公園、27709
EMail: aretana@cisco.com
メール: aretana@cisco.com
Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709
ラス白いシスコシステムズInc.7025キットCreek通り NC リサーチトライアングル公園、27709
EMail: riw@cisco.com
メール: riw@cisco.com
Vince Fuller GTE Internetworking 3801 E. Bayshore Rd. Palo Alto, CA, 94303
ビンスよりふくよかなGTEインターネットワーキング3801E.Bayshore通り パロアルト、カリフォルニア 94303
EMail: vaf@valinor.barrnet.net
メール: vaf@valinor.barrnet.net
Danny McPherson Amber Networks 2465 Augustine Drive Santa Clara, CA 95054
ダニーマクファーソンこはくネットワーク2465オーガスティンはサンタクララ、カリフォルニア 95054を追い立てます。
EMail: danny@ambernetworks.com
メール: danny@ambernetworks.com
Retana, et al. Standards Track [Page 9] RFC 3021 31-Bit Prefixes on IPv4 Links December 2000
レタナ、他 規格は2000年12月にIPv4リンクの上にRFC3021の31ビットの接頭語を追跡します[9ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Retana, et al. Standards Track [Page 10]
レタナ、他 標準化過程[10ページ]
一覧
スポンサーリンク