IPv6 への移行が停滞しているのは、プロトコルそのものではなく、インベントリ、コンプライアンス・テスト、およびデュアルスタックの記録管理が原因です。DNS、DHCP、IPAM を 1 つのシステムとして扱い、ネットワークごとの準備状況を追跡するチームは、移行を完了させることができます。Micetro は、既存のサーバー上でそれを実現します。
IPv6 への移行が停滞しているのは、プロトコルそのもののせいではなく、プロトコルに関連して変更しなければならない事項があるためです。 ネットワーク上のすべての IP アドレスを棚卸しし、実際のコンプライアンスをテストし、移行する必要がありますが、その棚卸しの量は、ほとんどの移行計画が想定していたよりも急速に増加しています。
GAOによる米国国防総省の調査は、この傾向が大規模に広がっていることを示しています。国防総省は2003年にIPv6への移行を決定しました。17年が経過した現在、監査、監察官による審査、立法上の義務化を経たにもかかわらず、完全に移行を完了したのはそのネットワークのうち1つだけでした。重要なのは、国防総省の計画が不十分だったということではありません。 重要なのは、IPv6への移行の難しさが構造的なものであるという点だ。
この作業は細部にまで気を配る必要があり、手作業が中心です。チームは接続をテストし、IPv6 対応を謳うデバイスが本番環境で正常に動作することを確認し、場合によってはネットワークの再設計も行います。日常業務や、クラウドや SD-WAN などのプロジェクトと比較すると、IPv6 は労力がかかり、価値が低いように見えるため、導入が先送りされ続けています。 BlueCatが、この規模の移行から得た教訓は、DNS、DHCP、IPAMを一体として移行する必要があるということです。
That is the reported number of IPアドレス in use at the U.S. Department of Defense, the largest known estate in the world, and only one of its networks had fully moved to IPv6 after 17 years.
Read article
How difficult are IPv6 migrations? A recent GAO report on DOD's transition plan provides some sobering conclusions.
実際的な違いは、規模と計画の負担にあります。 IPv4 は約 43 億個のアドレスしか提供せず、すでに枯渇していますが、IPv6 はおよそ 340 ウンデシリオン個のアドレスを提供します。この拡張により、NAT は必須要件ではなくなりましたが、その一方で、アドレス計画、互換性テスト、デュアルスタック管理が現実的な課題となっています。
IANA は 2011 年に IPv4 の空きアドレスを使い果たしましたが、流通市場で追加購入するには多額の費用がかかります。しかし、アドレスが枯渇したからといって、NAT が一夜にして消滅するわけではありません。 多くの組織はNATを使い続け、デュアルスタックがデフォルトの運用状態となるでしょう。IPv4とIPv6の比較は、実際には、両方のプロトコルをどれくらいの期間並行して運用し続けなければならないかという問題なのです。
IPv6 には、それ独自の運用上のリスクがあります。長い 16 進数のアドレスは手入力によるミスを招きやすいため、自動化と検証が重要になります。また、IPv6 には独自のセキュリティ上の考慮事項もあります。必要に応じて自己生成アドレスの使用を制限し、許可リストとセグメンテーションを徹底し、アドレスの割り当てを追跡可能にする必要がある場合は、ステートフル DHCPv6 を使用する必要があります。
これが IPv4 アドレス空間のすべてであり、2011 年に空きプールが枯渇したため、現在、新しいアドレスはすべて、再利用、NAT、または流通市場から供給されています。
Read article
The transition to IPv6 is here. Learn more with BlueCat about the necessity of it, the timeline, and the numerous benefits and challenges of IPv4 vs IPv6.
AAAA レコードは、A レコードが IPv4 アドレスを返すのと同じように、DNS クエリに対してホストの IPv6 アドレスを返します。 デュアルスタックの導入期間中、ホストは両方のレコードを保持することができるため、すべてのゾーンでは、同じ名前に対して 2 つのアドレスレコードを正確に保持する必要があります。
この名前はサイズを反映しています。IPv6 アドレスは 128 ビットで、IPv4 アドレスの 32 ビットの 4 倍であるため、アドレスの「A」が 4 回記述されています。AAAA レコードは、組織自身のネットワーク上またはホスティングプロバイダ上の権威サーバーにある DNS ゾーンに存在します。
レコードを確認するには、その名前に対して dig または nslookup クエリを実行します。 google.com の場合、AAAA ルックアップにより 2607:f8b0:4009:80a::200e などの IPv6 アドレスが返されます。レコードの作成方法は DNS 管理ツールによって異なるため、このツールは移行計画の一部となります。
Read article
DNS、DHCP、および IP データを 1 つのビューで把握することで、スプレッドシート、サーバー、ルーターを手作業でつなぎ合わせる作業が不要になり、アドレス、レコード、スコープの関連性を最新の状態で把握できるようになります。 IPv6 への移行において、その見解は計画の基盤となるインベントリとなります。
Omdia の技術検証によると、92% の組織が分散環境を運用しており、82% が 2 年前よりもネットワークが複雑になっていると回答しています。このような環境では、DDI データはサイロ化されており、レコード、スコープ、アドレスの関係を人手によって正確に維持しようとすると、エラーや不備が生じ、ネットワークの可用性を損なうことになります。
Omdiaは、そのデータが一元化されると何が変化するかを観察しました。レコードは変更履歴付きの単一のインターフェースで編集され、100万件以上のレコードがあるゾーンで「10.29.2」を検索すると、即座に1,062件のヒットが返されました。サブネットの監視とPTR検証フラグにより、ユーザーが気付く前に競合や利用率の問題が明らかになりました。
その割合の組織は、自社のネットワーク環境が 2 年前よりも複雑になっていると述べており、IPv6 インベントリは、そのような環境の中で構築されなければなりません。
Read article
BlueCat Micetro centralizes and normalizes DDI data across on-premises, hybrid, and multicloud environments, providing a single source of truth for DNS,…
各チームは、すでに運用している DNS および DHCP サーバーの上に 1 つの制御層を配置することで、長期にわたる移行を進めています。 そのレイヤーは、役割ベースのアクセスを強制し、すべての変更をログに記録し、手動での再構築ではなく、ツールを使用してゾーンやスコープを移動させます。
ほとんどの組織では、Windows Server、BIND、Kea、Cisco DHCP を混在して運用しており、それぞれ独自のコンソールとデータモデルを持っています。 オーバーレイ・モデルは、これらのサーバーを置き換えるのではなく、それらを統合して管理するため、チームのペースに合わせて移行を進めることができます。ある概要で述べられているように、「すべてのトランザクションと設定変更は、認証され、ログに記録され、監査可能です。」
移行ツールは、ポリシーと同様に重要です。ゾーン移行ウィザードを使用すると、ダウンタイムを最小限に抑えてサーバー間で DNS ゾーンを移行でき、スコープ移行では、オフラインのサーバーからのリース履歴も保持できます。REST API や Ansible、Terraform との統合により、チームは繰り返し可能な IPv6 変更をスクリプト化でき、承認ワークフローによって完全な監査証跡が保持されます。
Read article
Today’s enterprise networks span data centers, cloud environments, and distributed edge systems. DNS, DHCP, and IP address management (together known as…
チームは、IPv4 と同じ場所で IPv6 を管理し、既存の DNS および DHCP サーバー上で動作し、安全な委任と自動化をサポートする IPAM を探すべきです。 各基準は、移行を停滞させる障害モード、すなわち、インベントリの不備、手作業によるミス、そして担当者を確保できない置き換えプロジェクトに対応しています。
まずはカバレッジから始めましょう。デュアルスタックまたは IPv6 のみへの移行中は、IPv6 を別のツールではなく、IPv4 と併せて管理する必要があります。このアプローチでは、合併後のアドレス空間の重複や複数のディレクトリフォレストに対応できる必要があり、また、移行によって強制的なアーキテクチャの再構築とならないよう、既存の Microsoft およびその他の DDI サービス上に構築される必要があります。
次に、権限の委譲と自動化をテストします。きめ細かなロールベースのアクセス制御により、ローカル管理者は、広範な権限を持たずに、自分が所有するレコードを更新できるようになります。インターフェースで実行できることはすべて API を通じて実行できる「API ファースト」の設計により、チームは、サーバーの種類ごとに個別にスクリプトを作成する代わりに、繰り返し可能な IPv6 の変更を行うための単一の自動化プラットフォームを利用できるようになります。
Read article
Micetro is an overlay solution which helps you get extra life out of your current DNS, DHCP, and IP address management solutions.
ネットワークチームは、IPAM 上のすべてのアドレス範囲およびデバイスにおける IPv6 のテストおよび移行状況を追跡し、ローカル管理者にチェックを委任し、その状況を階層の上位へ報告することで、移行を進めています。 Micetro は、チームがすでに運用している DNS および DHCP サーバー上でこれをサポートしているため、IPv6 は IPv4 と並行して、ネットワークごとに順次有効化されます。
Micetro による IPv6 への移行に関するホワイトペーパーは、ネットワークの把握から始まります。Micetro は、A レコード、AAAA レコード、および DHCP スコープにあるアドレスを表示し、スプレッドシートから静的アドレスをインポートし、ルーターの ARP データや ping を通じて、文書化されていないアドレスを検出します。 その後、「IPv6 テストステータス」プロパティフィールドにより、各アドレス範囲およびデバイスが、テスト待ちから移行準備完了まで、段階的にマークされます。
Microsoft ディレクトリを通じてグループが管理される、きめ細かなロールベースのアクセス制御により、ローカル管理者は自分のネットワークの状態のみを更新できるようになります。 ワークフロー拡張機能によってステータスが階層の上位へ伝播され、2 つ目のフィールドでは、移行待ち、部分的に移行済み、または完全に IPv6 対応となっている状態を追跡します。通常、チームはまずバックボーンで IPv6 を有効にし、その後、それぞれのペースで周辺ネットワークへと拡大していきます。
Read article
[Whitepaper] Migrating to IPv6 with Micetro
Read article
With Micetro, integrate, orchestrate, and automate your current DNS, DHCP, and IPAM network infrastructure via a single web interface.
適切な道筋は、チームが現在のアドレス資産をどの程度把握しているか、また DNS および DHCP サーバーが現在どのように管理されているかによって異なります。ほとんどのチームは、これらの道筋を順番にたどります。資産の把握がすでに確実に行われている場合は、その先へスキップできる場合もあります。
IPv6 向けの DNS、DHCP、および IPAM を計画する際に、ネットワークチームが最もよく尋ねる質問に対する簡潔な回答。
まだご質問がありますか？
BlueCatの担当者から具体的な回答を得ましょう。
