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 வாடிக்கையாளருக்குச் சரியாக இருந்த திட்டம் அதே சேவையில் பாக்கெட்-சுரங்கப்பாதை வாடிக்கையாளருக்குத் தவறாக இருக்கலாம். நான்கு கேள்விகள் அப்படியே இருக்கும்; பதில்கள் மட்டுமே நகர்கின்றன.