Çfarë negocion IPv6CP dhe çfarë ende kërkon një prefiks
Një adresë link-local në ndërfaqen PPP është hap konfigurimi, jo akses IPv6. Ndani shkëmbimin e identifikuesve nga prefikset, rrugët dhe integrimi i klientit.
IPv6 ngrihet në ndërfaqen PPP, shfaqet një adresë link-local dhe ndryshimi shpallet i përfunduar. Pastaj asgjë nuk rrugëtohet, nuk ekziston asnjë adresë globale dhe një provë drejt një destinacioni publik dështon ndërkohë që ndërfaqja duket ende e konfiguruar. Lidhja u ngrit; rrjeti nuk u ngrit kurrë. Kryeni katër kontrollet më poshtë me radhë dhe ndaloni te ai që shpjegon hendekun.
Çfarë vërteton në të vërtetë një adresë link-local
IPv6CP ngre IPv6 në lidhjen PPP dhe negocion një identifikues ndërfaqeje për secilën anë. Ky identifikues prodhon një adresë link-local, e cila mjafton për të folur me palën përmes lidhjes dhe nuk mjafton për të arritur asgjë tjetër. Adresa vërteton se lidhja është gati për IPv6 dhe nuk vërteton asgjë për rrjetin pas palës. Leximi i saj si adresë aksesi është gabimi me të cilin nisin shumica e këtyre hetimeve.
Katër pyetjet më poshtë ndajnë atë që vendos shtresa e lidhjes nga ajo që duhet të ofrojë shërbimi. Përgjigjuni me radhë, sepse një pyetjeje të mëvonshme nuk mund t'i përgjigjesh derisa një e mëparshme mbetet e hapur.
| 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 |
Nga duhet të vijë prefiksi
Një adresë globale ka nevojë për një prefiks nga diku: një shpallje rrugëtuesi, një prefiks i deleguar, DHCPv6 ose konfigurim statik. IPv6CP nuk mbart asnjë dhe asnjë pritje në lidhje nuk do të prodhojë një. RFC 5072 e vendos IPv6CP si hapin e konfigurimit që ekzekutohet përpara se protokollet e tjera IPv6 të punojnë në lidhje, dhe ky është i gjithë shtrirja e tij: përgatitja e lidhjes, jo numërimi i rrjetit. Ofroni prefiksin dhe ndërfaqja fillon të mbartë trafik në vend që thjesht të ekzistojë.
Shpalljet e rrugëtuesit janë përgjigjja e zakonshme në një LAN dhe një më pak e besueshme në një tunel pikë më pikë, sepse klienti duhet të dërgojë kërkesa dhe të pranojë përgjigjen. Disa klientë tuneli nuk bëjnë as njërën. Kontrolloni çfarë është i gatshëm të pranojë klienti përpara se të vendosni që serveri duhet ta dërgojë.
I njëjti prefiks duhet të jetë i arritshëm nga skaji tjetër. Një klient që ka adresë globale por nuk ka rrugë kthimi është i konfiguruar, jo i lidhur.
Rrugët janë një premtim më vete
Edhe me një adresë, klienti duhet të dijë cilat destinacione i përkasin tunelit, dhe serveri ka nevojë për një rrugë kthimi për ato destinacione. Këto janë dy vendime të marra në dy vende. Një tunel që mbart të gjithë trafikun IPv6 ka nevojë për një rrugë të paracaktuar në klient dhe një rrugë kthimi në server; një tunel i ndarë kërkon që të dyja palët të bien dakord për të njëjtën listë prefiksesh. Kur nuk bien dakord, trafiku del dhe nuk kthehet kurrë.
Shkruani listën përpara se të konfiguroni gjithçka. Nëse plani thotë se vetëm prefiksi korporativ kalon përmes tunelit, klienti nuk duhet të ketë një rrugë IPv6 të paracaktuar, dhe serveri nuk duhet të shpallë një të tillë.
Pjesën tjetër e vendos integrimi i klientit
Disa klientë tuneli konfigurojnë IPv6 në mënyrë eksplicite. Network Extension i Apple, për shembull, merr një adresë, një prefiks dhe një grup rrugësh për tunelin, kështu që një aplikacion që e përdor nuk pret një shpallje në stilin Ethernet. Të tjerë mbështeten te shpalljet e rrugëtuesit që mbërrijnë përmes lidhjes. Të dy modelet janë legjitime dhe kërkojnë sjellje të ndryshme të serverit, prandaj zgjedhja e gabuar prodhon një klient që pret përgjithmonë një mesazh që askush nuk e dërgon. Identifikoni modelin përpara se të ndryshoni serverin.
Një emër i vjetër ndërfaqeje si ppp0 nuk vërteton asgjë për stivin që punon sot. Një klient modern mund të përdorë një API tuneli paketash në vend të një ndërfaqeje PPP, dhe supozimi se sillet si një lidhje historike është mënyra si prishet një dizajn që funksionon. Pyetni për versionin e klientit dhe metodën e furnizimit, jo për emrin e ndërfaqes.
Shkruani planin që i duhet klientit
Një përshkrim i plotë mbulon tri gjëra: çfarë adrese mban klienti, cilat destinacione duhet të mbartë tuneli dhe si i dërgon rrjeti përgjigjet mbrapsht. Një adresë link-local nuk i përgjigjet asnjërës, dhe një shpallje e pranuar i përgjigjet vetëm një pjese të njërës. Kontrolloni çdo zë veç e veç, në vend që të pranoni një tregues të gjelbër. Më pas shënoni cili mekanizëm ofroi çdo përgjigje, sepse ai regjistrim e kthen raportin e radhës për IPv6 në një kontroll dy minutash.
Mbajeni regjistrimin bashkë me dokumentacionin e shërbimit dhe përditësojeni kur ndryshon klienti. Një plan që ishte i saktë për një klient PPP mund të jetë i gabuar për një klient tuneli paketash në të njëjtin shërbim. Katër pyetjet mbeten të njëjtat; lëvizin vetëm përgjigjet.