スキップしてメイン コンテンツに移動

そろそろ企業向けにIPv6本格導入考える時期が来たんじゃない？

各企業において様々な働き方に対応できるインフラ構築も落ち着いた時期じゃないかと思いますが、IPv6だけは相変わらず導入できそうな気配を感じませんね。

やろうと思えばできるのですが、企業インターネット黎明期あった、グローバルアドレスを社内IPとして利用してしまう失敗が脳裏をよぎって躊躇してしまいますよね。「OCNエコノミーで安定高速インターネット接続環境を！！」みたいなことを言ってた時代に現地調査はいると「170.0.0.1/24」とかが設定されているネットワークに出会うことがたま～にありました。社内ネットワークで利用できるのは3種類のプライベートアドレスは今では当たり前ですが、Windows3.1時代にネットワークを構築した企業にとっては当たり前というとかわいそうですね。RFCの公開が1994年ですし。

インターネット接続環境はインフラ環境が単純な家庭用サービスが先行して普及するのは自然のことで、IPv6もその一つですね。フレッツ光プレミアム以降のサービスを契約すると気にすることなくIPv6対応ルーターが設置され利用できる準備が整いますので、利用者は意識してなくてもIPv6通信の普及は進むし、PPPoE遅い問題を目にした方はIPv6の積極的な導入に動いたのではないでしょうか？

そういう流れで会社のインターネット遅い！！IPv6対応して高速化しろよ！！って意見がちらほら聞こえているのです。企業ネットワークを変化させることって難しいのです。トップダウン型で取り組み始めても費用を提示するとNGってこともあるし、そもそも製品の選択肢が無かったり、性能不足、ノウハウ不足、パートナー不在と費用提示の前にとん挫することもあります。うまくいっても利用者側から変更を拒否されたり、利用システムが未対応だったりと課題もたくさんあり「今は変化できない」がず～っと続いてしまいます。

新規小規模拠点なら導入課題は少ないですが、既存小規模拠点の場合は予算的に不可というケースが多いのでは？一般家庭用機器ネットワーク拠点なら設定変更程度で済みますけど、VPN装置があったりすると対応機器に買換えが必要だったりしますが”壊れていない”　”今問題なく業務出来ている”という状況と”見えない効果”がブレーキを掛けます。だって「高速化した分、売り上げも上がるよね？」って現場が言われると無理、いらないって答えるよね。

そんな感じで変化はとても難しいのですが、インフラ担当としては何年も先を見据えて機器選定をしているので買換えタイミングでは高速化、もちろんIPv6対応も考慮しているわけです。機器に関しては予算が付けば解決できるし、利用システムも対応が徐々に増えているので何とかなるかな～という感じではあるのですけどね。

そんな中、絶対に無理だな～と感じているのが”定番設計が存在しない”という問題。

IPv4には”インターネット接続ゲートウェイでNATとLAN側はプライベートアドレスを使う”が最低限の定番設計で、拠点間で異なるサブネットを使っていれば統廃合に対して部分的な変更だけで対応できる。

この定番設計で構築されたネットワークをIPv4/IPv6デュアルスタック化しようとするといくつかの問題が解決できない。「あ、無理だ～」というのが私の感想。

何が無理って「プロバイダー変更のインパクト」「IPv4と同じセグメント分けが出来ない」って話だけでも、結構無理～って感じる。

プロバイダー変更のインパクト

IPv４はゲートウェイでグローバルアドレスに変換して、内部はプライベートアドレスを使用するので、プロバイダーを変更した際にグローバルアドレスが当然変わるけど、ゲートウェイの設定変更だけで利用者に影響でない。

これが、IPv６の場合、内部もグローバルアドレスを使うので、プロバイダー変更ですべてのIPアドレス設定に影響が発生する。自動設定だから問題ない？いや、端末への反映時間やDNSやサーバーの設定変更などを考慮すると「ISP障害だから別のISPに切り替えて対応しよう」ってのがIPv４のように気軽に出来ない。常に利用できる状態にするという設計になるのだろうか？

または、IPv4と同じようにユニークローカルアドレス使えばよいじゃないって話になるんだけど、NAT6対応のゲートウェイが必要になる。すべての機器が対応していれば話は簡単なんですけどね。

IPv4と同じセグメント分けが出来ない

IPv6はグローバルアドレスを使う前提なので、プロバイダーから割り当てられるIPアドレスを分割できる/56や/48だと良いのですが、/64だと無理ってなります。だって分割の最小が/64だから・・・これ以上分割できない。

PPPoEや専用線契約なら/48など潤沢なアドレス範囲を使えるので分割できるけど、IPoEだとひかり電話契約ありで/56、ひかり電話契約なしだと/64になるので必要セグメント数にもよるけど1:1に出来なければIPv4のセグメント統合が必要になる。

2022年現在はIPv6に変更する目的は「輻輳状態にあるPPPoEを迂回する」だと思うので、輻輳していないかもしれないIPv6のPPPoEは避けたいと考えるし、専用線費用なんて割に合わない。1Gbpsの専用線って月額いくらなんだ？100万位？


