IPv6CP چه چیزی را مذاکره می‌کند و چه چیزی هنوز به یک پیشوند نیاز دارد
نشانی link-local روی واسط PPP یک گام راه‌اندازی است، نه دسترسی IPv6. تبادل شناسه‌ها را از پیشوندها، مسیرها و یکپارچه‌سازی کارخواه جدا کنید.
IPv6 روی واسط PPP بالا می‌آید، یک نشانی link-local پدیدار می‌شود و تغییر پایان‌یافته اعلام می‌شود. سپس هیچ چیزی مسیریابی نمی‌شود، نشانی سراسری وجود ندارد و آزمون به مقصدی عمومی شکست می‌خورد در حالی که واسط هنوز پیکربندی‌شده به نظر می‌رسد. پیوند بالا آمد؛ شبکه هرگز. چهار بررسی زیر را به ترتیب انجام دهید و در همان یکی که شکاف را توضیح می‌دهد بایستید.
نشانی link-local در واقع چه چیزی را اثبات می‌کند
IPv6CP پروتکل IPv6 را روی پیوند PPP بالا می‌آورد و برای هر طرف یک شناسهٔ واسط مذاکره می‌کند. آن شناسه یک نشانی 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 روی پیوند اجرا می‌شود، و این تمام دامنهٔ آن است: آماده‌سازی پیوند، نه شماره‌گذاری شبکه. پیشوند را فراهم کنید تا واسط به‌جای صرفاً وجود داشتن، ترافیک حمل کند.
اعلام‌های مسیریاب پاسخ رایج در شبکهٔ محلی و کم‌قابل‌اعتمادتر در تونل نقطه‌به‌نقطه هستند، زیرا کارخواه باید هم درخواست بفرستد و هم پاسخ را بپذیرد. برخی کارخواه‌های تونل هیچ‌یک را انجام نمی‌دهند. پیش از آنکه تصمیم بگیرید کارساز باید آن را بفرستد، بررسی کنید کارخواه چه چیزی را می‌پذیرد.
همان پیشوند باید از سر دیگر هم قابل دسترسی باشد. کارخواهی که نشانی سراسری دارد اما مسیر بازگشت ندارد، پیکربندی شده است، نه متصل.
مسیرها وعده‌ای جداگانه‌اند
حتی با داشتن نشانی، کارخواه باید بداند کدام مقصدها به تونل تعلق دارند و کارساز برای آن مقصدها مسیر بازگشت لازم دارد. این‌ها دو تصمیم هستند که در دو جا گرفته می‌شوند. تونلی که همهٔ ترافیک IPv6 را حمل می‌کند به مسیر پیش‌فرض روی کارخواه و مسیر بازگشت روی کارساز نیاز دارد؛ تونل تفکیک‌شده نیاز دارد دو طرف بر فهرست پیشوند یکسان توافق کنند. وقتی توافق ندارند، ترافیک بیرون می‌رود و هرگز بازنمی‌گردد.
فهرست را پیش از پیکربندی هر چیزی بنویسید. اگر طرح می‌گوید فقط پیشوند شرکتی از تونل می‌گذرد، کارخواه نباید مسیر پیش‌فرض IPv6 داشته باشد و کارساز نباید یکی را اعلام کند.
یکپارچه‌سازی کارخواه بقیه را تعیین می‌کند
برخی کارخواه‌های تونل IPv6 را به‌صورت صریح پیکربندی می‌کنند. برای نمونه Network Extension شرکت Apple نشانی، پیشوند و مجموعه‌ای از مسیرها را برای تونل می‌گیرد، بنابراین برنامه‌ای که از آن استفاده می‌کند منتظر اعلامی به سبک Ethernet نمی‌ماند. دیگران به اعلام‌های مسیریابی که از پیوند می‌رسند تکیه می‌کنند. هر دو الگو مشروع‌اند و رفتار کارساز متفاوتی می‌خواهند، پس انتخاب الگوی نادرست کارخواهی پدید می‌آورد که تا ابد منتظر پیامی می‌ماند که هیچ‌کس نمی‌فرستد. پیش از تغییر کارساز الگو را مشخص کنید.
نام واسط قدیمی مانند ppp0 دربارهٔ پشته‌ای که امروز اجرا می‌شود چیزی اثبات نمی‌کند. کارخواه امروزی می‌تواند به‌جای واسط PPP از API تونل بسته استفاده کند، و این گمان که مانند یک اتصال تاریخی رفتار می‌کند همان راهی است که طراحی سالم را می‌شکند. نسخهٔ کارخواه و روش تأمین را بپرسید، نه نام واسط را.
طرحی را بنویسید که کارخواه نیاز دارد
یک توصیف کامل سه چیز را پوشش می‌دهد: کارخواه کدام نشانی را در اختیار دارد، تونل کدام مقصدها را باید حمل کند، و شبکه پاسخ‌ها را چگونه بازمی‌فرستد. نشانی link-local به هیچ‌یک پاسخ نمی‌دهد و اعلام پذیرفته‌شده تنها به بخشی از یکی پاسخ می‌دهد. هر مورد را جداگانه بررسی کنید به‌جای پذیرفتن نشانگر سبز. سپس ثبت کنید کدام سازوکار هر پاسخ را فراهم کرد، زیرا آن سابقه گزارش بعدی IPv6 را به یک بررسی دو دقیقه‌ای تبدیل می‌کند.
سابقه را همراه مستندات خدمت نگه دارید و آن را هنگام تغییر کارخواه به‌روز کنید. طرحی که برای کارخواه PPP درست بود می‌تواند برای کارخواه تونل بسته در همان خدمت نادرست باشد. چهار پرسش همان می‌مانند؛ تنها پاسخ‌ها جابه‌جا می‌شوند.