【完全解説】LCP交渉（PPP） — 意味・仕組み・オプション・トラブルシュート

2025年12月12日 最終更新日時 : 2025年12月12日 エバープレイ編集部

はじめに

LCP（Link Control Protocol）交渉は、PPP（Point-to-Point Protocol）でリンクを確立する際に行われる基本的かつ重要なプロセスです。モデムやシリアル回線、PPPoE（PPP over Ethernet）、PPTP/L2TPなどPPPを用いる多くの接続で、LCPが最初にリンクの性質を決め、以降の認証やネットワーク層プロトコルの設定（IPCPなど）へと進みます。本稿ではLCPの役割、パケット構造、代表的オプション、状態遷移、問題発生時の診断・対処法、実運用上の注意点までを深堀りします。

LCPの役割と位置づけ

LCPの主な役割は以下の通りです。

  • 通信リンクの初期化・維持：リンク品質監視やループ検出など。
  • リンク特性の交渉：最大受信単位（MRU）、アドレス・制御フィールド圧縮（ACFC）、プロトコルフィールド圧縮（PFC）、認証方式など。
  • ネゴシエーション完了後にネットワーク制御プロトコル（NCP）を開始する起点となる。

PPPの仕様はRFC 1661で定義され、LCPはPPPのリンク制御を担うサブプロトコルです。LCP交渉が成功するとLCPは「Opened」状態になり、必要に応じて認証を行い、その後NCP（例：IPCP）でIPアドレス等の設定に移行します。

LCPパケット構造と主要コード

LCPメッセージはPPPのプロトコルフィールドが0xC021（LCP）で識別され、LCPヘッダは次のような構造を持ちます：Code(1バイト)、Identifier(1バイト)、Length(2バイト)、Data(可変)。代表的なCode値は次の通りです。

  • Configure-Request（1）：オプションの提案。
  • Configure-Ack（2）：提案をそのまま受け入れ。
  • Configure-Nak（3）：提案の修正を要求。
  • Configure-Reject（4）：提案されたオプションを拒否。
  • Terminate-Request（5）/Terminate-Ack（6）：リンク終了の要求/応答。
  • Code-Reject（7）：未知のLCPコードの拒否。
  • Protocol-Reject（8）：未知の上位プロトコルの拒否。
  • Echo-Request（9）/Echo-Reply（10）：生存確認・ループ検出。
  • Discard-Request（11）、Identification（12）、Time-Remaining（13）など。

このやり取りにより、双方が合意するまでConfigureパケットを交換します。Configure-Ackが相互に交換されるとLCPはOpened状態へ移行します。

代表的なLCPオプションと意味

LCPは様々なオプションを交渉可能で、代表的なものは次の通りです。

  • MRU（Maximum Receive Unit）：相手に送信できる最大フレーム長を決めます。MTU/MRUの不一致は断片化や接続不良の原因になります。
  • 認証プロトコル：PAPやCHAPなどを指定します。LCPで認証方式をネゴシエートした後、実際の認証フェーズが行われます（CHAPはチャレンジ/レスポンスでPAPより安全）。
  • Magic Number：ループバックの検出やリンクの一意性確保に用いるランダム値。自分が送ったフレームがそのまま返ってくる（ループ）状況を検出できます。
  • プロトコルフィールド圧縮（PFC）：上位プロトコル識別子（16ビット）を省略して効率化するオプション。
  • アドレス・制御フィールド圧縮（ACFC）：PPPフレームのアドレス/制御フィールド（通常2バイト）を省略するオプション。
  • Quality/Callbackなど：リンク品質チェックや相手側が電話回線にコールバックする等、運用に応じたオプション。

オプションはConfigure-Request内でType/Length/Valueの形式で送られ、相手が受け入れるか、修正を要求（Nak）するか、完全に拒否（Reject）するかを示します。

状態遷移と交渉フロー

LCPの状態遷移は有限状態機械(FSM)で管理されます。主な状態はInitial、Starting、Closed、Stopped、Request-Sent、Ack-Rcvd、Ack-Sent、Openedなどです。シンプルな交渉フローは次のようになります。

  • リンクが物理的に確立される（例：シリアル回線Up）→ LCPがConfigure-Requestを送信。
  • 相手がConfigure-Requestを受信し、オプションを検証してConfigure-Ack/Nak/Rejectで応答。
  • お互いにConfigure-Ackを受け取るとLCPはOpenedへ遷移。
  • 必要ならば認証を実行（CHAP/PAP）。認証成功でNCP（例：IPCP）を開始し、ネットワークレベルの設定に進む。
  • リンク維持中にEchoやMagic Numberでループや死活を監視。問題があればTerminateで切断し再ネゴシエートする。

