IPv6CP എന്താണ് ചർച്ച ചെയ്യുന്നത്, എന്തിനാണ് ഇപ്പോഴും പ്രിഫിക്സ് വേണ്ടത്
PPP ഇന്റർഫേസിലെ ലിങ്ക്-ലോക്കൽ വിലാസം ഒരു സെറ്റപ്പ് ഘട്ടമാണ്, IPv6 ആക്സസ് അല്ല. ഐഡന്റിഫയർ കൈമാറ്റത്തെ പ്രിഫിക്സുകൾ, റൂട്ടുകൾ, ക്ലയന്റ് ഇന്റഗ്രേഷൻ എന്നിവയിൽ നിന്ന് വേർതിരിക്കുക.
PPP ഇന്റർഫേസിൽ IPv6 ഉയരുന്നു, ഒരു ലിങ്ക്-ലോക്കൽ വിലാസം പ്രത്യക്ഷപ്പെടുന്നു, മാറ്റം പൂർത്തിയായതായി പ്രഖ്യാപിക്കുന്നു. പിന്നീട് ഒന്നും റൂട്ട് ചെയ്യപ്പെടുന്നില്ല, ആഗോള വിലാസം ഇല്ല, ഇന്റർഫേസ് ഇപ്പോഴും കോൺഫിഗർ ചെയ്തതായി തോന്നുന്നു, പക്ഷേ പൊതു ലക്ഷ്യസ്ഥാനത്തേക്കുള്ള പരിശോധന പരാജയപ്പെടുന്നു. ലിങ്ക് ഉയർന്നു; നെറ്റ്വർക്ക് ഒരിക്കലും ഉയർന്നില്ല. താഴെയുള്ള നാല് പരിശോധനകൾ ക്രമത്തിൽ ചെയ്യുക, വിടവ് വിശദീകരിക്കുന്നതിൽ നിർത്തുക.
ലിങ്ക്-ലോക്കൽ വിലാസം യഥാർത്ഥത്തിൽ എന്താണ് തെളിയിക്കുന്നത്
IPv6CP PPP ലിങ്കിൽ IPv6 ഉയർത്തുകയും ഓരോ വശത്തിനും ഇന്റർഫേസ് ഐഡന്റിഫയർ ചർച്ച ചെയ്യുകയും ചെയ്യുന്നു. ആ ഐഡന്റിഫയർ ഒരു ലിങ്ക്-ലോക്കൽ വിലാസം ഉണ്ടാക്കുന്നു, അത് ലിങ്കിലൂടെ പങ്കാളിയുമായി സംസാരിക്കാൻ മതിയാകും, മറ്റൊന്നും എത്താൻ മതിയാകില്ല. ലിങ്ക് 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 പ്രോട്ടോക്കോളുകൾ പ്രവർത്തിക്കുന്നതിന് മുമ്പ് നടക്കുന്ന സെറ്റപ്പ് ഘട്ടമായി നിർത്തുന്നു, അതാണ് അതിന്റെ മുഴുവൻ പരിധി: ലിങ്ക് തയ്യാറാക്കുക, നെറ്റ്വർക്ക് അക്കമിടുകയല്ല. പ്രിഫിക്സ് നൽകുക, ഇന്റർഫേസ് വെറുതെ നിലനിൽക്കുന്നതിന് പകരം ട്രാഫിക് വഹിക്കാൻ തുടങ്ങും.
റൂട്ടർ പ്രഖ്യാപനങ്ങൾ ലാൻ-ൽ സാധാരണ ഉത്തരമാണ്, പോയിന്റ്-ടു-പോയിന്റ് ടണലിൽ കുറച്ച് വിശ്വസനീയമല്ല, കാരണം ക്ലയന്റ് അഭ്യർത്ഥനകൾ അയക്കുകയും ഉത്തരം സ്വീകരിക്കുകയും വേണം. ചില ടണൽ ക്ലയന്റുകൾ രണ്ടും ചെയ്യുന്നില്ല. സർവർ അത് അയക്കണമോ എന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് ക്ലയന്റ് എന്ത് സ്വീകരിക്കാൻ തയ്യാറാണെന്ന് പരിശോധിക്കുക.
അതേ പ്രിഫിക്സ് മറ്റേ അറ്റത്തു നിന്നും എത്താവുന്നതായിരിക്കണം. ആഗോള വിലാസമുണ്ടെങ്കിലും തിരിച്ചുവരവ് പാതയില്ലാത്ത ക്ലയന്റ് കോൺഫിഗർ ചെയ്തതാണ്, ബന്ധിപ്പിച്ചതല്ല.
റൂട്ടുകൾ വേറെ ഒരു വാഗ്ദാനമാണ്
വിലാസമുണ്ടെങ്കിലും, ഏത് ലക്ഷ്യസ്ഥാനങ്ങൾ ടണലിന്റേതാണെന്ന് ക്ലയന്റ് അറിയണം, സർവറിന് ആ ലക്ഷ്യസ്ഥാനങ്ങൾക്ക് തിരിച്ചുവരവ് പാത വേണം. ഇവ രണ്ട് സ്ഥലങ്ങളിൽ എടുക്കുന്ന രണ്ട് തീരുമാനങ്ങളാണ്. എല്ലാ IPv6 ട്രാഫിക്കും വഹിക്കുന്ന ടണലിന് ക്ലയന്റിൽ ഡിഫോൾട്ട് റൂട്ടും സർവറിൽ തിരിച്ചുവരവ് റൂട്ടും വേണം; വിഭജിത ടണലിന് ഇരുവശവും ഒരേ പ്രിഫിക്സ് പട്ടികയിൽ യോജിക്കണം. യോജിക്കുന്നില്ലെങ്കിൽ ട്രാഫിക് പുറത്തുപോകുന്നു, ഒരിക്കലും തിരിച്ചുവരുന്നില്ല.
എന്തെങ്കിലും കോൺഫിഗർ ചെയ്യുന്നതിന് മുമ്പ് പട്ടിക എഴുതുക. പ്ലാൻ പറയുന്നത് ടണലിലൂടെ കോർപ്പറേറ്റ് പ്രിഫിക്സ് മാത്രമാണ് പോകുന്നതെങ്കിൽ, ക്ലയന്റിന് ഡിഫോൾട്ട് IPv6 റൂട്ട് ഉണ്ടാകരുത്, സർവർ അത് പ്രഖ്യാപിക്കരുത്.
ബാക്കിയുള്ളത് ക്ലയന്റ് ഇന്റഗ്രേഷൻ തീരുമാനിക്കുന്നു
ചില ടണൽ ക്ലയന്റുകൾ IPv6 വ്യക്തമായി കോൺഫിഗർ ചെയ്യുന്നു. ഉദാഹരണത്തിന്, Apple-ന്റെ Network Extension ടണലിനായി വിലാസം, പ്രിഫിക്സ്, റൂട്ടുകളുടെ കൂട്ടം എന്നിവ എടുക്കുന്നു, അതിനാൽ അതുപയോഗിക്കുന്ന ആപ്ലിക്കേഷൻ Ethernet ശൈലിയിലുള്ള പ്രഖ്യാപനത്തിനായി കാത്തിരിക്കുന്നില്ല. മറ്റുള്ളവർ ലിങ്കിലൂടെ വരുന്ന റൂട്ടർ പ്രഖ്യാപനങ്ങളെ ആശ്രയിക്കുന്നു. രണ്ട് മാതൃകകളും സാധുവാണ്, അവയ്ക്ക് വ്യത്യസ്ത സർവർ പെരുമാറ്റം ആവശ്യമാണ്, അതിനാൽ തെറ്റായത് തിരഞ്ഞെടുത്താൽ ആരും അയക്കാത്ത സന്ദേശത്തിനായി എന്നെന്നും കാത്തിരിക്കുന്ന ക്ലയന്റ് ഉണ്ടാകും. സർവർ മാറ്റുന്നതിന് മുമ്പ് മാതൃക തിരിച്ചറിയുക.
ppp0 പോലുള്ള പഴയ ഇന്റർഫേസ് നാമം ഇന്ന് പ്രവർത്തിക്കുന്ന സ്റ്റാക്കിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. ആധുനിക ക്ലയന്റ് PPP ഇന്റർഫേസിന് പകരം പാക്കറ്റ്-ടണൽ API ഉപയോഗിച്ചേക്കാം, അത് ചരിത്രപരമായ കണക്ഷൻ പോലെ പെരുമാറുന്നു എന്ന് അനുമാനിക്കുന്നതാണ് പ്രവർത്തിക്കുന്ന രൂപകൽപ്പന തകർക്കുന്ന വഴി. ഇന്റർഫേസ് നാമത്തല്ല, ക്ലയന്റ് പതിപ്പും പ്രൊവിഷനിംഗ് രീതിയും ചോദിക്കുക.
ക്ലയന്റിന് വേണ്ട പ്ലാൻ എഴുതുക
പൂർണ്ണ വിവരണം മൂന്ന് കാര്യങ്ങൾ ഉൾക്കൊള്ളുന്നു: ക്ലയന്റിന് ഏത് വിലാസമുണ്ട്, ടണൽ ഏത് ലക്ഷ്യസ്ഥാനങ്ങൾ വഹിക്കണം, നെറ്റ്വർക്ക് ഉത്തരങ്ങൾ എങ്ങനെ തിരികെ അയയ്ക്കുന്നു. ലിങ്ക്-ലോക്കൽ വിലാസം അവയൊന്നിനും ഉത്തരം നൽകുന്നില്ല, സ്വീകരിച്ച പ്രഖ്യാപനം ഒന്നിന്റെ ഒരു ഭാഗത്തിന് മാത്രം ഉത്തരം നൽകുന്നു. പച്ച സൂചകം സ്വീകരിക്കുന്നതിന് പകരം ഓരോ ഇനവും വെവ്വേറെ പരിശോധിക്കുക. തുടർന്ന് ഏത് സംവിധാനം ഓരോ ഉത്തരവും നൽകി എന്ന് രേഖപ്പെടുത്തുക, കാരണം ആ രേഖ അടുത്ത IPv6 റിപ്പോർട്ടിനെ രണ്ട് മിനിറ്റ് പരിശോധനയാക്കി മാറ്റുന്നു.
സേവന രേഖകളോടൊപ്പം രേഖ സൂക്ഷിക്കുക, ക്ലയന്റ് മാറുമ്പോൾ അത് പുതുക്കുക. PPP ക്ലയന്റിന് ശരിയായിരുന്ന പ്ലാൻ അതേ സേവനത്തിലെ പാക്കറ്റ്-ടണൽ ക്ലയന്റിന് തെറ്റായേക്കാം. നാല് ചോദ്യങ്ങൾ അതേപടി തുടരുന്നു; ഉത്തരങ്ങൾ മാത്രം മാറുന്നു.