Chapter 8. IPv6 Temelleri

8.1. IPv6/IPSec Yapısı

Yoshinobu Inoue tarafından hazırlanmıştır.

Bu kısım IPv6 ve IPsec benzeri yapıların temellerini açıklamalıdır. Bu fonksiyonellikler KAME projesinden türetilmiştir.

8.1.1. IPv6

8.1.1.1. Uygunluk

IPv6 ile ilgili fonksiyonlar en son IPv6 standartlarına uygundur veya uymaya çalışmaktadır. Gelecek referanslar için bazı ilgili dokümanlarılisteledik. (Not: bu tam bir liste değildir - bu yönetmek için çok zordur...).

Detaylar için bu dokumandaki belirli bölümlere, RFC lere, klavuz sayflarına, veya kaynak koddaki yorumlara bakınız.

Uygunluk testleri TAHI projesinin KAME STABLE kitinde gerçekleştirildi. Sonuçlar http://www.tahi.org/report/KAME/ den görülebilir. Biz ayrıca geçmişte eski snapshotlarımızla New Hampshire Üniversitesi IOL testlerine (http://www.iol.unh.edu/) katıldık.

  • RFC1639: Büyük adres kayıtlarıüzerinde FTP operasyonu (FOOBAR)

    * RFC2428, RFC1639 üzerinde tercih edilir. FTP istemcileri önce RFC2428 denerler, sonra eğer hata alırlarsa RFC1639 u denerler.

    * RFC1886: IPv6 ıdesteklemek için DNS genişlemesi

    * RFC1933: IPv6 hostlarıve yönlendiriciler için geçiş mekanizması

    * IPv4 uyumlu adres desteklenmez.

    * Otomatik tünelleme (bu RFC nin 4.3 üncü kısmında tanımlanmış) desteklenmez.

    * gif(4) arabirimi jenerik bir yolla IPv[46]-over-IPv[46] tüneli yürütür, ve "konfigüre edilmiştünel" i kapsar. Detaylar için bu dokümandaki 23.5.1.5 inci kısma bakın.

    * RFC1981: IPv6 için MTU yolu bildirimi

    * RFC2080: IPv6 için RIPng

    * usr.sbin/route6d bunu destekler.

    * RFC2292: IPv6 için İleri Soket API si

    * Desteklenen kütüphane fonksiyonlarıve kernel API leri için sys/netinet6/ADVAPI ye balın.

    * RFC2362: Protokol Bağımsız Seyrek-Çoklu Yayın Modu (PIM-SM)

    * RFC2362, PIM-SM için paket formatlarınıtanımlar. draft-ietf-pim-ipv6-01.txt bunun üzerine yazılmıştır.

    * RFC2373: IPv6 Adresleme Mimarisi

    * düğüm ihtiyaçlıadresleri destekler, ve scope gerekliliklerine uyar.

    * RFC2374: Bir IPv6 Toplanabilir Global Unicast Adres Formatı

    * 64 bit uzunluğunda Arayüz ID sini destekler.

    * RFC2375: IPv6 Multicast Adres Atamaları

    * Kullanıcıtaraflıuygulamalar RFC de atanmışbilinen adresleri kullanırlar.

    * RFC2428: IPv6 ve NAT lar için FTP Kapsamları

    * RFC2428, RFC1639 üzerine tercih edilir. FTP istemcileri ilk önce RFC2428 i deneyecekler, daha sonra eğer başarısız olurlarsa RFC1639 deneyecekler.

    * RFC2460: IPv6 Ayrıntıları

    * RFC2461: IPv6 için Komşu Keşfetme

    * Detaylar için bu dokümanda 23.5.1.2 inci kısıma bakın.

    * RFC2462: IPv6 Durumsuz Adres Otokonfigürasyonu

    * Detaylar için bu dokümanda 23.5.1.4 üncü kısıma bakın.

    * RFC2463: IPv6 için ICMPv6 Ayrıntıları

    * Detaylar için bu dokümanda 23.5.1.9 uncu kısıma bakın.

    * RFC2464: IPv6 Paketlerinin Eternet Ağlarıüzerinden Taşınması

    * RFC2465: IPv6 için MIB: Yazımsal Klasikler ve Genel Grup

    * Gerekli istatistikler çekirdek tarafından toplanır. Gerçek IPv6 MIB desteği ucd-snmp için yama kiti olarak sağlanmıştır.

    * RFC2466: IPv6 için MIB: ICMPv6 Grubu

    * Gerekli istatistikler çekirdek tarafından toplanır. Gerçek IPv6 MIB desteği ucd-snmp için yama kiti olarak sağlanmıştır.

    * RFC2467: IPv6 Paketlerinin FDDI AğlarıÜzerinden Taşınması* RFC2497: IPv6 Paketlerinin ARCnet AğlarıÜzerinden Taşınması

    * RFC2553: IPv6 için Temel Soket Arayüzü Kapsamı

    * IPv4 haritalıadres (3.7) ve özel IPv6 bind soketi desteklenir.Detaylar için bu dokümanda 23.5.1.12 üncü kısıma bakın.

    * RFC2675: IPv6 Jumbogramları* Detaylar için bu dokümanda 23.5.1.7 üncü kısıma bakın.

    * RFC2710: IPv6 için Multicast Dinleyici Keşfi

    * RFC2711: IPv6 router alarm desteği

    * draft-ietf-ipngwg-router-renum-08: IPv6 için tekrar numaralandırma

    * draft-ietf-ipngwg-icmp-namelookups-02: ICMP üzerinden IPv6 İsim Arama

    * draft-ietf-ipngwg-icmp-name-lookups-03: ICMP üzerinden IPv6 İsim Arama

    * draft-ietf-pim-ipv6-01.txt: IPv6 için PIM

    * pim6dd(8) yoğun modu yürütür. pim6sd(8) seyrek modu yürütür.

    * draft-itojun-ipv6-tcp-to-anycast-00: Herhangi bir yayın adresine olan TCP bağlantısınıkoparma.

    * draft-yamamoto-wideipv6-comm-model-00

    * Detaylar için bu dokümanda 23.5.1.6 ıncıkısıma bakın.

    * draft-ietf-ipngwg-scopedaddr-format-00.txt : IPv6 Adresleri için Kapsamlıbir Format.

8.1.1.2. Komşu Keşfetme

Komşu keşfetme tam olarak sabittir. Güncel Adres Çözümleme, Eş Adres Sezme, ve Komşu Ulaşılamazlık Sezme olayları desteklenmektedir. Yakın gelecekte Komşu Proxy Bildirimi desteğini ve yönetici aracıolarak Davetsiz Komşu Bildirim taşımasını çekirdekte ekleyeceğiz.

Eğer DAD başaramazsa, adres "eşlenmiş(duplicated)" olarak işaretlenecektir ve mesaj syslog da (ve genellikle konsolda da) üretilecektir. "eşlenmiş" işareti ifconfig(8) ile kontrol edilebilir. DAD için kontrol etme ve DAD den kurtarma işlemi yapma yöneticinin sorumluluğudur. Yakın gelecekte durum geliştirilmelidir.

Bazıağ sürücü döngüleri kendilerine çoklu olarak yayarlar, komut böyle yapmamasına rağmen (özellikle promiscious modda).

