[要約] RFC 7755は、IPv6データセンター環境での状態を持たないIP/ICMP変換（SIIT-DC）についての要約です。その目的は、IPv4とIPv6の相互運用性を向上させ、データセンター内でのIPv6の採用を促進することです。
Internet Engineering Task Force (IETF) T. Anderson
Request for Comments: 7755 Redpill Linpro
Category: Informational February 2016
ISSN: 2070-1721
SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments
SIIT-DC：IPv6データセンター環境向けのステートレスIP / ICMP変換
Abstract
概要
This document describes the use of the Stateless IP/ICMP Translation Algorithm (SIIT) in an IPv6 Internet Data Center (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilization of public IPv4 addresses.
このドキュメントでは、IPv6インターネットデータセンター（IDC）でのステートレスIP / ICMP変換アルゴリズム（SIIT）の使用について説明します。この展開モデルでは、インターネット上のレガシーIPv4専用クライアントからのトラフィックは、IDCオペレーターのネットワークインフラストラクチャに到達するとIPv6に変換されます。それ以降は、ネイティブIPv6エンドユーザーからのトラフィックと同じように扱われる可能性があります。 IPv6エンドポイントには、任意の（IPv4で変換できない）IPv6アドレスを使用して番号を付けることができます。これにより、シングルスタックのIPv6のみのネットワークインフラストラクチャと、パブリックIPv4アドレスの効率的な利用が容易になります。
The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feeling that dual stack causes undesirable operational complexity.
主な対象者は、IPv6を展開している、利用可能なIPv4アドレスが不足している、および/またはデュアルスタックが望ましくない運用の複雑さを引き起こしていると感じているIDCオペレーターです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 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/rfc7755.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7755で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Single-Stack IPv6 Operation . . . . . . . . . . . . . . . 3
1.2. Stateless Operation . . . . . . . . . . . . . . . . . . . 4
1.3. IPv4 Address Conservation . . . . . . . . . . . . . . . . 4
1.4. Clients' IPv4 Source Addresses Visible to Applications . 5
1.5. Compatible with Standard IPv4 and IPv6 Stacks . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8
3.1. Packet Flow . . . . . . . . . . . . . . . . . . . . . . . 9
4. Deployment Considerations and Guidelines . . . . . . . . . . 10
4.1. Application/Device Support for IPv6 . . . . . . . . . . . 10
4.2. Application Support for NAT . . . . . . . . . . . . . . . 10
4.3. Application Communication Pattern . . . . . . . . . . . . 10
4.4. Choice of Translation Prefix . . . . . . . . . . . . . . 11
4.5. Routing Considerations . . . . . . . . . . . . . . . . . 12
4.6. Location of the SIIT-DC Border Relays . . . . . . . . . . 12
4.7. Migration from Dual Stack . . . . . . . . . . . . . . . . 13
4.8. Translation of ICMPv6 Errors to IPv4 . . . . . . . . . . 13
4.9. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 13
4.9.1. IPv4/IPv6 Header Size Difference . . . . . . . . . . 14
4.9.2. IPv6 Atomic Fragments . . . . . . . . . . . . . . . . 14
4.9.3. Minimum Path MTU Difference between IPv4 and IPv6 . . 15
4.10. IPv4-Translatable IPv6 Service Addresses . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Mistaking the Translation Prefix for a Trusted Network . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . 17
6.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Complete SIIT-DC IDC Topology Example . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
Historically, dual stack [RFC4213] [RFC6883] has been the recommended way to transition from a legacy IPv4-only environment to one capable of serving IPv6 users. However, for IDC operators, dual-stack operation has a number of disadvantages compared to single-stack operation. In particular, running two protocols rather than one results in increased complexity and operational overhead with little return on investment for as long as large parts of the public Internet remains predominantly IPv4 only. Furthermore, the dual-stack approach does not in any way help with the depletion of the IPv4 address space, which at the time of writing is a pressing concern in most parts of the world.
従来、デュアルスタック[RFC4213] [RFC6883]は、レガシーIPv4のみの環境からIPv6ユーザーにサービスを提供できる環境に移行するための推奨方法でした。ただし、IDCオペレーターにとって、デュアルスタック操作には、シングルスタック操作に比べて多くの欠点があります。特に、1つではなく2つのプロトコルを実行すると、パブリックインターネットの大部分が主にIPv4のみである限り、投資収益率がほとんどなく、複雑さと運用オーバーヘッドが増加します。さらに、デュアルスタックアプローチは、IPv4アドレス空間の枯渇を決して助けません。これは、執筆時点では世界のほとんどの地域で差し迫った懸念事項です。
Therefore, some IDC operators may instead prefer an approach in which they only need to operate one protocol in the data center as they prepare for the future. Stateless IP/ICMP Translation for IPv6 Data Center Environments (SIIT-DC) is one such approach. Its design goals include:
したがって、一部のIDCオペレーターは、将来に備えてデータセンターで1つのプロトコルのみを操作する必要があるアプローチを好む場合があります。 IPv6データセンター環境向けのステートレスIP / ICMP変換（SIIT-DC）は、そのようなアプローチの1つです。その設計目標は次のとおりです。
o Promote the deployment of native IPv6 services (cf. [RFC6540]).
o ネイティブIPv6サービスの展開を促進します（[RFC6540]を参照）。
o Provide IPv4 service availability for legacy users with no loss of performance or functionality.
o パフォーマンスや機能を損なうことなく、レガシーユーザーにIPv4サービスの可用性を提供します。
o Ensure that the legacy users' IPv4 addresses remain visible to the nodes and applications located in the IPv6 network.
o レガシーユーザーのIPv4アドレスが、IPv6ネットワークにあるノードとアプリケーションに表示されたままであることを確認します。
o Conserve and maximize the utilization of the operator's public IPv4 addresses.
o オペレーターのパブリックIPv4アドレスの使用を節約および最大化します。
o Avoid introducing more complexity than absolutely necessary, especially on the nodes and applications.
o 特にノードとアプリケーションでは、絶対に必要以上に複雑になることを避けてください。
o Easy to scale and deploy in a fault-tolerant manner.
o フォールトトレラントな方法で簡単にスケーリングおよび展開できます。
The following subsections elaborate on how SIIT-DC meets these goals.
以下のサブセクションでは、SIIT-DCがこれらの目標をどのように達成するかについて詳しく説明します。
SIIT-DC allows IDC operators to build their infrastructure and applications on an IPv6-only foundation. IPv4 end-user connectivity becomes a service provided by the network, which systems administration and application development staff do not need to concern themselves with. This promotes universal IPv6 deployment for the IDC operator's services and applications.
SIIT-DCを使用すると、IDCオペレーターはインフラストラクチャとアプリケーションをIPv6のみの基盤上に構築できます。 IPv4エンドユーザー接続は、ネットワークによって提供されるサービスになるため、システム管理およびアプリケーション開発のスタッフは自分で考慮する必要はありません。これにより、IDCオペレーターのサービスとアプリケーションのユニバーサルIPv6展開が促進されます。
SIIT-DC requires no special support or change from the underlying IPv6 infrastructure; it is compatible with all standard IPv6 networks. Traffic between IPv6-enabled end users and IPv6-enabled services will always be transported native end to end; SIIT-DC does not intercept or handle native IPv6 traffic at all.
SIIT-DCは、特別なサポートや基盤となるIPv6インフラストラクチャからの変更を必要としません。すべての標準IPv6ネットワークと互換性があります。 IPv6対応のエンドユーザーとIPv6対応のサービス間のトラフィックは、常にネイティブエンドツーエンドで転送されます。 SIIT-DCはネイティブIPv6トラフィックをまったく傍受または処理しません。
When the day comes to discontinue all support for IPv4, no change needs to be made to the overall architecture -- it's only a matter of shutting off the SIIT-DC Border Relays (BRs). Operators who deploy native IPv6 along with SIIT-DC will thus avoid requiring any future migration or deployment projects relating to IPv6 deployment and/or IPv4 sunsetting.
IPv4のすべてのサポートを中止する日が来たら、アーキテクチャ全体に変更を加える必要はありません。それは、SIIT-DCボーダーリレー（BR）を停止することだけです。したがって、SIIT-DCとともにネイティブIPv6を展開するオペレーターは、IPv6の展開やIPv4の廃止に関連する将来の移行または展開プロジェクトを必要としなくなります。
Unlike other solutions that provide either dual-stack availability to single-stack services (e.g., Stateful Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) [RFC6146] and Layer 4/7 proxies) or conservation of IPv4 addresses (e.g., IPv4 address translation (NAPT44) [RFC3022]), SIIT-DC does not maintain any state associated with individual connections or flows. In this sense, it operates exactly like a regular IP router and has similar scaling properties -- the limiting factors are packets per second and bandwidth. The number of concurrent flows and flow initiation rates are irrelevant for performance.
シングルスタックサービスにデュアルスタックの可用性を提供する他のソリューションとは異なり（たとえば、IPv6クライアントからIPv4サーバー（NAT64）[RFC6146]およびレイヤー4/7プロキシへのステートフルネットワークアドレスおよびプロトコル変換）、またはIPv4アドレスの保存（たとえば、IPv4アドレス変換（NAPT44）[RFC3022]）、SIIT-DCは、個々の接続またはフローに関連付けられた状態を維持しません。この意味で、通常のIPルーターとまったく同じように動作し、同様のスケーリングプロパティがあります。制限要因は、1秒あたりのパケット数と帯域幅です。同時フローの数とフロー開始率は、パフォーマンスには関係ありません。
This not only allows individual BRs to easily attain "line-rate" performance, but it also allows for per-packet load balancing between multiple BRs using Equal-Cost Multipath Routing [RFC2991]. Asymmetric routing is also acceptable, which makes it easy to avoid suboptimal traffic patterns; the prefixes involved may be anycasted from all the BRs in the provider's network, thus ensuring that the most optimal path through the network is used, even where the optimal path in one direction differs from the optimal path in the opposite direction.
これにより、個々のBRが「ラインレート」のパフォーマンスを簡単に達成できるだけでなく、等コストマルチパスルーティング[RFC2991]を使用して、複数のBR間のパケットごとのロードバランシングも可能になります。非対称ルーティングも許容され、最適でないトラフィックパターンを簡単に回避できます。含まれるプレフィックスはプロバイダーのネットワーク内のすべてのBRからエニーキャストできるため、ある方向の最適パスが反対方向の最適パスと異なる場合でも、ネットワークを介した最適パスが確実に使用されます。
Finally, stateless operation means that high availability is easily achieved. If a BR should fail, its traffic can be rerouted onto another BR using a standard IP routing protocol. This does not impact existing flows any more than what any other IP rerouting event would.
最後に、ステートレス操作とは、高可用性を簡単に実現できることを意味します。 BRに障害が発生した場合、そのトラフィックは、標準のIPルーティングプロトコルを使用して別のBRに再ルーティングできます。これは、他のIP再ルーティングイベントよりも既存のフローに影響を与えません。
In most parts of the world, it is difficult or even impossible to obtain generously sized IPv4 delegations from the Internet Numbers Registry System [RFC7020]. The resulting scarcity in turn impacts individual end users and operators, whom might be forced to purchase IPv4 addresses from other operators in order to cover their needs. This process can be risky to business continuity, in the case where no suitable block for sale can be located, and/or turn out to be prohibitively expensive. In spite of this, an IDC operator will find that providing IPv4 service remains essential, as a large share of the Internet end users still do not have IPv6 connectivity.
世界のほとんどの地域では、Internet Numbers Registry System [RFC7020]から十分なサイズのIPv4委任を取得することは困難または不可能ですらあります。結果として生じる不足は、個々のエンドユーザーとオペレーターに影響を与えます。これらのエンドユーザーとオペレーターは、ニーズをカバーするために他のオペレーターからIPv4アドレスを購入しなければならない場合があります。このプロセスは、販売に適したブロックが見つからない場合、および/または法外に高額であることが判明した場合、ビジネス継続性にリスクをもたらす可能性があります。これにもかかわらず、IDCオペレーターは、インターネットエンドユーザーの大部分がまだIPv6接続を持っていないため、IPv4サービスの提供が依然として不可欠であることがわかります。
A key goal of SIIT-DC is to help reduce a data center operator's IPv4 address requirement to the absolute minimum by allowing the operator to remove them entirely from nodes and applications that do not need to communicate with endpoints in the IPv4 Internet. One example would be servers that are operating in a supporting/backend role and only communicating with other servers (database servers, file servers, and so on). Another example would be the network infrastructure itself (router-to-router links, loopback addresses, and so on). Furthermore, as LAN prefix sizes must always be rounded up to the nearest power of two (or larger if one reserves space for future growth), even more IPv4 addresses will often end up being wasted without even being used.
SIIT-DCの主要な目標は、IPv4インターネット内のエンドポイントと通信する必要のないノードおよびアプリケーションからオペレーターが完全にそれらを削除できるようにすることで、データセンターオペレーターのIPv4アドレス要件を最小限に抑えるのに役立つことです。 1つの例は、サポート/バックエンドの役割で動作し、他のサーバー（データベースサーバー、ファイルサーバーなど）とのみ通信するサーバーです。別の例は、ネットワークインフラストラクチャ自体（ルーター間のリンク、ループバックアドレスなど）です。さらに、LANプレフィックスサイズは常に最も近い2の累乗（または、将来の拡張のためにスペースを予約する場合はそれ以上）に切り上げられる必要があるため、さらに多くのIPv4アドレスが使用されずに無駄になることがよくあります。
With SIIT-DC, the operator can remove these valuable IPv4 addresses from his backend servers and network infrastructure and reassign them to the SIIT-DC service as IPv4 Service Addresses. There exists no requirement that IPv4 Service Addresses are to be assigned in an aggregated manner, so there is nothing lost due to infrastructure overhead; every single IPv4 address assigned to SIIT-DC can be used as an IPv4 Service Address.
SIIT-DCを使用すると、オペレーターはこれらの貴重なIPv4アドレスをバックエンドサーバーとネットワークインフラストラクチャから削除し、IPv4サービスアドレスとしてSIIT-DCサービスに再割り当てできます。 IPv4サービスアドレスを集約的に割り当てる必要はないため、インフラストラクチャのオーバーヘッドによる損失はありません。 SIIT-DCに割り当てられたすべてのIPv4アドレスは、IPv4サービスアドレスとして使用できます。
SIIT-DC uses the [RFC6052] algorithm to map the entire end-user's IPv4 source address into a predefined IPv6 translation prefix. This ensures that there is no loss of information; the end-user's IPv4 source address remains available to the application located in the IPv6 network, allowing it to perform tasks like geolocation, logging, abuse handling, and so forth.
SIIT-DCは[RFC6052]アルゴリズムを使用して、エンドユーザーのIPv4送信元アドレス全体を事前定義されたIPv6変換プレフィックスにマッピングします。これにより、情報の損失がないことが保証されます。エンドユーザーのIPv4送信元アドレスはIPv6ネットワークにあるアプリケーションで引き続き使用できるため、地理位置情報、ロギング、不正使用の処理などのタスクを実行できます。
Except for the introduction of the BRs themselves, no change to the network, nodes, applications, or anything else is required in order to support SIIT-DC. SIIT-DC is practically invisible from the point of view of the IPv4 clients, the IPv6 nodes, the IPv6 data center network, and the IPv4 Internet. SIIT-DC interoperates with all standards-compliant IPv4 or IPv6 stacks.
BR自体の導入を除いて、SIIT-DCをサポートするために、ネットワーク、ノード、アプリケーション、またはその他に変更を加える必要はありません。 SIIT-DCは、IPv4クライアント、IPv6ノード、IPv6データセンターネットワーク、およびIPv4インターネットの観点からは事実上見えません。 SIIT-DCは、標準に準拠したすべてのIPv4またはIPv6スタックと相互運用します。
This document makes use of the following terms:
このドキュメントでは、次の用語を使用しています。
SIIT-DC Border Relay (BR): A device or a logical function that performs stateless protocol translation between IPv4 and IPv6. It MUST do so in accordance with [RFC6145] and [RFC7757].
SIIT-DCボーダーリレー（BR）：IPv4とIPv6の間でステートレスプロトコル変換を実行するデバイスまたは論理機能。それは[RFC6145]と[RFC7757]に従ってそうしなければなりません。
SIIT-DC Edge Relay (ER): A device or logical function that provides "native" IPv4 connectivity to IPv4-only devices or application software. It is very similar in function to a BR but is typically located close to the IPv4-only component(s) it is supporting rather than on the IDC's outer network border. The ER is an optional component of SIIT-DC. It is discussed in more detail in [RFC7756].
SIIT-DCエッジリレー（ER）：IPv4専用デバイスまたはアプリケーションソフトウェアへの「ネイティブ」IPv4接続を提供するデバイスまたは論理機能。機能はBRと非常に似ていますが、通常はIDCの外部ネットワーク境界ではなく、サポートしているIPv4のみのコンポーネントの近くにあります。 ERはSIIT-DCのオプションコンポーネントです。それは[RFC7756]でより詳細に議論されます。
IPv4 Service Address: An IPv4 address representing a node or service located in an IPv6 network. It is coupled with an IPv6 Service Address using an Explicit Address Mapping (EAM). Packets sent to this address are translated to IPv6 by the BR, and possibly back to IPv4 by an ER, before reaching the node or service.
IPv4サービスアドレス：IPv6ネットワークにあるノードまたはサービスを表すIPv4アドレス。明示的アドレスマッピング（EAM）を使用してIPv6サービスアドレスと結合されます。このアドレスに送信されたパケットは、ノードまたはサービスに到達する前に、BRによってIPv6に変換され、ERによってIPv4に戻される可能性があります。
IPv4 Service Address Pool: One or more IPv4 prefixes routed to the BR's IPv4 interface. IPv4 Service Addresses are allocated from this pool. This does not necessarily have to be a "pool" per se, as it could also be one or more host routes (whose prefix lengths are equal to /32). The purpose of using a pool rather than host routes is to facilitate IPv4 route aggregation and ease provisioning of new IPv4 Service Addresses.
IPv4サービスアドレスプール：BRのIPv4インターフェースにルーティングされる1つ以上のIPv4プレフィックス。 IPv4サービスアドレスは、このプールから割り当てられます。これは、1つ以上のホストルート（プレフィックスの長さが/ 32に等しい）の場合もあるので、必ずしもそれ自体が「プール」である必要はありません。ホストルートではなくプールを使用する目的は、IPv4ルートの集約を容易にし、新しいIPv4サービスアドレスのプロビジョニングを容易にすることです。
IPv6 Service Address: An IPv6 address assigned to an application, node, or service either directly or indirectly (through an ER). It is coupled with an IPv4 Service Address using an EAM. IPv4-only clients communicate with the IPv6 Service Address through SIIT-DC.
IPv6サービスアドレス：アプリケーション、ノード、またはサービスに直接または（ERを介して）間接的に割り当てられたIPv6アドレス。 EAMを使用してIPv4サービスアドレスと結合されます。 IPv4のみのクライアントは、SIIT-DCを介してIPv6サービスアドレスと通信します。
Explicit Address Mapping (EAM): A bidirectional coupling between an IPv4 Service Address and an IPv6 Service Address configured in a BR or ER. When translating between IPv4 and IPv6, the BR/ER changes the address fields in the translated packet's IP header according to any matching EAM. The EAM algorithm is specified in [RFC7757].
明示アドレスマッピング（EAM）：BRまたはERで構成されたIPv4サービスアドレスとIPv6サービスアドレス間の双方向結合。 IPv4とIPv6の間で変換する場合、BR / ERは、一致するEAMに従って、変換されたパケットのIPヘッダーのアドレスフィールドを変更します。 EAMアルゴリズムは[RFC7757]で指定されています。
Translation Prefix: An IPv6 prefix into which the entire IPv4 address space is mapped, according to the algorithm in [RFC6052]. The translation prefix is routed to the BR's IPv6 interface. When translating between IPv4 and IPv6, a BR/ER will insert/remove the translation prefix into/from the address fields in the translated packet's IP header, unless an EAM exists for the IP address that is being translated.
変換プレフィックス：[RFC6052]のアルゴリズムに従って、IPv4アドレス空間全体がマップされるIPv6プレフィックス。変換プレフィックスは、BRのIPv6インターフェイスにルーティングされます。 IPv4とIPv6の間で変換する場合、BR / ERは、変換されるIPアドレスにEAMが存在しない限り、変換されたパケットのIPヘッダーのアドレスフィールドに変換プレフィックスを挿入/削除します。
IPv4-Translatable IPv6 Addresses: As defined in Section 1.3 of [RFC6052].
IPv4-Translatable IPv6 Addresses：[RFC6052]のセクション1.3で定義されています。
IDC: Short for "Internet Data Center"; a data center whose main purpose is to deliver services to the public Internet. SIIT-DC is primarily targeted at being deployed in an IDC. An IDC is typically operated by an Internet Content Provider or a Managed Services Provider.
IDC：「インターネットデータセンター」の略。公共のインターネットにサービスを提供することを主な目的とするデータセンター。 SIIT-DCは、主にIDCでの展開を対象としています。 IDCは通常、インターネットコンテンツプロバイダーまたはマネージドサービスプロバイダーによって運営されています。
SIIT: The Stateless IP/ICMP Translation Algorithm, as specified in [RFC6145].
SIIT：[RFC6145]で指定されているステートレスIP / ICMP変換アルゴリズム。
XLAT: Short for "Translation". Used in figures to indicate where a BR/ ER uses SIIT [RFC6145] to translate IPv4 packets to IPv6 and vice versa.
XLAT：「Translation」の略。図で使用され、BR / ERがSIIT [RFC6145]を使用してIPv4パケットをIPv6に、またはその逆に変換する場所を示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This section describes the basic SIIT-DC architecture.
このセクションでは、基本的なSIIT-DCアーキテクチャについて説明します。
IPv6-capable user IPv4-only user
<2001:db8::ab:cd> <203.0.113.50>
| |
(the IPv6 Internet) (the IPv4 Internet)
| |
| +-[BR]---------<192.0.2.0/24>--------------+
| | |
| | EAM #1: 192.0.2.1,2001:db8:12:34::1 |
| | EAM #2..#n: [...] |
| | XLAT Prefix: 2001:db8:46::/96 |
| | |
| +------------<2001:db8:46::/96>------------+
| |
(the IPv6-only data center network)
|
+--<2001:db8:12:34::1>--[v6-only server]-+
| | |
| +-[2001:db8:12:34::1]--[v6-only app]-+ |
| | AF_INET6 socket | |
| +------------------------------------+ |
+----------------------------------------+
Figure 1: SIIT-DC Architecture
図1：SIIT-DCアーキテクチャ
In Figure 1, 192.0.2.0/24 is the IPv4 Service Address Pool. Individual IPv4 Service Addresses are assigned from this prefix, and traffic destined for it is routed to the BR's IPv4-facing network interface. There are no restrictions on how many IPv4 Service Address Pools are used or their prefix length, as long as they are all routed to the BR's IPv4-facing network interface.
図1では、192.0.2.0 / 24がIPv4サービスアドレスプールです。個々のIPv4サービスアドレスはこのプレフィックスから割り当てられ、それを宛先とするトラフィックはBRのIPv4に面したネットワークインターフェイスにルーティングされます。すべてがBRのIPv4に面するネットワークインターフェイスにルーティングされる限り、使用されるIPv4サービスアドレスプールの数またはそれらのプレフィックス長に制限はありません。
When translating packets between IPv4 and IPv6, the BR uses EAM #1 to replace any occurrence of the IPv4 Service Address (192.0.2.1) with its corresponding IPv6 Service Address (2001:db8:12:34::1). Addresses that do not match any EAM configured in the BR are translated by inserting or removing the translation prefix (2001:db8:46::/96); cf. Section 2.2 of [RFC6052].
IPv4とIPv6の間でパケットを変換する場合、BRはEAM＃1を使用して、IPv4サービスアドレス（192.0.2.1）を対応するIPv6サービスアドレス（2001：db8：12：34 :: 1）に置き換えます。 BRで構成されているどのEAMとも一致しないアドレスは、変換プレフィックス（2001：db8：46 :: / 96）を挿入または削除することによって変換されます。 cf. [RFC6052]のセクション2.2。
The BR can be deployed as a separate device or as a logical function in another multipurpose device, such as an IP router. Any number of BRs may exist simultaneously in the IDC's network infrastructure, as long as they are all configured with the same translation prefix and an identical EAM Table.
BRは、個別のデバイスとして、またはIPルーターなどの別の多目的デバイスの論理機能として展開できます。すべてが同じ変換プレフィックスと同一のEAMテーブルで構成されている限り、IDCのネットワークインフラストラクチャに同時に存在するBRの数はいくつでもかまいません。
The IPv6 Service Address should be registered in DNS using an "IN AAAA" record, while its corresponding IPv4 Service Address should be registered using an "IN A" record. This ensures that IPv6-capable clients access the application/service directly using native IPv6 end to end, while IP4-only clients will access it through SIIT-DC.
IPv6サービスアドレスは「IN AAAA」レコードを使用してDNSに登録する必要がありますが、対応するIPv4サービスアドレスは「IN A」レコードを使用して登録する必要があります。これにより、IPv4対応のクライアントがSIIT-DCを介してアクセスするのに対し、IPv6対応のクライアントはネイティブIPv6エンドツーエンドを使用してアプリケーション/サービスに直接アクセスできます。
In this example, the "IPv4-only user" from Figure 1 initiates a connection to the application running on the IPv6-only server. After first having looked up the "IN A" record in DNS, the user starts by transmitting a TCP SYN packet to the IPv4 Service Address. This IPv4 packet is routed to the BR and is there translated to IPv6 as follows:
この例では、図1の「IPv4専用ユーザー」がIPv6専用サーバーで実行されているアプリケーションへの接続を開始します。最初にDNSで「IN A」レコードを検索した後、ユーザーはTCP SYNパケットをIPv4サービスアドレスに送信することから始めます。このIPv4パケットはBRにルーティングされ、そこで次のようにIPv6に変換されます。
+--[IPv4]----------+ +--[IPv6]-----------------------+
| SRC 203.0.113.50 | | SRC 2001:db8:46::203.0.113.50 |
| DST 192.0.2.1 | --> | DST 2001:db8:12:34::1 |
| TCP SYN [..] | | TCP SYN [..] |
+------------------+ +-------------------------------+
Figure 2: IPv4-to-IPv6 Translation
図2：IPv4-to-IPv6変換
The resulting IPv6 packet is routed to the IPv6-only server, which processes and responds to it as if it had been a native IPv6 packet all along. The server's IPv6 response packet is then routed back to the BR, where it is translated back to IPv4 as follows:
結果のIPv6パケットはIPv6専用サーバーにルーティングされ、サーバーはそれが本来のIPv6パケットであるかのように処理して応答します。次に、サーバーのIPv6応答パケットはBRにルーティングされます。ここで、パケットは次のようにIPv4に変換されます。
+--[IPv6]-----------------------+ +--[IPv4]----------+
| SRC 2001:db8:12:34::1 | | SRC 192.0.2.1 |
| DST 2001:db8:46::203.0.113.50 | --> | DST 203.0.113.50 |
| TCP SYN/ACK [..] | | TCP SYN/ACK [..] |
+-------------------------------+ +------------------+
Figure 3: IPv6-to-IPv4 Translation
図3：IPv6-to-IPv4変換
It is important to note that neither the IPv4 client nor the IPv6 server/application need any special support to participate in SIIT-DC. However, the application may optionally be taught to extract the embedded IPv4 source address from incoming IPv6 packets with source addresses within the translation prefix. This will allow it to perform IPv4-specific tasks such as geolocation, logging, abuse handling, and so on.
IPv4クライアントもIPv6サーバー/アプリケーションもSIIT-DCに参加するために特別なサポートを必要としないことに注意することが重要です。ただし、アプリケーションは、オプションで、変換プレフィックス内のソースアドレスを持つ着信IPv6パケットから埋め込みIPv4ソースアドレスを抽出するように教えることができます。これにより、地理位置情報、ロギング、乱用処理などのIPv4固有のタスクを実行できます。
SIIT-DC as described in this document requires that the application (and/or the node the application is located on) supports IPv6 networking and that it has no dependency on local IPv4 network connectivity.
このドキュメントで説明されているSIIT-DCでは、アプリケーション（またはアプリケーションが配置されているノード、あるいはその両方）がIPv6ネットワークをサポートし、ローカルIPv4ネットワーク接続に依存していないことが必要です。
SIIT-DC can, however, support legacy IPv4-dependent applications and nodes through the introduction of an ER. The ER provides the legacy application or node with seemingly native IPv4 Internet connectivity, so that it may operate correctly in an otherwise IPv6-only network environment. This approach is described in more detail in [RFC7756].
ただし、SIIT-DCは、ERの導入により、レガシーIPv4に依存するアプリケーションとノードをサポートできます。 ERは、一見ネイティブのIPv4インターネット接続を備えたレガシーアプリケーションまたはノードを提供するため、それ以外の場合はIPv6のみのネットワーク環境で正しく動作する可能性があります。このアプローチは、[RFC7756]でより詳細に説明されています。
The operator should carefully examine whether or not the application protocols he would like to use SIIT-DC with are able to operate in a network environment where rewriting of IP addresses occurs. In general, if an application-layer protocol works correctly through standard NAT44 (see [RFC3235]), it will most likely work correctly through SIIT-DC as well.
オペレーターは、SIIT-DCを使用するアプリケーションプロトコルが、IPアドレスの書き換えが発生するネットワーク環境で動作できるかどうかを慎重に検討する必要があります。一般に、アプリケーション層プロトコルが標準NAT44（[RFC3235]を参照）を介して正しく機能する場合、SIIT-DCを介しても正しく機能する可能性が高いです。
Higher-level protocols that embed IP addresses as part of their payload are particularly problematic [RFC2663] [RFC2993] [RFC3022]. One well-known example of such a protocol is FTP [RFC959]. Such protocols can be made to work with SIIT-DC through the introduction of an ER, which provides end-to-end IPv4 address transparency by reversing the translations performed by the BR before passing the packets to the NAT-incompatible application. This approach is described in more detail in [RFC7756].
ペイロードの一部としてIPアドレスを埋め込む上位レベルのプロトコルは、特に問題があります[RFC2663] [RFC2993] [RFC3022]。そのようなプロトコルのよく知られた例の1つはFTP [RFC959]です。そのようなプロトコルは、ERの導入を通じてSIIT-DCと連携するように作成できます。ERは、パケットをNATと互換性のないアプリケーションに渡す前にBRによって実行される変換を逆にすることにより、エンドツーエンドのIPv4アドレスの透過性を提供します。このアプローチは、[RFC7756]でより詳細に説明されています。
SIIT-DC is best suited for traditional client/server applications where IPv4-only clients on the Internet initiate traffic towards an IPv6-only service, which in turn is passively listening for inbound traffic and responding as necessary. In this case, an IPv4 client looks exactly like a native IPv6 client from the IPv6 service's point of view and thus does not require any special treatment. One particularly common application protocol that follows this client/ server communication pattern, and thus is ideally suited for use with SIIT-DC, is HTTP [RFC7230].
SIIT-DCは、インターネット上のIPv4のみのクライアントがIPv6のみのサービスへのトラフィックを開始する従来のクライアント/サーバーアプリケーションに最適です。IPv6のみのサービスは、受信トラフィックを受動的にリッスンし、必要に応じて応答します。この場合、IPv4クライアントは、IPv6サービスの観点からはネイティブIPv6クライアントとまったく同じに見えるため、特別な処理は必要ありません。このクライアント/サーバー通信パターンに従い、SIIT-DCでの使用に理想的な1つの特に一般的なアプリケーションプロトコルは、HTTP [RFC7230]です。
It is also possible to combine SIIT-DC with DNS64 [RFC6147] in order to allow an IPv6-only application to initiate communication with IPv4-only nodes through SIIT-DC. However, in this case, care must be taken so that all outgoing communication is sourced from an IPv6 Service Address that is found in an EAM configured in the BR. If another address is used, the BR will most likely be unable to translate it to IPv4, causing the packet to be discarded. This could be prevented by altering the Default Address Selection Policy Table [RFC6724] on the IPv6 node.
また、IPv6のみのアプリケーションがSIIT-DCを介してIPv4のみのノードとの通信を開始できるようにするために、SIIT-DCをDNS64 [RFC6147]と組み合わせることが可能です。ただし、この場合、すべての発信通信がBRで構成されたEAMにあるIPv6サービスアドレスから発信されるように注意する必要があります。別のアドレスが使用されている場合、BRはそのアドレスをIPv4に変換できず、パケットが廃棄される可能性があります。これは、IPv6ノードのデフォルトアドレス選択ポリシーテーブル[RFC6724]を変更することで防止できます。
An alternative approach to the above would be to place an ER in front of the application in question, as described in [RFC7756]. This provides the application with seemingly native IPv4 connectivity, which it may use freely for bidirectional communication with the IPv4 Internet. An application or node located behind an ER does not need to worry about selecting a specific source address, as it will only have valid options available.
上記の代替アプローチは、[RFC7756]で説明されているように、問題のアプリケーションの前にERを配置することです。これにより、アプリケーションに一見ネイティブなIPv4接続が提供され、IPv4インターネットとの双方向通信に自由に使用できます。 ERの背後にあるアプリケーションまたはノードは、有効なオプションしか利用できないため、特定の送信元アドレスを選択することを心配する必要はありません。
Either a Network-Specific Prefix (NSP) from the provider's own IPv6 address space or the IANA-allocated Well-Known Prefix (WKP) 64:ff9b::/96 may be used. From a technical point of view, both work equally well. However, only a single WKP exists, so if a provider would like to deploy more than one instance of SIIT-DC in his network, or another translation technology such as Stateful NAT64 [RFC6146], the operator will be forced to use an NSP for all but one of those deployments.
プロバイダー独自のIPv6アドレス空間からのネットワーク固有のプレフィックス（NSP）またはIANAによって割り当てられた既知のプレフィックス（WKP）64：ff9b :: / 96を使用できます。技術的な観点から見ると、どちらも同じように機能します。ただし、存在するWKPは1つだけであるため、プロバイダーがネットワークに複数のSIIT-DCのインスタンス、またはステートフルNAT64 [RFC6146]などの別の変換テクノロジを展開する場合、オペレーターはNSPを使用する必要があります。これらのデプロイメントの1つを除くすべて。
Another consideration is that the WKP cannot be used in inter-domain routing. By using an NSP instead, SIIT-DC will support a deployment where the BR and the IPv6 Service Address are located in different Autonomous Systems.
別の考慮事項は、WKPをドメイン間ルーティングで使用できないことです。代わりにNSPを使用することにより、SIIT-DCは、BRとIPv6サービスアドレスが異なる自律システムに配置されている展開をサポートします。
The translation prefix may use any of the lengths described in Section 2.2 of [RFC6052], but /96 has two distinct advantages over the others. First, converting it to IPv4 can be done in a single operation by simply stripping off the first 96 bits; second, it allows for IPv4 addresses to be embedded directly into the text representation of an IPv6 address using the familiar dotted quad notation, e.g., "2001:db8::198.51.100.10" (cf. Section 2.4 of [RFC6052]), instead of being converted to hexadecimal notation. This makes it easier to write literal IPv6 addresses (e.g., in ACLs) that correspond to translated endpoints in the IPv4 Internet.
翻訳接頭辞には、[RFC6052]のセクション2.2で説明されている長さのいずれかを使用できますが、/ 96には、他の2つの明確な利点があります。まず、IPv4への変換は、最初の96ビットを削除するだけで、1回の操作で実行できます。次に、代わりに、よく知られたドット付き4進表記を使用して、IPv4アドレスをIPv6アドレスのテキスト表現に直接埋め込むことができます。たとえば、「2001：db8 :: 198.51.100.10」（[RFC6052]のセクション2.4を参照） 16進表記に変換されます。これにより、IPv4インターネットの変換されたエンドポイントに対応するリテラルIPv6アドレス（ACLなど）を簡単に記述できます。
For the reasons discussed above, this document recommends that an NSP with a prefix length of /96 be used. Section 3.3 of [RFC6052] discusses the choice of the translation prefix in more detail.
上記の理由により、このドキュメントでは、プレフィックス長が/ 96のNSPを使用することを推奨しています。 [RFC6052]のセクション3.3では、翻訳接頭辞の選択について詳しく説明しています。
The prefixes that constitute the IPv4 Service Address Pool and the IPv6 translation prefix may be routed to the BRs like any other IPv4 or IPv6 route in the provider's network. If more than one BR is being deployed, it is recommended that a routing protocol (IGP) be used to advertise the routes within the provider's network. This will ensure that the traffic that is to be translated will reach the closest BR, reducing or eliminating suboptimal traffic patterns as well as providing high availability: should one BR fail, the IGP will automatically redirect the traffic to the closest alternate BR.
IPv4サービスアドレスプールを構成するプレフィックスとIPv6変換プレフィックスは、プロバイダーのネットワーク内の他のIPv4またはIPv6ルートと同様にBRにルーティングできます。複数のBRが展開されている場合は、ルーティングプロトコル（IGP）を使用してプロバイダーのネットワーク内のルートをアドバタイズすることをお勧めします。これにより、変換されるトラフィックが最も近いBRに確実に到達し、次善のトラフィックパターンを削減または排除し、高可用性を提供します。1つのBRに障害が発生した場合、IGPはトラフィックを最も近い代替BRに自動的にリダイレクトします。
The goal of SIIT-DC is to facilitate a true IPv6-only application and network architecture, with the sole exception being the IPv4 interfaces of the BRs and the network infrastructure required to connect the BRs to the IPv4 Internet. Therefore, the BRs must be located somewhere between the IPv4 Internet and the application delivery stack, which includes all servers, load balancers, firewalls, intrusion detection systems, and similar devices that are processing traffic to a greater extent than merely forwarding it.
SIIT-DCの目標は、BRのIPv4インターフェイスとBRをIPv4インターネットに接続するために必要なネットワークインフラストラクチャを除いて、真のIPv6のみのアプリケーションとネットワークアーキテクチャを容易にすることです。したがって、BRはIPv4インターネットとアプリケーション配信スタックの間のどこかに配置する必要があります。これには、すべてのサーバー、ロードバランサー、ファイアウォール、侵入検知システム、およびトラフィックを単に転送するよりも広範囲にトラフィックを処理する同様のデバイスが含まれます。
It is optimal to place the BRs as close as possible to the direct path between the location of the IPv6 Service Address and the end users. If the closest BR was located a long way from the direct path, all packets in both directions must make a detour in order to traverse the BR. This would increase the RTT between the service and the end user by two times the extra latency incurred by the detour, as well as cause unnecessary load on the network links on the detour path.
BRは、IPv6サービスアドレスの場所とエンドユーザーの間の直接パスのできるだけ近くに配置するのが最適です。最も近いBRが直接パスから遠く離れている場合、BRを通過するためには、両方向のすべてのパケットが迂回する必要があります。これにより、サービスとエンドユーザー間のRTTが、迂回によって発生する余分なレイテンシの2倍に増加し、迂回パス上のネットワークリンクに不要な負荷が発生します。
Where possible, it is beneficial to implement the BRs as a logical function within the routers that also handle the native IPv6 traffic between the IPv6 Service Address and the IPv6 Internet. This way, an SIIT-DC deployment does not require separate networks ports (which might become saturated and impact the service quality) nor will it require extra rack space and energy. Some particularly good choices for the location could be within the IDC's access routers or within the Autonomous System's border routers.
可能な場合は、ルーター内の論理機能としてBRを実装し、IPv6サービスアドレスとIPv6インターネット間のネイティブIPv6トラフィックも処理することが有益です。このように、SIIT-DCの展開では、個別のネットワークポートは必要ありません（飽和状態になり、サービス品質に影響を与える可能性があります）。追加のラックスペースとエネルギーも必要ありません。 IDCのアクセスルーター内、または自律システムの境界ルーター内にある可能性が特に高い場所の選択肢がいくつかあります。
Finally, another possibility is that the IDC operator outsources the SIIT-DC service to another entity, for example, his upstream ISP. Doing so allows the IDC operator to build a true IPv6-only infrastructure.
最後に、別の可能性としては、IDCオペレーターがSIIT-DCサービスを別のエンティティ、たとえば彼の上流ISPにアウトソーシングする可能性があります。これにより、IDCオペレーターは真のIPv6のみのインフラストラクチャを構築できます。
While this document mainly discusses the use of IPv6-only nodes and applications, it is important to note that SIIT-DC is fully compatible with dual-stack infrastructures, including dual-stack nodes and applications.
このドキュメントでは主にIPv6のみのノードとアプリケーションの使用について説明しますが、SIIT-DCはデュアルスタックノードとアプリケーションを含むデュアルスタックインフラストラクチャと完全に互換性があることに注意することが重要です。
Thus, migrating a dual-stacked service to an IPv6-only one where SIIT-DC provides the IPv4 Internet connectivity is easy. The operator would start out by designating the service's current native IPv6 address as the IPv6 Service Address and assigning it a corresponding IPv4 Service Address. At this point, the service will respond on both its old (native) IPv4 address and the SIIT-DC IPv4 Service Address. The operator may now move traffic from the former to the latter by changing the service's "IN A" DNS record. Once all IPv4 traffic has been successfully moved to SIIT-DC, the old IPv4 address may be reclaimed.
したがって、SIIT-DCがIPv4インターネット接続を提供するIPv6のみのサービスにデュアルスタックサービスを移行することは簡単です。オペレーターは、サービスの現在のネイティブIPv6アドレスをIPv6サービスアドレスとして指定し、それに対応するIPv4サービスアドレスを割り当てることから始めます。この時点で、サービスは古い（ネイティブ）IPv4アドレスとSIIT-DC IPv4サービスアドレスの両方で応答します。オペレーターは、サービスの「IN A」DNSレコードを変更することにより、前者から後者にトラフィックを移動できます。すべてのIPv4トラフィックがSIIT-DCに正常に移動されると、古いIPv4アドレスが再利用される場合があります。
In response to an IPv4 packet subsequently translated to IPv6 by the BR, an IPv6 router in the IDC network may need to transmit an ICMPv6 error back to the origin IPv4 node. By default, such an ICMPv6 error will most likely be discarded by the BR, unless the source address of the ICMPv6 error happens to be an IPv4-translatable IPv6 address or covered by an EAM.
その後BRによってIPv6に変換されたIPv4パケットに応答して、IDCネットワークのIPv6ルーターは、ICMPv6エラーを元のIPv4ノードに送信する必要がある場合があります。デフォルトでは、ICMPv6エラーの送信元アドレスがたまたまIPv4で変換可能なIPv6アドレスであるか、EAMでカバーされていない限り、そのようなICMPv6エラーはBRによって破棄される可能性が高いです。
To facilitate reliable delivery of such ICMPv6 errors, an SIIT-DC operator SHOULD implement the recommendations in [RFC6791] in the BRs.
そのようなICMPv6エラーの信頼できる配信を容易にするために、SIIT-DCオペレーターは[RFC6791]の推奨事項をBRに実装する必要があります（SHOULD）。
There are some key differences between IPv4 and IPv6 relating to packet sizes and fragmentation that one MUST consider when deploying SIIT-DC. They result in a few problematic corner cases, which can be dealt with in a few different ways. The following subsections will discuss these in detail and provide operational guidance.
IPv4とIPv6の間には、SIIT-DCを展開する際に考慮しなければならないパケットサイズとフラグメンテーションに関連するいくつかの重要な違いがあります。その結果、いくつかの問題のあるコーナーケースが発生し、いくつかの異なる方法で対処できます。次のサブセクションでは、これらについて詳細に説明し、運用ガイダンスを提供します。
In particular, the operator may find that relying on fragmentation in the IPv6 domain is undesired or even operationally impossible [FRAGMENTS]. For this reason, the recommendations in this section seek to minimize the use of IPv6 fragmentation.
特に、オペレーターは、IPv6ドメインでのフラグメンテーションに依存することが望ましくないか、操作上不可能でさえあることに気付く場合があります[FRAGMENTS]。このため、このセクションの推奨事項では、IPv6フラグメンテーションの使用を最小限に抑えることを目指しています。
Unless otherwise stated, the following subsections assume that the MTUs in both the IPv4 and IPv6 domains are 1500 bytes.
特に明記しない限り、以下のサブセクションでは、IPv4ドメインとIPv6ドメインの両方のMTUが1500バイトであると想定しています。
The IPv6 header is up to 20 bytes larger than the IPv4 header. This means that a full-size 1500 bytes large IPv4 packet cannot be translated to IPv6 without being fragmented, otherwise it would likely have resulted in a 1520 bytes large IPv6 packet.
IPv6ヘッダーは、IPv4ヘッダーより最大20バイト大きくなります。これは、フルサイズの1500バイトの大きなIPv4パケットはフラグメント化しないとIPv6に変換できないことを意味します。それ以外の場合は、おそらく1520バイトの大きなIPv6パケットになります。
If the transport protocol used is TCP, this is generally not a problem; the IPv6 node will advertise a TCP Maximum Segment Size (MSS) of 1440 bytes during the initial TCP handshake. This causes the IPv4 clients to never send larger packets than what can be translated to a single full-size IPv6 packet, eliminating any need for fragmentation.
使用されるトランスポートプロトコルがTCPの場合、これは通常問題にはなりません。 IPv6ノードは、最初のTCPハンドシェイク中に1440バイトのTCP最大セグメントサイズ（MSS）を通知します。これにより、IPv4クライアントは単一のフルサイズのIPv6パケットに変換できるパケットよりも大きなパケットを送信することがなくなり、フラグメンテーションの必要がなくなります。
For other transport protocols, full-size IPv4 packets with the Don't Fragment (DF) flag cleared will need to be fragmented by the BR. This may be avoided by increasing the Path MTU between the BR and the IPv6 nodes to 1520 bytes or greater. If this is done, the MTU on the IPv6 nodes themselves SHOULD NOT be increased accordingly, as doing so would cause them to undergo Path MTU Discovery for all destinations on the IPv6 Internet. The nodes MUST, however, be able to accept and process incoming packets larger than their own MTU. If the nodes' IPv6 implementation allows the initial Path MTU to be set differently for specific destinations, it MAY be increased to 1520 for destinations within the translation prefix specifically.
他のトランスポートプロトコルの場合、Do n't Fragment（DF）フラグがクリアされたフルサイズのIPv4パケットは、BRによってフラグメント化される必要があります。これは、BRとIPv6ノード間のパスMTUを1520バイト以上に増やすことで回避できます。これを行う場合、IPv6ノード自体のMTUは、IPv6インターネット上のすべての宛先に対してパスMTUディスカバリーを受けるため、それに応じて増加すべきではありません（SHOULD NOT）。ただし、ノードは自分のMTUよりも大きい着信パケットを受け入れて処理できなければなりません（MUST）。ノードのIPv6実装で初期パスMTUを特定の宛先に対して異なるように設定できる場合は、変換プレフィックス内の宛先については、特に1520に増やすことができます。
In keeping with the fifth paragraph of Section 4 of [RFC6145], a stateless translator like a BR will by default add an IPv6 Fragmentation header to the resulting IPv6 packet when translating an IPv4 packet with the DF flag set to 0. This happens even though the resulting IPv6 packet isn't actually fragmented into several pieces, resulting in an IPv6 Atomic Fragment [RFC6946]. These Atomic Fragments are generally not useful in an IDC environment, and it is therefore recommended that this behavior be disabled in the BRs. To this end, Section 4 of [RFC6145] notes that the "translator MAY provide a configuration function that allows the translator not to include the Fragment Header for the non-fragmented IPv6 packets."
[RFC6145]のセクション4の5番目の段落に従って、BRのようなステートレストランスレーターは、DFフラグが0に設定されたIPv4パケットを変換するときに、デフォルトで、結果のIPv6パケットにIPv6フラグメンテーションヘッダーを追加します。これは、結果のIPv6パケットは実際にはいくつかの断片に断片化されておらず、IPv6 Atomic Fragment [RFC6946]になります。これらのアトミックフラグメントは、一般的にIDC環境では役に立たないため、BRでこの動作を無効にすることをお勧めします。このため、[RFC6145]のセクション4は、「トランスレーターが、フラグメント化されていないIPv6パケットのフラグメントヘッダーを含めないようにする構成機能を提供する場合があります」と述べています。
Note that work is currently in progress (in [RFC6145bis]) to deprecate IPv6 Atomic Fragments. As a result, a BR that conforms to that document is required to behave as recommended above.
IPv6 Atomic Fragmentsを廃止するための作業が（[RFC6145bis]で）現在進行中であることに注意してください。その結果、そのドキュメントに準拠するBRは、上記の推奨どおりに動作する必要があります。
In IPv6, the Identification value is located inside the Fragmentation header. That means that if the generation of IPv6 Atomic Fragments is disabled, the IPv4 Identification value will be lost during translation to IPv6. This could potentially confuse some diagnostic tools.
IPv6では、ID値はFragmentationヘッダー内にあります。つまり、IPv6 Atomic Fragmentsの生成が無効になっている場合、IPv4識別値はIPv6への変換中に失われます。これにより、一部の診断ツールが混乱する可能性があります。
Section 5 of [RFC2460] specifies that the minimum IPv6 link MTU is 1280 bytes. Therefore, an IPv6 node can reasonably assume that if it transmits an IPv6 packet that is 1280 bytes or smaller, it is guaranteed to reach its destination without requiring fragmentation or invoking the Path MTU Discovery algorithm [RFC1981]. However, this assumption might prove false if the destination is an IPv4 node reached through a protocol translator such as a BR, as the minimum IPv4 link MTU is 68 bytes. See Section 3.2 of [RFC791].
[RFC2460]のセクション5は、IPv6リンクの最小MTUが1280バイトであることを指定しています。したがって、IPv6ノードは、それが1280バイト以下のIPv6パケットを送信する場合、フラグメント化を必要とせずに、またはパスMTUディスカバリアルゴリズムを呼び出すことなく宛先に到達することが保証されると合理的に想定できます[RFC1981]。ただし、最小IPv4リンクMTUが68バイトであるため、宛先がBRなどのプロトコルトランスレータを介して到達するIPv4ノードである場合、この仮定は誤っている可能性があります。 [RFC791]のセクション3.2をご覧ください。
Section 5.1 of [RFC6145] specifies that a stateless translator should set the IPv4 Don't Fragment flag to 1 when it translates a non-fragmented IPv6 packet to IPv4. This means that when the path to the destination IPv4 node contains an IPv4 link with an MTU smaller than 1260 bytes (which corresponds to an IPv6 MTU smaller than 1280 bytes; cf. Section 4.9.1), the Path MTU Discovery algorithm will be invoked, even if the original IPv6 packet was only 1280 bytes large. This happens as a result of the IPv4 router connecting to the IPv4 link with the small MTU returning an ICMPv4 Need To Fragment error with an MTU value smaller than 1260, which in turn is translated by the BR to an ICMPv6 Packet Too Big error with an MTU value smaller than 1280, which is then transmitted to the origin IPv6 node.
[RFC6145]のセクション5.1は、ステートレストランスレーターがフラグメント化されていないIPv6パケットをIPv4に変換するときに、IPv4 Do n't Fragmentフラグを1に設定する必要があることを指定しています。つまり、宛先IPv4ノードへのパスに1260バイト未満のIPv4リンクが含まれている場合（これは、1280バイト未満のIPv6 MTUに対応します。セクション4.9.1を参照）、パスMTU検出アルゴリズムが呼び出されます。 、元のIPv6パケットのサイズが1280バイトしかない場合でも。これは、IPv4ルーターがIPv4リンクに接続し、MTUが1260より小さいICMPv4必要フラグメントエラーを返すIPv4リンクの結果として発生します。このエラーは、BRによってICMPv6パケットが大きすぎるエラーに変換されます。 MTU値は1280未満であり、その後、発信元IPv6ノードに送信されます。
When an IPv6 node receives an ICMPv6 Packet Too Big error indicating an MTU value smaller than 1280, it is not allowed to reduce its Path MTU estimation to the indicated value. It must instead include a Fragmentation header in subsequent packets sent on that path [RFC1981]. In other words, the IPv6 node will start emitting Atomic Fragments. The Fragmentation header signals to the BR that the Don't Fragment flag should be set to 0 in the resulting IPv4 packet, and it also provides the Identification value.
IPv6ノードが、MTU値が1280未満であることを示すICMPv6パケットが大きすぎるというエラーを受け取った場合、そのパスMTUの推定値を指定された値に減らすことはできません。代わりに、そのパスで送信される後続のパケットにフラグメンテーションヘッダーを含める必要があります[RFC1981]。つまり、IPv6ノードはAtomic Fragmentsの発行を開始します。 Fragmentationヘッダーは、結果のIPv4パケットでDo n't Fragmentフラグを0に設定する必要があることをBRに通知し、識別値も提供します。
If the use of the IPv6 Fragmentation header is problematic, the operator should consider enabling the functionality described as the "second approach" in Section 6 of [RFC6145]. This functionality changes the BR's behavior as follows:
IPv6フラグメンテーションヘッダーの使用に問題がある場合、オペレーターは[RFC6145]のセクション6で「2番目のアプローチ」として説明されている機能を有効にすることを検討する必要があります。この機能により、BRの動作が次のように変更されます。
o When translating ICMPv4 Need To Fragment to ICMPv6 Packet Too Big, the resulting packet will never contain an MTU value lower than 1280. This prevents the IPv6 nodes from generating Atomic Fragments.
o ICMPv4 Need To FragmentをICMPv6 Packet Too Bigに変換する場合、結果のパケットに1280未満のMTU値が含まれることはありません。これにより、IPv6ノードがAtomic Fragmentsを生成できなくなります。
o When translating IPv6 packets smaller than or equal to 1280 bytes, the Don't Fragment flag in the resulting IPv4 packet will be set to 0. This ensures that in the eventuality that the path contains an IPv4 link with an MTU smaller than 1260, the IPv4 router connected to that link will have the responsibility to fragment the packet before forwarding it towards its destination.
o 1280バイト以下のIPv6パケットを変換する場合、結果のIPv4パケットのDo n't Fragmentフラグは0に設定されます。これにより、MTUが1260未満のIPv4リンクがパスに含まれるようになります。そのリンクに接続されたIPv4ルーターは、パケットを宛先に転送する前にフラグメント化する責任があります。
In summary, this approach could be seen as prompting the IPv4 protocol itself to provide the "link-specific fragmentation and reassembly at a layer below IPv6" required for links that "cannot convey a 1280-octet packet in one piece", to paraphrase Section 5 of [RFC2460].
要約すると、このアプローチは、IPv4プロトコル自体に、「1280オクテットのパケットを1つのピースで伝達できない」リンクに必要な「リンク固有の断片化とIPv6の下のレイヤーでの再構成」を提供するように促すと見なすことができます。 [RFC2460]の5。
Note that work is currently in progress (in [RFC6145bis]) to deprecate IPv6 Atomic Fragments. As a result, a BR that conforms to that document is required to behave as suggested above.
IPv6 Atomic Fragmentsを廃止するための作業が（[RFC6145bis]で）現在進行中であることに注意してください。その結果、そのドキュメントに準拠するBRは、上記のように動作する必要があります。
SIIT-DC is designed so that the IPv6 Service Addresses are not required to be IPv4-translatable IPv6 addresses. Section 2 of [RFC7757] discusses why it is desirable to avoid requiring the use of IPv4-translatable IPv6 addresses.
SIIT-DCは、IPv6サービスアドレスがIPv4で変換可能なIPv6アドレスである必要がないように設計されています。 [RFC7757]のセクション2では、IPv4で変換可能なIPv6アドレスの使用を回避することが望ましい理由について説明しています。
It is, however, quite possible to deploy SIIT-DC in combination with IPv4-translatable IPv6 Service Addresses. The primary benefits in doing so are:
ただし、SIIT-DCをIPv4で変換可能なIPv6サービスアドレスと組み合わせて展開することは十分に可能です。そうすることの主な利点は次のとおりです。
o The operator is not required to provision EAMs for IPv4-translatable IPv6 Service Addresses onto the BR/ERs.
o オペレーターは、IPv4変換可能なIPv6サービスアドレスのEAMをBR / ERにプロビジョニングする必要はありません。
o [RFC6145] translation can be performed in a checksum-neutral manner; cf. Section 4.1 of [RFC6052].
o [RFC6145]変換は、チェックサムニュートラルな方法で実行できます。 cf. [RFC6052]のセクション4.1。
The trade-off is that the IPv4-translatable IPv6 Service Addresses must be configured on the IPv6 nodes, and the applications must be set up to use them -- likely in addition to their primary (non-IPv4-translatable) IPv6 addresses. The IPv4-translatable IPv6 Service Addresses must also be routed from the BR through the IDC's IPv6 network infrastructure to the nodes on which they are assigned. This essentially requires the entire IPv6 infrastructure to be made aware of and handle translated IPv4 traffic as a special case, which significantly increases complexity. As previously described in Section 1.1, avoiding such drawbacks is a design goal of SIIT-DC. The use of IPv4-translatable IPv6 Service Addresses is therefore discouraged.
トレードオフは、IPv4変換可能なIPv6サービスアドレスをIPv6ノードで構成する必要があり、アプリケーションがそれらを使用するように設定する必要があることです-プライマリ（IPv4変換不可）IPv6アドレスに加えて。 IPv4で変換可能なIPv6サービスアドレスは、BRからIDCのIPv6ネットワークインフラストラクチャを経由して、それらが割り当てられているノードにルーティングされる必要もあります。これには、本質的に、IPv6インフラストラクチャ全体が特殊なケースとして変換されたIPv4トラフィックを認識して処理する必要があり、複雑さが大幅に増大します。セクション1.1で前述したように、そのような欠点を回避することがSIIT-DCの設計目標です。したがって、IPv4で変換可能なIPv6サービスアドレスの使用はお勧めしません。
If a Network-Specific Prefix from the provider's own address space is chosen for the translation prefix, as recommended in Section 4.4, care MUST be taken if the translation service is used in front of services that have application-level ACLs that distinguish between the operator's own networks and the Internet at large, as traffic from translated IPv4 end users on the Internet might appear to be originating from the provider's own network. It is therefore important that the translation prefix be treated the same as the Internet at large rather than as a trusted network.
セクション4.4で推奨されているように、プロバイダー独自のアドレススペースからのネットワーク固有のプレフィックスが変換プレフィックスに選択されている場合、オペレーターのアプリケーションを区別するアプリケーションレベルのACLを持つサービスの前で変換サービスを使用する場合は注意が必要です。インターネット上の変換されたIPv4エンドユーザーからのトラフィックはプロバイダーの独自のネットワークから発信されているように見えるため、独自のネットワークおよびインターネット全体。したがって、トランスレーションプレフィックスを信頼できるネットワークとしてではなく、インターネット全体と同じように扱うことが重要です。
In order to alleviate this problem, the operator may opt to use a translation prefix that is distinct from and not a subset of the IPv6 prefixes used elsewhere in the network infrastructure.
この問題を軽減するために、オペレーターは、ネットワークインフラストラクチャの他の場所で使用されているIPv6プレフィックスとは異なる、別の変換プレフィックスを使用することを選択できます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、DOI 10.17487 / RFC6052、2010年10月、< http://www.rfc-editor.org/info/rfc6052>。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP / ICMP変換アルゴリズム」、RFC 6145、DOI 10.17487 / RFC6145、2011年4月、<http://www.rfc-editor.org/ info / rfc6145>。
[RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. Huston, "Stateless Source Address Mapping for ICMPv6 Packets", RFC 6791, DOI 10.17487/RFC6791, November 2012, <http://www.rfc-editor.org/info/rfc6791>.
[RFC6791] Li、X.、Bao、C.、Wing、D.、Vaithianathan、R。、およびG. Huston、「ICMPv6パケットのステートレスソースアドレスマッピング」、RFC 6791、DOI 10.17487 / RFC6791、2012年11月、< http://www.rfc-editor.org/info/rfc6791>。
[RFC7757] Anderson, T. and A. Leiva, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, <http://www.rfc-editor.org/info/rfc7757>.
[RFC7757]アンダーソン、T。およびA.リーバ、「ステートレスIP / ICMP変換のための明示的なアドレスマッピング」、RFC 7757、DOI 10.17487 / RFC7757、2016年2月、<http://www.rfc-editor.org/info/ rfc7757>。
[FRAGMENTS] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, M., and T. Taylor, "Why Operators Filter Fragments and What It Implies", Work in Progress, draft-taylor-v6ops-fragdrop-02, December 2013.
[フラグメント] Jaeggli、J.、Colitti、L.、Kumari、W.、Vyncke、E.、Kaeo、M。、およびT. Taylor、「なぜ演算子はフラグメントをフィルタリングし、それが何を意味するのか」、進行中の作業、ドラフト- taylor-v6ops-fragdrop-02、2013年12月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<http://www.rfc-editor.org/info/rfc791>。
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <http://www.rfc-editor.org/info/rfc959>.
[RFC959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、DOI 10.17487 / RFC0959、1985年10月、<http://www.rfc-editor.org/info/rfc959>。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「Path MTU Discovery for IP version 6」、RFC 1981、DOI 10.17487 / RFC1981、1996年8月、<http：//www.rfc-editor。 org / info / rfc1981>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <http://www.rfc-editor.org/info/rfc2663>.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、DOI 10.17487 / RFC2663、1999年8月、<http://www.rfc-editor.org/info / rfc2663>。
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, November 2000, <http://www.rfc-editor.org/info/rfc2991>.
[RFC2991] Thaler、D。およびC. Hopps、「ユニキャストおよびマルチキャストネクストホップ選択におけるマルチパスの問題」、RFC 2991、DOI 10.17487 / RFC2991、2000年11月、<http://www.rfc-editor.org/info / rfc2991>。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, DOI 10.17487/RFC2993, November 2000, <http://www.rfc-editor.org/info/rfc2993>.
[RFC2993] Hain、T。、「Architectural Implications of NAT」、RFC 2993、DOI 10.17487 / RFC2993、2000年11月、<http://www.rfc-editor.org/info/rfc2993>。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、DOI 10.17487 / RFC3022、2001年1月、<http://www.rfc-editor.org/info/ rfc3022>。
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, DOI 10.17487/RFC3235, January 2002, <http://www.rfc-editor.org/info/rfc3235>.
[RFC3235] Senie、D。、「Network Address Translator（NAT）-Friendly Application Design Guidelines」、RFC 3235、DOI 10.17487 / RFC3235、2002年1月、<http://www.rfc-editor.org/info/rfc3235> 。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, <http://www.rfc-editor.org/info/rfc4213>.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストおよびルーターの基本的な移行メカニズム」、RFC 4213、DOI 10.17487 / RFC4213、2005年10月、<http://www.rfc-editor.org/info/rfc4213 >。
[RFC6145bis] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm (rfc6145bis)", Work in Progress, draft-bao-v6ops-rfc6145bis-05, January 2016.
[RFC6145bis] Bao、C.、Li、X.、Baker、F.、Anderson、T.、and F. Gont、 "IP / ICMP Translation Algorithm（rfc6145bis）"、Work in Progress、draft-bao-v6ops-rfc6145bis -05、2016年1月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<http： //www.rfc-editor.org/info/rfc6146>。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <http://www.rfc-editor.org/info/rfc6147>.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、I。van Beijnum、「DNS64：DNS Extensions for Network Address Translation to IPv4 Servers to RFC」、RFC 6147、DOI 10.17487 / RFC6147、4月2011、<http://www.rfc-editor.org/info/rfc6147>。
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, DOI 10.17487/RFC6540, April 2012, <http://www.rfc-editor.org/info/rfc6540>.
[RFC6540] George W.、Donley、C.、Liljenstolpe、C。、およびL. Howard、「すべてのIP対応ノードに必要なIPv6サポート」、BCP 177、RFC 6540、DOI 10.17487 / RFC6540、2012年4月、< http://www.rfc-editor.org/info/rfc6540>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、Ed。、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月、<http://www.rfc-editor.org/info/rfc6724>。
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Content Providers and Application Service Providers", RFC 6883, DOI 10.17487/RFC6883, March 2013, <http://www.rfc-editor.org/info/rfc6883>.
[RFC6883] Carpenter、B。およびS. Jiang、「インターネットコンテンツプロバイダーおよびアプリケーションサービスプロバイダーのためのIPv6ガイダンス」、RFC 6883、DOI 10.17487 / RFC6883、2013年3月、<http://www.rfc-editor.org/info / rfc6883>。
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 6946, DOI 10.17487/RFC6946, May 2013, <http://www.rfc-editor.org/info/rfc6946>.
[RFC6946] Gont、F。、「Processing of IPv6 "Atomic" Fragments」、RFC 6946、DOI 10.17487 / RFC6946、May 2013、<http://www.rfc-editor.org/info/rfc6946>。
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The Internet Numbers Registry System", RFC 7020, DOI 10.17487/RFC7020, August 2013, <http://www.rfc-editor.org/info/rfc7020>.
[RFC7020] Housley、R.、Curran、J.、Huston、G。、およびD. Conrad、「The Internet Numbers Registry System」、RFC 7020、DOI 10.17487 / RFC7020、2013年8月、<http：//www.rfc -editor.org/info/rfc7020>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[RFC7756] Anderson, T. and S. Steffann, "Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode", RFC 7756, DOI 10.17487/RFC7756, February 2016, <http://www.rfc-editor.org/info/rfc7756>.
[RFC7756]アンダーソン、T。、およびS.ステファン、「IPv6インターネットデータセンター環境用のステートレスIP / ICMP変換（SIIT-DC）：デュアル変換モード」、RFC 7756、DOI 10.17487 / RFC7756、2016年2月、<http：/ /www.rfc-editor.org/info/rfc7756>。
Figure 4 attempts to "tie it all together" and show a more complete SIIT-DC topology, in order to better demonstrate its advantageous properties discussed in Section 1. These are discussed in more detail below.
図4は、セクション1で説明した有利な特性をより明確に示すために、「すべてをまとめる」ことで、より完全なSIIT-DCトポロジを示しています。
/--------------------------------\ /---------------\
| IPv4 Internet | | IPv6 Internet |
\-+----------------------------+-/ \--------+------/
| | |
| <----------[BGP]---------> | [BGP]
| | |
+-------<192.0.2.0/24>---------+ +---<192.0.2.0/24>---+ |
| BR #1 | | BR #2 | |
| EAM Table: | | | |
| ========== | | | |
| 192.0.2.1,2001:db8:12:34::1 | | | |
| 192.0.2.2,2001:db8:12:34::2 | | Exactly the same | |
| 192.0.2.3,2001:db8:fe:dc::1 | | configuration as | |
| 192.0.2.4,2001:db8:12:34::4 | | BR #1 | |
| 192.0.2.5,2001:db8:fe:dc::e | | | |
| | | | |
| XLAT Prefix 2001:db8:46::/96 | | | |
| | | | |
+--------<2001:db8:46::/96>----+ +-<2001:db8:46::/96>-+ |
| | |
| <------[ECMP]------> | |
| | |
/-----------------+----------------------+--\ |
| IPv6 IDC network w/ OSPFv3 +------------/
\-+--------------------------------+--------/
| |
| Tenant A's server LAN | Tenant B's server LAN
| 2001:db8:12:34::/64 | 2001:db8:fe:dc::/64
| |
+-- www ::1 (IPv6+SIIT-DC) +-- www-lb ::1 (IPv6+SIIT-DC)
| |
+-- mta ::2 (IPv6+SIIT-DC) +-- web ::80:01 (IPv6 only)
| | [...]
+-- ftp ::3 (IPv6) +-- web ::80:99 (IPv6 only)
| ::4 (IPv4, via ER) |
| | +----+
+-- app01 ::a:01 (IPv6 only) \---- ::e | ER | --\
| [...] +----+ |
+- app99 ::a:99 (IPv6 only) |
| ftp 192.0.2.5 ---/
+-- db01 ::d:01 (IPv6 only)
| [..]
\-- db99 ::d:99 (IPv6 only)
Figure 4: Example SIIT-DC IDC Topology
図4：SIIT-DC IDCトポロジの例
Single-Stack IPv6 Operation: As discussed in Section 1.1, SIIT-DC facilitates an IPv6-only IDC network infrastructure. The only places where IPv4 is absolutely required are between the BRs and the IPv4 Internet and between any ERs and the IPv4-only applications or devices they are serving (illustrated here as the two tenants' FTP servers). The figure also illustrates how SIIT-DC does not interfere with native IPv6; when there is no longer a need to support IPv4 clients, the BRs may be decommissioned without causing any impact to native IPv6 traffic.
シングルスタックIPv6操作：セクション1.1で説明したように、SIIT-DCはIPv6のみのIDCネットワークインフラストラクチャを促進します。 IPv4が絶対に必要な場所は、BRとIPv4インターネットの間、およびERとそれらがサービスを提供するIPv4専用アプリケーションまたはデバイス（ここでは2つのテナントのFTPサーバーとして示されています）の間だけです。この図は、SIIT-DCがネイティブIPv6に干渉しないことも示しています。 IPv4クライアントをサポートする必要がなくなった場合、ネイティブIPv6トラフィックに影響を与えることなくBRを使用停止にすることができます。
Stateless Operation: As discussed in Section 1.2, SIIT-DC operates in a stateless fashion. In the illustration, both BRs are simultaneously advertising (i.e., anycasting) the IPv4 Service Address Pool and the IPv6 translation prefix, so incoming traffic from the IPv4 Internet may arrive at either of the BRs, while outgoing IPv6 traffic destined for IPv4 endpoints are load balanced between them using Equal-Cost Multipath Routing. No continuous state synchronization between the two BRs occurs. Should one of the BRs fail, the BGP and OSPF protocols will ensure that traffic converges on the remaining BR. Existing sessions will not be disrupted beyond any disruption caused by the BGP/OSPF convergence process itself.
ステートレス動作：セクション1.2で説明したように、SIIT-DCはステートレスな方法で動作します。この図では、両方のBRが同時にIPv4サービスアドレスプールとIPv6変換プレフィックスをアドバタイズ（つまり、エニーキャスト）しているため、IPv4インターネットからの着信トラフィックはどちらかのBRに到達し、IPv4エンドポイント宛ての発信IPv6トラフィックはロードされます。等コストマルチパスルーティングを使用して、それらの間でバランスをとります。 2つのBR間の継続的な状態同期は発生しません。 BRの1つに障害が発生した場合、BGPおよびOSPFプロトコルは、トラフィックが残りのBRに確実に収束するようにします。既存のセッションは、BGP / OSPFコンバージェンスプロセス自体によって引き起こされる中断を超えて中断されることはありません。
IPv4 Address Conservation: As discussed in Section 1.3, SIIT-DC conserves the IDC operator's IPv4 address space. Even though the two customers in the example above have several hundred servers, the majority of the servers are not used for running services made available directly from the Internet and therefore do not need to consume IPv4 addresses. The IDC network infrastructure consumes no IPv4 addresses, either. Finally, the IPv4 addresses that are assigned to the SIIT-DC function as IPv4 Service Address Pools may be assigned with 100% efficiency, one address at a time; there is no requirement to assign multiple addresses to a single customer in a contiguous block.
IPv4アドレスの節約：セクション1.3で説明したように、SIIT-DCはIDCオペレーターのIPv4アドレス空間を節約します。上記の例の2人の顧客には数百のサーバーがありますが、サーバーの大部分はインターネットから直接利用できるサービスの実行には使用されないため、IPv4アドレスを使用する必要はありません。 IDCネットワークインフラストラクチャもIPv4アドレスを消費しません。最後に、IPv4サービスアドレスプールとしてSIIT-DC機能に割り当てられるIPv4アドレスは、一度に1つのアドレスで100％の効率で割り当てることができます。連続したブロックで単一の顧客に複数のアドレスを割り当てる必要はありません。
Application Support: As discussed in Section 1.5, as long as the application protocol is translation friendly (illustrated here with HTTP and SMTP), it will work with SIIT-DC without requiring any special adaptation. Furthermore, translation-unfriendly applications (illustrated here with FTP) will also work when located behind an ER [RFC7756]. Tenant A's FTP server illustrates how an ER may be located in the networking stack of a node, while Tenant B's FTP server illustrates how the ER may be deployed as a network service. The latter approach enables SIIT-DC to support IPv4-only nodes/devices.
アプリケーションサポート：セクション1.5で説明したように、アプリケーションプロトコルが翻訳に適している限り（ここではHTTPおよびSMTPで示されています）、特別な調整を必要とせずにSIIT-DCで動作します。さらに、翻訳に適さないアプリケーション（ここではFTPで示されています）も、ER [RFC7756]の背後に配置されている場合に機能します。テナントAのFTPサーバーは、ERがノードのネットワークスタックに配置される方法を示し、テナントBのFTPサーバーは、ERがネットワークサービスとして展開される方法を示します。後者のアプローチにより、SIIT-DCはIPv4のみのノード/デバイスをサポートできます。
Acknowledgements
謝辞
The author would like to thank the following individuals for their contributions, suggestions, corrections, and criticisms: Fred Baker, Cameron Byrne, Brian E. Carpenter, Ross Chandler, Tobias Gondrom, Christer Holmberg, Dagfinn Ilmari Mannsaaker, Lars Olafsen, Stig Sandbeck Mathisen, Knut A. Syed, Qin Wu, and Andrew Yourtchenko.
著者は、以下の個人の貢献、提案、修正、および批判に感謝したいと思います。フレッドベイカー、キャメロンバーン、ブライアンE.カーペンター、ロスチャンドラー、トビアスゴンドロム、クリスターホルムバーグ、ダグフィンイルマリマンサーカー、ラースオラフセン、スティグサンドベックマティセン、Knut A. Syed、Qin Wu、Andrew Yourtchenko。
Author's Address
著者のアドレス
Tore Anderson Redpill Linpro Vitaminveien 1A 0485 Oslo Norway
Tore Anderson Redpill Linpro Vitaminveien 1A 0485 Oslo Norway
Phone: +47 959 31 212
Email: tore@redpill-linpro.com
URI: http://www.redpill-linpro.com