[要約] RFC 6964は、IPv4サイトでのIPv6展開におけるISATAPの使用に関する操作ガイダンスです。ISATAPを使用してIPv6を展開するための手順とベストプラクティスを提供します。
Independent Submission F. Templin
Request for Comments: 6964 Boeing Research & Technology
Category: Informational May 2013
ISSN: 2070-1721
Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
サイト内自動トンネルアドレス指定プロトコル（ISATAP）を使用したIPv4サイトでのIPv6展開の運用ガイダンス
Abstract
概要
Many end-user sites in the Internet today still have predominantly IPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 provides satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed, however, end-user devices within such sites will increasingly require at least basic IPv6 functionality. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).
今日のインターネットの多くのエンドユーザーサイトには、依然としてIPv4内部インフラストラクチャが圧倒的に多く残っています。これらのサイトのサイズは、小規模なホーム/オフィスネットワークから大企業のエンタープライズネットワークまでさまざまですが、ほとんどのアプリケーションにIPv4が満足のいく内部ルーティングとアドレッシングサービスを提供するという共通点を共有しています。ただし、IPv6のみのサービスが展開されるにつれて、そのようなサイト内のエンドユーザーデバイスには、少なくとも基本的なIPv6機能がますます必要になります。したがって、このドキュメントでは、サイト内自動トンネルアドレスプロトコル（ISATAP）を使用して、主にIPv4サイト内にIPv6を展開するための運用ガイダンスを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc6964.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6964で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Enabling IPv6 Services Using ISATAP . . . . . . . . . . . . . 4
3. SLAAC Services . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Advertising ISATAP Router Behavior . . . . . . . . . . . 5
3.2. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . 6
3.3. Reference Operational Scenario - Shared Prefix Model . . 6
3.4. Reference Operational Scenario - Individual Prefix Model 9
3.5. SLAAC Site Administration Guidance . . . . . . . . . . . 12
3.6. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . 14
3.7. Considerations for Compatibility of Interface Identifiers 14
4. Manual Configuration . . . . . . . . . . . . . . . . . . . . 15
5. Scaling Considerations . . . . . . . . . . . . . . . . . . . 15
6. Site Renumbering Considerations . . . . . . . . . . . . . . . 16
7. Path MTU Considerations . . . . . . . . . . . . . . . . . . . 16
8. Alternative Approaches . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 18
End-user sites in the Internet today internally use IPv4 routing and addressing for core operating functions, such as web browsing, file sharing, network printing, email, teleconferencing, and numerous other site-internal networking services. Such sites typically have an abundance of public and/or private IPv4 addresses for internal networking and are separated from the public Internet by firewalls, packet filtering gateways, proxies, address translators, and other site-border demarcation devices. To date, such sites have had little incentive to enable IPv6 services internally [RFC1687].
今日のインターネットのエンドユーザーサイトは、内部でIPv4ルーティングとアドレッシングを使用して、Webブラウジング、ファイル共有、ネットワーク印刷、電子メール、電話会議、その他の多数のサイト内部ネットワークサービスなどのコア操作機能を提供しています。このようなサイトには通常、内部ネットワーク用に豊富なパブリックおよび/またはプライベートIPv4アドレスがあり、ファイアウォール、パケットフィルタリングゲートウェイ、プロキシ、アドレストランスレータ、およびその他のサイト境界境界デバイスによってパブリックインターネットから分離されています。現在まで、そのようなサイトは内部でIPv6サービスを有効にする動機がほとんどありませんでした[RFC1687]。
End-user sites that currently use IPv4 services internally come in endless sizes and varieties. For example, a home network behind a Network Address Translator (NAT) may consist of a single link supporting a few laptops, printers, etc. As a larger example, a small business may consist of one or a few offices with several networks connecting considerably larger numbers of computers, routers, handheld devices, printers, faxes, etc. Moving further up the scale, large financial institutions, major retailers, large corporations, etc., may consist of hundreds or thousands of branches worldwide that are tied together in a complex global enterprise network. Additional examples include personal-area networks, mobile vehicular networks, disaster relief networks, tactical military networks, various forms of Mobile Ad Hoc Networks (MANETs), etc.
現在IPv4サービスを使用しているエンドユーザーサイトには、無限のサイズと種類があります。たとえば、ネットワークアドレストランスレータ（NAT）の背後にあるホームネットワークは、いくつかのラップトップ、プリンタなどをサポートする単一のリンクで構成される場合があります。より大きな例として、中小企業は、いくつかのネットワークがかなり接続している1つまたはいくつかのオフィスで構成される場合があります。多数のコンピュータ、ルーター、ハンドヘルドデバイス、プリンター、ファクスなど。大規模な金融機関、大手小売業者、大企業などは、世界中で数百または数千の支店で構成され、複雑なグローバル企業ネットワーク。その他の例には、パーソナルエリアネットワーク、モバイル車両ネットワーク、災害救援ネットワーク、戦術軍事ネットワーク、さまざまな形態のモバイルアドホックネットワーク（MANET）などがあります。
With the proliferation of IPv6 services, however, existing IPv4 sites will increasingly require a means for enabling IPv6 services so that hosts within the site can communicate with IPv6-only correspondents. Such services must be deployable with minimal configuration and in a fashion that will not cause disruptions to existing IPv4 services. The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] provides a simple-to-use service that sites can deploy in the near term to meet these requirements.
ただし、IPv6サービスの急増に伴い、既存のIPv4サイトでは、サイト内のホストがIPv6のみの通信相手と通信できるように、IPv6サービスを有効にする手段がますます必要になります。このようなサービスは、最小限の構成で、既存のIPv4サービスを中断させない方法で展開できる必要があります。サイト内自動トンネルアドレスプロトコル（ISATAP）[RFC5214]は、サイトがこれらの要件を満たすために短期間に導入できる、使いやすいサービスを提供します。
ISATAP has also often been mentioned with respect to IPv6 deployment in enterprise networks [RFC4057] [RFC4852] [ENT-IPv6]. ISATAP can therefore be considered as an IPv6 solution alternative based on candidate enterprise network characteristics.
ISATAPは、エンタープライズネットワークでのIPv6の展開に関してもしばしば言及されています[RFC4057] [RFC4852] [ENT-IPv6]。したがって、ISATAPは、候補のエンタープライズネットワーク特性に基づくIPv6ソリューションの代替案と見なすことができます。
This document provides operational guidance for using ISATAP to enable IPv6 services within predominantly IPv4 sites while causing no disruptions to existing IPv4 services. The terminology of ISATAP (see [RFC5214], Section 3) applies also to this document.
このドキュメントでは、ISATAPを使用して、主にIPv4サイト内でIPv6サービスを有効にしながら、既存のIPv4サービスを中断させないための運用ガイダンスを提供します。 ISATAPの用語（[RFC5214]、セクション3を参照）は、このドキュメントにも適用されます。
Existing sites within the Internet will soon need to enable IPv6 services. Larger sites typically obtain provider-independent IPv6 prefixes from an Internet registry and advertise the prefixes into the IPv6 routing system on their own behalf, i.e., they act as an Internet Service Provider (ISP) unto themselves. Smaller sites that wish to enable IPv6 can arrange to obtain public IPv6 prefixes from an ISP, where the prefixes may be either purely native or the near-native prefixes offered by the IPv6 Rapid Deployment on IPv4 (6rd) [RFC5969]. Alternatively, the site can obtain prefixes independently of an ISP, e.g., via a tunnel broker [RFC3053], by using one of its public IPv4 addresses to form a 6to4 prefix [RFC3056], etc. In any case, after obtaining IPv6 prefixes, the site can automatically enable IPv6 services internally by configuring ISATAP.
インターネット内の既存のサイトでは、すぐにIPv6サービスを有効にする必要があります。大規模なサイトは通常、インターネットレジストリからプロバイダーに依存しないIPv6プレフィックスを取得し、プレフィックスを自分に代わってIPv6ルーティングシステムにアドバタイズします。つまり、サイト自体はインターネットサービスプロバイダー（ISP）として機能します。 IPv6を有効にしたい小規模なサイトは、ISPからパブリックIPv6プレフィックスを取得するように調整できます。プレフィックスは、純粋にネイティブか、IPv4でのIPv6迅速な展開（6番目）[RFC5969]によって提供されるネイティブに近いプレフィックスのいずれかです。または、サイトは、ISPとは独立してプレフィックスを取得できます。たとえば、トンネルブローカー[RFC3053]を介して、パブリックIPv4アドレスの1つを使用して6to4プレフィックス[RFC3056]などを形成します。いずれの場合でも、IPv6プレフィックスを取得した後、サイトは、ISATAPを構成することにより、IPv6サービスを内部で自動的に有効にすることができます。
The ISATAP service uses a Non-Broadcast, Multiple Access (NBMA) tunnel virtual interface model [RFC2491] [RFC2529] based on IPv6-in-IPv4 encapsulation [RFC4213]. The encapsulation format can further use Differentiated Services (DS) [RFC2983] and Explicit Congestion Notification (ECN) [RFC3168] mapping between the inner and outer IP headers to ensure expected per-hop behavior within well-managed sites.
ISATAPサービスは、IPv6-in-IPv4カプセル化[RFC4213]に基づく非ブロードキャスト、マルチアクセス（NBMA）トンネル仮想インターフェイスモデル[RFC2491] [RFC2529]を使用します。カプセル化形式は、差別化サービス（DS）[RFC2983]および明示的輻輳通知（ECN）[RFC3168]をさらに使用して、内部IPヘッダーと外部IPヘッダー間のマッピングを行い、適切に管理されたサイト内で期待されるホップごとの動作を保証できます。
The ISATAP service is based on two node types known as advertising ISATAP routers and ISATAP hosts. (While out of scope for this document, a third node type known as non-advertising ISATAP routers is defined in [ISATAP-UPDATE].) Each node may further have multiple ISATAP interfaces (i.e., one interface for each site) and may act as an advertising ISATAP router on some of those interfaces and a simple ISATAP host on others. Hence, the node type is considered on a per-interface basis.
ISATAPサービスは、ISATAPルーターとISATAPホストのアドバタイズと呼ばれる2つのノードタイプに基づいています。 （このドキュメントの範囲外ですが、非広告ISATAPルーターと呼ばれる3番目のノードタイプは[ISATAP-UPDATE]で定義されています。）各ノードはさらに複数のISATAPインターフェイス（つまり、サイトごとに1つのインターフェイス）を持ち、これらのインターフェイスの一部ではアドバタイズISATAPルーターとして、他のインターフェイスでは単純なISATAPホストとして。したがって、ノードタイプはインターフェイスごとに考慮されます。
Advertising ISATAP routers configure their ISATAP interfaces as advertising router interfaces (see [RFC4861], Section 6.2.2). ISATAP hosts configure their ISATAP interfaces as simple host interfaces and also coordinate their autoconfiguration operations with advertising ISATAP routers. In this sense, advertising ISATAP routers are "servers" while ISATAP hosts are "clients" in the service model.
広告ISATAPルーターは、ISATAPインターフェースを広告ルーターインターフェースとして構成します（[RFC4861]、セクション6.2.2を参照）。 ISATAPホストは、ISATAPインターフェイスを単純なホストインターフェイスとして構成し、アドバタイズISATAPルーターとの自動構成操作を調整します。この意味で、ISATAPルーターのアドバタイズは「サーバー」であり、ISATAPホストはサービスモデルの「クライアント」です。
Advertising ISATAP routers arrange to add their IPv4 addresses to the site's Potential Router List (PRL) so that ISATAP clients can discover them, as discussed in Sections 8.3.2 and 9 of [RFC5214]. Alternatively, site administrators could include IPv4 anycast addresses in the PRL and assign each such address to multiple advertising ISATAP routers. In that case, IPv4 routing within the site would direct the ISATAP client to the nearest advertising ISATAP router.
[RFC5214]のセクション8.3.2および9で説明されているように、アドバタイズISATAPルーターは、IPv4アドレスをサイトのポテンシャルルーターリスト（PRL）に追加して、ISATAPクライアントがそれらを検出できるようにします。または、サイト管理者はPRLにIPv4エニーキャストアドレスを含め、そのような各アドレスを複数のアドバタイズISATAPルーターに割り当てることができます。その場合、サイト内のIPv4ルーティングは、ISATAPクライアントを最も近いアドバタイズISATAPルーターに誘導します。
After the PRL is published, ISATAP clients within the site can automatically perform unicast IPv6 Neighbor Discovery Router Solicitation (RS) / Router Advertisement (RA) exchanges with advertising ISATAP routers using IPv6-in-IPv4 encapsulation [RFC4861] [RFC5214]. In the exchange, the IPv4 source address of the RS and the destination address of the RA are an IPv4 address of the client, while the IPv4 destination address of the RS and the source address of the RA are an IPv4 address of a server found in the PRL. Similarly, the IPv6 source address of the RS is a link-local ISATAP address that embeds the client's IPv4 address, while the source address of the RA is a link-local ISATAP address that embeds the server's IPv4 address. (The destination addresses of the RS and RA may be either the neighbor's link-local ISATAP address or a link-scoped multicast address, depending on the implementation.)
PRLが公開されると、サイト内のISATAPクライアントは、IPv6-in-IPv4カプセル化[RFC4861] [RFC5214]を使用して、ユニキャストIPv6近隣探索ルーター要請（RS）/ルーターアドバタイズ（RA）交換をアドバタイズISATAPルーターと自動的に実行できます。交換では、RSのIPv4送信元アドレスとRAの宛先アドレスはクライアントのIPv4アドレスですが、RSのIPv4宛先アドレスとRAの送信元アドレスは、サーバーのIPv4アドレスです。 PRL。同様に、RSのIPv6送信元アドレスは、クライアントのIPv4アドレスを埋め込むリンクローカルISATAPアドレスですが、RAの送信元アドレスは、サーバーのIPv4アドレスを埋め込むリンクローカルISATAPアドレスです。 （RSとRAの宛先アドレスは、実装に応じて、ネイバーのリンクローカルISATAPアドレスまたはリンクスコープのマルチキャストアドレスのいずれかになります。）
Following router discovery, ISATAP clients can configure and assign IPv6 addresses and/or prefixes using Stateless Address AutoConfiguration (SLAAC) [RFC4862] [RFC5214]. While out of scope for this document, use of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is also possible, pending future updates (see [ISATAP-UPDATE]).
ルーターの検出後、ISATAPクライアントは、ステートレスアドレス自動構成（SLAAC）[RFC4862] [RFC5214]を使用して、IPv6アドレスやプレフィックスを構成して割り当てることができます。このドキュメントの範囲外ですが、IPv6の動的ホスト構成プロトコル（DHCPv6）[RFC3315]の使用も可能であり、将来の更新が保留されます（[ISATAP-UPDATE]を参照）。
Predominantly IPv4 sites can enable SLAAC services for ISATAP clients that need to communicate with IPv6 correspondents. SLAAC services are enabled using either the "shared" or "individual" prefix model. In the shared prefix model, all advertising ISATAP routers advertise a common prefix (e.g., 2001:db8::/64) to ISATAP clients within the site. In the individual prefix model, advertising ISATAP router advertise individual prefixes (e.g., 2001:db8:0:1::/64, 2001:db8:0:2::/64, 2001:db8:0:3::/64, etc.) to ISATAP clients within the site. Note that combinations of the shared and individual prefix models are also possible, in which some of the site's ISATAP routers advertise shared prefixes and others advertise individual prefixes.
主にIPv4サイトは、IPv6コレスポンデントと通信する必要があるISATAPクライアントのSLAACサービスを有効にすることができます。 SLAACサービスは、「共有」または「個別」のいずれかの接頭辞モデルを使用して有効になります。共有プレフィックスモデルでは、アドバタイズするすべてのISATAPルーターが共通のプレフィックス（2001：db8 :: / 64など）をサイト内のISATAPクライアントにアドバタイズします。個々のプレフィックスモデルでは、ISATAPルーターをアドバタイズして個々のプレフィックスをアドバタイズします（例：2001：db8：0：1 :: / 64、2001：db8：0：2 :: / 64、2001：db8：0：3 :: / 64など）をサイト内のISATAPクライアントに送信します。共有プレフィックスモデルと個別プレフィックスモデルの組み合わせも可能であり、サイトのISATAPルーターの一部が共有プレフィックスをアドバタイズし、他のルーターが個別プレフィックスをアドバタイズすることに注意してください。
The following sections discuss operational considerations for enabling ISATAP SLAAC services within predominantly IPv4 sites.
次のセクションでは、主にIPv4サイト内でISATAP SLAACサービスを有効にするための運用上の考慮事項について説明します。
Advertising ISATAP routers that support SLAAC services send RA messages in response to RS messages received on an advertising ISATAP interface. SLAAC services are enabled when advertising ISATAP routers advertise non-link-local IPv6 prefixes in the Prefix Information Options (PIOs) with the A flag set to 1 [RFC4861]. When there are multiple advertising ISATAP routers, the routers can advertise a shared IPv6 prefix or individual IPv6 prefixes.
SLAACサービスをサポートするアドバタイズISATAPルーターは、アドバタイズISATAPインターフェイスで受信したRSメッセージに応答してRAメッセージを送信します。 SLAACサービスは、Aフラグが1に設定されたプレフィックス情報オプション（PIO）で非リンクローカルIPv6プレフィックスをアドバタイズするISATAPルーターをアドバタイズするときに有効になります[RFC4861]。複数のアドバタイズISATAPルーターがある場合、ルーターは共有IPv6プレフィックスまたは個々のIPv6プレフィックスをアドバタイズできます。
ISATAP hosts resolve the PRL and send RS messages to obtain RA messages from an advertising ISATAP router. When the host receives RA messages, it uses SLAAC to configure IPv6 addresses from any advertised prefixes with the A flag set to 1 as specified in [RFC4862] and [RFC5214], then it assigns the addresses to the ISATAP interface. The host also assigns any of the advertised prefixes with the L flag set to 1 to the ISATAP interface. (Note that the IPv6 link-local prefix fe80::/64 is always considered on-link on an ISATAP interface.)
ISATAPホストはPRLを解決し、RSメッセージを送信して、アドバタイズするISATAPルーターからRAメッセージを取得します。ホストはRAメッセージを受信すると、SLAACを使用して、[RFC4862]および[RFC5214]で指定されているように、Aフラグが1に設定されているアドバタイズされたプレフィックスからIPv6アドレスを構成し、ISATAPインターフェイスにアドレスを割り当てます。ホストはまた、Lフラグが1に設定されているアドバタイズされたプレフィックスのいずれかをISATAPインターフェイスに割り当てます。 （IPv6リンクローカルプレフィックスfe80 :: / 64は常にISATAPインターフェイス上のリンク上と見なされることに注意してください。）
Figure 1 depicts an example ISATAP network topology for allowing hosts within a predominantly IPv4 site to configure ISATAP services using SLAAC with the shared prefix model. The example shows two advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'), and an ordinary IPv6 host ('E') outside of the site in a typical deployment configuration. In this model, routers 'A' and 'B' both advertise the same (shared) IPv6 prefix 2001:db8::/64 into the IPv6 routing system, and also advertise the prefix in the RA messages they send to ISATAP clients.
図1は、主にIPv4サイト内のホストが共有プレフィックスモデルでSLAACを使用してISATAPサービスを構成できるようにするためのISATAPネットワークトポロジの例を示しています。この例は、2つのアドバタイズISATAPルーター（ 'A'、 'B'）、2つのISATAPホスト（ 'C'、 'D'）、および一般的な展開構成のサイト外の通常のIPv6ホスト（ 'E'）を示しています。このモデルでは、ルーター 'A'と 'B'の両方が同じ（共有）IPv6プレフィックス2001：db8 :: / 64をIPv6ルーティングシステムにアドバタイズし、ISATAPクライアントに送信するRAメッセージのプレフィックスもアドバタイズします。
.-(::::::::) 2001:db8:1::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host E |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,~~~~~~~~~~~~~~~~~,
,----|companion gateway|--.
/ '~~~~~~~~~~~~~~~~~' :
/ |.
,-' `.
; +------------+ +------------+ )
: | Router A | | Router B | /
: | (isatap) | | (isatap) | :
: | 192.0.2.1 | | 192.0.2.1 | ;
+ +------------+ +------------+ \
fe80::*:192.0.2.1 fe80::*:192.0.2.1
| 2001:db8::/64 2001:db8::/64 |
| ;
: IPv4 Site -+-'
`-. (PRL: 192.0.2.1) .)
\ _)
`-----+--------)----+'----'
fe80::*:192.0.2.18 fe80::*:192.0.2.34
2001:db8::*:192.0.2.18 2001:db8::*:192.0.2.34
+--------------+ +--------------+
| 192.0.2.18 | | 192.0.2.34 |
| (isatap) | | (isatap) |
| Host C | | Host D |
+--------------+ +--------------+
(* == "0000:5efe", i.e., the organizational unique code for ISATAP,
per Section 6.1 of [RFC5214])
Figure 1: Example ISATAP Network Topology Using Shared Prefix Model
図1：共有プレフィックスモデルを使用したISATAPネットワークトポロジの例
With reference to Figure 1, advertising ISATAP routers 'A' and 'B' within the IPv4 site connect to the IPv6 Internet either directly or via a companion gateway. The routers advertise the shared prefix 2001:db8::/64 into the IPv6 Internet routing system either as a singleton /64 or as part of a shorter aggregated IPv6 prefix. For the purpose of this example, we also assume that the IPv4 site is configured within multiple IPv4 subnets -- each with an IPv4 prefix length of /28.
図1を参照すると、IPv4サイト内のアドバタイズISATAPルーター「A」と「B」は、直接またはコンパニオンゲートウェイ経由でIPv6インターネットに接続します。ルーターは、共有プレフィックス2001：db8 :: / 64をシングルトン/ 64または短い集約IPv6プレフィックスの一部としてIPv6インターネットルーティングシステムにアドバタイズします。この例では、IPv4サイトが複数のIPv4サブネット内に構成されていることも前提としています。それぞれのサブネットにはIPv4プレフィックス長/ 28があります。
Advertising ISATAP routers 'A' and 'B' both configure the IPv4 anycast address 192.0.2.1 on a site-interior IPv4 interface, then configure an advertising ISATAP router interface for the site with link-local ISATAP address fe80::5efe:192.0.2.1. The site administrator then places the single IPv4 address 192.0.2.1 in the site's PRL. 'A' and 'B' then both advertise the anycast address/ prefix into the site's IPv4 routing system so that ISATAP clients can locate the router that is topologically closest. (Note: advertising ISATAP routers can also use individual IPv4 unicast addresses instead of, or in addition to, a shared IPv4 anycast address. In that case, the PRL will contain multiple IPv4 addresses of advertising routers -- some of which may be anycast and others unicast.)
アドバタイズISATAPルーター 'A'と 'B'はどちらもサイト内部IPv4インターフェイスでIPv4エニーキャストアドレス192.0.2.1を構成し、次にリンクローカルISATAPアドレスfe80 :: 5efe：192.0でサイトのアドバタイズISATAPルーターインターフェイスを構成します。 2.1。次に、サイト管理者は、単一のIPv4アドレス192.0.2.1をサイトのPRLに配置します。次に、「A」と「B」の両方がエニーキャストアドレス/プレフィックスをサイトのIPv4ルーティングシステムにアドバタイズするため、ISATAPクライアントはトポロジ的に最も近いルーターを見つけることができます。 （注：アドバタイズISATAPルーターは、共有IPv4エニーキャストアドレスの代わりに、またはそれに加えて、個別のIPv4ユニキャストアドレスを使用することもできます。その場合、PRLにはアドバタイズルーターの複数のIPv4アドレスが含まれます。他はユニキャスト。）
ISATAP host 'C' connects to the site via an IPv4 interface with address 192.0.2.18/28 and also configures an ISATAP host interface with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4 interface. 'C' next resolves the PRL and sends an RS message to the IPv4 address 192.0.2.1, where IPv4 routing will direct it to the closest of either 'A' or 'B'. Assuming 'A' is closest, 'C' receives an RA from 'A' then configures a default IPv6 route with next-hop address fe80::5efe:192.0.2.1 via the ISATAP interface and processes the IPv6 prefix 2001:db8::/64 advertised in the PIO. If the A flag is set in the PIO, 'C' uses SLAAC to automatically configure the IPv6 address 2001:db8::5efe:192.0.2.18 (i.e., an address with an ISATAP interface identifier) and assigns it to the ISATAP interface. If the L flag is set, 'C' also assigns the prefix 2001:db8::/64 to the ISATAP interface, and the IPv6 address becomes a true ISATAP address.
ISATAPホスト 'C'は、アドレス192.0.2.18/28のIPv4インターフェイスを介してサイトに接続し、IPv4インターフェイスを介してリンクローカルISATAPアドレスfe80 :: 5efe：192.0.2.18のISATAPホストインターフェイスを構成します。次に 'C'はPRLを解決し、RSメッセージをIPv4アドレス192.0.2.1に送信します。IPv4ルーティングはそれを最も近い 'A'または 'B'のいずれかに送信します。 「A」が最も近いと仮定すると、「C」は「A」からRAを受信し、次にISATAPインターフェイスを介してネクストホップアドレスfe80 :: 5efe：192.0.2.1でデフォルトのIPv6ルートを構成し、IPv6プレフィックス2001：db8 ::を処理します。 / 64がPIOでアドバタイズされました。 PIOでAフラグが設定されている場合、「C」はSLAACを使用してIPv6アドレス2001：db8 :: 5efe：192.0.2.18（つまり、ISATAPインターフェイス識別子を持つアドレス）を自動的に構成し、それをISATAPインターフェイスに割り当てます。 Lフラグが設定されている場合、 'C'はプレフィックス2001：db8 :: / 64もISATAPインターフェイスに割り当て、IPv6アドレスは真のISATAPアドレスになります。
In the same fashion, ISATAP host 'D' configures its IPv4 interface with address 192.0.2.34/28 and configures its ISATAP interface with link-local ISATAP address fe80::5efe:192.0.2.34. 'D' next performs an RS/RA exchange that is serviced by 'B', then uses SLAAC to autoconfigure the address 2001:db8::5efe:192.0.2.34 and a default IPv6 route with next-hop address fe80::5efe:192.0.2.1. Finally, IPv6 host 'E' connects to an IPv6 network outside of the site. 'E' configures its IPv6 interface in a manner specific to its attached IPv6 link and autoconfigures the IPv6 address 2001:db8:1::1.
同様に、ISATAPホスト「D」は、IPv4インターフェースをアドレス192.0.2.34/28で構成し、ISATAPインターフェースをリンクローカルISATAPアドレスfe80 :: 5efe：192.0.2.34で構成します。次に「D」は、「B」がサービスを提供するRS / RA交換を実行し、SLAACを使用して、アドレス2001：db8 :: 5efe：192.0.2.34およびネクストホップアドレスfe80 :: 5efeのデフォルトIPv6ルートを自動設定します。 192.0.2.1。最後に、IPv6ホスト「E」はサイト外のIPv6ネットワークに接続します。 「E」は、接続されているIPv6リンクに固有の方法でIPv6インターフェースを構成し、IPv6アドレス2001：db8：1 :: 1を自動構成します。
Following this autoconfiguration, when host 'C' inside the site has an IPv6 packet to send to host 'E' outside the site, it prepares the packet with source address 2001:db8::5efe:192.0.2.18 and destination address 2001:db8:1::1. 'C' then uses IPv6-in-IPv4 encapsulation to forward the packet to the IPv4 address 192.0.2.1, which will be directed to 'A' based on IPv4 routing. 'A' in turn decapsulates the packet and forwards it into the public IPv6 Internet, where it will be conveyed to 'E' via normal IPv6 routing. In the same fashion, host 'D' uses IPv6-in-IPv4 encapsulation via its default router 'B' to send IPv6 packets to IPv6 Internet hosts such as 'E'.
この自動構成に続いて、サイト内のホスト「C」にサイト外のホスト「E」に送信するIPv6パケットがある場合、送信元アドレス2001：db8 :: 5efe：192.0.2.18および宛先アドレス2001：db8でパケットを準備します。 ：1 :: 1。次に、「C」はIPv6-in-IPv4カプセル化を使用して、パケットをIPv4アドレス192.0.2.1に転送します。このアドレスは、IPv4ルーティングに基づいて「A」に送信されます。次に「A」はパケットのカプセル化を解除し、それをパブリックIPv6インターネットに転送します。ここで、通常のIPv6ルーティングを介して「E」に転送されます。同様に、ホスト「D」は、デフォルトルータ「B」を介してIPv6-in-IPv4カプセル化を使用して、「E」などのIPv6インターネットホストにIPv6パケットを送信します。
When host 'E' outside the site sends IPv6 packets to ISATAP host 'C' inside the site, the IPv6 routing system may direct the packet to either 'A' or 'B'. If the site is not partitioned internally, the router that receives the packet can use ISATAP to statelessly forward the packet directly to 'C'. If the site may be partitioned internally, however, the packet must first be forwarded to 'C's serving router based on IPv6 routing information. This implies that, in a partitioned site, the advertising ISATAP routers must connect within a full or partial mesh of IPv6 links, and they must either run a dynamic IPv6 routing protocol or configure static routes so that incoming IPv6 packets can be forwarded to the correct serving router.
サイト外のホスト「E」がIPv6パケットをサイト内のISATAPホスト「C」に送信すると、IPv6ルーティングシステムはパケットを「A」または「B」のいずれかに送信します。サイトが内部的に分割されていない場合、パケットを受信するルーターはISATAPを使用して、パケットをステートレスに直接「C」に転送できます。ただし、サイトが内部的に分割されている場合、パケットはまずIPv6ルーティング情報に基づいて「C」のサービングルータに転送される必要があります。これは、分割されたサイトで、アドバタイズISATAPルーターがIPv6リンクの完全または部分的なメッシュ内で接続する必要があり、着信IPv6パケットを正しいIPv6パケットに転送できるように、動的IPv6ルーティングプロトコルを実行するか、静的ルートを構成する必要があることを意味しますサービングルーター。
In this example, 'A' can configure the IPv6 route 2001:db8::5efe:192.0.2.32/124 with the IPv6 address of the next hop toward 'B' in the mesh network as the next hop, and 'B' can configure the IPv6 route 2001:db8::5efe:192.0.2.16/124 with the IPv6 address of the next hop toward 'A' as the next hop. (Notice that the /124 prefixes properly cover the /28 prefix of the IPv4 address that is embedded within the IPv6 address.) In that case, when 'A' receives a packet from the IPv6 Internet with destination address 2001:db8::5efe:192.0.2.34, it first forwards the packet toward 'B' over an IPv6 mesh link. 'B' in turn uses ISATAP to forward the packet into the site, where IPv4 routing will direct it to 'D'. In the same fashion, when 'B' receives a packet from the IPv6 Internet with destination address 2001:db8::5efe:192.0.2.18, it first forwards the packet toward 'A' over an IPv6 mesh link. 'A' then uses ISATAP to forward the packet into the site, where IPv4 routing will direct it to 'C'.
この例では、「A」はIPv6ルート2001：db8 :: 5efe：192.0.2.32/124をメッシュネットワーク内の「B」へのネクストホップのIPv6アドレスをネクストホップとして設定でき、「B」はIPv6ルート2001：db8 :: 5efe：192.0.2.16/124を、「A」へのネクストホップのIPv6アドレスをネクストホップとして設定します。 （/ 124プレフィックスは、IPv6アドレス内に埋め込まれたIPv4アドレスの/ 28プレフィックスを適切にカバーすることに注意してください。）その場合、「A」が宛先アドレス2001：db8 :: 5efeでIPv6インターネットからパケットを受信したとき：192.0.2.34、最初にパケットをIPv6メッシュリンクを介して「B」に転送します。次に「B」はISATAPを使用してパケットをサイトに転送し、IPv4ルーティングによってパケットが「D」に転送されます。同様に、「B」が宛先アドレス2001：db8 :: 5efe：192.0.2.18のIPv6インターネットからパケットを受信すると、最初にIPv6メッシュリンクを介して「A」に向けてパケットを転送します。次に、 'A'はISATAPを使用してパケットをサイトに転送し、IPv4ルーティングによってパケットが 'C'に転送されます。
Finally, when host 'C' inside the site connects to host 'D' inside the site, it has the option of using the native IPv4 service or the ISATAP IPv6-in-IPv4 encapsulation service. When there is operational assurance that IPv4 services between the two hosts are available, the hosts may be better served to continue to use legacy IPv4 services in order to avoid encapsulation overhead and to avoid communication failures due to middleboxes in the path that filter protocol-41 packets [RFC4213]. If 'C' and 'D' could be in different IPv4 network partitions, however, IPv6-in-IPv4 encapsulation should be used with one or both of routers 'A' and 'B' serving as intermediate gateways.
最後に、サイト内のホスト「C」がサイト内のホスト「D」に接続する場合、ネイティブIPv4サービスまたはISATAP IPv6-in-IPv4カプセル化サービスを使用するオプションがあります。 2つのホスト間でIPv4サービスが利用可能であることが運用保証されている場合、カプセル化のオーバーヘッドを回避し、プロトコル41をフィルタリングするパスのミドルボックスによる通信障害を回避するために、ホストはレガシーIPv4サービスを引き続き使用するほうがよい場合があります。パケット[RFC4213]。ただし、「C」と「D」が異なるIPv4ネットワークパーティションにある場合、IPv6-in-IPv4カプセル化は、中間ゲートウェイとして機能するルーター「A」と「B」の一方または両方で使用する必要があります。
Figure 2 depicts an example ISATAP network topology for allowing hosts within a predominantly IPv4 site to configure ISATAP services using SLAAC with the individual prefix model. The example shows two advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'), and an ordinary IPv6 host ('E') outside of the site in a typical deployment configuration. In the figure, ISATAP routers 'A' and 'B' both advertise different prefixes taken from the aggregated prefix 2001:db8::/48, with 'A' advertising 2001:db8:0:1::/64 and 'B' advertising 2001:db8:0:2::/64.
図2は、主にIPv4サイト内のホストが、個別のプレフィックスモデルでSLAACを使用してISATAPサービスを構成できるようにするためのISATAPネットワークトポロジの例を示しています。この例では、2つのアドバタイズISATAPルーター（ 'A'、 'B'）、2つのISATAPホスト（ 'C'、 'D'）、および通常の展開構成のサイト外の通常のIPv6ホスト（ 'E'）を示しています。この図では、ISATAPルーター 'A'と 'B'の両方が、集約プレフィックス2001：db8 :: / 48から取得した異なるプレフィックスをアドバタイズし、 'A'は2001：db8：0：1 :: / 64と 'B'をアドバタイズしています。 2001：db8：0：2 :: / 64の広告。
.-(::::::::) 2001:db8:1::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host E |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,~~~~~~~~~~~~~~~~~,
,----|companion gateway|--.
/ '~~~~~~~~~~~~~~~~~' :
/ |.
,-' `.
; +------------+ +------------+ )
: | Router A | | Router B | /
: | (isatap) | | (isatap) | :
: | 192.0.2.17 | | 192.0.2.33 | ;
+ +------------+ +------------+ \
fe80::*:192.0.2.17 fe80::*:192.0.2.33
2001:db8:0:1::/64 2001:db8:0:2::/64
| ;
: IPv4 Site -+-'
`-. (PRL: 192.0.2.1) .)
\ _)
`-----+--------)----+'----'
fe80::*:192.0.2.18 fe80::*:192.0.2.34
2001:db8:0:1::*:192.0.2.18 2001:db8:0:2::*:192.0.2.34
+--------------+ +--------------+
| 192.0.2.18 | | 192.0.2.34 |
| (isatap) | | (isatap) |
| Host C | | Host D |
+--------------+ +--------------+
(* == "0000:5efe")
Figure 2: Example ISATAP Network Topology Using Individual Prefix Model
図2：個別のプレフィックスモデルを使用したISATAPネットワークトポロジの例
With reference to Figure 2, advertising ISATAP routers 'A' and 'B' within the IPv4 site connect to the IPv6 Internet either directly or via a companion gateway. Router 'A' advertises the individual prefix 2001:db8:0:1::/64 into the IPv6 Internet routing system, and router 'B' advertises the individual prefix 2001:db8:0:2::/64. The routers could instead both advertise a shorter shared prefix such as 2001:db8::/48 into the IPv6 routing system, but in that case they would need to configure a mesh of IPv6 links between themselves in the same fashion as described for the shared prefix model in Section 3.3. For the purpose of this example, we also assume that the IPv4 site is configured within multiple IPv4 subnets -- each with an IPv4 prefix length of /28.
図2を参照すると、IPv4サイト内のISATAPルーター「A」および「B」のアドバタイズは、直接またはコンパニオンゲートウェイを介してIPv6インターネットに接続します。ルータ「A」は個々のプレフィックス2001：db8：0：1 :: / 64をIPv6インターネットルーティングシステムにアドバタイズし、ルータ「B」は個々のプレフィックス2001：db8：0：2 :: / 64をアドバタイズします。代わりに、ルーターはどちらも2001：db8 :: / 48などの短い共有プレフィックスをIPv6ルーティングシステムにアドバタイズできますが、その場合、共有について説明したのと同じ方法で、ルーター間にIPv6リンクのメッシュを構成する必要があります。セクション3.3の接頭辞モデル。この例では、IPv4サイトが複数のIPv4サブネット内に構成されていることも前提としています。それぞれのサブネットにはIPv4プレフィックス長/ 28があります。
Advertising ISATAP routers 'A' and 'B' both configure individual IPv4 unicast addresses 192.0.2.17/28 and 192.0.2.33/28 (respectively) instead of, or in addition to, a shared IPv4 anycast address. Router 'A' then configures an advertising ISATAP router interface for the site with link-local ISATAP address fe80::5efe:192.0.2.17, while router 'B' configures an advertising ISATAP router interface for the site with link-local ISATAP address fe80::5efe:192.0.2.33. The site administrator then places the IPv4 addresses 192.0.2.17 and 192.0.2.33 in the site's PRL. 'A' and 'B' then both advertise their IPv4 addresses into the site's IPv4 routing system.
ISATAPルーター 'A'と 'B'のアドバタイズは、共有IPv4エニーキャストアドレスの代わりに、またはそれに加えて、個別のIPv4ユニキャストアドレス192.0.2.17/28および192.0.2.33/28（それぞれ）を構成します。次に、ルーター 'A'はリンクローカルISATAPアドレスfe80 :: 5efe：192.0.2.17でサイトのアドバタイズISATAPルーターインターフェイスを構成し、ルーター 'B'はリンクローカルISATAPアドレスfe80でサイトのアドバタイズISATAPルーターインターフェイスを構成します:: 5efe：192.0.2.33。次に、サイト管理者はIPv4アドレス192.0.2.17および192.0.2.33をサイトのPRLに配置します。次に、「A」と「B」の両方が、サイトのIPv4ルーティングシステムにIPv4アドレスをアドバタイズします。
ISATAP host 'C' connects to the site via an IPv4 interface with address 192.0.2.18/28 and also configures an ISATAP host interface with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4 interface. 'C' next resolves the PRL and sends an RS message to the IPv4 address 192.0.2.17, where IPv4 routing will direct it to 'A'. 'C' then receives an RA from 'A' then configures a default IPv6 route with next-hop address fe80::5efe:192.0.2.17 via the ISATAP interface and processes the IPv6 prefix 2001:db8:0:1:/64 advertised in the PIO. If the A flag is set in the PIO, 'C' uses SLAAC to automatically configure the IPv6 address 2001:db8:0:1::5efe:192.0.2.18 (i.e., an address with an ISATAP interface identifier) and assigns it to the ISATAP interface. If the L flag is set, 'C' also assigns the prefix 2001:db8:0:1::/64 to the ISATAP interface, and the IPv6 address becomes a true ISATAP address.
ISATAPホスト 'C'は、アドレス192.0.2.18/28のIPv4インターフェイスを介してサイトに接続し、IPv4インターフェイスを介してリンクローカルISATAPアドレスfe80 :: 5efe：192.0.2.18のISATAPホストインターフェイスを構成します。次に「C」はPRLを解決し、RSメッセージをIPv4アドレス192.0.2.17に送信します。IPv4ルーティングはそれを「A」に転送します。次に「C」は「A」からRAを受信し、次にISATAPインターフェイスを介してネクストホップアドレスfe80 :: 5efe：192.0.2.17でデフォルトのIPv6ルートを構成し、アドバタイズされたIPv6プレフィックス2001：db8：0：1：/ 64を処理しますPIOで。 PIOでAフラグが設定されている場合、「C」はSLAACを使用してIPv6アドレス2001：db8：0：1 :: 5efe：192.0.2.18（つまり、ISATAPインターフェイス識別子を持つアドレス）を自動的に構成し、それをISATAPインターフェイス。 Lフラグが設定されている場合、「C」はプレフィックス2001：db8：0：1 :: / 64もISATAPインターフェイスに割り当て、IPv6アドレスは真のISATAPアドレスになります。
In the same fashion, ISATAP host 'D' configures its IPv4 interface with address 192.0.2.34/28 and configures its ISATAP interface with link-local ISATAP address fe80::5efe:192.0.2.34. 'D' next performs an RS/RA exchange that is serviced by 'B', then uses SLAAC to autoconfigure the address 2001:db8:0:2::5efe:192.0.2.34 and a default IPv6 route with next-hop address fe80::5efe:192.0.2.33. Finally, IPv6 host 'E' connects to an IPv6 network outside of the site. 'E' configures its IPv6 interface in a manner specific to its attached IPv6 link, and it autoconfigures the IPv6 address 2001:db8:1::1.
同様に、ISATAPホスト「D」は、IPv4インターフェースをアドレス192.0.2.34/28で構成し、ISATAPインターフェースをリンクローカルISATAPアドレスfe80 :: 5efe：192.0.2.34で構成します。次に「D」は、「B」がサービスを提供するRS / RA交換を実行し、SLAACを使用してアドレス2001：db8：0：2 :: 5efe：192.0.2.34および次ホップアドレスfe80のデフォルトIPv6ルートを自動構成します:: 5efe：192.0.2.33。最後に、IPv6ホスト「E」はサイト外のIPv6ネットワークに接続します。 「E」は、接続されているIPv6リンクに固有の方法でIPv6インターフェースを構成し、IPv6アドレス2001：db8：1 :: 1を自動構成します。
Following this autoconfiguration, when host 'C' inside the site has an IPv6 packet to send to host 'E' outside the site, it prepares the packet with source address 2001:db8::5efe:192.0.2.18 and destination address 2001:db8:1::1. 'C' then uses IPv6-in-IPv4 encapsulation to forward the packet to the IPv4 address 192.0.2.17, which will be directed to 'A' based on IPv4 routing. 'A' in turn decapsulates the packet and forwards it into the public IPv6 Internet, where it will be conveyed to 'E' via normal IPv6 routing. In the same fashion, host 'D' uses IPv6-in-IPv4 encapsulation via its default router 'B' to send IPv6 packets to IPv6 Internet hosts such as 'E'.
この自動構成に続いて、サイト内のホスト「C」にサイト外のホスト「E」に送信するIPv6パケットがある場合、送信元アドレス2001：db8 :: 5efe：192.0.2.18および宛先アドレス2001：db8でパケットを準備します。 ：1 :: 1。次に、「C」はIPv6-in-IPv4カプセル化を使用して、IPv4ルーティングに基づいて「A」に送信されるIPv4アドレス192.0.2.17にパケットを転送します。次に「A」はパケットのカプセル化を解除し、それをパブリックIPv6インターネットに転送します。ここで、通常のIPv6ルーティングを介して「E」に転送されます。同様に、ホスト「D」は、デフォルトルータ「B」を介してIPv6-in-IPv4カプセル化を使用して、「E」などのIPv6インターネットホストにIPv6パケットを送信します。
When host 'E' outside the site sends IPv6 packets to ISATAP host 'C' inside the site, the IPv6 routing system will direct the packet to 'A' since 'A' advertises the individual prefix that matches 'C's destination address. 'A' can then use ISATAP to statelessly forward the packet directly to 'C'. If 'A' and 'B' both advertise the shared shorter prefix 2001:db8::/48 into the IPv6 routing system, however, packets coming from 'E' may be directed to either 'A' or 'B'. In that case, the advertising ISATAP routers must connect within a full or partial mesh of IPv6 links the same as for the shared prefix model and must either run a dynamic IPv6 routing protocol or configure static routes so that incoming IPv6 packets can be forwarded to the correct serving router.
サイト外のホスト「E」がサイト内のISATAPホスト「C」にIPv6パケットを送信すると、「A」が「C」の宛先アドレスと一致する個々のプレフィックスをアドバタイズするため、IPv6ルーティングシステムはパケットを「A」に転送します。次に、「A」はISATAPを使用して、パケットをステートレスに直接「C」に転送できます。ただし、 'A'と 'B'の両方が共有の短いプレフィックス2001：db8 :: / 48をIPv6ルーティングシステムにアドバタイズする場合、 'E'からのパケットは 'A'または 'B'のどちらかに向けられます。その場合、アドバタイズISATAPルーターは、共有プレフィックスモデルの場合と同じように、IPv6リンクの完全または部分的なメッシュ内で接続し、動的IPv6ルーティングプロトコルを実行するか、静的ルートを構成して、着信IPv6パケットをに転送できるようにする必要があります。正しいサービングルーター。
In this example, 'A' can configure the IPv6 route 2001:db8:0:2::/64 with the IPv6 address of the next hop toward 'B' in the mesh network as the next hop, and 'B' can configure the IPv6 route 2001:db8:0.1::/64 with the IPv6 address of the next hop toward 'A' as the next hop. Then, when 'A' receives a packet from the IPv6 Internet with destination address 2001:db8:0:2::5efe:192.0.2.34, it first forwards the packet toward 'B' over an IPv6 mesh link. 'B' in turn uses ISATAP to forward the packet into the site, where IPv4 routing will direct it to 'D'. In the same fashion, when 'B' receives a packet from the IPv6 Internet with destination address 2001:db8:0:1::5efe:192.0.2.18, it first forwards the packet toward 'A' over an IPv6 mesh link. 'A' then uses ISATAP to forward the packet into the site, where IPv4 routing will direct it to 'C'.
この例では、「A」はIPv6ルート2001：db8：0：2 :: / 64を、メッシュネットワークの「B」へのネクストホップのIPv6アドレスをネクストホップとして設定でき、「B」はIPv6ルート2001：db8：0.1 :: / 64、「A」へのネクストホップのIPv6アドレスをネクストホップとして。次に、「A」がIPv6インターネットから宛先アドレス2001：db8：0：2 :: 5efe：192.0.2.34のパケットを受信すると、最初にそのパケットをIPv6メッシュリンクを介して「B」に転送します。次に「B」はISATAPを使用してパケットをサイトに転送し、IPv4ルーティングによってパケットが「D」に転送されます。同様に、「B」が宛先アドレス2001：db8：0：1 :: 5efe：192.0.2.18のIPv6インターネットからパケットを受信すると、最初にIPv6メッシュリンクを介して「A」に向けてパケットを転送します。次に、 'A'はISATAPを使用してパケットをサイトに転送し、IPv4ルーティングによってパケットが 'C'に転送されます。
Finally, when host 'C' inside the site connects to host 'D' inside the site, it has the option of using the native IPv4 service or the ISATAP IPv6-in-IPv4 encapsulation service. When there is operational assurance that IPv4 services between the two hosts are available, the hosts may be better served to continue to use legacy IPv4 services in order to avoid encapsulation overhead and to avoid any IPv4 protocol-41 filtering middleboxes that may be in the path. If 'C' and 'D' may be in different IPv4 network partitions, however, IPv6-in-IPv4 encapsulation should be used with one or both of routers 'A' and 'B' serving as intermediate gateways.
最後に、サイト内のホスト「C」がサイト内のホスト「D」に接続する場合、ネイティブIPv4サービスまたはISATAP IPv6-in-IPv4カプセル化サービスを使用するオプションがあります。 2つのホスト間でIPv4サービスが利用可能であることが運用保証されている場合、カプセル化のオーバーヘッドを回避し、パスにある可能性のあるIPv4プロトコル41フィルタリングミドルボックスを回避するために、ホストは従来のIPv4サービスを引き続き使用するほうが適切に機能します。 。ただし、「C」と「D」が異なるIPv4ネットワークパーティションにある場合、IPv6-in-IPv4カプセル化は、中間ゲートウェイとして機能するルーター「A」と「B」の一方または両方で使用する必要があります。
In common practice, firewalls, gateways, and packet filtering devices of various forms are often deployed in order to divide the site into separate partitions. In both the shared and individual prefix models described above, the entire site can be represented by the aggregate IPv6 prefix assigned to the site, while each site partition can be represented by "sliver" IPv6 prefixes taken from the aggregate. In order to provide a simple service that does not interact poorly with the site topology, site administrators should therefore institute an address plan to align IPv6 sliver prefixes with IPv4 site partition boundaries.
一般的な慣例では、サイトを別々のパーティションに分割するために、ファイアウォール、ゲートウェイ、およびさまざまな形式のパケットフィルタリングデバイスが配備されることがよくあります。上記の共有プレフィックスモデルと個別プレフィックスモデルの両方で、サイト全体はサイトに割り当てられた集約IPv6プレフィックスで表すことができ、各サイトパーティションは集約から取得した「スライバー」IPv6プレフィックスで表すことができます。したがって、サイトトポロジと十分に相互作用しない単純なサービスを提供するために、サイト管理者はIPv6スライバープレフィックスをIPv4サイトパーティション境界に合わせるためのアドレス計画を策定する必要があります。
For example, in the shared prefix model in Section 3.3, the aggregate prefix is 2001:db8::/64, and the sliver prefixes are 2001:db8::5efe:192.0.2.0/124, 2001:db8::5efe:192.0.2.16/124, 2001:db8::5efe:192.0.2.32/124, etc. In the individual prefix model in Section 3.4, the aggregate prefix is 2001:db8::/48, and the sliver prefixes are 2001:db8:0:0::/64, 2001:db8:0:1::/64, 2001:db8:0:2::/64, etc.
たとえば、セクション3.3の共有プレフィックスモデルでは、集約プレフィックスは2001：db8 :: / 64で、スリーバープレフィックスは2001：db8 :: 5efe：192.0.2.0/124、2001：db8 :: 5efe：192.0です。 .2.16 / 124、2001：db8 :: 5efe：192.0.2.32/124など。セクション3.4の個々のプレフィックスモデルでは、集約プレフィックスは2001：db8 :: / 48であり、スリーバープレフィックスは2001：db8：です。 0：0 :: / 64、2001：db8：0：1 :: / 64、2001：db8：0：2 :: / 64など。
When individual prefixes are used, site administrators can configure advertising ISATAP routers to advertise different individual prefixes to different sets of clients, e.g., based on the client's IPv4 subnet prefix such that the IPv6 prefixes are congruent with the IPv4 addressing plan. (For example, administrators can configure each advertising ISATAP router to provide services only to certain sets of ISATAP clients through inbound IPv6 Access Control List (ACL) entries that match the IPv4 subnet prefix embedded in the ISATAP interface identifier of the IPv6 source address.) When a shared prefix is used, site administrators instead configure the ISATAP routers to advertise the shared prefix to all clients.
個別のプレフィックスが使用される場合、サイト管理者は、たとえばクライアントのIPv4サブネットプレフィックスに基づいて、IPv6プレフィックスがIPv4アドレッシングプランと一致するように、クライアントの異なるセットに異なる個別のプレフィックスをアドバタイズするようにISATAPルーターのアドバタイズを構成できます。 （たとえば、管理者は各アドバタイズISATAPルーターを構成して、IPv6送信元アドレスのISATAPインターフェイス識別子に埋め込まれたIPv4サブネットプレフィックスと一致する受信IPv6アクセスコントロールリスト（ACL）エントリを介して、特定のISATAPクライアントのセットにのみサービスを提供できます。）共有プレフィックスを使用する場合、サイト管理者は代わりにISATAPルーターを構成して、共有プレフィックスをすべてのクライアントに通知します。
Advertising ISATAP routers can advertise prefixes with the (A, L) flags set to (1,0) so that ISATAP clients will use SLAAC to autoconfigure IPv6 addresses with ISATAP interface identifiers from the prefixes and assign them to the receiving ISATAP interface, but they will not assign the prefix itself to the ISATAP interface. In that case, the advertising router must assign the sliver prefix for the site partition to the advertising ISATAP interface. In this way, the advertising router considers the addresses covered by the sliver prefix as true ISATAP addresses, but the ISATAP clients themselves do not. This configuration enables a hub-and-spoke architecture, which in some cases may be augmented by route optimization based on the receipt of ICMPv6 Redirects.
広告ISATAPルーターは、（A、L）フラグが（1,0）に設定されたプレフィックスをアドバタイズできるため、ISATAPクライアントはSLAACを使用して、プレフィックスからのISATAPインターフェイス識別子でIPv6アドレスを自動構成し、受信ISATAPインターフェイスに割り当てますが、それらはプレフィックス自体をISATAPインターフェイスに割り当てません。その場合、アドバタイズルーターは、サイトパーティションのスリーバープレフィックスをアドバタイズISATAPインターフェイスに割り当てる必要があります。このように、アドバタイズルーターは、スリーバープレフィックスでカバーされるアドレスを真のISATAPアドレスと見なしますが、ISATAPクライアント自体はそうではありません。この構成により、ハブアンドスポークアーキテクチャが有効になります。これは、ICMPv6リダイレクトの受信に基づくルート最適化によって強化される場合があります。
Site administrators can implement address selection policy rules [RFC6724] through explicit configurations in each ISATAP client in order to give preference to IPv4 destination addresses over destination addresses derived from one of the client's IPv6 sliver prefixes. For example, site administrators can configure each ISATAP client associated with a sliver prefix such as 2001:db8::5efe:192.0.2.64/124 to add the prefix to its address selection policy table with a lower precedence than the prefix ::ffff:0:0/96. In this way, IPv4 addresses are preferred over IPv6 addresses from within the same sliver. The prefix could be added to each ISATAP client either manually or through an automated service such as a DHCP option [ADDR-SELECT] discovered by the client, e.g.,
サイト管理者は、各ISATAPクライアントの明示的な構成を通じてアドレス選択ポリシールール[RFC6724]を実装して、クライアントのIPv6スライバープレフィックスの1つから派生した宛先アドレスよりもIPv4宛先アドレスを優先させることができます。たとえば、サイト管理者は、2001：db8 :: 5efe：192.0.2.64/124などのスリーバープレフィックスに関連付けられた各ISATAPクライアントを構成して、プレフィックス:: ffffよりも優先順位の低いアドレス選択ポリシーテーブルにプレフィックスを追加できます。 0：0/96。このように、同じスライバー内からのIPv6アドレスよりもIPv4アドレスが優先されます。プレフィックスは、手動で、またはクライアントによって検出されたDHCPオプション[ADDR-SELECT]などの自動サービスを介して、各ISATAPクライアントに追加できます。
using Stateless DHCPv6 [RFC3736]. In this way, clients will use IPv4 communications to reach correspondents within the same IPv4 site partition and will use IPv6 communications to reach correspondents in other partitions and/or outside of the site.
ステートレスDHCPv6 [RFC3736]を使用。このようにして、クライアントはIPv4通信を使用して同じIPv4サイトパーティション内の通信相手に到達し、IPv6通信を使用して他のパーティション内および/またはサイト外の通信相手に到達します。
It should be noted that sliver prefixes longer than /64 cannot be advertised for SLAAC purposes. Also, sliver prefixes longer than /64 do not allow for interface identifier rewriting by address translators. These factors may favor the individual prefix model in some deployment scenarios, while the flexibility afforded by the shared prefix model may be more desirable in others. Additionally, if the network is small, then the shared prefix model works well. If the network is large, however, a better alternative may be to deploy separate ISATAP routers in each partition and have each advertise its own individual prefix.
/ 64より長いスリーバープレフィックスは、SLAACの目的でアドバタイズできないことに注意してください。また、/ 64より長いスリーバープレフィックスは、アドレストランスレーターによるインターフェイス識別子の書き換えを許可しません。これらの要因は、一部の展開シナリオでは個々のプレフィックスモデルを優先する可能性がありますが、共有プレフィックスモデルによって提供される柔軟性は、他のシナリオではより望ましい場合があります。さらに、ネットワークが小さい場合は、共有プレフィックスモデルが適切に機能します。ただし、ネットワークが大きい場合は、各パーティションに個別のISATAPルーターを展開し、それぞれに独自のプレフィックスをアドバタイズすることをお勧めします。
Finally, site administrators should configure ISATAP routers to not send ICMPv6 Redirect messages to inform a source client of a better next hop toward the destination unless there is strong assurance that the client and the next hop are within the same IPv4 site partition.
最後に、サイト管理者は、クライアントとネクストホップが同じIPv4サイトパーティション内にあることが確実でない限り、ICMPv6リダイレクトメッセージを送信しないようにISATAPルーターを構成して、ソースクライアントに宛先へのより良いネクストホップを通知する必要があります。
In sites that provide IPv6 services through ISATAP with SLAAC as described in this section, site administrators must take operational precautions to avoid routing loops. For example, each advertising ISATAP router should drop any incoming IPv6 packets that would be forwarded back to itself via another of the site's advertising routers. Additionally, each advertising ISATAP router should drop any encapsulated packets received from another advertising router that would be forwarded back to that same advertising router. This corresponds to the mitigation documented in Section 3.2.3 of [RFC6324], but other mitigations specified in that document can also be employed.
このセクションで説明するように、SLAACを備えたISATAPを介してIPv6サービスを提供するサイトでは、サイト管理者はルーティングループを回避するために運用上の予防措置を講じる必要があります。たとえば、各アドバタイズISATAPルーターは、サイトの別のアドバタイズルーターを介して自身に転送される着信IPv6パケットをすべてドロップする必要があります。さらに、各アドバタイジングISATAPルーターは、同じアドバタイジングルーターに転送される別のアドバタイズルーターから受信したカプセル化されたパケットをドロップする必要があります。これは、[RFC6324]のセクション3.2.3に記載されている緩和策に対応していますが、そのドキュメントで指定されている他の緩和策を採用することもできます。
Note that IPv6 packets with link-local ISATAP addresses are exempt from these checks, since they cannot be forwarded by an IPv6 router and may be necessary for router-to-router coordinations.
リンクローカルISATAPアドレスを持つIPv6パケットは、IPv6ルーターによって転送できず、ルーター間の調整に必要になる場合があるため、これらのチェックから除外されていることに注意してください。
[RFC5214], Section 6.1 specifies the setting of the "u" bit in the Modified EUI-64 interface identifier format used by ISATAP. Implementations that comply with the specification set the "u" bit to 1 when the IPv4 address is known to be globally unique; however, some legacy implementations unconditionally set the "u" bit to 0.
[RFC5214]、6.1項では、ISATAPで使用されるModified EUI-64インターフェイス識別子形式の「u」ビットの設定を指定しています。仕様に準拠する実装では、IPv4アドレスがグローバルに一意であることがわかっている場合、「u」ビットを1に設定します。ただし、一部の従来の実装では、「u」ビットを無条件に0に設定しています。
Implementations interpret the ISATAP interface identifier only within the link to which the corresponding ISATAP prefix is assigned; hence, the value of the "u" bit is interpreted only within the context of an on-link prefix and not within a global context. Implementers are responsible for ensuring that their products are interoperable; therefore, implementations must make provisions for ensuring "u" bit compatibility for intra-link communications.
実装は、対応するISATAPプレフィックスが割り当てられているリンク内でのみISATAPインターフェイス識別子を解釈します。したがって、「u」ビットの値は、オンリンクプレフィックスのコンテキスト内でのみ解釈され、グローバルコンテキスト内では解釈されません。実装者は、自社製品の相互運用性を確保する責任があります。したがって、実装では、イントラリンク通信の「u」ビット互換性を確保するための準備を行う必要があります。
Site administrators should accordingly configure ACL entries and other literal representations of ISATAP interface identifiers such that both values of the "u" bit are accepted. For example, if the site administrator configures an ACL entry that matches the prefix "fe80::0000:5efe:192.0.2.0/124", they should also configure a companion list entry that matches the prefix "fe80::0200:5efe:192.0.2.0/124".
サイト管理者は、 "u"ビットの両方の値が受け入れられるように、ISATAPインターフェイス識別子のACLエントリおよびその他のリテラル表現を適宜構成する必要があります。たとえば、サイト管理者がプレフィックス「fe80 :: 0000：5efe：192.0.2.0/124」と一致するACLエントリを構成する場合、プレフィックス「fe80 :: 0200：5efe：」と一致するコンパニオンリストエントリも構成する必要があります。 192.0.2.0/124 "。
When no autoconfiguration services are available (e.g., if there are no advertising ISATAP routers present), site administrators can use manual configuration to assign IPv6 addresses with ISATAP interface identifiers to the ISATAP interfaces of clients. Otherwise, site administrators should avoid manual configurations that would in any way invalidate the assumptions of the autoconfiguration service. For example, manually configured addresses may not be automatically renumbered during a site-wide renumbering event, which could subsequently result in communication failures.
自動構成サービスが利用できない場合（たとえば、アドバタイズISATAPルーターが存在しない場合）、サイト管理者は手動構成を使用して、ISATAPインターフェイス識別子を持つIPv6アドレスをクライアントのISATAPインターフェイスに割り当てることができます。それ以外の場合、サイト管理者は、自動構成サービスの前提条件を無効にする手動構成を回避する必要があります。たとえば、手動で構成されたアドレスは、サイト全体の再番号付けイベント中に自動的に再番号付けされない場合があり、その結果、通信障害が発生する可能性があります。
Section 3 depicts ISATAP network topologies with only two advertising ISATAP routers within the site. In order to support larger numbers of ISATAP clients (and/or multiple site partitions), the site can deploy more advertising ISATAP routers to support load balancing and generally shortest-path routing.
セクション3は、サイト内に2つのアドバタイズISATAPルーターのみを持つISATAPネットワークトポロジを示しています。多数のISATAPクライアント（または複数のサイトパーティション、あるいはその両方）をサポートするために、サイトはより多くのISATAPルーターを展開して、負荷分散と一般に最短経路ルーティングをサポートできます。
Such an arrangement requires that the advertising ISATAP routers participate in an IPv6 routing protocol instance so that IPv6 addresses/prefixes can be mapped to the correct ISATAP router. The routing protocol instance can be configured as either a full-mesh topology involving all advertising ISATAP routers, or as a partial-mesh topology with each advertising ISATAP router associating with one or more companion gateways. Each such companion gateway would in turn participate in a full mesh between all companion gateways.
このような構成では、IPv6アドレス/プレフィックスを正しいISATAPルーターにマップできるように、アドバタイズISATAPルーターがIPv6ルーティングプロトコルインスタンスに参加する必要があります。ルーティングプロトコルインスタンスは、すべてのアドバタイズISATAPルーターを含むフルメッシュトポロジとして、または各アドバタイズISATAPルーターが1つ以上のコンパニオンゲートウェイに関連付けられた部分メッシュトポロジとして構成できます。そのような各コンパニオンゲートウェイは、すべてのコンパニオンゲートウェイ間のフルメッシュに参加します。
Advertising ISATAP routers distribute IPv6 prefixes to ISATAP clients within the site. If the site subsequently reconnects to a different ISP, however, the site must renumber to use addresses derived from the new IPv6 prefixes [RFC6879].
広告ISATAPルーターは、サイト内のISATAPクライアントにIPv6プレフィックスを配布します。ただし、サイトがその後別のISPに再接続する場合、サイトは新しいIPv6プレフィックス[RFC6879]から派生したアドレスを使用するように番号を付け直す必要があります。
For IPv6 services provided by SLAAC, site renumbering in the event of a change in an ISP-served IPv6 prefix entails a simple renumbering of IPv6 addresses and/or prefixes that are assigned to the ISATAP interfaces of clients within the site. In some cases, filtering rules (e.g., within filtering tables at site-border firewalls) may also require renumbering, but this operation can be automated and limited to only one or a few administrative "touch points".
SLAACによって提供されるIPv6サービスの場合、ISPが提供するIPv6プレフィックスが変更された場合のサイトの再番号付けでは、サイト内のクライアントのISATAPインターフェイスに割り当てられているIPv6アドレスやプレフィックスの単純な再番号付けが必要になります。場合によっては、フィルタリングルール（サイト境界ファイアウォールのフィルタリングテーブル内など）でも番号の付け直しが必要になることがありますが、この操作は自動化でき、1つまたはいくつかの管理「タッチポイント」のみに制限できます。
In order to renumber the ISATAP interfaces of clients within the site using SLAAC, advertising ISATAP routers need only schedule the services offered by the old ISP for deprecation and begin to advertise the IPv6 prefixes provided by the new ISP. Lifetimes of ISATAP client interface addresses will eventually expire, and the host will renumber its interfaces with addresses derived from the new prefixes. ISATAP clients should also eventually remove any deprecated SLAAC prefixes from their address selection policy tables, but this action is not time-critical.
SLAACを使用してサイト内のクライアントのISATAPインターフェイスの番号を変更するには、ISATAPルーターをアドバタイズするために古いISPが提供するサービスを非推奨にスケジュールし、新しいISPが提供するIPv6プレフィックスのアドバタイズを開始するだけです。 ISATAPクライアントインターフェイスアドレスの寿命は最終的に期限切れになり、ホストは新しいプレフィックスから派生したアドレスを使用してインターフェイスの番号を付け直します。 ISATAPクライアントはまた、最終的には非推奨のSLAACプレフィックスをアドレス選択ポリシーテーブルから削除する必要がありますが、このアクションはタイムクリティカルではありません。
Finally, site renumbering in the event of a change in an ISP-served IPv6 prefix further entails locating and rewriting all IPv6 addresses in naming services, databases, configuration files, packet filtering rules, documentation, etc. If the site has published the IPv6 addresses of any site-internal nodes within the public Internet DNS system, then the corresponding resource records will also need to be updated during the renumbering operation. This can be accomplished via secure dynamic updates to the DNS.
最後に、ISPが提供するIPv6プレフィックスが変更された場合のサイトの再番号付けでは、ネームサービス、データベース、構成ファイル、パケットフィルタリングルール、ドキュメントなどですべてのIPv6アドレスを見つけて書き換える必要があります。サイトがIPv6アドレスを公開している場合パブリックインターネットDNSシステム内のサイト内部ノードの場合、対応するリソースレコードも再番号付け操作中に更新する必要があります。これは、DNSへの安全な動的更新によって実現できます。
IPv6-in-IPv4 encapsulation overhead effectively reduces the size of IPv6 packets that can traverse the tunnel in relation to the actual Maximum Transmission Unit (MTU) of the underlying IPv4 network path between the tunnel ingress and egress. Two methods for accommodating IPv6 path MTU discovery over IPv6-in-IPv4 tunnels (i.e., the static and dynamic methods) are documented in Section 3.2 of [RFC4213].
IPv6-in-IPv4カプセル化オーバーヘッドは、トンネルの入口と出口の間の基盤となるIPv4ネットワークパスの実際の最大伝送ユニット（MTU）に関連して、トンネルを通過できるIPv6パケットのサイズを効果的に削減します。 IPv6-in-IPv4トンネルを介したIPv6パスMTU検出に対応する2つの方法（静的および動的な方法）は、[RFC4213]のセクション3.2に記載されています。
The static method places a "safe" upper bound on the size of IPv6 packets permitted to enter the tunnel; however, the method can be overly conservative when larger IPv4 path MTUs are available. The dynamic method can accommodate much larger IPv6 packet sizes in some cases, but can fail silently if the underlying IPv4 network path does not return the necessary error messages.
静的な方法では、トンネルに入ることが許可されるIPv6パケットのサイズに「安全な」上限を設定します。ただし、より大きなIPv4パスMTUが使用可能な場合、この方法は非常に保守的になる可能性があります。動的な方法では、はるかに大きなIPv6パケットサイズに対応できる場合がありますが、基盤となるIPv4ネットワークパスが必要なエラーメッセージを返さない場合は、通知なしで失敗する可能性があります。
This document notes that sites that include well-managed IPv4 links, routers, and other network middleboxes are candidates for use of the dynamic MTU determination method, which may provide for a better operational IPv6 experience in the presence of IPv6-in-IPv4 tunnels.
このドキュメントでは、適切に管理されたIPv4リンク、ルーター、およびその他のネットワークミドルボックスを含むサイトは、動的MTU決定方法を使用する候補であり、IPv6-in-IPv4トンネルの存在下でより良い運用IPv6エクスペリエンスを提供できる可能性があることに注意します。
Finally, since all ISATAP tunnels terminate at a host, transport protocols that perform packet-size negotiations will see an IPv6 MTU that accounts for the encapsulation headers and therefore will avoid sending encapsulated packets that exceed the IPv4 path MTU.
最後に、すべてのISATAPトンネルはホストで終了するため、パケットサイズネゴシエーションを実行するトランスポートプロトコルは、カプセル化ヘッダーを考慮したIPv6 MTUを認識し、IPv4パスMTUを超えるカプセル化されたパケットの送信を回避します。
[RFC4554] proposes a use of VLANs for IPv4-IPv6 coexistence in enterprise networks. The ISATAP approach provides a more flexible and broadly applicable alternative and with fewer administrative touch points.
[RFC4554]は、エンタープライズネットワークにおけるIPv4-IPv6共存のためのVLANの使用を提案しています。 ISATAPアプローチは、より柔軟で広く適用可能な代替手段を提供し、管理上のタッチポイントを減らします。
The tunnel broker service [RFC3053] uses point-to-point tunnels that require end users to establish an explicit administrative configuration of the tunnel's far end, which may be outside of the administrative boundaries of the site.
トンネルブローカーサービス[RFC3053]は、エンドユーザーがトンネルの遠端の明示的な管理構成を確立する必要があるポイントツーポイントトンネルを使用します。これは、サイトの管理境界の外側にある場合があります。
6to4 [RFC3056] and Teredo [RFC4380] provide "last resort" unmanaged automatic tunneling services when no other means for IPv6 connectivity is available. These services are given lower priority when the ISATAP managed service and/or native IPv6 services are enabled.
6to4 [RFC3056]とTeredo [RFC4380]は、IPv6接続の他の手段が利用できない場合に、「ラストリゾート」のアンマネージド自動トンネリングサービスを提供します。 ISATAPマネージドサービスやネイティブIPv6サービスが有効になっている場合、これらのサービスの優先度は低くなります。
6rd [RFC5969] enables a stateless prefix delegation capability based on IPv4-embedded IPv6 prefixes, whereas ISATAP enables a stateful prefix delegation capability based on native IPv6 prefixes.
6rd [RFC5969]はIPv4埋め込みIPv6プレフィックスに基づくステートレスプレフィックス委任機能を有効にしますが、ISATAPはネイティブIPv6プレフィックスに基づくステートフルプレフィックス委任機能を有効にします。
In addition to the security considerations documented in [RFC5214], sites that use ISATAP should take care to ensure that no routing loops are enabled [RFC6324]. Additional security concerns with IP tunneling are documented in [RFC6169].
[RFC5214]で文書化されているセキュリティの考慮事項に加えて、ISATAPを使用するサイトは、ルーティングループが有効にならないように注意する必要があります[RFC6324]。 IPトンネリングに関する追加のセキュリティ問題は[RFC6169]に文書化されています。
The following are acknowledged for their insights that helped shape this work: Dmitry Anipko, Fred Baker, Ron Bonica, Brian Carpenter, Remi Despres, Thomas Henderson, Philip Homburg, Lee Howard, Ray Hunter, Joel Jaeggli, John Mann, Gabi Nakibly, Christopher Palmer, Hemant Singh, Mark Smith, Ole Troan, and Gunter Van de Velde.
ドミトリーアニプコ、フレッドベイカー、ロンボニカ、ブライアンカーペンター、レミデスプレス、トーマスヘンダーソン、フィリップホンバーグ、リーハワード、レイハンター、ジョエルジャグリ、ジョンマン、ガビナクシブル、クリストファーパーマー、ヘマントシン、マークスミス、オレトローン、グンターヴァンデヴェルデ。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] Droms、R。、「IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[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月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[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、「Intra-Site Automatic Tunnel Addressing Protocol（ISATAP）」、RFC 5214、2008年3月。
[ADDR-SELECT] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing Address Selection Policy using DHCPv6", Work in Progress, April 2013.
[ADDR-SELECT]マツモトA.、藤崎T.、およびT. Chown、「DHCPv6を使用したアドレス選択ポリシーの配布」、作業中、2013年4月。
[ENT-IPv6] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment Guidelines", Work in Progress, February 2013.
[ENT-IPv6] Chittimaneni、K.、Chown、T.、Howard、L.、Kuarsingh、V.、Pouffary、Y。、およびE. Vyncke、「Enterprise IPv6 Deployment Guidelines」、Work in Progress、2013年2月。
[ISATAP-UPDATE] Templin, F., "ISATAP Updates", Work in Progress, May 2012.
[ISATAP-UPDATE] Templin、F。、「ISATAP Updates」、作業中、2012年5月。
[RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", RFC 1687, August 1994.
[RFC1687] Fleischman、E。、「IPngに関する大企業ユーザーの見解」、RFC 1687、1994年8月。
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999.
[RFC2491]アーミテージ、G。、シュルター、P。、ジョーク、M。、およびG.ハーター、「IPv6 over Non-Broadcast Multiple Access（NBMA）ネットワーク」、RFC 2491、1999年1月。
[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月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「Differentiated Services and Tunnels」、RFC 2983、2000年10月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053] Durand、A.、Fasano、P.、Guardini、I。、およびD. Lento、「IPv6 Tunnel Broker」、RFC 3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B。およびK.ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[RFC4057] Bound、J。、「IPv6 Enterprise Network Scenarios」、RFC 4057、2005年6月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：Tunneling IPv6 over UDP through Network Address Translations（NATs）」、RFC 4380、2006年2月。
[RFC4554] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks", RFC 4554, June 2006.
[RFC4554] Chown、T。、「エンタープライズネットワークにおけるIPv4-IPv6共存のためのVLANの使用」、RFC 4554、2006年6月。
[RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. Green, "IPv6 Enterprise Network Analysis - IP Layer 3 Focus", RFC 4852, April 2007.
[RFC4852] Bound、J.、Pouffary、Y.、Klynsma、S.、Chown、T。、およびD. Green、「IPv6 Enterprise Network Analysis-IP Layer 3 Focus」、RFC 4852、2007年4月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969]タウンズリーW.およびO.トローン、「IPv4インフラストラクチャでのIPv6迅速な導入（第6回）-プロトコル仕様」、RFC 5969、2010年8月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169] Krishnan、S.、Thaler、D。、およびJ. Hoagland、「IPトンネリングに関するセキュリティ上の懸念」、RFC 6169、2011年4月。
[RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", RFC 6324, August 2011.
[RFC6324]たぶん、G。およびF. Templin、「IPv6自動トンネルを使用したルーティングループ攻撃：問題の記述と提案された軽減策」、RFC 6324、2011年8月。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724] Thaler、D.、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、2012年9月。
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013.
[RFC6879] Jiang、S.、Liu、B。、およびB. Carpenter、「IPv6 Enterprise Network Renumbering Scenarios、Considerations、and Methods」、RFC 6879、2013年2月。
Author's Address
著者のアドレス
Fred L. Templin Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
フレッドL.テンプリンボーイングリサーチ＆テクノロジーP.O.ボックス3707 MC 7L-49シアトル、ワシントン州98124米国
EMail: fltemplin@acm.org