[要約] RFC 5579は、ISATAPインターフェースを介してIPv4パケットを転送するための仕様です。このRFCの目的は、ISATAPを使用してIPv4ネットワーク間で通信を可能にすることです。
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-in-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エディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、RFC 3932を参照してください。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
自動IPv6-in-IPv4エンコーシングを使用してIPv4ネットワーク上のIPv6パケットを送信するために、敷地内自動トンネルアドレス指定プロトコル（ISATAP）[RFC5214]は、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-in-IPV4カプセル化を実行します。ISATAPインターフェイスは、[RFC5214]のセクション6および7で指定されているように、IPv6 Link-Localプレフィックス "Fe80 ::/10"内のIPv6 Link-Localプレフィックス "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-in-IPV4カプセル化と同じ方法でISATAPインターフェイス上の自動IPv4-in-IPV4カプセル化を可能にするメカニズムと運用慣行を指定します。その結果、このドキュメントは[RFC2003]で指定されたIPv4-in-IPV4トンネルメカニズムも拡張します。これらのメカニズムは、レンジャー[レンジャー]および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-in-IPV4カプセル化[RFC2003]、およびIPv6-in-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]に記載されているように解釈される場合は、キーワードが[RFC2119]に記載されているように解釈される場合に、このドキュメントに表示される場合、必要であってはなりません。
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-in-IPV4カプセル化を使用して、単一のIPv6ホップで接続されたIPv4ルーティングトポロジ（つまり、「サイト」）内の領域に及ぶ。つまり、サイトは、単一のIPv6ホップでサイト全体にIPv6-in-IPV4パケットを転送するISATAPインターフェイスを備えた境界ノードと、外側のライブ（TTL）を減らす境界ノード間の通常の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インターフェイスの1つ以上で構成されています。これらの基礎となるIPv4インターフェイスは、サイトまたはより大きなスコープ付きIPv4アドレスを構成し、2つの「隣接する」ISATAPインターフェイスの基礎となるIPv4インターフェイスは、サイト内の多くの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.
この仕様は、ISATAPインターフェイスモデルを拡張して、IPv4-in-IPV4カプセル化もサポートするだけです。IPv4-in-IPV4カプセル化が使用されると、ISATAPインターフェイスは、IPv6-in-IPV4カプセル化とまったく同じ基礎となるサイトに及びます。
ISATAP interface MTU considerations are exactly as specified in Section 3.2 of [RFC4213] and apply equally for both IPv6 and IPv4 operation.
ISATAPインターフェイスMTUの考慮事項は、[RFC4213]のセクション3.2で指定されたとおりであり、IPv6操作とIPv4操作の両方に等しく適用されます。
IPv6 operations over ISATAP interfaces are exactly as specified in [RFC5214].
ISATAPインターフェイスを介したIPv6操作は、[RFC5214]で正確に指定されています。
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エントリのNext-Hopアドレスは、Neightの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レイヤーに送信するパケットがある場合、IPv4 FIBルックアップを実行して、発信ISATAPインターフェイスとNext-Hop L3ADDRを決定します。次に、ノードは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ヘッダーの「Do n't Fragment（DF）」フラグを調べます。DF = 1の場合、パケットをドロップし、ICMPV4「断片化が必要な」メッセージを元のソース[RFC1191]に返します。それ以外の場合、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が発見された後、ノードはIPv4パケット/フラグメントをISATAPインターフェイスに認め、次のホップL3ADDRを次のホップレイヤー2アドレス（「L2ADDR」）にマッピングします。多くの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, etc.
IPv4のアドレスマッピングは、L3ADDRとL2ADDRの間のアルゴリズムマッピングが不可能ではないという点で、IPv6バージョンとは異なります。したがって、IPv4のISATAPには、サイト内のすべてのノードが同じ規則に従うように、敷地ごとに調整されるL3ADDR-> L2ADDRアドレスマッピングメソッドが必要です。例には、名前サービスの検索（[vet]で説明されているように）、静的マッピングテーブルルックアップなどが含まれます。
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.
次にノードは、Next-Hop L2ADDRでIPv4 FIBルックアップを実行して、正しい基礎となるIPv4インターフェイスを決定します。FIBルックアップが失敗した場合、ノードはパケットをドロップし、ICMPV4 "宛先の到達不可能な"メッセージを元のソース[RFC0792]に返します。それ以外の場合、パケットをカプセル化し、以下に説明するように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).
Next-Hop L2ADDRでIPv4 FIBルックアップを実行した後、ノードは[RFC2003]で指定されているパケットをカプセル化します。。ノードは、[RFC4213]のセクション3.2に従って、外側IPv4ヘッダーにDFフラグを設定します。ノードは、外側IPv4ヘッダーのIPプロトコルフィールドを4（つまり、IP-Protocol-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宛先アドレス（つまり、Next-Hop 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は単に「6OVOR4」[RFC2529]のユニキャストのみの派生物です。ただし、さまざまな理由で、ISATAPは実用的な広範な展開を見てきましたが、6over4アプローチは進行中の研究努力を通じて静かに進められています。この仕様は、ISATAPインターフェイスモデルを拡張して、IPv4マルチキャストマッピングをサポートし、6Over4でIPv6マルチキャストマッピングに正確に平行します（[RFC2529]、セクション6を参照）。確かに、「ISatap」という名前が広く公開されている用語にすでに染み込んでいるという事実がない場合、このアプローチは「4over4」と呼ばれるかもしれません。
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インターフェイスでのみ使用できます。このようなサイトの場合、マルチキャスト宛先アドレスを持つ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.
拡張ブロックを使用して形成されると、A /16サイズのブロックのみを使用することに注意してください。
+-------+-------+-------+-------+
| 239 | OLS | DST2 | DST3 |
+-------+-------+-------+-------+
DST2, DST3 Last two bytes of IPv4 multicast address.
DST2、DST3 IPv4マルチキャストアドレスの最後の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]および6OVOR4 [RFC2529]で指定されたセキュリティ上の考慮事項も適用されます。
Updated tunnel security considerations are found in [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インターフェイスモデルを拡張しています。Brian CarpenterとJari Arkkoに役立つレビュー入力に感謝します。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、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] Carpenter、B。およびC. Jung、「明示的なトンネルなしの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] Cheshire、S.、Aboba、B。、およびE. Guttman、「IPv4 Link-Localアドレスの動的構成」、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. Gilligan、「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] Templin、F.、Gleeson、T。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（ISATAP）」、RFC 5214、2008年3月。
[SECURITY] Hoagland, J., Krishnan, S., and D. Thaler, "Security Concerns With IP Tunneling", Work in Progress, October 2008.
[セキュリティ] Hoagland、J.、Krishnan、S。、およびD. Thaler、「IPトンネリングに関するセキュリティ上の懸念」、2008年10月の作業。
[VET] Templin, F., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010.
[Vet] Templin、F。、「仮想エンタープライズトラバーサル（VET）」、RFC 5558、2010年2月。
[RANGER] Templin, F., "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", RFC 5720, February 2010.
[Ranger] Templin、F。、「グローバルエンタープライズリクルーション（レンジャー）を備えたネットワークでのルーティングとアドレス指定」、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] Meyer、D。、「管理上スコープIPマルチキャスト」、BCP 23、RFC 2365、1998年7月。
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近隣のL3ADDRとL2ADDRが基礎となるサイト内でルーティング可能であることが知られているサイトでISATAPインターフェイスを構成することができます。その場合、ISATAPインターフェイスはカプセル化を避け、非カプセル化されたパケットをIPv4レイヤーに直接送信する場合があります。ただし、このアプローチは、カプセル化を通じて得られる間接の使用を提供しないことに注意してください。
Author's Address
著者の連絡先
Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
フレッドL.テンプリン（編集者）ボーイングリサーチ＆テクノロジーP.O.ボックス3707 MC 7L-49シアトル、ワシントン州98124 USA
EMail: fltemplin@acm.org