Bu gibi durumlarda DAD belki başaramayabilir. Çünkü DAD motoru iç yöne doğru NS paketi (aktüel olarak düğümün kendisinden) görür ve onu eşlenme işareti olarak düşünür. Belki sys/netinet6/nd6_nbr.c:nd6_dad_timer() daki "heuristic (anlamaya vesile olan)" olarak işaretlenmiş#if durumuna ince bir çözüm olarak("heuristic" bölümündeki kod parçasının ayrıntılıbir şekilde uydurulmamışolduğunu not edin) bakmak istersin.

Komşu Keşfetme tanımlaması(RFC2461) aşağıdaki durumlarda komşu iz tutmasından bahsetmez:

1. Link-layer adresi olmadan davetsiz RS/NS/NA/redirect paketi alan komşu iz girdisi, düğümü olmadığında

2. Ortamda link-layer adresi olmadan komşu iz tutması olduğunda (IsROuter biti için bir iz girdisine ihtiyaç duyarız)

İlk durum için, IETF ipnwg mail listesindeki tartışmalara dayanarak bir çözüm ürettik. Daha fazla detay için kaynak kodundaki yorumlara bakınız ve 6 Şubat 1999 da başlayan (IPng 7155) mail kuyruğuna bakın.

Bağlantıkararlılığıkuralında IPv6 BSD ağ kodundaki tahminlerden çok farklıdır. Şimdi bağlantıkararlılığıkuralı varsayılan yönlendirici listesi boşken destekleniyor (RFC2461, bölüm 5.2, 2. paragraftaki son cümle - tanımlamanın "host" ve "node" kelimelerini birkaç yerde kullanmadığınınot edin).

Mümkün Dos ataklarınıve sonsuz döngüleri engellemek için, şu anda ND paketinde sadece 10 seçenek kabul edilmiştir. Dolayısıyla eğer RA ya takılmış20 öncül seçeneğin varsa sadece ilk 10 seçenek kabul edilecektir. Eğer bu sana sorun olacaksa, lütfen bunun için FREEBSD-CURRENT mail listesine yazın ve/veya nd6_maxndopt ü sys/netinet6/nd6.c dosyasında modifiye edin. Eğer daha büyük istekler varsa belki değişken için sysctl bir şeyler ayarlarız.

8.1.1.3. Kapsam (Scope) İndeksi

IPv6 kapsamlanmışadresleri kullanır. Dolayısıyla bir IPv6 adresi ile birlikte kapsam indeksi belirtmek çok önemlidir. (link-local adres için arayüz indeksi, veya site-local adresi için site indeksi). Kapsam indeksi olmaksızın, kapsamlanmışIPv6 adresi çekirdek için muğlaktır, ve çekirdek bir paket için dışa bağlı arayüzü algılayamayacaktır.

Sıradan kullanıcıdüzeyli uygulamalar kapsam indeksini veya arayüz indeksini belirtmek için ileri API(RFC2292) yi kullanmalıdırlar. Benzer bir amaç için sockaddr_in6 yapısının bir üyesi olan sin6_scope_id RFC2553 te tanımlanmıştır. sin6_scope_id için olan semantik biraz bulanıktır. Eğer uygunamanızın taşınabilirliğini dikkate alıyorsanız sin6_scope_id yerine ileri API yi kullanmanızıtavsiye ederiz.

Çekirdekte link-local kapsamlıadres için bir arayüz indeksi ikinci 16bit kelimeye (3 üncü ve 4 üncü baytlar) IPv6 adresinde gömülmüştür. Örneğin yönlendirme tablosunda ve arayüz adres yapısında şu şekilde bir şey görebilirsin:

fe80:1::200:f8ff:fe01:6317

Yukarıdaki adres ağ arayüz kimlik numarası1 olan bir arayüze ait link-local unicast adrestir. Gömülü indeks az bir kod değişikliği ile çoklu arayüzler üzerinde etkin bir şekilde IPv6 link-local adresleri belirlememizi sağlar.

Yönlendirme süreçleri, route6d(8) ve ifconfig(8) gibi konfigürasyon programlarıgömülü kapsam indeksini manipüle etme ihtiyacıduyacaklar. Bu programlar yönlendirme soketleri ve ioctl'ler(SIOCGIFADDR_IN6 gibi) ve ikinci 16bit kelimesi dolu olan IPv6 adresleri döndürecek olan çekirdek API lerini kullanırlar. API ler çekirdeğin iç yapısınımanipüle etmek içindir. Bu API leri kullanan programlar çekirdek değişikliklerine hazırlıklı olmalıdırlar.

Kapsamlıadresi komut satırında belirttiğinde gömülü formu kesinlikle yazma (ff02:1::1 veya fe80:2::fedc gibi). Bunun çalışması beklenmez. Her zaman standart formu kullan, arayüzü belirten komut satırıseçeneği ile birlikte ff02::1 veya fe80::fedc gibi olsun (ping6 -I ne0 ff02::1 gibi). Genel olarak eğer bir komut giden arayüz için bir komut satırıseçeneğine sahip değilse bu komut kapsamlıadresi almak için hazır değildir. Bu belki IPv6 yı destekelemek için daha önceden kullanılan "dişci ofisi" durumuna terstir. İnanıyoruz ki bu tanımlamalar bunun için biraz gelişime ihtiyaç duyarlar.

Bazıkullanıcıdüzeyi araçlar genişletilmiş draft-ietf-ipngwg-scopedaddr-format-00.txt da belirtilen IPv6 sentaksınıdesteklerler. Giden bağlantıyı"fe80::1%ne0" deki gibi giden arayüzün ismini kullanarak belirtebilirsin. Bu yolla link-local kapsamlıadresi daha fazla bela yaşamadan belirtebilirsin.

Programında bu genişlemeyi kullanmak için, getaddrinfo(3) yu ve NI_WITHSCOPEID ile getnameinfo(3) yu kullanman gerekir. Yürütme bir link ve arayüz arasında bire bir ilişkili gibi farzedilir.

8.1.1.4. Tak ve Çalıştır

Durumsuz IPv6 adres otokonfigürasyonunun çoğu çekirdekte yürütülür. Komşu keşfetme fonksiyonlarıçekirdekte bir bütün olarak yürütülürler. bilgisayarlar için Yönlendirici Belirleme (RA) girdisi çekirdekte yürütülür. Uç bilgisayar için Yönlendirici Daveti (RS) çıktısı, yönlendiriciler için RS girdisi, yönlendiriciler için RA çıktısıkullanıcıdüzeyinde yürütülür.

8.1.1.4.1. Link-local ve özel adreslerin atanması

IPv6 link-local adresi IEEE802 adresi (Ethernet MAC adresi) nden oluşturulur. Arayüz aktif olduğunda (IFF_UP) her bir arayüz IPv6 link-local adresi ile otamatik olarak atanır.Ayrıca link-local adresi için direk yönlendirme yönlendirme tablosuna eklenir.

Burada netstat komutunun çıktısışöyledir:

Internet6:

Destination Gateway Flags Netif Expire

fe80:1::%ed0/64 link#1 UC ed0 

fe80:2::%ep0/64 link#2 UC ep0 

