Automatyczna konfiguracja IPv6 za pomocą DHCPv6

Automatyczna konfiguracja IPv6 za pomocą DHCPv6 Tomasz Mrugalski <spam@klub.com.pl> 1 Informacje wstępne: Rodzina protokołów IPv6 W niniejszym punkcie przedstawione zostały zagadnienia związane z rodziną protokołów IPv6. 1.1 Adresowanie w IPv6 Adresy IPv6 są przypisane interfejsom, czyli urządzeniom pozwalającym hostom na komunikację w sieci. Istnieją 3 typy adresów: unicast tradycyjny adres identyfikujący jednoznacznie pewien interfejs. To odpowiednik zwyczajnego adresu znanego z IPv4. multicast adres grupowy. Identyfikuje on pewną grupę hostów iub routerów. Dane wysyłane na taki adres dotrą do wszystkich, którzy do takiej grupy należą. Koncepcja adresów grupowych nie zmieniła się od czasów IPv4. anycast to zmodyfikowana wersja adresów multicastowych. Także taki rodzaj identyfikuje grupę hostów. W przeciwieństwie do multicastów, dane wysłane na adres anycastowy zostaną dostarczone tylko do jednego interfejsu identyfikowanego przez ten adres. Zwykle jest to interfejs najbliższy w sensie używanej metryki routingu. Należy zauważyć, że znane z IPv4 adresy rozgłoszeniowe (broadcast) nie zostały zdefiniowane dla IPv6. Ich rolę przejęły adresy multicast. 1.2 Notacja adresów Adresy IPv6 zwykle przedstawiane są w postaci szesnastkowej, przy czym po co czwartym znaku następuje znak,,:'', np.: 1234:5678:9ABC:DEF0:0000:0000:0000:0123 Ze względu na to, że przestrzeń adresowa jest ogromna, a co za tym idzie, wiele pól adresu ma wartość zerową, wprowadzono 2 ułatwienia w zapisie adresów. W każdym polu ograniczonym dwukropkami możliwe jest pominięcie początkowych, nieznaczących zer. Nie można jednak w ten sposób pominąć wszystkich znaków mieszczących się pomiędzy dwukropkami. Przedstawiony powyżej adres można więc zapisać krócej jako: 1234:5678:9ABC:DEF0:0:0:0:123 wprowadzono dodatkowy mechanizm umożliwiający pomijanie większej ilości zer następujących jedno po drugim. W takim przypadku omijane są całe przedziały składające się z samych zer. Można w ten sposób pominąć dowolną ilość przedziałów, ale tylko pod warunkiem, że sąsiadują one ze sobą. Mechanizm ten nosi nazwę kompresji zer. Dla danego adresu kompresję zer można zastosować tylko w jednym miejscu. Pominięte zera oznaczana są poprzez podwójny symbol,,:''. Zatem przedstawiony powyżej adres można skrócić jeszcze bardziej: 1234:5678:9ABC:DEF0::123 1/22

1.3 Prefiks i adres sieci W adresowaniu IPv6 zrealizowano ideę routingu bezklasowego. Oznacza to, że adres dzieli się na 2 części. Pierwsza z nich określa adres całej sieci, natomiast druga określa adres hosta w danej sieci. Długość adresu sieci zapisuje się poprzez dodanie znaku / na końcu adresu oraz podanie ilości bitów użytych do adresowania sieci. Adres samej sieci zapisujemy tak samo, jak zwykły adres. Jedyna różnica polega na tym, że końcówka adresu, normalnie używana do adresowania hostów w danej sieci, jest zastępowana zerami. Przykładowo adres 1234:5678:9ABC:DEF0::123/48 oznacza host o adresie DEF0::123 znajdujący się w sieci 1234:5678:9ABC::/48. 1.4 Zakres, a obszar ważności adresu Każdy adres posiada swój zakres ważności, czyli obszar w którym można z niego korzystać. Każdy adres w zakresie swojej ważności jest unikalny. Dostępne są następujące zakresy ważności: node Zakres jest ograniczony do lokalnego węzła. Przykładem takiego adresu jest ::1, czyli adres lokalny hosta. Każdy węzeł posiada taki adres, a mimo to nie ma konfliktu właśnie dzięki zastosowaniu zakresu ważności. link Ważność adresu obejmuje pojedyncze łącze. Z takiego zakresu korzysta np. protokół autokonfiguracji SAA. site Unikalność adresu w zakresie pojedynczego miejsca. Zwykle jest to zestaw segmentów sieci połącony razem, np. oddział firmy lub wydział uczelni. organization Ważność adresu obejmuje całą organizację. global To największy możliwy zakres ważności. Oznacza on, że dany adres jest unikalny w skali światowej i identyfikuje dany interfejs jednoznacznie. 1.5 Podział adresów W całej puli adresowej wydzielone zostały pewne obszary o specjalnym znaczeniu. Każdy adres należy do któregoś ze zdefiniowanych obszarów. Przynależność określa się za pomocą prefiksu. 2 ICMPv6 Przypisane adresy prefiks (hex) prefiks Zarezerwowane 00 /8 Globalne połączone adresu unicastowe 20 /3 Lokalne adresy unicastowe łącza fe80 /10 Lokalne adresy unicastowe miejsca fec0 /10 Adresy multicastowe ff /8 W porównaniu do poprzedniej wersji, protokół ICMP uległ ogromnym zmianom. Teraz w jego skład wchodzą: MLD (Multicast Listener Discovery) wykorzystywany do realizacji zadań związanych z obsługą grup. (W adresowaniu IPv6 rolę adresów broadcastowych przejęły adresy multicastowe, więc jest to znacząca część wszystkich usług.) ND (Neighbor Discovery) odkrywanie sąsiedztwa. Ten protokół ma za zadanie obsługę adresów warstwy łącza danych. Można go określić jako następcę protokołu ARP z dodatkowymi 2/22

