IPv6CP neyi müzakere eder ve ne hâlâ bir önek gerektirir
PPP arayüzündeki link-local adres bir kurulum adımıdır, IPv6 erişimi değildir. Tanımlayıcı alışverişini öneklerden, rotalardan ve istemci entegrasyonundan ayırın.
IPv6 PPP arayüzünde ayağa kalkar, bir link-local adres görünür ve değişiklik tamamlandı ilan edilir. Sonra hiçbir şey yönlendirilmez, genel bir adres yoktur ve arayüz hâlâ yapılandırılmış görünürken genel bir hedefe yapılan test başarısız olur. Bağlantı ayağa kalktı; ağ hiç kalkmadı. Aşağıdaki dört kontrolü sırayla yapın ve farkı açıklayan kontrolde durun.
Link-local adres gerçekte neyi kanıtlar
IPv6CP, PPP bağlantısında IPv6'yı ayağa kaldırır ve her taraf için bir arayüz tanımlayıcısı müzakere eder. Bu tanımlayıcı bir link-local adres üretir; bu adres bağlantı üzerinden eşle konuşmaya yeter ve başka herhangi bir şeye ulaşmaya yetmez. Adres, bağlantının IPv6 için hazır olduğunu kanıtlar ve eşin arkasındaki ağ hakkında hiçbir şey kanıtlamaz. Onu erişim adresi olarak okumak, bu incelemelerin çoğunun başladığı hatadır.
Aşağıdaki dört soru, bağlantı katmanının neyi belirlediğini hizmetin neyi sağlaması gerektiğinden ayırır. Sırayla yanıtlayın, çünkü önceki soru açıkken sonraki soru yanıtlanamaz.
| 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 |
Önek nereden gelmeli
Genel bir adres bir yerden önek gerektirir: yönlendirici duyurusu, devredilmiş önek, DHCPv6 veya statik yapılandırma. IPv6CP hiçbirini taşımaz ve bağlantıda ne kadar beklenirse beklensin oluşmaz. RFC 5072 IPv6CP'yi diğer IPv6 protokolleri bağlantıda çalışmadan önce çalışan kurulum adımı olarak konumlandırır ve bütün kapsamı budur: bağlantıyı hazırlamak, ağı numaralandırmak değil. Öneği sağlayın ve arayüz yalnızca var olmak yerine trafik taşımaya başlar.
Yönlendirici duyuruları bir LAN'da olağan yanıttır ve noktadan noktaya bir tünelde daha az güvenilirdir, çünkü istemci hem istek göndermeli hem de yanıtı kabul etmelidir. Bazı tünel istemcileri ikisini de yapmaz. Sunucunun bunu göndermesi gerektiğine karar vermeden önce istemcinin neyi kabul etmeye hazır olduğunu kontrol edin.
Aynı önek diğer uçtan da erişilebilir olmalıdır. Genel adresi olan ama dönüş yolu olmayan bir istemci yapılandırılmıştır, bağlı değildir.
Rotalar ayrı bir vaattir
Bir adres olsa bile istemci hangi hedeflerin tünele ait olduğunu bilmelidir ve sunucunun bu hedefler için dönüş yoluna ihtiyacı vardır. Bunlar iki yerde verilen iki karardır. Tüm IPv6 trafiğini taşıyan bir tünel, istemcide varsayılan rota ve sunucuda dönüş rotası gerektirir; bölünmüş tünel ise iki tarafın aynı önek listesinde anlaşmasını gerektirir. Anlaşamadıklarında trafik çıkar ve bir daha dönmez.
Herhangi bir şeyi yapılandırmadan önce listeyi yazın. Plan yalnızca kurumsal öneğin tünelden geçtiğini söylüyorsa, istemcide varsayılan bir IPv6 rotası olmamalı ve sunucu bunu duyurmamalıdır.
Geri kalanı istemci entegrasyonu belirler
Bazı tünel istemcileri IPv6'yı açıkça yapılandırır. Örneğin Apple'ın Network Extension'ı tünel için bir adres, bir önek ve bir dizi rota alır, böylece onu kullanan bir uygulama Ethernet tarzı bir duyuru beklemez. Diğerleri bağlantı üzerinden gelen yönlendirici duyurularına güvenir. İki model de meşrudur ve farklı sunucu davranışı gerektirir, bu yüzden yanlış olanı seçmek, kimsenin göndermediği bir mesajı sonsuza kadar bekleyen bir istemci üretir. Sunucuyu değiştirmeden önce modeli belirleyin.
ppp0 gibi eski bir arayüz adı bugün çalışan yığın hakkında hiçbir şey kanıtlamaz. Modern bir istemci PPP arayüzü yerine paket tüneli API'si kullanabilir ve onun tarihsel bir bağlantı gibi davrandığını varsaymak, çalışan bir tasarımı bozmanın yoludur. Arayüz adını değil, istemci sürümünü ve sağlama yöntemini sorun.
İstemcinin ihtiyaç duyduğu planı yazın
Tam bir açıklama üç şeyi kapsar: istemcinin hangi adrese sahip olduğunu, tünelin hangi hedefleri taşıması gerektiğini ve ağın yanıtları nasıl geri gönderdiğini. Link-local adres bunların hiçbirini yanıtlamaz ve kabul edilen bir duyuru yalnızca birinin bir bölümünü yanıtlar. Yeşil bir göstergeyi kabul etmek yerine her maddeyi ayrı ayrı kontrol edin. Sonra her yanıtı hangi mekanizmanın sağladığını kaydedin, çünkü bu kayıt bir sonraki IPv6 raporunu iki dakikalık bir kontrole dönüştürür.
Kaydı hizmet belgeleriyle birlikte tutun ve istemci değiştiğinde güncelleyin. Bir PPP istemcisi için doğru olan bir plan, aynı hizmetteki bir paket tüneli istemcisi için yanlış olabilir. Dört soru aynı kalır; yalnızca yanıtlar yer değiştirir.