2019/03/16(土)CPU マイクロコードのアップデート

2019/03/16 6:36 サーバ運営・管理
昨年、CPU自体の脆弱性として、「Meltdown」(メルトダウン)と「Spectre」(スペクトル)というものが知られるようになり、対処するためにCPU製造メーカでは、「マイクロコードの修正・更新」という手法を使って居ます。

聞いたことはあっても、『マイクロコードって何?』的な方々が殆どだと思います。
これはCPUの基本的な仕組みを知らない方々に対して言葉で説明するのも難しい代物ですが、
できるだけ簡単に述べると、CPUに対する命令コード(いわゆる昔は「機械語」と言っていた)の解析・実行処理を司る部分の一部を、内部の配線を変更するかの如くに書き換えるのです。

実際に配線を変更するのではなく、同等の効果を得るようにファームウェアを書き換えるようなイメージが最も近いでしょうか。しかし、実際はCPU内部にファームウェアを持っているわけではありません。やはり、CPUの仕組みを習得してもらわないと的確な説明は難しいです、はい。

FreeBSD においては、Ports の中の sysutils/devcpu-data をインストールすることで可能です。
# cd /usr/ports/sysutils/devcpu-data
# make install
インストール完了時にこのようなメッセージが出ます:
The first method ensures that any CPU features introduced by a microcode
update are visible to the kernel.  In other words, the update is loaded
before the kernel performs CPU feature detection.

To enable updates using the first method, add the following lines to
the system's /boot/loader.conf:

cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"

This method will not load the microcode update until the system is
rebooted.

To enable updates using the second method, add the following line to
the system's /etc/rc.conf:

microcode_update_enable="YES"


Updating CPU Microcode...
/usr/local/share/cpucontrol/m32306c3_00000022.fw: updating cpu /dev/cpuctl0 from rev 0x17 to rev 0x22... done.
/usr/local/share/cpucontrol/m32306c3_00000022.fw: updating cpu /dev/cpuctl2 from rev 0x17 to rev 0x22... done.
/usr/local/share/cpucontrol/m32306c3_00000022.fw: updating cpu /dev/cpuctl4 from rev 0x17 to rev 0x22... done.
/usr/local/share/cpucontrol/m32306c3_00000022.fw: updating cpu /dev/cpuctl6 from rev 0x17 to rev 0x22... done.
Done.
インストール時にマイクロコードの更新は出来ているようですが、上記の英文見ると、どうやら自動更新させるために更に設定が必要なようです。
自分も含めて英語が苦手な方々向けに説明を残します。

1つ目:
/boot/loader.conf に下記の行を追記:
cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"
再起動で必要に応じ、マイクロコードの更新がされる模様。

2つ目;
/etc/rc.conf に下記の行を追記:
microcode_update_enable="YES"
OSブート時に必要に応じ、マイクロコードの更新がされる模様。

どちらか1つで良さそう(後者だけを指示しているブログ等も見かける)ですが、よくわからないので、とりあえず一応両方入れています。

2019/02/07(木)FreeBSD の portupgrade

2019/02/07 18:47 サーバ運営・管理
FreeBSDを10 から11にしたあと、portupgrade で ports 導入の各ソフトウェアを更新したりすると、
===>  Cleaning for ImageMagick7-nox11-7.0.8.22
--->  Cleaning out obsolete shared libraries
No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5
No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5
No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5
No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5
No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5
No such file or directory @ realpath_rec - /usr/local/lib/compat/pkg/db5
のようなメッセージが毎回出るようにになります。実害は無いのでほったらかし状態だったが、気になるものは気になるので、対策を。。
# cd /usr/local/lib/compat/pkg
# ls -al
lrwxr-xr-x  1 root  wheel        22  7月  4  2018 libdb_cxx-5.3.so.0@ -> db5/libdb_cxx-5.3.so.0
lrwxr-xr-x  1 root  wheel        18  7月  4  2018 libdb_cxx-5.so.0@ -> libdb_cxx-5.3.so.0
lrwxr-xr-x  1 root  wheel        22  7月  4  2018 libdb_stl-5.3.so.0@ -> db5/libdb_stl-5.3.so.0
lrwxr-xr-x  1 root  wheel        18  7月  4  2018 libdb_stl-5.so.0@ -> libdb_stl-5.3.so.0
lrwxr-xr-x  1 root  wheel        18  7月  4  2018 libdb-5.3.so.0@ -> db5/libdb-5.3.so.0
lrwxr-xr-x  1 root  wheel        14  7月  4  2018 libdb-5.so.0@ -> libdb-5.3.so.0
実に簡単。上記6つのシンボリックリンクを削除するだけ。これで解決しました。
OSをメジャーバージョンアップデートしたら、依存ライブラリは変更されていることが殆どなので、できるだけ早めに各ソフトウェアは再コンパイルするのが無難。

