Mit tárgyal az IPv6CP, és minek kell még előtag
A link-local cím a PPP-interfészen beállítási lépés, nem IPv6-hozzáférés. Válassza külön az azonosítócserét az előtagoktól, az útvonalaktól és az ügyfélintegrációtól.
Az IPv6 feljön a PPP-interfészen, megjelenik egy link-local cím, és a változást késznek nyilvánítják. Aztán semmi nem forgalmazódik, nincs globális cím, és egy nyilvános célpont felé indított teszt meghiúsul, miközben az interfész továbbra is beállítottnak látszik. Az összeköttetés feljött; a hálózat soha. Végezze el az alábbi négy ellenőrzést sorrendben, és álljon meg annál, amelyik megmagyarázza a hiányt.
Mit bizonyít valójában egy link-local cím
Az IPv6CP felhozza az IPv6-ot a PPP-összeköttetésen, és interfész-azonosítót tárgyal mindkét félnek. Ez az azonosító link-local címet hoz létre, amely elegendő a partnerrel való beszélgetéshez az összeköttetésen, és nem elegendő bármi más eléréséhez. A cím bizonyítja, hogy az összeköttetés készen áll az IPv6-ra, és semmit nem bizonyít a partner mögötti hálózatról. Hozzáférési címként olvasni az a hiba, amellyel e vizsgálatok többsége kezdődik.
Az alábbi négy kérdés szétválasztja, mit dönt el az összeköttetési réteg, és mit kell a szolgáltatásnak biztosítania. Sorrendben válaszoljon rájuk, mert egy későbbi kérdésre nem lehet válaszolni, amíg egy korábbi nyitva van.
| 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 |
Honnan kell az előtagnak jönnie
A globális címnek valahonnan előtag kell: útválasztó-hirdetés, delegált előtag, DHCPv6 vagy statikus beállítás. Az IPv6CP nem hordoz egyet sem, és semmilyen várakozás az összeköttetésen nem hoz létre egyet. RFC 5072 az IPv6CP-t a beállítási lépésként helyezi el, amely azelőtt fut, hogy más IPv6-protokollok működnének az összeköttetésen, és ez a teljes hatóköre: az összeköttetés előkészítése, nem a hálózat számozása. Adja meg az előtagot, és az interfész forgalmat kezd hordozni a puszta létezés helyett.
Az útválasztó-hirdetések a szokásos válasz a helyi hálózaton, és kevésbé megbízható pont-pont alagúton, mert az ügyfélnek kéréseket kell küldenie és a választ is el kell fogadnia. Egyes alagútügyfelek egyiket sem teszik. Ellenőrizze, mit hajlandó az ügyfél elfogadni, mielőtt eldönti, hogy a kiszolgálónak el kell küldenie.
Ugyanannak az előtagnak a másik végpontból is elérhetőnek kell lennie. Az az ügyfél, amelynek van globális címe, de nincs visszaútja, be van állítva, de nincs csatlakoztatva.
Az útvonalak külön ígéret
Még címmel is tudnia kell az ügyfélnek, mely célpontok tartoznak az alagúthoz, és a kiszolgálónak visszaútra van szüksége ezekhez a célpontokhoz. Ez két döntés, két helyen. Az alagút, amely minden IPv6-forgalmat hordoz, alapértelmezett útvonalat igényel az ügyfélen és visszautat a kiszolgálón; a megosztott alagút azt igényli, hogy mindkét fél ugyanabban az előtaglistában egyezzen meg. Ha nem értenek egyet, a forgalom elmegy, és soha nem tér vissza.
Írja fel a listát, mielőtt bármit beállít. Ha a terv szerint csak a vállalati előtag megy át az alagúton, az ügyfélnek nem szabad alapértelmezett IPv6-útvonala legyen, és a kiszolgálónak nem szabad ilyet hirdetnie.
Az ügyfélintegráció dönt a többiről
Egyes alagútügyfelek kifejezetten beállítják az IPv6-ot. Az Apple Network Extensionje például címet, előtagot és útvonalkészletet vesz át az alagúthoz, így az azt használó alkalmazás nem vár Ethernet-stílusú hirdetésre. Mások az összeköttetésen érkező útválasztó-hirdetésekre támaszkodnak. Mindkét modell jogos, és eltérő kiszolgálóviselkedést igényel, ezért a rossz választás olyan ügyfelet eredményez, amely örökké vár egy üzenetre, amelyet senki nem küld. A kiszolgáló módosítása előtt azonosítsa a modellt.
Egy régi interfésznév, mint a ppp0, semmit nem bizonyít a ma futó veremről. Egy mai ügyfél csomagalagút-API-t használhat PPP-interfész helyett, és azt feltételezni, hogy történelmi kapcsolatként viselkedik, az a módja egy működő tervezés elrontásának. A kiszolgálóverziót és az ellátási módot kérdezze, ne az interfész nevét.
Írja meg a tervet, amelyre az ügyfélnek szüksége van
A teljes leírás három dolgot fed le: milyen címe van az ügyfélnek, mely célpontokat hordozzon az alagút, és hogyan küldi vissza a hálózat a válaszokat. A link-local cím egyikre sem válaszol, és egy elfogadott hirdetés csak az egyiknek egy részére. Ellenőrizze külön-külön minden tételt, ahelyett hogy elfogadna egy zöld jelzést. Ezután jegyezze fel, melyik mechanizmus szolgáltatta az egyes válaszokat, mert ez a feljegyzés a következő IPv6-jelentést kétperces ellenőrzéssé teszi.
Tartsa a feljegyzést a szolgáltatás dokumentációjával együtt, és frissítse, amikor az ügyfél változik. Egy terv, amely helyes volt egy PPP-ügyfélnek, hibás lehet egy csomagalagút-ügyfélnek ugyanazon a szolgáltatáson. A négy kérdés ugyanaz marad; csak a válaszok mozdulnak el.