NTP

NTPは、基点である1900年1月1日 00:00:00(UTC)からの経過秒数を32ビットで返す。これはつまり、2³²−1秒、すなわち4,294,967,295秒までしか数えることができない。これを超えた場合、経過秒数は0に戻ってしまう。

この起点から無符号32ビット値で表現可能な日時は、2036年2月7日 06:28:15(UTC)、つまり2036(令和18)年2月7日15:28:15(日本時間)(@311)であり、これより後を表現できない。これが、いわゆる2036年問題である。

対策方法は大きく二種類が考えられる。日時部分の値を64ビット長に伸ばすか、または32ビットのまま維持しその扱いを変更するか、である。SNTPv4(RFC 4330)およびそれを取り込んだNTPv4では対応案が提案されており、後者が選ばれた。

秒数は32ビット無符号の数値だが、この最上位ビットを見て動作を変更する。これを著している2018(平成30)年現在、日時を表わす情報は最上位ビットが立った状態である。また、最上位ビットが0つまり立っていない最後の年は1968(昭和43)年だった。

さて、NTPが送信するのは「現在日時」であるので、過去が表現できなくても何の問題もない。そこで、次のようにする。

• 0x80000000〜0xffffffff: 1968年〜2036年 (2036(令和18)年2月7日15:28:15(日本時間)(@311)まで)
• 0x00000000〜0x7fffffff: 2036年〜2104年 (2036(令和18)年2月7日15:28:16(日本時間)(@311)から)

今のうちから、このように実装を改めれば、特段大きな問題にはならないと考えられる。

この解決方法は同時に2104年問題を含むことになるが、この年が近付いた頃に同様の対応をすることで、問題なく対応できるものと考えられている。

福岡大学は日本初のNTPサーバー(clock.nc.fukuoka-u.ac.jp)を1993(平成5)年から公開している。

このサーバーのアドレスが各種時計合わせアプリのデフォルトとして設定されたり、ブロードバンドルーターのファームウェアに設定されたりしたため、2005(平成17)年頃にはアクセスが毎秒900件を超えるようになり管理者を悩ませることとなった。

2017(平成29)年10月のENOG47 MeetingではNTPだけで180Mbpsの帯域を消費しており、毎秒21万の時刻要求があることが紹介された。

そしてついに2018(平成30)年1月のJANOG41 Meetingで「福岡大学のNTPは停止します!」と発表された。

ただし、単純にNTPサーバーを停止させるとリクエストパケットが極端に増大することから、停止に向けた技術検証が行なわれる。

日本の独立行政法人情報通信研究機構は2006(平成18)年6月から一般向けに日本標準時と直結されたNTPサーバー(ntp.nict.jp)を提供している。

公開された時点で毎秒100万リクエストを処理可能であるとしている。

NTPはその仕組み上、ネットワーク的な距離や物理的な距離が近いほど正確な時刻を取得できる。

そのため、自分が直接接続しているネットワークのISPが提供するNTPサーバーへアクセスするのが最善の設定である。

使用しているISPがNTPを提供していない場合には、NICTのNTPサーバーを使用するのが次善の策だろう。