FreeBSD は、後方互換機能で何事もなく動作することが多いです。
しかしそれに頼り切っていると経験上、ある日突然、不可解な障害に悩むことになるのです。

2019/01/25(金)FreeBSD 12.0 カーネルにバグか

弊社管理サーバ19台の内、5台のサーバを FreeBSD12 に更新したのですが、そのうちの1台だけ、不定期に時折 Panic を起こして再起動を繰り返すサーバが・・・

ログメッセージにこんな感じで現れます:
Jan 25 04:15:46 uranus kernel: Fatal trap 12: page fault while in kernel mode
Jan 25 04:15:46 uranus kernel: cpuid = 1; apic id = 01
Jan 25 04:15:46 uranus kernel: fault virtual address    = 0xd8
Jan 25 04:15:46 uranus kernel: fault code               = supervisor read data, page not present
Jan 25 04:15:46 uranus kernel: instruction pointer      = 0x20:0xffffffff8091527d
Jan 25 04:15:46 uranus kernel: stack pointer            = 0x28:0xfffffe00185b9560
Jan 25 04:15:46 uranus kernel: frame pointer            = 0x28:0xfffffe00185b96b0
Jan 25 04:15:46 uranus kernel: code segment             = base 0x0, limit 0xfffff, type 0x1b
Jan 25 04:15:46 uranus kernel:                  = DPL 0, pres 1, long 1, def32 0, gran 1
Jan 25 04:15:46 uranus kernel: processor eflags = interrupt enabled, resume, IOPL = 0
Jan 25 04:15:46 uranus kernel: current process          = 0 (if_io_tqg_1)
Jan 25 04:15:46 uranus kernel: trap number              = 12
Jan 25 04:15:46 uranus kernel: panic: page fault
Jan 25 04:15:46 uranus kernel: cpuid = 1
Jan 25 04:15:46 uranus kernel: time = 1548357259
Jan 25 04:15:46 uranus kernel: KDB: stack backtrace:
Jan 25 04:15:46 uranus kernel: #0 0xffffffff8077a8c7 at kdb_backtrace+0x67
Jan 25 04:15:46 uranus kernel: #1 0xffffffff8072e4b3 at vpanic+0x1a3
Jan 25 04:15:46 uranus kernel: #2 0xffffffff8072e303 at panic+0x43
Jan 25 04:15:46 uranus kernel: #3 0xffffffff80a6496f at trap_fatal+0x35f
Jan 25 04:15:46 uranus kernel: #4 0xffffffff80a649c9 at trap_pfault+0x49
Jan 25 04:15:46 uranus kernel: #5 0xffffffff80a63fee at trap+0x29e
Jan 25 04:15:46 uranus kernel: #6 0xffffffff80a3f825 at calltrap+0x8
Jan 25 04:15:46 uranus kernel: #7 0xffffffff808feb43 at tcp_input+0x1553
Jan 25 04:15:46 uranus kernel: #8 0xffffffff80876a55 at ip_input+0x145
Jan 25 04:15:46 uranus kernel: #9 0xffffffff8084f496 at netisr_dispatch_src+0xd6
Jan 25 04:15:46 uranus kernel: #10 0xffffffff80833d83 at ether_demux+0x163
Jan 25 04:15:46 uranus kernel: #11 0xffffffff80834ee6 at ether_nh_input+0x346
Jan 25 04:15:46 uranus kernel: #12 0xffffffff8084f496 at netisr_dispatch_src+0xd6
Jan 25 04:15:46 uranus kernel: #13 0xffffffff80834184 at ether_input+0x54
Jan 25 04:15:46 uranus kernel: #14 0xffffffff8084b646 at iflib_rxeof+0xa16
Jan 25 04:15:46 uranus kernel: #15 0xffffffff80846476 at _task_fn_rx+0x76
Jan 25 04:15:46 uranus kernel: #16 0xffffffff80779154 at gtaskqueue_run_locked+0x144
Jan 25 04:15:46 uranus kernel: #17 0xffffffff80778db8 at gtaskqueue_thread_loop+0x98
Jan 25 04:15:46 uranus kernel: Uptime: 4h16m16s
Jan 25 04:15:46 uranus kernel: ---<<BOOT>>---
どうも、これに似ている模様・・・:
Bug 234296 - FreeBSD 12.0-STABLE r342216 Fatal trap 12

