ACタップ類も更新するため、必要な口数とケーブル長を検討する(UPS系・壁コン系に分けて集計すること)
- タップの識別性改善のため、UPS系をロック付き・壁コン系をロック無しとするのはどうか？(もしくは、カラーマーカーを追加する)
コンソール機材(Keyboard/Mouse/Display)接続ケーブルの必要長・配線経路の検討と資材発注
- USB延長ケーブルx2・DVI-Dケーブル・Display電源ケーブル
- オプションで、卓上ノートPC向けのACライン・LANケーブル
収容機材高に基づく棚の高さのデザイン
- プリンタ・ADFスキャナの収容スペースは要検討
- ADFスキャナに関してはスライド棚による実装も検討すべきか？
  - スライド棚の仕様は、耐荷重15kg、スライド長23cm
    - ScanSnap S1500 3kg/Deskjet 5551 5.7kg
    - ScanSnap S1500では、23cm引き出すと原稿トレイがギリギリラックから出てくる
- Network Switch系の棚には、一部板張りすると便利
  - 19mmポール向けの w74xD30の棚板材が候補
機材搬出までに、ケーブル類にタグを付けること
- LANケーブルは、機器名・Switchポート番号
- KVMケーブルは、ポート名
- ACケーブルは、機器名
- 必要であれば、ラベル材を調達すること

前回の続き

2018-12-14に報告されている Bug 233998が状況的に一致する

12.0-RELEASE上のThreadripper 1950X + X399での報告
パッチは、13-CURRENTには入っているがバックポートされていない？
- headからr342108を持ってくると問題が解決する(sys/contrib/zstdへのパッチは無関係)

残る課題は、SMT on状態での 32-thread動作の安定性の確認のみ最近のSMT回りのセキュリティ問題やFP性能を考えるとbuild以外にはSMT不要だったりするが…

2021-07-09

とりあえずまとめ

unbound
- 普通にinterfaceを増やせば良い
- access-controlにIPv6アドレスの定義を追加するのを忘れずに
- do-ip6でIPv6サポートが止めてある場合があるので、要確認

tinydns
- v6パッチが当ててある場合は、env/IPにカンマ区切りでIPv6アドレスを追加すればOK
- AAAAレコードの定義が独特なので各自対処のこと(0省略なし・コロン区切りなし)
  - tinydns-dataに処理させるMakefile側でsedとかを使って整形するのが現実的か？

axfrdns (TCP response for tinydns)
- tinydnsと違いtcpserverからの起動なので、IP毎にtcpserverを立てる形式になる
  - v6パッチ付きucspi-tcpが必要
  - 最悪、intedから起動するのも有り
- アクセス制御でprefixlenを指定出来ないので、実用的には48bit prefixもしくは64bit prefix毎にallow/denyを設定することになる

firewall
- 境界でアドレス偽装パケットを弾いている場合、v4アドレス向けのnot address-range形式のdenyルールがv6パケットに適用されてないか要確認 (DNS通信試験時に嵌った)

rtadvd'およびDHCPv6 serverを立ち上げて、LAN側からIPv6アドレスを取得出来るところまでは確立

だが、外に出れない Orz

LAN側からWAN側にNTPv6でprefix変換して送出したパケットが戻ってこれない状況

原因は、回線側のルーターからNTPv6でprefix変換されてWAN側アドレスに対して近傍探索が届くが、WAN側のインターフェースに存在しないアドレスなので、応答しないため、回線側からWAN側インターフェースへの通信が開始されない模様

動かすには、NTPv6同様のaddress prefix付け替え対応なND Proxyが必要？
- Prefix Delegationで受けたときのND動作はどうなるのだろう？
NTPv6は標準化されたけど、IETF的には推奨してないらしぃ(おぃおぃ)

素直にNAT66で繋ごうにも、ipfwにNAT66は未実装な罠 Orz (pfは実装済みぽぃ)

回線側のサポートがあれば、DHCPv6-PDでWAN側からprefix delegationをもらってLAN側prefixを設定できるが、光電話契約してないので無理 (KAMEの影響か、BSD系の設定例はWIDE DHCP clientを使ったものが多い様だ)

回線契約形態で、prefix delegationの振り出し状態が変わるということは、ND動作を考えると、回線側のルータ設定も連動して変更されていて、prefix block単位でroutingされているのかなぁ…

NAT66のためだけにipfwからpfへ切り替えるのも面倒くさそう…(YAMAHAルーター買ってくるか？)

まあ、socket pid/gid filteringは止めたのでipfwでないと困る理由もなくなったのだが

DHCPやlink localな通信を先に許可した後、残りの通信に対してLAN側に割り当て済みのアドレステーブルを使って

なフィルターを仕掛けているが、DHCPv6-PDでglobal-prefixをLAN側に告知した場合、globalな通信に関したWAN側と同じprefixが付くのでフィルターに引っかかってしまう

global-prefixをもらってくるか、さもなくばglobal IF同様にglobal-unicastを通過させるしかないか…

global-prefixを抜き取るアイデアとしては、rtsoldを改造して、M/O/Rオプションで外部scriptを起動するように、RA-prefixを受け取った時に外部scriptを起動させるという案がある