RFC4449 日本語訳
4449 Securing Mobile IPv6 Route Optimization Using a Static SharedKey. C. Perkins. June 2006. (Format: TXT=15080 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Perkins Request for Comments: 4449 Nokia Research Center Category: Standards Track June 2006
コメントを求めるワーキンググループC.パーキンス要求をネットワークでつないでください: 4449年のノキアリサーチセンターカテゴリ: 標準化過程2006年6月
Securing Mobile IPv6 Route Optimization Using a Static Shared Key
モバイルIPv6が経路最適化であると静的な共有されたキーを使用することで機密保護します。
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 (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates.
モバイルノードと通信員ノードは次にBinding Updatesを認可するのに使用できるBinding Management Keyを前計算することの役に立つデータをあらかじめ設定するかもしれません。
Table of Contents
目次
1. Introduction ....................................................1 2. Applicability Statement .........................................2 3. Precomputing a Binding Management Key (Kbm) .....................3 4. Security Considerations .........................................4 5. Acknowledgement .................................................5 6. References ......................................................5 6.1. Normative References .......................................5 6.2. Informative References .....................................6
1. 序論…1 2. 適用性声明…2 3. 拘束力がある管理キー(Kbm)をPrecomputingします…3 4. セキュリティ問題…4 5. 承認…5 6. 参照…5 6.1. 標準の参照…5 6.2. 有益な参照…6
1. Introduction
1. 序論
This specification introduces an alternative, low-latency security mechanism for protecting signaling related to the route optimization in Mobile IPv6. The default mechanism specified in [1] uses a periodic return routability test to verify both the "right" of the mobile node to use a specific home address, as well as the validity of the claimed care-of address. That mechanism requires no configuration and no trusted entities beyond the mobile node's home agent.
この仕様は、モバイルIPv6に経路最適化に関連するシグナリングを保護するために代替の、そして、低い潜在のセキュリティー対策を紹介します。 [1]で指定されたデフォルトメカニズムがモバイルノードが特定のホームアドレスを使用する「権利」と正当性の両方について確かめる周期的なリターンroutabilityテストを使用する、要求、注意、-、アドレス そのメカニズムはモバイルノードのホームのエージェントを超えて構成がなくて信じられた実体を全く必要としません。
Perkins Standards Track [Page 1] RFC 4449 Shared Data for Precomputable Kbm June 2006
パーキンス標準化過程[1ページ]RFC4449は2006年6月にPrecomputable Kbmのためのデータを共有しました。
The mechanism specified in this document, however, requires the configuration of a shared secret between mobile node and its correspondent node. As a result, messages relating to the routability tests can be omitted, leading to significantly smaller latency. In addition, the right to use a specific home address is ensured in a stronger manner than in [1]. On the other hand, the applicability of this mechanisms is limited due to the need for preconfiguration. This mechanism is also limited to use only in scenarios where mobile nodes can be trusted not to misbehave, as the validity of the claimed care-of addresses is not verified.
しかしながら、本書では指定されたメカニズムはモバイルノードとその通信員ノードの間の共有秘密キーの構成を必要とします。 その結果、かなりわずかな潜在に通じて、routabilityテストに関連するメッセージは省略できます。 さらに、特定のホームアドレスを使用する権利は[1]より強い方法で確実にされます。 他方では、このメカニズムの適用性は前構成の必要性のため制限されます。 また、このメカニズムはふらちな事をしないとモバイルノードを信じることができるシナリオだけにおける使用に制限されます、要求の正当性として注意、-、アドレスが確かめられません。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Other terminology is used as already defined in [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか? 他の用語は[1]で既に定義されるように使用されています。
2. Applicability Statement
2. 適用性証明
This mechanism is useful in scenarios where the following conditions are all met:
このメカニズムは以下の条件がすべて満たされるシナリオで役に立ちます:
- Mobile node and correspondent node are administered within the same domain.
- モバイルノードと通信員ノードは同じドメインの中で管理されます。
- The correspondent node has good reason to trust the actions of the mobile node. In particular, the correspondent node needs to be certain that the mobile node will not launch flooding attacks against a third party as described in [5].
- 通信員ノードには、モバイルノードの機能を信じる十分な理由があります。 特に、通信員ノードは、モバイルノードが[5]で説明されるように第三者に対してフラッディング攻撃に着手しないのを確信している必要があります。
- The configuration effort related to this mechanism is acceptable. Users MUST be able to generate/select a sufficiently good value for Kcn (see [3])
- このメカニズムに関連する構成取り組みは許容できます。 ユーザは、Kcnのために十分良い値を生成しなければならないか、または選択できなければなりません。([3])を見てください。
- There is a desire to take advantage of higher efficiency or greater assurance with regards to the correctness of the home address offered via this mechanism.
- あいさつでこのメカニズムで提供されたホームアドレスの正当性により高い効率か、より大きい保証を利用する願望があります。
- This mechanism is used only for authenticating Binding Update messages (and not, e.g., data), so the total volume of traffic is low (see RFC 4107 [4], and the discussion in section 4).
- そして、このメカニズムがBinding Updateメッセージを認証するのにだけ使用される、(例えば、データ)、それで、トラフィックの全容積は低いです(RFC4107[4]、およびセクション4の議論を見てください)。
This mechanism can also be useful in software development, testing, and diagnostics related to mobility signaling.
また、このメカニズムも移動性シグナリングに関連するソフトウェア開発、テスト、および病気の特徴で役に立つ場合があります。
Generally speaking, the required level of trust that the correspondent node needs for enabling a precomputable Kbm with a mobile node is more often found within relatively small, closed groups of users who are personally familiar with each other, or who
または、概して、通信員ノードがモバイルノードでprecomputable Kbmを有効にするのに必要とする必要なレベルの信頼が個人的に互いに詳しいユーザの比較的小さくて、閉じているグループの中で、よりしばしば見つけられる、だれ
Perkins Standards Track [Page 2] RFC 4449 Shared Data for Precomputable Kbm June 2006
パーキンス標準化過程[2ページ]RFC4449は2006年6月にPrecomputable Kbmのためのデータを共有しました。
have some external basis for establishing trustworthy interactions. A typical example scenario where this mechanism is applicable is within a corporation, or between specific users. Application in the general Internet is typically not possible due to the effort that is required to manually configure the correspondent nodes. Application at a public network operator is typically not possible due to requirements placed on the trustworthiness of mobile nodes.
信頼できる相互作用を設立する何らかの外部の基礎を持ってください。 会社以内か特定のユーザの間には、このメカニズムが適切である典型的な例のシナリオがあります。 一般的なインターネットのアプリケーションは手動で通信員ノードを構成するのに必要である取り組みのために通常可能ではありません。 公衆通信回線オペレータのアプリケーションはモバイルノードの信頼できることに置かれた要件のために通常可能ではありません。
3. Precomputing a Binding Management Key (Kbm)
3. 拘束力がある管理キーをPrecomputingします。(Kbm)
A mobile node and a correspondent node may preconfigure data useful for creating a Binding Management Key (Kbm), which can then be used for authorizing binding management messages, especially Binding Update and Binding Acknowledgement messages. This data is as follows:
モバイルノードと通信員ノードは次に管理メッセージ、特にBinding Update、およびBinding Acknowledgementメッセージを縛るのを認可するのに使用できるBinding Management Key(Kbm)を作成することの役に立つデータをあらかじめ設定するかもしれません。 このデータは以下の通りです:
- A shared key (Kcn) used to generate keygen tokens, at least 20 octets long
- 共有されたキー(Kcn)は以前は長い間、よくkeygenトークン、少なくとも20の八重奏を生成していました。
- A nonce for use when generating the care-of keygen token
- 生成するときの使用のための一回だけ、注意、-、keygenトークン
- A nonce for use when generating the home keygen token
- ホームkeygenトークンを生成するときの使用のための一回だけ
The keygen tokens MUST be generated from Kcn and the nonces as specified in Mobile IPv6 [1] return routability. Likewise, the binding management key Kbm must subsequently be generated from the keygen tokens in the same way as specified in Mobile IPv6 [1]. The preconfigured data is associated to the mobile node's home address. Kcn MUST be generated with sufficient randomness (see RFC 4086 [3]).
モバイルIPv6[1]リターンroutabilityの指定されるとしてのKcnと一回だけからkeygenトークンを生成しなければなりません。 同様に、次に、keygenトークンから拘束力がある管理の主要なKbmをモバイルIPv6[1]の指定されるのと同じように生成しなければなりません。 あらかじめ設定されたデータはモバイルノードのホームアドレスに関連づけられます。 十分な偶発性でKcnを生成しなければなりません。(RFC4086[3])を見てください。
Replay protection for Binding Update messages using Kbm computed from the preconfigured data depends upon the value of the Sequence Number field in the Binding Update. If the correspondent node does not maintain information about the recently used values of that field, then there may be an opportunity for a malicious node to replay old Binding Update messages and fool the correspondent node into routing toward an old care-of address. For this reason, a correspondent node that uses a precomputable Kbm also MUST keep track of the most recent value of the Sequence Number field of Binding Update messages using the precomputable Kbm value (for example, by committing it to stable storage).
あらかじめ設定されたデータから計算されたKbmを使用するBinding Updateメッセージのための反復操作による保護はBinding UpdateのSequence Number分野の値に依存します。 通信員ノードがその分野の最近中古の値の情報を保守しないなら悪意があるノードが古いBinding Updateメッセージを再演して、ルーティングへの通信員ノードをだます機会があるかもしれない、老人、注意、-、アドレス この理由で、precomputable Kbm値(例えば安定貯蔵にそれを遂行することによって)を使用して、precomputable Kbmを使用する通信員ノードもBinding UpdateメッセージのSequence Number分野の最新の値の動向をおさえなければなりません。
Perkins Standards Track [Page 3] RFC 4449 Shared Data for Precomputable Kbm June 2006
パーキンス標準化過程[3ページ]RFC4449は2006年6月にPrecomputable Kbmのためのデータを共有しました。
When a Binding Update is to be authenticated using such a precomputable binding key (Kbm), the Binding Authorization Data suboption MUST be present. The Nonce Indices option SHOULD NOT be present. If it is present, the nonce indices supplied SHOULD be ignored and are not included as part of the calculation for the authentication data, which is to be performed exactly as specified in [1].
Binding Updateがそのような「前-計算でき」拘束力があるキー(Kbm)を使用することで認証されることになっているとき、Binding Authorization Data suboptionは存在していなければなりません。 Nonce IndicesはSHOULD NOTにゆだねます。存在してください。 それが存在しているなら、SHOULDが供給された一回だけのインデックスリストは、無視されて、[1]でちょうど指定されるように実行されることである認証データのための計算の一部として含まれていません。
4. Security Considerations
4. セキュリティ問題
A correspondent node and a mobile node may use a precomputable binding management key (Kbm) to manage the authentication requirements for binding cache management messages. Such keys must be handled carefully to avoid inadvertent exposure to the threats outlined in [5]. Many requirements listed in this document are intended to ensure the safety of the manual configuration. In particular, Kcn MUST be generated with sufficient randomness (see RFC 4086 [3]), as noted in Section 3.
通信員ノードとモバイルノードは、拘束力があるキャッシュ管理メッセージのための認証要件を管理するのに、「前-計算でき」拘束力がある管理キー(Kbm)を使用するかもしれません。 [5]に概説された脅威として不注意な暴露を避けるために慎重にそのようなキーを扱わなければなりません。 本書ではリストアップされた多くの要件が手動の構成の安全を確実にすることを意図します。 特に、十分な偶発性でKcnを生成しなければなりません。(セクション3に述べられるようにRFC4086[3])を見てください。
Manually configured keys MUST be used in conformance with RFC 4107 [4]. Used according to the applicability statement, and with the other security measures mandated in this specification, the keys will satisfy the properties in that document. In order to ensure protection against dictionary attacks, the configured security information is intended to be used ONLY for authenticating Binding Update messages.
RFC4107[4]で順応に手動で構成されたキーを使用しなければなりません。 適用性証明、および他の安全策がこの仕様で強制されている状態で使用されていて、キーはそのドキュメントで特性を満たすでしょう。 辞書攻撃に対して保護を保証するために、Binding Updateメッセージを認証するだけに構成されたセキュリティ情報が使用されることを意図します。
A mobile node MUST use a different value for Kcn for each node in its Binding Update List, and a correspondent node MUST ensure that every mobile node uses a different value of Kcn. This ensures that the sender of a Binding Update can always be uniquely determined. This is necessary, as this authorization method does not provide any guarantee that the given care-of address is legitimate. For the same reason, this method SHOULD only be applied between nodes that are under the same administration. The return routability procedure is RECOMMENDED for all general use and MUST be the default, unless the user explicitly overrides this by entering the aforementioned preconfigured data for a particular peer.
モバイルノードはBinding Update Listの各ノードのためのKcnに異価を使用しなければなりません、そして、通信員ノードはあらゆるモバイルノードがKcnの異価を使用するのを確実にしなければなりません。 これは、Binding Updateの送付者がいつも唯一決定できるのを確実にします。 この承認メソッドがどんな保証にもそれを提供しないときこれが必要である、付与、注意、-、アドレスは正統です。 同じくらいは推論して、このメソッドはSHOULDです。同じ管理の下でそうであるノードの間で適用されるだけです。 リターンroutability手順は、すべての一般的使用のためのRECOMMENDEDであり、デフォルトであるに違いありません、ユーザが特定の同輩のために前述のあらかじめ設定されたデータを入力することによって明らかにこれをくつがえさない場合。
Replay protection for the Binding Authorization Data option authentication mechanism is provided by the Sequence Number field of the Binding Update. This method of providing replay protection fails when the Binding Update sequence numbers cycle through the 16 bit counter (i.e., not more than 65,536 distinct uses of Kbm), or if the sequence numbers are not protected against reboots. If the mobile node were to send a fresh Binding Update to its correspondent node every hour, 24 hours a day, every day of the year, this would require changing keys every 7 years. Even if the mobile node were to do so
Binding UpdateのSequence Number分野でBinding Authorization Dataオプション認証機構のための反復操作による保護を提供します。 Binding Update一連番号が16ビットのカウンタ(すなわち、Kbmの6万5536以上の異なった用途でない)かそれともリブートに対して保護されないかどうかを通して循環すると、反復操作による保護を提供するこのメソッドは失敗します。 モバイルノードが年の毎日毎時間1日24時間新鮮なBinding Updateを通信員ノードに送ることであるなら、これは、7年毎に転調するのを必要とします。 モバイルノードがそうすることであったなら
Perkins Standards Track [Page 4] RFC 4449 Shared Data for Precomputable Kbm June 2006
パーキンス標準化過程[4ページ]RFC4449は2006年6月にPrecomputable Kbmのためのデータを共有しました。
every minute, this would provide protection for over a month. Given typical mobility patterns, there is little danger of replay problems; nodes for which problems might arise are expected to use methods other than manual configuration for Kcn and the associated nonces. When the Sequence Number field rolls over, the parties SHOULD configure a new value for Kcn, so that new Kbm values will be computed.
毎分、これは1カ月以上保護を提供するでしょう。 典型的な移動パターンを考えて、再生問題という危険がほとんどありません。 問題が起こるかもしれないノードがKcnのための手動の構成と関連一回だけ以外のメソッドを使用すると予想されます。 Sequence Number分野がひっくり返るとき、SHOULDがKcnで、したがって、そんなに新しい状態で新しい値を構成するパーティーは計算されるでしょうKbmが、評価する。
If a correspondent node does NOT keep track of the sequence number for Binding Update messages from a particular mobile node, then the correspondent node could be fooled into accepting an old value for the mobile node's care-of address. In the unlikely event that this address was reallocated to another IPv6 node in the meantime, that IPv6 node would then be vulnerable to unwanted traffic emanating from the correspondent node.
通信員ノードがそうしないなら、特定のモバイルノードからのBinding Updateメッセージのために一連番号の動向をおさえてください、古い値を受け入れるように通信員ノードをだますことができたその時、モバイルノードのもの、注意、-、アドレス ありそうもないイベントでは、このアドレスが差し当たり別のIPv6ノードに再割当てされて、それがIPv6ノードであることはその時、通信員ノードから発する求められていないトラフィックに被害を受け易いでしょう。
Note that where a node has been configured to use the mechanism specified in this document with a particular peer, it SHOULD NOT attempt to use another mechanism, even if the peer requests this or claims not to support the mechanism in this document. This is necessary in order to prevent bidding down attacks.
ノードが使用に構成されたところでメカニズムが本書では特定の同輩と共に指定して、それが別のメカニズムを使用するSHOULD NOT試みであることに注意してください、同輩が本書ではメカニズムをサポートしないようにこれかクレームを要求しても。 これが、攻撃の下側に入札するのを防ぐのに必要です。
There is no upper bound on the lifetime defined for the precomputable Kbm. As noted, the key is very likely to be quite secure over the lifetime of the security association and usefulness of applications between a mobile node and correspondent node that fit the terms specified in section 2.
precomputable Kbmのために定義された生涯、上限が全くありません。 注意されるように、キーは非常にセクション2で指定された用語に合うモバイルノードと通信員ノードの間のセキュリティ協会の生涯、アプリケーションの有用性の上でかなり安全である傾向があります。
5. Acknowledgement
5. 承認
Thanks are due to everyone who reviewed the discussion of issue #146. Thanks to Jari Arkko for supplying text for the Introduction.
感謝は問題#146の議論を見直した皆のためです。 ヤリArkkoにIntroductionにテキストを供給してくださってありがとうございます。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[3] イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[4] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[4]Bellovin、S.とR.Housley、「暗号化キー管理のためのガイドライン」BCP107、2005年6月のRFC4107。
Perkins Standards Track [Page 5] RFC 4449 Shared Data for Precomputable Kbm June 2006
パーキンス標準化過程[5ページ]RFC4449は2006年6月にPrecomputable Kbmのためのデータを共有しました。
6.2. Informative References
6.2. 有益な参照
[5] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4226, December 2005.
[5]Nikander、P.、Arkko、J.、香気、T.、モンテネグロ、G.、およびE.Nordmark、「モバイルIPバージョン6経路最適化セキュリティはバックグラウンドを設計します」、RFC4226、2005年12月。
Author's Address
作者のアドレス
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
チャールズE.パーキンスノキアリサーチセンター313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650 625-2986 Fax: +1 650 625-2502 EMail: charles.perkins@nokia.com
以下に電話をしてください。 +1 650 625-2986Fax: +1 650 625-2502 メールしてください: charles.perkins@nokia.com
Perkins Standards Track [Page 6] RFC 4449 Shared Data for Precomputable Kbm June 2006
パーキンス標準化過程[6ページ]RFC4449は2006年6月にPrecomputable Kbmのためのデータを共有しました。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Perkins Standards Track [Page 7]
パーキンス標準化過程[7ページ]
一覧
スポンサーリンク