IPv4,IPv6 を直接扱う部分のようです。どうやら解決をみたらしいのですが、まだリリースバージョンへの反映はなされていません。FreeBSD12 への更新は様子見したほうがよさそう。

〔2019/02/06(Wed)追記〕
 昨日、リリースバージョン向けの対策版(FreeBSD 12.0-p3) が公開されたので、早速、本日未明から午前中にかけてFreeBSD 12 を稼働させている5台のサーバに対し、この不具合対策を行いました。
 数日様子を見て、安定しているようであれば他のサーバも FreeBSD12 に更新予定。

〔2019/02/28(Thu)追記〕
 どうも根本解決には至らない模様。頻度は減ったものの、5~6日経つと、勝手にリブートを繰り返します。
 なので、FreeBSD12 を運用環境に持ってくるのはお勧めできません。当面 FreeBSD 11系でやり過ごすことにします。

2019/01/17(木)ハードウェア不調によりサーバ1台交換。。

2019/01/17 5:13 サーバ運営・管理
昨年春頃から、動作不全に陥るようになったものの、直接、即サービスダウンに結びつくことは無い役割のサーバなのと、その度にハードウェアリセットで復旧するため、騙し騙し使っていたのですが・・

ついに今年に入ってから、ほぼ毎日動作不全に陥るようになったため、「もう寿命なのだろう」ということで、新品と交換。今回はこれ。
20190117_1.jpg


CPUはこれ(左側。画像クリックで少し大きな画像表示します)。店頭で販売していた最も安価なものを選んだ(要求される仕様からみて充分なので)んですが、4コアの模様。
今まで使っていたハードウェアのCPU(右側。画像クリックで少し大きな画像表示します)は新品で購入して、9年3ヶ月使っていた模様です。
20190117_2.jpg
 
20190117_3.jpg


CPUはまだ使えるのですが、SocketAM2 と称される仕様で、新品でマザーボードを入手するのは不可能。 HDDとかはある程度使い回しが利くのですが、最早、IDEインタフェースタイプの ATA133 とか、そういうものは普通に使えなくなっています。

2019/01/05(土)dovecot 2.3.4 はコンパイルエラーになる

2019/01/05 3:09 サーバ運営・管理
FreeBSD 11.2 または 12.0 にて、dovecot をソースコードから構築しようとすると、
途中で下記のようなエラーが出て、構築が出来なくなります:
test-event-stats.c: In function 'kill_stats_child':
test-event-stats.c:101:2: warning: implicit declaration of function 'kill'
[-Wimplicit-function-declaration]
(void)kill(stats_pid, SIGKILL);
^
test-event-stats.c:101:24: error: 'SIGKILL' undeclared (first use in this
function)
(void)kill(stats_pid, SIGKILL);
^
test-event-stats.c:101:24: note: each undeclared identifier is reported
only once for each function it appears in
gmake[2]: *** [Makefile:656: test-event-stats.o] Error 1
gmake[2]: Leaving directory
'/usr/local/src/dovecot-2.3.4/src/lib-master'
gmake[1]: *** [Makefile:565: install-recursive] Error 1
gmake[1]: Leaving directory
'/usr/local/src/dovecot-2.3.4/src'
gmake: *** [Makefile:683: install-recursive] Error 1
どうやら調査すると、構築環境依存による(?)バグらしく、パッチが出ていました:
https://github.com/dovecot/core/compare/10048229%5E...de42b54a.patch

このパッチでコンパイル自体は通りますが、実際の運用で問題ないかどうかまでは判りません。
dovecot 2.3.3 で特段問題が出ていない場合、2.3.4 へのアップデートは見合わせたほうがいいかもしれません。

2019/01/04(金)FreeBSD 12.0 に更新する際に気づいたこと

2019/01/05 1:38 サーバ運営・管理
20190104.png