możliwościami. Przechowuje bardziej szczegółowe informacje niż jego poprzednik, SAA (Stateless Address Autoconfiguration) protokół automatycznej adresacji węzłów na podstawie adresów warstwy łącza danych RR (Router Renumbering) związany z obsługą prefiksów i automatyzacją routerów IPv6 NI (Node Information Queries) definuje on obsługę zapytań do węzłów, w tym obsługę DNS. Obecnie ten protokół jest jeszcze w fazie standaryzacji. Z punktu widzenia laboratorium, ważne są protokoły Neighbor Discovery oraz Stateless Address Autoconfiguration, dlatego też te protokoły zostaną omówione poniżej w sposób bardziej szczegółowy. 2.1 Sposoby konfiguracji hostów W trakcie prac nad protokołami IPv6 ustalono, że nie powinna być wymagana ręczna konfiguracja węzłów przed włączaniem ich do sieci. W konsekwencji potrzebne okazało się wprowadzenie mechanizmów automatycznego określania parametrów pracy hosta. IPv6 definiuje 2 typy automatycznej adresacji: Stateless Address Autoconfiguration to wymagany i podstawowy element systemu autokonfiguracji. W prostszych konfguracjach jest to jedyna metoda konfiguracji hosta Stateful Address Autoconfiguration stosowane w przypadkach, kiedy wymagana jest większa kontrola nad przydzielanymi adresami. Przydzielaniem i zarządzaniem adresami w całej sieci zajmuje się serwer DHCP. Należy zauważyć, że jest to rozszerzona wersja konfiguracji hosta i działa ona w połączeniu z autokonfiguracją typu stateless. Warto zauważyć, że w obydwóch przypadkach nie jest konfigurowana domyślna brama. Za poprawne ustalenie domyślnego routingu odpowiedzialny jest protokół Router Renumbering. 2.2 Stateless Address Autoconfiguration (SAA) Po aktywowaniu interfejsu na danym łączu (np. podczas startu systemu) pierwszą wykonywaną czynnością jest wygenerowanie adresów lokalnych łącza. Początkowo adres ten zostaje oznaczony jako tymczasowy. Generowana jest wiadomość Neighbor Solicitation z właśnie wygenerowanym adresem tymczasowym jako adresem docelowym. Jeżeli adres ten jest używany przez jakiegokolwiek hosta, wygeneruje on odpowiedź Neighbor Advertisement. Jeżeli zostanie wykryta taka sytuacja, to proces autokonfiguracji zostaje zatrzymany i wymagana jest ręczna konfiguracja interfejsu. Warto zauważyć, że są to sytuacje rzadko spotykane i zazwyczaj nietypowe. Adres lokalny łącza generowany jest na podstawie adresu warstwy łącza danych, który jest unikalny dla wszystkich urządzeń, choć trzeba zaznaczyć, że w niektórych przypadkach istnieje ręczna możliwość jego zmiany. Adresy lokalne łącza tworzone są z rozszerzonego adresu warstwy łącza danych EUI 64 poprzez użycie prefixu FE80::0. Cechą charakterystyczną adresów lokalnych łącza jest to, że zarówno preferred lifetime, jak i valid lifetime są nieskończone. Po stwierdzeniu, że żaden host nie wygenerował Neighbor Solicitation uznaje się, że adres nie jest do tej pory używany i zostaje on przypisany do interfejsu. Od tej pory host posiada zdolność komunikacji z sąsiednimi węzłami w warstwie IP. Kolejnym krokiem jest ustalenie adresów lokalnych miejsca oraz globalnych. Warunkiem ich wykorzystania jest oczywiście istnienie routerów, które są w stanie przenosić ruch poza lokalne łącze. Istniejące routery okresowo generują wiadomości Router Advertisement informujący hosty, jaki 3/22

tryb autokonfiguracji powinien być przez nie wykorzystywany, a także inne dodatkowe informacje, jak np. prefiks sieci. Ze względu na to, że wiadomości te są generowane co pewien okres czasu, host może wymusić natychmiastowe wygenerowanie takiej wiadomości przez router. Robi to wysyłając wiadomość Router solicitation. Wiadomość Router Avertisement zawiera zero lub więcej informacji o prefiksie, które wykorzystywane są do generowania adresów lokalnych miejsca oraz globalnych. Po sprawdzeniu, czy zawarte informacje o prefiksach są poprawne, host na ich podstawie tworzy odpowiednie adresy. Istotnym ograniczeniem tego sposobu generowania adresów jest konieczność rozgłaszania klasy przynajmniej 64 bitowej. 2.3 Statefull Autoconfiguration Rozszerzeniem przedstawionego protokołu SAA jest protokół DHCPv6 i może on zostać użyty w celu przydzielania adresów lokalnych miejsca oraz globalnych. Oprócz możliwości alokowania wolnych adresów IP zgodnie z polityką ustaloną przez administratora, umożliwia on przysyłanie dodatkowych informacji konfiguracyjnch do klienta, takich jak konfiguracja serwerów DNS czy strefa czasowa. Szczegółowy opis protokołu DHCP znajduje się w punkcie 3. 2.4 Neighbor Discovery Aby skomunikować się z sąsiadującymi węzłami, konieczna jest znajomość ich adresów w warstwie łącza danych. Do ustalania tych adresów służy właśnie protokół Neighbor Discovery. Pełni on także ważną funkcję śledzenia dostępności sąsiadów oraz wykrywania ewentualnych zmian adresów warstwy łącza danych. Protokół ND udostępnia następujące mechanizmy: Rozpoznawanie routerów (Router Discovery) umożliwia hostowi lokalizowanie routerów, które dołączone są do tego samego łącza Rozpoznawanie prefiksu (Prefix Discovery) umożliwia hostowi znalezienie zbioru prefiksów adresów określających, które węzły docelowe dołączone są do tego samego łącza, co host Rozpoznawanie parametrów (Parameter Discovery) umożliwia otrzymanie takich parametrów łącza i sieci, jak np. MTU czy maksymalna ilość przeskoków (hop limit). Automatyczna konfiguracja adresów(address Autoconfiguration) procedura automatycznej konfiguracji, która została omówiona w poprzednim rozdziale. Odwzorowanie adresów (Address Resolution) ustalanie adresu łącza danych w przypadku, kiedy dany jest tylko adres IP Określania następnego przeskoku (Next hop Determination) wskazuje, na jaki adres mają być przesłane pakiety. Może to być adres routera lub adres hosta docelowego, jeżeli mamy do czynienia z ostatnim hopem. Wykrywania braku dostępności sąsiadów (Neighbor Unreachability Detection) umożliwia stwierdzenie nieosiągalności hosta. Wykrywania duplikatów adresów (Duplicate Address Detection) umożliwiający opisany w poprzednim podrozdziale mechanizm wykrywania, czy dany adres nie jest już wykorzystywany Przekierowanie (Redirect) umożliwia routerowi poinformowanie hosta, że istnieje inna, lepsza droga dla danych, które host chce transmitować przez dany router. Szczegółowy opis protokołu Neighbor Discovery leży poza zakresem tego laboratorium. 4/22

3 Opis protokołu DHCPv6 Poniższy opis protokołu DHCPv6 pochodzi z dokumentu RFC3315: Dynamic Host Configuration Protocol for IPv6. W wielu sytuacjach pożądane jest, aby wiele hostów w sieci było konfigurowalnych z jednego miejsca naraz. Tego typu scentralizowane zarządzanie konfiguracją wielu hostów, a nawet urządzeń sieciowych jest wysoce cenione przez administratorów. Jednym z protokołów umożliwiających wykonywanie tego typu czynności jest DHCP. Najnowsza jego wersja DHCPv6 została przewidziana do współpracy ze stacjami obsługującymi protokół IPv6. Protokół DHCP był już używany w rozwiązaniach opartych o IP w wersji 4. Ze względu na znaczne różnice pomiędzy IPv4 i IPv6, pomiędzy DHCP dla IPv4 oraz dla IPv6 zmieniono praktycznie całość protokołu. Poniżej został przedstawiony w skrócie protokół DHCPv6. 3.1 Informacje podstawowe W tym podpunkcie zostały przedstawione podstawowe pojęcia związane z protokołem DHCPv6. Protokół DHCPv6 jest protokołem typu klient serwer pozwalającym na przydzielanie i dzierżawę przez klienta od serwera adresów oraz innych parametrów konfiguracyjnych. 3.2 Porty UDP Komunikacja pomiędzy serwerem i klientem w protokole DHCPv6 odbywa się z wykorzystaniem protokołu UDP. Klienci nasłuchują wiadomości DHCP na porcie 546 UDP, natomiast serwery i przekaźniki nasłuchują wiadomości DHCP na porcie 547 UDP. 3.3 Adresy Zazwyczaj(o ile serwer nie zezwoli na wykorzystanie unicastu), klienci wysyłają wiadomości na adres multicastow wszystkich serwerów, natomiast serwer odpowiada wiadomościami przesyłanymi na adres lokalny łącza klienta.w DHCP wykorzystane są następujące adresy multicastowe: All_DHCP_Relay_Agents_and_Servers (FF02::1:2) multicastowy adres o zasięgu łącza używany przez klienta do komunikacji z sąsiadującymi przekaźnikami i serwerami. Wszystkie serwery i przekaźniki są członkami tej grupy multicastowej. All_DHCP_Servers (FF05::1:3) multicastowy adres o zasięgu miejsca używany przez przekaźniki do komunikacji z serwerami w przypadku, gdy przekaźnik chce wysłać wiadomość do wszystkich serwerów albo nie zna adresu unicastowego serwera. Zauważmy, że aby przekaźnik użył tego adresu, musi mieć adres o odpowiednim zasięgu dostępny dla serwerów. Wszystkie serwery w danym miejscu są członkami tej grupy multicastowej. 3.4 Czas w protkole DHCPv6 W tym punkcie zostaną zdefiniowane podstawowe timeouty związane z protokołem DHCPv6. T1 określa okres, po którym klient powinien się starać odnowić dzierżawę adresów i parametrów konfiguracyjnych u serwera, od którego je pierwotnie otrzymał T2 określa okres, po którym klient może się starać o odnowienie dzierżawy u innego serwera niż ten, który mu je pierwotnie przydzielił Valid lifetime określa okres, po którym klient powinien zaprzestać używania danego adresu i zdjąć go z interfejsu Preferred lifetime określa okres, po którym adres przechodzi w stan przedawniony(depreciated) i nie powinien być używany do zestawiania nowych połączeń 5/22

