1. Ważniejsze zmiany wprowadzone do IPv6

  2. Opis adresu IP wersji szóstej
  3. Pojęcie prefixu - czyli inne określenie maski
  4. Konfiguracja tunelu - opis dla FreeBSD
  5. Udostępnianie IPv6 ludziom z lanu - opis dla FreeBSD
  6. Udostępnianie tuneli 1
  7. Udostępnianie tuneli 2
  8. Konfiguracja serwera nazw na routerze
  9. Konfiguracja named`a po stronie klienta
  10. Sprawdzanie konfiguracji DNS
  11. Podsumowanie


Ważniejsze zmiany wprowadzone do IPv6:

1. Dłuższe adresy.

 Nowe rozmiary adresów to najbardziej znacząca zmiana. 128 bitowy adres daje liczbę 2^128 możliwych adresów. Jak to kiedyś ktoś obliczył jest to około 1500 adresów na metr kwadratowy Ziemi. Raczej nie musimy się martwić tym, że zabraknie nam adresów i będziemy musieli sięgać po inne metody, na przykład typu NAT (Network Address Translation).

2. Elastyczny format nagłówka.

 IPv6 używa nowego formatu datagramu. Mało tego - IPv6 używa opcjonalnych nagłówków. Nie tak, jak w IPv4, gdzie nagłówek miał ustalony z góry format i wiadomo było ile zajmuje dane pole (z wyjątkiem pola opcji). W wersji szóstej wymagany jest jedynie nagłówek podstawowy, a pozostałe nagłówki są opcjonalne. Co jest rzeczą ciekawą, nagłówek IPv6, choć musi obsługiwać dłuższe adresy niż nagłówek IPv4, zawiera mniej informacji niż nagłówek datagramu IPv4. Po prostu pewne pola zostały przeniesione do nagłówków opcjonalnych.


Nagłówek podstawowy pakietu IPv6: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |       Flow Label              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Payload Length    |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                       |
+                                                       +
|                                                       |
+                   Source Address                      +
|                                                       |
+                                                       +
|                                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                       |
+                                                       +
|                                                       |
+                Destination Address                    +
|                                                       |
+                                                       +
|                                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Nagłówek podstawowy ma 40 oktetów, w których zawarte są informacje o:



Nagłówek IPv4: (dla porównania, gdyż to najistotniejsze) 

0                   1                   2                   3   
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Dodatkowe (opcjonalne) nagłówki dla IPv6:



3. Dodatkowe opcje.

Zawarte głównie w nagłówkach dodatkowych, przy czym każdy datagram zawiera tylko te nagłówki dodatkowe, które są wymagane przez mechanizmy, z których on korzysta. Jako przykład można tutaj podać trasowanie według nadawcy IPv6. Odbywa się to przez zastosowanie dodatkowego nagłówka, który zawiera kolejne pośrednie routery, przez które datagram musi przejść. Dodatkowe opcje są również określane przez pole `dodatkowy nagłówek` w poprzednim nagłówku (ten zawiera informacje o tym, że następny nagłówek będzie nagłówkiem opcji). Dzięki tej metodzie nie musimy zawsze wykorzystywać wszystkich dodatkowych nagłówków, przez co zminiejszamy ilość dodatkowych informacji przesyłanych w datagramie. Co za tym idzie procentowy udział informacji sterujących do właściwych danych, które chcemy przesyłać. Prócz nagłówków dodatkowych projektanci zaproponowali dwa nagłówki dodatkowe więcej: nagłówek dodatkowych etapów oraz nagłówek dodatkowy odbiorcy. Nagłówki te dzielą opcje na, te które powinny być konsultowane na każdym etapie, oraz opcje, które powinny być interpretowane u odbiorcy.

4. Wsparcie dla rezerwowania zasobów.

 Pole podstawowego nagłówka, etykieta potoku (28b) zawiera informacje, których routery używają do wiązania datagramu z odpowiednim potokiem informacji oraz priorytetem. Dzięki temu dla danego datagramu możemy uzyskać określoną jakość usługi (przykładowo określone przepustowości oraz opóźnienia między nadawcą a odbiorcą) czyli QOS. Przykładowo przesyłając sygnały mowy możemy od usługodawcy zarządać określonych opóźnień i w ten sposób stworzyć internetowy telefon z jakością porównywalną (lub lepszą) od obecnie stosowanych standardów telefonicznych. To oczywiście działa też w drugą stronę. Otóż usługodawca może wymagać od swoich klientów, aby określili (może to sie odbywać na drodze negocjacji jakości usług) potrzebną im jakość usługi, a następnie używać potoków do ograniczania ruchu generowanego przez dany komputer czy program użytkowy.

Dzięki odpowiedniemu zarządzaniu potokami możemy zarządzać zasobami sieciowymi w sposób taki jaki nam odpowiada.



5. Zapewnienie rozszerzalności protokołu.

 Przez dodanie nagłówków opcjonalnych jesteśmy w stanie dostosowywać protokół na bieżąco do zmian w sprzęcie sieciowym, programach użytkowych i innych. Dzięki tej możliwości, gdy protokół już będzie obowiązywał to konieczność zmian protokołu nie będzie pociągała za sobą konieczności pisania od nowa całego protokołu. Przez wykorzystanie istniejącego protokołu i możliwości jego adaptacji będziemy mogli się dostosować do konkretnych wytycznych zaproponowanych przez nowe technologie i inne przyszłościowe rozwiązania.

6. Brak sumy kontrolnej nagłówka.

 W porównaniu z protokołem Ipv4, nagłówek datagramu IPv6 nie zawiera sumy kontrolnej nagłówka. Ma to na celu odciążenie routerów obliczających CRC. Przy dużych przepustowościach jest to kosztowne, dlatego też twórcy zrezygnowali z tej czynności. Czy to znaczy, że pakiety są całkowicie niezabezpieczone przed błędami (przekłamaniami)? Otóż nie, gdyż większość technologi, Ethernet, FDDI czy choćby ATM obliczają CRC (Cyclic Redundancy Check) z przesyłanych ramek. Także wyliczanie znów CRC w warstwie trzeciej (IP) okazało sie zbędne (bo właściwie po co robić dwa razy to samo).

7. Utworzenie adresu Anycast (Anycast Address).

 Jest to adres, który przypisujemy do kilku (najczęściej różnych) interfejsów. Mówiąc tutaj o interfejsie mam na myśli jeden z węzłów sieci. Pakiet wysłany na adres anycast trafia do jednego z interfejsów (do którego przypisany jest adres anycast), najczęściej najbliższego (rozumianego tutaj jako najbliższego według dystansu z konkretnego protokołu routingu). Przeważnie adres anycast jest adresem unikalnym (unicast), dlatego też urządzenie wysyłając pakiet na ten adres nie musi wiedzieć, że jest to adres typu Anycast. Tego adresu możemy użyć do rozłożenia obciążenia na kilka routerów.

Multicast Address - adres odpowiadający adresowi rozgłoszeniowemy z IPv4 (broadcast). Pakiet wysłany na adres multicast dociera do wszystkich interfejsów określonych przez ten adres.

Unicast Address - adres przypisany do pojedyńczego interfejsu. Pakiet wysłany na ten adres jest dostarczony do interfejsu identyfikującego się tym adresem.

8. Autokonfiguracja.

Automatyczna konfiguracja za pomocą Internet Control Messaging Protocol version 6 (ICMPv6) pozwala zidentyfikować lub sprawdzić adres. Pierwszym krokiem jest utworzenie 64 bitowego adresu na podstawie 48 bitowego adresu MAC (adres fizyczny karty sieciowej):

MAC:			08:00:20:0D:EE:39
IEEE EUI-64:		0800:20FF:FE0D:EE39
		        +2	
Identyfikator:	      	0A00:20FF:FE0D:EE39

Po utworzeniu identyfikatora komputer poprzez ICMPv6 sprawdza czy, w jego otoczeniu nie istnieje już komputer używający tego samego identyfikatora (czyli tego samego MAC`a). Jeśli okaże się, że już ktoś w sieci ma taki identyfikator, wówczas konieczne jest ręczne ustawienie interfejsowi owego identyfikatora. Jeśli wszystko przebiegnie dobrze to tworzony jest adres tzw. link-local: 
    fe80::0A00:20FF:FE0D:EE39%rl0