FreeBSD11 からは、5年間(2021年9月まで)のサポート期間が明言されている状態なので、
急いでメジャーバージョンアップデート対応する必要性は無いのだが、やはり動作検証・安定運用の実績は必要なので、メジャーバージョンアップデートしてみました。

FreeBSD12 は、少なくとも 2023年末までのサポートになるものと思われます。
OSのメジャーバージョンアップデートは普通に出来ますが、Ports 等で導入したアプリケーションソフトウェアは、基本的に再構築をかけたほうが無難。

まず、portversion -v コマンドを実行すると、下記のようになります:
root[~][2]# portversion -v
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
[Reading data from pkg(8) ... pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
- 245 packages found - done]
Fetching the ports index ... pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
表示されたとおり、pkg-static install -f pkg を実行して対処します。
これだけでは駄目な場合があり、perl モジュール群の更新で、
encode.c: loadable library and perl binaries are mismatched (got handshake key 0xd480080, needed 0xe180080)
のようなエラーが出て更新自体が出来なくなることがあります。
FreeBSD12 アップデート後にこうなった場合は、現状では、
/usr/local/lib/perl5/site_perl 配下を再構築しないと駄目です。

なので、
# cd /var/db/ports
# rm -rf *
# pkg delete perl5-5.26.3
# cd /usr/local/lib/perl5/site_perl
# rm -rf *
のようにして、perl とその依存モジュールを一旦削除し(ports/pakkage 導入の場合)、
再度新規インストールし直す手順を踏む必要があります。

ここで、perl を最新バージョンへ更新する場合は、
# vi /etc/make.conf
として、以下の行を追記 or 変更します;
DEFAULT_VERSIONS+=perl5=5.28
尚、この手順を踏む前に、
# pkg info -r perl5-5.26.3
などのようにして、インストールされている依存モジュールをメモしておき、抜けが生じないようにしましょう。

あと、perl を最新バージョンにすることは必ずしも得策とは言い切れません。
perl の最新バージョンに対応していないモジュールがあって、パッチを入れる必要があるモジュールが少なからずありますので、このあたりは自己責任で対応してください。

2019/01/02(水)FreeBSD13 になると、10BASE-T LANのサポートは一部終了か

2019/01/02 6:04 サーバ運営・管理
2018/12/11 に FreeBSD 12 がリリースされましたが、
リリースノートの「6.3. Deprecated Drivers」(『非推奨デバイスドライバ』という意味)の中でこんな内容がありました。
The following drivers have been deprecated in FreeBSD 12.0, and not present in FreeBSD 13.0: ae(4), de(4), ed(4), ep(4), ex(4), fe(4), pcn(4), sf(4), sn(4), tl(4), tx(4), txp(4), vx(4), wb(4), xe(4)
要するに、FreeBSD 12 では「非推奨扱い」とし、 FreeBSD 13 で「削除する」扱いのデバイスドライバが列挙されており、大半が 10BASE-T をサポートするLANカード等。

弊社だと、ed(4) が1枚だけなので、影響は小さいですが、1~2年後に提供されるであろう FreeBSD 13 にアップデートする際に慌てないようにする上で、今から考慮しておいたほうがよさそう。

あと、FreeBSD でもサポートを打ち切る対象となるような古すぎるLANカードは捨てるしかなさそう。 いまどきの Windows あたりはとっくにサポート打ち切りとなっているので・・・

2018/08/20(月)IPv6 6to4 接続を常に優先させる

結構嵌ってしまったので、自分メモ。
ネイティブ IPv6 接続と 6to4 接続、及びローカルLANを1つのサーバに接続している(つまり、3つの回線を接続している)環境で、IPv6 接続が全く出来ない現象に遭遇しました。

どうも
〈サーバからインターネット側への接続〉→ IPv6 接続出来る場合と出来ない場合がある
〈インターネット側からサーバへの接続〉→ IPv6 接続は全く接続出来ない
〈同一ネットワーク又はLANの接続〉 → 問題ない
という現象のようです。

最初、pf のフィルタ設定に問題があるのかと思っていましたが、どうやっても現象は解消せず。
なので、インターネット側から ping6 を流し、tcpdump コマンドでチェックしてみます。
※こんな時に役立つ tcpdump コマンド・・・

すると、なんと! 勝手にNGN回線へパケットが流れている!
ルーティング状態を見てみます....
20180820_1.png


