Wat IPv6CP ûnderhannelet en wat noch in foarheaksel nedich hat
In link-local adres op 'e PPP-ynterface is in opsetstap, gjin IPv6-tagong. Skied it útwikseljen fan identifikaasjes fan foarheaksels, rûtes en kliïntyntegraasje.
IPv6 komt omheech op 'e PPP-ynterface, in link-local adres ferskynt, en de feroaring wurdt klear ferklearre. Dan rûtet neat, der bestiet gjin globaal adres, en in test nei in publike bestimming mislearret wylst de ynterface der noch altyd ynsteld útsjocht. De ferbining kaam omheech; it netwurk nea. Wurkje de fjouwer kontrôles hjirûnder yn folchoarder troch en stopje by dy't it gat ferklearret.
Wat in link-local adres eins bewissiget
IPv6CP bringt IPv6 omheech op 'e PPP-ferbining en ûnderhannelet in ynterface-identifikaasje foar eltse kant. Dy identifikaasje produsearret in link-local adres, dat genôch is om mei de partner oer de ferbining te praten en net genôch om eat oars te berikken. It adres bewissiget dat de ferbining klear is foar IPv6, en it bewissiget neat oer it netwurk efter de partner. It lêze as tagongsadres is de flater dêr't de measte fan dizze ûndersiken mei begjinne.
De fjouwer fragen hjirûnder skiede wat de ferbiningslaach beslút fan wat de tsjinst leverje moat. Beäntwurdzje se yn folchoarder, want in lettere fraach kin net beäntwurde wurde wylst in eardere noch iepen is.
| 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 |
Wêr't it foarheaksel wei komme moat
In globaal adres hat in foarheaksel fan earne nedich: in routeroanwizing, in delegearre foarheaksel, DHCPv6 of statyske konfiguraasje. IPv6CP draacht der gjin ien, en gjin hoemannichte wachtsjen op 'e ferbining sil der ien produsearje. RFC 5072 pleatst IPv6CP as de opsetstap dy't rint foardat oare IPv6-protokollen op 'e ferbining wurkje, en dat is syn hiele omfang: de ferbining tariede, net it netwurk nûmerje. Leverje it foarheaksel en de ynterface begjint ferkear te dragen ynstee fan inkeld te bestean.
Routeroanwizingen binne it gewoane antwurd op in LAN en in minder betrouber ien op in punt-nei-punt-tunnel, want de kliïnt moat sawol fersiken stjoere as it antwurd akseptearje. Guon tunnelkliïnten dogge gjin fan beide. Kontrolearje wat de kliïnt beried is te akseptearjen foardat jo beslute dat de server it stjoere moat.
Itselde foarheaksel moat fan 'e oare kant berikber wêze. In kliïnt dy't in globaal adres hat mar gjin weromwei, is ynsteld, net ferbûn.
Rûtes binne in aparte belofte
Sels mei in adres moat de kliïnt witte hokker bestimmingen by de tunnel hearre, en de server hat in weromwei foar dy bestimmingen nedich. Dat binne twa besluten nommen op twa plakken. In tunnel dy't al it IPv6-ferkear draacht hat in standertrûte op 'e kliïnt en in weromrûte op 'e server nedich; in splitst tunnel freget dat beide kanten it iens wurde oer deselde foarheaksel-list. As se it net iens binne, giet it ferkear fuort en komt it nea werom.
Skriuw de list op foardat jo eat ynstelle. As it plan seit dat allinnich it bedriuwsfoarheaksel troch de tunnel giet, dan moat de kliïnt gjin standert-IPv6-rûte hawwe, en de server moat der gjin ien oankundigje.
Kliïntyntegraasje beslút de rest
Guon tunnelkliïnten stelle IPv6 eksplisyt yn. Bygelyks Network Extension fan Apple nimt in adres, in foarheaksel en in set rûtes foar de tunnel, sadat in applikaasje dy't it brûkt net op in Ethernet-eftige oankundiging wachtet. Oaren fertrouwe op routeroanwizingen dy't oer de ferbining binnenkomme. Beide modellen binne legit en se freegje oar servergedrach, sadat it ferkearde kiezen in kliïnt oplevert dy't ivich wachtet op in berjocht dat nimmen stjoert. Identifisearje it model foardat jo de server feroarje.
In âlde ynterfacenamme lykas ppp0 bewissiget neat oer de stapel dy't hjoed rint. In hjoeddeistige kliïnt kin in pakket-tunnel-API brûke ynstee fan in PPP-ynterface, en oannimme dat er him as in histoaryske ferbining hâldt en draacht is hoe't in wurkjend ûntwerp brutsen wurdt. Freegje nei de kliïntferzje en de foarsjenningmetoade, net nei de ynterfacenamme.
Skriuw it plan dat de kliïnt nedich hat
In folsleine beskriuwing beslacht trije dingen: hokker adres de kliïnt hat, hokker bestimmingen de tunnel drage moat, en hoe't it netwurk antwurden weromstjoert. In link-local adres beäntwurdet gjinien fan dy, en in akseptearre oankundiging beäntwurdet mar in part fan ien. Kontrolearje elk item apart ynstee fan in griene yndikator te akseptearjen. Notearje dan hokker meganisme elk antwurd levere, want dat ferslach makket it folgjende IPv6-rapport in kontrôle fan twa minuten.
Hâld it ferslach by de tsjinstedokumintaasje en wurkje it by as de kliïnt feroaret. In plan dat goed wie foar in PPP-kliïnt kin ferkeard wêze foar in pakket-tunnelkliïnt op deselde tsjinst. De fjouwer fragen bliuwe itselde; allinnich de antwurden ferpleatse har.