Możemy to sprawdzić: 
    # ifconfig rl0 | grep inet6
    inet6 fe80::0A00:20FF:FE0D:EE39%rl0 prefixlen 64 scopeid 0x1
Oczywiście w sieci lokalnej możemy również pingować po adresie link-local, który jest adresem unikalnym (unicast). 
    # ping6 fe80::0A00:20FF:FE0D:EE39%rl0
    PING6(56=40+8+8 bytes) fe80::260:52ff:fe09:f1b8%rl0 --> fe80::0A00:20FF:FE0D:EE39%rl0
    16 bytes from fe80::0A00:20FF:FE0D:EE39%rl0, icmp_seq=1 hlim=64 time=0.371 ms

Wówczas z pomocą ICMPv6 komputer może automatycznie skonfigurować swój interfejs, pobrać adres, długość prefiksu, adres bramy (informacje te rozgłaszane są przez routery) i zacząć pracę w sieci.
Oczywiście możemy określić, które komputery powinny korzystać z DHCPv6 (Dynamic Host Configuration Protocol version six), a które mogą używać autokonfiguracji przedstawionej powyżej.

Wsparcie autokonfiguracji (Neighbor Discovery) w zebrze: 

     interface eth0
     ipv6 nd send-ra
     ipv6 nd prefix-advertisement 3ffe:80ee:e5d::/48



