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 ક્લાયન્ટ માટે સાચી યોજના એ જ સેવા પર પેકેટ-ટનલ ક્લાયન્ટ માટે ખોટી હોઈ શકે છે. ચાર પ્રશ્નો એ જ રહે છે; ફક્ત જવાબો ખસે છે.