Network Working Group T. Kivinen
Request for Comments: 3947 SafeNet
Category: Standards Track B. Swander
Microsoft
A. Huttunen
F-Secure Corporation
V. Volpe
Cisco Systems
January 2005
Negotiation of NAT-Traversal in the IKE
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE).
この文書は、IPsecホスト間の1つまたは複数のネットワーク・アドレス変換デバイス（NATを）を検出する方法について説明し、インターネットキー交換（IKE）にNATボックスを通してIPsecパケットのUDPカプセル化の使用を交渉する方法。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . . 3
3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Detecting Support of NAT-Traversal. . . . . . . . . . . . 4
3.2. Detecting the Presence of NAT . . . . . . . . . . . . . . 4
4. Changing to New Ports . . . . . . . . . . . . . . . . . . . . . 6
5. Quick Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Negotiation of the NAT-Traversal Encapsulation. . . . . . 9
5.2. Sending the Original Source and Destination Addresses . . 9
6. Initial Contact Notifications. . . . . . . . . . . . . . . . . 11
7. Recovering from the Expiring NAT Mappings. . . . . . . . . . . 11
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13
10. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
This document is split into two parts. The first describes what is needed in IKE Phase 1 for NAT-Traversal support. This includes detecting whether the other end supports NAT-Traversal, and detecting whether there is one or more NATs between the peers.
この文書では、2つの部分に分割されます。最初は、NATトラバーサルをサポートするためのIKEフェーズ1で必要とされるものを説明します。これは、もう一方の端は、NATトラバーサルをサポートしているかどうかを検出し、ピア間の一の以上のNATがあるかどうかを検出することを含みます。
The second part describes how to negotiate the use of UDP encapsulated IPsec packets in IKE's Quick Mode. It also describes how to transmit the original source and destination addresses to the peer, if required. These addresses are used in transport mode to update the TCP/IP checksums incrementally so that they will match after the NAT transform. (The NAT cannot do this, because the TCP/IP checksum is inside the UDP encapsulated IPsec packet.)
第二部は、IKEのクイックモードでのUDPカプセル化されたIPsecパケットの使用を交渉する方法について説明します。また、必要に応じて、ピアに元のソースアドレスと宛先アドレスを送信する方法について説明します。これらのアドレスは、NAT変換後、彼らが一致するようにインクリメンタルにTCP / IPのチェックサムを更新するために、トランスポートモードで使用されています。 （TCP / IPチェックサムは、UDPは、IPsecパケットをカプセル化内にあるのでNATは、これを行うことはできません。）
The document [RFC3948] describes the details of UDP encapsulation, and [RFC3715] provides background information and motivation of NAT-Traversal in general. In combination with [RFC3948], this document represents an "unconditionally compliant" solution to the requirements as defined by [RFC3715].
文書[RFC3948]はUDPカプセル化の詳細を説明し、[RFC3715]は、一般的に背景情報及びNATトラバーサルの動機を提供します。 [RFC3715]で定義されるように[RFC3948]と組み合わせて、この文書は、要件に「無条件に準拠」ソリューションを表します。
In the basic scenario for this document, the initiator is behind NA(P)T, and the responder has a fixed static IP address.
この文書の基本的なシナリオでは、イニシエータは、NA（P）Tの後ろにあり、レスポンダは、固定された静的IPアドレスを有します。
This document defines a protocol that will work even if both ends are behind NAT, but the process of how to locate the other end is out of the scope of this document. In one scenario, the responder is behind a static host NAT (only one responder per IP, as there is no way to use any destination ports other than 500/4500). That is, it is known by the configuration.
この文書では、両端がNATの背後にある場合でも動作するプロトコルを定義しますが、もう一方の端を見つける方法のプロセスは、この文書の範囲外です。 （500/4500以外の任意の宛先ポートを使用する方法がないように、IPごとに1つのだけレスポンダ）あるシナリオでは、応答は、静的ホストNATの背後にあります。つまり、それは、構成によって知られています。
This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They are to be interpreted as described in [RFC2119].
、 "ではないMUST" キーワード "MUST" を使用しなければならない。この文書では、 "REQUIRED"、 "SHALL NOT"、 "SHOULD NOT"、「推奨、 "MAY"、 "OPTIONAL" は記述する "SHOULD" "ものと"要件。彼らは[RFC2119]に記載されているように解釈されるべきです。
The detection of support for NAT-Traversal and detection of NAT along the path between the two IKE peers occurs in IKE [RFC2409] Phase 1.
2つのIKEピアとの間の経路に沿ってNATのNATトラバーサルおよび検出のためのサポートの検出は、IKE [RFC2409]フェーズ1で生じます。
The NAT may change the IKE UDP source port, and recipients MUST be able to process IKE packets whose source port is different from 500. The NAT does not have to change the source port if:
NATは、IKE UDPソースポートを変更することができ、受信者は、その送信元ポート500からNATがあれば送信元ポートを変更する必要がない異なるIKEパケットを処理できなければなりません。
o only one IPsec host is behind the NAT, or
O一つだけのIPsecホストがNATの背後にある、または
o for the first IPsec host, the NAT can keep the port 500, and the NAT will only change the port number for later connections.
O最初のIPsecホストのために、NATは、ポート500を維持することができ、およびNATは、後で接続用のポート番号を変更します。
Recipients MUST reply back to the source address from the packet (see [RFC3715], section 2.1, case d). This means that when the original responder is doing rekeying or sending notifications to the original initiator, it MUST send the packets using the same set of port and IP numbers used when the IKE SA was last used.
受信者は、パケットから送信元アドレス（[RFC3715]を参照して、セクション2.1、ケースD）に返信しなければなりません。これは、元のレスポンダが鍵の変更を行うか、元のイニシエータに通知を送信しているとき、それはIKE SAが最後に使用されたときに使用するポートとIP番号の同じセットを使用してパケットを送信しなければならないことを意味します。
For example, when the initiator sends a packet with source and destination port 500, the NAT may change it to a packet with source port 12312 and destination port 500. The responder must be able to process the packet whose source port is 12312. It must reply back with a packet whose source port is 500 and destination port is 12312. The NAT will then translate this packet to source port 500 and destination port 500.
イニシエータは、送信元および宛先ポート500でパケットを送信するとき、例えば、NATは、レスポンダは、ソースポートこれは必要12312.あるパケットを処理することができなければならない送信元ポート12312と宛先ポート500とのパケットに変更することができますそのソースはポート500で、宛先ポートです12312. NATは、ポート500、宛先ポート500を調達するために、このパケットを翻訳しますパケットを返信。
The NAT-Traversal capability of the remote host is determined by an exchange of vendor ID payloads. In the first two messages of Phase 1, the vendor id payload for this specification MUST be sent if supported (and it MUST be received by both sides) for the NAT-Traversal probe to continue. The content of the payload is the MD5 hash of
リモート・ホストのNATトラバーサル機能は、ベンダーIDペイロードの交換によって決定されます。サポートされている場合、フェーズ1の最初の二つのメッセージでは、本明細書のベンダーIDペイロードを送信する必要があります（それは両側によって受信されなければならない）継続するNATトラバーサルプローブのため。ペイロードの内容は、のMD5ハッシュです
RFC 3947
RFC 3947
The exact content in hex for the payload is
ペイロードの進で正確な内容であります
4a131c81070358455c5728f20e95452f
4a131c81070358455c5728f20e95452f
The NAT-D payload not only detects the presence of NAT between the two IKE peers, but also detects where the NAT is. The location of the NAT device is important, as the keepalives have to initiate from the peer "behind" the NAT.
NAT-Dペイロードは、二つのIKEピア間のNATの存在を検出するだけでなく、NATである場合を検出するだけでなく。キープアライブは、NATの「後ろ」ピアから開始しなければならないようにNATデバイスの位置は、重要です。
To detect NAT between the two hosts, we have to detect whether the IP address or the port changes along the path. This is done by sending the hashes of the IP addresses and ports of both IKE peers from each end to the other. If both ends calculate those hashes and get same result, they know there is no NAT between. If the hashes do not match, somebody has translated the address or port. This means that we have to do NAT-Traversal to get IPsec packets through.
2つのホスト間でNATを検出するために、我々は、IPアドレスまたはパスに沿ってポートの変更かどうかを検出する必要があります。これは、他の各端部から両方のIKEピアのIPアドレスとポートのハッシュを送信することによって行われます。両端がそれらのハッシュを計算し、同じ結果を取得する場合、彼らは間にNATがありません知っています。ハッシュが一致しない場合、誰かがアドレスまたはポートを翻訳しています。これは、私たちがIPsecパケットを介して取得するためにNATトラバーサルをしなければならないことを意味します。
If the sender of the packet does not know his own IP address (in case of multiple interfaces, and the implementation does not know which IP address is used to route the packet out), the sender can include multiple local hashes to the packet (as separate NAT-D payloads). In this case, NAT is detected if and only if none of the hashes match.
パケットの送信元が自分のIPアドレスを知っていません（複数のインタフェースの場合は、実装が出てルートにパケットを使用しているIPアドレスを知らない）場合は、送信者は（などのパケットに複数のローカルハッシュを含むことができ、別NAT-Dペイロード）。そしてハッシュのどれも一致しない場合にのみこの場合、NATが検出されます。
The hashes are sent as a series of NAT-D (NAT discovery) payloads. Each payload contains one hash, so in case of multiple hashes, multiple NAT-D payloads are sent. In the normal case there are only two NAT-D payloads.
ハッシュは、NAT-D（NATディスカバリ）ペイロードの系列として送信されます。複数のハッシュの場合には、複数のNAT-Dペイロードが送信されるように、各ペイロードは、1つのハッシュを含んでいます。通常の場合に2つだけのNAT-Dペイロードがあります。
The NAT-D payloads are included in the third and fourth packets of Main Mode, and in the second and third packets in the Aggressive Mode.
NAT-Dペイロードは、メインモードの第三及び第四のパケットで、かつアグレッシブモードで第二および第三のパケットに含まれています。
The format of the NAT-D packet is
NAT-Dパケットのフォーマットは
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload length |
+---------------+---------------+---------------+---------------+
~ HASH of the address and port ~
+---------------+---------------+---------------+---------------+
The payload type for the NAT discovery payload is 20.
NAT発見のペイロードのためのペイロードタイプは20です。
The HASH is calculated as follows:
以下のようにハッシュが計算されます。
HASH = HASH(CKY-I | CKY-R | IP | Port)
HASH = HASH（CKY-I | CKY-R | IP |ポート）
This uses the negotiated HASH algorithm. All data inside the HASH is in the network byte-order. The IP is 4 octets for an IPv4 address and 16 octets for an IPv6 address. The port number is encoded as a 2 octet number in network byte-order. The first NAT-D payload contains the remote end's IP address and port (i.e., the destination address of the UDP packet). The remaining NAT-D payloads contain possible local-end IP addresses and ports (i.e., all possible source addresses of the UDP packet).
これは、交渉されたハッシュアルゴリズムを使用しています。 HASH内のすべてのデータはネットワークバイトオーダーです。 IPは、IPv4アドレスとIPv6アドレスの16オクテット4つのオクテットです。ポート番号は、ネットワークバイト順に2オクテットの数として符号化されます。最初のNAT-Dペイロードは、リモート側のIPアドレスおよびポートを含み（すなわち、UDPパケットの宛先アドレス）。残りのNAT-Dペイロードは、可能なローカルエンドのIPアドレスとポートを含む（すなわち、UDPパケットのすべての可能な送信元アドレス）。
If there is no NAT between the peers, the first NAT-D payload received should match one of the local NAT-D payloads (i.e., the local NAT-D payloads this host is sending out), and one of the other NAT-D payloads must match the remote end's IP address and port. If the first check fails (i.e., first NAT-D payload does not match any of the local IP addresses and ports), it means that there is dynamic NAT between the peers, and this end should start sending keepalives as defined in the [RFC3948] (this end is behind the NAT).
ピア間のNATが存在しない場合、最初のNAT-Dペイロードは、受信されたローカルNAT-Dペイロードの一方（このホストが送出され、すなわち、ローカルNAT-Dペイロード）と一致し、他のNAT-Dの一つべきペイロードは、リモート側のIPアドレスとポートと一致する必要があります。最初のチェックが失敗した場合（すなわち、最初のNAT-Dペイロードは、ローカルIPアドレスおよびポートのいずれとも一致しない）は、ピア間の動的NATが存在することを意味し、[RFC3948で定義されるように、この端部は、キープアライブの送信を開始すべきです]（この最後はNATの背後にあります）。
The CKY-I and CKY-R are the initiator and responder cookies. They are added to the hash to make precomputation attacks for the IP address and port impossible.
CKY-IとCKY-Rは、イニシエータとレスポンダクッキーです。彼らは、IPアドレスとポート不可能のための事前計算攻撃を行うために、ハッシュに追加されます。
The following example is of a Phase 1 exchange using NAT-Traversal in Main Mode (authentication with signatures):
次の例では、メインモードでNATトラバーサル（署名付きの認証）を使用して、フェーズ1交換です。
Initiator Responder
------------ ------------
HDR, SA, VID -->
<-- HDR, SA, VID
HDR, KE, Ni, NAT-D, NAT-D -->
<-- HDR, KE, Nr, NAT-D, NAT-D
HDR*#, IDii, [CERT, ] SIG_I -->
<-- HDR*#, IDir, [CERT, ], SIG_R
The following example is of Phase 1 exchange using NAT-Traversal in Aggressive Mode (authentication with signatures):
次の例では、アグレッシブモードでNATトラバーサルを使用して、フェーズ1つの交換（署名付きの認証）です。
Initiator Responder
------------ ------------
HDR, SA, KE, Ni, IDii, VID -->
<-- HDR, SA, KE, Nr, IDir,
[CERT, ], VID, NAT-D,
NAT-D, SIG_R
HDR*#, [CERT, ], NAT-D, NAT-D,
SIG_I -->
The # sign indicates that those packets are sent to the changed port if NAT is detected.
＃記号は、NATが検出された場合、それらのパケットが変更されたポートに送信されていることを示しています。
IPsec-aware NATs can cause problems (See [RFC3715], section 2.3). Some NATs will not change IKE source port 500 even if there are multiple clients behind the NAT (See [RFC3715], section 2.3, case n). They can also use IKE cookies to demultiplex traffic instead of using the source port (See [RFC3715], section 2.3, case m). Both of these are problematic for generic NAT transparency, as it is difficult for IKE to discover the capabilities of the NAT. The best approach is simply to move the IKE traffic off port 500 as soon as possible to avoid any IPsec-aware NAT special casing.
IPSecに対応NATは（[RFC3715]、セクション2.3を参照）問題を引き起こす可能性があります。いくつかのNATはNATの背後にある複数のクライアントが存在する場合でも、IKEソースポート500（[RFC3715]を参照してください、セクション2.3、ケースn）を変更しません。彼らはまた、代わりの送信元ポートを使用するトラフィックを分離するためにIKEクッキーを使用することができる（セクション2.3、ケースM、[RFC3715]を参照）。 IKEは、NATの機能を発見することは困難であるとして、これらの両方は、一般的なNAT透明性のために問題があります。最善のアプローチは、任意のIPsecの対応のNATの特殊なケースを避けるために、できるだけ早くポート500をオフIKEトラフィックを移動するだけです。
Take the common case of the initiator behind the NAT. The initiator must quickly change to port 4500 once the NAT has been detected to minimize the window of IPsec-aware NAT problems.
NATの背後にある開始剤の一般的なケースを取ります。 NATがIPSec対応のNAT問題のウィンドウを最小化するために検出された後、イニシエータはすぐにポート4500に変更する必要があります。
In Main Mode, the initiator MUST change ports when sending the ID payload if there is NAT between the hosts. The initiator MUST set both UDP source and destination ports to 4500. All subsequent packets sent to this peer (including informational notifications) MUST be sent on port 4500. In addition, the IKE data MUST be prepended with a non-ESP marker allowing for demultiplexing of traffic, as defined in [RFC3948].
NATは、ホスト間である場合にIDペイロードを送信するときにメインモードでは、イニシエータは、ポートを変更する必要があります。開始剤は（情報通知を含む）このピアに送信された後続のすべてのパケットはまた、ポート4500上で送信されなければならない4500にUDPの送信元ポートと宛先ポートの両方を設定しなければならない、IKEデータは、多重分離を可能にする非ESPマーカーで付加されなければなりませんトラフィックの、[RFC3948]で定義されます。
Thus, the IKE packet now looks like this:
このように、IKEパケットは次のようになります。
IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT, ] SIG_I
IP UDP（4500,4500）<非ESPマーカー> HDR *、IDii、[CERT、] SIG_I
This assumes authentication using signatures. The 4 bytes of non-ESP marker are defined in the [RFC3948].
これは、署名を使用して認証を前提としています。非ESPマーカーの4つのバイトは、[RFC3948]で定義されています。
When the responder gets this packet, the usual decryption and processing of the various payloads is performed. If these are successful, the responder MUST update local state so that all subsequent packets (including informational notifications) to the peer use the new port, and possibly the new IP address obtained from the incoming valid packet. The port will generally be different, as the NAT will map UDP(500,500) to UDP(X,500), and UDP(4500,4500) to UDP(Y,4500). The IP address will seldom be different from the pre-changed IP address. The responder MUST respond with all subsequent IKE packets to this peer by using UDP(4500,Y).
応答者がこのパケットを取得すると、様々なペイロードの通常の復号化処理が行われます。これらが成功した場合、ピアへ（情報の通知を含む）すべての後続のパケットが着信有効なパケットから取得した新しいポート、おそらく新しいIPアドレスを使用するように、レスポンダはローカル状態を更新する必要があります。 NATがUDP（Y、4500）にUDP（X、500）、及びUDP（4500,4500）とUDP（500500）にマッピングされ、ポートは、一般に、異なるであろう。 IPアドレスはめったに前変更されたIPアドレスと異なることがありません。レスポンダは、UDP（4500、Y）を使用して、このピアへのすべての後続のIKEパケットで応答しなければなりません。
Similarly, if the responder has to rekey the Phase 1 SA, then the rekey negotiation MUST be started by using UDP(4500,Y). Any implementation that supports NAT traversal MUST support negotiations that begin on port 4500. If a negotiation starts on port 4500, then it doesn't need to change anywhere else in the exchange.
応答者がフェーズ1 SAキーを再生成する必要がある場合同様に、その後、再入力交渉はUDP（4500、Y）を使用して開始する必要があります。ネゴシエーションがポート4500で起動した場合は、ポート4500で始まる交渉をサポートしなければならないNATトラバーサルをサポートする任意の実装が、それは為替のどこにも変更する必要はありません。
Once port change has occurred, if a packet is received on port 500, that packet is old. If the packet is an informational packet, it MAY be processed if local policy allows this. If the packet is a Main Mode or an Aggressive Mode packet (with the same cookies as previous packets), it SHOULD be discarded. If the packet is a new Main Mode or Aggressive exchange, then it is processed normally (the other end might have rebooted, and this is starting new exchange).
ポートの変更が発生すると、パケットがポート500上で受信された場合、そのパケットは古いです。パケットが情報パケットである場合は、ローカルポリシーがこれを許可している場合、それが処理されてもよいです。パケットが（前回のパケットと同じクッキー付き）、メインモードまたはアグレッシブモードのパケットである場合、それは破棄されるべきです。パケットは、新しいメインモードまたはアグレッシブな交換がある場合、（もう一方の端を再起動している場合がありますが、これは新しい交換を開始している）正常に処理されます。
Here is an example of a Phase 1 exchange using NAT-Traversal in Main Mode (authentication with signatures) with changing port:
ここでポートを変更してメインモード（署名と認証）でNATトラバーサルを使用して、フェーズ1交換の一例です。
Initiator Responder
------------ ------------
UDP(500,500) HDR, SA, VID -->
<-- UDP(500,X) HDR, SA, VID
UDP(500,500) HDR, KE, Ni,
NAT-D, NAT-D -->
<-- UDP(500,X) HDR, KE, Nr,
NAT-D, NAT-D
UDP(4500,4500) HDR*#, IDii,
[CERT, ]SIG_I -->
<-- UDP(4500,Y) HDR*#, IDir,
[ CERT, ], SIG_R
The procedure for Aggressive Mode is very similar. After the NAT has been detected, the initiator sends IP UDP(4500,4500) <4 bytes of non-ESP marker> HDR*, [CERT, ], NAT-D, NAT-D, and SIG_I. The responder does similar processing to the above, and if successful, MUST update it's internal IKE ports. The responder MUST respond with all subsequent IKE packets to this peer by using UDP(4500,Y).
アグレッシブモードのための手順は非常に似ています。 NATが検出された後、イニシエータはIP UDP（4500,4500）のHDR * <非ESPマーカーの4つのバイト>、[CERT、]、NAT-D、NAT-D、およびSIG_Iを送信します。応答者は、上記と同様の処理を行い、成功した場合、それは内部のIKEポートのアップデートしなければなりません。レスポンダは、UDP（4500、Y）を使用して、このピアへのすべての後続のIKEパケットで応答しなければなりません。
Initiator Responder
------------ ------------
UDP(500,500) HDR, SA, KE,
Ni, IDii, VID -->
<-- UDP(500,X) HDR, SA, KE,
Nr, IDir, [CERT, ],
VID, NAT-D, NAT-D,
SIG_R
UDP(4500,4500) HDR*#, [CERT, ],
NAT-D, NAT-D,
SIG_I -->
<-- UDP(4500, Y) HDR*#, ...
If the support of the NAT-Traversal is enabled, the port in the ID payload in Main Mode/Aggressive Mode MUST be set to 0.
NATトラバーサルのサポートが有効になっている場合、メインモード/アグレッシブモードでのIDペイロードのポートが0に設定しなければなりません。
The most common case for the responder behind the NAT is if the NAT is simply doing 1:1 address translation. In this case, the initiator still changes both ports to 4500. The responder uses an algorithm identical to that above, although in this case Y will equal 4500, as no port translation is happening.
1アドレス変換：NATは、単に1をやっている場合、NATの背後にある応答者のための最も一般的なケースです。この場合、イニシエータはまだポート変換が起こっていないように、この場合、Yは4500に等しくなるが、レスポンダは、上記と同一のアルゴリズムを使用して4500に両方のポートを変更します。
A different port change case involves out-of-band discovery of the ports to use. Those discovery methods are out of the scope of this document. For instance, if the responder is behind a port translating NAT, and the initiator needs to contact it first, then the initiator will have to determine which ports to use, usually by contacting some other server. Once the initiator knows which ports to use to traverse the NAT, generally something like UDP(Z,4500), it initiates using these ports. This is similar to the responder rekey case above in that the ports to use are already known up front, and no additional change has to take place. Also, the first keepalive timer starts after the change to the new port, and no keepalives are sent to the port 500.
異なるポート変更場合は、使用するポートの帯域外の発見を含みます。これらの発見方法は、この文書の範囲外です。応答者がNATを変換ポートの背後にある、および開始剤を最初に連絡する必要がある場合、例えば、その後、開始剤は、通常、いくつかの他のサーバとを接触させることによって、使用するポートを決定しなければなりません。イニシエータは、一般的に、NATを通過するために使用するポートUDP（Z、4500）のようなものを知っていると、それはこれらのポートを使用して開始します。これは、ポートがすでに前もって知られて使用することで上記のレスポンダの再入力の場合と同様であり、追加の変更が行われなければなりません。また、最初のキープアライブタイマーは、新しいポートに変更した後に開始し、キープアライブは、ポート500に送信されません。
After Phase 1, both ends know whether there is a NAT present between them. The final decision of using NAT-Traversal is left to Quick Mode. The use of NAT-Traversal is negotiated inside the SA payloads of Quick Mode. In Quick Mode, both ends can also send the original addresses of the IPsec packets (in case of the transport mode) to the other end so that each can fix the TCP/IP checksum field after the NAT transformation.
フェーズ1の後、両端には、それらの間のNAT存在があるかどうかを知っています。 NATトラバーサルを使用しての最終決定はクイックモードに委ねられています。 NATトラバーサルの使用は、クイックモードのSAペイロードの内側に交渉されています。各NAT変換後のTCP / IPチェックサムフィールドを修正することができるように、クイックモードでは、両方の端部は、他の端部に（トランスポート・モードの場合）IPsecパケットの元のアドレスを送信することができます。
The negotiation of the NAT-Traversal happens by adding two new encapsulation modes. These encapsulation modes are
NATトラバーサルの交渉は、2つの新しいカプセル化モードを追加することによって起こります。これらのカプセル化モードは、
UDP-Encapsulated-Tunnel 3 UDP-Encapsulated-Transport 4
UDPカプセル化 - トンネル3 UDPカプセル化、輸送4
It is not normally useful to propose both normal tunnel or transport mode and UDP-Encapsulated modes. UDP encapsulation is required to fix the inability to handle non-UDP/TCP traffic by NATs (see [RFC3715], section 2.2, case i).
通常、トンネル又はトランスポートモードとUDPカプセル化モードの両方を提案することで正常に有用ではありません。 UDPカプセル化は、（[RFC3715]、セクション2.2、ケースIを参照）のNATによる非UDP / TCPトラフィックを処理できないことを修正するために必要とされます。
If there is a NAT box between hosts, normal tunnel or transport encapsulations may not work. In this case, UDP-Encapsulation SHOULD be used.
ホスト間のNATボックスがある場合、通常のトンネル又はトランスポートカプセル化は機能しないことがあります。この場合、UDP-カプセル化を使用する必要があります。
If there is no NAT box between, there is no point in wasting bandwidth by adding UDP encapsulation of packets. Thus, UDP-Encapsulation SHOULD NOT be used.
間にはNATボックスがない場合、パケットのUDPカプセル化を追加することにより、帯域幅を無駄にはポイントがありません。このように、UDP-カプセル化を使用してはなりません。
Also, the initiator SHOULD NOT include both normal tunnel or transport mode and UDP-Encapsulated-Tunnel or UDP-Encapsulated-Transport in its proposals.
また、イニシエータはその提案に通常のトンネルまたはトランスポートモードとUDPカプセル化、トンネルまたはUDPカプセル化、輸送の両方を含めるべきではありません。
To perform incremental TCP checksum updates, both peers may need to know the original IP addresses used by their peers when those peers constructed the packet (see [RFC3715], section 2.1, case b). For the initiator, the original Initiator address is defined to be the Initiator's IP address. The original Responder address is defined to be the perceived peer's IP address. For the responder, the original Initiator address is defined to be the perceived peer's address. The original Responder address is defined to be the Responder's IP address.
増分TCPチェックサムの更新を実行するために、両方のピアがそれらのピアがパケットを構築したときに、そのピアによって使用される元のIPアドレスを知っている必要があるかもしれません（セクション2.1、ケースB、[RFC3715]を参照）。イニシエータのために、オリジナルのイニシエータアドレスは、イニシエータのIPアドレスになるように定義されます。オリジナルのレスポンダアドレスが知覚ピアのIPアドレスになるように定義されます。応答者のために、オリジナルのイニシエータアドレスが知覚ピアのアドレスになるように定義されます。オリジナルのレスポンダアドレスはレスポンダのIPアドレスになるように定義されます。
The original addresses are sent by using NAT-OA (NAT Original Address) payloads.
元のアドレスは、NAT-OA（NATオリジナルアドレス）ペイロードを使用して送信されます。
The Initiator NAT-OA payload is first. The Responder NAT-OA payload is second.
イニシエータNAT-OAペイロードが最初です。レスポンダNAT-OAペイロードは秒です。
Example 1:
例1：
Initiator <---------> NAT <---------> Responder
^ ^ ^
Iaddr NatPub Raddr
The initiator is behind a NAT talking to the publicly available responder. Initiator and Responder have the IP addresses Iaddr and Raddr. NAT has public IP address NatPub.
イニシエータは、公に利用可能な応答者に話をNATの背後にあります。イニシエータとレスポンダは、IPがIADDRとRADDRを扱っています。 NATは、パブリックIPアドレスNatPubを持っています。
Initiator:
イニシエータ：
NAT-OAi = Iaddr
NAT-OAr = Raddr
Responder: NAT-OAi = NATPub NAT-OAr = Raddr
レスポンダ：NAT OAI = NATPub NAT-OArで= RADDR
Example 2:
例2：
Initiator <------> NAT1 <---------> NAT2 <-------> Responder
^ ^ ^ ^
Iaddr Nat1Pub Nat2Pub Raddr
Here, NAT2 "publishes" Nat2Pub for Responder and forwards all traffic to that address to Responder.
ここでは、NAT2はレスポンダのためNat2Pubと転送レスポンダにそのアドレスへのすべてのトラフィックを「公開します」。
Initiator: NAT-OAi = Iaddr NAT-OAr = Nat2Pub
イニシエータ：NAT OAI = IADDR NAT-OArで= Nat2Pub
Responder: NAT-OAi = Nat1Pub NAT-OAr = Raddr
レスポンダ：NAT OAI = Nat1Pub NAT-OArで= RADDR
In the case of transport mode, both ends MUST send both original Initiator and Responder addresses to the other end. For tunnel mode, both ends SHOULD NOT send original addresses to the other end.
トランスポートモードの場合には、両端部が他端に元のイニシエータとレスポンダのアドレスの両方を送信しなければなりません。トンネルモードでは、両方の端部が他端に元のアドレスを送るべきではありません。
The NAT-OA payloads are sent inside the first and second packets of Quick Mode. The initiator MUST send the payloads if it proposes any UDP-Encapsulated-Transport mode, and the responder MUST send the payload only if it selected UDP-Encapsulated-Transport mode. It is possible that the initiator sends the NAT-OA payload but proposes both UDP-Encapsulated transport and tunnel mode. Then the responder selects the UDP-Encapsulated tunnel mode and does not send the NAT-OA payload back.
NAT-OAペイロードは、クイックモードの第一及び第二のパケットの内部に送られます。それは任意のUDPカプセル化 - トランスポートモードを提案している場合、イニシエータは、ペイロードを送らなければなりませんし、応答者は、それがUDPカプセル化 - トランスポートモードを選択した場合のみ、ペイロードを送らなければなりません。イニシエータがNAT-OAペイロードを送信しますが、UDPカプセル化トランスポートおよびトンネルモードの両方を提案している可能性があります。そして、レスポンダはUDPカプセル化トンネルモードを選択し、バックNAT-OAペイロードを送信しません。
The format of the NAT-OA packet is
NAT-OAパケットのフォーマットは、
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload length |
+---------------+---------------+---------------+---------------+
| ID Type | RESERVED | RESERVED |
+---------------+---------------+---------------+---------------+
| IPv4 (4 octets) or IPv6 address (16 octets) |
+---------------+---------------+---------------+---------------+
The payload type for the NAT original address payload is 21.
NAT元のアドレスペイロードのためのペイロードタイプは21です。
The ID type is defined in the [RFC2407]. Only ID_IPV4_ADDR and ID_IPV6_ADDR types are allowed. The two reserved fields after the ID Type must be zero.
IDタイプは[RFC2407]で定義されています。 ID_IPV4_ADDRとID_IPV6_ADDR種類のみが許可されています。 IDタイプの後に2つの予約フィールドがゼロでなければなりません。
The following example is of Quick Mode using NAT-OA payloads:
次の例では、NAT-OAペイロードを使用してクイックモードは次のとおりです。
Initiator Responder
------------ ------------
HDR*, HASH(1), SA, Ni, [, KE]
[, IDci, IDcr ]
[, NAT-OAi, NAT-OAr] -->
<-- HDR*, HASH(2), SA, Nr, [, KE]
[, IDci, IDcr ]
[, NAT-OAi, NAT-OAr]
HDR*, HASH(3) -->
The source IP and port address of the INITIAL-CONTACT notification for the host behind NAT are not meaningful (as NAT can change them), so the IP and port numbers MUST NOT be used to determine which IKE/IPsec SAs to remove (see [RFC3715], section 2.1, case c). The ID payload sent from the other end SHOULD be used instead; i.e., when an INITIAL-CONTACT notification is received from the other end, the receiving end SHOULD remove all the SAs associated with the same ID payload.
NATの背後にあるホスト用のINITIAL-CONTACT通知の送信元IPとポートアドレスは（NATがそれらを変更することができたように）意味がありませんので、IPとポート番号はIKE / IPsecのSAを削除するかを決定するために使用してはいけません（参照[ RFC3715]、セクション2.1、ケースC）。他端から送信されたIDペイロードが代わりに使用されるべきです。 INITIAL-CONTACT通知を他端から受信した場合、すなわち、受信側は、同一のIDペイロードに関連付けられたすべてのSAを削除する必要があります。
There are cases where NAT box decides to remove mappings that are still alive (for example, when the keepalive interval is too long, or when the NAT box is rebooted). To recover from this, ends that are NOT behind NAT SHOULD use the last valid UDP encapsulated IKE or IPsec packet from the other end to determine which IP and port addresses should be used. The host behind dynamic NAT MUST NOT do this, as otherwise it opens a DoS attack possibility because the IP address or port of the other host will not change (it is not behind NAT).
NATボックスがまだ生きているマッピングを削除することを決定した例があります（たとえば、キープアライブ間隔が長すぎる場合、またはNATボックスが再起動されたとき）。この状態から回復するには、NATの背後にされていない末端は、最後の有効なUDPを使用すべきであるIPとポートアドレスが使用されるべきかを決定するために、もう一方の端からIKEまたはIPsecパケットをカプセル化。それ以外の場合は、他のホストのIPアドレスまたはポートが（それがNATの背後ではありません）変更されませんので、DoS攻撃の可能性を開くと、ダイナミックNATの背後にあるホストは、これを実行してはなりません。
Keepalives cannot be used for these purposes, as they are not authenticated, but any IKE authenticated IKE packet or ESP packet can be used to detect whether the IP address or the port has changed.
彼らが認証されていないようキープアライブは、これらの目的に使用することはできませんが、任意のIKEは、IKEパケットを認証済みまたはESPパケットがIPアドレスやポートが変更されているかどうかを検出するために使用することができます。
Whenever changes to some fundamental parts of a security protocol are proposed, the examination of security implications cannot be skipped. Therefore, here are some observations about the effects, and about whether or not these effects matter.
セキュリティプロトコルのいくつかの基本的な部分への変更が提案されているときはいつでも、セキュリティへの影響の検査はスキップすることはできません。したがって、ここでの影響に関するいくつかの所見があり、これらの効果は問題かどうかについて。
o IKE probes reveal NAT-Traversal support to anyone watching the traffic. Disclosing that NAT-Traversal is supported does not introduce new vulnerabilities.
O IKEプローブは、トラフィックを見て誰にもNATトラバーサルのサポートを明らかにしました。 NATトラバーサルは、新しい脆弱性を導入しないサポートされていることを公表。
o The value of authentication mechanisms based on IP addresses disappears once NATs are in the picture. That is not necessarily a bad thing (for any real security, authentication measures other than IP addresses should be used). This means that authentication with pre-shared keys cannot be used in Main Mode without using group-shared keys for everybody behind the NAT box. Using group shared keys is a huge risk because it allows anyone in the group to authenticate to any other party and claim to be anybody in the group; e.g., a normal user could impersonate a vpn-gateway and act as a man in the middle, and read/modify all traffic to/from others in the group. Use of group-shared keys is NOT RECOMMENDED.
NATのピクチャにある後O IPアドレスに基づいて、認証メカニズムの値が消えます。それは必ずしも悪いことではありません（任意の実際のセキュリティのため、IPアドレス以外の認証対策を使用する必要があります）。これは、事前共有キーを使用して認証がNAT箱の後ろに皆のためのグループ共有鍵を使用せずに、メインモードでは使用できないことを意味します。それは、グループ内の誰もが他の当事者に認証し、グループ内で誰であることを主張することができますので、グループ共有鍵を使用すると、巨大なリスクです。例えば、通常のユーザは中間者としてVPNゲートウェイと行為を偽装し、リード/グループ内の他の人への/からのすべてのトラフィックを修正することができます。グループ共有キーの使用は推奨されません。
o As the internal address space is only 32 bits and is usually very sparse, it might be possible for the attacker to find out the internal address used behind the NAT box by trying all possible IP-addresses to find the matching hash. The port numbers are normally fixed to 500, and the cookies can be extracted from the packet. This limits the hash calculations to 2^32. If an educated guess of the private address space is made, then the number of hash calculations needed to find out the internal IP address goes down to 2^24 + 2 * (2^16).
内部アドレス空間は、32ビットであり、通常は非常にまばらであるOなどの攻撃者が一致するハッシュを見つけるために、すべての可能なIP-アドレスを試みることにより、NATボックスの後ろに使用される内部アドレスを見つけるためにのために、それは可能かもしれません。ポート番号は、通常、500に固定されており、クッキーは、パケットから抽出することができます。これは、2 ^ 32にハッシュ計算を制限します。プライベートアドレス空間の推測がなされている場合は、内部IPアドレスを見つけるために必要なハッシュ計算の数は2 ^ 24 + 2 *（2 ^ 16）にダウンしました。
o Neither NAT-D payloads nor Vendor ID payloads are authenticated in Main Mode nor in Aggressive Mode. This means that attacker can remove those payloads, modify them, or add them. By removing or adding them, the attacker can cause Denial of Service attacks. By modifying the NAT-D packets, the attacker can cause both ends to use UDP-Encapsulated modes instead of directly using tunnel or transport mode, thus wasting some bandwidth.
OどちらもNAT-DペイロードやベンダーIDペイロードは、メインモードでもアグレッシブモードで認証されます。これにより、攻撃者は、これらのペイロードを削除し、それらを変更、またはそれらを追加できることを意味します。削除またはそれらを追加することにより、攻撃者はサービス拒否攻撃を引き起こす可能性があります。 NAT-Dパケットを変更することによって、攻撃者は、両端ではなく、直接、したがって、いくつかの帯域幅を浪費し、トンネル又はトランスポートモードを使用してのUDPカプセル化モードを使用させることができます。
o Sending the original source address in the Quick Mode reveals the internal IP address behind the NAT to the other end. In this case we have already authenticated the other end, and sending the original source address is only needed in transport mode.
クイックモードでの元のソースアドレスを送信oをもう一方の端にNATの背後にある内部IPアドレスを明らかにします。この場合、我々はすでにもう一方の端を、認証、およびトランスポートモードのみで必要とされる元のソースアドレスを送信してきました。
o Updating the IKE SA/ESP UDP encapsulation IP addresses and ports for each valid authenticated packet can cause DoS if an attacker can listen to all traffic in the network, change the order of the packets, and inject new packets before the packet he has already seen. In other words, the attacker can take an authenticated packet from the host behind NAT, change the packet UDP source or destination ports or IP addresses and send it out to the other end before the real packet reaches it. The host not behind the NAT will update its IP address and port mapping and send further traffic to the wrong host or port. This situation is fixed immediately when the attacker stops modifying the packets, as the first real packet will fix the situation. Implementations SHOULD AUDIT the event every time the mapping is changed, as it should not happen that often.
攻撃者は、ネットワーク内のすべてのトラフィックを聞くパケットの順序を変更し、彼がすでに持っているパケットの前に、新たなパケットを注入することができた場合にDoS攻撃を引き起こす可能性がありますそれぞれの有効な認証されたパケットのためのIKE SA / ESP UDPカプセル化IPアドレスとポートの更新O見て。つまり、攻撃者がNATの背後にあるホストから認証されたパケットを取ることができ、パケットのUDPの送信元または宛先ポートまたはIPアドレスを変更し、実際のパケットが到達する前にもう一方の端にそれを送り出します。ないNATの背後にあるホストは、そのIPアドレスとポートマッピングを更新し、間違ったホストまたはポートにさらにトラフィックを送信します。攻撃者は、状況を修正する最初の本当のパケットとして、パケットを変更停止したときに、この状況はすぐに固定されています。それは頻繁に起こるべきではないとして実装は、イベントにマッピングが変更されるたびを監査すべきです。
This document contains two new "magic numbers" allocated from the existing IANA registry for IPsec and renames existing registered port 4500. This document also defines 2 new payload types for IKE.
この文書では、IPsecのための既存のIANAレジストリから割り当てられた二つの新しい「マジックナンバー」が含まれており、この文書はまた、IKEのために2つの新しいペイロードタイプを定義して登録されているポート4500を既存の名前を変更します。
The following are new items that have been added in the "Internet Security Association and Key Management Protocol (ISAKMP) Identifiers" Encapsulation Mode registry:
以下の「インターネットSecurity AssociationとKey Managementプロトコル（ISAKMP）識別子」カプセル化モードのレジストリに追加された新しい項目は、次のとおりです。
Name Value Reference
---- ----- ---------
UDP-Encapsulated-Tunnel 3 [RFC3947]
UDP-Encapsulated-Transport 4 [RFC3947]
Change in the registered port registry:
登録されているポートレジストリに変更します。
Keyword Decimal Description Reference
------- ------- ----------- ---------
ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC3947]
ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC3947]
New IKE payload numbers need to be added to the Next Payload Types registry:
新しいIKEペイロード番号は、次のペイロードタイプレジストリに追加する必要があります。
NAT-D 20 NAT Discovery Payload
NAT-OA 21 NAT Original Address Payload
The UNSAF [RFC3424] questions are addressed by the IPsec-NAT compatibility requirements document [RFC3715].
UNSAF [RFC3424]の質問は、IPsecでNAT互換性要件ドキュメント[RFC3715]によって対処されています。
Thanks to Markus Stenberg, Larry DiBurro, and William Dixon, who contributed actively to this document.
このドキュメントに積極的に貢献したマルクスステンバーグ、ラリーDiBurro、ウィリアムディクソン、に感謝します。
Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald, who contributed to the document used as the base for this document.
このドキュメントのベースとして使用された文書に貢献しタトゥYlonenと、サンテリPaavolainen、およびJoern Sierwald、に感謝します。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
"ISAKMPのための解釈のインターネットIPセキュリティー領域" [RFC2407]パイパー、D.、RFC 2407、1998年11月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "IPsecのパケットのUDPカプセル化"、RFC 3948、2005年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B.とW.ディクソン、 "IPsecでネットワークアドレス変換（NAT）の互換性の要件"、RFC 3715、2004年3月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
、RFC 3424、2002年11月、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）" [RFC3424] Daigle氏、L.とIAB、。
Authors' Addresses
著者のアドレス
Tero Kivinen SafeNet, Inc. Fredrikinkatu 47 FIN-00100 HELSINKI Finland
TERO Kivinen SafeNetの株式会社Fredrikinkatu 47 FIN-00100 HELSINKIフィンランド
EMail: kivinen@safenet-inc.com
メールアドレス：kivinen@safenet-inc.com
Ari Huttunen F-Secure Corporation Tammasaarenkatu 7, FIN-00181 HELSINKI Finland
アリHuttunen F-Secureの株式会社Tammasaarenkatu 7、FIN-00181 HELSINKIフィンランド
EMail: Ari.Huttunen@F-Secure.com
メールアドレス：Ari.Huttunen@F-Secure.com
Brian Swander Microsoft One Microsoft Way Redmond, WA 98052 USA
ブライアンSwanderマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052 USA
EMail: briansw@microsoft.com
メールアドレス：briansw@microsoft.com
Victor Volpe Cisco Systems 124 Grove Street Suite 205 Franklin, MA 02038 USA
ビクターボルペシスコシステムズ124グローブストリートスイート205フランクリン、MA 02038 USA
EMail: vvolpe@cisco.com
メールアドレス：vvolpe@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。