Wszystkie czasy T1, T2, valid lifetime i prefered lifetime są określane przez serwer i przekazywane klientowi. Czasy valid lifetime i prefered lifetime są związane z każdym z przydzielanych adresów, natomiast czasy T1 i T2 ze strukturą grupującą adresy tzw. Identity Association. 3.5 IA Identity Association IA pozwala na identyfikację, grupowanie i zarządzanie zbiorem powiązanych adresów IPv6. Każde IA składa się z identyfikatora IAID (32 bitowy identyfikator generowany przez klienta), czasów T1 i T2 oraz jednego lub więcej adresów IPv6. Każdy adres zawarty w IA ma określony preferred lifetime i valid lifetime. Czasy T1 i T2 są przesyłane od serwera DHCP do klienta w opcji IA_ NA. Klient musi związać przynajmniej jedno różne IA dla każdego ze swoich interfejsów sieciowych, dla których chce mieć przypisane adresy IPv6. Klient używa IA przypisanych interfejsowi w celu otrzymania informacji konfiguracyjnej od serwera dla tego interfejsu. Każde IA musi być przypisane do dokładnie jednego interfejsu. Identyfikator IAID jednoznacznie identyfikuje IA i musi być unikalny wśród identyfikatorów IAID klienta. Identyfikator IAID jest wybierany przez klienta. Przy odwoływaniu się do danego IA przez klienta, identyfikator IAID dla tego IA musi pozostawać niezmienny pomiędzy odwołaniami, nawet w przypadku restartów klienta. Klient może spełnić ten warunek np. poprzez przechowywanie IAID w pamięci nie ulotnej lub używając algorytmu, który będzie dawał to samo IAID o ile konfiguracja klienta się nie zmieniła. Jeśli klient nie posiada pamięci nie ulotnej i występują zmiany w konfiguracji może nie istnieć sposób, aby zachowywać to samo IAID pomiędzy odwołaniami. 3.6 Unikalny identyfikator DHCP (DUID DHCP Unique Identifier) Ponieważ komunikacja klient serwer odbywa się przy użyciu multicastu musi istnieć sposób na rozróżnianie partnera w komunikacji (przykładowo klient chcąc przydzielić adresy od danego serwera musi w jakiś sposób określić ten serwer). W tym celu wprowadzone zostały w protokole DHCP identyfikatory DUID. Każdy klient i serwer DHCP posiada swój własny identyfikator DUID. Serwery DHCP używają identyfikatorów DUID do zidentyfikowania klienta przy wyszukiwaniu parametrów konfiguracyjnych i kojarzeniu klienta z jego IA. Klienci DHCP używają identyfikatorów DUID w otrzymanym wiadomości do identyfikacji serwera. W punktach 5.2 i 5.3 zostało opisane kodowanie identyfikatora DUID w wiadomości DHCP. Należy zauważyć, że podstawą do identyfikacji klienta/serwera nie jest ani adres warstwy łącza danych, ani adres lokalny łącza, a identyfikator DUID. Identyfikator DUID jest przenoszony jako opcja (patrz opcje Server Identifier i Client Identifier), ponieważ może być zmiennej długości i nie musi występować w każdej wiadomości DHCP. Identyfikator DUID jest zaprojektowany w taki sposób, aby każdy serwer i klient miał różny, unikalny i stały DUID tzn. DUID używany przez danego klienta lub serwer nie powinien być zmieniany w czasie, o ile tylko to jest możliwe np. nie powinien się zmieniać w wyniku zmian w osprzęcie sieciowym urządzenia. Przyczyną istnienia wielu typów identyfikatorów DUID jest potrzeba, aby DUID był globalnie unikalny i jednocześnie łatwy do wygenerowania. Niektóre urządzenia mogą nie zawierać jakiejkolwiek pamięci nieulotnej. Przetrzymywanie stałego DUID w takim urządzeniu jest oczywiście niemożliwe, zatem sposób generowania DUID musi również brać pod uwagę takie urządzenia. DUID składa się z dwubajtowego pola określającego typ DUID a, po którym następuje zmienna liczba bajtów tworzących właściwy identyfikator DUID. DUID nie może być dłuższy niż 128 bajtów (bez pola określającego typ). Obecnie są zdefiniowane następujące typy: 6/22

Tworzony na podstawie adresu warstwy łącza danych i aktualnego czasu (tzw. DUID LLT). Ten rodzaj identyfikatora DUID składa się z dwubajtowego pola typu zawierającego wartość 1, dwóch bajtów kodu określającego typ sprzętu, czterech oktetów zawierających czas, po którym następuje adres warstwy łącza danych któregokolwiek z interfejsów sieciowych dołączony do urządzenia DHCP w momencie generowania identyfikatora DUID. Hardware type typ sprzętu określony przez IANA w RFC 826 (np. dla Ethernetu 6) Time liczba sekund, które upłynęły od północy(utc) 1 stycznia 2000 modulo 2^32 Link layer address adres warstwy łącza danych Przypisywany przez producenta przy użyciu numeru korporacyjnego (DUID EN). Ta forma identyfikatora DUID jest przypisywana urządzeniu przez jego producenta. Składa się z zarejestrowanego przez producenta prywatnego numeru korporacyjnego, po którym następuje unikalny identyfikator urządzenia nadawany przez producenta. Numery koroporacyjne są zarządzane i wydawane przez IANA. Poniższy rysunek przedstawia strukturę identyfikatora DUID nadawanego przez producenta: Enterprise number numer korporacyjny przydzielony producentowi przez IANA Identifier unikalny identyfikator określany przez producenta urządzenia Przy użyciu adresu warstwy łącza danych (DUID LL). Ten typ identyfikatora DUID składa się z dwóch oktetów określającyh typ i mających wartość 3, dwóch oktetów określająch typ sprzętu sieciowego, po których następuje adres warstwy łącza danych któregokolwiek z interfejsów sieciowych, na stałe przyłączonych do urządzenia. Przykładowo host, który ma interfejs sieciowy zaimplementowany w układzie scalonym, który prawdopodobnie nie zostanie usunięty i użyty w innym urządzeniu może używać tego typu identyfikatora DUID. Hardware type typ sprzętu określony przez IANA w RFC 826 (np. dla Ethernetu 6) Link layer address adres warstwy łącza danych 4 Format wiadomości DHCPv6 Wszystkie wiadomości wysyłane pomiędzy klientem i serwerem mają identyczny i stały format nagłówka i zmienny format pola opcji. Opcje są zapamiętywane kolejno w polu opcji. Poniższy rysunek pokazuje format wiadomości DHCP wysyłanych pomiędzy klientem i serwerem: 4 5 6 7 8 9 4 5 6 7 8 9 4 5 6 7 8 9 0 1 msg type transaction id options (zmienna długość) msg type określa typ wiadomości DHCP; dostępne typy wiadomości podane zostały w następnym punkcie transaction id identyfikator danej wymiany wiadomości options opcje wiadomości; opcje są opisane w punkcie 3 7/22