IEEE802 adresine sahip olmayan (sahte arayüzler tünel ve ppp gibi) arayüzler bu adresleri mümkün olduğunca Ethernet arayüzleri gibi arayüzlerden ödünç alırlar. Eğer hiç IEEE802 donanımıbağlı değil ise, son çare sahte-rastgele değer olan MD5(bilgisayar adı) link-local adres kaynağıolarak kullanılır. Eğer senin kullanımın için uygun değilse linl-local adresi elle ayarlaman gerekecek.

Eğer bir arayüz IPv6 yıdesteklemiyorsa ( örneğin multicast desteği yoksa), link-local adresi bu arayüze atanamaz. Detaylar için bölüm 2 ye bakınız.

Her bir arayüz davetli multicast adresine ve link-local bütün düğümlerin multicast adreslerine katılırlar (Örneğin: fe80::1:ff01:6317 ve ff02::1, birbirine ait olmak üzere, bağlı olduğu linkte). Link local adresine ek olarak loopback adresi (::1) loopback arayüzüne atanacaktır. Ayrıca ::1/128 ve ff01::/32 otomatik olarak yönlendirme tablosuna eklenirler , ve loopback arayüzü node-local multicast grup ff01::1 e katılırlar.

8.1.1.4.2. Bilgisayarlardaki durumsuz adres otokonfigürasyonu

IPv6 tanıtımında düğümler 2 katagoriye ayrılmışlardır: yönlendiriciler ve bilgisayarlar. Yönlendiriciler diğerlerine adreslenmişpaketleri geçirirler, bilgisayarlar ise paketleri geçiremezler. net.inet6.ip6.forwarding bu düğümün bilgisayar veya yönlendirici olup olmadığınıtanımlar (1 ise yönlendirici, 0 ise bilgisayar).

Bir bilgisayar yönlendiriciden yönlendirme daveti duyarsa, bilgisayar belki durumsuz adres otokonfigürasyonunu yapabilir. Bu net.inet6.ip6.accept_rtadv (1 ise yapılabilir demektir) ile kontrol edilebilir. Otokonfigürasyon ile birlikte alıcıarayüz için (genellikle global adres öneki) ağ adres öneki eklenir. Varsayılan yönlendirme ayrıca konfigüre edilir. Yönlendiriciler periyodik olarak Yönlendirici Bildirim paketleri yollarlar. Bitişik yönlendiriciden RA paketi istemek için bir bilgisayar yönlendirici daveti gönderir. Herhangi bir zamanda RS paketi üretmek için rtsold(8) komutunu kullan. rtsold(8) daemon ıayrıca mevcuttur. rtsold(8) ne zaman gerekirse yönlendirici daveti oluşturur, ve her türlü kullanım için çalışır (dizüstü bilgisayarlar). Eğer biri Yönlendirici Bildirimini yoksaymak isterse, net.inet6.ip6.accept_rtadv i 0 yapmak için sysctl yi kullansın.

Bir yönlendiricide yönlendirici bildirimi oluşturmak için rtadvd(8) daemon ınıkullanın.

IPv6 tanıtımının aşağıdaki maddeleri farzettiğini not edin, ve uyumsuz durumlar belirsiz bırakılmıştır:

* Sadece bilgisayarlar yönlendirici bildirimlerini dinleyecekler

* Loopback hariç tek ağ kartına sahip bilgisayarlar

Bundan dolayı, net.inet6.ip6.accept_rtadv ı yönlendiricilerde veya çok arayüzlü bilgisayarlarda aktif hale getirmek mantıksızdır. Konfigüre edilmemişdüğüm değişik davranabilir.

Sysctl olayınıözetlersek:

BURADA TABLO İLE İLGİLİBİR PROBLEM VAR!!!!!!!!!

accept_rtadv forward etme düğümün rolü --- --- --- 0 0 bilgisayar (manuel olarak konfigüre edilecek) 0 1 yönlendirici 1 0 otokonfigüre bilgisayar (tanıtım bilgisayarın sadece tek bir arayüzü olduğunu fazeder, çoklu olanlar kapsam dışıdır) 1 1 geçersiz, veya deneyimli (tanıtımın kapsamıdışında)

  
  

  
  

RFC2462 gelen RA önek bilgisi seçeneğine karşıonaylama kuralına sahiptir. Bu bilgisayarlarıkötü niyetli (veya konfigüre olmayan) çok kısa yaşam süresinde bildirim yapan yönlendiricilere karşıkorumaktır. ipngw mail listesine ("(ipng 6712)" ye arşivden bakın) Jim Bound tarafından yapılan bir güncelleme vardıve o Jim in güncellemesi ile yürütülür.

DAD ve otokonfigürasyon arasındaki ilişki için bu dokümandaki 23.5.1.2 bölüme bakın.

8.1.1.5. Jenerik Tünel Arayüzü

GIF (Jenerik arayüz) konfigürasyonu yapılmıştüneller için sözde bir arayüzdür. gif(4) te detaylar tanımlanmıştır. Güncel olarak

* v6 in v6

* v6 in v4

* v4 in v6

* v4 in v4 mevcuttur. Gif arayüzlerine fiziksel (dış) kaynak ve hedef adresleri atamak için gifconfig(8) i kullanabilirsiniz. İç ve dışIP başlığı(v4 in v4, veya v6 in v6) için aynıadres ailesini kullanan konfigürasyonlar tehlikelidir. Sınırsız sayıda tüneller uygulamak için arayüzleri ve yönlendirme tablolarınıkonfigüre etmek çok kolaydır. Lütfen dikkatli olun. gif ECN dostu olacak şekilde yapılandırılabilir. Tünellerin ECN dostluğu için 23.5.4.5 inci bölüme ve nasıl yapılandırılacağıiçin de gif(4) e bakın.

Eğer bir IPv4-in-IPv6 tipi tüneli gif arayüzü ile yapılandırmak istiyorsanız, gif(4) ü dikkatlice okuyunuz. Otomatik olarak gif arayüzüne atanmışolan link-local IPv6 adresini kaldırmanız gerekecek.

8.1.1.6. Kaynak Adres Seçimi

