IPv6CP が決めること、プレフィックスが今も必要な理由
PPP インターフェースのリンクローカルアドレスは設定手順であり、IPv6 アクセスではありません。識別子の交換と、プレフィックス・ルート・クライアント統合を切り分けます。
PPP インターフェースで IPv6 が上がり、リンクローカルアドレスが現れ、変更は完了と宣言されます。しかしその後、何もルーティングされず、グローバルアドレスも存在せず、インターフェースは設定済みに見えるまま公開先へのテストだけが失敗します。リンクは上がったのに、ネットワークは上がっていません。以下の四つの確認を順に行い、食い違いを説明する項目で止めてください。
リンクローカルアドレスが実際に証明すること
IPv6CP は PPP リンク上で IPv6 を立ち上げ、双方にインターフェース識別子をネゴシエートします。その識別子からリンクローカルアドレスが作られ、これはリンク越しに相手と話すには足り、それ以外の何かに到達するには足りません。アドレスが証明するのはリンクが IPv6 の準備を終えたことであり、相手の背後のネットワークについては何も証明しません。これをアクセス用アドレスと読むのが、こうした調査の多くを始める誤りです。
以下の四つの問いは、リンク層が決めることとサービスが用意すべきことを分けます。前の問いが開いているうちは後の問いに答えられないので、順に答えてください。
| Question | Answered by | What it does not settle |
|---|---|---|
| Is IPv6 up on the link? | IPv6CP: interface identifiers, then link-local addresses | Any address reachable beyond the peer |
| Where does a global prefix come from? | Router advertisement, delegated prefix, DHCPv6 or static configuration | IPv6CP carries no prefix of its own |
| Who owns the routes? | The client's tunnel configuration and the server's return path | A link-local address implies no route at all |
| How does this client get configured? | Explicit tunnel settings or router advertisements, depending on the client | The standard does not choose for the implementation |
プレフィックスはどこから来るのか
グローバルアドレスには、ルーター広告、委任プレフィックス、DHCPv6、静的設定のいずれかからプレフィックスが必要です。IPv6CP はプレフィックスを運ばず、リンク上でどれだけ待っても生成されません。RFC 5072 は IPv6CP を、他の IPv6 プロトコルがリンク上で動く前の設定手順、つまりリンクを用意する段階と位置づけており、ネットワークに番号を振るものではありません。プレフィックスを用意すれば、インターフェースは単に存在するのではなくトラフィックを運び始めます。
ルーター広告は LAN では一般的な答えですが、クライアントが要請を送り、応答も受け入れる必要があるポイントツーポイントのトンネルでは信頼性が下がります。トンネルクライアントによってはどちらもしません。サーバーが送るべきか決める前に、クライアントが何を受け入れるかを確認してください。
同じプレフィックスは反対側からも到達できる必要があります。グローバルアドレスを持ちながら戻り経路がないクライアントは、設定済みであって接続済みではありません。
ルートは別の約束です
アドレスがあっても、クライアントはどの宛先がトンネルに属するかを知る必要があり、サーバーはその宛先への戻り経路を必要としますが、これは二か所で下される二つの決定です。すべての IPv6 トラフィックを運ぶトンネルには、クライアントのデフォルトルートとサーバーの戻りルートが必要です。分割トンネルでは、双方が同じプレフィックス一覧に合意する必要があります。合意がなければ、トラフィックは出ていったまま戻りません。
何かを設定する前に一覧を書き出してください。計画が「トンネルを通るのは社内プレフィックスだけ」と言うなら、クライアントにデフォルトの IPv6 ルートを置かず、サーバーもそれを広告しないようにします。
残りはクライアント統合が決めます
トンネルクライアントによっては IPv6 を明示的に設定します。たとえば Apple の Network Extension はトンネル用にアドレス、プレフィックス、ルート一式を受け取るため、これを使うアプリケーションは Ethernet 風の告知を待ちません。リンク上に届くルーター広告に頼るものもあり、どちらのモデルも正当ですが必要なサーバー側の挙動は異なります。誤ったモデルを選ぶと、誰も送らないメッセージを永遠に待つクライアントになります。サーバーを変える前にモデルを特定してください。
ppp0 のような古いインターフェース名は、今日動いているスタックについて何も証明しません。現在のクライアントは PPP インターフェースではなくパケットトンネル API を使うことがあり、歴史的な接続と同じように振る舞うと仮定することが、動いている設計を壊す方法です。インターフェース名ではなく、クライアントのバージョンと配備方法を尋ねてください。
クライアントに必要な計画を書く
完全な記述には、クライアントが持つアドレス、トンネルが運ぶべき宛先、ネットワークが応答をどう返すかの三つが含まれます。リンクローカルアドレスはどれにも答えず、受け入れた広告は一つの一部にしか答えません。緑の表示を鵜呑みにせず、項目ごとに個別に確認してください。その後、どの仕組みが各回答を提供したかを記録すれば、その記録が次回の IPv6 報告を二分の確認に変えます。
記録はサービスの文書と一緒に保管し、クライアントが変わったら更新してください。PPP クライアントに正しかった計画が、同じサービスのパケットトンネルクライアントには誤りであり得ます。四つの問いは同じままで、変わるのは答えだけです。