RFC4036 日本語訳
4036 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for SubscriberManagement. W. Sawyer. April 2005. (Format: TXT=57946 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Sawyer Request for Comments: 4036 April 2005 Category: Standards Track
コメントを求めるワーキンググループW.木挽き要求をネットワークでつないでください: 4036 2005年4月のカテゴリ: 標準化過程
Management Information Base for
Data Over Cable Service Interface Specification (DOCSIS)
Cable Modem Termination Systems for Subscriber Management
加入者管理のケーブルサービスインターフェース仕様(DOCSIS)ケーブルモデム終了システムの上のデータのための管理情報ベース
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それはData過剰Cable Service Interface Specification(DOCSIS)の言いなりになっているCable Modem Termination SystemsのSimple Network Managementのプロトコルの(SNMP)を拠点とする管理のために1セットの管理オブジェクトを定義します。これらの管理オブジェクトは加入者による誤用からケーブルネットワークの保護を容易にします。 Differentiated Services MIB(RFC3289)はここで必要であったフィルタ機能を提供します、この仕様に基づき定義された分類項目を利用して。
Table of Contents
目次
1. The Internet-Standard Management Framework.................... 2
2. Conventions................................................... 2
3. Overview...................................................... 2
3.1. Structure of the MIB.................................... 4
3.1.1. docsSubMgtFilterGroupTable...................... 4
3.1.2. IPv4 Compliance................................. 5
3.2. Management Requirements................................. 5
3.2.1. Interaction with DOCSIS Provisioning for CPE
Address Control................................. 6
3.2.2. Interaction with DOCSIS Provisioning for
Filtering....................................... 6
3.2.3. Distinguishing Modem from Subscriber Traffic.... 7
1. インターネット標準の管理フレームワーク… 2 2. コンベンション… 2 3. 概要… 2 3.1. MIBの構造… 4 3.1.1docsSubMgtFilterGroupTable… 4 3.1.2. IPv4コンプライアンス… 5 3.2. 管理要件… 5 3.2.1. CPEのためにアドレス制御に食糧を供給するDOCSISとの相互作用… 6 3.2.2. フィルタリングのためのDOCSISの食糧を供給するとの相互作用… 6 3.2.3. 加入者トラフィックとモデムを区別します… 7
Sawyer Standards Track [Page 1] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[1ページ]。
3.3. Relationship to the Differentiated Services MIB
[RFC3289]............................................... 7
3.3.1. Using the Filter Group to Extend Packet
Classification.................................. 8
3.3.2. Interface Usage................................. 8
3.4. Filtering and the Tiny Fragment Attack.................. 9
4. Definitions................................................... 9
5. Acknowledgements.............................................. 23
6. IANA Considerations........................................... 23
7. Normative References.......................................... 23
8. Informative References........................................ 24
9. Security Considerations....................................... 25
Author's Address.................................................. 26
Full Copyright Statement.......................................... 27
3.3. 差別化されたサービスMIB[RFC3289]との関係… 7 3.3.1. フィルタを使用して、分類して、パケット分類を広げてください… 8 3.3.2. 用法を連結してください… 8 3.4. フィルタリングと小さい断片は攻撃されます… 9 4. 定義… 9 5. 承認… 23 6. IANA問題… 23 7. 標準の参照… 23 8. 有益な参照… 24 9. セキュリティ問題… 25作者のアドレス… 26 完全な著作権宣言文… 27
1. The Internet-Standard Management Framework
1. インターネット標準の管理フレームワーク
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
現在のインターネット標準のManagement Frameworkについて説明するドキュメントの詳細な概要について、RFC3410[RFC3410]のセクション7を参照してください。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 一般に、MIBオブジェクトはSimple Network Managementプロトコル(SNMP)を通してアクセスされます。 MIBのオブジェクトは、Management情報(SMI)のStructureで定義されたメカニズムを使用することで定義されます。 このメモはSTD58とRFC2578[RFC2578]とSTD58とRFC2579[RFC2579]とSTD58RFC2580[RFC2580]で説明されるSMIv2に対応であるMIBモジュールを指定します。
2. Conventions
2. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
3. Overview
3. 概要
This MIB module provides a set of objects required for the management of DOCSIS Cable Modem Termination Systems (CMTS). The specification is derived in part from the operational model described in the DOCSIS Radio Frequency Interface Specification [ITU-T-J122]. These managed objects facilitate protection of the cable network from misuse by subscribers. This misuse might include, for example, address spoofing, service spoofing, or operation of unauthorized services.
このMIBモジュールはDOCSIS Cable Modem Termination Systems(CMTS)の管理に必要である1セットのオブジェクトを提供します。 DOCSIS Radio Frequency Interface Specification[ITU-T-J122]で説明されたオペレーショナル・モデルから仕様を一部得ます。 これらの管理オブジェクトは加入者による誤用からケーブルネットワークの保護を容易にします。 この誤用は例えば権限がなくサービスのアドレススプーフィング、サービススプーフィング、または操作を含むかもしれません。
Sawyer Standards Track [Page 2] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[2ページ]。
The following figure illustrates the operational and physical deployment relationships between elements in a cable modem network. This MIB module resides at the CMTS, which is the first point in the public data network at which the cable operator controls physical access. The CMTS (possibly assisted by other IP service devices) acts as a network edge, separating the physical outside-plant cable television network from the operator's IP network.
以下の図はケーブルモデムネットワークで要素の間の操作上的、そして、物理的な展開関係を例証します。 このMIBモジュールが中の公衆データがネットワークでつなぐ最初のポイントであるCMTSに住んでいる、どれ、ケーブル操作員制御身体検査アクセサリー CMTS(ことによると他のIPサービスデバイスによって補助される)はネットワーク縁として機能します、オペレータのIPネットワークとプラントの外の物理的なケーブルテレビネットワークを切り離して。
| operator's IP network
+------+ ---------------------
| CMTS | operator's cable head-end
+------+ ---------------------
|
+--------+--------+ CATV physical network
| | |
+----+ +----+ +----+ ------------------
| CM | | CM | | CM | subscriber premises
+----+ +----+ +----+ ------------------
| | | subscriber host or network
| オペレータのIPネットワーク+------+ --------------------- | CMTS| オペレータのケーブルギヤエンドの+------+ --------------------- | +--------+--------+ CATV物理ネットワーク| | | +----+ +----+ +----+ ------------------ | CM| | CM| | CM| 加入者構内+----+ +----+ +----+ ------------------ | | | 加入者ホストかネットワーク
This MIB module controls IP packet forwarding to and from each cable modem, at the CMTS. Different modems may be accorded different treatment.
このMIBモジュールはケーブルモデムとCMTSの各ケーブルモデムからIPパケット推進を制御します。 異なった処理は異なったモデムに与えられるかもしれません。
Much of this module duplicates capabilities found in the DOCSIS Cable Device MIB [RFC2669]. Although it is expected that the Cable Device MIB will be used to prevent unwanted traffic from entering the cable network, it is also possible that a malicious user might tamper with cable modem software, disabling its filtering policies. This MIB provides a more secure mechanism, as physical access to the CMTS is controlled by the network operator.
このモジュールの多くがDOCSIS Cable Device MIB[RFC2669]で見つけられた能力をコピーします。 Cable Device MIBが求められていないトラフィックがケーブルネットワークに入るのを防ぐのに使用されると予想されますが、また、悪意あるユーザーがケーブルモデムソフトウェアをいじるのも、可能です、方針をフィルターにかけると無効にして。 CMTSへの物理的なアクセスがネットワーク・オペレータによって制御されるとき、このMIBは、より安全なメカニズムを提供します。
In particular, this MIB provides two capabilities: first, to limit the IP addresses behind a modem, and second, to provide address and protocol filtering to and from a modem. The first duplicates the capabilities of the docsDevCpe group [RFC2669]. This provides for either learned or provisioned subscriber premises host IP addresses behind a cable modem.
特に、このMIBは2つの能力を提供します: まず最初に、IPを制限するのは、モデムとモデムからアドレスとプロトコルフィルタリングを提供するために後ろでモデム、および2番目を扱います。 docsDevCpeの能力が分類する最初の写し[RFC2669]。 これはホストIPがケーブルモデムの後ろで扱う学術的であるか食糧を供給された加入者構内に備えます。
The address and protocol filtering capability is similar to that performed by the cable modem itself. It differs in several respects because it is intended to control subscriber traffic at the CMTS, rather than at the individual CM. First, the MIB structure must be indexed appropriately at the CMTS to indicate which cable modem subscriber is intended. Second, rather than maintaining a separate list of filters for each modem at the CMTS, it is assumed that large numbers of modems will share filtering characteristics. Therefore, modems are grouped so as to share common filter lists.
アドレスとプロトコルフィルタリング能力はケーブルモデム自体によって実行されたそれと同様です。 個々のCMでというよりむしろCMTSで加入者トラフィックを制御するのが意図しているので、それはいくつかの点において異なります。 まず最初に、どのケーブルモデム加入者が意図するかを示すためにCMTSで適切にMIB構造に索引をつけなければなりません。 CMTSの各モデムのためにフィルタの別々のリストを維持するより2番目に、むしろ、多くのモデムがろ過特性を共有すると思われます。 したがって、モデムは、一般的なフィルタリストを共有するために分類されます。
Sawyer Standards Track [Page 3] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[3ページ]。
The filtering capability is implemented using the Classification, Counting, and Drop facilities of the Differentiated Services MIB [RFC3289]. In order to provide different filtering for various classes of subscribers, this MIB defines the docsSubMgtFilterGroupTable, which specifies which filters apply to each subscriber packet. This table is used by RFC 3289 as a first pass of classification, and also to choose a second pass of classification using the diffServMultiFieldClfrTable:
フィルタリング能力はDifferentiated Services MIBのClassificationを使用して、Countingと、Drop施設であると実装されます[RFC3289]。 様々なクラスの加入者に異なったフィルタリングを提供するために、このMIBはdocsSubMgtFilterGroupTableを定義します。(docsSubMgtFilterGroupTableは、どのフィルタがそれぞれの加入者パケットに適用されるかを指定します)。 このテーブルは分類の最初のパスとしてRFC3289によって使用されます、そして、また、2番目を選ぶには、分類がdiffServMultiFieldClfrTableを使用するのを通過してください:
diffServDataPathStart --> diffServClfrEntry(1)
diffServClfrElementSpecific(1) --> docsSubMgtFilterGroupIndex
diffServClfrElementNext(1) --> diffServClfrEntry(2)
diffServClfrElementSpecific(2)--> diffServMultiFieldClfrEntry
diffServClfrElementNext(2) --> difServActionEntry (count or algDrop)
diffServDataPathStart-->diffServClfrEntry(1) diffServClfrElementSpecific(1)-->docsSubMgtFilterGroupIndex diffServClfrElementNext(1)-->diffServClfrEntry(2) diffServClfrElementSpecific(2)-->diffServMultiFieldClfrEntry diffServClfrElementNext(2)-->difServActionEntry(カウントかalgDrop)
Because it is assumed that large numbers of modems will share filtering characteristics, DOCSIS signaling defines filter groups according to which cable modems share common filter lists. The operator creates references to these groups in the diffServClfrElementSpecific(1) entries above.
多くのモデムがろ過特性を共有すると思われるので、DOCSISシグナリングはフィルタグループをケーブルモデムが一般的なフィルタリストを共有する定義します。 オペレータは上のdiffServClfrElementSpecific(1)エントリーでこれらのグループの参照を作成します。
3.1. Structure of the MIB
3.1. MIBの構造
This MIB is structured in four tables:
このMIBは4個のテーブルで構造化されます:
o The docsSubMgtCpeControlTable controls the acceptance of
subscriber host addresses behind a cable modem.
o docsSubMgtCpeControlTableはケーブルモデムの後ろで加入者ホスト・アドレスの承認を制御します。
o The docsSubMgtCpeIpTable monitors the subscriber host addresses
that the CMTS believes exist behind the cable modem.
o docsSubMgtCpeIpTableはCMTSがケーブルモデムの後ろに存在すると信じている加入者ホスト・アドレスをモニターします。
o The docsSubMgtCmFilterTable binds a cable modem to a set of
filters in diffServMultiFieldClfrTable.
o docsSubMgtCmFilterTableはdiffServMultiFieldClfrTableの1セットのフィルタにケーブルモデムを縛ります。
o The docsSubMgtFilterGroupTable provides the OIDs by which the
diffServClfrElementTable selects a filter group.
o docsSubMgtFilterGroupTableはdiffServClfrElementTableがフィルタグループを選択するOIDsを提供します。
The docsSubMgtCpeControlTable and docsSubMgtCmFilterTable AUGMENT the docsIfCmtsCmStatusTable from [RFC2670]. Similarly, docsSubMgtCpeIpTable expands this table (an additional index is used). As such, each entry in these tables is bound to a registered cable modem, as perceived by the CMTS.
docsSubMgtCpeControlTableとdocsSubMgtCmFilterTableは[RFC2670]からdocsIfCmtsCmStatusTableを増大させます。 同様に、docsSubMgtCpeIpTableはこのテーブルを広げます(追加インデックスは使用されています)。 そういうものとして、CMTSによって知覚されるようにこれらのテーブルの各エントリーは登録されたケーブルモデムに縛られます。
3.1.1. docsSubMgtFilterGroupTable
3.1.1. docsSubMgtFilterGroupTable
The docsSubMgtFilterGroupTable links the filter group (signaled by DOCSIS as a small integer) to the diffServClfrElementEntry for the first pass of filter classification. diffServClfrElementSpecific
docsSubMgtFilterGroupTableはフィルタ分類diffServClfrElementSpecificの最初のパスのために、フィルタグループ(わずかな整数としてDOCSISによって合図される)をdiffServClfrElementEntryにリンクします。
Sawyer Standards Track [Page 4] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[4ページ]。
requires a RowPointer. Thus, this table exists to provide referenced objects for diffServClfrElementSpecific. The classification method is as follows:
RowPointerを必要とします。 したがって、このテーブルは、参照をつけられたオブジェクトをdiffServClfrElementSpecificに供給するために存在しています。 分類メソッドは以下の通りです:
o Use the DOCSIS filter group, as inferred from the sending or
receiving modem, as the classification criterion.
o 分類評価基準として送付か受信モデムから推論されるようにDOCSISフィルタグループを使用してください。
o Use docsSubMgtFilterGroupIndex as the value to match.
o 合うのに値としてdocsSubMgtFilterGroupIndexを使用してください。
An entry exists in this Table if a reference to it exists in diffServClfrElementSpecific.
それの参照がdiffServClfrElementSpecificに存在しているなら、エントリーはこのTableに存在しています。
As such, contrary to common practice, the index for the table is read-only and is both the Entry's index and its only value.
そういうものとして、テーブルのためのインデックスは、一般的な習慣とは逆の書き込み禁止であり、Entryのインデックスとその唯一の値の両方です。
3.1.2. IPv4 Compliance
3.1.2. IPv4コンプライアンス
Please note that the compliance statements in this version of the MIB module require support only for IPv4 addresses. That is because the current version of the DOCSIS protocols (1.0, 1.1, and 2.0) are not IPv6 capable. Although support for IPv6 will require changes to the DOCSIS protocols, it is expected that the only changes to the MIB module itself will be the addition of new compliance statements that mandate support for IPv6 addresses. All IP addresses that appear in this document conform to the textual conventions specified in [RFC4001].
MIBモジュールのこのバージョンでの承諾声明はIPv4アドレスにだけ支持を要します。 それはDOCSISプロトコル(1.0、1.1、および2.0)の最新版ができるIPv6でないからです。 IPv6のサポートはDOCSISプロトコルへの変化を必要とするでしょうが、MIBモジュール自体への唯一の変化が命令がIPv6のためにアドレスをサポートするという新しい承諾声明の追加になると予想されます。 現れるすべてのIPアドレスが本書では[RFC4001]で指定された原文のコンベンションに従います。
3.2. Management Requirements
3.2. 管理要件
The DOCSIS cable modem provisioning model [ITU-T-J122] requires that cable modems use TFTP to acquire a list of parameters. The modem then passes many of these parameters to the CMTS in the DOCSIS Registration message. The parameter values are digitally signed by the creator of the TFTP contents, and the signature is verified by the CMTS. In general, then, the CMTS itself need not be configured with the attributes of its cable modems. It will acquire these values through the Registration process that is secured by the digital signature.
モデル[ITU-T-J122]に食糧を供給するDOCSISケーブルモデムは、ケーブルモデムがパラメタのリストを取得するのにTFTPを使用するのを必要とします。 そして、モデムはこれらのパラメタの多くをDOCSIS RegistrationメッセージのCMTSに通過します。 パラメタ値はTFTPコンテンツのクリエイターによってデジタルに署名されます、そして、署名はCMTSによって確かめられます。 一般に、次に、CMTS自身はケーブルモデムの属性によって構成される必要はありません。それはデジタル署名で機密保護されるRegistrationプロセスを通してこれらの値を取得するでしょう。
Cable modem subscriber management, as described here, modifies this process slightly to reduce data and to ease administrative control. Filtering criteria, for example, are maintained through SNMP at the CMTS, and the modem registration merely signals the index values for the rows that apply to that modem.
ここで説明されるケーブルモデム加入者経営者側は、データを減らして、運営管理コントロールを緩和するようにこのプロセスをわずかに変更します。 例えばフィルタリング評価基準はCMTSのSNMPを通して維持されます、そして、モデム登録はそのモデムに適用される行のために単にインデックス値を示します。
Sawyer Standards Track [Page 5] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[5ページ]。
3.2.1. Interaction with DOCSIS Provisioning for CPE Address Control
3.2.1. CPEのためにアドレス制御に食糧を供給するDOCSISとの相互作用
The CMTS creates rows in docsSubMgtCpeControlTable for each modem as a result of the DOCSIS registration process. The DOCSIS registration attributes may include items semantically equivalent to those in the docsDevCpe section of the DOCSIS Cable Device MIB [RFC2669]:
CMTSはDOCSIS登録手続の結果、各モデムのためにdocsSubMgtCpeControlTableの行を作成します。 DOCSIS登録属性はDOCSIS Cable Device MIB[RFC2669]のdocsDevCpe部でそれらに意味的に同等な項目を含むかもしれません:
o docsDevCpeEnroll o docsDevCpeIpMax o docsDevCpeIp
o docsDevCpeEnroll o docsDevCpeIpMax o docsDevCpeIp
Successful DOCSIS registration will have the effect of setting the corresponding fields in the docsSubMgtCpeControlTable and the docsSubMgtCpeIpTable. If they are not present at modem registration, the CMTS shall apply the following:
うまくいっているDOCSIS登録には、docsSubMgtCpeControlTableとdocsSubMgtCpeIpTableに対応する分野をはめ込むという効果があるでしょう。 それらがモデム登録で存在していないなら、CMTSは以下を適用するものとします:
o docsSubMgtCpeControlActive <-- docsSubMgtCpeActiveDefault o docsSubMgtCpeControlMaxCpeIp <-- docsSubMgtCpeMaxIpDefault o docsSubMgtCpeControlLearnable <-- docsSubMgtCpeLearnableDefault
o docsSubMgtCpeControlActive<--docsSubMgtCpeActiveDefault o docsSubMgtCpeControlMaxCpeIp<--docsSubMgtCpeMaxIpDefault o docsSubMgtCpeControlLearnable<--docsSubMgtCpeLearnableDefault
Rows in docsSubMgtCpeIpTable are created through any of three ways: DOCSIS registration (as described above), learning by the CMTS, or some unspecified administrative mechanism on the CMTS. The docsDevCpeIpMax table bound applies only to the first two.
docsSubMgtCpeIpTableの通りは3つの方法のどれかで作成されます: DOCSIS登録(上で説明されるように)、CMTSによる学習、またはCMTSの上の何らかの不特定の管理機構。 docsDevCpeIpMaxテーブルバウンドは最初の2だけに適用されます。
The CMTS may learn addresses simply by snooping source IP addresses from traffic originating from each cable modem. Other learning mechanisms (for example, ARP snooping) may be used. The learning mechanism is not defined by this document.
CMTSは、各ケーブルモデムから発するトラフィックから単にソースIPアドレスについて詮索することによって、アドレスを学ぶかもしれません。 他の学習のメカニズム(例えば、ARP詮索)は使用されるかもしれません。 学習のメカニズムはこのドキュメントによって定義されません。
3.2.2. Interaction with DOCSIS Provisioning for Filtering
3.2.2. フィルタリングのためのDOCSISの食糧を供給するとの相互作用
Rows in docsSubMgtCmFilterTable are created by the CMTS for each modem as a result of the DOCSIS registration process. The DOCSIS registration attributes may include four indices (see section C.1.1.18.3 of [ITU-T-J122]):
docsSubMgtCmFilterTableの通りはDOCSIS登録手続の結果、各モデムのためにCMTSによって作成されます。 DOCSIS登録属性が4つのインデックスリストを含むかもしれない、(セクションC.1.1を見てください、.18、.3、[ITU-T-J122)について:
o One identifying the upstream (ingress with respect to the CMTS
interface) filter group for packets originating from the cable
modem (i.e., those packets whose source MAC address matches that
of the cable modem).
o ケーブルモデム(すなわち、ソースMACがマッチがケーブルモデムのものであると扱うそれらのパケット)から発するパケットのために上流(CMTSインタフェースに関するイングレス)のフィルタグループを特定する1つ。
o One identifying the upstream filter group for packets originating
from subscribers attached to the cable modem (i.e., those packets
whose source MAC address does not match that of the cable modem).
o 加入者から発するパケットのために上流のフィルタグループを特定する1つがケーブルモデムに付きました(すなわち、アドレスがソースMACをするそれらのパケットはケーブルモデムのものに合っていません)。
Sawyer Standards Track [Page 6] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[6ページ]。
o One identifying the downstream (egress with respect to the CMTS
interface) filter group for packets destined to the cable modem
(i.e., those packets whose destination MAC address matches that of
the cable modem).
o パケットのために川下(CMTSインタフェースに関する出口)のフィルタグループを特定する1つがケーブルモデム(すなわち、送付先MACアドレスがケーブルモデムのものに合っているそれらのパケット)に運命づけられました。
o One identifying the downstream filter group for packets destined
to subscribers attached to the cable modem (i.e., those packets
whose destination MAC address does not match that of the cable
modem).
o パケットのために川下のフィルタグループを特定する1つがケーブルモデム(すなわち、送付先MACアドレスがケーブルモデムのものに合っていないそれらのパケット)に取り付けられた加入者に運命づけられました。
Successful registration will have the effect of setting docsSubMgtCmFilterCmDownstream, docsSubMgtCmFilterCmUpstream, docsSubMgtCmFilterSubDownstream, and docsSubMgtCmFilterSubUpstream, for that modem (just as if they were set through the SNMP protocol). If the DOCSIS attributes are not present, the four values are set to zero. The effect will be to use the default entry (diffServClfrElementSpecific=zeroDotZero) specified in the diffServClfrElementTable. Note that omission of the DOCSIS-signaled values results in application of the default filtering entry, not in omission of filtering.
うまくいっている登録には、docsSubMgtCmFilterCmDownstream、docsSubMgtCmFilterCmUpstream、docsSubMgtCmFilterSubDownstream、およびdocsSubMgtCmFilterSubUpstreamを設定するという効果があるでしょう、そのモデムのために(まるでまさしくそれらがSNMPプロトコルを通して設定されるかのように)。 DOCSIS属性が存在していないなら、4つの値がゼロに設定されます。 効果はdiffServClfrElementTableで指定されたデフォルトエントリー(diffServClfrElementSpecific=zeroDotZero)を使用することでしょう。 DOCSISによって合図された値の省略がフィルタリングの省略ではなく、エントリーをフィルターにかけるデフォルトの適用をもたらすことに注意してください。
3.2.3. Distinguishing Modem from Subscriber Traffic
3.2.3. 加入者トラフィックとモデムを区別します。
All traffic originating from or destined to a subscriber site is potentially suspect and subject to suppression by the network operator. This is true even if the traffic is ostensibly sourced or sunk by the cable modem itself, rather than by the subscriber hosts behind the modem. To provide more nuanced administrative control, this document allows separate filter policies for modems and hosts. For example, modem policies may limit modems to server subnet - only access while allowing a different scope to subscribers.
加入者サイトに発するか、または運命づけられるすべてのトラフィックが、ネットワーク・オペレータによる抑圧を潜在的に疑わしくて、受けることがあります。 トラフィックがモデムの後ろの加入者ホストでというよりむしろケーブルモデム自体によって表面上出典を明示される、または沈められても、これは本当です。 より微妙な違いがある運営管理コントロールを提供するために、このドキュメントはモデムとホストのための別々のフィルタ方針を許容します。 例えば、モデム方針はモデムをサーバサブネットに制限するかもしれません--異なった範囲を加入者に許容している間のアクセスだけ。
The CMTS chooses the filter set to apply based solely on the MAC address (source MAC upstream, destination MAC downstream). If the MAC address matches that of the modem, then the docsSubMgtCmFilterCmUp/Downstream pair is used; otherwise, the docsSubMgtCmFilterSubUp/Downstream pair is applied.
CMTSは、唯一MACアドレス(ソースMAC上流、目的地のMAC川下)に基づいた状態で適用するためにフィルタセットを選びます。 MACが、マッチがモデムのものであると扱うなら、docsSubMgtCmFilterCmUp/川下組は使用されています。 さもなければ、docsSubMgtCmFilterSubUp/川下組は適用されています。
If the CM acts as a router rather than as a DOCSIS bridging forwarder, then the network operator will only use the docsSubMgtCmFilterCmUp/Downstream pair.
CMがDOCSISのブリッジしている混載業者としてというよりむしろルータとして機能すると、ネットワーク・オペレータはdocsSubMgtCmFilterCmUp/川下組を使用するだけでしょう。
3.3. Relationship to the Differentiated Services MIB [RFC3289]
3.3. 差別化されたサービスMIBとの関係[RFC3289]
DOCSIS CMTSes rely on the classification, counting, and drop facilities of the Differentiated Services MIB to screen subscriber packets for IP, TCP, and UDP characteristics. It is expected that
DOCSIS CMTSesは、IP、TCP、およびUDPの特性のために加入者パケットをスクリーニングするためにDifferentiated Services MIBの分類、勘定、および低下施設に依存します。 それが予想される、それ
Sawyer Standards Track [Page 7] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[7ページ]。
any implementation of this MIB also includes at least the following from RFC 3289:
また、このMIBのどんな実装もRFC3289からの少なくとも以下を含んでいます:
o diffServDataPathTable o diffServClfrTable o diffServClfrElementTable o diffServMultiFieldClfrTable o diffServActionTable o diffServCountActTable o diffServAlgDropTable (diffServAlgDropType=alwaysDrop)
o diffServDataPathTable o diffServClfrTable o diffServClfrElementTable o diffServMultiFieldClfrTable o diffServActionTable o diffServCountActTable o diffServAlgDropTable(diffServAlgDropType=alwaysDrop)
The corresponding "next-free" objects are also required.
また、対応する「次なし」のオブジェクトが必要です。
The use of other facilities from RFC 3289 is not precluded but is beyond the scope of this specification.
RFC3289からの他の施設の使用は、排除されませんが、この仕様の範囲を超えています。
3.3.1. Using the Filter Group to Extend Packet Classification
3.3.1. パケット分類を広げるのにフィルタグループを使用します。
The base capability of RFC 3289 assumes that all packets on the same direction of the same interface will be classified by the same criteria. Filter Groups, which are introduced in this document, expand on RFC 3289 to allow various subscribers to receive different classification (filtering) treatment. One way to view filter groups is as sub-interfaces within the physical DOCSIS channel. Another way to view them is as values of a field logically prepended to the packet prior to classification:
RFC3289のベース能力は、同じインタフェースの同じ方向のすべてのパケットが同じ評価基準によって分類されると仮定します。 フィルタGroups(本書では導入される)は、様々な加入者が異なった分類(フィルターにかける)処理を受け取るのを許容するためにRFC3289について詳述します。 物理的なDOCSISチャンネルの中にフィルタグループを見る1つの方法が同じくらいサブインタフェースです。 分類の前に、パケットに論理的にprependedされた分野の値としてそれらを見る別の方法があります:
[filter group][DOCSIS MAC header][IP header]...
[フィルタグループ] [DOCSIS MACヘッダー] [IPヘッダー]…
Of course this 'logical' field has no existence outside of the CMTS.
もちろん、この'論理的な'分野はCMTSの外に存在を全く持っていません。
The diffServClfrTable and diffServClfrElementTable are then used twice: the first classifiers select among filter groups, using OIDs from docsSubMgtFilterGroupTable. The 'next' action on matching a filter group is to select a diffServClfrEntry that now classifies on IP/TCP/UDP criteria (the diffServMultiFieldClfrTable). The 'next' action on this second match may be a 'count' (and accept), a 'drop', or some other feature from RFC 3289.
次に、diffServClfrTableとdiffServClfrElementTableは二度使用されます: docsSubMgtFilterGroupTableからOIDsを使用して、最初のクラシファイアはフィルタの中でグループを選択します。 フィルタグループを合わせることへの'次'の動作は現在IP/TCP/UDPで評価基準(diffServMultiFieldClfrTable)を分類するdiffServClfrEntryを選択することです。 この2番目のマッチへの'次'の動作は、'カウント'(受け入れる)、'低下'、またはRFC3289からのある他の特徴であるかもしれません。
3.3.2. Interface Usage
3.3.2. インタフェース用法
For the purposes of DOCSIS subscriber management, only the DOCSIS MAC cable interface(s) are used. The interface appears as the index to diffServDataPathEntry, which is the starting point for diffserv MIB table traversal.
DOCSIS加入者管理の目的のために、DOCSIS MACケーブルインタフェースだけが使用されています。 インタフェースはインデックスとしてdiffServDataPathEntryにおいて現れます。(diffServDataPathEntryはdiffserv MIBテーブル縦断のための出発点です)。
Sawyer Standards Track [Page 8] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[8ページ]。
The use of the diffserv MIB for other purposes, both on the DOCSIS MAC interfaces and on other network interfaces, is not precluded by this document.
DOCSIS MACインタフェースの上と、そして、他の目的と、他のネットワーク・インターフェースにおけるdiffserv MIBの使用はこのドキュメントによって排除されません。
3.4. Filtering and the Tiny Fragment Attack
3.4. フィルタリングと小さい断片攻撃
It is recommended that the implementers prevent the "tiny fragment" and "overlapping fragment" attacks for the TCP filtering tables in this MIB, as discussed in RFC 1858 [RFC1858] and RFC 3128 [RFC3128].
implementersがこのMIBでテーブルをフィルターにかけるTCPのために「小さい断片」と「重なっている断片」攻撃を防ぐのは、お勧めです、RFC1858[RFC1858]とRFC3128[RFC3128]で議論するように。
Prevention of these attacks can be implemented with the following rules, when filtering is enabled:
フィルタリングが可能にされるとき、以下の規則でこれらの攻撃の防止を実装することができます:
o Admit all packets with fragment offset >= 2.
o 断片があるすべてのパケットが>=2を相殺することを認めてください。
o Discard all packets with fragment offset = 1, or with fragment
offset = 0 AND fragment payload length < 16.
o 断片オフセット=1か、断片オフセット=0と断片ペイロード長<16ですべてのパケットを捨ててください。
o Apply filtering rules to all packets with fragment offset = 0.
o 断片オフセット=0ですべてのパケットに規則をフィルターにかけて、適用してください。
4. Definitions
4. 定義
DOCS-IETF-SUBMGT-MIB DEFINITIONS ::= BEGIN
DOCS-IETF-SUBMGT-MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
Integer32,
mib-2
FROM SNMPv2-SMI
RowStatus,
TruthValue,
TimeStamp,
StorageType
FROM SNMPv2-TC
OBJECT-GROUP,
MODULE-COMPLIANCE
FROM SNMPv2-CONF
InetAddressType,
InetAddress
FROM INET-ADDRESS-MIB
docsIfCmtsCmStatusIndex,
docsIfCmtsCmStatusEntry
FROM DOCS-IF-MIB -- RFC2670
diffServMIBDataPathGroup,
diffServMIBClfrGroup,
diffServMIBClfrElementGroup,
diffServMIBMultiFieldClfrGroup,
IMPORTS MODULE-IDENTITY、OBJECT-TYPE、Integer32、mib-2 FROM SNMPv2-SMI RowStatus、TruthValue、TimeStamp、StorageType FROM SNMPv2-TC OBJECT-GROUP、MODULE-COMPLIANCE FROM SNMPv2-CONF InetAddressType、InetAddress FROM INET-ADDRESS-MIB docsIfCmtsCmStatusIndex、docsIfCmtsCmStatusEntry FROM DOCS、MIBである、--RFC2670 diffServMIBDataPathGroup、diffServMIBClfrGroup、diffServMIBClfrElementGroup、diffServMIBMultiFieldClfrGroup
Sawyer Standards Track [Page 9] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[9ページ]。
diffServMIBActionGroup,
diffServMIBAlgDropGroup,
diffServMIBCounterGroup,
diffServDataPathStatus,
diffServClfrStatus,
diffServClfrElementStatus,
diffServMultiFieldClfrAddrType,
diffServMultiFieldClfrSrcAddr,
diffServMultiFieldClfrDstAddr,
diffServAlgDropStatus,
diffServDataPathStorage,
diffServClfrStorage,
diffServClfrElementStorage,
diffServMultiFieldClfrStorage,
diffServActionStorage,
diffServCountActStorage,
diffServAlgDropStorage,
diffServAlgDropType
FROM DIFFSERV-MIB -- RFC3289
;
DIFFSERV-MIB(RFC3289)からのdiffServMIBActionGroup、diffServMIBAlgDropGroup、diffServMIBCounterGroup、diffServDataPathStatus、diffServClfrStatus、diffServClfrElementStatus、diffServMultiFieldClfrAddrType、diffServMultiFieldClfrSrcAddr、diffServMultiFieldClfrDstAddr、diffServAlgDropStatus、diffServDataPathStorage、diffServClfrStorage、diffServClfrElementStorage、diffServMultiFieldClfrStorage、diffServActionStorage、diffServCountActStorage、diffServAlgDropStorage、diffServAlgDropType
docsSubMgt MODULE-IDENTITY
LAST-UPDATED "200503290000Z" -- March 29, 2005
ORGANIZATION "IETF IP over Cable Data Network (IPCDN) Working
Group"
CONTACT-INFO
" Wilson Sawyer
Postal: 50 Kelly Brook Lane
East Hampstead, NH 03826
U.S.A.
docsSubMgtモジュールアイデンティティは"200503290000Z"をアップデートしました--、2005年3月29日組織「ケーブルデータ網(IPCDN)作業部会の上のIETF IP」コンタクトインフォメーション、「ウィルソン・ソーヤーPostal:、」 50 ケリーブルック東ハムステッド、レーンニューハンプシャー03826米国
Phone: +1 603 382 7080
E-mail: wsawyer@ieee.org
以下に電話をしてください。 +1 7080年の603 382メール: wsawyer@ieee.org
IETF IPCDN Working Group
General Discussion: ipcdn@ietf.org
Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn
Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn
Co-chairs: Richard Woundy, Richard_Woundy@cable.comcast.com
Jean-Francois Mule, jf.mule@cablelabs.com"
DESCRIPTION
"This is the CMTS centric subscriber management MIB for
DOCSIS-compliant CMTS. It provides the objects to allow a Cable
Modem Termination operator to control the IP addresses and
protocols associated with subscribers' cable modems.
IETF IPCDNワーキンググループ一般議論: ipcdn@ietf.org は申し込まれます: http://www.ietf.org/mailman/listinfo/ipcdn アーカイブ: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn 共同議長: 「リチャードWoundy、 Richard_Woundy@cable.comcast.com ジャン・フランソワMule、 jf.mule@cablelabs.com 」記述、「これはDOCSIS対応することのCMTSのためのCMTSの中心の加入者管理MIBです」。 それは、Cable Modem Terminationオペレータが加入者のケーブルモデムに関連しているIPアドレスとプロトコルを制御するのを許容するためにオブジェクトを提供します。
Sawyer Standards Track [Page 10] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[10ページ]。
Copyright (C) The Internet Society (2005). This version of this
MIB module is part of RFC 4036; see the RFC itself for full legal
notices."
REVISION "200503290000Z" -- March 29, 2005
DESCRIPTION
"Initial version, published as RFC 4036. Note that the
compliance statements in this version apply only to
implementations that support DOCSIS 1.0/1.1/2.0, which
are not IPv6-capable."
::= { mib-2 125 }
Copyright(C)インターネット協会(2005)。 このMIBモジュールのこのバージョンはRFC4036の一部です。 「完全な法定の通知に関してRFC自身を見てください。」 REVISION"200503290000Z"--「初期のバージョンであって、RFC4036として発行された」2005年3月29日記述。 「このバージョンでの承諾声明が1.0/1.1/2.0のIPv6できないそのサポートDOCSISを実装だけに当てはまることに注意してください。」 ::= mib-2 125
docsSubMgtObjects OBJECT IDENTIFIER ::= { docsSubMgt 1 }
docsSubMgtObjectsオブジェクト識別子:、:= docsSubMgt1
docsSubMgtCpeControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsSubMgtCpeControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table AUGMENTs the docsIfCmtsCmStatusTable, adding
four WRITEable objects, as well as a read-only object, all of
which reflect the state of subscriber management on a particular
CM."
::= { docsSubMgtObjects 1 }
アクセスしやすくないdocsSubMgtCpeControlTable OBJECT-TYPEの現在の記述SYNTAX SEQUENCE OF DocsSubMgtCpeControlEntryマックス-ACCESS STATUS「このテーブルAUGMENTs docsIfCmtsCmStatusTable、4個のWRITEableオブジェクトを加えて、および書き込み禁止オブジェクトのa特定のCM。」そのすべてが加入者管理の状態をよく考えます。 ::= docsSubMgtObjects1
docsSubMgtCpeControlEntry OBJECT-TYPE
SYNTAX DocsSubMgtCpeControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A row in the docsSubMgtCpeControlTable. All values are set
at successful modem registration, either from the system default,
or from objects included in the DOCSIS registration request sent
upstream to the CMTS from the CM. The contents of this entry are
meaningless unless the corresponding docsIfCmtsCmStatusValue (see
reference) is registrationComplete(6). The persistence of this
row is determined solely by the lifespan of the corresponding
docsIfCmtsCmStatusEntry (normally StorageType=volatile)."
「AはdocsSubMgtCpeControlTableでこぐ」docsSubMgtCpeControlEntry OBJECT-TYPE SYNTAX DocsSubMgtCpeControlEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 すべての値がCMからうまくいっているモデム登録において、または、システム・デフォルトか、上流へ送られたDOCSIS登録要求に含まれていたオブジェクトからCMTSに設定されます。 このエントリーの内容は対応するdocsIfCmtsCmStatusValue(参照を見る)がregistrationComplete(6)でないなら無意味です。 「この行の固執は唯一対応するdocsIfCmtsCmStatusEntry(通常StorageType=揮発性の)の寿命で決定します。」
REFERENCE
"RFC 2670"
AUGMENTS { docsIfCmtsCmStatusEntry }
::= {docsSubMgtCpeControlTable 1 }
「RFC2670」という参照はdocsIfCmtsCmStatusEntryを増大させます:、:= docsSubMgtCpeControlTable1
DocsSubMgtCpeControlEntry ::= SEQUENCE
{
docsSubMgtCpeControlMaxCpeIp Integer32,
docsSubMgtCpeControlActive TruthValue,
docsSubMgtCpeControlLearnable TruthValue,
DocsSubMgtCpeControlEntry:、:= 系列、docsSubMgtCpeControlMaxCpeIp Integer32、docsSubMgtCpeControlActive TruthValue、docsSubMgtCpeControlLearnable TruthValue
Sawyer Standards Track [Page 11] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[11ページ]。
docsSubMgtCpeControlReset TruthValue,
docsSubMgtCpeControlLastReset TimeStamp
}
docsSubMgtCpeControlReset TruthValue、docsSubMgtCpeControlLastResetタイムスタンプ
docsSubMgtCpeControlMaxCpeIp OBJECT-TYPE
SYNTAX Integer32(0..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The number of simultaneous IP addresses permitted behind
the CM. If this is set to zero, all CPE traffic from the CM is
dropped. If the provisioning object corresponding to
docsSubMgtCpeIpTable includes more CPE IP address entries for
this modem than the value of this object, then this object is
set to the count of the number of rows in docsSubMgtCpeIpTable
that have the same docsIfCmtsCmStatusIndex value. (For example,
if the CM has 5 IP addresses specified for it, this value is 5.)
This limit applies to learned and DOCSIS-provisioned entries
but not to entries added through some administrative
process at the CMTS. If not set through DOCSIS provisioning,
this object defaults to docsSubMgtCpeMaxIpDefault. Note that
this object is only meaningful if docsSubMgtCpeControlActive
is true."
::= { docsSubMgtCpeControlEntry 1 }
docsSubMgtCpeControlMaxCpeIp OBJECT-TYPE SYNTAX Integer32(0 .2147483647)マックス-ACCESSは「同時のIPアドレスの数はCMの後ろで可能にしたこと」をSTATUSの現在の記述に読書して書きます。 これがゼロに設定されるなら、CMからのすべてのCPEトラフィックが下げられます。 docsSubMgtCpeIpTableに対応する食糧を供給するオブジェクトがこのモデムためのこのオブジェクトの値よりCPE IPアドレスエントリーを含んでいるなら、このオブジェクトは同じdocsIfCmtsCmStatusIndex値を持っているdocsSubMgtCpeIpTableの行の数のカウントに設定されます。 (例えば、CMで5つのIPアドレスをそれに指定するなら、この値は5です。) この限界は、CMTSで学術的でDOCSISによって食糧を供給されたエントリーに適用しますが、ある管理プロセスを通して加えられたエントリーに適用されるというわけではありません。 DOCSISの食糧を供給することで設定されないなら、このオブジェクトはdocsSubMgtCpeMaxIpDefaultをデフォルトとします。 「docsSubMgtCpeControlActiveが本当である場合にだけこのオブジェクトが重要であることに注意してください。」 ::= docsSubMgtCpeControlEntry1
docsSubMgtCpeControlActive OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Controls the application of subscriber management to
this cable modem. If this is set to true, CMTS-based CPE
control is active, and all the actions required by the various
filter tables and controls apply at the CMTS. If this is set
to false, no subscriber management filtering is done at the
CMTS (but other filters may apply). If not set through DOCSIS
provisioning, this object defaults to
docsSubMgtCpeActiveDefault."
::= { docsSubMgtCpeControlEntry 2 }
マックス-ACCESSが「加入者管理の適用をこのケーブルモデムに制御する」とSTATUSの現在の記述に読書して書くdocsSubMgtCpeControlActive OBJECT-TYPE SYNTAX TruthValue。 これが本当の、そして、CMTSベースのCPEに設定されるなら、制御は動作です、そして、すべての動作が様々なフィルタテーブルが必要であり、コントロールはCMTSで申請されます。 これが誤っていることへのセット、CMTSでフィルタリングが行われる加入者管理でない(他のフィルタは適用されるかもしれない)なら。 「DOCSISの食糧を供給することで設定されないなら、このオブジェクトはdocsSubMgtCpeActiveDefaultをデフォルトとします。」 ::= docsSubMgtCpeControlEntry2
docsSubMgtCpeControlLearnable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Controls whether the CMTS may learn (and pass traffic
for) CPE IP addresses associated with a cable modem. If this is
set to true, the CMTS may learn up to docsSubMgtMaxCpeIp
そして、docsSubMgtCpeControlLearnable OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSが現在の記述をSTATUSに読書して書く、「CMTSが学ぶかもしれないかどうかを制御する、(トラフィックを通過する、)、CPE IPアドレスがケーブルモデムと交際した、」 CMTSが、これが本当に設定されることをdocsSubMgtMaxCpeIpまで学ぶかもしれないなら
Sawyer Standards Track [Page 12] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[12ページ]。
addresses (less any DOCSIS-provisioned entries) related to this
CM. Those IP addresses are added (by internal process) to the
docsSubMgtCpeIpTable. The nature of the learning mechanism is
not specified here.
アドレス(より少ないいずれもエントリーにDOCSIS食糧を供給した)はこのCMに関連しました。 それらのIPアドレスはdocsSubMgtCpeIpTableに加えられます(内部のプロセスで)。 学習のメカニズムの本質はここで指定されません。
If not set through DOCSIS provisioning, this object defaults to
docsSubMgtCpeLearnableDefault. Note that this object is only
meaningful if docsSubMgtCpeControlActive is true."
::= { docsSubMgtCpeControlEntry 3 }
DOCSISの食糧を供給することで設定されないなら、このオブジェクトはdocsSubMgtCpeLearnableDefaultをデフォルトとします。 「docsSubMgtCpeControlActiveが本当である場合にだけこのオブジェクトが重要であることに注意してください。」 ::= docsSubMgtCpeControlEntry3
docsSubMgtCpeControlReset OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object always returns false on read. If this object is
set to true, the rows with 'learned' addresses in
docsSubMgtCpeIpTable for this CM are deleted from that table."
::= { docsSubMgtCpeControlEntry 4 }
docsSubMgtCpeControlReset OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSは「このオブジェクトは読書のときに虚偽でいつも戻ること」をSTATUSの現在の記述に読書して書きます。 「このオブジェクトが本当に設定されるなら、このCMのための'学術的な'アドレスがdocsSubMgtCpeIpTableにある行はそのテーブルから削除されます。」 ::= docsSubMgtCpeControlEntry4
docsSubMgtCpeControlLastReset OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when docsSubMgtCpeControlReset was
last set true. Zero if never reset."
DEFVAL { 0 }
::= { docsSubMgtCpeControlEntry 5 }
docsSubMgtCpeControlLastReset OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「docsSubMgtCpeControlResetが最後であったことで、sysUpTimeの値は本当にセットしました」。 「決してリセットされないなら、ゼロに合わせます。」 DEFVAL0:、:= docsSubMgtCpeControlEntry5
docsSubMgtCpeMaxIpDefault OBJECT-TYPE
SYNTAX Integer32(0..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The default value for docsSubMgtCpeControlMaxCpeIp if not
signaled in the DOCSIS Registration request. This value should
be treated as nonvolatile; if set, its value should persist
across device resets."
DEFVAL { 16 }
::= { docsSubMgtObjects 2 }
docsSubMgtCpeMaxIpDefault OBJECT-TYPE SYNTAX Integer32(0 .2147483647)マックス-ACCESSは「デフォルトは、DOCSIS Registration要求でdocsSubMgtCpeControlMaxCpeIpのために評価したか、または合図したこと」をSTATUSの現在の記述に読書して書きます。 この値は不揮発性として扱われるべきです。 「設定されるなら、値はデバイスリセットの向こう側に持続するべきです。」 DEFVAL16:、:= docsSubMgtObjects2
docsSubMgtCpeActiveDefault OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The default value for docsSubMgtCpeControlActive if not
docsSubMgtCpeActiveDefault OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSは「そうでなければデフォルトはdocsSubMgtCpeControlActiveのために評価する」現在の記述をSTATUSに読書して書きます。
Sawyer Standards Track [Page 13] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[13ページ]。
signaled in the DOCSIS Registration request. This value should
be treated as nonvolatile; if set, its value should persist
across device resets."
DEFVAL { false }
::= { docsSubMgtObjects 3 }
DOCSIS Registration要求では、合図されます。 この値は不揮発性として扱われるべきです。 「設定されるなら、値はデバイスリセットの向こう側に持続するべきです。」 DEFVAL偽:、:= docsSubMgtObjects3
docsSubMgtCpeLearnableDefault OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The default value for docsSubMgtCpeControlLearnable if not
signaled in the DOCSIS Registration request. This value should
be treated as nonvolatile; if set, its value should persist
across device resets."
DEFVAL { true }
::= { docsSubMgtObjects 4 }
docsSubMgtCpeLearnableDefault OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSは「デフォルトは、DOCSIS Registration要求でdocsSubMgtCpeControlLearnableのために評価したか、または合図したこと」をSTATUSの現在の記述に読書して書きます。 この値は不揮発性として扱われるべきです。 「設定されるなら、値はデバイスリセットの向こう側に持続するべきです。」 DEFVAL、本当:、:= docsSubMgtObjects4
docsSubMgtCpeIpTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsSubMgtCpeIpEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of CPE IP addresses known on a per-CM basis."
::= { docsSubMgtObjects 5 }
「1CMあたり1個のベースで知られていて、CPE IPのテーブルは扱う」docsSubMgtCpeIpTable OBJECT-TYPEのSYNTAX SEQUENCE OF DocsSubMgtCpeIpEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= docsSubMgtObjects5
docsSubMgtCpeIpEntry OBJECT-TYPE
SYNTAX DocsSubMgtCpeIpEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the docsSubMgtCpeIpTable. The first index is
the specific modem we're referring to, and the second index is
the specific CPE IP entry."
INDEX { docsIfCmtsCmStatusIndex,
docsSubMgtCpeIpIndex }
::= {docsSubMgtCpeIpTable 1 }
docsSubMgtCpeIpEntry OBJECT-TYPE SYNTAX DocsSubMgtCpeIpEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「docsSubMgtCpeIpTableのエントリー。」 「最初のインデックスは私たちが言及している特定のモデムです、そして、2番目のインデックスは特定のCPE IPエントリーです。」 docsIfCmtsCmStatusIndex、docsSubMgtCpeIpIndexに索引をつけてください:、:= docsSubMgtCpeIpTable1
DocsSubMgtCpeIpEntry ::= SEQUENCE
{
docsSubMgtCpeIpIndex Integer32,
docsSubMgtCpeIpAddressType InetAddressType,
docsSubMgtCpeIpAddr InetAddress,
docsSubMgtCpeIpLearned TruthValue
}
DocsSubMgtCpeIpEntry:、:= 系列docsSubMgtCpeIpIndex Integer32、docsSubMgtCpeIpAddressType InetAddressType、docsSubMgtCpeIpAddr InetAddress、docsSubMgtCpeIpLearned TruthValue
docsSubMgtCpeIpIndex OBJECT-TYPE
SYNTAX Integer32(1..2147483647)
docsSubMgtCpeIpIndexオブジェクト・タイプ構文Integer32(1..2147483647)
Sawyer Standards Track [Page 14] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[14ページ]。
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index of this CPE IP address relative to the indexed CM.
An entry is created either through the included CPE IP addresses
in the provisioning object, or via learning.
「このCPE IPのインデックスは索引をつけられたCMに比例して扱う」マックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 エントリーは食糧を供給するオブジェクトの含まれているCPE IPアドレスを通って、または、学習で作成されます。
If docsSubMgtCpeControlActive is true and a CMTS receives
an IP packet from a CM that contains a source IP address that
does not match one of the docsSubMgtCpeIpAddr entries for this
CM, one of two things occurs. If the number of entries is less
than docsSubMgtCpeControlMaxCpeIp, the source address is added to
the table and the packet is forwarded. If the number of entries
equals the docsSubMgtCpeControlMaxCpeIp, then the packet is
dropped."
::= { docsSubMgtCpeIpEntry 1 }
docsSubMgtCpeControlActiveが本当であり、CMTSがこのCMのためのdocsSubMgtCpeIpAddrエントリーの1つに合っていないソースIPアドレスを含むCMからIPパケットを受けるなら、2つのものの1つは起こります。 エントリーの数がdocsSubMgtCpeControlMaxCpeIpより少ないなら、テーブルにソースアドレスを加えます、そして、パケットを送ります。 「エントリーの数がdocsSubMgtCpeControlMaxCpeIpと等しいなら、パケットは下げられます。」 ::= docsSubMgtCpeIpEntry1
docsSubMgtCpeIpAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of internet address of docsSubMgtCpeIpAddr."
::= { docsSubMgtCpeIpEntry 2 }
docsSubMgtCpeIpAddressType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「docsSubMgtCpeIpAddrのインターネットアドレスのタイプ。」 ::= docsSubMgtCpeIpEntry2
docsSubMgtCpeIpAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address either set from provisioning or learned via
address gleaning or other forwarding means. See
docsSubMgtCpeIpIndex for the mechanism.
docsSubMgtCpeIpAddr OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述「アドレス落ち穂拾いで食糧を供給するか、または学ぶので設定されたアドレスか他の推進が意味するIP。」 メカニズムに関してdocsSubMgtCpeIpIndexを見てください。
The type of this address is determined by the value of
docsSubMgtCpeIpAddressType."
::= { docsSubMgtCpeIpEntry 3 }
「このアドレスのタイプはdocsSubMgtCpeIpAddressTypeの値で決定します。」 ::= docsSubMgtCpeIpEntry3
docsSubMgtCpeIpLearned OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If true, this entry was learned from IP packets sent
upstream rather than from the provisioning objects."
::= { docsSubMgtCpeIpEntry 4 }
docsSubMgtCpeIpLearned OBJECT-TYPE SYNTAX TruthValueのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「このエントリーが本当に食糧を供給するオブジェクトからというよりむしろ上流へ送られたIPパケットから学習されたなら」。 ::= docsSubMgtCpeIpEntry4
docsSubMgtCmFilterTable OBJECT-TYPE
docsSubMgtCmFilterTableオブジェクト・タイプ
Sawyer Standards Track [Page 15] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[15ページ]。
SYNTAX SEQUENCE OF DocsSubMgtCmFilterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Binds filter groups to modems, identifying for each modem
the upstream and downstream filter groups that apply to packets
for that modem. Normally, this table reflects the filter group
values signaled by DOCSIS Registration, although values may be
overridden by management action.
SYNTAX SEQUENCE OF DocsSubMgtCmFilterEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「各モデムのためにそのモデムのためにパケットに申し込まれる上流の、そして、川下のフィルタグループを特定して、フィルタグループをモデムに縛ります」。 通常、このテーブルは値が管理活動でくつがえされたかもしれませんが、DOCSIS Registrationによって合図されたフィルタ階級値を反映します。
For each of the columns in this table, zero is a distinguished
value, indicating that the default filtering action is to be
taken rather than that associated with a filter group number.
Zero is used if the filter group is not signaled by DOCSIS
registration."
::= { docsSubMgtObjects 6 }
このテーブルのそれぞれのコラムに関しては、ゼロは顕著な値です、動作をフィルターにかけるデフォルトがフィルタグループ番号に関連づけられたそれよりむしろ取られることであることを示して。 「DOCSIS登録でフィルタグループが合図されないなら、ゼロは使用されています。」 ::= docsSubMgtObjects6
docsSubMgtCmFilterEntry OBJECT-TYPE
SYNTAX DocsSubMgtCmFilterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Binds a filter group to each direction of traffic for a
modem. The filters in this entry apply if
docsSubMgtCpeControlActive is true.
docsSubMgtCmFilterEntry OBJECT-TYPE SYNTAX DocsSubMgtCmFilterEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「モデムでトラフィックの各方向にフィルタグループを縛ります」。 docsSubMgtCpeControlActiveが本当であるなら、このエントリーにおけるフィルタは適用されます。
The contents of this entry are meaningless unless the
corresponding docsIfCmtsCmStatusValue (see reference) is
registrationComplete(6). The persistence of this row is
determined solely by the lifespan of the corresponding
docsIfCmtsCmStatusEntry (normally StorageType=volatile)."
REFERENCE
"RFC 2670"
AUGMENTS { docsIfCmtsCmStatusEntry }
::= {docsSubMgtCmFilterTable 1 }
このエントリーの内容は対応するdocsIfCmtsCmStatusValue(参照を見る)がregistrationComplete(6)でないなら無意味です。 「この行の固執は唯一対応するdocsIfCmtsCmStatusEntry(通常StorageType=揮発性の)の寿命で決定します。」 「RFC2670」という参照はdocsIfCmtsCmStatusEntryを増大させます:、:= docsSubMgtCmFilterTable1
DocsSubMgtCmFilterEntry ::= SEQUENCE
{
docsSubMgtCmFilterSubDownstream Integer32,
docsSubMgtCmFilterSubUpstream Integer32,
docsSubMgtCmFilterCmDownstream Integer32,
docsSubMgtCmFilterCmUpstream Integer32
}
DocsSubMgtCmFilterEntry:、:= 系列docsSubMgtCmFilterSubDownstream Integer32、docsSubMgtCmFilterSubUpstream Integer32、docsSubMgtCmFilterCmDownstream Integer32、docsSubMgtCmFilterCmUpstream Integer32
docsSubMgtCmFilterSubDownstream OBJECT-TYPE
SYNTAX Integer32(0..65535)
MAX-ACCESS read-write
STATUS current
docsSubMgtCmFilterSubDownstream OBJECT-TYPE SYNTAX Integer32(0 .65535)マックス-ACCESSはSTATUSに電流を読書して書きます。
Sawyer Standards Track [Page 16] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[16ページ]。
DESCRIPTION
"The filter group applied to traffic destined for subscribers
attached to the referenced CM. Upon row creation, this is set
either to zero (use default classification, the
diffServClfrElementSpecific=zeroDotZero row of
diffServClfrElementTable) or to the value in the provisioning
object sent upstream from the CM to the CMTS during registration.
The value of this object is the same as that of the filter group
index appearing as docsSubMgtFilterGroupIndex."
::= { docsSubMgtCmFilterEntry 1 }
「フィルタグループは参照をつけられたCMに付けられた加入者のために運命づけられたトラフィックに当てはまった」記述。 行作成では、これは登録の間、上流へCMからCMTSに送られた食糧を供給するオブジェクトにゼロ(デフォルト分類を使用してください、diffServClfrElementTableのdiffServClfrElementSpecific=zeroDotZero行)、または、値に設定されます。 「このオブジェクトの値はdocsSubMgtFilterGroupIndexとして現れるフィルタグループインデックスのものと同じです。」 ::= docsSubMgtCmFilterEntry1
docsSubMgtCmFilterSubUpstream OBJECT-TYPE
SYNTAX Integer32(0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The filter group applied to traffic originating from
subscribers attached to the referenced CM. Upon row creation
this is set to either zero (use default classification, the
diffServClfrElementSpecific=zeroDotZero row of
diffServClfrElementTable), or to the value in the provisioning
object sent upstream from the CM to the CMTS. The value of this
object is the same as that of the filter group index appearing as
docsSubMgtFilterGroupIndex."
::= { docsSubMgtCmFilterEntry 2 }
docsSubMgtCmFilterSubUpstream OBJECT-TYPE SYNTAX Integer32(0 .65535)マックス-ACCESSは「参照をつけられたCMに付けられた加入者から発するトラフィックに適用されたフィルタグループ」をSTATUSの現在の記述に読書して書きます。 行作成では、これはどちらかのゼロ(デフォルト分類を使用してください、diffServClfrElementTableのdiffServClfrElementSpecific=zeroDotZero行)、または、上流へCMからCMTSに送られた食糧を供給するオブジェクトの値に設定されます。 「このオブジェクトの値はdocsSubMgtFilterGroupIndexとして現れるフィルタグループインデックスのものと同じです。」 ::= docsSubMgtCmFilterEntry2
docsSubMgtCmFilterCmDownstream OBJECT-TYPE
SYNTAX Integer32(0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The filter group applied to traffic destined for the
referenced CM itself. Upon row creation this is set either to
zero (use default classification, the
diffServClfrElementSpecific=zeroDotZero row of
diffServClfrElementTable), or to the value in the provisioning
object sent upstream from the CM to the CMTS during registration.
The value of this object is the same as that of the filter group
index appearing as docsSubMgtFilterGroupIndex."
::= { docsSubMgtCmFilterEntry 3 }
docsSubMgtCmFilterCmDownstream OBJECT-TYPE SYNTAX Integer32(0 .65535)マックス-ACCESSは「参照をつけられたCM自体のために運命づけられたトラフィックに適用されたフィルタグループ」をSTATUSの現在の記述に読書して書きます。 行作成では、これがゼロに設定されたか(デフォルト分類を使用してください、diffServClfrElementTableのdiffServClfrElementSpecific=zeroDotZero行)、または食糧を供給することにおける値に、オブジェクトは登録の間、CMからCMTSまで上流へ発信しました。 「このオブジェクトの値はdocsSubMgtFilterGroupIndexとして現れるフィルタグループインデックスのものと同じです。」 ::= docsSubMgtCmFilterEntry3
docsSubMgtCmFilterCmUpstream OBJECT-TYPE
SYNTAX Integer32(0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The filter group applied to traffic originating from the
referenced CM itself. This is set upon row creation to either
docsSubMgtCmFilterCmUpstream OBJECT-TYPE SYNTAX Integer32(0 .65535)マックス-ACCESSは「参照をつけられたCM自体から発するトラフィックに適用されたフィルタグループ」をSTATUSの現在の記述に読書して書きます。 これはどちらかへ行作成を上に置かれます。
Sawyer Standards Track [Page 17] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[17ページ]。
zero (use default classification, the
diffServClfrElementSpecific=zeroDotZero row of
diffServClfrElementTable), or to the value in the provisioning
object sent upstream from the CM to the CMTS during registration.
The value of this object is the same as the filter group index
appearing as docsSubMgtFilterGroupIndex."
::= { docsSubMgtCmFilterEntry 4 }
(デフォルト分類を使用してください、diffServClfrElementTableのdiffServClfrElementSpecific=zeroDotZero行) 登録の間、CMTSへのCMから食糧を供給するオブジェクトの値に上流へ送ります。 「このオブジェクトの値はdocsSubMgtFilterGroupIndexとして現れるのにおいてフィルタグループが索引をつけるのと同じです。」 ::= docsSubMgtCmFilterEntry4
docsSubMgtFilterGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsSubMgtFilterGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Provides a collection of referenceable entries to which
diffServClfrElementSpecific refers. This table provides filter
group indices that can be compared with those signaled during
DOCSIS registration. A packet matches an entry from this table
if the packet originated from or is destined to a cable modem
that registered this index as one of its four filter groups
(see docsSubMgtCmFilterTable), and if the packet direction and
MAC address select the use of this index among the four."
::= { docsSubMgtObjects 7 }
docsSubMgtFilterGroupTable OBJECT-TYPEのSYNTAX SEQUENCE OF DocsSubMgtFilterGroupEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「diffServClfrElementSpecificが参照する参照可能エントリーの収集を提供します」。 このテーブルはDOCSIS登録の間、合図されるそれらと比較できるフィルタグループインデックスリストを提供します。 「4フィルタの1つが分類されて(docsSubMgtCmFilterTableを見てください)、パケット方向とMACアドレスが4つの中でこのインデックスの使用を選択するなら、パケットは、発せられるパケットであるならこのテーブルからエントリーに合っているか、またはこのインデックスを示したケーブルモデムに運命づけられています。」 ::= docsSubMgtObjects7
docsSubMgtFilterGroupEntry OBJECT-TYPE
SYNTAX DocsSubMgtFilterGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry only exists if needed by the
diffServClfrElementEntry. A packet matches this entry if the
packet's cable modem registered this index as one of its four
filter groups (see docsSubMgtCmFilterTable) and if the packet
direction and MAC address select the use of this index among
the four."
INDEX { docsSubMgtFilterGroupIndex }
::= { docsSubMgtFilterGroupTable 1 }
docsSubMgtFilterGroupEntry OBJECT-TYPE SYNTAX DocsSubMgtFilterGroupEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「diffServClfrElementEntryが必要である場合にだけ、エントリーは存在しています」。 「4フィルタの1つが分類されるので(docsSubMgtCmFilterTableを見てください)パケットのケーブルモデムがこのインデックスを示して、パケット方向とMACアドレスが4つの中でこのインデックスの使用を選択するなら、パケットはこのエントリーに合っています。」 docsSubMgtFilterGroupIndexに索引をつけてください:、:= docsSubMgtFilterGroupTable1
DocsSubMgtFilterGroupEntry ::= SEQUENCE
{
docsSubMgtFilterGroupIndex Integer32
}
DocsSubMgtFilterGroupEntry:、:= 系列docsSubMgtFilterGroupIndex Integer32
docsSubMgtFilterGroupIndex OBJECT-TYPE
SYNTAX Integer32(1..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The filter group index, from the set signaled at DOCSIS
「フィルタグループはDOCSISで合図されたセットから索引をつける」docsSubMgtFilterGroupIndex OBJECT-TYPE SYNTAX Integer32(1 .65535)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
Sawyer Standards Track [Page 18] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[18ページ]。
Registration. Provides a referenceable entry to which
diffServClfrElementSpecific points. A packet matches this
classifier entry if the packet's cable modem registered this
index value as one of its four filter groups, and if the packet
direction and MAC address select the use of this index among
the four. Because this is the only field in this table, it is
read-only, contrary to the usual SMI custom of making indices
not-accessible.
登録。 どのdiffServClfrElementSpecificポイントに参照可能エントリーを提供するか。 4フィルタの1つが分類されるのでパケットのケーブルモデムがこのインデックス値を示して、パケット方向とMACアドレスが4つの中でこのインデックスの使用を選択するなら、パケットはこのクラシファイアエントリーに合っています。 これがこのテーブルで唯一の分野であるので、それは書き込み禁止です、インデックスリストをアクセスしやすくしない普通のSMI習慣とは逆に。
Note that although zero may be signaled (or defaulted) at DOCSIS
Registration to indicate a default filtering group, no such entry
appears in this table, as diffServClfrElementSpecific will
use a zeroDotZero pointer for that classification."
::= { docsSubMgtFilterGroupEntry 1 }
「DOCSIS Registrationでゼロがデフォルトフィルタリンググループを示すように合図されるかもしれませんが(または、デフォルトとします)、どんなそのようなエントリーもこのテーブルに現れないことに注意してください、diffServClfrElementSpecificがその分類にzeroDotZero指針を使用するとき。」 ::= docsSubMgtFilterGroupEntry1
docsSubMgtConformance OBJECT IDENTIFIER ::= { docsSubMgt 2 }
docsSubMgtCompliances OBJECT IDENTIFIER ::=
{ docsSubMgtConformance 1 }
docsSubMgtGroups OBJECT IDENTIFIER ::=
{ docsSubMgtConformance 2 }
docsSubMgtConformanceオブジェクト識別子:、:= docsSubMgt2docsSubMgtCompliancesオブジェクト識別子:、:= docsSubMgtConformance1docsSubMgtGroupsオブジェクト識別子:、:= docsSubMgtConformance2
docsSubMgtBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for CMTS devices that implement
CMTS centric subscriber management.
docsSubMgtBasicCompliance MODULE-COMPLIANCE STATUSの現在の記述、「CMTSが中心の加入者管理であると実装するCMTSデバイスのための承諾声明。」
This compliance statement applies to implementations that
support DOCSIS 1.0/1.1/2.0, which are not IPv6 capable."
「この承諾声明は1.0/1.1/2.0のそのサポートDOCSISを実装に当てはまります」。(DOCSISはできるIPv6ではありません)。
MODULE DIFFSERV-MIB -- RFC3289
MANDATORY-GROUPS {
diffServMIBDataPathGroup,
diffServMIBClfrGroup,
diffServMIBClfrElementGroup,
diffServMIBMultiFieldClfrGroup,
diffServMIBActionGroup,
diffServMIBAlgDropGroup,
diffServMIBCounterGroup
}
モジュールDIFFSERV-MIB--RFC3289の義務的なグループdiffServMIBDataPathGroup、diffServMIBClfrGroup、diffServMIBClfrElementGroup、diffServMIBMultiFieldClfrGroup、diffServMIBActionGroup、diffServMIBAlgDropGroup、diffServMIBCounterGroup
OBJECT diffServDataPathStatus -- same as RFC3289
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION
"Support for createAndWait and notInService is not required."
RFC3289 SYNTAX RowStatusのアクティブな(1)WRITE-SYNTAX RowStatusと同じOBJECT diffServDataPathStatus、createAndGo(4)、(6)を破壊してください、記述、「createAndWaitとnotInServiceのサポートは必要ではありません」。
Sawyer Standards Track [Page 19] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[19ページ]。
OBJECT diffServClfrStatus -- same as RFC3289
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION
"Support for createAndWait and notInService is not required."
RFC3289 SYNTAX RowStatusのアクティブな(1)WRITE-SYNTAX RowStatusと同じOBJECT diffServClfrStatus、createAndGo(4)、(6)を破壊してください、記述、「createAndWaitとnotInServiceのサポートは必要ではありません」。
OBJECT diffServClfrElementStatus -- same as RFC3289
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION
"Support for createAndWait and notInService is not required."
RFC3289 SYNTAX RowStatusのアクティブな(1)WRITE-SYNTAX RowStatusと同じOBJECT diffServClfrElementStatus、createAndGo(4)、(6)を破壊してください、記述、「createAndWaitとnotInServiceのサポートは必要ではありません」。
OBJECT diffServMultiFieldClfrAddrType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
"An implementation is only required to support IPv4
addresses."
OBJECT diffServMultiFieldClfrAddrType SYNTAX InetAddressType ipv4(1)、「IPv4アドレスであるとサポート実装が必要であるだけである」記述。
OBJECT diffServMultiFieldClfrSrcAddr
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses."
OBJECT diffServMultiFieldClfrSrcAddr SYNTAX InetAddress、(「IPv4アドレスであるとサポート実装が必要であるだけである」SIZE(4)) DESCRIPTION。
OBJECT diffServMultiFieldClfrDstAddr
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses."
OBJECT diffServMultiFieldClfrDstAddr SYNTAX InetAddress、(「IPv4アドレスであるとサポート実装が必要であるだけである」SIZE(4)) DESCRIPTION。
OBJECT diffServAlgDropStatus -- same as RFC3289
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION
"Support for createAndWait and notInService is not required."
RFC3289 SYNTAX RowStatusのアクティブな(1)WRITE-SYNTAX RowStatusと同じOBJECT diffServAlgDropStatus、createAndGo(4)、(6)を破壊してください、記述、「createAndWaitとnotInServiceのサポートは必要ではありません」。
OBJECT diffServDataPathStorage
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServDataPathStorage SYNTAX StorageType nonVolatile(3)、「不揮発性記憶装置をサポート実装が必要であるだけである」記述。
OBJECT diffServClfrStorage
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServClfrStorage SYNTAX StorageType nonVolatile(3)、「不揮発性記憶装置をサポート実装が必要であるだけである」記述。
Sawyer Standards Track [Page 20] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[20ページ]。
OBJECT diffServClfrElementStorage
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServClfrElementStorage SYNTAX StorageType nonVolatile(3)、「不揮発性記憶装置をサポート実装が必要であるだけである」記述。
OBJECT diffServMultiFieldClfrStorage
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServMultiFieldClfrStorage SYNTAX StorageType nonVolatile(3)、「不揮発性記憶装置をサポート実装が必要であるだけである」記述。
OBJECT diffServActionStorage
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServActionStorage SYNTAX StorageType nonVolatile(3)、「不揮発性記憶装置をサポート実装が必要であるだけである」記述。
OBJECT diffServCountActStorage
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServCountActStorage SYNTAX StorageType nonVolatile(3)、「不揮発性記憶装置をサポート実装が必要であるだけである」記述。
OBJECT diffServAlgDropStorage
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServAlgDropStorage SYNTAX StorageType nonVolatile(3)、「不揮発性記憶装置をサポート実装が必要であるだけである」記述。
OBJECT diffServAlgDropType
SYNTAX INTEGER { alwaysDrop(5) }
DESCRIPTION
"For DOCSIS subscriber management, this object is
only used to provide packet filtering. Implementations
need not support other values of this enumeration."
OBJECT diffServAlgDropType SYNTAX INTEGER alwaysDrop(5)、記述、「DOCSIS加入者管理において、このオブジェクトはパケットフィルタリングを提供するのに使用されるだけです」。 「実装はこの列挙の他の値をサポートする必要はありません。」
MODULE -- This module i.e., DOCS-IETF-SUBMGT-MIB
MODULE--すなわち、このモジュールDOCS-IETF-SUBMGT-MIB
MANDATORY-GROUPS {
docsSubMgtGroup
}
義務的なグループdocsSubMgtGroup
OBJECT docsSubMgtCpeControlMaxCpeIp
SYNTAX Integer32(0..16)
DESCRIPTION
"An implementation is only required to support up to
sixteen addresses per modem."
「1モデムあたり最大16のアドレスをサポート実装が必要であるだけである」OBJECT docsSubMgtCpeControlMaxCpeIp SYNTAX Integer32(0 .16)記述。
Sawyer Standards Track [Page 21] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[21ページ]。
OBJECT docsSubMgtCpeMaxIpDefault
SYNTAX Integer32(0..16)
DESCRIPTION
"An implementation is only required to support up to
sixteen addresses per modem."
「1モデムあたり最大16のアドレスをサポート実装が必要であるだけである」OBJECT docsSubMgtCpeMaxIpDefault SYNTAX Integer32(0 .16)記述。
OBJECT docsSubMgtCpeIpAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
"An implementation is only required to support IPv4
addresses."
OBJECT docsSubMgtCpeIpAddressType SYNTAX InetAddressType ipv4(1)、「IPv4アドレスであるとサポート実装が必要であるだけである」記述。
OBJECT docsSubMgtCpeIpAddr
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses."
OBJECT docsSubMgtCpeIpAddr SYNTAX InetAddress、(「IPv4アドレスであるとサポート実装が必要であるだけである」SIZE(4)) DESCRIPTION。
OBJECT docsSubMgtCmFilterSubDownstream
SYNTAX Integer32(0..30)
DESCRIPTION
"An implementation is only required to support thirty
filter groups."
「30のフィルタグループをサポート実装が必要であるだけである」OBJECT docsSubMgtCmFilterSubDownstream SYNTAX Integer32(0 .30)記述。
OBJECT docsSubMgtCmFilterSubUpstream
SYNTAX Integer32(0..30)
DESCRIPTION
"An implementation is only required to support thirty
filter groups."
「30のフィルタグループをサポート実装が必要であるだけである」OBJECT docsSubMgtCmFilterSubUpstream SYNTAX Integer32(0 .30)記述。
OBJECT docsSubMgtCmFilterCmDownstream
SYNTAX Integer32(0..30)
DESCRIPTION
"An implementation is only required to support thirty
filter groups."
「30のフィルタグループをサポート実装が必要であるだけである」OBJECT docsSubMgtCmFilterCmDownstream SYNTAX Integer32(0 .30)記述。
OBJECT docsSubMgtCmFilterCmUpstream
SYNTAX Integer32(0..30)
DESCRIPTION
"An implementation is only required to support thirty
filter groups."
「30のフィルタグループをサポート実装が必要であるだけである」OBJECT docsSubMgtCmFilterCmUpstream SYNTAX Integer32(0 .30)記述。
::= { docsSubMgtCompliances 1 }
::= docsSubMgtCompliances1
docsSubMgtGroup OBJECT-GROUP
OBJECTS {
docsSubMgtCpeControlMaxCpeIp,
docsSubMgtCpeControlActive,
docsSubMgtGroupオブジェクト群対象、docsSubMgtCpeControlMaxCpeIp、docsSubMgtCpeControlActive
Sawyer Standards Track [Page 22] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[22ページ]。
docsSubMgtCpeControlLearnable,
docsSubMgtCpeControlReset,
docsSubMgtCpeControlLastReset,
docsSubMgtCpeMaxIpDefault,
docsSubMgtCpeActiveDefault,
docsSubMgtCpeLearnableDefault,
docsSubMgtCpeIpAddressType,
docsSubMgtCpeIpAddr,
docsSubMgtCpeIpLearned,
docsSubMgtCmFilterSubDownstream,
docsSubMgtCmFilterSubUpstream,
docsSubMgtCmFilterCmDownstream,
docsSubMgtCmFilterCmUpstream,
docsSubMgtFilterGroupIndex
}
STATUS current
DESCRIPTION
"The objects used to manage host-based cable modems
via a set of CMTS enforced controls."
::= { docsSubMgtGroups 1 }
docsSubMgtCpeControlLearnable、docsSubMgtCpeControlReset、docsSubMgtCpeControlLastReset、docsSubMgtCpeMaxIpDefault、docsSubMgtCpeActiveDefault、docsSubMgtCpeLearnableDefault、docsSubMgtCpeIpAddressType、docsSubMgtCpeIpAddr、docsSubMgtCpeIpLearned、docsSubMgtCmFilterSubDownstream、docsSubMgtCmFilterSubUpstream、docsSubMgtCmFilterCmDownstream、docsSubMgtCmFilterCmUpstream、docsSubMgtFilterGroupIndex 「実施されたCMTSの1セットを通してホストベースのケーブルモデムを管理するのにおいて中古のオブジェクトは制御する」STATUSの現在の記述。 ::= docsSubMgtGroups1
END
終わり
5. Acknowledgements
5. 承認
This document is based on work by Michael St. Johns, then at Excite@Home. Thanks to Guenter Roeck and Julie McGray for reviewing earlier versions. Thanks to Bert Wijnen, Mike Heard, and Harrie Hazewinkel for extensive later review. Thanks to the working group chairs, Richard Woundy and Jean-Francois Mule, for their extensive support.
マイケル通りジョーンズのこのドキュメントはそして、 Excite@Home で仕事に基づいています。 ギュンターRoeckとジュリーMcGrayに以前のバージョンを見直してくださってありがとうございます。 大量の後のレビューをバートWijnen、マイクHeard、およびHarrie Hazewinkelをありがとうございます。 彼らの大規模な支持をワーキンググループいす、リチャードWoundy、およびジャン・フランソワMuleをありがとうございます。
6. IANA Considerations
6. IANA問題
The MIB module defined in this document uses the following IANA- assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry:
本書では定義されたMIBモジュールはSMI民数記登録に記録されたOBJECT IDENTIFIER値が割り当てられた以下のIANAを使用します:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
docsSubMgt { mib-2 125}
記述子OBJECT IDENTIFIER価値---------- ----------------------- docsSubMgtmib-2 125
7. Normative References
7. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Sawyer Standards Track [Page 23] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[23ページ]。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、パーキンス、D.、およびJ.Schoenwaelder、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[RFC2579] McCloghrieとK.とパーキンス、D.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2580] McCloghrieとK.とパーキンス、D.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[ITU-T-J122] Second-Generation Transmission Systems for Interactive
Cable Television Services, J.122, ITU-T, December, 2002.
[ITU-T-J122] 2002年12月の対話的なケーブルテレビ放送、J.122、ITU-Tの二世伝動装置。
[RFC2670] St. Johns, M., "Radio Frequency (RF) Interface
Management Information Base for MCNS/DOCSIS compliant RF
interfaces", RFC 2670, August 1999.
[RFC2670] 聖ジョーンズ、M.、「MCNS/DOCSIS対応することのRFインタフェースへのラジオFrequency(RF)インタフェースManagement Information基地」、RFC2670、1999年8月。
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management
Information Base for the Differentiated Services
Architecture", RFC 3289, May 2002.
[RFC3289]ベイカー(F.とチェン、K.とA.スミス、「差別化されたサービスアーキテクチャのための管理情報ベース」RFC3289)は2002がそうするかもしれません。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
2005年2月の[RFC4001]ダニエルとM.とハーバーマンとB.とRouthier、S.とJ.Schoenwaelder、「インターネットネットワーク・アドレスのための原文のコンベンション」RFC4001。
8. Informative References
8. 有益な参照
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
1995年10月の[RFC1858]ZiembaとG.とリード、D.とP.Traina、「IP断片フィルタリングのためのセキュリティ問題」RFC1858。
[RFC2669] St. Johns, M., "DOCSIS Cable Device MIB Cable Device
Management Information Base for DOCSIS compliant Cable
Modems and Cable Modem Termination Systems", RFC 2669,
August 1999.
[RFC2669] 聖ジョーンズ、M.、「DOCSISの言いなりになっているCable ModemsとCable Modem Termination SystemsのためのDOCSIS Cable Device MIB Cable Device Management Information基地」、RFC2669(1999年8月)。
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3128]ミラー、I.、「小さい断片攻撃の異形に対する保護、(RFC1858)、」、RFC3128、6月2001日
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
[RFC3410] ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、「インターネット標準の管理フレームワークのための序論と適用性声明」、RFC3410(2002年12月)。
Sawyer Standards Track [Page 24] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[24ページ]。
[DOCSBPI] "Data-Over-Cable Service Interface Specifications:
Baseline Privacy Plus Interface Specification SP-BPI+-
I11-040407", DOCSIS, April 2004, available at
http://www.cablemodem.com/ and at
http://www.cablelabs.com/specifications/archives.
[DOCSBPI] 「データ過剰ケーブルサービスは仕様を連結します」。 「基線Privacy Plus Interface Specification SP BPI+I11-040407、」、2004年4月に http://www.cablemodem.com/ において http://www.cablelabs.com/specifications/archives で利用可能なDOCSIS。
9. Security Considerations
9. セキュリティ問題
This MIB is intended to limit certain kinds of network behavior by subscriber hosts attached to cable modems, including, for example, IP spoofing. These limitations may be compromised, however, if the cable modem's identity or registration process is spoofed. The DOCSIS RFI and privacy specifications [ITU-T-J122] and [DOCSBPI] define a number of mechanisms for assuring modem identity.
このMIBがケーブルモデムに取り付けられた加入者ホストによる、ある種類のネットワークの振舞いを制限することを意図します、例えばIPスプーフィングを含んでいて。 しかしながら、ケーブルモデムのアイデンティティか登録手続が偽造されるなら、これらの制限は感染されるかもしれません。 DOCSIS RFI、プライバシー仕様[ITU-T-J122]、および[DOCSBPI]は、モデムのアイデンティティを保証するために多くのメカニズムを定義します。
For network filtering of TCP traffic to be effective, implementors MUST follow the recommendations in section 3.4.
TCPトラフィックのネットワークフィルタリングが有効であるように、作成者はセクション3.4で推薦の後をつけなければなりません。
There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. These objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations.
aがあります。読書して書くことのマックス-ACCESS節を持っているこのMIBで定義された管理オブジェクトに付番する、そして/または、読書して作成します。 これらのオブジェクトはいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響がある場合があります。
Unauthorized SETs to this MIB can permit two major security problems with public cable network operation: IP address spoofing, and defeat of operator-defined packet filtering.
このMIBへの権限のないSETsは公共のケーブルネットワーク操作に関する2つの主要な警備上の問題を可能にすることができます: IPアドレススプーフィング、およびオペレータによって定義されたパケットフィルタリングの敗北。
The following objects, if SET maliciously, would evade controls on address spoofing:
以下は反対して、陰湿に、SETであるならアドレススプーフィングのときにコントロールを回避するでしょう:
docsSubMgtCpeControlMaxCpeIp
docsSubMgtCpeControlActive
docsSubMgtCpeControlLearnable
docsSubMgtCpeControlReset
docsSubMgtCpeMaxIpDefault
docsSubMgtCpeActiveDefault
docsSubMgtCpeLearnableDefault
docsSubMgtCpeControlMaxCpeIp docsSubMgtCpeControlActive docsSubMgtCpeControlLearnable docsSubMgtCpeControlReset docsSubMgtCpeMaxIpDefault docsSubMgtCpeActiveDefault docsSubMgtCpeLearnableDefault
The following objects could also permit packet filtering to be defeated:
また、以下のオブジェクトは、パケットフィルタリングが破られるのを可能にするかもしれません:
docsSubMgtCmFilterSubDownstream
docsSubMgtCmFilterSubUpstream
docsSubMgtCmFilterCmDownstream
docsSubMgtCmFilterCmUpstream
docsSubMgtCmFilterSubDownstream docsSubMgtCmFilterSubUpstream docsSubMgtCmFilterCmDownstream docsSubMgtCmFilterCmUpstream
Sawyer Standards Track [Page 25] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[25ページ]。
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET access to these objects and possibly even to encrypt the values of these objects when they are sent over the network via SNMP. The most sensitive is docsSubMgtCpeIpAddr within docsSubMgtCpeIpTable. Although docsSubMgtCpeIpTable is intended to control address spoofing, it includes information about the current subscriber address pool. This information may in itself be valuable to would-be spoofers.
このMIBモジュール(すなわち、アクセスしやすくないのを除いたマックス-ACCESSがあるオブジェクト)によるいくつかの読み込み可能なオブジェクトがいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 それは、その結果、これらのオブジェクトへのGETアクセスさえ制御するために重要であって、SNMPを通してネットワークの上にそれらを送るとき、これらのオブジェクトの値を暗号化するためにことによると同等です。 最も敏感であるのは、docsSubMgtCpeIpTableの中のdocsSubMgtCpeIpAddrです。 docsSubMgtCpeIpTableがアドレススプーフィングを制御することを意図しますが、それは現在の加入者アドレスプールの情報を含んでいます。 この情報は本来ひとりよがりのspoofersに貴重であるかもしれません。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
SNMPv3の前のSNMPバージョンは十分な安全性を含んでいませんでした。 ネットワーク自体が安全であっても(例えば、IPSecを使用するのによる)、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトが安全なネットワークにこのMIBモジュールでだれに許容されているかに関してコントロールが全くありません。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは([RFC3410]を見てください、セクション8)、RECOMMENDEDです、SNMPv3の暗号のメカニズム(認証とプライバシーのための)の全面的な支援を含んでいて。
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) who have legitimate rights to GET or SET (change/create/delete) them.
さらに、SNMPv3の前のSNMPバージョンの展開はNOT RECOMMENDEDです。 代わりに、それはSNMPv3を配布して、暗号のセキュリティを可能にするRECOMMENDEDです。 そして、このMIBモジュールのインスタンスへのアクセスを与えるSNMP実体がGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために適切に構成されるのを保証するのは、顧客/オペレータ責任です。
Author's Address
作者のアドレス
Wilson Sawyer 50 Kelly Brook Lane East Hampstead NH 03826
ウィルソン木挽き50のケリー・ブルック・レーンの東ハムステッドニューハンプシャー 03826
Phone: +1 603 382 7080 EMail: wsawyer@ieee.org
以下に電話をしてください。 +1 7080年の603 382メール: wsawyer@ieee.org
Sawyer Standards Track [Page 26] RFC 4036 DOCSIS Subscriber Management MIB April 2005
木挽き規格はDOCSIS加入者管理MIB2005年4月にRFC4036を追跡します[26ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Sawyer Standards Track [Page 27]
木挽き標準化過程[27ページ]
一覧
スポンサーリンク
