|
2026 年 2 月 27 日 (金) 10 年振りのニュース
!!
筑波大学発ベンチャー ソフトイーサ株式会社
代表取締役 登 大遊
IPv6
生アドレスで「更新専用アドレス」を指定されている方へ - パケット送付先 IPv6 アドレスの変更のお願い
「スクリプトを定期的に動作させることができない専用デバイスや IoT 機器」で使用されている場合で、FQDN 指定ではなく
IPv6 生アドレス指定で更新専用アドレスにパケットを定期的に送付されている場合は、2026 年 4 月 1 日以降は新しい
IPv6 アドレスへの送付をお願いいたします。
「OPEN IPv6 ダイナミック DNS for
フレッツ・光ネクスト」サービス (https://i.open.ad.jp/)
を公開してから、約 10 年間も経過いたしました。本実験サービスは、さまざまな試行錯誤の結果、たいへん安定して稼働しており、これまでに
NTT 東日本フレッツ域内の少なくとも 47,000 人のユニークなフレッツ回線のユーザーの方々 (ホスト作成数)
にいろいろな目的でご利用いただいている、フレッツ用大当たりヒット型目玉的無償・無保証学術実験サービスとなっております。誠にありがとうございます。
さて、本サービスを
「スクリプトを定期的に動作させることができない専用デバイスや IoT 機器での使用方法」
で利用されており、かつ、更新専用アドレスに対するパケットを発射される際、発射先のアドレスを IPv6
生アドレスで指定されているユーザーの方々 (すなわち、更新専用アドレスとして "FQDN (DNS ホスト名)"
を指定されていない方々) に、このたび、以下のお願いをいたします。
記
- 1. 前提
各ホストの更新専用アドレス (生 IPv6 アドレス)
につきまして、上位 56 ビットのプレフィックス部分は、2016 年のサービス公開当初から現在まで、
「2409:11:c0e0:400::/56」
というアドレスになっていました。すなわち、
「スクリプトを定期的に動作させることができない専用デバイスや IoT 機器での使用方法」 にあるような、DNS
クライアント機能を有さない機器で、定期的に ping (ICMP), NTP, SNMP トラップまたは syslog
を送付する機能で、いわば無理矢理に本サービスの登録済みホストの IPv6
アドレスの自動更新をされるような仕組みを構築されているユーザーの方々は、それらのネットワーク機器等のコンフィグファイルの中には、「2409:11:c0e0:4**:****:****:****:****」のような
IPv6 アドレスに謎の ping (ICMP), NTP, SNMP トラップまたは syslog
を定期的に送付する設定をされていらっしゃるものと思います。
- 2. お願い
「スクリプトを定期的に動作させることができない専用デバイスや IoT 機器」で使用されている場合で、FQDN
指定ではなく IPv6 生アドレス指定で更新専用アドレスにパケットを定期的に送付されている場合は、2026 年 4 月
1 日以降、登録されているホストレコードの IPv6 アドレスを更新 (変更) される場合、各ホストの更新専用アドレス
(生 IPv6 アドレス) の上位 56 ビット部分を
「2409:11:dea0:3d00::/56」
に置き換えたアドレスに送付いただきますようお願いいたします。
なお、2026 年 2 月 27 日 (本日)
から、すでに新しい更新専用アドレスのシステムは稼働しておりますので、2026 年 4 月 1
日を待つことなく、本日時点でこの新アドレスを利用いただくことも可能です。
- 3. ホストごとの「更新専用アドレス」の具体的 IPv6 アドレス (新しい更新専用アドレス)
の確認方法
「登録済みのホスト一覧」から確認できます。
※ ホスト一覧にホストが表示されない場合は、「DDNS
ホストキーリストの編集」から表示追加可能です。「DDNS
ホストキーリストの編集」におけるホストキーが不明な場合は、トップページにある再発行フォームからメールアドレスを指定していただき、ホストキー一覧をメールで取得可能です。
また、現在使用されている各ホストの更新専用アドレス (生 IPv6 アドレス) の下位 72 ビットを 16
進数で、ハイフン抜き、かつゼロ埋めで大文字表記した文字列がホストキーです。メールアドレスを登録されていなかった方も、この方法でホストキーを取得可能です。
- 4. いつからこの新しい更新専用アドレスが利用可能か?
上述のとおり、本日以降、この新しい更新専用アドレスに対してパケットを送付いただくことが可能です。
- 5. いつまでにこの新しい更新専用アドレスを利用することとする必要があるのか?
2026 年 4 月 1 日以降、登録済みホストの IPv6 アドレスを、IPv6
生アドレスで「更新専用アドレス」を用いて更新される際には、この新しい更新専用アドレスを利用する必要があります。
- 6. あるネットワーク機器に、古い更新専用アドレスに対して定期的に ping (ICMP),
NTP, SNMP トラップまたは syslog
を送付するコンフィグを記載している。そのネットワーク機器のコンフィグにおいて、いつまでにこの新しい更新専用アドレスを利用するコンフィグの書き換えをする必要があるのか?
特にコンフィグの書き換えを必要とする期限はありません (書き換えなくても、登録済みホストの IPv6
アドレスが本サービスの DNS レコードから消えることはありません) が、2026 年 4 月 1 日以降、機器の
IPv6 アドレスが変更となった場合で、その新しい IPv6 アドレスを、登録済みホストの IPv6
アドレスとして変更されたい場合は、その時までに、コンフィグの書き換えが必要です。(書き換えをしていないと、登録 IPv6
アドレスが変更されません。)
- 7. 2026 年 4 月 1 日までに IPv6
生アドレスとしての「更新専用アドレス」を新しいものに変更しないならば、通信ができなくなるのか?
いいえ。「6.」で述べたとおり、すでに登録済みホストの IPv6 アドレスが本サービスの DNS
レコードから消えることはありません。したがって、2026 年 4 月 1 日になると通信が切れるということはありません。ただし、その DNS レコードの IPv6 アドレスを 2026 年 4 月 1
日以降変更されたい場合は、新しい「更新専用アドレス」を使用いただく必要があります。
- 8. 私のサーバー、VPN ルータ、NW
機器等は、「update-xxxxxxxx.i.open.ad.jp」のような更新専用ホスト名を用いて HTTP,
HTTPS, ping (ICMP), NTP, SNMP トラップまたは syslog
を送付する先を指定しているが、何らかの変更作業が必要か?
いいえ。update-xxxxxxxx.i.open.ad.jp のような更新専用ホスト名を FQDN
で指定されている場合、その FQDN に対応する IPv6
生アドレスとしての「更新専用アドレス」は、すでに「2.」で述べた新しい IPv6
プレフィックスを応答するようになっていますので、何らの変更の必要はありません。
- 9. 2026 年 4 月 1 日以降、古い IPv6
生アドレスとしての「更新専用アドレス」を用いた更新は利用できなくなるのか?
2026 年 4 月
1 日以降も、古い IPv6
生アドレスとしての「更新専用アドレス」は、光ファイバの延長等の工夫により、できるだけ延命できるように努めたいと思います
(下記 (3)
参照)。しかしながら、建物改修により物理的に光ファイバが切れてしまう期間が発生する可能性があり、かつ、その期間は比較的長期となる可能性があるため、本お知らせにより、2026
年 4 月 1 日以降は、できる限り、新しい
「更新専用アドレス」を用いた更新を利用していただくようお願いすることにしました。
なお、このたびの各ホストの更新専用アドレス (生 IPv6 アドレス) の上位 56
ビットのプレフィックス部分の変更の理由・原因は、次のとおりです。
(1) 本実験サービスの目的は、非営利・無償・無保証の学術目的の実験サービスの構築
(構築そのものが学術的実験である) であり、筑波大学
OPEN プロジェクトというネットワーク実験の一部機能として、2016
年 6 月 14 日 (約 10 年前) に、非常にいいかげんに急いで開発・構築したものです。IPv6
生アドレスで「更新専用アドレス」を指定するためには、NTT 東日本のフレッツ NGN 網内で /56 の IPv6
アドレス宛のパケットをすべて終端する (吸い込む) 特殊なサーバー (以下「スペシャル・サーバー」という。) を、1
個、設置する必要があります。さらに、このスペシャル・サーバーは、NGN 網内と IPv6
インターネットの両方から到達可能である必要があり (一部のユーザーはインターネットからも DDNS
を利用されることを想定しているため)、技術上の理由により、NTT 東日本の NGN
網内アドレスで設置することができません。われわれは、2016 年 6
月時点で、筑波大学のある建物内に引いていた実験用フレッツ回線 (UNI)
に、このスペシャル・サーバーを設置しました。当時は、筑波大学の当該建物の寿命は、本サービスの賞味期限よりも十分長いと予想していました。
(2) 各ホストの更新専用アドレス (生 IPv6 アドレス) の上位 56
ビットのプレフィックス部分は、2016 年のサービス公開当初から現在まで、
「2409:11:c0e0:400::/56」というアドレスになっていました。これは、以下の図 1 の赤枠の NGN
UNI 装置に /56 でルーティングされるようになっています。
図 1. 引っ越し元: 2016 年 6 月 14 日 (約 10 年前)
に、われわれが筑波大学内で非常にいいかげんに急いで開発・構築した際の /56 Prefix
の「スペシャル・サーバー」用の実験用フレッツ回線 (赤枠が装置)
(3)
ところが、当初の予想に反して、本実験サービスよりも、筑波大学の当該建物の寿命のほうが先に到来してしまいました。当該建物は、延命のため、2026
年 4 月ごろから、大幅な改修工事を行なう予定です。この間、当該建物の電気供給が途絶えます。そうすると、本 UNI
回線の ONU の電気が切れてしまいます。そこで、最寄りの NTT
東日本局舎からこの大学建物に来ている光ファイバを、自前ケーブルあるいは NTT
東日本ダークファイバで大学内外の他の建物にレイヤ 1 で伝送することで、別の建物に ONU
を移設することを検討していました。これが実現すれば、今回の IPv6 アドレスの変更は不要になります。しかしながら、NTT
東日本から当該建物の光ファイバを収容するボックス (光キャビネット) までの数十芯の太い多芯光ファイバケーブル
(これは、地下を通って建物に入ってくる) が、建物備付けの古典的金属箱
(その金属缶には小さな穴が空いており、光ファイバはその穴の中を通っている)
の内部を通過しており、かつ、その金属箱を建物改修とともに取り外さなければならない可能性が高くなりました。この際、物理的に、光ファイバを光キャビネットから切断しなければなりません。そうしなければ、金属箱を取り外すことができないためです。さらに、金属箱を取り外しに成功した後も、その
NTT 収容ビルから来るフレッツ用ファイバの線端に、構内光ケーブルまたは NTT
ダークファイバの別の芯線を接続し他の建物に中継するためには、SC
コネクタあるいは融着による折返しが必要です。この接続作業は技術的には可能と見込まれますが、建物改修工事中は室内で相当過酷な環境に置かれ、作業等によって折れ曲がりが発生してしまう可能性があります。光ファイバの最小半径を考慮すると、折れ曲がりはかなりのリスクです。そして、突然折れ曲がりが発生した場合でも、工事中は安全のため当該建物に立入ることが困難となる見込みです。
(4) そこで、この際、上記 /56 のスペシャル・サーバー用 Prefix を収容する NGN
用の装置を、つくばにある NTT 収容ビル内に建設したラックに新たに敷設する UNI
回線に収容してしまうことにしました。つくばにある NTT 収容ビルには、NTT
東日本を含めたさまざまな通信キャリアの装置が設置されており、建物改修工事が必要となった場合でも、通信機器を稼働させたままの改修工事がなされる見込みが高く、同収容ビルの寿命は、本サービスの寿命よりも長いと予想されるためです。
(5) ところが、技術上の問題により、大学にある現在の上記 /56 のスペシャル・サーバー用 Prefix
を、つくばにある NTT 収容ビル内に建設したラックに新たに敷設する UNI
回線に収容することができないことが分かりました。そこで、この際、上記 /56 のスペシャル・サーバー用 Prefix
を新しいものに変更することにいたしました。
(6) われわれの予想が正しければ、今回の設置場所変更により、今回の上記 /56 のスペシャル・サーバー用
Prefix は相当長期 (さらに今後十年間以上) にわたり稼働し続けることができると考えられます。しかしながら、われわれの予想に反して、本サービスがさらに長期間継続し、いよいよ、つくばにある
NTT 収容ビルの寿命を超えることとなったような場合は、将来、上記 /56 のスペシャル・サーバー用 Prefix
を再度変更する必要が生じる場合があります。
もう 1 つの心配事は、上記 /56 のスペシャル・サーバー用 Prefix を収容している、2409:0010::/28
を供給しているインターネットマルチフィード株式会社の NGN 用 IPoE
インターネット接続機能の将来の仕様または挙動の変化・終了が、本サービスの寿命よりも先に到来した場合、将来、上記 /56
のスペシャル・サーバー用 Prefix
を再度変更する必要が生じる場合があるという点です。この懸念を解決するためには、上記 /56 のスペシャル・サーバー用
Prefix を NGN 内の閉域専用収容アドレス装置 (SNI) に収容する必要があります。そのようにすれば、固定的な
NGN
網内アドレスを実現可能です。ただ、この場合、インターネットからの更新パケットが届かなくなってしまうというデメリットがあります。メリットとデメリットを比較検討した結果、当面の間は、上記
/56 のスペシャル・サーバー用 Prefix は、2409:0010::/28 内に設置継続することにしました。
図 2. 引っ越し先: このたび本サービスの寿命よりも長いビル寿命 (おそらく) が見込まれる、つくばにある NTT
収容ビル内に建設した自前ラックに設置した、「スペシャル・サーバー」を収容するための物理ポート (赤枠が /56
Prefix の UNI を収容するポート) (「スペシャル・サーバー」自体は別の場所にある)
図 2 の設備は、動画として、以下の YouTube ビデオに収録されています。
2026/2/28 追記
(1) 多数の装置でスペシャル・パケットを送付されている方々へのご朗報
「たくさんの
IPv6 DDNS ホストを作成して利用しているが、それぞれの装置の Config
を正しく更新したかどうか分かるように、どの装置が旧スペシャル・サーバーにパケットを送付してきていて、どの装置が新スペシャル・サーバーにパケットを送付してきているか分かる機能が欲しい」という複数のユーザーの方々
(実は NTT 東日本の社員などらしい) から要望がありましたので、このたび、ホスト一覧表および API
によるホスト一覧応答フィールドに、「直近更新試行通信方法」、「直近日時」、「累積更新試行回数」を追記し、「直近更新試行通信方法」が「ByPacket1」の場合は旧サーバー、「ByPacket2」の場合は新サーバーを意味することにより、識別可能にいたしました。
詳しくはホスト一覧ページおよび API マニュアル の「TryRenewDt」、「TryRenewMethod」、「TryRenewCount」の説明書きをご刮目ください。
(2) NTT 西日本で使用されたい方々のためのご朗報
NTT
西日本のフレッツ回線から本 DDNS サービスの IPv6 アドレスの更新が可能な中継サーバーを Asei SEKIGUCHI
氏 (筑波大学の大学院生) が作成しました。
説明書が
https://ddns-proxy.asei.gv.vc/ にあります。
なお、上記の中継サーバーは、おそらく安全だと思いますが、技術的には、原理上、伝送されるホスト鍵に中継サーバー管理者が触れることができますので、ご注意ください。そのリスクは、だいたいは、たとえば
Anthropic 社を信用する日本企業や行政機関が秘密情報を有するプロンプトを
Microsoft Azure や
Microsoft Copilot の AI サービスを経由して Anthropic 社の Claude AI
を呼び出す場合に、その入力プロンプトを平文で中継者である米
Microsoft 社が読み、学習し、記録し、他者に提供し、他の目的で利用することが技術的にできてしまうリスク、かつこれらがないことの安全性を外側から技術的に検証不能であるリスクと同質のリスクです。あるいは、日本企業や行政機関がクラウド型の
CDN (例: Amazon
CloudFront,
Elastic Load Balancing など) あるいは HTTPS 中間者 (Person in the
Middle) 暗号解読型 HTTPS Web アクセスプロキシサーバー (Zscaler
など) を利用して HTTPS 終端をさせるとき、そういったクラウドサービス等の管理者が、HTTPS を流れる機密通信
(個人情報、入力パスワード文字列、二段階認証設定時の秘密鍵としての QR コードの画像、Cookie のセッションキー等を含む)
を読み、学習し、記録し、他者に提供し、他の目的で利用することが技術的にできてしまうリスク、かつこれらがないことの安全性を外側から技術的に検証不能であるリスクと同質のリスクです。これらはどのような契約約款
(よくよく読むと、データ漏洩時のような損害賠償の上限額が直近一定月分の料金に制限されている)
やプライバシーポリシーや「オペレータが通常データを読めないように自作ソフトで制御している」
と主張する検証不能なブラックボックス自作システム
(そのシステムのソースコードそのものの外部監査の仕組みもなく、顧客はその実装を検査不能)
に関する宣伝など作文され掲載してあったとしても防ぐことは技術的に不可能です。そして、われわれは直接知っている日本人が自ら作り、日本人のみで運営するサービスの信用は、われわれの知らない外国人
(例: Amazon 社の事業活動は、一見して米国企業であるとしても、実際には、2020
年以降、米国における著しい人材不足により、多数の高度コンピュータ技術を有するさらなる第三外国人技術者群に頼って運営されている
2) の運営するサービスの信用よりも明らかに高いと評価します。したがって、日本企業は、Microsoft
Azure や Copilot、Amazon CloudFront、Zscaler
などを利用しているのであれば、それと同等以上の安全性をもって、上記の NTT
西日本用の中継サーバーを利用することが可能であるとわれわれは考えます。この文章は、上記中継サーバーが中継をすることに係る情報セキュリティ上の信用・安全性は、Microsoft
や AWS、Zscaler
等における同様の中継時の安全性よりもすくなくとも相対的に高いことを主張するものであり、これらの米国企業の情報セキュリティ上の信用・安全性の高低を述べるものではありません。
以上
|