Kion IPv6CP intertraktas kaj kio ankoraŭ bezonas prefikson
Ligila loka adreso sur la PPP-interfaco estas agorda paŝo, ne IPv6-aliro. Apartigu la identigilon-interŝanĝon de prefiksoj, vojoj kaj klienta integriĝo.
IPv6 leviĝas sur la PPP-interfaco, ligila loka adreso aperas, kaj la ŝanĝo estas deklarita finita. Poste nenio estas enkursigata, tutmonda adreso ne ekzistas, kaj testo al publika celo malsukcesas dum la interfaco ankoraŭ aspektas agordita. La ligilo leviĝis; la reto neniam. Trapasu la kvar kontrolojn sube laŭ ordo kaj haltu ĉe tiu, kiu klarigas la mankon.
Kion ligila loka adreso vere pruvas
IPv6CP levas IPv6 sur la PPP-ligilo kaj intertraktas interfacan identigilon por ĉiu flanko. Tiu identigilo produktas ligilan lokan adreson, kiu sufiĉas por paroli kun la kunulo tra la ligilo kaj ne sufiĉas por atingi ion alian. La adreso pruvas, ke la ligilo pretas por IPv6, kaj ĝi pruvas nenion pri la reto malantaŭ la kunulo. Legi ĝin kiel alira adreso estas la eraro, per kiu komenciĝas la plej multaj el ĉi tiuj enketoj.
La kvar demandoj sube apartigas tion, kion decidas la ligila tavolo, de tio, kion la servo devas provizi. Respondu ilin laŭ ordo, ĉar posta demando ne povas esti respondita dum pli frua ankoraŭ malfermiĝas.
| 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 |
De kie la prefikso devas veni
Tutmonda adreso bezonas prefikson de ie: enkursigila anonco, delegita prefikso, DHCPv6 aŭ statika agordo. IPv6CP portas neniun, kaj nenia atendado sur la ligilo produktos unu. RFC 5072 lokas IPv6CP kiel la agordan paŝon, kiu funkcias antaŭ ol aliaj IPv6-protokoloj funkcias sur la ligilo, kaj tio estas ĝia tuta amplekso: prepari la ligilon, ne numeri la reton. Provizu la prefikson kaj la interfaco komencas porti trafikon anstataŭ nur ekzisti.
Enkursigilaj anoncoj estas la kutima respondo en loka reto kaj malpli fidinda en punkt-al-punkta tunelo, ĉar la kliento devas kaj sendi petojn kaj akcepti la respondon. Iuj tunelaj klientoj faras nek unu. Kontrolu, kion la kliento pretas akcepti, antaŭ ol decidi, ke la servilo devas sendi ĝin.
La sama prefikso devas esti atingebla de la alia fino. Kliento, kiu havas tutmondan adreson sed neniun revenan vojon, estas agordita, ne konektita.
Vojoj estas aparta promeso
Eĉ kun adreso, la kliento devas scii, kiuj celoj apartenas al la tunelo, kaj la servilo bezonas revenan vojon por tiuj celoj. Tio estas du decidoj faritaj en du lokoj. Tunelo, kiu portas la tutan IPv6-trafikon, bezonas defaŭltan vojon sur la kliento kaj revenan vojon sur la servilo; dividita tunelo bezonas, ke ambaŭ flankoj konsentu pri la sama prefiksa listo. Kiam ili malkonsentas, trafiko foriras kaj neniam revenas.
Skribu la liston antaŭ ol agordi ion ajn. Se la plano diras, ke nur la entreprena prefikso iras tra la tunelo, la kliento ne devus havi defaŭltan IPv6-vojon, kaj la servilo ne devus anonci unu.
Klienta integriĝo decidas la reston
Iuj tunelaj klientoj agordas IPv6 eksplicite. La Network Extension de Apple, ekzemple, prenas adreson, prefikson kaj aron da vojoj por la tunelo, do aplikaĵo, kiu uzas ĝin, ne atendas anoncon laŭ Ethernet-stilo. Aliaj fidas enkursigilajn anoncojn alvenantajn tra la ligilo. Ambaŭ modeloj estas legitaj kaj postulas malsaman servilan konduton, do elekti la malĝustan produktas klienton, kiu atendas eterne mesaĝon, kiun neniu sendas. Identigu la modelon antaŭ ol ŝanĝi la servilon.
Malnova interfaca nomo kiel ppp0 pruvas nenion pri la stako, kiu funkcias hodiaŭ. Nuntempa kliento povas uzi paket-tunelan API anstataŭ PPP-interfaco, kaj supozi, ke ĝi kondutas kiel historia konekto, estas la maniero rompi funkciantan dezajnon. Demandu pri la klienta versio kaj la provizmetodo, ne pri la interfaca nomo.
Skribu la planon, kiun la kliento bezonas
Kompleta priskribo kovras tri aferojn: kiun adreson la kliento tenas, kiujn celojn la tunelo devus porti, kaj kiel la reto sendas respondojn reen. Ligila loka adreso respondas neniun el ili, kaj akceptita anonco respondas nur parton de unu. Kontrolu ĉiun eron aparte anstataŭ akcepti verdan indikilon. Poste notu, kiu mekanismo liveris ĉiun respondon, ĉar tiu registro transformas la sekvan IPv6-raporton en duminutan kontrolon.
Konservu la registron kun la serva dokumentaro kaj ĝisdatigu ĝin, kiam la kliento ŝanĝiĝas. Plano, kiu estis ĝusta por PPP-kliento, povas esti malĝusta por paket-tunela kliento en la sama servo. La kvar demandoj restas la samaj; nur la respondoj moviĝas.