RFC3948 日本語訳

3948 UDP Encapsulation of IPsec ESP Packets. A. Huttunen, B. Swander,V. Volpe, L. DiBurro, M. Stenberg. January 2005. (Format: TXT=30366 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                        A. Huttunen
Request for Comments: 3948                          F-Secure Corporation
Category: Standards Track                                     B. Swander
                                                               Microsoft
                                                                V. Volpe
                                                           Cisco Systems
                                                              L. DiBurro
                                                         Nortel Networks
                                                             M. Stenberg
                                                            January 2005

Huttunenがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3948年のF安全な社のカテゴリ: 規格はM.Stenberg2005年1月にB.SwanderマイクロソフトV.ボルペシスコシステムズL.DiBurroノーテルネットワークを追跡します。

                 UDP Encapsulation of IPsec ESP Packets

IPsec超能力パケットのUDPカプセル化

Status of this Memo

この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 protocol specification defines methods to encapsulate and
   decapsulate IP Encapsulating Security Payload (ESP) packets inside
   UDP packets for traversing Network Address Translators.  ESP
   encapsulation, as defined in this document, can be used in both IPv4
   and IPv6 scenarios.  Whenever negotiated, encapsulation is used with
   Internet Key Exchange (IKE).

このプロトコル仕様は、Network Address Translatorsを横断するためにUDPパケットの中で要約するメソッドとdecapsulate IP Encapsulating Security有効搭載量(超能力)パケットを定義します。 IPv4とIPv6シナリオの両方で本書では定義される超能力カプセル化は使用できます。 交渉されるとき、カプセル化はインターネット・キー・エクスチェンジ(IKE)と共に使用されます。

Huttunen, et al.            Standards Track                     [Page 1]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[1ページ]。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .  3
       2.1.  UDP-Encapsulated ESP Header Format . . . . . . . . . . .  3
       2.2.  IKE Header Format for Port 4500  . . . . . . . . . . . .  4
       2.3.  NAT-Keepalive Packet Format  . . . . . . . . . . . . . .  4
   3.  Encapsulation and Decapsulation Procedures . . . . . . . . . .  5
       3.1.  Auxiliary Procedures . . . . . . . . . . . . . . . . . .  5
             3.1.1.  Tunnel Mode Decapsulation NAT Procedure  . . . .  5
             3.1.2.  Transport Mode Decapsulation NAT Procedure . . .  5
       3.2.  Transport Mode ESP Encapsulation . . . . . . . . . . . .  6
       3.3.  Transport Mode ESP Decapsulation . . . . . . . . . . . .  6
       3.4.  Tunnel Mode ESP Encapsulation  . . . . . . . . . . . . .  7
       3.5.  Tunnel Mode ESP Decapsulation  . . . . . . . . . . . . .  7
   4.  NAT Keepalive Procedure  . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
       5.1.  Tunnel Mode Conflict . . . . . . . . . . . . . . . . . .  8
       5.2.  Transport Mode Conflict  . . . . . . . . . . . . . . . .  9
   6.  IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       8.1.  Normative References . . . . . . . . . . . . . . . . . . 11
       8.2.  Informative References . . . . . . . . . . . . . . . . . 11
   A.  Clarification of Potential NAT Multiple Client Solutions . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 パケット・フォーマット. . . . . . . . . . . . . . . . . . . . . . . . 3 2.1。 UDPによってカプセル化された超能力ヘッダー形式. . . . . . . . . . . 3 2.2。 ポート4500.42.3のためのIKEヘッダー形式。 NAT-Keepaliveパケット・フォーマット. . . . . . . . . . . . . . 4 3。 カプセル化と被膜剥離術手順. . . . . . . . . . 5 3.1。 補助の手順. . . . . . . . . . . . . . . . . . 5 3.1.1。 モード被膜剥離術NAT手順. . . . 5 3.1.2にトンネルを堀ってください。 モード被膜剥離術NAT手順. . . 5 3.2を輸送してください。 モード超能力カプセル化. . . . . . . . . . . . 6 3.3を輸送してください。 モード超能力被膜剥離術. . . . . . . . . . . . 6 3.4を輸送してください。 モード超能力カプセル化. . . . . . . . . . . . . 7 3.5にトンネルを堀ってください。 モード超能力被膜剥離術. . . . . . . . . . . . . 7 4にトンネルを堀ってください。 NAT Keepalive手順. . . . . . . . . . . . . . . . . . . 7 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 8 5.1。 モード闘争. . . . . . . . . . . . . . . . . . 8 5.2にトンネルを堀ってください。 モード闘争. . . . . . . . . . . . . . . . 9 6を輸送してください。 IAB問題. . . . . . . . . . . . . . . . . . . . . . 10 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 11 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1。 引用規格. . . . . . . . . . . . . . . . . . 11 8.2。 NATの潜在的倍数クライアントソリューション. . . 12作者のA.明確化が.14の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 15を扱う有益な参照. . . . . . . . . . . . . . . . . 11

1.  Introduction

1. 序論

   This protocol specification defines methods to encapsulate and
   decapsulate ESP packets inside UDP packets for traversing Network
   Address Translators (NATs) (see [RFC3715], section 2.2, case i).  The
   UDP port numbers are the same as those used by IKE traffic, as
   defined in [RFC3947].

このプロトコル仕様は、Network Address Translators(NATs)を横断するためにUDPパケットの中で要約するメソッドとdecapsulate超能力パケットを定義します([RFC3715]を見てください、セクション2.2、ケースi)。 UDPポートナンバーは[RFC3947]で定義されるようにIKEトラフィックによって使用されるものと同じです。

   The sharing of the port numbers for both IKE and UDP encapsulated ESP
   traffic was selected because it offers better scaling (only one NAT
   mapping in the NAT; no need to send separate IKE keepalives), easier
   configuration (only one port to be configured in firewalls), and
   easier implementation.

より良いスケーリング(NATにおける1つのNATマッピングだけ; 別々のIKE keepalivesを送る必要性がない)、より簡単な構成(1つのファイアウォールで構成されるべきポートだけ)、および、より簡単な実装を提供するので、超能力トラフィックであるとカプセル化されたIKEとUDPの両方のためのポートナンバーの共有は選択されました。

   A client's needs should determine whether transport mode or tunnel
   mode is to be supported (see [RFC3715], Section 3, "Telecommuter
   scenario").  L2TP/IPsec clients MUST support the modes as defined in
   [RFC3193].  IPsec tunnel mode clients MUST support tunnel mode.

クライアントの必要性は、交通機関かトンネルモードがサポートされるかどうか([RFC3715]、「在宅勤務者シナリオ」というセクション3を見ます)ことであることを決定するべきです。 L2TP/IPsecクライアントは[RFC3193]で定義されるようにモードをサポートしなければなりません。 IPsecトンネルモードクライアントはトンネルモードをサポートしなければなりません。

Huttunen, et al.            Standards Track                     [Page 2]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[2ページ]。

   An IKE implementation supporting this protocol specification MUST NOT
   use the ESP SPI field zero for ESP packets.  This ensures that IKE
   packets and ESP packets can be distinguished from each other.

このプロトコルが仕様であるとサポートするIKE実装は超能力パケットにESP SPI分野ゼロを使用してはいけません。 これは、互いとIKEパケットと超能力パケットを区別できるのを確実にします。

   As defined in this document, UDP encapsulation of ESP packets is
   written in terms of IPv4 headers.  There is no technical reason why
   an IPv6 header could not be used as the outer header and/or as the
   inner header.

本書では定義されるように、超能力パケットのUDPカプセル化はIPv4ヘッダーに関して書かれています。 外側のヘッダー内側のヘッダーとしてIPv6ヘッダーを使用できなかったどんな技術的な理由もありません。

   Because the protection of the outer IP addresses in IPsec AH is
   inherently incompatible with NAT, the IPsec AH was left out of the
   scope of this protocol specification.  This protocol also assumes
   that IKE (IKEv1 [RFC2401] or IKEv2 [IKEv2]) is used to negotiate the
   IPsec SAs.  Manual keying is not supported.

IPsec AHでの外側のIPアドレスの保護が本来NATと両立しないので、IPsec AHはこのプロトコル仕様の範囲から外されました。 また、このプロトコルは、IKE(IKEv1[RFC2401]かIKEv2[IKEv2])がIPsec SAsを交渉するのに使用されると仮定します。 手動の合わせることはサポートされません。

   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 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

2.  Packet Formats

2. パケット・フォーマット

2.1.  UDP-Encapsulated ESP Header Format

2.1. UDPによってカプセル化された超能力ヘッダー形式

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Source Port            |      Destination Port         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Length              |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      ESP header [RFC2406]                     |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 超能力ヘッダー[RFC2406]| ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The UDP header is a standard [RFC0768] header, where

UDPヘッダーは標準の[RFC0768]ヘッダー、どこです。

   o  the Source Port and Destination Port MUST be the same as that used
      by IKE traffic,
   o  the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and
   o  receivers MUST NOT depend on the UDP checksum being a zero value.

o ○ Source PortとDestination PortはIKEトラフィックによって使用されるそれと同じであるに違いありません、ゼロが評価するように伝えられて、IPv4 UDP Checksum SHOULD。o受信機はゼロが評価するUDPチェックサム存在によってはいけません。

   The SPI field in the ESP header MUST NOT be a zero value.

超能力ヘッダーのSPI分野はゼロが値であったならそうしてはいけません。

Huttunen, et al.            Standards Track                     [Page 3]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[3ページ]。

2.2.  IKE Header Format for Port 4500

2.2. ポート4500へのIKEヘッダー形式

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Source Port            |      Destination Port         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Length              |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Non-ESP Marker                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      IKE header [RFC2409]                     |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 非超能力のマーカー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IKEヘッダー[RFC2409]| ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The UDP header is a standard [RFC0768] header and is used as defined
   in [RFC3947].  This document does not set any new requirements for
   the checksum handling of an IKE packet.

UDPヘッダーは、標準の[RFC0768]ヘッダーであり、[RFC3947]で定義されるように使用されています。 このドキュメントはIKEパケットのチェックサム取り扱いのためのどんな新しい要件も設定しません。

   A Non-ESP Marker is 4 zero-valued bytes aligning with the SPI field
   of an ESP packet.

Non-超能力Markerは超能力パケットのSPI分野に並ぶ無評価された4バイトです。

2.3.  NAT-Keepalive Packet Format

2.3. NAT-Keepaliveパケット・フォーマット

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Source Port            |      Destination Port         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Length              |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    0xFF       |
   +-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF| +-+-+-+-+-+-+-+-+

   The UDP header is a standard [RFC0768] header, where

UDPヘッダーは標準の[RFC0768]ヘッダー、どこです。

   o  the Source Port and Destination Port MUST be the same as used by
      UDP-ESP encapsulation of Section 2.1,
   o  the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and
   o  receivers MUST NOT depend upon the UDP checksum being a zero
      value.

o ○ Source PortとDestination Portはセクション2.1のUDP-超能力カプセル化によって使用されるのと同じであるに違いありません、ゼロが評価するように伝えられて、IPv4 UDP Checksum SHOULD。o受信機はゼロが評価するUDPチェックサム存在によってはいけません。

   The sender MUST use a one-octet-long payload with the value 0xFF.
   The receiver SHOULD ignore a received NAT-keepalive packet.

送付者は値の0xFFがある、ある八重奏長さペイロードを使用しなければなりません。 受信機SHOULDは容認されたNAT-keepaliveパケットを無視します。

Huttunen, et al.            Standards Track                     [Page 4]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[4ページ]。

3.  Encapsulation and Decapsulation Procedures

3. カプセル化と被膜剥離術手順

3.1.  Auxiliary Procedures

3.1. 補助の手順

3.1.1.  Tunnel Mode Decapsulation NAT Procedure

3.1.1. トンネル・モード被膜剥離術NAT手順

   When a tunnel mode has been used to transmit packets (see [RFC3715],
   section 3, criteria "Mode support" and "Telecommuter scenario"), the
   inner IP header can contain addresses that are not suitable for the
   current network.  This procedure defines how these addresses are to
   be converted to suitable addresses for the current network.

トンネルモードがパケットを伝えるのに使用されたとき([RFC3715]を見てください、セクション3、評価基準「モードサポート」と「在宅勤務者シナリオ」)、内側のIPヘッダーは現在のネットワークに適していないアドレスを含むことができます。 この手順は現在のネットワークに、適当なアドレスに変換されるこれらのアドレスがことである方法を定義します。

   Depending on local policy, one of the following MUST be done:

ローカルの方針によって、以下の1つをしなければなりません:

   1.  If a valid source IP address space has been defined in the policy
       for the encapsulated packets from the peer, check that the source
       IP address of the inner packet is valid according to the policy.
   2.  If an address has been assigned for the remote peer, check that
       the source IP address used in the inner packet is the assigned IP
       address.
   3.  NAT is performed for the packet, making it suitable for transport
       in the local network.

1. 有効なソースIPアドレス空間がカプセル化されたパケットのために同輩から方針で定義されたなら、方針によると、内側のパケットのソースIPアドレスが有効であることをチェックしてください。 2. リモート同輩のためにアドレスを割り当ててあるなら、アドレスが内側のパケットで使用したソースIPが割り当てられたIPアドレスであることをチェックしてください。 3. それを企業内情報通信網で輸送に適するようにして、NATはパケットのために実行されます。

3.1.2.  Transport Mode Decapsulation NAT Procedure

3.1.2. 交通機関被膜剥離術NAT手順

   When a transport mode has been used to transmit packets, contained
   TCP or UDP headers will have incorrect checksums due to the change of
   parts of the IP header during transit.  This procedure defines how to
   fix these checksums (see [RFC3715], section 2.1, case b).

交通機関がパケットを伝えるのに使用されたとき、IPヘッダーの一部の変化のため、トランジットの間、含まれたTCPかUDPヘッダーには、不正確なチェックサムがあるでしょう。 この手順はこれらのチェックサムを修理する方法を定義します([RFC3715]、セクション2.1を見てください、そして、bをケースに入れてください)。

   Depending on local policy, one of the following MUST be done:

ローカルの方針によって、以下の1つをしなければなりません:

   1.  If the protocol header after the ESP header is a TCP/UDP header
       and the peer's real source and destination IP address have been
       received according to [RFC3947], incrementally recompute the
       TCP/UDP checksum:

1. 次々とプロトコル超能力ヘッダーがTCP/UDPヘッダーと同輩の本当の情報筋であるか、そして、送付先IPアドレスは、[RFC3947]に応じて受け取られて、TCP/UDPチェックサムを増加して再計算します:

       *  Subtract the IP source address in the received packet from the
          checksum.
       *  Add the real IP source address received via IKE to the
          checksum (obtained from the NAT-OA)
       *  Subtract the IP destination address in the received packet
          from the checksum.
       *  Add the real IP destination address received via IKE to the
          checksum (obtained from the NAT-OA).
       Note: If the received and real address are the same for a given
       address (e.g., say the source address), the operations cancel and
       don't need to be performed.

* 容認されたパケットでチェックサムからIPソースアドレスを引き算してください。 * 本当のIPソースアドレスがチェックサム(NAT-OAから、得る)*へのIKEを通して受信されたと言い足してください。容認されたパケットでチェックサムから受信者IPアドレスを引き算してください。 * 本当の受信者IPアドレスがチェックサム(NAT-OAから、得る)へのIKEを通して受信されたと言い足してください。 以下に注意してください。 与えられたアドレスに、受け取られていていて本当のアドレスが同じであるなら(例えば、ソースアドレスを言ってください)、操作は取り消して、実行される必要はありません。

Huttunen, et al.            Standards Track                     [Page 5]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[5ページ]。

   2.  If the protocol header after the ESP header is a TCP/UDP header,
       recompute the checksum field in the TCP/UDP header.

2. プロトコルヘッダーであるなら、超能力ヘッダーの後に、TCP/UDPヘッダーがあって、recomputeはTCP/UDPヘッダーのチェックサム分野です。

   3.  If the protocol header after the ESP header is a UDP header, set
       the checksum field to zero in the UDP header.  If the protocol
       after the ESP header is a TCP header, and if there is an option
       to flag to the stack that the TCP checksum does not need to be
       computed, then that flag MAY be used.  This SHOULD only be done
       for transport mode, and if the packet is integrity protected.
       Tunnel mode TCP checksums MUST be verified.  (This is not a
       violation to the spirit of section 4.2.2.7 in [RFC1122] because a
       checksum is being generated by the sender and verified by the
       receiver.  That checksum is the integrity over the packet
       performed by IPsec.)

3. 次々とプロトコル超能力ヘッダーがUDPヘッダーであるなら、UDPヘッダーにチェックサム分野をゼロに設定してください。 超能力ヘッダーの後のプロトコルがTCPヘッダーであり、TCPチェックサムが計算されるために必要としないスタックに旗を揚げさせるオプションがあれば、その旗は使用されるかもしれません。 交通機関のためにして、パケットが保全である場合にだけ、このSHOULDはそうです。保護にされる。 トンネルモードTCPチェックサムについて確かめなければなりません。 これはセクション4.2の精神への違反ではありません。チェックサムがあるので、[RFC1122]の.7は、送付者によって生成されて、受信機について確かめました。(.2 そのチェックサムはIPsecによって実行されたパケットの上の保全です)。

   In addition an implementation MAY fix any contained protocols that
   have been broken by NAT (see [RFC3715], section 2.1, case g).

さらに、実装はNATによって破られたどんな含まれたプロトコルも修理するかもしれません([RFC3715]を見てください、セクション2.1、ケースg)。

3.2.  Transport Mode ESP Encapsulation

3.2. 交通機関超能力カプセル化

                 BEFORE APPLYING ESP/UDP
            ----------------------------
      IPv4  |orig IP hdr  |     |      |
            |(any options)| TCP | Data |
            ----------------------------

超能力/UDPを適用する前に---------------------------- IPv4|orig IP hdr| | | |(どんなオプションも)| TCP| データ| ----------------------------

                 AFTER APPLYING ESP/UDP
            -------------------------------------------------------
      IPv4  |orig IP hdr  | UDP | ESP |     |      |   ESP   | ESP|
            |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|
            -------------------------------------------------------
                                      |<----- encrypted ---->|
                                |<------ authenticated ----->|

超能力/UDPを適用した後に------------------------------------------------------- IPv4|orig IP hdr| UDP| 超能力| | | 超能力| 超能力| |(どんなオプションも)| Hdr| Hdr| TCP| データ| トレーラ|Auth| ------------------------------------------------------- | <、-、-、-、-- 暗号化されます。---->| | <、-、-、-、-、-- 認証されます。----->|

   1.  Ordinary ESP encapsulation procedure is used.
   2.  A properly formatted UDP header is inserted where shown.
   3.  The Total Length, Protocol, and Header Checksum (for IPv4) fields
       in the IP header are edited to match the resulting IP packet.

1. 普通の超能力カプセル化手順は使用されています。 2. 適切にフォーマットされたUDPヘッダーは示されるところに挿入されます。 3. Total Length、プロトコル、およびIPヘッダーのHeader Checksum(IPv4のための)分野は、結果として起こるIPパケットを合わせるために編集されます。

3.3.  Transport Mode ESP Decapsulation

3.3. 交通機関超能力被膜剥離術

   1.  The UDP header is removed from the packet.
   2.  The Total Length, Protocol, and Header Checksum (for IPv4) fields
       in the new IP header are edited to match the resulting IP packet.
   3.  Ordinary ESP decapsulation procedure is used.
   4.  Transport mode decapsulation NAT procedure is used.

1. パケットからUDPヘッダーを取り除きます。 2. Total Length、プロトコル、および新しいIPヘッダーのHeader Checksum(IPv4のための)分野は、結果として起こるIPパケットを合わせるために編集されます。 3. 普通の超能力被膜剥離術手順は使用されています。 4. 交通機関被膜剥離術NAT手順は使用されています。

Huttunen, et al.            Standards Track                     [Page 6]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[6ページ]。

3.4.  Tunnel Mode ESP Encapsulation

3.4. トンネル・モード超能力カプセル化

                 BEFORE APPLYING ESP/UDP
            ----------------------------
      IPv4  |orig IP hdr  |     |      |
            |(any options)| TCP | Data |
            ----------------------------

超能力/UDPを適用する前に---------------------------- IPv4|orig IP hdr| | | |(どんなオプションも)| TCP| データ| ----------------------------

                 AFTER APPLYING ESP/UDP
        --------------------------------------------------------------
   IPv4 |new h.| UDP | ESP |orig IP hdr  |     |      |   ESP   | ESP|
        |(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth|
        --------------------------------------------------------------
                           |<------------ encrypted ----------->|
                     |<------------- authenticated ------------>|

超能力/UDPを適用した後に-------------------------------------------------------------- IPv4|新しいh.| UDP| 超能力|orig IP hdr| | | 超能力| 超能力| |(選びます)| Hdr| Hdr|(どんなオプションも)| TCP| データ| トレーラ|Auth| -------------------------------------------------------------- | <、-、-、-、-、-、-、-、-、-、-、-- 暗号化されます。----------->| | <、-、-、-、-、-、-、-、-、-、-、-、-- 認証されます。------------>|

   1.  Ordinary ESP encapsulation procedure is used.
   2.  A properly formatted UDP header is inserted where shown.
   3.  The Total Length, Protocol, and Header Checksum (for IPv4) fields
   in the new IP header are edited to match the resulting IP packet.

1. 普通の超能力カプセル化手順は使用されています。 2. 適切にフォーマットされたUDPヘッダーは示されるところに挿入されます。 3. Total Length、プロトコル、および新しいIPヘッダーのHeader Checksum(IPv4のための)分野は、結果として起こるIPパケットを合わせるために編集されます。

3.5.  Tunnel Mode ESP Decapsulation

3.5. トンネル・モード超能力被膜剥離術

   1.  The UDP header is removed from the packet.
   2.  The Total Length, Protocol, and Header Checksum (for IPv4) fields
       in the new IP header are edited to match the resulting IP packet.
   3.  Ordinary ESP decapsulation procedure is used.
   4.  Tunnel mode decapsulation NAT procedure is used.

1. パケットからUDPヘッダーを取り除きます。 2. Total Length、プロトコル、および新しいIPヘッダーのHeader Checksum(IPv4のための)分野は、結果として起こるIPパケットを合わせるために編集されます。 3. 普通の超能力被膜剥離術手順は使用されています。 4. トンネルモード被膜剥離術NAT手順は使用されています。

4.  NAT Keepalive Procedure

4. NAT Keepalive手順

   The sole purpose of sending NAT-keepalive packets is to keep NAT
   mappings alive for the duration of a connection between the peers
   (see [RFC3715], Section 2.2, case j).  Reception of NAT-keepalive
   packets MUST NOT be used to detect whether a connection is live.

NAT-keepaliveパケットを送る唯一の目的は同輩の間の接続の持続時間のためにNATマッピングを生かす([RFC3715]を見てください、セクション2.2、ケースj)ことです。 接続が活動的であるかどうか検出するのにNAT-keepaliveパケットのレセプションを使用してはいけません。

   A peer MAY send a NAT-keepalive packet if one or more phase I or
   phase II SAs exist between the peers, or if such an SA has existed at
   most N minutes earlier.  N is a locally configurable parameter with a
   default value of 5 minutes.

同輩が1であるならNAT-keepaliveパケットを送るかもしれませんか、より多くのフェーズの私かフェーズII SAsが同輩の間に存在しているか、またはそのようなSAが高々存在したなら、Nは、より早いのを書き留めます。 Nは5分のデフォルト値がある局所的に構成可能なパラメタです。

   A peer SHOULD send a NAT-keepalive packet if a need for it is
   detected according to [RFC3947] and if no other packet to the peer
   has been sent in M seconds.  M is a locally configurable parameter
   with a default value of 20 seconds.

[RFC3947]に従ってそれの必要性を見つけて、M秒に同輩への他のパケットを全く送らないなら、A同輩SHOULDはNAT-keepaliveパケットを送ります。 Mは20秒のデフォルト値がある局所的に構成可能なパラメタです。

Huttunen, et al.            Standards Track                     [Page 7]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[7ページ]。

5.  Security Considerations

5. セキュリティ問題

5.1.  Tunnel Mode Conflict

5.1. トンネル・モード闘争

   Implementors are warned that it is possible for remote peers to
   negotiate entries that overlap in an SGW (security gateway), an issue
   affecting tunnel mode (see [RFC3715], section 2.1, case e).

リモート同輩がSGW(セキュリティゲートウェイ)(トンネルモード([RFC3715]を見てください、セクション2.1、ケースe)に影響する問題)に重なるエントリーを交渉するように、作成者はそれが可能であるのに注意されます。

             +----+            \ /
             |    |-------------|----\
             +----+            / \    \
             Ari's           NAT 1     \
             Laptop                     \
            10.1.2.3                     \
             +----+            \ /        \       +----+          +----+
             |    |-------------|----------+------|    |----------|    |
             +----+            / \                +----+          +----+
             Bob's           NAT 2                  SGW           Suzy's
             Laptop                                               Server
            10.1.2.3

+----+ \ / | |-------------|----\ +----+/\\アリのNAT1円のラップトップ10.1円.2.3円+----+ \ / \ +----+ +----+ | |-------------|----------+------| |----------| | +----+ / \ +----+ +----+ ボブのNAT2SGWスージーのラップトップサーバ10.1.2.3

   Because SGW will now see two possible SAs that lead to 10.1.2.3, it
   can become confused about where to send packets coming from Suzy's
   server.  Implementors MUST devise ways of preventing this from
   occurring.

SGWがそうするので、今、10.1に通じる2可能なSAsを見てください。それはパケットをスージーのサーバからどこに来させるかに関して混乱するようになることができます。.2 .3 作成者はこれが起こるのを防ぐ方法を工夫しなければなりません。

   It is RECOMMENDED that SGW either assign locally unique IP addresses
   to Ari's and Bob's laptop (by using a protocol such as DHCP over
   IPsec) or use NAT to change Ari's and Bob's laptop source IP
   addresses to these locally unique addresses before sending packets
   forward to Suzy's server.  This covers the "Scaling" criteria of
   section 3 in [RFC3715].

SGWが局所的に、アリのものへの固有のIPアドレスとボブのラップトップ(IPsecの上のDHCPなどのプロトコルを使用するのによる)を割り当てるか、またはスージーのサーバにパケットを考慮させるために送る前にソースIPがこれらの局所的にユニークなアドレスに扱うアリとボブのラップトップを変えるのにNATを使用するのが、RECOMMENDEDです。これは[RFC3715]のセクション3の「スケーリング」評価基準をカバーしています。

   Please see Appendix A.

Appendix Aを見てください。

Huttunen, et al.            Standards Track                     [Page 8]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[8ページ]。

5.2.  Transport Mode Conflict

5.2. 交通機関闘争

   Another similar issue may occur in transport mode, with 2 clients,
   Ari and Bob, behind the same NAT talking securely to the same server
   (see [RFC3715], Section 2.1, case e).

別の同様の問題は交通機関で起こるかもしれません、2人のクライアント、アリ、およびボブと共に、しっかりと同じサーバと話す同じNATの後ろで([RFC3715]を見てください、セクション2.1、ケースe)。

   Cliff wants to talk in the clear to the same server.

クリフは同じサーバへの明確で話したがっています。

             +----+
             |    |
             +----+ \
             Ari's   \
             Laptop   \
            10.1.2.3   \
             +----+    \ /                +----+
             |    |-----+-----------------|    |
             +----+    / \                +----+
             Bob's     NAT                Server
             Laptop   /
            10.1.2.4 /
                    /
            +----+ /
            |    |/
            +----+
            Cliff's
            Laptop
           10.1.2.5

+----+ | | +----+ \アリのラップトップ10.1円の.2.3円\+----+ \ / +----+ | |-----+-----------------| | +----+ / \ +----+ ボブのNATサーバラップトップ/10.1.2.4//+----+ / | |/ +----+ クリフのラップトップ10.1.2、.5

   Now, transport SAs on the server will look like this:

現在、サーバの輸送SAsはこれに似るでしょう:

   To Ari: Server to NAT, <traffic desc1>, UDP encap <4500, Y>

アリに: NAT、<トラフィックdesc1>、UDP encap<4500、Y>へのサーバ

   To Bob: Server to NAT, <traffic desc2>, UDP encap <4500, Z>

ボブに: NAT、<トラフィックdesc2>、UDP encap<4500、Z>へのサーバ

   Cliff's traffic is in the clear, so there is no SA.

クリフのトラフィックが明確にあるので、SAが全くありません。

   <traffic desc> is the protocol and port information.  The UDP encap
   ports are the ports used in UDP-encapsulated ESP format of section
   2.1.  Y,Z are the dynamic ports assigned by the NAT during the IKE
   negotiation.  So IKE traffic from Ari's laptop goes out on UDP
   <4500,4500>.  It reaches the server as UDP <Y,4500>, where Y is the
   dynamically assigned port.

<トラフィックdesc>はプロトコルとポート情報です。 UDP encapポートはセクション2.1のUDPによってカプセル化された超能力形式に使用されるポートです。 Y、ZはIKE交渉の間にNATによって割り当てられたダイナミックなポートです。 それで、アリのラップトップからのIKEトラフィックはUDP<4500、4500>で出かけます。 それはUDP<Y、4500>としてサーバに達します。そこでは、Yがダイナミックに割り当てられたポートです。

   If the <traffic desc1> overlaps <traffic desc2>, then simple filter
   lookups may not be sufficient to determine which SA has to be used to
   send traffic.  Implementations MUST handle this situation, either by
   disallowing conflicting connections, or by other means.

<トラフィックdesc1>が<トラフィックdesc2>を重ね合わせるなら、当時の簡単なフィルタルックアップは、どのSAがトラフィックを送るのに使用されなければならないかを決定するために十分でないかもしれません。 実装は闘争接続を禁じるか、または他の手段でこの状況を扱わなければなりません。

Huttunen, et al.            Standards Track                     [Page 9]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[9ページ]。

   Assume now that Cliff wants to connect to the server in the clear.
   This is going to be difficult to configure, as the server already has
   a policy (from Server to the NAT's external address) for securing
   <traffic desc>.  For totally non-overlapping traffic descriptions,
   this is possible.

今、クリフが明確でサーバに接続したがっていると仮定してください。 構成するのはこれが難しくなるでしょう、サーバに方針が<トラフィックがdesc>であると機密保護するために既にあるとき(ServerからNATの外部アドレスまで)。 非重なっている完全にトラフィック記述において、これは可能です。

   Sample server policy could be as follows:

サンプルサーバ方針は以下の通りであるかもしれません:

   To Ari: Server to NAT, All UDP, secure

アリに: All UDPの、そして、安全なNATへのサーバ

   To Bob: Server to NAT, All TCP, secure

ボブに: All TCPの、そして、安全なNATへのサーバ

   To Cliff: Server to NAT, ALL ICMP, clear text

クリフに: NATへのサーバ、ALL ICMPはテキストをクリアします。

   Note that this policy also lets Ari and Bob send cleartext ICMP to
   the server.

また、アリとボブがこの方針でcleartext ICMPをサーバに送ることができることに注意してください。

   The server sees all clients behind the NAT as the same IP address, so
   setting up different policies for the same traffic descriptor is in
   principle impossible.

サーバが、NATの後ろですべてのクライアントを同じIPアドレスと考えるので、同じトラフィック記述子のために異なった方針をセットアップするのは原則として不可能です。

   A problematic example of configuration on the server is as follows:

サーバでの構成の問題の多い例は以下の通りです:

   Server to NAT, TCP, secure (for Ari and Bob)

TCPの、そして、安全なNATへのサーバ(アリとボブのための)

   Server to NAT, TCP, clear (for Cliff)

NATへのサーバ、TCPはクリアします。(クリフのための)

   The server cannot enforce his policy, as it is possible that
   misbehaving Bob sends traffic in the clear.  This is
   indistinguishable from when Cliff sends traffic in the clear.  So it
   is impossible to guarantee security from some clients behind a NAT,
   while allowing clear text from different clients behind the SAME NAT.
   If the server's security policy allows this, however, it can do
   best-effort security: If the client from behind the NAT initiates
   security, his connection will be secured.  If he sends in the clear,
   the server will still accept that clear text.

ふらちな事をしているボブが明確でトラフィックを送るのが、可能であるときに、サーバは彼の方針を実施できません。 これはクリフが明確でトラフィックを送る時から区別がつきません。 それで、NATの後ろで何人かのクライアントから安全を保障するのはSAME NATの後ろの異なったクライアントからのクリアテキストを許容している間、不可能です。 しかしながら、サーバの安全保障政策がこれを許容するなら、ベストエフォート型セキュリティができます: NATの後ろからのクライアントがセキュリティを開始すると、彼の接続を保証するでしょう。 彼が明確を送ると、それでも、サーバはそのクリアテキストを受け入れるでしょう。

   For security guarantees, the above problematic scenario MUST NOT be
   allowed on servers.  For best effort security, this scenario MAY be
   used.

セキュリティ保証のために、サーバに上の問題の多いシナリオを許容してはいけません。 ベストエフォート型セキュリティのために、このシナリオは使用されるかもしれません。

   Please see Appendix A.

Appendix Aを見てください。

6.  IAB Considerations

6. IAB問題

   The UNSAF [RFC3424] questions are addressed by the IPsec-NAT
   compatibility requirements document [RFC3715].

IPsec-NAT互換性要件ドキュメント[RFC3715]によってUNSAF[RFC3424]質問は扱われます。

Huttunen, et al.            Standards Track                    [Page 10]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[10ページ]。

7.  Acknowledgments

7. 承認

   Thanks to Tero Kivinen and William Dixon, who contributed actively to
   this document.

Tero Kivinenとウィリアム・ディクソンをありがとうございます。(ディクソンは、活発にこのドキュメントに貢献しました)。

   Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen, and Santeri
   Paavolainen, who contributed to the early documents about NAT
   traversal.

NAT縦断に関する早めのドキュメントに貢献したJoern Sierwald、タミールZegman、Tatu Ylonen、およびSanteri Paavolainenのおかげで。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

[RFC0768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。

   [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.

[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。

   [RFC3947]  Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
              RFC 3947, January 2005.

[RFC3947] Kivinen、T.、「IKEでのNAT縦断の交渉」、RFC3947、2005年1月。

8.2.  Informative References

8.2. 有益な参照

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日

   [RFC3193]  Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
              "Securing L2TP using IPsec", RFC 3193, November 2001.

[RFC3193] パテルとB.とAbobaとB.とディクソンとW.とゾルン、G.とS.ブース、「IPsecを使用することでL2TPを固定します」、RFC3193、2001年11月。

   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
              Self-Address Fixing (UNSAF) Across Network Address
              Translation", RFC 3424, November 2002.

[RFC3424] DaigleとL.とIAB、「一方的な自己アドレスのためのネットワークアドレス変換の向こう側に(UNSAF)を修理するIAB問題」、RFC3424、2002年11月。

   [RFC3715]  Aboba, B. and W. Dixon, "IPsec-Network Address Translation
              (NAT) Compatibility Requirements", RFC 3715, March 2004.

[RFC3715] AbobaとB.とW.ディクソン、「IPsec-ネットワーク・アドレス翻訳(NAT)互換性要件」、RFC3715、2004年3月。

   [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              Work in Progress, October 2004.

[IKEv2] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」が進歩、2004年10月に働いています。

Huttunen, et al.            Standards Track                    [Page 11]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[11ページ]。

Appendix A.  Clarification of Potential NAT Multiple Client Solutions

NATの潜在的倍数クライアントソリューションの付録A.明確化

   This appendix provides clarification about potential solutions to the
   problem of multiple clients behind the same NAT simultaneously
   connecting to the same destination IP address.

この付録は、同時に同じ送付先IPアドレスに接続しながら、同じNATの後ろで潜在的ソリューションに関して複数のクライアントの問題に明確化を提供します。

   Sections 5.1 and 5.2 say that you MUST avoid this problem.  As this
   is not a matter of wire protocol, but a matter local implementation,
   the mechanisms do not belong in the protocol specification itself.
   They are instead listed in this appendix.

セクション5.1と5.2は、あなたがこの問題を避けなければならないと言います。 これがワイヤプロトコルの問題ではなく、件の地方の実装であるので、プロトコル仕様自体にはメカニズムがありません。 それらは代わりにこの付録に記載されています。

   Choosing an option will likely depend on the scenarios for which one
   uses/supports IPsec NAT-T.  This list is not meant to be exhaustive,
   so other solutions may exist.  We first describe the generic choices
   that solve the problem for all upper-layer protocols.

オプションを選ぶのはおそらく1つがIPsec NAT Tを使用するか、または支持するシナリオによるでしょう。 このリストが徹底的であることが意味されないので、他の解決策は存在するかもしれません。 私たちは最初に、すべての上側の層のプロトコルのために問題を解決する一般的な選択について説明します。

   Generic choices for ESP transport mode:

超能力のための一般的な選択はモードを輸送します:

   Tr1) Implement a built-in NAT (network address translation) above
   IPsec decapsulation.

Tr1) IPsec被膜剥離術を超えて内蔵のNAT(ネットワークアドレス変換)を実行してください。

   Tr2) Implement a built-in NAPT (network address port translation)
   above IPsec decapsulation.

Tr2) IPsec被膜剥離術を超えて内蔵のNAPT(ナプト)を実行してください。

   Tr3) An initiator may decide not to request transport mode once NAT
   is detected and may instead request a tunnel-mode SA.  This may be a
   retry after transport mode is denied by the responder, or the
   initiator may choose to propose a tunnel SA initially.  This is no
   more difficult than knowing whether to propose transport mode or
   tunnel mode without NAT.  If for some reason the responder prefers or
   requires tunnel mode for NAT traversal, it must reject the quick mode
   SA proposal for transport mode.

Tr3) 創始者は、NATがいったん検出されると交通機関を要求しないと決めて、代わりにトンネルモードSAを要求するかもしれません。 交通機関が応答者によって否定された後にこれは再試行であるかもしれませんか創始者が、初めはトンネルSAを提案するのを選ぶかもしれません。 NATなしで交通機関かトンネルモードを提案するかどうかを知っているほどこれは難しくはありません。 ある理由で応答者がNAT縦断のためのトンネルモードを好むか、または必要とするなら、それは交通機関のための迅速なモードSA提案を拒絶しなければなりません。

   Generic choices for ESP tunnel mode:

超能力のための一般的な選択はモードにトンネルを堀ります:

   Tn1) Same as Tr1.

Tn1) Tr1と同じです。

   Tn2) Same as Tr2.

