RFC3567 日本語訳

3567 Intermediate System to Intermediate System (IS-IS) CryptographicAuthentication. T. Li, R. Atkinson. July 2003. (Format: TXT=13467 bytes) (Obsoleted by RFC5304) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                              T. Li
Request for Comments: 3567                              Procket Networks
Category: Informational                                      R. Atkinson
                                                        Extreme Networks
                                                               July 2003

コメントを求めるワーキンググループT.李の要求をネットワークでつないでください: 3567Procketはカテゴリをネットワークでつなぎます: 情報のR.アトキンソン極端は2003年7月をネットワークでつなぎます。

          Intermediate System to Intermediate System (IS-IS)
                      Cryptographic Authentication

中間システムへの中間システム、(-、)、暗号の認証

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   This document describes the authentication of Intermediate System to
   Intermediate System (IS-IS) Protocol Data Units (PDUs) using the
   Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5)
   algorithm as found in RFC 2104.  IS-IS is specified in International
   Standards Organization (ISO) 10589, with extensions to support
   Internet Protocol version 4 (IPv4) described in RFC 1195.  The base
   specification includes an authentication mechanism that allows for
   multiple authentication algorithms.  The base specification only
   specifies the algorithm for cleartext passwords.

このドキュメントがIntermediate Systemの認証についてIntermediate Systemに説明する、(-、)、Hashedメッセージ立証コードを使用して、Data Units(PDUs)について議定書の中で述べてください--RFC2104で見つけられるメッセージDigest5(HMAC-MD5)アルゴリズム。 -、国際Standards Organization(ISO)10589で拡大で指定されて、インターネットプロトコルがRFC1195で説明されたバージョン4である(IPv4)とサポートします。 基礎仕様はそれが複数の認証アルゴリズムのために許容する認証機構を含んでいます。基礎仕様はcleartextパスワードにアルゴリズムを指定するだけです。

   This document proposes an extension to that specification that allows
   the use of the HMAC-MD5 authentication algorithm to be used in
   conjunction with the existing authentication mechanisms.

このドキュメントはHMAC-MD5認証アルゴリズムの使用が既存の認証機構に関連して使用されるのを許容するその仕様に拡大を提案します。

1. Introduction

1. 序論

   The IS-IS protocol, as specified in ISO 10589 [1], provides for the
   authentication of Link State PDUs (LSPs) through the inclusion of
   authentication information as part of the LSP.  This authentication
   information is encoded as a Type-Length-Value (TLV) tuple.  The use
   of IS-IS for IPv4 networks is described in [3].

-、ISO10589[1]で指定されるプロトコルはLSPの一部として認証情報の包含によるLink州PDUs(LSPs)の認証に備えます。 この認証情報はType長さの価値(TLV)のtupleとしてコード化されます。 使用、-、IPv4ネットワークのために、説明されたコネ[3]はそうです。

   The type of the TLV is specified as 10.  The length of the TLV is
   variable.  The value of the TLV depends on the authentication
   algorithm and related secrets being used.  The first octet of the
   value is used to specify the authentication type.  Type 0 is

TLVのタイプは10として指定されます。 TLVの長さは可変です。 TLVの値は使用される認証アルゴリズムと関連する秘密に依存します。 価値の最初の八重奏は、認証タイプを指定するのに使用されます。 タイプ0はそうです。

Li & Atkinson                Informational                      [Page 1]

RFC 3567           IS-IS Cryptographic Authentication          July 2003

李とアトキンソン情報[1ページ]のRFC3567、-、暗号の認証2003年7月

   reserved, type 1 indicates a cleartext password, and type 255 is used
   for routing domain private authentication methods.  The remainder of
   the TLV value is known as the Authentication Value.

予約されていて、タイプ1はcleartextパスワードを示します、そして、タイプ255は経路ドメインの個人的な認証方法に使用されます。 TLV価値の残りはAuthentication Valueとして知られています。

   This document extends the above situation by allocating a new
   authentication type for HMAC-MD5 and specifying the algorithms for
   the computation of the Authentication Value.  This document also
   describes modifications to the base protocol to ensure that the
   authentication mechanisms described in this document are effective.