Dodatek 1) Opis adresu IP wersji szóstej.

 Jest to najbardziej znacząca zmiana w porównaniu z protokołem IP wersji czwartej. Adres w wersji czwartej jest 32 bitowy, co daje pulę adresową 2^32 możliwych adresów IP. W wersji szóstej adres jest adresem 128 bitowym (2^128 możliwych adresów). Projektanci IPv6, aby uczynić adresy bardziej zwartymi, odeszli od koncepcji stosowanej w IP wersji czwartej (czyli notacji dziesiętnej z kropkami np: 127.0.0.1). Zaproponowali natomiast używanie notacji szesnastkowej z dwukropkami. Komputery (czy węzły sieci) oczywiście nie rozróżniają takiej czy takiej notacji. Dla nich liczy się forma binarna, a zastosowanie różnych notacji ma na celu użycie formy bardziej zrozumiałej (przystępnej) dla ludzi. W IP wersji szóstej IP stanowi 128 znakowy ciąg zer i jedynek 1110010011111....1101.

Na czym polega notacja szesnastkowa z dwókropkami?

	

0 - 0000	4 - 0100	8 - 1000	C - 1100		
1 - 0001	5 - 0101	9 - 1001	D - 1101
2 - 0010	6 - 0110	A - 1010	E - 1110
3 - 0011	7 - 0111	B - 1011	F - 1111

Aby przekształcić adres z postaci binarnej na szesnastkową, 128 bitowy ciąg zer i jedynek dzielimy po 4 i każdej 4 bitów przypisujemy wartość heksadecymalną (jak wyżej). Przykładowo mająć ciąg zaczynający się od sekwencji: 

0011 1111 1111 1110 1000 0000 1110 1110 ...
3    F    F   E     8    0    E    E  ...

W ten sposób otrzymujemy notację szesnastkową. Jak teraz z tej notacji uzyskać notację szesnastkową z dwókropkami?
Sprawa jest dość prosta. Otrzymany ciąg szesnastkowy dzielimy znów czwórkami otrzymująć:
3FFE:80EE: ....

Łatwo policzyć ilość sekcji 4 znakowych:
128 (bitów) : 4 (zmiana na heksadecymalne) : 4 (bo dzielimy czwórkami) = 8

Czyli kompletne IPv6 będzie wyglądało następująco:

XXXX:xxxx:XXXX:xxxx:XXXX:xxxx:XXXX:xxxx