典型的な障害と診断方法

LCP交渉がうまくいかないケースは運用で頻出します。代表的な事例と診断/対処法を挙げます。

  • Configure-Nakループ：片方が提案したオプションに対し相手が繰り返しNakを返し、互いに受け入れられる組合せが見つからない。対処：相手の要求を読み取り、推奨値でConfigure-Requestを再送するか、双方の設定を整合させる。
  • Authentication Failure：LCPで認証方式は合意しても、PAP/CHAPの認証が失敗する。対処：ユーザ名/パスワード、チャレンジ応答の整合、CHAPのバージョン確認。
  • MRU/MTU不一致：大きすぎるフレームで断片化や破棄が発生。対処：MRUを小さくする、MTU調整、PPPの圧縮オプション確認。
  • ループバック/レインフォース現象：Magic Numberが一致する応答を受けるとループを疑う。対処：Echo-Request/Replyの交換内容を解析し、レイヤ2のトポロジを確認。
  • 未知のオプションやコードの拒否：相互にサポートしない拡張がある場合、Configure-RejectやCode-Rejectが返る。対処：不要な拡張を無効化するか、両端のソフトウェアバージョンを揃える。

診断ツールとしてはtcpdumpやWiresharkでPPP/LCPパケットをキャプチャして内容（Code、Identifier、OptionのType/Length/Value）を確認するのが有効です。WiresharkはLCPのフィールドを解析表示してくれるため、交渉のどの段階で躓いているかを素早く特定できます。

実戦的なポイント（運用・設定上の注意）

  • PPPoEやVPNでの接続では、MTU/MRUの調整が特に重要です。PPPoEではヘッダ分のオーバーヘッドが出るため、MTUを低めに設定することが多い（例：1492など）。
  • 認証はCHAP推奨。PAPは平文送信であり安全性が低い。
  • 圧縮オプション（PFC/ACFC）は効率化に有効だが、中間機器が圧縮をサポートしていないと通信不能になることがあるため注意する。
  • プロバイダやISP側の設定と合致しないと接続できないため、事前に求められるMRUや認証方式、コールバックの有無などを確認する。
  • ルータやOSのPPP実装差（例：一部実装が特定のLCPオプションを無視する等）により互換性問題が生じる場合はベンダーのドキュメントで推奨設定を参照する。

セキュリティ面の考察

LCP自体はリンクの制御プロトコルであり、認証方式のネゴシエーション機能を持ちますが、認証の実際の強度は選ばれたプロトコルに依存します。CHAPはPAPに比べ安全ですが、CHAPのバージョンや実装の違い、共有秘密の管理なども考慮が必要です。またLCPのネゴシエーション段階でオプションを改竄されると意図しない圧縮や認証方式で接続される恐れがあるため、物理層や中継機器の信頼性確保が重要です。VPN用途では上位で暗号化（IPsec等）を併用することでさらに安全性を高めます。

運用時のトラブル例（実例）

よくある具体例としては、ISPに接続した回線で認証が通らないケース。原因はユーザ名の前後に不要な空白が含まれている、エンコードが異なる、CHAPでのチャレンジに対するレスポンス計算が異なる実装差など。対処はログ（pppdやルータのログ）を確認し、WiresharkでCHAPパケットを比較することです。もう一つは、PPPoE接続で大きなファイル転送が頻繁に切断されるケース。これはMTU/MRUやPPP圧縮オプションの不一致が原因であることが多く、MTUを1480〜1492程度へ調整することで改善することが多いです。

まとめ

LCP交渉はPPPベースの通信でリンクを確立・維持するための基盤であり、MRUや認証、圧縮設定など重要なパラメータを相互に合意する役割を果たします。トラブルの多くはオプションの不整合や認証失敗に由来するため、ログの確認、パケットキャプチャ、ISPの仕様確認が有効です。運用ではMTU/MRUの最適化、CHAPの採用、圧縮オプションの慎重な利用がポイントとなります。

参考文献

RFC 1661 - The Point-to-Point Protocol (PPP)
RFC 2516 - A Method for Transmitting PPP Over Ethernet (PPPoE)
RFC 1994 - PPP Challenge Handshake Authentication Protocol (CHAP)
Wireshark Documentation - PPP/LCP 解説
tcpdump - packet capture tool

カテゴリー
IT
前の記事
PPPoEセッションを徹底解説：仕組み・ヘッダ・MTU問題・運用とトラブルシューティングNew!!
2025年12月12日
次の記事
PAP認証とは？仕組み・脆弱性・実務での対策を徹底解説New!!
2025年12月12日