デュアルスタックへの準備は本格的に考えているけど、課題はたくさんありそうだし、何より定番設計が無さそう。ってのが一番痛いよね～。まだまだ企業内ネットワークのIPv6対応は先の話になりそう。

ラベル:

コメント

コメントを投稿

このブログの人気の投稿

SharePoint アイテム保管ライブラリをのぞいてみよう（2023年1月改訂）

※アカウント移行に失敗し画像を失ったので再度取得し改訂しました。 Office 365 Advent Calendar 2021  の12月16日投稿です。 警告： 個人的な理解に基づく内容、表現です。疑いを持って取り扱ってください。 SharePoint と OneDrive の保持の詳細 - Microsoft 365 Compliance | Microsoft Docs SharePoint Onlineをご利用の方にとっては普通？の機能ですが、SharePoint Server 2010以前から利用している方にとっては2013からの新機能「インプレース保持」で使われる「アイテム保管ライブラリ」をちょっとのぞいてみようという内容です。 Exchangeのインプレース保持とSharePointの保持は違うよ～ Exchange のインプレース保持はごみ箱から消えたメッセージを含むすべてを保持することができるのですが、SharePointでは対象外アイテムが存在しますし、編集についてはバージョン履歴に依存しています。また、情報管理ポリシーの「ごみ箱に移動する」が動作しなくなるなど利用者への影響もありますので注意が必要です。また、保持してることを内緒にしたくてもサイト管理者にはバレバレな点は認識しておかないとね。あとE3相当以上の方はExchangeは容量無制限ですけど、SharePointはしっかりと契約容量に含まれているので上司の方から説明のたびに叱られる可能性がありますね。 SharePointの保持は、Exchangeが連携して利用する大容量添付ファイル送信やTeamsメッセージの添付ファイルを保持する目的のために存在する機能なのかな～という感じがします。SharePointの情報調査や監査という意味では、バックアップ製品などでこまめに世代管理する必要があると感じます。 SharePointで削除されたアイテムは各サイトの「アイテム保管ライブラリ」にコピーされ設定期間保持されます。 各サイトというのがミソですね。しかも、サイト管理者から参照可能な場所に保持されるため、保持について理解のないサイト管理者はこのライブラリのアイテムURLを見ることができないユーザーに渡すなど困った行動を起こす可能性があります。 それでは保持を確認するために保持されるアイテムを準
コメントを投稿
続きを読む

あけまして

コロナから始まり、コロナに終わる。 今年は別の話題で終わると良いですね。 モーそろそろアフターコロナになりたいな〜と思います。  今日は何人でした。とかね、なんか昭和最後の年末年始をちょっと思い出す。 なんだかな〜って感じですね。
コメントを投稿
続きを読む

1000ユーザーの役職情報を削除しなさい

ActiveDirectoryを管理していると、「1,000ユーザーの役職情報を削除しなさい」なんてオーダーが出る可能性はある。 理由は何でもいい。似たような状況に置かれたと考えてほしい。 Q.急いでいるんだけど、いつまでに完了できる？ A.ん～～1ユーザー30秒かからないとして500分程度。大体8時間 　ちょっと残業すれば今日中に終わると思います。 これ、あなたの答えですか？ 先日までは私の答えもこれだったかもしれません。 でも、今の私なら、「それなら30分くらいもらえれば終わります」（余裕） なぜなら私にはPowerShellという武器があるから。 まぁ、以前から便利なのは知ってたんですけどね、使う機会がなくてスクリプトとしては使っていなかったんですよ。やっても「Export-SPWeb」みたいな単発の命令ばっかりで～ じゃぁ、スクリプトっぽくいくよ～ Import-Module ActiveDirectory $users = Get-ADUser -Filter * ForEarch($user in $users) { Set-ADUser -Identity $user -Clear Title } あとはActiveDirectoryを編集できる権限で実行するだけ。 5分で書いて1分実行。 ついでに確認用のコマンドをちょっと打って まぁ、20分は忙しそうなふりして遊びましょうか？ 本当に動かすときは、編集対象に問題がないかとか、ちゃんと編集できた確認とか やるべきことは色々あるけど、たった6行・・・ いや、最小限でいよく Import-Module ActiveDirectory Get-ADUser -Filter * | Set-ADUser -Clear Title 2行で終わるかも・・・ つぶしてもいい環境だったらこれでいいよね。 PowerShellの何がすごいかって、 今までの方法だと、サーバーに接続して・・・って言語すらまともに使えないのに～ って感じだったのが、それぞれのコマンドが勝手に必要な手順をこなしてくれるんですよね。 スクリプトやプログラム言語でActiveDirectoryからユーザー一覧を取得する。 これだけでも結構な行数のプログラムを書かなければならなかった？わけなんですが、 Get-ADuser -Filter
コメントを投稿
続きを読む