RFC3993 日本語訳
3993 Subscriber-ID Suboption for the Dynamic Host ConfigurationProtocol (DHCP) Relay Agent Option. R. Johnson, T. Palaniappan, M.Stapp. March 2005. (Format: TXT=13938 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Johnson
Request for Comments: 3993 T. Palaniappan
Category: Standards Track M. Stapp
Cisco Systems, Inc.
March 2005
コメントを求めるワーキンググループR・ジョンソンRequestをネットワークでつないでください: 3993年のT.Palaniappanカテゴリ: 2005年の標準化過程M.スタップシスコシステムズのInc.行進
Subscriber-ID Suboption for the
Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
Dynamic Host Configuration Protocol(DHCP)中継エージェントオプションのための加入者ID Suboption
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 new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable "Subscriber-ID" with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure.
このメモはDynamic Host Configuration Protocol(DHCP)の中継エージェント情報オプションのために新しいSubscriber-ID「副-オプション」を定義します。 「副-オプション」はDHCP中継エージェントに安定した「加入者ID」をDHCPクライアントメッセージにクライアントと基本的な物理ネットワークインフラストラクチャから独立している方法で関連づけさせます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 2
3. The Subscriber-ID Suboption . . . . . . . . . . . . . . . . . 2
3.1. Suboption Format . . . . . . . . . . . . . . . . . . . . 3
4. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 3
5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 7
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 要件用語. . . . . . . . . . . . . . . . . . . 2 3 加入者ID Suboption. . . . . . . . . . . . . . . . . 2 3.1。 Suboptionは.3 4をフォーマットします。 エージェントの振舞い. . . . . . . . . . . . . . . . . . . . . 3 5をリレーしてください。 DHCPサーバの振舞い. . . . . . . . . . . . . . . . . . . . . 4 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 4 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 5 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 5 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1。 引用規格. . . . . . . . . . . . . . . . . . 5 9.2。 有益な参照. . . . . . . . . . . . . . . . . 5作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 6の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 7
Johnson, et al. Standards Track [Page 1] RFC 3993 Subscriber-ID Suboption March 2005
ジョンソン、他 規格は2005年の加入者ID Suboption行進のときにRFC3993を追跡します[1ページ]。
1. Introduction
1. 序論
DHCP (RFC 2131 [2]) provides IP addresses and configuration information for IPv4 clients. It includes a relay agent capability in which processes within the network infrastructure receive broadcast messages from clients and forward them to DHCP servers as unicast messages. In network environments such as DOCSIS data-over- cable and xDSL, it has proven useful for the relay agent to add information to the DHCP message before forwarding it, by using the relay agent information option (RFC 3046 [3]).
DHCP、(RFC2131[2])はIPアドレスと設定情報をIPv4クライアントに提供します。 それはネットワークインフラの中のプロセスがクライアントから同報メッセージを受け取って、ユニキャストメッセージとしてDHCPサーバに彼らを送る中継エージェント能力を含んでいます。 DOCSISデータ過剰ケーブルやxDSLなどのネットワーク環境で、それを進める前に中継エージェントがDHCPメッセージに情報を追加するのが役に立つと判明しました、中継エージェント情報オプションを使用することによって。(RFC3046[3])。
Servers that recognize the relay agent option echo it back in their replies, and some of the information that relays add may be used to help an edge device efficiently return replies to clients. The information that relays supply can also be used in the server's decision making about the addresses and configuration parameters that the client should receive.
中継エージェントオプションを認識するサーバが彼らの回答でそれをecho backです、そして、リレーがエッジデバイスが効率的に戻るのを助けるのに使用されるかもしれないと言い足す情報のいくつかがクライアントに答えます。 また、クライアントが受け取るべきであるアドレスと設定パラメータに関してサーバの意志決定に供給をリレーする情報は使用できます。
In many service provider environments, it is desirable to associate some provider-specific information with clients' DHCP messages. This is often done by using the relay agent information option. RFC 3046 defines Remote-ID and Circuit-ID suboptions that are used to carry such information. The values of those suboptions, however, are usually based on a network resource such as an IP address of a network access device, an ATM Virtual Circuit identifier, or a DOCSIS cable-modem identifier. As a result, the values carried in these suboptions are dependent on the physical network configuration. If a client connects to the service provider network through different paths, different values are carried in network-dependent suboptions.
多くのサービスプロバイダー環境で、何らかのプロバイダー特殊情報をクライアントのDHCPメッセージに関連づけるのは望ましいです。 中継エージェント情報オプションを使用することによって、これをしばしばします。 RFC3046はそのような情報を運ぶのに使用されるRemote-IDとCircuit-ID「副-オプション」を定義します。 しかしながら、通常、それらの「副-オプション」の値はネットワークアクセスデバイス、ATM Virtual Circuit識別子、またはDOCSISケーブルモデム識別子のIPアドレスのようにネットワーク資源に基づいています。 その結果、これらの「副-オプション」で運ばれた値は物理ネットワーク構成に依存しています。 クライアントが異なった経路を通してサービスプロバイダーネットワークに接続するなら、異価はネットワーク依存する「副-オプション」で運ばれます。
2. Requirements Terminology
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 RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
3. The Subscriber-ID Suboption
3. 加入者ID Suboption
In complex service provider environments, connecting a customer's DHCP configuration and administrative information is necessary. The Subscriber-ID suboption carries a value that can be independent of the physical network configuration through which the subscriber is connected. This value complements, and might well be used in addition to, the network-based relay agent option suboptions discussed in Section 2. The "subscriber-id" assigned by the provider is intended to be stable as customers connect through different paths, and as network changes occur.
複雑なサービスプロバイダー環境で、顧客のDHCP構成と管理情報を接続するのが必要です。 Subscriber-ID「副-オプション」は加入者が接続されている物理ネットワーク構成から独立する場合がある値を運びます。 に加えてこれが補数を評価して、たぶん使用されるだろう、セクション2で議論したネットワークベースの中継エージェントオプション「副-オプション」 異なった経路、ネットワーク変化が起こるとき、顧客が接続するのでプロバイダーによって割り当てられた「加入者イド」が安定していることを意図します。
Johnson, et al. Standards Track [Page 2] RFC 3993 Subscriber-ID Suboption March 2005
ジョンソン、他 規格は2005年の加入者ID Suboption行進のときにRFC3993を追跡します[2ページ]。
The Subscriber-ID information allows the service provider to assign/activate subscriber-specific actions; e.g., assignment of host IP address and subnet mask, DNS configuration, or trigger accounting. This suboption is de-coupled from the access network's physical structure, so subscriber moves from one access-point to another, for example, would not require reconfiguration at the service provider's DHCP servers.
Subscriber-ID情報で、サービスプロバイダーは、加入者特有の動作を割り当てるか、または起動します。 例えば、ホストIPアドレスとサブネットマスクか、DNS構成か、引き金の会計の課題。 この「副-オプション」がアクセスネットワークの物理構造から衝撃を吸収されるので、1つのアクセスポイントから例えば、別のものまでの加入者移動はサービスプロバイダーのDHCPサーバにおける再構成を必要としないでしょう。
The Subscriber-ID is an ASCII string; the encoding of the string is defined in Section 3.1. The semantic contents of the Subscriber-ID string are, of course, provider-specific. This specification does not establish any semantic requirements on the data in the string.
Subscriber-IDはASCIIストリングです。 ストリングのコード化はセクション3.1で定義されます。 Subscriber-IDストリングの意味内容はもちろんプロバイダー特有です。 この仕様はストリングのデータに関するどんな意味要件も確立しません。
3.1. Suboption Format
3.1. Suboption形式
This memo defines a new DHCP relay agent option suboption that carries a "Subscriber-ID" value. The value is an ASCII string. The suboption takes a form similar to that of many other relay information option suboptions:
このメモは「加入者ID」値を運ぶ新しいDHCP中継エージェントオプション「副-オプション」を定義します。 値はASCIIストリングです。 「副-オプション」は他の多くのリレー情報オプション「副-オプション」のものと同様の形を取ります:
0 1 2 3 4 5
+-----+-----+-----+-----+-----+----+--
|Code | Len | Subscriber-ID string ...
+-----+-----+-----+-----+-----+----+--
0 1 2 3 4 5 +-----+-----+-----+-----+-----+----+-- |コード| レン| 加入者IDストリング… +-----+-----+-----+-----+-----+----+--
The Code for the suboption is 6.
「副-オプション」のためのCodeは6歳です。
The one-octet Len field is the length of the ID string, in octets. The minimum length of the ID string is 1 octet.
1八重奏のレン分野は八重奏で、IDストリングの長さです。 IDストリングの最小の長さは1つの八重奏です。
The "Subscriber-ID" is an NVT ASCII [4] string. The string MUST NOT be NULL terminated, as the length is specified in the "Len" field.
「加入者ID」はNVT ASCII[4]ストリングです。 ストリングは長さが「レン」分野で指定されるとき終えられたNULLであるはずがありません。
4. Relay Agent Behavior
4. 中継エージェントの振舞い
DHCP relay agents MAY be configured to include a Subscriber-ID suboption if they include a relay agent information option in relayed DHCP messages. The subscriber-id strings themselves are assigned and configured through mechanisms that are outside the scope of this memo.
彼らがリレーされたDHCPメッセージに中継エージェント情報オプションを含んでいるなら、DHCP中継エージェントは、Subscriber-ID「副-オプション」を含むように構成されるかもしれません。 加入者イドストリング自体は、このメモの範囲の外にあるメカニズムを通して割り当てられて、構成されます。
Johnson, et al. Standards Track [Page 3] RFC 3993 Subscriber-ID Suboption March 2005
ジョンソン、他 規格は2005年の加入者ID Suboption行進のときにRFC3993を追跡します[3ページ]。
5. DHCP Server Behavior
5. DHCPサーバの振舞い
This suboption provides additional information to the DHCP server. If it is configured to support this option, the DHCP server may use this information in addition to other relay agent option data and other options included in the DHCP client messages in order to assign an IP address and/or other configuration parameters to the client. There is no special additional processing for this suboption.
この「副-オプション」はDHCPサーバに追加情報を提供します。このオプションをサポートするのが構成されているなら、DHCPクライアントメッセージにオプションデータと別の選択肢を含んでいる場合、DHCPサーバは、IPアドレス、そして/または、他の設定パラメータをクライアントに割り当てるのに他の中継エージェントに加えてこの情報を使用するかもしれません。 どんなこの「副-オプション」に、特別な追加処理もありません。
6. Security Considerations
6. セキュリティ問題
Message authentication in DHCP for intradomain use where the out-of- band exchange of a shared secret is feasible is defined in RFC 3118 [5]. Potential exposures to attacks are discussed in section 7 of the DHCP protocol specification in RFC 2131 [2].
-バンドでは、共有秘密キーの交換は可能です。intradomainのためのDHCPの通報認証がどこを使用するか、アウト、RFC3118[5]では、定義されます。 RFC2131[2]でDHCPプロトコル仕様のセクション7で攻撃への潜在被曝について議論します。
The DHCP relay agent option depends on a trusted relationship between the DHCP relay agent and the server, as described in section 5 of RFC 3046. Fraudulent relay agent option data could potentially lead to theft-of-service or exhaustion of limited resources (like IP addresses) by unauthorized clients. A host that tampered with relay agent data associated with another host's DHCP messages could deny service to that host, or interfere with its operation by leading the DHCP server to assign it inappropriate configuration parameters.
DHCP中継エージェントオプションはDHCP中継エージェントとサーバとの信じられた関係によります、RFC3046のセクション5で説明されるように。 詐欺的な中継エージェントオプションデータは潜在的にサービスの窃盗か疲れきるのに権限のないクライアントが限りある資源(IPアドレスのような)についてつながるかもしれません。 DHCPサーバが不適当な設定パラメータをそれに割り当てるように導くことによって、別のホストのDHCPメッセージに関連している中継エージェントデータをいじったホストは、そのホストに対するサービスを否定するか、または操作を妨げることができるでしょう。
While the introduction of fraudulent relay agent options can be prevented by a perimeter defense that blocks these options unless the relay agent is trusted, a deeper defense using authentication for relay agent options via the Authentication Suboption [6] or IPSec [7] SHOULD be deployed as well.
詐欺的な中継エージェントオプションの導入を防ぐことができる間、また、中継エージェントが信じられない場合これらのオプションを妨げる規定の防衛線内での防衛、中継エージェントオプションにAuthentication Suboption[6]を通して認証を使用するより深いディフェンスまたはIPSec[7]SHOULDによって、配布されてください。
There are several data fields in a DHCP message conveying information that may identify an individual host on the network. These include the chaddr, the client-id option, and the hostname and client-fqdn options. Depending on the type of identifier selected, the Subscriber-ID suboption may also convey information that identifies a specific host or a specific user on the network. In practice, this information isn't exposed outside the internal service-provider network, where DHCP messages are usually confined. Administrators who configure data that's going to be used in DHCP Subscriber-ID suboptions should be careful to use identifiers that are appropriate for the types of networks they administer. If DHCP messages travel outside the service-provider's own network, or if the suboption values may become visible to other users, that may raise privacy concerns for the access provider or service provider.
ネットワークで個々のホストを特定するかもしれない情報を伝えるDHCPメッセージにはいくつかのデータ・フィールドがあります。 これらはchaddr、クライアントイドオプション、ホスト名、およびクライアント-fqdnオプションを含んでいます。 選択された識別子のタイプに頼っていて、また、Subscriber-ID「副-オプション」はネットワークで特定のホストか特定のユーザを特定する情報を伝えるかもしれません。 実際には、この情報は内部のサービスプロバイダーネットワークの外で暴露されません。そこでは、通常、DHCPメッセージが限定されます。 DHCP Subscriber-ID「副-オプション」で使用されるデータを構成する管理者はそれらが管理するネットワークのタイプに、適切な識別子を使用するのに慎重であるはずです。 DHCPメッセージがサービスプロバイダーの自身のネットワークの外を移動するか、または「副-オプション」値が他のユーザにとって目に見えるようになるかもしれないなら、それはアクセスプロバイダかサービスプロバイダーのためにプライバシーの問題を提起するかもしれません。
Johnson, et al. Standards Track [Page 4] RFC 3993 Subscriber-ID Suboption March 2005
ジョンソン、他 規格は2005年の加入者ID Suboption行進のときにRFC3993を追跡します[4ページ]。
7. IANA Considerations
7. IANA問題
IANA has assigned a value of 6 from the DHCP Relay Agent Information Option [3] suboption codes for the Subscriber-ID Suboption described in this document.
IANAは本書では説明されたSubscriber-ID SuboptionのためにDHCP Relayエージェント情報Option[3]「副-オプション」コードから6の値を割り当てました。
8. Acknowledgements
8. 承認
This document is the result of work done within Cisco Systems. Thanks especially to Andy Sudduth for his review comments.
このドキュメントはシスコシステムズの中で行われた仕事の結果です。彼のレビューコメントを特にアンディSudduthをありがとうございます。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[2]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001.
[3] パトリック、M.、「DHCP中継エージェント情報オプション」、RFC3046、2001年1月。
[4] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD
8, RFC 854, May 1983.
[4] ポステルとJ.とJ.レイノルズ、「telnetプロトコル仕様」、STD8、RFC854、1983年5月。
9.2. Informative References
9.2. 有益な参照
[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[5]DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、2001年6月。
[6] Stapp, M., "The Authentication Suboption for the DHCP Relay
Agent Option", Work in Progress.
[6] スタップ、M.、「DHCP中継エージェントオプションのための認証Suboption」が進行中で働いています。
[7] Droms, R., "Authentication of Relay Agent Options Using IPSec",
Work in Progress.
[7] R.、「IPSecを使用する中継エージェントオプションの認証」というDromsは進行中で働いています。
Johnson, et al. Standards Track [Page 5] RFC 3993 Subscriber-ID Suboption March 2005
ジョンソン、他 規格は2005年の加入者ID Suboption行進のときにRFC3993を追跡します[5ページ]。
Authors' Addresses
作者のアドレス
Richard Johnson Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
リチャードペニスシスコシステムズInc.170W.タスマンサンノゼ博士、カリフォルニア95134米国
Phone: 408.526.4000 EMail: raj@cisco.com
以下に電話をしてください。 408.526.4000 メールしてください: raj@cisco.com
Theyn Palaniappan Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
Theyn PalaniappanシスコシステムズInc.170W.タスマンサンノゼ博士、カリフォルニア95134米国
Phone: 408.526.4000 EMail: athenmoz@cisco.com
以下に電話をしてください。 408.526.4000 メールしてください: athenmoz@cisco.com
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
スタップシスコシステムズInc.1414マサチューセッツAveをマークしてください。 Boxborough、MA01719米国
Phone: 978.936.0000 EMail: mjs@cisco.com
以下に電話をしてください。 978.936.0000 メールしてください: mjs@cisco.com
Johnson, et al. Standards Track [Page 6] RFC 3993 Subscriber-ID Suboption March 2005
ジョンソン、他 規格は2005年の加入者ID Suboption行進のときにRFC3993を追跡します[6ページ]。
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機能のための基金は現在、インターネット協会によって提供されます。
Johnson, et al. Standards Track [Page 7]
ジョンソン、他 標準化過程[7ページ]
一覧
スポンサーリンク
