トピック
ソフトウェアライフサイクルとベンダーロックイン
「トピックの観点から見たソフトウェアライフサイクルとベンダーロックイントピックは、特定のテーマ、シグナル、または監視すべき話題を共有する記事を結びつけます。このページは、関連報道、公開情報源、市場関係者、インフラへの影響をたどる豊かな道筋を提供し、企業動向、政策決定、地域的影響、運用リスクにわたってそのトピックがなぜ重要なのかを理解するための十分な文脈を与えます。単なる記事リストにとどまらず、読者は繰り返し現れるシグナル、影響を受ける組織、公開証拠、市場背景、サービス継続性、調達、競争、コンプライアンス、戦略計画といった背景を比較できます。このページでは、トピックの対象範囲、関係するインフラ事業者や政策、報道内容を裏付ける証拠、そして通信事業者、顧客、投資家、政策関係者にとってそのテーマがなぜ重要なのかを説明します。」
インターネット史
送られなかったヘッダー：TCPがIPアドレスをチェックサムに含める理由
TCP は、宛先の情報を別のヘッダーとして送信しない。IP から受け取った情報を両端で組み立て、TCP のチェックサム計算にだけ加えるのである。
インターネット史
空間を占める二つのフラグ：TCPがSYNとFINを数える理由
TCP はバイトに番号を付ける一方で、二つの制御イベントにも論理上の位置を割り当てます。SYN は最初のデータより前、FIN は最後のデータより後に置かれます。そのため、どちらもデータと同じ確認・再送の仕組みで扱えますが、アプリケーションデータになるわけではありません。
インターネット史
メッセージ境界ではなかった PUSH：TCP の PSH フラグ
これはバイト列を先へ進める要求であって、メッセージを包む印ではない。
インターネット史
片側が状態を失った接続：TCPのハーフオープン検出
一方の端点が再起動して接続状態を失っても、もう一方は接続が確立済みだと思い続けることがある。次の通信でその食い違いが表面化し、RST が残存状態を破棄して新しい接続の同期を可能にする。
グローバルの機関トレンド
ISCの脆弱性対応は誰の権限で動くのか――BINDとKeaをめぐる実務上の統制
ISC は、サポート対象の BIND と Kea で脆弱性が見つかった場合、情報開示、修正版の準備、公式リリースの時期を調整できる。しかし、この影響力は、すべての運用者に更新を命じる公的権限とは異なる。開示前の情報、公式な修正経路、下流での導入判断を分けて見ることが重要である。
インターネット史
両側が同時にノックしたとき：TCP の同時オープン
*TCP の三ウェイハンドシェイクは、固定されたクライアントとサーバーを必要としない。両端が同時に開始しても、一つの接続に収束できる。*
インターネット史
話し始める前に待たなければならなかったホスト：再起動後のTCPクワイエットタイム
再起動したホストがきれいに見えるのは、単に多くを忘れているからかもしれない。TCP のクワイエットタイム（送信待機時間）は、その記憶喪失を待ち時間に置き換える。古いセグメントが消えるまで、以前の接続で使った番号と重なる領域を再利用しないのである。
インターネット史
待機を早く終わらせたリセット：TCP TIME-WAIT 暗殺の危険
TIME-WAIT は、切断後に残る静かな状態に見える。しかし RFC 1337 は、古いセグメントが ACK を引き起こし、その ACK が状態を失った相手から RST を引き出すことで、古い重複パケットを封じる保護が途中で消えることを示した。
インターネット史
再送タイマーではなかった期限：TCP User Timeout
TCP は再送を続けられても、別の時計で接続を待ち続ける期限を迎えることがある。
インターネット史
交渉ではなかった提案：TCP MSS が各方向をどのように制限したか
各 SYN には、送信側が自分の受信能力を示す値を含められます。二つの値は異なり得ます。MSS は共通のパケット長でも、経路 MTU の証明でもありません。
インターネット史
前のハンドシェイクを覚えなければならなかったハンドシェイク：RFC 5746 が TLS 再ネゴシエーションを結び付けた方法
TLS の各ハンドシェイクは自分自身の完了を認証できても、同じ接続のどの履歴を継いだのかまでは示せなかった。RFC 5746 はその連続性を暗号学的に検証できる状態にした。
インターネット史
到達不能になってもキャッシュに残った隣接者：RFC 7048 がフェイルオーバーと忘却を分けた理由
3回目のユニキャスト探索に応答がなくても、最後に得たリンク層アドレスを直ちに捨てる必要はなくなった。IPv6 はその隣接者の優先順位を下げながら、記録を使って回復を試みられる。
インターネット史
唯一だと証明される前に話し始めたアドレス：オプティミスティックDADが早期利用を制限した方法
新しく設定された IPv6 アドレスは、重複検出が終わる前でも通信に使えた。ただし、正当な隣接ノードの状態を変更できるほどの権限は、まだ持たなかった。
IETF
安全なTACACS+移行に残る危険な中間段階：RFC 9887と二重認証経路の代償
TLS 対応の TACACS+クライアントは、TLS に失敗しても非 TLS へフォールバックしてはならない。それでも、すべての機器を同時に移行できない場合には、未移行の機器向けに分離した非 TLS サーバーを残すことがある。その旧経路が到達可能な間、混在する移行段階は完了するまで安全ではない。新しい TLS エンドポイントが正しく動作するだけでは、二重経路の収束を証明できない。
ケースファイル
通知は届いた。それでも一台のサーバーは空だった
RRDP の notification は軽いファイルだが、そこに書かれた snapshot と delta が取得可能だという重い約束を持つ。IETF が最終意見募集にかけた RPKI 公開運用案は、その約束を順序で守る。データを先に置き、notification は最後に見せる。
ケースファイル
同じ Policy に二つの「最良」があった：RFC 9830
BGP では候補 A が best、SRPM では候補 B が active。運用画面が二つの結果を一つの「最良経路」にまとめた瞬間、どちらの判断も説明できなくなる。RFC 9830 が規定するのは、SR Policy の Candidate Path を BGP で運ぶ方法である。BGP の選択を headend の選択に昇格させる規格ではない。
インターネット史
行数もCRCも一致した。それでも実行許可は届いていない：RFC 1505
受信したメールの行数は宣言どおりだった。圧縮を解くとバイト数も CRC も一致した。復元されたのは、シェルが読める命令を含むアーカイブだった。ここまでの検査はすべて成功している。しかし、成功した検査のどれにも「この命令を受信側で実行してよい」とは書かれていない。RFC 1505の歴史的な面白さは、その空白を仕様の内部に残したことにある。
ケースファイル
チャレンジはメールを解放した。リストにはまだ届いていない
IETF は9月11日にメール基盤を切り替える予定だ。新しい構成は、初回送信者の確認、リスト処理、アドレス書換え、署名、外向き配送を別々の機能にする。だからこそ、一つの機能が返した成功を、配送全体の成功として読まない運用が必要になる。
ケースファイル
大きい CRL Number は、現行 CRL を決められない：RFC 9829
障害対応の場では、最大の番号が「最新版」に見える。だが RPKI では、その近道が検証経路を二つに割る。RFC 9829 は CRL Number を残しながら、その大小から現行性を決める権限だけを外した。選択に必要なのは、発行者の現行マニフェスト、内容ハッシュ、そして証明書の CRLDP が同じオブジェクトを指すという事実である。
インターネット史
一つの仮想リンクという前提が、影のネットワークを生んだ：RFC 1504
AURP は複数拠点を結ぶトンネルを、一つの仮想データリンクとして扱った。便利な抽象化である。だが実際の到達関係が部分的だったとき、「同じリンク上の全員が直接話せる」という前提は、必要な経路を消すだけでなく、自分の変換結果を別ネットワークとして戻す余地も作った。