Przykładowo:
3FFE:80EE:0E5D:0000:0000:0000:0000:0001

Dodatkowo w notacji tej przyjęto metodę kompresji zer. Aby zapewnić, że kompresja nie spowoduje niejednoznaczności w interpretacji, przyjęto, że w danym adresie może być ona zastosowana tylko raz.

Wygląda to tak dla naszego przykładu:
3FFE:80EE:E5D::1

Niezłe uproszczenie prawda? ;)

Notacja szesnastkowa z dwókropkami zezwala na pisanie końcówek w notacji dziesiętnej z kropkami. Ten fakt będzie miał znaczenie podczas migracji między IP wersji czwartej do szóstej (choć ciężko przewidzieć czy IPv4 rzeczywiście zostanie całkowicie zastąpiony i czy na przykład nie będzie nadal używany w sieciach szkieletowych i ważniejszych ruterach).
Otóż IPv4 można zapisać:

0:0:0:0:0:0:172.16.1.1
0:0:0:0:0:ffff:172.16.1.1 (to jeśli adres nie obsługuje IPv6, a tylko IPv4)

Oczywiście możemy również użyć kompresji zer:

::172.16.1.1
::ffff:127.16.1.1

I końcowy wynik jest zdumiewający, wygląda prawie jak zwykłe IPv4.

Dodatek 2) Pojęcie prefixu - czyli inne określenie maski sieci.

 Myśle, że należy tutaj omówić również pojęcie prefixu.
Otrzymując przykładową sieć:
3FFE:80EE:E5D::/48


/48 reprezentuje w tym wypadku długość prefixu.
Prefix to po prostu inny zapis maski.

Najprościej to wytłumaczyć w ten sposób:
111111111111111111111......0000000000000000000000000000
48 jedynek 80 zer

Co odpowiada w zapisie heksadecymalnym:

FFFF:FFFF:FFFF:0000:0000:0000:0000:0000
3FFE:80EE:0E5D:: - określa sieć FFFF:FFFF:FFFF:: - prefix

Czyli możemy używać IP:
3FFE:80EE:E5D:xxxx:xxxx:xxxx:xxxx:xxxx
Do czego to potrzebne? Otórz zanim komputer wyśle jakikolwiek datagram to najpierw sprawdza, czy aby odbiorca nie jest w sieci określonej przez prefix. Aby sprawdzić mnoży binarnie IP (dowolne z puli) z prefixem (otrzymując w ten sposób sieć).
1*1=1 0*1=0 1*0=0 0*0=0

Jeśli w ten sposób otrzymany adres zgadza się z adresem sieci to, znak że pakiet można przekazać bezpośrednio do odbiorcy (odbiorca jest w tej samej sieci, lanie). W przeciwnym wypadku komputer korzysta z tablicy rutingu i kieruje datagram do odpowiedniej bramy (gateway). Dalszym losem datagramu martwi się już router. Zastosowanie prefixu pozwala nam podzielić naszą sieć na mniejsze podsieci (w dość prosty sposób). Informacja o prefixie może być wykorzystywana przez protokoły routingu (routujemy całe sieci, a nie pojedyńcze IP, przez to zmniejszamy tablice routingu i przyspieszamy działanie sieci).

Czyli w naszej sieci /48 będziemy mieli 2^(128-48) dostępnych adresów IP wersji szóstej.

Dodatek 3) Konfiguracja tunelu do xs26 - opis dla FreeBSD

Koniecznie przeczytaj również podsumowanie!

Obecnie protokół IPv6 jest protokołem działającym w sieciach testowych. Najczęście jest to kapsułkowanie pakietów IPv6 w pakietach IPv4, czyli jakby to najprościej powiedzieć wrzucanie datagramów IPv6 do pola ładunkowego datagramów protokołu wersji czwartej. Jest wiele węzłów, do których możemy zestawić tunel IPv4 i przez ten tunel przesyłać pakiety IPv6. Większość węzłów jest ze sobą połączona, przez co możemy mieć dostęp do usług oferowanych przez pozostałych użytkowników za pomocą v6, na przykład: irc6, www6, ftp6 itd.
Opiszę tutaj jak prosto skonfigurować tunel do jednego z węzłów sieci xs26.net :