このドキュメントは、HMAC-MD5のために新しい認証タイプを割り当てて、Authentication Valueの計算にアルゴリズムを指定することによって、上の状況を広げています。 また、このドキュメントは、本書では説明された認証機構が確実に有効になるようにするためにベースプロトコルに変更を説明します。

   This document is a publication of the IS-IS Working Group within the
   IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual
   inclusion with ISO 10589.

このドキュメントが刊行物である、-、IETFの中の作業部会、貢献はISO IEC JTC1/SC6へのISO10589との最後の包含のためのものです。

2. Authentication Procedures

2. 認証手順

   The authentication type used for HMAC-MD5 is 54 (0x36).  The length
   of the Authentication Value for HMAC-MD5 is 16, and the length field
   in the TLV is 17.

HMAC-MD5に使用される認証タイプは54歳(0×36)です。 HMAC-MD5のためのAuthentication Valueの長さは16です、そして、TLVの長さの分野は17です。

   The HMAC-MD5 algorithm requires a key K and text T as input [2].  The
   key K is the password for the PDU type, as specified in ISO 10589.
   The text T is the IS-IS PDU to be authenticated with the
   Authentication Value field inside of the Authentication Information
   TLV set to zero.  Note that the Authentication Type is set to 54 and
   the length of the TLV is set to 17 before authentication is computed.
   When LSPs are authenticated, the Checksum and Remaining Lifetime
   fields are set to zero (0) before authentication is computed.  The
   result of the algorithm is placed in the Authentication Value field.

HMAC-MD5アルゴリズムは、[2]を入力するので、主要なKとテキストTを必要とします。 主要なKはISO10589で指定されるようにPDUタイプへのパスワードです。 テキストTがそうである、-、IS PDU、Authentication情報TLVのAuthentication Value分野内部で認証されるのはゼロにセットしました。 Authentication Typeが54に用意ができて、認証が計算される前にTLVの長さが17に設定されることに注意してください。 LSPsが認証されるとき、ChecksumとRemaining Lifetime分野は認証が計算される前に(0)のゼロを合わせるように用意ができています。 アルゴリズムの結果はAuthentication Value分野に置かれます。

   When calculating the HMAC-MD5 result for Sequence Number PDUs, Level
   1 Sequence Number PDUs SHALL use the Area Authentication string as in
   Level 1 Link State PDUs.  Level 2 Sequence Number PDUs shall use the
   domain authentication string as in Level 2 Link State PDUs.  IS-IS
   HELLO PDUs SHALL use the Link Level Authentication String, which MAY
   be different from that of Link State PDUs.  The HMAC-MD5 result for
   the IS-IS HELLO PDUs SHALL be calculated after the Packet is padded
   to the MTU size, if padding is not disabled.  Implementations that
   support the optional checksum for the Sequence Number PDUs and IS-IS
   HELLO PDUs MUST NOT include the Checksum TLV.

Sequence Number PDUsのためのHMAC-MD5結果について計算するとき、Level1Sequence Number PDUs SHALLはLevel1Link州PDUsのようにArea Authenticationストリングを使用します。 レベル2 Sequence Number PDUsはLevel2Link州PDUsのようにドメイン認証ストリングを使用するものとします。 IS-IS HELLO PDUs SHALLはLink Level Authentication Stringを使用します。(Link Level Authentication StringはLink州PDUsのものと異なっているかもしれません)。 HMAC-MD5が結果になる、-、HELLO PDUs SHALL、PacketがMTUサイズに水増しされた後に計算されてください、詰め物は障害がないなら。 そして、Sequence Number PDUsのために任意のチェックサムをサポートする実装、-、HELLO PDUsはChecksum TLVを含んではいけません。

   To authenticate an incoming PDU, a system should save the values of
   the Authentication Value field, the Checksum and the Remaining
   Lifetime field, set these fields to zero, compute authentication, and
   then restore the values of these fields.

システムは、入って来るPDUを認証するために、Authentication Value分野、Checksum、およびRemaining Lifetime分野の値を節約して、これらの分野をゼロに設定して、認証を計算して、次に、これらの分野の値を回復するはずです。

Li & Atkinson                Informational                      [Page 2]

RFC 3567           IS-IS Cryptographic Authentication          July 2003