Güncel kaynal seçim kuralıkapsama dayalıdır (Bazıistisnalar vardır, aşağıya göz atın). Verilmişbir hedef için IPv6 adresi takip eden kurallara göre seçilir:

  1. Eğer kaynak adresi kesin olarak kullanıcıtarafından belirtilmişse (örneğin ileri API yoluyla), belirtilmişadres kullanılır.

  2. Eğer hedef adresi ile aynıkapsama sahip bir adres giden arayüze (genellikle yönlendirme tablosuna bakılarak bulunur) atanmışsa kullanılır. Bu en çok karşılaşılan durumdur.

  3. Eğer yukarıdaki durumu karşılayan bir adres yoksa gönderme düğümünde olan arayüzlerden birine atanmışglobal adresi seçin.

  4. . Eğer yukarıdaki durumu karşılayan bir adres yoksa ve hedef adres yerel kapsamlıise gönderme düğümünde olan arayüzlerden birine atanmışyerel bir adres seçin.

  5. . Eğer yukarıdaki durumu karşılayan bir adres yoksa hedef için yönlendirme tablosundaki girdilerden ilgili olan adresi seçin. Bu kapsam ihlaline sebep olabilecek bir çaredir.

    Örneğin, ::1, ff01::1 için seçilir. fe80:1::200:f8ff:fe01:6317, fe80:1::2a0:24ff:feab:839b için seçilir (gömülü arayüz indeksinin , 23.5.1.3 te tanıtılmıştır, doğru kaynak adresini seçmemize yaradığınıhatırlayın. Bu gömülü indisler iletken telde olmayacalar). Eğer giden arayüz kapsam için çoklu adrese sahipse, en uzun eşleşmeye göre bir kaynak seçilir. 2001:0DB8:808:1:200:f8ff:fe01:6317 ve 2001:0DB8:9:124:200:f8ff:fe01:6317 nin giden arayüze verildiğini düşünün. 2001:0DB8:808:1:200:f8ff:fe01:6317, 2001:0DB8:800::1 hedefi için kaynak olarak seçilmiştir. Yukarıdaki kuralın IPv6 dokümantasyonunda bulunmadığınınot edin. "Yürütmeye kadar" olan parça olarak düşünülür.

    Yukarıdaki kurala uymadığımız bazıdurumlar vardır. Biri bağlanmışTCP oturumlarıdır, ve biz tcb deki saklıadresi kaynak olarak kullanırız. Diğer örnek de komşu bildirimi için kaynak adresidir. Dokumantasyona bağlıolarak (RFC2461 7.2.2) NA nın kaynağıuygun NS nin hedefinin hedef adresi olmalıdır. Bu durumda en uzun eşleşme kuralıyerine dokumantasyona uyarız.

    Yeni bağlantılar için (kural 1 uygulanmadığızaman) düşük adresler (tercih edilmişyaşam süreleri 0 olan adresler) eğer başka seçenekler varsa kaynak adres olarak seçilmezler. Eğer başka seçenek yoksa düşük adres son çare olarak kullanılır. Eğer düşük adreslerden birden fazla seçenek varsa yukarıdaki kapsan kuralıbu düşük adreslerden birini seçmek için kullanılır. Eğer bazınedenlerden dolayıdüşük adres kullanımınıengellemek istiyorsan net.inet6.ip6.use_deprecated i 0 olarak yapılandır. Düşük adresle ilgili bilgiler RFC2462 5.5.4 de tanımlanmıştır. (Not: IETF ipngwg de düşük adreslerin nasıl kullanılacağına dair tartışmalar vardır).

8.1.1.7. Jumbo Yükleme

Jumbo yükleme seçeneği 65536 oktetten büyük IPv6 paketlerini yollamak için kullanılabilir. Ama MTU su 65536 dan büyük bür fiziksel arayüz yoktur ve dolayısıyla bu şekildeki yüklemeler sadece loopback arayüzünde görülebilir (Örneğin lo0).

Eğer jumbo yüklemeleri denemek istiyorsan, önce çekirdeği tekrar yapılandırmalısın ki loopback arayüzünün MTU su 65536 dan büyük olsun;aşağıdakileri kernel konfigürasyon dosyasına ekleyin:

options "LARGE_LOMTU" #To test jumbo
          payload

ve çekirdeği yeniden derleyin.

Sonra jumbo yüklemelerini -b ve -s parametreleri ile birlikte ping6(8) komutu ile test edebilirsiniz. -b soket tamponunu genişletmek için kullanılmalıdır, ve -s seçeneği de 65536 dan büyük olmasıgereken paketin boyutunu belirler. Örneğin aşağıdaki komutu çalıştırın:

 % ping6 -b 70000 -s 68000 ::1

IPv6 beyannamesi jumbo yüklemesinin parçalıbaşlıklar taşıyan paketlerde kullanılmamasınıgerektirmektedir. Eğer bu durum aşılırsa bir ICMPv6 Parametre Problemi mesajıgöndericiye gönderilmelidir. beyanname böyle der, ama genelde böyle bir mesaj görmezsin.

Bir IPv6 paketi alındığında parça uzunluğu kontrol edilir ve IPv6 başlığındaki yükleme uzunluğu alanındaki değerle veya varsa Jumbo Yükleme seçeneği değeri ile karşılaştırılır. Eğer birincisi ikincisinden kısa ise paket reddedilir ve istatistikler arttırılır. İstatistikleri netstat(8) komut çıktısıolarak "-s -p ip6" seçeneği ile görebilirsin:

 % netstat -s -p ip6 

ip6: 

(snip) 

1 with data size <data length 

Dolayısıyla çekirdek şüpheli bir paket gerçek jumbo yüklemesinde yani 65535 baytın üzerinde olmadığısürece ICMPv6 hatasıgöndermez. Yukarıda tasvir edildiği gibi, güncel olarak böylesine büyük bir MTU ya sahip fiziksel arayüz yoktur, dolayısıyla çok nadir olarak ICMPv6 hatasıdöndürür.

Şu anda TCP/IP üzerinden jumbogram desteği yoktur. Çünkü loopback arayüzünden başka test edeceğimiz ortam yoktur. Buna ihtiyacınız varsa bizimle irtibata geçin.

IPsec jumbogramlar üzerinde çalışmaz. Bu jumbogram ile AH desteği için olan bayannamedeki ikilemlerden dolayıdır(AH başlık büyüklüğü yükleme uzunluğunu etkiler ve bu AH olduğu sürece gelen paketlerin doğruluk sınamasını(authentication) zorlaştırır).

Jumbogramların BSD desteği için önemli meseleler vardır. Bunlarıadresleyeceğiz, fakat bitirmek için biraz zamana ihtiyacımız var. Birkaçınıverecek olursak:

  • mbuf pkthdr.len alanı4.4BSD de int tipindedir, dolayısıyla 32 bit mimarisindeki CPU larda 2G boyutundan büyük jumbogramlarıtutmayacaktır. Bir şekilde jumbogramları desteklemek istiyorsak, alan 4G + IPv6 başlığı+ link-layer başlığıuzunluğunu tutacak şekilde genişletilmelidir. Dolayısıyla en az int64_t (u_int32_t yeterli değildir) tipinde olmalıdır.

  • Biz hatalıolarak IPv6 başlığının ip6_plen alanınıpaket yükleme uzunluğu için değişik yerlerde kontrol ediyoruz. Bunun yerinde mbuf pkthdr.len i kontrol etmeliyiz. ip6_input() jumbo yükleme seçeneği üzerine akıllılık testi uygulayacak ve sonrasında güvenli bir şekilde mbuf pkthdr.len i kullanabileceğiz.

  • Bir grup yerde TCP kodu dikkatli güncelleme gerektirmektedir.

8.1.1.8. Başlık işlemede döngü engelleme