上記で re2 と示すのがNGN回線です。これでは応答を返しても相手に届かないわけです。

何故こうなるのか。。 
どうやら FreeBSD では、OSが立ち上がる時、最後に認識したLANボードで取得したルーティング情報をデフォルトゲートウェイにしてしまうようです。(というか、IPv6的仕様らしい?)
こんな時のために、「ルータアドレスをデフォルトゲートウェイにしない」という指定がネットワークインターフェースに対して出来るようになっています。

具体的には下記のように /etc/rc.conf に指定します(アドレス等は伏せ字にしています):
ipv6_default_interface="re0"
ipv6_defaultrouter="2002:c058:6301::"
ifconfig_re0_ipv6="inet6 2002:xxxx:yyyy:zzzz::qqqq/48 -accept_rtadv"
ifconfig_re1_ipv6="inet6 fdxx:pppp:gggg:hhhh::nnnn/64"
ifconfig_re2_ipv6="inet6 accept_rtadv no_radr"
2行目の、2002:c058:6301:: は、6to4 のリレールータIPアドレス(6to4 においては特に必要で無い限り固定)、
1行目の re0 は、6to4 で接続するネットワークリンクのLANボードを示します。

5行目、 re2 の no_radr というキーワードで、「デフォルトゲートウェイにしない」を指定します。
re0 をデフォルトインターフェースに指定することで、デフォルトゲートウェイが re0 のリンクになります。

/etc/rc.conf を修正後に再起動して、再度ルーティングテーブルを確認します:
20180820_2.png


これで、〈インターネット側からサーバへの接続〉は出来るようになります。
しかし、〈サーバからインターネット側への接続〉で、デフォルトインターフェースに re2 が勝手に選ばれ、NGN回線からインターネット接続しようとします。。

IPv6固有のアドレスポリシーテーブルを変更しないといけないようです。
デフォルトでは、このテーブルは以下のようになっています。
 ::1/128     50   0
 ::/0       40   1
 ::ffff:0:0/96  35   4
 2002::/16    30   2
 2001::/32     5   5
 fc00::/7     3   13
 ::/96       1   3
 fec0::/10     1   11
 3ffe::/16     1   12
2002::/16 の 6to4 エントリは不要です。
自ノードが使うアドレスがある場合、大抵は削除するとよいです。筆者の場合は以下のように変更しました:
 ::1/128     50   0
 ::/0       40   1
 ::ffff:0:0/96  35   4
 2408::/22    10   6
 2001::/32     5   5
 fc00::/7     3   13
 ::/96       1   3
 fec0::/10     1   11
 3ffe::/16     1   12
*1

上記内容を /etc/ip6addrctl.conf に作成し、root ユーザにて
# ip6addrctl flush
# ip6addrctl install /etc/ip6addrctl.conf
を実行することで、即座に反映します。
また、サーバ再起動時に /etc/ip6addrctl.conf を読み込むため、設定内容がその場限りで消えてしまうことはありません。

これで、〈サーバからインターネット側への接続〉も常に 6to4 が優先されるようになりました。

*1 : 2408:://22 の行はたぶん要らないと思う。。(動作は 2018/08/20現在 未確認)

2018/06/25(月)6to4 回線の IPv6 逆引きを公開設定

2018/06/25 5:10 サーバ運営・管理
今は日本人に優しい資料が無い(あってもちょっと古い)ため、いつもの備忘録代わりに作ってみました。
これを使うためには、
・当該サーバ等を 6to4(IPv4 回線における IPv6 トンネル接続) にて IPv6 に接続している。
・使用するIPv4アドレスは、固定IPである
・設定したい 6to4 IPv6 逆引きゾーンを登録する権限がある

といった前提条件があります。ネットワーク管理者中級向けといったところでしょうか。

この設定をするには、予め該当の 6to4 で使用する IPv6 アドレスの逆引きゾーンを登録したい権威DNSに登録しておかなければなりません。
例えば IPv4 アドレスで 192.168.1.50 に対応する 6to4 IPv6 アドレスは、2002:c0a8:0132::/48 となりますので、
逆引きゾーン 2.3.1.0.8.a.0.c.2.0.0.2.ip6.arpa を当該権威DNSへ登録してから以下の申請作業を行います。
#例示のIPv4 アドレスは、プライベートIPアドレス領域なので、逆引き登録は出来ません。

