Independent Submission F. Templin, Ed.
Request for Comments: 5579 Boeing Research & Technology
Category: Informational February 2010
ISSN: 2070-1721
Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces
サイト内の自動トンネル上でのIPv4パケットの送信は、プロトコル（ISATAP）インタフェースへの対応します
Abstract
抽象
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces.
イントラサイト自動トンネルアドレス指定プロトコル（ISATAP）は、自動IPv6の型のIPv4カプセル化を使用してIPv4ネットワーク上のIPv6パケットの送信のために非放送、多重アクセス（NBMA）インターフェイスタイプを指定します。元の仕様が、IPv4パケットのカプセル化と伝送のための規定をしません。この文書では、ISATAPインターフェイス上のIPv4パケットを送信する方法を指定します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5579.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5579で取得することができます。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. ISATAP Interface Model ..........................................3
4. ISATAP Interface MTU ............................................4
5. IPv6 Operation ..................................................4
6. IPv4 Operation ..................................................4
6.1. ISATAP IPv4 Address Configuration ..........................4
6.2. IPv4 Route Configuration ...................................5
6.3. ISATAP Interface Determination .............................5
6.4. Next-Hop Resolution ........................................5
6.5. Encapsulation and Transmission .............................6
6.6. IPv4 Multicast Mapping .....................................6
6.7. Recursive Encapsulation Avoidance ..........................7
7. Security Considerations .........................................7
8. Acknowledgements ................................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................8
Appendix A. Encapsulation Avoidance ................................9
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. ISATAP interfaces therefore typically configure IPv6 addresses and prefixes, but they do not configure IPv4 addresses and prefixes. In typical implementations and deployments, an ISATAP interface therefore appears as an ordinary interface configured for IPv6 operation but with a null IPv4 configuration. This places an unnecessary limitation on the ISATAP domain of applicability.
イントラサイト自動トンネルプロトコル（ISATAP）[RFC5214]をアドレッシング自動IPv6の型のIPv4カプセル化を使用してIPv4ネットワーク上のIPv6パケットの送信のために非放送、多重アクセス（NBMA）インターフェイスタイプを指定します。 ISATAPインターフェイスは、したがって、一般的にIPv6アドレスとプレフィックスを設定するが、彼らは、IPv4アドレスとプレフィックスを設定しないでください。典型的な実装と展開では、ISATAPインタフェースは、したがって、IPv6の動作のためではなくヌルのIPv4構成で構成され、通常のインターフェイスとして現れます。これは、適用のISATAPドメイン上の不要な制限を課します。
ISATAP interfaces perform automatic IPv6-in-IPv4 encapsulation over a virtual IPv6 overlay that spans a region within a connected IPv4 routing topology (i.e., a "site") comprising ordinary IPv4 routers. ISATAP interfaces configure IPv6 link-local addresses that encapsulate an IPv4 address assigned to an underlying IPv4 interface within the IPv6 link-local prefix "fe80::/10", as specified in Sections 6 and 7 of [RFC5214]. ISATAP interfaces may additionally configure IPv6 addresses from a non-link-local IPv6 prefix in exactly the same fashion. As a result, [RFC5214] extends the basic transition mechanisms specified in [RFC4213].
ISATAPインターフェイスは、通常のIPv4ルーターを含む接続されたIPv4ルーティングトポロジー（すなわち、「サイト」）内の領域にまたがる仮想IPv6オーバーレイ上のIPv6自動型のIPv4カプセル化を行います。 [RFC5214]のセクション6及び7で指定されISATAPインタフェースは、IPv6リンクローカル接頭辞「FE80 :: / 10」内の基礎となるIPv4インタフェースに割り当てられたIPv4アドレスをカプセル化IPv6リンクローカルアドレスを設定します。 ISATAPインターフェイスは、さらに正確に同じ様式で、非リンクローカルIPv6プレフィックスからIPv6アドレスを構成することができます。結果として、[RFC5214]は[RFC4213]で指定された基本的な移行メカニズムを拡張します。
This document specifies mechanisms and operational practices that enable automatic IPv4-in-IPv4 encapsulation over ISATAP interfaces in the same manner as for IPv6-in-IPv4 encapsulation. As a result, this document also extends the IPv4-in-IPv4 tunneling mechanisms specified in [RFC2003]. These mechanisms are useful in a wide variety of enterprise network scenarios, e.g., as discussed in the RANGER [RANGER] and VET [VET] proposals.
この文書は、IPv6インのIPv4カプセル化と同様にISATAPインターフェイス上のIPv4自動型のIPv4カプセル化を可能メカニズムと運用プラクティスを特定します。結果として、この文書はまた、[RFC2003]で指定されたIPv4型のIPv4トンネリングメカニズムを拡張します。これらの機構は、レンジャー[RANGER]およびVET [VET]提案で議論するように、例えば、企業ネットワークシナリオの広範囲に有用です。
The following sections specify IPv4 operation over ISATAP interfaces. A working knowledge of the IPv4 and IPv6 protocols ([RFC0791] and [RFC2460]), IPv4-in-IPv4 encapsulation [RFC2003], and IPv6-in-IPv4 encapsulation ([RFC4213] and [RFC5214]) is assumed.
以下のセクションでは、ISATAPインターフェイス上のIPv4の動作を指定します。 IPv4とIPv6プロトコルの知識（[RFC0791]及び[RFC2460]）、IPv4の型のIPv4カプセル化[RFC2003]、およびIPv6型のIPv4カプセル化（[RFC4213]及び[RFC5214]）を想定しています。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
彼らは、この文書に表示される[RFC2119]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
ISATAP interfaces use automatic IPv6-in-IPv4 encapsulation to span a region within a connected IPv4 routing topology (i.e., a "site") in a single IPv6 hop. That is to say that the site comprises border nodes with ISATAP interfaces that forward IPv6-in-IPv4 packets across the site in a single IPv6 hop, and ordinary IPv4 routers between the border nodes that decrement the Time to Live (TTL) in the outer IPv4 header. Border nodes that configure ISATAP interfaces within the same site therefore see each other as single-hop neighbors.
ISATAPインターフェイスは、単一のIPv6のホップで接続されたIPv4ルーティングトポロジ（すなわち、「サイト」）内の領域にまたがるように、自動IPv6の型のIPv4カプセル化を使用します。すなわち、サイトが外側に（TTL）生存時間を減少ボーダーノード間の単一のIPv6ホップでサイト全体のIPv6型のIPv4パケットを転送ISATAPインタフェースとの境界ノード、及び通常のIPv4ルータを含むということですIPv4ヘッダ。同じサイト内のISATAPインターフェイスを設定する境界ノードは、従って、単一ホップ隣人として互いに参照します。
ISATAP interfaces are configured over one or more of the node's underlying IPv4 interfaces connected to the site. These underlying IPv4 interfaces configure site- or greater-scoped IPv4 addresses, and the underlying IPv4 interfaces of two "neighboring" ISATAP interfaces may be separated by many IPv4 hops within the site.
ISATAPインターフェイスは、サイトに接続されたノードの基礎となるIPv4インタフェースの一つ以上の上に構成されています。これら基礎となるIPv4インタフェースは、部位特異的またはより大きなスコープのIPv4アドレスを設定し、多くのIPv4サイト内でホップすることにより、2つの「隣接」ISATAPインタフェースの基礎となるIPv4インタフェースを分離することができます。
This specification simply extends the ISATAP interface model to also support IPv4-in-IPv4 encapsulation. When IPv4-in-IPv4 encapsulation is used, the ISATAP interface spans exactly the same underlying site as for IPv6-in-IPv4 encapsulation.
この仕様は、単にもIPv4の型のIPv4カプセル化をサポートするためにISATAPインタフェースモデルを拡張します。 IPv4のイン・IPv4のカプセル化を使用する場合は、ISATAPインターフェイスは、IPv6インIPv4のカプセル化とまったく同様の基本的なサイトにまたがります。
ISATAP interface MTU considerations are exactly as specified in Section 3.2 of [RFC4213] and apply equally for both IPv6 and IPv4 operation.
[RFC4213]のセクション3.2で指定されたIPv6とIPv4の動作の両方に等しく適用されるISATAPインタフェースMTUの考慮事項は、正確です。
IPv6 operations over ISATAP interfaces are exactly as specified in [RFC5214].
[RFC5214]で指定されるようにISATAPインターフェイス上のIPv6操作が正確です。
The following sections specify IPv4 operation over ISATAP interfaces:
以下のセクションでは、ISATAPインターフェイス上のIPv4の動作を指定します。
As for IPv6 operation, IPv4 operation requires that all ISATAP interfaces connected to the same site configure a unique Layer 3 IPv4 address ("L3ADDR") taken from an IPv4 prefix for the site. L3ADDR is used for next-hop determination, but it may also be used as the source address for packets that originate from the ISATAP interface itself.
IPv6の動作用として、IPv4の動作は同じサイトに接続されているすべてのISATAPインターフェイスがサイトのIPv4接頭辞から採取された一意のレイヤ3 IPv4アドレス（「L3ADDR」）を設定する必要があります。 L3ADDRは、ネクストホップ決意のために使用されるが、それはまた、ISATAPインタフェース自体から発信パケットの送信元アドレスとして使用してもよいです。
When a unique "name" for the ISATAP site is required (e.g., to distinguish it from other ISATAP sites), L3ADDR is taken from a public IPv4 prefix. Otherwise, it may be taken from a link-local-scoped IPv4 prefix (e.g., 169.254/16 [RFC3927]).
ISATAPサイトの一意の「名前」を必要とする場合（例えば、他のISATAPサイトからそれを区別するために）、L3ADDRはパブリックIPv4プレフィックスから取得されます。それ以外の場合は、リンクローカルスコープのIPv4プレフィックス（例えば、169.254 / 16 [RFC3927]）から採取されてもよいです。
Methods for ensuring L3ADDR uniqueness include dynamic allocation using DHCP [RFC2131], manual configuration, etc.
L3ADDRの一意性を確保するための方法は、DHCPを使用して動的割当て[RFC2131]、手動設定、等を含みます
As for any IPv4 interface, IPv4 Forwarding Information Base (FIB) entries (i.e., IPv4 routes) are configured over ISATAP interfaces via either administrative or dynamic mechanisms.
任意のIPv4インタフェースと、IPv4の転送情報ベース（FIB）のエントリ（すなわち、IPv4ルート）は、管理者または動的機構を介してISATAPインターフェイス上に構成されています。
Next-hop addresses in FIB entries configured over an ISATAP interface correspond to the L3ADDR assigned to the ISATAP interface of a neighbor.
ISATAPインタフェースを介して構成されたFIBエントリの次ホップアドレスは、ネイバーのISATAPインターフェイスに割り当てられL3ADDRに対応します。
When the node's IPv4 layer has a packet to send, it performs an IPv4 FIB lookup to determine the outgoing ISATAP interface and the next-hop L3ADDR. The node then checks the packet length against the MTU configured on the ISATAP interface.
ノードのIPv4層が送信するパケットを有する場合、それは発信ISATAPインターフェイスとネクストホップL3ADDRを決定するためのIPv4 FIBルックアップを行います。ノードは、ISATAPインターフェイスに設定MTUに対してパケット長をチェックします。
If the packet is no larger than the MTU, the node admits it into the ISATAP interface without fragmentation. If the packet is larger than the MTU, the node examines the "Don't Fragment (DF)" flag in the IPv4 header. If DF=1, it drops the packet and returns an ICMPv4 "fragmentation needed" message to the original source [RFC1191]; otherwise, it fragments the packet using IPv4 fragmentation and admits each fragment into the ISATAP interface.
パケットがMTUよりも大きくない場合、ノードは、断片化なしでISATAPインタフェースにそれを認めています。パケットがMTUよりも大きい場合、ノードは、IPv4ヘッダ内の「フラグメントない（DF）」フラグを調べます。 DF = 1の場合は、パケットをドロップし、元のソースメッセージ[RFC1191] ICMPv4の「必要フラグメンテーション」を返します。それ以外の場合は、IPv4の断片を使用してパケットを断片化し、ISATAPインターフェイスに各フラグメントを認めます。
As for ISATAP for IPv6, ISATAP for IPv4 requires a means for determining the L3ADDR of neighbors on the ISATAP interface that can provide a next-hop toward the final destination. Next-hop determination for default routes is through the Potential Router List (PRL) discovery procedures specified in Section 8.3.2 of [RFC5214]. Next-hop determination methods for more-specific routes include forwarding initial packets via a default router until a redirect is received, name service lookup (e.g., as described in [VET]), etc.
IPv6のISATAPとしては、IPv4のISATAPは、最終的な宛先に向かう次のホップを提供することができるISATAPインターフェイス上のネイバーのL3ADDRを決定するための手段が必要となります。デフォルトルートのネクストホップ決意は、[RFC5214]のセクション8.3.2で指定された潜在的なルータリスト（PRL）発見手順によるものです。より具体的なルートのネクストホップ決意方法は、リダイレクトを受信するまで、デフォルトのルータを介して等ネームサービスの検索（例えば、[VET]に記載されているように）、初期パケットを転送含みます
After a next-hop L3ADDR is discovered, the node admits IPv4 packets/fragments into the ISATAP interface and maps the next-hop L3ADDR into a next-hop Layer 2 address ("L2ADDR"), which in reality is the IPv4 address of an underlying interface of the ISATAP neighbor that may be many IPv4 hops away.
ネクストホップL3ADDRが発見された後、ノードは、ISATAPインターフェイスにIPv4パケット/フラグメントを許可し、実際にはのIPv4アドレスであるネクストホップのレイヤ2アドレス（「L2ADDR」）にネクストホップL3ADDRをマッピング多くのIPv4のかもしれISATAP隣人の基本的なインタフェースは、ホップ離れ。
Address mapping for IPv4 differs from the IPv6 version in that no algorithmic mapping between L3ADDR and L2ADDR is possible. ISATAP for IPv4 therefore requires an L3ADDR->L2ADDR address mapping method that is coordinated on a per-site basis such that all nodes in the site follow the same convention. Examples include name service lookup (e.g., as described in [VET]), static mapping table lookup,
IPv4のアドレスマッピングはL3ADDRとL2ADDRの間にアルゴリズムマッピングが不可能であるという点で、IPv6のバージョンと異なります。 IPv4のISATAPは、したがって、サイト内のすべてのノードが同じ規則に従うよう、サイトごとに配位しているL3ADDR-> L2ADDRアドレスマッピング方法を必要とします。例としては、ネームサービスの検索を含む（例えば、[VET]に記載されているように）、静的マッピングテーブルルックアップ、
etc.
等
The node next performs an IPv4 FIB lookup on the next-hop L2ADDR to determine the correct underlying IPv4 interface. If the FIB lookup fails, the node drops the packet and returns an ICMPv4 "Destination Unreachable" message to the original source [RFC0792]; otherwise, it encapsulates the packet and submits it to the IPv4 layer as described below.
ノードは、次の正しい基礎となるIPv4インタフェースを決定するために、次ホップL2ADDRでIPv4 FIBルックアップを行います。 FIBルックアップが失敗した場合、ノードはパケットをドロップし、元のソース[RFC0792]にICMPv4の「宛先到達不能」メッセージを返します。それ以外の場合は、パケットをカプセル化し、以下に説明するようにIPv4の層にそれを提出します。
After performing the IPv4 FIB lookup on the next-hop L2ADDR, the node encapsulates the packet as specified in [RFC2003] with the IPv4 address of the underlying interface as the outer IPv4 source address and the next-hop L2ADDR as the outer IPv4 destination address. The node sets the DF flag in the outer IPv4 header according to Section 3.2 of [RFC4213]. The node also sets the IP protocol field in the outer IPv4 header to 4 (i.e., ip-protocol-4).
[RFC2003]で指定されたネクストホップL2ADDRでIPv4 FIBルックアップを実行した後、ノードは、外側のIPv4宛先アドレスとして、外側のIPv4ソースアドレスとして、基礎となるインタフェースとネクストホップL2ADDRのIPv4アドレスを持つパケットをカプセル化します。ノードは、[RFC4213]のセクション3.2に従って外側IPv4ヘッダ内のDFフラグをセットします。ノードはまた、4に、外側IPv4ヘッダ内のIPプロトコルフィールドを設定する（すなわち、IPプロトコル-4）。
The node then submits the encapsulated packet to the IPv4 layer. The IPv4 layer fragments the packet if necessary, then forwards each fragment to the underlying IPv4 interface. The underlying IPv4 interface then performs address resolution on the outer IPv4 destination address (i.e., the next-hop L2ADDR) and submits the packet for transmission on the underlying link layer.
ノードは、IPv4の層にカプセル化されたパケットを送信します。必要に応じてIPv4の層は、下層のIPv4インタフェースを次に転送する各フラグメントパケットを断片化。基礎となるIPv4インタフェースは、次に、外側のIPv4宛先アドレス（すなわち、ネクストホップL2ADDR）上のアドレス解決を行い、下層のリンク層上での送信のためにパケットを送信します。
In many aspects, ISATAP is simply a unicast-only derivative of "6over4" [RFC2529]. For various reasons, however, ISATAP has seen practical wide-scale deployment while the 6over4 approach has been silently carried forward through ongoing research efforts. This specification extends the ISATAP interface model to support IPv4 multicast mapping in a manner that exactly parallels IPv6 multicast mapping in 6over4 (see [RFC2529], Section 6). Indeed, the approach might more aptly be named "4over4" were it not for the fact that the name "ISATAP" has already become ingrained in the widely published terminology.
多くの態様では、ISATAPは単に「6over4は」[RFC2529]のユニキャストのみの誘導体です。 6over4はアプローチが静かに進行中の研究の努力によって引き継がれているが、様々な理由から、しかし、ISATAPは、実用的な大規模な展開を見ています。この仕様は、正確に（[RFC2529]、セクション6を参照）に6over4はIPv6マルチキャストマッピングと平行なるようにIPv4マルチキャストマッピングをサポートするために、ISATAPインタフェースモデルを拡張します。実際、アプローチがより適切に「4over4」指名されるかもしれません、それは名前「ISATAP」はすでに広く公表された用語で根深いとなっているという事実のためではありませんでした。
IPv4 multicast mapping is available only on ISATAP interfaces configured over sites that support IPv4 multicast. For such sites, an IPv4 packet sent on an ISATAP interface with a multicast destination address DST MUST be encapsulated for transmission on an underlying IPv4 interface to the IPv4 multicast address of Organization-Local Scope using the mapping below. The mapped address SHOULD be taken from the block 239.193.0.0/16, a different sub-block of the Organization-Local Scope address block, or -- if none of those are available -- from the expansion blocks defined in [RFC2365].
IPv4マルチキャストマッピングは、IPv4のみマルチキャストをサポートサイト上に構成されたISATAPインターフェイスで利用可能です。このようなサイトでは、マルチキャスト宛先アドレスDSTとISATAPインターフェイス上で送信されたIPv4パケットは、以下のマッピングを使用して組織ローカルスコープのIPv4マルチキャストアドレスへの基礎となるIPv4インタフェース上の伝送のためにカプセル化されなければなりません。マッピングされたアドレスがブロック239.193.0.0/16、組織ローカルスコープアドレスブロックの異なるサブブロックから取られるべきである、または - [RFC2365]で定義された拡張ブロックから - それらのいずれも利用できない場合。
Note that when they are formed using the expansion blocks, they use only a /16-sized block.
それらは拡張ブロックを用いて形成される場合、それらは唯一/ 16サイズのブロックを使用することに留意されたいです。
+-------+-------+-------+-------+
| 239 | OLS | DST2 | DST3 |
+-------+-------+-------+-------+
DST2, DST3 Last two bytes of IPv4 multicast address.
IPv4マルチキャストアドレスのDST2、DST3最後の2バイト。
OLS From the configured Organization-Local Scope address block. SHOULD be 193; see [RFC2365] for details.
構成された組織ローカルスコープのアドレスブロックからOLS。 193である必要があります。詳細については、[RFC2365]を参照してください。
Figure 1: ISATAPv4 Multicast Mapping
図1：ISATAPv4マルチキャストマッピング
No new IANA registration procedures are required for the above.
新しいIANA登録手順は、上記のために必要ありません。
The node must take care in managing its IPv4 FIB table entries in order to avoid looping through recursive encapsulations.
ノードは、再帰的なカプセル化をループを回避するために、そのIPv4のFIBテーブルエントリの管理に注意を払う必要があります。
The security considerations specified in [RFC2003] apply equally to this document. The security considerations specified in ISATAP [RFC5214] and 6over4 [RFC2529] also apply, with the exception that ip-protocol-4 encapsulation is used instead of ip-protocol-41.
[RFC2003]で指定されたセキュリティ上の考慮事項は、この文書にも同様に適用されます。 ISATAP [RFC5214]と6over4は[RFC2529]で指定されたセキュリティ上の考慮事項は、IPプロトコル-4カプセル化の代わりに、IPプロトコル41を用いていることを除いて、適用します。
Updated tunnel security considerations are found in [SECURITY].
更新されたトンネルのセキュリティの考慮事項は、[SECURITY]で発見されています。
This work extends the ISATAP interface model, which has evolved through the insights of many contributers over the course of many decades. Special thanks to Brian Carpenter and Jari Arkko for their helpful review input.
この作品は、数十年にわたって多くの貢献者の洞察を経て発展してきたISATAPインターフェイスモデルを拡張します。彼らの役に立つレビュー入力のためのブライアン・カーペンターとヤリArkkoに感謝します。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529]カーペンター、B.及びC.チョン、 "明示的なトンネルなしでのIPv4ドメイン上のIPv6の送信"、RFC 2529、1999年3月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]チェシャー、S.、Aboba、B.、およびE.ガットマン、 "IPv4のリンクローカルアドレスの動的構成"、RFC 3927、2005年5月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]テンプリン、F.、グリーソン、T.、およびD.ターラーは、 "イントラサイト自動トンネルは、プロトコル（ISATAP）をアドレス指定"、RFC 5214、2008年3月。
[SECURITY] Hoagland, J., Krishnan, S., and D. Thaler, "Security Concerns With IP Tunneling", Work in Progress, October 2008.
[SECURITY]ホーグランド、J.、クリシュナン、S.、およびD.ターラー、 "IPトンネリングとセキュリティの懸念"、進歩、2008年10月での作業。
[VET] Templin, F., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010.
[VET]テンプリン、F.、 "仮想エンタープライズトラバーサル（VET）"、RFC 5558、2010年2月。
[RANGER] Templin, F., "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", RFC 5720, February 2010.
[RANGER]テンプリン、F.、 "ルーティングとグローバル企業再帰（RANGER）とのネットワークにおけるアドレス指定"、RFC 5720、2010年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]マイヤー、D.、 "管理スコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。
Appendix A. Encapsulation Avoidance
付録A.カプセル化の回避
In some instances, an ISATAP interface may be configured over a site in which the L3ADDRs and L2ADDRs of all ISATAP neighbors are also known to be routable within the underlying site. In that case, the ISATAP interface MAY avoid encapsulation and submit the unencapsulated packets directly to the IPv4 layer. Note however that this approach does not provide for the use of indirection afforded through encapsulation.
いくつかの例では、ISATAPインターフェイスは、すべてのISATAPネイバーのL3ADDRsとL2ADDRsも根底にあるサイト内ルーティング可能であることが知られているサイト上に構成されてもよいです。その場合には、ISATAPインターフェイスは、カプセル化を回避することができるし、IPv4層に直接カプセル化されていないパケットを送信してください。このアプローチは、カプセル化によってもたらされる間接の使用を提供していないことに注意してください。
Author's Address
著者のアドレス
Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
フレッド・L.テンプリン（エディタ）ボーイング・リサーチ＆テクノロジー私書箱ボックス3707 MC 7L-49シアトル、WA 98124 USA
EMail: fltemplin@acm.org
メールアドレス：fltemplin@acm.org