RFC1716 日本語訳
1716 Towards Requirements for IP Routers. P. Almquist, F. Kastenholz. November 1994. (Format: TXT=432330 bytes) (Obsoleted by RFC1812) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Almquist, Author
Request for Comments: 1716 Consultant
Category: Informational F. Kastenholz, Editor
FTP Software, Inc.
November 1994
ワーキンググループP.Almquist、コメントを求める作者要求をネットワークでつないでください: 1716年のコンサルタントカテゴリ: 情報のF.Kastenholz、エディタFTPソフトウェアInc.1994年11月
Towards Requirements for IP Routers
IPルータのための要件に向かって
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Almquist & Kastenholz [Page i] RFC 1716 Towards Requirements for IP Routers November 1994
IP Routers1994年11月のためのAlmquist&Kastenholz[ページi]RFC1716Towards Requirements
Table of Contents
目次
0. PREFACE ....................................................... 1 1. INTRODUCTION .................................................. 2 1.1 Reading this Document ........................................ 4 1.1.1 Organization ............................................... 4 1.1.2 Requirements ............................................... 5 1.1.3 Compliance ................................................. 6 1.2 Relationships to Other Standards ............................. 7 1.3 General Considerations ....................................... 8 1.3.1 Continuing Internet Evolution .............................. 8 1.3.2 Robustness Principle ....................................... 9 1.3.3 Error Logging .............................................. 9 1.3.4 Configuration .............................................. 10 1.4 Algorithms ................................................... 11 2. INTERNET ARCHITECTURE ......................................... 13 2.1 Introduction ................................................. 13 2.2 Elements of the Architecture ................................. 14 2.2.1 Protocol Layering .......................................... 14 2.2.2 Networks ................................................... 16 2.2.3 Routers .................................................... 17 2.2.4 Autonomous Systems ......................................... 18 2.2.5 Addresses and Subnets ...................................... 18 2.2.6 IP Multicasting ............................................ 20 2.2.7 Unnumbered Lines and Networks and Subnets .................. 20 2.2.8 Notable Oddities ........................................... 22 2.2.8.1 Embedded Routers ......................................... 22 2.2.8.2 Transparent Routers ...................................... 23 2.3 Router Characteristics ....................................... 24 2.4 Architectural Assumptions .................................... 27 3. LINK LAYER .................................................... 29 3.1 INTRODUCTION ................................................. 29 3.2 LINK/INTERNET LAYER INTERFACE ................................ 29 3.3 SPECIFIC ISSUES .............................................. 30 3.3.1 Trailer Encapsulation ...................................... 30 3.3.2 Address Resolution Protocol - ARP .......................... 31 3.3.3 Ethernet and 802.3 Coexistence ............................. 31 3.3.4 Maximum Transmission Unit - MTU ............................ 31 3.3.5 Point-to-Point Protocol - PPP .............................. 32 3.3.5.1 Introduction ............................................. 32 3.3.5.2 Link Control Protocol (LCP) Options ...................... 33 3.3.5.3 IP Control Protocol (ICP) Options ........................ 34 3.3.6 Interface Testing .......................................... 35 4. INTERNET LAYER - PROTOCOLS .................................... 36 4.1 INTRODUCTION ................................................. 36 4.2 INTERNET PROTOCOL - IP ....................................... 36
0. 前書きします。 1 1. 序論… 2 1.1 このDocumentを読みます… 4 1.1 .1組織… 4 1.1 .2の要件… 5 1.1 .3コンプライアンス… 6 他の規格との1.2の関係… 7 1.3の一般問題… 8 1.3 .1 継続するインターネット発展… 8 1.3 .2堅牢性の原則… 9 1.3 .3 誤り伐採… 9 1.3 .4構成… 10 1.4のアルゴリズム… 11 2. インターネット構造… 13 2.1序論… 13 2.2 構造のElements… 14 2.2 .1 レイヤリングについて議定書の中で述べてください… 14 2.2 .2 ネットワークでつなぎます。 16 2.2 .3のルータ… 17 2.2 .4の自律システム… 18 2.2 .5のアドレスとサブネット… 18 2.2 .6 IPマルチキャスティング… 20 2.2 .7 無数の線、ネットワーク、およびサブネット… 20 2.2 .8 注目に値する奇異… 22 2.2 .8 .1 ルータを埋め込みます… 22 2.2 .8 .2の透明なルータ… 23 2.3 ルータの特性… 24 2.4 建築仮定… 27 3. 層をリンクしてください… 29 3.1序論… 29 3.2リンク/インターネット層のインタフェース… 29 3.3 特定の問題… 30 3.3 .1 トレーラカプセル化… 30 3.3 .2は解決プロトコルを記述します--ARP。 31 3.3 .3のイーサネットと802.3共存… 31 3.3 .4最大トランスミッション単位(MTU)… 31 3.3 .5 ポイントツーポイントは議定書を作ります--ppp 32 3.3 .5 .1序論… 32 3.3 .5 .2 制御プロトコル(LCP)オプションをリンクしてください… 33 3.3 .5 .3 IP制御プロトコル(ICP)オプション… 34 3.3 .6 テストを連結してください… 35 4. インターネットは層にされます--プロトコル 36 4.1序論… 36 4.2 インターネットは議定書を作ります--IP 36
Almquist & Kastenholz [Page ii] RFC 1716 Towards Requirements for IP Routers November 1994
IP Routers1994年11月のためのAlmquist&Kastenholz[ページii]RFC1716Towards Requirements
4.2.1 INTRODUCTION ............................................... 36 4.2.2 PROTOCOL WALK-THROUGH ...................................... 37 4.2.2.1 Options: RFC-791 Section 3.2 ............................. 37 4.2.2.2 Addresses in Options: RFC-791 Section 3.1 ................ 40 4.2.2.3 Unused IP Header Bits: RFC-791 Section 3.1 ............... 40 4.2.2.4 Type of Service: RFC-791 Section 3.1 ..................... 41 4.2.2.5 Header Checksum: RFC-791 Section 3.1 ..................... 41 4.2.2.6 Unrecognized Header Options: RFC-791 Section 3.1 ......... 41 4.2.2.7 Fragmentation: RFC-791 Section 3.2 ....................... 42 4.2.2.8 Reassembly: RFC-791 Section 3.2 .......................... 43 4.2.2.9 Time to Live: RFC-791 Section 3.2 ........................ 43 4.2.2.10 Multi-subnet Broadcasts: RFC-922 ........................ 43 4.2.2.11 Addressing: RFC-791 Section 3.2 ......................... 43 4.2.3 SPECIFIC ISSUES ............................................ 47 4.2.3.1 IP Broadcast Addresses ................................... 47 4.2.3.2 IP Multicasting .......................................... 48 4.2.3.3 Path MTU Discovery ....................................... 48 4.2.3.4 Subnetting ............................................... 49 4.3 INTERNET CONTROL MESSAGE PROTOCOL - ICMP ..................... 50 4.3.1 INTRODUCTION ............................................... 50 4.3.2 GENERAL ISSUES ............................................. 50 4.3.2.1 Unknown Message Types .................................... 50 4.3.2.2 ICMP Message TTL ......................................... 51 4.3.2.3 Original Message Header .................................. 51 4.3.2.4 ICMP Message Source Address .............................. 51 4.3.2.5 TOS and Precedence ....................................... 51 4.3.2.6 Source Route ............................................. 52 4.3.2.7 When Not to Send ICMP Errors ............................. 53 4.3.2.8 Rate Limiting ............................................ 54 4.3.3 SPECIFIC ISSUES ............................................ 55 4.3.3.1 Destination Unreachable .................................. 55 4.3.3.2 Redirect ................................................. 55 4.3.3.3 Source Quench ............................................ 56 4.3.3.4 Time Exceeded ............................................ 56 4.3.3.5 Parameter Problem ........................................ 57 4.3.3.6 Echo Request/Reply ....................................... 57 4.3.3.7 Information Request/Reply ................................ 58 4.3.3.8 Timestamp and Timestamp Reply ............................ 58 4.3.3.9 Address Mask Request/Reply ............................... 59 4.3.3.10 Router Advertisement and Solicitations .................. 61 4.4 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP .................... 61 5. INTERNET LAYER - FORWARDING ................................... 62 5.1 INTRODUCTION ................................................. 62 5.2 FORWARDING WALK-THROUGH ...................................... 62 5.2.1 Forwarding Algorithm ....................................... 62 5.2.1.1 General .................................................. 63 5.2.1.2 Unicast .................................................. 64
4.2.1 序論… 36 4.2 .2 立ち稽古について議定書の中で述べてください… 37 4.2 .2 .1のオプション: RFC-791部3.2… 37 4.2 .2 オプションにおける.2のアドレス: RFC-791部3.1… 40 4.2 .2 .3 未使用のIPヘッダービット: RFC-791部3.1… 40 4.2 .2 .4 サービスのタイプ: RFC-791部3.1… 41 4.2 .2 .5 ヘッダーチェックサム: RFC-791部3.1… 41 4.2 .2 .6 認識されていないヘッダーオプション: RFC-791部3.1… 41 4.2 .2 .7断片化: RFC-791部3.2… 42 4.2 .2 .8 Reassembly: RFC-791部3.2… 43 4.2 .2 生きる.9時間: RFC-791部3.2… 43 4.2 .2 .10 マルチサブネットは放送されます: RFC-922… 43 4.2 .2 .11 アドレシング: RFC-791部3.2… 43 4.2 .3 特定の問題… 47 4.2 .3 .1 IPはアドレスを放送しました… 47 4.2 .3 .2 IPマルチキャスティング… 48 4.2 .3 .3 経路MTU発見… 48 4.2 .3 .4サブネッティング… 49 4.3インターネットコントロールメッセージは議定書を作ります--ICMP 50 4.3 .1序論… 50 4.3 .2 一般的な問題… 50 4.3 .2 .1 未知のメッセージタイプ… 50 4.3 .2 .2 ICMPメッセージTTL… 51 4.3 .2 .3のオリジナルのメッセージヘッダー… 51 4.3 .2 .4 ICMPメッセージ源アドレス… 51 4.3 .2 .5のTOSと先行… 51 4.3 .2 .6送信元経路… 52 4.3 .2、.7、いつ、誤りをICMPに送らないように… 53 4.3 .2 .8 制限を評定してください… 54 4.3 .3 特定の問題… 55 4.3 .3 .1 目的地手の届かない… 55 4.3 .3 .2 向け直します。 55 4.3 .3 .3ソース焼き入れ… 56 4.3 .3 超えられていた.4時間… 56 4.3 .3 .5パラメタ問題… 57 4.3 .3 .6 要求/回答をまねてください… 57 4.3 .3 .7情報要求/回答… 58 4.3 .3 .8のタイムスタンプとタイムスタンプは返答します… 58 4.3 .3 .9 マスク要求/回答を記述してください… 59 4.3 .3 .10のルータ通知と懇願… 61 4.4 インターネット集団経営は議定書を作ります--IGMP。 61 5. インターネット層--進めます。 62 5.1序論… 62 5.2推進立ち稽古… 62 5.2 .1推進アルゴリズム… 62 5.2 .1 .1一般… 63 5.2 .1 .2ユニキャスト… 64
Almquist & Kastenholz [Page iii] RFC 1716 Towards Requirements for IP Routers November 1994
IP Routers1994年11月のためのAlmquist&Kastenholz[ページiii]RFC1716Towards Requirements
5.2.1.3 Multicast ................................................ 65 5.2.2 IP Header Validation ....................................... 66 5.2.3 Local Delivery Decision .................................... 68 5.2.4 Determining the Next Hop Address ........................... 70 5.2.4.1 Immediate Destination Address ............................ 71 5.2.4.2 Local/Remote Decision .................................... 71 5.2.4.3 Next Hop Address ......................................... 72 5.2.4.4 Administrative Preference ................................ 77 5.2.4.6 Load Splitting ........................................... 78 5.2.5 Unused IP Header Bits: RFC-791 Section 3.1 ................. 79 5.2.6 Fragmentation and Reassembly: RFC-791 Section 3.2 .......... 79 5.2.7 Internet Control Message Protocol - ICMP ................... 80 5.2.7.1 Destination Unreachable .................................. 80 5.2.7.2 Redirect ................................................. 82 5.2.7.3 Time Exceeded ............................................ 84 5.2.8 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP .................. 84 5.3 SPECIFIC ISSUES .............................................. 84 5.3.1 Time to Live (TTL) ......................................... 84 5.3.2 Type of Service (TOS) ...................................... 85 5.3.3 IP Precedence .............................................. 87 5.3.3.1 Precedence-Ordered Queue Service ......................... 88 5.3.3.2 Lower Layer Precedence Mappings .......................... 88 5.3.3.3 Precedence Handling For All Routers ...................... 89 5.3.4 Forwarding of Link Layer Broadcasts ........................ 92 5.3.5 Forwarding of Internet Layer Broadcasts .................... 92 5.3.5.1 Limited Broadcasts ....................................... 94 5.3.5.2 Net-directed Broadcasts .................................. 94 5.3.5.3 All-subnets-directed Broadcasts .......................... 95 5.3.5.4 Subnet-directed Broadcasts ............................... 97 5.3.6 Congestion Control ......................................... 97 5.3.7 Martian Address Filtering .................................. 99 5.3.8 Source Address Validation .................................. 99 5.3.9 Packet Filtering and Access Lists .......................... 100 5.3.10 Multicast Routing ......................................... 101 5.3.11 Controls on Forwarding .................................... 101 5.3.12 State Changes ............................................. 101 5.3.12.1 When a Router Ceases Forwarding ......................... 102 5.3.12.2 When a Router Starts Forwarding ......................... 102 5.3.12.3 When an Interface Fails or is Disabled .................. 103 5.3.12.4 When an Interface is Enabled ............................ 103 5.3.13 IP Options ................................................ 103 5.3.13.1 Unrecognized Options .................................... 103 5.3.13.2 Security Option ......................................... 104 5.3.13.3 Stream Identifier Option ................................ 104 5.3.13.4 Source Route Options .................................... 104 5.3.13.5 Record Route Option ..................................... 104 5.3.13.6 Timestamp Option ........................................ 105
5.2.1.3 マルチキャスト… 65 5.2 .2 IPヘッダー合法化… 66 5.2 .3のローカルの配送決定… 68 5.2 .4 次のホップアドレスを決定します… 70 5.2 .4 .1 即座の送付先アドレス… 71 5.2 .4 .2の地方の、または、リモートな決定… 71 5.2 .4 .3 次のホップアドレス… 72 5.2 .4 .4 管理好み… 77 5.2 .4 .6 分かれることをロードしてください… 78 5.2 .5 未使用のIPヘッダービット: RFC-791部3.1… 79 5.2 .6 断片化とReassembly: RFC-791部3.2… 79 5.2 .7 インターネットはメッセージプロトコルを制御します--ICMP。 80 5.2 .7 .1 目的地手の届かない… 80 5.2 .7 .2 向け直します。 82 5.2 .7 超えられていた.3時間… 84 5.2 .8 インターネット集団経営は議定書を作ります--IGMP 84 5.3 特定の問題… 84 5.3 生きる.1時間(TTL)… 84 5.3 .2 サービス(TOS)のタイプ… 85 5.3 .3 IP先行… 87 5.3 .3 .1 先行で命令された待ち行列サービス… 88 5.3 .3 .2 層の先行マッピングを下ろしてください… 88 5.3 .3 .3 すべてのルータのための先行取り扱い… 89 5.3 .4 リンクレイヤの推進は放送されます… 92 5.3 .5 インターネット層の推進は放送されます… 92 5.3 .5 .1株式会社は放送されます… 94 5.3 .5 .2 ネットで指示された放送… 94 5.3 .5 .3 指示されたオールサブネット放送… 95 5.3 .5 .4 サブネットで指示された放送… 97 5.3 .6 混雑コントロール… 97 5.3 .7の火星のアドレスフィルタリング… 99 5.3 .8 ソースアドレス合法化… 99 5.3 .9のパケットフィルタリングとアクセスは記載します… 100 5.3.10 マルチキャストルート設定… 101 5.3.11 推進のコントロール… 101 5.3.12 変化を述べてください… 101 5.3.12.1 ルータが、進めるのをやめるとき… 102 5.3.12.2 ルータが進め始めると… 102 5.3.12.3 Interface Failsである、Disabledはそうです。 103 5.3.12.4 InterfaceがEnabledであるときに… 103 5.3.13 IPオプション… 103 5.3.13.1 認識されていないオプション… 103 5.3.13.2 セキュリティオプション… 104 5.3.13.3 識別子オプションを流してください… 104 5.3.13.4 送信元経路オプション… 104 5.3.13.5 ルートオプションを記録してください… 104 5.3.13.6 タイムスタンプオプション… 105
Almquist & Kastenholz [Page iv] RFC 1716 Towards Requirements for IP Routers November 1994
IP Routers1994年11月のためのAlmquist&Kastenholz[ページiv]RFC1716Towards Requirements
6. TRANSPORT LAYER ............................................... 106
6.1 USER DATAGRAM PROTOCOL - UDP ................................. 106
6.2 TRANSMISSION CONTROL PROTOCOL - TCP .......................... 106
7. APPLICATION LAYER - ROUTING PROTOCOLS ......................... 109
7.1 INTRODUCTION ................................................. 109
7.1.1 Routing Security Considerations ............................ 109
7.1.2 Precedence ................................................. 110
7.2 INTERIOR GATEWAY PROTOCOLS ................................... 110
7.2.1 INTRODUCTION ............................................... 110
7.2.2 OPEN SHORTEST PATH FIRST - OSPF ............................ 111
7.2.2.1 Introduction ............................................. 111
7.2.2.2 Specific Issues .......................................... 111
7.2.2.3 New Version of OSPF ...................................... 112
7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM - DUAL IS-IS
.............................................................. 112
7.2.4 ROUTING INFORMATION PROTOCOL - RIP ......................... 113
7.2.4.1 Introduction ............................................. 113
7.2.4.2 Protocol Walk-Through .................................... 113
7.2.4.3 Specific Issues .......................................... 118
7.2.5 GATEWAY TO GATEWAY PROTOCOL - GGP .......................... 119
7.3 EXTERIOR GATEWAY PROTOCOLS ................................... 119
7.3.1 INTRODUCTION ............................................... 119
7.3.2 BORDER GATEWAY PROTOCOL - BGP .............................. 120
7.3.2.1 Introduction ............................................. 120
7.3.2.2 Protocol Walk-through .................................... 120
7.3.3 EXTERIOR GATEWAY PROTOCOL - EGP ............................ 121
7.3.3.1 Introduction ............................................. 121
7.3.3.2 Protocol Walk-through .................................... 122
7.3.4 INTER-AS ROUTING WITHOUT AN EXTERIOR PROTOCOL .............. 124
7.4 STATIC ROUTING ............................................... 125
7.5 FILTERING OF ROUTING INFORMATION ............................. 127
7.5.1 Route Validation ........................................... 127
7.5.2 Basic Route Filtering ...................................... 127
7.5.3 Advanced Route Filtering ................................... 128
7.6 INTER-ROUTING-PROTOCOL INFORMATION EXCHANGE .................. 129
8. APPLICATION LAYER - NETWORK MANAGEMENT PROTOCOLS .............. 131
8.1 The Simple Network Management Protocol - SNMP ................ 131
8.1.1 SNMP Protocol Elements ..................................... 131
8.2 Community Table .............................................. 132
8.3 Standard MIBS ................................................ 133
8.4 Vendor Specific MIBS ......................................... 134
8.5 Saving Changes ............................................... 135
9. APPLICATION LAYER - MISCELLANEOUS PROTOCOLS ................... 137
9.1 BOOTP ........................................................ 137
9.1.1 Introduction ............................................... 137
9.1.2 BOOTP Relay Agents ......................................... 137
10. OPERATIONS AND MAINTENANCE ................................... 139
6. 層を輸送してください… 106 6.1ユーザデータグラムは議定書を作ります--UDP 106 6.2 転送管理は議定書を作ります--TCP。 106 7. 応用層--ルーティングプロトコル… 109 7.1序論… 109 7.1.1 ルート設定セキュリティ問題… 109 7.1.2 先行… 110 7.2 内部のゲートウェイプロトコル… 110 7.2.1 序論… 110 7.2.2 最短パス1番目を開いてください--OSPF。 111 7.2.2.1 序論… 111 7.2.2.2 特定の問題… 111 7.2.2.3 OSPFの新しいバージョン… 112 7.2.3、中間システムへの中間システム--二元的なイシスS… 112 7.2.4 ルーティング情報プロトコル--裂いてください… 113 7.2.4.1 序論… 113 7.2.4.2 立ち稽古について議定書の中で述べてください… 113 7.2.4.3 特定の問題… 118 7.2.5 ゲートウェイへのゲートウェイは議定書を作ります--GGP。 119 7.3 外のゲートウェイプロトコル… 119 7.3.1 序論… 119 7.3.2 ゲートウェイプロトコルに接してください--BGP 120 7.3.2.1 序論… 120 7.3.2.2 立ち稽古について議定書の中で述べてください… 120 7.3.3 外のゲートウェイは議定書を作ります--EGP。 121 7.3.3.1 序論… 121 7.3.3.2 立ち稽古について議定書の中で述べてください… 122 7.3.4、相互、外のプロトコルのないルーティング… 124 7.4スタティックルーティング… 経路情報の125 7.5フィルタリング… 127 7.5.1 合法化を発送してください… 127 7.5.2 基本的なルートフィルタリング… 127 7.5.3 高度なルートフィルタリング… 128 7.6 相互ルーティング・プロトコル情報交換… 129 8. 応用層--ネットワークマネージメントプロトコル… 131 8.1 簡単なネットワークマネージメントは議定書を作ります--SNMP。 131 8.1.1 SNMPはElementsについて議定書の中で述べます… 131 8.2共同体テーブル… 132 8.3 標準のMIBS… 133 8.4 業者の特定のMIBS… 134 8.5 節約は変化します… 135 9. アプリケーションは層にされます--種々雑多なプロトコル。 137 9.1BOOTP… 137 9.1.1 序論… 137 9.1.2 BOOTPはエージェントをリレーします… 137 10. 操作AND維持… 139
Almquist & Kastenholz [Page v] RFC 1716 Towards Requirements for IP Routers November 1994
IP Routers1994年11月のためのAlmquist&Kastenholz[ページv]RFC1716Towards Requirements
10.1 Introduction ................................................ 139 10.2 Router Initialization ....................................... 140 10.2.1 Minimum Router Configuration .............................. 140 10.2.2 Address and Address Mask Initialization ................... 141 10.2.3 Network Booting using BOOTP and TFTP ...................... 142 10.3 Operation and Maintenance ................................... 143 10.3.1 Introduction .............................................. 143 10.3.2 Out Of Band Access ........................................ 144 10.3.2 Router O&M Functions ...................................... 144 10.3.2.1 Maintenance - Hardware Diagnosis ........................ 144 10.3.2.2 Control - Dumping and Rebooting ......................... 145 10.3.2.3 Control - Configuring the Router ........................ 145 10.3.2.4 Netbooting of System Software ........................... 146 10.3.2.5 Detecting and responding to misconfiguration ............ 146 10.3.2.6 Minimizing Disruption ................................... 147 10.3.2.7 Control - Troubleshooting Problems ...................... 148 10.4 Security Considerations ..................................... 149 10.4.1 Auditing and Audit Trails ................................. 149 10.4.2 Configuration Control ..................................... 150 11. REFERENCES ................................................... 152 APPENDIX A. REQUIREMENTS FOR SOURCE-ROUTING HOSTS ................ 162 APPENDIX B. GLOSSARY ............................................. 164 APPENDIX C. FUTURE DIRECTIONS .................................... 169 APPENDIX D. Multicast Routing Protocols .......................... 172 D.1 Introduction ................................................. 172 D.2 Distance Vector Multicast Routing Protocol - DVMRP ........... 172 D.3 Multicast Extensions to OSPF - MOSPF ......................... 173 APPENDIX E Additional Next-Hop Selection Algorithms .............. 174 E.1. Some Historical Perspective .................................. 174 E.2. Additional Pruning Rules ..................................... 176 E.3 Some Route Lookup Algorithms ................................. 177 E.3.1 The Revised Classic Algorithm ............................... 178 E.3.2 The Variant Router Requirements Algorithm ................... 179 E.3.3 The OSPF Algorithm .......................................... 179 E.3.4 The Integrated IS-IS Algorithm .............................. 180 Security Considerations ........................................... 182 Acknowledgments ................................................... 183 Editor's Address .................................................. 186
10.1序論… 139 10.2 ルータ初期設定… 140 10.2 .1の最小のルータ構成… 140 10.2 .2 マスク初期設定を扱って、扱ってください… 141 10.2 .3 BOOTPとTFTPを使用して、穂ばらみをネットワークでつないでください… 142 10.3維持管理… 143 10.3 .1序論… 143 10.3 .2 バンドアクセスから… 144 10.3 .2 ルータO&Mは機能します… 144 10.3 .2 .1 メインテナンス--ハードウェア診断… 144 10.3 .2 .2は制御されます--どさっと落として、リブートします… 145 10.3 .2 .3 ルータを構成して、制御してください… 145 10.3 .2 .4 システムソフトをNetbootingします… 146 10.3 .2 .5 misconfigurationに検出して、反応します。 146 10.3 .2 .6 分裂を最小にします… 147 10.3 .2 .7 問題を障害調査して、制御してください… 148 10.4 セキュリティ問題… 149 10.4 .1 監査と監査道… 149 10.4 .2構成管理… 150 11. 参照… 152 ソースルーティングホストのための付録A.要件… 162付録B.用語集… 164 付録C.未来の方向… 169 付録D.マルチキャストルーティング・プロトコル… 172D.1序論… 172 D.2はベクトルマルチキャストルーティング・プロトコルを遠ざけます--DVMRP。 OSPFへの172のD.3マルチキャスト拡張子--、MOSPF… 173 付録のE追加次のホップ選択アルゴリズム… 174 E.1。 何らかの歴史観… 174 E.2。 追加刈り込みは統治されます… 176E.3、或るものはルックアップアルゴリズムを発送します… 177 E.3.1の改訂された古典的なアルゴリズム… 178 E.3.2異形ルータ要件アルゴリズム… 179 E.3.3OSPFアルゴリズム… 179E.3.4統合、-、アルゴリズム… 180 セキュリティ問題… 182の承認… 183エディタのアドレス… 186
Almquist & Kastenholz [Page vi] RFC 1716 Towards Requirements for IP Routers November 1994
IP Routers1994年11月のためのAlmquist&Kastenholz[ページvi]RFC1716Towards Requirements
0. PREFACE
0. 序文
This document is a snapshot of the work of the Router Requirements working group as of November 1991. At that time, the working group had essentially finished its task. There were some final technical matters to be nailed down, and a great deal of editing needed to be done in order to get the document ready for publication. Unfortunately, these tasks were never completed.
このドキュメントは1991年11月付けでRouter Requirementsワーキンググループの仕事のスナップです。 その時、ワーキンググループは本質的にはタスクを終えました。 縛り付けられるために、いくつかの最終的な技術事項がありました、そして、大きな編集が公表のためにドキュメントを用意するためにする必要がありました。 残念ながら、これらのタスクは決して完成しませんでした。
At the request of the Internet Area Director, the current editor took the last draft of the document and, after consulting the mailing list archives, meeting minutes, notes, and other members of the working group, edited the document to its current form. This effort included the following tasks: 1) Deleting all the parenthetical material (such as editor's comments). Useful information was turned into DISCUSSION sections, the rest was deleted. 2) Completing the tasks listed in the last draft's To be Done sections. As a part of this task, a new "to be done" list was developed and included as an appendix to the current document. 3) Rolling Philip Almquist's "Ruminations on the Next Hop" and "Ruminations on Route Leaking" into this document. These represent significant work and should be kept. 4) Fulfilling the last intents of the working group as determined from the archival material. The intent of this effort was to get the document into a form suitable for publication as an Historical RFC so that the significant work which went into the creation of this document would be preserved.
議事録(注意、およびワーキンググループの他のメンバー)は、インターネットAreaディレクターの依頼で、現在のエディタがドキュメントの最後の草稿を取って、メーリングリストアーカイブに相談した後に、現在のフォームにドキュメントを編集しました。 この取り組みは以下のタスクを含んでいました: 1) すべての挿入句の材料(エディタのコメントなどの)を削除します。 役に立つ情報はDISCUSSION部に変えられて、残りは削除されました。 2) Done部になってください最後の草稿のToにリストアップされたタスクを完成して。 このタスクの一部として、「するために」新しいリストは、付録として現在のドキュメントに開発されて、含められました。 3) 回転しているフィリップAlmquistの「次のホップにおける反芻」とこのドキュメントへの「ルート漏出の反芻。」 これらは、重要な仕事を表して、保たれるべきです。 4) 記録保管所の材料から決定するようにワーキンググループの最後の「不-テント」を実現させます。 この取り組みの意図はこのドキュメントの作成に入った重要な仕事が保存されるようにHistorical RFCとして公表に適したフォームにドキュメントを手に入れることでした。
The content and form of this document are due, in large part, to the working group's chair, and document's original editor and author: Philip Almquist. Without his efforts, this document would not exist.
このドキュメントの内容とフォームは当然です、主に、ドキュメントのワーキンググループのいす、元のエディタ、および作者に: フィリップAlmquist。 彼の取り組みがなければ、このドキュメントは存在していないでしょう。
Almquist & Kastenholz [Page 1] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[1ページ]RFC1716
1. INTRODUCTION
1. 序論
The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document.
この仕事の目標はインターネットGateways[INTRO: 1)のためにRFC-1009、Requirementsを新しいドキュメントに取り替えることです。
This memo is an intermediate step toward that goal. It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. The Internet community usually refers to such devices as IP routers or simply routers; The OSI community refers to such devices as intermediate systems. Many older Internet documents refer to these devices as gateways, a name which more recently has largely passed out of favor to avoid confusion with application gateways.
このメモはその目標に向かった途中経過です。 それは、インターネット・プロトコル群のネットワーク層推進機能を実行するデバイスのための要件を定義して、議論します。 通常、インターネットコミュニティはIPルータや単にルータのようなデバイスについて言及します。 OSI共同体は中間システムのようなデバイスについて言及します。多くの、より古いインターネットドキュメントがゲートウェイとしてのこれらのデバイスについて言及します、より最近アプリケーションゲートウェイへの混乱を避けるために好意から主に去った名前。
An IP router can be distinguished from other sorts of packet switching devices in that a router examines the IP protocol header as part of the switching process. It generally has to modify the IP header and to strip off and replace the Link Layer framing.
ルータが切替処理の一部としてIPプロトコルヘッダーを調べるので、他の種類のパケット交換デバイスとIPルータを区別できます。 一般に、それは、Link Layer縁どりをIPヘッダーを変更して、全部はぎ取って、取り替えなければなりません。
The authors of this memo recognize, as should its readers, that many routers support multiple protocol suites, and that support for multiple protocol suites will be required in increasingly large parts of the Internet in the future. This memo, however, does not attempt to specify Internet requirements for protocol suites other than TCP/IP.
このメモの作者は、読者であるべきであることのように多くのルータが、複数のプロトコルがスイートであるとサポートして、複数のプロトコル群のサポートが将来インターネットのますますかなりの部分で必要であると認めます。 しかしながら、このメモは、TCP/IP以外のプロトコル群のためのインターネット要件を指定するのを試みません。
This document enumerates standard protocols that a router connected to the Internet must use, and it incorporates by reference the RFCs and other documents describing the current specifications for these protocols. It corrects errors in the referenced documents and adds additional discussion and guidance for an implementor.
このドキュメントはインターネットに関連しているルータが使用しなければならない標準プロトコルを列挙します、そして、それは参照でこれらのプロトコルのための現在の仕様を説明するRFCsと他のドキュメントを組み込みます。 それは、参照をつけられたドキュメントで間違いを直して、作成者のために追加議論と指導を加えます。
For each protocol, this final version of this memo also contains an explicit set of requirements, recommendations, and options. The reader must understand that the list of requirements in this memo is incomplete by itself; the complete set of requirements for an Internet protocol router is primarily defined in the standard protocol specification documents, with the corrections, amendments, and supplements contained in this memo.
また、各プロトコルのために、このメモのこの最終版は要件、推薦、および明白なオプションを含んでいます。 読者は、このメモによる要件のリストがそれ自体で不完全であることを理解しなければなりません。 インターネットプロトコルルータのための完全なセットの要件は標準プロトコル仕様ドキュメントで主として定義されます、このメモに含まれた修正、修正、および補足で。
This memo should be read in conjunction with the Requirements for Internet Hosts RFCs ([INTRO:2] and [INTRO:3]). Internet hosts and routers must both be capable of originating IP datagrams and receiving IP datagrams destined for them. The major distinction between Internet hosts and routers is that routers are required to implement forwarding algorithms and Internet hosts do not require forwarding capabilities. Any Internet host acting as a router must adhere to the requirements contained in the final version of this memo.
このメモはインターネットHosts RFCsのためのRequirementsに関連して読まれるべきです([INTRO: 2]と[INTRO: 3])。 インターネット・ホストとルータは、IPデータグラムを溯源して、ともにそれらのために運命づけられたIPデータグラムを受けることができなければなりません。 インターネット・ホストとルータの主要な区別はルータが推進がアルゴリズムであると実装するのに必要であり、インターネット・ホストが、能力を進めるのを必要としないということです。 ルータとして務めているどんなインターネット・ホストもこのメモの最終版に含まれた要件を固く守らなければなりません。
Almquist & Kastenholz [Page 2] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[2ページ]RFC1716
The goal of open system interconnection dictates that routers must function correctly as Internet hosts when necessary. To achieve this, this memo provides guidelines for such instances. For simplification and ease of document updates, this memo tries to avoid overlapping discussions of host requirements with [INTRO:2] and [INTRO:3] and incorporates the relevant requirements of those documents by reference. In some cases the requirements stated in [INTRO:2] and [INTRO:3] are superseded by the final version of this document.
開放形システム相互接続の目標は、必要であるときに、ルータがインターネット・ホストとして正しく機能しなければならないと決めます。 これを達成するために、このメモはそのようなインスタンスのためのガイドラインを提供します。 簡素化とドキュメント最新版の容易さのために、このメモは、[INTRO: 2]と[INTRO: 3]とのホスト要件の議論を重ね合わせるのを避けようとして、参照でそれらのドキュメントの関連要件を取り入れます。 いくつかの場合、[INTRO: 2]と[INTRO: 3]で述べられた要件はこのドキュメントの最終版によって取って代わられます。
A good-faith implementation of the protocols produced after careful reading of the RFCs, with some interaction with the Internet technical community, and that follows good communications software engineering practices, should differ from the requirements of this memo in only minor ways. Thus, in many cases, the requirements in this document are already stated or implied in the standard protocol documents, so that their inclusion here is, in a sense, redundant. However, they were included because some past implementation has made the wrong choice, causing problems of interoperability, performance, and/or robustness.
プロトコルの誠実実装はRFCsの熟読の後に生産されました、インターネット技術団体とのいくつかの相互作用で、そして、それが良い通信ソフトウエア工学習慣に続いて、小さい方の方法だけでこのメモの要件と異なるべきです。 したがって、多くの場合、要件は、標準プロトコルドキュメントで本書では既に述べられているか、または含意されます、ここでの彼らの包含がある意味で余分であるように。 しかしながら、相互運用性、性能、そして/または、丈夫さの問題を引き起こして、過去の何らかの実装が選択を誤ったので、それらは含まれていました。
This memo includes discussion and explanation of many of the requirements and recommendations. A simple list of requirements would be dangerous, because:
このメモは要件と推薦の多くに関する議論と説明を含んでいます。 要件の単純並びが危険であるだろう、:
o Some required features are more important than others, and some features are optional.
o いくつかの必要な特徴が他のものより重要です、そして、いくつかの特徴が任意です。
o Some features are critical in some applications of routers but irrelevant in others.
o いくつかの特徴が、ルータのいくつかのアプリケーションで重要ですが、他のもので無関係です。
o There may be valid reasons why particular vendor products that are designed for restricted contexts might choose to use different specifications.
o 制限された文脈のために設計されている特定のメーカー製品が規格相違を使用するのを選ぶかもしれない正当な理由があるかもしれません。
However, the specifications of this memo must be followed to meet the general goal of arbitrary router interoperation across the diversity and complexity of the Internet. Although most current implementations fail to meet these requirements in various ways, some minor and some major, this specification is the ideal towards which we need to move.
しかしながら、インターネットの多様性と複雑さの向こう側に任意のルータinteroperationの一般的な目標を達成するためにこのメモの仕様に従わなければなりません。 ほとんどの現在の実装は様々な道、ある未成年者、および何らかの少佐におけるこれらの必要条件を満たしませんが、この仕様は私たちが移行する必要がある理想です。
These requirements are based on the current level of Internet architecture. This memo will be updated as required to provide additional clarifications or to include additional information in those areas in which specifications are still evolving.
これらの要件は現在のレベルのインターネットアーキテクチャに基づいています。 追加明確化を提供するか、または仕様がまだ発展しているそれらの領域に追加情報を含むように必要に応じてこのメモをアップデートするでしょう。
Almquist & Kastenholz [Page 3] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[3ページ]RFC1716
1.1 Reading this Document
1.1 このDocumentを読むこと。
1.1.1 Organization
1.1.1 組織
This memo emulates the layered organization used by [INTRO:2] and
[INTRO:3]. Thus, Chapter 2 describes the layers found in the
Internet architecture. Chapter 3 covers the Link Layer. Chapters
4 and 5 are concerned with the Internet Layer protocols and
forwarding algorithms. Chapter 6 covers the Transport Layer.
Upper layer protocols are divided between Chapter 7, which
discusses the protocols which routers use to exchange routing
information with each other, Chapter 8, which discusses network
management, and Chapter 9, which discusses other upper layer
protocols. The final chapter covers operations and maintenance
features. This organization was chosen for simplicity, clarity,
and consistency with the Host Requirements RFCs. Appendices to
this memo include a bibliography, a glossary, and some conjectures
about future directions of router standards.
このメモは[INTRO: 2]と[INTRO: 3]時までに使用される層にされた組織を見習います。 したがって、第2章はインターネットアーキテクチャで見つけられた層について説明します。 第3章はLink Layerをカバーしています。 第4章と第5章は、インターネットLayerプロトコルに関係があって、アルゴリズムを送っています。第6章はTransport Layerをカバーしています。 上側の層のプロトコルは第7章と、どれがルータがルーティング情報を互いと交換するのに使用するプロトコルについて議論するか、そして、第8章と、どれがネットワークマネージメントについて議論するか、そして、第9章(他の上側の層のプロトコルについて議論するもの)の間分割されます。 最終的な章は操作とメインテナンス機能を含んでいます。 この組織はHost Requirements RFCsがある簡単さ、明快、および一貫性に選ばれました。 このメモへの付録はルータ規格の将来の方向に関する図書目録、用語集、およびいくつかの憶説を含んでいます。
In describing the requirements, we assume that an implementation
strictly mirrors the layering of the protocols. However, strict
layering is an imperfect model, both for the protocol suite and
for recommended implementation approaches. Protocols in different
layers interact in complex and sometimes subtle ways, and
particular functions often involve multiple layers. There are
many design choices in an implementation, many of which involve
creative breaking of strict layering. Every implementor is urged
to read [INTRO:4] and [INTRO:5].
要件について説明する際に、私たちは、実装が厳密にプロトコルのレイヤリングを反映すると思います。 しかしながら、厳しいレイヤリングはプロトコル群とお勧めの実装アプローチのための不完全なモデルです。 異なった層のプロトコルは複雑で時々微妙な方法で相互作用します、そして、特定の機能はしばしば複数の層にかかわります。 実装には多くのデザイン選択があります。その多くが厳しいレイヤリングを創造的な壊すことにかかわります。 すべての作成者が[INTRO: 4]と[INTRO: 5]を読むよう促されます。
In general, each major section of this memo is organized into the
following subsections:
一般に、このメモのそれぞれの主要なセクションは以下の小区分に組織化されます:
(1) Introduction
(1) 序論
(2) Protocol Walk-Through - considers the protocol specification
documents section-by-section, correcting errors, stating
requirements that may be ambiguous or ill-defined, and
providing further clarification or explanation.
通じて(2)プロトコルWalk--プロトコル仕様ドキュメントがセクションであることごとに、あいまいであるかほとんど定義されていないかもしれなくて、さらなる明確化か説明を提供している要件を述べて、間違いを直して、考えます。
(3) Specific Issues - discusses protocol design and
implementation issues that were not included in the walk-
through.
(3)の特定のIssues--散歩で突き抜けた状態で含まれていなかったプロトコルデザインと導入問題について議論します。
Under many of the individual topics in this memo, there is
parenthetical material labeled DISCUSSION or IMPLEMENTATION. This
material is intended to give a justification, clarification or
このメモによる個々の話題の多くの下では、DISCUSSIONかIMPLEMENTATIONとラベルされた挿入句の材料があります。 またはこの材料が正当化、明確化を与えることを意図する。
Almquist & Kastenholz [Page 4] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[4ページ]RFC1716
explanation to the preceding requirements text. The
implementation material contains suggested approaches that an
implementor may want to consider. The DISCUSSION and
IMPLEMENTATION sections are not part of the standard.
前の要件テキストへの説明。 材料が含む実装は作成者が考えたがっているかもしれないアプローチを示しました。 DISCUSSIONとIMPLEMENTATION部は規格の一部ではありません。
1.1.2 Requirements
1.1.2 要件
In this memo, the words that are used to define the significance
of each particular requirement are capitalized. These words are:
このメモでは、それぞれの特定の要件の意味を定義するのに使用される単語は大文字で書かれます。 これらの単語は以下の通りです。
o MUST
This word means that the item is an absolute requirement of the
specification.
o Thisは項目がある手段を言い表さなければなりません。仕様に関する絶対条件。
o MUST IMPLEMENT
This phrase means that this specification requires that the
item be implemented, but does not require that it be enabled by
default.
o それがデフォルトで可能にされるのが必要でないことで、IMPLEMENT Thisは実装された状態でこの仕様が必要とする項目がある手段を言葉で表さなければなりませんか?
o MUST NOT
This phrase means that the item is an absolute prohibition of
the specification.
o Thisは項目がある手段を言葉で表してはいけません。仕様の絶対禁止。
o SHOULD
This word means that there may exist valid reasons in
particular circumstances to ignore this item, but the full
implications should be understood and the case carefully
weighed before choosing a different course.
o 有効な状態で存在するかもしれない手段がこの項目を無視するために特定の事情で推論しますが、完全な含意が理解されるべきであるというSHOULD This単語と異なったコースを選ぶ前に慎重に熟慮されたケース。
o SHOULD IMPLEMENT
This phrase is similar in meaning to SHOULD, but is used when
we recommend that a particular feature be provided but does not
necessarily recommend that it be enabled by default.
o SHOULD IMPLEMENT This句は意味においてSHOULDと同様です、私たちが、特定の特徴が提供されることを勧めるとき、使用されていますが、それがデフォルトで可能にされることを必ず勧めるというわけではないのを除いて。
o SHOULD NOT
This phrase means that there may exist valid reasons in
particular circumstances when the described behavior is
acceptable or even useful, but the full implications should be
understood and the case carefully weighed before implementing
any behavior described with this label.
o SHOULD NOT Thisはこのラベルで説明されたどんな振舞いも実装する前にいつ説明された振舞いが許容できるか、または役に立ちさえしますが、完全な含意が理解されるべきであるか、そして、この件が慎重に熟慮した特定の事情の正当な理由が存在するかもしれない手段を言葉で表します。
o MAY
This word means that this item is truly optional. One vendor
may choose to include the item because a particular marketplace
requires it or because it enhances the product, for example;
another vendor may omit the same item.
o 5月のThis単語は、本当に、この項目が任意であることを意味します。 特定の市場がそれを必要とするか、または例えば製品を高めるので、1つのベンダーが、項目を含んでいるのを選ぶかもしれません。 別のベンダーは同じ項目を省略するかもしれません。
Almquist & Kastenholz [Page 5] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[5ページ]RFC1716
1.1.3 Compliance
1.1.3 承諾
Some requirements are applicable to all routers. Other
requirements are applicable only to those which implement
particular features or protocols. In the following paragraphs,
Relevant refers to the union of the requirements applicable to all
routers and the set of requirements applicable to a particular
router because of the set of features and protocols it has
implemented.
いくつかの要件がすべてのルータに適切です。 他の要件は特定の特徴かプロトコルを実装するものだけに適切です。 以下のパラグラフで、Relevantはそれが実装した特徴のセットのために特定のルータに適切な要件とプロトコルのすべてのルータとセットに適切な要件の組合について言及します。
Note that not all Relevant requirements are stated directly in
this memo. Various parts of this memo incorporate by reference
sections of the Host Requirements specification, [INTRO:2] and
[INTRO:3]. For purposes of determining compliance with this memo,
it does not matter whether a Relevant requirement is stated
directly in this memo or merely incorporated by reference from one
of those documents.
すべてのRelevant要件が直接このメモに述べられているというわけではないことに注意してください。 このメモの様々な部分はHost Requirements仕様、[INTRO: 2]、および[INTRO: 3]の参照部のそばで盛込みます。 このメモへのコンプライアンスを決定する目的のために、Relevant要件が直接このメモに述べられているか、またはそれらのドキュメントの1つからの参照で単に組み込まれるかが重要ではありません。
An implementation is said to be conditionally compliant if it
satisfies all of the Relevant MUST, MUST IMPLEMENT, and MUST NOT
requirements. An implementation is said to be unconditionally
compliant if it is conditionally compliant and also satisfies all
of the Relevant SHOULD, SHOULD IMPLEMENT, and SHOULD NOT
requirements. An implementation is not compliant if it is not
conditionally compliant (i.e., it fails to satisfy one or more of
the Relevant MUST, MUST IMPLEMENT, or MUST NOT requirements).
満足させるなら条件付きに言いなりになると言われる場合、Relevantのすべてがそうしなければなりません、MUST IMPLEMENTということであり、実装はNOT要件がことでなければなりません。 実装は、それが条件付きに言いなりになるなら無条件に言いなりになると言われて、また、Relevant SHOULD、SHOULD IMPLEMENT、およびSHOULD NOT要件のすべてを満たします。 それが条件付きに言いなりにならないなら、実装は対応しません。または、(1つを満たしてはいけませんか、または一層のRelevantが満足しなければなりません、MUST IMPLEMENT、要件でない)でなければならない
For any of the SHOULD and SHOULD NOT requirements, a router may
provide a configuration option that will cause the router to act
other than as specified by the requirement. Having such a
configuration option does not void a router's claim to
unconditional compliance as long as the option has a default
setting, and that leaving the option at its default setting causes
the router to operate in a manner which conforms to the
requirement.
SHOULDとSHOULD NOT要件のいずれのためにも、ルータは要件によって指定されるのを除いて、ルータが行動する設定オプションを提供するかもしれません。 そのような設定オプションを持っている場合、要件に従う方法で作動するために既定の設定原因におけるオプションをルータに残して、オプションに既定の設定、およびそれがいる限り、ルータのクレームは無条件の承諾に欠如しません。
Likewise, routers may provide, except where explicitly prohibited
by this memo, options which cause them to violate MUST or MUST NOT
requirements. A router which provides such options is compliant
(either fully or conditionally) if and only if each such option
has a default setting which causes the router to conform to the
requirements of this memo. Please note that the authors of this
memo, although aware of market realities, strongly recommend
against provision of such options. Requirements are labeled MUST
or MUST NOT because experts in the field have judged them to be
particularly important to interoperability or proper functioning
in the Internet. Vendors should weigh carefully the customer
同様に、このメモで明らかに禁止されているのを除いて、ルータが違反するためにそれらを引き起こすオプションを提供するかもしれない、NOT要件はそうしなければなりません。 そして、そのようなオプションを提供するルータが対応である、(完全か条件付きに)そのような各オプションにルータがこのメモの要件に従う既定の設定がある場合にだけ。 このメモ意識していますが、作者が強く現実を売り出すというメモはそのようなオプションに関する条項に対して推薦してくれますか? または、要件がラベルされる、分野の専門家が、インターネットで機能しながら彼らが特に相互運用性に重要であるか、または適切であると判断したので、そうしてはいけません。 ベンダーは慎重に顧客の重さを計るべきです。
Almquist & Kastenholz [Page 6] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[6ページ]RFC1716
support costs of providing options which violate those rules.
それらの規則に違反する提供オプションのコストをサポートしてください。
Of course, this memo is not a complete specification of an IP
router, but rather is closer to what in the OSI world is called a
profile. For example, this memo requires that a number of
protocols be implemented. Although most of the contents of their
protocol specifications are not repeated in this memo,
implementors are nonetheless required to implement the protocols
according to those specifications.
もちろん、このメモは、IPルータの完全な仕様ではありませんが、OSI世界にプロフィールと呼ばれるものの、より近くにむしろあります。 例えば、このメモは、多くのプロトコルが実装されるのを必要とします。 それらのプロトコル仕様の内容の大部分はこのメモで繰り返されませんが、作成者はそれらの仕様通りにそれにもかかわらず、プロトコルを実装しなければなりません。
1.2 Relationships to Other Standards
1.2 他の規格との関係
There are several reference documents of interest in checking the current status of protocol specifications and standardization:
プロトコル仕様と標準化の現在の状態をチェックするのにおいて興味深いいくつかの参考書類があります:
o INTERNET OFFICIAL PROTOCOL STANDARDS
This document describes the Internet standards process and lists
the standards status of the protocols. As of this writing, the
current version of this document is STD 1, RFC 1610, [ARCH:7].
This document is periodically re-issued. You should always
consult an RFC repository and use the latest version of this
document.
o OFFICIALプロトコルSTANDARDS Thisが記録するインターネットは、インターネット標準化過程を説明して、プロトコルの規格状態を記載します。 この書くこと現在、このドキュメントの最新版はSTD1、RFC1610です[ARCH: 7]。 このドキュメントは定期的に再発行されます。 あなたは、いつもRFC倉庫に相談して、このドキュメントの最新版を使用するべきです。
o Assigned Numbers
This document lists the assigned values of the parameters used
in the various protocols. For example, IP protocol codes, TCP
port numbers, Telnet Option Codes, ARP hardware types, and
Terminal Type names. As of this writing, the current version of
this document is STD 2, RFC 1700, [INTRO:7]. This document is
periodically re-issued. You should always consult an RFC
repository and use the latest version of this document.
o 割り当てられた民数記Thisはパラメタの割り当てられた値が様々なプロトコルに使用したリストを記録します。 例えば、IPプロトコルコードであり、TCPは数、Telnet Option Codes、ARPハードウェアタイプ、およびTerminal Type名を移植します。 この書くこと現在、このドキュメントの最新版はSTD2、RFC1700です[INTRO: 7]。 このドキュメントは定期的に再発行されます。 あなたは、いつもRFC倉庫に相談して、このドキュメントの最新版を使用するべきです。
o Host Requirements
This pair of documents reviews the specifications that apply to
hosts and supplies guidance and clarification for any
ambiguities. Note that these requirements also apply to
routers, except where otherwise specified in this memo. As of
this writing (December, 1993) the current versions of these
documents are RFC 1122 and RFC 1123, (STD 3) [INTRO:2], and
[INTRO:3] respectively.
o ドキュメントのホストRequirements This組は、ホストに適用される仕様を再検討して、どんなあいまいさのための指導と明確化も供給します。 また、別の方法でこのメモで指定されているところを除いて、これらの要件がルータに適用されることに注意してください。 この書くこと(1993年12月)現在、これらのドキュメントの最新版がRFC1122であり、RFC1123、(STD3)は、[INTRO: 2]と、[INTRO: 3]です。それぞれ。
o Router Requirements (formerly Gateway Requirements)
This memo.
o ルータRequirements、(以前ゲートウェイRequirements) このメモ。
Note that these documents are revised and updated at different
times; in case of differences between these documents, the most
recent must prevail.
いろいろな時間にこれらのドキュメントを改訂して、アップデートすることに注意してください。 間の違いの場合には、これらのドキュメント、最新の必須は行き渡っています。
Almquist & Kastenholz [Page 7] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[7ページ]RFC1716
These and other Internet protocol documents may be obtained from
the:
これらと他のインターネットプロトコルドキュメントを入手するかもしれない、:
The InterNIC
DS.INTERNIC.NET
InterNIC Directory and Database Service
InterNIC DS.INTERNIC.NET InterNICディレクトリとデータベース・サービス
+1 (800) 444-4345 or +1 (619) 445-4600
+1 (800) 444-4345か+1 (619) 445-4600
info@internic.net
info@internic.net
1.3 General Considerations
1.3 一般問題
There are several important lessons that vendors of Internet software have learned and which a new vendor should consider seriously.
インターネット・ソフトのベンダーが学んで、新しいベンダーが真剣に考えるべきであるいくつかの重要な教訓があります。
1.3.1 Continuing Internet Evolution
1.3.1 継続するインターネット発展
The enormous growth of the Internet has revealed problems of
management and scaling in a large datagram-based packet
communication system. These problems are being addressed, and as
a result there will be continuing evolution of the specifications
described in this memo. New routing protocols, algorithms, and
architectures are constantly being developed. New and additional
internet-layer protocols are also constantly being devised.
Because routers play such a crucial role in the Internet, and
because the number of routers deployed in the Internet is much
smaller than the number of hosts, vendors should expect that
router standards will continue to evolve much more quickly than
host standards. These changes will be carefully planned and
controlled since there is extensive participation in this planning
by the vendors and by the organizations responsible for operation
of the networks.
インターネットの莫大な成長は管理と大きいデータグラムベースのパケット通信システムを計量するという問題を明らかにしました。 これらの問題は扱われています、そして、その結果、このメモで説明された仕様の継続する発展があるでしょう。 新しいルーティング・プロトコル、アルゴリズム、およびアーキテクチャは絶えず開発されています。 また、新しくて追加しているインターネット層のプロトコルは絶えず工夫されています。 ルータがインターネットでそのような極めて重要な役割をプレーして、インターネットで配布されたルータの数がホストの数よりはるかに少ないので、ベンダーは、ルータ規格が、規格を接待するよりはるかに急速に発展し続けると予想するべきです。 ベンダーとネットワークの操作に責任がある組織によるこの計画への大規模な参加があるので、これらの変化は、慎重に計画されて、制御されるでしょう。
Development, evolution, and revision are characteristic of
computer network protocols today, and this situation will persist
for some years. A vendor who develops computer communications
software for the Internet protocol suite (or any other protocol
suite!) and then fails to maintain and update that software for
changing specifications is going to leave a trail of unhappy
customers. The Internet is a large communication network, and the
users are in constant contact through it. Experience has shown
that knowledge of deficiencies in vendor software propagates
quickly through the Internet technical community.
開発、発展、および改正は今日コンピュータ・ネットワーク・プロトコルで独特です、そして、この状況は数年間持続するでしょう。 仕様を変えるためのそのソフトウェアをインターネット・プロトコル群(または、いかなる他のプロトコル群も!)のためのコンピュータコミュニケーションソフトウェアを開発して、維持して、次にアップデートしないベンダーは不幸な顧客の道を出るでしょう。 インターネットは大きい通信ネットワークです、そして、ユーザはそれを通して常に接触しています。 経験は、メーカー・ソフトウエアの欠乏に関する知識がインターネット技術団体を通ってすばやく伝播されるのを示しました。
Almquist & Kastenholz [Page 8] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[8ページ]RFC1716
1.3.2 Robustness Principle
1.3.2 堅牢性の原則
At every layer of the protocols, there is a general rule (from
[TRANS:2] by Jon Postel) whose application can lead to enormous
benefits in robustness and interoperability:
プロトコルのあらゆる層に、丈夫さと相互運用性にはアプリケーションが莫大な利益につながることができる一般的な規則(ジョン・ポステルが[TRANS: 2]からの)があります:
Be conservative in what you do,
be liberal in what you accept from others.
あなたがすることで保守的であってください、そして、あなたが他のものから受け入れるもので寛容であってください。
Software should be written to deal with every conceivable error,
no matter how unlikely; sooner or later a packet will come in with
that particular combination of errors and attributes, and unless
the software is prepared, chaos can ensue. In general, it is best
to assume that the network is filled with malevolent entities that
will send packets designed to have the worst possible effect.
This assumption will lead to suitably protective design. The most
serious problems in the Internet have been caused by unforeseen
mechanisms triggered by low probability events; mere human malice
would never have taken so devious a course!
ソフトウェアはどんなにありそうもなくても想像できるあらゆる誤りに対処するために書かれるべきです。 遅かれ早かれ、パケットは誤りと属性のその特定の組み合わせで入るでしょう、そして、ソフトウェアが準備されていない場合、カオスは続くことができます。 一般に、ネットワークが最もひどく可能な効果を持つように設計されたパケットを送る悪意の実体で満たされると仮定するのは最も良いです。 この仮定は適当に保護的なデザインにつながるでしょう。 インターネットで最も重大な問題は低い確率イベントによって引き起こされた予期しないメカニズムによって引き起こされました。 単なる人間の悪意はとても遠回りのコースを一度も取ったことがありません!
Adaptability to change must be designed into all levels of router
software. As a simple example, consider a protocol specification
that contains an enumeration of values for a particular header
field - e.g., a type field, a port number, or an error code; this
enumeration must be assumed to be incomplete. If the protocol
specification defines four possible error codes, the software must
not break when a fifth code shows up. An undefined code might be
logged, but it must not cause a failure.
すべてのレベルのルータソフトウェアに変化する適応性を設計しなければなりません。 簡単な例として、特定のヘッダーフィールドのためにプロトコルが値の列挙を含む仕様であると考えてください--例えば、タイプ分野、ポートナンバー、またはエラーコード 不完全であるとこの列挙を思わなければなりません。 プロトコル仕様が4つの可能なエラーコードを定義するなら、5番目のコードが現れると、ソフトウェアが知れ渡ってはいけません。 未定義コードは登録されるかもしれませんが、それは失敗を引き起こしてはいけません。
The second part of the principle is almost as important: software
on hosts or other routers may contain deficiencies that make it
unwise to exploit legal but obscure protocol features. It is
unwise to stray far from the obvious and simple, lest untoward
effects result elsewhere. A corollary of this is watch out for
misbehaving hosts; router software should be prepared to survive
in the presence of misbehaving hosts. An important function of
routers in the Internet is to limit the amount of disruption such
hosts can inflict on the shared communication facility.
原則の第二部はほとんど同じくらい重要です: ホストか他のルータのソフトウェアは法的な、しかし、不鮮明なプロトコル機能を利用するのを賢明でなくする欠乏を含むかもしれません。 不運な効果がほかの場所に結果として生じるといけないので、明白で簡単から遠くにさ迷うのは賢明ではありません。 この推論はふらちな事をしているホストに注意することです。 ルータソフトウェアはふらちな事をしているホストの面前で生き残るように準備されるべきです。 インターネットでのルータの重要な機能はそのようなホストが共有された通信機器の上で加えることができる分裂の量を制限することです。
1.3.3 Error Logging
1.3.3 エラー・ロギング
The Internet includes a great variety of systems, each
implementing many protocols and protocol layers, and some of these
contain bugs and misfeatures in their Internet protocol software.
As a result of complexity, diversity, and distribution of
function, the diagnosis of problems is often very difficult.
それぞれ多くのプロトコルとプロトコル層を実装して、インターネットはさまざまなシステムを含んでいます、そして、これらの或るものは彼らのインターネットプロトコル・ソフトウエアにバグとmisfeaturesを含んでいます。 機能の複雑さ、多様性、および分配の結果、問題の診断はしばしば非常に難しいです。
Almquist & Kastenholz [Page 9] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[9ページ]RFC1716
Problem diagnosis will be aided if routers include a carefully
designed facility for logging erroneous or strange events. It is
important to include as much diagnostic information as possible
when an error is logged. In particular, it is often useful to
record the header(s) of a packet that caused an error. However,
care must be taken to ensure that error logging does not consume
prohibitive amounts of resources or otherwise interfere with the
operation of the router.
ルータが誤ったか奇妙なイベントを登録するための入念に設計された施設を含んでいると、問題診断は支援されるでしょう。 誤りがいつ登録されるかというできるだけ多くの診断情報を含んでいるのは重要です。 誤りを引き起こしたパケットのヘッダーを記録するのはしばしば特に、役に立ちます。 しかしながら、エラー・ロギングが禁止の量のリソースを消費もしませんし、そうでなければ、ルータの操作を妨げもしないのを保証するために注意しなければなりません。
There is a tendency for abnormal but harmless protocol events to
overflow error logging files; this can be avoided by using a
circular log, or by enabling logging only while diagnosing a known
failure. It may be useful to filter and count duplicate
successive messages. One strategy that seems to work well is to
both:
o Always count abnormalities and make such counts accessible
through the management protocol (see Chapter 8); and
o Allow the logging of a great variety of events to be
selectively enabled. For example, it might useful to be able
to log everything or to log everything for host X.
異常な、しかし、無害なプロトコルイベントをエラー・ロギングファイルからはみ出させる傾向があります。 循環ログを使用するか、または知られている失敗を診断しているだけである間、伐採を可能にすることによって、これを避けることができます。 それはフィルタとカウント写しの連続したメッセージの役に立つかもしれません。 両方にはうまくいくように思える1つの戦略があります: o いつも異常を数えてください、そして、そのようなカウントを管理プロトコルを通してアクセスしやすくしてください(第8章を参照してください)。 o Allowはさまざまな選択的に可能にされるべきイベントの伐採をそうします。 例えば、それは役に立つかもしれません。すべてを登録するか、またはホストXのためにすべてを登録できるように、役に立ちます。
This topic is further discussed in [MGT:5].
[MGT: 5]でこの話題についてさらに議論します。
1.3.4 Configuration
1.3.4 構成
In an ideal world, routers would be easy to configure, and perhaps
even entirely self-configuring. However, practical experience in
the real world suggests that this is an impossible goal, and that
in fact many attempts by vendors to make configuration easy
actually cause customers more grief than they prevent. As an
extreme example, a router designed to come up and start routing
packets without requiring any configuration information at all
would almost certainly choose some incorrect parameter, possibly
causing serious problems on any networks unfortunate enough to be
connected to it.
理想の世界では、ルータは、構成しやすくて、恐らく自己を完全に構成してさえいるでしょう。 しかしながら、本当の世界の実用的な経験は、これが不可能な目標であり、事実上、構成を簡単にするベンダーによる多くの試みが実際に彼らが防ぐより多くの深い悲しみを顧客に引き起こすのを示します。 極端な例として、全く設定情報を必要としないでルーティングパケットを来て、始めるように設計されたルータはほぼ確実に何らかの不正確なパラメタを選ぶでしょう、十分不幸などんなネットワークの深刻な問題もそれに接続されることをことによると引き起こして。
Often this memo requires that a parameter be a configurable
option. There are several reasons for this. In a few cases there
currently is some uncertainty or disagreement about the best value
and it may be necessary to update the recommended value in the
future. In other cases, the value really depends on external
factors - e.g., the distribution of its communication load, or the
speeds and topology of nearby networks - and self-tuning
algorithms are unavailable and may be insufficient. In some
cases, configurability is needed because of administrative
requirements.
しばしば、このメモは、パラメタが構成可能なオプションであることを必要とします。 このいくつかの理由があります。 いくつかの場合には、最も良い値に関して何らかの不確実性か不一致が現在あります、そして、将来推奨値をアップデートするのが必要であるかもしれません。 他の場合では、値を本当に外部の要素(近いネットワークの例えば、通信負荷の分配か、速度とトポロジー)に依存して、自己調節アルゴリズムは、入手できなく、不十分であるかもしれません。 いくつかの場合、configurabilityが管理要件のために必要です。
Almquist & Kastenholz [Page 10] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[10ページ]RFC1716
Finally, some configuration options are required to communicate
with obsolete or incorrect implementations of the protocols,
distributed without sources, that persist in many parts of the
Internet. To make correct systems coexist with these faulty
systems, administrators must occasionally misconfigure the correct
systems. This problem will correct itself gradually as the faulty
systems are retired, but cannot be ignored by vendors.
最終的に、いくつかの設定オプションが、インターネットの多くの地域に固執するソースなしで分配されたプロトコルの時代遅れの、または、不正確な実装で交信するのに必要です。 正しいシステムにこれらの不完全なシステムと共存させるように、管理者は時折正しいシステムをmisconfigureしなければなりません。この問題を、不完全なシステムが退職しているので徐々にそれ自体を修正しますが、ベンダーは無視できません。
When we say that a parameter must be configurable, we do not
intend to require that its value be explicitly read from a
configuration file at every boot time. For many parameters, there
is one value that is appropriate for all but the most unusual
situations. In such cases, it is quite reasonable that the
parameter default to that value if not explicitly set.
パラメタが構成可能であるに違いないと言うとき、私たちは、値が構成ファイルからあらゆるブート時間で明らかに読まれるのを必要としないつもりです。 多くのパラメタのために、1つのほとんど最も珍しい状況に、適切な値があります。 そのような場合、パラメタがその値をデフォルトとするか、または明らかにセットするのが、かなり妥当です。
This memo requires a particular value for such defaults in some
cases. The choice of default is a sensitive issue when the
configuration item controls accommodation of existing, faulty,
systems. If the Internet is to converge successfully to complete
interoperability, the default values built into implementations
must implement the official protocol, not misconfigurations to
accommodate faulty implementations. Although marketing
considerations have led some vendors to choose misconfiguration
defaults, we urge vendors to choose defaults that will conform to
the standard.
いくつかの場合、このメモはそのようなデフォルトのために特定の値を必要とします。 コンフィギュレーション品目が存在する宿泊設備を制御するとき、デフォルトの選択はデリケートな問題です、不完全です、システム。インターネットが相互運用性を完成するために首尾よく一点に集まるつもりであるなら、実装が組み込まれたデフォルト値は、不完全な実装を収容するためにmisconfigurationsではなく、公式のプロトコルを実装しなければなりません。 マーケティング問題は、いくつかのベンダーがmisconfigurationデフォルトを選ぶように導きましたが、私たちは、規格に従うデフォルトを選ぶようベンダーに促します。
Finally, we note that a vendor needs to provide adequate
documentation on all configuration parameters, their limits and
effects.
最終的に、私たちは、ベンダーが、それらのすべての設定パラメータ、限界、および効果に関する適切なドキュメンテーションを提供する必要に注意します。
1.4 Algorithms
1.4のアルゴリズム
In several places in this memo, specific algorithms that a router ought to follow are specified. These algorithms are not, per se, required of the router. A router need not implement each algorithm as it is written in this document. Rather, an implementation must present a behavior to the external world that is the same as a strict, literal, implementation of the specified algorithm.
方々にこのメモでは、ルータが従うべきである特定のアルゴリズムは指定されます。 ルータはそういうものとしてこれらのアルゴリズムに要求されません。 それが本書では書かれているとき、ルータは各アルゴリズムを実装する必要はありません。 むしろ、実装は指定されたアルゴリズムの厳しくて、文字通りの実装と同じ外界への振舞いを提示しなければなりません。
Algorithms are described in a manner that differs from the way a good implementor would implement them. For expository purposes, a style that emphasizes conciseness, clarity, and independence from implementation details has been chosen. A good implementor will choose algorithms and implementation methods which produce the same results as these algorithms, but may be more efficient or less general.
アルゴリズムは良い作成者がそれらを実装するだろうという方法と異なっている方法で説明されます。 解説の目的のために、実装の詳細から簡潔、明快、および独立を強調するスタイルは選ばれました。 良い作成者は、これらのアルゴリズムと同じ結果を生むアルゴリズムと実装メソッドを選びますが、より有能であるか、またはそれほど一般的でないかもしれません。
Almquist & Kastenholz [Page 11] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[11ページ]RFC1716
We note that the art of efficient router implementation is outside of the scope of this memo.
私たちは、効率的なルータ実装の芸術がこのメモの範囲の外にあることに注意します。
Almquist & Kastenholz [Page 12] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[12ページ]RFC1716
2. INTERNET ARCHITECTURE
2. インターネットアーキテクチャ
This chapter does not contain any requirements. However, it does contain useful background information on the general architecture of the Internet and of routers.
本章はどんな要件も含んでいません。 しかしながら、それはインターネットとルータの一般的なアーキテクチャの役に立つ基礎的な情報を含んでいます。
General background and discussion on the Internet architecture and supporting protocol suite can be found in the DDN Protocol Handbook [ARCH:1]; for background see for example [ARCH:2], [ARCH:3], and [ARCH:4]. The Internet architecture and protocols are also covered in an ever-growing number of textbooks, such as [ARCH:5] and [ARCH:6].
DDNプロトコルHandbook[ARCH: 1]でインターネットアーキテクチャとプロトコル群を支えるのと一般バックグラウンドと議論を見つけることができます。 バックグラウンドに関しては、例えば、[ARCH: 2]、[ARCH: 3]、および[ARCH: 4]を見てください。 また、インターネットアーキテクチャとプロトコルは[ARCH: 5]や[ARCH: 6]などのとどまるところを知らない数の教科書で含まれています。
2.1 Introduction
2.1 序論
The Internet system consists of a number of interconnected packet networks supporting communication among host computers using the Internet protocols. These protocols include the Internet Protocol (IP), the Internet Control Message Protocol (ICMP), the Internet Group Management Protocol (IGMP), and a variety transport and application protocols that depend upon them. As was described in Section [1.2], the Internet Engineering Steering Group periodically releases an Official Protocols memo listing all of the Internet protocols.
インターネット・システムはホストコンピュータの中でインターネットプロトコルを使用することでコミュニケーションをサポートする多くのインタコネクトされたパケット網から成ります。 これらのプロトコルはそれらによるインターネットプロトコル(IP)、インターネット・コントロール・メッセージ・プロトコル(ICMP)、インターネットGroup Managementプロトコル(IGMP)、バラエティー輸送、およびアプリケーション・プロトコルを含んでいます。 セクション[1.2]で説明されたように、インターネットEngineering Steering Groupは定期的にインターネットプロトコルのすべてを記載するOfficialプロトコルメモを発表します。
All Internet protocols use IP as the basic data transport mechanism. IP is a datagram, or connectionless, internetwork service and includes provision for addressing, type-of-service specification, fragmentation and reassembly, and security. ICMP and IGMP are considered integral parts of IP, although they are architecturally layered upon IP. ICMP provides error reporting, flow control, first-hop router redirection, and other maintenance and control functions. IGMP provides the mechanisms by which hosts and routers can join and leave IP multicast groups.
すべてのインターネットプロトコルが基礎データ移送機構としてIPを使用します。 IPはデータグラム、またはコネクションレスなインターネットワークサービスであり、サービスのタイプのアドレシング、仕様、断片化、および再アセンブリへの支給、およびセキュリティを含めます。 それらはIPで建築上層にされますが、ICMPとIGMPはIPの不可欠の部分であると考えられます。 ICMPは誤り報告、フロー制御、最初に、ホップルータリダイレクション、他のメインテナンス、およびコントロール機能を提供します。 IGMPはホストとルータがIPマルチキャストグループに加わって、残すことができるメカニズムを提供します。
Reliable data delivery is provided in the Internet protocol suite by Transport Layer protocols such as the Transmission Control Protocol (TCP), which provides end-end retransmission, resequencing and connection control. Transport Layer connectionless service is provided by the User Datagram Protocol (UDP).
通信制御プロトコル(TCP)などのTransport Layerプロトコルは確実な資料配送をインターネット・プロトコル群に提供します。(通信制御プロトコルは、終わり-終わりの「再-トランスミッション」、再配列、および接続コントロールを提供します)。 コネクションレス型サービスがユーザー・データグラム・プロトコル(UDP)によって提供されるLayerを輸送してください。
Almquist & Kastenholz [Page 13] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[13ページ]RFC1716
2.2 Elements of the Architecture
2.2 アーキテクチャのElements
2.2.1 Protocol Layering
2.2.1 プロトコルレイヤリング
To communicate using the Internet system, a host must implement
the layered set of protocols comprising the Internet protocol
suite. A host typically must implement at least one protocol from
each layer.
インターネット・システムを使用することで交信するために、ホストはインターネット・プロトコル群を包括する層にされたセットのプロトコルを実装しなければなりません。 ホストは各層から少なくとも1つのプロトコルを通常実装しなければなりません。
The protocol layers used in the Internet architecture are as
follows [ARCH:7]:
インターネットアーキテクチャに使用されるプロトコル層は以下の通りです[ARCH: 7]:
o Application Layer
The Application Layer is the top layer of the Internet protocol
suite. The Internet suite does not further subdivide the
Application Layer, although some application layer protocols do
contain some internal sub-layering. The application layer of
the Internet suite essentially combines the functions of the
top two layers - Presentation and Application - of the OSI
Reference Model [ARCH:8]. The Application Layer in the
Internet protocol suite also includes some of the function
relegated to the Session Layer in the OSI Reference Model.
o アプリケーションLayer Application Layerはインターネット・プロトコル群の最上層です。 いくつかの応用層プロトコルが何らかの内部のサブレイヤリングを含んでいますが、インターネットスイートはさらにApplication Layerを細分しません。 インターネットスイートの応用層は本質的にはOSI Reference Model[ARCH: 8]のトップ2の層(プレゼンテーションとApplication)の関数を結合します。 また、インターネット・プロトコル群のApplication LayerはOSI Reference ModelのSession Layerに左遷された機能のいくつかを含んでいます。
We distinguish two categories of application layer protocols:
user protocols that provide service directly to users, and
support protocols that provide common system functions. The
most common Internet user protocols are:
- Telnet (remote login)
- FTP (file transfer)
- SMTP (electronic mail delivery)
私たちは応用層プロトコルの2つのカテゴリを区別します: 直接ユーザに対するサービスを提供して、一般的なシステム機能を提供するプロトコルをサポートするユーザプロトコル。 最も一般的なインターネットユーザプロトコルは以下の通りです。 - telnet(リモート・ログイン)--FTP(ファイル転送)--SMTP(電子メール配送)
There are a number of other standardized user protocols and
many private user protocols.
他の多くの標準化されたユーザプロトコルと多くの個人的なユーザプロトコルがあります。
Support protocols, used for host name mapping, booting, and
management, include SNMP, BOOTP, TFTP, the Domain Name System
(DNS) protocol, and a variety of routing protocols.
ホスト名マッピング、穂ばらみ、および管理において、使用されたサポートプロトコルはSNMP、BOOTP、TFTP、ドメインネームシステム(DNS)プロトコル、およびさまざまなルーティング・プロトコルを含んでいます。
Application Layer protocols relevant to routers are discussed
in chapters 7, 8, and 9 of this memo.
ルータに関連しているアプリケーションLayerプロトコルは第7章と第8章とこのメモの第9章で論じられます。
o Transport Layer
The Transport Layer provides end-to-end communication services.
This layer is roughly equivalent to the Transport Layer in the
OSI Reference Model, except that it also incorporates some of
OSI's Session Layer establishment and destruction functions.
o 輸送Layer Transport Layerはエンド・ツー・エンド通信サービスを提供します。 この層はおよそOSI Reference ModelのTransport Layerに同等です、また、OSIのSession Layer設立と破壊機能のいくつかを取り入れるのを除いて。
Almquist & Kastenholz [Page 14] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[14ページ]RFC1716
There are two primary Transport Layer protocols at present:
- Transmission Control Protocol (TCP)
- User Datagram Protocol (UDP)
現在のところ、2つのプライマリTransport Layerプロトコルがあります: - 通信制御プロトコル(TCP)--ユーザー・データグラム・プロトコル(UDP)
TCP is a reliable connection-oriented transport service that
provides end-to-end reliability, resequencing, and flow
control. UDP is a connectionless (datagram) transport service.
Other transport protocols have been developed by the research
community, and the set of official Internet transport protocols
may be expanded in the future.
TCPは終わりから終わりへの信頼性、再配列、およびフロー制御を提供する信頼できる接続指向の輸送サービスです。 UDPはコネクションレスな(データグラム)輸送サービスです。 他のトランスポート・プロトコルは研究団体によって開発されました、そして、公式のインターネットトランスポート・プロトコルのセットは将来、膨張するかもしれません。
Transport Layer protocols relevant to routers are discussed in
Chapter 6.
第6章でルータに関連している輸送Layerプロトコルについて議論します。
o Internet Layer
All Internet transport protocols use the Internet Protocol (IP)
to carry data from source host to destination host. IP is a
connectionless or datagram internetwork service, providing no
end-to-end delivery guarantees. IP datagrams may arrive at the
destination host damaged, duplicated, out of order, or not at
all. The layers above IP are responsible for reliable delivery
service when it is required. The IP protocol includes
provision for addressing, type-of-service specification,
fragmentation and reassembly, and security.
o インターネットLayer Allインターネットトランスポート・プロトコルは、送信元ホストからあて先ホストまでデータを運ぶのに、インターネットプロトコル(IP)を使用します。 終わりから終わりへの配送保証を全く提供しないで、IPはコネクションレスであるかデータグラム相互ネットワーク・サービスです。 IPデータグラムはあて先ホストに破損していて、コピーされていて、故障していた状態で届くかもしれませんか、とんでもない。 それが必要であるときに、IPの上の層は信頼できる配信サービスに原因となります。 IPプロトコルはサービスのタイプのアドレシング、仕様、断片化、および再アセンブリへの支給、およびセキュリティを含んでいます。
The datagram or connectionless nature of IP is a fundamental
and characteristic feature of the Internet architecture.
IPのデータグラムかコネクションレスな自然がインターネットアーキテクチャの基本的で独特の特徴です。
The Internet Control Message Protocol (ICMP) is a control
protocol that is considered to be an integral part of IP,
although it is architecturally layered upon IP, i.e., it uses
IP to carry its data end-to-end. ICMP provides error
reporting, congestion reporting, and first-hop router
redirection.
インターネット・コントロール・メッセージ・プロトコル(ICMP)はIPの不可欠の部分であると考えられる制御プロトコルです、それがIPで建築上層にされますが、すなわち、それはデータの終わりから終わりを運ぶのにIPを使用します。 ICMPは誤り報告、輻輳通知、および最初に、ホップルータリダイレクションを提供します。
The Internet Group Management Protocol (IGMP) is an Internet
layer protocol used for establishing dynamic host groups for IP
multicasting.
インターネットGroup Managementプロトコル(IGMP)はIPマルチキャスティングのためにダイナミックなホストグループを設立するのに使用されるインターネット層プロトコルです。
The Internet layer protocols IP, ICMP, and IGMP are discussed
in chapter 4.
インターネット層プロトコルのIP、ICMP、およびIGMPは第4章で論じられます。
o Link Layer
To communicate on its directly-connected network, a host must
implement the communication protocol used to interface to that
network. We call this a Link Layer layer protocol.
o リンクLayer Toは直接接続されたネットワークについて話し合って、ホストはそのネットワークに連結するのに使用される通信プロトコルを実装しなければなりません。 私たちは、これをLink Layer層のプロトコルと呼びます。
Almquist & Kastenholz [Page 15] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[15ページ]RFC1716
Some older Internet documents refer to this layer as the
Network Layer, but it is not the same as the Network Layer in
the OSI Reference Model.
いくつかの、より古いインターネットドキュメントがこの層をNetwork Layerと呼びますが、それはOSI Reference ModelでNetwork Layerと同じではありません。
This layer contains everything below the Internet Layer.
この層はインターネットLayerの下にすべてを含んでいます。
Protocols in this Layer are generally outside the scope of
Internet standardization; the Internet (intentionally) uses
existing standards whenever possible. Thus, Internet Link
Layer standards usually address only address resolution and
rules for transmitting IP packets over specific Link Layer
protocols. Internet Link Layer standards are discussed in
chapter 3.
一般にインターネット標準化の範囲の外にこのLayerのプロトコルがあります。 可能であるときはいつも、インターネットは(故意に)既存の規格を使用します。 したがって、通常、インターネットLink Layer規格は、特定のLink Layerプロトコルの上にIPパケットを伝えるために唯一のアドレスが解決と規則であると扱います。 インターネットLink Layer規格は第3章で論じられます。
2.2.2 Networks
2.2.2 ネットワーク
The constituent networks of the Internet system are required to
provide only packet (connectionless) transport. According to the
IP service specification, datagrams can be delivered out of order,
be lost or duplicated, and/or contain errors.
インターネット・システムの構成しているネットワークはパケットの(コネクションレス)の輸送だけを提供しなければなりません。 IPサービス仕様に従って、データグラムは、故障していた状態で提供できるか、失われているか、またはコピーされる、そして/または、誤りを含んでいます。
For reasonable performance of the protocols that use IP (e.g.,
TCP), the loss rate of the network should be very low. In
networks providing connection-oriented service, the extra
reliability provided by virtual circuits enhances the end-end
robustness of the system, but is not necessary for Internet
operation.
IP(例えば、TCP)を使用するプロトコルの妥当な性能において、ネットワークの損失率は非常に低いはずです。 コネクション型サービスを提供するネットワークでは、仮想の回路によって提供された付加的な信頼性は、システムの終わり-終わりの丈夫さを高めますが、インターネット操作に必要ではありません。
Constituent networks may generally be divided into two classes:
一般に、構成しているネットワークは2つのクラスに分割されるかもしれません:
o Local-Area Networks (LANs)
LANs may have a variety of designs. In general, a LAN will
cover a small geographical area (e.g., a single building or
plant site) and provide high bandwidth with low delays. LANs
may be passive (similar to Ethernet) or they may be active
(such as ATM).
o ローカル・エリア・ネットワーク(LAN)LANには、さまざまなデザインがあるかもしれません。 一般に、LANは、小さい地理的な領域(例えば、単一のビルかプラント建設地)をカバーしていて、低い遅れを高帯域に提供するでしょう。 LANが受け身であるかもしれませんか(イーサネットと同様の)、またはそれらはアクティブであるかもしれません(ATMなどの)。
o Wide-Area Networks (WANs)
Geographically-dispersed hosts and LANs are interconnected by
wide-area networks, also called long-haul networks. These
networks may have a complex internal structure of lines and
packet-switches, or they may be as simple as point-to-point
lines.
o ワイドエリアネットワーク(WAN)が地理的にホストを分散して、LANは、広域ネットワークによってインタコネクトされて、また、長期ネットワークと呼ばれます。 これらのネットワークには系列とパケット交換機の複雑な内部の構造が同じくらいあるかもしれないか、それらはポイントツーポイントが立ち並んでいるのとまたは同じくらい簡単であるかもしれません。
Almquist & Kastenholz [Page 16] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[16ページ]RFC1716
2.2.3 Routers
2.2.3 ルータ
In the Internet model, constituent networks are connected together
by IP datagram forwarders which are called routers or IP routers.
In this document, every use of the term router is equivalent to IP
router. Many older Internet documents refer to routers as
gateways.
インターネットモデルでは、構成しているネットワークはIPデータグラム混載業者によって一緒に接続されます(ルータかIPルータと呼ばれます)。 本書では、ルータという用語のあらゆる使用がIPルータに同等です。 多くの、より古いインターネットドキュメントがゲートウェイとしてのルータについて言及します。
Historically, routers have been realized with packet-switching
software executing on a general-purpose CPU. However, as custom
hardware development becomes cheaper and as higher throughput is
required, but special-purpose hardware is becoming increasingly
common. This specification applies to routers regardless of how
they are implemented.
汎用CPUの上にパケット交換ソフトウェア実行がある状態で、歴史的に、ルータは実現されました。 しかしながら、カスタムハードウェア開発が、より安くより高くなるので、スループットが必要ですが、専用ハードウェアはますます一般的になっています。 それらがどう実装されるかにかかわらずこの仕様はルータに適用されます。
A router is connected to two or more networks, appearing to each
of these networks as a connected host. Thus, it has (at least)
one physical interface and (at least) one IP address on each of
the connected networks (this ignores the concept of un-numbered
links, which is discussed in section [2.2.7]). Forwarding an IP
datagram generally requires the router to choose the address of
the next-hop router or (for the final hop) the destination host.
This choice, called routing, depends upon a routing database
within the router. The routing database is also sometimes known
as a routing table or forwarding table.
接続ホストとしてそれぞれのこれらのネットワークにおいて現れて、ルータは2つ以上のネットワークに関連づけられます。 その結果、それには、それぞれの接続ネットワークに関する(少なくとも)の1つの物理インターフェースと(少なくとも)の1つのIPアドレスがあります。(これが不-番号付のリンクの概念を無視する、セクションでどれについて議論するか、[2.2、.7、) 一般に、IPデータグラムを進めるのは、次のホップルータか(最終的なホップのための)あて先ホストのアドレスを選ぶためにルータを必要とします。 ルーティングと呼ばれるこの選択はルータの中でルーティングデータベースによります。 また、ルーティングデータベースは経路指定テーブルか推進テーブルとして時々知られています。
The routing database should be maintained dynamically to reflect
the current topology of the Internet system. A router normally
accomplishes this by participating in distributed routing and
reachability algorithms with other routers.
ルーティングデータベースは、インターネット・システムの現在のトポロジーを反映するためにダイナミックに維持されるべきです。 通常、ルータは、他のルータで分配されたルーティングと可到達性アルゴリズムに参加することによって、これを達成します。
Routers provide datagram transport only, and they seek to minimize
the state information necessary to sustain this service in the
interest of routing flexibility and robustness.
ルータはデータグラム輸送だけを前提とします、そして、それらはルーティングの柔軟性と丈夫さのためにこのサービスを維持するのに必要な州の情報を最小にすると求めます。
Packet switching devices may also operate at the Link Layer; such
devices are usually called bridges. Network segments which are
connected by bridges share the same IP network number, i.e., they
logically form a single IP network. These other devices are
outside of the scope of this document.
また、パケット交換デバイスはLink Layerで作動するかもしれません。 通常、そのようなデバイスはブリッジと呼ばれます。 ブリッジによって接続されるネットワークセグメントは同じIPネットワーク・ナンバーを共有します、すなわち、それらがただ一つのIPネットワークを論理的に形成します。 これらの対向機器がこのドキュメントの範囲の外にあります。
Another variation on the simple model of networks connected with
routers sometimes occurs: a set of routers may be interconnected
with only serial lines, to form a network in which the packet
switching is performed at the Internetwork (IP) Layer rather than
the Link Layer.
ルータに接続されたネットワークの単純モデルの別の変化は時々起こります: 1セットのルータはシリアル・ラインだけでインタコネクトされて、パケット交換がLink LayerよりむしろInternetwork(IP)層で実行されるネットワークを形成するかもしれません。
Almquist & Kastenholz [Page 17] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[17ページ]RFC1716
2.2.4 Autonomous Systems
2.2.4 自律システム
For technical, managerial, and sometimes political reasons, the
routers of the Internet system are grouped into collections called
autonomous systems. The routers included in a single autonomous
system (AS) are expected to:
技術的で、経営者の、そして、時々政治上の理由で、インターネット・システムのルータは自律システムと呼ばれる収集に分類されます。単一の自律システム(AS)に含まれていたルータによる以下のことと予想されます。
o Be under the control of a single operations and maintenance
(O&M) organization;
o ただ一つの操作とメインテナンス(O&M)組織のコントロールの下にいてください。
o Employ common routing protocols among themselves, to
dynamically maintain their routing databases.
o 自分たちの中で一般的なルーティング・プロトコルを使って、ダイナミックにそれらのルーティングデータベースを維持してください。
A number of different dynamic routing protocols have been
developed (see Section [7.2]); the routing protocol within a
single AS is generically called an interior gateway protocol or
IGP.
多くの異なったダイナミックルーティングプロトコルを開発してあります。(セクション[7.2])を見てください。 独身のASの中のルーティング・プロトコルは一般的に内部のゲートウェイプロトコルかIGPと呼ばれます。
An IP datagram may have to traverse the routers of two or more ASs
to reach its destination, and the ASs must provide each other with
topology information to allow such forwarding. An exterior
gateway protocol (generally BGP or EGP) is used for this purpose.
IPデータグラムは目的地に到着するように2ASsのルータを横断しなければならないかもしれません、そして、ASsはそのような推進を許すためにトポロジー情報を互いに提供しなければなりません。 外のゲートウェイプロトコル(一般にBGPかEGP)はこのために使用されます。
2.2.5 Addresses and Subnets
2.2.5 アドレスとサブネット
An IP datagram carries 32-bit source and destination addresses,
each of which is partitioned into two parts - a constituent
network number and a host number on that network. Symbolically:
IPデータグラムは32ビットのソースとそれのそれぞれが2つの部品に仕切られる送付先アドレスを運びます--構成しているネットワーク・ナンバーとそのネットワークのホスト番号。 象徴的に:
IP-address ::= { <Network-number>, <Host-number> }
以下をIP扱ってください:= <ネットワーク・ナンバー>、<ホスト番号>。
To finally deliver the datagram, the last router in its path must
map the Host-number (or rest) part of an IP address into the
physical address of a host connection to the constituent network.
最終的にデータグラムを提供するために、経路における最後のルータはIPアドレスのHost-数(休息する)の部分を構成しているネットワークとのホスト接続の物理アドレスに写像しなければなりません。
This simple notion has been extended by the concept of subnets,
which were introduced in order to allow arbitrary complexity of
interconnected LAN structures within an organization, while
insulating the Internet system against explosive growth in network
numbers and routing complexity. Subnets essentially provide a
multi-level hierarchical routing structure for the Internet
system. The subnet extension, described in [INTERNET:2], is now a
required part of the Internet architecture. The basic idea is to
partition the <Host-number> field into two parts: a subnet number,
and a true host number on that subnet:
この簡単な概念はサブネットの概念によって敷衍されました。(サブネットは、組織の中にインタコネクトされたLAN構造の任意の複雑さを許容するためにネットワーク・ナンバーとルーティングの複雑さにおける爆発的成長に対してインターネット・システムを絶縁している間、導入されました)。 サブネットは本質的にはマルチレベル階層型ルーティング構造をインターネット・システムに供給します。 現在、[インターネット: 2]で説明されたサブネット拡大はインターネットアーキテクチャの必要な部分です。 <Host-番号>が2つの部品としてさばくパーティションには基本的な考え方があります: サブネット番号、およびそのサブネットの真のホスト番号:
IP-address ::=
以下をIP扱ってください:=
Almquist & Kastenholz [Page 18] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[18ページ]RFC1716
{ <Network-number>, <Subnet-number>, <Host-number> }
<ネットワーク・ナンバー>、<サブネット番号>、<ホスト番号>。
The interconnected physical networks within an organization will
be given the same network number but different subnet numbers.
The distinction between the subnets of such a subnetted network is
normally not visible outside of that network. Thus, routing in
the rest of the Internet will be based only upon the <Network-
number> part of the IP destination address; routers outside the
network will combine <Subnet-number> and <Host-number> together to
form an uninterpreted rest part of the 32-bit IP address. Within
the subnetted network, the routers must route on the basis of an
extended network number:
同じネットワーク・ナンバーの、しかし、異なったサブネット番号を組織の中のインタコネクトされた物理ネットワークに与えるでしょう。 通常、そのようなサブネット化したネットワークのサブネットの区別は外でそのネットワークで目に見えません。 したがって、インターネットの残りにおけるルーティングはNetwork-数の>が分ける受信者IPアドレスの<だけに基づくでしょう。 ネットワークの外におけるルータは、32ビットのIPアドレスの非解釈された休息部分を形成するために<Subnet-番号>と<Host-番号>を一緒に結合するでしょう。 サブネット化したネットワークの中では、ルータは拡大ネットワーク番号に基づいて以下を発送しなければなりません。
{ <Network-number>, <Subnet-number> }
<ネットワーク・ナンバー>、<サブネット番号>。
Under certain circumstances, it may be desirable to support
subnets of a particular network being interconnected only via a
path which is not part of the subnetted network. Even though many
IGP's and no EGP's currently support this configuration
effectively, routers need to be able to support this configuration
of subnetting (see Section [4.2.3.4]). In general, routers should
not make assumptions about what are subnets and what are not, but
simply ignore the concept of Class in networks, and treat each
route as a { network, mask }-tuple.
ある状況で、サブネット化したネットワークの一部でない経路を通してだけインタコネクトされる特定のネットワークのサブネットをサポートするのは望ましいかもしれません。 多くですが、IGPのものがサポートしますが、EGPのどんなものも現在ルータが事実上、サポートすることができる必要があるこの構成にサブネッティングのこの構成をサポートしない、(セクションを見てください、[4.2 .3 .4)。 一般に、何がサブネットであるか、そして、ネットワークで単にClassの概念を無視する以外に、何がないかに関する仮定と御馳走はaとしてルータでそれぞれネットワーク、マスクを発送するべきではありません。-tuple。
DISCUSSION:
It is becoming clear that as the Internet grows larger and
larger, the traditional uses of Class A, B, and C networks will
be modified in order to achieve better use of IP's 32-bit
address space. Classless Interdomain Routing (CIDR)
[INTERNET:15] is a method currently being deployed in the
Internet backbones to achieve this added efficiency. CIDR
depends on the ability of assigning and routing to networks
that are not based on Class A, B, or C networks. Thus, routers
should always treat a route as a network with a mask.
議論: それはインターネットがどんどん大きくなるときClass A、B、およびCネットワークの伝統的な用途がIPの32ビットのアドレスのスペースの、より良い使用を達成するように変更されるのが明確になっています。 階級のないInterdomainルート設定(CIDR)[インターネット: 15]は現在この加えられた効率を達成するためにインターネットの基幹で配布されるメソッドです。 CIDRは割り当ての能力とClass A、B、またはCネットワークに基づいていないネットワークへのルーティングに依存します。 したがって、ルータはいつもマスクでネットワークとしてルートを扱うべきです。
Furthermore, for similar reasons, a subnetted network need not
have a consistent subnet mask through all parts of the network.
For example, one subnet may use an 8 bit subnet mask, another 10
bit, and another 6 bit. Routers need to be able to support this
type of configuration (see Section [4.2.3.4]).
その上、同様の理由で、サブネット化したネットワークはネットワークのすべての部分を通って一貫したサブネットマスクを持つ必要はありません。 例えばサブネットが8ビットのサブネットマスク、もう10ビット、およびもう6ビット使用するかもしれない1つ。 ルータが、このタイプの構成をサポートすることができる必要がある、(セクションを見てください、[4.2 .3 .4)。
The bit positions containing this extended network number are
indicated by a 32-bit mask called the subnet mask; it is
recommended but not required that the <Subnet-number> bits be
contiguous and fall between the <Network-number> and the <Host-
number> fields. No subnet should be assigned the value zero or -1
この拡大ネットワーク番号を含むビット位置はサブネットマスクと呼ばれる32ビットのマスクによって示されます。 それがお勧めですが、必要でないことで、<が>ビットにSubnet付番するのは、隣接であり、<Network-番号>と>がさばく<Host-番号の間で低下します。 値ゼロか-1をどんなサブネットにも割り当てるべきではありません。
Almquist & Kastenholz [Page 19] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[19ページ]RFC1716
(all one bits).
(すべての1ビット。)
Although the inventors of the subnet mechanism probably expected
that each piece of an organization's network would have only a
single subnet number, in practice it has often proven necessary or
useful to have several subnets share a single physical cable.
サブネットメカニズムの発明者は、それぞれの組織のネットワークにはただ一つのサブネット番号しかないとたぶん予想しましたが、実際には、いくつかのサブネットに単一の物理ケーブルを共有させるのが必要であるか、または役に立つとしばしば判明しました。
There are special considerations for the router when a connected
network provides a broadcast or multicast capability; these will
be discussed later.
接続ネットワークが放送かマルチキャスト能力を提供するとき、ルータのための特別な問題があります。 後でこれらについて議論するでしょう。
2.2.6 IP Multicasting
2.2.6 IPマルチキャスティング
IP multicasting is an extension of Link Layer multicast to IP
internets. Using IP multicasts, a single datagram can be
addressed to multiple hosts. This collection of hosts is called a
multicast group. Each multicast group is represented as a Class D
IP address. An IP datagram sent to the group is to be delivered
to each group member with the same best-effort delivery as that
provided for unicast IP traffic. The sender of the datagram does
not itself need to be a member of the destination group.
IPマルチキャスティングはIPインターネットへのLink Layerマルチキャストの拡大です。 IPマルチキャストを使用して、複数のホストに単一のデータグラムを扱うことができます。 ホストのこの収集はマルチキャストグループと呼ばれます。 それぞれのマルチキャストグループはClass D IPアドレスとして代表されます。 グループに送られたIPデータグラムはそれと同じベストエフォート型配送でそれぞれのグループのメンバーにユニキャストIPトラフィックに提供していた状態で提供されることになっています。 データグラムの送付者は目的地グループのメンバーである必要性をそれ自体にするというわけではありません。
The semantics of IP multicast group membership are defined in
[INTERNET:4]. That document describes how hosts and routers join
and leave multicast groups. It also defines a protocol, the
Internet Group Management Protocol (IGMP), that monitors IP
multicast group membership.
IPマルチキャストグループ会員資格の意味論は[インターネット: 4]で定義されます。 そのドキュメントはホストとルータがどうマルチキャストグループに加わって、残すかを説明します。 また、それはプロトコル、IPマルチキャストグループ会員資格をモニターするインターネットGroup Managementプロトコル(IGMP)を定義します。
Forwarding of IP multicast datagrams is accomplished either
through static routing information or via a multicast routing
protocol. Devices that forward IP multicast datagrams are called
multicast routers. They may or may not also forward IP unicasts.
In general, multicast datagrams are forwarded on the basis of both
their source and destination addresses. Forwarding of IP
multicast packets is described in more detail in Section [5.2.1].
Appendix D discusses multicast routing protocols.
IPマルチキャストデータグラムの推進は静的ルーティング情報を通して、または、マルチキャストルーティング・プロトコルで実行されます。 IPマルチキャストデータグラムを進めるデバイスはマルチキャストルータと呼ばれます。 また、彼らはIPユニキャストを進めるかもしれません。 一般に、彼らのソースと送付先アドレスの両方に基づいてマルチキャストデータグラムを進めます。 IPマルチキャストパケットの推進がさらに詳細にセクションで説明される、[5.2 .1]。 付録Dはマルチキャストルーティング・プロトコルについて議論します。
2.2.7 Unnumbered Lines and Networks and Subnets
2.2.7 無数の線、ネットワーク、およびサブネット
Traditionally, each network interface on an IP host or router has
its own IP address. Over the years, people have observed that
this can cause inefficient use of the scarce IP address space,
since it forces allocation of an IP network number, or at least a
subnet number, to every point-to-point link.
伝統的に、IPホストかルータの各ネットワーク・インターフェースはそれ自身のIP住所を知っています。 数年間、人々は、これが不十分なIPアドレス空間の効率の悪い使用を引き起こす場合があるのを観測しました、IPネットワーク・ナンバーの配分、または少なくともサブネット番号を強制するので、あらゆるポイントツーポイント接続に。
To solve this problem, a number of people have proposed and
implemented the concept of unnumbered serial lines. An unnumbered
多くの人々が、この問題を解決するために、無数のシリアル・ラインの概念を提案して、実装しました。 無数
Almquist & Kastenholz [Page 20] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[20ページ]RFC1716
serial line does not have any IP network or subnet number
associated with it. As a consequence, the network interfaces
connected to an unnumbered serial line do not have IP addresses.
シリアル・ラインには、それに関連している少しのIPネットワークやサブネット番号もありません。 結果として、無数のシリアル・ラインに関連づけられたネットワーク・インターフェースはIPアドレスを持っていません。
Because the IP architecture has traditionally assumed that all
interfaces had IP addresses, these unnumbered interfaces cause
some interesting dilemmas. For example, some IP options (e.g.
Record Route) specify that a router must insert the interface
address into the option, but an unnumbered interface has no IP
address. Even more fundamental (as we shall see in chapter 5) is
that routes contain the IP address of the next hop router. A
router expects that that IP address will be on an IP (sub)net that
the router is connected to. That assumption is of course violated
if the only connection is an unnumbered serial line.
IPアーキテクチャが、すべてのインタフェースにはIPアドレスがあったと伝統的に仮定したので、これらの無数のインタフェースはいくつかのおもしろいジレンマを引き起こします。 例えば、いくつかのIPオプション(例えば、Record Route)が、ルータがインターフェース・アドレスをオプションに挿入しなければならないと指定しますが、無数のインタフェースには、IPアドレスが全くありません。 さらに基本的であるのは(私たちが第5章で見るように)、ルートが次のホップルータのIPアドレスを含んでいるということです。 ルータは、そのIPアドレスがルータが関連づけられるIP(潜水艦)ネットにあると予想します。 その仮定は唯一の接続が無数のシリアル・ラインであるならもちろん違反されます。
To get around these difficulties, two schemes have been invented.
The first scheme says that two routers connected by an unnumbered
serial line aren't really two routers at all, but rather two
half-routers which together make up a single (virtual) router.
The unnumbered serial line is essentially considered to be an
internal bus in the virtual router. The two halves of the virtual
router must coordinate their activities in such a way that they
act exactly like a single router.
これらの困難を逃れるために、2つの体系を発明してあります。 最初の体系が、無数のシリアル・ラインによって接続された2つのルータが本当に全く2つのルータではなく、むしろ2つの半分ルータであると言う、どれがただ一つ(仮想の)のルータを上に一緒にしますか? 無数のシリアル・ラインは仮想のルータにおける内部のバスであると本質的には考えられます。 仮想のルータの2つの半分がちょうどただ一つのルータのように行動するような方法で彼らの活動を調整しなければなりません。
This scheme fits in well with the IP architecture, but suffers
from two important drawbacks. The first is that, although it
handles the common case of a single unnumbered serial line, it is
not readily extensible to handle the case of a mesh of routers and
unnumbered serial lines. The second drawback is that the
interactions between the half routers are necessarily complex and
are not standardized, effectively precluding the connection of
equipment from different vendors using unnumbered serial lines.
この体系は、IPアーキテクチャとよく合っていますが、2つの重要な欠点に苦しみます。 1番目はただ一つの無数のシリアル・ラインのよくある例を扱いますが、ルータと無数のシリアル・ラインのメッシュに関するケースを扱うのが容易に広げることができないということです。 2番目の欠点は半分ルータの間の相互作用が必ず複雑であり、標準化されないということです、事実上、異なったベンダーから無数のシリアル・ラインを使用することで設備の接続を排除して。
Because of these drawbacks, this memo has adopted an alternative
scheme, which has been invented multiple times but which is
probably originally attributable to Phil Karn. In this scheme, a
router which has unnumbered serial lines also has a special IP
address, called a router-id in this memo. The router-id is one of
the router's IP addresses (a router is required to have at least
one IP address). This router-id is used as if it is the IP
address of all unnumbered interfaces.
これらの欠点のために、このメモは代替の体系を採用しました。(発明されましたが、それは、元々、たぶん複数の回フィルKarnに起因しています)。 また、この体系では、無数のシリアル・ラインを持っているルータはこのメモによるルータイドと呼ばれる特別なIPアドレスを持っています。 ルータイドはルータのIPアドレスの1つ(ルータが少なくとも1つのIPアドレスを持つのに必要である)です。 このルータイドはまるでそれがすべての無数のインタフェースのIPアドレスであるかのように使用されています。
Almquist & Kastenholz [Page 21] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[21ページ]RFC1716
2.2.8 Notable Oddities
2.2.8 注目に値する奇異
2.2.8.1 Embedded Routers
2.2.8.1 埋め込まれたルータ
A router may be a stand-alone computer system, dedicated to its
IP router functions. Alternatively, it is possible to embed
router functions within a host operating system which supports
connections to two or more networks. The best-known example of
an operating system with embedded router code is the Berkeley
BSD system. The embedded router feature seems to make
internetting easy, but it has a number of hidden pitfalls:
ルータはIPルータ機能に捧げられたスタンドアロンのコンピュータシステムであるかもしれません。 あるいはまた、2つ以上のネットワークに接続をサポートするホスト・オペレーティング・システムの中でルータ機能を埋め込むのは可能です。 埋め込まれたルータコードがあるオペレーティングシステムの最もよく知られている例はバークレーBSDシステムです。 埋め込まれたルータ機能はinternettingを簡単にするように思えますが、それには、多くの隠れた落とし穴があります:
(1) If a host has only a single constituent-network interface,
it should not act as a router.
(1) ホストに単一の構成しているネットワーク・インターフェースしかないなら、それはルータとして機能するべきではありません。
For example, hosts with embedded router code that
gratuitously forward broadcast packets or datagrams on the
same net often cause packet avalanches.
例えば、埋め込まれたルータコードをもっている同じネットで無償で放送パケットかデータグラムを進めるホストがしばしばパケット殺到を引き起こします。
(2) If a (multihomed) host acts as a router, it must implement
ALL the relevant router requirements contained in this
document.
(2) (「マルチ-家へ帰」りました)ホストがルータとして務めるなら、それは、すべての関連ルータが本書では含まれた要件であると実装しなければなりません。
For example, the routing protocol issues and the router
control and monitoring problems are as hard and important
for embedded routers as for stand-alone routers.
例えば、埋め込まれたルータに、ルーティング・プロトコル問題、ルータコントロール、およびモニターしている問題は、スタンドアロンのルータのように同じくらい固くて、同じくらい重要です。
Since Internet router requirements and specifications may
change independently of operating system changes, an
administration that operates an embedded router in the
Internet is strongly advised to have the ability to
maintain and update the router code (e.g., this might
require router code source).
インターネットルータ要件と仕様がオペレーティングシステム変化の如何にかかわらず変化するかもしれないので、インターネットで埋め込まれたルータを運用する管理がルータコードを維持して、アップデートする能力を持っているように強くアドバイスされます(例えば、これはルータコードソースを必要とするかもしれません)。
(3) Once a host runs embedded router code, it becomes part of
the Internet system. Thus, errors in software or
configuration can hinder communication between other
hosts. As a consequence, the host administrator must lose
some autonomy.
(3) ホストがいったん埋め込まれたルータコードを実行すると、それはインターネット・システムの一部になります。 したがって、ソフトウェアか構成における誤りは他のホストのコミュニケーションを妨げる場合があります。 結果として、ホスト管理者は何らかの自治を失わなければなりません。
In many circumstances, a host administrator will need to
disable router code embedded in the operating system, and
any embedded router code must be organized so that it can
be easily disabled.
多くの事情では、ホスト管理者は、オペレーティングシステムに埋め込まれたルータコードを無効にする必要があるでしょう、そして、容易にそれを無効にすることができるようにどんな埋め込まれたルータコードも組織化しなければなりません。
(4) If a host running embedded router code is concurrently
ホスト実行がルータコードを埋め込んだなら、同時に(4)はそうです。
Almquist & Kastenholz [Page 22] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[22ページ]RFC1716
used for other services, the O&M (Operation and
Maintenance) requirements for the two modes of use may be
in serious conflict.
使用の2つの方法のための他のサービス、O&Mに、中古(操作とMaintenance)の要件は重大な闘争中であるかもしれません。
For example, router O&M will in many cases be performed
remotely by an operations center; this may require
privileged system access which the host administrator
would not normally want to distribute.
例えば、多くの場合、ルータO&Mは操作センターによって離れて実行されるでしょう。 これは通常、ホスト管理者が広げたがっていない特権があるシステムアクセスを必要とするかもしれません。
2.2.8.2 Transparent Routers
2.2.8.2 透明なルータ
There are two basic models for interconnecting local-area
networks and wide-area (or long-haul) networks in the Internet.
In the first, the local-area network is assigned a network
number and all routers in the Internet must know how to route
to that network. In the second, the local-area network shares
(a small part of) the address space of the wide-area network.
Routers that support this second model are called address
sharing routers or transparent routers. The focus of this memo
is on routers that support the first model, but this is not
intended to exclude the use of transparent routers.
ローカル・エリア・ネットワークとインタコネクトするための2人の基本型と広い領域(または、長期)ネットワークがインターネットにあります。 1番目では、ネットワーク・ナンバーとインターネットのルータが、どのようにがそのネットワークに発送するかを知らなければならないすべてがローカル・エリア・ネットワークに配属されます。 2番目では、ローカル・エリア・ネットワークが共有される、(小さい部分、)、広域ネットワークのアドレス空間。 この2番目のモデルをサポートするルータはルータか透明なルータを共有するアドレスと呼ばれます。 このメモの焦点が第1代モデルをサポートするルータにありますが、これが透明なルータの使用を除くことを意図しません。
The basic idea of a transparent router is that the hosts on the
local-area network behind such a router share the address space
of the wide-area network in front of the router. In certain
situations this is a very useful approach and the limitations
do not present significant drawbacks.
透明なルータの基本的な考え方はそのようなルータの後ろのローカル・エリア・ネットワークのホストがルータの正面で広域ネットワークのアドレス空間を共有するということです。 ある状況で、これは非常に役に立つアプローチです、そして、制限は重要な欠点を提示しません。
The words in front and behind indicate one of the limitations
of this approach: this model of interconnection is suitable
only for a geographically (and topologically) limited stub
environment. It requires that there be some form of logical
addressing in the network level addressing of the wide-area
network. All of the IP addresses in the local environment map
to a few (usually one) physical address in the wide-area
network. This mapping occurs in a way consistent with the { IP
address <-> network address } mapping used throughout the
wide-area network.
前部と後ろの単語はこのアプローチの制限の1つを示します: インタコネクトのこのモデルは地理的に限られた(位相的に)スタッブ環境だけに適しています。 それはネットワークレベルの何らかのフォームの論理的なアドレシングが広域ネットワークのアドレシングであったならそこでそれを必要とします。 地方の環境におけるIPアドレスのすべてが広域ネットワークでいくつか(通常1)に物理アドレスを写像します。 このマッピングは写像されるIPアドレス<->ネットワーク・アドレスと一致した方法で広域ネットワーク中で使用されていた状態で現れます。
Multihoming is possible on one wide-area network, but may
present routing problems if the interfaces are geographically
or topologically separated. Multihoming on two (or more)
wide-area networks is a problem due to the confusion of
addresses.
マルチホーミングは、1つの広域ネットワークで可能ですが、インタフェースが地理的か位相的に切り離されるなら、ルーティング問題を提示するかもしれません。 アドレスの混乱のために2つ(さらに)の広域ネットワークに関するマルチホーミングは問題です。
The behavior that hosts see from other hosts in what is
apparently the same network may differ if the transparent
ホストが他のホストからことで見る振舞いは明らかに同じネットワークが透明であるなら異なるかもしれないということです。
Almquist & Kastenholz [Page 23] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[23ページ]RFC1716
router cannot fully emulate the normal wide-area network
service. For example, the ARPANET used a Link Layer protocol
that provided a Destination Dead indication in response to an
attempt to send to a host which was powered off. However, if
there were a transparent router between the ARPANET and an
Ethernet, a host on the ARPANET would not receive a Destination
Dead indication if it sent a datagram to a host that was
powered off and was connected to the ARPANET via the
transparent router instead of directly.
ルータは完全に通常の広域ネットワークサービスを見習うことができるというわけではありません。 例えば、アルパネットは離れて動かされて、そうするホストに送る試みに対応してDestination Dead指示を提供したLink Layerプロトコルを使用しました。 の代わりにする、しかしながら、アルパネットとイーサネットの間には、透明なルータがあれば、それが離れて動かされたホストにデータグラムを送って、透明なルータでアルパネットに関連づけられるならアルパネットのホストがDestination Dead指示を受けない、直接。
2.3 Router Characteristics
2.3 ルータの特性
An Internet router performs the following functions:
インターネットルータは以下の機能を実行します:
(1) Conforms to specific Internet protocols specified in this
document, including the Internet Protocol (IP), Internet Control
Message Protocol (ICMP), and others as necessary.
(1)は本書では指定された特定のインターネットプロトコルに従います、必要に応じてインターネットプロトコル(IP)、インターネット・コントロール・メッセージ・プロトコル(ICMP)、および他のものを含んでいて。
(2) Interfaces to two or more packet networks. For each connected
network the router must implement the functions required by that
network. These functions typically include:
(2) 2つ以上のパケット網へのインタフェース。 ルータが実装しなければならないそれぞれの接続ネットワークにおいて、機能がそのネットワークが必要です。 通常これらの機能は:
o Encapsulating and decapsulating the IP datagrams with the
connected network framing (e.g., an Ethernet header and
checksum),
o 接続ネットワークが(例えば、イーサネットヘッダーとチェックサム)を縁どっているIPデータグラムをカプセル化して、decapsulatingします。
o Sending and receiving IP datagrams up to the maximum size
supported by that network, this size is the network's Maximum
Transmission Unit or MTU,
o そのネットワークによってサポートされた最大サイズまでの送受信IPデータグラム、このサイズは、ネットワークのMaximum Transmission UnitかMTUです。
o Translating the IP destination address into an appropriate
network-level address for the connected network (e.g., an
Ethernet hardware address), if needed, and
o そして必要であるなら接続ネットワーク(例えば、イーサネットハードウェア・アドレス)のための適切なネットワークレベルアドレスに受信者IPアドレスを翻訳する。
o Responding to the network flow control and error indication,
if any.
o ネットワークフロー制御と誤り表示に応じることもしあれば。
See chapter 3 (Link Layer).
第3章を見てください(Layerをリンクしてください)。
(3) Receives and forwards Internet datagrams. Important issues in
this process are buffer management, congestion control, and
fairness.
(3)はインターネットデータグラムを受けて、進めます。このプロセスの切迫した課題は、バッファ管理と、輻輳制御と、公正です。
o Recognizes various error conditions and generates ICMP error
and information messages as required.
o 必要に応じてICMP誤りと情報がメッセージであると様々なエラー条件を認めて、生成します。
o Drops datagrams whose time-to-live fields have reached zero.
o 生きる時間野原がゼロに達したデータグラムを下げます。
Almquist & Kastenholz [Page 24] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[24ページ]RFC1716
o Fragments datagrams when necessary to fit into the MTU of the
next network.
o 次のネットワークのMTUに収まるのに必要であるときに、データグラムを断片化します。
See chapter 4 (Internet Layer - Protocols) and chapter 5
(Internet Layer - Forwarding) for more information.
詳しい情報に関して第4章(インターネットLayer--プロトコル)と第5章(インターネットLayer--推進)を見てください。
(4) Chooses a next-hop destination for each IP datagram, based on
the information in its routing database. See chapter 5
(Internet Layer - Forwarding) for more information.
(4)はルーティングデータベースの情報に基づいてそれぞれのIPデータグラムのための次のホップの目的地を選びます。 詳しい情報に関して第5章(インターネットLayer--推進)を見てください。
(5) (Usually) supports an interior gateway protocol (IGP) to carry
out distributed routing and reachability algorithms with the
other routers in the same autonomous system. In addition, some
routers will need to support an exterior gateway protocol (EGP)
to exchange topological information with other autonomous
systems. See chapter 7 (Application Layer - Routing Protocols)
for more information.
(通常、)(5)は、他のルータが同じ自律システムにある状態で分配されたルーティングと可到達性アルゴリズムを行うために、内部のゲートウェイプロトコル(IGP)をサポートします。 さらに、いくつかのルータが、他の自律システムと位相的な情報を交換するのに外のゲートウェイプロトコルが(EGP)であるとサポートする必要があるでしょう。詳しい情報に関して第7章(アプリケーションLayer--ルート設定プロトコル)を見てください。
(6) Provides network management and system support facilities,
including loading, debugging, status reporting, exception
reporting and control. See chapter 8 (Application Layer -
Network Management Protocols) and chapter 10 (Operation and
Maintenance) for more information.
(6)はローディング、デバッグ、状態報告、例外報告書、およびコントロールを含むネットワークマネージメントとシステム支援施設を提供します。 詳しい情報に関して第8章(アプリケーションLayer--ネットワークManagementプロトコル)と第10章(操作とMaintenance)を見てください。
A router vendor will have many choices on power, complexity, and features for a particular router product. It may be helpful to observe that the Internet system is neither homogeneous nor fully- connected. For reasons of technology and geography it is growing into a global interconnect system plus a fringe of LANs around the edge. More and more these fringe LANs are becoming richly interconnected, thus making them less out on the fringe and more demanding on router requirements.
ルータベンダーは特定のルータ製品のためのパワー、複雑さ、および特徴に多くの選択を持つでしょう。 インターネット・システムが同次でなくて完全に接続されているというわけではないのを観測するのは役立っているかもしれません。 技術と地理学の理由で、それは縁の周りでグローバルな内部連絡システムとLANのフリンジになっています。 ますます多くのこれらは、豊かにインタコネクトされるようになっていて、その結果、それらをフリンジで、より少なくルータ要件では、より過酷にしながら、LANを縁どります。
o The global interconnect system is comprised of a number of wide-
area networks to which are attached routers of several Autonomous
Systems (AS); there are relatively few hosts connected directly to
the system.
o グローバルな内部連絡システムはどれが数個のAutonomous Systems(AS)の付属ルータであるかに多くの広い領域ネットワークから成ります。 直接システムに接続されたホストは比較的わずかしかいません。
o Most hosts are connected to LANs. Many organizations have
clusters of LANs interconnected by local routers. Each such
cluster is connected by routers at one or more points into the
global interconnect system. If it is connected at only one point,
a LAN is known as a stub network.
o ほとんどのホストがLANに接続されます。 多くの組織がローカルルータでLANのクラスタとインタコネクトさせます。 そのような各クラスタは1ポイント以上でルータによってグローバルな内部連絡システムに接続されます。 それが1ポイントだけで接続されるなら、LANはスタッブネットワークとして知られています。
Routers in the global interconnect system generally require:
一般に、グローバルな内部連絡システムのルータは以下を必要とします。
o Advanced Routing and Forwarding Algorithms
o 高度なルート設定とアルゴリズムを進めること。
Almquist & Kastenholz [Page 25] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[25ページ]RFC1716
These routers need routing algorithms which are highly dynamic and
also offer type-of-service routing. Congestion is still not a
completely resolved issue (see Section [5.3.6]). Improvements in
these areas are expected, as the research community is actively
working on these issues.
これらのルータは、非常にダイナミックなルーティング・アルゴリズムを必要として、また、サービスのタイプにルーティングを提供します。 それでも、混雑が完全な決心している問題であるというわけではない、(セクションを見てください、[5.3 .6)。 研究団体が活発にこれらの問題に取り組んでいるとき、これらの領域での改良は予想されます。
o High Availability
o 高可用性
These routers need to be highly reliable, providing 24 hours a
day, 7 days a week service. Equipment and software faults can
have a wide-spread (sometimes global) effect. In case of failure,
they must recover quickly. In any environment, a router must be
highly robust and able to operate, possibly in a degraded state,
under conditions of extreme congestion or failure of network
resources.
1日24時間提供して、これらのルータは、高信頼性である必要があって、年中無休はサービスです。 設備とソフトウェア欠点は広範囲(時々グローバルな)の効果を持つことができます。 失敗の場合には、彼らはすぐに回復しなければなりません。 どんな環境でも、ルータは、非常に強健であって、作動できなければなりません、ことによると降格している状態で、極端な混雑の状態かネットワーク資源の失敗の下で。
o Advanced O&M Features
o 高度なOとMの特徴
Internet routers normally operate in an unattended mode. They
will typically be operated remotely from a centralized monitoring
center. They need to provide sophisticated means for monitoring
and measuring traffic and other events and for diagnosing faults.
通常、インターネットルータは無人のモードで作動します。 通常、それらは集結されたモニターしている中心から離れて操作されるでしょう。 彼らは、トラフィックと他のイベントをモニターして、測定して、欠点を診断するための高度な手段を提供する必要があります。
o High Performance
o 高性能
Long-haul lines in the Internet today are most frequently 56 Kbps,
DS1 (1.4Mbps), and DS3 (45Mbps) speeds. LANs are typically
Ethernet (10Mbps) and, to a lesser degree, FDDI (100Mbps).
However, network media technology is constantly advancing and even
higher speeds are likely in the future. Full-duplex operation is
provided at all of these speeds.
最も頻繁に今日のインターネットの長期系列は56Kbps、DS1(1.4Mbps)、およびDS3(45Mbps)速度です。 LANは、通常イーサネット(10Mbps)と、より少ない度合いへのFDDI(100Mbps)です。 しかしながら、技術が絶えず進めているネットワークメディアとさらに高い速度は将来、ありそうです。 これらの速度について全二重操作を全く提供します。
The requirements for routers used in the LAN fringe (e.g., campus networks) depend greatly on the demands of the local networks. These may be high or medium-performance devices, probably competitively procured from several different vendors and operated by an internal organization (e.g., a campus computing center). The design of these routers should emphasize low average latency and good burst performance, together with delay and type-of-service sensitive resource management. In this environment there may be less formal O&M but it will not be less important. The need for the routing mechanism to be highly dynamic will become more important as networks become more complex and interconnected. Users will demand more out of their local connections because of the speed of the global interconnects.
LANフリンジ(例えば、キャンパスネットワーク)に使用されるルータのための要件は企業内情報通信網の要求に大いによります。 これらはたぶんいくつかの異なったベンダーから競争的に調達されて、内部の組織(例えば、キャンパス計算機センタ)によって運用された高いか中くらいの性能のデバイスであるかもしれません。 これらのルータのデザインは低い平均値潜在と良い炸裂性能を強調するべきです、遅れとサービスのタイプの敏感な資源管理と共に。 この環境には、それほど正式でないO&Mがあるかもしれませんが、それはそれほど重要にならないというわけではないでしょう。 ネットワークが、より複雑でインタコネクトされるようになるのに従って、ルーティングメカニズムが非常にダイナミックになる必要性は、より重要になるでしょう。 ユーザはグローバルな内部連絡の速度のために彼らの市内接続から以上を要求するでしょう。
As networks have grown, and as more networks have become old enough
ネットワークが成長して、同じくらいより多くのネットワークが十分古くなったので
Almquist & Kastenholz [Page 26] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[26ページ]RFC1716
that they are phasing out older equipment, it has become increasingly imperative that routers interoperate with routers from other vendors.
彼らは、より古い設備を段階的に廃止していて、ルータがルータで他のベンダーから共同利用するのはますます必須になりました。
Even though the Internet system is not fully interconnected, many parts of the system need to have redundant connectivity. Rich connectivity allows reliable service despite failures of communication lines and routers, and it can also improve service by shortening Internet paths and by providing additional capacity. Unfortunately, this richer topology can make it much more difficult to choose the best path to a particular destination.
インターネット・システムは完全にインタコネクトされるというわけではありませんが、システムの多くの部分が余分な接続性を必要とします。 通信回線とルータの失敗にもかかわらず、豊かな接続性は信頼できるサービスを許します、そして、また、それはインターネット経路を短くして、追加容量を提供することによって、サービスを改良できます。 残念ながら、このより豊かなトポロジーで、特定の目的地に最も良い経路を選ぶのははるかに難しくなる場合があります。
2.4 Architectural Assumptions
2.4 建築仮定
The current Internet architecture is based on a set of assumptions about the communication system. The assumptions most relevant to routers are as follows:
現在のインターネットアーキテクチャは1セットの通信系に関する仮定に基づいています。 ルータに最も関連している仮定は以下の通りです:
o The Internet is a network of networks.
o インターネットはネットワークのネットワークです。
Each host is directly connected to some particular network(s); its
connection to the Internet is only conceptual. Two hosts on the
same network communicate with each other using the same set of
protocols that they would use to communicate with hosts on distant
networks.
各ホストは直接何らかの特定のネットワークに接続されます。 インターネットとの接続は概念的であるだけです。 同じネットワークの2人のホストが、それらが遠方のネットワークでホストとコミュニケートするのに使用する同じセットのプロトコルを使用することで互いにコミュニケートします。
o Routers don't keep connection state information.
o ルータは、接続状態が情報であることを保ちません。
To improve the robustness of the communication system, routers are
designed to be stateless, forwarding each IP packet independently
of other packets. As a result, redundant paths can be exploited
to provide robust service in spite of failures of intervening
routers and networks.
ルータは状態がなくなるように設計されています、他のパケットの如何にかかわらずそれぞれのIPパケットを進めて通信系の丈夫さを改良するなら。 その結果、介入しているルータとネットワークの失敗にもかかわらず、体力を要しているサービスを提供するのに冗長パスを利用できます。
All state information required for end-to-end flow control and
reliability is implemented in the hosts, in the transport layer or
in application programs. All connection control information is
thus co-located with the end points of the communication, so it
will be lost only if an end point fails. Routers effect flow
control only indirectly, by dropping packets or increasing network
delay.
すべての州の情報が終わりから終わりへのフロー制御に必要です、そして、信頼性はトランスポート層の中、または、ホストか、アプリケーション・プログラムで実装されます。すべての接続制御情報がコミュニケーションのエンドポイントでこのようにして共同見つけられています、したがって、エンドポイントが失敗する場合にだけ、それは失われるでしょう。 パケットを下げるか、またはネットワーク遅延を増強することによって、ルータは間接的にだけフロー制御に作用します。
Note that future protocol developments may well end up putting
some more state into routers. This is especially likely for
resource reservation and flows.
今後のプロトコル開発が結局たぶんそれ以上の状態をルータに入れるだろうことに注意してください。 これは、資源予約に特にありそうであり、流れます。
Almquist & Kastenholz [Page 27] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[27ページ]RFC1716
o Routing complexity should be in the routers.
o ルータにはルート設定の複雑さがあるべきです。
Routing is a complex and difficult problem, and ought to be
performed by the routers, not the hosts. An important objective
is to insulate host software from changes caused by the inevitable
evolution of the Internet routing architecture.
ルート設定は、複雑で難しい問題であり、ホストではなく、ルータによって実行されるべきです。 重要な目的はインターネット・ルーティングアーキテクチャの必然の発展によって引き起こされた変化からホストソフトウェアを隔離することです。
o The system must tolerate wide network variation.
o システムは広いネットワーク変化を許容しなければなりません。
A basic objective of the Internet design is to tolerate a wide
range of network characteristics - e.g., bandwidth, delay, packet
loss, packet reordering, and maximum packet size. Another
objective is robustness against failure of individual networks,
routers, and hosts, using whatever bandwidth is still available.
Finally, the goal is full open system interconnection: an Internet
router must be able to interoperate robustly and effectively with
any other router or Internet host, across diverse Internet paths.
インターネットデザインの基本的な目的はさまざまなネットワークの特性を許容することです--例えば、帯域幅、遅れ、パケット損失、パケット再命令、および最大のパケットサイズ。 どんなまだ利用可能な帯域幅も使用して、別の目的は個々のネットワーク、ルータ、およびホストの失敗に対する丈夫さです。 最終的に、目標は完全な開放形システム相互接続です: インターネットルータはいかなる他のルータかインターネット・ホストと共にも強壮に有効に共同利用できなければなりません、さまざまのインターネット経路の向こう側に。
Sometimes implementors have designed for less ambitious goals.
For example, the LAN environment is typically much more benign
than the Internet as a whole; LANs have low packet loss and delay
and do not reorder packets. Some vendors have fielded
implementations that are adequate for a simple LAN environment,
but work badly for general interoperation. The vendor justifies
such a product as being economical within the restricted LAN
market. However, isolated LANs seldom stay isolated for long;
they are soon connected to each other, to organization-wide
internets, and eventually to the global Internet system. In the
end, neither the customer nor the vendor is served by incomplete
or substandard routers.
時々、作成者は以下で意欲的な目標を設計しました。 例えば、通常、LAN環境は全体でインターネットよりはるかに優しいです。 LANは、低いパケット損失と遅れを持って、どんな追加注文にもパケットをしません。 いくつかのベンダーが簡単なLAN環境に、適切な実装をさばきましたが、一般的なinteroperationのためにひどく働いてください。 ベンダーは制限されたLAN市場の中で経済的であるような製品を正当化します。 しかしながら、孤立しているLANは長い間、めったに孤立していた状態で残っていません。 それらは結局、すぐ、互い、組織全体のインターネットに接続されます。世界的なインターネットシステムに。 結局、顧客もベンダーも不完全であるか標準以下のルータによって役立たれていません。
The requirements spelled out in this document are designed for a
full-function router. It is intended that fully compliant routers
will be usable in almost any part of the Internet.
スペルアウトされた要件は完全な機能ルータのために本書では設計されています。 完全に対応することのルータがインターネットのほとんどどんな地域でも使用可能になることを意図します。
Almquist & Kastenholz [Page 28] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[28ページ]RFC1716
3. LINK LAYER
3. リンクレイヤ
Although [INTRO:1] covers Link Layer standards (IP over foo, ARP, etc.), this document anticipates that Link-Layer material will be covered in a separate Link Layer Requirements document. A Link-Layer requirements document would be applicable to both hosts and routers. Thus, this document will not obsolete the parts of [INTRO:1] that deal with link-layer issues.
[INTRO: 1]カバーLink Layer規格(foo、ARPなどの上のIP)ですが、このドキュメントは、Link-層の材料が別々のLink Layer Requirementsドキュメントでカバーされていると予期します。 Link-層の要件ドキュメントはホストとルータの両方に適切でしょう。 したがって、このドキュメントはリンクレイヤ問題に対処する[INTRO: 1]の部品を時代遅れにしないでしょう。
3.1 INTRODUCTION
3.1 序論
Routers have essentially the same Link Layer protocol requirements as other sorts of Internet systems. These requirements are given in chapter 3 of Requirements for Internet Gateways [INTRO:1]. A router MUST comply with its requirements and SHOULD comply with its recommendations. Since some of the material in that document has become somewhat dated, some additional requirements and explanations are included below.
ルータには、本質的には他の種類のインターネット・システムと同じLink Layerプロトコル要件があります。インターネットGateways[INTRO: 1]のためにRequirementsの支部3でこれらの要件を与えます。 ルータは要件に従わなければなりません、そして、SHOULDは推薦に従います。 そのドキュメントの何らかの材料がいくらか時代遅れになったので、いくつかの追加要件と説明が以下に含まれています。
DISCUSSION:
It is expected that the Internet community will produce a
Requirements for Internet Link Layer standard which will supersede
both this chapter and chapter 3 of [INTRO:1].
議論: インターネットコミュニティが本章と[INTRO: 1]の第3章の両方に取って代わるインターネットLink Layer規格のためにRequirementsを生産すると予想されます。
3.2 LINK/INTERNET LAYER INTERFACE
3.2 リンク/インターネット層のインタフェース
Although this document does not attempt to specify the interface between the Link Layer and the upper layers, it is worth noting here that other parts of this document, particularly chapter 5, require various sorts of information to be passed across this layer boundary.
このドキュメントは、Link Layerと上側の層とのインタフェースを指定するのを試みませんが、ここでこのドキュメントの他の部分(特に第5章)が、様々な種類の情報がこの層の境界の向こう側に通過されるのを必要とすることに注意する価値があります。
This section uses the following definitions:
このセクションは以下の定義を使用します:
o Source physical address
o ソース物理アドレス
The source physical address is the Link Layer address of the host
or router from which the packet was received.
ソース物理アドレスはパケットが受け取られたホストかルータのLink Layerアドレスです。
o Destination physical address
o 目的地物理アドレス
The destination physical address is the Link Layer address to
which the packet was sent.
目的地物理アドレスはパケットが送られたLink Layerアドレスです。
The information that must pass from the Link Layer to the Internetwork Layer for each received packet is:
それぞれの容認されたパケットのためにLink LayerからInternetwork Layerまで終わらなければならない情報は以下の通りです。
Almquist & Kastenholz [Page 29] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[29ページ]RFC1716
(1) The IP packet [5.2.2],
(1) IPパケット、[5.2 .2]
(2) The length of the data portion (i.e., not including the Link-
Layer framing) of the Link Layer frame [5.2.2],
(2) Link Layerフレームのデータ部(すなわち、Link層の縁どりを含んでいない)の長さ、[5.2、.2、]
(3) The identity of the physical interface from which the IP packet
was received [5.2.3], and
そして(3) IPパケットが受け取られた物理インターフェースのアイデンティティ、[5.2 .3、]。
(4) The classification of the packet's destination physical address
as a Link Layer unicast, broadcast, or multicast [4.3.2],
[5.3.4].
(4) Link Layerユニキャスト、放送、またはマルチキャストとしてのパケットの目的地物理アドレスの分類、[4.3、.2、]、[5.3、.4、]
In addition, the Link Layer also should provide:
さらに、Link Layerも提供するはずです:
(5) The source physical address.
(5) ソース物理アドレス。
The information that must pass from the Internetwork Layer to the Link Layer for each transmitted packet is:
それぞれの伝えられたパケットのためにInternetwork LayerからLink Layerまで終わらなければならない情報は以下の通りです。
(1) The IP packet [5.2.1]
(1) IPパケット[5.2.1]
(2) The length of the IP packet [5.2.1]
(2) IPパケットの長さ[5.2.1]
(3) The destination physical interface [5.2.1]
(3) 目的地の物理インターフェース[5.2.1]
(4) The next hop IP address [5.2.1]
(4) 次のホップIPアドレス[5.2.1]
In addition, the Internetwork Layer also should provide:
さらに、Internetwork Layerも提供するはずです:
(5) The Link Layer priority value [5.3.3.2]
(5) Link Layer優先順位の値[5.3.3.2]
The Link Layer must also notify the Internetwork Layer if the packet to be transmitted causes a Link Layer precedence-related error [5.3.3.3].
また、伝えられるべきパケットがLink Layerの先行関連の誤りを引き起こすならLink LayerがInternetwork Layerに通知しなければならない、[5.3 .3 .3]。
3.3 SPECIFIC ISSUES
3.3 特定の問題
3.3.1 Trailer Encapsulation
3.3.1 トレーラカプセル化
Routers which can connect to 10Mb Ethernets MAY be able to receive
and forward Ethernet packets encapsulated using the trailer
encapsulation described in [LINK:1]. However, a router SHOULD NOT
originate trailer encapsulated packets. A router MUST NOT
originate trailer encapsulated packets without first verifying,
using the mechanism described in section 2.3.1 of [INTRO:2], that
the immediate destination of the packet is willing and able to
Ethernetsが受けることができるかもしれない10Mbに接続できるルータと前進のイーサネットパケットは、[LINK: 1]で説明されたトレーラカプセル化を使用することでカプセルに入れられました。 しかしながら、ルータSHOULD NOTはパケットであるとカプセル化されたトレーラを溯源します。 パケットの即座の目的地にルータは最初に、検証なしでパケットであるとカプセル化されたトレーラを溯源してはいけなくて、メカニズムを使用すると、.1セクション2.3[INTRO: 2]が中で説明されて、望んでいて、できます。
Almquist & Kastenholz [Page 30] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[30ページ]RFC1716
accept trailer-encapsulated packets. A router SHOULD NOT agree
(using these same mechanisms) to accept trailer-encapsulated
packets.
トレーラでカプセル化されたパケットを受け入れてください。 SHOULD NOTが受け入れるのに同意する(これらの同じメカニズムを使用します)ルータはパケットをトレーラでカプセルに入れりました。
3.3.2 Address Resolution Protocol - ARP
3.3.2 アドレス解決プロトコル--ARP
Routers which implement ARP MUST be compliant and SHOULD be
unconditionally compliant with the requirements in section 2.3.2
of [INTRO:2].
アルプを実装するルータは対応するに違いありません、そして、SHOULDは無条件に対応します。.2セクション2.3[INTRO: 2]における要件で、言いなりになります。
The link layer MUST NOT report a Destination Unreachable error to
IP solely because there is no ARP cache entry for a destination.
唯一目的地のためのARPキャッシュエントリーが全くないので、リンクレイヤはDestination Unreachable誤りをIPに報告してはいけません。
A router MUST not believe any ARP reply which claims that the Link
Layer address of another host or router is a broadcast or
multicast address.
ルータは別のホストかルータのLink Layerアドレスが放送かマルチキャストアドレスであると主張するどんなARP回答も信じてはいけません。
3.3.3 Ethernet and 802.3 Coexistence
3.3.3 イーサネットと802.3共存
Routers which can connect to 10Mb Ethernets MUST be compliant and
SHOULD be unconditionally compliant with the requirements of
Section [2.3.3] of [INTRO:2].
10MbのEthernetsに接続できるルータが対応であるに違いなく、SHOULDが無条件に対応である、セクションの要件で言いなりになる、[2.3、.3、]、[INTRO: 2]について。
3.3.4 Maximum Transmission Unit - MTU
3.3.4 マキシマム・トランスミッション・ユニット--MTU
The MTU of each logical interface MUST be configurable.
それぞれの論理的なインタフェースのMTUは構成可能であるに違いありません。
Many Link Layer protocols define a maximum frame size that may be
sent. In such cases, a router MUST NOT allow an MTU to be set
which would allow sending of frames larger than those allowed by
the Link Layer protocol. However, a router SHOULD be willing to
receive a packet as large as the maximum frame size even if that
is larger than the MTU.
多くのLink Layerプロトコルが送られるかもしれない最大のフレーム・サイズを定義します。 そのような場合、ルータは、MTUがLink Layerプロトコルによって許容されたものより大きいフレームを発信させるセットであることを許容してはいけません。 しかしながら、ルータSHOULD、それがMTUよりさらに大きいなら、最大のフレーム・サイズと同じくらい大きいパケットを受けることを望んでください。
DISCUSSION:
Note that this is a stricter requirement than imposed on hosts
by [INTRO:2], which requires that the MTU of each physical
interface be configurable.
議論: これが[INTRO: 2]時までにホストに課されるより厳しい要件であることに注意してください。(それは、それぞれの物理インターフェースのMTUが構成可能であることを必要とします)。
If a network is using an MTU smaller than the maximum frame
size for the Link Layer, a router may receive packets larger
than the MTU from hosts which are in the process of
initializing themselves, or which have been misconfigured.
ネットワークがLink Layerのための最大のフレーム・サイズより小さいMTUを使用しているなら、ルータはホストからの自分たちを初期化することの途中にあるか、またはmisconfiguredされたMTUより大きいパケットを受けるかもしれません。
In general, the Robustness Principle indicates that these
packets should be successfully received, if at all possible.
一般に、Robustness Principleは、できれば、これらのパケットが首尾よく受け取られるべきであるのを示します。
Almquist & Kastenholz [Page 31] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[31ページ]RFC1716
3.3.5 Point-to-Point Protocol - PPP
3.3.5 二地点間プロトコル--ppp
Contrary to [INTRO:1], the Internet does have a standard serial
line protocol: the Point-to-Point Protocol (PPP), defined in
[LINK:2], [LINK:3], [LINK:4], and [LINK:5].
[INTRO: 1]とは逆に、インターネットには、標準のシリアル・ラインプロトコルがあります: Pointからポイントへの[LINK: 2]で定義されたプロトコル(PPP)[LINK: 3]、[LINK: 4]、および[LINK: 5。]
A serial line interface is any interface which is designed to send
data over a telephone, leased, dedicated or direct line (either 2
or 4 wire) using a standardized modem or bit serial interface
(such as RS-232, RS-449 or V.35), using either synchronous or
asynchronous clocking.
シリアル・ラインのインタフェースは賃貸されて、専用である電話か標準化されたモデムか噛み付いているシリアルインタフェース(RS-232、RS-449またはV.35などの)を使用する直系(2か4ワイヤ)の上にデータを送るように設計されているあらゆるインタフェースです、同時の、または、非同期な時計を使用して。
A general purpose serial interface is a serial line interface
which is not solely for use as an access line to a network for
which an alternative IP link layer specification exists (such as
X.25 or Frame Relay).
汎用のシリアルインタフェースはアクセス回線として代替のIPリンクレイヤ仕様が存在するネットワーク(X.25かFrame Relayなどの)への唯一使用のためのものでないシリアル・ラインのインタフェースです。
Routers which contain such general purpose serial interfaces MUST
implement PPP.
そのような汎用のシリアルインタフェースを含むルータはPPPを実装しなければなりません。
PPP MUST be supported on all general purpose serial interfaces on
a router. The router MAY allow the line to be configured to use
serial line protocols other than PPP, all general purpose serial
interfaces MUST default to using PPP.
PPP MUST、ルータのすべての汎用のシリアルインタフェースの上でサポートされてください。 ルータは、系列がPPP以外のシリアル・ラインプロトコルを使用するために構成されるのを許容するかもしれなくて、すべての汎用のシリアルインタフェースがPPPを使用するのをデフォルトとしなければなりません。
3.3.5.1 Introduction
3.3.5.1 序論
This section provides guidelines to router implementors so that
they can ensure interoperability with other routers using PPP
over either synchronous or asynchronous links.
このセクションは、彼らが他のルータで同時の、または、非同期なリンクの上にPPPを使用することで相互運用性を確実にすることができるように、ルータ作成者にガイドラインを提供します。
It is critical that an implementor understand the semantics of
the option negotiation mechanism. Options are a means for a
local device to indicate to a remote peer what the local device
will *accept* from the remote peer, not what it wishes to send.
It is up to the remote peer to decide what is most convenient
to send within the confines of the set of options that the
local device has stated that it can accept. Therefore it is
perfectly acceptable and normal for a remote peer to ACK all
the options indicated in an LCP Configuration Request (CR) even
if the remote peer does not support any of those options.
Again, the options are simply a mechanism for either device to
indicate to its peer what it will accept, not necessarily what
it will send.
作成者がオプション交渉メカニズムの意味論を理解しているのは、重要です。 オプションはaが、ローカル装置は何を示すかをリモート同輩に示すローカル装置のために*リモート同輩(それが送りたがっているものでない)からの*を受け入れるように意味するということです。 何がそれが受け入れることができるローカル装置が述べたオプションのセットの境界の中で発信するために最も都合がよいかを決めるのは、リモート同輩次第です。 したがって、リモート同輩がそれらのオプションのいずれもサポートしないでも、ACKへのすべてのオプションがLCP Configuration Request(CR)で示したリモート同輩にとって、完全に許容できて正常です。 一方、オプションは単にどちらのデバイスも、それが何を受け入れるかを同輩に示すメカニズムです、必ずそれが送るものであるというわけではない。
Almquist & Kastenholz [Page 32] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[32ページ]RFC1716
3.3.5.2 Link Control Protocol (LCP) Options
3.3.5.2 リンク制御プロトコル(LCP)オプション
The PPP Link Control Protocol (LCP) offers a number of options
that may be negotiated. These options include (among others)
address and control field compression, protocol field
compression, asynchronous character map, Maximum Receive Unit
(MRU), Link Quality Monitoring (LQM), magic number (for
loopback detection), Password Authentication Protocol (PAP),
Challenge Handshake Authentication Protocol (CHAP), and the
32-bit Frame Check Sequence (FCS).
PPP Link Controlプロトコル(LCP)は交渉されるかもしれない多くのオプションを提供します。 これらのオプションは(特に)アドレス、制御フィールド圧縮、プロトコル分野圧縮、非同期なキャラクタ地図、Maximum Receive Unit(MRU)、Link Quality Monitoring(LQM)、マジックナンバー(ループバック検出のための)、パスワード認証プロトコル(PAP)、チャレンジハンドシェイク式認証プロトコル(CHAP)、および32ビットのFrame Check Sequence(FCS)を含んでいます。
A router MAY do address/control field compression on either
synchronous or asynchronous links. A router MAY do protocol
field compression on either synchronous or asynchronous links.
A router MAY indicate that it can accept these compressions,
but MUST be able to accept uncompressed PPP header information
even if it has indicated a willingness to receive compressed
PPP headers.
ルータは同時の、または、非同期なリンクでアドレス/制御フィールド圧縮をするかもしれません。 ルータは同時の、または、非同期なリンクでプロトコル分野圧縮をするかもしれません。 ルータは、これらの圧縮を受け入れることができるのを示すかもしれませんが、圧縮されたPPPヘッダーを受け取る意欲を示したとしても、解凍されたPPPヘッダー情報を受け入れることができなければなりません。
DISCUSSION:
These options control the appearance of the PPP header.
Normally the PPP header consists of the address field (one
byte containing the value 0xff), the control field (one byte
containing the value 0x03), and the two-byte protocol field
that identifies the contents of the data area of the frame.
If a system negotiates address and control field compression
it indicates to its peer that it will accept PPP frames that
have or do not have these fields at the front of the header.
It does not indicate that it will be sending frames with
these fields removed. The protocol field may also be
compressed from two to one byte in most cases.
議論: これらのオプションはPPPヘッダーの外観を制御します。 通常、PPPヘッダーはアドレス・フィールド(値の0xffを含む1バイト)、制御フィールド(値0x03を含む1バイト)、およびフレームのデータ領域のコンテンツを特定する2バイトのプロトコル分野から成ります。 システムがアドレスと制御フィールド圧縮を交渉するなら、それは、ヘッダーの前部でこれらの分野を持っているか、または持っていないPPPフレームを受け入れるのを同輩に示します。 それは、これらの野原を取り除いていてフレームを送信するのを示しません。 多くの場合、また、プロトコル分野は2〜1バイト圧縮されるかもしれません。
IMPLEMENTATION:
Some hardware does not deal well with variable length header
information. In those cases it makes most sense for the
remote peer to send the full PPP header. Implementations
may ensure this by not sending the address/control field and
protocol field compression options to the remote peer. Even
if the remote peer has indicated an ability to receive
compressed headers there is no requirement for the local
router to send compressed headers.
実装: 何らかのハードウェアは可変長ヘッダー情報によく対処しません。 それらの場合では、それはリモート同輩が完全なPPPを送る意味にヘッダーに最もなります。 実装は、アドレス/制御フィールドとプロトコル分野圧縮オプションをリモート同輩に送らないことによって、これを確実にするかもしれません。 リモート同輩が圧縮されたヘッダーを受け取る能力を示したとしても、ローカルルータが圧縮されたヘッダーを送るという要件が全くありません。
A router MUST negotiate the Async Control Character Map (ACCM)
for asynchronous PPP links, but SHOULD NOT negotiate the ACCM
for synchronous links. If a router receives an attempt to
negotiate the ACCM over a synchronous link, it MUST ACKnowledge
ルータはAsync ControlキャラクターMap(ACCM)を非同期なPPPリンクと交渉しなければなりませんが、SHOULD NOTは同期リンクとACCMを交渉します。 ルータが同期リンクの上にACCMを交渉する試みを受けるなら、受けなければならない、ACKnowledge
Almquist & Kastenholz [Page 33] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[33ページ]RFC1716
the option and then ignore it.
オプションとその時はそれを無視します。
DISCUSSION:
There are implementations that offer both sync and async
modes of operation and may use the same code to implement
the option negotiation. In this situation it is possible
that one end or the other may send the ACCM option on a
synchronous link.
議論: それがオプション交渉を実装するのに同時性とasyncの両方に運転モードを提供して、同じコードを使用するかもしれない実装があります。 この状況で、その片端かもう片方が同期リンクにおけるACCMオプションを送るのは、可能です。
A router SHOULD properly negotiate the maximum receive unit
(MRU). Even if a system negotiates an MRU smaller than 1,500
bytes, it MUST be able to receive a 1,500 byte frame.
ルータSHOULDは適切に交渉します。最大はユニット(MRU)を受けます。 システムが1,500バイトより小さくMRUを交渉しても、1,500バイトのフレームを受け取ることができなければなりません。
A router SHOULD negotiate and enable the link quality
monitoring (LQM) option.
ルータSHOULDは(LQM)オプションをモニターするリンク品質を、交渉して、可能にします。
DISCUSSION:
This memo does not specify a policy for deciding whether the
link's quality is adequate. However, it is important (see
Section [3.3.6]) that a router disable failed links.
議論: このメモはリンクの品質が適切であるかどうか決めるための方針を指定しません。 しかしながら、それが重要である、(セクションを見てください、[3.3 .6) ルータは失敗したリンクを無効にします。
A router SHOULD implement and negotiate the magic number option
for loopback detection.
ルータSHOULDはループバック検出のためのマジックナンバーオプションを実装して、交渉します。
A router MAY support the authentication options (PAP - password
authentication protocol, and/or CHAP - challenge handshake
authentication protocol).
ルータは、認証がオプション(PAP--パスワード認証プロトコル、そして/または、CHAP--挑戦握手認証プロトコル)であるとサポートするかもしれません。
A router MUST support 16-bit CRC frame check sequence (FCS) and
MAY support the 32-bit CRC.
ルータは、16ビットのCRCがフレームチェックシーケンス(FCS)であるとサポートしなければならなくて、32ビットがCRCであるとサポートするかもしれません。
3.3.5.3 IP Control Protocol (ICP) Options
3.3.5.3 IP制御プロトコル(ICP)オプション
A router MAY offer to perform IP address negotiation. A router
MUST accept a refusal (REJect) to perform IP address
negotiation from the peer.
ルータは、IPアドレス交渉を実行すると申し出るかもしれません。 ルータは同輩からIPアドレス交渉を実行することへの拒否(REJect)を受け入れなければなりません。
A router SHOULD NOT perform Van Jacobson header compression of
TCP/IP packets if the link speed is in excess of 64 Kbps.
Below that speed the router MAY perform Van Jacobson (VJ)
header compression. At link speeds of 19,200 bps or less the
router SHOULD perform VJ header compression.
ルータSHOULD NOTはリンク速度が64KbpsであるならTCP/IPパケットのヴァンジェーコブソンヘッダー圧縮を実行します。 その速度より下では、ルータはヴァン・ジェーコブソン(VJ)ヘッダー圧縮を実行するかもしれません。 1万9200よりビーピーエスのリンク速度では、ルータSHOULDはVJヘッダー圧縮を実行します。
Almquist & Kastenholz [Page 34] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[34ページ]RFC1716
3.3.6 Interface Testing
3.3.6 インターフェース試験
A router MUST have a mechanism to allow routing software to
determine whether a physical interface is available to send
packets or not. A router SHOULD have a mechanism to allow routing
software to judge the quality of a physical interface. A router
MUST have a mechanism for informing the routing software when a
physical interface becomes available or unavailable to send
packets because of administrative action. A router MUST have a
mechanism for informing the routing software when it detects a
Link level interface has become available or unavailable, for any
reason.
ルータには、物理インターフェースがパケットを送るために利用可能であるか否かに関係なく、ルーティングソフトウェアが決定するのを許容するメカニズムがなければなりません。 SHOULDがメカニズムを持っているルータで、ルーティングソフトウェアは物理インターフェースの品質を判断できます。 ルータには、物理インターフェースがいつ管理動作のためにパケットを送るのにおいて利用可能であるか入手できなくなるかをルーティングソフトウェアに知らせるためのメカニズムがなければなりません。 ルータには、それがいつLinkの平らなインタフェースを検出するかをルーティングソフトウェアに知らせるのが利用可能であるか入手できなくなったどんな理由でもメカニズムがなければなりません。
DISCUSSION:
It is crucial that routers have workable mechanisms for
determining that their network connections are functioning
properly, since failure to do so (or failure to take the proper
actions when a problem is detected) can lead to black holes.
議論: ルータには彼らのネットワーク接続が適切に機能していることを決定するための実行可能なメカニズムがあるのは、重要です、そうしない場合ブラックホールに通じることができるので。
The mechanisms available for detecting problems with network
connections vary considerably, depending on the Link Layer
protocols in use and also in some cases on the interface
hardware chosen by the router manufacturer. The intent is to
maximize the capability to detect failures within the Link-
Layer constraints.
ネットワーク接続に関する問題を検出するのに利用可能なメカニズムはかなり異なります、使用中のLink Layerプロトコルと、そして、いくつかの場合、ルータメーカーによって選ばれたインタフェースハードウェアにもよって。 意図はLink層の規制の中に失敗を検出する能力を最大にすることです。
Almquist & Kastenholz [Page 35] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[35ページ]RFC1716
4. INTERNET LAYER - PROTOCOLS
4. インターネット層--プロトコル
4.1 INTRODUCTION
4.1 序論
This chapter and chapter 5 discuss the protocols used at the Internet Layer: IP, ICMP, and IGMP. Since forwarding is obviously a crucial topic in a document discussing routers, chapter 5 limits itself to the aspects of the protocols which directly relate to forwarding. The current chapter contains the remainder of the discussion of the Internet Layer protocols.
本章と第5章はインターネットLayerで使用されるプロトコルについて議論します: IP、ICMP、およびIGMP。 推進がドキュメント議論ルータで明らかに重要な話題であるので、第5章はそれ自体を直接推進に関連するプロトコルの局面に制限します。 現在の章はインターネットLayerプロトコルの議論の残りを含んでいます。
4.2 INTERNET PROTOCOL - IP
4.2インターネットプロトコル--IP
4.2.1 INTRODUCTION
4.2.1 序論
Routers MUST implement the IP protocol, as defined by
[INTERNET:1]. They MUST also implement its mandatory extensions:
subnets (defined in [INTERNET:2]), and IP broadcast (defined in
[INTERNET:3]).
ルータは[インターネット: 1]時までに定義されるようにIPプロトコルを実装しなければなりません。 また、彼らは義務的な拡大を実装しなければなりません: サブネット([インターネット: 2]では、定義される)、およびIP放送([インターネット: 3]では、定義されます)。
A router MUST be compliant, and SHOULD be unconditionally
compliant, with the requirements of sections 3.2.1 and 3.3 of
[INTRO:2], except that:
ルータは対応するに違いありません、そして、SHOULDは無条件に対応します。セクション3.2 .1と3.3[INTRO: 2]の要件で言いなりになります、それを除いてください:
o Section 3.2.1.1 may be ignored, since it duplicates
requirements found in this memo.
o セクション3.2 .1 このメモで見つけられた要件をコピーするので、.1は無視されるかもしれません。
o Section 3.2.1.2 may be ignored, since it duplicates
requirements found in this memo.
o セクション3.2 .1 このメモで見つけられた要件をコピーするので、.2は無視されるかもしれません。
o Section 3.2.1.3 should be ignored, since it is superseded by
Section [4.2.2.11] of this memo.
o セクション3.2.1、それがセクションによって取って代わられるので.3が無視されるべきである、[4.2 .2 この.11のメモ]。
o Section 3.2.1.4 may be ignored, since it duplicates
requirements found in this memo.
o セクション3.2 .1 このメモで見つけられた要件をコピーするので、.4は無視されるかもしれません。
o Section 3.2.1.6 should be ignored, since it is superseded by
Section [4.2.2.4] of this memo.
o セクション3.2.1、それがセクションによって取って代わられるので.6が無視されるべきである、[4.2 .2 この.4のメモ]。
o Section 3.2.1.8 should be ignored, since it is superseded by
Section [4.2.2.1] of this memo.
o セクション3.2.1、それがセクションによって取って代わられるので.8が無視されるべきである、[4.2 .2 この.1のメモ]。
In the following, the action specified in certain cases is to
silently discard a received datagram. This means that the
datagram will be discarded without further processing and that the
以下では、ある場合には指定された動作は静かに容認されたデータグラムを捨てることです。 これは、データグラムがさらなる処理とそれなしで捨てられることを意味します。
Almquist & Kastenholz [Page 36] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[36ページ]RFC1716
router will not send any ICMP error message (see Section [4.3]) as
a result. However, for diagnosis of problems a router SHOULD
provide the capability of logging the error (see Section [1.3.3]),
including the contents of the silently-discarded datagram, and
SHOULD record the event in a statistics counter.
ルータはどんなICMPエラーメッセージも送らないでしょう。(その結果セクション[4.3])を見てください。 しかしながら、問題aルータの診断のために、SHOULDが誤りを登録する能力を提供する、(セクションを見てください、[1.3、.3、)、静かに捨てられたデータグラム、およびa統計のイベントが打ち返すSHOULD記録のコンテンツを含んでいます。
4.2.2 PROTOCOL WALK-THROUGH
4.2.2 プロトコル立ち稽古
RFC 791 is [INTERNET:1], the specification for the Internet
Protocol.
RFC791は[インターネット: 1]、インターネットプロトコルのための仕様です。
4.2.2.1 Options: RFC-791 Section 3.2
4.2.2.1 オプション: RFC-791部3.2
In datagrams received by the router itself, the IP layer MUST
interpret those IP options that it understands and preserve the
rest unchanged for use by higher layer protocols.
ルータ自体によって受け取られたデータグラムでは、IP層は、それが理解しているそれらのIPオプションを解釈して、使用に、より高い層のプロトコルで変わりのない残りを保存しなければなりません。
Higher layer protocols may require the ability to set IP
options in datagrams they send or examine IP options in
datagrams they receive. Later sections of this document
discuss specific IP option support required by higher layer
protocols.
より高い層のプロトコルはそれらが送るデータグラムにIPオプションをはめ込むか、または彼らが受けるデータグラムでIPオプションを調べる能力を必要とするかもしれません。 このドキュメントの後のセクションは、より高い層のプロトコルによって必要とされた特定のIPオプションサポートについて論じます。
DISCUSSION:
Neither this memo nor [INTRO:2] define the order in which a
receiver must process multiple options in the same IP
header. Hosts and routers originating datagrams containing
multiple options must be aware that this introduces an
ambiguity in the meaning of certain options when combined
with a source-route option.
議論: このメモも[INTRO: 2]も受信機が同じIPヘッダーで複数のオプションを処理しなければならないオーダーを定義しません。 複数のオプションを含むデータグラムを溯源するホストとルータは送信元経路オプションに結合されるとこれが、あるオプションの意味におけるあいまいさを導入するのを意識しているに違いありません。
Here are the requirements for specific IP options:
ここに、特定のIPオプションのための要件があります:
(a) Security Option
(a) セキュリティオプション
Some environments require the Security option in every
packet originated or received. Routers SHOULD IMPLEMENT
the revised security option described in [INTERNET:5].
いくつかの環境が溯源されるか、または受け取られたあらゆるパケットでSecurityオプションを必要とします。 改訂されたセキュリティオプションが[インターネット: 5]で説明したルータSHOULD IMPLEMENT。
DISCUSSION:
Note that the security options described in
[INTERNET:1] and RFC 1038 ([INTERNET:16]) are obsolete.
議論: [インターネット: 1]で説明されたセキュリティオプションとRFC1038[インターネット: 16)が時代遅れであることに注意してください。
(b) Stream Identifier Option
(b) ストリーム識別子オプション
This option is obsolete; routers SHOULD NOT place this
option in a datagram that the router originates. This
このオプションは時代遅れです。 ルータSHOULD NOTはルータが溯源するデータグラムにこのオプションを置きます。 これ
Almquist & Kastenholz [Page 37] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[37ページ]RFC1716
option MUST be ignored in datagrams received by the
router.
ルータによって受け取られたデータグラムでオプションを無視しなければなりません。
(c) Source Route Options
(c) 送信元経路オプション
A router MUST be able to act as the final destination of a
source route. If a router receives a packet containing a
completed source route (i.e., the pointer points beyond
the last field and the destination address in the IP
header addresses the router), the packet has reached its
final destination; the option as received (the recorded
route) MUST be passed up to the transport layer (or to
ICMP message processing).
ルータは送信元経路の最終的な目的地として機能できなければなりません。 ルータが完成した送信元経路を含むパケットを受けるなら(すなわち、ポイント最後の分野を超えたポインタとIPヘッダーの送付先アドレスはルータを記述します)、パケットは最終的な目的地に達しました。 (記録されたルート)を受けるとき、オプションにトランスポート層(またはICMPメッセージ処理に)まで合格しなければなりません。
In order to respond correctly to source-routed datagrams
it receives, a router MUST provide a means whereby
transport protocols and applications can reverse the
source route in a received datagram and insert the
reversed source route into datagrams they originate (see
Section 4 of [INTRO:2] for details).
正しくそれが受けるソースによって発送されたデータグラムに応じるために、ルータは、トランスポート・プロトコルとアプリケーションが逆になることができる手段に容認されたデータグラムの送信元経路を提供して、それらが溯源するデータグラムに逆にされた送信元経路を挿入しなければなりません(詳細に関して[INTRO: 2]のセクション4を見てください)。
Some applications in the router MAY require that the user
be able to enter a source route.
ルータにおけるいくつかのアプリケーションが、ユーザが送信元経路に入ることができるのを必要とするかもしれません。
A router MUST NOT originate a datagram containing multiple
source route options. What a router should do if asked to
forward a packet containing multiple source route options
is described in Section [5.2.4.1].
ルータは複数の送信元経路オプションを含むデータグラムを溯源してはいけません。 複数の送信元経路オプションを含むパケットを進めるように頼まれるならルータがするべきであることがセクションで説明される、[5.2 .4 .1]。
When a source route option is created, it MUST be
correctly formed even if it is being created by reversing
a recorded route that erroneously includes the source host
(see case (B) in the discussion below).
送信元経路オプションが作成されるとき、それが誤って、送信元ホスト(以下での議論におけるケース(B)を見る)を含んでいる記録されたルートを逆にすることによって作成されていても、正しくそれを形成しなければなりません。
DISCUSSION:
Suppose a source routed datagram is to be routed from
source S to destination D via routers G1, G2, ... Gn.
Source S constructs a datagram with G1's IP address as
its destination address, and a source route option to
get the datagram the rest of the way to its
destination. However, there is an ambiguity in the
specification over whether the source route option in a
datagram sent out by S should be (A) or (B):
議論: ソースの発送されたデータグラムがルータG1、G2を通してソースSから目的地Dまで発送されることになっていると仮定してください… Gn。 ソースSは、目的地への方法の残りをデータグラムに得るために送付先アドレス、および送信元経路オプションとしてG1のIPアドレスでデータグラムを組み立てます。 しかしながら、Sによって出されたデータグラムの送信元経路オプションが(A)かそれとも(B)であるべきであるかの上に仕様にはあいまいさがあります:
(A): {>>G2, G3, ... Gn, D} <--- CORRECT
(A): >>G2、G3、…Gn、D、<。--- 正しい
(B): {S, >>G2, G3, ... Gn, D} <---- WRONG
(B): S、>>G2、G3、…Gn、D、<。---- 間違う
Almquist & Kastenholz [Page 38] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[38ページ]RFC1716
(where >> represents the pointer). If (A) is sent, the
datagram received at D will contain the option: {G1,
G2, ... Gn >>}, with S and D as the IP source and
destination addresses. If (B) were sent, the datagram
received at D would again contain S and D as the same
IP source and destination addresses, but the option
would be: {S, G1, ...Gn >>}; i.e., the originating host
would be the first hop in the route.
(>>がポインタを表すところ。) (A)を送ると、Dに受け取られたデータグラムはオプションを含むでしょう: G1、G2、IPソースと送付先アドレスとしてのSとDがある…Gn>>。 同じIPソースとしかし、送付先アドレス、オプションは以下の通りであるだろうというように、(B)を送るなら、Dに受け取られたデータグラムが再びSとDを含んでいるでしょうに。 S、G1、…Gn>>。 すなわち、送信元ホストはルートで最初のホップでしょう。
(d) Record Route Option
(d) ルートオプションを記録してください。
Routers MAY support the Record Route option in datagrams
originated by the router.
ルータはルータによって溯源されたデータグラムでRecord Routeオプションをサポートするかもしれません。
(e) Timestamp Option
(e) タイムスタンプオプション
Routers MAY support the timestamp option in datagrams
originated by the router. The following rules apply:
ルータはルータによって溯源されたデータグラムでタイムスタンプオプションをサポートするかもしれません。 以下の規則は適用されます:
o When originating a datagram containing a Timestamp
Option, a router MUST record a timestamp in the option
if
o Timestamp Optionを含むデータグラムを溯源するとき、ルータはタイムスタンプをオプションに記録しなければなりません。
- Its Internet address fields are not pre-specified or
- Its first pre-specified address is the IP address of
the logical interface over which the datagram is
being sent (or the router's router-id if the
datagram is being sent over an unnumbered
interface).
- または、インターネットアドレス・フィールドがあらかじめ指定されない、--最初のあらかじめ指定されたアドレスはデータグラムが送られる論理的なインタフェースのIPアドレス(ルータのルータイドはデータグラムが存在であるなら無数のインタフェースを移動した)です。
o If the router itself receives a datagram containing a
Timestamp Option, the router MUST insert the current
timestamp into the Timestamp Option (if there is space
in the option to do so) before passing the option to
the transport layer or to ICMP for processing.
o ルータ自体がTimestamp Optionを含むデータグラムを受けるなら、処理のためにトランスポート層、または、ICMPにオプションに合格する前に、ルータはTimestamp Option(そうするためにオプションにスペースがあれば)に現在のタイムスタンプを挿入しなければなりません。
o A timestamp value MUST follow the rules given in
Section [3.2.2.8] of [INTRO:2].
o タイムスタンプ値がセクションで与えられた規則に従わなければならない、[3.2 .2 .8[INTRO: 2。]]
IMPLEMENTATION:
To maximize the utility of the timestamps contained in
the timestamp option, it is suggested that the
timestamp inserted be, as nearly as practical, the time
at which the packet arrived at the router. For
datagrams originated by the router, the timestamp
inserted should be, as nearly as practical, the time at
which the datagram was passed to the Link Layer for
実現: タイムスタンプオプションに含まれたタイムスタンプに関するユーティリティを最大にするために、挿入されたタイムスタンプがあることが提案されます、ほとんど同じくらい実用的です、パケットがルータに到着した時。 ルータによって溯源されたデータグラムに関しては、挿入されたタイムスタンプはそうであるべきです、ほとんど同じくらい実用的です、データグラムがLink Layerに渡された時
Almquist & Kastenholz [Page 39] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[39ページ]RFC1716
transmission.
トランスミッション。
4.2.2.2 Addresses in Options: RFC-791 Section 3.1
4.2.2.2 オプションにおけるアドレス: RFC-791部3.1
When a router inserts its address into a Record Route, Strict
Source and Record Route, Loose Source and Record Route, or
Timestamp, it MUST use the IP address of the logical interface
on which the packet is being sent. Where this rule cannot be
obeyed because the output interface has no IP address (i.e., is
an unnumbered interface), the router MUST instead insert its
router-id. The router's router-id is one of the router's IP
addresses. Which of the router's addresses is used as the
router-id MUST NOT change (even across reboots) unless changed
by the network manager or unless the configuration of the
router is changed such that the IP address used as the router-
id ceases to be one of the router's IP addresses. Routers with
multiple unnumbered interfaces MAY have multiple router-id's.
Each unnumbered interface MUST be associated with a particular
router-id. This association MUST NOT change (even across
reboots) without reconfiguration of the router.
ルータがRecord RouteかStrict SourceとRecord RouteかLoose SourceとRecord Routeか、Timestampにアドレスを挿入するとき、それはパケットが送られる論理的なインタフェースのIPアドレスを使用しなければなりません。 この規則に従うことができないところに、出力インタフェースにはIPアドレス(すなわち、無数のインタフェースである)が全くないので、ルータは代わりにルータイドを挿入しなければなりません。 ルータのルータイドはルータのIPアドレスの1つです。 ネットワークマネージャによって変えられないか、またはルータの構成が変えられない場合ルータイドが変化してはいけないので(リブートの向こう側にさえ)ルータのアドレスのどれが使用されているかので、ルータイドとして使用されるIPアドレスは、ルータのIPアドレスの1つであることをやめます。 複数の無数のインタフェースがあるルータには、ルータイドの複数のものがあるかもしれません。 それぞれの無数のインタフェースは特定のルータイドに関連しているに違いありません。 この協会はルータの再構成なしで変化してはいけません(リブートの向こう側にさえ)。
DISCUSSION:
This specification does not allow for routers which do not
have at least one IP address. We do not view this as a
serious limitation, since a router needs an IP address to
meet the manageability requirements of Chapter [8] even if
the router is connected only to point-to-point links.
議論: この仕様は少なくとも1つのIPアドレスを持っていないルータを考慮しません。 私たちはこれを重大な制限であるとみなしません、ルータがポイントツーポイント接続だけに接続されてもルータが章[8]の管理可能性必要条件を満たすためにIPアドレスを必要とするので。
IMPLEMENTATION:
One possible method of choosing the router-id that fulfills
this requirement is to use the numerically smallest (or
greatest) IP address (treating the address as a 32-bit
integer) that is assigned to the router.
実現: この要件を実現させるルータイドを選ぶ1つの可能な方法はルータに割り当てられる数の上で最も小さくて(最もすばらしい)のIPアドレス(32ビットの整数としてアドレスを扱う)を使用することです。
4.2.2.3 Unused IP Header Bits: RFC-791 Section 3.1
4.2.2.3 未使用のIPヘッダービット: RFC-791部3.1
The IP header contains two reserved bits: one in the Type of
Service byte and the other in the Flags field. A router MUST
NOT set either of these bits to one in datagrams originated by
the router. A router MUST NOT drop (refuse to receive or
forward) a packet merely because one or more of these reserved
bits has a non-zero value.
IPヘッダーは予約された2ビットを含んでいます: ServiceバイトのTypeの1つとFlags分野のもう片方。 ルータはルータによって溯源されたデータグラムの1つにこれらのどちらのビットも設定してはいけません。 単にこれらの予約されたビットの1つ以上には非ゼロ値があるので、ルータは(受けるか、または進める廃物)パケットを落としてはいけません。
Almquist & Kastenholz [Page 40] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[40ページ]RFC1716
DISCUSSION:
Future revisions to the IP protocol may make use of these
unused bits. These rules are intended to ensure that these
revisions can be deployed without having to simultaneously
upgrade all routers in the Internet.
議論: IPプロトコルへの今後の改正はこれらの未使用のビットを利用するかもしれません。 これらの規則が、同時にインターネットのすべてのルータをアップグレードさせる必要はなくてこれらの改正を配備できるのを保証することを意図します。
4.2.2.4 Type of Service: RFC-791 Section 3.1
4.2.2.4 サービスのタイプ: RFC-791部3.1
The Type-of-Service byte in the IP header is divided into three
sections: the Precedence field (high-order 3 bits), a field
that is customarily called Type of Service or TOS (next 4
bits), and a reserved bit (the low order bit).
IPヘッダーのサービスのTypeバイトは3つのセクションに分割されます: Precedenceは(高位3ビット)をさばきます、通例にServiceのTypeかTOS(次の4ビット)と、予約されたビットと呼ばれる分野(下位のビット)。
Rules governing the reserved bit were described in Section
[4.2.2.3].
予約されたビットを決定する規則がセクションで説明された、[4.2 .2 .3]。
A more extensive discussion of the TOS field and its use can be
found in [ROUTE:11].
[ROUTE: 11]でTOS分野とその使用の、より大規模な議論を見つけることができます。
The description of the IP Precedence field is superseded by
Section [5.3.3]. RFC-795, Service Mappings, is obsolete and
SHOULD NOT be implemented.
IP Precedence分野の記述がセクションによって取って代わられる、[5.3 .3]。 RFC-795(Service Mappings)が時代遅れである、SHOULD NOT、実行されてください。
4.2.2.5 Header Checksum: RFC-791 Section 3.1
4.2.2.5 ヘッダーチェックサム: RFC-791部3.1
As stated in Section [5.2.2], a router MUST verify the IP
checksum of any packet which is received. The router MUST NOT
provide a means to disable this checksum verification.
セクションに述べられている、[5.2、.2、]、ルータはどんな受け取られていているパケットのIPチェックサムについても確かめなければなりません。 ルータはこのチェックサム検証を無効にする手段を提供してはいけません。
IMPLEMENTATION:
A more extensive description of the IP checksum, including
extensive implementation hints, can be found in [INTERNET:6]
and [INTERNET:7].
実現: [インターネット: 6]と[インターネット: 7]で大規模な実現ヒントを含むIPチェックサムの、より大規模な記述を見つけることができます。
4.2.2.6 Unrecognized Header Options: RFC-791 Section 3.1
4.2.2.6 認識されていないヘッダーオプション: RFC-791部3.1
A router MUST ignore IP options which it does not recognize. A
corollary of this requirement is that a router MUST implement
the End of Option List option and the No Operation option,
since neither contains an explicit length.
ルータはそれが認識しないIPオプションを無視しなければなりません。 この要件の推論はルータがOption ListオプションといいえOperationオプションのEndを実行しなければならないということです、どちらも明白な長さを含んでいないので。
Almquist & Kastenholz [Page 41] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[41ページ]RFC1716
DISCUSSION:
All future IP options will include an explicit length.
議論: すべての今後のIPオプションが明白な長さを含むでしょう。
4.2.2.7 Fragmentation: RFC-791 Section 3.2
4.2.2.7 断片化: RFC-791部3.2
Fragmentation, as described in [INTERNET:1], MUST be supported
by a router.
[インターネット: 1]で説明される断片化はルータで後押しされていなければなりません。
When a router fragments an IP datagram, it SHOULD minimize the
number of fragments. When a router fragments an IP datagram,
it MUST send the fragments in order. A fragmentation method
which may generate one IP fragment which is significantly
smaller than the other MAY cause the first IP fragment to be
the smaller one.
aであるときに、ルータはIPデータグラムを断片化して、それはSHOULDです。断片の数を最小にしてください。 ルータがIPデータグラムを断片化すると、それは整然とした状態で断片を送らなければなりません。 1個のもう片方よりかなり小さいIP断片を発生させるかもしれない断片化方法は、最初のIP断片が小さいものであることを引き起こすかもしれません。
DISCUSSION:
There are several fragmentation techniques in common use in
the Internet. One involves splitting the IP datagram into
IP fragments with the first being MTU sized, and the others
being approximately the same size, smaller than the MTU.
The reason for this is twofold. The first IP fragment in
the sequence will be the effective MTU of the current path
between the hosts, and the following IP fragments are sized
to hopefully minimize the further fragmentation of the IP
datagram. Another technique is to split the IP datagram
into MTU sized IP fragments, with the last fragment being
the only one smaller, as per page 26 of [INTERNET:1].
議論: 共用のいくつかの断片化のテクニックがインターネットにあります。 1つはMTUである1番目のIP断片へのIPデータグラムが大きさで分けた分かれる、およびほとんど同じサイズである他のものにかかわります、MTUより小さいです。 この理由は二つです。 系列における最初のIP断片はホストの間の現在の経路の有効なMTUになるでしょう、そして、以下のIP断片は、希望をいだいてIPデータグラムのさらなる断片化を最小にするために大きさで分けられます。 別のテクニックはIPデータグラムを大きさで分けられたIPが断片化するMTUに分けることです、より小さく唯一無二である最後の断片で、26[インターネット: 1]ページに従って。
A common trick used by some implementations of TCP/IP is to
fragment an IP datagram into IP fragments that are no larger
than 576 bytes when the IP datagram is to travel through a
router. In general, this allows the resulting IP fragments
to pass the rest of the path without further fragmentation.
This would, though, create more of a load on the destination
host, since it would have a larger number of IP fragments to
reassemble into one IP datagram. It would also not be
efficient on networks where the MTU only changes once, and
stays much larger than 576 bytes (such as an 802.5 network
with a MTU of 2048 or an Ethernet network with an MTU of
1536).
TCP/IPのいくつかの実現で使用される一般的なトリックはIPデータグラムがルータを通って移動することになっているとき576バイトほど大きくないIP断片にIPデータグラムを断片化することです。 一般に、これで、結果として起こるIP断片はさらなる断片化なしで経路の残りを通過できます。 もっとも、これはあて先ホストの上の一層の負荷を作成するでしょう、それには、1個のIPデータグラムに組み立て直すより多くのIP断片があるでしょう、したがって。 また、それもMTUが一度変化するだけであり、576バイトよりはるかに大きいままであるネットワーク(2048年のMTUとの802.5ネットワークか1536年のMTUとのイーサネットネットワークなどの)で効率的でないでしょう。
One other fragmentation technique discussed was splitting
the IP datagram into approximately equal sized IP fragments,
with the size being smaller than the next hop network's MTU.
This is intended to minimize the number of fragments that
would result from additional fragmentation further down the
他の断片化のテクニックが議論した1つはIPデータグラムをほとんど等しい大きさで分けられたIP断片に分けていました、サイズが次のホップネットワークのMTUより小さい状態で。 これが下にさらに追加断片化から生じる断片の数を最小にすることを意図します。
Almquist & Kastenholz [Page 42] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[42ページ]RFC1716
path.
経路。
In most cases, routers should try and create situations that
will generate the lowest number of IP fragments possible.
多くの場合、ルータはIP断片の可能な最も下位の数を発生させる状況を作成してみるべきです。
Work with slow machines leads us to believe that if it is
necessary to send small packets in a fragmentation scheme,
sending the small IP fragment first maximizes the chance of
a host with a slow interface of receiving all the fragments.
遅いマシンによる仕事は、私たちが、断片化計画で小型小包を送るのが必要であるなら、最初に小さいIP断片を送るとホストの機会がすべての断片を受ける遅いインタフェースで最大化すると信じているように導きます。
4.2.2.8 Reassembly: RFC-791 Section 3.2
4.2.2.8 Reassembly: RFC-791部3.2
As specified in Section 3.3.2 of [INTRO:2], a router MUST
support reassembly of datagrams which it delivers to itself.
.2セクション3.3[INTRO: 2]で指定されるように、ルータはそれがそれ自体に届けるデータグラムの再アセンブリを支持しなければなりません。
4.2.2.9 Time to Live: RFC-791 Section 3.2
4.2.2.9生きる時間: RFC-791部3.2
Time to Live (TTL) handling for packets originated or received
by the router is governed by [INTRO:2]. Note in particular
that a router MUST NOT check the TTL of a packet except when
forwarding it.
ルータによって溯源されるか、または受け取られたパケットのためのLive(TTL)取り扱いへの時間は[INTRO: 2]時までに決定されます。 それを進める時を除いて、ルータがパケットのTTLをチェックしてはいけないことに特に注意してください。
4.2.2.10 Multi-subnet Broadcasts: RFC-922
4.2.2.10 マルチサブネットは放送されます: RFC-922
All-subnets broadcasts (called multi-subnet broadcasts in
[INTERNET:3]) have been deprecated. See Section [5.3.5.3].
オールサブネット放送(マルチサブネット放送を回収します[インターネット: 3])は非難されました。 セクションを見てください、[5.3 .5 .3]。
4.2.2.11 Addressing: RFC-791 Section 3.2
4.2.2.11 アドレシング: RFC-791部3.2
There are now five classes of IP addresses: Class A through
Class E. Class D addresses are used for IP multicasting
[INTERNET:4], while Class E addresses are reserved for
experimental use.
現在、5つのクラスのIPアドレスがあります: Class E.Class Dアドレスを通るクラスAはIPマルチキャスティング[インターネット: 4]に使用されます、Class Eアドレスが実験用のために予約されますが。
A multicast (Class D) address is a 28-bit logical address that
stands for a group of hosts, and may be either permanent or
transient. Permanent multicast addresses are allocated by the
Internet Assigned Number Authority [INTRO:7], while transient
addresses may be allocated dynamically to transient groups.
Group membership is determined dynamically using IGMP
[INTERNET:4].
マルチキャスト(クラスD)アドレスはホストのグループを表している、永久的であるか、または一時的であるかもしれない28ビットの論理アドレスです。 永久的なマルチキャストアドレスはISOCの機関の一つで[INTRO: 7]によって割り当てられます、ダイナミックに一時的なグループに一時アドレスを割り当てるかもしれませんが。 グループ会員資格は、ダイナミックに、IGMP[インターネット: 4]を使用することで決定しています。
We now summarize the important special cases for Unicast (that
is class A, B, and C) IP addresses, using the following
notation for an IP address:
私たちは現在Unicast(それはクラスA、B、およびCである)IPアドレスのために重要な特別なケースをまとめます、IPアドレスに以下の記法を使用して:
Almquist & Kastenholz [Page 43] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[43ページ]RFC1716
{ <Network-number>, <Host-number> }
<ネットワーク・ナンバー>、<ホスト番号>。
or
または
{ <Network-number>, <Subnet-number>, <Host-number> }
<ネットワーク・ナンバー>、<サブネット番号>、<ホスト番号>。
and the notation -1 for a field that contains all 1 bits and
the notation 0 for a field that contains all 0 bits. This
notation is not intended to imply that the 1-bits in a subnet
mask need be contiguous.
そして、分野へのすべての1ビットを含む記法-1と分野へのすべての0ビットを含む記法0。 この記法が、サブネットにおける1ビットのマスクが隣接でなければならないことを含意することを意図しません。
(a) { 0, 0 }
(a){ 0, 0 }
This host on this network. It MUST NOT be used as a
source address by routers, except the router MAY use this
as a source address as part of an initialization procedure
(e.g., if the router is using BOOTP to load its
configuration information).
このネットワークのこのホスト。 それはソースアドレスとしてルータによって使用されてはいけなくて、ルータを除いて、初期化手順の一部としてのソースアドレスとしてこれを使用するかもしれません(例えば、ルータが設定情報をロードするのにBOOTPを使用しているなら)。
Incoming datagrams with a source address of { 0, 0 } which
are received for local delivery (see Section [5.2.3]),
MUST be accepted if the router implements the associated
protocol and that protocol clearly defines appropriate
action to be taken. Otherwise, a router MUST silently
discard any locally-delivered datagram whose source
address is { 0, 0 }.
0、地方の配送のために受け取られる0のソースアドレスがある受信データグラム、(セクションを見てください、[5.2、.3、)、ルータが関連プロトコルを実装して、そのプロトコルが取るために明確に適切な行動を定義するなら、受け入れなければなりません。 さもなければ、ルータは静かに、ソースアドレスが0、0であるどんな局所的に提供されたデータグラムも捨てなければなりません。
DISCUSSION:
Some protocols define specific actions to take in
response to a received datagram whose source address is
{ 0, 0 }. Two examples are BOOTP and ICMP Mask
Request. The proper operation of these protocols often
depends on the ability to receive datagrams whose
source address is { 0, 0 }. For most protocols,
however, it is best to ignore datagrams having a source
address of { 0, 0 } since they were probably generated
by a misconfigured host or router. Thus, if a router
knows how to deal with a given datagram having a { 0, 0
} source address, the router MUST accept it.
Otherwise, the router MUST discard it.
議論: いくつかのプロトコルが、ソースアドレスが0、0である容認されたデータグラムに対応して取るために特定の動作を定義します。 2つの例が、BOOTPとICMP Mask Requestです。 これらのプロトコルの適切な操作はしばしばソースアドレスが0、0であるデータグラムを受け取る能力に依存します。 しかしながら、ほとんどのプロトコルに、それらがたぶんmisconfiguredホストかルータによって生成されたので0、0のソースアドレスを持っているデータグラムを無視するのは最も良いです。 したがって、ルータが0、0ソースアドレスを持っている与えられたデータグラムに対処する方法を知っているなら、ルータはそれを受け入れなければなりません。 さもなければ、ルータはそれを捨てなければなりません。
See also Section [4.2.3.1] for a non-standard use of { 0,
0 }.
また、セクションを見てください、[4.2 .3 .1] 0、0の標準的でない使用のために。
(b) { 0, <Host-number> }
(b)0、<ホスト番号>。
Specified host on this network. It MUST NOT be sent by
このネットワークの指定されたホスト。 それで、発信されてはいけません。
Almquist & Kastenholz [Page 44] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[44ページ]RFC1716
routers except that the router MAY uses this as a source
address as part of an initialization procedure by which
the it learns its own IP address.
ルータ、5月がソースアドレスとしてのこれを使用するルータが初期化手順を離れさせる、どれ、それはそれ自身のIPアドレスを学ぶか。
(c) { -1, -1 }
(c){ -1, -1 }
Limited broadcast. It MUST NOT be used as a source
address.
株式会社は放送されました。 ソースアドレスとしてそれを使用してはいけません。
A datagram with this destination address will be received
by every host and router on the connected physical
network, but will not be forwarded outside that network.
この送付先アドレスがあるデータグラムを接続物理ネットワークにあらゆるホストとルータで受け取りますが、そのネットワークの外で進めないでしょう。
(d) { <Network-number>, -1 }
(d)<ネットワーク・ナンバー>、-1
Network Directed Broadcast - a broadcast directed to the
specified network. It MUST NOT be used as a source
address. A router MAY originate Network Directed
Broadcast packets. A router MUST receive Network Directed
Broadcast packets; however a router MAY have a
configuration option to prevent reception of these
packets. Such an option MUST default to allowing
reception.
Directed Broadcastをネットワークでつないでください--指定されたネットワークに向けられた放送。 ソースアドレスとしてそれを使用してはいけません。 ルータはNetwork Directed Broadcastパケットを溯源するかもしれません。 ルータはNetwork Directed Broadcastパケットを受けなければなりません。 しかしながら、ルータには、これらのパケットのレセプションを防ぐ設定オプションがあるかもしれません。 そのようなオプションはレセプションを許容するのをデフォルトとしなければなりません。
(e) { <Network-number>, <Subnet-number>, -1 }
(e)<ネットワーク・ナンバー>、<サブネット番号>、-1
Subnetwork Directed Broadcast - a broadcast sent to the
specified subnet. It MUST NOT be used as a source
address. A router MAY originate Network Directed
Broadcast packets. A router MUST receive Network Directed
Broadcast packets; however a router MAY have a
configuration option to prevent reception of these
packets. Such an option MUST default to allowing
reception.
サブネットワークDirected Broadcast--放送は指定されたサブネットに発信しました。 ソースアドレスとしてそれを使用してはいけません。 ルータはNetwork Directed Broadcastパケットを溯源するかもしれません。 ルータはNetwork Directed Broadcastパケットを受けなければなりません。 しかしながら、ルータには、これらのパケットのレセプションを防ぐ設定オプションがあるかもしれません。 そのようなオプションはレセプションを許容するのをデフォルトとしなければなりません。
(f) { <Network-number>, -1, -1 }
(f)<ネットワーク・ナンバー>、-1、-1
All Subnets Directed Broadcast - a broadcast sent to all
subnets of the specified subnetted network. It MUST NOT
be used as a source address. A router MAY originate
Network Directed Broadcast packets. A router MUST receive
Network Directed Broadcast packets; however a router MAY
have a configuration option to prevent reception of these
packets. Such an option MUST default to allowing
reception.
すべてのSubnets Directed Broadcast--放送は指定されたサブネット化したネットワークのすべてのサブネットに発信しました。 ソースアドレスとしてそれを使用してはいけません。 ルータはNetwork Directed Broadcastパケットを溯源するかもしれません。 ルータはNetwork Directed Broadcastパケットを受けなければなりません。 しかしながら、ルータには、これらのパケットのレセプションを防ぐ設定オプションがあるかもしれません。 そのようなオプションはレセプションを許容するのをデフォルトとしなければなりません。
Almquist & Kastenholz [Page 45] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[45ページ]RFC1716
(g) { 127, <any> }
(g)127、<、どんな>。
Internal host loopback address. Addresses of this form
MUST NOT appear outside a host.
内部のホストループバックアドレス。 このフォームのアドレスはホストの外に現れてはいけません。
The <Network-number> is administratively assigned so that its
value will be unique in the entire world.
<Network-番号>は、値が全世界でユニークになるように、行政上割り当てられます。
IP addresses are not permitted to have the value 0 or -1 for
any of the <Host-number>, <Network-number>, or <Subnet-number>
fields (except in the special cases listed above). This
implies that each of these fields will be at least two bits
long.
IPアドレスにはHost-数の>、<Network-番号>、または<Subnet-番号>がさばく(上に記載された特別なケース以外に)<のどれかの値0か-1があることが許可されていません。 これは、それぞれのこれらの分野が長さ少なくとも2ビットであることを含意します。
For further discussion of broadcast addresses, see Section
[4.2.3.1].
放送演説のさらなる議論に関して、セクションを見てください、[4.2 .3 .1]。
Since (as described in Section [4.2.1]) a router must support
the subnet extensions to IP, there will be a subnet mask of the
form: { -1, -1, 0 } associated with each of the host's local IP
addresses; see Sections [4.3.3.9], [5.2.4.2], and [10.2.2].
以来、(セクションで説明される、[4.2、.1、)、ルータはサブネット拡大をIPにサポートしなければならなくて、形式のサブネットマスクがあるでしょう: -1、-1、0はそれぞれのホストのローカルアイピーアドレスと交際しました。 そして、セクションを見てください、[4.3 .3 .9、][5.2 .4 .2、][10.2 .2]。
When a router originates any datagram, the IP source address
MUST be one of its own IP addresses (but not a broadcast or
multicast address). The only exception is during
initialization.
ルータがどんなデータグラムも溯源するとき、IPソースアドレスはそれ自身のIPアドレス(しかし、放送でないマルチキャストアドレスでない)の1つであるに違いありません。 唯一の例外が初期化の間、あります。
For most purposes, a datagram addressed to a broadcast or
multicast destination is processed as if it had been addressed
to one of the router's IP addresses; that is to say:
ほとんどの目的のために、まるでそれがルータのIPアドレスの1つに扱われたかのように放送かマルチキャストの目的地に扱われたデータグラムは処理されます。 すなわち:
o A router MUST receive and process normally any packets with
a broadcast destination address.
o 通常、ルータは、ブロードキャストあて先アドレスでどんなパケットも受けて、処理しなければなりません。
o A router MUST receive and process normally any packets sent
to a multicast destination address which the router is
interested in.
o 通常、ルータは、ルータが興味を持っているマルチキャスト送付先アドレスに送られたどんなパケットも、受けて、処理しなければなりません。
The term specific-destination address means the equivalent
local IP address of the host. The specific-destination address
is defined to be the destination address in the IP header
unless the header contains a broadcast or multicast address, in
which case the specific-destination is an IP address assigned
to the physical interface on which the datagram arrived.
用語特定の送付先アドレスはホストの同等なローカルアイピーアドレスを意味します。 ヘッダーが放送かマルチキャストアドレスを含んでいない場合、特定の送付先アドレスはIPヘッダーの送付先アドレスになるように定義されて、その場合、特定の目的地はデータグラムが届いた物理インターフェースに割り当てられたIPアドレスです。
A router MUST silently discard any received datagram containing
an IP source address that is invalid by the rules of this
ルータは静かにこの規則で無効のIPソースアドレスを含むどんな容認されたデータグラムも捨てなければなりません。
Almquist & Kastenholz [Page 46] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[46ページ]RFC1716
section. This validation could be done either by the IP layer
or by each protocol in the transport layer.
セクション。 IP層かトランスポート層の各プロトコルはこの合法化ができました。
DISCUSSION:
A misaddressed datagram might be caused by a Link Layer
broadcast of a unicast datagram or by another router or host
that is confused or misconfigured.
議論: misaddressedデータグラムは混乱するか、またはmisconfiguredされる別のユニキャストデータグラムのLink Layer放送かルータかホストによって引き起こされるかもしれません。
4.2.3 SPECIFIC ISSUES
4.2.3 特定の問題
4.2.3.1 IP Broadcast Addresses
4.2.3.1 IP放送演説
For historical reasons, there are a number of IP addresses
(some standard and some not) which are used to indicate that an
IP packet is an IP broadcast. A router
歴史的な理由で、多くのIPアドレスがある、(何らかの規格といくつか、)、IPパケットがIP放送であることを示すのに使用される。 ルータ
(1) MUST treat as IP broadcasts packets addressed to
255.255.255.255, { <Network-number>, -1 }, { <Network-
number>, <Subnet-number>, -1 }, and { <Network-number>,
-1, -1 }.
(1)はパケットが255.255に扱ったIP放送として扱わなければなりません。そして、.255 .255 <Network-番号>、-1、<Network-番号>、<は>にSubnet付番します、-1、<が>にNetwork付番します、-1、-1。
(2) SHOULD silently discard on receipt (i.e., don't even
deliver to applications in the router) any packet
addressed to 0.0.0.0, { <Network-number>, 0 }, {
<Network-number>, <Subnet-number>, 0 }, or { <Network-
number>, 0, 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、<Network-番号>、<が>、0にSubnet達する、<Network-番号>、0、0、。 これらのパケットが静かに捨てられないなら、IP放送としてそれらを扱わなければならない、(セクションを見てください、[5.3、.5、) これらのパケットの領収書を許容する設定オプションがあるかもしれません。 このオプションSHOULDはそれらを捨てるのをデフォルトとします。
(3) SHOULD (by default) use the limited broadcast address
(255.255.255.255) when originating an IP broadcast
destined for a connected network or subnet (except when
sending an ICMP Address Mask Reply, as discussed in
Section [4.3.3.9]). A router MUST receive limited
broadcasts.
(3) SHOULDが(デフォルトで)限られた放送演説を使用する、(255.255に、.255)いつ起因するIPが放送した.255が接続ネットワークかサブネットのために運命づけられた、(セクションで議論するようにICMP Address Mask Replyを送る、[4.3 .3 .9)。 ルータは限られた放送を受けなければなりません。
(4) SHOULD NOT originate datagrams addressed to 0.0.0.0, {
<Network-number>, 0 }, { <Network-number>, <Subnet-
number>, 0 }, or { <Network-number>, 0, 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、<Network-番号>、<が>、0にSubnet達する、<Network-番号>、0、0 これらのパケット(関連1つの形式の放送を使用することの代わりに)の世代を許容する設定オプションがあるかもしれません。 このオプションSHOULDはそれらを生成しないのをデフォルトとします。
Almquist & Kastenholz [Page 47] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[47ページ]RFC1716
DISCUSSION:
In the second bullet, the router obviously cannot recognize
addresses of the form { <Network-number>, <Subnet-number>, 0
} if the router does not know how the particular network is
subnetted. In that case, the rules of the second bullet do
not apply because, from the point of view of the router, the
packet is not an IP broadcast packet.
議論: 2番目の弾丸では、ルータは明らかに認識できません。ルータが、特定のネットワークがどのように「副-網で覆」われるかを知らないなら、<Network-番号>、<Subnet-番号>、0はフォームを扱います。 その場合、パケットがルータの観点からのIP放送パケットでないので、2番目の弾丸の規則は適用されません。
4.2.3.2 IP Multicasting
4.2.3.2 IPマルチキャスティング
An IP router SHOULD satisfy the Host Requirements with respect
to IP multicasting, as specified in Section 3.3.7 of [INTRO:2].
An IP router SHOULD support local IP multicasting on all
connected networks for which a mapping from Class D IP
addresses to link-layer addresses has been specified (see the
various IP-over-xxx specifications), and on all connected
point-to-point links. Support for local IP multicasting
includes originating multicast datagrams, joining multicast
groups and receiving multicast datagrams, and leaving multicast
groups. This implies support for all of [INTERNET:4] including
IGMP (see Section [4.4]).
SHOULDが.7セクション3.3[INTRO: 2]で指定されるようにIPマルチキャスティングに関してHost Requirementsを満たすIPルータ。 すべてのIPルータSHOULDサポートローカルアイピーマルチキャスティングは、Class D IPアドレスからリンクレイヤアドレスまでのマッピングが指定された(様々なIP過剰xxx仕様を見ます)ネットワークを接続して、ポイントツーポイント接続をすべてに接続しました。 マルチキャストグループに加わって、マルチキャストデータグラムを受けて、マルチキャストグループを出て、ローカルアイピーマルチキャスティングのサポートは、マルチキャストデータグラムを溯源するのを含んでいます。 IGMPを含んでいて、これは[インターネット: 4]のすべてのサポートを含意します。(セクション[4.4])を見てください。
DISCUSSION:
Although [INTERNET:4] is entitled Host Extensions for IP
Multicasting, it applies to all IP systems, both hosts and
routers. In particular, since routers may join multicast
groups, it is correct for them to perform the host part of
IGMP, reporting their group memberships to any multicast
routers that may be present on their attached networks
(whether or not they themselves are multicast routers).
議論: [インターネット: 4]はIP Multicastingのための題しているHost Extensionsですが、それはIPシステム、ホストとルータのすべての両方に適用されます。 ルータがマルチキャストグループに加わるかもしれないので、IGMPのホスト部分を実行するのは、特に、正しいです、どんなそれらの付属ネットワークに存在するかもしれないマルチキャストルータにもそれらのグループ会員資格を報告して(それら自体がマルチキャストルータであるか否かに関係なく)。
Some router protocols may specifically require support for
IP multicasting (e.g., OSPF [ROUTE:1]), or may recommend it
(e.g., ICMP Router Discovery [INTERNET:13]).
いくつかのルータプロトコルが、IPマルチキャスティング(例えば、OSPF[ROUTE: 1])に明確に支持を要するか、またはそれ(例えば、ICMP Routerディスカバリー[インターネット: 13])を推薦するかもしれません。
4.2.3.3 Path MTU Discovery
4.2.3.3 経路MTU発見
In order to eliminate fragmentation or minimize it, it is
desirable to know what is the path MTU along the path from the
source to destination. The path MTU is the minimum of the MTUs
of each hop in the path. [INTERNET:14] describes a technique
for dynamically discovering the maximum transmission unit (MTU)
of an arbitrary internet path. For a path that passes through
a router that does not support [INTERNET:14], this technique
might not discover the correct Path MTU, but it will always
断片化を排除するか、またはそれを最小にするために、ソースから目的地まで何が経路に沿った経路MTUであるかを知るのは望ましいです。 経路MTUは経路のそれぞれのホップのMTUsの最小限です。 [インターネット: 14] ダイナミックに、任意のインターネット経路のマキシマム・トランスミッション・ユニット(MTU)を発見するためのテクニックについて説明します。 このテクニックは正しいPath MTUを発見しないかもしれませんが、それはいつも[インターネット: 14]をサポートしないルータを通り抜ける経路への発見になるでしょう。
Almquist & Kastenholz [Page 48] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[48ページ]RFC1716
choose a Path MTU as accurate as, and in many cases more
accurate than, the Path MTU that would be chosen by older
techniques or the current practice.
より正確な状態で場合と多くの場合で同じくらい正確なPath MTUを選んでください、選ばれているPath MTUは、より古いテクニックか電流で練習します。
When a router is originating an IP datagram, it SHOULD use the
scheme described in [INTERNET:14] to limit the datagram's size.
If the router's route to the datagram's destination was learned
from a routing protocol that provides Path MTU information, the
scheme described in [INTERNET:14] is still used, but the Path
MTU information from the routing protocol SHOULD be used as the
initial guess as to the Path MTU and also as an upper bound on
the Path MTU.
aであるときに、ルータはIPデータグラムを溯源していて、それは体系がデータグラムのサイズを制限するために中[インターネット: 14]で説明したSHOULD使用です。 データグラムの目的地へのルータのルートが情報をPath MTUに供給するルーティング・プロトコルから学習されたなら、[インターネット: 14]で説明された体系はまだ使用されていて、ルーティング・プロトコルからの唯一のPath MTU情報はSHOULDです。Path MTUに関する初期の推測として上限としてもPath MTUで使用されてください。
4.2.3.4 Subnetting
4.2.3.4 サブネッティング
Under certain circumstances, it may be desirable to support
subnets of a particular network being interconnected only via a
path which is not part of the subnetted network. This is known
as discontiguous subnetwork support.
ある状況で、サブネット化したネットワークの一部でない経路を通してだけインタコネクトされる特定のネットワークのサブネットをサポートするのは望ましいかもしれません。 これはdiscontiguousサブネットワークサポートとして知られています。
Routers MUST support discontiguous subnetworks.
ルータは、discontiguousがサブネットワークであるとサポートしなければなりません。
IMPLEMENTATION:
In general, a router should not make assumptions about what
are subnets and what are not, but simply ignore the concept
of Class in networks, and treat each route as a { network,
mask }-tuple.
実装: 一般に、何がサブネットであるか、そして、ネットワークで単にClassの概念を無視する以外に、何がないかに関する仮定と御馳走はaとしてルータでそれぞれネットワーク、マスクを発送するべきではありません。-tuple。
DISCUSSION:
The Internet has been growing at a tremendous rate of late.
This has been placing severe strains on the IP addressing
technology. A major factor in this strain is the strict IP
Address class boundaries. These make it difficult to
efficiently size network numbers to their networks and
aggregate several network numbers into a single route
advertisement. By eliminating the strict class boundaries
of the IP address and treating each route as a {network
number, mask}-tuple these strains may be greatly reduced.
議論: インターネットは最近、物凄い速度で発展しています。 これは技術を扱うIPに厳しい緊張を置いています。 この緊張における重要な要因は厳しいIP Addressクラス境界です。 これらが作る、それ、難しい、効率的に、サイズネットワークはただ一つのルート広告へのいくつかのネットワーク・ナンバーにそれらのネットワークと集合に付番します。 aが数、マスクをネットワークでつなぎながら、IPアドレスの厳しいクラス限界を排除して、各ルートを扱うことによって、これらが張る-tupleは大いに減少するかもしれません。
The technology for currently doing this is Classless
Interdomain Routing (CIDR) [INTERNET:15].
現在これをするための技術はClassless Interdomainルート設定(CIDR)[インターネット: 15]です。
Furthermore, for similar reasons, a subnetted network need not
have a consistent subnet mask through all parts of the network.
For example, one subnet may use an 8 bit subnet mask, another
10 bit, and another 6 bit. This is known as variable subnet-
その上、同様の理由で、サブネット化したネットワークはネットワークのすべての部分を通って一貫したサブネットマスクを持つ必要はありません。 例えばサブネットが8ビットのサブネットマスク、もう10ビット、およびもう6ビット使用するかもしれない1つ。 これは変数サブネットとして知られています。
Almquist & Kastenholz [Page 49] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[49ページ]RFC1716
masks.
マスク。
Routers MUST support variable subnet-masks.
ルータは可変サブネットマスクを支えなければなりません。
4.3 INTERNET CONTROL MESSAGE PROTOCOL - ICMP
4.3インターネット・コントロール・メッセージ・プロトコル--ICMP
4.3.1 INTRODUCTION
4.3.1 序論
ICMP is an auxiliary protocol, which provides routing, diagnostic
and and error functionality for IP. It is described in
[INTERNET:8]. A router MUST support ICMP.
そして、ICMPが補助のプロトコルである、そして、IPのための誤りの機能性。(プロトコルはルーティング、病気の特徴を提供します)。 それは[インターネット: 8]で説明されます。 ルータはICMPをサポートしなければなりません。
ICMP messages are grouped in two classes which are discussed in
the following sections:
ICMPメッセージは以下のセクションで議論する2つのクラスで分類されます:
ICMP error messages:
ICMPエラーメッセージ:
Destination Unreachable Section 4.3.3.1
Redirect Section 4.3.3.2
Source Quench Section 4.3.3.3
Time Exceeded Section 4.3.3.4
Parameter Problem Section 4.3.3.5
目的地の手の届かないセクション4.3.3の.1の再直接の部4.3の.3.2ソース焼き入れ部4.3の.3の.3の時間の超えられている部4.3の.3.4パラメタ問題セクション4.3.3.5
ICMP query messages:
Echo Section 4.3.3.6
Information Section 4.3.3.7
Timestamp Section 4.3.3.8
Address Mask Section 4.3.3.9
Router Discovery Section 4.3.3.10
ICMPはメッセージについて質問します: エコーセクション4.3.3.6情報収集部門4.3.3.7タイムスタンプ部4.3の.3.8アドレスのマスク部分4.3.3.9ルータ発見部4.3 .3 .10
General ICMP requirements and discussion are in the next section.
一般ICMP要件と議論が次のセクションにあります。
4.3.2 GENERAL ISSUES
4.3.2 一般答弁
4.3.2.1 Unknown Message Types
4.3.2.1 未知のメッセージタイプ
If an ICMP message of unknown type is received, it MUST be
passed to the ICMP user interface (if the router has one) or
silently discarded (if the router doesn't have one).
未知のタイプのICMPメッセージが受信されているなら、それをICMPユーザーインタフェース(ルータに1つがあるなら)に通過されなければならないか、または静かに捨てなければなりません(ルータに1つがないなら)。
Almquist & Kastenholz [Page 50] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[50ページ]RFC1716
4.3.2.2 ICMP Message TTL
4.3.2.2 ICMPメッセージTTL
When originating an ICMP message, the router MUST initialize
the TTL. The TTL for ICMP responses must not be taken from the
packet which triggered the response.
ICMPメッセージを溯源するとき、ルータはTTLを初期化しなければなりません。 応答の引き金となったパケットからICMP応答のためのTTLを取ってはいけません。
4.3.2.3 Original Message Header
4.3.2.3 オリジナルのメッセージヘッダー
Every ICMP error message includes the Internet header and at
least the first 8 data bytes of the datagram that triggered the
error. More than 8 bytes MAY be sent, but the resulting ICMP
datagram SHOULD have a length of less than or equal to 576
bytes. The returned IP header (and user data) MUST be
identical to that which was received, except that the router is
not required to undo any modifications to the IP header that
are normally performed in forwarding that were performed before
the error was detected (e.g., decrementing the TTL, updating
options). Note that the requirements of Section [4.3.3.5]
supersede this requirement in some cases (i.e., for a Parameter
Problem message, if the problem is in a modified field, the
router must undo the modification). See Section [4.3.3.5])
あらゆるICMPエラーメッセージがインターネット・ヘッダーと誤りの引き金となったデータグラムの最初の8データ・バイトを含んでいます。 8バイト以上を送るかもしれませんが、結果として起こるICMPデータグラムSHOULDには、576バイト以下の長さがあります。 返されたIPヘッダー(そして、利用者データ)は受け取られたそれと同じであるに違いありません、ルータがIPヘッダーへの通常、誤りが検出される(例えば、オプションをアップデートして、TTLを減少させます)前に実行された推進で実行されるどんな変更も元に戻すのに必要でないのを除いて。 それに注意してください、セクションの要件、[4.3 .3 いくつかの場合、.5は]この要件に取って代わります(すなわち、Parameter Problemメッセージに関して、問題が変更された分野にあるなら、ルータは変更を元に戻さなければなりません)。 セクションを見てください、[4.3、.3、.5)
4.3.2.4 ICMP Message Source Address
4.3.2.4 ICMPメッセージ源アドレス
Except where this document specifies otherwise, the IP source
address in an ICMP message originated by the router MUST be one
of the IP addresses associated with the physical interface over
which the ICMP message is transmitted. If the interface has no
IP addresses associated with it, the router's router-id (see
Section [5.2.5]) is used instead.
このドキュメントが別の方法で指定するところ以外の、ルータによって溯源されたICMPメッセージのIPソースアドレスはICMPメッセージが送られる物理インターフェースに関連しているIPアドレスの1つであるに違いありません。 インタフェースでそれに関連しているIPアドレス、ルータのルータイドが全くない、(セクションを見てください、[5.2、.5、)、代わりに使用されます。
4.3.2.5 TOS and Precedence
4.3.2.5 TOSと先行
ICMP error messages SHOULD have their TOS bits set to the same
value as the TOS bits in the packet which provoked the sending
of the ICMP error message, unless setting them to that value
would cause the ICMP error message to be immediately discarded
because it could not be routed to its destination. Otherwise,
ICMP error messages MUST be sent with a normal (i.e. zero) TOS.
An ICMP reply message SHOULD have its TOS bits set to the same
value as the TOS bits in the ICMP request that provoked the
reply.
ICMPエラーメッセージSHOULDはICMPエラーメッセージの発信を引き起こしたパケットにTOSビットと同じ値にそれらのTOSビットを設定させます、それを目的地に発送できなかったのですぐにその値にそれらを設定するのにICMPエラーメッセージを捨てないなら。 さもなければ、正常な(すなわち、ゼロ)TOSと共にICMPエラーメッセージを送らなければなりません。 ICMPのTOSビットがそれを要求するので、SHOULDがTOSビットに同じ値に設定させるICMP応答メッセージは回答を引き起こしました。
EDITOR'S COMMENTS:
The following paragraph originally read:
エディタのコメント: 以下のパラグラフは元々、読みました:
ICMP error messages MUST have their IP Precedence field
ICMPエラーメッセージには、それらのIP Precedence分野がなければなりません。
Almquist & Kastenholz [Page 51] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[51ページ]RFC1716
set to the same value as the IP Precedence field in the
packet which provoked the sending of the ICMP error
message, except that the precedence value MUST be 6
(INTERNETWORK CONTROL) or 7 (NETWORK CONTROL), SHOULD be
7, and MAY be settable for the following types of ICMP
error messages: Unreachable, Redirect, Time Exceeded, and
Parameter Problem.
先行値が6(INTERNETWORK CONTROL)か7(NETWORK CONTROL)、SHOULDでなければならないのを除いて、ICMPエラーメッセージの発信を引き起こしたパケットのIP Precedence分野と同じ値へのセットは、7であり、以下のタイプに関するICMPエラーメッセージに、「舗装用敷石-可能」であるかもしれません: 超えられていた手の届かなくて、再直接の時間、およびパラメタ問題。
I believe that the following paragraph is equivalent and
easier for humans to parse (Source Quench is the only other
ICMP Error message). Other interpretations of the original
are sought.
私は、以下のパラグラフは同等であって、人間には、分析するのが、より簡単であると信じています(ソースQuenchは他の唯一のICMP Errorメッセージです)。 オリジナルの他の解釈は求められます。
ICMP Source Quench error messages MUST have their IP Precedence
field set to the same value as the IP Precedence field in the
packet which provoked the sending of the ICMP Source Quench
message. All other ICMP error messages (Destination
Unreachable, Redirect, Time Exceeded, and Parameter Problem)
MUST have their precedence value set to 6 (INTERNETWORK
CONTROL) or 7 (NETWORK CONTROL), SHOULD be 7. The IP
Precedence value for these error messages MAY be settable.
ICMP Source Quenchエラーメッセージで、ICMP Source Quenchメッセージの発信を引き起こしたパケットのIP Precedence分野と同じ値にそれらのIP Precedence分野を設定しなければなりません。 他のすべてのICMPエラーメッセージ(目的地Unreachable、Redirect、Time Exceeded、およびParameter Problem)が、6(INTERNETWORK CONTROL)か7(NETWORK CONTROL)、SHOULDへのそれらの先行選択値群が7であることを持たなければなりません。 これらのエラーメッセージのためのIP Precedence価値は「舗装用敷石-可能」であるかもしれません。
An ICMP reply message MUST have its IP Precedence field set to
the same value as the IP Precedence field in the ICMP request
that provoked the reply.
ICMP応答メッセージで、ICMPのIP Precedence分野と同じ値へのIP Precedence分野セットは、それが回答を引き起こしたよう要求しなければなりません。
4.3.2.6 Source Route
4.3.2.6 送信元経路
If the packet which provokes the sending of an ICMP error
message contains a source route option, the ICMP error message
SHOULD also contain a source route option of the same type
(strict or loose), created by reversing the portion before the
pointer of the route recorded in the source route option of the
original packet UNLESS the ICMP error message is an ICMP
Parameter Problem complaining about a source route option in
the original packet.
また、ICMPエラーメッセージの発信を引き起こすパケットが送信元経路オプションを含んでいるなら、ICMPエラーメッセージSHOULDは(厳しいかゆるい)であることで同じタイプの送信元経路オプションを含んでいて、ルートの指針がオリジナルのパケットの送信元経路オプションにUNLESSを記録する前に部分を逆にすることによって作成されて、ICMPエラーメッセージはオリジナルのパケットで送信元経路オプションに関して不平を言うICMP Parameter Problemです。
DISCUSSION:
In environments which use the U.S. Department of Defense
security option (defined in [INTERNET:5]), ICMP messages may
need to include a security option. Detailed information on
this topic should be available from the Defense
Communications Agency.
議論: 米国国防総省のセキュリティオプション([インターネット: 5]では、定義される)を使用する環境で、ICMPメッセージは、セキュリティオプションを含む必要があるかもしれません。 この話題の詳細な情報はDefense Communications Agencyから利用可能であるべきです。
Almquist & Kastenholz [Page 52] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[52ページ]RFC1716
4.3.2.7 When Not to Send ICMP Errors
4.3.2.7 いつ誤りをICMPに送りませんか。
An ICMP error message MUST NOT be sent as the result of
receiving:
受信するという結果としてICMPエラーメッセージを送ってはいけません:
o An ICMP error message, or
o またはICMPエラーメッセージ。
o A packet which fails the IP header validation tests
described in Section [5.2.2] (except where that section
specifically permits the sending of an ICMP error message),
or
o またはセクションで説明されたIPヘッダー合法化テストに失敗するパケット、[5.2、.2、]、(そのセクションが明確にICMPエラーメッセージの発信を可能にするところを除いた)。
o A packet destined to an IP broadcast or IP multicast
address, or
o またはパケットがIP放送かIPマルチキャストアドレスに運命づけられた。
o A packet sent as a Link Layer broadcast or multicast, or
o またはパケットがLink Layer放送かマルチキャストとして発信した。
o A packet whose source address has a network number of zero
or is an invalid source address (as defined in Section
[5.3.7]), or
o ソースアドレスがゼロのネットワーク・ナンバーを持っているか、無効のソースアドレスであるパケット、(セクションで定義される、[5.3、.7、)
o Any fragment of a datagram other then the first fragment
(i.e., a packet for which the fragment offset in the IP
header is nonzero).
o いずれもデータグラムを別に断片化して、次に、1番目は断片化します(すなわち、断片がIPヘッダーで相殺されたパケットは非零です)。
Furthermore, an ICMP error message MUST NOT be sent in any case
where this memo states that a packet is to be silently
discarded.
その上、どのような場合でもこのメモが、パケットが静かに捨てられることになっていると述べるところにICMPエラーメッセージを送ってはいけません。
NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT
ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.
以下に注意してください。 これらの制限は本書では送付ICMPエラーメッセージのためのほかの場所でどんな要件の上でも優先します。
DISCUSSION:
These rules aim to prevent the broadcast storms that have
resulted from routers or hosts returning ICMP error messages
in response to broadcast packets. For example, a broadcast
UDP packet to a non-existent port could trigger a flood of
ICMP Destination Unreachable datagrams from all devices that
do not have a client for that destination port. On a large
Ethernet, the resulting collisions can render the network
useless for a second or more.
議論: これらの規則は、ルータかホストから生じたブロードキャスト・ストームが放送パケットに対応してエラーメッセージをICMPに返すのを防ぐことを目指します。 例えば、その仕向港へのクライアントがいないすべてのデバイスから、実在しないポートへの放送UDPパケットはICMP Destination Unreachableデータグラムの洪水の引き金となるかもしれません。 大きいイーサネットでは、結果として起こる衝突は1秒以上間、役に立たなくネットワークを表すことができます。
Every packet that is broadcast on the connected network
should have a valid IP broadcast address as its IP
destination (see Section [5.3.4] and [INTRO:2]). However,
some devices violate this rule. To be certain to detect
broadcast packets, therefore, routers are required to check
接続ネットワークで放送されるあらゆるパケットがIPの目的地として有効なIP放送演説を持っているはずである、(セクションを見てください、[5.3、.4、]、そして、[INTRO: 2。) しかしながら、いくつかのデバイスがこの規則に違反します。 したがって、放送パケットを検出するのに、ルータがチェックするのに必要であることを確信しているように
Almquist & Kastenholz [Page 53] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[53ページ]RFC1716
for a link-layer broadcast as well as an IP-layer address.
リンクレイヤには、IP-層のアドレスと同様に、放送してください。
IMPLEMENTATION:
This requires that the link layer inform the IP layer when a
link-layer broadcast packet has been received; see Section
[3.1].
実装: これは、リンクレイヤが、リンク層ブロードキャストパケットがいつ受け取られたかをIP層に知らせるのを必要とします。 セクション[3.1]を見てください。
4.3.2.8 Rate Limiting
4.3.2.8 レート制限
A router which sends ICMP Source Quench messages MUST be able
to limit the rate at which the messages can be generated. A
router SHOULD also be able to limit the rate at which it sends
other sorts of ICMP error messages (Destination Unreachable,
Redirect, Time Exceeded, Parameter Problem). The rate limit
parameters SHOULD be settable as part of the configuration of
the router. How the limits are applied (e.g., per router or
per interface) is left to the implementor's discretion.
メッセージをICMP Source Quenchに送るルータはメッセージを生成することができるレートを制限できなければなりません。 ルータSHOULD、また、それが他の種類に関するICMPエラーメッセージ(目的地Unreachable、Redirect、Time Exceeded、Parameter Problem)を送るレートを制限できてください。 レートはパラメタSHOULDを制限します。ルータの構成の一部として、「舗装用敷石-可能」であってください。 限界がどう適用されているかは(例えば、ルータかインタフェースあたりの)作成者のものに任せます。
DISCUSSION:
Two problems for a router sending ICMP error message are:
(1) The consumption of bandwidth on the reverse path, and
(2) The use of router resources (e.g., memory, CPU time)
議論: ルータ送付ICMPエラーメッセージのための2つの問題は以下の通りです。 (1) (2) 逆の経路における帯域幅の消費、およびルータリソースの使用(例えば、メモリ、CPU時間)
To help solve these problems a router can limit the
frequency with which it generates ICMP error messages. For
similar reasons, a router may limit the frequency at which
some other sorts of messages, such as ICMP Echo Replies, are
generated.
これらの問題を解決するのを助けるために、ルータはそれがICMPにエラーメッセージを生成する頻度を制限できます。 同様の理由で、ルータはある他の種類のICMP Echo Repliesなどのメッセージが発生している頻度を制限するかもしれません。
IMPLEMENTATION:
Various mechanisms have been used or proposed for limiting
the rate at which ICMP messages are sent:
実装: 様々なメカニズムは、ICMPメッセージが送られるレートを制限するために使用されるか、または提案されました:
(1) Count-based - for example, send an ICMP error message
for every N dropped packets overall or per given source
host. This mechanism might be appropriate for ICMP
Source Quench, but probably not for other types of ICMP
messages.
(1)、カウントベース、--例えば、全体的に見てN下げられたパケット毎か与えられた送信元ホストあたり1つのICMPエラーメッセージを送ってください。 ICMP Source Quenchに、このメカニズムは適切であるかもしれませんが、他のタイプに関するICMPメッセージのためにたぶんそうでない。
(2) Timer-based - for example, send an ICMP error message
to a given source host or overall at most once per T
milliseconds.
(2)、タイマベース、--例えば、全体的に見て高々Tミリセカンドに一度ICMPエラーメッセージを与えられた送信元ホストに送ってください。
(3) Bandwidth-based - for example, limit the rate at which
(3)、帯域幅ベース、--、例えば、レートを制限してくださいどれ
Almquist & Kastenholz [Page 54] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[54ページ]RFC1716
ICMP messages are sent over a particular interface to
some fraction of the attached network's bandwidth.
付属ネットワークの帯域幅のある部分への特定のインタフェースの上にICMPメッセージを送ります。
4.3.3 SPECIFIC ISSUES
4.3.3 特定の問題
4.3.3.1 Destination Unreachable
4.3.3.1 目的地手が届きません。
If a route can not forward a packet because it has no routes at
all to the destination network specified in the packet then the
router MUST generate a Destination Unreachable, Code 0 (Network
Unreachable) ICMP message. If the router does have routes to
the destination network specified in the packet but the TOS
specified for the routes is neither the default TOS (0000) nor
the TOS of the packet that the router is attempting to route,
then the router MUST generate a Destination Unreachable, Code
11 (Network Unreachable for TOS) ICMP message.
パケットで指定された送信先ネットワークにルートを全く持っていないのでルートがパケットを進めることができないなら、ルータはDestination Unreachable(Code0(ネットワークUnreachable)ICMPメッセージ)を生成しなければなりません。 ルートに指定されたTOSがルータがパケットで指定された送信先ネットワークにルートを持っていますが、デフォルトTOS(0000)でなくてまたルータが発送するのを試みているパケットのTOSでないなら、ルータはDestination Unreachable(Code11(TOSのためのネットワークUnreachable)ICMPメッセージ)を生成しなければなりません。
If a packet is to be forwarded to a host on a network that is
directly connected to the router (i.e., the router is the
last-hop router) and the router has ascertained that there is
no path to the destination host then the router MUST generate a
Destination Unreachable, Code 1 (Host Unreachable) ICMP
message. If a packet is to be forwarded to a host that is on a
network that is directly connected to the router and the router
cannot forward the packet because because no route to the
destination has a TOS that is either equal to the TOS requested
in the packet or is the default TOS (0000) then the router MUST
generate a Destination Unreachable, Code 12 (Host Unreachable
for TOS) ICMP message.
パケットが直接ルータに接続されるネットワークでホストに送られることになっていて(すなわち、ルータは最後のホップルータです)、ルータが、あて先ホストへの経路が全くないのを確かめたなら、ルータはDestination Unreachable(Code1(ホストUnreachable)ICMPメッセージ)を生成しなければなりません。 パケットが直接ルータに接続されるネットワークの一員であるホストに送られることになっていて、目的地へのどんなルートにもTOSがないので、それがパケットで要求されたTOSと等しいか、デフォルトTOS(0000)であるのでルータがパケットは送ることができないなら、ルータがDestination Unreachable(Code12(TOSのホストUnreachable)ICMPメッセージ)を生成しなければなりません。
DISCUSSION:
The intent is that a router generates the "generic"
host/network unreachable if it has no path at all (including
default routes) to the destination. If the router has one
or more paths to the destination, but none of those paths
have an acceptable TOS, then the router generates the
"unreachable for TOS" message.
議論: 意図、目的地に経路を全く(デフォルトルートを含んでいる)持っていないなら、ルータが「ジェネリック」ホスト/ネットワークを生成するそのaは手が届きませんか? ルータが1つ以上の経路を目的地に持っていますが、それらの経路のいずれではも許容できるTOSがないなら、ルータは「TOSに手の届かない」メッセージを生成します。
4.3.3.2 Redirect
4.3.3.2 再直接です。
The ICMP Redirect message is generated to inform a host on the
same subnet that the router used by the host to route certain
packets should be changed.
ICMP Redirectメッセージは、同じサブネットに関して、あるパケットを発送するのにホストによって使用されたルータが変えられるべきであることをホストに知らせるために生成されます。
Almquist & Kastenholz [Page 55] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[55ページ]RFC1716
Contrary to section 3.2.2.2 of [INTRO:2], a router MAY ignore
ICMP Redirects when choosing a path for a packet originated by
the router if the router is running a routing protocol or if
forwarding is enabled on the router and on the interface over
which the packet is being sent.
とは逆に、セクション3.2 .2 .2[INTRO: 2]、ルータがルーティング・プロトコルを実行しているならパケットがルータで起因したか、または推進がルータの上と、そして、パケットが送られるインタフェースの上で可能にされるなら経路を選ぶとき、ルータはICMP Redirectsを無視するかもしれません。
4.3.3.3 Source Quench
4.3.3.3 ソース焼き入れ
A router SHOULD NOT originate ICMP Source Quench messages. As
specified in Section [4.3.2], a router which does originate
Source Quench messages MUST be able to limit the rate at which
they are generated.
ルータSHOULD NOTはICMP Source Quenchメッセージを溯源します。 セクションで指定される、[4.3、.2、]、Source Quenchメッセージを溯源するルータはそれらが発生しているレートを制限できなければなりません。
DISCUSSION:
Research seems to suggest that Source Quench consumes
network bandwidth but is an ineffective (and unfair)
antidote to congestion. See, for example, [INTERNET:9] and
[INTERNET:10]. Section [5.3.6] discusses the current
thinking on how routers ought to deal with overload and
network congestion.
議論: 研究は、Source Quenchがネットワーク回線容量を消費するのを示すように思えますが、混雑への効果がなくて(不公平)の解毒剤です。 例えば、[インターネット: 9]と[インターネット: 10]を見てください。 セクション、[5.3 .6は]ルータがどうオーバーロードとネットワークの混雑に対処するべきであるかの現在の考えについて議論します。
A router MAY ignore any ICMP Source Quench messages it
receives.
ルータはそれが受け取るどんなICMP Source Quenchメッセージも無視するかもしれません。
DISCUSSION:
A router itself may receive a Source Quench as the result of
originating a packet sent to another router or host. Such
datagrams might be, e.g., an EGP update sent to another
router, or a telnet stream sent to a host. A mechanism has
been proposed ([INTERNET:11], [INTERNET:12]) to make the IP
layer respond directly to Source Quench by controlling the
rate at which packets are sent, however, this proposal is
currently experimental and not currently recommended.
議論: パケットを溯源するという結果が別のルータかホストに発信したので、ルータ自体はSource Quenchを受けるかもしれません。 そのようなデータグラムはそうです例えばEGPアップデートが別のルータに発信したか、またはtelnet小川がホストに発信しました。 しかしながら、この提案は、メカニズムが提案されて[インターネット: 11]、IP層を直接Source Quenchにどのパケットでレートを制御するかによって応じさせる[インターネット: 12)を送って、現在、実験的であって、現在、お勧めではありません。
4.3.3.4 Time Exceeded
4.3.3.4超えられていた時間
When a router is forwarding a packet and the TTL field of the
packet is reduced to 0, the requirements of section [5.2.3.8]
apply.
ルータがいつパケットを進めているか、そして、パケットのTTL分野は0まで減少します、セクションの要件、[5.2 .3 .8が]適用されます。
When the router is reassembling a packet that is destined for
the router, it MUST fulfill requirements of [INTRO:2], section
[3.3.2] apply.
ルータがルータのために運命づけられているパケットを組み立て直しているとき、[INTRO: 2]の要件を実現させなければなりません、セクション、[3.3、.2、]、適用してください。
When the router receives (i.e., is destined for the router) a
Time Exceeded message, it MUST comply with section 3.2.2.4 of
ルータがTime Exceededメッセージを受け取るとき(すなわち、ルータのために、運命づけられています)、セクション3.2.2に従わなければならない、.4
Almquist & Kastenholz [Page 56] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[56ページ]RFC1716
[INTRO:2].
[序奏: 2]。
4.3.3.5 Parameter Problem
4.3.3.5 パラメタ問題
A router MUST generate a Parameter Problem message for any
error not specifically covered by another ICMP message. The IP
header field or IP option including the byte indicated by the
pointer field MUST be included unchanged in the IP header
returned with this ICMP message. Section [4.3.2] defines an
exception to this requirement.
ルータは別のICMPメッセージで明確にカバーされなかった少しの誤りへのParameter Problemメッセージも生成しなければなりません。 このICMPメッセージと共に返されたIPヘッダーで変わりがない状態で指針分野によって示されたバイトを含むIPヘッダーフィールドかIPオプションを含まなければなりません。 セクション、[4.3に、.2は]この要件への例外を定義します。
A new variant of the Parameter Problem message was defined in
[INTRO:2]:
Code 1 = required option is missing.
Parameter Problemメッセージの新しい変種は[INTRO: 2]で定義されました: 必要なコード1=オプションはなくなっています。
DISCUSSION:
This variant is currently in use in the military community
for a missing security option.
議論: なくなったセキュリティオプションに、この異形は現在、軍事の共同体で使用中です。
4.3.3.6 Echo Request/Reply
4.3.3.6 エコー要求/回答
A router MUST implement an ICMP Echo server function that
receives Echo Requests and sends corresponding Echo Replies. A
router MUST be prepared to receive, reassemble and echo an ICMP
Echo Request datagram at least as large as the maximum of 576
and the MTUs of all the connected networks.
ルータはEcho Requestsを受けて、対応するEcho Repliesを送るICMP Echoサーバ機能を実装しなければなりません。 576の最大とすべての接続ネットワークのMTUsと少なくとも同じくらい大きいICMP Echo Requestデータグラムを受けて、組み立て直して、反響するようにルータを準備しなければなりません。
The Echo server function MAY choose not to respond to ICMP echo
requests addressed to IP broadcast or IP multicast addresses.
Echoサーバ機能は、IP放送かIPマルチキャストアドレスに扱われたICMPエコー要求に応じないのを選ぶかもしれません。
A router SHOULD have a configuration option which, if enabled,
causes the router to silently ignore all ICMP echo requests; if
provided, this option MUST default to allowing responses.
SHOULDが静かに可能にされるならルータを引き起こす設定オプションを持っているルータはすべてのICMPエコー要求を無視します。 提供するなら、このオプションは応答を許容するのをデフォルトとしなければなりません。
DISCUSSION:
The neutral provision about responding to broadcast and
multicast Echo Requests results from the conclusions reached
in section [3.2.2.6] of [INTRO:2].
議論: 結論からの放送する応じるのとマルチキャストEcho Requests結果に関する中立支給にセクションで達した、[3.2 .2 .6[INTRO: 2。]]
As stated in Section [10.3.3], a router MUST also implement an
user/application-layer interface for sending an Echo Request
and receiving an Echo Reply, for diagnostic purposes. All ICMP
Echo Reply messages MUST be passed to this interface.
セクションに述べられている、[10.3、.3、]、ルータは送付のためのユーザ/応用層インターフェースがEcho Requestであると実装して、診断目的のためにEcho Replyをまた受けるのもそうしなければなりません。 すべてのICMP Echo Replyメッセージをこのインタフェースに通過しなければなりません。
The IP source address in an ICMP Echo Reply MUST be the same as
the specific-destination address of the corresponding ICMP Echo
ICMP Echo ReplyのIPソースアドレスは対応するICMP Echoの特定の送付先アドレスと同じであるに違いありません。
Almquist & Kastenholz [Page 57] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[57ページ]RFC1716
Request message.
メッセージを要求してください。
Data received in an ICMP Echo Request MUST be entirely included
in the resulting Echo Reply.
結果として起こるEcho ReplyにICMP Echo Requestに受け取られたデータを完全に含まなければなりません。
If a Record Route and/or Timestamp option is received in an
ICMP Echo Request, this option (these options) SHOULD be
updated to include the current router and included in the IP
header of the Echo Reply message, without truncation. Thus,
the recorded route will be for the entire round trip.
ICMP Echo RequestにRecord Route、そして/または、Timestampオプションを受け取るなら、トランケーションなしで現在のルータを含むようにアップデートして、Echo ReplyメッセージのIPヘッダーに含んでいるこのオプション(これらのオプション)SHOULDです。 したがって、記録されたルートは全体の周遊旅行のためにものになるでしょう。
If a Source Route option is received in an ICMP Echo Request,
the return route MUST be reversed and used as a Source Route
option for the Echo Reply message.
ICMP Echo RequestにSource Routeオプションを受け取るなら、Echo ReplyメッセージにSource Routeオプションとして戻り経路を逆にして、使用しなければなりません。
4.3.3.7 Information Request/Reply
4.3.3.7 情報要求/回答
A router SHOULD NOT originate or respond to these messages.
SHOULD NOTがこれらのメッセージに溯源するか、または反応させるルータ。
DISCUSSION:
The Information Request/Reply pair was intended to support
self-configuring systems such as diskless workstations, to
allow them to discover their IP network numbers at boot
time. However, these messages are now obsolete. The RARP
and BOOTP protocols provide better mechanisms for a host to
discover its own IP address.
議論: 情報Request/回答組は、ディスクレスワークステーションなどの自己設定システムをサポートして、ブート時間における自己のIPネットワーク・ナンバーを発見するのを許容することを意図しました。 しかしながら、これらのメッセージは現在、時代遅れです。 ホストがそれ自身のIPアドレスを発見するように、RARPとBOOTPプロトコルは、より良いメカニズムを提供します。
4.3.3.8 Timestamp and Timestamp Reply
4.3.3.8 タイムスタンプとタイムスタンプ回答
A router MAY implement Timestamp and Timestamp Reply. If they
are implemented then:
ルータはTimestampとTimestamp Replyを実装するかもしれません。 それらがその時実装されるなら:
o The ICMP Timestamp server function MUST return a Timestamp
Reply to every Timestamp message that is received. It
SHOULD be designed for minimum variability in delay.
o ICMP Timestampサーバ機能はあらゆる受信されたTimestampメッセージにTimestamp Replyを返さなければなりません。 それ、SHOULD、遅れにおける最小の可変性には、設計されてください。
o An ICMP Timestamp Request message to an IP broadcast or IP
multicast address MAY be silently discarded.
o IP放送かIPマルチキャストアドレスへのICMP Timestamp Requestメッセージは静かに捨てられるかもしれません。
o The IP source address in an ICMP Timestamp Reply MUST be the
same as the specific-destination address of the
corresponding Timestamp Request message.
o ICMP Timestamp ReplyのIPソースアドレスは対応するTimestamp Requestメッセージの特定の送付先アドレスと同じであるに違いありません。
o If a Source Route option is received in an ICMP Timestamp
Request, the return route MUST be reversed and used as a
Source Route option for the Timestamp Reply message.
o ICMP Timestamp RequestにSource Routeオプションを受け取るなら、Timestamp ReplyメッセージにSource Routeオプションとして戻り経路を逆にして、使用しなければなりません。
Almquist & Kastenholz [Page 58] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[58ページ]RFC1716
o If a Record Route and/or Timestamp option is received in a
Timestamp Request, this (these) option(s) SHOULD be updated
to include the current router and included in the IP header
of the Timestamp Reply message.
o Timestamp RequestにRecord Route、そして/または、Timestampオプションを受け取るなら、現在のルータを含むようにアップデートして、Timestamp ReplyメッセージのIPヘッダーに含んでいるこの(これら)オプションSHOULDです。
o If the router provides an application-layer interface for
sending Timestamp Request messages then incoming Timestamp
Reply messages MUST be passed up to the ICMP user interface.
o ルータが送付Timestamp Requestメッセージに応用層インターフェースを提供するなら、入って来るTimestamp ReplyメッセージをICMPユーザーインタフェースまで通過しなければなりません。
The preferred form for a timestamp value (the standard value)
is milliseconds since midnight, Universal Time. However, it
may be difficult to provide this value with millisecond
resolution. For example, many systems use clocks that update
only at line frequency, 50 or 60 times per second. Therefore,
some latitude is allowed in a standard value:
真夜中、世界標準時以来タイムスタンプ値(基準値)のための好まれた形はミリセカンドです。 しかしながら、ミリセカンド解決をこの値に提供するのは難しいかもしれません。 例えば、多くのシステムがその単に回線周波数でのアップデート、50回か1秒に60回の時計を使用します。 したがって、何らかの緯度が基準値で許容されています:
(a) A standard value MUST be updated at least 16 times per
second (i.e., at most the six low-order bits of the value
may be undefined).
(a) 1秒に少なくとも16回基準値をアップデートしなければなりません(すなわち、高々価値の下位の6ビットは未定義であるかもしれません)。
(b) The accuracy of a standard value MUST approximate that of
operator-set CPU clocks, i.e., correct within a few
minutes.
(b) すなわち、基準値の精度は数分以内に正しい状態でオペレータセットCPU時計のものに近似しなければなりません。
IMPLEMENTATION:
To meet the second condition, a router may need to query
some time server when the router is booted or restarted. It
is recommended that the UDP Time Server Protocol be used for
this purpose. A more advanced implementation would use the
Network Time Protocol (NTP) to achieve nearly millisecond
clock synchronization; however, this is not required.
実装: 第2条件を満たすために、ルータは、ルータがブートされるか、または再開されるとき、何らかの時間サーバについて質問する必要があるかもしれません。 UDP Time Serverプロトコルがこのために使用されるのは、お勧めです。 より高度な実装はほとんどミリセカンド時計同期を達成するのに、Network Timeプロトコル(NTP)を使用するでしょう。 しかしながら、これは必要ではありません。
4.3.3.9 Address Mask Request/Reply
4.3.3.9 アドレスマスク要求/回答
A router MUST implement support for receiving ICMP Address Mask
Request messages and responding with ICMP Address Mask Reply
messages. These messages are defined in [INTERNET:2].
ルータはICMP Address Mask Requestメッセージを受け取って、ICMP Address Mask Replyメッセージで応じるサポートを実装しなければなりません。 これらのメッセージは[インターネット: 2]で定義されます。
A router SHOULD have a configuration option for each logical
interface specifying whether the router is allowed to answer
Address Mask Requests for that interface; this option MUST
default to allowing responses. A router MUST NOT respond to an
Address Mask Request before the router knows the correct subnet
mask.
SHOULDがそれぞれに、論理的な設定オプションに連結させるルータがそのインタフェースにAddress Mask Requestsに答えることができるかどうか指定するルータ。 このオプションは応答を許容するのをデフォルトとしなければなりません。 正しいサブネットマスクを知る前にルータはAddress Mask Requestに応じてはいけません。
A router MUST NOT respond to an Address Mask Request which has
ルータはそうしたAddress Mask Requestに応じてはいけません。
Almquist & Kastenholz [Page 59] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[59ページ]RFC1716
a source address of 0.0.0.0 and which arrives on a physical
interface which has associated with it multiple logical
interfaces and the subnet masks for those interfaces are not
all the same.
aはアドレスの出典を明示します。0.0では、.0、どれが複数の論理的なインタフェースをそれに関連づけた物理インターフェースで到着するか、そして、およびサブネットがそれらのインタフェースにマスクをかける.0はちょうど同じではありません。
A router SHOULD examine all ICMP Address Mask Replies which it
receives to determine whether the information it contains
matches the router's knowledge of the subnet mask. If the ICMP
Address Mask Reply appears to be in error, the router SHOULD
log the subnet mask and the sender's IP address. A router MUST
NOT use the contents of an ICMP Address Mask Reply to determine
the correct subnet mask.
SHOULDがそれが含む情報がサブネットマスクに関するルータの知識に合っているか否かに関係なく、決定するために、それが受けるすべてのICMP Address Mask Repliesを調べるルータ。 ICMP Address Mask Replyが、間違っているように見えるなら、ルータSHOULDはサブネットマスクと送付者のIPアドレスを登録します。 ルータは、正しいサブネットマスクを決定するのにICMP Address Mask Replyのコンテンツを使用してはいけません。
Because hosts may not be able to learn the subnet mask if a
router is down when the host boots up, a router MAY broadcast a
gratuitous ICMP Address Mask Reply on each of its logical
interfaces after it has configured its own subnet masks.
However, this feature can be dangerous in environments which
use variable length subnet masks. Therefore, if this feature
is implemented, gratuitous Address Mask Replies MUST NOT be
broadcast over any logical interface(s) which either:
ホストが起動するとき、ルータが下がっているならホストがサブネットマスクを学ぶことができないかもしれないので、それ自身のサブネットマスクを構成した後に、ルータはそれぞれの論理的なインタフェースの無料のICMP Address Mask Replyを放送するかもしれません。 しかしながら、この特徴は可変長サブネットマスクを使用する環境で危険である場合があります。 したがって、この特徴が実装されるなら、無料のAddress Mask Repliesはどんな論理的なインタフェースにわたってもどれを放送するかことであるはずがありません:
o Are not configured to send gratuitous Address Mask Replies.
Each logical interface MUST have a configuration parameter
controlling this, and that parameter MUST default to not
sending the gratuitous Address Mask Replies.
o 無料のAddress Mask Repliesを送るために、構成されません。 それぞれの論理的なインタフェースには、これを制御する設定パラメータがなければなりません、そして、そのパラメタは無料のAddress Mask Repliesを送らないのをデフォルトとしなければなりません。
o Share the same IP network number and physical interface but
have different subnet masks.
o 同じIPネットワーク・ナンバーと物理インターフェースを共有しなさい、ただし、異なったサブネットマスクを持ってください。
The { <Network-number>, -1, -1 } form (on subnetted networks)
or the { <Network-number>, -1 } form (on non-subnetted
networks) of the IP broadcast address MUST be used for
broadcast Address Mask Replies.
<Network-番号>、-1はIP放送演説を形成します(非サブネット化したネットワークで)。または、<は>にNetwork付番します、-1、-1、形成してください、(サブネット化したネットワークで)放送Address Mask Repliesに使用しなければなりません。
DISCUSSION:
The ability to disable sending Address Mask Replies by
routers is required at a few sites which intentionally lie
to their hosts about the subnet mask. The need for this is
expected to go away as more and more hosts become compliant
with the Host Requirements standards.
議論: ルータで送付がAddress Mask Repliesであると無効にする能力が故意にサブネットマスクに関して彼らのホストに位置するいくつかのサイトで必要です。 ますます多くのホストがHost Requirements規格で言いなりになるようになるのに従ってこの必要性が遠ざかると予想されます。
The reason for both the second bullet above and the
requirement about which IP broadcast address to use is to
prevent problems when multiple IP networks or subnets are in
use on the same physical network.
上記の2番目の弾丸と要件のどのIP放送演説を使用したらよいかに関する両方の理由は複数のIPネットワークかサブネットが同じ物理ネットワークで使用中であるときに、問題を防ぐことです。
Almquist & Kastenholz [Page 60] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[60ページ]RFC1716
4.3.3.10 Router Advertisement and Solicitations
4.3.3.10 ルータ通知と懇願
An IP router MUST support the router part of the ICMP Router
Discovery Protocol [INTERNET:13] on all connected networks on
which the router supports either IP multicast or IP broadcast
addressing. The implementation MUST include all of the
configuration variables specified for routers, with the
specified defaults.
IPルータは、ルータがIPマルチキャストかIPブロードキャスト・アドレッシングのどちらかをサポートするすべての接続ネットワークでルータがICMP Routerディスカバリープロトコル[インターネット: 13]の一部であるとサポートしなければなりません。 実装は指定されたデフォルトでルータに指定された構成変数のすべてを含まなければなりません。
DISCUSSION:
Routers are not required to implement the host part of the
ICMP Router Discovery Protocol, but might find it useful for
operation while IP forwarding is disabled (i.e., when
operating as a host).
議論: ルータによって、ICMP Routerディスカバリープロトコルのホスト部分を実装するのが必要ではありませんが、IP推進は障害がある間(すなわち、ホストとして作動するとき)それが操作の役に立つのがわかるかもしれません。
DISCUSSION:
We note that it is quite common for hosts to use RIP as the
router discovery protocol. Such hosts listen to RIP traffic
and use and use information extracted from that traffic to
discover routers and to make decisions as to which router to
use as a first-hop router for a given destination. While
this behavior is discouraged, it is still common and
implementors should be aware of it.
議論: 私たちは、ホストがルータ発見プロトコルとしてRIPを使用するのが、全く一般であることに注意します。 そのようなホストは、ルータを発見して、与えられた目的地に最初に、ホップルータとしてどのルータを使用したらよいかに関して決定をするのにそのトラフィックから抜粋された情報を、RIPトラフィックを聞いて、使用して、使用します。 この振舞いはお勧めできないのですが、それはまだ一般的です、そして、作成者はそれを意識しているべきです。
4.4 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP
4.4インターネットグループ管理プロトコル--IGMP
IGMP [INTERNET:4] is a protocol used between hosts and multicast routers on a single physical network to establish hosts' membership in particular multicast groups. Multicast routers use this information, in conjunction with a multicast routing protocol, to support IP multicast forwarding across the Internet.
IGMP[インターネット: 4]は特定のマルチキャストグループにホストの会員資格を証明するのにただ一つの物理ネットワークでホストとマルチキャストルータの間で使用されるプロトコルです。 マルチキャストルータは、インターネットの向こう側にIPマルチキャスト推進をサポートするのにマルチキャストルーティング・プロトコルに関連してこの情報を使用します。
A router SHOULD implement the host part of IGMP.
IGMPのホスト部分のルータSHOULD道具。
Almquist & Kastenholz [Page 61] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[61ページ]RFC1716
5. INTERNET LAYER - FORWARDING
5. インターネット層--推進
5.1 INTRODUCTION
5.1 序論
This section describes the process of forwarding packets.
このセクションは推進パケットのプロセスについて説明します。
5.2 FORWARDING WALK-THROUGH
5.2 推進立ち稽古
There is no separate specification of the forwarding function in IP. Instead, forwarding is covered by the protocol specifications for the internet layer protocols ([INTERNET:1], [INTERNET:2], [INTERNET:3], [INTERNET:8], and [ROUTE:11]).
IPには推進機能のどんな別々の仕様もありません。 代わりに、推進はインターネット層のプロトコル[インターネット: 1]、[インターネット: 2]、[インターネット: 3]、[インターネット: 8]、および[ROUTE: 11)のためのプロトコル仕様でカバーされています。
5.2.1 Forwarding Algorithm
5.2.1 推進アルゴリズム
Since none of the primary protocol documents describe the
forwarding algorithm in any detail, we present it here. This is
just a general outline, and omits important details, such as
handling of congestion, that are dealt with in later sections.
プライマリプロトコルドキュメントのいずれもどんな詳細にも推進アルゴリズムを説明しないので、私たちはここにそれを提示します。 これは、ただ概要であり、後のセクションで対処されている混雑の取り扱いの重要な詳細を省略します。
It is not required that an implementation follow exactly the
algorithms given in sections [5.2.1.1], [5.2.1.2], and [5.2.1.3].
Much of the challenge of writing router software is to maximize
the rate at which the router can forward packets while still
achieving the same effect of the algorithm. Details of how to do
that are beyond the scope of this document, in part because they
are heavily dependent on the architecture of the router. Instead,
we merely point out the order dependencies among the steps:
そして、実装が続くのが必要でない、まさにセクションで与えられたアルゴリズム、[5.2 .1 .1、][5.2 .1 .2、][5.2 .1 .3]。 書くことのルータソフトウェアの挑戦の多くはルータがまだアルゴリズムの同じ効果を達成している間にパケットを進めることができるレートを最大にすることです。 どうそれをするかに関する詳細はこのドキュメントの範囲を超えています、それらが一部ずっしりとルータのアーキテクチャに依存しているので。 代わりに、私たちは以下のステップの中で単にオーダーの依存を指摘します:
(1) A router MUST verify the IP header, as described in section
[5.2.2], before performing any actions based on the contents
of the header. This allows the router to detect and discard
bad packets before the expenditure of other resources.
(1) ルータはIPヘッダーについて確かめなければなりません、セクションで説明されるように[5.2、.2、]、働く前に、どんな動作もヘッダーのコンテンツを基礎づけました。 これで、ルータは、他のリソースの費用の前に悪いパケットを検出して、捨てます。
(2) Processing of certain IP options requires that the router
insert its IP address into the option. As noted in Section
[5.2.4], the address inserted MUST be the address of the
logical interface on which the packet is sent or the router's
router-id if the packet is sent over an unnumbered interface.
Thus, processing of these options cannot be completed until
after the output interface is chosen.
(2) あるIPオプションの処理は、ルータがIPアドレスをオプションに挿入するのを必要とします。 セクションで有名である、[5.2、.4、]、無数のインタフェースの上にパケットを送るなら、挿入されたアドレスはパケットが送られる論理的なインタフェースかルータのルータイドのアドレスであるに違いありません。 したがって、出力インタフェースが選ばれた後までこれらのオプションの処理は終了できません。
(3) The router cannot check and decrement the TTL before checking
whether the packet should be delivered to the router itself,
for reasons mentioned in Section [4.2.2.9].
(3) ルータは、パケットがルータ自体に提供されるべきであるかどうかチェックする前にTTLをチェックして、減少させることができません、セクションで言及された理由で[4.2 .2 .9]。
Almquist & Kastenholz [Page 62] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[62ページ]RFC1716
(4) More generally, when a packet is delivered locally to the
router, its IP header MUST NOT be modified in any way (except
that a router may be required to insert a timestamp into any
Timestamp options in the IP header). Thus, before the router
determines whether the packet is to be delivered locally to
the router, it cannot update the IP header in any way that it
is not prepared to undo.
(4) パケットが局所的にルータに提供されるとき、より一般に、何らかの方法でIPヘッダーを変更してはいけません(ルータがIPヘッダーのどんなTimestampオプションにもタイムスタンプを挿入するのに必要であるかもしれない以外に)。 したがって、ルータが、パケットが局所的にルータに提供されることになっているかどうか決定する前にそれは元に戻すように準備されないどんな方法でもIPヘッダーをアップデートできません。
5.2.1.1 General
5.2.1.1 一般
This section covers the general forwarding algorithm. This
algorithm applies to all forms of packets to be forwarded:
unicast, multicast, and broadcast.
このセクションは一般的な推進アルゴリズムをカバーします。 このアルゴリズムは、進められるのにすべての形式のパケットに当てはまります: ユニキャスト、マルチキャスト、および放送。
(1) The router receives the IP packet (plus additional
information about it, as described in Section [3.1]) from
the Link Layer.
(1) ルータはIPパケットを受けます。(セクション[3.1])でLink Layerから説明されるようなそれに関するプラス追加情報。
(2) The router validates the IP header, as described in
Section [5.2.2]. Note that IP reassembly is not done,
except on IP fragments to be queued for local delivery in
step (4).
(2) ルータがセクションで説明されるようにIPヘッダーを有効にする、[5.2 .2]。 IP断片以外に、ステップ(4)における地方の配送のために列に並ばせられるためにIP再アセンブリをしないことに注意してください。
(3) The router performs most of the processing of any IP
options. As described in Section [5.2.4], some IP options
require additional processing after the routing decision
has been made.
(3) ルータはどんなIPオプションの処理の大部分も実行します。 セクションで説明される、[5.2、.4、]、ルーティング決定をした後にいくつかのIPオプションが追加処理を必要とします。
(4) The router examines the destination IP address of the IP
datagram, as described in Section [5.2.3], to determine
how it should continue to process the IP datagram. There
are three possibilities:
(4) ルータはIPデータグラムの送付先IPアドレスを調べます、セクションで説明されるように[5.2、.3、]、それが、どのようにIPデータグラムを処理し続けるべきであるかを決定するために。 3つの可能性があります:
o The IP datagram is destined for the router, and should
be queued for local delivery, doing reassembly if
needed.
o 必要であるなら再アセンブリにして、IPデータグラムは、ルータのために運命づけられていて、地方の配送のために列に並ばせられるべきです。
o The IP datagram is not destined for the router, and
should be queued for forwarding.
o IPデータグラムは、ルータのために運命づけられていなくて、推進のために列に並ばせられるべきです。
o The IP datagram should be queued for forwarding, but (a
copy) must also be queued for local delivery.
o IPデータグラムは推進のために列に並ばせられるべきですが、また、地方の配送のために(コピー)を列に並ばせなければなりません。
Almquist & Kastenholz [Page 63] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[63ページ]RFC1716
5.2.1.2 Unicast
5.2.1.2 ユニキャスト
Since the local delivery case is well-covered by [INTRO:2], the
following assumes that the IP datagram was queued for
forwarding. If the destination is an IP unicast address:
ローカルの配送ケースが[INTRO: 2]でよくカバーされているので、以下は、IPデータグラムが推進のために列に並ばせられたと仮定します。 目的地がIPユニキャストであるなら、以下を扱ってください。
(5) The forwarder determines the next hop IP address for the
packet, usually by looking up the packet's destination in
the router's routing table. This procedure is described
in more detail in Section [5.2.4]. This procedure also
decides which network interface should be used to send the
packet.
(5) 混載業者はパケットのための次のホップIPアドレスを決定します、通常、ルータの経路指定テーブルでパケットの目的地を見上げることによって。 この手順がさらに詳細にセクションで説明される、[5.2 .4]。 また、この手順は、どのネットワーク・インターフェースがパケットを送るのに使用されるべきであるかを決めます。
(6) The forwarder verifies that forwarding the packet is
permitted. The source and destination addresses should be
valid, as described in Section [5.3.7] and Section [5.3.4]
If the router supports administrative constraints on
forwarding, such as those described in Section [5.3.9],
those constraints must be satisfied.
(6) 混載業者は、パケットを進めるのが受入れられることを確かめます。 ソースと送付先アドレスは有効であるべきです、セクションで説明されるように[5.3、.7、]、セクション、[5.3、.4、]、ルータが推進のセクションで説明されたものなどの管理規制をサポートする、[5.3、.9、]、それらの規制を満たさなければなりません。
(7) The forwarder decrements (by at least one) and checks the
packet's TTL, as described in Section [5.3.1].
(7) 混載業者がセクションで説明されるようにパケットのTTLを減少して(少なくとも1時までに)、チェックする、[5.3、.1、]
(8) The forwarder performs any IP option processing that could
not be completed in step 3.
(8) 混載業者はステップ3で終了できなかった少しのIPオプション処理も実行します。
(9) The forwarder performs any necessary IP fragmentation, as
described in Section [4.2.2.7]. Since this step occurs
after outbound interface selection (step 5), all fragments
of the same datagram will be transmitted out the same
interface.
(9) 混載業者がセクションで説明されるようにどんな必要なIP断片化も実行する、[4.2 .2 .7]。 このステップが外国行きのインタフェース選択(ステップ5)の後に起こるので、同じデータグラムのすべての断片は伝えられて、同じくらいが外に連結するということでしょう。
(10) The forwarder determines the Link Layer address of the
packet's next hop. The mechanisms for doing this are Link
Layer-dependent (see chapter 3).
(10) 混載業者はパケットの次のホップのLink Layerアドレスを決定します。 これをするためのメカニズムはLink Layer依存しています(第3章を見てください)。
(11) The forwarder encapsulates the IP datagram (or each of the
fragments thereof) in an appropriate Link Layer frame and
queues it for output on the interface selected in step 5.
(11) 混載業者は、適切なLink LayerフレームでIPデータグラム(または、それのそれぞれの断片)をカプセル化して、出力のためにステップ5で選択されたインタフェースにそれを列に並ばせます。
(12) The forwarder sends an ICMP redirect if necessary, as
described in Section [4.3.3.2].
(12) 混載業者が必要なら、セクションで説明されるように再直接でICMPを送る、[4.3 .3 .2]。
Almquist & Kastenholz [Page 64] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[64ページ]RFC1716
5.2.1.3 Multicast
5.2.1.3 マルチキャスト
If the destination is an IP multicast, the following steps are
taken.
目的地がIPマルチキャストであるなら、以下の方法を取ります。
Note that the main differences between the forwarding of IP
unicasts and the forwarding of IP multicasts are
IPユニキャストの推進とIPマルチキャストの推進の主な違いがそうであることに注意してください。
o IP multicasts are usually forwarded based on both the
datagram's source and destination IP addresses,
o 通常、データグラムのソースと送付先IPアドレスの両方に基づいてIPマルチキャストを進めます。
o IP multicast uses an expanding ring search,
o IPマルチキャストは拡張リング検索を使用します。
o IP multicasts are forwarded as Link Level multicasts, and
o そしてLink LevelマルチキャストとしてIPマルチキャストを進める。
o ICMP errors are never sent in response to IP multicast
datagrams.
o IPマルチキャストデータグラムに対応してICMP誤りを決して送りません。
Note that the forwarding of IP multicasts is still somewhat
experimental. As a result, the algorithm presented below is not
mandatory, and is provided as an example only.
IPマルチキャストの推進がまだいくらか実験的であることに注意してください。 その結果、以下に提示されたアルゴリズムを、義務的でなく、例だけとして提供します。
(5a) Based on the IP source and destination addresses found in
the datagram header, the router determines whether the
datagram has been received on the proper interface for
forwarding. If not, the datagram is dropped silently. The
method for determining the proper receiving interface
depends on the multicast routing algorithm(s) in use. In
one of the simplest algorithms, reverse path forwarding
(RPF), the proper interface is the one that would be used
to forward unicasts back to the datagram source.
(5a)はデータグラムヘッダーで見つけられたアドレスをIPソースと目的地に基礎づけました、と推進のために適切なインタフェースにデータグラムを受け取ったか否かに関係なく、ルータは決定します。 そうでなければ、データグラムは静かに下げられます。 適切な受信インタフェースを決定するためのメソッドは使用中のマルチキャストルーティング・アルゴリズムによります。 最も簡単なアルゴリズムの1つ、逆の経路推進(RPF)では、適切なインタフェースはデータグラムソースにユニキャストを送って戻すのに使用されるものです。
(6a) Based on the IP source and destination addresses found in
the datagram header, the router determines the datagram's
outgoing interfaces. In order to implement IP multicast's
expanding ring search (see [INTERNET:4]) a minimum TTL
value is specified for each outgoing interface. A copy of
the multicast datagram is forwarded out each outgoing
interface whose minimum TTL value is less than or equal to
the TTL value in the datagram header, by separately
applying the remaining steps on each such interface.
(データグラムヘッダーで見つけられたIPソースと送付先アドレスに基づく6a)、ルータはデータグラムの外向的なインタフェースを決定します。 IPマルチキャストの拡張リング検索(見ます[インターネット: 4])が最小のTTLであると実装するために、値はそれぞれの外向的なインタフェースに指定されます。 最小のTTL値がデータグラムヘッダーのTTLより値以下であるそれぞれの外向的なインタフェースからマルチキャストデータグラムのコピーを進めます、別々にそれぞれのそのようなインタフェースにおける残っているステップを適用することによって。
(7a) The router decrements the packet's TTL by one.
(ルータがパケットのTTLを1に減少させる7a)
(8a) The forwarder performs any IP option processing that could
not be completed in step (3).
(混載業者の8a)はステップ(3)で終了できなかった少しのIPオプション処理も実行します。
Almquist & Kastenholz [Page 65] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[65ページ]RFC1716
(9a) The forwarder performs any necessary IP fragmentation, as
described in Section [4.2.2.7].
(混載業者の9a)がセクションで説明されるようにどんな必要なIP断片化も実行する、[4.2 .2 .7]。
(10a) The forwarder determines the Link Layer address to use in
the Link Level encapsulation. The mechanisms for doing
this are Link Layer-dependent. On LANs a Link Level
multicast or broadcast is selected, as an algorithmic
translation of the datagrams' class D destination address.
See the various IP-over-xxx specifications for more
details.
(混載業者の10a)は、Link LayerアドレスがLink Levelでカプセル化を使用することを決定します。 これをするためのメカニズムはLink Layer依存しています。 LANでは、Link Levelマルチキャストか放送が選択されます、データグラムのクラスD送付先アドレスのアルゴリズムの翻訳として。 その他の詳細のための様々なIP過剰xxx仕様を見てください。
(11a) The forwarder encapsulates the packet (or each of the
fragments thereof) in an appropriate Link Layer frame and
queues it for output on the appropriate interface.
(混載業者の11a)は適切なLink Layerフレームでパケット(または、それのそれぞれの断片)をカプセルに入れって、出力のために適切なインタフェースにそれを列に並ばせます。
5.2.2 IP Header Validation
5.2.2 IPヘッダー合法化
Before a router can process any IP packet, it MUST perform a the
following basic validity checks on the packet's IP header to
ensure that the header is meaningful. If the packet fails any of
the following tests, it MUST be silently discarded, and the error
SHOULD be logged.
ルータがどんなIPパケットも処理できる前に、それは、ヘッダーが確実に重要になるようにするためにパケットのIPヘッダーに以下の基本的なバリディティチェックを実行しなければなりません。 パケットが以下のテストのどれかに失敗するなら、それは、静かに捨てられて誤りSHOULDであるに違いありません。登録されます。
(1) The packet length reported by the Link Layer must be large
enough to hold the minimum length legal IP datagram (20
bytes).
(1) Link Layerによって報告されたパケット長は最小の長さの法的なIPデータグラム(20バイト)を持つことができるくらい大きくなければなりません。
(2) The IP checksum must be correct.
(2) IPチェックサムは正しいに違いありません。
(3) The IP version number must be 4. If the version number is
not 4 then the packet may well be another version of IP, such
as ST-II.
(3) IPバージョン番号は4であるに違いありません。 バージョン番号が4でないなら、パケットはたぶんST-IIなどのIPの別のバージョンでしょう。
(4) The IP header length field must be at least 5.
(4) IPヘッダ長分野は少なくとも5であるに違いありません。
(5) The IP total length field must be at least 4 * IP header
length field.
(5) IP全長分野は少なくとも4*IPヘッダ長分野であるに違いありません。
A router MUST NOT have a configuration option which allows
disabling any of these tests.
ルータには、これらのテストのいずれも無効にする設定オプションがあってはいけません。
If the packet passes the second and third tests, the IP header
length field is at least 4, and both the IP total length field and
the packet length reported by the Link Layer are at least 16 then,
despite the above rule, the router MAY respond with an ICMP
Parameter Problem message, whose pointer points at the IP header
length field (if it failed the fourth test) or the IP total length
パケットが2番目と3番目のテストに合格して、IPヘッダ長分野が少なくとも4であり、その時IP全長分野とLink Layerによって報告されたパケット長の両方が少なくとも16であるなら、上の規則にもかかわらず、ルータはICMP Parameter Problemメッセージで応じるかもしれなくて、IPヘッダ長分野(4番目のテストに失敗したなら)かIPの指針ポイントは全長です。
Almquist & Kastenholz [Page 66] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[66ページ]RFC1716
field (if it failed the fifth test). However, it still MUST
discard the packet and still SHOULD log the error.
さばきます(5番目のテストに失敗したなら)。 しかしながら、まだ、パケットを捨てなければなりません、そして、それでも、SHOULDは誤りを登録します。
These rules (and this entire document) apply only to version 4 of
the Internet Protocol. These rules should not be construed as
prohibiting routers from supporting other versions of IP.
Furthermore, if a router can truly classify a packet as being some
other version of IP then it ought not treat that packet as an
error packet within the context of this memo.
これらの規則(そして、この全体のドキュメント)はインターネットプロトコルのバージョン4だけに適用されます。 IPの他のバージョンをサポートするのからルータを禁じるのにこれらの規則を理解するべきではありません。 その上、ルータが本当にその時IPのある他のバージョンであり、分類しないようにパケットを分類できるなら、このメモの文脈の中で誤りパケットとしてそのパケットを扱ってください。
IMPLEMENTATION:
It is desirable for purposes of error reporting, though not
always entirely possible, to determine why a header was
invalid. There are four possible reasons:
実装: それは、ヘッダーがなぜ無効であったかを決定するために誤りが報告する目的のために望ましくて、もっとも、いつも完全に可能であるというわけではありません。 4つの可能な理由があります:
o The Link Layer truncated the IP header
o Link LayerはIPヘッダーに先端を切らせました。
o The datagram is using a version of IP other than the
standard one (version 4).
o データグラムは標準のもの(バージョン4)以外のIPのバージョンを使用しています。
o The IP header has been corrupted in transit.
o IPヘッダーはトランジットで腐敗しています。
o The sender generated an illegal IP header.
o 送付者は不法なIPヘッダーを生成しました。
It is probably desirable to perform the checks in the order
listed, since we believe that this ordering is most likely to
correctly categorize the cause of the error. For purposes of
error reporting, it may also be desirable to check if a packet
which fails these tests has an IP version number equal to 6.
If it does, the packet is probably an ST-II datagram and should
be treated as such. ST-II is described in [FORWARD:1].
私たちが、この注文が正しく誤りの原因を最も分類しそうであると信じているのでリストアップされたオーダーにおけるチェックを実行するのはたぶん望ましいです。 また、誤りが報告する目的のために、これらのテストに失敗するパケットが6と等しいIPバージョン番号を持っているかどうかチェックするのも望ましいかもしれません。 そうするなら、パケットは、たぶんST-IIデータグラムであり、そういうものとして扱われるべきです。 ST-IIは[FORWARD: 1]で説明されます。
Additionally, the router SHOULD verify that the packet length
reported by the Link Layer is at least as large as the IP total
length recorded in the packet's IP header. If it appears that the
packet has been truncated, the packet MUST be discarded, the error
SHOULD be logged, and the router SHOULD respond with an ICMP
Parameter Problem message whose pointer points at the IP total
length field.
さらに、ルータSHOULDは、Link Layerによって報告されたパケット長が全長がパケットのIPヘッダーに記録したIPと少なくとも同じくらい大きいことを確かめます。 パケットによる端が欠けていて、パケットを捨てなければなりません、誤りSHOULDということであったように見えるなら、登録されてください。そうすれば、ルータSHOULDは指針がIP全長分野を指し示すICMP Parameter Problemメッセージで応じます。
DISCUSSION:
Because any higher layer protocol which concerns itself with
data corruption will detect truncation of the packet data when
it reaches its final destination, it is not absolutely
necessary for routers to perform the check suggested above in
order to maintain protocol correctness. However, by making
this check a router can simplify considerably the task of
議論: それが最終的な目的地に達するとデータの汚染に携わるどんなより高い層のプロトコルもパケットデータのトランケーションを検出するので、ルータがプロトコルの正当性を維持するために上に示されたチェックを実行するのは絶対に必要ではありません。 ルータがかなりタスクを単純化できるこのチェックをします。
Almquist & Kastenholz [Page 67] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[67ページ]RFC1716
determining which hop in the path is truncating the packets.
It will also reduce the expenditure of resources down-stream
from the router in that down-stream systems will not need to
deal with the packet.
どれが経路を跳ぶかを決定するのがパケットに先端を切らせています。 また、川下のシステムがパケットに対処する必要はないので、それはルータからリソース川下の費用を下げるでしょう。
Finally, if the destination address in the IP header is not one of
the addresses of the router, the router SHOULD verify that the
packet does not contain a Strict Source and Record Route option.
If a packet fails this test, the router SHOULD log the error and
SHOULD respond with an ICMP Parameter Problem error with the
pointer pointing at the offending packet's IP destination address.
最終的に、IPヘッダーの送付先アドレスがルータのアドレスの1つでないなら、ルータSHOULDは、パケットがStrict SourceとRecord Routeオプションを含まないことを確かめます。 パケットがこのテストに失敗するなら、指針が怒っているパケットの受信者IPアドレスを指し示していて、ルータSHOULDログの誤りとSHOULDはICMP Parameter Problem誤りで応じます。
DISCUSSION:
Some people might suggest that the router should respond with a
Bad Source Route message instead of a Parameter Problem
message. However, when a packet fails this test, it usually
indicates a protocol error by the previous hop router, whereas
Bad Source Route would suggest that the source host had
requested a nonexistent or broken path through the network.
議論: 何人かの人々が、Bad Source RouteメッセージがParameter Problemメッセージの代わりにある状態でルータが応じるべきであると示唆するかもしれません。 しかしながら、パケットがこのテストに失敗すると、前のホップルータで通常プロトコル誤りを示しますが、Bad Source Routeは、送信元ホストがネットワークを通して実在しないか起伏の多い経路を要求したと示唆するでしょう。
5.2.3 Local Delivery Decision
5.2.3 ローカルの配送決定
When a router receives an IP packet, it must decide whether the
packet is addressed to the router (and should be delivered
locally) or the packet is addressed to another system (and should
be handled by the forwarder). There is also a hybrid case, where
certain IP broadcasts and IP multicasts are both delivered locally
and forwarded. A router MUST determine which of the these three
cases applies using the following rules:
ルータがIPパケットを受けるとき、それは、パケットがルータ(そして、局所的に提供されるべきである)に扱われるか、またはパケットが別のシステム(そして、混載業者が扱われるべきである)に扱われるかを決めなければなりません。 また、ハイブリッドケースがあります。そこでは、あるIP放送とIPマルチキャストは、局所的に提供されて、進められます。 ルータがどれを決定しなければならないか、これらの3つのケースが以下の規則を使用することで適用されます:
o An unexpired source route option is one whose pointer value
does not point past the last entry in the source route. If the
packet contains an unexpired source route option, the pointer
in the option is advanced until either the pointer does point
past the last address in the option or else the next address is
not one of the router's own addresses. In the latter (normal)
case, the packet is forwarded (and not delivered locally)
regardless of the rules below.
o 満期になっていない送信元経路オプションはポインタ値が送信元経路における最後のエントリーの先で指さないものです。 パケットが満期になっていない送信元経路オプションを含んでいるなら、オプションにおける指針は指針がオプションにおける最後のアドレスを超えて指すか、次のアドレスがルータの自己のアドレスの1つにならないまで高度です。 後者(正常な)の場合では、規則にかかわらずパケットを以下に送ります(そして、局所的に、配送しません)。
o The packet is delivered locally and not considered for
forwarding in the following cases:
o パケットは、局所的に提供されて、以下の場合における推進のために考えられません:
- The packet's destination address exactly matches one of the
router's IP addresses,
- パケットの送付先アドレスはまさにルータのIPアドレスの1つに合っています。
- The packet's destination address is a limited broadcast
- パケットの送付先アドレスは限られた放送です。
Almquist & Kastenholz [Page 68] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[68ページ]RFC1716
address ({-1, -1}), and
そして(-1、-1)を扱ってください。
- The packet's destination is an IP multicast address which is
limited to a single subnet (such as 224.0.0.1 or 224.0.0.2)
and (at least) one of the logical interfaces associated with
the physical interface on which the packet arrived is a
member of the destination multicast group.
- または、パケットの目的地がただ一つのサブネットに制限されるIPマルチキャストアドレスである、(224.0としてそのような.0、.1、224.0 .0 パケットが到着した物理インターフェースに関連している論理的なインタフェースの.2と)(少なくとも)の1つは目的地マルチキャストグループのメンバーです。
o The packet is passed to the forwarder AND delivered locally in
the following cases:
o パケットは、混載業者に渡されて、以下の場合で局所的に提供されます:
- The packet's destination address is an IP broadcast address
that addresses at least one of the router's logical
interfaces but does not address any of the logical
interfaces associated with the physical interface on which
the packet arrived
- パケットの送付先アドレスは少なくともルータの論理的なインタフェースの1つを扱いますが、パケットが到着した物理インターフェースに関連している論理的なインタフェースのいずれも扱わないIP放送演説です。
- The packet's destination is an IP multicast address which is
not limited to a single subnetwork (such as 224.0.0.1 and
224.0.0.2 are) and (at least) one of the logical interfaces
associated with the physical interface on which the packet
arrived is a member of the destination multicast group.
- パケットの目的地が単一のサブネットワークに制限されないIPマルチキャストアドレスである、(224.0としてそのような.0、.1と224.0、.0、.2がそうである、)、(少なくとも)のパケットが到着した物理インターフェースに関連している論理的なインタフェースの1つは目的地マルチキャストグループのメンバーです。
o The packet is delivered locally if the packet's destination
address is an IP broadcast address (other than a limited
broadcast address) that addresses at least one of the logical
interfaces associated with the physical interface on which the
packet arrived. The packet is ALSO passed to the forwarder
unless the link on which the packet arrived uses an IP
encapsulation that does not encapsulate broadcasts differently
than unicasts (e.g. by using different Link Layer destination
addresses).
o パケットはパケットの送付先アドレスが少なくともパケットが到着した物理インターフェースに関連している論理的なインタフェースの1つを扱うIP放送演説(限られた放送演説を除いた)であるなら局所的に提供されます。 パケットはパケットが到着したリンクがユニキャスト(例えば、異なったLink Layer送付先アドレスを使用するのによる)と異なって放送をカプセル化しないIPカプセル化を使用しない場合混載業者に渡されたALSOです。
o The packet is passed to the forwarder in all other cases.
o パケットは他のすべての場合における混載業者に渡されます。
DISCUSSION:
The purpose of the requirement in the last sentence of the
fourth bullet is to deal with a directed broadcast to another
net or subnet on the same physical cable. Normally, this works
as expected: the sender sends the broadcast to the router as a
Link Layer unicast. The router notes that it arrived as a
unicast, and therefore must be destined for a different logical
net (or subnet) than the sender sent it on. Therefore, the
router can safely send it as a Link Layer broadcast out the
same (physical) interface over which it arrived. However, if
the router can't tell whether the packet was received as a Link
Layer unicast, the sentence ensures that the router does the
議論: 4番目の弾丸に関する最後の文の要件の目的は同じ物理ケーブルの上の別のネットかサブネットに指示された放送に対処することです。 通常、これは予想されるように働いています: 送付者はLink Layerユニキャストとして放送をルータに送ります。 ルータにそれがユニキャストとして到着したことに注意して、したがって、送付者がそれを送ったのと異なった論理的なネット(または、サブネット)のために運命づけなければなりません。 したがって、Link Layerがそれが到着したのと同じ(物理的)のインタフェースから放送したようにルータは安全にそれを送ることができます。 しかしながら、ルータが、パケットがLink Layerユニキャストとして受け取られたかどうかわからないなら、文は、ルータがそうするのを確実にします。
Almquist & Kastenholz [Page 69] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[69ページ]RFC1716
safe but wrong thing rather than the unsafe but right thing.
危険であるのにもかかわらずの、正しいものよりむしろ安全な、しかし、間違ったもの。
IMPLEMENTATION:
As described in Section [5.3.4], packets received as Link Layer
broadcasts are generally not forwarded. It may be advantageous
to avoid passing to the forwarder packets it would later
discard because of the rules in that section.
実現: セクションで説明される、[5.3 Link Layer放送が一般に進められないので、.4、]パケットは受信されました。 それが後でそのセクションの規則のために捨てる混載業者パケットに通るのを避けるのは有利であるかもしれません。
Some Link Layers (either because of the hardware or because of
special code in the drivers) can deliver to the router copies
of all Link Layer broadcasts and multicasts it transmits. Use
of this feature can simplify the implementation of cases where
a packet has to both be passed to the forwarder and delivered
locally, since forwarding the packet will automatically cause
the router to receive a copy of the packet that it can then
deliver locally. One must use care in these circumstances in
order to prevent treating a received loop-back packet as a
normal packet that was received (and then being subject to the
rules of forwarding, etc etc).
いくつかのLink Layers(ハードウェアのためドライバーの特別なコードによる)がすべてのLink Layer放送とそれが伝えるマルチキャストのルータコピーに配送できます。 この特徴の使用はパケットがともに混載業者に渡されて、局所的に果たされなければならないケースの実現を簡素化できます、パケットを進めるのがルータに次にそれが局所的に届けることができるパケットのコピーを自動的に受け取らせるので。 受け取られた正常なパケット(そして、次に、など推進などの規則を条件とした存在)として容認されたループバックパケットを扱うのを防ぐためにこういう事情ですから注意しなければなりません。
Even in the absence of such a Link Layer, it is of course
hardly necessary to make a copy of an entire packet in order to
queue it both for forwarding and for local delivery, though
care must be taken with fragments, since reassembly is
performed on locally delivered packets but not on forwarded
packets. One simple scheme is to associate a flag with each
packet on the router's output queue which indicates whether it
should be queued for local delivery after it has been sent.
そのようなLink Layerがないときでさえ、全体のパケットのコピーを作るのは推進と地方の配送のためにそれを列に並ばせるのにもちろんほとんど必要ではありません、断片で注意しなければなりませんが、局所的に渡されたパケットに実行されますが、再アセンブリが進められたパケットの上で実行されるというわけではないので。 1つの簡単な計画はそれを送った後に地方の配送のためにそれを列に並ばせるべきであるかどうかを示すルータの出力キューの各パケットに旗を関連づけることです。
5.2.4 Determining the Next Hop Address
5.2.4 次のホップアドレスを決定すること。
When a router is going to forward a packet, it must determine
whether it can send it directly to its destination, or whether it
needs to pass it through another router. If the latter, it needs
to determine which router to use. This section explains how these
determinations are made.
ルータがパケットを進めるだろうというとき、それは、直接目的地にそれを送ることができるかどうか、または別のルータにそれを通すのが必要であるかどうか決定しなければなりません。 後者であるなら、それは、どのルータを使用したらよいかを決定する必要があります。 このセクションはどうこれらの決断をするかを説明します。
This section makes use of the following definitions:
このセクションは以下の定義を利用します:
o LSRR - IP Loose Source and Record Route option
o LSRR--IP Loose SourceとRecord Routeオプション
o SSRR - IP Strict Source and Record Route option
o SSRR--IP Strict SourceとRecord Routeオプション
o Source Route Option - an LSRR or an SSRR
o 送信元経路オプション--LSRRかSSRR
o Ultimate Destination Address - where the packet is being sent
o 究極のDestination Address--パケットが送られるところ
Almquist & Kastenholz [Page 70] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[70ページ]RFC1716
to: the last address in the source route of a source-routed
packet, or the destination address in the IP header of a non-
source-routed packet
to: ソースによって発送されたパケットの送信元経路における最後のアドレス、またはソースによって非発送されたパケットのIPヘッダーの送付先アドレス
o Adjacent - reachable without going through any IP routers
o 隣接する--、届く。どんなIPルータにも直面していなくて
o Next Hop Address - the IP address of the adjacent host or
router to which the packet should be sent next
o 次のHop Address--パケットが次に送られるべきである隣接しているホストかルータのIPアドレス
o Immediate Destination Address - the ultimate destination
address, except in source routed packets, where it is the next
address specified in the source route
o 即座のDestination Address--ソースの発送されたパケット以外の最終仕向地アドレス。(そこでは、それが送信元経路で指定された次のアドレスです)。
o Immediate Destination - the node, system, router, end-system,
or whatever that is addressed by the Immediate Destination
Address.
o 即座のDestination--ノード、システム、ルータ、エンドシステム、またはImmediate Destination Addressによって記述されることなら何でも。
5.2.4.1 Immediate Destination Address
5.2.4.1 即座の送付先アドレス
If the destination address in the IP header is one of the
addresses of the router and the packet contains a Source Route
Option, the Immediate Destination Address is the address
pointed at by the pointer in that option if the pointer does
not point past the end of the option. Otherwise, the Immediate
Destination Address is the same as the IP destination address
in the IP header.
IPヘッダーの送付先アドレスがルータのアドレスの1つであり、パケットがSource Route Optionを含んでいるなら、Immediate Destination Addressはポインタがオプションの終わりを過ぎて向けられないならポインタによってそのオプションで指し示されたアドレスです。 さもなければ、Immediate Destination AddressはIPヘッダーで受信者IPアドレスと同じです。
A router MUST use the Immediate Destination Address, not the
Ultimate Destination Address, when determining how to handle a
packet.
パケットを扱う方法を決定するとき、ルータはUltimate Destination Addressではなく、Immediate Destination Addressを使用しなければなりません。
It is an error for more than one source route option to appear
in a datagram. If it receives one, it SHOULD discard the
packet and reply with an ICMP Parameter Problem message whose
pointer points at the beginning of the second source route
option.
それは1つ以上の送信元経路オプションがデータグラムに現れる誤りです。 1を受け取ります、それ。SHOULDはポインタがセカンドソースルートオプションの始まりを指し示すICMP Parameter Problemメッセージでパケットと回答を捨てます。
5.2.4.2 Local/Remote Decision
5.2.4.2 地方の、または、リモートな決定
After it has been determined that the IP packet needs to be
forwarded in accordance with the rules specified in Section
[5.2.3], the following algorithm MUST be used to determine if
the Immediate Destination is directly accessible (see
[INTERNET:2]):
IPパケットが、セクションで指定された規則に従って進められる必要を決定した後、[5.2、.3、]、Immediate Destinationが直接アクセスしやすいかどうか(見てください[インターネット: 2])決定するのに以下のアルゴリズムを使用しなければなりません:
(1) For each network interface that has not been assigned any
IP address (the unnumbered lines as described in Section
少しのIPアドレスも割り当てられていない各ネットワーク・インターフェースへの(1)、(セクションで説明される無数の線
Almquist & Kastenholz [Page 71] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[71ページ]RFC1716
[2.2.7]), compare the router-id of the other end of the
line to the Immediate Destination Address. If they are
exactly equal, the packet can be transmitted through this
interface.
[2.2、.7、)、Immediate Destination Addressの電話の向こう側のルータイドを比較してください。 それらがまさに等しいなら、このインタフェースを通してパケットを伝えることができます。
DISCUSSION:
In other words, the router or host at the remote end of
the line is the destination of the packet or is the
next step in the source route of a source routed
packet.
議論: 言い換えれば、線のリモートエンドにおけるルータかホストが、パケットの目的地であるかソースの発送されたパケットの送信元経路の次のステップです。
(2) If no network interface has been selected in the first
step, for each IP address assigned to the router:
(a) Apply the subnet mask associated with the address to
this IP address.
(2) ネットワーク・インターフェースが全くルータに割り当てられたそれぞれのIPアドレスのために第一歩で選択されていないなら: (a) アドレスに関連しているサブネットマスクをこのIPアドレスに適用してください。
IMPLEMENTATION:
The result of this operation will usually have
been computed and saved during initialization.
実現: 通常、この操作の結果は、初期化の間、計算されて、節約されてしまうでしょう。
(b) Apply the same subnet mask to the Immediate
Destination Address of the packet.
(c) Compare the resulting values. If they are equal to
each other, the packet can be transmitted through the
corresponding network interface.
(b) 同じサブネットマスクをパケットのImmediate Destination Addressに適用してください。 (c) 結果として起こる値を比較してください。 それらが互いと等しいなら、対応するネットワーク・インターフェースを通してパケットを伝えることができます。
(3) If an interface has still not been selected, the Immediate
Destination is accessible only through some other router.
The selection of the router and the next hop IP address is
described in Section [5.2.4.3].
(3) インタフェースがまだ選択されていないなら、Immediate Destinationはある他のルータだけを通してアクセスしやすいです。 ルータの選択と次のホップIPアドレスがセクションで説明される、[5.2 .4 .3]。
5.2.4.3 Next Hop Address
5.2.4.3 次のホップアドレス
EDITOR'S COMMENTS:
Note that this section has been extensively rewritten. The
original document indicated that Phil Almquist wished to
revise this section to conform to his "Ruminations on the
Next Hop" document. I am under the assumption that the
working group generally agreed with this goal; there was an
editor's note from Phil that remained in this document to
that effect, and the RoNH document contains a "mandatory
RRWG algorithm".
エディタのコメント: このセクションが手広く書き直されたことに注意してください。 正本は、フィルAlmquistが彼の「次のホップにおける反芻」ドキュメントに従うためにこのセクションを改訂したがっているのを示しました。 私は一般に、ワーキンググループがこの目標に同意したという仮定でいます。 効果、およびRoNHが「義務的なRRWGアルゴリズム」を含むと記録する本書では残っていたフィルからそれまでの編集者注がありました。
So, I have taken said algorithm from RoNH and moved it into
here.
それで、私は、RoNHから前述のアルゴリズムを取って、それをここに動かしました。
Almquist & Kastenholz [Page 72] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[72ページ]RFC1716
Additional useful or interesting information from RoNH has
been extracted and placed into an appendix to this note.
RoNHからの追加役に立つかおもしろい情報は、この注意への付録に抜粋されて、置かれました。
The router applies the algorithm in the previous section to
determine if the Immediate Destination Address is adjacent. If
so, the next hop address is the same as the Immediate
Destination Address. Otherwise, the packet must be forwarded
through another router to reach its Immediate Destination. The
selection of this router is the topic of this section.
ルータは、Immediate Destination Addressが隣接しているかどうか決定するために前項のアルゴリズムを適用します。 そうだとすれば、次のホップアドレスはImmediate Destination Addressと同じです。 さもなければ、Immediate Destinationに達するように別のルータを通してパケットを進めなければなりません。 このルータの選択はこのセクションの話題です。
If the packet contains an SSRR, the router MUST discard the
packet and reply with an ICMP Bad Source Route error.
Otherwise, the router looks up the Immediate Destination
Address in its routing table to determine an appropriate next
hop address.
パケットがSSRRを含んでいるなら、ルータはICMP Bad Source Route誤りでパケットと回答を捨てなければなりません。 さもなければ、ルータは、次の適切なホップアドレスを決定するために経路指定テーブルでImmediate Destination Addressを見上げます。
DISCUSSION:
Per the IP specification, a Strict Source Route must specify
a sequence of nodes through which the packet must traverse;
the packet must go from one node of the source route to the
next, traversing intermediate networks only. Thus, if the
router is not adjacent to the next step of the source route,
the source route can not be fulfilled. Therefore, the ICMP
Bad Source Route error.
議論: IP仕様に従って、Strict Source Routeはパケットが横断されなければならないノードの系列を指定しなければなりません。 中間ネットワークだけを横断して、パケットは送信元経路の1つのノードから次まで行かなければなりません。 したがって、ルータが送信元経路の次のステップに隣接していないなら、送信元経路が実現できません。 したがって、ICMP Bad Source Route誤り。
The goal of the next-hop selection process is to examine the
entries in the router's Forwarding Information Base (FIB) and
select the best route (if there is one) for the packet from
those available in the FIB.
次のホップ選択の過程の目標は、ルータのForwarding Information基地(FIB)の中でエントリーを調べて、パケットのために、FIBで利用可能なそれらから最も良いルート(1つがあれば)を選択することです。
Conceptually, any route lookup algorithm starts out with a set
of candidate routes which consists of the entire contents of
the FIB. The algorithm consists of a series of steps which
discard routes from the set. These steps are referred to as
Pruning Rules. Normally, when the algorithm terminates there
is exactly one route remaining in the set. If the set ever
becomes empty, the packet is discarded because the destination
is unreachable. It is also possible for the algorithm to
terminate when more than one route remains in the set. In this
case, the router may arbitrarily discard all but one of them,
or may perform "load-splitting" by choosing whichever of the
routes has been least recently used.
概念的に、どんなルートルックアップアルゴリズムもFIBの全体のコンテンツから成る1セットの候補ルートで始めます。 アルゴリズムはセットからルートを捨てる一連のステップから成ります。 これらのステップはPruning Rulesと呼ばれます。 アルゴリズムが終わるとき、通常、セットに残っている1つのルートがまさにあります。 セットが空になるなら、目的地が手が届かないので、パケットは捨てられます。 また、1つ以上のルートがセットに残っているとき、アルゴリズムが終わるのも、可能です。 この場合、ルータは、任意にそれらの1つ以外のすべてを捨てるか、または最も最近でないときにルートで使用された選ぶことで「負荷分かれること」を実行するかもしれません。
With the exception of rule 3 (Weak TOS), a router MUST use the
following Pruning Rules when selecting a next hop for a packet.
If a router does consider TOS when making next-hop decisions,
the Rule 3 must be applied in the order indicated below. These
パケットのために次のホップを選択するとき、規則3(弱いTOS)を除いて、ルータは以下のPruning Rulesを使用しなければなりません。 次のホップ決定をするとき、ルータがTOSを考えるなら、以下の指示された順番でRule3を適用しなければなりません。 これら
Almquist & Kastenholz [Page 73] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[73ページ]RFC1716
rules MUST be (conceptually) applied to the FIB in the order
that they are presented. (For some historical perspective,
additional pruning rules, and other common algorithms in use,
see Appendix E).
(概念的に)それらが提示されるオーダーにおけるFIBに規則を適用しなければなりません。 (何らかの歴史観、追加刈り込み規則、および使用中の他の一般的なアルゴリズムに関して、Appendix Eを見てください。)
DISCUSSION:
Rule 3 is optional in that Section [5.3.2] says that a
router only SHOULD consider TOS when making forwarding
decisions.
議論: 規則3がそのセクションで任意である、[5.3、.2、]、推進を決定にするとき、ルータSHOULDだけがTOSを考えると言います。
(1) Basic Match
This rule discards any routes to destinations other than
the Immediate Destination Address of the packet. For
example, if a packet's Immediate Destination Address is
36.144.2.5, this step would discard a route to net
128.12.0.0 but would retain any routes to net 36.0.0.0,
any routes to subnet 36.144.0.0, and any default routes.
(1) 基本的なMatch This規則はパケットのImmediate Destination Address以外の目的地へのどんなルートも捨てます。 パケットのImmediate Destination Addressが例えば36.144である、.2、.5、このステップがネットにルートを捨てるだろう、128.12、.0、.0、どんなルートもネットに保有するだろう、36.0、.0、.0、サブネットへのどんなルート、も36.144、.0、.0、そして、どんなデフォルトルート。
More precisely, we assume that each route has a
destination attribute, called route.dest, and a
corresponding mask, called route.mask, to specify which
bits of route.dest are significant. The Immediate
Destination Address of the packet being forwarded is
ip.dest. This rule discards all routes from the set of
candidate routes except those for which (route.dest &
route.mask) = (ip.dest & route.mask).
より正確に、私たちは、route.destのどのビットが重要であるかを指定するために各ルートがroute.destと呼ばれる目的地属性とroute.maskと呼ばれる対応するマスクを持っていると思います。 進められるパケットのImmediate Destination Addressはip.destです。 (route.destとroute.mask)が(ip.destとroute.mask)と等しいそれらを除いて、この規則は候補ルートのセットからすべてのルートを捨てます。
(2) Longest Match
Longest Match is a refinement of Basic Match, described
above. After Basic Match pruning is performed, the
remaining routes are examined to determine the maximum
number of bits set in any of their route.mask attributes.
The step then discards from the set of candidate routes
any routes which have fewer than that maximum number of
bits set in their route.mask attributes.
(2) 最も長いMatch Longest Matchは上で説明されたBasic Matchの気品です。 Basic Match刈り込みが実行された後に、残っているルートは、ビットの最大数がそれらのroute.mask属性のどれかでセットしたことを決定するために調べられます。 そして、ステップは候補ルートのセットからその最大数のビットがそれらのroute.mask属性でセットしたほどそうしていないどんなルートも捨てます。
For example, if a packet's Immediate Destination Address
is 36.144.2.5 and there are {route.dest, route.mask}
pairs of {36.144.2.0, 255.255.255.0}, {36.144.0.5,
255.255.0.255}, {36.144.0.0, 255.255.0.0}, and {36.0.0.0,
255.0.0.0}, then this rule would keep only the first two
pairs; {36.144.2.0, 255.255.255.0} and {36.144.0.5,
255.255.0.255}.
For example, if a packet's Immediate Destination Address is 36.144.2.5 and there are {route.dest, route.mask} pairs of {36.144.2.0, 255.255.255.0}, {36.144.0.5, 255.255.0.255}, {36.144.0.0, 255.255.0.0}, and {36.0.0.0, 255.0.0.0}, then this rule would keep only the first two pairs; そして、36.144 .2 .0、255.255、.255、.0、36.144 .0 .5、255.255、.0、.255
Almquist & Kastenholz [Page 74] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[74ページ]RFC1716
(3) Weak TOS
Each route has a type of service attribute, called
route.tos, whose possible values are assumed to be
identical to those used in the TOS field of the IP header.
Routing protocols which distribute TOS information fill in
route.tos appropriately in routes they add to the FIB;
routes from other routing protocols are treated as if they
have the default TOS (0000). The TOS field in the IP
header of the packet being routed is called ip.tos.
(3) 弱いTOS Eachルートには、route.tosと呼ばれる可能な値がIPヘッダーのTOS分野で使用されるものと同じであると思われる一種のサービス属性があります。 TOS情報を分配するルーティング・プロトコルがそれらがFIBに加えるルートに適切にroute.tosに記入します。 まるでそれらにはデフォルトTOS(0000)があるかのように他のルーティング・プロトコルからのルートは扱われます。 発送されるパケットのIPヘッダーのTOS分野はip.tosと呼ばれます。
The set of candidate routes is examined to determine if it
contains any routes for which route.tos = ip.tos. If so,
all routes except those for which route.tos = ip.tos are
discarded. If not, all routes except those for which
route.tos = 0000 are discarded from the set of candidate
routes.
候補ルートのセットは、それが何かroute.tosがip.tosと等しいルートを含むかどうか決定するために調べられます。 そうだとすれば、route.tosがip.tosと等しいそれら以外のすべてのルートが捨てられます。 そうでなければ、route.tosが0000と等しいそれら以外のすべてのルートが候補ルートのセットから捨てられます。
Additional discussion of routing based on Weak TOS may be
found in [ROUTE:11].
Weak TOSに基づくルーティングの追加議論は[ROUTE: 11]で見つけられるかもしれません。
DISCUSSION:
The effect of this rule is to select only those routes
which have a TOS that matches the TOS requested in the
packet. If no such routes exist then routes with the
default TOS are considered. Routes with a non-default
TOS that is not the TOS requested in the packet are
never used, even if such routes are the only available
routes that go to the packet's destination.
議論: この規則の効果はパケットで要求されたTOSに合っているTOSを持っているそれらのルートだけを選択することです。 何かそのようなルートが存在していないなら、デフォルトTOSがあるルートは考えられます。 パケットで要求されたTOSでない非デフォルトTOSがあるルートは決して使用されません、そのようなルートがパケットの目的地に行く唯一の利用可能なルートであっても。
(4) Best Metric
Each route has a metric attribute, called route.metric,
and a routing domain identifier, called route.domain.
Each member of the set of candidate routes is compared
with each other member of the set. If route.domain is
equal for the two routes and route.metric is strictly
inferior for one when compared with the other, then the
one with the inferior metric is discarded from the set.
The determination of inferior is usually by a simple
arithmetic comparison, though some protocols may have
structured metrics requiring more complex comparisons.
(4) route.domainは、Metric Eachが発送するベストがroute.metricと呼ばれるメートル法の属性、および経路ドメイン識別子を持っていると呼びました。 互いと比べて、候補ルートのセットの各メンバーはセットのメンバーです。 2つのルートに、route.domainが等しく、1には、もう片方と比べるとroute.metricが厳密に粗悪であるなら、目下がメートル法であることでのものはセットから捨てられます。 目下の決断が通常簡単な算術比較であります、いくつかのプロトコルが、より複雑な比較を必要とする測定基準を構造化したかもしれませんが。
(5) Vendor Policy
Vendor Policy is sort of a catch-all to make up for the
fact that the previously listed rules are often inadequate
to chose from among the possible routes. Vendor Policy
pruning rules are extremely vendor-specific. See section
[5.2.4.4].
(5) 以前に記載された規則がしばしば不十分である事実が可能なルートから選ばれたので、ベンダーPolicy Vendor Policyはすべて、ちょっと作るキャッチです。 ベンダーPolicy刈り込み規則はベンダー非常に特有です。 セクションを見てください、[5.2 .4 .4]。
Almquist & Kastenholz [Page 75] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[75ページ]RFC1716
This algorithm has two distinct disadvantages. Presumably, a
router implementor might develop techniques to deal with these
disadvantages and make them a part of the Vendor Policy pruning
rule.
このアルゴリズムには、2回の異なった損失があります。 おそらく、ルータ作成者は、これらの損失に対処して、それらをVendor Policy刈り込み規則の一部にするように技術を見いだすかもしれません。
(1) IS-IS and OSPF route classes are not directly handled.
そして、(1)、-、OSPFルートのクラスは直接扱われません。
(2) Path properties other than type of service (e.g. MTU) are
ignored.
(2) サービス(例えば、MTU)のタイプ以外の経路の特性は無視されます。
It is also worth noting a deficiency in the way that TOS is
supported: routing protocols which support TOS are implicitly
preferred when forwarding packets which have non-zero TOS
values.
また、TOSがサポートされる方法で欠乏に注意する価値があります: 非ゼロTOS値を持っているパケットを進めるとき、TOSをサポートするルーティング・プロトコルがそれとなく好まれます。
The Basic Match and Longest Match pruning rules generalize the
treatment of a number of particular types of routes. These
routes are selected in the following, decreasing, order of
preference:
規則を剪定するBasic MatchとLongest Matchは多くの特定のタイプのルートの処理を一般化します。 これらのルートは以下で選択されて、減少しているよく使われる順です:
(1) Host Route: This is a route to a specific end system.
(1) ルートをホスティングしてください: これは特定のエンドシステムへのルートです。
(2) Subnetwork Route: This is a route to a particular subnet
of a network.
(2) サブネットワークルート: これはネットワークの特定のサブネットへのルートです。
(3) Default Subnetwork Route: This is a route to all subnets
of a particular net for which there are not (explicit)
subnet routes.
(3) デフォルトサブネットワークルート: これは(明白)のサブネットルートがない特定のネットのすべてのサブネットへのルートです。
(4) Network Route: This is a route to a particular network.
(4) ルートをネットワークでつないでください: これは特定のネットワークへのルートです。
(5) Default Network Route (also known as the default route):
This is a route to all networks for which there are no
explicit routes to the net or any of its subnets.
(5) デフォルトNetwork Route(また、デフォルトルートとして、知られています): これはルートですネットへのどんな明白なルートもないすべてのネットワークかサブネットのどんなも。
If, after application of the pruning rules, the set of routes
is empty (i.e., no routes were found), the packet MUST be
discarded and an appropriate ICMP error generated (ICMP Bad
Source Route if the Immediate Destination Address came from a
source route option; otherwise, whichever of ICMP Destination
Host Unreachable or Destination Network Unreachable is
appropriate, as described in Section [4.3.3.1]).
ルートのセットが剪定している規則の適用の後に空であるなら(すなわち、ルートは全く見つけられませんでした)、パケットは捨てなければならなくて、適切なICMPは誤り発生しています。(ICMP Bad Source RouteはImmediate Destination Addressであるなら送信元経路オプションから来ました;、さもなければ、ICMP Destination Host UnreachableのどれでもかDestination Network Unreachableが適切です、セクションで説明されるように[4.3 .3 .1)。
Almquist & Kastenholz [Page 76] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[76ページ]RFC1716
5.2.4.4 Administrative Preference
5.2.4.4 管理好み
One suggested mechanism for the Vendor Policy Pruning Rule is
to use administrative preference.
Vendor Policy Pruning Ruleのための1つの提案されたメカニズムは管理好みを使用することです。
Each route has associated with it a preference value, based on
various attributes of the route (specific mechanisms for
assignment of preference values are suggested below). This
preference value is an integer in the range [0..255], with zero
being the most preferred and 254 being the least preferred.
255 is a special value that means that the route should never
be used. The first step in the Vendor Policy pruning rule
discards all but the most preferable routes (and always
discards routes whose preference value is 255).
各ルートは好みの値をそれに関連づけました、ルートの様々な属性に基づいて(好みの値の課題のための特定のメカニズムは以下に示されます)。 この好みの値は範囲[0 .255]の整数です、254が最も都合のよくない状態でゼロが最も都合のよく。 255はルートが決して使用されるべきでないことを意味する特別な値です。 Vendor Policy刈り込み規則による第一歩はほとんど最も望ましいルート(そして、いつも好みの値が255であるルートを捨てる)を捨てます。
This policy is not safe in that it can easily be misused to
create routing loops. Since no protocol ensures that the
preferences configured for a router are consistent with the
preferences configured in its neighbors, network managers must
exercise care in configuring preferences.
この方針は、ルーティング輪を作成するために容易にそれを誤用できるので、安全ではありません。 どんなプロトコルも、ルータのために構成された好みが隣人で構成される好みと一致しているのを確実にしないので、ネットワークマネージャは好みを構成するのに注意を訓練しなければなりません。
o Address Match
It is useful to be able to assign a single preference value
to all routes (learned from the same routing domain) to any
of a specified set of destinations, where the set of
destinations is all destinations that match a specified
address/mask pair.
o アドレスMatch Itは、指定されたセットの目的地のどれかへのすべてのルート(同じ経路ドメインから、学習される)にただ一つの好みの値を割り当てることができるように役に立ちます。そこでは、目的地のセットがすべて指定されたアドレス/マスク組に合っている目的地です。
o Route Class
For routing protocols which maintain the distinction, it is
useful to be able to assign a single preference value to all
routes (learned from the same routing domain) which have a
particular route class (intra-area, inter-area, external
with internal metrics, or external with external metrics).
o 区別を維持するルートClass Forルーティング・プロトコル、特定のルートのクラス(イントラ領域、内部の測定基準による外部の、または、外部の測定基準による外部の相互領域)を持っているすべてのルート(同じ経路ドメインから、学習される)にただ一つの好みの値を割り当てることができるのは役に立ちます。
o Interface
It is useful to be able to assign a single preference value
to all routes (learned from a particular routing domain)
that would cause packets to be routed out a particular
logical interface on the router (logical interfaces
generally map one-to-one onto the router's network
interfaces, except that any network interface which has
multiple IP addresses will have multiple logical interfaces
associated with it).
o インタフェースItは、ルータで特定の論理的なインタフェースからパケットを発送するすべてのルート(特定の経路ドメインから、学習される)にただ一つの好みの値を割り当てることができるように役に立ちます(一般に、論理的なインタフェースが1〜1つをルータのネットワーク・インターフェースに写像します、複数のIPアドレスを持っているどんなネットワーク・インターフェースもそれに関連している複数の論理的なインタフェースを持つのを除いて)。
o Source router
It is useful to be able to assign a single preference value
o ソースルータItは、ただ一つの好みの値を割り当てることができるように役に立ちます。
Almquist & Kastenholz [Page 77] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[77ページ]RFC1716
to all routes (learned from the same routing domain) which
were learned from any of a set of routers, where the set of
routers are those whose updates have a source address which
match a specified address/mask pair.
ルータのセットがソースがアップデートで指定されたアドレス/マスク組にどのマッチに演説するそれらであるルータの1セットのいずれからも学習されたすべてのルート(同じ経路ドメインから、学習される)に。
o Originating AS
For routing protocols which provide the information, it is
useful to be able to assign a single preference value to all
routes (learned from a particular routing domain) which
originated in another particular routing domain. For BGP
routes, the originating AS is the first AS listed in the
route's AS_PATH attribute. For OSPF external routes, the
originating AS may be considered to be the low order 16 bits
of the route's external route tag if the tag's Automatic bit
is set and the tag's PathLength is not equal to 3.
o 情報を提供するAS Forルーティング・プロトコルを溯源して、別の特定の経路ドメインで起こったすべてのルート(特定の経路ドメインから、学習される)にただ一つの好みの値を割り当てることができるのは役に立ちます。 BGPルートに、起因しているASはルートのAS_PATH属性で記載された最初のASです。 OSPF外部経路において、タグのAutomaticビットが設定されて、タグのPathLengthが3と等しくないなら、起因しているASはルートの外部経路の16ビットがタグ付けをする下位であると考えられるかもしれません。
o External route tag
It is useful to be able to assign a single preference value
to all OSPF external routes (learned from the same routing
domain) whose external route tags match any of a list of
specified values. Because the external route tag may
contain a structured value, it may be useful to provide the
ability to match particular subfields of the tag.
o 外部経路タグItは、外部経路タグが規定値のリストのいずれにも合っているすべてのOSPF外部経路(同じ経路ドメインから、学習される)にただ一つの好みの値を割り当てることができるように役に立ちます。 外部経路タグが構造化された値を含むかもしれないので、タグの特定の部分体を合わせる能力を提供するのは役に立つかもしれません。
o AS path
It may be useful to be able to assign a single preference
value to all BGP routes (learned from the same routing
domain) whose AS path "matches" any of a set of specified
values. It is not yet clear exactly what kinds of matches
are most useful. A simple option would be to allow matching
of all routes for which a particular AS number appears (or
alternatively, does not appear) anywhere in the route's
AS_PATH attribute. A more general but somewhat more
difficult alternative would be to allow matching all routes
for which the AS path matches a specified regular
expression.
o AS経路Itは、AS経路が1セットの規定値のいずれにも「合わせている」すべてのBGPルート(同じ経路ドメインから、学習される)にただ一つの好みの値を割り当てることができるように役に立つかもしれません。 どんな種類のマッチが最も役に立つかは、まさにまだ明確ではありません。 または、A簡単なオプションが特定のAS番号が現れるすべてのルートを合わせるのを許容するだろうことである、(代わりに、現れない、)、ルートのAS_PATH属性でどこでも。 より一般的な、しかし、いくらか難しい代替手段はAS経路が指定された正規表現に合っているすべてのルートを合わせるのを許容するだろうことです。
5.2.4.6 Load Splitting
5.2.4.6 負荷の分かれること
At the end of the Next-hop selection process, multiple routes
may still remain. A router has several options when this
occurs. It may arbitrarily discard some of the routes. It may
reduce the number of candidate routes by comparing metrics of
routes from routing domains which are not considered
equivalent. It may retain more than one route and employ a
load-splitting mechanism to divide traffic among them. Perhaps
the only thing that can be said about the relative merits of
Next-ホップ選択プロセスの終わりでは、複数のルートがまだ残っているかもしれません。 ルータには、これが起こると、いくつかのオプションがあります。 それは任意にいくつかのルートを捨てるかもしれません。 それは、同等であることは考えられない経路ドメインからルートの測定基準を比較することによって、候補ルートの数を減少させるかもしれません。 それは、それらの中でトラフィックを分割するのに1つ以上のルートを保有して、負荷が分かれるメカニズムを使うかもしれません。 恐らく優劣に関して言うことができる唯一のこと
Almquist & Kastenholz [Page 78] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[78ページ]RFC1716
the options is that load-splitting is useful in some situations
but not in others, so a wise implementor who implements load-
splitting will also provide a way for the network manager to
disable it.
また、負荷分かれるのがいくつかの状況で役に立つということですが、他のものでオプションがことであるというわけではないので、負荷の分かれることを実装する賢明な作成者はネットワークマネージャがそれを無効にする方法を提供するでしょう。
5.2.5 Unused IP Header Bits: RFC-791 Section 3.1
5.2.5 未使用のIPヘッダービット: RFC-791部3.1
The IP header contains several reserved bits, in the Type of
Service field and in the Flags field. Routers MUST NOT drop
packets merely because one or more of these reserved bits has a
non-zero value.
IPヘッダーはService分野のTypeとFlags分野に予約された数ビットを保管しています。 単にこれらの予約されたビットの1つ以上には非ゼロ値があるので、ルータはパケットを下げてはいけません。
Routers MUST ignore and MUST pass through unchanged the values of
these reserved bits. If a router fragments a packet, it MUST copy
these bits into each fragment.
ルータは、無視しなければならなくて、変わりのないことでこれらの予約されたビットの値を通過しなければなりません。 ルータがパケットを断片化するなら、それは各断片にこれらのビットをコピーしなければなりません。
DISCUSSION:
Future revisions to the IP protocol may make use of these
unused bits. These rules are intended to ensure that these
revisions can be deployed without having to simultaneously
upgrade all routers in the Internet.
議論: IPプロトコルへの今後の改正はこれらの未使用のビットを利用するかもしれません。 これらの規則が、同時にインターネットのすべてのルータをアップグレードさせる必要はなくてこれらの改正を配布することができるのを保証することを意図します。
5.2.6 Fragmentation and Reassembly: RFC-791 Section 3.2
5.2.6 断片化とReassembly: RFC-791部3.2
As was discussed in Section [4.2.2.7], a router MUST support IP
fragmentation.
セクションで議論した、[4.2 .2 .7] ルータはIP断片化をサポートしなければなりません。
A router MUST NOT reassemble any datagram before forwarding it.
それを進める前に、ルータはどんなデータグラムも組み立て直してはいけません。
DISCUSSION:
A few people have suggested that there might be some topologies
where reassembly of transit datagrams by routers might improve
performance. In general, however, the fact that fragments may
take different paths to the destination precludes safe use of
such a feature.
議論: 数人の人々が、いくらかのtopologiesがルータによるトランジットデータグラムの再アセンブリが性能を向上させるかもしれないところにあるかもしれないことを提案しました。 一般に、しかしながら、断片が異なった経路を目的地に取るかもしれないという事実はそのような特徴の安全な使用を排除します。
Nothing in this section should be construed to control or limit
fragmentation or reassembly performed as a link layer function
by the router.
制御するためにこのセクションの何も解釈するべきではありませんでしたか、または限界断片化か再アセンブリがリンクレイヤ機能としてルータで働きました。
Almquist & Kastenholz [Page 79] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[79ページ]RFC1716
5.2.7 Internet Control Message Protocol - ICMP
5.2.7 インターネット・コントロール・メッセージ・プロトコル--ICMP
General requirements for ICMP were discussed in Section [4.3].
This section discusses ICMP messages which are sent only by
routers.
セクション[4.3]でICMPのための一般要件について議論しました。 このセクションはルータだけによって送られるICMPメッセージについて論じます。
5.2.7.1 Destination Unreachable
5.2.7.1 目的地手が届きません。
The ICMP Destination Unreachable message is sent by a router in
response to a packet which it cannot forward because the
destination (or next hop) is unreachable or a service is
unavailable
目的地(または、次のホップ)が手が届かないか、またはサービスが入手できないので、ルータはそれが進めることができないパケットに対応してICMP Destination Unreachableメッセージを送ります。
A router MUST be able to generate ICMP Destination Unreachable
messages and SHOULD choose a response code that most closely
matches the reason why the message is being generated.
ルータはICMP Destination Unreachableにメッセージを生成することができなければなりません、そして、SHOULDは最も密接に、メッセージが生成されている理由に合っている応答コードを選びます。
The following codes are defined in [INTERNET:8] and [INTRO:2]:
以下のコードは[インターネット: 8]と[INTRO: 2]で定義されます:
0 = Network Unreachable - generated by a router if a
forwarding path (route) to the destination network is not
available;
0はネットワークUnreachableと等しいです--ルータで、送信先ネットワークへの推進経路(ルート)が利用可能でないなら、生成されます。
1 = Host Unreachable - generated by a router if a forwarding
path (route) to the destination host on a directly
connected network is not available;
1はホストUnreachableと等しいです--ルータで、直接接続されたネットワークのあて先ホストへの推進経路(ルート)が利用可能でないなら、生成されます。
2 = Protocol Unreachable - generated if the transport protocol
designated in a datagram is not supported in the transport
layer of the final destination;
2はプロトコルUnreachableと等しいです--データグラムで指定されたトランスポート・プロトコルが最終的な目的地のトランスポート層の中でサポートされないなら、生成されます。
3 = Port Unreachable - generated if the designated transport
protocol (e.g. UDP) is unable to demultiplex the datagram
in the transport layer of the final destination but has no
protocol mechanism to inform the sender;
3 = ポートUnreachable--指定されたトランスポート・プロトコル(例えば、UDP)であるなら生成されるのにおいて、輸送におけるデータグラムが層にする最終的な目的地の「反-マルチプレックス」に送付者に知らせるプロトコルメカニズムが全くありません。
4 = Fragmentation Needed and DF Set - generated if a router
needs to fragment a datagram but cannot since the DF flag
is set;
4 データグラムを断片化しますが、DF旗が設定されるので、DF Set--断片化が必要とした=とルータが、必要があるなら生成されるのは断片化できません。
5 = Source Route Failed - generated if a router cannot forward
a packet to the next hop in a source route option;
5はソースRoute Failedと等しいです--ルータが送信元経路オプションで次のホップにパケットを送ることができないなら、生成されます。
6 = Destination Network Unknown - This code SHOULD NOT be
generated since it would imply on the part of the router
that the destination network does not exist (net
unreachable code 0 SHOULD be used in place of code 6);
0SHOULDを手の届かないコードに網で覆ってください。6 =目的地Network Unknown--このコードSHOULD NOT、ルータ側の送信先ネットワークが存在しないのを含意するでしょう、したがって、生成されてください、(コード6)に代わって、使用されてください。
Almquist & Kastenholz [Page 80] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[80ページ]RFC1716
7 = Destination Host Unknown - generated only when a router
can determine (from link layer advice) that the
destination host does not exist;
7は目的地Host Unknownと等しいです--ルータが、あて先ホストが存在しないことを決定できる場合にだけ(リンクレイヤアドバイスから)、生成されます。
11 = Network Unreachable For Type Of Service - generated by a
router if a forwarding path (route) to the destination
network with the requested or default TOS is not
available;
11はネットワークUnreachable For Type Of Serviceと等しいです--ルータで、要求かデフォルトTOSとの送信先ネットワークへの推進経路(ルート)が利用可能でないなら、生成されます。
12 = Host Unreachable For Type Of Service - generated if a
router cannot forward a packet because its route(s) to the
destination do not match either the TOS requested in the
datagram or the default TOS (0).
12はホストUnreachable For Type Of Serviceと等しいです--目的地へのルートがデータグラムで要求されたTOSかデフォルトTOS(0)のどちらかに合っていないのでルータがパケットを進めることができないなら、生成されます。
The following additional codes are hereby defined:
以下の追加コードはこれにより定義されます:
13 = Communication Administratively Prohibited - generated if a
router cannot forward a packet due to administrative
filtering;
13はコミュニケーションAdministratively Prohibitedと等しいです--ルータが管理フィルタリングのためパケットを進めることができないなら、生成されます。
14 = Host Precedence Violation. Sent by the first hop router
to a host to indicate that a requested precedence is not
permitted for the particular combination of
source/destination host or network, upper layer protocol,
and source/destination port;
14はホスト先行違反と等しいです。 最初のホップルータでホストに送って、要求された先行がソース/あて先ホストかネットワーク、上側の層のプロトコル、およびソース/目的地港の特定の組み合わせのために受入れられないのを示します。
15 = Precedence cutoff in effect. The network operators have
imposed a minimum level of precedence required for
operation, the datagram was sent with a precedence below
this level;
事実上、15は先行締切りと等しいです。 ネットワーク・オペレータは操作に必要である最低水準の先行を課して、このレベルの下における先行と共にデータグラムを送りました。
NOTE: [INTRO:2] defined Code 8 for source host isolated.
Routers SHOULD NOT generate Code 8; whichever of Codes 0
(Network Unreachable) and 1 (Host Unreachable) is appropriate
SHOULD be used instead. [INTRO:2] also defined Code 9 for
communication with destination network administratively
prohibited and Code 10 for communication with destination host
administratively prohibited. These codes were intended for use
by end-to-end encryption devices used by U.S military agencies.
Routers SHOULD use the newly defined Code 13 (Communication
Administratively Prohibited) if they administratively filter
packets.
以下に注意してください。 [INTRO: 2]は隔離された送信元ホストのためにCode8を定義しました。 ルータSHOULD NOTはCode8を生成します。 適切なSHOULDはCodes0(ネットワークUnreachable)と1(ホストUnreachable)のどれでもです。代わりに使用されます。 また、[INTRO: 2]は行政上禁止されている送信先ネットワークとあて先ホストとのコミュニケーションのための行政上禁止されているCode10とのコミュニケーションのためにCode9を定義しました。 これらのコードは使用のためにU.のS軍事の代理店によって使用された終端間暗号化デバイスで意図しました。 行政上パケットをフィルターにかけるなら、ルータSHOULDは新たに定義されたCode13(コミュニケーションAdministratively Prohibited)を使用します。
Routers MAY have a configuration option that causes Code 13
(Communication Administratively Prohibited) messages not to be
generated. When this option is enabled, no ICMP error message
is sent in response to a packet which is dropped because its
ルータには、Code13(コミュニケーションAdministratively Prohibited)に生成するべきでないメッセージを引き起こす設定オプションがあるかもしれません。 このオプションを可能にするとき、下げられるパケットに対応してICMPエラーメッセージを全く送らない、それ
Almquist & Kastenholz [Page 81] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[81ページ]RFC1716
forwarding is administratively prohibited.
推進は行政上禁止されています。
Similarly, routers MAY have a configuration option that causes
Code 14 (Host Precedence Violation) and Code 15 (Precedence
Cutoff in Effect) messages not to be generated. When this
option is enabled, no ICMP error message is sent in response to
a packet which is dropped because of a precedence violation.
同様に、ルータには、生成するべきでないCode14(ホストPrecedence Violation)とCode15(Effectの先行Cutoff)メッセージを引き起こす設定オプションがあるかもしれません。 このオプションを可能にするとき、先行違反のために下げられるパケットに対応してICMPエラーメッセージを全く送りません。
Routers MUST use Host Unreachable or Destination Host Unknown
codes whenever other hosts on the same destination network
might be reachable; otherwise, the source host may erroneously
conclude that all hosts on the network are unreachable, and
that may not be the case.
同じ送信先ネットワークの他のホストが届くかもしれないときはいつも、ルータはHost UnreachableかDestination Host Unknownコードを使用しなければなりません。 さもなければ、送信元ホストは、ネットワークのすべてのホストが手が届かないと誤って結論を下すかもしれません、そして、それはそうでないかもしれません。
[INTERNET:14] describes a slight modification the form of
Destination Unreachable messages containing Code 4
(Fragmentation needed and DF set). A router MUST use this
modified form when originating Code 4 Destination Unreachable
messages.
[インターネット: 14] Code4(必要である断片化とDFはセットしました)を含むDestination Unreachableのフォームが通信させるわずかな変更について説明します。 Code4Destination Unreachableメッセージを溯源するとき、ルータはこの変更されたフォームを使用しなければなりません。
5.2.7.2 Redirect
5.2.7.2 再直接です。
The ICMP Redirect message is generated to inform a host on the
same subnet that the router used by the host to route certain
packets should be changed.
ICMP Redirectメッセージは、同じサブネットに関して、あるパケットを発送するのにホストによって使用されたルータが変えられるべきであることをホストに知らせるために生成されます。
Routers MUST NOT generate the Redirect for Network or Redirect
for Network and Type of Service messages (Codes 0 and 2)
specified in [INTERNET:8]. Routers MUST be able to generate
the Redirect for Host message (Code 1) and SHOULD be able to
generate the Redirect for Type of Service and Host message
(Code 3) specified in [INTERNET:8].
ルータは[インターネット: 8]で指定されたServiceメッセージ(コード0と2)のNetworkとTypeのためのNetworkかRedirectのためにRedirectを生成してはいけません。 ルータはHostメッセージ(コード1)とSHOULDのためにRedirectを生成することができるのが、(コード3)が指定したServiceのTypeのためにRedirectを生成することができて、Hostメッセージ[インターネット: 8]であるということであるに違いありません。
DISCUSSION:
If the directly-connected network is not subnetted, a router
can normally generate a network Redirect which applies to
all hosts on a specified remote network. Using a network
rather than a host Redirect may economize slightly on
network traffic and on host routing table storage. However,
the savings are not significant, and subnets create an
ambiguity about the subnet mask to be used to interpret a
network Redirect. In a general subnet environment, it is
difficult to specify precisely the cases in which network
Redirects can be used. Therefore, routers must send only
host (or host and type of service) Redirects.
議論: 直接接続されたネットワークが「副-網で覆」われないなら、通常、ルータは、ネットワークが指定されたリモートネットワークのすべてのホストに適用するRedirectであると生成することができます。 ホストRedirectよりむしろネットワークを使用するのはわずかなネットワークトラフィックとホスト経路指定テーブルストレージのときに締められるかもしれません。 しかしながら、貯蓄は重要ではありません、そして、サブネットはネットワークRedirectを解釈するのに使用されるためにサブネットマスクの周りであいまいさを作成します。 一般的なサブネット環境で、正確にネットワークRedirectsを使用できる場合を指定するのは難しいです。 したがって、ルータはホストだけを送らなければなりません。(サービスのホストとタイプ) 向け直します。
A Code 3 (Redirect for Host and Type of Service) message is
Code3(ServiceのHostとTypeのために、向け直します)メッセージはそうです。
Almquist & Kastenholz [Page 82] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[82ページ]RFC1716
generated when the packet provoking the redirect has a
destination for which the path chosen by the router would
depend (in part) on the TOS requested.
再直接を引き起こすパケットがルータによって選ばれた経路が(一部)要求されたTOSによる目的地を持っていると、生成されます。
Routers which can generate Code 3 redirects (Host and Type of
Service) MUST have a configuration option (which defaults to
on) to enable Code 1 (Host) redirects to be substituted for
Code 3 redirects. A router MUST send a Code 1 Redirect in
place of a Code 3 Redirect if it has been configured to do so.
Code1(ホスト)を可能にするのは、Code3に代入されるのを向け直します。Code3を生成することができるルータが(ServiceのホストとType)を向け直す、設定オプションを持たなければならない、(どれ、デフォルトとするか、オンである、)、向け直します。 それがそうするために構成されたなら、ルータはCode3Redirectに代わって1RedirectをCodeに送らなければなりません。
If a router is not able to generate Code 3 Redirects then it
MUST generate Code 1 Redirects in situations where a Code 3
Redirect is called for.
ルータがCode3Redirectsを生成することができないなら、それはCode3Redirectが求められる状況でCode1Redirectsを生成しなければなりません。
Routers MUST NOT generate a Redirect Message unless all of the
following conditions are met:
以下の条件のすべてが会われない場合、ルータはRedirect Messageを生成してはいけません:
o The packet is being forwarded out the same physical
interface that it was received from,
o それが受け取られたのと同じ出かけている物理インターフェースをパケットに送っています。
o The IP source address in the packet is on the same Logical
IP (sub)network as the next-hop IP address, and
o そしてパケットのIPソースアドレスが次のホップIPアドレスと同じLogical IP(潜水艦)ネットワークにある。
o The packet does not contain an IP source route option.
o パケットはIP送信元経路オプションを含んでいません。
The source address used in the ICMP Redirect MUST belong to the
same logical (sub)net as the destination address.
ICMP Redirectで使用されるソースアドレスは送付先アドレスと同じ論理的な(潜水艦)ネットに属さなければなりません。
A router using a routing protocol (other than static routes)
MUST NOT consider paths learned from ICMP Redirects when
forwarding a packet. If a router is not using a routing
protocol, a router MAY have a configuration which, if set,
allows the router to consider routes learned via ICMP Redirects
when forwarding packets.
ルーティング・プロトコル(スタティックルートを除いた)を使用するルータはパケットを進めるときICMP Redirectsから学習された経路を考えてはいけません。 ルータがルーティング・プロトコルを使用していないなら、ルータには、設定されるならパケットを進めるとき、ルートがICMP Redirectsを通して学んだと考えるためにルータを許容する構成があるかもしれません。
DISCUSSION:
ICMP Redirect is a mechanism for routers to convey routing
information to hosts. Routers use other mechanisms to learn
routing information, and therefore have no reason to obey
redirects. Believing a redirect which contradicted the
router's other information would likely create routing
loops.
議論: ICMP Redirectは情報をホストに発送するルータが伝えるメカニズムです。 ルータはルーティング情報を学ぶのに他のメカニズムを使用します、そして、したがって、従う理由を全く持たないでください。向け直します。 aが再直接であると信じていて、どれがルータの他の情報に矛盾したかがおそらくルーティング輪を作成するでしょう。
On the other hand, when a router is not acting as a router,
it MUST comply with the behavior required of a host.
他方では、ルータがルータとして機能していないとき、それはホストに必要である振舞いに応じなければなりません。
Almquist & Kastenholz [Page 83] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[83ページ]RFC1716
5.2.7.3 Time Exceeded
5.2.7.3超えられていた時間
A router MUST generate a Time Exceeded message Code 0 (In
Transit) when it discards a packet due to an expired TTL field.
A router MAY have a per-interface option to disable origination
of these messages on that interface, but that option MUST
default to allowing the messages to be originated.
満期のTTL分野のためパケットを捨てるとき、ルータは、Time ExceededメッセージがCode0である(Transitの)と生成しなければなりません。 ルータには、そのインタフェースにおけるこれらのメッセージの創作を無効にする1インタフェースあたり1つのオプションがあるかもしれませんが、そのオプションは溯源されるべきメッセージを許容するのをデフォルトとしなければなりません。
5.2.8 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP
5.2.8 インターネットグループ管理プロトコル--IGMP
IGMP [INTERNET:4] is a protocol used between hosts and multicast
routers on a single physical network to establish hosts'
membership in particular multicast groups. Multicast routers use
this information, in conjunction with a multicast routing
protocol, to support IP multicast forwarding across the Internet.
IGMP[インターネット: 4]は特定のマルチキャストグループにホストの会員資格を証明するのにただ一つの物理ネットワークでホストとマルチキャストルータの間で使用されるプロトコルです。 マルチキャストルータは、インターネットの向こう側にIPマルチキャスト推進をサポートするのにマルチキャストルーティング・プロトコルに関連してこの情報を使用します。
A router SHOULD implement the multicast router part of IGMP.
IGMPのマルチキャストルータ部分のルータSHOULD道具。
5.3 SPECIFIC ISSUES
5.3 特定の問題
5.3.1 Time to Live (TTL)
5.3.1生きる時間(TTL)
The Time-to-Live (TTL) field of the IP header is defined to be a
timer limiting the lifetime of a datagram. It is an 8-bit field
and the units are seconds. Each router (or other module) that
handles a packet MUST decrement the TTL by at least one, even if
the elapsed time was much less than a second. Since this is very
often the case, the TTL is effectively a hop count limit on how
far a datagram can propagate through the Internet.
IPヘッダーの生きるTime(TTL)分野は、データグラムの生涯を制限するタイマになるように定義されます。 それは8ビットの分野です、そして、ユニットは秒です。 パケットを扱う各ルータ(または、他のモジュール)はTTLを少なくとも1つ減少させなければなりません、経過時間が2番目よりはるかに少なかったとしても。 頻繁にこれがそうであるので、ケースであり、事実上、TTLは遠くに、データグラムがインターネットを通してどう伝播されることができるかにおけるホップカウント限界です。
When a router forwards a packet, it MUST reduce the TTL by at
least one. If it holds a packet for more than one second, it MAY
decrement the TTL by one for each second.
ルータがパケットを進めるとき、それはTTLを少なくとも1つ減少させなければなりません。 1秒以上間、パケットを維持するなら、それはTTLを各2番目あたり1つ減少させるかもしれません。
If the TTL is reduced to zero (or less), the packet MUST be
discarded, and if the destination is not a multicast address the
router MUST send an ICMP Time Exceeded message, Code 0 (TTL
Exceeded in Transit) message to the source. Note that a router
MUST NOT discard an IP unicast or broadcast packet with a non-zero
TTL merely because it can predict that another router on the path
to the packet's final destination will decrement the TTL to zero.
However, a router MAY do so for IP multicasts, in order to more
efficiently implement IP multicast's expanding ring search
algorithm (see [INTERNET:4]).
TTLがゼロ(それほど)まで減少するなら、パケットを捨てなければなりません、そして、ルータは目的地がマルチキャストアドレスでないならICMP Time Exceededメッセージを送らなければなりません、ソースへのCode0(TransitのTTL Exceeded)メッセージ。 単にパケットの最終的な目的地への経路の別のルータがTTLをゼロまで減少させると予測できるのでルータが非ゼロTTLと共にIPユニキャストか放送パケットを捨ててはいけないことに注意してください。 しかしながら、ルータはIPマルチキャストのためにそうするかもしれません、より効率的にIPマルチキャストの拡張リング検索アルゴリズムを実装するために(見てください[インターネット: 4])。
Almquist & Kastenholz [Page 84] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[84ページ]RFC1716
DISCUSSION:
The IP TTL is used, somewhat schizophrenically, as both a hop
count limit and a time limit. Its hop count function is
critical to ensuring that routing problems can't melt down the
network by causing packets to loop infinitely in the network.
The time limit function is used by transport protocols such as
TCP to ensure reliable data transfer. Many current
implementations treat TTL as a pure hop count, and in parts of
the Internet community there is a strong sentiment that the
time limit function should instead be performed by the
transport protocols that need it.
議論: IP TTLはホップカウント限界とタイムリミットの両方としていくらか分裂病的に使用されます。 パケットがネットワークで無限に輪にされることを引き起こすことによってルーティング問題がネットワークを溶かすことができないのを確実にするのにホップカウント機能は重要です。 時間極限関数はTCPなどのトランスポート・プロトコルによって使用されて、確実な資料転送を確実にします。 多くの現在の実装が純粋なホップカウントとしてTTLを扱います、そして、インターネットコミュニティの部品に、時間極限関数が代わりにそれを必要とするトランスポート・プロトコルによって実行されるべきであるという強気があります。
In this specification, we have reluctantly decided to follow
the strong belief among the router vendors that the time limit
function should be optional. They argued that implementation
of the time limit function is difficult enough that it is
currently not generally done. They further pointed to the lack
of documented cases where this shortcut has caused TCP to
corrupt data (of course, we would expect the problems created
to be rare and difficult to reproduce, so the lack of
documented cases provides little reassurance that there haven't
been a number of undocumented cases).
この仕様では、私たちは、時間極限関数が任意であるべきであるというルータベンダーの中の強い信念に続くといやいやながら決めました。 彼らは、時間極限関数の実装が一般に、現在それをしないほど難しいと主張しました。 彼らはさらにTCPがこの近道でデータを崩壊させた(私たちは、まれであって、難しくなるように生じた問題が再生するとしたがって、記録されたケースの不足がもちろん、ほとんど、多くの正式書類のないケースがなかったという再保証を提供しないと予想するでしょう)記録されたケースの不足を示しました。
IP multicast notions such as the expanding ring search may not
work as expected unless the TTL is treated as a pure hop count.
The same thing is somewhat true of traceroute.
拡張リング検索などのIPマルチキャスト概念はTTLが純粋なホップカウントとして扱われない場合予想されるように働かないかもしれません。 同じものはトレースルートに関していくらか本当です。
ICMP Time Exceeded messages are required because the traceroute
diagnostic tool depends on them.
トレースルート診断用道具がそれらによるので、ICMP Time Exceededメッセージが必要です。
Thus, the tradeoff is between severely crippling, if not
eliminating, two very useful tools vs. a very rare and
transient data transport problem (which may not occur at all).
したがって、厳しく非常にまれで一時的なデータ輸送問題(全く起こらないかもしれない)に対して2つの非常に役に立つツールを無力にするか、または排除するとき、見返りがあります。
5.3.2 Type of Service (TOS)
5.3.2 サービスのタイプ(TOS)
The Type-of-Service byte in the IP header is divided into three
sections: the Precedence field (high-order 3 bits), a field that
is customarily called Type of Service or "TOS (next 4 bits), and a
reserved bit (the low order bit). Rules governing the reserved
bit were described in Section [4.2.2.3]. The Precedence field
will be discussed in Section [5.3.3]. A more extensive discussion
of the TOS field and its use can be found in [ROUTE:11].
IPヘッダーのサービスのTypeバイトは3つのセクションに分割されます: Precedenceは(高位3ビット)(通例にServiceのTypeか「TOS(次の4ビット)、および予約されたビット(下位のビット)」と呼ばれる分野)をさばきます。 予約されたビットを決定する規則がセクションで説明された、[4.2 .2 .3]。 セクションでPrecedence分野について議論する、[5.3 .3]。 [ROUTE: 11]でTOS分野とその使用の、より大規模な議論を見つけることができます。
A router SHOULD consider the TOS field in a packet's IP header
when deciding how to forward it. The remainder of this section
それを進める方法を決めるときSHOULDがパケットのIPヘッダーのTOS分野であると考えるルータ。 このセクションの残り
Almquist & Kastenholz [Page 85] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[85ページ]RFC1716
describes the rules that apply to routers that conform to this
requirement.
この要件に従うルータに適用される規則について説明します。
A router MUST maintain a TOS value for each route in its routing
table. Routes learned via a routing protocol which does not
support TOS MUST be assigned a TOS of zero (the default TOS).
ルータは経路指定テーブルの各ルートにTOS値を維持しなければなりません。 ルートは、ゼロ(デフォルトTOS)のTOSが割り当てられるようにTOS MUSTをサポートしないルーティング・プロトコルで学びました。
To choose a route to a destination, a router MUST use an algorithm
equivalent to the following:
目的地にルートを選ぶために、ルータは以下に同等なアルゴリズムを使用しなければなりません:
(1) The router locates in its routing table all available routes
to the destination (see Section [5.2.4]).
(1) ルータが経路指定テーブルですべての利用可能なルートの目的地に場所を見つける、(セクションを見てください、[5.2、.4、)
(2) If there are none, the router drops the packet because the
destination is unreachable. See section [5.2.4].
(2) なにもなければ、目的地が手が届かないので、ルータはパケットを下げます。 セクションを見てください、[5.2 .4]。
(3) If one or more of those routes have a TOS that exactly
matches the TOS specified in the packet, the router chooses
the route with the best metric.
(3) それらのルートのものか以上にまさにパケットで指定されたTOSに合っているTOSがあるなら、ベストがメートル法でルータはルートを選びます。
(4) Otherwise, the router repeats the above step, except looking
at routes whose TOS is zero.
(4) さもなければ、TOSがゼロであるルートを見るのを除いて、ルータは上のステップを繰り返します。
(5) If no route was chosen above, the router drops the packet
because the destination is unreachable. The router returns
an ICMP Destination Unreachable error specifying the
appropriate code: either Network Unreachable with Type of
Service (code 11) or Host Unreachable with Type of Service
(code 12).
(5) ルートが全く上で選ばれなかったなら、目的地が手が届かないので、ルータはパケットを下げます。 ルータは適切なコードを指定するICMP Destination Unreachable誤りを返します: ServiceのTypeとNetwork Unreachable(コード11)かServiceのTypeとHost Unreachable(コード12)のどちらか。
DISCUSSION:
Although TOS has been little used in the past, its use by hosts
is now mandated by the Requirements for Internet Hosts RFCs
([INTRO:2] and [INTRO:3]). Support for TOS in routers may
become a MUST in the future, but is a SHOULD for now until we
get more experience with it and can better judge both its
benefits and its costs.
議論: TOSは過去に少ししか使用されていませんが、ホストによる使用は現在、インターネットHosts RFCs[INTRO: 2]と[INTRO: 3)のためにRequirementsによって強制されます。 ルータにおけるTOSがaになるかもしれないので、サポートは将来そうしなければなりません、当分間の私たちが、より多くの経験を現代的にならせるまでのSHOULDであり、両方の利益とそのコストを判断するほうがよいことができるのを除いて。
Various people have proposed that TOS should affect other
aspects of the forwarding function. For example:
様々な人々は、TOSが推進機能の他の局面に影響するはずであるよう提案しました。 例えば:
(1) A router could place packets which have the Low Delay bit
set ahead of other packets in its output queues.
(1) ルータは他のパケットの前に出力キューでLow Delayビットを設定するパケットを置くかもしれません。
(2) a router is forced to discard packets, it could try to
avoid discarding those which have the High Reliability bit
set.
(2) ルータはやむを得ずパケットを捨てて、それは、High Reliabilityビットを設定するものを捨てるのを避けようとするかもしれません。
Almquist & Kastenholz [Page 86] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[86ページ]RFC1716
These ideas have been explored in more detail in [INTERNET:17]
but we don't yet have enough experience with such schemes to
make requirements in this area.
これらの考えはさらに詳細に[インターネット: 17]で探られましたが、私たちは、この領域で要件を作るためにそのような体系でまだ十分な経験がありません。
5.3.3 IP Precedence
5.3.3 IP先行
This section specifies requirements and guidelines for appropriate
processing of the IP Precedence field in routers. Precedence is a
scheme for allocating resources in the network based on the
relative importance of different traffic flows. The IP
specification defines specific values to be used in this field for
various types of traffic.
このセクションはルータにおける、IP Precedence分野の適切な処理のための要件とガイドラインを指定します。 先行は異なった交通の流れの相対的な重要性に基づくネットワークでリソースを割り当てるのが体系です。 IP仕様は、様々なタイプのトラフィックにこの分野で使用されるために特定の値を定義します。
The basic mechanisms for precedence processing in a router are
preferential resource allocation, including both precedence-
ordered queue service and precedence-based congestion control, and
selection of Link Layer priority features. The router also
selects the IP precedence for routing, management and control
traffic it originates. For a more extensive discussion of IP
Precedence and its implementation see [FORWARD:6].
ルータにおける先行処理のための基本的機構は優先の資源配分です、先行の命令された待ち行列サービスと先行ベースの輻輳制御とLink Layer優先権機能の品揃えの両方を含んでいて。 また、ルータはそれが溯源するルーティング、管理、およびコントロールトラフィックのためのIP先行を選択します。 IP Precedenceの、より大規模な議論とその実装に関しては、見てください[FORWARD: 6]。
Precedence-ordered queue service, as discussed in this section,
includes but is not limited to the queue for the forwarding
process and queues for outgoing links. It is intended that a
router supporting precedence should also use the precedence
indication at whatever points in its processing are concerned with
allocation of finite resources, such as packet buffers or Link
Layer connections. The set of such points is implementation-
dependent.
このセクションで議論する先行で命令された待ち行列サービスは、出発しているリンクに含みますが、推進プロセスのための待ち行列に制限されないで、列を作ります。 また、先行をサポートするルータが処理で有限な資源の配分に関するどんなポイントでも先行指示を使用するべきであることを意図します、パケットバッファやLink Layer接続のように。 そのようなポイントのセットは実装に依存しています。
DISCUSSION:
Although the Precedence field was originally provided for use
in DOD systems where large traffic surges or major damage to
the network are viewed as inherent threats, it has useful
applications for many non-military IP networks. Although the
traffic handling capacity of networks has grown greatly in
recent years, the traffic generating ability of the users has
also grown, and network overload conditions still occur at
times. Since IP-based routing and management protocols have
become more critical to the successful operation of the
Internet, overloads present two additional risks to the
network:
議論: 元々大きいトラフィック大波かネットワークへの主要な損害が固有の脅威として見なされるDODシステムにおける使用にPrecedence野原を提供しましたが、それには、多くの非軍事のIPネットワークの役に立つアプリケーションがあります。 ネットワークのトラフィック取り扱い容量は大いに近年成長しましたが、また、ユーザの能力を生成するトラフィックは成長しました、そして、ネットワーク過負荷条件は時には、まだ現れています。 IPベースのルーティングと管理プロトコルがインターネットのうまくいっている操作により重要になったので、オーバーロードは2つの追加危険をネットワークに提示します:
(1) High delays may result in routing protocol packets being
lost. This may cause the routing protocol to falsely
deduce a topology change and propagate this false
(1) 高い遅れは失われているルーティング・プロトコルパケットをもたらすかもしれません。 これは、ルーティング・プロトコルが間違ってトポロジー変化を推論して、これを虚偽で伝播することを引き起こすかもしれません。
Almquist & Kastenholz [Page 87] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[87ページ]RFC1716
information to other routers. Not only can this cause
routes to oscillate, but an extra processing burden may be
placed on other routers.
他のルータへの情報。 ルートがこれで振動できるだけではなく、付加的な処理負担は他のルータにかけられるかもしれません。
(2) High delays may interfere with the use of network
management tools to analyze and perhaps correct or relieve
the problem in the network that caused the overload
condition to occur.
(2) 高い遅れは、恐らく起こる過負荷条件を引き起こしたネットワークで、問題を分析するネットワークマネージメントツールの使用を妨げて、修正するか、または救うかもしれません。
Implementation and appropriate use of the Precedence mechanism
alleviates both of these problems.
Precedenceメカニズムの実装と適切な使用はこれらの問題の両方を軽減します。
5.3.3.1 Precedence-Ordered Queue Service
5.3.3.1 先行で命令された待ち行列サービス
Routers SHOULD implement precedence-ordered queue service.
Precedence-ordered queue service means that when a packet is
selected for output on a (logical) link, the packet of highest
precedence that has been queued for that link is sent. Routers
that implement precedence-ordered queue service MUST also have
a configuration option to suppress precedence-ordered queue
service in the Internet Layer.
ルータSHOULDは先行で命令された待ち行列サービスを実装します。 先行で命令された待ち行列サービスは、パケットが出力のために(論理的)のリンクの上に選択されるとき、そのリンクへ列に並ばせられた中で最も高い先行のパケットが送られることを意味します。 また、先行で命令された待ち行列サービスを実装するルータはインターネットLayerで先行で命令された待ち行列サービスを抑圧する設定オプションを持たなければなりません。
Any router MAY implement other policy-based throughput
management procedures that result in other than strict
precedence ordering, but it MUST be configurable to suppress
them (i.e., use strict ordering).
どんなルータも、他の方針ベースのスループットが厳しいのを除いて、先行注文をもたらす管理手順であると実装するかもしれませんが、それらを抑圧するのは構成可能であるに違いありません(すなわち、厳しい注文を使用してください)。
As detailed in Section [5.3.6], routers that implement
precedence-ordered queue service discard low precedence packets
before discarding high precedence packets for congestion
control purposes.
セクションで詳細である、[5.3、.6、]、混雑管理目的のために高い先行パケットを捨てる前に、先行で命令された待ち行列サービスを実装するルータが低い先行パケットを捨てます。
Preemption (interruption of processing or transmission of a
packet) is not envisioned as a function of the Internet Layer.
Some protocols at other layers may provide preemption features.
先取り(処理の中断かパケットのトランスミッション)はインターネットLayerの機能として思い描かれません。 他の層のいくつかのプロトコルが先取り機能を提供するかもしれません。
5.3.3.2 Lower Layer Precedence Mappings
5.3.3.2 下層先行マッピング
Routers that implement precedence-ordered queueing MUST
IMPLEMENT, and other routers SHOULD IMPLEMENT, Lower Layer
Precedence Mapping.
先行で命令された待ち行列MUST IMPLEMENT、および他のルータがSHOULD IMPLEMENT、Lower Layer Precedence Mappingであると実装するルータ。
A router which implements Lower Layer Precedence Mapping:
Lower Layer Precedence Mappingを実装するルータ:
o MUST be able to map IP Precedence to Link Layer priority
mechanisms for link layers that have such a feature defined.
o 特徴が定義したそのようなものを持っているリンクレイヤのためにLink Layer優先権メカニズムにIP Precedenceを写像できなければならなくなってください。
Almquist & Kastenholz [Page 88] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[88ページ]RFC1716
o MUST have a configuration option to select the Link Layer's
default priority treatment for all IP traffic
o すべてのIPトラフィックに関するLink Layerのデフォルト優先権処理を選択する設定オプションを持たなければなりません。
o SHOULD be able to configure specific nonstandard mappings of
IP precedence values to Link Layer priority values for each
interface.
o SHOULD、各インタフェースのためにIP先行値の特定の標準的でないマッピングをLink Layer優先順位の値に構成できてください。
DISCUSSION:
Some research questions the workability of the priority
features of some Link Layer protocols, and some networks may
have faulty implementations of the link layer priority
mechanism. It seems prudent to provide an escape mechanism
in case such problems show up in a network.
議論: 何らかの研究がいくつかのLink Layerプロトコルの優先権機能の加工性に質問して、リンクレイヤ優先権メカニズムの不完全な実装を持っているネットワークもあるかもしれません。 そのような問題がネットワークで現れるといけないので、逃避機制を提供するのは慎重に思えます。
On the other hand, there are proposals to use novel queueing
strategies to implement special services such as low-delay
service. Special services and queueing strategies to
support them need further research and experimentation
before they are put into widespread use in the Internet.
Since these requirements are intended to encourage (but not
force) the use of precedence features in the hope of
providing better Internet service to all users, routers
supporting precedence-ordered queue service should default
to maintaining strict precedence ordering regardless of the
type of service requested.
他方では、低い遅れサービスなどの特殊業務を実装するのに目新しい待ち行列戦略を使用するという提案があります。 インターネットで普及使用にそれらを入れる前にそれらをサポートする特殊業務と待ち行列戦略はさらなる研究と実験を必要とします。 より良いインターネットのサービスをすべてのユーザに提供することを希望してこれらの要件が先行機能の(しかし、力でない)使用を奨励することを意図するので、先行で命令された待ち行列サービスをサポートするルータはサービスのタイプにかかわらず注文が要求した厳しい先行を維持するのをデフォルトとするべきです。
Implementors may wish to consider that correct link layer
mapping of IP precedence is required by DOD policy for
TCP/IP systems used on DOD networks.
作成者は、IP先行の正しいリンクレイヤマッピングがDODネットワークで使用されるTCP/IPシステムのためにDOD方針によって必要とされると考えたがっているかもしれません。
5.3.3.3 Precedence Handling For All Routers
5.3.3.3 すべてのルータのための先行取り扱い
A router (whether or not it employs precedence-ordered queue
service):
ルータ(それが先行で命令された待ち行列サービスを使うか否かに関係なく):
(1) MUST accept and process incoming traffic of all precedence
levels normally, unless it has been administratively
configured to do otherwise.
通常、(1)はすべての先行レベルの入って来るトラフィックを受け入れて、処理しなければなりません、それが別の方法でするために行政上構成されていない場合。
(2) MAY implement a validation filter to administratively
restrict the use of precedence levels by particular
traffic sources. If provided, this filter MUST NOT filter
out or cut off the following sorts of ICMP error messages:
Destination Unreachable, Redirect, Time Exceeded, and
Parameter Problem. If this filter is provided, the
procedures required for packet filtering by addresses are
(2) 行政上特定のトラフィックソースによる先行レベルの使用を制限するために合法化フィルタを実装するかもしれません。 提供するなら、このフィルタは、以下の種類に関するICMPエラーメッセージを無視してはいけませんし、また断ち切ってはいけません: 手の届かなくて、再直接の時間が超えていた目的地、およびパラメタ問題。 このフィルタを提供するなら、パケットフィルタリングのためにアドレスによって必要とされた手順は提供します。
Almquist & Kastenholz [Page 89] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[89ページ]RFC1716
required for this filter also.
このフィルタのためにも、必要です。
DISCUSSION:
Precedence filtering should be applicable to specific
source/destination IP Address pairs, specific
protocols, specific ports, and so on.
議論: 先行フィルタリングは特定のソース/目的地IP Address組、特定のプロトコル、特定のポートなどに適切であるべきです。
An ICMP Destination Unreachable message with code 14
SHOULD be sent when a packet is dropped by the validation
filter, unless this has been suppressed by configuration
choice.
14SHOULDをコード化してください。ICMP Destination Unreachableメッセージ、合法化フィルタでパケットを下げるときには送ってください、これが構成選択で抑圧されていない場合。
(3) MAY implement a cutoff function which allows the router to
be set to refuse or drop traffic with precedence below a
specified level. This function may be activated by
management actions or by some implementation dependent
heuristics, but there MUST be a configuration option to
disable any heuristic mechanism that operates without
human intervention. An ICMP Destination Unreachable
message with code 15 SHOULD be sent when a packet is
dropped by the cutoff function, unless this has been
suppressed by configuration choice.
(3) 指定されたレベルの下における先行に応じて、トラフィックを拒否するか、またはルータが下げるように設定されるのを許容する締切りの機能を実装するかもしれません。 この機能は管理活動か実装に依存するいくつかの発見的教授法で活性化するかもしれませんが、人間の介入なしで動作するどんな発見的なメカニズムも無効にする設定オプションがあるに違いありません。 15SHOULDをコード化してください。ICMP Destination Unreachableメッセージ、締切りの機能でパケットを下げるときには送ってください、これが構成選択で抑圧されていない場合。
A router MUST NOT refuse to forward datagrams with IP
precedence of 6 (Internetwork Control) or 7 (Network
Control) solely due to precedence cutoff. However, other
criteria may be used in conjunction with precedence cutoff
to filter high precedence traffic.
ルータは、唯一先行締切りのため6のIP先行(インターネットワークControl)か7(ネットワークControl)があるデータグラムを進めるのを拒否してはいけません。 しかしながら、他の評価基準は、高い先行トラフィックをフィルターにかけるのに先行締切りに関連して使用されるかもしれません。
DISCUSSION:
Unrestricted precedence cutoff could result in an
unintentional cutoff of routing and control traffic.
In general, host traffic should be restricted to a
value of 5 (CRITIC/ECP) or below although this is not a
requirement and may not be valid in certain systems.
議論: 無制限な先行締切りはルーティングとコントロールトラフィックの意図的でない締切りをもたらすかもしれません。 一般に、これは、要件でなく、またあるシステムで有効でないかもしれませんが、ホストトラフィックは5(CRITIC/ECP)以下の値に制限されるべきです。
(4) MUST NOT change precedence settings on packets it did not
originate.
(4)はそれが溯源しなかったパケットでの先行設定を変えてはいけません。
(5) SHOULD be able to configure distinct precedence values to
be used for each routing or management protocol supported
(except for those protocols, such as OSPF, which specify
which precedence value must be used).
(5) SHOULD、各ルーティングに使用されるべき値か管理プロトコルがサポートした(どの先行値を使用しなければならないかを指定するOSPFなどのそれらのプロトコルを除いて)異なった先行を構成できてください。
(6) MAY be able to configure routing or management traffic
precedence values independently for each peer address.
(6)はそれぞれの同輩アドレスのために独自にルーティングか管理トラフィック先行値を構成できるかもしれません。
Almquist & Kastenholz [Page 90] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[90ページ]RFC1716
(7) MUST respond appropriately to Link Layer precedence-
related error indications where provided. An ICMP
Destination Unreachable message with code 15 SHOULD be
sent when a packet is dropped because a link cannot accept
it due to a precedence-related condition, unless this has
been suppressed by configuration choice.
(7)は提供するところで適切にLink Layer先行関連する誤り指摘に応じなければなりません。 15SHOULDをコード化してください。ICMP Destination Unreachableメッセージ、リンクが先行関連の状態のためそれを受け入れることができないのでパケットを下げるときには送ってください、これが構成選択で抑圧されていない場合。
DISCUSSION:
The precedence cutoff mechanism described in (3) is
somewhat controversial. Depending on the topological
location of the area affected by the cutoff, transit
traffic may be directed by routing protocols into the
area of the cutoff, where it will be dropped. This is
only a problem if another path which is unaffected by
the cutoff exists between the communicating points.
Proposed ways of avoiding this problem include
providing some minimum bandwidth to all precedence
levels even under overload conditions, or propagating
cutoff information in routing protocols. In the
absence of a widely accepted (and implemented) solution
to this problem, great caution is recommended in
activating cutoff mechanisms in transit networks.
議論: (3)で説明された先行締切りのメカニズムはいくらか論議を呼んでいます。 締切りで影響を受ける領域の位相的な位置によって、トランジットトラフィックはルーティング・プロトコルによって締切りの領域に向けられるかもしれません。(そこでは、それが下げられるでしょう)。 別の締切りで影響を受けない経路が交信ポイントの間に存在している場合にだけ、これは問題です。 この問題を避ける提案された方法は、ルーティング・プロトコルに過負荷条件さえのすべての先行レベルにいくらかの最小の帯域幅を供給するか、または締切りの情報を伝播するのを含んでいます。 この問題への広く受け入れられた(そして、実装されます)解決がないとき、十分な注意は輸送網で締切りのメカニズムを動かすことにおいてお勧めです。
A transport layer relay could legitimately provide the
function prohibited by (4) above. Changing precedence
levels may cause subtle interactions with TCP and
perhaps other protocols; a correct design is a non-
trivial task.
トランスポート層リレーは合法的に上で(4)によって禁止された機能を提供するかもしれません。 先行レベルを変えると、TCPとの微妙な相互作用と恐らく他のプロトコルは引き起こされるかもしれません。 正しいデザインは非些細なタスクです。
The intent of (5) and (6) (and the discussion of IP
Precedence in ICMP messages in Section [4.3.2]) is that
the IP precedence bits should be appropriately set,
whether or not this router acts upon those bits in any
other way. We expect that in the future specifications
for routing protocols and network management protocols
will specify how the IP Precedence should be set for
messages sent by those protocols.
それはIP先行ビットです。(5)と(6)の意図、(セクションのICMPメッセージにおける、IP Precedenceの議論、[4.3、.2、)、適切に設定されるべきです、このルータがいかなる他の方法でもそれらのビットに作用するか否かに関係なく。 私たちはルーティング・プロトコルのための将来の仕様でそれを予想します、そして、ネットワーク管理プロトコルはIP Precedenceがどうそれらのプロトコルによって送られたメッセージに用意ができるべきであるかを指定するでしょう。
The appropriate response for (7) depends on the link
layer protocol in use. Typically, the router should
stop trying to send offensive traffic to that
destination for some period of time, and should return
an ICMP Destination Unreachable message with code 15
(service not available for precedence requested) to the
traffic source. It also should not try to reestablish
a preempted Link Layer connection for some period of
time.
(7)のための適切な応答はリンクレイヤプロトコルに使用中によります。 ルータは、通常、いつかの期間の間、不快なトラフィックを送ろうとするのをその目的地に止めるべきであり、コード15(要求された先行に利用可能でないサービス)があるICMP Destination Unreachableメッセージをトラフィックソースに返すべきです。 また、それはいつかの期間の間、先取りされたLink Layer接続を回復させようとするべきではありません。
Almquist & Kastenholz [Page 91] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[91ページ]RFC1716
5.3.4 Forwarding of Link Layer Broadcasts
5.3.4 リンクレイヤ放送の推進
The encapsulation of IP packets in most Link Layer protocols
(except PPP) allows a receiver to distinguish broadcasts and
multicasts from unicasts simply by examining the Link Layer
protocol headers (most commonly, the Link Layer destination
address). The rules in this section which refer to Link Layer
broadcasts apply only to Link Layer protocols which allow
broadcasts to be distinguished; likewise, the rules which refer to
Link Layer multicasts apply only to Link Layer protocols which
allow multicasts to be distinguished.
ほとんどのLink Layerプロトコル(PPPを除いた)のIPパケットのカプセル化で、受信機は、ユニキャストと単にLink Layerプロトコルヘッダー(一般的に、Link Layerの目的地が扱う大部分)を調べることによって、放送とマルチキャストを区別できます。 Link Layer放送について言及するこのセクションの規則は放送が区別されるのを許容するLink Layerプロトコルだけに適用されます。 同様に、Link Layerマルチキャストについて言及する規則はマルチキャストが区別されるのを許容するLink Layerプロトコルだけに適用されます。
A router MUST NOT forward any packet which the router received as
a Link Layer broadcast (even if the IP destination address is also
some form of broadcast address) unless the packet is an all-
subnets-directed broadcast being forwarded as specified in
[INTERNET:3].
ルータはパケットが[インターネット: 3]で指定されるように進められる指示されたオールサブネット放送でないならLink Layerが放送したようにルータが受けたどんなパケットも進めてはいけません(また、受信者IPアドレスが何らかのフォームの放送演説であっても)。
DISCUSSION:
As noted in Section [5.3.5.3], forwarding of all-subnets-
directed broadcasts in accordance with [INTERNET:3] is optional
and is not something that routers do by default.
議論: セクションで有名である、[5.3 .5 .3] [インターネット: 3]に従ったオールサブネットで指示された放送の推進は、任意であり、ルータがデフォルトですることではありません。
A router MUST NOT forward any packet which the router received as
a Link Layer multicast unless the packet's destination address is
an IP multicast address.
ルータはパケットの送付先アドレスがIPマルチキャストアドレスでないならルータがLink Layerマルチキャストとして受けたどんなパケットも進めてはいけません。
A router SHOULD silently discard a packet that is received via a
Link Layer broadcast but does not specify an IP multicast or IP
broadcast destination address.
ルータSHOULDは静かにLink Layer放送で受け取りますが、IPマルチキャストかIPブロードキャストあて先アドレスを指定しないパケットを捨てます。
When a router sends a packet as a Link Layer broadcast, the IP
destination address MUST be a legal IP broadcast or IP multicast
address.
Link Layerが放送したようにルータがパケットを送るとき、受信者IPアドレスは、法的なIP放送かIPマルチキャストアドレスであるに違いありません。
5.3.5 Forwarding of Internet Layer Broadcasts
5.3.5 インターネット層の放送の推進
There are two major types of IP broadcast addresses; limited
broadcast and directed broadcast. In addition, there are three
subtypes of directed broadcast; a broadcast directed to a
specified network, a broadcast directed to a specified subnetwork,
and a broadcast directed to all subnets of a specified network.
Classification by a router of a broadcast into one of these
categories depends on the broadcast address and on the router's
understanding (if any) of the subnet structure of the destination
network. The same broadcast will be classified differently by
different routers.
2つの主要なタイプのIP放送演説があります。 限られた放送と指示された放送。 さらに、指示された放送の3血液型亜型があります。 指定されたネットワークに向けられた放送、指定されたサブネットワークに向けられた放送、および指定されたネットワークのすべてのサブネットに向けられた放送。 放送演説とルータの送信先ネットワークのサブネット構造に関する条件(もしあれば)でこれらのカテゴリの1つへの放送のルータによる分類はよります。 同じ放送は異なったルータによって異なって分類されるでしょう。
Almquist & Kastenholz [Page 92] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[92ページ]RFC1716
A limited IP broadcast address is defined to be all-ones: { -1, -1
} or 255.255.255.255.
限られたIP放送演説はオールものになるように定義されます: または、-1、-1、255.255 .255 .255。
A net-directed broadcast is composed of the network portion of the
IP address with a local part of all-ones, { <Network-number>, -1
}. For example, a Class A net broadcast address is
net.255.255.255, a Class B net broadcast address is
net.net.255.255 and a Class C net broadcast address is
net.net.net.255 where net is a byte of the network address.
ネットに指示された放送はオールものの地方の部分、<Network-番号>、-1でIPアドレスのネットワーク部分から構成されます。 そして、例えば、ClassのAネットの放送演説が網状になることである、.255、.255、.255、ClassのBネットの放送演説がnet.netである、.255、.255、ClassのCのネットの放送演説はネットがネットワーク・アドレスの1バイトであるnet.net.net.255です。
An all-subnets-directed broadcast is composed of the network part
of the IP address with a subnet and a host part of all-ones, {
<Network-number>, -1, -1 }. For example, an all-subnets broadcast
on a subnetted class B network is net.net.255.255. A network must
be known to be subnetted and the subnet part must be all-ones
before a broadcast can be classified as all-subnets-directed.
指示されたオールサブネット放送は<が>にNetwork付番します、-1、-1というサブネットがあるIPアドレスのネットワーク部分とオールもののホスト部分を落ち着かせて、ことです。 例えば、「副-網で覆」われたクラスBネットワークにおけるオールサブネット放送はnet.net.255.255です。 「副-網で覆」われるのをネットワークを知らなければなりません、そして、指示されたオールサブネットとして放送を分類できる前にサブネット部分はオールものであるに違いありません。
A subnet-directed broadcast address is composed of the network and
subnet part of the IP address with a host part of all-ones, {
<Network-number>, <Subnet-number>, -1 }. For example, a subnet-
directed broadcast to subnet 2 of a class B network might be
net.net.2.255 (if the subnet mask was 255.255.255.0) or
net.net.1.127 (if the subnet mask was 255.255.255.128). A network
must be known to be subnetted and the net and subnet part must not
be all-ones before an IP broadcast can be classified as subnet-
directed.
サブネットで指示された放送演説はオールもののホスト部分、<Network-番号>、<Subnet-番号>、-1でIPアドレスのネットワークとサブネット部分から構成されます。 サブネットであるなら、マスクはそうでした。例えば、クラスBネットワークのサブネット2へのサブネットの指示された放送がnet.net.2.255であるかもしれない、(サブネットマスクが255.255の.255の.0か)net.net.1.127であった、(255.255 .255 .128)。 「副-網で覆」われるのをネットワークを知らなければなりません、そして、指示されたサブネットとしてIP放送を分類できる前にネットとサブネット部分はオールものであるはずがありません。
As was described in Section [4.2.3.1], a router may encounter
certain non-standard IP broadcast addresses:
セクションで説明された、[4.2 .3 .1] ルータはある標準的でないIP放送演説に遭遇するかもしれません:
o 0.0.0.0 is an obsolete form of the limited broadcast address
o 0.0.0.0 限られた放送演説が時代遅れのフォームがありますか?
o { broadcast address.
o アドレスを放送してください。
o { broadcast address.
o アドレスを放送してください。
o { form of a subnet-directed broadcast address.
o サブネットで指示された放送演説のフォーム。
As was described in that section, packets addressed to any of
these addresses SHOULD be silently discarded, but if they are not,
they MUST be treated in accordance with the same rules that apply
to packets addressed to the non-obsolete forms of the broadcast
addresses described above. These rules are described in the next
few sections.
それらがそうでないなら、そのセクションで説明されたように、捨てられて、これらのアドレスSHOULDのいずれにも記述されたパケットは静かに説明されましたが、上で説明された放送演説の非時代遅れのフォームに記述されたパケットに適用されるのと同じ規則に従って、それらを扱わなければなりません。 これらの規則は次の数セクションで説明されます。
Almquist & Kastenholz [Page 93] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[93ページ]RFC1716
5.3.5.1 Limited Broadcasts
5.3.5.1 株式会社放送
Limited broadcasts MUST NOT be forwarded. Limited broadcasts
MUST NOT be discarded. Limited broadcasts MAY be sent and
SHOULD be sent instead of directed broadcasts where limited
broadcasts will suffice.
株式会社放送を進めてはいけません。 株式会社放送を捨ててはいけません。 放送が送られるかもしれない株式会社とSHOULD、指示された放送の代わりに、限られた放送が十分であるところで送ってください。
DISCUSSION:
Some routers contain UDP servers which function by resending
the requests (as unicasts or directed broadcasts) to other
servers. This requirement should not be interpreted as
prohibiting such servers. Note, however, that such servers
can easily cause packet looping if misconfigured. Thus,
providers of such servers would probably be well-advised to
document their setup carefully and to consider carefully the
TTL on packets which are sent.
議論: いくつかのルータが要求(ユニキャストか指示された放送としての)を他のサーバに再送することによって機能するUDPサーバを含んでいます。 そのようなサーバを禁止しながら、この要件を解釈するべきではありません。 しかしながら、misconfiguredされるならそのようなサーバが容易にパケットループを引き起こす場合があることに注意してください。 したがって、そのようなサーバのプロバイダーは、慎重に彼らのセットアップを記録して、送られるパケットの上で慎重にTTLを考えるためにたぶん慎重でしょう。
5.3.5.2 Net-directed Broadcasts
5.3.5.2 ネットで指示された放送
A router MUST classify as net-directed broadcasts all valid,
directed broadcasts destined for a remote network or an
attached nonsubnetted network. A router MUST forward net-
directed broadcasts. Net-directed broadcasts MAY be sent.
ルータはネットに指示された放送としてリモートネットワークか付属nonsubnettedネットワークのために運命づけられたすべての有効で、指示された放送を分類しなければなりません。 ルータはネットの指示された放送を進めなければなりません。 ネットで指示された放送を送るかもしれません。
A router MAY have an option to disable receiving net-directed
broadcasts on an interface and MUST have an option to disable
forwarding net-directed broadcasts. These options MUST default
to permit receiving and forwarding net-directed broadcasts.
ルータは、インタフェースでネットに指示された放送を受けて、無効にするオプションを持っているかもしれなくて、ネットに指示された放送を進めて、無効にするオプションを持たなければなりません。 これらのオプションは、ネットに指示された放送を受けて、進めるのを許容するためにデフォルトとしなければなりません。
DISCUSSION:
There has been some debate about forwarding or not
forwarding directed broadcasts. In this memo we have made
the forwarding decision depend on the router's knowledge of
the subnet mask for the destination network. Forwarding
decisions for subnetted networks should be made by routers
with an understanding of the subnet structure. Therefore,
in general, routers must forward directed broadcasts for
networks they are not attached to and for which they do not
understand the subnet structure. One router may interpret
and handle the same IP broadcast packet differently than
another, depending on its own understanding of the structure
of the destination (sub)network.
議論: 推進の何らかの討論があったか、または直接送付しないのは放送されます。 このメモでは、私たちは送信先ネットワークのために推進決定をサブネットマスクに関するルータの知識によらせました。 サブネット化したネットワークのために決定を進めるのはサブネット構造の理解があるルータによって作られるべきです。 したがって、一般に、ルータはそれらが付けられていなくて、また彼らがサブネット構造を理解していないネットワークのために指示された放送を進めなければなりません。 1つのルータが、別のものと異なって同じIP放送パケットを解釈して、扱うかもしれません、それ自身の目的地(潜水艦)ネットワークの構造の理解によって。
Almquist & Kastenholz [Page 94] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[94ページ]RFC1716
5.3.5.3 All-subnets-directed Broadcasts
5.3.5.3 指示されたオールサブネット放送
A router MUST classify as all-subnets-directed broadcasts all
valid directed broadcasts destined for a directly attached
subnetted network which have all-ones in the subnet part of the
address. If the destination network is not subnetted, the
broadcast MUST be treated as a net-directed broadcast.
ルータは指示されたオールサブネット放送として直接付属しているサブネット化したネットワークのために運命づけられたすべての有効な指示された放送を分類しなければなりません(アドレスのサブネット部分のオールものがあります)。 送信先ネットワークが「副-網で覆」われないなら、ネットに指示された放送として放送を扱わなければなりません。
A router MUST forward an all-subnets-directed broadcast as a
link level broadcast out all physical interfaces connected to
the IP network addressed by the broadcast, except that:
すべての物理インターフェースからのリンク・レベル放送が放送で演説されたIPネットワークに接続したそれを除いて、ルータは指示されたオールサブネット放送を進めなければなりません:
o A router MUST NOT forward an all-subnet-directed broadcast
that was received by the router as a Link Layer broadcast,
unless the router is forwarding the broadcast in accordance
with [INTERNET:3] (see below).
o ルータはLink Layer放送としてルータによって受けられた指示されたオールサブネット放送を進めてはいけません、[インターネット: 3]に応じてルータが放送を進めていない場合(以下を見てください)。
o If a router receives an all-subnets-directed broadcast over
a network which does not indicate via Link Layer framing
whether the frame is a broadcast or a unicast, the packet
MUST NOT be forwarded to any network which likewise does not
indicate whether a frame is a broadcast.
o ルータがフレームが放送かそれともユニキャストであるかをLink Layer縁どりで示さないネットワークの上に指示されたオールサブネット放送を受けるなら、フレームが放送であるかどうかを同様に示さないどんなネットワークにもパケットを送ってはいけません。
o A router MUST NOT forward an all-subnets-directed broadcast
if the router is configured not to forward such broadcasts.
A router MUST have a configuration option to deny forwarding
of all-subnets-directed broadcasts. The configuration
option MUST default to permit forwarding of all-subnets-
directed broadcasts.
o ルータがそのような放送を進めないように構成されるなら、ルータは指示されたオールサブネット放送を進めてはいけません。 ルータには、指示されたオールサブネットの推進が放送されることを否定する設定オプションがなければなりません。 設定オプションはオールサブネットで指示された放送の許可証推進をデフォルトとしなければなりません。
EDITOR'S COMMENTS:
The algorithm presented here is broken. The working group
explicitly desired this algorithm, knowing its failures.
エディタのコメント: ここに提示されたアルゴリズムは壊れています。 失敗を知っていて、ワーキンググループは明らかにこのアルゴリズムを望んでいました。
The second bullet, above, prevents All Subnets Directed
Broadcasts from traversing more than one PPP (or other
serial) link in a row. Such a topology is easily conceived.
Suppose that some corporation builds its corporate backbone
out of PPP links, connecting routers at geographically
dispersed locations. Suppose that this corporation has 3
sites (S1, S2, and S3) and there is a router at each site
(R1, R2, and R3). At each site there are also several LANs
connected to the local router. Let there be a PPP link
connecting S1 to S2 and one connecting S2 to S3 (i.e. the
links are R1-R2 and R2-R3). So, if a host on a LAN at S1
sends a All Subnets Directed Broadcast, R1 will forward the
broadcast over the R1-R2 link to R2. R2 will forward the
2番目の弾丸は、上でAll Subnets Directed Broadcastsが1個以上のPPP(または、他のシリーズ)リンクを並んで横断するのを防ぎます。 そのようなトポロジーは容易に発想されます。 地理的に分散している位置でルータを接続して、ある会社がPPPリンクから法人の背骨を造ると仮定してください。 この会社には3つのサイト(S1、S2、およびS3)があって、ルータが各サイト(R1、R2、およびR3)にあると仮定してください。 また、各サイトに、ローカルルータに接続されたいくつかのLANがあります。 そこでは、S1をS2に接続するPPPリンクと1つが接続S2であったならS3(すなわち、リンクは、R1-R2とR2-R3である)にさせます。 それで、S1のLANのホストがAll Subnets Directed Broadcastを送ると、R1はR2へのR1-R2リンクの上に放送を送るでしょう。 R2は進めるでしょう。
Almquist & Kastenholz [Page 95] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[95ページ]RFC1716
broadcast to the LAN(s) connected to R2. Since the PPP does
not differentiate broadcast from non-broadcast frames, R2
will NOT forward the broadcast onto the R2-R3 link.
Therefore, the broadcast will not reach S3.
R2に接続されたLANに放送してください。 PPPが非放送フレームと放送を区別しないので、R2はR2-R3リンクに放送を送らないでしょう。 したがって、放送はS3に達しないでしょう。
[INTERNET:3] describes an alternative set of rules for
forwarding of all-subnets-directed broadcasts (called multi-
subnet-broadcasts in that document). A router MAY IMPLEMENT
that alternative set of rules, but MUST use the set of rules
described above unless explicitly configured to use the
[INTERNET:3] rules. If routers will do [INTERNET:3]-style
forwarding, then the router MUST have a configuration option
which MUST default to doing the rules presented in this
document.
[インターネット: 3] 指示されたオールサブネット放送(そのドキュメントにおけるマルチサブネットの放送と呼ばれる)の推進のための代替のセットの規則について説明します。 代替手段がセットしたルータMAY IMPLEMENTは統治しますが、[インターネット: 3]規則を使用するために明らかに構成されない場合上で説明された規則のセットを使用しなければなりません。 ルータがスタイル推進をするなら[インターネット: 3]、ルータには、本書では提示された規則をするのをデフォルトとしなければならない設定オプションがなければなりません。
DISCUSSION:
As far as we know, the rules for multi-subnet broadcasts
described in [INTERNET:3] have never been implemented,
suggesting that either they are too complex or the utility
of multi-subnet broadcasts is low. The rules described in
this section match current practice. In the future, we
expect that IP multicast (see [INTERNET:4]) will be used to
better solve the sorts of problems that multi-subnets
broadcasts were intended to address.
議論: 私たちが知っている限り、[インターネット: 3]で説明されたマルチサブネット放送のための規則は一度も実行されたことがありません、それらが複雑過ぎるか、またはマルチサブネット放送のユーティリティが低いと示唆して。 このセクションで説明された規則は現在の習慣に合っています。 将来、私たちは、IPマルチキャスト(見ます[インターネット: 4])が、より一層マルチサブネット放送が記述することを意図した問題の種類を解決するのに使用されると予想します。
We were also concerned that hosts whose system managers
neglected to configure with a subnet mask could
unintentionally send multi-subnet broadcasts.
また、私たちはシステム・マネージャがサブネットマスクで構成するのを忘れたホストがマルチサブネット放送を何気なく送ることができることを心配していました。
A router SHOULD NOT originate all-subnets broadcasts, except as
required by Section [4.3.3.9] when sending ICMP Address Mask
Replies on subnetted networks.
AルータSHOULD NOTがオールサブネット放送を溯源して、必要に応じてセクションで除いてください、[4.3 .3 .9] ICMP Address Mask Repliesをサブネット化したネットワークに送るとき。
DISCUSSION:
The current intention is to decree that (like 0-filled IP
broadcasts) the notion of the all-subnets broadcast is
obsolete. It should be treated as a directed broadcast to
the first subnet of the net in question that it appears on.
議論: 現在の意志はオールサブネット放送の(0でいっぱいにされたIP放送のような)概念が時代遅れであると命じることです。 それはそれが現れる問題のネットの最初のサブネットへの指示された放送として扱われるべきです。
Routers may implement a switch (default off) which if turned
on enables the [INTERNET:3] behavior for all-subnets
broadcasts.
ルータはつけられているならオールサブネット放送のための[インターネット: 3]振舞いを可能にするスイッチ(デフォルトが下にある状態で)を実行するかもしれません。
If a router has a configuration option to allow for
forwarding all-subnet broadcasts, it should use a spanning
tree, RPF, or other multicast forwarding algorithm (which
may be computed for other purposes such as bridging or OSPF)
ルータに推進オールサブネット放送のために許容する設定オプションがあるなら、それはスパニングツリー、RPF、または他のマルチキャスト推進アルゴリズムを使用するべきです。(どれが橋を架けなどなどの他の目的のために計算されるかもしれないか、そして、OSPF)
Almquist & Kastenholz [Page 96] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[96ページ]RFC1716
to distribute the all-subnets broadcast efficiently. In
general, it is better to use an IP multicast address rather
than an all-subnets broadcast.
オールサブネットを分配するのは効率的に放送されました。 一般に、オールサブネット放送よりむしろIPマルチキャストアドレスを使用しているほうがよいです。
5.3.5.4 Subnet-directed Broadcasts
5.3.5.4 サブネットで指示された放送
A router MUST classify as subnet-directed broadcasts all valid
directed broadcasts destined for a directly attached subnetted
network in which the subnet part is not all-ones. If the
destination network is not subnetted, the broadcast MUST be
treated as a net-directed broadcast.
ルータはサブネットで指示された放送としてサブネット部分がオールものでない直接付属しているサブネット化したネットワークのために運命づけられたすべての有効な指示された放送を分類しなければなりません。 送信先ネットワークが「副-網で覆」われないなら、ネットに指示された放送として放送を扱わなければなりません。
A router MUST forward subnet-directed broadcasts.
ルータはサブネットで指示された放送を進めなければなりません。
A router MUST have a configuration option to prohibit
forwarding of subnet-directed broadcasts. Its default setting
MUST permit forwarding of subnet-directed broadcasts.
ルータには、サブネットで指示された放送の推進を禁止する設定オプションがなければなりません。 既定の設定はサブネットで指示された放送の許可証推進がそうしなければなりません。
A router MAY have a configuration option to prohibit forwarding
of subnet-directed broadcasts from a source on a network on
which the router has an interface. If such an option is
provided, its default setting MUST permit forwarding of
subnet-directed broadcasts.
ルータには、ルータがインタフェースを持っているネットワークのソースからサブネットで指示された放送の推進を禁じる設定オプションがあるかもしれません。 そのようなオプションを提供するなら、既定の設定はサブネットで指示された放送の許可証推進を提供しなければなりません。
5.3.6 Congestion Control
5.3.6 輻輳制御
Congestion in a network is loosely defined as a condition where
demand for resources (usually bandwidth or CPU time) exceeds
capacity. Congestion avoidance tries to prevent demand from
exceeding capacity, while congestion recovery tries to restore an
operative state. It is possible for a router to contribute to
both of these mechanisms. A great deal of effort has been spent
studying the problem. The reader is encouraged to read
[FORWARD:2] for a survey of the work. Important papers on the
subject include [FORWARD:3], [FORWARD:4], [FORWARD:5], and
[INTERNET:10], among others.
ネットワークにおける混雑は緩くリソース(通常帯域幅かCPU時間)の要求が容量を超えている状態と定義されます。 輻輳回避は、要求が容量を超えているのを防ごうとしますが、混雑回復は作用している状態を回復しようとします。 ルータがこれらのメカニズムの両方に貢献するのは、可能です。大きな努力を問題を研究するのに費やしてあります。 読者が仕事の調査のために読むよう[FORWARD: 2]奨励されます。 話題の上の重要書類は[FORWARD: 3]、[FORWARD: 4]、[FORWARD: 5]、および特に[インターネット: 10]を含んでいます。
The amount of storage that router should have available to handle
peak instantaneous demand when hosts use reasonable congestion
policies, such as described in [FORWARD:5], is a function of the
product of the bandwidth of the link times the path delay of the
flows using the link, and therefore storage should increase as
this Bandwidth*Delay product increases. The exact function
relating storage capacity to probability of discard is not known.
ホストが[FORWARD: 5]で説明されるように合理的な混雑方針を使用するとき、ルータがピークの瞬時に起こっている要求を扱うために利用可能にするべきである格納の量はこのBandwidth*遅れ製品が増加するのに従ってリンクを使用して、したがって格納を使用する流れの経路遅れが増加するべきであるというリンク時代の帯域幅の生成物の機能です。 破棄の確率に記憶容量に関連する正確な機能は知られていません。
When a router receives a packet beyond its storage capacity it
ルータが記憶容量でパケットを受ける、それ
Almquist & Kastenholz [Page 97] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[97ページ]RFC1716
must (by definition, not by decree) discard it or some other
packet or packets. Which packet to discard is the subject of much
study but, unfortunately, little agreement so far.
(定義上法令)はそれ、ある他のパケットまたはパケットを捨てなければなりませんか? 今までのところ、どのパケットを捨てたらよいかは、多くの研究にもかかわらず、残念ながら少ない協定の対象です。
A router MAY discard the packet it has just received; this is the
simplest but not the best policy. It is considered better policy
to randomly pick some transit packet on the queue and discard it
(see [FORWARD:2]). A router MAY use this Random Drop algorithm to
determine which packet to discard.
ルータはそれがちょうど受けたパケットを捨てるかもしれません。 これが最も簡単ですが、最善の策は簡単ではありません。 それは、手当たりしだいに待ち行列のあるトランジットパケットを選んで、それを捨てるために、より良い方針であると考えられます(見てください[FORWARD: 2])。 ルータは、どのパケットを捨てたらよいかを決定するのにこのRandom Dropアルゴリズムを使用するかもしれません。
If a router implements a discard policy (such as Random Drop)
under which it chooses a packet to discard from among a pool of
eligible packets:
ルータがaを実行するなら、それが適任のパケットのプールから捨てるためにパケットを選ぶ方針(Random Dropなどの)を捨ててください:
o If precedence-ordered queue service (described in Section
[5.3.3.1]) is implemented and enabled, the router MUST NOT
discard a packet whose IP precedence is higher than that of a
packet which is not discarded.
o 先行で命令された待ち行列サービスである、(セクションで説明される、[5.3 .3 .1は、)実行されて、可能にされて、ルータはIP先行が捨てられなかったパケットのものより高いパケットを捨ててはいけません。
o A router MAY protect packets whose IP headers request the
maximize reliability TOS, except where doing so would be in
violation of the previous rule.
o ルータがヘッダーが要求するだれのパケットIPを保護するかもしれないか、信頼性のTOSを最大にしてください、そうするのが前の規則を違反しているところを除いて。
o A router MAY protect fragmented IP packets, on the theory that
dropping a fragment of a datagram may increase congestion by
causing all fragments of the datagram to be retransmitted by
the source.
o ルータは断片化しているIPパケットを保護するかもしれません、データグラムの断片を落とすとデータグラムのすべての断片が情報筋によって再送されることを引き起こすことによって混雑が増加するかもしれないという理論で。
o To help prevent routing perturbations or disruption of
management functions, the router MAY protect packets used for
routing control, link control, or network management from being
discarded. Dedicated routers (i.e.. routers which are not also
general purpose hosts, terminal servers, etc.) can achieve an
approximation of this rule by protecting packets whose source
or destination is the router itself.
o 管理機能のルーティング摂動か分裂を防ぐのを助けるために、ルータは捨てられるのでルーティングコントロール、リンク制御、またはネットワークマネージメントに使用されるパケットを保護するかもしれません。 ひたむきなルータ(. すなわち、汎用のホストも、端末のサーバでないなどルータ)は、ソースか目的地がルータ自体であるパケットを保護することによって、この規則の近似を実現できます。
Advanced methods of congestion control include a notion of
fairness, so that the 'user' that is penalized by losing a packet
is the one that contributed the most to the congestion. No matter
what mechanism is implemented to deal with bandwidth congestion
control, it is important that the CPU effort expended be
sufficiently small that the router is not driven into CPU
congestion also.
輻輳制御の改良された方法は公正の概念を含んでいます、パケットを失うことによって罰せられる'ユーザ'が混雑に最も貢献したものであるように。 どんなメカニズムが帯域幅輻輳制御に対処するために実行されても、努力が費やしたCPUが十分小さいのは、重要です。CPU混雑もルータに追い込まれません。
As described in Section [4.3.3.3], this document recommends that a
router should not send a Source Quench to the sender of the packet
that it is discarding. ICMP Source Quench is a very weak
セクションで説明される、[4.3 .3 .3] このドキュメントは、ルータがそれが捨てているパケットの送付者にSource Quenchを送るべきでないことを勧めます。 ICMP Source Quenchはaまさしくその弱者です。
Almquist & Kastenholz [Page 98] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[98ページ]RFC1716
mechanism, so it is not necessary for a router to send it, and
host software should not use it exclusively as an indicator of
congestion.
ルータがそれを送るのはメカニズムによって必要でなく、ホストソフトウェアは排他的に混雑のインディケータとしてそれを使用するはずがありません。
5.3.7 Martian Address Filtering
5.3.7 火星のアドレスフィルタリング
An IP source address is invalid if it is an IP broadcast address
or is not a class A, B, or C address.
IPソースアドレスはそれがIP放送演説でもなくて、またクラスAでなくて、またBでなくて、またまたはCアドレスでもないなら無効です。
An IP destination address is invalid if it is not a class A, B, C,
or D address.
受信者IPアドレスはそれがクラスAでなくて、またBでなくて、またCでなくて、またまたはDアドレスでもないなら無効です。
A router SHOULD NOT forward any packet which has an invalid IP
source address or a source address on network 0. A router SHOULD
NOT forward, except over a loopback interface, any packet which
has a source address on network 127. A router MAY have a switch
which allows the network manager to disable these checks. If such
a switch is provided, it MUST default to performing the checks.
SHOULD NOTが無効のIPソースアドレスかネットワーク0に関するソースアドレスを持っているどんなパケットも送るルータ。 ループバックインタフェース、ネットワーク127に関するソースアドレスを持っているどんなパケット以外のルータSHOULD NOTフォワード。 ルータはネットワークマネージャがこれらのチェックを無効にすることができるスイッチを持っているかもしれません。 そのようなスイッチを提供するなら、それはチェックを実行するのをデフォルトとしなければなりません。
A router SHOULD NOT forward any packet which has an invalid IP
destination address or a destination address on network 0. A
router SHOULD NOT forward, except over a loopback interface, any
packet which has a destination address on network 127. A router
MAY have a switch which allows the network manager to disable
these checks. If such a switch is provided, it MUST default to
performing the checks.
SHOULD NOTが無効の受信者IPアドレスかネットワーク0に関する送付先アドレスを持っているどんなパケットも送るルータ。 ループバックインタフェース、ネットワーク127に関する送付先アドレスを持っているどんなパケット以外のルータSHOULD NOTフォワード。 ルータはネットワークマネージャがこれらのチェックを無効にすることができるスイッチを持っているかもしれません。 そのようなスイッチを提供するなら、それはチェックを実行するのをデフォルトとしなければなりません。
If a router discards a packet because of these rules, it SHOULD
log at least the IP source address, the IP destination address,
and, if the problem was with the source address, the physical
interface on which the packet was received and the Link Layer
address of the host or router from which the packet was received.
ルータはこれらの規則のためにパケットを捨てて、それは少なくともソースが演説するSHOULDログIPです、受信者IPアドレス、問題であるならソースアドレス、物理的によるパケットが受け取られたインタフェースとパケットが受け取られたホストかルータのLink Layerアドレスが受信者IPアドレスであるなら
5.3.8 Source Address Validation
5.3.8 ソースアドレス合法化
A router SHOULD IMPLEMENT the ability to filter traffic based on a
comparison of the source address of a packet and the forwarding
table for a logical interface on which the packet was received.
If this filtering is enabled, the router MUST silently discard a
packet if the interface on which the packet was received is not
the interface on which a packet would be forwarded to reach the
address contained in the source address. In simpler terms, if a
router wouldn't route a packet containing this address through a
particular interface, it shouldn't believe the address if it
appears as a source address in a packet read from this interface.
フィルタトラフィックへの能力が比較を基礎づけたパケットのソースアドレスのルータSHOULD IMPLEMENTと論理的なインタフェースへのパケットが受け取られた推進テーブル。 ルータはこのフィルタリングが可能にされて、パケットが受け取られたインタフェースがパケットがソースアドレスに含まれたアドレスに達するように進められるインタフェースでないなら静かにパケットを捨てなければなりません。 より簡単な用語で、パケットのソースアドレスがこのインタフェースから読んだように見えて、ルータが特定のインタフェースを通してこのアドレスを含むパケットを発送しないなら、それはアドレスを信じるべきではありません。
If this feature is implemented, it MUST be disabled by default.
この特徴が実装されるなら、デフォルトでそれを無効にしなければなりません。
Almquist & Kastenholz [Page 99] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[99ページ]RFC1716
DISCUSSION:
This feature can provide useful security improvements in some
situations, but can erroneously discard valid packets in
situations where paths are asymmetric.
議論: この特徴は、役に立つセキュリティ改良をいくつかの状況に提供できますが、経路が非対称である状況で誤って有効なパケットを捨てることができます。
5.3.9 Packet Filtering and Access Lists
5.3.9 パケットフィルタリングとアクセスリスト
As a means of providing security and/or limiting traffic through
portions of a network a router SHOULD provide the ability to
selectively forward (or filter) packets. If this capability is
provided, filtering of packets MUST be configurable either to
forward all packets or to selectively forward them based upon the
source and destination addresses. Each source and destination
address SHOULD allow specification of an arbitrary mask.
ネットワークの一部を通してセキュリティを提供する、そして/または、トラフィックを制限する手段として、SHOULDが選択的に能力を提供するルータは(または、フィルタ)パケットを進めます。 この能力を提供するなら、パケットのフィルタリングは、すべてのパケットを進めるか、または選択的にソースと送付先アドレスに基づいた状態でそれらを進めるために構成可能でなければなりません。 各ソースと送付先アドレスSHOULDは任意のマスクの仕様を許容します。
If supported, a router MUST be configurable to allow one of an
サポートされるなら、ルータは1つを許容するのにおいて構成可能であるに違いありません。
o Include list - specification of a list of address pairs to be
forwarded, or an
o またはリストを含めてください--アドレスのリストの仕様が進めるために対にされる。
o Exclude list - specification of a list of address pairs NOT to
be forwarded.
o リストを除いてください--アドレスのリストの仕様は進められるNOTを対にします。
A router MAY provide a configuration switch which allows a choice
between specifying an include or an exclude list.
または、ルータがインクルードを指定することの選択を許す設定スイッチを提供するかもしれない、リストを除いてください。
A value matching any address (e.g. a keyword any or an address
with a mask of all 0's) MUST be allowed as a source and/or
destination address.
ソース、そして/または、送付先アドレスとしてどんなアドレス(例えばaがあるいずれかアドレスがマスクをかけるすべての0に関するキーワード)にも合っている値を許容しなければなりません。
In addition to address pairs, the router MAY allow any combination
of transport and/or application protocol and source and
destination ports to be specified.
アドレス組に加えて、ルータは、輸送、そして/または、アプリケーション・プロトコルと、ソースと仕向港のどんな組み合わせも指定されるのを許容するかもしれません。
The router MUST allow packets to be silently discarded (i.e..
discarded without an ICMP error message being sent).
ルータは、パケットが静かに捨てられるのを許容しなければなりません。(すなわち、捨てる、ICMPエラーメッセージなしで送ります)
The router SHOULD allow an appropriate ICMP unreachable message to
be sent when a packet is discarded. The ICMP message SHOULD
specify Communication Administratively Prohibited (code 13) as the
reason for the destination being unreachable.
ルータSHOULDはパケットが捨てられるとき送られるべき適切なICMP手の届かないメッセージを許容します。 ICMPメッセージSHOULDは手が届かない目的地の理由としてCommunication Administratively Prohibited(コード13)を指定します。
The router SHOULD allow the sending of ICMP destination
unreachable messages (code 13) to be configured for each
combination of address pairs, protocol types, and ports it allows
to be specified.
ルータSHOULDは、ICMP送信不可能メッセージ(コード13)の発信がそれが指定されるのを許容するアドレス組、プロトコルタイプ、およびポートの各組み合わせのために構成されるのを許容します。
Almquist & Kastenholz [Page 100] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[100ページ]RFC1716
The router SHOULD count and SHOULD allow selective logging of
packets not forwarded.
ルータSHOULDは数えます、そして、SHOULDは進められなかったパケットの択伐を許容します。
5.3.10 Multicast Routing
5.3.10 マルチキャストルート設定
An IP router SHOULD support forwarding of IP multicast packets,
based either on static multicast routes or on routes dynamically
determined by a multicast routing protocol (e.g., DVMRP
[ROUTE:9]). A router that forwards IP multicast packets is called
a multicast router.
静的なマルチキャストルート、または、マルチキャストルーティング・プロトコル(例えば、DVMRP[ROUTE: 9])でダイナミックに決定しているルートに基づくIPマルチキャストパケットのIPルータSHOULDサポート推進。 IPマルチキャストパケットを進めるルータはマルチキャストルータと呼ばれます。
5.3.11 Controls on Forwarding
5.3.11 推進のコントロール
For each physical interface, a router SHOULD have a configuration
option which specifies whether forwarding is enabled on that
interface. When forwarding on an interface is disabled, the
router:
各物理インターフェース、SHOULDが推進がそれで可能にされるかどうか指定する設定オプションに連結させるルータのために。 インタフェースにおける推進が身体障害者、ルータであるときに:
o MUST silently discard any packets which are received on that
interface but are not addressed to the router
o 静かにそのインタフェースに受け取られるどんなパケットも捨てなければなりませんが、ルータに扱われません。
o MUST NOT send packets out that interface, except for datagrams
originated by the router
o NOTはルータによって溯源されたデータグラム以外のそのインタフェースからパケットを送らなければなりませんか?
o MUST NOT announce via any routing protocols the availability of
paths through the interface
o NOTはインタフェースを通して何かルーティング・プロトコルで経路の有用性を発表しなければなりませんか?
DISCUSSION:
This feature allows the network manager to essentially turn off
an interface but leaves it accessible for network management.
議論: この特徴は、ネットワークマネージャが本質的にはインタフェースをオフにするのを許容しますが、それをネットワークマネージメントにアクセスしやすいままにします。
Ideally, this control would apply to logical rather than
physical interfaces, but cannot because there is no known way
for a router to determine which logical interface a packet
arrived on when there is not a one-to-one correspondence
between logical and physical interfaces.
理想的に、このコントロールは、物理的であるというよりむしろ論理的なインタフェースに適用するでしょうが、論理的で物理的なインタフェースの間に1〜1つの通信がないときルータがパケットがどの論理的なインタフェースで到着したかを決定する知られている方法が全くないので、適用できません。
5.3.12 State Changes
5.3.12 州の変化
During the course of router operation, interfaces may fail or be
manually disabled, or may become available for use by the router.
Similarly, forwarding may be disabled for a particular interface
or for the entire router or may be (re)enabled. While such
transitions are (usually) uncommon, it is important that routers
handle them correctly.
ルータ操作のコースの間、インタフェースは、失敗するか、手動で障害があるかもしれない、またはルータで使用に利用可能になるかもしれません。 同様に、推進は、特定のインタフェースか全体のルータのために無効にされるか、または可能にされるかもしれません(re)。 そのような変遷は(通常)珍しいのですが、ルータが正しくそれらを扱うのは、重要です。
Almquist & Kastenholz [Page 101] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[101ページ]RFC1716
5.3.12.1 When a Router Ceases Forwarding
5.3.12.1 aであるときに、ルータは、進めるのをやめます。
When a router ceases forwarding it MUST stop advertising all
routes, except for third party routes. It MAY continue to
receive and use routes from other routers in its routing
domains. If the forwarding database is retained, the router
MUST NOT cease timing the routes in the forwarding database.
If routes that have been received from other routers are
remembered, the router MUST NOT cease timing the routes which
it has remembered. It MUST discard any routes whose timers
expire while forwarding is disabled, just as it would do if
forwarding were enabled.
ルータが、進めるのをやめるとき、それは、第三者ルート以外のすべてのルートの広告を出すのを止めなければなりません。 それは、経路ドメインで他のルータからルートを受けて、使用し続けるかもしれません。 推進データベースが保有されるなら、ルータは、推進データベースでルートを調節するのをやめてはいけません。 他のルータから受け取られたルートが覚えていられるなら、ルータは、それが覚えていたルートを調節するのをやめてはいけません。 それは推進が障害がある間にタイマが期限が切れるどんなルートも捨てなければなりません、ちょうど推進が可能にされるならするように。
DISCUSSION:
When a router ceases forwarding, it essentially ceases being
a router. It is still a host, and must follow all of the
requirements of Host Requirements [INTRO: 2]. The router
may still be a passive member of one or more routing
domains, however. As such, it is allowed to maintain its
forwarding database by listening to other routers in its
routing domain. It may not, however, advertise any of the
routes in its forwarding database, since it itself is doing
no forwarding. The only exception to this rule is when the
router is advertising a route which uses only some other
router, but which this router has been asked to advertise.
議論: ルータが、進めるのをやめるとき、それは、ルータであることを本質的にはやめます。 それは、それでも、ホストであり、Host Requirements[INTRO: 2]の要件のすべてに続かなければなりません。 しかしながら、ルータはまだ1つ以上の経路ドメインの受け身のメンバーであるかもしれません。そういうものとして、それは、経路ドメインで他のルータを聞くことによって、推進データベースを維持できます。 進めないことをしているので、しかしながら、それは推進データベースにルートのいずれも広告を出さないかもしれません。 この規則への唯一の例外はルータがいつある他のルータだけを使用するルートの広告を出しているか、しかし、どれがこのルータが広告を出すように頼まれたかということです。
A router MAY send ICMP destination unreachable (host
unreachable) messages to the senders of packets that it is
unable to forward. It SHOULD NOT send ICMP redirect messages.
ルータはそれが進めることができないパケットの送付者への目的地の手の届かない(ホスト手の届かない)メッセージをICMPに送るかもしれません。 それ、SHOULD NOTは再直接のメッセージをICMPに送ります。
DISCUSSION:
Note that sending an ICMP destination unreachable (host
unreachable) is a router action. This message should not be
sent by hosts. This exception to the rules for hosts is
allowed so that packets may be rerouted in the shortest
possible time, and so that black holes are avoided.
議論: 手が届かない状態で(ホスト手の届かない)ICMPの目的地を送るのが、ルータ動作であることに注意してください。 ホストはこのメッセージを送るべきではありません。 ホストのための規則へのこの例外が許容されているので、パケットはできるだけ短時間で別ルートで送られるかもしれなくて、ブラックホールは避けられます。
5.3.12.2 When a Router Starts Forwarding
5.3.12.2 時はルータスタート推進です。
When a router begins forwarding, it SHOULD expedite the sending
of new routing information to all routers with which it
normally exchanges routing information.
aであるときに、ルータは進め始めます、それ。SHOULDは通常、それがルーティング情報を交換するすべてのルータへの新しいルーティング情報の送付を速めます。
Almquist & Kastenholz [Page 102] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[102ページ]RFC1716
5.3.12.3 When an Interface Fails or is Disabled
5.3.12.3 Interface Failsである、Disabledです。
If an interface fails or is disabled a router MUST remove and
stop advertising all routes in its forwarding database which
make use of that interface. It MUST disable all static routes
which make use of that interface. If other routes to the same
destination and TOS are learned or remembered by the router,
the router MUST choose the best alternate, and add it to its
forwarding database. The router SHOULD send ICMP destination
unreachable or ICMP redirect messages, as appropriate, in reply
to all packets which it is unable to forward due to the
interface being unavailable.
インタフェースは失敗するか、または障害があるなら、ルータが、取り外して、推進データベースのそのインタフェースを利用するすべてのルートの広告を出すのを止めなければなりません。 それはそのインタフェースを利用するすべてのスタティックルートを無効にしなければなりません。 同じ目的地とTOSへの他のルートがルータによって学習されるか、または覚えていられるなら、ルータは、最も良い補欠を選んで、推進データベースにそれを追加しなければなりません。 ルータSHOULDは目的地の手の届かないかICMP再直接のメッセージをICMPに送ります、適宜、それが入手できないインタフェースのため進めることができないすべてのパケットに対して。
5.3.12.4 When an Interface is Enabled
5.3.12.4 InterfaceはEnabledです。
If an interface which had not been available becomes available,
a router MUST reenable any static routes which use that
interface. If routes which would use that interface are
learned by the router, then these routes MUST be evaluated
along with all of the other learned routes, and the router MUST
make a decision as to which routes should be placed in the
forwarding database. The implementor is referred to Chapter
[7], Application Layer - Routing Protocols for further
information on how this decision is made.
利用可能でなかったインタフェースが利用可能になるなら、ルータはそのインタフェースを使用するどんなスタティックルートも再可能にしなければなりません。 そのインタフェースを使用するルートがルータによって学習されるなら、他の学術的ルートのすべてと共にこれらのルートを評価しなければなりません、そして、どのルートが推進データベースに置かれるべきであるかに関してルータは決定しなければなりません。 作成者は章[7]を参照されます、Application Layer--どうこの決定をするかに関する詳細のためのルート設定プロトコル。
A router SHOULD expedite the sending of new routing information
to all routers with which it normally exchanges routing
information.
ルータSHOULDは通常、それがルーティング情報を交換するすべてのルータへの新しいルーティング情報の送付を速めます。
5.3.13 IP Options
5.3.13 IPオプション
Several options, such as Record Route and Timestamp, contain slots
into which a router inserts its address when forwarding the
packet. However, each such option has a finite number of slots,
and therefore a router may find that there is not free slot into
which it can insert its address. No requirement listed below
should be construed as requiring a router to insert its address
into an option that has no remaining slot to insert it into.
Section [5.2.5] discusses how a router must choose which of its
addresses to insert into an option.
Record RouteやTimestampなどのいくつかのオプションがパケットを進めるときルータがアドレスを挿入するスロットを含んでいます。 しかしながら、そのような各オプションには、有限数のスロットがあります、そして、したがって、ルータによって、それがアドレスを挿入できる自由なスロットがないのがわかるかもしれません。 以下にリストアップされなかった要件は全くそれを挿入する残っているスロットを全く持っていないオプションにアドレスを挿入するためにルータを必要とするのに理解されるべきです。 セクション、[5.2、.5、]、ルータが、アドレスのどれをオプションに挿入するかをどう選ばなければならないかについて議論します。
5.3.13.1 Unrecognized Options
5.3.13.1 認識されていないオプション
Unrecognized IP options in forwarded packets MUST be passed
through unchanged.
変わりがない状態で進められたパケットの認識されていないIPオプションを通り抜けなければなりません。
Almquist & Kastenholz [Page 103] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[103ページ]RFC1716
5.3.13.2 Security Option
5.3.13.2 セキュリティオプション
Some environments require the Security option in every packet;
such a requirement is outside the scope of this document and
the IP standard specification. Note, however, that the
security options described in [INTERNET:1] and [INTERNET:16]
are obsolete. Routers SHOULD IMPLEMENT the revised security
option described in [INTERNET:5].
いくつかの環境があらゆるパケットでSecurityオプションを必要とします。 このドキュメントとIPの標準の仕様の範囲の外にそのような要件はあります。 しかしながら、[インターネット: 1]と[インターネット: 16]で説明されたセキュリティオプションが時代遅れであることに注意してください。 改訂されたセキュリティオプションが[インターネット: 5]で説明したルータSHOULD IMPLEMENT。
5.3.13.3 Stream Identifier Option
5.3.13.3 ストリーム識別子オプション
This option is obsolete. If the Stream Identifier option is
present in a packet forwarded by the router, the option MUST be
ignored and passed through unchanged.
このオプションは時代遅れです。 Stream Identifierオプションがルータによって進められたパケットに存在しているなら、変わりがない状態でオプションを無視されて、通り抜けなければなりません。
5.3.13.4 Source Route Options
5.3.13.4 送信元経路オプション
A router MUST implement support for source route options in
forwarded packets. A router MAY implement a configuration
option which, when enabled, causes all source-routed packets to
be discarded. However, such an option MUST NOT be enabled by
default.
ルータは進められたパケットの送信元経路オプションのサポートを実装しなければなりません。 ルータは、構成が可能にされるとすべてのソースによって発送されたパケットを捨てるオプションであると実装するかもしれません。 しかしながら、デフォルトでそのようなオプションを可能にしてはいけません。
DISCUSSION:
The ability to source route datagrams through the Internet
is important to various network diagnostic tools. However,
in a few rare cases, source routing may be used to bypass
administrative and security controls within a network.
Specifically, those cases where manipulation of routing
tables is used to provide administrative separation in lieu
of other methods such as packet filtering may be vulnerable
through source routed packets.
議論: 送信元経路データグラムへのインターネットを通した能力は様々なネットワーク診断用道具に重要です。 しかしながら、いくつかのまれなケースでは、ソースルーティングは、ネットワークの中で管理とセキュリティコントロールを迂回させるのに使用されるかもしれません。 明確に、経路指定テーブルの操作がパケットフィルタリングなどの他のメソッドの代わりに管理分離を提供するのに使用されるそれらのケースはソースの発送されたパケットを通して被害を受け易いかもしれません。
5.3.13.5 Record Route Option
5.3.13.5 ルートオプションを記録してください。
Routers MUST support the Record Route option in forwarded
packets.
ルータは、進められたパケットでRecord Routeがオプションであるとサポートしなければなりません。
A router MAY provide a configuration option which, if enabled,
will cause the router to ignore (i.e. pass through unchanged)
Record Route options in forwarded packets. If provided, such
an option MUST default to enabling the record-route. This
option does not affect the processing of Record Route options
in datagrams received by the router itself (in particular,
Record Route options in ICMP echo requests will still be
processed in accordance with Section [4.3.3.6]).
ルータは可能にされるならルータが進められたパケットで記録的なRouteオプションを無視する(すなわち、変わりがない状態で、通り抜けます)設定オプションを提供するかもしれません。 提供するなら、そのようなオプションは記録的なルートを可能にするのをデフォルトとしなければなりません。 このオプションがルータ自体によって受け取られたデータグラムでのRecord Routeオプションの処理に影響しない、(それでも、セクションによると、特に、ICMPエコー要求におけるRecord Routeオプションが処理される、[4.3 .3 .6)。
Almquist & Kastenholz [Page 104] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[104ページ]RFC1716
DISCUSSION:
There are some people who believe that Record Route is a
security problem because it discloses information about the
topology of the network. Thus, this document allows it to
be disabled.
議論: Record Routeがネットワークのトポロジーに関して情報を開示するので警備上の問題であると信じている何人かの人々がいます。 したがって、このドキュメントで、それは無効にします。
5.3.13.6 Timestamp Option
5.3.13.6 タイムスタンプオプション
Routers MUST support the timestamp option in forwarded packets.
A timestamp value MUST follow the rules given in Section
[3.2.2.8] of [INTRO:2].
ルータは、進められたパケットでタイムスタンプがオプションであるとサポートしなければなりません。 タイムスタンプ値がセクションで与えられた規則に従わなければならない、[3.2 .2 .8[INTRO: 2。]]
If the flags field = 3 (timestamp and prespecified address),
the router MUST add its timestamp if the next prespecified
address matches any of the router's IP addresses. It is not
necessary that the prespecified address be either the address
of the interface on which the packet arrived or the address of
the interface over which it will be sent.
旗が=3(タイムスタンプと前指定されたアドレス)をさばくなら、次の前指定されたアドレスがルータのIPアドレスのどれかに合っているなら、ルータはタイムスタンプを加えなければなりません。 前指定されたアドレスがパケットが到着したインタフェースのアドレスかそれが送られるインタフェースのアドレスのどちらかであることは必要ではありません。
IMPLEMENTATION:
To maximize the utility of the timestamps contained in the
timestamp option, it is suggested that the timestamp
inserted be, as nearly as practical, the time at which the
packet arrived at the router. For datagrams originated by
the router, the timestamp inserted should be, as nearly as
practical, the time at which the datagram was passed to the
network layer for transmission.
実装: タイムスタンプオプションに含まれたタイムスタンプに関するユーティリティを最大にするために、挿入されたタイムスタンプがあることが提案されます、ほとんど同じくらい実用的です、パケットがルータに到着した時。 ルータによって溯源されたデータグラムに関しては、挿入されたタイムスタンプはそうであるべきです、ほとんど同じくらい実用的です、データグラムがトランスミッションのためにネットワーク層に渡された時。
A router MAY provide a configuration option which, if enabled,
will cause the router to ignore (i.e. pass through unchanged)
Timestamp options in forwarded datagrams when the flag word is
set to zero (timestamps only) or one (timestamp and registering
IP address). If provided, such an option MUST default to off
(that is, the router does not ignore the timestamp). This
option does not affect the processing of Timestamp options in
datagrams received by the router itself (in particular, a
router will insert timestamps into Timestamp options in
datagrams received by the router, and Timestamp options in ICMP
echo requests will still be processed in accordance with
Section [4.3.3.6]).
ルータは可能にされるなら存在という旗の単語が(タイムスタンプ専用)のゼロを合わせるためにセットしたとき進められたデータグラムでタイムスタンプオプションを無視する(すなわち、変わりがない状態で、通り抜けます)ルータか1つ(タイムスタンプと登録IPアドレス)を引き起こす設定オプションを提供するかもしれません。 提供するなら、あれほどですオプションが下に(すなわち、ルータはタイムスタンプを無視しない)デフォルトでなければならない。 このオプションはルータ自体によって受け取られたデータグラムでのTimestampオプションの処理に影響しません。(特に、ルータがルータによって受け取られたデータグラムのTimestampオプションにタイムスタンプを挿入する、それでも、セクションによると、ICMPエコー要求におけるTimestampオプションが処理される、[4.3 .3 .6)。
DISCUSSION:
Like the Record Route option, the Timestamp option can
reveal information about a network's topology. Some people
consider this to be a security concern.
議論: Record Routeオプションのように、Timestampオプションはネットワークのトポロジーの情報を明らかにすることができます。 人々の中にはこれがセキュリティ関心であると考える人もいます。
Almquist & Kastenholz [Page 105] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[105ページ]RFC1716
6. TRANSPORT LAYER
6. トランスポート層
A router is not required to implement any Transport Layer protocols except those required to support Application Layer protocols supported by the router. In practice, this means that most routers implement both the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP).
ルータは、ルータでサポートされたプロトコルをApplication Layerにサポートするのに必要であるもの以外のどんなTransport Layerプロトコルも実装するのに必要ではありません。 実際には、これは、ほとんどのルータが、両方が通信制御プロトコル(TCP)とユーザー・データグラム・プロトコル(UDP)であると実装することを意味します。
6.1 USER DATAGRAM PROTOCOL - UDP
6.1ユーザー・データグラム・プロトコル--UDP
The User Datagram Protocol (UDP) is specified in [TRANS:1].
ユーザー・データグラム・プロトコル(UDP)は[TRANS: 1]で指定されます。
A router which implements UDP MUST be compliant, and SHOULD be unconditionally compliant, with the requirements of section 4.1.3 of [INTRO:2], except that:
どの道具UDP MUSTが言いなりになるか、そして、SHOULDは無条件に言いなりになります。ルータ、.3セクション4.1[INTRO: 2]の要件で言いなりになります、それを除いてください:
o This specification does not specify the interfaces between the
various protocol layers. Thus, a router need not comply with
sections 4.1.3.2, 4.1.3.3, and 4.1.3.5 of [INTRO:2] (except of
course where compliance is required for proper functioning of
Application Layer protocols supported by the router).
o この仕様は様々なプロトコル層の間のインタフェースを指定しません。 そして、その結果、ルータがセクション4.1.3に従う必要はない、.2 4.1 .3 .3、4.1 .3 .5[INTRO: 2。](もちろん、コンプライアンスがルータでサポートされたApplication Layerプロトコルの適切な機能に必要であるところで除きます)
o Contrary to section 4.1.3.4 of [INTRO:2], an application MUST NOT
be able to disable to generation of UDP checksums.
o .4[INTRO: 2]、アプリケーションがUDPチェックサムの世代に無効にすることができるはずがないセクション4.1.3とは逆に。
DISCUSSION:
Although a particular application protocol may require that UDP
datagrams it receives must contain a UDP checksum, there is no
general requirement that received UDP datagrams contain UDP
checksums. Of course, if a UDP checksum is present in a received
datagram, the checksum must be verified and the datagram discarded
if the checksum is incorrect.
議論: 特定用途プロトコルは、それが受けるUDPデータグラムがUDPチェックサムを含まなければならないのを必要とするかもしれませんが、容認されたUDPデータグラムがUDPチェックサムを含んでいる、もちろんというどんな一般的な要件もありません、UDPチェックサムが容認されたデータグラムに存在していて、チェックサムについて確かめなければならなくて、チェックサムが不正確であるならデータグラムが捨てられたなら。
6.2 TRANSMISSION CONTROL PROTOCOL - TCP
6.2通信制御プロトコル--TCP
The Transmission Control Protocol (TCP) is specified in [TRANS:2].
通信制御プロトコル(TCP)は[TRANS: 2]で指定されます。
A router which implements TCP MUST be compliant, and SHOULD be unconditionally compliant, with the requirements of section 4.2 of [INTRO:2], except that:
どの道具TCP MUSTが言いなりになるか、そして、SHOULDは無条件に言いなりになります。ルータ、[INTRO: 2]のセクション4.2の要件で言いなりになります、それを除いてください:
o This specification does not specify the interfaces between the
various protocol layers. Thus, a router need not comply with the
following requirements of [INTRO:2] (except of course where
compliance is required for proper functioning of Application Layer
o この仕様は様々なプロトコル層の間のインタフェースを指定しません。 したがって、ルータが[INTRO: 2]の以下の要件に従う必要はない、(もちろんコンプライアンスがApplication Layerの適切な機能に必要であるところで除いてください。
Almquist & Kastenholz [Page 106] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[106ページ]RFC1716
protocols supported by the router):
ルータによってサポートされたプロトコル)、:
Section 4.2.2.2:
Passing a received PSH flag to the application layer is now
OPTIONAL.
セクション4.2 .2 .2、: 現在、容認されたPSH旗を応用層に渡すのは、OPTIONALです。
Section 4.2.2.4:
A TCP MUST inform the application layer asynchronously
whenever it receives an Urgent pointer and there was
previously no pending urgent data, or whenever the Urgent
pointer advances in the data stream. There MUST be a way for
the application to learn how much urgent data remains to be
read from the connection, or at least to determine whether or
not more urgent data remains to be read.
セクション4.2 .2 .4、: Urgent指針を受けて、以前に、どんな未定の緊急のデータもなかったときはいつも、TCP MUSTが応用層を非同期に知らせるか、またはUrgent指針がデータを進むときはいつも、流れてください。 より緊急のデータが読まれるために残っているか否かに関係なく、アプリケーションが、緊急のデータが接続から読まれるか、または少なくとも決定するためにいくらのままで残っているかを学ぶ方法があるに違いありません。
Section 4.2.3.5:
An application MUST be able to set the value for R2 for a
particular connection. For example, an interactive
application might set R2 to ``infinity,'' giving the user
control over when to disconnect.
セクション4.2 .3 .5、: アプリケーションは特定の接続のためにR2に値を設定できなければなりません。 例えば、いつ切断するかユーザ支配力を与えて、対話型アプリケーションは「無限」にR2を設定するかもしれません。
Section 4.2.3.7:
If an application on a multihomed host does not specify the
local IP address when actively opening a TCP connection, then
the TCP MUST ask the IP layer to select a local IP address
before sending the (first) SYN. See the function
GET_SRCADDR() in Section 3.4.
セクション4.2 .3 .7、: 活発にTCP接続を開くとき、「マルチ-家へ帰」っているホストにおけるアプリケーションがローカルアイピーアドレスを指定しないなら、TCP MUSTは、(1番目)のSYNを送る前にローカルアイピーアドレスを選択するようにIP層に頼みます。 セクション3.4で機能GET_SRCADDR()を見てください。
Section 4.2.3.8:
An application MUST be able to specify a source route when it
actively opens a TCP connection, and this MUST take
precedence over a source route received in a datagram.
セクション4.2 .3 .8、: 活発にTCP接続を開くとき、アプリケーションは送信元経路を指定できなければなりません、そして、これはデータグラムに受け取られた送信元経路の上で優先しなければなりません。
o For similar reasons, a router need not comply with any of the
requirements of section 4.2.4 of [INTRO:2].
o 同様の理由で、ルータは.4セクション4.2[INTRO: 2]の要件のいずれにも従う必要はありません。
o The requirements of section 4.2.2.6 of [INTRO:2] are amended as
follows: a router which implements the host portion of MTU
discovery (discussed in Section [4.2.3.3] of this memo) uses 536
as the default value of SendMSS only if the path MTU is unknown;
if the path MTU is known, the default value for SendMSS is the
path MTU - 40.
o .6[INTRO: 2]が以下の通り修正されるというセクション4.2.2の要件: MTU発見のホスト部分を実装するルータ、(セクションで議論する、[4.2 .3 この.3のメモ]) 経路MTUが未知である場合にだけ、SendMSSのデフォルト値として536を使用します。 経路MTUが知られているなら、SendMSSのためのデフォルト値は経路MTUです--40。
o The requirements of section 4.2.2.6 of [INTRO:2] are amended as
follows: ICMP Destination Unreachable codes 11 and 12 are
additional soft error conditions. Therefore, these message MUST
NOT cause TCP to abort a connection.
o .6[INTRO: 2]が以下の通り修正されるというセクション4.2.2の要件: ICMP Destination Unreachableコード11と12は追加ソフト・エラー状態です。 したがって、これらのメッセージで、TCPは接続を中止してはいけません。
Almquist & Kastenholz [Page 107] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[107ページ]RFC1716
DISCUSSION:
It should particularly be noted that a TCP implementation in a
router must conform to the following requirements of [INTRO:2]:
議論: ルータにおけるTCP実装が[INTRO: 2]の以下の要件に従わなければならないことに特に注意されるべきです:
o Providing a configurable TTL. [4.2.2.1]
o 構成可能なTTLを提供します。 [4.2.2.1]
o Providing an interface to configure keep-alive behavior, if
keep-alives are used at all. [4.2.3.6]
o 構成するインタフェースを提供して、生活費アリフが少しでも使用されるなら、振舞いを生かしてください。 [4.2.3.6]
o Providing an error reporting mechanism, and the ability to
manage it. [4.2.4.1]
o メカニズムを報告する誤り、およびそれを管理する能力を提供します。 [4.2.4.1]
o Specifying type of service. [4.2.4.2]
o サービスのタイプを指定します。 [4.2.4.2]
The general paradigm applied is that if a particular interface is
visible outside the router, then all requirements for the
interface must be followed. For example, if a router provides a
telnet function, then it will be generating traffic, likely to be
routed in the external networks. Therefore, it must be able to
set the type of service correctly or else the telnet traffic may
not get through.
適用された一般的なパラダイムは特定のインタフェースがルータの外で目に見えるならインタフェースのためのすべての要件に続かなければならないということです。 例えば、ルータがtelnet機能を提供すると、トラフィックを生成するでしょう、外部のネットワークで発送されそうです。 したがって、正しくサービスのタイプを設定できなくなければならないかもしれませんか、telnetトラフィックは通らないかもしれません。
Almquist & Kastenholz [Page 108] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[108ページ]RFC1716
7. APPLICATION LAYER - ROUTING PROTOCOLS
7. 応用層--ルーティング・プロトコル
7.1 INTRODUCTION
7.1 序論
An Autonomous System (AS) is defined as a set of routers all belonging under the same authority and all subject to a consistent set of routing policies. Interior gateway protocols (IGPs) are used to distribute routing information inside of an AS (i.e. intra-AS routing). Exterior gateway protocols are used to exchange routing information between ASs (i.e. inter-AS routing).
Autonomous System(AS)は一貫したセットのルーティング方針を条件として同じ権威とすべてに属す1セットのルータとすべて、定義されます。 内部のゲートウェイプロトコル(IGPs)は、AS(すなわち、イントラ-ASルーティング)のルーティング情報内部を分配するのに使用されます。 外のゲートウェイプロトコルは、ASs(すなわち、相互ASルーティング)の間でルーティング情報を交換するのに使用されます。
7.1.1 Routing Security Considerations
7.1.1 ルート設定セキュリティ問題
Routing is one of the few places where the Robustness Principle
(be liberal in what you accept) does not apply. Routers should be
relatively suspicious in accepting routing data from other routing
systems.
ルート設定はRobustness Principle(あなたが受け入れるものでは、寛容である)が適用しないわずかな場所の1つです。 ルータは他のルーティングシステムからルーティングデータを受け入れるのにおいて比較的疑わしげであるはずです。
A router SHOULD provide the ability to rank routing information
sources from most trustworthy to least trustworthy and to accept
routing information about any particular destination from the most
trustworthy sources first. This was implicit in the original
core/stub autonomous system routing model using EGP and various
interior routing protocols. It is even more important with the
demise of a central, trusted core.
SHOULDがルーティングが情報源であると最も信頼できるのから最も信頼できないまで格付けして、最初に最も信頼できるソースからどんな特定の目的地のルーティング情報も受け入れる能力を提供するルータ。 これは、オリジナルのコア/スタッブ自律システムルーティングモデルでEGPと様々な内部のルーティング・プロトコルを使用することで暗に示されていました。 それは中央の、そして、信じられたコアの終焉によってさらに重要です。
A router SHOULD provide a mechanism to filter out obviously
invalid routes (such as those for net 127).
SHOULDが明らかに無効のルート(ネットの127のためのそれらなどの)を無視するためにメカニズムを提供するルータ。
Routers MUST NOT by default redistribute routing data they do not
themselves use, trust or otherwise consider invalid. In rare
cases, it may be necessary to redistribute suspicious information,
but this should only happen under direct intercession by some
human agency.
ルータはデフォルトで自分たちでそれらが再配付しないルーティングデータを再配付してはいけません。無効であると使用するか、信じるか、またはそうでなければ、考えます。 たまには、疑わしげな情報を再配付するのが必要であるかもしれませんが、これはいくらかの人力でダイレクト仲裁の下で起こるだけであるべきです。
In general, routers must be at least a little paranoid about
accepting routing data from anyone, and must be especially careful
when they distribute routing information provided to them by
another party. See below for specific guidelines.
一般に、ルータは、少なくとも少しだれからもルーティングデータを受け入れることに関してパラノイアでなければならなく、別の人によってそれらに提供されたルーティング情報を分配するとき、特に慎重でなければなりません。 特別な基準に関して以下を見てください。
Routers SHOULD IMPLEMENT peer-to-peer authentication for those
routing protocols that support them.
それらをサポートするそれらのルーティング・プロトコルのためのルータSHOULD IMPLEMENTピアツーピア認証。
Almquist & Kastenholz [Page 109] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[109ページ]RFC1716
7.1.2 Precedence
7.1.2 先行
Except where the specification for a particular routing protocol
specifies otherwise, a router SHOULD set the IP Precedence value
for IP datagrams carrying routing traffic it originates to 6
(INTERNETWORK CONTROL).
特定のルーティング・プロトコルのための仕様が別の方法で指定するところを除いて、ルータSHOULDはそれが6(INTERNETWORK CONTROL)に溯源するルーティングトラフィックを運ぶIPデータグラムにIP Precedence価値を設定しました。
DISCUSSION:
Routing traffic with VERY FEW exceptions should be the highest
precedence traffic on any network. If a system's routing
traffic can't get through, chances are nothing else will.
議論: VERY FEW例外があるルート設定トラフィックはどんなネットワークでも最も高い先行トラフィックであるべきです。 システムのルーティングトラフィックが通ることができないと、多分、他に何もは通るでしょう。
7.2 INTERIOR GATEWAY PROTOCOLS
7.2 内部のゲートウェイプロトコル
7.2.1 INTRODUCTION
7.2.1 序論
An Interior Gateway Protocol (IGP) is used to distribute routing
information between the various routers in a particular AS.
Independent of the algorithm used to implement a particular IGP,
it should perform the following functions:
Interiorゲートウェイプロトコル(IGP)は、特定のASの様々なルータの間にルーティング情報を分配するのに使用されます。 特定のIGPを実装するのに使用されるアルゴリズムの如何にかかわらず、以下の機能を実行するべきです:
(1) Respond quickly to changes in the internal topology of an AS
(1) すばやくASの内部のトポロジーの変化に応じてください。
(2) Provide a mechanism such that circuit flapping does not cause
continuous routing updates
(2) 回路のばたつくのが連続したルーティングアップデートを引き起こさないように、メカニズムを提供してください。
(3) Provide quick convergence to loop-free routing
(3) 無輪のルーティングに迅速な集合を提供してください。
(4) Utilize minimal bandwidth
(4) 最小量の帯域幅を利用してください。
(5) Provide equal cost routes to enable load-splitting
(5) 等しい費用ルートを提供して、負荷分かれることを可能にしてください。
(6) Provide a means for authentication of routing updates
(6) ルーティングアップデートの認証のための手段を提供してください。
Current IGPs used in the internet today are characterized as
either being being based on a distance-vector or a link-state
algorithm.
今日インターネットに使用されている現在のIGPsは距離ベクトルに基づいた存在かリンク州のアルゴリズムのどちらかであるとして特徴付けられます。
Several IGPs are detailed in this section, including those most
commonly used and some recently developed protocols which may be
widely used in the future. Numerous other protocols intended for
use in intra-AS routing exist in the Internet community.
数個のIGPsがこのセクションで詳細です、最も一般的に使用されるものと将来広く使用されるかもしれないいくつかの最近開発されたプロトコルを含んでいて。 イントラ-ASルーティングにおける使用のために意図する他の多数のプロトコルはインターネットコミュニティに存在しています。
A router which implements any routing protocol (other than static
routes) MUST IMPLEMENT OSPF (see Section [7.2.2]) and MUST
どんなルーティング・プロトコル(スタティックルートを除いた)もMUST IMPLEMENT OSPFであると実装するルータ、(セクションを見てください、[7.2、.2、)でなければならない
Almquist & Kastenholz [Page 110] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[110ページ]RFC1716
IMPLEMENT RIP (see Section [7.2.4]). A router MAY implement
additional IGPs.
道具裂け目、(セクションを見てください、[7.2 .4)。 ルータは追加IGPsを実装するかもしれません。
7.2.2 OPEN SHORTEST PATH FIRST - OSPF
7.2.2 最短パス開いている1番目--OSPF
7.2.2.1 Introduction
7.2.2.1 序論
Shortest Path First (SPF) based routing protocols are a class
of link-state algorithms which are based on the shortest-path
algorithm of Dijkstra. Although SPF based algorithms have been
around since the inception of the ARPANet, it is only recently
that they have achieved popularity both inside both the IP and
the OSI communities. In an SPF based system, each router
obtains an exact replica of the entire topology database via a
process known as flooding. Flooding insures a reliable
transfer of the information. Each individual router then runs
the SPF algorithm on its database to build the IP routing
table. The OSPF routing protocol is an implementation of an
SPF algorithm. The current version, OSPF version 2, is
specified in [ROUTE:1]. Note that RFC-1131, which describes
OSPF version 1, is obsolete.
最も短いPath First(SPF)ベースのルーティング・プロトコルはダイクストラの最短パスアルゴリズムに基づいているリンク州のアルゴリズムのクラスです。 ARPANetの始まり以来SPFのベースのアルゴリズムが周囲にありますが、最近だけともにIPとOSI共同体の両方で人気を達成したということです。 SPFのベースのシステムでは、各ルータは氾濫として知られているプロセスを通して全体のトポロジーデータベースの寸分の違いもない複製物を得ます。 氾濫は情報の信頼できる転送を保障します。 そして、それぞれの個々のルータは、IP経路指定テーブルを組立てるためにSPFアルゴリズムをデータベースに実行します。 OSPFルーティング・プロトコルはSPFアルゴリズムの実装です。 最新版(OSPFバージョン2)は[ROUTE: 1]で指定されます。 RFC-1131(OSPFバージョン1について説明する)が時代遅れであることに注意してください。
Note that to comply with Section [8.3] of this memo, a router
which implements OSPF MUST implement the OSPF MIB [MGT:14].
それに注意して、このメモ(OSPF MUST道具がOSPF MIB[MGT: 14]であると実装するルータ)のセクション[8.3]に従ってください。
7.2.2.2 Specific Issues
7.2.2.2 特定の問題
Virtual Links
仮想のリンク
There is a minor error in the specification that can cause
routing loops when all of the following conditions are
simultaneously true:
以下の条件のすべてが同時に本当であるときにルーティング輪を引き起こす場合がある仕様には軽い過失があります:
(1) A virtual link is configured through a transit area,
(1) 仮想のリンクはトランジット領域を通って構成されます。
(2) Two separate paths exist, each having the same
endpoints, but one utilizing only non-virtual
backbone links, and the other using links in the
transit area, and
そして(2) それぞれ同じ終点を持っていて、2つの別々の経路が存在していますが、非仮想のバックボーンだけを利用する1つがリンクされて、他の使用がトランジット領域でリンクされる。
(3) The latter path is part of the (underlying physical
representation of the) configured virtual link,
routing loops may occur.
(3) 後者の経路が部分である、(具現の基礎となる、)、構成された仮想のリンク、ルーティング輪は現れるかもしれません。
To prevent this, an implementation of OSPF SHOULD invoke
これを防ぐために呼び出す、OSPF SHOULDの実装は呼び出します。
Almquist & Kastenholz [Page 111] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[111ページ]RFC1716
the calculation in Section 16.3 of [ROUTE:1] whenever any
part of the path to the destination is a virtual link (the
specification only says this is necessary when the first
hop is a virtual link).
目的地への経路のどんな地域も仮想のリンク(仕様は、最初のホップが仮想のリンクであるときに、これが必要であると言うだけである)であるときはいつも、[ROUTE: 1]のセクション16.3における計算。
7.2.2.3 New Version of OSPF
7.2.2.3 OSPFの新しいバージョン
As of this writing (4/4/94) there is a new version of the OSPF
specification that is winding its way through the Internet
standardization process. A prudent implementor will be aware
of this and develop an implementation accordingly.
この書くこと(4/4/94)現在、インターネット標準化過程で蛇行しているOSPF仕様の新しいバージョンがあります。 慎重な作成者は、これを意識していて、それに従って、実装を開発するでしょう。
The new version fixes several errors in the current
specification [ROUTE:1]. For this reason, implementors and
vendors ought to expect to upgrade to the new version
relatively soon. In particular, the following problems exist
in [ROUTE:1] that the new version fixes:
新しいバージョンは現在の仕様[ROUTE: 1]に基づくいくつかの誤りを修正します。 この理由で、作成者とベンダーは、比較的早く新しいバージョンにアップグレードすると予想するべきです。 特に、以下の問題は新しいバージョンが修理する[ROUTE: 1]で存在しています:
o In [ROUTE:1], certain configurations of virtual links can
lead to incorrect routing and/or routing loops. A fix for
this is specified in the new specification.
o [ROUTE: 1]では、仮想のリンクのある構成は不正確なルーティングにつながることができます、そして、ルーティングは輪にされます。 これのためのフィックスは新しい仕様で指定されます。
o In [ROUTE:1], OSPF external routes to For example, a router
cannot import into an OSPF domain external routes both for
192.2.0.0, 255.255.0.0 and 192.2.0.0, 255.255.255.0. Routes
such as these may become common with the deployment of CIDR
[INTERNET:15]. This has been addressed in the new OSPF
specification.
o そして、[ROUTE: 1]、Forの例へのOSPF外部経路では、ルータがともに192.2のためにOSPFドメインに外部経路を輸入できない、.0、.0、255.255、.0、.0、192.2 .0 .0 255.255 .255 .0。 これらなどのルートはCIDR[インターネット: 15]の展開について一般的になるかもしれません。 新しいOSPF仕様にこれを記述してあります。
o In [ROUTE:1], OSPF Network-LSAs originated before a router
changes its OSPF Router ID can confuse the Dijkstra
calculation if the router again becomes Designated Router
for the network. This has been fixed.
o [ROUTE: 1]では、ルータが再びネットワークのためのDesignated Routerになるなら、ルータがOSPF Router IDを変える前に溯源されたOSPF Network-LSAsはダイクストラの計算を混乱させることができます。 これは修理されました。
7.2.3 INTERMEDIATE SYSTEM TO INTERMEDIATE SYSTEM - DUAL IS-IS
7.2.3 中間システムへの中間システム--二元的なIS-IS
The American National Standards Institute (ANSI) X3S3.3 committee
has defined an intra-domain routing protocol. This protocol is
titled Intermediate System to Intermediate System Routeing
Exchange Protocol.
American National Standards Institut(ANSI)X3S3.3委員会はイントラドメインルーティング・プロトコルを定義しました。 このプロトコルはIntermediate System Routeing ExchangeプロトコルへのIntermediate Systemと題をつけられます。
Its application to an IP network has been defined in [ROUTE:2],
and is referred to as Dual IS-IS (or sometimes as Integrated IS-
IS). IS-IS is based on a link-state (SPF) routing algorithm and
shares all the advantages for this class of protocols.
IPネットワークへのアプリケーションが[ROUTE: 2]で定義されて、Dualと呼ばれる、-、(時々Integrated、存在、) -、リンク州(SPF)のルーティング・アルゴリズムに基づいていて、このクラスのプロトコルのためにすべての利点を共有します。
Almquist & Kastenholz [Page 112] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[112ページ]RFC1716
7.2.4 ROUTING INFORMATION PROTOCOL - RIP
7.2.4 ルーティング情報プロトコル--裂いてください。
7.2.4.1 Introduction
7.2.4.1 序論
RIP is specified in [ROUTE:3]. Although RIP is still quite
important in the Internet, it is being replaced in
sophisticated applications by more modern IGPs such as the ones
described above.
RIPは[ROUTE: 3]で指定されます。 RIPはインターネットでまだかなり重要ですが、上で説明されたものなどの、より近代的なIGPsによる高性能のアプリケーションでそれを取り替えています。
Another common use for RIP is as a router discovery protocol.
Section [4.3.3.10] briefly touches upon this subject.
ルータ発見プロトコルとしてRIPの別の一般の使用はあります。 セクション、[4.3 .3 .10は]簡潔にこの対象に触れます。
7.2.4.2 Protocol Walk-Through
7.2.4.2 プロトコル立ち稽古
Dealing with changes in topology: [ROUTE:3], pp. 11
トポロジーの変化に対処します: [ROUTE: 3]、ページ 11
An implementation of RIP MUST provide a means for timing
out routes. Since messages are occasionally lost,
implementations MUST NOT invalidate a route based on a
single missed update.
リップの実現は出ているルートをタイミングのための手段に提供しなければなりません。 メッセージが時折失われているので、実現はただ一つの逃されたアップデートに基づくルートを無効にしてはいけません。
Implementations MUST by default wait six times the update
interval before invalidating a route. A router MAY have
configuration options to alter this value.
ルートを無効にする前に、実現はデフォルトでアップデート間隔の6回待たなければなりません。 ルータには、この値を変更する設定オプションがあるかもしれません。
DISCUSSION:
It is important to routing stability that all routers
in a RIP autonomous system use similar timeout value
for invalidating routes, and therefore it is important
that an implementation default to the timeout value
specified in the RIP specification. However, that
timeout value is overly conservative in environments
where packet loss is reasonably rare. In such an
environment, a network manager may wish to be able to
decrease the timeout period in order to promote faster
recovery from failures.
議論: RIP自律システムのすべてのルータがルートを無効にするのに同様のタイムアウト値を使用するのが、ルーティングの安定性に重要であり、したがって、タイムアウト値への実現デフォルトがRIP仕様で指定したのは、重要です。 しかしながら、そのタイムアウト値はパケット損失がかなりまれであるところで環境でひどく保守的です。 そのような環境で、ネットワークマネージャは失敗からの、より速い回復を促進するためにタイムアウト時間を減少させることができるようになりたがっているかもしれません。
IMPLEMENTATION:
There is a very simple mechanism which a router may use
to meet the requirement to invalidate routes promptly
after they time out. Whenever the router scans the
routing table to see if any routes have timed out, it
also notes the age of the least recently updated route
which has not yet timed out. Subtracting this age from
実現: ルータが即座にルートを無効にするために条件を満たすのに使用するかもしれない非常に簡単なメカニズムがあります。後それらのタイムアウト。 また、ルータが何かルートが外で調節されたかどうか確認するために経路指定テーブルをスキャンするときはいつも、それは、最少の時代が最近外でまだ調節されていないルートをアップデートしたことに注意します。 これが年をとる引き
Almquist & Kastenholz [Page 113] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[113ページ]RFC1716
the timeout period gives the amount of time until the
router again needs to scan the table for timed out
routes.
ルータが、再び調節された出ているルートにテーブルをスキャンする必要があるまで、タイムアウト時間は時間を与えます。
Split Horizon: [ROUTE:3], pp. 14-15
地平線を分けてください: [ROUTE: 3]、ページ 14-15
An implementation of RIP MUST implement split horizon, a
scheme used for avoiding problems caused by including
routes in updates sent to the router from which they were
learned.
リップの実現は分裂地平線(それらが学習されたルータに送られたアップデートにルートを含んでいることによって引き起こされた問題を避けるのに使用される計画)を実行しなければなりません。
An implementation of RIP SHOULD implement Split horizon
with poisoned reverse, a variant of split horizon which
includes routes learned from a router sent to that router,
but sets their metric to infinity. Because of the routing
overhead which may be incurred by implementing split
horizon with poisoned reverse, implementations MAY include
an option to select whether poisoned reverse is in effect.
An implementation SHOULD limit the period of time in which
it sends reverse routes at an infinite metric.
当たっている逆に伴うRIP SHOULD道具Split地平線の実現、ルートを含んでいる分裂地平線の異形がそのルータに送られたルータから学びますが、セットする、それら、無限でメートル法です。 当たっている逆で分裂地平線を実行することによって被られるかもしれないルーティングオーバーヘッドのために、実現は、当たっている逆が有効であるかどうかを選択するためにオプションを含むかもしれません。 SHOULDがそれがどれを送るかで、無限のメートル法のルートが逆になっている期間に制限する実現。
IMPLEMENTATION:
Each of the following algorithms can be used to limit
the period of time for which poisoned reverse is
applied to a route. The first algorithm is more
complex but does a more complete job of limiting
poisoned reverse to only those cases where it is
necessary.
実現: どの当たっている逆がルートに適用されているか期間を制限するのにそれぞれの以下のアルゴリズムを使用できます。 最初のアルゴリズムは、より複雑ですが、当たっている逆をそれが必要であるそれらのケースだけに制限するより完全な仕事をします。
The goal of both algorithms is to ensure that poison
reverse is done for any destination whose route has
changed in the last Route Lifetime (typically 180
seconds), unless it can be sure that the previous route
used the same output interface. The Route Lifetime is
used because that is the amount of time RIP will keep
around an old route before declaring it stale.
両方のアルゴリズムの目標はルートが最後のRoute Lifetime(通常180秒)で変化したどんな目的地にも毒逆をするのを保証することです、前のルートが同じ出力インタフェースを使用したのが、確かであるはずがないなら。 それがRIPが古いルートの周りに保つ時間であるので、Route Lifetimeはそれが聞き古したである宣言する前に、使用されています。
The time intervals (and derived variables) used in the
following algorithms are as follows:
以下のアルゴリズムで費やされた時間間隔(そして、変数を引き出す)は以下の通りです:
Tu The Update Timer; the number of seconds between
RIP updates. This typically defaults to 30
seconds.
トゥアップデートタイマ。 RIPアップデートの間の秒数。 これは30秒を通常デフォルトとします。
Rl The Route Lifetime, in seconds. This is the
amount of time that a route is presumed to be
秒のRl Route Lifetime。 これはルートをあえてそうされる時間です。
Almquist & Kastenholz [Page 114] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[114ページ]RFC1716
good, without requiring an update. This typically
defaults to 180 seconds.
アップデートを必要としないで、良いです。 これは180秒を通常デフォルトとします。
Ul The Update Loss; the number of consecutive updates
that have to be lost or fail to mention a route
before RIP deletes the route. Ul is calculated to
be (Rl/Tu)+1. The +1 is to account for the fact
that the first time the ifcounter is decremented
will be less than Tu seconds after it is
initialized. Typically, Ul will be 7: (180/30)+1.
Ulアップデートの損失。 失われているか、またはRIPの前でルートに言及する必要はない連続したアップデートの数はルートを削除します。 Ulは、(Rl/トゥ)+1になるように計算されます。 それが初期化された秒後に+1をifcounterが減少する1回目がトゥより以下になるという事実を占めることになっています。 Ulは通常7歳になるでしょう: (180/30)+1.
In The value to set ifcounter to when a destination
is newly learned. This value is Ul-4, where the 4
is RIP's garbage collection timer/30
いつにifcounterを設定するか値では、目的地は新たに学習されます。 この値はUl-4です。(そこでは、4がRIPのガーベージコレクションタイマ/30です)。
The first algorithm is:
最初のアルゴリズムは以下の通りです。
- Associated with each destination is a counter, called
the ifcounter below. Poison reverse is done for any
route whose destination's ifcounter is greater than
zero.
- ifcounterは、以下に各目的地に関連づけられているのが、カウンタであると呼びました。 目的地の何かルートifcounterがゼロ以上であるかために毒逆をします。
- After a regular (not triggered or in response to a
request) update is sent, all of the non-zero
ifcounters are decremented by one.
- 定期的な(引き起こされないか、または要求に対応してそうしない)アップデートを送った後に、非ゼロifcountersのすべてを1つ減少させます。
- When a route to a destination is created, its
ifcounter is set as follows:
- 目的地へのルートが作成されるとき、ifcounterは以下の通り用意ができています:
- If the new route is superseding a valid route, and
the old route used a different (logical) output
interface, then the ifcounter is set to Ul.
- 新しいルートが有効なルートに取って代わっていて、古いルートが異なった(論理的な)出力インタフェースを使用したなら、ifcounterはUlに用意ができています。
- If the new route is superseding a stale route, and
the old route used a different (logical) output
interface, then the ifcounter is set to MAX(0, Ul
- INT(seconds that the route has been stale/Ut).
- 新しいルートが聞き古したルートに取って代わっていて、古いルートが異なった(論理的な)出力インタフェースを使用したならifcounterがMAXに用意ができている、(0 Ul--INT(ルートが聞き古した/Utであることを後援します)。
- If there was no previous route to the destination,
the ifcounter is set to In.
- 目的地への前のルートが全くなかったなら、ifcounterはInに用意ができています。
- Otherwise, the ifcounter is set to zero
- さもなければ、ifcounterはゼロに用意ができています。
- RIP also maintains a timer, called the resettimer
below. Poison reverse is done on all routes
whenever resettimer has not expired (regardless of
- resettimerは、以下にまた、RIPがタイマを維持すると呼びました。 にかかわらずresettimerが期限が切れていないときはいつも、すべてのルートで毒逆をする、(。
Almquist & Kastenholz [Page 115] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[115ページ]RFC1716
the ifcounter values).
ifcounter値)
- When RIP is started, restarted, reset, or otherwise
has its routing table cleared, it sets the
resettimer to go off in Rl seconds.
- RIPが始められて、再開しているリセットである、またはそうでなければ、経路指定テーブルをきれいにさせるとき、それは、resettimerにRl秒に去るように設定します。
The second algorithm is identical to the first except
that:
それを除いて、2番目のアルゴリズムは1日と同じです:
- The rules which set the ifcounter to non-zero values
are changed to always set it to Rl/Tu, and
- そしていつもRl/トゥにそれを設定するために非ゼロ値にifcounterを設定する規則を変える。
- The resettimer is eliminated.
- resettimerは排除されます。
Triggered updates: [ROUTE:3], pp. 15-16; pp. 29
引き起こされたアップデート: [ROUTE: 3]、ページ 15-16; ページ 29
Triggered updates (also called flash updates) are a
mechanism for immediately notifying a router's
neighbors when the router adds or deletes routes or
changes their metrics. A router MUST send a triggered
update when routes are deleted or their metrics are
increased. A router MAY send a triggered update when
routes are added or their metrics decreased.
引き起こされたアップデート(また、フラッシュ最新版と呼ばれる)は、ルータが加えるか、ルートを削除するか、またはすぐにそれらの測定基準を変えるときルータの隣人に通知するためのメカニズムです。 ルートが削除されるか、またはそれらの測定基準が増加されているとき、ルータは引き起こされたアップデートを送らなければなりません。 ルートが加えられたか、またはそれらの測定基準が減少したとき、ルータは引き起こされたアップデートを送るかもしれません。
Since triggered updates can cause excessive routing
overhead, implementations MUST use the following
mechanism to limit the frequency of triggered updates:
引き起こされたアップデートが過度のルーティングオーバーヘッドを引き起こす場合があるので、実現は引き起こされたアップデートの頻度を制限するのに以下のメカニズムを使用しなければなりません:
(1) When a router sends a triggered update, it sets a
timer to a random time between one and five
seconds in the future. The router must not
generate additional triggered updates before this
timer expires.
(1) ルータが将来引き起こされたアップデートを送るとき、1〜5秒の無作為の時間にタイマを設定します。 このタイマが期限が切れる前にルータは追加引き起こされたアップデートを発生させてはいけません。
(2) If the router would generate a triggered update
during this interval it sets a flag indicating
that a triggered update is desired. The router
also logs the desired triggered update.
(2) ルータがこの間隔の間、引き起こされたアップデートを発生させるなら、それは、旗が、引き起こされたアップデートが望まれているのを示すように設定します。 また、ルータは必要な引き起こされたアップデートを登録します。
(3) When the triggered update timer expires, the
router checks the triggered update flag. If the
flag is set then the router sends a single
triggered update which includes all of the changes
that were logged. The router then clears the flag
and, since a triggered update was sent, restarts
this algorithm.
(3) 引き起こされたアップデートタイマが期限が切れると、ルータは引き起こされたアップデート旗をチェックします。 旗が設定されるなら、ルータは登録された変化のすべてを含んでいるただ一つの引き起こされたアップデートを送ります。 ルータは、次に、旗をきれいにして、引き起こされたアップデートを送ったので、このアルゴリズムを再開します。
Almquist & Kastenholz [Page 116] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[116ページ]RFC1716
(4) The flag is also cleared whenever a regular update
is sent.
(4) また、定期的なアップデートを送るときはいつも、旗はきれいにされます。
Triggered updates SHOULD include all routes that have
changed since the most recent regular (non-triggered)
update. Triggered updates MUST NOT include routes that
have not changed since the most recent regular update.
引き起こされたアップデートSHOULDは最新の定期的な(非引き起こされた)アップデート以来変化しているすべてのルートを含んでいます。 引き起こされたアップデートは最新の定期的なアップデート以来変化していないルートを含んではいけません。
DISCUSSION:
Sending all routes, whether they have changed
recently or not, is unacceptable in triggered
updates because the tremendous size of many Internet
routing tables could otherwise result in
considerable bandwidth being wasted on triggered
updates.
議論: そうでなければ、多くのインターネット経路指定テーブルの物凄いサイズが引き起こされたアップデートに浪費されるかなりの帯域幅をもたらすかもしれないので、それらが最近変化したか否かに関係なく、すべてのルートを送るのは引き起こされたアップデートにおいて容認できません。
Use of UDP: [ROUTE:3], pp. 18-19.
UDPの使用: [ROUTE: 3]、ページ 18-19.
RIP packets sent to an IP broadcast address SHOULD have
their initial TTL set to one.
IP放送アドレスSHOULDに送られたRIPパケットで、それらの初期のTTLを1つに用意ができさせます。
Note that to comply with Section [6.1] of this memo, a
router MUST use UDP checksums in RIP packets which it
originates, MUST discard RIP packets received with
invalid UDP checksums, but MUST not discard received
RIP packets simply because they do not contain UDP
checksums.
ルータがこのメモのセクション[6.1]に従うために、それが溯源するRIPパケットでUDPチェックサムを使用しなければなりませんが、無効のUDPチェックサムで受け取られたRIPパケットを捨てなければなりませんが、単にUDPチェックサムを含んでいないので容認されたRIPパケットは捨ててはいけないことに注意してください。
Addressing Considerations: [ROUTE:3], pp. 22
アドレシング問題: [ROUTE: 3]、ページ 22
A RIP implementation SHOULD support host routes. If it
does not, it MUST (as described on page 27 of
[ROUTE:3]) ignore host routes in received updates. A
router MAY log ignored hosts routes.
SHOULDサポートホストが発送するRIP実現。 そうしないなら、それは容認されたアップデートでホストルートを無視しなければなりません(27[ROUTE: 3]ページで説明されるように)。 ルータは無視されたホストのためにルートを登録するかもしれません。
The special address 0.0.0.0 is used to describe a
default route. A default route is used as the route of
last resort (i.e. when a route to the specific net does
not exist in the routing table). The router MUST be
able to create a RIP entry for the address 0.0.0.0.
.0が使用されている特別なアドレス0.0.0はデフォルトルートを説明します。 デフォルトルートは切り札のルートとして使用されます(すなわち、特定のネットへのルートはいつ経路指定テーブルに存在しませんか)。 ルータは.0にアドレス0.0.0のためのRIPエントリーを作成できなければなりません。
Input Processing - Response: [ROUTE:3], pp. 26
処理--応答を入力してください: [ROUTE: 3]、ページ 26
When processing an update, the following validity
checks MUST be performed:
アップデートを処理するとき、以下のバリディティチェックを実行しなければなりません:
o The response MUST be from UDP port 520.
o 応答はUDPポート520から来ているに違いありません。
Almquist & Kastenholz [Page 117] RFC 1716 Towards Requirements for IP Routers November 1994
IPルータ1994年11月のための要件に向かったAlmquist&Kastenholz[117ページ]RFC1716
o The source address MUST be on a directly connected
subnet (or on a directly connected, non-subnetted
network) to be considered valid.
o 有効であると考えられるために、ソースアドレスは直接接続されたサブネット(または直接接続された非サブネット化したネットワークで)にあるに違いありません。
o The source address MUST NOT be one of the router's
addresses.
o ソースアドレスはルータのアドレスの1つであるはずがありません。
DISCUSSION:
Some networks, media, and interfaces allow a
sending node to receive packets that it
broadcasts. A router must not accept its own
packets as valid routing updates and process
them. The last requirement prevents a router
from accepting its own routing updates and
processing them (on the assumption that they were
sent by some other router on the network).
議論: いくつかのネットワーク、メディア、およびインタフェースで、送付ノードはそれが放送するパケットを受けることができます。 ルータは、有効であるとしてのアップデートを発送するそれ自身のパケットを受け入れて、それらを処理してはいけません。 最後の要件は、ルータがそれ自身のルーティングアップデートを受け入れて、それらを処理するのを(ネットワークのある他のルータでそれらを送ったという前提で)防ぎます。
An implementation MUST NOT replace an existing route if
the metric received is equal to the existing metric
except in accordance with the following heuristic.
受け取られたメートル法が以下のヒューリスティック以外の、メートル法の存在と等しいなら、実現は既存のルートに取って代わってはいけません。
一覧
スポンサーリンク