IPv6 beyannamesi paketlere yerleştirmek üzere keyfi sayıda genişletilmişbaşlıklara izin verir. Eğer IPv6 paket işleme kodunu BSD IPv4 kodu gibi yürütürsek, çekirdek yığınıuzun fonksiyon çağrı zincirinden dolayıtaşabilir. sys/netinet6 kodu çekirdek yığın taşmasınıengellemek için dikkatlice tasarlandı. Bundan dolayı, sys/netinet6 kodu kendi anahtar protokol yapısını"struct ip6protosw" olarak tanımlar (netinet6/ip6protosw.h a bakın). Uygunluk için IPv4 tarafında (sys/netinet) benzer güncelleme yapılmadı, ama onun pr_input() prototipine ufak degişiklikler eklendi. Dolayısıyla "struct ipprotosw" ayrıca tanımlandı. Bunun yüzünden eğer büyük sayıda IPsec başlıklarıile IPsec-over-IPv4 paketi alıyorsan çekirdek yığınıbelki taşabilir. IPsec-over-IPv6 de sorun yoktur (Elbette, bunun gibi bütün IPsec başlıklarıIPsec kontrolünü geçmelidir. Dolayısıyla meçhul bir saldırgan böyle bir atak yapamayacaktır).

8.1.1.9. ICMPv6

RFC2463 yayınlandıktan sonra, IETF ipngwg bir ağ aygıtında ICMPv6 fırtınasınıönlemek için ICMPv6 yeniden yollamasına karşı ICMPv6 hata paketini yollamaya etkisiz kıldı. Bu zaten çekirdekte yapılmıştır.

8.1.1.10. Uygulamalar

Kullanıcıdüzeyi programlama için, RFC2553, RFC2292 de belirlenmişIPv6 soket API sini desteklemekteyiz.

IPv6 üzerinden TCP/UDP mevcut ve çok sabittir. Telnet(1), ftp(1), rlogin(1), rsh(1), ssh(1) vb. nin keyfini çıkarabilirsin. Bu uygulamalar protokol bağımsızdır. Yani, bunlar otomatik olarak DNS e göre IPv4 veya IPv6 yıseçerler.

8.1.1.11. Çekirdek Temelleri

ip_forward() ip_output() u çağırdığısürece, ip6_forward() direk olarak if_output() u çağırır, çünkü yönlendiriciler kesinlikle IPv6 paketlerini parçalara bölmemelidirler.

ICMPv6 1280 e kadar orjinal paketi içerirler. UDP6/IP6 port ulaşılamaması, örneğin, bütün uzatılmışbaşlıklarıve değişmemiş UDP6 ve IP6 başlıklarınıiçermelidir. Dolayısıyla TCP hariç bütün IP6 fonksiyonlarıorjinal paketi korumak için hiçbir zaman ağ bayt sırasınıhost bayt sırasına çevirmemelidir.

tcp_input(), udp6_input() ve icmp6_input() genişletilmiş başlıklardan dolayıIP6 başlığının transport başlıklarından önce gidiyor olduğunu hesaplayamaz. Bundan dolayıin6_cksum() IP6 başlığı ve transport başlığıdevamlıolmayan paketleri tutmak için oluşturuldu. TCP/IP6 ya da UDP6/IP6 başlık yapılarıchecksum hesaplamasıiçermezler.

IP6 başlığını, genişletilmişbaşlıklarıve transport başlıklarınıkolaylıkla işlemek için ağ sürücülerinin paketleri bir adet iç mbuf' da veya bir veya daha fazla sayıda dışmbuf' da saklamasıgerekir. Şimdi 96 - 204 bayt arasıveri bir dışmbuf da saklanmasına rağmen tipik eski bir sürücü 2 iç mbuf hazırlardı.

netstat -s -p ip6 sürücünüzün uygunluğunu söyler. Takip eden örnekte, "cce0" gerekliliği çiğner. (Daha fazla bilgi için Bölüm 2 ye bakın.

Mbuf statistics:

317 one mbuf

two or more mbuf::

lo0 = 8

cce0 = 10

3282 one ext mbuf

0 two or more ext mbuf

bir girişfonksiyonu başlangıçta IP6 ile başlığıarasındaki alanın devamlıolduğunu sınamak için IP6_EXTHDR_CHECK i çağırır. IP6_EXTHDR_CHECK sadece paketin loopback arayüzünden geldiğini belirten M_LOOP bayrağımbuf ta varsa m_pullup() ıçağırır. m_pullup() fiziksel ağ arayüzlerinden gelen paketler için kesinlikle çağırılmaz.

Hem IP hem de IP6 tekrar birleştirme (reassemble) fonksiyonlarım_pullup() ıhiç bir zaman çağırmaz.

8.1.1.12. IPv4 haritalıadresleme ve IPv6 joker soketi

RFC2553 IPv4 haritalıadreslemeyi (3.7) ve IPv6 joker bind soketinin (3.8) özel davranışınıtasvir eder. Beyanname sizin;

*AF_INET6 joker bind soketi ile IPv4 bağlantısınıkabul etmenize

* ::ffff:10.1.1.1 gibi özel bir adres formu ile AF_INET6 soketi üzerinden IPv4 paketi yollamanıza

izin verir. Ama beyanname çok karışıktır ve soket tabakasının nasıl davranacağınıbelirtmez. Burada refarans için eski olanı "dinleyici taraf" ve yeni olanı"başlatıcıtaraf" diye çağırıyoruz.

Aynıportta iki adres ailesi için de joker bind ı gerçekleyebilirsin. Aşağıdaki tablo FreeBSD 4.x in davranışını gösterir.

dinleyici taraf başlatıcıtaraf

(AF_INET6 jokeri (::ffff:10.1.1.1 e bağlantı) soket IPv4 bağl. alır)

--- ---

FreeBSD 4.x yapılandırılabilir desteklenir varsayılan: etkin

Takip eden bölüm size daha fazla detay verecek ve davranışı nasıl yapılandırabileceğinizi öğretecektir.

Dinleyici tarafa yönelik yorumlar:

Görünen o ki RFC2553 özellikle port alanıkonusu, hata modu, ve AF_INET/INET6 joker bind' ında olmak üzere joker bind konusundan çok az bahsetmiştir Ona uyan fakat farklıdavranan bu RFC için değişik yorumlar bulunabilir. Dolayısıyla, taşınabilir bir uygulama geliştirmek için çekirdekteki davranışıdikkate almamalısınız. getaddrinfo(3) yu kullanmak en güvenli yoldur. Port numarasıalanı ve joker bind konularu detaylıbir şekilde Mart 1999 da ipv6imp mail listesinde tartışıldıve somut bir konsensüsün olmadığıgörüldü. Mail listesi arşivlerine bakabilirsiniz.

Eğer bir sunucu uygulamasıIPv4 ve IPv6 bağlantılarınıkabul etmek istiyorsa iki alternatif vardır.

Biri AF_INET ve AF_INET6 soketlerini kullanmaktır (iki sokete ihtiyacınız olacak). Bütün adresleri döndürmek için getaddrinfo(3) yu AI_PASSIVE ile birlikte ai_flags içinde, ve socket(2) ve bind(2) ıkullanınız. Birden fazla soket açarak uygun adres ailesine ait bağlantılarıkabul edebilirsiniz. IPv4 bağlantılarıAF_INET soketi ile, IPv6 bağlantılarıAF_INET6 soketi ile kabul edilecektir.

Diğer bir yöntem bir AF_INET6 joker bind soketi kullanmaktır. getaddrinfo(3) yu AI_PASSIVE ile birlikte ai_flags içinde kullanınız, ve ilk argüman "hostname" i NULL olarak atayınız. Ve döndürülen adrese (IPv6 belirlenmemişadres olmalı) socket(2) ve bind(2). Bu tek soket ile IPv4 ve IPv6 paketlerini kabul edebilirsiniz.

Taşınabilir olarak sadece AF_INET6 joker bind soketinden IPv6 trafiğini sağlamak istiyorsanız, her zaman AF_INET6 dinleyici soketine bağlantıhazırlandığında ilgili adresi kontrol ediniz. Eğer adres IPv4 haritalıbir adres ise, bağlantıyıreddedebilirsiniz. Durumu IN6_IS_ADDR_V4MAPPED() makrosu ile kontrol edebilirsiniz.

Bu konuyu daha kolay çözebilmek için, aşağıdaki gibi kullanılan IPV6_BINDV6ONLY isimli bir setsockopt(2) seçeneği vardır.

 int on;

 setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, (char
          *)&on, sizeof (on)) <0));