4.1 Typy wiadomości DHCPv6 Więcej szczegółów dotyczących tych wiadomości można znaleźć w dalszej części instrukcji. W nawiasach zostały podane kody odpowiadające danemu typowi wiadomości (pole msg type w wiadomości). DHCP definiuje następujące typy wiadomości: SOLICIT (1) klient wysyła wiadomość SOLICIT w celu lokalizacji serwerów oraz uzyskania informacji o dostępnych adresach oraz opcjach. ADVERTISE (2) serwer wysyła wiadomość ADVERTISE w celu poinformowania, że jest gotowy do obsługi klienta, w odpowiedzi na wiadomość SOLICIT od klienta. REQUEST (3) klient wysyła wiadomość REQUEST, aby otrzymać parametry konfiguracyjne (m.in. adres IP) od serwera. CONFIRM (4) klient wysyła wiadomość CONFIRM do serwera, aby określić, czy adresy, które zostały mu przypisane, są nadal prwidłowe dla łącza, do którego jest dołączony. RENEW (5) klient wysyła wiadomość RENEW do serwera, który pierwotnie dostarczył adresy klienta i parametry konfiguracyjne, aby przedłużyć czas ważności przypisanych adresów i uaktualnić parametry konfiguracyjne (po czasie T1) REBIND (6) klient wysyła wiadomość REBIND do jakiegokolwiek dostępnego serwera, aby przedłużyć czas ważności przypisanych mu adresów oraz uaktualnić inne parametry konfiguracyjne; ta wiadomość jest wysyłana po tym, jak klient nie otrzyma odpowiedzi na wiadomość RENEW (po czasie T2) REPLY (7) serwer wysyła wiadomość REPLY zawierającą przypisane adresy i parametry konfiguracyjne w odpowiedzi na wiadomości SOLICIT, REQUEST, RENEW, REBIND otrzymane od klienta. Serwer wysyła wiadomość REPLY zawierający parametry konfiguracyjne w odpowiedzi na wiadomość INFORMATION REQUEST. Serwer wysyła wiadomość REPLY w odpowiedzi na wiadomość CONFIRM, potwierdzając lub nie, że klient jest dołączony do właściwego łącza. Serwer odpowiada również wiadomością REPLY, aby potwierdzić otrzymanie wiadomości RELEASE lub DECLINE. RELEASE (8) klient wysyła wiadomość RELEASE do serwera, który przypisał mu adresy, aby poinformować, że klient nie będzie używał jednego lub więcej z przypisanych mu wcześniej adresów DECLINE (9) klient wysyła wiadomość DECLINE do serwera, aby poinformować, że klient wykrył, że jeden lub więcej adresów przypisanych przez serwer jest już używany na łączu, do którego klient jest dołączony RECONFIGURE (10) serwer wysyła wiadomość RECONFIGURE, aby poinformować klienta, że serwer ma nowe lub uaktualnione parametry i klient ma zainicjować wymianę wiadomości RENEW REPLY lub INFORMATION REQUEST REPLY z serwerem w celu otrzymania uaktualnionych informacji INFORMATION REQUEST (11) wiadomość żądająca, aby serwer podał parametry konfiguracyjne bez przypisywania adresów IPv6 klientowi 4.2 Użycie identyfikatora transakcji Zazwyczaj wymiana wiadomości pomiędzy klientem, a serwerem ma postać transakcji tj. pytania 8/22

klienta i odpowiedzi serwera. Przykładowe transakcje: SOLICIT ADVERTISE, REQUEST REPLY, RENEW REPLY, SOLICIT_z_Rapid_Commit REPLY_z_Rapid_Commit, REBIND REPLY, RELEASE REPLY. Pole identyfikator transakcji (patrz format wiadomości DHCPv6) przechowuje wartość używaną przez klientów i serwery do synchronizacji odpowiedzi serwera z zapytaniami klienta. Za każdym razem, gdy klient rozpoczyna nową transakcję, powinien generować losową liczbę jako identyfikator transakcji. Klient musi pozostawiać niezmieniony identyfikator transakcji przy retransmisji wiadomości (zabezpiecza przed błędną interpretacją odpowiedzi). 4.3 Transmisja komunikatów przez klienta Klient najczęściej wysyła komunikaty DHCP na adres All_DHCP_Relay_Agents_and_Servers. Klient używa multicastu do połączenia się z wszystkimi lub pojedynczym serwerem. Jeżeli adresatem ma być pojedynczy serwer jest on wskazywany poprzez DUID serwera w opcji Server Identifier w wiadomości wysyłanej przez klienta (wszystkie serwery otrzymają ten komunikat, ale wskazany serwer przez opcję Server Identifier odpowie). W przypadku braku tej opcji odbiorcą komunikatu są wszystkie serwery. Klient może również wysłać komunikat bezpośrednio do serwera przy użyciu unicastu, ale pod warunkiem, że serwer na to zezwoli, wysyłając klientowi wcześniej opcję Server Unicast. 4.4 Poprawność wymiany wiadomości inicjowanej przez klienta Klienci DHCP są odpowiedzialni za niezawodne dostarczenie wiadomości w przypadku wymiany wiadomości inicjowanej przez klienta (zazwyczaj to klient inicjuje wymianę wiadomości). Jeśli klient DHCP nie otrzyma spodziewanej odpowiedzi od serwera musi retransmitować swoją wiadomość. Zasadniczo do retransmisji komunikatów używany jest algorytm binarno wykładniczy (informacje szczegółowe patrz RFC 3315). 4.5 Typowe transakcje pomiędzy klientem i serwerem DHCPv6 Ten punkt opisuje typowe transakcje występujące w protokole DHCPv6: Okrywanie serwera przez klienta Przydzielanie adresów i parametrów konfiguracyjnych Odnawianie dzierżawy Zwalnianie adresów 4.6 Proces odkrywania serwera Ten punkt opisuje sposób odkrywania serwerów, które mogą przypisać adresy do IA należących do klienta. Klient jest odpowiedzialny za utworzenie IA i żądanie od serwera przypisania do nich adresów IPv6. Klient najpierw tworzy IA i przypisuje mu identyfikator IAID. Następnie klient transmituje komunikat SOLICIT zawierający opcję IA_NA opisującą IA. Serwery, które mogą przypisać adres do IA odpowiadają klientowi komunikatem ADVERTISE. Klient gromadzi odpowiedzi serwerów, wybiera na ich podstawie serwer(y) i inicjuje z nim(i) wymianę informacji konfiguracyjnych (wymiana komunikatów REQUEST REPLY), co zostało opisane w następnym punkcie. Jeśli klient jest gotowy do zaakceptowania komunikatu REPLY z przypisanym adresem i innymi zasobami w odpowiedzi na komunikat SOLICIT, klient załącza opcję Rapid Commit w komunikacie SOLICIT. Pozwala to na skrócenie liczby wymienianych wiadomości z 4 (SOLICIT, ADVERTISE, REQUEST, REPLY) do 2 (SOLICIT, REPLY). Ponieważ serwer w momencie wysłania komunikatu REPLY ostatecznie przydziela adresy i inne parametry konfiguracyjne klientowi, należy zapewnić, aby na jednym łączu istniał tylko jeden serwer mogący odpowiadać na wiadomość 9/22