Tn2) Tr2と同じです。

   Tn3) This option is possible if an initiator can be assigned an
   address through its tunnel SA, with the responder using DHCP.  The
   initiator may initially request an internal address via the
   DHCP-IPsec method, regardless of whether it knows it is behind a NAT.
   It may re-initiate an IKE quick mode negotiation for DHCP tunnel SA
   after the responder fails the quick mode SA transport mode proposal.
   This happens either when a NAT-OA payload is sent or because it

Tn3) トンネルSAを通してアドレスを創始者に割り当てることができるなら、このオプションは可能です、応答者がDHCPを使用していて。 創始者は初めはDHCP-IPsec方法で内部のアドレスを要求するかもしれません、NATの後ろにあるのを知っているかどうかにかかわらず。 応答者が迅速なモードSA交通機関提案に失敗した後にそれはDHCPトンネルSAのためにIKEの迅速なモード交渉を再開始するかもしれません。 または、NAT-OAペイロードを送るとき、これが起こる、それ

Huttunen, et al.            Standards Track                    [Page 12]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[12ページ]。

   discovers from NAT-D that the initiator is behind a NAT and its local
   configuration/policy will only accept a NAT connection when being
   assigned an address through DHCP-IPsec.

NAT Dから、創始者がNATの後ろにいて、アドレスがDHCP-IPsecを通して割り当てられるときだけローカルの構成/方針がNAT接続を受け入れると発見します。

   There are also implementation choices that offer limited
   interoperability.  Implementors should specify which applications or
   protocols should work if these options are selected.  Note that
   neither Tr4 nor Tn4, as described below, are expected to work with
   TCP traffic.