Bu çağrıbaşarılıolunca, bu soket sadece IPv6 paketlerini alır.

Başlatıcıtarafa yönelik yorumlar:

Uygulama geliştiricilerine uyarılar: taşınabilir bir IPv6 uygulaması(çoklu IPv6 çekirdeklerinde çalışan) geliştirmek için, inanıyoruzki aşağıdakiler başarıya götüren anahtarlardır:

  • Asla AF_INET veya AF_INET6 bağımlıkodlama yapma

  • Sistem üzerinden getaddrinfo(3) ve getnameinfo(3) u kullan. Asla gethostby*(), getaddrby*(), inet_*() veya getipnodeby*() fonksiyonlarınıkullanma. ( Mevcut uygulamaları kolaylıkla IPv6 uyumlu hale getirmek için bazen getipnodeby*() kullanışlıolacaktır. Ama eğer mümkünse, getaddrinfo(3) ve getnameinfo(3) u kullanmak için kodu tekrar yazmayı dene.)

  • Eğer hedefe bağlanmak istiyorsan getaddrinfo(3) ve getnameinfo(3) u kullan ve telnet(1) in yaptığıgibi cevap gelen bütün hedefleri dene.

  • IPv6 yığınının bazıkısımlarıhatalalıgetaddrinfo(3) içerir. Uygulaman ile birlikte minimum çalışan versiyonu kullan ve bunu son çare olarak kullan.

IPv4 ve IPv6 giden bağlantılarıiçin AF_INET6 soketini kullanmak istiyorsan getipnodebyname(3) fonksiyonunu kullanman gerekecek. Mevcut uygulamanızıminimum eforla IPv6 uyumlu hale getirmek istediğinizde bu yaklaşım belki seçilebilir. Ama bilinki bu geçici bir çözümdür, çünkü getipnodebyname(3) fonksiyonunun kendisi kapsamlıIPv6 adreslerini tutamadığından tavsiye edilmez. IPv6 isim çözümlemesi için, getaddrinfo(3) önerilen API dir. Dolayısıyla zamanıgeldiğinde getaddrinfo(3) u kullanmasıiçin uygulamanızı tekrar yazmalısınız.

Dışarıya bağlanan uygulamalar yazarken eğer AF_INET ve AF_INET6 yıayrıadres aileleri olarak işleme alırsanız işler daha basitleşir. {set,get}sockopt, DNS işleri daha kolaylaşır. IPv4 haritalıadreslere güvenmenizi tavsiye etmiyoruz.

8.1.1.12.1. birleşmiştcp ve inpcb kodu

FreeBSD 4.x IPv4 ve IPv6 arasında (sys/netinet/tcp* den) paylaşılan tcp kodunu ve ayrık udp4/6 kodunu kullanır. Birleşmiş inpcb yapısınıkullanır.

Platform IPv4 haritalıadresleri desteklemek üzere yapılandırılabilir. Çekirdek yapılandırmasıaşağıdaki gibi özetlenebilir:

  • Varsayılan olarak AF_INET6 kesin durumlarda IPv4 bağlantılarına el atacaktır, ve IPv4 haritalıIPv6 adresine gömülmüşIPv4 hedefine doğru bağlantıbaşlatabilir.

  • Bunu tüm sistemde aşağıdaki gibi sysctl komutunu kullanarak engelleyebilirsin.

    sysctl net.inet6.ip6.mapped_addr=0

8.1.1.12.1.1. Dinleyici taraf

Her bir soket özel AF_INET6 joker bind soketini (varsayılan olarak aktif) desteklemek için yapılandırılabilir. Bunu her soket üzerinde setsockopt(2) ile aşağıdaki gibi pasif hale getirebilirsiniz.

int on;

setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, (char
              *)&on, sizeof (on)) <0));

Ancak aşağıdaki durumlar sağlanırsa joker AF_INET6 soketi IPv4 bağlantısınıişleyebilir:

  • IPv4 bağlantısına eşlenmişAF_INET soketi yoksa

  • AF_INET6 soketi IPv4 trafiğini kabul etmek üzere yapılandırılmışsa, bu durumda getsockopt(IPV6_BINDV6ONLY) 0 döner.

open/close isteklerinde bir problem yoktur.

8.1.1.12.1.2. BaşlatıcıTaraf

Eğer ağ arayüzü IPv4 haritalıadresleri desteklemek üzere yapılandırılmışise FreeBSD 4.x IPv4 haritalı(::ffff:10.1.1.1) adresine giden bağlantılarıdestekler.

8.1.1.12.1.3. sockaddr_storage

RFC2553 bitirilmek üzereyken sockaddr_storage yapısının elemanlarının nasıl isimlendirileceği üzerinde tartışmalar vardı. Onlara dokunulmamasıiçin bir görüşisimlerin önünde "__" ("__ss_len gibi") olmasınıistiyordu. Diğer bir görüşise onlara direk dokunmamız gerektiğinden dolayı("ss_len" gibi) önünde bir şey olmasınıistemiyordu. Bunun üzerinde açık ortak bir fikir yoktur.

Sonuç olarak RFC2553 sockaddr_storage yapısınıaşağıdaki gibi tanımlar:

 struct sockaddr_storage 

{ 

u_char __ss_len;/* address length */ 

u_char __ss_family;/* address family */
              

/* and bunch of padding */ 

};

Muhalif olarak XNET bunu aşağıdaki gibi tanımlar:

 struct sockaddr_storage { 

u_char ss_len;/* address length */ 

u_char ss_family;/* address family */
              

/* and bunch of padding */ 

};

Aralık 1999 da RFC2553bis 'in ikinci(XNET) tanımlamayı şeçmesi gerektiği üzerinde anlaşmaya varıldı.

Şu anki yürütme RFC2553bis 'e bağlıolarak XNET tanımlamasına uyar.

Eğer çoklu IPv6 yöntemlerine bakarsanız, her iki tanımlamayıda görebilirsiniz. Kullanıcıtabanlıbir programcı olarak bununla başa çıkabilmenin en taşınabilir yolu:

  1. platformlarda ss_family ve/veya ss_len 'in mevcudiyetini GNU autoconf 'u kullanarak garanti etmek

  2. tüm olayları(başlık dosyasıdahil) __ss_family 'nin içinde birleştirmek için -Dss_family=__ss_family 'e sahip olmak, veya

  3. hiç __ss_family 'e dokunmamak. sockaddr * 'e atmak ve sa_family 'i şışekilde kullanmaktır:

    struct sockaddr_storage ss;

    family = ((struct sockaddr
                      *)&ss)->sa_family 

