Mida IPv6CP läbi räägib ja mis vajab endiselt prefiksit
Link-local aadress PPP-liidesel on seadistamise samm, mitte IPv6 juurdepääs. Eraldage identifikaatorite vahetus prefiksitest, marsruutidest ja kliendi integreerimisest.
IPv6 tõuseb PPP-liidesel, ilmub link-local aadress ja muudatus kuulutatakse lõpetatuks. Seejärel ei marsruudita midagi, globaalset aadressi ei ole ja test avalikku sihtkohta ebaõnnestub, samal ajal kui liides näeb endiselt seadistatud välja. Lülitus tõusis; võrk mitte kunagi. Käige allolevad neli kontrolli järjekorras läbi ja peatuge sellel, mis lünga ära seletab.
Mida link-local aadress tegelikult tõestab
IPv6CP tõstab IPv6 PPP-lülitusel üles ja räägib kummagi poole jaoks läbi liidese identifikaatori. See identifikaator loob link-local aadressi, millest piisab lülituse kaudu partneriga rääkimiseks ja millest ei piisa millegi muu kättesaamiseks. Aadress tõestab, et lülitus on IPv6 jaoks valmis, ja ei tõesta midagi partneri taga oleva võrgu kohta. Selle lugemine juurdepääsuaadressina on viga, millega enamik neist uurimistest algab.
Neli allolevat küsimust eraldavad selle, mida lülituskiht otsustab, sellest, mida teenus peab pakkuma. Vastake neile järjekorras, sest hilisemale küsimusele ei saa vastata, kuni varasem on veel lahtine.
| 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 |
Kust peab prefiks tulema
Globaalne aadress vajab prefiksit kuskilt: ruuteri teadaanne, delegeeritud prefiks, DHCPv6 või staatiline seadistus. IPv6CP ei kanna ühtegi ja ükski lülitusel ootamine seda ei tekita. RFC 5072 paigutab IPv6CP seadistamise sammuks, mis toimub enne, kui teised IPv6-protokollid lülitusel töötavad, ja see on kogu tema ulatus: lülituse ettevalmistamine, mitte võrgu nummerdamine. Andke prefiks ja liides hakkab liiklust kandma, selle asemel et lihtsalt olemas olla.
Ruuteri teadaanded on tavaline vastus kohtvõrgus ja vähem usaldusväärne punkt-punkt-tunnelis, sest klient peab nii päringuid saatma kui ka vastuse vastu võtma. Mõned tunnelikliendid ei tee kumbagi. Kontrollige, mida klient on valmis vastu võtma, enne kui otsustate, et server peaks selle saatma.
Sama prefiks peab olema kättesaadav ka teisest otsast. Klient, kellel on globaalne aadress, kuid puudub tagasitee, on seadistatud, mitte ühendatud.
Marsruudid on eraldi lubadus
Isegi aadressiga peab klient teadma, millised sihtkohad tunnelisse kuuluvad, ja server vajab nende sihtkohtade jaoks tagasiteed. Need on kaks otsust, mis tehakse kahes kohas. Tunnel, mis kannab kogu IPv6 liiklust, vajab kliendil vaikemarsruuti ja serveril tagasiteed; jaotatud tunnel nõuab, et mõlemad pooled lepiksid kokku samas prefiksite loendis. Kui need ei ühti, lahkub liiklus ega tule kunagi tagasi.
Kirjutage loend üles enne, kui midagi seadistate. Kui plaan ütleb, et tunnelist läheb ainult ettevõtte prefiks, ei tohiks kliendil olla vaikimisi IPv6 marsruuti ja server ei tohiks seda teavitada.
Kliendi integreerimine otsustab ülejäänu
Mõned tunnelikliendid seadistavad IPv6 selgesõnaliselt. Näiteks Apple'i Network Extension võtab tunneli jaoks aadressi, prefiksi ja rea marsruute, nii et seda kasutav rakendus ei oota Etherneti-stiilis teadaannet. Teised loodavad lülitusel saabuvatele ruuteri teadaannetele. Mõlemad mudelid on õiguspärased ja nõuavad erinevat serveri käitumist, nii et vale valik annab kliendi, mis ootab igavesti sõnumit, mida keegi ei saada. Tehke mudel kindlaks enne serveri muutmist.
Vana liidese nimi nagu ppp0 ei tõesta midagi täna töötava virna kohta. Kaasaegne klient võib kasutada PPP-liidese asemel paketitunneli API-t, ja eeldus, et see käitub nagu ajalooline ühendus, on viis töötava kavandi lõhkumiseks. Küsige kliendi versiooni ja pakkumismeetodi, mitte liidese nime kohta.
Kirjutage plaan, mida klient vajab
Täielik kirjeldus katab kolm asja: millist aadressi klient hoiab, milliseid sihtkohti tunnel peaks kandma ja kuidas võrk vastuseid tagasi saadab. Link-local aadress ei vasta neist ühelegi ja vastuvõetud teadaanne vastab ainult ühe osale. Kontrollige iga punkti eraldi, selle asemel et aktsepteerida rohelist indikaatorit. Seejärel kirjutage üles, milline mehhanism iga vastuse andis, sest see kirje muudab järgmise IPv6 aruande kaheminutiliseks kontrolliks.
Hoidke kirjet teenuse dokumentatsiooni juures ja uuendage seda, kui klient muutub. Plaan, mis oli õige PPP-kliendile, võib olla vale paketitunneli kliendile samas teenuses. Neli küsimust jäävad samaks; liiguvad ainult vastused.