さて、この逆引きゾーン設定は、該当のホストマシン自身から、申請作業をWebブラウザでアクセスしなければなりません。
とはいっても、該当のホストマシン自体にWebブラウザをインストールしていない場合も多いはずです。この申請のために Chrome などわざわざインストールするのも馬鹿げています。

こんなときにさくっと役立つのが、昔から「テキストWebブラウザ」として存在する Lynx というソフトウェアです。前近代的な故、今どきのエンジニアな方々は知らないかもしれません。画像や動画、音声には対応しませんが、それ以外のコンテンツは何とか表示できます。

FreeBSD においては、 Lynx は Ports で簡単にインストールできます。(Portsツリー /usr/ports/www/lynx)
Lynx をインストールした後は、
lynx http://www.basekernel.co.jp/
のようにコマンドラインでURIを指定します。筆者の環境ではこうなります。。。
20180623_1.png
日本語がまともに表示できません。設定変更を行います。
何故かメニュー部分は文字化けしていませんで、o キー押下で設定画面が出ることがわかります。
ここで、o キーを押下すると。。。
20180623_2.png
なんと、設定画面も文字化け。。。
フォーカス部分は色が変わるようなので、下記の青緑色部分で示す部分を変更します。
#リターンキーや矢印キーを使います。
20180623_3.png
ここで、下記のような表示になるように矢印キーを操作し、リターンキー押下で設定が保存されます。
20180623_4.png
一度終了し、再度
lynx http://www.basekernel.co.jp/
とすると、今度は、
20180623_5.png
こんな感じで表示されるはずです。ここからが本題で、再び一度終了させ、
lynx https://6to4.nro.net/
とアクセスします。以下のような感じになるはずです。
幾つかサーバ証明書の警告が出ますが、yで強制的に進みます。
20180623_6.png
ここで、下の方にアクセス元のIPアドレスが表示されます。
どうやら IPv4 でアクセスしているようです。なので、直接IPv6アドレス指定でやってみます。
6to4.nro.net の IPv6 アドレスは、2002:ca0c:1dea::1 のようです。
#drill コマンドでAAAA レコードを正引きしてみただけです。

一度終了させ、
lynx https://[2002:ca0c:1dea::1]/
のようにすると、今度は受付する画面になりました。
20180623_7.png
ここでパスワード(削除の際に必要になる模様)を入力し、
20180623_8.png
更に、連絡先のメールアドレス、ゾーンを登録した権威DNSサーバ名を入力し、
Submit させます。
尚、連絡先のメールアドレスと2つの権威DNSサーバ入力は必須のようです。

受理・逆引き登録が完了すると、
20180623_9.png
のようになります。何らかの問題があると英語でメッセージが表示され、この画面にはなりません。

同時に登録完了で以下のような電子メールが apnic より送信されます。
20180623_a.png
SOAレコードに登録した電子メールアドレスにも同内容の電子メールが行きますので注意してください。

2018/06/11(月)IPv6の基礎(12) -トラブル対処で役立ちそうな知識

今回は、トラブル対処や調査で出くわしてしまうような場面で、知っていれば何のことは無い、という話題です。
20180611_1.png
実は、IPv6には「一時アドレス」という概念があります。(RFC4941 で規定)
これはサーバ管理者泣かせな機能なのですが、一定時間ごとにどんどんIPv6ユニキャストアドレスが新しくなっていくのです。
そうです。これは「発信元を特定しにくくする」ためのものです。
#これも個人的には、セキュリティに過度に煩い層の影響だと思う。。

サーバ攻撃を受けた際に発信元が分かりにくくなり、原因究明に大いに影響ありそうなのです。
これを逆手にとって、ネット犯罪を助長するような一面があり、しかしながらプレフィックス部はどんなに IPv6 アドレスが変わろうが固定なので、どこまで効果があるかは疑問が残ります。

IPv6 ではリンク毎に「リンクローカルユニキャストアドレス」が付与されるという話を何度かしてきました。
早い話、LANカード或いはイーサネットデバイスが同じ機器に複数あると、その数だけ同じ機器にリンクローカルユニキャストアドレスは割り当てられるのです。
リンクローカルユニキャストアドレスはプレフィックスが同じですので、実際に通信する際は、%で始まるインタフェース名を補助的に使用して、リンクを区別します。
OK キャンセル 確認 その他