8.1.2. Ağ Sürücüleri

Şimdi aşağıdaki iki madde standart sürücüler tarafından desteklenmek için gereklidir:

  1. mbuf cluster gerekliliği. Bu kararlısürümde, bütün işletim sistemlerinde tüm sürücülerin beklediğimiz gibi davranmasıiçin MICCLSIZE 'ıMHLEN+1 olarak değiştirdik.

  2. çokluyayın(multicast). eğer bir arayüz için ifmcstat(8) hiçbir multicast grubu kabul etmezse bu arayüz yamalanmalıdır.

Eğer sürücülerden hiçbiri istenenleri desteklemiyorsa IPv6 ve/veya IPsec haberleşmesi için kullanılamazlar. Eğer IPv6/IPsec kullanan kartın herhangi bir problem çıkarırsa lütfen bunu "FreeBSD problem reports" mail listesine bildirin.

NOT: Eskiden bütün PCMCIA sürücülerinin in6_ifattach() e çağrıyapmasınıistedik. Böyle bir isteğe artık ihtiyacımız yok.

8.1.3. Çevirici

IPv4/IPv6 çeviricisini 4 sınıfa ayırdık:

  • Translator A --- IPv6 adasındaki IPv6 makinasından IPv4 okyanusundaki IPv4 makinasına bağlantıkurmayımümkün kılmak için eski geçişaşamalarında kullanıldı.

  • Translator B --- IPv4 okyanusundaki IPv4 makinasından IPv6 adasındaki IPv6 makinasına bağlantıkurmayımümkün kılmak için eski geçişaşamalarında kullanıldı.

  • Translator C --- IPv4 adasındaki IPv4 makinasından IPv6 okyanusundaki IPv6 makinasına bağlantıkurmayımümkün kılmak için eski geçişaşamalarında kullanıldı.

  • Translator D --- IPv6 okyanusundaki IPv6 makinasından IPv4 adasındaki IPv4 makinasına bağlantıkurmayımümkün kılmak için eski geçişaşamalarında kullanıldı.

A sınıfıiçin TCP nakil çeviricisi (relay translator) desteklenir. Bu "GÜVEN(FAITH)" olarak adlandırılır. Ayrıca A sınıfı için IP başlık çeviricisini sağlıyoruz. (İkinci özellik (IP başlığı) FreeBSD 4.x e henüz koyulmadı.)

8.1.3.1. FAITH TCP nakil çeviricisi

FAITH sistemi kernel tarafından yardım edilen faithd(8) isimli TCP nakil daemon 'unu kullanır. FAITH bir IPv6 adres önekini alır ve TCP bağlantısınıbu önek üzerinden IPv4 hedefine nakleder.

Örneğin, eğer alınmışIPv6 öneki 2001:0DB8:0200:ffff:: ise, ve TCP bağlantısıiçin hedef IPv6 adresi 2001:0DB8:0200:ffff::163.221.202.12 ise bağlantı163.221.202.12 IPv4 hedefine nakledilir.

hedef IPv4 düğümü (163.221.202.12)

^

|

IPv4 tcp toward 163.221.202.12 FAITH-nakil çift yığın düğümü

^

|

IPv6 TCP toward 2001:0DB8:0200:ffff::163.221.202.12 kaynak IPv6 düğümü

faithd(8) FAITH-nakil çift yığın düğümünden (FAITH-relay dual stack node) çağırılmalıdır. Daha fazla detay için src/usr.sbin/faithd/README 'ye danışın.

8.1.4. IPsec

IPsec temel olarak üç kısımdan oluşmaktadır.

  1. Politika Yönetimi

  2. Anahtar Yönetimi

  3. AH ve ESP tutma

8.1.4.1. Politika Yönetimi

Çekirdek deneysel politika yönetim kodu yürütmektedir. Güvenlik politikasınıyönetmek için iki yol vardır. Biri setsockopt(2) kullanarak her soket için politika oluşturmaktır. Bu durumlarda, politika yapılandırmasıipsec_set_policy(3) de tasvir edilmiştir. Diğeri ise setkey(8) üzerinden PF_KEY arayüzünü kullanarak çekirdeğin paket filtreleme tabanlıpolitikasını yapılandırmaktır.

Politika girdisi indeksi ile birlikte tekrar sıralanmamıştır, dolayısıyla girdiyi eklediğiniz andaki sıra çok önemlidir.

8.1.4.2. Anahtar Yönetimi

Bu kitte (sys/netkey) yürütülen anahtar yönetim kodu ev yapımı PFKEY v2 yürütmesidir. Bu RFC2367 'e uygundur.

Ev yapımıIKE daemonu, "racoon" kite eklenmiştir (kame/kame/racoon). Temel olarak racoon 'u daemon olarak çalıştırmanız gerekecek, sonra anahtarlarıgerektiren bir politika oluşturun (ping -P 'out ipsec esp/transport//use' gibi). Çekirdek gerektiğinde anahtarlarıdeğiştirmek için racoon daemonu ile kontağa geçecektir.

8.1.4.3. AH ve ESP tutma

IPsec modülü standart IPv4/IPv6 işlemeye karşı "kancalar(hooks)" olarak geliştirildi. Bir paket yollarken, ip{,6}_output() eşleşen bir SPD 'nin (Güvenlik Politika Veritabanı) varlığına bakarak ESP/AH işlemenin gerekliliğini kontrol eder. Eğer gerekli ise, {esp,ah}{4,6}_output() çağrılır ve duruma göre mbuf güncellenecektir. Bir paket alındığında, {esp,ah}4_input() protokol numarasına bağlıolarak çağrılacaktır. Örneğin (*inetsw[proto])(). {esp,ah}4_input() paketin selahiyetini kontrol edecektir, papatya zinciri başlığınıve ESP/AH eklentisini çıkaracaktır. Paket kabulünde ESP/AH başlığınıçıkarmak güvenlidir çünkü hiçbir zaman alına paketi "olduğu gibi" kullanmayacağız.

ESP/AH kullanarak TCP4/6 efektif veri segman boyutu, ESP/AH tarafından eklenen ekstra papatya zinciri başlıklarıtarafından etkilenecektir. Kodumuz bu durumu dikkate alır.

Temel şifreleme fonksiyonları"sys/crypto" dizininden bulunabilir. ESP/AH dönüşümü {esp,ah}_core.c de sargıfonksiyonları ile listelenmiştir. Eğer bazıalgoritmalar eklemek istiyorsanız, sargıfonksiyonunuzu {esp,ah}_core.c ye, şifreleme algoritmanızıda sys/crypto 'nun içine ekleyin.

Bu sürümde tünel modu aşağıdaki kısıtlamalar ile kısmi olarak desteklenmektedir:

  • IPsec tüneli GIF jenerik tünel arayüzü ile birleşemez. Büyük bir titizlik ister çünkü ip_output() ve tunnelifp->if_output() arasında bir sonsuz döngü oluşturmuş olabiliriz. Onlarıbirleştirmeni ne kadar iyi olduğuna bağlı olarak düşünce çeşitlenir.

  • MTU ve Don't Fragment (Parçalama yapma) bitleri (IPv4) daha fazla kontrole ihtiyaç duyar, ama temel olarak iyi çalışır.

  • AH modeli için otantikasyon(authentication) modeli mutlaka tekrar ele alınmalıdır. Er geç politika yönetim motorunu geliştirmemiz gerekecek.