李とアトキンソン情報[2ページ]のRFC3567、-、暗号の認証2003年7月

   An implementation that implements HMAC-MD5 authentication and
   receives HMAC-MD5 Authentication Information MUST discard the PDU if
   the Authentication Value is incorrect.

Authentication Valueが不正確であるなら、HMAC-MD5が認証であると実装して、HMAC-MD5 Authentication情報を受け取る実装はPDUを捨てなければなりません。

   An implementation MAY have a transition mode where it includes HMAC-
   MD5 Authentication Information in PDUs but does not verify the HMAC-
   MD5 authentication information.  This is a transition aid for
   networks in the process of deploying authentication.

実装は、PDUsにそれがHMAC MD5 Authentication情報を含んでいる変遷モードを持っているかもしれませんが、HMAC MD5認証情報について確かめません。 これは認証を配布することの途中にネットワークのための変遷援助です。

   An implementation MAY check a set of passwords when verifying the
   Authentication Value.  This provides a mechanism for incrementally
   changing passwords in a network.

Authentication Valueについて確かめるとき、実装は1セットのパスワードをチェックするかもしれません。 これはネットワークにおけるパスワードを増加して変えるのにメカニズムを提供します。

   An implementation that does not implement HMAC-MD5 authentication MAY
   accept a PDU that contains the HMAC-MD5 Authentication Type.  ISes
   (routers) that implement HMAC-MD5 authentication and initiate LSP
   purges MUST remove the body of the LSP and add the authentication
   TLV.  ISes implementing HMAC-MD5 authentication MUST NOT accept
   unauthenticated purges.  ISes MUST NOT accept purges that contain
   TLVs other than the authentication TLV.  These restrictions are
   necessary to prevent a hostile system from receiving an LSP, setting
   the Remaining Lifetime field to zero, and flooding it, thereby
   initiating a purge without knowing the authentication password.

HMAC-MD5が認証であると実装しない実装はHMAC-MD5 Authentication Typeを含むPDUを受け入れるかもしれません。 HMAC-MD5が認証であると実装して、LSPパージを開始するISes(ルータ)はLSPのボディーを取り除いて、認証TLVを加えなければなりません。 HMAC-MD5が認証であると実装するISesは非認証されたパージを受け入れてはいけません。 ISesは認証TLV以外のTLVsを含むパージを受け入れてはいけません。 これらの制限が敵軍のシステムがLSPを受けるのを防ぐのに必要です、Remaining Lifetime分野をゼロに設定して、それをあふれさせて、その結果、認証パスワードを知らないで、パージを開始します。

2.1 Implementation Considerations

2.1 実装問題

   There is an implementation issue just after password rollover on an
   IS-IS router that might benefit from additional commentary.
   Immediately after password rollover on the router, the router or IS-
   IS process may restart.  If this happens, this causes the LSP
   Sequence Number restarts from the value 1 using the new password.
   However, neighbors will reject those new LSPs because the Sequence
   Number is smaller.  The router can not increase its own LSP Sequence
   Number because it fails to authenticate its own old LSP that
   neighbors keep sending to it.  So the router can not update its LSP
   Sequence Number to its neighbors until all the neighbors time out all
   of the original LSPs.  One possible solution to this problem is for
   the IS-IS process to detect if any inbound LSP with an authentication
   failure has the local System ID and also has a higher Sequence Number
   than the IS-IS process has.  In this event, the IS-IS process SHOULD
   increase its own LSP Sequence Number accordingly and re-flood the
   LSPs.  However, as this scenario could also be triggered by an active
   attack by an adversary, it is recommended that a counter also be kept
   on this case to mitigate the risk from such an active attack.

