169.254.0.0/16徹底解説：APIPA・リンクローカルの仕組み、運用、トラブル対処法
エバープレイ編集部はじめに — 169.254.0.0/16とは何か
169.254.0.0/16 は、IPv4 における「リンクローカル（link-local）」アドレス空間として IANA により予約されている範囲です。一般に OS が DHCP サーバからの割当てに失敗した際の自動フォールバック（Microsoft の APIPA や各種 OS の RFC 3927 実装）で用いられ、同一リンク上のホスト間での通信に限定して使用されます。本コラムでは、仕様の出典、アドレス選択の具体的な動作、OSごとの挙動、運用上の注意点やトラブルシューティング、セキュリティ観点まで詳しく解説します。
仕様と背景（RFC 3927 の要点）
リンクローカル IPv4 アドレスの取り扱いは RFC 3927（"Dynamic Configuration of IPv4 Link-Local Addresses"）で定義されています。要点は次のとおりです。
- ネットワークプレフィックスは 169.254.0.0/16 として予約されている。
- ホストはランダムにアドレスを選び、選択アドレスが他と衝突しないことを ARP を用いて確認（ARP probing）してからアドレスを有効化する。
- 衝突が発生した場合は別のアドレスを選択して再試行する。
- このアドレスはリンクローカルとして、その名の通り同一 L2 セグメント（同一ブロードキャストドメイン）内でのみ有効とするべきであり、ルータによってルーティングされるべきではない。
RFC 3927 の実装指針には、ARP による検出回数やタイミング、重複が見つかった場合の再試行方法、選択アドレスの範囲（一部範囲を除外する推奨）などが記載されています。
アドレス選択範囲と実務での扱い
理論上の予約空間は 169.254.0.0/16 ですが、実装や運用上は以下のような扱いが一般的です。
- 多くの実装（RFC 推奨を含む）は、169.254.1.0 〜 169.254.254.255 の範囲を選択候補とすることを推奨しています。これによりネットワーク／ブロードキャストの特殊値（例：169.254.0.0 や 169.254.255.255）による混乱を避ける意図があります。
- サブネットマスクは通常 255.255.0.0（/16）で設定され、同一 /16 内のホストと通信可能とみなしますが、実際の到達性は L2 の範囲に依存します。
自動構成の手順（概略）
- DHCP による取得が不可であることを検知（DHCP タイムアウトや明示的失敗）。
- ランダムに 169.254.0.0/16 内の候補アドレスを選ぶ（実装により選択アルゴリズムは異なる）。
- ARP probing：選んだアドレスに対して ARP Probe（通常は未割当の ARP 要求）を送信してアドレスの重複を確認する。複数回の試行を行う実装が多い。
- 応答がなければアドレスを割り当て、必要に応じて gratuitous ARP を送信して自己主張（defend）する。
- 衝突が検出された場合は再選択して再度確認するか、一定時間待機して再試行する。
OSごとの挙動（Windows / macOS / Linux）
- Windows: "APIPA"（Automatic Private IP Addressing）と呼ばれ、DHCP が利用できない場合に 169.254.x.x のアドレスを自動設定します。Windows の挙動は古くからの実装に依存する部分があり、ログや ipconfig /all で確認できます。
- macOS / iOS: RFC 3927 準拠の実装（ZeroConf の一部として mDNS/Bonjour と併用）で、リンクローカルを利用してサービス検出やピア接続を行います。
- Linux: avahi や systemd-networkd、NetworkManager などが RFC 3927 を実装またはサポートします。ディストリビューションやネットワーク管理ソフトウェアによってデフォルトの動作タイミングが異なります。
運用上のユースケースと利点
- 小規模／一時的な L2 ネットワークでの即席通信：ケーブル直結やスイッチだけの簡易接続で IP 通信をすばやく行える。
- サービス検出（ZeroConf/Bonjour）と組み合わせたプラグ・アンド・プレイ的な接続。
- DHCP サーバの故障時の一時的な通信確保（ただし WAN 接続などは期待できない）。
注意点・落とし穴
- 分離された VLAN や異なるブロードキャストドメイン下では到達不可：リンクローカルはルータを越えないため、異なるセグメント間で名前解決や通信を期待してはいけません。
- トラブルシューティングの誤解：PC が 169.254.x.x を持っているときは DHCP の問題が疑われますが、ユーザ側で誤って固定アドレスや誤設定をしているケースもある。
- セキュリティ/監査：監視システムやログ集約で意図しないリンクローカルアドレスが存在すると解析を難しくすることがある。
- サービス検出のノイズ：ネットワークに多数の自動割当てアドレスが存在すると、mDNS やブロードキャストベースの検出が増加する。
トラブルシューティング手順（実践的）
- まず確認: ipconfig /all（Windows）、ip addr show / ifconfig（Linux/macOS）でアドレスを確認する。169.254. は DHCP 失敗のサイン。
- 物理層確認: ケーブル、スイッチポート、リンクランプ、SFP 等の物理/リンク層障害をチェック。
- DHCP の可用性確認: DHCP サーバが稼働中か、DHCP リレー設定や ACL がブロックしていないかを確認。
- ARP をチェック: arp -a 等で重複や不要なエントリを確認。場合によっては gratuitous ARP が原因で一時的に衝突が生じることもある。
- 一時対応: 迅速にネットワーク接続を回復する必要がある場合は、管理された静的 IP を設定するか、ネットワーク管理者により DHCP サーバの復旧を行う。
セキュリティ考察
リンクローカルアドレス自体は特別な攻撃面を増やすわけではありませんが、次の点に留意する必要があります。
- なりすまし（ARP スプーフィング）: ARP ベースの検出・割当プロセスがあるため、ARP を悪用した攻撃が成立し得る。スイッチのポートセキュリティや動的 ARP 検査 (DAI) の導入が有効。
- 認証／ログの混乱: リモートからのトラフィックと誤認することがあり、ログ解析時にノイズとなる。
- 内部の横移動検出: 169.254.x.x の出現は通常ローカルの問題だが、侵入の痕跡と重なる場合は注意深い解析が必要。
運用上のベストプラクティス
- DHCP インフラの可用性を確保する（冗長化、監視、アラート）。
- 監視ツールに 169.254.x.x の出現をトリガーとするアラートを設定して早期検知する。
- テスト/実験環境ではリンクローカルの特性（ルータを越えない点）を活かして隔離された通信を行う。
- ネットワーク設計で不要なアドレスの自動割当を避けるために、管理ポリシーを定義する（例: 固定 IP を使う VLAN、スイッチポートのロックダウンなど）。
まとめ
169.254.0.0/16（リンクローカル）は、DHCP 等による管理がない状況でも同一リンク上の簡易通信を可能にする重要な仕組みです。RFC 3927 に基づく自動割当のアルゴリズム、OS ごとの実装差、運用上の利点と制約を理解しておくことが、現場での迅速な問題切り分けと安定運用につながります。特に DHCP 障害時に発生するため、監視と実装の把握（ARP 挙動や OS のログなど）が有効です。
参考文献
- RFC 3927 — Dynamic Configuration of IPv4 Link-Local Addresses
- Microsoft Docs — Automatic Private IP Addressing (APIPA)
- Wikipedia — IPv4 link-local address
- IANA — IPv4 Special-Purpose Address Registry
- Avahi (ZeroConf on Linux) — Project page
投稿者プロフィール