Autoskrypty startowe z XS26
Jak to działa: 
		+--- IPv4-only cloud -------------------+
		|					|
	+<================= IPv6-over-IPv4 tunnel =============>+
	|  	|					|	|
	|	+---------------------------------------+  	|
	|							|
      IPv4/v6 router					      IPv4/v6 router
	|							|
      ==+======= IPv4/v6 segment 1			      ==+======= IPv4/v6 segment 2
Kapsułkowanie pakietów IPv6 w datagramach IPv4: 
  +-----------------+-----------------+----------------//--------------------------------+
  |  	 IPv4       |	   IPv6       |                      DATA                        |
  |  	 header     |	  header      |                                                  |
  +-----------------+-----------------+---------------//---------------------------------+     
			
		    <---------------------- IPv4 payload -------------------------------->

Moje IP: 157.158.180.188 IP pop`a z xs26: 62.24.64.27 Otrzymana sieć: 3FFE:80EE:E5D::/48

Co robimy:



Dodatek 4) Udostępnianie ipv6 ludziom z Lanu - opis dla FreeBSD

Koniecznie przeczytaj również podsumowanie!

Czasami zdarza się, że chcemy zestawić tunel dla pakietów IPv6 tylko do głównego routera, a otrzymane IPv6 chcemy rozdzielić między użytkowników sieci lokalnej. Czasami, szczególnie gdy użytkownicy lanu są za NAT`em jest to najprostszy sposób aby i oni również mogli korzystać z protokołu IP wersji szóstej.

W tym punkcie opisze prosto jak skonfigurować nasz router:
Podzieliłem tak sieć, że użytkownicy z lanu będą używać IP: 3FFE:80EE:E5D:0:0:0:1:xxxx co odpowiada prefixowi /112
Bramą dla nich będzie 3FFE:80EE:E5D::1:1

Pojedyńczy użytkownik otrzyma 256 ip czyli jego adres będzie postaci: 3FFE:80EE:E5D:0:0:0:1:UUxx gdzie:


Przykład zilustrowałem na przykładzie O.S. FreeBSD jednak użytkownicy z lanu z powodzeniem mogą używać innych systemów operacyjnych np: linux, windowsXP oraz innych obsłgujących protokół IPv6.

Dodatek 5) Udostępnianie tuneli (bez końcówek IPv6) - opis dla FreeBSD

Koniecznie przeczytaj również podsumowanie!



W tym punkcie opisze jak udostępniać tunele znajomym:


Przykładowo wydzielony tunel dla znajomego:

3FFE:80EE:E5D:1::/64 - przydzielona sieć
Czyli znajomy będzie mógł używać adresów: 3FFE:80EE:E5D:1:xxxx:xxxx:xxxx:xxxx