パスワードロールオーバーのすぐ後のオンである導入問題がある、-、追加論評の利益を得るかもしれないルータ。 ルータ、ルータに関するパスワードロールオーバー直後存在、プロセスは再開するかもしれません。 これが起こるなら、LSP Sequence Numberが新しいパスワードを使用する値1から再開するこの原因します。 しかしながら、Sequence Numberが、より小さいので、隣人はそれらの新しいLSPsを拒絶するでしょう。 隣人がそれに送り続けるそれ自身の古いLSPを認証しないので、ルータはそれ自身のLSP Sequence Numberを増強できません。 したがって、ルータはすべての隣人タイムアウトまでLSP Sequence Numberを隣人にアップデートできません。オリジナルのLSPsのすべて。 この問題への1つの可能な解決がある、-、処理して、何か認証失敗がある本国行きのLSPが地方のSystem IDを持っていて、また、より高いSequence Numberを持っているかどうか検出してください、-、プロセス、持っています。 このイベントで-、プロセスSHOULDはそれに従って、それ自身のLSP Sequence Numberを増強して、LSPsを再あふれさせます。 また、敵による活発な攻撃でこのシナリオを引き起こすことができるでしょう、しかしながら、したがって、また、カウンタがそのような活発な攻撃から危険を緩和するために本件の上に保たれるのは、お勧めです。

Li & Atkinson                Informational                      [Page 3]

RFC 3567           IS-IS Cryptographic Authentication          July 2003

李とアトキンソン情報[3ページ]のRFC3567、-、暗号の認証2003年7月

3. Security Considerations

3. セキュリティ問題

   This document enhances the security of the IS-IS routing protocol.
   Because a routing protocol contains information that need not be kept
   secret, privacy is not a requirement.  However, authentication of the
   messages within the protocol is of interest, to reduce the risk of an
   adversary compromising the routing system by deliberately injecting
   false information into the routing system.

このドキュメントがセキュリティを高める、-、ルーティング・プロトコル。 ルーティング・プロトコルが必要性が秘密にされないという情報を含んでいるので、プライバシーは要件ではありません。 しかしながら、プロトコルの中のメッセージの認証は、故意にルーティングシステムに偽情報を注ぐことによってルーティングシステムに感染する敵の危険を減少させるために興味があります。

   The technology in this document provides an authentication mechanism
   for IS-IS.  The mechanism described here is not perfect and does not
   need to be perfect.  Instead, this mechanism represents a significant
   increase in the work function of an adversary attacking the IS-IS
   protocol, while not causing undue implementation, deployment, or
   operational complexity.

技術が本書では認証機構を提供する、- ここで説明されたメカニズムは、完全でなく、完全である必要はありません。 代わりに、このメカニズムが敵が攻撃する仕事機能のかなりの増加を表す、-、過度の実装、展開、または操作上の複雑さを引き起こしていない間、議定書を作ってください。

   This mechanism does not prevent replay attacks, however, in most
   cases, such attacks would trigger existing mechanisms in the IS-IS
   protocol that would effectively reject old information.  Denial of
   service attacks are not generally preventable in a useful networking
   protocol [4].

しかしながら、このメカニズムが反射攻撃を防がないで、多くの場合、そのような攻撃が中で既存のメカニズムの引き金となるだろう、-、事実上、旧情報を拒絶するプロトコル。 一般に、サービス不能攻撃は役に立つネットワーク・プロトコル[4]で予防可能ではありません。

   Changes to the authentication mechanism described here (primarily:
   to add a Key-ID field such as OSPFv2 and RIPv2 have) were considered
   at some length, but ultimately were rejected.  The mechanism here was
   already widely implemented in 1999.  As of this writing, this
   mechanism is fairly widely deployed within the users interested in
   cryptographic authentication of IS-IS.  The improvement provided by
   the proposed revised mechanism was not large enough to justify the
   change, given the installed base and lack of operator interest in
   deploying a revised mechanism.

加えてください。認証機構への変化がここで説明した、(主として:、OSPFv2とRIPv2にはあるKey-ID分野) 何らかの長さで考えられましたが、結局、拒絶されました。 ここのメカニズムは1999年に既に広く実装されました。 この書くこと現在このメカニズムが暗号の認証に興味を持っているユーザの中で広く公正に配布される、- 提案された改訂されたメカニズムによって提供された改良は変化を正当化できるくらいには大きくはありませんでした、改訂されたメカニズムを配布することへのオペレータ関心のインストールされたベースと不足を考えて。

   If and when a key management protocol appears that is both widely
   implemented and easily deployed to secure routing protocols such as
   IS-IS, a different authentication mechanism that is designed for use
   with that key management schema could be added if desired.