SOLICIT z opcją Rapid Commit, dzięki czemu uniknie się podwójnego i błędnego przydzielenia zasobów przez kilka serwerów. Komunikat SOLICIT jest zawsze wysyłany na adres multicastowy wszystkich serwerów i przekaźników, nie zawiera DUID a serwera (służy do odkrycia serwera); zawiera DUID klienta (opcja Client Identifier); zawiera propozycje adresów(opcja IA_NA) i żądanie innych parametrów konfiguracyjnych przez klienta (opcja Option Request) ewentualnie wraz z podpowiedziami (inne opcje np. DNS Servers) Komunikat ADVERTISE jak wszystkie komunikaty wysyłane przez serwer jest wysyłany na adres lokalny łącza klienta, zawiera DUID serwera (aby klient rozpoznał serwer i mógł skierować komunikat REQUEST do właściwego serwera opcja Serwer Identifier), zawiera DUID klienta (w ten sposób klient rozpoznaje, że jest to odpowiedź kierowana do niego opcja Client Identifier), zawiera oferowane przez serwer adresy (opcja IA_NA) i inne parametry konfiguracyjne (np. opcje DNS Servers). W komunikacie ADVERTISE może zostać zawarta opcja Preference określającą stopień preferencji danego serwera. Klient powinien wybrać serwer o większym stopniu preferencji (patrz opcja Preference). Jeżeli serwer nie jest w stanie przydzielić adresów zawiera opcję Status Code o wartości NoAddrAvail. Wiadomości z taką opcją powinny być ignorowane przez klienta. 4.7 Proces przydzielenia adresów i parametrów konfiguracyjnych Po zebraniu odpowiedzi ADVERTISE i wybraniu serwera oferująca najlepsze parametry, klient generuje komunikat REQUEST w celu przypisania adresów do IA, a także zdobycia innych informacji konfiguracyjnych. Serwer po otrzymaniu wiadomości REQUEST odpowie zwykle komunikatem REPLY z przydzielonymi odpowiednimi adresami i opcjami. Jeśli klient załączy opcję Rapid Commit w komunikacie SOLICIT, będzie się spodziewał komunikatu REPLY, który będzie zawierał opcję Rapid Commit. Klient odrzuca otrzymywane komunikaty REPLY, które nie zawierają opcji Rapid Commit. Jeśli klient otrzyma komunikat REPLY z opcją Rapid Commit, przetwarza ten komunikat. Klient może też w takim przypadku zbierać komunikaty ADVERTISE będące odpowiedziami na jego komunikat SOLICIT, a wysyłane przez serwery nie obsługujące opcji Rapid Commit. Jeżeli klient nie otrzyma komunikatu REPLY z opcją Rapid Commit może wybrać serwer na podstawie jednego z otrzymanych komunikatów ADVERTISE. Dwa możliwe sposoby odkrywania serwera i przydzielania parametrów konfiguracyjnych zostały przedstawione na poniższym rysunku: 10/22

Transkacje: SOLICIT ADVERTISE i REQUEST REPLY Transkacja: SOLICIT REPLY K l i e n t S e r w e r S O L C I T K l i e n t S e r w e r A D V E R T I S E R E Q U E S T ( m c a s t, a l e d o 1 s e r w. ) S O L C I T ( z o p c j š R A P I D C O M M T ) R E P L Y ( z o p j š R A P I D C O M M I T ) R E P L Y Należy zauważyć, że klient wysyła komunikat REQUEST zawsze na adres multicastowy i zwykle z takimi samymi opcjami, jak komunikat SOLICIT. Jednak zawsze dołącza dodatkową opcję Serwer Identifier. Dzięki tej opcji tylko wybrany przez klienta serwer odpowie na jego żądanie i przydzieli klientowi odpowiednie zasoby. Komunikat REPLY jest wysyłany na adres lokalny łącza klienta, zawiera DUID serwera (opcja Serwer Identifier), zawiera identyfikator klienta (opcja Client Identifier), zawiera oferowane przez serwer adresy (opcja IA_NA) i inne parametry konfiguracyjne (np. opcje DNS Servers). Zauważmy, że w opcji IA_NA podane są określane przez serwer czasy T1 i T2, a także podopcje IA_Address, z których każda zawiera adres wraz z czasami valid i preferred lifetime. 4.8 Proces odnawiania dzierżawy adresów i parametrów konfiguracyjnych Po upływie czasu T1 od momentu otrzymania adresu klient zobowiązany jest rozpocząć proces odświeżania dzierżawy adresów i parametrów konfiguracyjnych. Klient wysyła wówczas komunikat RENEW do serwera, który pierwotnie dostarczył mu adresy i parametry konfiguracyjne. Serwer odpowiada wiadomością REPLY określając nowe czasy życia dla poszczególnych adresów zgodnie z ustawionymi parametrami administracyjnymi. Serwer może też dodać nowe adresy albo usunąć stare adresy poprzez ustawienie valid i prefered lifetime czasu życia tych adresów na zero. Serwer kontroluje również czas, kiedy klient skontaktuje się z serwerem w celu przedłużenia czasów życia nadanych mu adresów poprzez parametry T1 i T2 nadane konkretnemu IA. UWAGA: Czasy T1 i T2 są związane z danym IA, a nie z adresami zawartymi w tym IA. Stąd po upłynięciu czasu T1 dla danego IA wszystkie adresy zawarte w nim zawarte są odnawiane. Wiadomość RENEW jest wysyłana najczęściej na adres multicastowy (może, o ile serwer zezwoli, na adres unicastowy patrz opcja Option Unicast), zawiera DUID serwera (bo kierowana jest do konkretnego serwera tego który przydzielił adresy), zawiera DUID klienta, zawiera jedną lub więcej opcji IA, w których zawarte adresy powinny zostać przedłużone oraz ewentualnie inne parametry konfiguracyjne, które chciałby odświeżyć. Wiadomość REPLY wysyłana jest jak zwykle na adres unicastowy klienta i zawiera oprócz identyfikatorów serwera i klienta, uaktualnioną informację konfiguracyjną. 11/22