Całą konfiguracje przedstawiłem mniej więcej krok po kroku. Jak to zautomatyzować?
Wpis:
ipv6_gateway_enable="YES" w pliku /etc/rc.conf włącza nam odpowiedniego sysctl`a. (net.inet6.ip6.forwarding=1)
Pozostałe polecenia konfigurjące możemy wpisać do pliku ipv6.sh i dodać go do /usr/local/etc/rc.d/.
Aby plik był uruchamiany przy starcie powinien mieć +x oraz nazywać się *.sh.

Dodatek 6) Udostępnianie tuneli (+ końcówki IPv6) - opis dla FreeBSD

Koniecznie przeczytaj również podsumowanie!



W tym punkcie opisze jak udostępniać tunele znajomym:


Przykładowo wydzielony tunel dla znajomego:

3FFE:80EE:E5D:1::/64 - przydzielona sieć
3FFE:80EE:E5D:add1::3 - moja końcówka tunelu
3FFE:80EE:E5D:add1::2 - końcówka tunelu znajomego

Czyli znajomy będzie mógł używać adresów: 3FFE:80EE:E5D:1:xxxx:xxxx:xxxx:xxxx

Dodatek 7) Konfiguracja serwera nazw na routerze

a) konfiguracja strefy prostej



W pliku konfiguracyjnym dla danej strefy prostej należy wpisać rekord AAAA stosowany dla IPv6
Przykładowo wygląda to tak:

<18:15:13> root@sky:/etc/namedb/ipv4> more dres.ltd.pl
$ORIGIN .
$TTL 86400      ; 1 day 
dres.ltd.pl             IN SOA  dres.ltd.pl. jano.irc.pl. (	
	           	2002102003 ; serial				
			10800      ; refresh (3 hours)			
			900        ; retry (15 minutes)			
      			2419200    ; expire (4 weeks)			
       			86400      ; minimum (1 day)			
       			)						
		    NS      sky.ondraszek.ds.polsl.gliwice.pl.		
		    MX      10 sky.ondraszek.ds.polsl.gliwice.pl.	
		    AAAA    3ffe:80ee:e5d::10	; tutaj nasze przypisanie
		    A       157.158.180.188 				
$ORIGIN dres.ltd.pl.
w.paski			AAAA	3ffe:80ee:e5d::11


b) konfiguracja strefy odwrotnej


- do pliku named.conf dopisujemy naszą strefę:
Przykładowo wygląda to tak:

zone "d.5.e.0.e.e.0.8.e.f.f.3.ip6.int"{
	type master;
	file "xs26.rev";
	};


- a plik konfiguracyjny xs26.rev wygląda następująco:


$TTL    3600  
@       IN      SOA     sky.ondraszek.ds.polsl.gliwice.pl. root.sky.ondraszek.ds.polsl.gliwice.pl.  (
        20021126        ; Serial
        3600    ; Refresh
        900     ; Retry
        3600000 ; Expire
        3600 )  ; Minimum
	IN      NS      sky.ondraszek.ds.polsl.gliwice.pl.

1.0.0.0					 IN   NS       name.serwer.znajomego.od.sieci/64.pl.  ;przypadek B

0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   	 IN   NS       host1.z.lanu.ale.nie.za.natem.      ; przypadek A
0.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0	 IN   NS       host2.z.lanu.ale.nie.za.natem.	  ; przypadek A

2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR     sky.ondraszek.eu.org.
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR     hera.eu.org.
4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR     ondrach.eu.org.
9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR     stable.one.pl.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR     dres.ltd.pl.
5.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0  IN   PTR     bsd.xpam.de.

Czyli mamy odpowiednio, że dla IPv6 3ffe:80ee:e5d::10 revdns wskazuje na domene dres.ltd.pl.

Uwaga: Przypadek A

Jeśli to jest lan, w którym uzytkownik domena.z.lanu.ale.nie.za.natem. ma zewnętrzne IP i chce realizować na swoim Name Serwerze strefe odwrotną dla otrzymanych ip, to wpis podany w przypadku A załatwia sprawę. Wszelkie zapytania o revdns dla strefy 3ffe:80ee:e5d::1:00xx będą kierowne do NS`a host1.z.lanu.ale.nie.za.natem. A zapytania revdns dla strefy 3ffe:80ee:e5d::1:10xx będą kierowane do host2.z.lanu.ale.nie.za.natem.



Uwaga: Przypadek B

Wpis mówiący, że zapytania o revdnsy dla strefy przyznanej naszemu znajomemu będą kierowane do name serwera name.serwer.znajomego.od.sieci/64.pl
Podsieć przyznana znajomemu(udostępnianie tuneli): 3ffe:80ee:e5d:1::/64