また、限られた相互運用性を提供する実現選択があります。 作成者は、これらのオプションが選択されるならどのアプリケーションかプロトコルが働くべきであるかを指定するべきです。 以下で説明されないTr4もTn4もTCP交通で働くと予想されることに注意してください。

   Limited interoperability choices for ESP transport mode:

超能力のための株式会社相互運用性選択はモードを輸送します:

   Tr4) Implement upper-layer protocol awareness of the inbound and
   outbound IPsec SA so that it doesn't use the source IP and the source
   port as the session identifier (e.g., an L2TP session ID mapped to
   the IPsec SA pair that doesn't use the UDP source port or the source
   IP address for peer uniqueness).

Tr4) セッション識別子(例えばIDが同輩のユニークさにUDPソース港かソースIPアドレスを使用しないIPsec SA組に写像したL2TPセッション)としてソースIPとソース港を使用しないように、本国行きの、そして、外国行きのIPsec SAの上側の層のプロトコル認識を実行してください。

   Tr5) Implement application integration with IKE initiation so that it
   can rebind to a different source port if the IKE quick mode SA
   proposal is rejected by the responder; then it can repropose the new
   QM selector.

Tr5) IKEの迅速なモードSA提案が応答者によって拒絶されるなら異なったソースにポートを縛り直すことができるように、IKE開始と共にアプリケーション統合を実行してください。 そして、それは新しいQMセレクタを再提案できます。

   Limited interoperability choices for ESP tunnel mode:

