Kaj se pogaja IPv6CP in kaj še potrebuje predpono
Naslov link-local na vmesniku PPP je korak nastavitve, ne dostop do IPv6. Ločite izmenjavo identifikatorjev od predpon, poti in integracije odjemalca.
IPv6 se dvigne na vmesniku PPP, pojavi se naslov link-local in sprememba je razglašena za končano. Nato se nič ne usmerja, globalnega naslova ni in preizkus do javnega cilja spodleti, medtem ko je vmesnik videti še vedno konfiguriran. Povezava se je dvignila; omrežje nikoli. Izvedite štiri preverjanja spodaj po vrsti in ustavite se pri tistem, ki pojasni vrzel.
Kaj naslov link-local v resnici dokazuje
IPv6CP dvigne IPv6 na povezavi PPP in se za vsako stran pogaja o identifikatorju vmesnika. Ta identifikator ustvari naslov link-local, ki zadošča za pogovor s partnerjem čez povezavo in ne zadošča za doseganje česar koli drugega. Naslov dokazuje, da je povezava pripravljena na IPv6, in ne dokazuje ničesar o omrežju za partnerjem. Branje naslova kot dostopnega naslova je napaka, s katero se začne večina teh preiskav.
Štiri vprašanja spodaj ločujejo, kar odloči povezavni sloj, od tega, kar mora zagotoviti storitev. Odgovorite po vrsti, ker na poznejše vprašanje ni mogoče odgovoriti, dokler je prejšnje odprto.
| 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 |
Od kod mora priti predpona
Globalni naslov potrebuje predpono od nekje: naznanilo usmerjevalnika, delegirano predpono, DHCPv6 ali statično konfiguracijo. IPv6CP ne nosi nobene in nobeno čakanje na povezavi je ne ustvari. RFC 5072 postavlja IPv6CP kot korak nastavitve, ki se izvede, preden na povezavi delujejo drugi protokoli IPv6, in to je ves njegov obseg: pripraviti povezavo, ne oštevilčiti omrežja. Zagotovite predpono in vmesnik začne prenašati promet, namesto da bi le obstajal.
Naznanila usmerjevalnika so običajen odgovor v lokalnem omrežju in manj zanesljiv v tunelu od točke do točke, ker mora odjemalec pošiljati zahteve in sprejeti odgovor. Nekateri tunelski odjemalci ne storijo ne enega ne drugega. Preverite, kaj je odjemalec pripravljen sprejeti, preden se odločite, da naj strežnik to pošlje.
Ista predpona mora biti dosegljiva z drugega konca. Odjemalec, ki ima globalni naslov, a nima poti nazaj, je konfiguriran, ne povezan.
Poti so ločena obljuba
Tudi z naslovom mora odjemalec vedeti, kateri cilji spadajo v tunel, strežnik pa potrebuje pot nazaj za te cilje. To sta dve odločitvi, sprejeti na dveh mestih. Tunel, ki prenaša ves promet IPv6, potrebuje privzeto pot na odjemalcu in povratno pot na strežniku; razdeljeni tunel zahteva, da se obe strani strinjata o istem seznamu predpon. Ko se ne strinjata, promet odide in se nikoli ne vrne.
Zapišite seznam, preden karkoli konfigurirate. Če načrt pravi, da skozi tunel gre le korporativna predpona, odjemalec ne sme imeti privzete poti IPv6 in strežnik je ne sme naznanjati.
O preostalem odloči integracija odjemalca
Nekateri tunelski odjemalci konfigurirajo IPv6 izrecno. Network Extension podjetja Apple na primer prevzame naslov, predpono in nabor poti za tunel, zato aplikacija, ki ga uporablja, ne čaka na naznanilo v slogu Ethernet. Drugi se zanašajo na naznanila usmerjevalnika, ki prispejo po povezavi. Oba modela sta legitimna in zahtevata drugačno vedenje strežnika, zato napačna izbira ustvari odjemalca, ki večno čaka na sporočilo, ki ga nihče ne pošlje. Prepoznajte model, preden spremenite strežnik.
Staro ime vmesnika, kot je ppp0, ne dokazuje ničesar o skladu, ki teče danes. Sodoben odjemalec lahko uporabi API paketnega tunela namesto vmesnika PPP, in domneva, da se vede kot zgodovinska povezava, je način, kako pokvariti delujočo zasnovo. Vprašajte za različico odjemalca in način zagotavljanja, ne za ime vmesnika.
Napišite načrt, ki ga odjemalec potrebuje
Popoln opis zajema tri stvari: kateri naslov ima odjemalec, katere cilje naj bi prenašal tunel in kako omrežje pošilja odgovore nazaj. Naslov link-local ne odgovori na nobeno od teh, sprejeto naznanilo pa le na del enega. Preverite vsako postavko posebej, namesto da sprejmete zelen indikator. Nato zabeležite, kateri mehanizem je zagotovil vsak odgovor, ker ta zapis spremeni naslednje poročilo o IPv6 v preverjanje, dolgo dve minuti.
Zapis hranite skupaj z dokumentacijo storitve in ga posodobite, ko se odjemalec spremeni. Načrt, ki je bil pravilen za odjemalca PPP, je lahko napačen za odjemalca paketnega tunela na isti storitvi. Štiri vprašanja ostajajo enaka; premikajo se le odgovori.