K l i e n t S e r w e r R E N E W R E P L Y 4.9 Proces zwalniania adresu Jeżeli klient nie chce dalej korzystać z jednego lub więcej przydzielonych mu adresów (np. przy zamykaniu systemu operacyjnego) powinien je zwolnić. Wykonuje to poprzez wysłanie do serwera wiadomości RELEASE. K l i e n t S e r w e r R E L E A S E R E P L Y Jeżeli klient nie chce dalej korzystać z jednego lub więcej przydzielonych mu adresów (np. przy zamykaniu systemu operacyjnego) powinien je zwolnić. Wykonuje to poprzez wysłanie do serwera wiadomości RELEASE. W wiadomości tej zawiera wszystkie adresy, które chciałby zwolnić. 4.10 Współpraca DHCPv6 z konfiguracją Stateless Protokół DHCPv6 może także stanowić uzupełnienie protokołu SAA. Protokół SAA zapewnia tylko przydzielenie adresu. Jeżeli adresy przydzielone w procesie autokonfiguracji są odpowiednie (np. nie chcemy przydzielać adresów globalnych), wówczas protokół DHCPv6 może zostać wykorzystany tylko do przydziału innych parametrów konfiguracyjnych (serwer DNS, NTP, NIS ). W tym celu twórcy protokołu DHCPv6 przewidzieli wymianę komunikatów INFORMATION REQUEST REPLY. Komunikat INFORMATION REQUEST powinien zawierać opcje Option Request. Opcja ta zawiera numery opcji żądanych przez klienta. Ponadto klient może umieścić w wiadomości INFORMATION REQUEST te opcje wraz z preferowanymi wartościami. Inną obowiązkową opcją, która powinna się znaleźć w komunikacie to Client Identifier. K l i e n t S e r w e r I N F O R M A T I O N R E Q U E S T R E P L Y Serwer po otrzymaniu wiadomości INFORMATION REQUEST odpowiada wiadomością REPLY zawierającą oferowane przez serwer wartości żądanych przez klienta opcji. Ponadto wiadomość REPLY zawiera identyfikator DUID klienta i identyfikator DUID serwera. 4.11 Sytuacje nietypowe i wyjątkowe (dla bardziej dociekliwych) W poniższym punkcie zostały przedstawione informacje związane z następującymi sytuacjami nietypowymi i wyjątkowymi: Awaria serwera podstawowego Wykrywanie zduplikowanych adresów Zmiana łącza lub awaria klienta 12/22

4.12 Awaria serwera podstawowego (komunikat REBIND) Po upływie czasu T1 klient rozpoczyna proces odnawiania dzierżawy wysyłają wiadomość RENEW. Jeżeli klient nie otrzyma odpowiedzi do upłynięcia czasu T2, zaprzestaje retransmisji komunikatu RENEW, a rozpoczyna transmisję komunikatu REBIND. Komunikat REBIND, w przeciwieństwie do komunikatu RENEW, nie zawiera opcji Serwer Identifier i jest kierowany do wszystkich serwerów. Pozwala to serwerowi zapasowemu przejąć rolę serwera podstawowego. Serwer, który otrzyma komunikat REBIND i może przedłużyć adresy klientowi, odpowiada komunikatem REPLY. Najczęściej będzie to serwer zapasowy, ale również może być to serwer podstawowy, który pierwotnie przydzielił adresy klientowi (a w wyniku awarii łącza nie był w stanie odpowiadać). K l i e n t S e r w e r R E N E W ( m c a s t, a l e d o 1 s e r w. ) R E P L Y R E N E W ( m c a s t, a l e d o 1 s e r w. ) R E P L Y R E B I N D R E P L Y Komunikat REBIND będzie zawierał te same opcje, co komunikat RENEW za wyjątkiem wspomnianej opcji Serwer Identifier. Kierowany jest zawsze na adres multicastowy. Wiadomość REPLY wysyłana jest na adres unicastowy klienta i zawiera oprócz identyfikatorów serwera(może się zmienić na inny) i klienta, uaktualnioną informację konfiguracyjną. 4.13 Wykrywanie zduplikowanych adresów Klient przydzielając jakikolwiek adres unicastowy do interfejsu zobowiązany jest do przeprowadzenia procedury detekcji podwójnych adresów (patrz punkt 2.2). Jeżeli klient wykryje, że adres przypisany przez serwer jest już przydzielony na łączu, do którego jest dołączony, nie może używać tego adresu oraz zobowiązany jest o tym poinformować serwer wysyłając wiadomość DECLINE. Serwer odpowiada wiadomością REPLY informując klienta, że otrzymał tę informację klienta (zapobiega to retransmisji wiadomości DECLINE przez klienta). K l i e n t D E C L I N E S e r w e r R E P L Y Wiadomość DECLINE opcję(e) IA_NA zawierającą zduplikowany(e) adres(y), identyfikatory DUID klienta i serwera (opcje Client Identifier i Serwer Identifier). Serwer odpowiada wiadomością REPLY zawierającą te same opcje, co wiadomość DECLINE. 13/22

4.14 Zmiana łącza/awaria klienta Kiedy klient przemieszcza się z jednego łącza do innego, może się okazać, że prefiks, z którego korzystał do tej pory nie jest już właściwy. Przykłady podobnych zdarzeń: klient zostaje ponownie uruchomiony klient zostaje fizycznie podłączony do sieci klient używa technologii bezprzewodowej i właśnie zmienił stację bazową W każdej takiej sytuacji, klient powinien zainicjować transakcję CONFIRM REPLY. K l i e n t S e r w e r C O N F I R M R E P L Y Wiadomość CONFIRM jest przesyłana na adres multicastowy wszystkich serwerów i przekaźników DHCPv6. Jest kierowana do wszystkich serwerów, więc nie zawiera DUID a serwera. Powinna natomiast zawierać DUID klienta oraz opcje IA_NA dla wszystkich IA, które są przypisane do interfejsu, dla którego wiadomość jest wysyłana. W przypadku zmiany łącza wiadomość CONFIRM zostanie wysłana dla jednego interfejsu, natomiast w przypadku restartu klienta wiadomość CONFIRM zostanie wysłana dla każdego z interfejsów. Serwery odpowiadają wiadomością REPLY określającą, czy adresy zawarte w opcjach IA_NA są aktualne dla aktualnego łącza klienta. 5 Opcje DHCPv6 Opcje są używane do przenoszenia dodatkowych informacji i parametrów w wiadomości DHCP. Wszystkie opcje mają wspólny format opisany poniżej. Wszystkie wartości w opcji są zapisywane w porządku sieciowym bajtów. 5.1 Format opcji DHCP Format opcji DHCP jest następujący: 4 5 6 7 8 9 4 5 6 7 8 9 4 5 6 7 8 9 0 1 Option code Option len Option data (option len oktetów) option code liczba całkowita bez znaku określająca typ przenoszonej opcji option len liczba całkowita bez znaku podająca długość pola option data tej opcji w oktetach option data dane opcji, format danych zależy od danej opcji 14/22

