IPv6CP inajadili nini na nini bado kinahitaji kiambishi awali
Anwani ya link-local kwenye kiolesura cha PPP ni hatua ya usanidi, si ufikiaji wa IPv6. Tenganisha ubadilishanaji wa vitambulisho na viambishi awali, njia na muunganiko wa mteja.
IPv6 inapanda kwenye kiolesura cha PPP, anwani ya link-local inaonekana, na mabadiliko yatangazwa kuwa yamekamilika. Kisha hakuna kinachoelekezwa, hakuna anwani ya kimataifa, na jaribio kuelekea lengwa la umma linashindikana wakati kiolesura bado kinaonekana kimeundwa. Kiungo kilipanda; mtandao haukuwa kamwe. Fanya ukaguzi nne hapa chini kwa mpangilio na usimame kwenye ule unaoeleza pengo.
Anwani ya link-local inathibitisha nini kwa kweli
IPv6CP hupandisha IPv6 kwenye kiungo cha PPP na hujadili kitambulisho cha kiolesura kwa kila upande. Kitambulisho hicho hutengeneza anwani ya link-local, ambayo inatosha kuzungumza na mwenzake kupitia kiungo na haitoshi kufikia kitu kingine chochote. Anwani inathibitisha kuwa kiungo kiko tayari kwa IPv6, na haithibitishi chochote kuhusu mtandao ulio nyuma ya mwenzake. Kuiona kama anwani ya ufikiaji ndilo kosa ambalo uchunguzi mwingi kama huu huanzia.
Maswali manne hapa chini yanatenganisha kile tabaka la kiungo huamua na kile huduma inapaswa kutoa. Yajibu kwa mpangilio, kwa sababu swali la baadaye haliwezi kujibiwa wakati la awali liko wazi.
| 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 |
Kiambishi awali kinapaswa kutoka wapi
Anwani ya kimataifa inahitaji kiambishi awali kutoka mahali fulani: tangazo la kipanga njia, kiambishi awali kilichokabidhiwa, DHCPv6 au usanidi tuli. IPv6CP haibebi chochote, na hakuna kusubiri kwenye kiungo kutakachozalisha. RFC 5072 inaweka IPv6CP kama hatua ya usanidi inayokimbia kabla ya itifaki nyingine za IPv6 kufanya kazi kwenye kiungo, na huo ndio wigo wake wote: kuandaa kiungo, si kuhesabu mtandao. Toa kiambishi awali na kiolesura kitaanza kubeba trafiki badala ya kuwepo tu.
Matangazo ya kipanga njia ni jibu la kawaida kwenye LAN na jibu lisilo la kuaminika zaidi kwenye handaki la nukta-hadi-nukta, kwa sababu mteja lazima atume maombi na pia akubali jibu. Baadhi ya wateja wa handaki hawaendi wala wale. Angalia mteja yuko tayari kukubali nini kabla ya kuamua kuwa seva inapaswa kuituma.
Kiambishi awali hicho hicho lazima kifikike kutoka upande mwingine. Mteja aliye na anwani ya kimataifa lakini hana njia ya kurudi ameundwa, hajaunganishwa.
Njia ni ahadi tofauti
Hata ukiwa na anwani, mteja anahitaji kujua ni maeneo gani yaliyo ndani ya handaki, na seva inahitaji njia ya kurudi kwa maeneo hayo. Hizi ni maamuzi mawili yaliyofanywa mahali pawili. Handaki linalobeba trafiki yote ya IPv6 linahitaji njia chaguo-msingi kwa mteja na njia ya kurudi kwa seva; handaki lililogawanywa linahitaji pande zote mbili kukubaliana kuhusu orodha moja ya viambishi awali. Wasipokubaliana, trafiki inatoka na hairudi kamwe.
Andika orodha kabla ya kusanidi kitu chochote. Ikiwa mpango unasema kuwa ni kiambishi awali cha kampuni tu kinachopita kwenye handaki, mteja hapaswi kuwa na njia chaguo-msingi ya IPv6, na seva haipaswi kuitangaza.
Kilichosalia huamuliwa na muunganiko wa mteja
Baadhi ya wateja wa handaki husanidi IPv6 kwa uwazi. Kwa mfano, Network Extension ya Apple huchukua anwani, kiambishi awali na seti ya njia kwa handaki, kwa hivyo programu inayoitumia haisubiri tangazo la mtindo wa Ethernet. Wengine hutegemea matangazo ya kipanga njia yanayofika kupitia kiungo. Mitindo yote miwili ni halali na inahitaji tabia tofauti za seva, kwa hivyo kuchagua vibaya hutoa mteja anayesubiri milele ujumbe ambao hakuna mtu anautuma. Tambua mtindo kabla ya kubadilisha seva.
Jina la zamani la kiolesura kama ppp0 halithibitishi chochote kuhusu rafu inayokimbia leo. Mteja wa kisasa anaweza kutumia API ya handaki la pakiti badala ya kiolesura cha PPP, na kudhani kwamba hujiendesha kama muunganisho wa kihistoria ndiyo njia ya kuvunja muundo unaofanya kazi. Uliza toleo la mteja na mbinu ya utoaji, si jina la kiolesura.
Andika mpango ambao mteja anauhitaji
Maelezo kamili yanashughulikia mambo matatu: mteja ana anwani gani, handaki linapaswa kubeba maeneo gani, na mtandao unarudishaje majibu. Anwani ya link-local haijibu hata moja, na tangazo lililokubaliwa hujibu sehemu ya moja tu. Kagua kila kipengele kivyake badala ya kukubali kiashiria cha kijani. Kisha andika ni utaratibu gani ulitoa kila jibu, kwa sababu rekodi hiyo inageuza ripoti ijayo ya IPv6 kuwa ukaguzi wa dakika mbili.
Hifadhi rekodi pamoja na nyaraka za huduma na uisasishe mteja anapobadilika. Mpango uliokuwa sahihi kwa mteja wa PPP unaweza kuwa si sahihi kwa mteja wa handaki la pakiti kwenye huduma hiyo hiyo. Maswali manne yanabaki yale yale; ni majibu tu yanayohama.