Ano ang pinag-uusapan ng IPv6CP at ano pa ang kailangan ng prefix
Ang link-local address sa PPP interface ay hakbang sa setup, hindi access sa IPv6. Ihiwalay ang palitan ng identifier sa mga prefix, ruta at integrasyon ng kliyente.
Bumabangon ang IPv6 sa PPP interface, lumilitaw ang link-local address, at idinedeklarang tapos na ang pagbabago. Pagkatapos walang niruruta, walang global address, at nabigo ang pagsubok sa pampublikong destinasyon habang mukhang naka-configure pa rin ang interface. Bumangon ang link; hindi kailanman bumangon ang network. Gawin ang apat na pagsusuri sa ibaba nang sunud-sunod at huminto sa isang nagpapaliwanag ng agwat.
Ano ang talagang pinapatunayan ng link-local address
Iniaangat ng IPv6CP ang IPv6 sa PPP link at nakikipag-usap sa isang interface identifier para sa bawat panig. Ang identifier na iyon ay gumagawa ng link-local address, na sapat para makipag-usap sa kapwa sa pamamagitan ng link at hindi sapat para maabot ang anupaman. Pinapatunayan ng address na handa ang link para sa IPv6, at wala itong pinapatunayan tungkol sa network sa likod ng kapwa. Ang pagbasa nito bilang access address ang pagkakamaling pinagsisimulan ng karamihan ng mga imbestigasyong ito.
Ang apat na tanong sa ibaba ay naghihiwalay sa itinatakda ng link layer mula sa dapat ibigay ng serbisyo. Sagutin ang mga ito nang sunud-sunod, dahil hindi masasagot ang susunod na tanong habang bukas pa ang nauna.
| 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 |
Saan dapat magmula ang prefix
Ang global address ay nangangailangan ng prefix mula sa kung saan: isang anunsyo ng router, isang delegadong prefix, DHCPv6 o static na configuration. Walang dinadala ang IPv6CP, at walang paghihintay sa link ang gagawa nito. RFC 5072 inilalagay ang IPv6CP bilang hakbang sa setup na tumatakbo bago magtrabaho ang ibang IPv6 protocol sa link, at iyon ang buong saklaw nito: ihanda ang link, hindi bilangin ang network. Ibigay ang prefix at magsisimulang magdala ng trapiko ang interface sa halip na umiral lamang.
Ang mga anunsyo ng router ay karaniwang sagot sa LAN at hindi gaanong maaasahan sa point-to-point tunnel, dahil kailangang magpadala ng mga kahilingan at tumanggap ng sagot ang kliyente. May mga tunnel client na wala sa dalawa. Suriin kung ano ang handang tanggapin ng kliyente bago magpasya na dapat itong ipadala ng server.
Ang parehong prefix ay dapat maabot mula sa kabilang dulo. Ang kliyenteng may global address ngunit walang daan pabalik ay naka-configure, hindi konektado.
Ang ruta ay hiwalay na pangako
Kahit may address, kailangang malaman ng kliyente kung aling destinasyon ang kabilang sa tunnel, at kailangan ng server ng daan pabalik para sa mga destinasyong iyon. Ito ay dalawang desisyong ginawa sa dalawang lugar. Ang tunnel na nagdadala ng lahat ng trapikong IPv6 ay nangangailangan ng default na ruta sa kliyente at daan pabalik sa server; ang hati na tunnel ay nangangailangan na parehong panig ay sumang-ayon sa parehong listahan ng prefix. Kapag hindi sila sumasang-ayon, lumalabas ang trapiko at hindi na bumabalik.
Isulat ang listahan bago i-configure ang anuman. Kung sinasabi ng plano na tanging prefix ng kumpanya ang dumadaan sa tunnel, hindi dapat magkaroon ng default na IPv6 route ang kliyente, at hindi dapat ianunsyo ito ng server.
Ang natitira ay pinagpapasyahan ng integrasyon ng kliyente
May mga tunnel client na tahasang nagko-configure ng IPv6. Halimbawa, ang Network Extension ng Apple ay kumukuha ng address, prefix at hanay ng ruta para sa tunnel, kaya ang aplikasyong gumagamit nito ay hindi naghihintay ng anunsyong tulad ng Ethernet. Ang iba ay umaasa sa mga anunsyo ng router na dumarating sa link. Pareho ang mga modelong ito ay lehitimo at nangangailangan ng magkaibang pag-uugali ng server, kaya ang maling pagpili ay lumilikha ng kliyenteng walang hanggang naghihintay ng mensaheng walang nagpapadala. Tukuyin ang modelo bago baguhin ang server.
Ang lumang pangalan ng interface tulad ng ppp0 ay walang pinapatunayan tungkol sa stack na tumatakbo ngayon. Ang makabagong kliyente ay maaaring gumamit ng packet-tunnel API sa halip na PPP interface, at ang pag-akalang kumikilos ito tulad ng makasaysayang koneksyon ay ang paraan para masira ang gumaganang disenyo. Itanong ang bersyon ng kliyente at paraan ng pagtataguyod, hindi ang pangalan ng interface.
Isulat ang planong kailangan ng kliyente
Ang kumpletong paglalarawan ay sumasaklaw sa tatlong bagay: kung anong address ang hawak ng kliyente, anong mga destinasyon ang dapat dalhin ng tunnel at paano ibinabalik ng network ang mga sagot. Ang link-local address ay hindi sumasagot sa alinman sa mga ito, at ang tinanggap na anunsyo ay sumasagot lamang sa isang bahagi ng isa. Suriin ang bawat aytem nang hiwalay sa halip na tanggapin ang berdeng tagapagpahiwatig. Pagkatapos itala kung aling mekanismo ang nagbigay ng bawat sagot, dahil ginagawa ng talaang iyon ang susunod na ulat ng IPv6 na pagsusuring dalawang minuto.
Itago ang tala kasama ng dokumentasyon ng serbisyo at i-update ito kapag nagbago ang kliyente. Ang planong tama para sa kliyenteng PPP ay maaaring mali para sa kliyenteng packet tunnel sa parehong serbisyo. Ang apat na tanong ay mananatiling pareho; ang mga sagot lamang ang gumagalaw.