Niektóre opcje DHCPv6 mogą być zawarte w innych opcje mogą być zawarte w innych. Przykładowo opcja IA Address może pojawić się tylko w opcji IA_NA. 5.2 Opcja Client Identifier Opcja Client Identifier jest używana do przenoszenia identyfikatora DUID umożliwiającego identyfikację klienta w komunikacji klient serwer. Format opcji Client Identifier jest następujący: 4 5 6 7 8 9 4 5 6 7 8 9 4 5 6 7 8 9 0 1 OPTION_CLIENTID option len DUID (zmienna długość) option code OPTION_CLIENTID (1) option len długość DUID w oktetach option data DUID klienta w formacie wcześniej opisanym 5.3 Opcja Server Identifier Opcja Serwer Identifier jest używana do przenoszenia identyfikatora DUID, umożliwiając klientowi identyfikację serwer w komunikacji klient serwer. Format opcji Server Identifier jest następujący: 4 5 6 7 8 9 4 5 6 7 8 9 4 5 6 7 8 9 0 1 OPTION_SERVERID option len DUID (zmienna długość) option code OPTION_SERVERID (1) option len długość DUID w oktetach option data DUID serwera w formacie wcześniej opisanym 5.4 Opcja Identity Association for Non temporary Addresses Opcja IA dla adresów nietymczasowych (IA_NA) jest używana do przenoszenia IA, parametrów związanych z IA i nietymczasowych adresów związanych z opcją IA_NA. Adresy pojawiające się w opcji IA_NA nie są adresami tymczasowymi (patrz punkt Opcja IA_TA ). Format opcji IA_NA ma postać: 4 5 6 7 8 9 4 5 6 7 8 9 4 5 6 7 8 9 0 1 OPTION_IA_NA option len IAID (4 oktety) 15/22

T1 T2 IA_NA Options option code OPTION_IA_NA (3) option len 12 + długość pola opcje IA_NA option data unikalny identyfikator dla IA ; IAID. Identyfikator musi być unikalny wśród wszystkich identyfikatorów IA klienta. T1 Czas, po którym klient kontaktuje się z serwerem, od którego otrzymał pierwotnie adres w IA_NA w celu przedłużenia czasu dzierżawy przypisanego do adresów w IA_NA. T1 określa przedział czasu wyrażony w sekundach. T2 Czas, po którym klient kontaktuje się z dowolnym serwerem, w celu przedłużenia czasu dzierżawy przypisanego adresom w danym IA_NA. T2 określa przedział czasu wyrażony w sekundach. IA_NA Options Opcje związane z danym IA_NA. Pole IA_NA zwiera te opcje, które są charakterystyczne dla IA_NA. Przykładowo wszystkie opcje IA Address przenoszące adresy związane z danym IA znajdą się w polu IA_NA Options opcji IA_NA. Opcja IA_NA może pojawić się bezpośrednio w wiadomości DHCP. Wiadomość DHCP może zawierać wiele opcji IA_NA. Kod stanu operacji wykorzystującej opcję IA_NA jest podawany w opcji Status Code w polu IA_NA options. Zauważmy, że IA_NA nie posiada jawnie podanego czasu życia lub czasu dzierżawy dla samej siebie. Kiedy poprawny czas życia wszystkich adresów w IA_NA wygaśnie, uważa się, że samo IA_NA również traci ważność. Czasy T1 i T2 są załączane, aby pozwolić serwerowi na kontrolę momentu, w którym klient powinien ponownie skontaktować się z serwerem, w celu odświeżenia danych w IA_NA. W wiadomości wysyłanej przez klienta do serwera, wartości T1 i T2 wskazują, jakie są preferencje klienta, jeśli chodzi o te parametry. Wartości T1 i T2 ustawione na 0 oznaczają brak preferencji. W wiadomości wysyłanej od serwera do klienta, wartości T1 i T2 muszą zostać wykorzystane przez klienta. Serwer wybiera T1 i T2 tak, aby pozwolić klientowi na przedłużenie czasu życia każdego adresu z IA_NA zanim adres straci ważność nawet wówczas, gdy serwer będzie niedostępny przez pewien krótki okres czasu. Rekomendowane wartości T1 i T2 to odpowiedni.5 i.8 najkrótszego preferowanego czasu życia w IA. Jeśli czas, po którym adresy w IA_NA powinny być odnowione ma być ustalany przez klienta, serwer ustawia T1 i T2 na 0. 5.5 Opcja IA Address Opcja IA Address jest używana do przenoszenia adresów IPv6 związanych z danym IA. Opcja IA Address musi być enkapsulowana w polu opcji opcji IA (patrz opcja IA_NA). Pole opcji enkapsuluje te opcje, które są specyficzne dla tego adresu. Format opcji IA Address jest następujący: 4 5 6 7 8 9 4 5 6 7 8 9 4 5 6 7 8 9 0 1 OPTION_IAADDR option len 16/22

IPv6 address Preferred lifetime Valid lifetime IAAddr options option code OPTION_IAADDR (5) option len 24 + długość pola IAAddr options IPv6 address adres IPv6 preferred lifetime preferowany czas życia adresu IPv6 w opcji wyrażony w sekundach valid lifetime czas ważności adresu IPv6 wyrażony w sekundach IAAddr options opcje związane z tym adresem W wiadomości wysyłanej przez klienta, wartości pól preferred lifetime i valid lifetime oznaczają klienta preferencje w stosunku do odpowiednich parametrów. Jeśli klient nie ma preferencji związanych z tymi parametrami, ustawia je na zero. W wiadomości wysyłanej przez serwer klient musi zaakceptować oba podane przez serwer wartości w polach preferred lifetime i valid lifetime. Wartości w obu polach oznaczają liczbę sekund pozostałą do upłynięcia odpowiednio czasu życia i ważności adersu. Opcja IA Address może pojawić się tylko w opcji IA_NA. Więcej niż jedna opcja IA Address może pojawić się zarówno w opcji IA_NA. Stan operacji z użyciem danej opcji IA Address może być przenoszony w opcji Status Code w polu IAAddr options. 5.6 Opcja Preference Opcja Preference jest wysyłana przez serwer do klienta, aby wpłynąć na wybór serwera przez klienta. Format tej opcji jest następujący: 4 5 6 7 8 9 4 5 6 7 8 9 4 5 6 7 8 9 0 1 OPTION_PREFERENCE option len pref value option code OPTION_PREFERENCE (7) option len 1 pref value wartość preferencji serwera dla tej wiadomości ( im większa wartość tym serwer bardziej preferowany) Serwer może załączyć opcję Preference w wiadomości ADVERTISE, aby kontrolować wybór serwera przez klienta. W punkcie opisującym proces odkrywania serwera został opisany sposób użycia opcji Preference przez klienta i interpretację wartości opcji. 5.7 Opcja Elapsed Time 17/22

