Co negocjuje IPv6CP i co nadal wymaga prefiksu
Adres link-local na interfejsie PPP to krok konfiguracji, a nie dostęp do IPv6. Oddziel wymianę identyfikatorów od prefiksów, tras i integracji klienta.
IPv6 podnosi się na interfejsie PPP, pojawia się adres link-local i zmiana zostaje uznana za zakończoną. Potem nic nie jest routowane, nie ma adresu globalnego, a test do publicznego celu kończy się niepowodzeniem, choć interfejs nadal wygląda na skonfigurowany. Łącze się podniosło; sieć nigdy. Wykonaj poniższe cztery kontrole po kolei i zatrzymaj się na tej, która wyjaśnia lukę.
Co naprawdę dowodzi adres link-local
IPv6CP podnosi IPv6 na łączu PPP i negocjuje identyfikator interfejsu dla każdej strony. Ten identyfikator tworzy adres link-local, który wystarcza do rozmowy z drugą stroną przez łącze i nie wystarcza do dotarcia do czegokolwiek innego. Adres dowodzi, że łącze jest gotowe na IPv6, i nie dowodzi niczego o sieci za drugą stroną. Czytanie go jako adresu dostępowego to błąd, od którego zaczyna się większość takich dochodzeń.
Cztery pytania poniżej oddzielają to, co rozstrzyga warstwa łącza, od tego, co musi zapewnić usługa. Odpowiedz na nie po kolei, bo na późniejsze pytanie nie można odpowiedzieć, dopóki wcześniejsze pozostaje otwarte.
| 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 |
Skąd musi pochodzić prefiks
Adres globalny potrzebuje prefiksu skądś: z ogłoszenia routera, delegowanego prefiksu, DHCPv6 lub konfiguracji statycznej. IPv6CP nie przenosi żadnego, a żadne czekanie na łączu go nie wytworzy. RFC 5072 umieszcza IPv6CP jako krok konfiguracji, który działa, zanim inne protokoły IPv6 zaczną działać na łączu, i to jest cały jego zakres: przygotować łącze, a nie numerować sieć. Dostarcz prefiks, a interfejs zacznie przenosić ruch, zamiast tylko istnieć.
Ogłoszenia routera to zwykła odpowiedź w sieci lokalnej i mniej niezawodna w tunelu punkt-punkt, ponieważ klient musi zarówno wysyłać żądania, jak i przyjmować odpowiedź. Niektóre klienty tuneli nie robią ani jednego, ani drugiego. Sprawdź, co klient jest gotów przyjąć, zanim zdecydujesz, że serwer ma to wysłać.
Ten sam prefiks musi być osiągalny z drugiego końca. Klient, który ma adres globalny, ale nie ma drogi powrotnej, jest skonfigurowany, a nie połączony.
Trasy to osobna obietnica
Nawet z adresem klient musi wiedzieć, które cele należą do tunelu, a serwer potrzebuje drogi powrotnej dla tych celów. To dwie decyzje podjęte w dwóch miejscach. Tunel przenoszący cały ruch IPv6 potrzebuje trasy domyślnej na kliencie i trasy powrotnej na serwerze; tunel dzielony wymaga, aby obie strony zgodziły się co do tej samej listy prefiksów. Gdy się nie zgadzają, ruch wychodzi i nigdy nie wraca.
Zapisz listę, zanim cokolwiek skonfigurujesz. Jeśli plan mówi, że przez tunel przechodzi tylko prefiks firmowy, klient nie powinien mieć domyślnej trasy IPv6, a serwer nie powinien jej ogłaszać.
Resztę rozstrzyga integracja klienta
Niektóre klienty tuneli konfigurują IPv6 jawnie. Na przykład Network Extension firmy Apple przyjmuje adres, prefiks i zestaw tras dla tunelu, więc aplikacja, która go używa, nie czeka na ogłoszenie w stylu Ethernet. Inne polegają na ogłoszeniach routera przychodzących przez łącze. Oba modele są uzasadnione i wymagają innego zachowania serwera, więc zły wybór daje klienta, który wiecznie czeka na wiadomość, której nikt nie wysyła. Rozpoznaj model, zanim zmienisz serwer.
Stara nazwa interfejsu, taka jak ppp0, niczego nie dowodzi o stosie działającym dziś. Współczesny klient może używać API tunelu pakietowego zamiast interfejsu PPP, a założenie, że zachowuje się jak historyczne połączenie, to sposób na zepsucie działającego projektu. Pytaj o wersję klienta i metodę dostarczania, nie o nazwę interfejsu.
Napisz plan, którego potrzebuje klient
Pełny opis obejmuje trzy rzeczy: jaki adres ma klient, jakie cele tunel ma przenosić i jak sieć odsyła odpowiedzi. Adres link-local nie odpowiada na żadne z nich, a przyjęte ogłoszenie odpowiada tylko na część jednego. Sprawdzaj każdy punkt osobno, zamiast akceptować zielony wskaźnik. Następnie zapisz, który mechanizm dostarczył każdą odpowiedź, bo ten zapis zamienia następny raport o IPv6 w kontrolę trwającą dwie minuty.
Przechowuj zapis razem z dokumentacją usługi i aktualizuj go, gdy klient się zmieni. Plan, który był poprawny dla klienta PPP, może być błędny dla klienta tunelu pakietowego w tej samej usłudze. Cztery pytania pozostają te same; zmieniają się tylko odpowiedzi.