8.1.4.4. RFC ve ID lere uygunluk

Çekirdekteki IPsec kodu aşağıdaki standartlara uygunluk göstermektedir (veya göstermeye çalışmaktadır):

"eski IPsec" beyannamesi rfc240[1-6].txt, rfc241[01].txt, rfc2451.txt ve draft-mcdonald-simple-ipsec-api-01.txt (draft 'ın süresi doldu, ama ftp://ftp.kame.net/pub/internet-drafts/ den alabilirsin) de yazılmıştır. (NOT: IKE beyannameleri, rfc241[7-9].txt kullanıcıdüzeyinde "racoon" IKE daemon 'u olarak yürütüldü)

Şu an desteklenen algoritmalar şunlardır:

  • eski IPsec AH

  • null kripto checksum (doküman yok, sadece hata ayıklama gibi)

  • MD5 ile anahtarlanmış128bit kripto checksum (rfc1828.txt)

  • SHA1 ile anahtarlanmış128bit kripto checksum (doküman yok)

  • HMAC MD5 ile anahtarlanmış128bit kripto checksum (rfc2085.txt)

  • HMAC SHA1 ile anahtarlanmış128bit kripto checksum (doküman yok)

  • eski IPsec ESPsi

  • null şifreleme (doküman yok, rfc2410.txt ye benzer)

  • DES-CBC modu (rfc1829.txt)

  • yeni IPsec AH

  • null şifreleme (rfc2410.txt)

  • TüretilmişIV ile DES-CBC (draft-ietf-ipsec-ciph-des-derived-01.txt, draft süresi doldu)

  • Açık IV ile DES-CBC (rfc2405.txt)

  • Açık IV ile 3DES-CBC (rfc2451.txt)

  • BLOWFISH CBC (rfc2451.txt)

  • CAST128 CBC (rfc2451.txt)

  • RC5 CBC (rfc2451.txt)

  • yukarıdakilerin hepsi şunlarla birleştirilebilir:

  • HMAC-MD5(96bit) ile ESP otantikasyonu

  • HMAC-SHA1(96bit) ile ESP otantikasyonu

Aşağıdaki algoritmalar desteklenmez:

  • eski IPsec AH

  • 128bit kripto checksum 'ıile HMAC MD5 + 64bit cevap engelleme (rfc2085.txt)

  • SHA1 ile anahtarlanmış160bit kripto checksum + 32bit eklenti (rfc1852.txt)

IPsec (çekirdekte) ve IKE (kullanıcıdüzeyi "racoon" da) birkaç etkileşimli operasyonel test olaylarıile test edildi, ve diğer işlemler ile iyi biçimde etkileşimli çalıştığıile bilinir. Ayrıca IPsec kripto algoritmalarıiçin çok genişbir alan oluşturan şu anki IPsec yürütmesi RFC de tanıtılmıştır.

8.1.4.5. IPsec tünellerinde ECN ehemmiyeti

ECN dostu IPsec tünelleri draft-ipsec-ecn-00.txt de tasvir edildiği gibi desteklenir.

Normal IPsec tüneli RFC2401 de tasvir edilmiştir. Kapsüllemede IPv4 TOS alanı(veya, IPv6 trafik sınf alanı) iç IP başlığından dış IP başlığına kopyalanacaktır. Kapsülü açarken dışIP başlığı kolaylıkla atılacaktır. Kapsülü açma kuralıECN ile uyuşmaz, çünkü dışIP TOS/trafik sınıf alanındaki ECN biti kaybedilecektir.

IPsec tünelini ECN dostu hale getirmek için kapsülleme ve kapsül açma prosedürlerinde düzenlemelere gitmeliyiz. Bu http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt, bölüm 3 de açıklanmıştır.

IPsec tünel yapısısize net.inet.ipsec.ecn (veya net.inet6.ipsec6.ecn) i bazıdeğerlere ayarlayarak üç davranış sunabilir:

  • RFC2401: ECN için hiçbir şey yok (sysctl değeri -1)

  • ECN yasaklı(sysctl değeri 0)

  • ECN ye izin var (sysctl değeri 1)

Davranışın her SA bazında değilde her düğüm bazında yapılandırılabilir olduğunu dikkate alın (draft-ipsec-ecn-00 her SA bazında yapılandırma ister ama benim için çok fazladır).

Davranışşu şekilde özetlenebilir (daha fazla detay için kaynak koda bakın):

Kapsülleme kapsül açma

--- ---

RFC2401 bütün TOS bitlerini Dışarıdaki TOS bitlerini sil içeriden dışarıya kopyala. (İçdeki TOS bitlerini olduğu gibi kullan) ECN yasaklıİçeriden dışarıya olan ECN Dışarıdaki TOS bitlerini sil (0cfc ile maskeli) ler hariç (İçdeki TOS bitlerini olduğu gibi kullan) TOS bitlerini kopyala ECN bitlerini sıfırla. ECN bitlerini sıfırla.

ECN izinli İçeriden dışarıya olan ECN CE İçerideki TOS bitlerini biraz değişiklikle kullan (0cfe ile maskeli) ler hariç Eğer ECN CE biti 1 ise, içerideki ECN CE bitini aktif et. TOS bitlerini kopyala. ECN CE bitini sıfırla.

Yapılandırma için genel strateji şu şekildedir:

  • Eğer her iki IPsec tünel uçlarıECN dostu davranışa sahipse, her iki ucu "ECN izinli" hale getirirseniz daha iyi olur (sysctl değeri 1).

  • Eğer diğer uç TOS biti konusunda çok katıise, "RFC2401" i kullan (sysctl değeri -1)

  • Diğer durumlarda "ECN yasak" durumunu kullan (sysctl değeri 0).

    Varsayılan davranış"ECN yasak" dır (sysctl değeri 0).

Daha fazla bilgi için lütfen şuraya başvurunuz:

http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt

, RFC2481 (Explicit Congestion Notification), src/sys/netinet6/{ah,esp}_input.c

(Detaylıanalizlerinden dolayıKenjiro Cho <kjc@csl.sony.co.jp>ya teşekkürler)

8.1.4.6. Etkileşimli İşlevsellik

KME kodunun geçmişte test ettiği IPsec/IKE etkileşimli işlevselliği için (bazı) platformlar buradadır. Dikkat edinki her iki uç da yapılarınıdeğiştirmişolabilir, dolayısıyla sadece referans amacıyla aşağıdaki listeyi kullanın.

Altiga, Ashley-laurent (vpcom.com), Data Fellows (F-Secure),

Ericsson ACC, FreeS/WAN, HITACHI, IBM AIX(R), IIJ, Intel,

Microsoft(R) Windows NT(R), NIST (linux IPsec + plutoplus),

Netscreen, OpenBSD, RedCreek, Routerware, SSH, Secure Computing,

Soliton, Toshiba, VPNet, Yamaha RT100i