4 5 6 7 8 9 4 5 6 7 8 9 4 5 6 7 8 9 0 1 OPTION_PREFERENCE option len elapsed time option code OPTION_ELAPSED_TIME (8) option len 2 elapsed time określa czas, jak długo klient próbuje zakończyć jego obecną transakcję z serwerem DHCP. Czas ten wyrażony jest w setnych sekundy. Klient musi załączyć opcję Elapsed Time w komunikacie, aby wskazać jak długo klient próbuje zakończyć wymianę komunikatów DHCP. Okres ten jest mierzony od momentu, w którym klient wysłał pierwszy komunikat podczas danej wymiany komunikatów. W przypadku, gdy jest to pierwsza wiadomość pole powinno zostać ustawione na 0. Serwery i agenty przekazywania (Relsy Agents) używają wartości zawartej w tej opcji do kontrolowania, jak serwer odpowiada na wiadomości klienta. Przykładowo opcja Elapsed Time pozwala, aby zapasowy serwer DHCP odpowiedział na żądanie, gdy podstawowy serwer nie odpowiedział w odpowiednio krótkim czasie. 5.8 Opcja Server Unicast Serwer wysyła tę opcję do klienta, aby poinformować klienta, że może używać adresu unicastowego przy wysyłaniu wiadomości do serwera. Format opcji Serwer Unicast jest następujący: 4 5 6 7 8 9 4 5 6 7 8 9 4 5 6 7 8 9 0 1 OPTION_UNICAST option len IPv6 address option code OPTION_UNICAST (12) option len 16 server address adres IP, na który klient powinien wysyłać wiadomości przy użyciu unicastu Serwer określa adres IPv6, na który klient ma wysyłać wiadomości przy użyciu unicast u w polu serwer address. Kiedy klient otrzymuje tę opcję, kiedy jest to możliwe, klient wysyła wiadomośći bezpośrednio do serwera przy użyciu adresu podanego w polu server address tej opcji. 5.9 Opcja Status Code Ta opcja pozwala zwrócić kod stanu operacji związanej z daną wiadomością DHCP lub opcją, która się w niej znajdowała. Format opcji Status Code jest następujący: 4 5 6 7 8 9 4 5 6 7 8 9 4 5 6 7 8 9 0 1 OPTION_STATUS_CODE option len status code status message 18/22

option code OPTION_STATUS_CODE (13) option len 2 + długość pola status message status code liczba określająca stan zakodowany w tej opcji. Kody stanu są zdefiniowane w punkcie status message tekst w kodzie UTF 8, który może być wyświetlony użytkownikowi i nie może być zakończony zerem Opcja Status Code może pojawić się polu opcji komunikat DHCP iub polu opcji innej opcji. Jeśli kod stanu nie pojawi się w wiadomości, w której może się pojawić, uznaje się, że wszystkie operacje się powiodły. 5.10 Opcja Rapid Commit Opcja Rapid Commit jest używana do sygnalizacji możliwości przypisania adresu za pomocą tylko dwóch wiadomości. Format opcji Rapid Commit jest następujący: 4 5 6 7 8 9 4 5 6 7 8 9 4 5 6 7 8 9 0 1 OPTION_RAPID_COMMIT 0 option code OPTION_RAPID_COMMIT (14) option len 0 Klient może załączyć tę opcję w komunikacie Solicit, jeśli klient może dokonać wymiany wiadomości SOLICIT REPLY opisanej w punkcie Proces odkrywania serwera. Serwer musi załączyć tę opcję w komunikacie Reply wysłanym w odpowiedzi na komunikat SOLICIT, jeżeli ma zostać dokonana wymiana wiadomości SOLICIT REPLY. Dyskusja: Każdy serwer odpowiadjący komunikatem REPLY na SOLICIT, który zawiera opcję Rapid Commit będzie musiał natychmiastowo przypisać adresy w komunikacie Reply wysłanym do klienta i nie otrzyma żadnego potwierdzenia, że klient otrzymał wiadomość REPLY. Dlatego jeśli więcej niż jeden serwer odpowiada na komunikat Solicit, który zawiera opcję Rapid Commit, niektóre serwery przypiszą adresy, które nie zostaną użyte przez klienta. Problem niewykorzystanych adresów może być minimalizowany poprzez np. projektowanie tak usługi DHCP, że tylko jeden serwer będzie odpowiadał na komunikat SOLICIT lub użycie względnie krótkich czasów życia dla przypisywanych adresów. 5.11 Opcja Option Request Opcja Option Request jest używana do określania listy opcji w komunikacji pomiędzy serwerem i klientem. Format opcji Option Request jest przedstawiony na poniższym rysunku: 4 5 6 7 8 9 4 5 6 7 8 9 4 5 6 7 8 9 0 1 OPTION_ORO option len requested option code 1 requested option code 2 option code OPTION_ORO (6) option len 2*liczba żądanych opcji requested option code n Kod opcji, która jest żadana przez klienta 19/22

Klient może załączyć opcję Option Request w komunikatach Solicit, Request, Renew, Rebind, Confirm oraz Information Request w celu poinformowania serwera o opcjach, które klient chce, aby serwer wysłał klientowi. Serwer może załączyć opcję Option Request w opcji Reconfigure, aby wskazać, które opcje klient może żądać od serwera. Kody stanu DHCPv6 używa kodów stanu w celu poinformowania o sukcesie lub błędzie podczas wykonywania operacji żądanych w komunikatach otrzymanych od klientów lub serwerów. Kody błędów pozwalają również na podanie dodatkowych informacji o specyficznych błędach. Nazwa Kod Opis Success 0 Powodzenie UnSpecFail 1 Błąd, przyczyna nieokreślona; ten kod jest wysyłany albo przez serwer, albo przez klienta w celu poinformowania o błędzie nie wyspecyfikowanym w tym dokumencie NoAddAvail 2 Serwer nie posiada wolnych adresów, aby przydzielić do IA NoBinding 3 Wiązanie klienta nie dostępne NotOnLink 4 Prefiks adresu nie jest właściwy dla łącza, do którego dołączony jest klient UseMulticast 5 Wysyłany przez serwer w celu wymuszenia na danym kliencie używania adresu multicastowego 6 Dibbler przenośna implementacja DHCPv6 Dibbler jest otwartą implementacją DHCPv6 powstałą na wydziale ETI Politechniki Gdańskiej. Jest to pierwsza na świecie implementacja tego protokołu w systemach Windows i jedna z dwóch obecnie wolnodostępnych dla systemów Linux. Obsługuje zarówno konfigurację stanową (tzn. przydzielanie adresów), jak i bezstanową (tzn. przydzielanie opcji). Jest ona rozwijana na licencji GNU GPL. Oznacza to, że każdy ma prawo do darmowego używania, modyfikacji i rozpowszechniania zarówno wersji binarnych, jak i źródeł. Szersze informacje dostępne są na stronie projektu: http://klub.com.pl/dhcpv6/ 7 Opis plików konfiguracyjnych Dibblera Rozdział ten zawiera skrócone informacje na temat sposobu konfiguracji klienta i serwera DHCPv6. Szczegóły wraz z dodatkowymi przykładami można znaleźć na stronie projektu: w dokumentacji oraz na stronach manuala (man dibbler server, man dibbler client). Niniejszy opis ma na celu w sposób jak najprostszy przedstawić zasady budowy plików konfiguracyjnych i sposób konfiguracji klienta i serwera DHCPv6. 7.1 Przykłady plików konfiguracyjnych klienta. Przykład 0: Najprostszą formą konfiguracji klienta jest pozostawienie pliku konfiguracyjnego pustego. Spowoduje to próbę przydzielenia na każdym z istniejących w systemie interfejsów (oprócz interfejsu loopback) jednego IA zawierającego jeden adres. Przykład 1: Załóżmy jednak trochę bardziej skomplikowaną sytuację. Niech w systemie znajduje się kilka interfejsów. Spośród nich wybraliśmy eth0 i właśnie ten interfejs będzie konfigurowany. Na początek chcemy bez cudów uzyskać podstawowe informacje adres, serwery DNS i nazwę domeny. Oprócz tego nie interesują nas szczegółowe logi. Oto plik realizujący powyższe wymagania: 20/22