IPv6CP ఏమి చర్చిస్తుంది మరియు ఇంకా ఏమి ప్రిఫిక్స్ అవసరం
PPP ఇంటర్ఫేస్‌పై link-local చిరునామా అనేది సెటప్ దశ, IPv6 యాక్సెస్ కాదు. గుర్తింపుల మార్పిడిని ప్రిఫిక్స్‌లు, మార్గాలు మరియు క్లయింట్ ఇంటిగ్రేషన్ నుండి వేరు చేయండి.
PPP ఇంటర్ఫేస్‌పై IPv6 పైకి వస్తుంది, link-local చిరునామా కనిపిస్తుంది, మార్పు పూర్తయినట్లు ప్రకటించబడుతుంది. ఆ తర్వాత ఏదీ రూట్ చేయబడదు, ప్రపంచ చిరునామా లేదు, ఇంటర్ఫేస్ ఇంకా కాన్ఫిగర్ చేయబడినట్లు కనిపిస్తూనే పబ్లిక్ గమ్యానికి పరీక్ష విఫలమవుతుంది. లింక్ పైకి వచ్చింది; నెట్‌వర్క్ ఎప్పుడూ రాలేదు. క్రింది నాలుగు తనిఖీలను క్రమంగా చేయండి మరియు ఖాళీని వివరించే దానిపై ఆగండి.
link-local చిరునామా నిజంగా ఏమి నిరూపిస్తుంది
IPv6CP PPP లింక్‌పై IPv6 ను పైకి లేపుతుంది మరియు ప్రతి వైపు ఇంటర్ఫేస్ ఐడెంటిఫైయర్‌ను చర్చిస్తుంది. ఆ ఐడెంటిఫైయర్ link-local చిరునామాను ఉత్పత్తి చేస్తుంది, అది లింక్ ద్వారా భాగస్వామితో మాట్లాడటానికి సరిపోతుంది మరియు మరేదైనా చేరుకోవడానికి సరిపోదు. చిరునామా లింక్ IPv6 కి సిద్ధంగా ఉందని నిరూపిస్తుంది, భాగస్వామి వెనుక ఉన్న నెట్‌వర్క్ గురించి ఏమీ నిరూపించదు. దీన్ని యాక్సెస్ చిరునామాగా చదవడమే ఈ దర్యాప్తులలో చాలా వరకు ప్రారంభమయ్యే పొరపాటు.
క్రింది నాలుగు ప్రశ్నలు లింక్ పొర నిర్ణయించేది మరియు సేవ అందించవలసినది వేరు చేస్తాయి. వాటికి క్రమంగా సమాధానం ఇవ్వండి, ఎందుకంటే మునుపటి ప్రశ్న తెరిచి ఉన్నంత కాలం తర్వాతి ప్రశ్నకు సమాధానం చెప్పలేము.
| 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 |
ప్రిఫిక్స్ ఎక్కడ నుండి రావాలి
ప్రపంచ చిరునామాకు ఎక్కడి నుండో ప్రిఫిక్స్ అవసరం: రౌటర్ ప్రకటన, అప్పగించిన ప్రిఫిక్స్, DHCPv6 లేదా స్థిర కాన్ఫిగరేషన్. IPv6CP ఏదీ మోయదు, లింక్‌పై ఎంత వేచినా అది ఉత్పత్తి కాదు. RFC 5072 IPv6CP ను లింక్‌పై ఇతర IPv6 ప్రోటోకాల్‌లు పనిచేయడానికి ముందు నడిచే సెటప్ దశగా ఉంచుతుంది, మరియు అదే దాని పూర్తి పరిధి: లింక్‌ను సిద్ధం చేయడం, నెట్‌వర్క్‌ను సంఖ్యలు వేయడం కాదు. ప్రిఫిక్స్ ఇవ్వండి, ఇంటర్ఫేస్ కేవలం ఉనికిలో ఉండటం బదులు ట్రాఫిక్‌ను మోయడం ప్రారంభిస్తుంది.
రౌటర్ ప్రకటనలు LAN లో సాధారణ సమాధానం మరియు పాయింట్-టు-పాయింట్ టన్నెల్‌లో తక్కువ నమ్మదగినవి, ఎందుకంటే క్లయింట్ అభ్యర్థనలు పంపాలి మరియు సమాధానాన్ని అంగీకరించాలి. కొన్ని టన్నెల్ క్లయింట్‌లు రెండూ చేయవు. సర్వర్ దాన్ని పంపాలా వద్దా అని నిర్ణయించే ముందు క్లయింట్ ఏమి అంగీకరించడానికి సిద్ధంగా ఉందో తనిఖీ చేయండి.
అదే ప్రిఫిక్స్ మరో చివర నుండి కూడా చేరుకోగలిగి ఉండాలి. ప్రపంచ చిరునామా ఉన్నా తిరిగి వచ్చే మార్గం లేని క్లయింట్ కాన్ఫిగర్ చేయబడింది, కనెక్ట్ కాలేదు.
మార్గాలు వేరే వాగ్దానం
చిరునామా ఉన్నా, ఏ గమ్యాలు టన్నెల్‌కు చెందుతాయో క్లయింట్ తెలుసుకోవాలి, సర్వర్‌కు ఆ గమ్యాలకు తిరిగి వెళ్లే మార్గం అవసరం. ఇవి రెండు చోట్ల తీసుకునే రెండు నిర్ణయాలు. మొత్తం IPv6 ట్రాఫిక్‌ను మోసే టన్నెల్‌కు క్లయింట్‌లో డిఫాల్ట్ మార్గం మరియు సర్వర్‌లో తిరిగి వెళ్లే మార్గం అవసరం; విభజిత టన్నెల్‌కు రెండు వైపులా ఒకే ప్రిఫిక్స్ జాబితాపై అంగీకరించాలి. అవి అంగీకరించకపోతే, ట్రాఫిక్ బయటకు వెళ్లి ఎప్పటికీ తిరిగి రాదు.
ఏదైనా కాన్ఫిగర్ చేయడానికి ముందు జాబితా రాయండి. ప్లాన్ టన్నెల్ ద్వారా కార్పొరేట్ ప్రిఫిక్స్ మాత్రమే వెళ్తుందని చెబితే, క్లయింట్‌కు డిఫాల్ట్ IPv6 మార్గం ఉండకూడదు, సర్వర్ దాన్ని ప్రకటించకూడదు.
మిగిలినది క్లయింట్ ఇంటిగ్రేషన్ నిర్ణయిస్తుంది
కొన్ని టన్నెల్ క్లయింట్‌లు IPv6 ను స్పష్టంగా కాన్ఫిగర్ చేస్తాయి. ఉదాహరణకు, Apple యొక్క Network Extension టన్నెల్ కోసం చిరునామా, ప్రిఫిక్స్ మరియు మార్గాల సమితిని తీసుకుంటుంది, కాబట్టి దాన్ని ఉపయోగించే అప్లికేషన్ Ethernet శైలి ప్రకటన కోసం వేచి ఉండదు. మరికొందరు లింక్ ద్వారా వచ్చే రౌటర్ ప్రకటనలపై ఆధారపడతారు. రెండు నమూనాలు చెల్లుబాటు అవుతాయి మరియు వాటికి భిన్న సర్వర్ ప్రవర్తన అవసరం, కాబట్టి తప్పుది ఎంచుకుంటే ఎవరూ పంపని సందేశం కోసం ఎప్పటికీ వేచి ఉండే క్లయింట్ ఏర్పడుతుంది. సర్వర్ మార్చడానికి ముందు నమూనాను గుర్తించండి.
ppp0 వంటి పాత ఇంటర్ఫేస్ పేరు ఈరోజు నడుస్తున్న స్టాక్ గురించి ఏమీ నిరూపించదు. ఆధునిక క్లయింట్ PPP ఇంటర్ఫేస్‌కు బదులు ప్యాకెట్-టన్నెల్ API ఉపయోగించవచ్చు, మరియు అది చారిత్రక కనెక్షన్ లాగా ప్రవర్తిస్తుందని భావించడమే పనిచేస్తున్న డిజైన్‌ను విచ్ఛిన్నం చేసే మార్గం. ఇంటర్ఫేస్ పేరు కాదు, క్లయింట్ వెర్షన్ మరియు ప్రొవిజనింగ్ పద్ధతిని అడగండి.
క్లయింట్‌కు అవసరమైన ప్లాన్ రాయండి
పూర్తి వివరణ మూడు విషయాలను కవర్ చేస్తుంది: క్లయింట్ ఏ చిరునామా కలిగి ఉంది, టన్నెల్ ఏ గమ్యాలను మోయాలి, మరియు నెట్‌వర్క్ సమాధానాలను ఎలా తిరిగి పంపుతుంది. link-local చిరునామా వాటిలో దేనికీ సమాధానం ఇవ్వదు, ఆమోదించిన ప్రకటన ఒకదానిలోని ఒక భాగానికి మాత్రమే సమాధానం ఇస్తుంది. ఆకుపచ్చ సూచికను అంగీకరించడం బదులు ప్రతి అంశాన్ని విడిగా తనిఖీ చేయండి. తర్వాత ఏ యంత్రాంగం ప్రతి సమాధానాన్ని అందించిందో నమోదు చేయండి, ఎందుకంటే ఆ నమోదు తదుపరి IPv6 నివేదికను రెండు నిమిషాల తనిఖీగా మారుస్తుంది.
సేవా పత్రాలతో నమోదును ఉంచండి మరియు క్లయింట్ మారినప్పుడు నవీకరించండి. PPP క్లయింట్‌కు సరైన ప్లాన్ అదే సేవలో ప్యాకెట్-టన్నెల్ క్లయింట్‌కు తప్పు కావచ్చు. నాలుగు ప్రశ్నలు అలాగే ఉంటాయి; సమాధానాలు మాత్రమే కదులుతాయి.