超能力のための株式会社相互運用性選択はモードにトンネルを堀ります:

   Tn4) Same as Tr4.

Tn4) Tr4と同じです。

Huttunen, et al.            Standards Track                    [Page 13]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[13ページ]。

Authors' Addresses

作者のアドレス

   Ari Huttunen
   F-Secure Corporation
   Tammasaarenkatu 7
   HELSINKI  FIN-00181
   FI

アリのHuttunenのF安全な社のTammasaarenkatu7ヘルシンキフィン-00181FI

   EMail: Ari.Huttunen@F-Secure.com

メール: Ari.Huttunen@F-Secure.com

   Brian Swander
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   US

ブライアンSwanderマイクロソフト1マイクロソフト、道のワシントン98052レッドモンド(米国)

   EMail: briansw@microsoft.com

メール: briansw@microsoft.com

   Victor Volpe
   Cisco Systems
   124 Grove Street
   Suite 205
   Franklin, MA  02038
   US

ビクタボルペシスコシステムズ124木立通りSuite205MA02038フランクリン(米国)

   EMail: vvolpe@cisco.com

メール: vvolpe@cisco.com

   Larry DiBurro
   Nortel Networks
   80 Central Street
   Boxborough, MA  01719
   US

ラリーDiBurroノーテルは米国で80セントラル・ストリートBoxborough、MA 01719をネットワークでつなぎます。

   EMail: ldiburro@nortelnetworks.com

メール: ldiburro@nortelnetworks.com

   Markus Stenberg
   FI

マーカスStenberg FI

   EMail: markus.stenberg@iki.fi

メール: markus.stenberg@iki.fi

Huttunen, et al.            Standards Track                    [Page 14]

RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[14ページ]。

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 IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Huttunen, et al.            Standards Track                    [Page 15]

Huttunen、他 標準化過程[15ページ]

一覧

 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 

スポンサーリンク

telnetの反応がなくなった時に接続を強制的に切断する方法

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

上に戻る