Protocolフィールドが139なIPパケットについての情報へのリンク(TCPやUDPではなく、またPortが139なのではない)。/etc/protocolsに載ってない機械だらけだけどIANA登録済み
- IANA Protocol Numbers
- RFC7401 Host Identity Protocol Version 2 (HIPv2)
- OpenHIP
タグ: rfc
NTT VG230i – ひかり電話SIP <-> ISDN ゲートウェイ
電波時計で 2012-12-12 12:12:12 を見ようと思っていたら、過ぎてました。
あまりのショックにというわけではないですがVG230i
Server: mcas/3.0 (VG230i 2.0.0.0; B2BUA; NTTEAST/NTTWEST)
を4台ほどNTTより取り寄せ、某所で予定より早く使う必要が出たので試しにいじってみました。取り寄せる前にオンラインで取扱説明書を見ました。「テレホタイム」という言葉が存在していた10年以上前になんかよくわからんけど P-MP で申し込むんだぁ!と申込書にチェックを付けた懐かしい記憶がよみがえり、今や自分が P-MP or P-P の設定をする側の立場になれるのかと優越感には浸れるものの、知りたいSIP/2.0側の情報は「本商品は、接続後、ひかり電話ルータが自動設定サーバから取得したひかり電話の設定情報を自動的に取得します」ということしかわかりません。無いよりましそうなので気づいたことを順不同で羅列しておきます。「ひかり電話」、「自動設定サーバ」ですぐに何のことかわかる人には(にも)不要な情報だと思われます。
ファームウェアのバージョンや組み合わせるNGN/フレッツ網やひかり電話ルータによって違う動作をするか、あるいはまったく動作しないかもしれません。あと下の拠点bのRV-230SEでは動作しましたが、そもそもBフレッツはVG230iの対応する動作環境とはなっていないようです。下記のDHCPに対応できていないひかり電話ルータがあるとかいう話でしょうか、それともQoS絡みでしょうか。あしからず。
- VG230i 2.0.0.0
- 使用したひかり電話ルータ/ホームゲートウェイ: RT-400NE 4.02(フレッツ光ネクスト)(拠点a) および RV-230SE 16.14(Bフレッツ)(拠点b)
- 横で動作していたルータなど: 拠点a,b ともに NVR500(ATAとして) 11.00.19 および RTX1200(PPPoEおよびVLAN担当) 10.01.42
- 「ひかり電話ルータが自動設定サーバから取得したひかり電話の設定情報を自動的に取得します」の「設定情報を自動的に取得します」とはDHCPのことらしい(((Bフレッツ版では:DHCPにてIPアドレス等を取得した場合の技術条件 -) ユーザ・網インタフェース仕様 – レイヤ3の仕様 – IPv4プロトコル)。VG230iにログされているDHCP後の「簡易設定」は意味が良くわからないのでパケット見るしかないかも。
- ログから見るとDHCP optionは 1,3,6,51,53,54,58,59,90,120,125 が渡ってきている模様
- ログから見るとその直後に「簡易設定」なるものをして「自動設定」が完了する模様。
- VG230iの設定ページから自分で好きなSIPサーバを設定することはできない。
- 端末とは「音声利用IP 通信網サービス（第2種サービスタイプ2）に接続される端末機器のうち、セッション制御用ユーザエージェント（SIP-UA）を実装するものを指す。特に、網に対して、セッションを起動する側の端末を発端末、網からセッションを起動される端末を着端末と呼ぶ。」そうです。Bフレッツ（第2種サービスタイプ1）版にも同じことが書いてあるのは第6.0版でのコピペ後の修正忘れでしょうか。
面白そうな項目など
- アドレス重複時の対策
- 「また、端末が利用可能なIPv4アドレスは、網に接続する際に網から割り当てられたIPv4アドレスの範囲のみで、その他のIPv4アドレスを利用した場合の動作は保証されません。」
- 音声利用ＩＰ通信網サービス（第1種サービス）のインターフェース-ひかり電話ビジネスタイプ- では、「また、発ユーザが通知したい発番号を送信INVITEのP-Preferred-Identityに設定することで着ユーザにその番号を通知可能とします。」となっている。ビジネスでなら当たり前なことができるということか…それとも実はひかり電話でもできる?
- 関係なさそうだけどなんかみつけたので気が向いたら読む。特開２００９－２００９８０
というわけで PPPoEパススルー している人はひかり電話ルータのDHCPサーバを使っていない人が多いでしょうから、ひかり電話ルータのDHCPサーバを動作させてVG230iに「設定情報を自動的に取得」させてあげる必要あり(PPPoEパススルーのままで動作してました)。”ngn type lanX ntt”したRTX1200やNVR500のDHCPサーバはもしかしたらVG230i用に使えるのかもしれない(*1)(確認してません)。
既にひかり電話ルータに自力でSIP接続している場合は以下のように内線設定が自動的に書き換えられてしまうので、VG230iを接続する前に受け入れ態勢を整え、ひかり電話ルータの設定を保存しておかないと半べそになります。
- VG230iが端末登録(ユーザ網インタフェース仕様 – セッション制御(ここはセションではないのねん))するとひかり電話ルータは、「使用する」にチェックがついていて、その時点でSIPでREGISTERされていない内線を相手に明け渡し、相手のMACアドレスをその内線設定に書き込む。VG230iに対してRV-230SEはSIPユーザIDとSIPパスワードも渡したことを確認。ちゃんと網羅して確認していないがユーザIDとパスワードをブランクに設定し、あるのはMACアドレスのみにするという場合もあったように見える。
- 気づいて別の内線に変えようとしてもMACアドレスが重複する設定はできないので、SIPクライアント側を切断(expire 0)してLANケーブルを抜くか、あるいは「使用する」のチェックを全部はずし、勝手に変更されて困った方の内線設定をあって欲しい姿に戻してから、接続してほしい方の内線設定にMACアドレスを設定してやり直す、という不毛な作業が発生します。
ISDN側にもいろいろつなげました。手近にあったTAを1台とNVR500を2台の計3台、NVR部分はなつかしのBMJ-8相当の分岐を使ってLANケーブルでバス接続、できあがった全7個のアナログ回線には計14個のRJ11 RJ45アダプタを利用しLANケーブルで家庭用電話機やモデムと接続、NVRはLANに接続、さらにTAのRS-232CのDB9ピンにもRJ45アダプタを利用した挙句にRS-232CのついているPCが離れていたので RS-232C LANコンバータ を2台使用。普段からなんでもLANケーブルで済ませるという横着のおかげでアナログ電話周りなのにLANケーブルだらけの変態試験環境になってしまいました。LANケーブルをLAN用に使っている部分はNVRのsyslog出力用と、RS-232C over IPの部分だけですね… 一部で人気の某機のようにひかり電話ルータが出力するモデムダイアルインやナンバーディスプレイ信号で誤動作することもなく(SIP機とアナログ線機で対決させては非常にかわいそうだけど)、NVRの吐くsyslogをsyslog-ngに喰わせて簡単なシェルスクリプトで自分好みのCTIになったところで満足して解体。倉庫からホコリをかぶったホームテレホンを引っ張り出してくる元気は無かったのでここで終了。発信者番号が1つに固定なのが悲しいので、全部の発信者番号で内線登録してでもなんとかするといった改善をしてくれればもう8,400円はお買い得と思われます。というか1IPアドレス1内線(ユーザ網インタフェース仕様 – セッション制御 – 端末登録 – 端末登録の制限)というひかり電話側のしょぼい制限を昔のように無くしてもらえないものだろうか…
FAXは1つのFAXモデムを、受信2回線、送信1回線で使うために TELFAX MINI P&Pというかゆいところに手が届く製品を多く作っている会社の切り替え機を使ってしましたが、ついでにここもシンプルに整理しよう。
落書きのようなものなので随時追加、修正します。読みづらくてすいません。間違いなどはコメントで教えてくださいませ。
(*1) 2017/6/8追記: 実験されたmobu様よりIPアドレスも割り振られないとのご連絡をいただきました。確かにこの状態ではSIPサーバがどこにもいないのでSIP <-> ISDNゲートウェイであるVG230iが動作する由もないのでした。
IPv4無くなりました
枯渇時計を表示させていた方はお気づきのことでしょうが、IANAから通常の分配が終了し、Two /8s allocated to APNIC from IANA や 【速報】IANAからAPNICへ、二つの/8ブロックが割り振られました によると近日中に最後の/8の5ブロックを5つのRIRに割り振って完全終了になるそうです。v4.fullbogons.cymru.com は今年から来年にかけて bogons.cymru.com との違いがほとんどなくなるはずです。(Bogons vs. Fullbogons – what’s that all about?) とはいえまだあるっちゃあるわけですが…
2011/4/16 追記:APNICにも通常割り振りの在庫が無くなったそうです。
2011/2/5 参考追加
DNSSEC始めました
祝ルートからJPへのチェイン。弊社が利用しているドメイン(co.jp jp ch me es be dk com net org…)もすべてDNSSECおよびDANE/TLSA対応完了。DNSSECが有効でTLSA RR,CAA RRにも対応したセカンダリDNSサーバ,DANE,TLSA,DMARC,DKIM,SPFに関するご相談は弊社へどうぞ。と宣伝をしたところで以下は設定を確認するためのリンク集と自分で確認する手順。
server does not support RFC 5746, see CVE-2009-3555 (was: potentially vulnerable to CVE-2009-3555) Apache HTTPD + OpenSSLでRFC5746リネゴシエーション対応
CVE-2011-0411 Plaintext command injection in STARTTLSはこちら
Bug 549641の変更をここのタイトルにも入れてみました(2010/9/14) 。元々「潜在的に脆弱」という微妙なメッセージから書き起こしたエントリなので、文章のつながりが悪くなったかもしれません。
CVE-2009-3555はDescriptionによればSSL3.0(とおそらくそれより前)とTLSプロトコルにおいて、”renegotioation”でMITM攻撃者がデータを挿入可能である、というものになり、去年の11月に業界(?)を震撼(?)させたものです。
この問題を解決するべくIETFのTLSな方たちは世のため他人のため、ものすごい勢いで”secure renegotiation”(安全な再ネゴシエーション)を定義して本年2月までにRFC5746にしてくれました。
表題のメッセージはFirefoxがhttps://なサイトにアクセスした場合や、ThunderbirdがSSL,TLSでPOP3, IMAP4, SMTPアクセスした場合などなどでエラーコンソールにログされるものですが、mozilla wiki Security:Renegotiationを超訳すると、「まだ問題があるwebサーバだらけで、今よく見えるように警告してしまうとそれを無視しましょうとのたまう人が出てきて、ユーザは似たような警告も含めて無視する習慣が付いてしまうだけで世の中が幸せにならない。だから潜在的に問題のあるサーバはそっとエラーコンソールにログするだけ」とのことです。実際にはRFC5746を実装していないwebサーバとのTLS/SSL使用時に表示されるので、webサーバ側にrenegotiationを全て無効にする形でのパッチが適用されている場合、webサーバとしてはCVE-2009-3555に対して脆弱でなくでもそれを通信中のフラグ(RFC5746対応している場合にはServerHelloのextentionのrenegotiation_infoが付いてくる)では検知できないのでFirefoxのエラーコンソールに表題のメッセージがログされます。
表題のメッセージを消す==webサーバをRFC5746のsecure renegotiationに対応させるためにすることをざっくり書くと、OpenSSLとApache HTTPD(mod_ssl)2.2系列の場合、
- 対象のwebサーバにhttps://で接続してFirefoxのエラーコンソールに表題のログが表示されることを確認。
- 先にOpenSSLを0.9.8m以降にアップデート。(2014/4/8現在1.0.1g以降をお勧め)
- 次にApache HTTPD 2.2系列の場合2.2.15以降(2010/9/14現在2.2.16以降をお勧め)にアップデートかリビルド。
- 再度https://で接続してFirefoxのエラーコンソールに表題のログが表示されなくなったことを確認。
となります。(悲しいことにrenegotiationしないと続行できない状況の場合、いまだRFC5746非対応であるIE(←末尾に追記)RFC5746非対応ブラウザなどで問題になり、わざわざmod_sslにSSLInsecureRenegotiationディレクティブを使用して古いrenegotiationを有効にせざるをえなくて困っているサーバ管理者の方も多いです)
その他にもご自分のwebサーバがインターネット上にあればQualys SSL LabsのSSL Server Testにて、SSL,TLS全般の確認ができます(表示されているように、別のURLで流れさるまでの何時間かURLと結果がさらされます(その後指定すればさらされないようになりました)。さらに上位と下位は別枠で表示してくれます)。結果のMiscellaneousのRenegotiationの項に、安全なのか古いリネゴが使えてしまう状態か、などが表示されます。
クライアントのRFC5746対応も必要ですが、表題のログがエラーコンソールに出ている時点で当然古いrenegotiationを問題視しているwebブラウザを使用していることになるのでここでは考えないことにします。webブラウザのRFC5746対応はmozilla wiki Security:Renegotiationに書かれているようにhttps://ssltls.de/で確認できます(←末尾にちょっと追記)。有るべき姿はwebブラウザ、webサーバに限らず、「SSL,TLSを用いた全てのクライアントとサーバがRFC5746に対応していること」になります。
ではwebサーバとしてはCVE-2009-3555に対して脆弱でなくてもログされる場合(薦められた状態ではないですが)はというと…
例えばOpenSSLのChangeLogを見ると、
|
1 2 |
2009/11/5 Changes between 0.9.8k and 0.9.8l すべての renegotiation を無効にしてやったぜ。 |
|
1 2 |
2010/2/25 Changes between 0.9.8l and 0.9.8m RFC5746実装。 |
となっていて、またFreeBSD Security Advisoriesの2009/12/3 FreeBSD-SA-09:15.sslでは
|
1 |
よく注意: このアップデートで、renegotiationは全部拒否しちゃうようになるからね |
となっています。ソースレポジトリを見ると2010/6/15現在-CURRENTとRELENG_8(-STABLE), RELENG_8_1がOpenSSL 0.9.8nであり、他は OpenSSL 0.9.8eとかkとか + SA-09:15 ということになるようです。
さらにApache HTTPD 2.2.15のChangeLogでは、
|
1 2 |
OpenSSL 0.9.8lより前とコンパイルした場合はクライアントがinitiateしたrenegotiationを拒否。 OpenSSL 0.9.8m以降とコンパイルした場合は包括的修正が適用される |
となっているので、Apache HTTPD(mod_ssl) 2.2.15以降の2.2系列をOpenSSL 0.9.8m以降のライブラリでコンパイル、リンクすることでRFC5746のsecure renegotiation対応になります。
Apache HTTPDにSSLInsecureRenegotiation指定をしない前提でまとめていくと2010/6/15現在
FreeBSD 8.1(現在ベータ1,7月リリース予定)のOpenSSLは0.9.8nなのでRFC5746対応。したがってCVE-2009-3555に対しては脆弱ではない。
FreeBSD 8.0, 7.3, 7.1各セキュリティブランチを最新の状態にしている人のOpenSSLは0.9.8? + SA-09:15なのでRFC5746は対応していないが、renegotiationを全部無効にすることでCVE-2009-3555に対しては脆弱ではない。
OpenSSL 0.9.8l
あるいはFreeBSD 8.0, 7.3, 7.1各セキュリティブランチのOpenSSL(0.9.8? + SA-09:15)
+ Apache HTTPD(mod_ssl) 2.2系列全部
の場合は
- 表題のエラーコンソールログは表示される(RFC5746非対応)
- CVE-2009-3555についてwebサーバは脆弱ではない(ただしrenegotiationがすべて無効)
OpenSSL 0.9.8m以降(2010/6/15現在OpenSSL 1.0.0a以降をお勧めします)
+ Apache HTTPD(mod_ssl) 2.2.15以降の2.2系列
の場合は
- 表題のエラーコンソールログは表示されない(RFC5746対応)
- CVE-2009-3555についてwebサーバは脆弱ではない(RFC5746対応)
要注意なのは、Apache HTTPD 2.2.15にしただけで安心してしまう次のパターンでしょうか。現実的にMITM攻撃が成立するかは考えずにChangeLogからだけ言うとするとCVE-2009-3555に対してwebサーバは脆弱です。
OpenSSL 0.9.8k以下(FreeBSDの場合は0.9.8k以下かつSA-09:15のアップデートがされていない場合)
+ Apache HTTPD 2.2.15以降の2.2系列、
あるいは2.2.14 + http://www.apache.org/dist/httpd/patches/apply_to_2.2.14/CVE-2009-3555-2.2.patch
の場合は、
- 表題のエラーコンソールログは当然表示される(RFC5746非対応)
- CVE-2009-3555に対しては * 脆弱である *
(クライアントがinitiateした場合のrenegotiationを拒否しているだけ)
まずサーバ側の古いrenegotiationの実装が一掃され(同時にメジャーwebブラウザが全部RFC5746対応するという壁も大きいようで)、そしてRFC5746実装が使用され、renegotiationの一部や全部を無効にしただけのパッチがおおよそ一掃されて、それからようやく表題のエラーコンソールのログが派手な警告なりエラーなりに格上げされることになると思われますが、まだまだかかりそうですね…
例:https://bugzilla.mozilla.org/show_bug.cgi?id=555952
FreeBSD 8.0, 7.3, 7.1 + Apache HTTPD(mod_ssl)で表題のエラーコンソールログが出なくなるようにする、つまりRFC5746対応にするには、2010/6/15現在SA-09:15ではOpenSSLのrenegotiationを全部無効にしているためApache HTTPD(mod_ssl)を2.2.15にするだけでは不十分であり、こどもの日にportsがOpenSSL 0.9.8mに対応された(2010/6/15現在1.0.0a対応)ので、これを使うのが早そうです。
|
1 2 3 4 5 6 7 8 9 |
# portsnap fetch # portsnap update # portinstall security/openssl # env WITH_OPENSSL_PORT=yes portupgrade -f www/apache22 # ldd /usr/local/libexec/apache22/mod_ssl.so /usr/local/libexec/apache22/mod_ssl.so: libssl.so.7 => /usr/local/lib/libssl.so.7 libcrypto.so.7 => /usr/local/lib/libcrypto.so.7 ... |
最後の表示では、特に/usr/lib/や/lib/ではなくて、/usr/local/lib/libssl.so.*, /usr/local/lib/libcrypto.so.*であることを確認する必要があります。
あらかじめFirefoxでhttps://接続してエラーコンソールに表題のものがログされていることを確認した後、アップデート作業後にログされなくなればRFC5746対応完了です。
Windows関連ちょっとだけ追記(2010/9/14)。 2010年8月の月例(日本だと8/11あたり)のアップデート群に含まれていたKB980436: MS10-049: Vulnerabilities in SChannel could allow remote code executionによってWindowsのTLS/SSLスタックがRFC5746対応されましたが、それが使われるWindows XPのIEで https://ssltls.de/ のペンギンさんが表示されないのを確認しようとしてたこともあって時間がとれずに一月経ってしまいました。どうやらmod_nssを使った環境を作らないとちゃんと確認できなそうなので、先ほどざっと確認した現象だけ列挙しておきます。
- Opera,Firefoxは結構前からペンギンさんが表示される。
- KB980436が適用されたWindows Vistaではペンギンさんは表示される。
- KB980436が適用されていてもWindows XP, 2003ではIEのバージョンによらず、ClientHelloのextentionでもSCSVでもペンギンさんは表示されない。
- Windows XP(IE)のClientHelloのextentionにはtype 0xFF01(renegotiation_info)しかないが、Vista(IE)やOperaはそれに加えてserver_nameやstatus_requestなどがある。
- HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL にUseScsvForTlsという名前のDWORD値を作成して1をセットすると、Windows XP(IE)ではClientHelloのextentionが無くなる。Firefoxはserver_nameやstatus_requestなどがある。どちらもrenegotiatoin_infoは無く、cipher suiteに0x00FFが追加されている(SCSV)。
次はmod_nss環境を作成してnssのデバッグログを吐かせるところからになりますが、誰かとっくのとうに解決していたら教えてくださいませ。
なおWindows(IE,IISなど)で古いリネゴを拒否する方法はKB980436に書かれています。レジストリをいじって
|
1 2 |
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "AllowInsecureRenegoClients"=dword:00000000 |
で再起動すればサーバ(IISなど)が、そして
|
1 2 |
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "AllowInsecureRenegoServers"=dword:00000000 |
で再起動すればクライアント(IEなど)が古いリネゴを拒否するようになります(いろいろ使えなくなるものが出るようなので、まだ不便かもしれません)。
その他の参考リンク
文書に記述する際の説明用/例示用のドメイン名、IPアドレス、MACアドレス RFC6890,RFC5737,RFC3849,RFC2606,RFC6761,RFC7042 IANAなどなど
説明書などでドメイン名を例示するときに、 hoge とか foo とか bar とか chome などにを適当なTLDをつなげたり、最近ではTLDとして使ってしまうと自分のドメインでない場合や、自分のドメインでも更新しなかった場合などに問題になる可能性があります。IPアドレスもしかりです。そのままコピペされたり検索エンジンにインデックスされて他人に迷惑をかけないためにも、文書に記述するときに使ってよいドメイン名、IPアドレス、MACアドレス(EUI-48)が決まっています。
RFC6890によって RFC5735 はobsoleteにされました。(RFC5735によって RFC3330 はobsoleteにされました。参考: IPv4枯渇)
- 2016-06-28 MACアドレス関連追記
- 2013-10-11 RFC6890関連追記(Documentation用IPアドレスの変更はありません)
- 2011-02-10 .lg.jp関連追記
- 2011-01-26 .テスト などTLD関連追記
- 2010-03-17 .jp関連追記
| 192.0.2.0/24 | 192.0.2.0 – 192.0.2.255 | TEST-NET-1 (TEST-NET) | RFC6890 RFC5737(RFC5735 RFC3330) |
| 198.51.100.0/24 | 198.51.100.0 – 198.51.100.255 | TEST-NET-2 | RFC6890 RFC5737(RFC5735 RFC3330) |
| 203.0.113.0/24 | 203.0.113.0 – 203.0.113.255 | TEST-NET-3 | RFC6890 RFC5737(RFC5735) |
| 2001:db8::/32 | 2001:db8::0 – 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff | Documentation Prefix | RFC6890 RFC3849(RFC5156) |
| 00-00-5E-00-53- | 00-00-5E-00-53-00 – 00-00-5E-00-53-FF | EUI-48 (MAC addresses) Documentation Values | RFC7042 2.1.2 (2.1.1) |
| 00-00-5E-EF-10-00-00- 他 | 00-00-5E-EF-10-00-00-00 – 00-00-5E-EF-10-00-00-FF | EUI-64 (unmodified 64-bit MAC addresses) Documentation Values | RFC7042 2.2.3 |
| .test | recommended for use in testing | TLDs for Testing, & Documentation Examples | RFC2606 RFC6761 |
| .测试(.XN–0ZWM56D) .परीक्षा(.XN–11B5BS3A9AJ6G) .испытание(.XN–80AKHBYKNJ4F) .테스트(.XN–9T4B11YI5A) .測試(.XN–G6W251D) .பரிட்சை(.XN–HLCJ6AYA9ESC7A) .δοκιμή(.XN–JXALPDLP) .テスト(.XN–ZCKZAH) .טעסט (.XN–DEBA0AD) .آزمایشی (.XN–HGBK6AJ7F53BBA) .إختبار (.XN–KGBECHTV) | e.g. ほげ.テスト (xn--18j4d.xn--zckzah) | Reserved for testing internationalised domain names | Root Zone Database |
| .example | recommended for use in documentation or as examples e.g. hoge.example | TLDs for Testing, & Documentation Examples | RFC2606 RFC6761 |
| .invalid | intended for use in online construction of domain names that are sure to be invalid | TLDs for Testing, & Documentation Examples | RFC2606 RFC6761 |
| .localhost | having an A record(DNS) pointing to the loop back IP address and is reserved for such use | TLDs for Testing, & Documentation Examples | RFC2606 RFC6761 |
| example.com | e.g. hoge.example.com, example.com | Reserved Example Second Level Domain Names | RFC2606 RFC6761 |
| example.net | e.g. hoge.example.net, example.net | Reserved Example Second Level Domain Names | RFC2606 RFC6761 |
| example.org | e.g. hoge.example.org, example.org | Reserved Example Second Level Domain Names | RFC2606 RFC6761 |
| example.jp example0.jp example1.jp … example9.jp ドメイン名例.jp (xn--eckwd4c7cu47r2wf.jp) | e.g. hoge.example.jp, example7.jp, ほげ.ドメイン名例.jp (xn--18j4d.xn--eckwd4c7cu47r2wf.jp) | 汎用 JP ドメイン名における予約ドメイン名の3 JPRS FAQ | |
| example.<属性ラベル>.jp example0.<属性ラベル>.jp … example9.<属性ラベル>.jp example.<市区町村ラベル>.<都道府県ラベル>.jp … example.<都道府県属性ラベル>.<都道府県ラベル>.jp … example.<市区町村属性ラベル>.<市区町村ラベル>.<都道府県ラベル>.jp … など詳細は右記技術細則にて | e.g. hoge.example3.ed.jp, example7.city.shibuya.tokyo.jp | 属性型（組織種別型）・地域型JPドメイン名登録等に関する技術細則の4.4 JPRS FAQ | |
| example.lg.jp example0.lg.jp … example9.lg.jp | e.g. city.example8.lg.jp | LG ドメイン名登録等に関する技術細則の3.4 JPRS FAQ |
忍び寄るIPv4アドレス枯渇
またbogonが減ったそうです。The Team Cymru Bogon List IANA IPv4 Address Space Registry
逆に追加された 198.51.100.0/24 and 203.0.113.0/24 はIANAの出典をみると RFC5737 のことで、特別なアドレス領域をまとめていた RFC3330 も RFC5735 にobsoleteにされた(差分は最後の方のAppendix A)とのこと。パケットフィルタでbogonを自動更新で無く運用(=RESERVEDだけをフィルタ)されている方は変更すると幸せになれるかもしれません。自動更新でなく未割り当て領域をフィルタすると悲しいことになるのでだめですよー。
とはいえまだまだIPv4の空きはあるっちゃあるわけですが。(その後中央在庫無くなってます)