a主要な管理プロトコルが現れるなら、それがルーティング・プロトコルを保証するために広く実装されて、かつ容易に配布される、-、望まれているなら、使用のためにそのかぎ管理図式で設計されている異なった認証機構は加えられるかもしれません。

   If a stronger authentication were believed to be required, then the
   use of a full digital signature [5] would be an approach that should
   be seriously considered.  It was rejected for this purpose at this
   time because the computational burden of full digital signatures is
   believed to be much higher than is reasonable given the current
   threat environment in operational commercial networks.

より強い認証が必要であると信じられているなら、完全なデジタル署名[5]の使用は真剣に考えられるべきであるアプローチでしょうに。 操作上の商業ネットワークにおける現在の脅威環境を考えて、妥当であるというよりも完全なデジタル署名のコンピュータの負担がはるかに高いと信じられているので、それはこのためにこのとき、拒絶されました。

Li & Atkinson                Informational                      [Page 4]

RFC 3567           IS-IS Cryptographic Authentication          July 2003

李とアトキンソン情報[4ページ]のRFC3567、-、暗号の認証2003年7月

Acknowledgements

承認

   The authors would like to thank (in alphabetical order) Dave Katz,
   Steven Luong, Tony Przygienda, Nai-Ming Shen, and Henk Smit for their
   comments and suggestions on this document.

作者はこのドキュメントの上に彼らのコメントと提案についてNai-明のデーヴ・キャッツ、スティーブンLuong、トニーPrzygienda、シン、およびヘンク・スミットに感謝したがっています(アルファベット順に)。

Normative References

引用規格

   [1]  ISO, "Intermediate System to Intermediate System Routing
        Information Exchange Protocol for use in Conjunction with the
        Protocol for Providing the Connectionless-mode Network Service
        (ISO 8473)", ISO/IEC 10589:2002, Second Edition.

[1] ISO、「プロトコルがあるConjunctionにおける、Providing Connectionless-モードNetwork Serviceの使用のためのIntermediate System経路情報Exchangeプロトコルへの中間的System、(ISO8473)、」、ISO/IEC10589:2002、Second Edition。

   [2]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
        for Message Authentication", RFC 2104, February 1997.

[2]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。

Informative References

有益な参照

   [3]  Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual
        environments", RFC 1195, December 1990.

[3]Callon、R.、「使用、TCP/IPとDual環境におけるルート設定のためのOSI IS存在、」、RFC1195、12月1990日

   [4]  Voydock, V. and S. Kent, "Security Mechanisms in High-level
        Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.

[4] ACMコンピューティングは、Vol.15、1983年6月No.日2にVoydockとV.とS.ケント、「ハイレベル・ネットワークにおけるセキュリティー対策」と調査します。

   [5]  Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital
        Signatures", RFC 2154, June 1997.

[5] マーフィーとS.とムジナとM.とB.ウェリントン、「デジタル署名があるOSPF」、RFC2154、1997年6月。

Authors' Addresses

作者のアドレス

   Tony Li
   Procket Networks
   1100 Cadillac Ct.
   Milpitas, CA 95035  USA

トニー李Procketは1100年のキャデラックctをネットワークでつなぎます。 ミルピタス、カリフォルニア95035米国

   Phone: +1 (408) 635-7903
   EMail: tli@procket.net

以下に電話をしてください。 +1 (408) 635-7903 メールしてください: tli@procket.net

   Ran J. Atkinson
   Extreme Networks
   3585 Monroe Street
   Santa Clara, CA 95051  USA

J.アトキンソン極端なネットワーク3585モンロー・通りサンタクララ、カリフォルニア95051米国を経営していました。

   Phone: +1 (408) 579-2800
   EMail: rja@extremenetworks.com

以下に電話をしてください。 +1 (408) 579-2800 メールしてください: rja@extremenetworks.com

Li & Atkinson                Informational                      [Page 5]

RFC 3567           IS-IS Cryptographic Authentication          July 2003

李とアトキンソン情報[5ページ]のRFC3567、-、暗号の認証2003年7月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Li & Atkinson                Informational                      [Page 6]

李とアトキンソンInformationalです。[6ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

スマートスピーカーと連携できる機器の対応表 赤外線リモコン スマートプラグ

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る