Dodatek 8) Konfiguracja named`a po stronie klienta (przypadek A)

a) wpis do named.conf 


zone "0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.5.e.0.e.e.0.8.e.f.f.3.ip6.int" {
	type master;
	file "host1.rev";
	};


b) plik host1.rev 

$TTL    3600
        @       IN      SOA    host1.z.lanu.ale.nie.za.natem.  user.moj.mail.pl.  (
                20021126        ; Serial
                3600    ; Refresh
                900     ; Retry
                3600000 ; Expire
                3600 )  ; Minimum
                IN      NS      host1.z.lanu.ale.nie.za.natem.

0.0		IN	PTR	rev.do.mojej.domenki1.pl.
0.1		IN	PTR	rev.do.mojej.domenki2.pl.
f.f		IN	PTR	rev.do.mojej.domenki.pl.

Oczywiście nie każdy chce (lub potrafi) skonfigurować na swoim komputerze poprawnie działający Name Server, dlatego też strefę odwrotną dla danego użytkownika możemy bez problemu robić na routerze głównym. Szczerze powiedziawszy jest to nawet lepsze rozwiązanie z tego względu, że większość komputerów w sieci lokalnej to stacje robocze, które nie działają cały czas. Choć również opisałem taki przypadek, dla tych ambitniejszych użytkowników z lanu.

Dodatek 9) Sprawdzanie konfiguracji DNS (Domain Name System) - ( dig, host )


Sprawdzenie strefy prostej

# dig @name.server.obsługujący.domene.pl dres.ltd.pl AAAA
...
;;      dres.ltd.pl, type = AAAA, class = IN

;; ANSWER SECTION:
dres.ltd.pl.            1D IN AAAA      3ffe:80ee:e5d::10
...

Sprawdzanie strefy odwrotnej


# dig @name.server.obsługujący.strefe.odwrotną.pl -x 3ffe:80ee:e5d::10 
	
Forma zapytania jest wzięta z manuala.

Domyślnie dodaje końcówkę ....ip6.arpa zamiast ...ip6.int
Wynika to z faktu, że obecnie powinniśmy używać oficjalnie   ...ip6.arpa. 
Choć wielu użytkowników nadal używa formy ip6.int. Dlatego też proponuje 
skonfigurowanie 2 stref jedną dla ip6.arpa oraz ip6.int (pliki strefy pozostaną 
takie same dla jednej jak i dla drugiej). Dzięki temu nasz Name Serwer będzie 
obsługiwał zarówno pierwszą jak i drugą formę.
Choć możemy zawsze użyć tej formy zapytania:

# dig @nasz.ns.pl 0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.5.e.0.e.e.0.8.e.f.f.3.ip6.int PTR

Lub też użyć linuksowego host:

# host -n 3ffe:80ee:e5d::10 name.server.obsługujący.strefe.odwrotną.pl

0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.5.e.0.e.e.0.8.e.f.f.3.ip6.int domain name pointer dres.ltd.pl.
Mamy takie odpowiedzi jeśli wszystko poprawnie skonfigurowaliśmy.

Podsumowanie - ważne, przeczytaj to.

 Artykuł ten opisuje tylko podstawowe zagadnienia związane z protokołem IPv6. Więcej i bardziej szczegółowych informacji należy szukać w dokumentach rfc. Przykładowa konfiguracja została przedstawiona dla FreeBSD , dlatego nie musi działać na innych systemach operacyjnych. Opisując przykładową konfigurację założyłem, że czytelnik zna podstawowe zagadnienia związane z funkcjonowaniem sieci komputerowych, systemem DNS oraz routingiem. Artykuł w większości przypadków na pewno nie podaje rozwiązania na tacy. Aczkolwiek wzorując się na opisie konfiguracji można bez problemu sobie poradzić (szczególnie w BSD, linuksie - pomagając sobie podręcznikiem systemowym man(1) ).

Jeśli ktoś znajdzie jakieś błędy (a pewnie takie się znajdą), to jestem wdzięczny za wskazanie takowych.
Mam też świadomość tego, że mogłem nie do końca zrozumieć pewne rzeczy (lub po prostu o czymś nie wiedzieć, gdyż temat dość rozległy), dlatego też będę wdzięczny za wszelkie informację na ten temat.

Pozdrowienia dla wszystkich z kanału #bsdguru :-)


Podziękowania dla Raczka za udostępnienie komputera do testów,
michalo za udostępnienie testowego tunela i wsparcie.

Literatura: