Mitä IPv6CP neuvottelee ja mikä tarvitsee yhä etuliitteen
PPP-liittymän link-local-osoite on asennusvaihe, ei IPv6-yhteys. Erottele tunnisteiden vaihto etuliitteistä, reiteistä ja asiakasintegraatiosta.
IPv6 nousee PPP-liittymälle, link-local-osoite ilmestyy ja muutos julistetaan valmiiksi. Sitten mitään ei reititetä, yleistä osoitetta ei ole, ja testi julkiseen kohteeseen epäonnistuu, vaikka liittymä näyttää yhä määritetyltä. Linkki nousi; verkko ei koskaan. Käy alla olevat neljä tarkistusta järjestyksessä läpi ja pysähdy siihen, joka selittää puutteen.
Mitä link-local-osoite todella todistaa
IPv6CP nostaa IPv6:n PPP-linkille ja neuvottelee kummallekin puolelle liittymätunnisteen. Tämä tunniste tuottaa link-local-osoitteen, joka riittää puhumiseen vastapuolen kanssa linkin yli eikä riitä mihinkään muuhun. Osoite todistaa, että linkki on valmis IPv6:lle, eikä todista mitään vastapuolen takana olevasta verkosta. Sen lukeminen käyttöosoitteena on virhe, josta useimmat näistä tutkimuksista alkavat.
Alla olevat neljä kysymystä erottavat sen, mitä linkkikerros ratkaisee, siitä, mitä palvelun on tarjottava. Vastaa niihin järjestyksessä, sillä myöhempään kysymykseen ei voi vastata, kun aikaisempi on vielä avoin.
| 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 |
Mistä etuliite on tultava
Yleinen osoite tarvitsee etuliitteen jostakin: reitittimen ilmoitus, delegoitu etuliite, DHCPv6 tai staattinen määritys. IPv6CP ei kanna sitä, eikä mikään linkillä odottaminen tuota sitä. RFC 5072 sijoittaa IPv6CP:n asennusvaiheeksi, joka käy ennen kuin muut IPv6-protokollat toimivat linkillä, ja se on koko sen laajuus: linkin valmistelu, ei verkon numeroiminen. Toimita etuliite, ja liittymä alkaa kantaa liikennettä sen sijaan, että se vain olisi olemassa.
Reitittimen ilmoitukset ovat tavallinen vastaus lähiverkossa ja vähemmän luotettava pisteestä pisteeseen -tunnelissa, koska asiakkaan on sekä lähetettävä pyyntöjä että hyväksyttävä vastaus. Jotkin tunneliasiakkaat eivät tee kumpaakaan. Tarkista, mitä asiakas on valmis hyväksymään, ennen kuin päätät, että palvelimen pitäisi lähettää se.
Saman etuliitteen on oltava saavutettavissa myös toisesta päästä. Asiakas, jolla on yleinen osoite mutta ei paluureittiä, on määritetty, ei yhdistetty.
Reitit ovat erillinen lupaus
Jo osoitteen kanssa asiakkaan on tiedettävä, mitkä kohteet kuuluvat tunneliin, ja palvelin tarvitsee paluureitin noihin kohteisiin. Ne ovat kaksi päätöstä kahdessa paikassa. Tunneli, joka kantaa kaiken IPv6-liikenteen, tarvitsee oletusreitin asiakkaalla ja paluureitin palvelimella; jaettu tunneli edellyttää, että molemmat osapuolet sopivat samasta etuliiteluettelosta. Kun ne eivät sovi, liikenne lähtee eikä palaa koskaan.
Kirjoita luettelo ennen kuin määrität mitään. Jos suunnitelma sanoo, että vain yrityksen etuliite kulkee tunnelin kautta, asiakkaalla ei pitäisi olla oletus-IPv6-reittiä, eikä palvelimen pitäisi ilmoittaa sellaista.
Asiakasintegraatio ratkaisee loput
Jotkin tunneliasiakkaat määrittävät IPv6:n eksplisiittisesti. Esimerkiksi Applen Network Extension ottaa tunnelille osoitteen, etuliitteen ja joukon reittejä, joten sitä käyttävä sovellus ei odota Ethernet-tyylistä ilmoitusta. Toiset luottavat linkin yli saapuviin reitittimen ilmoituksiin. Molemmat mallit ovat päteviä ja vaativat erilaista palvelinkäyttäytymistä, joten väärän valinta tuottaa asiakkaan, joka odottaa ikuisesti viestiä, jota kukaan ei lähetä. Tunnista malli ennen palvelimen muuttamista.
Vanha liittymän nimi, kuten ppp0, ei todista mitään tänään käyvästä pinosta. Nykyinen asiakas voi käyttää pakettitunnelin API:a PPP-liittymän sijaan, ja olettamus, että se käyttäytyy kuin historiallinen yhteys, on tapa rikkoa toimiva suunnittelu. Kysy asiakkaan versio ja toimitusmenetelmä, älä liittymän nimeä.
Kirjoita suunnitelma, jonka asiakas tarvitsee
Täydellinen kuvaus kattaa kolme asiaa: mikä osoite asiakkaalla on, mitkä kohteet tunnelin pitäisi kantaa ja miten verkko lähettää vastaukset takaisin. Link-local-osoite ei vastaa niistä yhteenkään, ja hyväksytty ilmoitus vastaa vain osaan yhdestä. Tarkista jokainen kohta erikseen sen sijaan, että hyväksyt vihreän ilmaisimen. Kirjaa sitten, mikä mekanismi tuotti kunkin vastauksen, sillä se kirjaus muuttaa seuraavan IPv6-raportin kahden minuutin tarkistukseksi.
Pidä kirjaus palvelun dokumentaation kanssa ja päivitä se, kun asiakas muuttuu. Suunnitelma, joka oli oikein PPP-asiakkaalle, voi olla väärä pakettitunnelin asiakkaalle samassa palvelussa. Neljä kysymystä pysyvät samoina; vain vastaukset liikkuvat.