評価方法自体は、サービスの実装でのIPv6の使用とエンドユーザーによるIPv6の使用という2つの部分に分割することに決定されました。 当然、私は大規模なプロジェクトを実験しませんでした。 しかし、小さなことの研究の結果は、コミュニティと共有する準備ができています。
サービスにIPv6を使用する可能性を評価するために、小さな会社が電子メールサーバーとして使用するサーバーが使用されました。 サーバーの脆弱性：2つのドメイン、それぞれ10〜15個のアカウント。 消費者は主にIMAP4を介して接続しますが、WEB銃口も存在します。 主に着信メールトラフィック。 メーラーによって排他的に使用されるキャッシングDNSがあります。
IPv6を評価するために、小規模企業でインターネットを配布するための境界ホストとしてユーザーがホストを使用しました（5件のジョブ）。 主なトラフィック消費：Webページの閲覧、企業のメール、およびいくつかのソーシャルネットワークは、非ITオフィスでは一般的な状況です。 それに加えて、Androidプラットフォーム上の3〜4台のデバイスにインターネットを配信するWiFiアクセスポイントがあります。
どちらの場合も、プロバイダーはネイティブIPv6を提供しました。
メールサーバーの場合、MXレコードのDNSに重複したAAAAレコードが追加されています。 DNSの場合、IPv6アドレスを含むルートサーバーの新しいリストがアップロードされました。 ファイアウォールへの変更は最小限です。実際、IPv4のルールはIPv6でも複製されました。
DHCPを介して発行されたプライベートIPv4アドレスとともに、エンドユーザーの場合、追加のIPv6アドレスがSLAACを介して発行されました。 プロバイダーが/ 64プレフィックスを提供したため、静的IPv6アドレスが各クライアントに割り当てられました。 保護のため、以前にローカルネットワークからクライアントによって要求された場合にのみ、着信トラフィックを許可するルールが境界ルーターで作成されました。
経営成績
メールサービスの機能に変更はありませんでした。 IPv6をサポートするメールサーバー（yandex.ru、gmail.comなど）との接続は、主にIPv6上で行われます。 アクセス不能タイムアウトが機能することはほとんどありません。 ただし、この場合のpostfixは、IPv4を介して独立して再接続しようとするため、この場合の配信遅延は無視できます。
スパマー（まだ？）主にIPv4に住んでいます。 しかし、実質的にブラックリストはどれもIPv6をサポートしていません。 すべてのサーバーがIPv6の逆DNSゾーンを正しく構成しているわけではありません（ただし、これはspamassassinの重み選択によって処理されます）。
ユーザーの観点から見ると、GoogleとYandexが「IPv6アドレスからの疑わしいトラフィック」を報告し、ユーザーがロボットではないことを確認するよう要求したときに問題がありました。 約1週間の運用の後、そのようなリクエストはそれほど頻繁に表示されなくなりました（IPv6統計はSLAACによってユーザーに発行されることを思い出します）が、まだ完全には消えていません。 サイトの読み込み速度および/または何にもアクセスできないという苦情が報告されています。
そして、最も興味深いのは、すべてが開始されたためです（確立モード。サービスの左グラフ、ユーザーの右グラフ）。
さて、外部サービスはデュアルスタックに転送できます。 いずれにせよ、メールの場合、IPv6ではほぼ2倍のトラフィックがあります。 サービスの可用性は、低下するよりも改善される可能性があります（重複リンクの存在により）。
内部サービスは、最初は純粋なIPv6上に構築できます。 ルーティングは、従来のポート転送よりも少ないリソースで済みます。 ネットワーク監視が簡素化されます。 すべてのサービスのセキュリティは、外界からの制御アクセスを維持しながら、境界ルーターのいくつかのルールによって確保できます。
ただし、エンドユーザーがデュアルスタックに切り替えると、予期しない問題が発生します。 アクセス速度やサードパーティのサービスの可用性の劇的な改善は期待できません。 IPv6を介したトラフィックは依然としてIPv4を介したトラフィックよりも少なくなりますが、この比率を変更する傾向があります。