Implementacja serwera i klienta DHCPv6 dla systemów rodziny Linux

Implementacja serwera i klienta DHCPv6 dla systemów rodziny Linux Tomasz Mrugalski 22 września 2003 roku

2

Spis treści 1 Wstęp 9 1.1 Tematyka i cel pracy....................................... 9 1.2 Wprowadzenie do zagadnień poruszanych w dalszej części pracy............... 10 1.2.1 Koncepcja sieciowego systemu operacyjnego...................... 10 1.2.2 Model klient serwer................................... 10 1.2.3 System GNU/Linux................................... 11 2 Rodzina protokołów IPv6 13 2.1 Adresowanie w IPv6....................................... 14 2.1.1 Notacja adresów..................................... 14 2.1.2 Prefiks i adres sieci.................................... 15 2.1.3 Zakres ważności adresu................................. 15 2.1.4 Podział adresów..................................... 15 2.2 Sposoby konfiguracji hostów................................... 16 2.2.1 Stateless Address Autoconfiguration (SAA)...................... 16 2.2.2 Autokonfiguracja typu statefull............................. 17 2.2.3 Neighbor Discovery.................................... 17 2.2.4 Pozostałe protokoły................................... 17 3 Protokoł DHCPv6 19 3.1 Stałe w protokole DHCP..................................... 19 3.1.1 Adresy multicastowe................................... 19 3.1.2 Porty UDP........................................ 19 3.1.3 Typy wiadomości DHCP................................. 20 3.1.4 Transmisja wiadomości przez klienta.......................... 21 3.1.5 Kody stanu........................................ 21 3.1.6 Transmisja i parametry retransmisji.......................... 21 3.1.7 Formaty wiadomości................................... 22 3.1.8 Reprezentacja i użycie nazw domen........................... 22 3.2 Kody stanu............................................ 23 3.3 Identyfikator DUID........................................ 23 3.3.1 Wartość identyfikatora DUID.............................. 23 3.3.2 DUID generowany na podstawie adresu warstwy łącza danych i czasu....... 24 3.3.3 DUID przypisywany przez producenta w oparciu o numer korporacyjny...... 24 3.3.4 DUID tworzony w oparciu o adres warstwy łącza danych............... 25 3.4 Identity Association....................................... 26 3.4.1 Przypisanie adresów do IA............................... 26 3.5 Wiadomości............................................ 27 3.5.1 Transmisja po stronie klienta.............................. 27

4 SPIS TREŚCI 3.5.2 Sprawdzanie poprawności wiadomości......................... 27 3.5.3 Użycie identyfikatora transakcji............................. 28 3.5.4 Wiadomość SOLICIT................................. 28 3.5.5 Wiadomość ADVERTISE............................... 28 3.5.6 Wiadomość REQUEST................................ 28 3.5.7 Wiadomość CONFIRM................................ 29 3.5.8 Wiadomość RENEW................................. 29 3.5.9 Wiadomość REBIND................................. 29 3.5.10 Wiadomość DECLINE................................ 29 3.5.11 Wiadomość RELEASE................................ 29 3.5.12 Wiadomość REPLY.................................. 30 3.5.13 Wiadomość RECONFIGURE............................ 30 3.5.14 Wiadomość INFORMATION-REQUEST.................... 30 3.5.15 Wiadomość RELAY-FORWARD.......................... 30 3.5.16 Wiadomość RELAY-REPLY............................. 31 3.6 Opcje............................................... 31 3.6.1 Format opcji....................................... 31 3.6.2 Opcja Client Identifier................................. 31 3.6.3 Opcja Server Identifier................................. 32 3.6.4 Opcja Identity Association............................... 32 3.6.5 Opcja IA Address.................................... 33 3.6.6 Opcja Option Request.................................. 34 3.6.7 Opcja Preference.................................... 34 3.6.8 Opcja Elapsed Time................................... 35 3.6.9 Opcja Server Unicast.................................. 35 3.6.10 Opcja Status Code.................................... 35 3.6.11 Opcja Rapid Commit.................................. 36 3.6.12 Opcja User Class.................................... 37 3.6.13 Opcja VENDOR CLASS................................ 37 3.6.14 Opcja Vendor-specific Information........................... 38 3.6.15 Opcja Reconfigure Accept................................ 39 3.7 Zachowanie klienta........................................ 39 3.7.1 Adres źródłowy klienta i wybór interfejsu....................... 40 3.7.2 Tworzenie wiadomości SOLICIT........................... 40 3.7.3 Transmisja wiadomości SOLICIT........................... 40 3.7.4 Odbiór wiadomości ADVERTISE.......................... 41 3.7.5 Tworzenie i transmisja wiadomości REQUEST................... 42 3.7.6 Tworzenie i transmisja wiadomości CONFIRM................... 42 3.7.7 Tworzenie i transmisja wiadomości RENEW.................... 43 3.7.8 Tworzenie i transmisja wiadomości REBIND.................... 43 3.7.9 Tworzenie i transmisja wiadomości INFORMATION-REQUEST....... 44 3.7.10 Tworzenie i transmisja wiadomości RELEASE................... 45 3.7.11 Tworzenie i transmisja wiadomości DECLINE................... 45 3.7.12 Odbiór wiadomości REPLY.............................. 46 3.8 Zachowanie serwera........................................ 47 3.8.1 Odbiór wiadomości SOLICIT............................. 47 3.8.2 Tworzenie i transmisja wiadomości ADVERTISE................. 47 3.8.3 Tworzenie i transmisja wiadomości REPLY..................... 48 3.8.4 Odbiór wiadomości REQUEST............................ 48 3.8.5 Odbiór wiadomości CONFIRM............................ 49

SPIS TREŚCI 5 3.8.6 Odbiór wiadomości RENEW............................. 49 3.8.7 Odbiór wiadomości REBIND............................. 49 3.8.8 Odbiór wiadomości REQUEST-INFORMATION................ 50 3.8.9 Odbiór wiadomości RELEASE............................ 50 3.8.10 Odbiór wiadomości DECLINE............................ 50 4 Wspierane standardy 53 4.1 Potrzeba standaryzacji...................................... 53 4.2 Internet Engeneering Task Force................................ 53 4.3 Standardy............................................. 54 5 Interfejsy programistyczne (API) i wymagania systemowe 55 5.1 Wymagana funkjonalność systemu operacyjnego....................... 55 5.2 Interfejsy programistyczne (API) a model ISO/OSI...................... 55 5.2.1 wyliczanie interfejsów.................................. 56 5.2.2 Przypisywanie i usuwanie adresów........................... 57 5.2.3 gniazda UDP....................................... 58 5.2.4 Konwersja na format sieciowy.............................. 61 5.3 Demony.............................................. 61 6 Architektura serwera 63 6.1 Manager interfejsów SrvIfaceMgr............................... 63 6.2 Manager adresów SrvAddrMgr................................ 63 6.3 Manager konfiguracji SrvCfgMgr............................... 65 6.4 Manager transmisji SrvTransMgr............................... 65 7 Architektura klienta 67 7.1 Manager interfejsów ClntIfaceMgr.............................. 67 7.2 Manager adresów ClntAddrMgr................................ 67 7.3 Manager konfiguracji ClntCfgMgr.............................. 69 7.4 Manager transmisji ClntTransMgr.............................. 69 8 Implementacja 71 8.1 klasy AddressManagera..................................... 71 8.1.1 klasy wspólne....................................... 71 8.1.2 klasy klienta....................................... 73 8.1.3 klasy serwera....................................... 73 8.2 klasy ConfigManagera...................................... 73 8.2.1 klasy wspólne....................................... 74 8.2.2 klasy klienta....................................... 74 8.2.3 klasy serwera....................................... 76 8.3 klasy InterfaceManagera..................................... 77 8.3.1 klasy wspólne....................................... 77 8.3.2 klasy klienta....................................... 77 8.3.3 klasy serwera....................................... 79 8.4 TransMgr............................................. 79 8.4.1 klasy klienta....................................... 79 8.4.2 klasy serwera....................................... 79 8.5 Messages............................................. 80 8.5.1 klasy klienta....................................... 81 8.5.2 klasy serwera....................................... 83

6 SPIS TREŚCI 8.6 Opcje............................................... 85 8.6.1 Opcja Client ID..................................... 85 8.6.2 Opcja Server ID..................................... 87 8.6.3 Opcja IA NA...................................... 87 8.6.4 Opcja IAADDR..................................... 89 8.6.5 Opcja ORO....................................... 90 8.6.6 Opcja Preference.................................... 90 8.6.7 Opcja Elapsed Time................................... 91 8.6.8 Opcja Server Unicast.................................. 91 8.6.9 Opcja Status Code.................................... 93 8.6.10 Opcja Rapid Commit.................................. 93 8.6.11 Opcja User Class.................................... 94 8.6.12 Opcja Vendor Class................................... 94 8.6.13 Opcja Vendor Info................................... 96 8.6.14 Opcja Interface ID................................... 96 8.6.15 Opcja DNS Resolver.................................. 97 8.6.16 Opcja Domain Search List............................... 98 8.6.17 Opcja Timezone..................................... 98 8.6.18 Opcja NTP Servers................................... 99 8.7 Pozostałe............................................. 100 9 Opis plików konfiguracyjnych 101 9.1 Tokeny............................................... 101 9.2 Struktura pliku konfiguracyjnego klienta DHCPv6...................... 102 9.2.1 Zakresy ważności..................................... 102 9.2.2 Deklaracje globalne.................................... 102 9.2.3 Deklaracja interfejsu.................................... 102 9.2.4 Deklaracja IA....................................... 103 9.2.5 Deklaracja Adresu..................................... 103 9.2.6 Notacja adresów..................................... 104 9.2.7 Opcje............................................ 104 9.2.8 Przykłady plików konfiguracyjnych klienta....................... 106 9.3 Struktura pliku konfiguracyjnego serwera DHCPv6...................... 108 9.3.1 Deklaracje globalne.................................... 108 9.3.2 Deklaracja interfejsu................................... 108 9.3.3 Deklaracja klasy...................................... 109 9.3.4 Opis deklaracji opcji................................... 109 9.3.5 Przykłady plików konfiguracyjnych serwera...................... 110 10 Testy 113 10.1 Test 1: Sytuacja klasyczna.................................... 113 10.2 Test 2: Odświerzanie adresu................................... 118 10.3 Test 3: Zwalnianie adresu.................................... 121 10.4 Test 4: Przyspieszone zapytanie................................. 123 10.5 Test 5: DHCPv6 w trybie stateless............................... 125 10.6 Test 6: Wykrywanie zduplikowanych adresów......................... 127 10.7 Test 7: Wiele klientów, jeden serwer.............................. 132 10.8 Test 8: Jeden klient, wiele serwerów.............................. 134 10.9 Test 9: Jeden klient, 2 serwery, kończące się adresy...................... 137 10.10Test 10: Interoperability klienta................................. 142 10.11Test 11: Interoperability serwera................................ 148

SPIS TREŚCI 7 11 Podsumowanie 151 11.1 Implementacja.......................................... 151 11.2 Wartość dydaktyczna laboratorium.............................. 152 11.3 Wykorzystne narzędzia...................................... 153 11.4 Licencja GPL........................................... 153 A Laboratorium: wersja dla prowadzącego 155 A.1 Cel laboratorium......................................... 155 A.2 Zakres umiejętności wymaganych od studenta......................... 155 A.3 Pytania kontrolne......................................... 155 A.4 Schemat laboratorium...................................... 157 A.5 Ręczna konfiguracja....................................... 157 A.6 Instalacja oprogramowania.................................... 158 A.7 Standardowa przyznanie adresu................................. 159 A.8 Odświeżanie adresów RENEW................................ 163 A.9 Odświeżanie w przypadku problemów REBIND....................... 165 A.10 Zwalnianie adresu RELEASE................................. 166 A.11 Pytanie o opcje INFORMATION-REQUEST........................ 169 A.12 Wykrywanie zdublowanych adresów DECLINE....................... 171 A.13 Zapytanie przyspieszone RAPID-COMMIT......................... 174 A.14 Start po upadku systemu CONFIRM............................. 175 A.15 Zmiana schematu laboratorium................................. 179 A.16 Konfiguracja wielu do jednego.................................. 180 A.17 Wybór serwera przez klienta................................... 182 B Laboratorium: wersja dla studenta 187 B.1 Cel laboratorium......................................... 187 B.2 Wymagane umiejętności..................................... 187 B.3 Pytania kontrolne......................................... 187 B.4 Schemat laboratorium...................................... 188 B.5 Ręczna konfiguracja....................................... 189 B.6 Instalacja oprogramowania.................................... 189 B.7 DHCPv6 standardowa wymiana SOLICIT/ ADVERTISE/ REQUEST/ REPLY.... 190 B.8 Odświerzanie adresów RENEW................................ 190 B.9 Odświerzanie w przypadku problemów REBIND...................... 190 B.10 Zwalnianie adresu RELEASE................................. 190 B.11 Pytanie o opcje INFORMATION-REQUEST........................ 190 B.12 Wykrywanie zdublowanych adresów DECLINE....................... 191 B.13 Zapytanie przyspieszone RAPID-COMMIT......................... 191 B.14 Start po upadku systemu CONFIRM............................. 191 B.15 Zmiana schematu laboratorium................................. 191 B.16 Konfiguracja wielu do jednego.................................. 192 B.17 Wybór serwera przez klienta................................... 192 C Kod źródłowy 195 D Licencja GNU General Public Licence 197

8 SPIS TREŚCI

Rozdział 1 Wstęp Protokoły z rodziny TCP/IP są podstawowymi protokołami wykorzystywanymi do komunikacji zarówno w Internecie, jak i znakomitej większości sieci lokalnych. Wersja protokołu będąca obecnie w powszechnym użyciu nosi numer 4. Została ona zaprojektowana i oddana do użytku na początku lat osiemdziesiątych. Nie przewidywano wówczas lawinowego wzrostu liczby podłączonych komputerów, który rozpoczął się pod koniec lat osiemdziesiątych i trwa do dziś. Powoli dają o sobie znać pewne niedoskonałości i ograniczenia protokołów TCP/IP w wersji 4. Najważniejszym z nich jest stosunkowo niewielka liczba dostępnych adresów. Poprzez niedostatecznie restrykcyjną politykę przyznawania adresów w początkowej fazie rozwoju Internetu, wiele adresów jest obecnie nie do wykorzystania. Wprawdzie opracowano metody łagodzące szybkie ubywanie dostępnych adresów IP np. CIDR (routing bezklasowy) lub dynamiczne tłumaczenie adresów NAT, jednak spowolniły one zjawisko, ale nie rozwiązały problemu. Od połowy lat dziewięćdziesiątych coraz szerszym poparciem cieszy się idea wprowadzenia gruntownych zmian do istniejących rozwiązań. Podstawową zmianą jest znaczne zwiększenie przestrzeni adresowej z 32 do 128 bitów. Oprócz tego, poważnym zmianom zostały poddane praktycznie wszystkie elementy architektury TCP/IP. Obecnie proces standaryzacji nowej wersji, określanej zbiorczo jako IP następnej generacji lub krócej IPv6, jest w finałowej fazie. Dlatego już wkrótce należy spodziewać się lawinowego wzrostu praktycznych rozwiązań opartych o ten właśnie standard. Pomimo znacznego uproszczenia wielu kwestii, IPv6 oferuje znacznie więcej możliwości niż jego poprzednik. Przykładem może być wspieranie mobilności, automatyczna konfiguracja hostów oraz routingu, a także obowiązkowe wsparcie dla protokołów kryptograficznych. Tak szeroki wachlarz możliwości jest przyczyną pewnych komplikacji. Przeciętny użytkownik komputera nie jest już w stanie samodzielnie skonfigurować swojej stacji roboczej do pracy w środowisku sieciowym. Również w przypadku osób profesjonalnie zajmujących się administracją sieci komputerowych, ręczne ustawianie niezliczonych parametrów jest operacją bardzo żmudną i łatwo może stać się przyczyną wielu błędów. Potrzebny jest zatem mechanizm umożliwiający jak najprostszą, a najlepiej w pełni automatyczną konfigurację urządzeń podłączonych do sieci. Pożądane jest także scentralizowane zarządzanie konfiguracją poszczególnych hostów. Wszystkie te wymagania spełnia protokół Dynamic Host Configuration Protocol w wersji 6. Niniejsza praca jest poświęcona architekturze oraz problemom związanym z implementacją tego protokołu w systemie GNU/Linux. 1.1 Tematyka i cel pracy Podstawowym tematem niniejszej pracy jest implementacja protokołu DHCPv6 w systemie GNU/Linux. Cały proces zostanie przeanalizowany w sposób kompleksowy. Obserwacja i analiza zostaną zapoczątkowane już w fazie powstawania specyfikacji. Przedstawiona zostanie potrzeba istnienia prokotołu dynamicznej konfiguracji, a także wymagania niezbędne do jego wykorzystania. Szczegółowo zostanie omówiony zarów-

10 Wstęp no sam protokół, jak i jego implementacja. Przedstawione zostaną ciekawsze problemy praktyczne napotkane w czasie implementacji wraz ze sposobami ich rozwiązania. Na podstawie opracowania protokołu oraz implementacji zostanie przygotowana propozycja zajęć dydaktycznych do zrealizowania w laboratorium. Pracę zakończy podsumowanie projektu wraz z wnioskami i uwagami dotyczącymi wykorzystania stworzonego oprogramowania w praktyce. 1.2 Wprowadzenie do zagadnień poruszanych w dalszej części pracy W niniejszym podrozdziale zostaną pokrótce omówione ważniejsze zagadnienia, których zrozumienie jest kluczowe dla dalszej części pracy. 1.2.1 Koncepcja sieciowego systemu operacyjnego Z punktu widzenia użytkownika lokalnej sieci komputerowej, system, który nie zapewnia łatwego dostępu do zasobów sieciowych, jest mało przydatny. Współczesny użytkownik oczekuje od systemu komputerowego jak najłatwiejszej możliwości wykorzystania sieci. Przekłada się to bezpośrednio na wymagania programistów, którzy te oczekiwania pragną spełnić. W taki oto sposób problem obsługi sieci i związanych z nią mechanizmów zostaje sprowadzony do najniższego poziomu programowego systemu operacyjnego. Aby w pełni zrozumieć to zagadnenie, należy zastanowić się, co dokładnie oznacza sformułowanie system operacyjny. Według [3] system operacyjny jest to dedykowany program, który działa jako pośrednik pomiędzy użytkownikiem komputera a sprzętem komputerowym. Tworzy on środowisko, w którym użytkownik może wykonywać programy pozwalające rozwiązywać formułowane przez niego problemy. Rozszerzając tą definicję o pojęcie sieci, można wprowadzić pojęcie sieciowego systemu operacyjnego: Sieciowy system operacyjny jest to dedykowany program, który działa jako pośrednik pomiędzy użytkownikiem komputera a sprzętem komputerowym, w tym również urządzeń sieciowych. Tworzy on środowisko, w którym użytkownik może wykonywać programy pozwalające rozwiązywać formułowane problemy lokalnie, a także przy wykorzystaniu oddalonych zasobów za pomocą komunikacji sieciowej. Intuicyjne rozróżnienie jest w tym przypadku jak najbardziej poprawne system sieciowy to taki, który oferuje komunikację sieciową, a także udostępnia pewne mechanizmy oraz narzędzia do wykorzystania takiej komunikacji. Przykładami systemów sieciowych są GNU/Linux, FreeBSD, a także wersje Windows95 i nowsze. Z drugiej strony, przykładem niesieciowego systemu operacyjnego może być MS DOS, który nie wspierał żadnych mechanizmów sieciowych. Pomimo możliwości np. obsługi kart sieciowych w systemie DOS, nie jest on uważany za system sieciowy, ponieważ taka obsługa nie jest standardowa, a ponadto nie oferuje żadnych standardowych narzędzi do diagnostyki lub eksploatacji sieci. Wymagania odnośnie systemu operacyjnego związane z siecią skupiają się głównie na uniezależnieniu sposobu działania od sprzętu, architektury oraz zastosowanych rozwiązań programowych. Celem takiego wymogu jest jednolity sposób postrzegania maszyny obserwowany od strony sieci, a co za tym idzie, możliwość współpracy różnych maszyn wyposażonych w różne systemy operacyjne. Jest oczywistym fakt, że systemy zdolne do komunikacji, będą się ze sobą komunikować. W znakomitej większości przypadków, taka komunikacja nie będzie w pełni równoprawna. Zwykle jedna ze stron będzie świadczyć usługi na rzecz drugiej. Takie podejście nazywa sie modelem klient serwer. 1.2.2 Model klient serwer Najczęstszy scenariusz połączenia sieciowego zakłada, że jedna ze stron pragnie skorzystać z usług świadczonych przez stronę drugą. Zwykle tą funkcją zajmują się specjalizowane komputery nazywane powszechnie serwerami. Druga strona, zwykle inicjująca połączenie i przysyłająca zapytania, jest nazywana

Wstęp 11 klientem. Ten, zdawałoby się, oczywisty model, implikuje wiele mechanizmów. Podstawowym z nich jest fakt, że całość interakcji od strony serwera jest sterowana zdarzeniami. Oznacza to, że serwer samoczynnie nie nawiązuje połączenia z klientem ani nie transmituje danych, jeżeli klient tego nie zażąda. Wyjątkiem od tej reguły są tzw. timeouty, kiedy to serwer stwierdza, że nie zaobserwował pewnych zjawisk, które powinny mieć miejsce w określonym czasie. Przykładem może być brak potwierdzenia przy transmisji danych. Serwer transmitując dane do klienta oczekuje, że ten potwierdzi ich odbiór. Skoro nie otrzymano potwierdzenia odbioru w określonym czasie, serwer zakłada, że transmisja się nie udała i retransmituje dane. Klient może rozpocząć i kontynuować rozmowę z serwerem na wiele różnych sposobów. Podobnie serwer w wielu przypadkach ma możliwość różnych reakcji na otrzymane od klienta zapytania. Trzeba jednak zaznaczyć, że nie każda reakcja jest dozwolona w każdej sytuacji. Zbiór dozwolonych scenariuszy konwersacji wraz ze szczegółowym opisem formatu i znaczenia przesyłanych danych, nazywamy protokołem transmisji.. 1.2.3 System GNU/Linux System GNU/Linux, nazwany krótko, choć nie do końca poprawnie, Linuxem jest fenomemem ostatnich lat. Aby w pełni zrozumieć, czym jest system GNU/Linux, niezbędny jest krótki rys historyczny. W roku 1991 fiński student informatyki Linus Torvalds, zniechęcony brakiem możliwości korzystania z uczelnianego serwera unixowego, rozpoczął pracę nad tzw. emulatorem terminala, który by mu taką zdalną pracę umożliwił. W krótkim czasie projekt przekształcił się w zaawansowany program z aspiracjami do miana jądra systemu operacyjnego. Tym, czym wyróżniło ten projekt spośród tysięcy podobnych, było podejście do kodu źródłowego. Torvalds udostępnił napisany przez siebie kod źródłowy społeczności internetowej, zezwolił na swobodne wykorzystywanie i modyfikację, a także poprosił o nadsyłanie poprawek. W ten oto sposób położył fundamenty pod tzw. wolne oprogramowanie.. Wkrótce projekt, nazwany w międzyczasie Linuxem, wzbogacił się o mnóstwo nowych funkcji, a jego aktywnym rozwojem zajęła się grupa ludzi z całego świata. Szybko okazało się, że jądro systemu osiągnęło już na tyle dojrzałą formę, że można było z niego korzystać. Brakowało jednak drugiej, integralnej części systemu operacyjnego setek narzędzi, bez których praca w systemie jest niemożliwa. Początki oraz rozwój systemu Linux zostały szeroko opisane w [4]. Mniej więcej 10 lat wcześniej, w Stanach Zjednoczonych, Richard M. Stallman, student, a później pracownik MIT borykał się z innymi problemami. W ówczesnych czasach dostępne na rynku oprogramowanie nie było zbyt zaawansowane i posiadało wiele błędów. Nabywając oprogramowanie komercyjne, użytkowicy nie mieli prawa ani możliwości poprawiania istniejących błędów, a także nielegalne było dostosowanie posiadanego oprogramowania do swoich możliwości. Zniechęcony takim podejściem producentów systemów UNIX, Stallman postanowił napisać swoją własną kopię najważniejszych narzędzi systemowych. Podobnie jak Torvalds, udostępnił on swój kod innym programistom i zachęcił ich do wprowadzania poprawek oraz ulepszeń. W taki sposób narodził się projekt mający na celu stworzenie otwartej, ogólnodostepnej i darmowej kopii systemu UNIX. Projekt ten został nazwany GNU i jest rekurencyjnym akronimem oznaczającym GNU s Not Unix. Więcej na temat projektu GNU można przeczytać w [23]. W okolicach roku 1992 Linus Torvalds posiadał jądro systemu operacyjnego, ale brakowało mu narzędzi systemowych. Richard Stallman posiadał za to wszystkie narzędzia, ale nie miał z kolei środowiska, w którym te narzędzia mogłyby być wykorzystywane. Pomiędzy obydwoma projektami szybko wytworzyła się swoista symbioza, która trwa do dziś. Połączenie zostało nazwane GNU/Linux, co należy rozumieć jako system GNU działający na jądrze Linuxa. W tym miejscu warto podać jako ciekawostkę, że dzięki przenośności systemu GNU, dostępna jest również wersja oparta o mikrojądro Hurd. System ten nazywany jest GNU/Hurd. Więcej o projekcie Hurd można dowiedzieć się z [24]. System GNU/Linux niedawno ukończył 12 lat. Swoją niesamowitą karierę zawdzięcza nietypowej filozofii zezwalającej na otrzymanie za darmo kodu wszystkich aplikacji, wprowadzenie zmian i redystrybucję własnej wersji kodu. Dzięki temu na całym świecie setki tysięcy osób rozwija pojedyncze aplikacje, które

12 Wstęp razem tworzą system GNU/Linux. Oczywiście jądro Linuxa od samego początku było projektowane z myślą o obsłudze sieci, dlatego też obsługa mechanizmów sieciowych należy do jednej z najlepszych. Wśród licznych obsługiwanych protokołów sieciowych znajduje się IP w wersji 6. Niestety, do tej pory protokoł DHCPv6 nie jest obsługiwany. Możliwość zmiany tego stanu rzeczy autor niniejszej pracy uważa za wielki zaszczyt.

Rozdział 2 Rodzina protokołów IPv6 Ograniczenia stosu TCP/IP w wersji 4 wymusiły wprowadzenie szeregu zmian oraz nowatorskich koncepcji, które powinny zapewnić jego wysoką przydatność dla sieci o zasięgu światowym. Wg [1] najważniejsze zmiany i rozszerzenia obejmują: 1. zmiany w formacie nagłówka znacznie uproszczono format nagłówka. Dodatkową zaletą jest stała wielkość 40 bajtów (w warstwie 3). Pola o zmiennej wielkości zostały zastąpione dodatkowymi, opcjonalnymi nagłówkami. Dzięki niezmiennej, prostej budowie nagłówka postawowego, zadania wykonywane przez routery i switche zostały znacznie uproszczone, co owocuje relatywnym wzrostem ich wydajności. 2. przestrzeń adresowa uległa rozszerzeniu z 32 na 128-bitową. Dzięki tak ogromnej ilości adresów (na jeden m 2 powierzchni Ziemi przypada około 10 23 adresów) zakłada się, że problem braku adresów został rozwiązany w sposób permanentny 3. wprowadzono wydajny oraz hierarchiczny sposób adresowania i routingu 4. dodano automatyczne adresowanie w trybach stateless i statefull 5. wprowadzono priorytety i pełną obsługę jakości usług (QoS) rezerwacji zasobów sieciowych. 6. dodano możliwość obsługi metod kryptograficznych, tzn. uwierzytelniania, autoryzacji i szyfrowania danych 7. wprowadzono zakresy ważności adresów rozwiązania lokalne nie muszą używać adresów z puli globalnej, jak to miało miejsce w przypadku IPv4 Rodzina protokołów IPv6 składa się z czystego protokołu warstwy sieciowej (w stosie TCP/IP nazywanej internetową) IPv6. Jako nośnik używane są protokoły warstwy łącza danych (np. Ethernet, TokenRing) lub tunelowanie poprzez protokół IPv4. Na styku warstwy internetowej i transportowej działa protokół diagnostyczno-kontrolny ICMPv6. W porównaniu do poprzedniej wersji, protokół ICMP uległ ogromnym zmianom. Teraz w jego skład wchodzą: MLD (Multicast Listener Discovery) wykorzystywany do realizacji usług na bazie adresów multicastowych (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 współpracę z warstwą łącza danych. Można go określić jako następcę protokołu ARP z dodatkowymi możliwościami SAA (Stateless Address Autoconfiguration) protokół automatycznej adresacji węzłów

14 Rodzina protokołów IPv6 RR (Router Renumbering) związany z obsługą prefiksów i adresów sieciowych 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 nieniejszej pracy, użyteczne są protokoły Neighbor Discovery oraz Stateless Address Autoconfiguration, dlatego też te protokoły zostaną omówione w sposób bardziej szczegółowy. W warstwie transportowej znajdują się dwa klasyczne protokoły: zorientowany połączeniowo TCP oraz datagramowy UDP. Powyżej znajdują się wszystkie wykorzystywane obecnie protokoły aplikacyjne, np. HTTP, SMTP, POP3, FTP itd. Wśród nich znajduje się również protokół DHCPv6. 2.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 i/lub routerów. Dane wysyłane na taki adres dotrą do wszystkich, którzy taki adres wykorzystują. 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 poprzednika, 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 metody routingu. Należy zauważyć, że znane z IPv4 adresy rozgłoszeniowe (broadcast) nie zostały zdefiniowane. Ich rolę przejęły adresy typu multicast. 2.1.1 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. 1. 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 2. 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:

Rodzina protokołów IPv6 15 1234:5678:9ABC:DEF0::123 2.1.2 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 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::DEF:123/24 oznacza host o adresie DEF::123 znajdujący się w sieci 1234:5678:9ABC::/24. 2.1.3 Zakres 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 host 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 adresu jest poprawny w obrębie całej organizacji 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 w każdym przypadku. 2.1.4 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.

16 Rodzina protokołów IPv6 Przypisane adresy Prefiks prefiks część przestrzeni (bin.) (heks.) adresowej Zarezerwowane 0000 0000 00 1/256 Niezdefiniowane 0000 0001 01 1/256 Niezdefiniowane 0000 001 02 1/128 Niezdefiniowane 0000 010 04 1/128 Niezdefiniowane 0000 011 06 1/128 Niezdefiniowane 0000 1 08 1/32 Niezdefiniowane 0001 10 1/16 Globalne połączone adresu multicastowe 001 20 1/8 Niezdefiniowane 010 40 1/8 Niezdefiniowane 011 60 1/8 Niezdefiniowane 100 80 1/8 Niezdefiniowane 101 A0 1/8 Niezdefiniowane 110 C0 1/8 Niezdefiniowane 1110 E0 1/16 Niezdefiniowane 1111 0 F0 1/32 Niezdefiniowane 1111 10 F8 1/64 Niezdefiniowane 1111 110 FC 1/128 Niezdefiniowane 1111 1110 0 FE 1/512 Lokalne adresy unicastowe łącza 1111 1110 10 FE80 1/1024 Lokalne adresy unicastowe węzłe 1111 1110 11 FEc0 1/1024 Adresy multicastowe 1111 1111 FF 1/256 2.2 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 Statefull 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ą w trybie 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.1 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 tymczasowych jako adresem docelowym 1. 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 1 Dokładniej: adresem docelowym jest adres multicastowy generowany na podstawie adresu tymczasowego

Rodzina protokołów IPv6 17 sytuacje rzadko spotykane i zazwyczaj nietypowe. Adres lokalny łącza generowany jest na podstawie adresu warstwy MAC, 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 prefered lifetime, jak i valid lifetime mają ustawione na nieskończoność, czyli nigdy nie wygasają i zawsze zachowują swoją ważność. 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 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 advertisement 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. 2.2.2 Autokonfiguracja typu statefull 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.2.3 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. Ważnym elementem tego protokołu jest mechanizm DAD Duplicate Address Detection. Umożliwia on wyrycie, czy dany adres nie jest już przypadkiem wykorzystywany. Z tego mechanizmu korzysta się za każdym razem, kiedy do interfejsu zostaje przypisany adres. Szczegółowy opis protokołu Neighbor Discovery leży poza zakresem niniejszej pracy i znajduje się w dokumencie [12]. 2.2.4 Pozostałe protokoły Protokół ICMPv6 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).

18 Rodzina protokołów IPv6 Automatyczna konfiguracja adresów(address Autoconfiguration) procedura automatycznej konfiguracji, która została omówiona w poprzednim podrozdziale. Odwzorowanie adresów (Address Resolution) ustalanie adresu łącza danych w przypadku, kiedy dany jest tylko adres IP Określania adresu 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.

Rozdział 3 Protokoł DHCPv6 Poniższa specyfikacja pochodzi z dokumentów Dynamic Host Configuration Protocol for IPv6, wersja robocza 28 ([20]) oraz RFC3315:Dynamic Host Configuration Protocol for IPv6 ([18]). 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. Szczegółowe przedstawienie protokołu DHCPv6 zostało przedstawione poniżej. 3.1 Stałe w protokole DHCP W tym punkcie zostały opisane różne stałe programowe i sieciowe używane przez protokół DHCP. 3.1.1 Adresy multicastowe DHCP używa następujących adresów multicastowych: 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 unicastowego adresu 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 multicastowej grupy. 3.1.2 Porty UDP Klienci nasłuchają wiadomości DHCP na porcie 546 UDP. Serwery i przekaźniki nasłuchają wiadomości DHCP na porcie 547 UDP.

20 Protokoł DHCPv6 3.1.3 Typy wiadomości DHCP DHCP definiuje następujące typy wiadomości. Więcej szczegółów dotyczących tych wiadomości można znaleźć w punkcie 6. W nawiasach zotały podane kody odpowiadające danemu typowi wiadomości. SOLICIT (1) klient wysyła wiadomość SOLICIT w celu lokalizacji serwerów ADVERTISE (2) serwer wysyła wiadomość ADVERTISE w celu poinformowania, że jest gotowy do osbsługi klienta, w odpowiedzi na komunikat 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 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 REPLY (7) serwer wysyła wiadomość REPLY zawierającą przypisane adresy i parametry konfiguracyjne w odpowiedzi na komunikaty 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 komunikatem REPLY, aby potwierdzić otrzymanie wiadomości REAEASE 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 RE- NEW / REPLY lub INFORMATION-REQUEST / REPLY z serwerem w celu otrzymania uaktualnionych informacji INFORMATION-REQUEST (11) wiadomość żądający, aby serwer podał parametry konfiguracyjne bez przypisywania adresów IP klientowi RELAY-FORW (12) przekaźnik wysyła wiadomość RELAY-FORWARD, aby przekazać wiadomość klienta do serwera, albo bezpośrednio, albo poprzez inny przekaźnik. Wiadomość klienta jest enkapsulowany w opcji wiadomości RELAY-FORWARD RELAY-REPLY (13) Serwer wysyła wiadomość RELAY-REPLY do przekaźnika, albo bezpośrednio, albo przez inny przekaźnik, aby przekazać wiadomości klientowi. Serwer enkapsuluje wiadomość dla klienta w postaci opcji w komunikacie RELAY-REPLY, którą przekaźnik wydobywa i przekazuje klientowi

Protokoł DHCPv6 21 3.1.4 Transmisja wiadomości przez klienta Jeżeli inaczej nie wyspecyfikowano w tym dokumencie lub dokumencie, który opisuje, jak IPv6 jest przenoszony poprzez łącze konkretnego typu (dla łączy, które nie pozwalają na transmisję multicast, np. FrameRelay lub ATM), klient wysyła wiadomość DHCP na adres All DHCP Relay Agents and Servers. Klient używa multicastu do połączenia się z wszystkimi lub pojedynczym serwerem. Pojedynczy serwer jest wskazywany przez specyficzny dla tego serwera DUID w opcji Server Identifier w wiadomości klienta (wszystkie serwery otrzymają ten komunikat, ale tylko wskazany serwer może odpowiadzieć). W przypadku braku tej opcji odbiorcą wiadomości są wszystkie serwery. Klient może również wysłać wiadomość bezpośrednio do serwera przy użyciu unicastu, jak opisano w punkcie 3.6.9 3.1.5 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. Specyfikacja kodów błędów znajduje się w punkcie 3.2. 3.1.6 Transmisja i parametry retransmisji Ten punkt prezentuje tabelę stałych używanych do opisu transmisji wiadomości pomiędzy klientem i serwerem. Parameter Domyślnie Opis MAX SOL DELAY 1 sec Maksymalne opóźnienie pierwszej wiadomości SOLICIT SOL TIMEOUT 1 sec Początkowa wartość timeoutu dla wiadomości SOLICIT SOL MAX RT 120 sec Maksymalna wartość timeoutu dla wiadomości SOLICIT REQ TIMEOUT 1 sec Początkowa wartość timeoutu dla wiadomości REQUEST REQ MAX RT 30 sec Maksymalna wartość timeoutu dla wiadomości REQUEST REQ MAX RC 10 Maksymalna liczba prób powtórzenia wiadomości REQUEST CNF TIMEOUT 1 sec Początkowa wartość timeoutu dla wiadomości CONFIRM CNF MAX RT 4 sec Maksymalna wartość timeoutu dla wiadomości CONFIRM CNF MAX RD 10 sec Maksymalny czas oczekiwania na odpowiedź dla wiadomości CONFIRM REN TIMEOUT 10 sec Początkowa wartość timeoutu dla wiadomości RENEW REN MAX RT 600 sec Maksymalna wartość timeoutu dla wiadomości RENEW REB TIMEOUT 10 sec Początkowa wartość timeoutu dla wiadomości REBIND REB MAX RT 600 sec Maksymalna wartość timeoutu dla wiadomości REBIND

22 Protokoł DHCPv6 INF TIMEOUT 1 sec Początkowa wartość timeoutu dla wiadomości INFORMATION-REQUEST INF MAX RT 120 sec Maksymalna wartość timeoutu dla wiadomości INFORMATION-REQUEST REL TIMEOUT 1 sec Początkowa wartość timeoutu dla wiadomości RELEASE REL MAX RT 0 Maksymalna wartość timeoutu dla wiadomości RELEASE REL MAX RC 5 Maksymalna liczba prób powtórzenia wiadomości RELEASE DEC TIMEOUT 1 sec Początkowa wartość timeoutu dla wiadomości DECLINE DEC MAX RT 0 Maksymalna wartość timeoutu dla wiadomości DECLINE DEC MAX RC 5 Maksymalna liczba prób powtórzenia wiadomości DECLINE REC TIMEOUT 2 sec Początkowa wartość timeoutu dla wiadomości RECONFIGURE REC MAX RC 8 Maksymalna liczba prób powtórzenia wiadomości RECONFIGURE HOP COUNT LIMIT 32 Maksymalna liczba przeskoków dla wiadomości RELAY-FORWARD 3.1.7 Formaty wiadomości Wszystkie komunikaty wysyłane pomiędzy klientem i serwerem mają identyczny i stały format nagłówka i zmienny format pola opcji. Wszystkie wartości w nagłówku i polu opcji są w porządku sieciowym bajtów. Opcje są zapamiętywane kolejno w polu opcji. Opcje są wyrównane jedynie co do granicy bajtu, ale nie są wyrównywane w żaden inny sposób np. do granicy 2, czy 4 bajtów. Następujący rysunek pokazuje format wiadomości DHCP wysyłanych pomiędzy klientem i serwerem: 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 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 punkcie 3.1.3 transaction-id identyfikator danej wymiany wiadomości options opcje wiadomości;opcje są opisane w punkcie 3.6 3.1.8 Reprezentacja i użycie nazw domen Nazwy domen muszą być kodowane jednoznacznie. Nazwa domeny jest kodowana przy użyciu techniki opisanej w punkcie 3.1 RFC1035 [8]. Nazwa domeny lub lista nazw domen w DHCP nie może być zapisywana w skompresowanej postaci jak opisano w punkcie 4.1.4 RFC 1035 [8].

Protokoł DHCPv6 23 3.2 Kody stanu 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 3.3 Identyfikator DUID Każdy klient i serwer DHCP ma 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ą identyfiakotorów DUID w otrzymanym komunikacie do identyfikacji serwera. W punktach 3.6.2 i 3.6.3 zostało opisane kodowanie identyfikatora DUID w komunikacie DHCP. Klienci i serwery mogą porównywać identyfikatory DUID jedynie co do równości. Nie mogą również w jakikolwiek sposób interpretować indentyfikatorów DUID. Klienci i serwery nie mogą ograniczać typów DUID do typów zdefiniowanych w tym dokumencie, gdyż inne typy identyfikatorów DUID mogą zostać zdefiniowane w przyszłości. Identyfikator DUID jest przenoszony jako opcja, ponieważ może być zmiennej długości i nie musi występować w każdym komunikacie 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. Globalnie unikalny identyfikator, który jest łatwy do wygenerowania dla każdego urządzenia musi być generowany na różne sposoby. Niektóre urządzenia mogą nie zawierać jakiejkolwiek pamięci trwałej. 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. 3.3.1 Wartość identyfikatora DUID DUID składa się z dwu oktetowego pola kod typu, po którym następuje zmienna liczba oktetów, które tworzą właściwy identyfikator. DUID nie może być dłuższy niż 128 oktetów (bez pola kod typu ). Obecnie są zdefiniowane następujące typy: 1. Przy wykorzystaniu adresu warstwy łącza danych i aktualnego czasu 2. Przypisywany przez producenta przy użyciu numeru korporacyjnego 3. Przy użyciu adresu warstwy łącza danych

24 Protokoł DHCPv6 3.3.2 DUID generowany na podstawie adresu warstwy łącza danych i czasu Ten rodzaj identyfikatora DUID składa się z dwuoktetowego pola typu zawierającego wartość 1, dwóch oktetów kodu określającego typ sprzętu, czterech oktetów zawierających czas, po którym następuje adres warstwy łącza danych któregokiolwiek z interfejsów sieciowegych dołączony do urządzenia DHCP w momencie generowania identyfikatora DUID. Wartość czasu określa moment, w który generowany jest identyfikatora DUID w postaci liczby sekund które upłynęły od północy(utc) 1 stycznia 2000 modulo 2 32. Pole hardware-type musi być poprawnym typem sprzętu zdefiniowanym przez IANA w RFC 826 [7]. Zarówno czas i typ sprzętu są przechowywane w sieciowym porządku bajtów. Adres łącza danych jest przechowywany w formie kanonicznej, jak zostało to opisane w RFC 2464 [14]. Następujący rysunek ilustruje format DUID-LLT: 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 1 hardware-type time. link layer address.. (zmienna dlugość)... Wybór interfejsu może być całkowicie dowolny, o ile tylko ten interfejs dostarcza globalnie unikalnego adresu warstwy łącza danych dla danego typu łącza i ten sam DUID-LLT powinien zostać użyty przy konfiguracji pozostałych interfejsów sieciowych podłączonych do urządzenia, bez względu na to, którego interfejsu sieciowego adres warstwy łącza danych został użyty do generacji DUID-LLT. Klienci i serwery używające tego typu identyfikatora DUID muszą przechowywać DUID-LLT nawet, gdy interfejs sieciowy użyty do generacji identyfikatora zostanie usunięty. Klienci i serwery, które nie mają pamięci nie ulotnej nie mogą używać tego typu identyfikatora DUID. Klienci i serwery, które używają tego typu identyfikatora powinni skonfigurować czas zanim przystąpią do generacij DUID(o ile jest to możliwe). Przy generacji DUID klienci i serwer powinni użyć źródła czasu (np. zegara czasu rzeczywistego), nawet jeśli to źródło czasu nie może zostać skonfigurowane przed generacją DUID. Użycie źródła czasu powoduje, że jest mało prawdopodbne, aby dwa identyczne DUID- LLT zostły wygenerowane nawet, jeśli interfejs zostanie wyjęty i przeniesiony do innego urządzenia, które użyje go do generacji nowego DUID-LLT. Kolizja pomiędzy dwoma identyfikatorami DUID-LLT jest mało prawdopodobna nawet wówczas, gdy zegary nie zostaną odpowiednio skonfigurowane przed generacją DUID. Ta metoda generacji identyfikatora DUID jest metodą rekomendowaną dla urządzeń takich jak komputery stacjonarne i przenośne, drukarki, routery itp. tzn. zawierających pewną formę zapisywalnej, nieulotnej pamięci. Pomimo wszelkich prób, jest możliwe, aby w wyniku działania tego algorytmu generacji identyfikatora DUID, dojdzie do kolizji identyfikatorów. Klient DHCP, który generuje DUID-LLT używając tego mechanizmu musi posiadać mechanizm pozwalający na wymianę wygenerowanego DUID-LLT na nowy. 3.3.3 DUID przypisywany przez producenta w oparciu o numer korporacyjny 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:

Protokoł DHCPv6 25 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 2 enterprise-number enterpise-number (contd). identifier.. (zmienna długość)... Idntifier jest okreslany przez producenta urządzenia, ale musi być unikalny dla urządzenia, które go używa i musi być przypisywany w momencie produkcji i przechowywany w pamięci trwałej. Numer korporacyjny jest zarezerwowanym numerem zarządzanym przez IANA [9]. Numer korporacyjny jest przechowywany jako 32-bitowa liczba bez znaku. Przykład identyfikatora DUID tego rodzaju może wyglądać następująco: 0 2 0 0 0 9 12 192 132 221 3 0 9 18 W tym przykładzie mamy dwa oktety określające typ identyfikatora (DUID-EN=2), nr korporacyjny(9), po którym następuje osiem oktetów identyfikatora określonego przez producenta (0x0C C0 84 D3 03 00 09 12). 3.3.4 DUID tworzony w oparciu o adres warstwy łącza danych 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-LL. Typ sprzętu musi być poprawnym typem sprzętu przypisanym przez IANA, jak zdefiniowano w RFC 826 [7]. Typ sprzętu jest przechowywany w porządku sieciowym bajtów. Adres łącza danych jest przechowywany w postaci kanonicznej opisanej w RFC 2464 [14]. Następujący rysunek ilustruje format DUID-LL: 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 3 hardware-type. link-layer address.. (zmienna długość)... Wybór interfejsu jest całkowicie dowolny, o ile tylko interfejs pozwala na uzyskanie unikalnego adresu warstwy łącza danych i jest umieszczony na stałe w danym urządzeniu, dla którego identyfikator DUID ma być wygenerowany. Ten sam DUID powinien zostać użyty przy konfiguracji wszystkich interfejsów sieciowych podłączonych do urządzenia, bez względu na adres warstwy łącza danych użyty do generacji identyfikatora DUID. DUID-LL jest zalecany dla urządzeń, która posiadają na stałe podłączone interfejsy sieciowe i nie posiadają stałej, zapisywalnej pamięci. DUID-LL nie może może być używany przez klienty lub serwery DHCP, które nie są w stanie rozróżnić, czy dany interfejs jest na stałe przyłączony do urządzenia.

26 Protokoł DHCPv6 3.4 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 i informacji konfiguracyjnej. Klient musi związać przynajmniej jedno unikalne IA dla każdego ze swoich interfejsów sieciowych, dla których chce mieć uzyskać adresy IPv6 od serwera. 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, identyfiaktor 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 nieulotnej i występują zmiany w konfiguracji może nie istnieć sposób, aby zachowywać to samo IAID pomiędzy odwołaniami. Informacja konfiguracyjna IA składa się z jednego lub więcej adresów IPv6 wraz z czasami T1 i T2. W punkcie 3.6.4 został opisany sposób kodowania IA w komunikacie DHCP. Każdy adres w IA ma preferowany czas ważności i ważny czas życia, jak zdefiniowano w RFC 2462 [13]. Czasy życia są przesyłane od serwera DHCP do klienta w opcji IA. Czasy życia odnoszą się do użycia adresów IPv6 jak zostało opisane w punkcie 5.5.4 RFC 2462 [13]. 3.4.1 Przypisanie adresów do IA Serwer wybiera adresy, które mają być przydzielone zgodnie z polityką przypisywania adresów określoną przez administratora serwera i informacją związaną z klientem, którą może być: Łącze, do którego klient jest dołączony. Serwer może określić łącze, do którego dołączony jest klient za pomocą jednego z poniższych sposobów: Jeśli serwer otrzymał wiadomość bezpośrednio od klienta i adres źródłowy wiadomości w datagramie IP jest adresem lokalnym łącza wtedy klient jest na tym samym łączu, do którego dołączony jest interfejs serwera, z którego został otrzymany komunikat Jeśli serwer otrzymuje wiadomość od przekaźnika, wtedy klient jest na tym samym łączu, do którego przyłączony jest interfejs określony przez pole adres łącza w wiadomości otrzymanej od przekaźnika Jeśli serwer otrzymał wiadomość bezpośrednio od klienta i adres źródłowy w datagramie IP nie jest adresem lokalny łącza, wtedy klient znajduje się na łączu określonym przez adres źródłowy w datagramie IP (zauważmy, że ta sytuacja może wystąpić tylko wtedy, jeśli serwer umożliwił klientowi użycie adresu unicas i klient wysłał komunikat, dla którego dozwolone jest użycie adersu unicastowego). Identyfikator DUID dostarczony przez klienta Inna informacja zawarta w opcjach załączonych przez klienta Inna informacja zawarta w opcjach załączonych przez przekaźnik Jakikolwiek adres przypisany przez serwer, który jest oparty na identyfikatorze EUI-64 musi zawierać identyfikator interfejsu z bitami u (globalny/lokalny) i g (indywidualny/grupowy) interfejsu ustanwionymi porawniw, jak zdefiniowano w punkcie 2.5.1 RFC2373 [9]. Serwerowi nie wolno przypisywać adresu, który jest w zarezerwowany do innych celów. Przykładowo serwer nie może przypisać zarezerwowanych adresów anycast z jakiejkolwiek podsieci, jak zdefiniowano w RFC 2526 [15].

Protokoł DHCPv6 27 3.5 Wiadomości 3.5.1 Transmisja po stronie klienta Klienci DHCP są odpowiedzialne za niezawodne dostarczenie wiadomości w przypadku wymiany wiadomości inicjowanej przez klienta opisanej w punkcie 3.7. Jeśli klient DHCP nie otrzyma spodziewanej odpowiedzi od serwera musi retransmitować swoją wiadomość. Ten punkt opisuje sposób retransmisji używany przez klientów w przypadku wymiany wiadomości inicjowanej przez klienta. Zauważmy, że procedura opisana w tym punkcie jest tylko trochę zmodyfikowana, gdy używana jest wiadomość SOLICIT. Zmodyfikowana procedura jest opisana w punkcie 3.7.3. Klient rozpoczyna wymianę wiadomości poprzez transmisję wiadomości do serwera. Wymiana się kończy, gdy klient otrzyma właściwą odpowiedź lub wiele odpowiedzi od serwera lub serwerów, albo gdy wymiana wiadomości zostanie uznana za nieudaną zgodnie z mechanizmem opisanym poniżej. Zachowanie klienta w przypadku retransmisji jest kontrolowane i opisane poprzez następujące zmienne: RT Timeout retransmisji (ang. Retransmission timeout) IRT Początkowy czas retransmisji (ang. Initial retransmission time) MRC Maksymalna liczba retransmisji (ang. Maximum retransmission count) MRT Maksymalny czas retransmisji (ang. Maximum retransmission time) MRD Maksymalnu okres retransmisji (ang. Maximum retransmission duration) RAND Współczynnik randomizacji (ang. Randomization factor) Przy każdej transmisji lub retransmisji wiadomości, klient ustawia RT zgodnie z regułami podanymi poniżej. Jeśli RT upłynie zanim wymiana wiadomości zostanie zakończona, klient oblicza nową wartość RT i retransmituje komunikat. Każde z obliczeń nowej wartości uwzględnia współczynnik RAND, który jest wielkością losową z zakresu -0.1 i 0.1 o rozkładzie równomiernym. Współczynnik RAND pozwala na uniknięcie synchronizacji przy transmisji wiadomości przez klienty DHCP. Algorytm wyboru liczby losowej nie musi być skomplikowany. Algorytm powinien dawać różne sekwencje liczb losowych przy każdym wywołaniu przez klienta. RT dla transmisji pierwszej wiadomości jest określane w oparciu o IRT: RT = IRT + RAND IRT RT dla transmisji każdego następnego wiadomości jest określane na podstawie poprzedniej wartości RT: RT = 2 RT prev+rand RT prev MRT określa górną granicę na wartość RT (bez względu na dodawaną wartość losową). Jeśli MRT ma wartość 0, nie ma górnej granicy na wartość RT. W innym przypadku: Jeśli (RT > MRT ) RT = MRT + RAND MRT MRC określa maksymalną liczbę prób retransmisji wiadomości przez klienta. Jeśli MRC nie jest zerem, wymiana wiadomości uznana zostaje za nieudaną po wysłaniu wiadomości MRC razy. MRD określa maksymalny okres czasu, w ciągu którego klient może retransmitować komunikat. Jeśli MRC jest różne od zera, wymiana wiadomości uznana zostaje za nieudaną, gdy upłynie MRC sekund od momentu transmisji pierwszego wiadomości. Jeśli zarówno MRC i MRD są niezerowe, wymiana wiadomości uznana zostaje za nieudaną, gdy jeden z warunków podanych w dwóch powyższych akapitach zostanie spełniony. Jeśli zarówno MRC i MRD są równe zero, klient będzie kontynuował transmisję wiadomości, aż do momentu otrzymania odpowiedzi. 3.5.2 Sprawdzanie poprawności wiadomości Klienci i serwery powinny odrzucać wiadomości, które zawierają niedozwolone w danym komunikacie opcje np. opcja IA nie może się pojawić w komunikacie

28 Protokoł DHCPv6 INFORMATION-REQUEST. Klienci i serwery mogą wydobyć informację z takiego wiadomości jeśli informacja w nim zawarta może być przydatna dla odbiorcy. Serwer musi odrzucić jakiekolwiek komunikaty SOLICIT, CONFIRM, REBIND lub INFORMATION-REQUEST, które otrzymuje poprzez adres unicastowy. Jeśli serwer otrzymuje wiadomość, który zawiera opcję, której nie powinien zawierać (jak wiadomość INFORMATION-REQUEST z opcją IA ), nie zawiera wymaganej opcji lub jest niepoprawny, może wysłać wiadomość REPLY (lub ADVERTISE ) z opcją Server Identifier oraz opcją Client Identifier (jeżeli była zawarta w komunikacie) i kodem stanu UnSpecFail. 3.5.3 Użycie identyfikatora transakcji Pole identyfikator transakcji przechowuje wartość używaną przez klienty i serwery do synchronizacji odpowiedzi serwera z zapytaniami klienta. Klient powinien generować losową liczbę, która nie może być łatwo odgadnięta lub możliwa do przewidzenia, jako identyfikator transakcji dla każdego wiadomości, który wysyła. Zauważmy, że jeśli klient generuje łatwo przewidywalne numery transakcji, może być bardziej podatny na pewne sposoby ataku. Klient musi pozostawiać niezmieniony identyfikator transakcji przy retransmisji wiadomości. 3.5.4 Wiadomość SOLICIT Klienci muszą odrzucać każdy otrzymany wiadomość SOLICIT. Serwery muszą odrzucać jakikolwiek wiadomość SOLICIT, który nie zawiera opcji Client Identifier lub zawierający opcję Server Identifier. 3.5.5 Wiadomość ADVERTISE Klienci muszą odrzucać jakiekolwiek otrzymane komunikaty następujących warunków: ADVERTISE, które nie spełniają wiadomość nie zawiera opcji Server Identifier wiadomość nie zawiera opcji Client Identifier zawartość opcji Client Identifier nie pasuje do identyfikatora DUID klienta pole identyfikatora transakcji nie pasuje do wartości identyfikatora użytej komunikacie SOLICIT Serwery i przekaźniki muszą odrzucać jakikolwiek otrzymany komunikat ADVERTISE. 3.5.6 Wiadomość REQUEST Klienci muszą odrzucać jakiekolwiek otrzymane komuniakty REQUEST. Serwery muszą odrzucać jakiekolwiek otrzymane komunikaty, które nie spełniają jednego z poniższych warunków: wiadomość nie zawiera opcji Server Identifier zawartość opcji Server Identifier nie odpowiada identyfiatorowi DUID serwera wiadomość nie zawiera opcji Client Identifier

Protokoł DHCPv6 29 3.5.7 Wiadomość CONFIRM Klienci muszą odrzucać jakikolwiek otrzymany wiadomość CONFIRM. Serwery muszą odrzucać jakikolwiek wiadomość CONFIRM, który nie ma załączonej opcji Client Identifier lub nie zawiera opcji Server Identifier. 3.5.8 Wiadomość RENEW Klienci muszą odrzucać jakikolwiek otrzymany wiadomość RENEW. Serwery muszą odrzucać jakikolwiek wiadomość RENEW, który nie spełnia jednego z poniższych warunków: wiadomość musi zawierać opcję Server Identifier zawartość opcji Server Identifier musi odpowiadać identyfiatorowi DUID serwera wiadomość musi zawierać opcję Client Identifier 3.5.9 Wiadomość REBIND Klienci muszą odrzucać jakikolwiek otrzymany wiadomość REBIND. Serwey muszą odrzucać jakikolwiek wiadomość REBIND, który nie zawiera opcji Client Identifier lub który nie zawiera opcji Server Identifier. 3.5.10 Wiadomość DECLINE Klienci muszą odrzucać jakikolwiek otrzymany wiadomość DECLINE. Serwey muszą odrzucać jakikolwiek wiadomość DECLINE, który nie spełnia jednego z poniższych warunków: wiadomość musi zawierać opcję Server Identifier zawartość opcji Server Identifier musi odpowiadać identyfiatorowi DUID serwera wiadomość musi zawierać opcję Client Identifier 3.5.11 Wiadomość RELEASE Klienci muszą odrzucać jakikolwiek otrzymany wiadomość RELEASE. Serwey muszą odrzucać jakikolwiek wiadomość RELEASE, który nie spełnia jednego z poniższych warunków: wiadomość musi zawierać opcję Server Identifier zawartość opcji Server Identifier musi odpowiadać identyfiatorowi DUID serwera wiadomość musi zawierać opcję Client Identifier

30 Protokoł DHCPv6 3.5.12 Wiadomość REPLY Klienci muszą odrzucać jakikolwiek wiadomość warunków: REPLY, który nie spełnia jednego z poniższych wiadomość musi zawierać opcję Server Identifier zawartość pola identyfikatora transakcji musi odpowiadać wartości tego pola w komunikacie inicjującym wymianę. jeśli wiadomość inicjujący komunikację zawierał opcję Client Identifier, opcja ta musi być zawarta w komunikacie REPLY i jej zawartość musi odpowiadać identyfikatorowi DUID klienta lub jeśli klient nie zawarł tej opcji w komunikacie inicjującym wymianę wiadomość REPLY nie może zawierać opcji Client Identifier Serwery i relay muszą odrzucać jakikolwiek otrzymany wiadomość REPLY. 3.5.13 Wiadomość RECONFIGURE Serwery i przekaźniki muszą odrzucać jakikolwiek otrzymany wiadomość RECONFIGURE. Klienci muszą odrzucać jakikolwiek wiadomość RECONFIGURE, który nie spełnia jednego z poniższych warunków: wiadomość musi być przesłany na adres unicastowy klienta wiadomość musi zawierać opcję Server Identifier wiadomość musi zawierać opcję Client Identifier, która zawiera DUID klienta wiadomość musi zawierać opcję Reconfigure Message i msg-type musi mieć poprawną wartość wiadomość nie może zawierać opcji IA, jeśli msg-type w opcji Reconfigure Message ma wartość INFORMATION-REQUEST wiadomość musi zawierać uwierzytelnianie DHCP: 1. wiadomość zawiera opcję Authentication 2. wiadomość musi przejść test uwierzytelniający wykonany przez klienta 3.5.14 Wiadomość INFORMATION-REQUEST Klienci muszą odrzucać jakikolwiek otrzymany wiadomość INFORMATION-REQUEST. Serwey muszą odrzucać jakikolwiek wiadomość INFORMATION-REQUEST, który nie spłnia jednego z poniższych warunków: wiadomość zawiera opcję Server Identifier i identyfikator DUID zawarty w opcji nie odpowiada identyfikatorowi serwera wiadomość zawiera opcję IA 3.5.15 Wiadomość RELAY-FORWARD Klienci muszą odrzucać jakikolwiek otrzymany wiadomość RELAY-FORWARD.

Protokoł DHCPv6 31 3.5.16 Wiadomość RELAY-REPLY Klienci muszą odrzucać jakikolwiek otrzymany wiadomość RELAY-REPLY. 3.6 Opcje Opcje są używane do przenoszenia dodatkowych informacji i parametrów w wiadomości DHCP. Wszystkie opcje mają wspólny format opisany w punkcie 3.6.1. Wszystkie wartości w opcji są zapisywane w porządku sieciowym bajtów. Ten dokument opisuje opcje DHCP będące częśią podstawowej specyfikacji DHCP. Inne opcje mogą zostać zdefiniowane w przyszłości w oddzielnych dokumentach. Jeśli nie zostanie inaczej podane, każda opcja może pojawić się w obszarze opcji wiadomości DHCP i może pojawić się tylko raz. Jeśli opcja może pojawić się kilkakrotnie, każde wystąpienie jest uważane za oddzielne i obszary danych opcji nie mogą być żaden sposób połączone. 3.6.1 Format opcji Format opcji DHCP jest następujący: 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 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 Opcje DHCPv6 mają swój zasięg określony poprzez enkapsulację. Pewne opcje dotyczą głównie klienta. Inne dotyczą IA, a jeszcze inne adresu dla danego IA. Dwa ostatnie przypadki są omówione w puktach 3.6.4 i opcja 3.6.5 3.6.2 Opcja Client Identifier Opcja Client Identifier jest używana do przenoszenia identyfikatora DUID (patrz punkt 3.3) identyfikując klienta w komunikacji klient-serwer. Format opcji Client Identifier jest następujący: 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 OPTION CLIENTID option-len. DUID.. (zmienna długość)... option-code OPTION CLIENTID (1) option-len długość DUID w oktetach option-data DUID klienta

32 Protokoł DHCPv6 3.6.3 Opcja Server Identifier Opcja Serwer Identifier jest używana do przenoszenia identyfikatora DUID (patrz punkt 3.3) identyfikując serwer w komunikacji klient-serwer. Format opcji Server Identifier jest następujący: 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 OPTION SERVERID option-len. DUID.. (zmienna długość)... option-code OPTION SERVERID (1) option-len długość DUID w oktetach option-data DUID serwera 3.6.4 Opcja Identity Association 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ć: 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 OPTION IA NA option-len IAID (4 oktety) 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. Przestrzeń liczbowa identyfikatora IAID dla opcji IA NA jest oddzielona od przestrzeni identyfikatorów dla opcji IA TA. T1 Czas, po którym klient kontaktuje się z serwerem, od którego otrzymał adres w IA NA w celu przedłużenia czasu dzierżawy przypisanego adresu do 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.

Protokoł DHCPv6 33 Pole IA NA enkapsuluje te opcje, które są specyficzne dla IA NA. Przykładowo wszystkie opcje IA Address przenoszące adres związany 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ę czasu, w którym klient powinien ponownie skontaktować się z serwerem, jeśli chodzi o dane 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óry adres w IA NA powinien być odnowiony(renewed) powinien zostać odnowiony ma być ustalany przez klienta, serwer ustawia T1 i T2 na 0. 3.6.5 Opcja IA Address Opcja IA Address jest używana do podania adresów IPv6 związanych z danym IA. Opcja IA Address musi być enkapsulowana w polu opcji opcji IA. Pole opcji enkapsuluje te opcje, które są specyficzne dla tego adresu. Format opcji IA Address jest następujący: 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 OPTION IAADDR option-len IPv6 address) preferred-lifetime valid-lifetime. IAaddr-options... option-code OPTION IA TA (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 IAddr-options opcje związane z tym adresem

34 Protokoł DHCPv6 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 lub opcji IA TA. Więcej niż jedna opcja IA Address może pojawić się zarówno w opcji IA NA, jak i opcji IA TA. Stan operacji z użyciem danej opcji IA Address może być przenoszony w opcji Status Code w polu opcji IAaddr-options. 3.6.6 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: 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 OPTION ORO option-len request-option-code-1 request-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 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. 3.6.7 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: 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 OPTION PREFERENCE option-len pref-value) option-code OPTION PREFERENCE (7) option-len 1 pref-value wartość preferencji serwera dla tej wiadomości Serwer może załączyć opcję Preference w wiadomości ADVERTISE, aby kontrolować wybór serwera przez klienta. W punkcie 3.7.4 został opisany sposób użycia opcji Preference przez klienta i interpretację wartości opcji.

Protokoł DHCPv6 35 3.6.8 Opcja Elapsed Time 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 OPTION ELAPSED TIME option-len elapsed-time option-code OPTION ELAPSED TIME (8) option-len 2 pref-value elapsed time czas, po którym klient powinien rozpocząć 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ę wiadomości DHCP. Okres ten jest mierzony od momentu, w którym klient wysłał pierwszy wiadomość podczas danej wymiany wiadomości. 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. 3.6.9 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: 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 OPTION UNICAST option-len server-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 typu unicastowego w polu serweraddress. 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. Bardziej szczegółowe informacje dotyczące, kiedy klient może wysyłać wiadomości przy użyciu unicastu zostały podane w punkcie 3.7. 3.6.10 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:

36 Protokoł DHCPv6 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 OPTION STATUS CODE option-len status-code... status-message... 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 3.2 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 wiadomość DHCP i/lub 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. 3.6.11 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: 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 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 opisaną w punkcie 3.7.2. Serwer musi załączyć tę opcję w komunikacie Reply wysłanym w odpowiedzi na wiadomość 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 wiadomość Solicit, który zawiera opcję Rapid Commit, niektóre serwery przypiszą adresy, które nie zostaną użyte przez klienta. Problem nie wykorzystanych adresów może być minimalizowany poprzez np. projektowanie tak usługi DHCP, że tylko jeden serwer będzie odpowiadał na wiadomość SOLICIT lub użycie względnie krótkich czasów życia dla przypisywanych adresów.

Protokoł DHCPv6 37 3.6.12 Opcja User Class Opcja User Class jest używana przez klienta do identyfikacji typu lub kategorii użytkownika lub aplikacji, które reprezentuje. Format opcji User Class jest następujący: 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 OPTION USER CLASS option-len... user-class-data... option-code OPTION RAPID COMMIT (15) option-len długość pola user-class-data user-class-data klasy użytkownika przenoszone przez klienta Informacja zawarta w obszarze danych tej opcji jest zawarta w jednym lub więcej ciągłych polach, które reprezentują klasę lub klasy użytkownika, których klient jest członkiem. Serwer wybiera parametry konfiguracyjne dla klienta w oparciu o klasy określone w tej opcji. Przykładowo opcja User Class może być użyta, aby konfigurować wszystkich pracowników działu księgowości inaczej niż pracowników działu marketingu. Informacja o klasie użytkownika przenoszona w tej opcji musi być konfigurowalna przez klienta. Obszar danych opcji User Class musi zawierać jedno lub więcej wystąpień pola user-class-data. Każde Wystąpienie pola user-class-data ma następującą postać: user-class-len opaque-data... Pole user-class-len ma dwa oktety i określa długość ciągłych danych zawierających klasy użytkownika. Serwer interpretuje klasy zidentyfikowane w tej opcji zgodnie z swoją informacją konfiguracyjna, aby przesłać właściwe parametry konfiguracyjne klientowi. Serwer może użyć tylko tych klas użytkownika, które zostały skonfigurowane do interpretacji w czasie wybierania konfiguracji i ignorować wszystkie inne klasy. W odpowiedzi na wiadomość zawierającą opcję User Class, serwer załącza opcję User Class zawierającą te klasy, które zostały poprawnie zinterpretowane przez serwer, dzięki czemu klient jest poinformowany o klasach zinterpretowanych przez serwer. 3.6.13 Opcja VENDOR CLASS Ta opcja jest używana przez klienta do identyfikacji producenta, który wyprodukował sprzęt na którym działa klient. Informacja zawarta w obszarze danych tej opcji jest zawarta w jednym lub wielu ciągłych polach, które identyfikują szczegół konfiguracji sprzętowej. Format opcji VENDOR CLASS jest przedstawiony na poniższym rysunku. 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 OPTION VENDOR CLASS option-len enterprise-number... vendor-class-data...

38 Protokoł DHCPv6 option-code OPTION VENDOR CLASS (16) option-len 4 + długość pola vendor-class-data enterprise-number zarejestrowany numer korporacyjnu jak w IANA (uwaga [9] w drafcie)!!!) vendor-class-data konfiguracja sprzętowa hosta, na którym działa klient Pole vendor-class-data jest złożone z serii oddzielnych jednostek, z których każda opisuje pewną część konfiguracji sprzętowej klienta. Przykładowo wystąpienie opcji vendor-class-data może zawierać wersję systemu operacyjnego, na którym działa klient lub wielkość pamięci zainstalowanej w komputerze klienckim. Każde wystąpienie vendor-class-data ma postać: vendor-class-len opaque-data... Pole vendor-class-len jest dwu oktetowe i określa długość pojedynczego wystąpienia. 3.6.14 Opcja Vendor-specific Information Ta opcja jest używana przez klienty I serwery do wymiany informacji specyficzne dla dostawcy. Format opcji jest przedstawiony na poniższym rysunku: 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 OPTION VENDOR OPTS option-len enterprise-number... option-data... option-code OPTION VENDOR OPTS (17) option-len 4 + długość pola option-data enterprise-number zarejestrowany numer korporacyjny jak w IANA (uwaga [9] w drafcie)!!!) option-data ciągły obiekt o długości option-len oktetów, interpretowany przez klienta i serwera dzięki kodowi vendor-specific Definicja informacji przenoszonej w tej opcji jest wyspecyfikowana przez producenta. Producent jest określany poprzez pole enterprise-number. Użycie informacji określonej przez producenta pozwala rozszerzyć dziłanie i użyteczność, poprzez wprowadzanie nowych cech do implementacji protokołu DHCP danego producenta. Klient DHCP, który nie otrzymuje żądanej informacji vendor-specific będzie wciąż jednak w stanie skonfigurować stos IPv6 urządzenia hosta i funkcjonować poprawnie. Zaenkapsulowane opcje vendor-specific muszą być załączone jako ciąg pól code/length/value o identycznym formaci z polem opcji DHCP. Kody opcji są definiowane przez producenta identyfikowanego przez pole numeru producenta, który jest przydzielana przez IANA. Każda z zaenkapsulowanych opcji jest sformatowana następująco:

Protokoł DHCPv6 39 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 opt-code opt-len... option-data... opt-code kod zaenkapsulowanej opcji option-len liczba całkowita bez znaku określająca dłgość pola option-data w tej zaenkapsulowanej opcji option-data obszar danych zaenkapsulowanej opcji Wiele wystąpień opcji Vendor-specific Information może pojawić się w komunikacie DHCP. Każde wystąpienie opcji jest interpretowane zgodnie z kodami opcji zdefiniowanymi przez producenta określonego poprzez numer korporacyjny w tej opcji. 3.6.15 Opcja Reconfigure Accept Klient używa opcji Reconfigure Accept w celu poinformowania serwerowi, czy będzie akceptować wiadomości RECONFIGURE, a serwer używa tej opcji, aby poinformować klienta, czy ten ma akceptować wysyłane przez serwer komunikaty RECONFIGURE. Domyślnym zachowaniem w przypadku braku tej opcji jest brak chęci akceptacji wiadomości RECONFIGURE oraz nakaz odrzucania przez klienta wiadomości RECONFIGURE. Poniższy rysunek przedstawia format opcji Reconfigure Acccept : 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 OPTION RECONF ACCEPT 0 opt-code OPTION RECONF ACCEPT (20) opt-len 0 3.7 Zachowanie klienta Klient inicjalizuje wymianę wiadomości z serwerem lub serwerami w celu uzyskania lub zakualizowania interesujących go parametrów. Klient może zainicjować taką wymianę wiadomości jako część procedury konfiguracji systemu, kiedy zostanie taka czynność zażądana przez warstwę aplikacji lub gdy zakończy się okres ważności już przypisanego adresu (wiadomości RENEW i REBIND ). Klient używa wiadomości SOLICIT w celu znalezienia serwerów DHCP skonfigurowanych do przypisania adresów lub innych parametrów konfiguracyjnych na łączu, do którego klient jest dołączony. Klient posługuje się wiadomościami REQUEST, RENEW, REBIND, RELEASE i DEC- LINE w trakcie normalnego cyklu życiowego adresu. Używa wiadomości CONFIRM, aby potwierdzić adresy, kiedy zostanie przełączony do innego łącza. Używa wiadomości INFORMATION-REQUEST, kiedy potrzebuje informacji konfuracyjnych, ale nie potrzebuje adresów. Jeżeli klient dysponuje adresem o odpowiednim zasięgu, który może zostać użyty przez serwer i otrzymał od serwera wiadomość z ustawioną opcją Server Unicast, to wiadomości REQUEST, RENEW, RELEASE i DECLINE powinien wysyłać na adres unicastowy serwera. Dzięki użyciu adresu unicastowego możliwe jest uniknięcie opóźnień spowodowanych przez korzystanie z przekaźników, jak również uniknięcie nadmiaru i duplikacji odpowiedzi udzielonych przez wiele serwerów. Serwer powienien zezwalać na użycie adresu unicastowego tylko w przypadku, jeżeli nie jest używany pośrednik.

40 Protokoł DHCPv6 3.7.1 Adres źródłowy klienta i wybór interfejsu Kiedy klient wysyła wiadomość DHCP na adres All DHCP Relay Agents and Servers powinien wysłać wiadomość na interfejs, dla którego chce uzyskać informacje konfiguracyjne. Jednakże, klient może wysłać wiadomość poprzez inny interfejs przyłączony do tego samego łącza o ile tylko klient jest pewien, że oba interfejsy są przyłączone do tego samego łącza. Klient musi użyć adresu lokalnego łącza przypisanego interfejsowi, dla którego żada parametrów konfiguracyjnych, jako adres źródłowy w nagłówku datagramu IP. Kiedy klient wysyła wiadomość DHCP bezpośrednio do serwera poprzez adres unicastowy serwera (po otrzymaniu od serwera opcji Server Unicast ), adres źródłowy w nagłówku datagramu IP musi być adresem przypisanym do interfejsu, dla którego klient chce otrzymać informacje konfiguracyjne i który serwer może użyć do wysłania odpowiedzi. 3.7.2 Tworzenie wiadomości SOLICIT Ten rozdział opisuje sposób lokalizacji serwerów, które mogą przypisać adresy do IA należących do klienta. Klient jest odpowiedzialny za tworzenie IA i żądanie od serwera przypisania do nich adresów IPv6. Klient najpierw tworzy IA i przypisuje mu identyfikator IAID. Następnie klient transmituje wiadomość SOLICIT zawierający opcję IA opisującą IA. Serwery, które mogą przypisać adres do IA odpowiadają klientowi komunikatem ADVERTISE. Klient inicjuje wtedy wymianę informacji konfiguracyjnych jak zostało to opisane w punkcie 3.7. Jeśli klient zaakceptuje wiadomość REPLY z przypisanym adresem i innymi zasobami w odpowiedzi na wiadomość SOLICIT, klient załącza opcję Rapid Commit w komunikacie SOLICIT (patrz punkt 3.6.11). Klient ustawia pole msg-type na SOLICIT. Klient generuje identyfikator transakcji i wstawia go do pola transaction-id. Klient musi załączyć opcję a Client Identifier, aby pozwolić serwerowi na identyfikację. Klient załącza opcję IA dla wszystkich IA, dla których chce, aby serwer przypisał adresy. Klient może załączyć gotowe adresy w opcji IA, jako wskazówka dla serwera, jakie adresy chciałby mieć przypisane. Klientowi nie wolno załączać jakiejkolwiek innej opcji poza ściśle dozwolonymi w definicji poszczególnych opcji. Klient używa opcji IA NA, gdy chce przypisać adres stały, a opcji IA TA, gdy chce mieć przypisany adres tymczasowy. W komunikacie DHCP może zostać załączona zarówno jedna, jak i obie opcje jednocześnie. Klient musi załączyć opcję Option Request (patrz punkt 3.6.6), aby wskazać, jakimi parametrami jest on zainteresowany. Klient może dodatkowo załączyć wartości tych opcji, jako wskazówka dla serwera, jakie wartości chciałby otrzymać. Klient musi załączyć opcję Reconfigure Accept (patrz punkt 3.6.15) wskazującą, czy klient będzie akceptował wiadomość RECONFIGURE otrzymywaną od serwera. 3.7.3 Transmisja wiadomości SOLICIT Pierwszy wiadomość SOLICIT od klienta dla danego interfejsu musi być opóźniony o losowy okres od 0 do SOL MAX DELAY. W przypadku trransmisji wiadomości SOLICIT, kiedy protokół DHCP jest inicjowany przez protokołu IPv6 ND, opóźnienie pozwala na odczekanie pewnego okresu zanim zostanie zaincjowany proces autokonfiguracji (patrz punkt 5.5.3 RFC2462 [13]). To losowe opóźnienie pozwala na desynchronizację klienta, który został uruchomiony w tym samym momencie czas (np. po utracie zasilania). Klient transmituje wiadomość zgodnie z procedurą opisaną w punkcie 3.5.2 przy użyciu następujących parametrów: IRT = SOL T IMEOUT

Protokoł DHCPv6 41 MRT = SOL MAX RT MRC = 0 MRD = 0 Jeśli klient załączył opcję Rapid Commit w jego komunikacie SOLICIT, klient przerywa proces oczekiwania na odpowiedź, gdy tylko otrzyma komunikat REPLY z opcją Rapid Commit. Jeśli klient czeka na komunikat ADVERTISE, mechanizm w punkcie 3.5.2 jest modyfikowany w sposób opisany poniżej (tylko dla komuniaktu SOLICIT ). Wymiana wiadomości nie jest przerywana po otrzymaniu wiadomości ADVERTISE, dopóki nie upłynie RT. Klient będzie raczej zbierał komunikaty ADVER- TISE, do momentu upłynięcia timeoutu RT. Także, RT musi być wybrany, w taki sposób, aby być znacznie większy niż IRT poprzez wybór wartości współczynnika RAND znacznie większej od 0. Klient musi zbierać komunikaty ADVERTISE przez pierwsze RT sekund, chyba że otrzyma wiadomość ADVERTISE o priorytecie/preferencji równej 255. Wartość ta jest przenoszona w opcji Preference (patrz punkt 3.6.7). Jakikolwiek komunikat, który nie posiada tej opcji ma domyślnie priorytet o wartości 0. Jeśli klient otrzyma wiadomość o priorytecie 255, klient musi natychmiast zainicjować wymianę wiadomości (jak opisano w punkcie 3.5.2) poprzez wysłanie wiadomości REQUEST do serwera, od którego otrzymał wiadomość ADVERTISE. Jeśli klient otrzyma wiadomość ADVERTISE, który nie posiada opcji Preference z priorytetem o wartości 255, klient kontynuuje oczekiwanie, dopóki nie upłynie czas RT. Jeśli pzed upływem pierwszego RT klient otrzymał wiadomość ADVERTISE, klient może zainicjować wymianę wiadomości poprzez wysłanie wiadomości REQUEST. Jeśli klient nie otrzymał wiadomości ADVERTISE przed upłynięciem pierwszego RT, rozpoczyna mechanizm retransmisji opisany w punkcie 3.5.2. Klient przerywa retransmisję, gdy tylko otrzyma wiadomość ADVERTISE i nie czeka na dodatkowe komunikaty ADVERTISE. Klient DHCP powinien ustawić MRC i MRD na 0. Jeśli klient DHCP jest skonfigurowany z MRC lub MRD ustawionym na wartość różną od 0, musi zaprzestać konfiguracji interfejsu, gdy wymiana wiadomości zostanie uznana za nieudaną. Po tym jak klient zaprzestanie prób konfiguracji interfejsu, powinien rozpocząć od nowa proces konfiguracji po jakimś zewnętrznym zdarzeniu, jak restart systemu, czy zmiana łącza, do którego klient jest dołączony. 3.7.4 Odbiór wiadomości ADVERTISE Klient musi zignorować jakikolwiek wiadomość ADVERTISE, który zawiera opcję Status Code zawierającą wartość NoAddrsAvail. Klient może jedynie poinformować użytkownika o odebraniu takiej wiadomości. W przypadku otrzymania jednego lub więcej wiadomości ADVERTISE, klient wybiera jeden lub więcej wiadomości ADVERTISE w oparciu o następujące kryteria: 1. Komunikaty ADVERTISE o największym priotytecie są preferowane nad pozostałymi komunikatami 2. Z grupy wiadomości ADVERTISE o tym samym priorytecie, klient może wybrać te serwery, których komunikaty ADVERTISE zawierają informację najbardziej odpowiednią dla klienta. 3. Klient może wybrać serwer o niższym priorytecie, jeśli dany serwer rogłasza lepszy zestaw parametrówn np. dostępne adresy w IA. Gdy klient już wybrał wiadomość ADVERTISE, najczęściej zapamiętuje informacje o każdym serwerze tj. priorytet, rozgłaszane adresy, moment otrzymania wiadomości ADVERTISE itp. Jeśli klient potrzebowałby wybrać alternatywny serwer w przypadku, gdy wybrany serwer nie odpowiada, klient może wybrać następny serwer zgodnie z zasadami podanymi powyżej.

42 Protokoł DHCPv6 3.7.5 Tworzenie i transmisja wiadomości REQUEST Klient używa wiadomości REQUEST, aby przypisać adresy do IA, a także do zdobycia innych informacji konfiguracyjnych. Klient zawiera jedną lub więcej opcji IA. Na to serwer odpowiada adresami i innymi informacjami odnośnie IA. Informacje te są zawarte w polu opcji IA w wiadomości REPLY. Klient generuje wartość identyfikator transakcji i wstawia ją w pole transaction-id. Umieszcza też identyfikator serwera docelowego w plou Server Identifier. Klient musi umieścić własny identyfikator w polu opcji Client Identifier, aby serwer mógł go zidentyfikować. Klient dodaje również opcje, które uzna za konieczne. Wśród nich musi być jedna lub więcej opcji IA, jeżeli klient chce otrzymać adres. Klient musi dołączyć opcję Option Request aby zaznaczyć, które opcje pragnie otrzymać od serwera. Klient może dołączyć opcje z wartościami, jakie chciałby uzyskać będzie to podpowiedź dla serwera. Klient transmituje wiadomość, używając następująych parametrów: IRT = REQ T IMEOUT MRT = REQ MAX RT MRC = REQ MAX RC MRD = 0 Jeżeli wymiana wiadomości się nie uda, to klient podejmuje akcję zgodnie z lokalną polityką. Przykładem akcji klienta może być: wybór innego serwera z listy serwerów znanych klientowi (np. dzięki zebraniu listy serwerów, które odpowiedziały na wiadomość SOLICIT rozpocząć proces odkrywania serwera przerwać proces konfiguracji i zgłosić błąd. 3.7.6 Tworzenie i transmisja wiadomości CONFIRM Kiedy klient przemieści się z jednego łącza do innego, może okazać się, że prefiks, z którego korzystał do tej pory jest już nieaktualny. Przykłady podobnych zdarzeń. klient uruchomiony zostaje ponownie klient zostje podłączony fizycznie do sieci klient używa technologii bezpezwodowej i właśnie zmienił stację bazową. W każdej sytuacji, kiedy klient zmienił łącze, klient musi zainicjować wymianę wiadomości CON- FIRM / REPLY. Klient dołącza wszystkie IA przypisane do danego interfejsu, a które mogły zostać przeniesione. Przesyłane są również adresy skojarzone z IA. Serwery odpowiadają czy te adresy są aktualne dla aktaulnego łącza. Klient ustawia pole msg-type na wartość CONFIRM. Klient generuje identyfikator transakcji i wstawia jego wartość do pola transaction-id. Klient musi dołączyć opcję Client Identifier, aby zidentyfikować się serwerowi. Klient dołącza opcje IA dla wszystkich IA przypisanych do interfejsu, dla którego wiadomość CONFIRM jest właśnie wysyłana. Te opcje muszą zawierać wszystkie adresy, które klient ma obecnie przypisane do tych IA. Klient powinien ustawić pola T1 i T2 w opcjach IA NA oraz preferowany czas życia i poprawny czas życia (preferred-lifetime i valid-lifetime) na 0, ponieważ serwer zignoruje te wartości. Pierwsza wiadomość CONFIRM od klienta musi być opóźniona o pewien losowy okres czasu pomiędzy 0 i CNF MAX DELAY. Klient transmituje wiadomość przy wykorzystaniu następujących parametrów:

Protokoł DHCPv6 43 IRT = CNF T IMEOUT MRT = CNF MAX RT MRC = 0 MRD = CNF MAX RD Jeżeli klient nie otrzyma odpowiedzi przed zakończeniem procesu transmisji wiadomości, powinien on nadal używać posiadanych adresów IP, zgodnie ze znanymi czasami życia dla tych adresów, a także powinien nadal używać znanych do tej pory parametrów konfiguracyjnych. 3.7.7 Tworzenie i transmisja wiadomości RENEW Aby przedłużyć preferowany czas życia dla posiadanych adresów IP, klient wysyła wiadomość RE- NEW do serwera, od którego otrzymał te adresy. Klient dołącza opcję IA Address. Serwer określa nowe czasy życia dla poszczególnych adresów zgodnie z ustawionymi parametrami administracyjnymi. Serwer może też dodać nowe adresy. Serwer może usunąć adresy poprzez ustawienie preferowanego i poprawnego czasu życia tych adresów na zero. Serwer kontroluje czas, kiedy klient kontaktuje się z serwerem w celu przedłużenia czasów życia nadanych mu adresów poprzez parametry T1 i T2 nadane konkretnemu IA. Po upływie czasu T1 klient rozpoczyna wymianę wiadomości RENEW / REPLY, aby przedłużyć czasy życia adresów. Klient dołącza opcję IA ze wszystkimi adresami obecnie przyporządkowanymi do IA. Jeżeli T1 lub T2 są ustawione przez serwer na 0 lub wogóle nie ma czasów T1 lub T2, klient może wysłać wiadomość RENEW lub REBIND Klient ustawia pole msg-type na RENEW. Klient generuje identyfikator transakcji i umieszcza go w polu transaction-id. Klient umieszcza indentyfiaktor serwer w polu Server Identifier. Klient musi dołączyć opcję Client Identifier, aby zidentyfikować siebie serwerowi. Klient dodaje wszystkie potrzebne opcje, włącznie z przynajmniej jedną opcją IA. Klient musi dołączyć listę adresów, których obecnie używa w powiązaniu z IA w wiadomości RENEW. Klient musi dołączyć opcję Option Request aby zaznaczyć, które opcje chciałby otrzymać. Klient może dołączyć opcje z danymi jako podpowiedź dla serwera, jakie wartości parametrów chciałby otrzymać. Klient transmituje wiadomość z użyciem następujących parametrów: IRT = REN T IMEOUT MRT = REN MAX RT MRC = 0 MRD =Czas pozostały do T2 Wymiana wiadomości zostaje zakończona, gdy upłynie czas T2, kiedy to klient rozpoczyna wysyłanie wiadomości REBIND. 3.7.8 Tworzenie i transmisja wiadomości REBIND Po upływie czasu T2 dla danego IA (który upłynie tylko w przypadku, jeżeli serwer nie odpowiada na wiadomości RENEW, które klient rozpoczął wysyłać po upływie czasu T1), klient rozpoczyna wymianę wiadomości REBIND / REPLY z dostępnym serwerem. Klient dołącza opcję IA ze wszystkimi adresami przypisanymi obecnie do IA.

44 Protokoł DHCPv6 Klient ustawia pole msg-type na REBIND. Klient generuje identyfikator transakcji i umieszcza go w polu transaction-id. Klient musi dołączyć opcję Client Identifier, aby zidentyfikować siebie serwerowi. Klient dodaje wszystkie potrzebne opcje, włącznie z przynajmniej jedną opcją IA. Klient musi dołączyć listę adresów, który obecnie używa w powiązaniu z IA w wiadomości RENEW. Klient musi dołączyć opcję Option Request aby zaznaczyć, które opcje chciałby otrzymać. Klient może dołączyć opcje z danymi jako podpowiedź dla serwera, jakie wartości parametrów chciałby otrzymać. Klient transmituje wiadomość z użyciem następujących parametrów: IRT = REB T IMEOUT MRT = REB MAX RT MRC = 0 MRD=pozostały czas do końca czasu życia wszystkich adresów Wymiana wiadomości zostaje zakończona, gdy czasy życia dla wszystkich adresów przypisanych do IA przedawnią się. W takim przypadku klient ma kilka możliwości do wyboru: Klient może wysłać wiadomość SOLICIT, aby zlokalizować nowy serwer DHCP i wysłać do niego wiadomośc REQUEST Klient może dysponować innymi adresami przypisanymi do innych IA, więc może odrzucić przedawnione adresy 3.7.9 Tworzenie i transmisja wiadomości INFORMATION-REQUEST Klient używa wiadomości INFORMATION-REQUEST do zdobycia informacji konfiguracyjnych, które nie dotyczą adresów IP. Klient ustawia pole msg-type na INFORMATION-REQUEST. Klient generuje identyfikator transakcji i umieszcza go w polu transaction-id. Klient powinien dołączyć opcję Client Identifier, aby zidentyfikować się serwerowi. Jeżeli klient tego nie zrobi, serwer nie będzie w stanie zwrócić jakichkolwiek specyficznych dla danego klienta opcji lub nawet serwer może wogóle nie odpowiedzieć na taką wiadomość. Klient musi dołączyć opcję Option Request, aby zaznaczyć, które opcje chciałby otrzymać. Klient może dołączyć opcje z danymi jako podpowiedź dla serwera, jakie wartości parametrów chciałby otrzymać. Pierwsze wysłanie wiadomości INFORMATION-REQUEST musi zostać opóźnione o losową ilość czasu pomiedzy 0 i INF MAX DELAY. Klient transmituje wiadomość z użyciem następujących parametrów: IRT = INF T IMEOUT MRT = INF MAX RT MRC = 0 MRD = 0

Protokoł DHCPv6 45 3.7.10 Tworzenie i transmisja wiadomości RELEASE Aby zwrócić jeden lub więcej adresów, klient wysyła wiadomość RELEASE do serwera. Klient ustawia pole msg-type na RELEASE. Klient generuje identyfikator transakcji i umieszcza go w polu transaction-id. Klient umieszcza identyfikator serwera, który przydzielił adresy w polu opcji Server Identifier. Klient musi dołączyć opcję Client Identifier, aby zidentyfikować się serwerowi. Klient dołącza opcje zawierające IA dla adresów, które właśnie zwalnia. Adresy, które są właśnie zwalniane muszą zostać zawarte w IA. Klient nie może używać jakiegokolwiek adresu, który właśnie zwalnia, jako adresu źródłowego wiadomości. Ponieważ wiadomości RELEASE mogą zostać utracone, klient powinien retrasmitować wiadomość RELEASE, jeżeli nie otrzymał odpowiedzi w postaci pakietu REPLY. Są jednak takie przypadki, kiedy klient nie chce czekać (np. procedura wyłączenia hosta). Implementacje powinne przynajmniej raz retransmitować wiadomość RELEASE. Klient transmituje wiadomość z użyciem następujących parametrów: IRT = REL T IMEOUT MRT = 0 MRC = REL MAX MRC MRD = 0 Klient musi zaprzestać używania adresów, jak tylko rozpocznie wysyłanie wiadomości RELEASE. Jeżeli adresy zostaną zwolnione, ale odpowiedź serwera (wiadomość REPLY ) zostanie zagubiona, to klient retransmituje wiadomość RELEASE. Jeżeli w takiej sytuacji serwer odpowie wiadomością REPLY, to ona zawierać status NoBinding. Dlatego klient nie powinien traktować odpowiedzi REPLY z ustawionym kodem błędu NoBinding jako błędu. Należy zauważyć, że jeżeli klient nie zwróci adresów, serwer uzna je za dostęne po przekroczeniu ich czasu życia. 3.7.11 Tworzenie i transmisja wiadomości DECLINE Jeżeli klient wykryje, że jeden lub więcej adresów przypisanych mu przez serwer jest już w użyciu przez inny węzeł, to klient wysyła wiadomość DECLINE do serwera, aby poinformować go o tym fakcie. Klient ustawia pole msg-type na DECLINE. Klient generuje identyfikator transakcji i umieszcza go w polu transaction-id. Klient umieszcza identyfikator serwera, który przydzielił adresy w polu opcji Server Identifier. Klient musi dołączyć opcję Client Identifier, aby zidentyfikować się serwerowi. Klient dołącza opcje zawierające IA dla adresów, które spowodowały konflikt. Adresy, które powodują konflikt muszą zostać zawarte w IA. Klient nie może używać jakiegokolwiek adresu, który powoduje konflikt, jako adresu źródłowego wiadomości. Klient transmituje wiadomość z użyciem następujących parametrów: IRT = DEC T IMEOUT MRT = 0 MRC = DEC MAX MRC MRD = 0

46 Protokoł DHCPv6 Jeżeli adresy zostały przesłane we wiadomości DECLINE, ale odpowiedź serwera zaginęłą, klient powinien retransmitować wiadomość DECLINE i serwer może odpowiedzieć wiadomością REPLY z ustawioną flagą NoBinding. Dlatego też kleint nie powinien traktować odpowiedzi z ustawioną flagą NoBinding jako błędu. 3.7.12 Odbiór wiadomości REPLY Jeśli klient załączył opcję Rapid Commit w komunikacie SOLICIT, będzie się spodziewał wiadomości 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 poprawny wiadomość REPLY z opcją Rapid Commit, przetwarza ten wiadomość w sposób opisany w punkcie 3.7.12. Jeśli nie otrzyma wiadomości REPLY i nie otrzyma poprawnego wiadomości ADVERTISE jak opisano w punkcie 3.7.4. Po odebraniu wiadomości REPLY, która jest odpowiedzią na wiadomości SOLICIT, REQUEST, CONFIRM, RENEW, REBIND lub INFORMATION-REQUEST, klient uzyskuje informacje konfiguracyjne. Klient powinien sprawdzić dla każdego adresu, który otrzyma, czy nie jest on już używany, zanim rozpocznie jakąkolwiek transmisję z wykorzystaniem tego adresu. eżeli klient wykryje, że otrzymany adres jest używany, wysyła wiadomośc DECLINE do serwera. Jeżeli wiadomość REPLY została odebrana jako odpowiedź na wiadomość SOLICIT z ustawioną opcją Rapid commit, REQUEST, RENEW lub REBIND, klient uaktualnia informacje, które posiada odnośnie IA, w szczególności: zapamiętuje ustawienia zegarów T1 i T2 zapamiętuje nowe adresy z opcji IA uaktualnia czasy życia dla adresów, które już pamięta odrzuca adresy, które mają czasy życia równe 0 Jeżeli klient odbierze wiadomość REPLY z ustawioną opcją Status Code na wartość UnspecFail, serwer daje znać, że nie był w stanie przetworzyć wiadomości na skutek nieokreślonego błędu. Jeżeli klient retransmituje oryginalną wiadomość do tego samego serwera, musi ograniczyć tempo, w jakim retransmituje wiadomości, jak również ograniczyć czas, w którym będzie przeprowadzał retransmisje. Jezeli klient otrzyma wiadomość REPLY z ustawioną opcją Status Code na wartość UseMulticast, musi zapamiętać nadawcę tej wiadomości i kolejne wiadomości wysyłać za pomocą multicastu poprzez interfejs, z którego otrzymał wiadomość REPLY. Musi też wysłać ponownie swoją wiadomość za pomocą multicastu. Kiedy klient otrzyma wiadomość z ustawionym statusem NotOnLink w odpowiedzi na wiadomość REQUEST, klient może wysłać wiadomość REQUEST bez specyfikowania jakichkolwiek adresów lub zrestartować procedurę odkrywania serwerów DHCP. Kliedy klient odbierze wiadomość z ustawionym statusem NoAddrsAvail w odpowiedzi na wiadomość REQUEST, klient może spróbować odpytać inny serwer lub wysłać wiadomość Information-Reqest w celu uzyskania tylko parametrów konfiguracyjnych (bez adresów IP). Kiedy klient odbierze wiadomość REPLY z ustawionym statusem NoBinding, musi wysłać wiadomość REQUEST, aby zarejestrować IA. Kiedy klient odbierze poprawną wiadomość REPLY w odpowiedzi na wiadomość RELEASE lub DECLINE, klient traktuje zdarzenie RELEASE jako zakończone, bez względu na status zawarty w otrzymanej odpowiedzi.

Protokoł DHCPv6 47 3.8 Zachowanie serwera W większości przypadków, serwer odpowiada wiadomością REPLY na wiadomości klientów. Wiadomość REPLY musi zawierać ustawioną wartość pola Server Identifier i zawierać wartość DUID serwera, a także opcję Client Identifier, o ile odpowiednie pole zostało ustawione w wiadomości klienta. Serwer powinien ograniczyć ilość opcji przesyłanych we wiadomości w taki sposób, aby nie dopuścić do fragmentacji pakietu. Jeżeli klient dołączył opcję Option Request do swojej wiadomości, to serwer dołącza oczekiwane opcje. Serwer może dołączyć dodatkowe opcje, jeżeli został tak skonfigurowany. 3.8.1 Odbiór wiadomości SOLICIT Serwer ustala informacje dotyczące klienta, jak to opisano w pkt. 11 powyżej i sprawdza politykę administracyjną w stosunku do klienta. Jeśli serwer nie ma pozwolenia na odpowiadanie temu klientowi, serwer odrzuca komunikaty SOLICIT. Przykładowo jeśli polityka administracyjna serwera jest taka, że odpowiada klientom, którzy akceptują wiadomość RECONFIGURE, a klient załącza opcję Reconfigure Accept określającą brak akceptacji dla wiadomości RECONFIGURE, serwer może odrzucić ten wiadomość SOLICIT. Jeśli klient załączył opcję Rapid Commit w komunikacie Sollicit i serwer został skonfigurowany z możliwością natychmiastowego przypisywania adresów i innych zasobów, serwer odpowiada na wiadomość SOLICIT komunikatem REPLY jak opisano w punkcie 3.8.3. Inaczej serwer ignoruje opcję Rapid Commit i przetwarza pozostałą część wiadomości, jak gdyby opcja Rapid Commit była nieobecna. 3.8.2 Tworzenie i transmisja wiadomości ADVERTISE Serwer wysyła wiadomość ADVERTISE w odpowiedzi na poprawny komunikat SOLICIT, w celu poinformowania klienta o dostępności serwera. Serwer ustawia pole msg-type na wartość ADVERTISE i kopiuje zawartość pola transaction-id z wiadomości SOLICIT odebranej od klienta. Serwer dołącza identyfikator serwera w opcji Server Identifier i kopiuje opcję Client Identifier z wiadomości SOLICIT. Serwer może dodać opcję Preference, aby przekazać wartość preferowaną dla wiadomości ADVERTISE. Implementacja serwera powinna umożliwiać ustawienie preferowanej wartości przez administratora. Domyslną wartością musi być 0, o ile nie zostanie podana inna przez administratora. Serwer musi dodać opcję Reconfigure Accept, aby zaznaczyć, kiedy klient musi zaakceptować, a kiedy odrzucić wiadomości RECONFIGURE. Serwer dołącza opcje, które prześle klientowi, w kolejnej wiadomości REPLY. Te informacje mogę zostać użyte przez klienta przy wyborze serwera, z którego usług zamierza korzystać (w przypadku, kiedy ma kilka serwerów do wyboru). Jeżeli klient dołączył opcję Option Request do wiadomości SOLICIT, to serwer dołącza opcje zawierające konfiguracje dla wszystkich parametrów zażądanych przez klienta. Serwer może zwrócić dodatkowe opcje, jeżeli został tak skonfigurowany. Powinien jednak zadbać o to, żeby ilość dołączonych opcji nie spowodowała fragmentacji pakietu. Jeżeli wiadomość SOLICIT od klienta zawierała jedną lub więcej opcji IA, to serwer musi dpołączyć opcję IA do wiadomości ADVERTISE, która zawiera jakiekolwiek adresy, które będą przypisane do tych IA. Jeżeli klient załączył adres w opcji IA w wiadomości SOLICIT, to serwer używa tych adresów jako podpowiedzi odnośnie adresów, które klient chciałby otrzymać. Jeżeli serwer nie przypisze żadnych adresów do żadnych IA z wiadomości REQUEST otrzymanej od klienta, to musi wysłać wiadomość ADVERTISE, która zawiera tylko opcję Status Code z kodem NoAddrAvail oraz statusem wiadomości, opcją Server Identifier z ustawionym DUID serwera oraz opcją Client Identifier zawierającą DUID klienta. Jeżeli wiadomość SOLICIT została odebrana bezpośrednio przez serwer, odpowiedź - wiadomość ADVERTISE musi zostać wysłana na adres unicastowy, z którego przyszła wiadomość SOLICIT

48 Protokoł DHCPv6. Wiadomośc ADVERTISE musi zostać wysłana przez interfejs, przez który otrzymano wiadomość SOLICIT. 3.8.3 Tworzenie i transmisja wiadomości REPLY Jeżeli oryginalna wiadomość została odebrana bezpośrednio przez serwer, serwer musi odpowiedzieć również bezpośrednio używając adresu z pola adresu źródłowego we wiadomości, na którą aktualnie serwer odpowiada. Wiadomość musi zostać wysłana przez interfejs, którym otrzymano wiadomość od klienta. Serwer musi przyznać adresy lub inne informacje konfiguracyjne przed wysłaniem wiadomości REPLY w odpowiedzi na wiadomość SOLICIT klienta. W przypadkach, kiedy ma miejsce wymiana wiadomości SOLICIT REPLY, serwer musi przyznać adresy przed wysłaniem wiadomości REPLY. Klient może założyć, że adresy otrzymane w wiadomości REPLY zostały mu nadane i nie musi wysyłać wiadomości REQUEST z prośbą o ich przyznanie. W typowych warunkach serwery, które zostały skonfigurowane do przeprowadzania wymiany wiadomości SOLICIT - REPLY powinny być tak rozmieszczone, że na każdą wiadomość SOLICIT odpowie tylko jeden serwer. Jeżeli zdarzy się tak, że na jedną wiadomość SOLICIT odpowie kilka serwerów, to klient wybiera jedną z nich i używa tylko adresów z tej odpowiedzi. Adresy nadane przez pozostałe serwery zostaną zaznaczone jako nadane klientowi, chociaż klient nie będzie z nich korzystał. Serwer dołącza opcję Rapid Commit w wiadomości REPLY, aby zaznaczyć, że wiadomość REPLY jest odpowiedzią na wiadomość SOLICIT. Serwer musi dodać opcję Reconfigure Accept, aby zaznaczyć, kiedy klient musi zaakceptować lub odrzucić wszystkie wiadomości RECONFIGURE, jakie otrzyma. 3.8.4 Odbiór wiadomości REQUEST Kiedy serwer odbierze wiadomość REQUEST przez normalny adres unicastowy od klienta, do którego nie wysyłał opcji Server unicast, serwer odrzuca wiadomość i odpowiada wiadomością REPLY z ustawioną opcją Status Code na wartośćusemulticast, opcją Server Identifier na wartość DUID serwer i opcją Client Identifier zawierającą wartość podaną przez klienta. Serwer nie może dołączyć żadnych innych opcji. Kiedy serwer odbierze poprawną wiadomość REQUEST, tworzy powiązanie dla klienta i zapamiętuje podane przez klienta IA. Serwer tworzy wiadomość REPLY przez ustawienie pola msg-type na wartość REPLY i skopiowanie identyfikatora transakcji z wiadomości Reqest do pola transaction-id. Serwer musi dołączyć opcję Server Identifier zawierającą DUID serwera oraz opcję Client Identifier zawierającą wartość podaną przez klienta. Jeżeli serwer stwierdzi, że jeden lub więcej prefiksów adresów IP w wiadomości od klienta nie jest odpowiedni dla danego łącza, to odpowiada klientowi wiadomością z ustawioną opcją Status Code na wartość NotOnLink. Jeżeli serwer nie jest w stanie przydzielić żadnych adresów do IA przekazanych przez klienta, serwer musi dołączyć opcję IA w wiadomości REPLY bez przypisanego adresu, a także ustawić opcję Status Code na wartość NoAddrsAvail. Dla każdego ia, dla którego serwer jest w stanie przydzielić adresy, serwer dołącza IA wraz z nadanymi adresami. Serwer zapamiętuje powiązanie dla klienta powiązanie IA z adresami. Serwer musi dodać opcję Reconfigure Accept, aby zaznaczyć, że klient powinien akceptować wiadomości RECONFIGURE. Serwer dołącza też inne opcje zawierające informacje konfiguracyjne.

Protokoł DHCPv6 49 3.8.5 Odbiór wiadomości CONFIRM Kiedy serwer odbierze wiadomość CONFIRM, sprawdza czy adresy w tej wiadomości są odpowiednie dla łącza, do którego dołączony jest klient. Jeżeli wszystkie adresy w wiadomości przejdą ten test, serwer zwraca status Success. Jeżeli jakikolwiek adres nie przejdzie tego testu, serwer zwraca status NotOnLink. Jezeli serwer nie jest w stanie przeprowadzić testu (np. serwer nie posiada informacji o prefiksach dla łącza, do którego podłączony jest klient) lub nie było żadnych adresów przypisanych do żadnego z IA przysłanych przez klienta, serwer nie może przesłać klientowi odpowiedzi. Serwer ignoruje pola T1 i T2 i opcjach IA oraz pola preferred-lifetime i valid-lifetime w opcjach adresu. Serwer tworzy wiadomość REPLY poprzez ustawienie pola msg-type na wartość REPLY i kopiuje identyfikator transakcji z wiadomości CONFIRM do pola transaction-id. Serwer musi dołączyć opcję Server Identifier zawierającą DUID serwera oraz opcję Client Identifier zawierającą wartość podaną przez klienta. Serwer dołącza opcję Status Code zaznaczając status wiadomości CONFIRM. 3.8.6 Odbiór wiadomości RENEW Kiedy serwer odbierze wiadomość RENEW przez normalny adres unicastowy od klienta, do którego nie wysyłał opcji Server unicast, serwer odrzuca wiadomość i odpowiada wiadomością REPLY z ustawioną opcją Status Code na wartość UseMulticast, opcją Server Identifier na wartość DUID serwer i opcją Client Identifier zawierającą wartość podaną przez klienta. Serwer nie może dołączyć żadnych innych opcji. Kiedy serwer odbierze wiadomość RENEW, która zawiera IA od klienta, serwer lokalizuje powiązanie i sprawdza, czy informacja przesłana przez klienta pokrywa się z wersją zapamiętaną. Jeżeli serwer nie może znaleźć powiązania dla ia, zwraca IA bez przypisanych adresów ze opcją Status Code ustawioną na wartość NoBinding i wiadomości REPLY. Jeżeli serwer stwierdzi, że jeden lub więcej prefiksów adresów IP w wiadomości od klienta nie jest odpowiedni dla danego łącza, to odsyła ten adres klientowi z czasem życia ustawionym na 0. Jeżeli serwer znajdzie adresy w IA dla klienta, odsyła IA klientowi z nowymi wartościami czasów życia i licznikami T1 i T2. Serwer może zmienić listę adresów i czasów życia adresów zwracanych klientowi. Serwer konstruuje wiadomość REPLY przez ustawienie pola msg-type na wartość REPLY i skopiowanie identyfikatora transakcji z wiadomości klienta. Serwer może dołączyć inne opcje konfiguracyjne, które zostaną przesłane klientowi. 3.8.7 Odbiór wiadomości REBIND Kiedy serwer odbierze wiadomość REBIND, która zawiera IA od klienta, serwer lokalizuje powiązanie i sprawdza, czy informacja przesłana przez klienta pokrywa się wersją zapamiętaną. Jeżeli serwer nie może znaleźć powiązania dla ia, zwraca IA bez przypisanych adresów ze opcją Status Code ustawioną na wartość NoBinding i wiadomości REPLY. Jeżeli serwer stwierdzi, że jeden lub więcej prefiksów adresów IP w wiadomości od klienta nie jest odpowiedni dla danego łącza, to odsyła ten adres klientowi z czasem życia ustawionym na 0. Jeżeli serwer znajdzie adresy w IA dla klienta, odsyła IA klientowi z nowymi wartościami czasów życia i licznikami T1 i T2. Serwer konstruuje wiadomość REPLY przez ustawienie pola msg-type na wartość REPLY i skopiowanie identyfikatora transakcji z wiadomości klienta. Serwer musi dołączyć opcję Server Identifier zawierającą DUID serwera, a także identyfikator transakcji identyczny z otrzymanym od klienta.

50 Protokoł DHCPv6 3.8.8 Odbiór wiadomości REQUEST-INFORMATION Kiedy serwer otrzyma wiadomość Request-Information oznacza to, że klient prosi o informacje konfiguracyjne, które nie obejmują przypisania adresów. Serwer ustala wszystkie parametry dotyczące klienta zgodnie z konfiguracją serwera. Serwer tworzy wiadomość REPLY przez ustawienie pola msg-type na wartość REPLY i skopiowanie identyfikatora transakcji z wiadomości Reqest do pola transaction-id. Serwer musi dołączyć opcję Server Identifier zawierającą DUID serwera. Jeżeli klient dołączył opcję Client Identification do swojej wiadomości Request-Information, serwer użyje tej wartości w opcję Client Identifier wiadomości REPLY. Jeżeli wiadomość Information-reqest odebrana od klienta nie zawierała opcji Client Identifier, to serwer powinien odpowiedzieć wiadomością REPLY zawierającą ogólne parametry konfiguracjne, nie związane z konkretnym klientem. Jeżeli serwer zdecyduje się nie odpowiedzieć na taką wiadomość, klient może retransmitować wiadomość INFORMATION-REQUEST w nieskończoność. 3.8.9 Odbiór wiadomości RELEASE Kiedy serwer odbierze wiadomość RELEASE przez normalny adres unicastowy od klienta, do którego nie wysyłał opcji Server Unicast, serwer odrzuca wiadomość i odpowiada wiadomością REPLY z ustawioną opcją Status Code na wartość UseMulticast, opcją Server Identifier na wartość DUID serwer i opcją Client Identifier zawierającą wartość podaną przez klienta. Serwer nie może dołączyć żadnych innych opcji. Kiedy serwer odbierze wiadomość RELEASE, która zawiera IA od klienta, serwer sprawdza poprawność IA i przypisanych adresów. Jeżeli adresy są przypisane ia, a dane IA zostało przypisane do klienta, serwer kasuje adresy z IA i zwraca je do puli adresów gotowych do przydzielenia innym klientom. Serwer ignoruje adresy nieprzypisane do IA, jednak może zalogować taki fakt jako błąd. Po przetworzeniu wszystkich adresów, serwer generuje wiadomość REPLY i dołącza do niej opcję Status Code ustawioną na wartość Success, opcję Server Identifier na DUID serwera oraz opcję Client Identifier na DUID klienta. Dla każdego IA w wiadomości RELEASE, dla którego serwer nie posiada informacji o powiązaniach, serwer dodaje opcję IA używając IAID z wiadomości RELEASE i dodaje opcję Status Code. Nie powinny zostać dodane żadne inne opcje. Serwer może zachować informację o przypisanych adresach już po zakończeniu ich czasów życia. Może to zrobić w celu późniejszego przydzielenia tego samego adresu temu samemu klientowi. 3.8.10 Odbiór wiadomości DECLINE Kiedy serwer odbierze wiadomość DECLINE przez normalny adres unicastowy od klienta, do którego nie wysyłał opcji Server Unicast, serwer odrzuca wiadomość i odpowiada wiadomością REPLY z ustawioną opcją Status Code na wartość UseMulticast, opcją Server Identifier na wartość DUID serwer i opcją Client Identifier zawierającą wartość podaną przez klienta. Serwer nie może dołączyć żadnych innych opcji. Kiedy serwer odbierze wiadomość RELEASE, która zawiera IA od klienta, serwer sprawdza poprawność IA i przypisanych adresów. Jeżeli adresy są przypisane IA, a dane IA zostało przypisane do klienta, serwer kasuje adresy z IA. Serwer powinien zaznaczyć adresy przesłane przez klienta jako odrzucone (ang. decline), aby w przyszłości nie przydzielać tych adresów innym klientom. Serwer ignoruje adresy nie przydzielone do IA (może jednak zdecydować się na zalogowanie błędu, jeżeli znajdzie taki adres). Po przetworzeniu wszystkich adresów, serwer generuje wiadomość REPLY i dołącza do niej opcję Status Code ustawioną na wartość Success, opcję Server Identifier na DUID serwera oraz opcję Client Identifier na DUID klienta. Dla każdego IA w wiadomości DECLINE, dla którego serwer nie posiada

Protokoł DHCPv6 51 informacji o powiązaniach, serwer dodaje opcję IA używając IAID z wiadomości DECLINE i dodaje opcję Status Code. Nie powinny zostać dodane żadne inne opcje.

52 Protokoł DHCPv6

Rozdział 4 Wspierane standardy 4.1 Potrzeba standaryzacji Biorąc pod uwagę brak scentralizowanej kontroli nad Internetem, dużym zagrożeniem dla jego funkcjonalności jest wprowadzanie wzajemnie niekompatybilnych rozwiązań. W celu uniknięcia tego typu niebezpieczeństwa, została powołana IETF Internet Engineering Task Force. Jest to organizacja, która nieustannie dba o znajdowanie pewnego wspólnego mianownika pomiędzy już istniejącymi rozwiązaniami, a także spójnym i przejrzystym definiowaniem zaleceń w sytuacji, gdy nie istnieją jeszcze ugruntowane rozwiązania. 4.2 Internet Engeneering Task Force IETF składa się z wielu grup roboczych. Każda z nich zajmuje się pewnym wybranym zagadnieniem. Tematyka DHCPv6 zawiera się w zakresie zainteresowania dwóch grup roboczych ITEF: IPv6 Working Group oraz DHC Working Group.. Należy zaznaczyć, że wyniki prac IETF publikowane są jako zalecenia, a nie standardy, a ich przestrzeganie jest dobrowolne. Wszystkie zalecenia (w każdej fazie rozwoju) są ogólnodostępne bez jakichkolwiek opłat, w przeciwieństwie do na przykład IEEE. Takie podejście rozwiązuje wiele kwestii formalnoprawnych. Dodatkową zaletą jest otwarty model opracowywanych zaleceń każdy zorientowany w temacie ma możliwość zgłoszenia swoich uwag i pomysłów w trakcie prac komisji. Co pewien czas komisje zajmujące się poszczególnymi zagadnieniami, publikują robocze wersje przyszłych zaleceń. Taka robocza wersja tzw. draft posiada numer wersji, a także datę ważności, po której zostanie zastąpiona następnym wydaniem. W sytuacji, kiedy grupa robocza uzna, że specyfikacja jest już wystarczająco stabilna i dopracowana, publikuje końcową wersję jako tzw. dokument Request For Comments. Pod IETF podlegają różne organizacje. Wsród nich bardzo ważną rolę pełni IANA Internet Assigned Numbers Authority.. Jest to organizacja zajmująca się nadawaniem unikatowych numerów poszczególnym opcjom. Dba o zachowanie unikalności przyjmowanych wartości. Przykładem działania IANA jest usystematyzowanie numerów opcji protokołu DHCP. Warto zauważyć, że znajdujące się obecnie w fazie roboczej specyfikacje [22] oraz [21] nie posiadają jeszcze przydzielonych wartości do poszczególnych opcji. Po zakończeniu prac nad tymi specyfikacjami, IANA oficjalnie przydzieli im konkrentne unikalne wartości. Więcej na temat historii, struktury oraz zadań IETF można znaleźć w [17]. Hipertestowa wersja tego dokumentu dostępna jest również pod adresem http://www.ietf.org/tao.html.

54 Wspierane standardy 4.3 Standardy W momencie rozpoczęcia niniejszej pracy, specyfikacja protokołu była dostępna w fazie draft-23. Obecnie dostępna jest już finalna wersja RFC 3315. Przedstawiona tutaj implementacja klienta i serwera DHCPv6 spełnia zalecenia następujących dokumentów: zalecenia RFC: drafty: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315 [18] IP Version 6 Addressing Architecture RFC 2373 [9] IPv6 Multicast Address Assignments RFC 2375 [10] Internet Protocol, Version 6 (IPv6) Specification RFC 2460 [11] IPv6 Stateless Address Autoconfiguration RFC2462 [13] DNS Configuration options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt) [22] Time Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt) [21]

Rozdział 5 Interfejsy programistyczne (API) i wymagania systemowe Oczywistym wymogiem względem środowiska, w którym będzie uruchamiany klient i serwer DHCPv6 jest obsługa sieci. Mam tutaj na myśli kompleksowe wsparcie dla rozwiązań sieciowych, oferowane przez wszystkie współczesne systemy linuxowe oraz unixowe, a także systemy firmy Microsoft. 5.1 Wymagana funkjonalność systemu operacyjnego By móc korzystać z systemu, konieczne jest spełnienie pewnych wymagań przez kernel. Lista niezbędnych usług to: obsługa protokołu IPv6 obsługa adresów typu multicast w rodzinie IPv6 dostępny interfejs sieciowy uruchamianie serwera i klienta z uprawnieniami administratora (roota) (konieczność otwarcia portów 546 i 547, przypisywanie adresów do interfejsu) 5.2 Interfejsy programistyczne (API) a model ISO/OSI Omawianie wykorzystywanych interfejsów programistycznych najłatwiej uporządkować odnosząc je do modelu ISO/OSI. warstwa Wykorzystywane API 7. aplikacji 6. prezentacji konwersja na format sieciowy 5. sesji 4. transportowa gniazda UDP 3. sieciowa przypisywanie/usuwanie adresów 2. łącza danych 1. fizyczna wyliczanie dostępnych interfejsów Wykorzystywane interfejsy programistyczne (tzw. API) zostały omówione w kolejności od warstwy fizycznej do prezentacji. W każdym przypadku wykorzystane funkcje są przedstawiane wraz z kodem. Dla przejrzystości została usunięta obsługa błędów (zakładamy, że wszystko przebiega poprawnie).

56 Interfejsy programistyczne (API) i wymagania systemowe 5.2.1 wyliczanie interfejsów System Linux wprowadza pojęcie interfejsu. Interfejsem jest każde urządzenie fizyczne lub logiczne, które jest w stanie transmitować i/lub odbierać dane. W szczególności każda rozpoznana karta sieciowa jest reprezentowana przez interfejs. Zwyczajowo karty sieciowe standardu Ethernet oznaczana są kolejno jako eth0, eth1 itd. Ważnym interfejsem logicznym jest interfejs lo, który stanowi tzw. pętlę zwrotną. Są do niego przypisane adresy IPv4 127.0.0.1 oraz IPv6 ::1. Dzięki temu interfejsowi implementacja stosów TCP/IPv4 oraz TCP/IPv6 zachowuje się stabilnie również w sytuacjach, kiedy to system pozbawiony jest jakichkolwiek interfejsów. (Gdyby usunąć interfejs lo, pojawiłby się problem z ustawianiem adresu źródłowego w wysyłanych pakietach. Dodatkowo, nie byłoby dokąd wysyłać pakietów.) Zarządzaniem pakietami zajmuje się kernel. Udostępnia on szereg funkcji, za pomocą których możliwe są operacje na poszczególnych interfejsach. Strony podręcznika poświęcone rtnetlink (rozdział 7) mówią: Network routes, ip addresses, link parameters, neighbour setups, queueing disciplines, traffic classes and packet classifiers may all be controlled through NETLINK_ROUTE sockets. Bezpośrednie korzystanie z funkcji udostępnianych przez kernel jest nieco utrudnione (bardzo rozbudowane struktury danych przekazywane jako parametry), dlatego też powstała biblioteka, która taką komunikację ma ułatwiać. Wchodzi ona w skład narzędzia systemowego iproute. Pośród wielu innych, udostępnia ona funkcje takie jak: int rtnl open(struct rtnl handle *rth, unsigned subscriptions) funkcja otwiera gniazdo sieciowe typu NETLINK ROUTE i zapisuje jego stan w strukturze rth. Struktura ta będzie używana przy wszystkich kolejnych odwołaniach do funkcji bibliotecznych int rtnl wilddump request(struct rtnl handle *rth, int family, int type) funkcja przesyła do kernela żądanie udostępnienia danych odnośnie interfejsów obsługującej dany typ. Można w ten sposób zażądać np. informacji o interfejsach już obsługujących gniazda IPv6. Dzięki wykorzystaniu rodziny AF PACKET, można zarządać listy wszystkich interfejsów, które obsługują ruch pakietowy (czy praktycznie każde urządzenie sieciowe). Dzięki tej cennej właściwości można uzyskać spis wszystkich interfejsów w systemie. int rtnl dump filter(struct rtnl handle *rth, int (*filter)(struct sockaddr nl *, struct nlmsghdr *n, void *), void *arg1, int (*junk)(struct sockaddr nl *,struct nlmsghdr *n, void *), void *arg2) to jedna z kluczowych funkcji. Dzięki niej możliwe jest wydobycie informacji zażądanych przez funkcję rtnl wilddump request. Jako drugi parametr funkcja pobiera adres innej funkcji-filtra, której zadaniem jest ocena, czy element jest pożądany, czy nie. Najczęstszym zastosowaniem jest pobór informacji o wszystkich interfejsach, zatem funkcja filtra w praktyce zwykle zapamiętuje dane wszystkich interfejsów (np. w wygodnej do późniejdzego przetworzenia listy). Argumenty 4 i 5 umożliwiają wykorzystanie dodatkowych funkcji filtrowania, ale ich użycie nie jest niezbędne, więc mogą posiadać wartości ustawione na NULL. Każdy interfejs, oprócz nazwy (np. eth0 dla pierwszego interfejsu ethernetowego lub wifi1 dla drugiej karty radiowej) dysponuje unikalnym numerem interfejsu. 1 Praktyczne wykorzystanie przedstawionych informacji, zobrazuje poniższy przykład. Ten oto krótki kod odczytuje listę wszystkich interfejsów i wypisuje je wraz z odpowiadającymi im numerami. 1 Z uwagi na przenośność (w niektórych systemach np. Windows nazwy interfejsów są czasem bardzo długie i zawierają znaki specjalne) w całym kodzie wykorzystywany jest właśnie numer interfejsu. Jedyne miejsce, gdzie używana jest nazwa interfejsu to obsługa pliku konfiguracyjnego. Odnalezienie numeru odpowiadającego konkretnego interfejsowi to jedna z pierwszych rzeczy wykonywanych po załadowaniu pliku konfiguracyjnego z dysku

Interfejsy programistyczne (API) i wymagania systemowe 57 struct rtnl_handle rth; struct nlmsg_list *linfo = NULL; struct nlmsg_list *l; struct rtattr * tb[ifla_max+1]; // utwórz socket rtnl_open(&rth, 0); // zażądaj informacji o interfejsach z rodziny AF_PACKET rtnl_wilddump_request(&rth, AF_PACKET, RTM_GETLINK); // pobierz dane udostępnione przez kernel rtnl_dump_filter(&rth, store_nlmsg, &linfo, NULL, NULL); // wyświetl kolejno informacje o interfejsach for (l=linfo; l; l = l->next) { ifi=nlmsg_data(&l->h); len = l->h.nlmsg_len; len -= NLMSG_LENGTH(sizeof(*ifi)); memset(tb, 0, sizeof(tb)); parse_rtattr(tb, IFLA_MAX, IFLA_RTA(ifi), len); printf("interfejs nr %d: %s \n", i++, (char*)rta\_data(tb[ifla\_ifname])); } 5.2.2 Przypisywanie i usuwanie adresów Po uzyskaniu informacji o dostępnych w systemie interfejsach, do akcji wkracza system DHCP. W przypadku klienta niezbędne jest przypisanie adresu ff02::1:2 do wszystkich interfejsów, które mają być obsługiwane. Po stronie klienta adresy przypisywane są po nadaniu ich przez serwer. W obu przypadkach wywołanie funkcji systemowych jest analogiczne. int ipaddr_add_or_del(char * addr, int ifaceid) { struct rtnl_handle rth; struct { struct nlmsghdr n; struct ifaddrmsg ifa; char buf[256]; } req; inet_prefix lcl; inet_prefix peer; int local_len = 0; int peer_len = 0; int scoped = 0; memset(&req, 0, sizeof(req)); req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifaddrmsg)); req.n.nlmsg_flags = NLM_F_REQUEST; // żądamy przypisania adresu IPv6 do interfejsu req.n.nlmsg_type = RTM_NEWADDR;

58 Interfejsy programistyczne (API) i wymagania systemowe req.ifa.ifa_family = AF_INET6; // ustalenie prefixu przypisywanego adresu get_prefix_1(&lcl, addr, AF_INET6); addattr_l(&req.n, sizeof(req), IFA_LOCAL, &lcl.data, lcl.bytelen); local_len = lcl.bytelen; if (peer_len == 0 && local_len) { peer = lcl; addattr_l(&req.n, sizeof(req), IFA_ADDRESS, &lcl.data, lcl.bytelen); } if (req.ifa.ifa_prefixlen == 0) req.ifa.ifa_prefixlen = lcl.bitlen; if (!scoped) req.ifa.ifa_scope = default_scope(&lcl); // otwarcie niskopoziomowego gniazda do komunikacji z kernelem rtnl_open(&rth, 0); // ustawienie, o który interfejs nam chodzi req.ifa.ifa_index = ifaceid; // wysłanie żądania rtnl_talk(&rth, &req.n, 0, 0, NULL, NULL, NULL); return 0; } W bardzo podobny sposób wykonywane jest usuwanie adres z danego interfejsu. Jedyna różnica polega na tym, że zamiast parametru RTM NEWADDR, używany jest RTM DELADDR. 5.2.3 gniazda UDP Po ewentualnym przypisaniu adresów (serwer), kolejnym krokiem jest przygotowanie do transmisji w warstwie transportowej. Protokół DHCPv6 działa w oparciu o przesyłanie pakietów UDP. Sposób otwarcia gniazd umożliwiających transmisję został przedstawiony poniżej. Oto skrócony kod programu wysyłający niewielki pakiet zawierający napis HELLO WORLD : int sd; struct sockaddr\_in6 srvaddr; int addrlen; int result; char line[32]; char iface[32]; char addr[32]; int portnum; char on; // port, na który będzie wysłany pakiet UDP

Interfejsy programistyczne (API) i wymagania systemowe 59 portnum = 546; // adres adresata sprintf(addr,"ff02::1:2"); // treść wiadomości sprintf(line,"hello WORLD"); // tworzenie gniazda (protokoł: IPv6, typ: datagramowe) sd = socket(pf\_inet6, SOCK\_DGRAM, 0); // dane będę wysyłane przez interfejs eth0 sprintf(iface,"eth0"); // bindowanie gniazda tylko do jednego interfejsu setsockopt(sd, SOL\_SOCKET, SO\_BINDTODEVICE, (char*)&iface, strlen(iface)+1); // budowa struktury zawierającej adres serwera bzero(&srvaddr, sizeof(srvaddr)); srvaddr.sin6\_family = AF\_INET6; srvaddr.sin6\_port = htons(portnum); inet\_pton(af\_inet6, addr, &srvaddr.sin6\_addr); // wysłanie danych sendto(sd,line,strlen(line)+1, 0, (struct sockaddr*)&srvaddr,sizeof(srvaddr)); // zamknięcie gniazda close(sd); Po ustawieniu parametrów transmisji (numer portu, interfejsu, przygotwanie bufora) następuje utworzenie gniazda za pomocą wywołania funkcji socket(). Warto zwrócić uwagę na na przedstawiony sposób przypisania gniazda do jednego konkretnego interfejsu. W ten sposób unikamy niejednoznaczności: załóżmy, że klient ma dwa interfejsu eth0 oraz eth1. Chce skomunikować się z serwerem dysponującym adresem ff02::1:2. Niestety, jest to adres o zakresie zażności na poziomie łącza, co oznacza, że na każdym łączu może istnieć oddzielny serwer posługujący się takim adresem. Zatem aby skomunikować się z hostem o takim adresie poprawne jest użycie zarówno interfejsu eth0, jak i eth1. Dlatego właśnie niezbędne jest przypisanie gniazda do konkretnego interfejsu. Następnie budowana jest struktura zawierająca adres odbiorcy. Na koniec następuje właściwa transmisja (funkcja sendto() ) oraz zamknięcie gniazda ( close() ). Oto, komplementarny do poprzedniego, program, nasłuchujący na porcie 546: int sd, portnum; struct sockaddr_in6 addr; struct sockaddr_in6 client; int addrlen; char buf[512]; char line[100]; char len; // port, na którym nasłuchujemy portnum = 546;

60 Interfejsy programistyczne (API) i wymagania systemowe // tworzenie socketa sd = socket(af_inet6, SOCK_DGRAM, 0); // tworzenie struktury adresowej bzero(&addr, sizeof(addr)); addr.sin6_family = AF_INET6; addr.sin6_port = htons(portnum); inet_pton(af_inet6, "0::0", &addr.sin6_addr); // bindowanie gniazda bind(sd, (struct sockaddr*)&addr, sizeof(addr) ); // zerowanie bufora odbiorczego memset(buf,0,512); // odbiór pakietu len=recvfrom(sd,buf,sizeof(buf), 0,(struct sockaddr *) &client, &addrlen); // wyświetlenie zawartości odebranego pakietu printf("odebrałem %d bajtów [%s]\n",len,buf); Podobnie przebiega procedura odbioru danych. Kilku słów komentarza wymaga wywołanie funkcji inet pton(af INET6, 0::0, &addr.sin6 addr). Funkcja ta powoduje, że akceptowane będą pakiety z dowolnego (0::0) adresu. Przed odbiorem konieczne jest tzw. zbindowanie gniazda, czyli przypisanie go do konkretnego portu. W ten sposób rozwiązany zostaje potencjalny problem niejednoznaczności, gdy dwa lub więcej gniazd chciałoby odbierać dane napływające do jakiegoś portu. Właśnie wywołanie funkcji bind() zwróci błąd drugiemu i kolejnym gniazom, które będą próbowały nasłuchiwać na już zajętym porcie. Po podłączeniu się do portu, można odczytać dane. W domyślnym trybie funkcja readfrom() jest blokująca, czyli w przypadku jeżeli nie będzie na razie danych do odczytania, to funkcja zaśnie do czasu przybycia oczekiwanych danych. Na koniec odebrane dane są wyświetlane. int socket(int domain, int type, int protocol) tworzone jest gniazdo w pewnej domenie (w przypadku niniejszej pracy zawsze będzie to AF INET6), dodatkowo można określić typ gniazda (np. datagramowe SOCK DGRAM). Ostatni parametr określający konkretny protokół, do którego będzie wykorzystywane gniazdo, nie jest używany. int bind(int sockfd, struct sockaddr *my addr, socklen t addrlen) bind nadaje gniazdu, określonemu za pomocą parametru sockfd, lokalny adres my addr. Ostatni parametr addrlen określa rozmiar struktury my addr. int recvfrom(int s,void *buf,size t len,int flags,struct sockaddr *from, socklen t *slen) odbiera dane z gniazda s. Dane zostają zapisane w pamięci w miejscu wskazanych przez buf. Maksymalna ilość danych odczytanych jest zapisana w zmiennej len. Za pomocą zmiennej flags można określić pewne dodatkowe parametry (np. odbieranie danych out-of-band). Pole from zawiera adres struktury, która określa, od kogo mogą być odebrane dane. Ostatnie pole określa rozmiar struktury wskazywanej przez from. sendto(int s, const void *msg, size t len, int flags, struct sockaddr *to,socklen t dl); wysyła dane poprzez gniazdo s. Zmienna msg wskazuje na adres pamięci, gdzie znajduje się wiadomość do wysłania, len określa jej rozmiar. Znaczenie flag jest analogiczne jak w przypadku recvfrom(). Dodatkowe 2 parametry to wskaźnik na strukturę określającą odbiorcę oraz rozmiar tej struktury.

Interfejsy programistyczne (API) i wymagania systemowe 61 setsockopt(sd,sol SOCKET,SO BINDTODEVICE,(char*)&iface, strlen(iface)+1) ogólna funkcja umożliwiająca ustawianie wielu różnych parametrów gniazd. W tym przypadku jest to wymuszenie nasłuchiwania tylko na jednym interfejsie. 5.2.4 Konwersja na format sieciowy Po utworzeniu gniazd możliwe jest przesyłanie wiadomości DHCPv6. Wiadomości te zawierają wiele pól, które przechowują liczby całkowite. Reprezentacja tych liczb na różnych rodzajach komputerów nie zawsze jest jednakowa. Pod tym względem procesory dzielą się na tzw. big-endian, które przechowują najpierw najbardziej znaczący bajt oraz little-endianm które najmniej znaczący bajt przechowują jako pierwsze. W celu umożliwienia komunikacji pomiędzy obydwoma rodzinami procesorów, wprowadzono tzw. porządek sieciowy, czyli konkretną kolejność obowiązująca w sieci. Z powodóch historycznych 2 jest ona zgodna z podejściem big-endian. Przykładem procesorów little-endian jest cała rodzina x86 (Intel,AMD,Transmeta,Cyrix). Przykładem procesorów big-endian są procesory firm Sun oraz Motorola. W celu ujednolicenia sposobu zapisu oraz zwiększenia przenośności wprowadzono następujące funkcje: uint32 t htonl(uint32 t hostlong) funkcja pobiera 32-bitową liczbe w formacie hosta i zwracą ją w formacie sieciowym. uint16 t htons(uint16 t hostshort) funkcja pobiera 16-bitową liczbę w formacie hosta i zwraca ją w formacie sieciowym. uint32 t ntohl(uint32 t netlong) funkcja pobiera 32-bitową liczbę w formacie sieciowym i zwraca ją w formacie hosta. uint16 t ntohs(uint16 t netshort) funkcja pobiera 16-bitową liczbę w formacie sieciowym i zwraca ją w formacie hosta. Warto zauważyć, że na komputerach wyposażonych w procesory big-endian, funkcje te po prostu zwracają przekazany im argument. Zaleca się jednak ich stosowanie w celu uniknięcia problemów przenośności. 5.3 Demony Zarówno serwer, jak i klient DHCPv6 będą działały jako tzw. demony. Wg [25] definicja demona brzmi: W informatyce demon jest szczególną klasą programu komputerowego; zwykle jest to proces działający w tle, rzadziej pod bezpośrednią kontrolą użytkownika. Demony często są uruchamiane przy starcie systemu i często oferują usługi w odpowiedzi na prośby przychodzące z sieci, aktywność sprzętową lub inne programy, wykonując różne zadania. W przypadku demonów linuxowych proces ich tworzenia wygląda następująco: 1. Utworzenie procesu demon jest uruchamiany tak, jak każdy inny proces systemowy. 2. Zamknięcie deskryptorów plików proces musi zamknąć wszystkie otwarte pliki. Powodów takiego postępowania jest kilka. Najważniejszy z nich to umożliwienie odmontowania systemu plików (odmontowanie systemu plików z otwartymi plikami nie jest możliwe). W szczególności ważne jest, aby zamknąć pliki stdin, stdin oraz stderr. W przypadku tych plików powód jest inny. Wyobraźmy sobie taką sytuację: użytkownik uruchamia terminal, uruchamia z niego demona, który rozpoczyna pracę w tle, a użytkownik zamyka terminal. Gdyby demon nie zamykał tych plików, w tym momencie posiadałby otwarte deskryptory skojarzone z nieistniejącym terminalem. Do zamykania deskryptorów plików służy standardowa funkcja close(int fd). 2 porządek sieciowy został wprowadzony na długo przed pojawieniem się na rynku procesorów firmy Intel

62 Interfejsy programistyczne (API) i wymagania systemowe 3. Zmiana katalogu roboczego zmiana katalogu roboczego na katalog główny. Dzięki tej operacji będzie możliwe odmontowanie systemu plików, z którego został uruchomiony demon. W tym celu wykorzystywana jest funckcja chdir(char * path). 4. Wyzerowanie maski trybu dostępu do plików zabezpiecza przed problemami związanymi z dostępem do nowotworzonych plików. Przykładowo użytkownik wydaje komendę umask 777, co oznacza, że nowotworzone pliki mają mieć wyzerowane wszystkie prawa dostępu (odczyt,zapis i uruchamianie zabronione dla właściciela pliku, grupy oraz pozostałych). Gdyby demon nie wyzerował maski pliku, mogłoby dość do sytuacji, w której nie miałby prawa odczytać pliku, który sam stworzył. Do tego celu wykorzystywana jest funkcja systemowa umask(int mask). 5. działanie jako proces w tle W wielu przypadkach demon jest uruchamiany z terminala. Gdyby nie wykonano procedury odłączenia, demon blokowałby terminal, z którego został uruchomiony. W celu przełączenia się na pracę w tle wywoływana jest funkcja systemowa fork(void), która tworzy proces potomny. W tym przypadku proces macierzysty jest kończony. 6. Odłączenie od grupy procesów Każdy proces systemowy dziedziczy identyfikator grupy procesów po procesie, który powołał go do życia. Współdzieląc identyfikator grupy ze swoim przodkiem, staje się podatny na sygnały kierowane do całej grupy. W ten sposób niepotrzebnie będzie otrzymywał syganły kierowane niekoniecznie do niego. Aby rozwiązać ten problem, należy utworzyć właśną grupę procesów. W tym celu demon wywołuje funkcję systemową setpgrp(void). 7. zablokowanie sygnałów W przypadku, kiedy demon (lub funkcja systemowa przez niego wywołana) spróbowałyby wyświetlić jakiekolwiek informacje na terminalu, do którego nie ma już przecież dostępu, demon otrzymałby sygnały SIGTTOU,SIGTTIN oraz SIGTSTP, co mogłoby spowodować jego natychmiastowe zakończenie. Właśnie dlatego należy ów sygnał zablokować. W tym celu wywoływana jest funkcja sterowania obsługą sygnałów signal( int signal,sig IGN). Po wykonaniu opisanych powyżej czynności, proces jest uważany za demona.

Rozdział 6 Architektura serwera Sedno serwera zostało podzielone na 4 specjalizowane części, zajmujące się odpowiednio: konfiguracją, interfejsami, bazą danych adresów oraz zarządzaniem transmisją. Za każde z tych zadań odpowiada odrębny fragment zwany managerem. Ze względu na podobieństwo konstrukcji serwera i klienta, managery działające po stronie serwera zostały oznaczone przedrostkami Srv. Są 4 managery: manager konfiguracji Server ConfigurationManager, zwany w skrócie SrvCfgMgr. manager interfejsów Server InterfaceManager, zwany w skrócie SrvIfaceMgr. manager adresów Server AddressManager, zwany w skrócie SrvAddrMgr. manager transmisji Server TransmissionManager, zwany w skrócie SrvTransMgr. 6.1 Manager interfejsów SrvIfaceMgr SrvIfaceMgr odpowiada za reprezentację interfejsów obecnych w systemie. Umożliwia zarządzanie fizycznymi adresami oraz otwartymi gniazdami. Zawiera listę, na której znajdują się wszystkie interfejsy dostępne w systemie. Na każdym można otworzyć gniazdo służące do nasłuchu i transmisji danych. Istnieje również możliwość przypisania, uaktualnienia oraz usunięcia adresu IPv6 z danego interfejsu (serwer nie korzysta z tej możliwości). Każdy interface przechowuje oddzielną listę obiektów reprezentujących gniazda. Takie rozwiązanie jest niezbędne do nasłuchu na wszystkich gniazdach naraz. SrvIfaceMgr nie korzysta z innych managerów. Jest wykorzystywany przez: SrvCfgMgr sprawdzenie, czy interfejsy określone w pliku konfiguracyjnym są dostępne w systemie. SrvTransMgr otwarcie gniazd przy starcie systemu. 6.2 Manager adresów SrvAddrMgr Drugim z kluczowych elementów całego systemu jest SrvAddrMgr. Jego zadanie polega na przechowywaniu informacji o klientach i przydzielonych im adresach. Dla każdego klienta występującego o adres, serwer przechowuje szczegółowe informacje: DUID, adres lokalny łącza, za pomocą którego można się skomunikować z danym klientem, a także informacje odnośnie wszystkich IA. Każdy obiekt reprezentujący klienta, posiada listę IA zawierającą stan obecnie przydzielonych adresów. Po każdej zmianie stanu (dodanie, uaktualnienie lub usunięcie adresu) zawartość bazy jest zachowywana w pliku na dysku. Zgodnie ze specyfikacją taki zachowanie jest konieczne w celu przywrócenia stanu po awarii serwera (zanik

64 Architektura serwera Rysunek 6.1: Architektura serwera

Architektura serwera 65 zasilania, awaria systemu). Przy starcie systemu baza zostaje wczytana z dysku. W celu ułatwienia analizy danych, plik dyskowy zawierający adresy ma format XML. SrvAddrMgr nie korzysta z innych managerów. Jest wykorzystywany przez: SrvCfgMgr sprawdzenie, czy nowowylosowany adres nie jest przypadkiem już używany. SrvTransMgr przechowywanie informacji o adresie. 6.3 Manager konfiguracji SrvCfgMgr Trzecim elementem systemu jest SrvCfgMgr. Jego zadaniem jest odczyt pliku konfiguracyjnego, utworzenie na jego podstawie obiektów reprezentujących odpowiednie wpisy oraz sprawdzenie ich poprawności (np. czy dany interface rzeczywiście występuje w systemie lub czy dany zakres adresów jest poprawny). Przechowuje informacje o dostępnych pulach adresowych. Na tej podstawie generuje nowe adresy. Odczytuje z pliku DUID,a w razie jego braku generuje go. Korzysta z: SrvAddrMgr sprawdzenie, czy nowowylosowany adres nie jest przypadkiem już używany. SrvIfaceMgr sprawdzenie, czy interfejsy określone w pliku konfiguracyjnym są dostępne w systemie. Jest wykorzystywany przez: SrvTransMgr odczyt konfiguracji, przydzielenie nowego adresu, odczyt DUID. 6.4 Manager transmisji SrvTransMgr Czwartym, najważniejszym elementem jest SrvTransMgr. Zarządza on transmisją i odbiorem wiadomości. Na podstawie odebranych wiadomości tworzy odpowiedzi. Wygenerowane i wysłane wiadomości są przetrzymywane w kolejce (w tzw. cache u) na wypadek konieczności retransmisji. Nie jest wykorzystywany przez inne managery. Korzysta z: SrvIfaceMgr otwarcie gniazd przy starcie systemu. SrvAddrMgr przechowywanie informacji o adresie. SrvCfgMgr odczyt konfiguracji, przydzielenie nowego adresu, odczyt DUID.

66 Architektura serwera

Rozdział 7 Architektura klienta Jednym z założeń projektowych jest uzyskanie maksymalnej przenośności kodu. Klient jest wykonany w technologii obiektowej. Podobnie jak serwer, składa się z 4 głównych elementów: manager interfejsów Client InterfaceManager, zwany w skrócie ClntIfaceMgr. manager adresów Client AddressManager, zwany w skrócie ClntAddrMgr. manager konfiguracji Client ConfigManager, zwany w skrócie ClntCfgMgr. manager transmisji Client TransmissionManager, zwany w skrócie ClntTransMgr. 7.1 Manager interfejsów ClntIfaceMgr Pełni on funkcję analogiczną do ClntIfaceMgr a z jedynie kosmetycznymi zmianami. SrvIfaceMgr odpowiada za reprezentację interfejsów obecnych w systemie. Umożliwia zarządzanie fizycznymi adresami oraz otwartymi gniazdami. Zawiera listę, na której znajdują się wszystkie interfejsy dostępne w systemie. Na każdym można otworzyć gniazdo służące do nasłuchu i transmisji danych. Istnieje również możliwość przypisania, uaktualnienia oraz usunięcia adresu IPv6 z danego interfejsu. Każdy interface przechowuje oddzielną listę obiektów reprezentujących gniazda. Takie rozwiązanie jest niezbędne do nasłuchu na wszystkich gniazdach naraz. ClntIfaceMgr nie korzysta z innych managerów. Jest wykorzystywany przez: ClntCfgMgr sprawdzenie, czy interfejsy określone w pliku konfiguracyjnym są dostępne w systemie. ClntTransMgr otwarcie gniazd przy starcie systemu, dodawanie, uaktualnianie i usuwanie adresów. 7.2 Manager adresów ClntAddrMgr Drugim z kluczowych elementów całego systemu jest SrvAddrMgr. Również on nie odbiega od ClntAddrMgr a. Jego zadanie polega na przechowywaniu informacji o otrzymanych IA oraz towarzyszących im adresach. Po każdej zmianie stanu (dodanie, uaktualnienie lub usunięcie adresu) zawartość bazy jest zachowywana w pliku na dysku. Zgodnie ze specyfikacją taki zachowanie jest konieczne w celu przywrócenia stanu po awarii serwera (zanik zasilania, awaria systemu). Przy starcie systemu baza zostaje wczytana z dysku. W celu ułatwienia analizy danych, plik dyskowy zawierający adresy ma format XML. SrvAddrMgr nie korzysta z innych managerów. Jest wykorzystywany przez: ClntCfgMgr sprawdzenie, czy nowowylosowany adres nie jest przypadkiem już używany. ClntTransMgr przydzielanie nowego, uaktualnienie oraz usunięcie istniejącego adresu.

68 Architektura klienta Rysunek 7.1: Architekrua klienta

Architektura klienta 69 7.3 Manager konfiguracji ClntCfgMgr Trzecim elementem systemu jest SrvCfgMgr. Jego zadaniem jest odczyt pliku konfiguracyjnego, utworzenie na jego podstawie obiektów reprezentujących odpowiednie wpisy oraz sprawdzenie ich poprawności (np. czy dany interface rzeczywiście występuje w systemie). Korzysta z: ClntIfaceMgr sprawdzenie, czy interfejsy określone w pliku konfiguracyjnym są dostępne w systemie. Jest wykorzystywany przez: ClntTransMgr odczyt konfiguracji, odczyt DUID. 7.4 Manager transmisji ClntTransMgr Czwartym, najważniejszym elementem jest ClntTransMgr. Zarządza on transmisją i odbiorem wiadomości. Dba o spełnienie wymagań określonych w pliku konfiguracyjnym. Znajduje serwery. Występuje o adresy, odświerza ja, a w niektórych przypadkach zwalnia. Wygenerowane i wysłane wiadomości są przetrzymywane w kolejce (w tzw. cache u) na wypadek konieczności retransmisji. Nie jest wykorzystywany przez inne managery. Korzysta z: SrvIfaceMgr otwarcie gniazd przy starcie systemu, dodanie, uaktualnienie, usunięcie adresu. SrvAddrMgr przechowywanie informacji o adresach. SrvCfgMgr odczyt konfiguracji, odczyt DUID.

70 Architektura klienta

Rozdział 8 Implementacja Implementacja została wykonana w języku C++. W celu zapewnienia maksymalnej przenośności pewne niskopoziomowe funkcje zostały zaimplementowane w czystym C. Dzięki takiemu podejściu uruchomienie serwera i klienta w nowym środowisku (np. systemy BSD) wymaga jedynie zaimplementowania niskopoziomowych funkcji związanych z dodawaniem i usuwaniem adresów, socketów oraz odczytem czasu. Implementacja składa się z dwóch części: serwera oraz klienta. Część klas jest wspólna, choć większość jest specyficzna dla każdej ze stron. W celu ułatwienia orientacji, klasy występujące tylko po stronie serwera mają przedrostek Srv w nazwie, natomiast dla klienta taką samą rolę pełni przedrostek Clnt. Zarówno serwer, jak i klient są tzw. demonami. client plik client.cpp Plik zawierający funkcję main() klienta. Tutaj są wykonywane wszystkie czynności związane ze startem procesu, ale jeszcze nie bezpośrednio związane z samym DHCP. Dla Linuxa jest to np. przełączenie procesu w tryb pracy demona, a dla systemów Windows rejestracja procesu jako usługi systemowej. server plik server.cpp Plik zawierający funkcję main() serwera. Tutaj są wykonywane wszystkie czynności związane ze startem procesu, ale jeszcze nie bezpośrednio związane z samym DHCP. Dla Linuxa jest to np. przełączenie procesu w tryb pracy demona, a dla systemów Windows rejestracja procesu jako usługi systemowej. 8.1 klasy AddressManagera Zadaniem całego AddressManagera (określanego w skrócie jako AddrMgr) jest zarządzanie adresami. Jest to specyficzna baza danych dedykowana obsłudze adresów. Architektura została przedstawiona na rysunku 8.1. 8.1.1 klasy wspólne TAddrMgr plik AddrMgr/AddrMgr.cpp Baza danych zarządzająca adresami. Przechowuje informacje o klientach. Umożliwia odczyt i zapis zawartości do pliku w formacie XML. Ważniejsze metody: gett1timeout() zwraca ilość sekund do upłynięcia najmniejszego licznika T1 gett2timeout() zwraca ilość sekund do upłynięcia najmniejszego licznika T2 gettpreftimeout() zwraca ilość sekund do upłynięcia najmniejszego licznika Prefered-lifetime

72 Implementacja Rysunek 8.1: Architektura AddrMgr a

Implementacja 73 getvalidtimeout() zwraca ilość sekund do upłynięcia najmniejszego licznika Valid-lifetime dbload() Ładuje bazę danych z zewnętrznego pliku XML. dbstore() Zapisuje bazę danych do zewnętrznego pliku XML. getaddrcount() zlicza ilość adresów dla danego klienta. TAddrClient plik AddrMgr/AddrClient.cpp Przechowuje stan pojedynczego klienta. Zawiera listę IA. Ważniejsze metody: gett1timeout() zwraca ilość sekund do upłynięcia najmniejszego licznika T1 gett2timeout() zwraca ilość sekund do upłynięcia najmniejszego licznika T2 gettpreftimeout() zwraca ilość sekund do upłynięcia najmniejszego licznika Prefered-lifetime getvalidtimeout() zwraca ilość sekund do upłynięcia najmniejszego licznika Valid-lifetime getaddrcount() zlicza ilość adresów dla danego klienta. TAddrIA plik AddrMgr/AddrIA.cpp Przechowuje stan pojedynczego IA. Zawiera listę adresów. Ważniejsze metody: gett1timeout() zwraca ilość sekund do upłynięcia najmniejszego licznika T1 gett2timeout() zwraca ilość sekund do upłynięcia najmniejszego licznika T2 gettpreftimeout() zwraca ilość sekund do upłynięcia najmniejszego licznika Prefered-lifetime getvalidtimeout() zwraca ilość sekund do upłynięcia najmniejszego licznika Valid-lifetime getaddrcount() zlicza ilość adresów dla danego IA. TAddrAddr plik AddrMgr/AddrAddr.cpp Przechowuje stan pojedynczego adresu. Ważniejsze metody: gettpreftimeout() zwraca ilość sekund do upłynięcia najmniejszego licznika Prefered-lifetime getvalidtimeout() zwraca ilość sekund do upłynięcia najmniejszego licznika Valid-lifetime 8.1.2 klasy klienta TClntAddrMgr plik ClntAddrMgr/ClntAddrMgr.cpp Wersja AddrMgr a specjalizująca się w zadaniach klieta. Umożliwia łatwiejszy dostęp do IA (ClntAddrMgr zawiera informacje tylko o jednym kliencie sobie samym). 8.1.3 klasy serwera TSrvAddrMgr plik SrvAddrMgr/SrvAddrMgr.cpp Wersja AddrMgr a specjalizująca się w zadaniach serwera. 8.2 klasy ConfigManagera Zadaniem ConfigManager a (określanego w skrócie jako CfgMgr) jest odczyt, generowanie i obsługa wszelkich informacji związanych z konfiguracją, np. odczyt i ewentualne generowanie DUID. Informacje po odczytaniu są następnie udostępniane reszcie systemu.

74 Implementacja 8.2.1 klasy wspólne TCfgMgr plik CfgMgr/CfgMgr.cpp Klasa pierwotna ConfigManager ów. Dziedziczą po niej zarówno ClntCfgMgr, jak i SrvCfgMgr. Zapewnia niektóre czynności wspólne dla serwera i klienta (np. generowanie DUID ). 8.2.2 klasy klienta TClntCfgMgr plik ClntConfMgr/ClntCfgMgr.cpp Klasa reprezentująca konfigurację klienta. Przechowuje informację o wymaganej konfiguracji interfejsów. TClntCfgIface plik ClntConfMgr/ClntCfgIface.cpp Klasa reprezentująca fragment pliku konfiguracyjnego poświęcony jednemu interfejsowi. Zawiera listę grup IA. TClntCfgGroup plik ClntConfMgr/ClntCfgGroup.cpp Klasa reprezentująca fragment pliku konfiguracyjnego poświęcony grupie IA. Przechowuje informacje wspólne dla pewnych IA połączonych w grupę. Zawiera listę IA. TClntCfgIA plik ClntConfMgr/ClntCfgIA.cpp Klasa reprezentująca fragment pliku konfiguracyjnego poświęcony jednemu IA. Zawiera listę adresów. TClntCfgAddr plik ClntConfMgr/ClntCfgAddr.cpp Klasa przechowująca informację o pojedynczym adresie występującym w pliku konfiguracyjnym. TClntLexer plik ClntParser/ClntLexer.cpp Klasa leksera. Odpowiada za konwersję pliku konfiguracyjnego klienta na strumień tokenów. Generowana za pomocą programu flex. TClntParser plik ClntParser/ClntParser.cpp Klasa parsera. Odpowiada za analizę strumienia tokenów, rozpoznawanie opcji i tworzenie na tej podstawie odpowiednich klas. TClntParsGlobalOpt plik ClntParser/ClntParsGlobalOpt.cpp Klasa reprezentuje rozpoznaną w pliku konfiguracyjnym klienta opcję globalną. TClntParsIfaceOpt plik ClntParser/ClntParsIfaceOpt.cpp Klasa reprezentuje rozpoznaną w pliku konfiguracyjnym klienta opcję specyficzną dla interfejsu. TClntParsIAOpt plik ClntParser/ClntParsIAOpt.cpp Klasa reprezentuje rozpoznaną w pliku konfiguracyjnym klienta opcję specyficzną dla pojedynczego IA. TClntParsAddrOpt plik ClntParser/ClntParsAddrOpt.cpp Klasa reprezentuje rozpoznaną w pliku konfiguracyjnym klienta opcję specyficzną dl pojedynczego adresu.

Implementacja 75 Rysunek 8.2: Struktura CfgMgr a po stronie klienta

76 Implementacja 8.2.3 klasy serwera Rysunek 8.3: Struktura CfgMgr a po stronie serwera TSrvCfgMgr plik SrvConfMgr/SrvCfgMgr.cpp Klasa reprezentująca plik konfiguracyjny serwera. Przechowuje informację o interfejsach oraz klasach adresów, które na danych interfejsach można przydzielać. TSrvCfgIface plik SrvConfMgr/SrvCfgIface.cpp Klasa reprezentująca fragment pliku konfiguracyjnego odpowiedzialny za jeden interfejs. Zawiera listę klas adresowych.

Implementacja 77 TSrvCfgAddrClass plik SrvConfMgr/SrvCfgAddrClass.cpp Klasa reprezentująca jeden zakres lub klasę adresów. TSrvLexer plik SrvParser/SrvLexer.cpp Klasa leksera. Odpowiada za konwersję pliku konfiguracyjnego serwera na strumień tokenów. Generowana za pomocą programu flex. TSrvParser plik SrvParser/SrvParser.cpp Klasa parsera. Odpowiada za analizę strumienia tokenów, rozpoznawanie opcji i tworzenie na tej podstawie odpowiednich klas. TSrvParsGlobalOpt plik SrvParser/SrvParsGlobalOpt.cpp Klasa reprezentuje rozpoznaną w pliku konfiguracyjnym klienta opcję globalną. TSrvParsIfaceOpt plik SrvParser/SrvParsIfaceOpt.cpp Klasa reprezentuje rozpoznaną w pliku konfiguracyjnym klienta opcję specyficzną dla interfejsu. TSrvParsClassOpt plik SrvParser/SrvParsClassOpt.cpp Klasa reprezentuje rozpoznaną w pliku konfiguracyjnym klienta opcję specyficzną dla klasy lub zakresu adresów. 8.3 klasy InterfaceManagera Zadaniem InterfaceManager a (określanego w skrócie jako IfaceMgr) jest reprezentacja oraz obsługa fizycznych interfejsów znajdujących się w systemie. Zajmuje się dodawaniem, sprawdzaniem, uaktualnianiem i zdejmowaniem adresów z interfejsów, a także obsługą gniazd tworzeniem, sprawdzaniem stanu, nasłuchiwaniem, transmisją, odczytem i zamykaniem gniazda. 8.3.1 klasy wspólne Ze względu na niskopoziomową specyfikę, większość obiektów jest wspólna dla serwera i klienta. TIfaceMgr plik IfaceMgr/IfaceMgr.cpp Klasa odpowiedzialna za zarządzanie interfejsami w systemie. Zawiera listę interfejsów. Umożliwia nasłuchiwanie na wszystkich otwartych gniazdach naraz. TIfaceIface plik IfaceMgr/Iface.cpp Klasa reprezentująca pojedynczy interfejs w systemie. Umożliwia sprawdzenie stanu interfejsu, dodanie i usunięcie adresu, a także otwarcie i zamknięcie gniazda. Zawiera listę gniazd. TSocketIPv6 plik IfaceMgr/SocketIPv6.cpp Klasa reprezentująca pojedyncze gniazdo. Umożliwia wysłanie i odbieranie danych. 8.3.2 klasy klienta TClntIfaceMgr plik ClntIfaceMgr/ClntIfaceMgr.cpp Kliencka wersja managera interface ów. Oprócz funckjonalności oferowanej przez IfaceMgr a, umożliwia dodatkowo odbiór danych i stworzenie na ich podstawie obiektu (typu pochodnego ClntMsg) reprezentującego odebraną wiadomość.

78 Implementacja Rysunek 8.4: Ogólna struktura IfaceMgr a wraz z diagramem dziedziczenia

Implementacja 79 Rysunek 8.5: Struktura TransMgr a po stronie klienta 8.3.3 klasy serwera TSrvIfaceMgr plik SrvIfaceMgr/SrvIfaceMgr.cpp Serwerowa wersja managera interface ów. Oprócz funckjonalności oferowanej przez IfaceMgr a, umożliwia dodatkowo odbiór danych i stworzenie na ich podstawie obiektu (typu pochodnego SrvMsg) reprezentującego odebraną wiadomość. 8.4 TransMgr Transmission Manager (określany w skrócie jako TransMgr) jest sercem całego systemu kontroluje co i kiedy jest wysyłane, a także reaguje na odebrane z sieci informacje. Zawiera listę prowadzonych obecnie transakcji. 8.4.1 klasy klienta TClntTransMgr plik ClntTransMgr/ClntTransMgr.cpp Transmission Manager sterujący zachowaniem klienta. W razie konieczności wysyła wiadomości SO- LICIT, REQUEST, RENEW, REBIND, DECLINE, CONFIRM i RELEASE. Dba o retransmisję wiadomości. Jego struktura została przedstawiona na rysunku 8.5. 8.4.2 klasy serwera TSrvTransMgr plik SrvTransMgr/SrvTransMgr.cpp Steruje zachowaniem serwera. Odbiera wiadomości ze skonfigurowanych interfejsów, tworzy i transmituje odpowiedzi. Odpowiedzi są buforowane na wypadek retransmisji. Jego struktura została przedstawiona na rysunku 8.6.

80 Implementacja Rysunek 8.6: Struktura TransMgr a po stronie serwera 8.5 Messages Rysunek 8.7: Struktura wiadomości wraz z hierarchią dziedziczenia

Implementacja 81 Struktura klasy TMsg zostałą przedstawiona na rysunku 8.7. TMsg plik Messages/Msg.cpp Podstawowa klasa, po której dziedziczą wszystkie pozostałe wiadomości. Oferuje pewne uniwersalne metody, np. odpowiedzialne za wysyłanie wiadomości. 8.5.1 klasy klienta TClntMsg plik ClntMessages/ClntMsg.cpp Ogólna klasa wiadomości po stronie klienta. Zawiera listę opcji wraz z metodami ją obsługującymi. Przechowuje i uaktualnia liczniki związane z retransmisjami (MRC, MRD, MRT, IRT, RT, RC). Zawiera szereg metod czysto wirtualnych, implementowanych w poszczególnych klasach potomnych. Ważniejsze metody: check() Metoda wirtualna. Sprawdza poprawność otrzymanej wiadomości. send() Wysyła wiadomość. doduties() Metoda wirtualna. W razie potrzeby retransmituje wiadomość. answer() Metoda wirtualna. Reaguje na odpowiedź na wiadomość. TClntMsgSolicit plik ClntMessages/ClntMsgSolicit.cpp Klasa reprezentująca wiadomość SOLICIT po stronie klienta. Przechowuje otrzymane odpowiedzi ADVERTISE. Ważniejsze metody: doduties() po upłynięciu timeout u sprawdza, czy można już zakończyć czas zbierania wiadomości ADVERTISE od serwerów, czy też może konieczna jest retransmisja wiadomości. sortanswers() sortuje otrzymane odpowiedzi serwerów w kolejności preferencji (z odrzucaniem niepożądanych odpowiedzi) TClntMsgAdvertise plik ClntMessages/ClntMsgAdvertise.cpp Klasa reprezentująca po stronie klienta wiadomość ADVERTISE otrzymaną od serwera. Zawiera opcje oraz propozycje adresów, które klient chciałby otrzymać od serwera. TClntMsgRequest plik ClntMessages/ClntMsgRequest.cpp Klasa reprezentująca wiadomość REQUEST po stronie klienta. Zawiera opcje oraz propozycje adresów, o których przydzielenie klient zwraca się do konkretnego serwera. TClntMsgRenew plik ClntMessages/ClntMsgRenew.cpp Klasa reprezentująca wiadomość RENEW po stronie klienta. Ważniejsze metody: updateia() uaktualnia ustawienia (czasy prefered i valid dla adresów) dla danego IA. releaseia() zwalnia adresy w danym IA, jeżeli nie spełniają one założeń określonych w pliku konfiguracyjnym (np. wymagane są minimum 3 adresy) TClntMsgRebind plik ClntMessages/ClntMsgRebind.cpp Klasa reprezentująca wiadomość REBIND po stronie klienta. Ważniejsze metody: updateia() uaktualnia ustawienia (czasy prefered i valid dla adresów) dla danego IA.

82 Implementacja Rysunek 8.8: Dziedziczenie wiadomości po stronie klienta

Implementacja 83 releaseia() zwalnia adresy w danym IA, jeżeli nie spełniają one założeń określonych w pliku konfiguracyjnym (np. wymagane są minimum 3 adresy) TClntMsgRelease plik ClntMessages/ClntMsgRelease.cpp Klasa reprezentująca wiadomość RELEASE po stronie klienta. Zawiera opcje odpowiadające zwalnianym właśnie adresom. Usuwa adresy z AddrMgr a i zdejmuje je z interfejsów. TClntMsgReply plik ClntMessages/ClntMsgReply.cpp Klasa reprezentująca odpowiedź serwera (wiadomość REPLY ) po stronie klienta. Sprawdza poprawność oraz zgodność ze specyfikacją otrzymanych opcji. TClntMsgDecline plik ClntMessages/ClntMsgDecline.cpp Klasa reprezentująca wiadomość DECLINE po stronie klienta. Zawiera opcje reprezentujące zwalniane adresy. Usuwa adresy z AddrMgr a oraz zdejmuje je z interfejsów. TClntMsgInfRequest plik ClntMessages/ClntMsgInfRequest.cpp Klasa reprezentująca wiadomość INFORMATIION-REQUEST. Zawiera opcje, które klient chciałby otrzymać od serwera. TClntMsgConfirm plik ClntMessages/ClntMsgConfirm.cpp Klasa reprezentująca wiadomość CONFIRM po stronie klienta. Zawiera adresy, których potwierdzenie chciałby otrzymać klient. 8.5.2 klasy serwera Diagram klas dla wiadomości po stronie serwera przedstawiono na rysunku 8.9. TSrvMsg plik SrvMessages/SrvMsg.cpp Ogólna klasa reprezentująca wiadomość po stronie serwera. Ważniejsze opcje: appendrequestedoptions() dołącza opcje, które zostały określone w pliku konfiguracyjnym. send() wysyła wiadomość. doduties() Metoda wirtualna. Sprawdza, czy istnieje jeszcze możliwość retransmisji wiadomości. Jeżeli nie, to ustawia transakcję jako zakończoną. check() Metoda wirtualna. Sprawdza, czy dana wiadomość jest poprawna (np. zawiera niezbędne opcje). gettimeout() zwraca czas, za jaki będzie można ostatecznie usunąć wiadomość z cache u. TSrvMsgAdvertise plik SrvMessages/SrvMsgAdvertise.cpp Klasa reprezentująca wiadomość ADVERTISE po stronie serwera. Na podstawie obiektu tej klasy jest tworzony obiekt reprezentujący wiadomość REPLY. TSrvMsgRequest plik SrvMessages/SrvMsgRequest.cpp Klasa reprezentująca wiadomość REQUEST po stronie serwera. Na podstawie tej klasy jest tworzony obiekt reprezentujący wiadomość REPLY. TSrvMsgConfirm plik SrvMessages/SrvMsgConfirm.cpp Klasa reprezentująca wiadomość CONFIRM po stronie serwera. Na podstawie tej klasy jest tworzony obiekt reprezentujący wiadomość REPLY. TSrvMsgDecline plik SrvMessages/SrvMsgDecline.cpp Klasa reprezentująca wiadomość DECLINE po stronie serwera. Na podstawie tej klasy jest tworzony obiekt reprezentujący wiadomość REPLY.

84 Implementacja Rysunek 8.9: Dziedziczenie wiadomości po stronie serwera

Implementacja 85 TSrvMsgInfRequest plik SrvMessages/SrvMsgInfRequest.cpp Klasa reprezentująca wiadomość INFORMATION-REQUEST po stronie serwera. Na podstawie tej klasy jest tworzony obiekt reprezentujący wiadomość REPLY. TSrvMsgRebind plik SrvMessages/SrvMsgRebind.cpp Klasa reprezentująca wiadomość REBIND po stronie serwera. Na podstawie tej klasy jest tworzony obiekt reprezentujący wiadomość REPLY. TSrvMsgRelease plik SrvMessages/SrvMsgRelease.cpp Klasa reprezentująca wiadomość RELEASE po stronie serwera. Na podstawie tej klasy jest tworzony obiekt reprezentujący wiadomość REPLY. TSrvMsgRenew plik SrvMessages/SrvMsgRenew.cpp Klasa reprezentująca wiadomość RENEW po stronie serwera. Na podstawie tej klasy jest tworzony obiekt reprezentujący wiadomość REPLY. TSrvMsgReply plik SrvMessages/SrvMsgReply.cpp Klasa reprezentująca wiadomość REPLY po stronie serwera. Wiadomość zawiera odpowiedź na zapytania klienta. Przydziela adresy. Zwalnia adresy. Odświerza adresy. Zaznacza adresy jako zdublowane (wiadomość DECLINE ). TSrvMsgSolicit plik SrvMessages/SrvMsgSolicit.cpp Klasa reprezentująca wiadomość SOLICIT po stronie serwera. 8.6 Opcje Diagram klas dla opcji został przedstawiony na rysunku 8.10 Ze względu na większe podobieństwo opcji po stronie serwera i klienta zależności pomiędzy klasami zostały skonstruowane nieco inaczej niż w przypadku wiadomości (najpierw podział na stronę serwera i klienta, a dopiero potem na rodzaje wiadomości): najpierw wprowadzono rozróżnienie na poszczególne opcje,a dopiero potem na stronę serwera i klienta. TOpt plik Options/Opt.cpp Ogólna klasa reprezentująca opcje. Zawiera szereg metod wspólnych dla wszystkich opcji. Zawiera listę podopcji. Ważniejsze z nich to: getsize() Metoda wirtualna. Zwraca rozmiar opcji. storeself() Metoda wirtualna. Zapisuje się w podanym buforze. doduties() Metoda wirtualna. Realizuje zawartość opcji. isvalid() Metoda wirtualna. Sprawdza, czy zawartość opcji jest poprawna. getopttype() Zwraca typ opcji. 8.6.1 Opcja Client ID Diagram klas został przedstawiony na rysunku 8.11. TOptClientIdentifier plik Options/OptClientIdentifier.cpp Klasa reprezentująca opcję CLIENT-IDENTIFER. Zawiera DUID klienta. TClntOptClientIdentifier plik ClntOptions/ClntOptClientIdentifier.cpp Klasa potomna klasy OptClientIdentifier, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory.

86 Implementacja Rysunek 8.10: Diagram klas dla opcji Rysunek 8.11: Diagram klas dla opcji Client ID

Implementacja 87 Rysunek 8.12: Diagram klas dla opcji Server ID TSrvOptClientIdentifier plik SrvOptions/SrvOptClientIdentifier.cpp Klasa potomna klasy OptClientIdentifier, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. 8.6.2 Opcja Server ID Diagram klas został przedstawiony na rysunku 8.12. TOptServerIdentifier plik Options/OptServerIdentifier.cpp Klasa reprezentująca opcję SERVER-IDENTIFIER. Zawiera DUID klienta. TClntOptServerIdentifier plik ClntOptions/ClntOptServerIdentifier.cpp Klasa potomna klasy OptServerIdentifier, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. TSrvOptServerIdentifier plik SrvOptions/SrvOptServerIdentifier.cpp Klasa potomna klasy OptServerIdentifier, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. 8.6.3 Opcja IA NA Diagram klas dla opcji IA NA został przedstawiony na rysunku 8.13. TOptIA NA plik Options/OptIA NA.cpp Klasa reprezentująca opcję IA NA. Opisuje pojedyncze IA. Zawiera listę podopcji. TClntOptIA NA plik ClntOptions/ClntOptIA NA.cpp Klasa potomna klasy OptIA NA, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. Sprawdza otrzymaną listę adresów. W zależności od typu wiadomości, na który odpowiedzią jest ta opcja, dodaje, uaktualnia lub zwalnia adresy.

88 Implementacja Rysunek 8.13: Diagram klas dla opcji IA NA

Implementacja 89 TSrvOptIA NA plik SrvOptions/SrvOptIA NA.cpp Klasa potomna klasy OptIA NA, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. Sprawdza otrzymaną listę adresów i synchronizuje ją z adresami w bazie. Dodaje adresy do bazy. Usuwa adresy z bazy. Uaktualnia adresy w bazie. 8.6.4 Opcja IAADDR Rysunek 8.14: Diagram klas dla opcji IAADDR TOptIAAddress plik Options/OptIAAddress.cpp Klasa reprezentująca opcję IAADDRESS. Przechowuje adres IPv6. TClntOptIAAddress plik ClntOptions/ClntOptIAAddress.cpp Klasa potomna klasy OptIAAddress, dedykowana dla klienta. Przechowuje adresy. Zawiera specyficzne dla klienta konstruktory. TSrvOptIAAddress plik SrvOptions/SrvOptIAAddress.cpp Klasa potomna klasy OptIAAddress, dedykowana dla serwera. Przechowuje adres. Zawiera specyficzne dla serwera konstruktory.

90 Implementacja 8.6.5 Opcja ORO Rysunek 8.15: Diagram klas dla opcji ORO TOptOptionRequest plik Options/OptOptionRequest.cpp Klasa reprezentująca opcję OPTION-REQUEST. Zawiera listę opcji, którymi zainteresowany jest klient. TClntOptOptionRequest plik ClntOptions/ClntOptOptionRequest.cpp Klasa potomna klasy OptOptionRequest, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. TSrvOptOptionRequest plik SrvOptions/SrvOptOptionRequest.cpp Klasa potomna klasy OptOptionRequest, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. 8.6.6 Opcja Preference Diagram klas dla opcji PREFERENCE został przedstawiony na rysunku 8.16. TOptPreference plik Options/OptPreference.cpp Klasa reprezentująca opcję PREFERENCE. Zawiera preferencje serwera.

Implementacja 91 Rysunek 8.16: Diagram klas dla opcji Preference TClntOptPreference plik ClntOptions/ClntOptPreference.cpp Klasa potomna klasy OptPreference, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. TSrvOptPreference plik SrvOptions/SrvOptPreference.cpp Klasa potomna klasy OptPreference, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. 8.6.7 Opcja Elapsed Time Diagram klas dla opcji ELAPSED został przedstawiony na rysunku 8.17. TOptElapsed plik Options/OptElapsed.cpp Klasa reprezentująca opcję ELAPSED. Zawiera informację o tym, jak długo trwa już transakcja. TClntOptElapsed plik ClntOptions/ClntOptElapsed.cpp Klasa potomna klasy OptElapsed, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. TSrvOptElapsed plik SrvOptions/SrvOptElapsed.cpp Klasa potomna klasy OptElapsed, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. 8.6.8 Opcja Server Unicast Diagram klas dla opcji SERVER-UNICAST został przedstawiony na rysunku 8.18. TOptServerUnicast plik Options/OptServerUnicast.cpp Klasa reprezentująca opcję SERVER-UNICAST. Zacznacza, czy możliwa jest komunikacja z serwerem za pomocą adresów unicastowych.

92 Implementacja Rysunek 8.17: Diagram klas dla opcji Elapsed Time Rysunek 8.18: Diagram klas dla opcji Server Unicast

Implementacja 93 Rysunek 8.19: Diagram klas dla opcji Status Code TClntOptServerUnicast plik ClntOptions/ClntOptServerUnicast.cpp Klasa potomna klasy OptServerUnicast, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. TSrvOptServerUnicast plik SrvOptions/SrvOptServerUnicast.cpp Klasa potomna klasy OptServerUnicast, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. 8.6.9 Opcja Status Code Diagram klas dla opcji STATUS-CODE został przedstawiony na rysunku 8.19. TOptStatusCode plik Options/OptStatusCode.cpp Klasa reprezentująca opcję STATUSCODE. Zawiera status wykonanej operacji wraz ze słownym opisem. TClntOptStatusCode plik ClntOptions/ClntOptStatusCode.cpp Klasa potomna klasy OptStatusCode, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. TSrvOptStatusCode plik SrvOptions/SrvOptStatusCode.cpp Klasa potomna klasy OptStatusCode, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. Zawiera rezultat działania serwera w postaci kodu błędu oraz pola tekstowego. 8.6.10 Opcja Rapid Commit Diagram klas dla opcji RAPID-COMMIT został przedstawiony na rysunku 8.20.

94 Implementacja Rysunek 8.20: Diagram klas dla opcji Rapid Commit TOptRapidCommit plik Options/OptRapidCommit.cpp Klasa reprezentująca opcję RAPID-COMMIT. Jej obecność oznacza, że dana strona akceptuje przyspieszoną wymianę komunikatów ( SOLICIT REPLY ). TClntOptRapidCommit plik ClntOptions/ClntOptRapidCommit.cpp Klasa potomna klasy OptRapidCommit, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. TSrvOptRapidCommit plik SrvOptions/SrvOptRapidCommit.cpp Klasa potomna klasy OptRapidCommit, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. 8.6.11 Opcja User Class Diagram klas dla opcji USER-CLASS został przedstawiony na rysunku 8.21. TOptUserClass plik Options/OptUserClass.cpp Klasa reprezentująca opcję USERCLASS. Zawiera opcje użytkownika. W tej implementacji ta opcja jest rozpoznawana, ale nie jest używana. TClntOptUserClass plik ClntOptions/ClntOptUserClass.cpp Klasa potomna klasy OptUserClass, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. Opcja jest rozpoznawana, ale nie jest używana. TSrvOptUserClass plik SrvOptions/SrvOptUserClass.cpp Klasa potomna klasy OptUserClass, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. Opcja jest rozpoznawana, ale nie jest używana. 8.6.12 Opcja Vendor Class Diagram klas dla opcji VENDOR-CLASS został przedstawiony na rysunku 8.22. TOptVendorClass plik Options/OptVendorClass.cpp Klasa reprezentująca opcję VENDORCLASS. Zawiera opcje producenta. W tej implementacji ta opcja jest rozpoznawana, ale nie jest używana.

Implementacja 95 Rysunek 8.21: Diagram klas dla opcji User Class Rysunek 8.22: Diagram klas dla opcji Vendor Class

96 Implementacja TClntOptVendorClass plik ClntOptions/ClntOptVendorClass.cpp Klasa potomna klasy OptVendorClass, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. Opcja jest rozpoznawana, ale nie jest używana. TSrvOptVendorClass plik SrvOptions/SrvOptVendorClass.cpp Klasa potomna klasy OptVendorClass, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. Opcja jest rozpoznawana, ale nie jest używana. 8.6.13 Opcja Vendor Info Rysunek 8.23: Diagram klas dla opcji Vendor Info TOptVendorSpecInfo plik Options/OptVendorSpecInfo.cpp Klasa reprezentująca opcję VENDORSPECINFO. Zawiera informacje producenta. W tej implementacji ta opcja jest rozpoznawana, ale nie jest używana. TClntOptVendorSpecInfo plik ClntOptions/ClntOptVendorSpecInfo.cpp Klasa potomna klasy OptVendorSpecInfo, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. Opcja jest rozpoznawana, ale nie jest używana. TSrvOptVendorSpecInfo plik SrvOptions/SrvOptVendorSpecInfo.cpp Klasa potomna klasy OptVendorSpecInfo, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. Opcja jest rozpoznawana, ale nie jest używana. 8.6.14 Opcja Interface ID TOptInterfaceID plik Options/OptInterfaceID.cpp Klasa reprezentująca opcję INTERFACE-ID. Zawiera identyfikator interfejsu, potrzebny przy komunikacji z relay-przekaźnikami. W tej implementacji nie jest używana. TClntOptInterfaceID plik ClntOptions/ClntOptInterfaceID.cpp Klasa potomna klasy OptInterfaceID, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory.

Implementacja 97 TSrvOptInterfaceID plik SrvOptions/SrvOptInterfaceID.cpp Klasa potomna klasy OptInterfaceID, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. W tej implementacji nie jest używana. 8.6.15 Opcja DNS Resolver Rysunek 8.24: Diagram klas dla opcji DNS Resolver TOptDNSServers plik Options/OptDNSServers.cpp Klasa reprezentująca opcję DNS-SERVERS, sprecyzowaną w drafcie draft-ietf-dhc-dhcpv6-optdnsconfig-03.txt. Zawiera listę serwerów DNS, z którymi może komunikować się klient. TClntOptDNSServers plik ClntOptions/ClntOptDNSServers.cpp Klasa potomna klasy OptDNSServers, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. Ustawia otrzymane wartości w systemie. TSrvOptDNSServers plik SrvOptions/SrvOptDNSServers.cpp Klasa potomna klasy OptDNSServers, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory.

98 Implementacja 8.6.16 Opcja Domain Search List Rysunek 8.25: Diagram klas dla opcji Domain Search List TOptDomainName plik Options/OptDomainName.cpp Klasa reprezentująca opcję DOMAIN-NAME, sprecyzowaną w drafcie draft-ietf-dhc-dhcpv6-optdnsconfig-03.txt. Zawiera listę domen, którą powinien przeszukiwać klient w procesie rozwiązywania nazwy. TClntOptDomainName plik ClntOptions/ClntOptDomainName.cpp Klasa potomna klasy OptServerUnicast, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. Ustawia otrzymane wartości w systemie. TSrvOptDomainName plik SrvOptions/SrvOptDomainName.cpp Klasa potomna klasy OptNTPServer, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. 8.6.17 Opcja Timezone Diagram klas dla opcji TIMEZONE został przedstawiony na rysunku 8.26. TOptTimeZone plik Options/OptTimeZone.cpp Klasa reprezentująca opcję TIMEZONE, sprecyzowaną w drafcie draft-ietf-dhc-dhcpv6-opt-timeconfig- 02.txt. Zawiera informację o strefie czasowej, w jakiej znajduje się sieć. TClntOptTimeZone plik ClntOptions/ClntOptTimeZone.cpp Klasa potomna klasy OptServerUnicast, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. Ustawia otrzymane wartości w systemie. TSrvOptTimeZone plik SrvOptions/SrvOptTimeZone.cpp Klasa potomna klasy OptServerUnicast, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory.

Implementacja 99 Rysunek 8.26: Diagram klas dla opcji Timezone 8.6.18 Opcja NTP Servers Rysunek 8.27: Diagram klas dla opcji NTP Servers

100 Implementacja TOptNTPServers plik Options/OptNTPServers.cpp Klasa reprezentująca opcję NTP-SERVERS, sprecyzowaną w drafcie draft-ietf-dhc-dhcpv6-opttimeconfig-02.txt. Zawiera listę serwerów czasu protokołu NTP. TClntOptNTPServers plik ClntOptions/ClntOptNTPServers.cpp Klasa potomna klasy OptNTPServer, dedykowana dla klienta. Zawiera specyficzne dla klienta konstruktory. Ustawia otrzymane wartości w systemie. TSrvOptNTPServers plik SrvOptions/SrvOptNTPServers.cpp Klasa potomna klasy OptNTPServer, dedykowana dla serwera. Zawiera specyficzne dla serwera konstruktory. 8.7 Pozostałe TDHCPClient plik DHCPClient.cpp Klasa reprezentująca klienta DHCP. Najbardziej ogólna klasa, która jest jeszcze w pełni przenośna. TDHCPServer plik DHCPServer.cpp Klasa podstawowa reprezentująca serwer DHCP. Najbardziej ogólna klasa, która jest jeszcze w pełni przenośna. TDHCPConst plik DHCPConst.cpp Ten plik w zasadzie nie zawiera klasy, a jedynie zestaw funkcji pomocnicznych, zwracających np. czy dana opcja może wystąpić w danej wiadomości. TDUID plik DUID.cpp Klasa przechowująca DUID. TIPv6Addr plik IPv6Addr.cpp Klasa przechowująca adres IPv6. Logger plik Logger.cpp Zestaw funkcji odpowiedzialny za logowanie informacji. StationID plik StationID.cpp Klasa identyfikująca klienta za pomocą DUID lub adresu IPv6. Jest wykorzystywana w procesie odczytu i wykorzystania pliku konfiguracyjnego. StationRange plik StationRange.cpp Klasa określająca zakres adresów lub zakres wykorzystania pliku konfiguracyjnego. DUID. Jest wykorzystywana w procesie odczytu i TimeZone plik TimeZone.cpp Klasa określająca strefę czasową. Jest wykorzystywana w opcji OptTimeZone i pochodnych.

Rozdział 9 Opis plików konfiguracyjnych Rozdział ten opisuje sposób konfiguracji klienta i serwera DHCPv6. W następnym punkcie został opisany zestaw tokenów używany zarówno w pliku konfiguracyjnym klienta, jak i serwera, natomiast w dwóch następnych punktach opisana została struktura plików konfiguracyjnych. Opis ten w zamierzeniu ma w sposób jak najprostszy przedstawić zasady budowy plików konfiguracyjnych i sposób konfiguracji klienta i serwera DHCPv6. 9.1 Tokeny W plikach konfiguracyjnych klienta i serwera używane są następujące tokeny: Adres IPv6 adres IPv6 podawany w formacie opisanym w punkcie 9.2.6 np: 20:2::3. 32 bitowa liczba dziesiętna(bez znaku) - ciąg cyfr dziesiętnych np. 234 32 bitowa liczba szesnastkowa(bez znaku) - ciąg cyfr szesnatkowych zakończony literą h np. 23afh Łańcuch znaków - ciąg znaków ujęty w apostrofy np. Lokalny Identyfiaktor DUID - ciąg cyfr szesnastkowych ujęty w cudzysłów np. 01203543 Oprócz wymienionych powyżej tokenów zdefiniowane są następujące identyfikatory: w pliku konfiguracyjnym klienta: iface, no-config, address, ia, no-ia, log-level, work-dir, append, prepend, require, request, send, default, supersede, prefered-lifetime, valid-lifetime, t1, t2, dns-servers, domain, ntp-servers, time-zone, reject-servers, prefered-servers, rapidcommit w pliku konfiguracyjnym serwera: iface, no-config, class, log-level, work-dir, dns-servers, domain, ntpserver, time-zone, accept-only, reject-only, t1, t2, prefered lifetime, valid-lifetime, unicast, preference, pool, rapidcommit, max-lease, client-max-lease Ponadto można używać komentarzy: jednoliniowych zarówno rozpoczynających się od znaków // (jak w C++) lub rozpoczynających od znaku się od znaku # (skrypty) wieloliniowych rozpoczynających się od znaków /* i zakończonych znakami */ Parser plików konfiguracyjnych nie rozróżnia wielkości znaków, zatem identyfikatory Iface,iface, IFACE są dla parsera identyczne. Wielkość znaków ma oczywiście znaczenie w podawanych łańcuchach znaków np. przy określaniu katalogu roboczego, czy nazwy interfejsu.

102 Opis plików konfiguracyjnych 9.2 Struktura pliku konfiguracyjnego klienta DHCPv6 9.2.1 Zakresy ważności. W pliku konfiguracyjnym klienta DHCPv6 zostały wyróżnione cztery rodzaje zakresów: 1. globalny 2. itnerfejsu 3. IA 4. adresu Zakres globalny jest najszerszy i rozciąga się od początku do końca pliku konfiguracyjnego. W zakresie globalnym można zadeklarować interfejs, a wraz z nim jego zakres. Analogicznie w zakresie interfejsu można dokonać deklaracji IA, a w zakresie IA zadeklarować adres i zakres adresu. Zakres adresu jest najwęższym zakresem i nie może zawierać innych zakresów. Z każdym zakresem związane są specyficzne dla niego opcje. Opcje, ich typy oraz zakresy, z którymi są powiązane zostały przedstawione w tabeli w punkcie 9.2.7. W każdym zakresie można zadeklarować opcje związane z tym zakresem lub opcje związane z zakresami węższymi. Pozwala to na deklaracje domyślnych wartodci opcji. Przykładowo opcja T1 związana z IA może pojawić się również w zakresie interfejsu, czy globalnym, dzięki czemu nie trzeba powtarzać deklaracji tej opcji przy każdej deklaracji IA. Deklaracja danej opcji obowiązuje od miejsca jej deklaracji do momentu miejsca ponownej deklaracji lub do końca zakresu, w którym została zadeklarowana. Należy zauważyć, że jeżeli w szerszym zakresie została zadeklarowana pewna opcja, w zakresie węższym można dokonać ponownej deklaracji, przy czym taka ponowna deklaracja będzie obowiązywała od miejsca jej wystąpienia do końca zakresu wewnetrznego. Taki sposób deklaracji pozwala na uszczegółowianie opcji. Przykładowo niech w zakresie globalnym przed deklracją wszystkich interfejsów zostanie zadeklarowana opcja T1 o wartodci 10, gdyż z taką wartodcią opcji T1 ma być przydzielana wieksza część IA. Jednak dla jednego z interfejsów konieczne jest przydzielenie IA o wartości 20. Wystarczy wówczas na początku deklaracji zakresu tego interfejsu zadeklarować ponownie opcję T1 wartości 20. Jeżeli opcja związana z danym zakresem zostanie w nim zadeklarowana kilkakrotnie, obowiązywać będzie ostatnia deklaracja. 9.2.2 Deklaracje globalne. W zakresie globalnym mogą pojawić się deklaracje wszystkich opcji oraz deklaracje interfejsu. Opis deklaracji interfejsu znajduje się w następnym punkcie natomiast opis sposobu deklaracji opcji dla poszczególnych zakresów znajduje się w punkcie 9.2.7. Plik konfiguracyjny ma następującą postać: [deklaracja interfejsu deklaracja opcji globalnych deklaracja opcji interfejsu deklaracja opcji IA deklaracja opcji adresu ]... 9.2.3 Deklaracja interfejsu. Interfejs można zadeklarować na dwa różne sposoby: iface interfejsnazwa interfejsnumer no-config lub

Opis plików konfiguracyjnych 103 iface interfejsnazwa interfejsnumer { [deklaracja IA deklaracja opcji interfejsu deklaracja opcji IA deklaracja opcji adresu ]... } gdzie interfejsnazwa oznacza nazwę interfejsu, a interfejsnumer to numer interfejsu. Opis deklaracji IA znajduje się w kolejnym punkcie natomiast opcji interfejsu, IA oraz adresu w punkcie 9.2.7. Pierwszy sposób deklaracji określa, że interfejs o nazwie interfejsnazwa lub numerze interfejsnumer nie ma być konfigurowany przez klienta DHCPv6. Domyślnie, jeżeli deklaracja danego interfejsu nie zostanie podana w pliku konfiguracyjnym każdy interfejs konfigurowany jest z jednym IA zawierającym jeden adres. Drugi sposób pozwala na szczegółowe określenie sposobu konfiguracji interfejsu o nazwie interfejsnazwa lub numerze interfejsnumer. Sposób ten pozwala na określenie ile ma zostać przydzielonych IA i ile każde z nich ma posiadać adresów, a także pozwala na określenie opcji dla deklarowanych IA i adresów. Przy braku deklaracji jakiegokolwiek IA w zakresie interfejsu, domyślnie przyjęta będzie konfiguracja z jednym IA zawierającym jeden adres. Jeżeli natomiast klient ma się ubiegać jedynie o parametry konfiguracyjne (np. gdy adresy przydzielane są przy użyciu SA) należy jawnie zadeklarować opcję no-ia (patrz opis opcji w punkcie 9.2.7). 9.2.4 Deklaracja IA. IA jest deklarowane w następujący sposób: ia [LICZBA] [{ [deklaracja adresu deklaracja opcji IA deklaracja opcji adresu ]... }] gdzie LICZBA to liczba określająca ile IA o podanych wewnątrz tego zakresu opcjach i deklaracjach adresu ma zostać przydzielonych od serwera DHCPv6. Jeżeli LICZBA jest różna od 1 w zakresie adresu, nie może pojawić się deklaracja adresu IPv6(patrz następny punkt). Opis deklaracji adresu znajduje się w kolejnym punkcie natomiast opcji związanych z IA oraz opcji związanych z zakresem adresu w punkcie 9.2.7. Taka deklaracja pozwala na zadeklarowanie dla danego interfejsu LICZBA razy IA, o podanych wewnątrz zakresu IA parametrach. Jeżeli zakres IA nie zawiera żadnych deklaracji adresu, wówczas domyślnie przyjmuje się, że IA powinno zawierać jeden adres. 9.2.5 Deklaracja Adresu. Adres deklarowany jest w następujący sposób: address [LICZBA] [{ [deklaracja opcji adresu deklaracja adresu IPv6 ]... }]

104 Opis plików konfiguracyjnych gdzie LICZBA oznacza ile adresów o podanych wewnątrz zakresu parametrach ma zostać przydzielonych. Jeżeli LICZBA jest różna od 1 nie można określać wewnątrz zakresu adresu deklaracji adresu IPv6. Opis opcji zakresu adresu znajduje się w punkcie 9.2.7. Deklaracja adresu IPv6 to adres podany w postaci opisanej w punkcie 9.2.6. 9.2.6 Notacja adresów Adresy mogą być wprowadzane w dowolnej postaci: pełnej (np. 0020:0000:0000:0000:0000:0567:0000:0001), skróconej (20:0:0:0:0:567:0:1) lub najwygodniejszej skompresowanej (20::567:0:1). 9.2.7 Opcje. Sposób deklaracji Deklaracja opcji składa się z nazwy opcji, wartości opcji i słów kluczowych pozwalających na określenie dodatkowej informacji związanej ze sposobem ubiegania się o opcje. Wyróżnione zostały następujące słowa kluczowe: send podana wartość opcji stanowi jedynie wskazówkę dla serwera DHCPv6 default wartość opcji stanowi wskazówkę dla serwera DHCP, ale także przyjmie taką wartość, jeżeli serwer nie zwróci tej opcji supersede nadpisuje wartość opcji otrzymaną od serwera przez wartość zadeklarowaną append pozwala dołączyć podane wartości opcji do końca listy opcji zwróconych przez serwer prepend pozwala na dołączenie podanej wartości na początek listy opcji zwróconych przez serwer request klient jedynie żąda od serwera danej opcji require klient powinien odrzucać wszystkie wiadomości nie posiadające danej opcji Nie wszystkie słowa klczowe mogą wystąpić z każdą opcją. Wykaz słów kluczowych z którymi dana opcja może wystąpić został ujęty w tabeli w punkcie 9.2.7. Oto dwa sposoby deklaracji opcji: [request][require] NazwaOpcji [send supersede default] WartośćOpcji [prepend append] NazwaOpcji W przypadku większości opcji, których wartościami nie mogą być listy stosuje się zazwyczaj pierwszy sposób deklaracaji. Dla opcji mogących pobierać listę wartości (np. lista adresów serwerów DNS) oprócz pierwszego sposobu deklaracji można zastosować drugi sposób. Rodzaje opcji, ich typy (tj. dozwolone wartości) oraz słowa kluczowe z jakimi mogą występować zotały ujęte w tabeli w punkcie 9.2.7. Opis opcji W poniższej tabeli zostały zebrane wszystkie opcje. Do każdej opcji oprócz opisu i wartości które może przyjmować, podane są słowa kluczowe, z którymi może występować oraz najwęższy zakres, w którym może opcja wystąpić.

Opis plików konfiguracyjnych 105 Nazwa opcji Zakres występowania Validlifetime Preferedlifetime klu- Słowa czowe Wartości wartość) (Domyślna send adresu liczba z zakresu 0-4294967296 (4294967296) send adresu liczba z zakresu 0-4294967296 (4294967296) T1 send, default IA liczba z zakresu 0-4294967296 (4294967296) T2 send, default IA liczba z zakresu 0-4294967296 (4294967296) werów Lista serwerów, które powinny zostać odrzucone przy przydzielaniu danego IA/grupy IA Rejectservers Preferedservers Rapid- Commit Time- Zone brak IA lista adresów IP i/lub identyfikatorów DUID, rozdzielona przecinkami (Pusta lista) brak IA lista adresów IP i/lub identyfikatorów DUID, rozdzielona przecinkami (Pusta lista) Opis Okres, w czasie którego adres pozostaje ważny i może być używany Okres, po którym adres przechodzi ze stanu prefered w stan depreciated Okres, po upłynięciu którego klient powinien odświeżyć adresy zawarte w IA u serwera, od którego zostały otrzymane Okres, po którym klient powinien spróbować odnowić adres, u jakiegokolwiek z dostępnych ser- Lista preferowanych serwerów, zebrane odpowiedzi ADVERTI- SE od wielu serwerów zostaną posortowane w/g kolejności serwerów na tej liście brak IA 0 lub 1 (0) określa, czy dane o dane IA można ubiegać się przy użyciu wiadomości SOLICIT z opcją Rapid Commit send, fault, persede, append, prepend, require, request NTPservers de- su- send, default, supersede, require, request send, fault, persede, append, prepend, require, request interfejsu Łańcuch znaków w formacie określonym w draft-*-timeconfig- 02.txt ( ) interfejsu Lista adresów IPv6 oddzielonych przecinkami (Pusta lista) DNSservers de- su- interfejsu Lista adresów IPv6 oddzielonych przecinkami (Pusta lista) Lista serwerów NTP Strefa czasowa Lista serwerów DNS

106 Opis plików konfiguracyjnych Domain send, default, interfejsu Łańcuch znaków w super- formacie podanym sede, require, w draft-*-dnsconfigrequest 03.txt ( ) Work-Dir brak globalny Łańcuch znaków (Aktualny katalog) Strefa czasowa Określa miejsce zapisywnia takich plików jak plik z DUID em, czy plik z bazą danych o przydzielonych adresach Log-level brak globalny Liczb z zakresu 1-5 (5) Określa poziom logowania błędów 9.2.8 Przykłady plików konfiguracyjnych klienta. Najprostszą formą konfiguracji klienta DHCPv6 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. Załóżmy jednak trochę bardziej skomplikowaną sytuację. Niech w systemie znajdują się 4 interfejsy o numerach od 1 do 4. Interfejsy od 1 do 3 mają nie być konfigurowane, natomiast interfejs numer 4 o nazwie Lokalny ma mieć przypisane 3 IA. Dwa z tych IA mają mieć przydzielone po 1 adresie, natomiast trzecie IA ma mieć przypisane 3 adresy. Dobrze by było, żeby adresy zawarte w dwóch pierwszych IA miały czas ważności i preferowany równe odpowiednio 2h/1h, a czasy T1 i T2 związane z odświeżaniem adresu wynosiły odpowiednio 10 i 20 min. Natomiast od trzeciego IA wymagane jest, aby adresy w nim przydzielone były następujące: 20::1,20::2 i 20::3, a ich czas życia i preferowany były równe odpowiednio 1h i 30 min., natomiast parametry odświeżania T1 i T2 powinny mieć wartości takie, jak w przypadku pozostałych dwóch IA. Wymagane jest również pobranie od serwerów informacji o dostępnych serwerach NTP i strefie czasowej, a także serwerach DNS i liście przeszukiwania domen. Plik konfiguracyjny spełniający te założenia mógłby mieć postać iface Lokalny { valid-lifetime 7200 //deklaracja domyślnych wartości prefered-lifetime 3600 //dla valid-, prefered-lifetime, T1 i T2 T1 600 //będą obowiązywały do końca zakresu interfejsu T2 1200 //iface Lokalny IA 2 //deklaracja dwóch IA po jednym adresie w każdym z IA IA //deklaracja IA o parametrach podanych wewnątrz zakresu { valid-lifetime 3600 //zmiana domyślnych wartości valid- i prefered-lifetime prefered-lifetime 1800//będzie obowiązywać do końca zakresu IA //deklaracja adresu moglaby wygladać address 3, //ale w takiej postaci nie byłoby możliwe określenie adresów //więc deklarujemy w taki sposób: address { 20::1 20::2 20::3 }

Opis plików konfiguracyjnych 107 } NTP-Servers Time-Zone DNS-Servers Domains } iface 3 no-config iface 2 no-config iface 1 no-config Spróbujmy teraz rozbudować ten plik konfiguracyjny w następujący sposób: Niech podczas przydzielania IA będzie uwzględniana następująca lista preferencji serwerów DHCP: 30::1, 30::2 Niech dla trzeciego IA(z określonymi adresami) serwer DHCP o identyfikatorze DUID: 000100061234565700AB02467 będzie zawsze odrzucany Niech trzecie IA będzie przydzielane w trybie Rapid Commit Określmy też poziom logowania oraz katalog roboczy Plik konfiguracyjny spełniający powyższe wymagania może mieć postać: iface eth0 { log-level 3 work-dir /var/cache/dhcpv6 prefered-servers 30::1,30::2 //lista preferowanych serwerów DHCP valid-lifetime 7200 //deklaracja domyślnych wartości prefered-lifetime 3600 //dla valid-, prefered-lifetime, T1 i T2 T1 600 //będą obowiązywały do końca zakresu interfejsu T2 1200 //iface Lokalny IA 2 //deklaracja dwóch IA po jednym adresie w każdym z IA IA //deklaracja IA o parametrach podanych wewnątrz zakresu { valid-lifetime 3600 //zmiana domyślnych wartości valid- i prefered-lifetime prefered-lifetime 1800//będzie obowiązywać do końca zakresu IA reject-servers 000100061234565700AB02467 //odrzucamy serwer o podanym DUID zie RapidCommit 1 address { 20::1 20::2 20::3 } } NTP-Servers Time-Zone DNS-Servers Domains } iface wifi0 no-config //i informujemy,że chcemy przydzielać IA w trybie Rapid Commit

108 Opis plików konfiguracyjnych 9.3 Struktura pliku konfiguracyjnego serwera DHCPv6 W pliku konfiguracyjnym serwera DHCPv6 zostały wyróżnione cztery rodzaje zakresów: 1. globalny 2. inetrfejsu 3. klasy Analogicznie jak w przypadku pliku konfiguracyjnego klienta najszerszym zakresem jest zakres globalnym. W zakresie globalnym można zadeklarować interfejs, a wraz z nim jego zakres. Z kolei w zakresie interfejsu można definiować klasę adresów wraz zakresem klasy. Tak jak w pliku konfiguracyjnum klienta z zakresami powiązane są różne opcje, a uwagi dotyczące miejsca deklaracji opcji i ich zasięgu przedstawione w punkcie 9.2.1 na stronie 102 pozostają w mocy dla pliku konfiguracyjnego serwera. 9.3.1 Deklaracje globalne. W zakresie globalnym mogą pojawić się deklaracje wszystkich opcji oraz deklaracje interfejsu. Opis deklaracji interfejsu znajduje się w następnym punkcie natomiast opis sposobu deklaracji opcji znajduje się w 9.3.4. Plik konfiguracyjny ma zatem postać: [deklaracja interfejsu deklaracja opcji globalnych deklaracja opcji interfejsu deklaracja opcji klasy ]... 9.3.2 Deklaracja interfejsu Interfejs można zadeklarować na dwa różne sposoby: iface interfejsnazwa interfejsnumer no-config lub iface interfejsnazwa interfejsnumer { [deklaracja klasy deklaracja opcji interfejsu deklaracja opcji klasy ]... } gdzie interfejsnazwa oznacza nazwę interfejsu, a interfejsnumer to numer interfejsu. Opis deklaracji IA znajduje się w kolejnym punkcie natomiast opcji interfejsu, IA oraz adresu w punkcie 9.2.7. Pierwszy sposób deklaracji określa, że interfejs o nazwie interfejsnazwa lub numerze interfejsnumer nie ma być konfigurowany przez klienta DHCPv6. W przeciwieństwie do klienta serwer nie konfiguruje interfejsów, który deklaracja nie znajdzie się w pliku konfiguracyjnym. Drugi sposób pozwala na szczegółowe określenie sposobu konfiguracji interfejsu o nazwie interfejsnazwa lub numerze interfejsnumer. Sposób ten pozwala na określenie jakie klasy adresowe mają być przydzielane na danym interfejsie, a także na ustalenie sposobu przydzielania adresów np. przy użyciu opcji reject-clients można dla danej klasy wyspecyfikować, których klientów odrzucać. Opis deklaracji klasy znajduje się w następnym punkcie, natomiast opis opcji klasy i opcji interfejsu w punkcie 9.3.4.

Opis plików konfiguracyjnych 109 9.3.3 Deklaracja klasy. Klasa adresów deklarowana jest w następujący sposób: iface interfejsnazwa interfejsnumer { [deklaracja opcji klasy deklarcja puli adresowej]... } gdzie sposób deklaracji opcji klasy znajduje się w następnym punkcie, a deklaracja puli adresowej ma postać: pool adres IPv6-adres IPv6[,adres IPv6-adres IPv6]... gdzie adres IPv6 ma postać opisaną w punkcie 9.2.6. 9.3.4 Opis deklaracji opcji Deklaracja opcji w pliku konfiguracyjnym serwera ma postać: NazwaOpcji WartośćOpcji Rodzaje opcji wraz z opisem, dozwolone/domyślne wartości oraz zakres występowania zostały zebrane w poniższej tabeli: Nazwa opcji Zakres Wartość (Domyślna występowania wartość) log-level globalny Liczba z zakresu 1-5 (5) work-dir globalny Łańcuch (aktualny katalog) dns-server interfejsu Lista adresów IPv6 oddzielonych przecinkami (Pusta lista) domain interfejsu Łańcuch w formacie opisanym w [22] ntp-server interfejsu Lista adresów IPv6 oddzielonych przecinkami (Pusta lista) time-zone interfejsu Łańcuch w formacie opisanym w [21] ( ) acept-only klasy Lista zakresów adresów IPv6/zakresów identyfikatorów DUID (Pusta lista) reject-clients klasy Lista zakresów adresów IPv6/zakresów identyfikatorow DUID (Pusta lista) Opis Określa poziom szczegółowości logowania komunikatół (1-najbardziej szczegółowy poziom, 5-najmniej szczegółowy) Określa ścieżke do katalogu, w którym powinny być zapisywane pliki związane z usługą Lista adresów serwerów DNS Lista przeszukiwania domen ( ) Lista serwerów NTP Strefa czasowa Lista klientów, którzy tylko będą akceptowani przy przydzielaniu adresów z tej klasy Lista klientów, którzy powinni być odrzucani przy przydzielaniu adresów z tej klasy

110 Opis plików konfiguracyjnych t1 klasy liczba z zakresu 0-4294967296 (4294967296) t2 klasy liczba z zakresu 0-4294967296 (4294967296) prefered-lifetime klasy liczba z zakresu 0-4294967296 (4294967296) valid-lifetime klasy liczba z zakresu 0-4294967296 (4294967296) Określa wartość T1 dla IA z adresami przydzielonymi z tej klasy Określa wartość T2 dla IA z adresami przydzelonymi z tej klasy Określa wartość pola prefered dla adresów przydzielanych z tej klasy Określa wartość pola valid dla adresów przydzielanych z tej klasy unicast klasy 1 lub 0 (0) określa, czy dla danej klasy ma być wspierana opcja Option Unicast preference klasy liczba z zakresu 0-255 określa stopień preferencji danego serwera (0) rapidcommit klasy 1 lub 0 (0) określa, czy adresy w tej klasie mogą być przydzielane po otrzymaniu komunikatu SOLICIT z opcją RapidCommit max-lease klasy liczba z zakresu 0-4294967296 (4294967296) client-max-lease klasy liczba z zakresu 0-4294967296 (4294967296) Określa ile maksymalnie adresów można przydzielić z danej klasy Określa ile maksymalnie adresów można przydzielić adresów z danej klasy pojedynczemu klientowi 9.3.5 Przykłady plików konfiguracyjnych serwera W przeciwieństwie do sposobu konfiguracji klienta, aby serwer konfigurował klientów na jakimś interfejsie, interfejs ten musi on zostać jawnie opisany w jego pliku konfiguracyjnym. Załóżmy zatem na początek prostą sytuację: należy skonfigurować interfejs o numerze 5 i przydzielać na nim adresy z klasy 20::10/124. Taki najprostszy plik konfiguracyjny może mieć postać: iface 5 { } class { pool 20::10-20::1f } Rozszerzmy teraz ten plik o następujące elementy: dodajmy nową klasę na interfejsie 5 np. 20::fe00/120, dla której dozwolone będzie przydzielanie adresów w trybie Rapid Commit ustawmy preferencje serwera na 255, aby był najważniejszy na interfejsie 5 skonfigurujmy interfejs 4, aby przydzielane były na nim adresy z klasy 20::20/124, ale na tym interfejsie niech preferencja serwera będzie ustawiona na 0

Opis plików konfiguracyjnych 111 Niech klient o identyfikatorze DUID 00001231200adeaaa będzie odrzucany w klasie 20::20/124 Niech dla wszystkich klas czasy valid- i prefered adresów wynoszą 1h i 30 min., a czasy T1 i T2 odpowiednio 10 min. i 20 min. Natomiast wyjątkowo dla klasy 20::20/124 czasy valid- i preferedpowinny wynosić 2h i 1h Niech w klasie 20::10/124 jedne klient ma przydzielone maksymalnie 2 adresy Niech w klasie 20::20/124 maksymalnie może być przydzielonych 10 adresów Zezwolmy też klientom na interfejsie 5 na komunikację przy użyciu unicastu Niech klient o adresie IP fe80::200:39ff:fe4b:1abc ma przydzielany adres 20::2f oczywiście z klasy 20::20/124 Poinformujmy również klientów na interfejsie numer 5 o dostępnych serwerach DNS i NTP, a także strefie czasowej i listy przeszukiwania domen. ustalmy także katalog roboczy i poziom logowania błędów Oto właściwy plik konfiguracyjny: valid-lifetime 3600 prefered-lifetime 1800 T1 600 T2 1200 iface 4 { preference 0 class { reject-clients 00001231200adeaaa 20::2e-20::20 max-lease 10 } class { accept-only fe80::200:39ff:fe4b:1abc pool 20::2f } } iface 5 { dns-server ntp-server time-zone EST domain preference 255 class { pool 20::fe00-20::feff RapidCommit 1 }

112 Opis plików konfiguracyjnych } class { valid-lifetime 7200 prefered-lifetime 3600 pool 20::f-20::0 client-max-lease 2 }

Rozdział 10 Testy Nieodłączną częścią każdego procesu wytwarzania oprogramowania jest faza testów. W klasycznym modelu kaskadowym Konieczne jest sprawdzenie, że otrzymany produkt spełnia wymagania klienta. Oczywistym celem testowania jest również usunięcie jak największej możliwej ilości błędów. W przypadku implementacji protokołu DHCPv6 sprawdzenie zgodności było ułatwione specyfikacja wymagań została przecież przedstawiona w formalnym dokumencie [20], a potem w [18]. Jednym z celów implementacji jest tzw. interoperability, czyli w tłumaczeniu na język polski zgodność z innymi implementacjami. W szczególności testom podlegało sprawdzenie zgodności z bliźniaczą implementacją DHCPv6, wykonywaną równolegle przez Pana Marka Senderskiego. W chwili pisania niniejszej pracy, istniała tylko jedna, niepełna implementacja DHCPv6 pod linuxa. Jej wersja, oznaczona numerem 0.85 jest dostępna pod adresem http://dhcpv6.sourceforge.net. Autorami są Shirley Ma (IBM), Stephen Hemminger, Venkata Jagana oraz Kazuo Hiekata. Bazuje ona na nieaktualnym (oznaczonym jako obsolete) dokumencie draft-dhcpv6-26. Ze względu na to, że implementacja ta nie posiada nazwy, a przez autorów określana jest po prostu jako DHCPv6, wszelkie odniesienie do niej będą brzmiały obcy serwer i obcy klient. Również z nią zostały przeprowadzone odpowiednie testy. Proces testowania polegał na sprawdzeniu poszczególnych senariuszy możliwych do wystąpienia w protokole DHCPv6. W większości przypadków zostały zbadane 4 konfiguracje: klient: Linux, serwer: Linux klient: Windows, serwer: Windows klient: Linux, serwer: Windows klient: Windows, serwer: Linux Testy zostały przeprowadzone wspólnie z Panem Markiem Senderskim. Wynik testu został podany w formacie Ilość sukcesów, ilość porażek. W przypadku porażki zawarty jest szczegółowy opis. 10.1 Test 1: Sytuacja klasyczna Cel: Pokazanie poprawności odnajdowania serwera, przyznawanie adresu. Opis: Klient po uruchomieniu generuje wiadomość SOLICIT (rysunek 10.1). Serwer po otrzymaniu, odpowiada wiadomością ADVERTISE (rysunek 10.2). Klient stwierdza, że upłynął czas na ewentualne odpowiedzi serwerów, więc z listy kandydantów wybiera jedyny serwer. Transmituje wiadomość REQU- EST z prośbą o adresy. Wiadomość zawiera opcję IA zawierającą opcję IAADDR, która reprezentuje adres. Ustawione są parametry IA oraz adresu, jakie chciałby otrzymać klient (T1=20, T2=40, adres 20::1, prefered-lifetime: nieskończoność, valid-lifetime: nieskończoność. Wiadomość została pokazana na

114 Testy rysunku 10.3. Odebrane wartości serwer traktuje jako wskazówki przy doborze wartości. Serwer po otrzymaniu wiadomości przydziela adresy, co sygnalizuje wiadomością REPLY (ustawione parametry: T1=5, T=10, adres 20::1, pefered-lifetime 45, valid-lifetime: 60). Odpowiedź klienta została przedstawiona na rysunku 10.4. Po otrzymaniu adresu klient przeprowadza detekcję zduplikowanych adresów. Mechanizm ten jest częścią protokołu. Generuje w tym celu wiadomość Neighbor Solicitation, przedstawioną na rysunku 10.5. Brak odpowiedzi Neighbor Advertisement oznacza, że adres nie jest jeszcze używany. Jest on więc konfigurowany w systemie jako poprawny i aplikacje użytkownika mogą rozpocząć jego wykorzystanie. Wynik: Sukcesów: 4, porażek: 0 Rysunek 10.1: Test 1: Wiadomość SOLCIT

Testy 115 Rysunek 10.2: Test 1: Wiadomość ADVERTISE

116 Testy Rysunek 10.3: Test 1: Wiadomość REQUEST, opcje IA oraz IAADDR

Testy 117 Rysunek 10.4: Test 1: Wiadomość REPLY, opcje IA oraz IAADDR

118 Testy Rysunek 10.5: Test 1: Wiadomość NEIGHBOR SOLICITATION 10.2 Test 2: Odświerzanie adresu Cel: Demonstracja poprawności odświerzania adresów Opis: Bezpośrednio po zakończeniu testu 1, klient czeka na upłynięcie T1 sekund (wartość T1 została przekazana przez serwer we wiadomości REPLY ). Po upłynięciu tego czasu generowana jest wiadomość RENEW (rysunek 10.6). Serwer po otrzymaniu wiadomości, uaktualnia czasy życia adresów i uaktualnione wartości odsyła klientowi za pomocą wiadomości REPLY (rysunek 10.7). Klient odbiera wiadomość, po czy zasypia na kolejny okres T1 sekund. W przypadku braku odpowiedzi ze strony serwera (wywołanej sztucznie poprzez chwilowe rozłączenie sieci) wiadomość RENEW jest restransmitowana do czasu przekroczenia czasu T2. Po tym czasie następuje wygenerowanie wiadomości REBIND (rysunek 10.8) skierowanej do wszystkich serwerów. W tym momencie zostaje z powrotem przywrócone połączenie sieciowe. Serwer odbiera wiadomość REBIND, uaktualnia adresy, po czym odsyła odpowiedź we wiadomości REPLY, która jest analogiczna z odpowiedzią na REPLY. Klient po odebraniu odpowiedzi stwierdza, że komunikacja z serwerem została odnowiona i powraca do normalnego trybu odświerzania adresów za pomocą wiadomości RENEW. Wynik: Sukcesów: 4, porażek: 0

Testy 119 Rysunek 10.6: Test 2: Wiadomość RENEW

120 Testy Rysunek 10.7: Test 2: Wiadomość REPLY

Testy 121 Rysunek 10.8: Test 2: Wiadomość REBIND 10.3 Test 3: Zwalnianie adresu Cel: Demonstracja poprawności zwalniania adresów. Opis: Klient po zakończeniu testu 2 posiada przydzielone adresy, które okresowo odświerza. Otrzymuje polecenie zakończenia pracy od użytkownika (sygnał w przypadku Linuxa lub polecenie zakończenia usługi w przypadku Windowsa). Generuje wiadomość RELEASE zawierające adresy (rysunek 10.9). Po odbraniu wiadomości serwer przetwarza wszystkie odebrne opcje IA, adresy zaznacza w bazie jako wolne i odsyła odpowiedź REPLY potwierdzającą ten fakt. Wiadomość zawiera opcję STATUS CODE informującą o rezultacie zwolnienia adresów (rysunek 10.10). Wynik: Sukcesów: 4, porażek: 0

122 Testy Rysunek 10.9: Test 3: Wiadomość RELEASE

Testy 123 Rysunek 10.10: Test 3: Wiadomość REPLY z opcją STATUS CODE 10.4 Test 4: Przyspieszone zapytanie Cel: Demonstracja działania przyspieszonej transakcji przyznawania adresów (z wykorzystaniem opcji RAPID COMMIT ). Opis: Normalny tryb przyznawania adresów obejmuje wiadomości: SOLICIT, ADVERTISE, REQUEST, REPLY. Dzięki załączeniu opcji RAPID COMMIT do pierwszej wiadomości (rysunek 10.11) i przy odpowiedniej konfiguracji serwera, możliwe jest pominięcie wiadomości 2 oraz 3 i bezpośrednia odpowiedź za pomocą REPLY (rysunek 10.12). Wynik: Sukcesów: 4, porażek: 0

124 Testy Rysunek 10.11: Test 4: Wiadomość SOLICIT z opcją RAPID COMMIT

Testy 125 Rysunek 10.12: Test 4: Wiadomość REPLY 10.5 Test 5: DHCPv6 w trybie stateless Cel: Demonstracja działania DHCPv6 w trybie stateless. Opis: W przypadku, kiedy klient nie jest zainteresowany otrzymaniem adresów, a jedynie informacji konfiguracyjnych, generuje wiadomość INFORMATION-REQUEST (rysunek 10.13). Serwer po otrzymaniu takiej wiadomości odpowiada wiadomością REPLY z ustawionymi odpowiednimi opcjami (rysunek 10.14). Na tym kończy się interakcja pomiędzy serwerem i klientem. Wynik: Sukcesów: 4, porażek: 0

126 Testy Rysunek 10.13: Test 5: Wiadomość INFORMATION-REQUEST

Testy 127 Rysunek 10.14: Test 5: Wiadomość REPLY 10.6 Test 6: Wykrywanie zduplikowanych adresów Cel: Detekcja używanych adresów Opis: Przedstawiona tu sytuacja może być dalszym ciągiem sceniariusza z testu 1. Analiza sytuacji rozpoczyna się od otrzymania przez klienta wiadomości REPLY zawierającej jakieś adresy, w tym przypadku 20::1 oraz 20::2 (rysunek 10.15). Klient po przeanalizowaniu otrzymanych wartości rozpoczyna procedurę DAD detekcji zduplikowanych adresów. Wysyła wiadomość NEIGHBOR SOLICITA- TION (rysunek 10.16). Odbiera wiadomość NEIGHBOR ADVERTISEMENT, co oznacza, że dany adres jest już używany (rysunek 10.17). W takiej sytuacji dalsze wykorzystanie adresu jest niemożliwe. Klient informuje serwer o wykryciu tego faktu za pomocą wiadomości DECLINE (rysunek 10.18). Serwer w bazie danych zaznacza adres jako używany przez nieznany host i odpowiada klientowi potwierdzeniem w postaci wiadomości REPLY (rysunek 10.19). Wynik: Sukcesów: 4, porażek: 0

128 Testy Rysunek 10.15: Test 6: Wiadomość REPLY (odpowiedź na REQUEST )

Testy 129 Rysunek 10.16: Test 6: Wiadomość NEIGHBOR SOLICITATION

130 Testy Rysunek 10.17: Test 6: Wiadomość NEIGHBOR ADVERTISEMENT

Testy 131 Rysunek 10.18: Test 6: Wiadomość DECLINE

132 Testy Rysunek 10.19: Test 6: Wiadomość REPLY (odpowiedź na DECLINE ), opcja IA wraz z podopcjami IAADDR oraz STATUS-CODE 10.7 Test 7: Wiele klientów, jeden serwer Cel: Demonstracja obsługi wielu klientów przez jeden serwer. Opis: Klient 1 rozpoczyna procedurę znajdowania serwera (rysunek 10.20). Następuje standardowa wymiana wiadomości ( SOLICIT REPLY REQUEST REPLY ). Następnie klient 1 przechodzi w tryb okresowego odświerzania adresów. W tym momencie włącza się klient 2 (rysunek 10.21). Po zakończeniu procedury przyznawania adresów, również klient 2 rozpoczyna okresowe odświerzanie adresów. Test kończy się okresowymi wiadomościami RENEW od dwóch klientów. Wynik: Sukcesów: 4, porażek: 0

Testy 133 Rysunek 10.20: Test 7: Transakcja SOLICIT... REPLY pierwszego klienta

134 Testy Rysunek 10.21: Test 7: Transakcja SOLICIT... REPLY drugiego klienta 10.8 Test 8: Jeden klient, wiele serwerów Cel: Demonstracja wyboru przez klienta jednego z dostępnych serwerów. Opis: Klient rozpoczyna procedurę znajdowania serwera za pomocą wiadomości SOLICIT. Otrzymuje dwie odpowiedzi ADVERTISE od różnych serwerów. Serwer, który odpowiedział jako pierwszy (adres fe80::20c:6eff:fe01::8359), posiada opcję PREFERENCE ustawioną na wartość 7 (rysunek 10.22). Odpowiedź z drugiego serwera (adres fe80::200:39ff:fe3a:1db2) nadeszła wkrótce potem. Zawierała ona opcję PREFERENCE ustawioną na 5 (rysunek 10.23). Po zakończeniu zbierania odpowiedzi serwera, klient wybiera z listy serwer o najwyższych preferencjach. W tym przypadku jest to serwer nr 1. Właśnie do niego jest skierowana wiadomość REQUEST, co można łatwo stwierdzić analizując adres źródłowy odpowiedzi REPLY (rysunek 10.24). Wynik: Sukcesów: 4, porażek: 0

Testy 135 Rysunek 10.22: Test 8: Odpowiedź ADVERISE serwera 1 wraz z opcją PREFERENCE

136 Testy Rysunek 10.23: Test 8: Odpowiedź ADVERISE serwera 2 wraz z opcją PREFERENCE

Testy 137 Rysunek 10.24: Test 8: Odpowiedź REPLY wysłana przez serwer 1 10.9 Test 9: Jeden klient, 2 serwery, kończące się adresy Cel: Demonstracja obsługi dynamicznej zmiany serwera w przypadku kończących się adresów. Opis: Początek identyczny, jak w teście 8. Tym razem klient prosi o przyznanie dwóch IA z jednym adresem w każdym z nich (rysunek 10.25). Serwer 1 posiada już tylko jeden wolny adres, który przydziala do pierwszego IA. Na drugie IA odpowiada z załączoną opcją STATUS-CODE ustawioną na wartość NoAddrAvail (rysunek 10.26). W takiej sytuacji klient uznaje, że pierwsze IA zostało skonfigurowane poprawnie, więc konieczne jest skonfigurowanie tylko drugiego IA. W tym celu wysyła drugą wiadomość REQUEST do kolejnego serwera na liście preferencji (rysunek 10.27). Serwer 2 przyznaje adres, co sygnalizuje wiadomością REPLY (rysunek 10.28). W tej chwili klient posiada 2 adresy obsługiwane przez 2 różne serwery. Fakt obsługi przez 2 serwery łatwo stwierdzić obserwując sposób odświerzania adresów 2 wiadomości RENEW do dwóch różnych serwerów oraz następujące odpowiedzi REPLY, każda z odpowiedniego serwera (rysunek 10.29). Wynik: Sukcesów: 4, porażek: 0

138 Testy Rysunek 10.25: Test 9: Wiadomość REQUEST z dwoma opcjami IA, kierowana do serwera 1

Testy 139 Rysunek 10.26: Test 9: Odpowiedź REPLY serwera 1 z dwoma opcjami IA

140 Testy Rysunek 10.27: Test 9: Wiadomość REQUEST z dwoma opcjami IA, kierowana do serwer 2

Testy 141 Rysunek 10.28: Test 9: Odpowiedź REPLY serwera 2 z jedną opcją IA

142 Testy Rysunek 10.29: Test 9: Odświerzanie adresów za pomocą dwóch wiadomości RENEW 10.10 Test 10: Interoperability klienta Cel: Demonstracja współpracy klienta z obcym serwerem. Opis: Jako obcy serwer posłużył demon znajdujący się w pakiecie DHCPv6 dostępnym pod adresem http://dhcpv6.sourceforge.net. Klient rozpoczął odkrywanie serwerów za pomocą wiadomości SOLICIT (rysunek 10.30) zawierającej dwa IA z jedym adresem w każdym. Serwer odpowiedział wiadomością ADVERTISE (rysunek 10.31). Niestety, wiadomość zawierała tylko jedną opcję IA, ale za to z trzema adresami. Klient z dostępnych serwerów wybrał jedyny możliwy i wysłał do niego wiadomość REQU- EST ponownie z dwoma opcjami IA (rysunek 10.32). Serwer odpwiedział wiadomością REPLY, w której przydzielił 3 adresy do jednego IA, chociaż w tym IA proszono tylko o jeden adres. W takiej sytuacji nasz klient uznał, że to IA zostało skonfigurowane poprawnie (wymagana ilość adresów została przydzielona), natomiast drugie IA zostało uznane za niemożliwe do skonfigurowania. Klient przystąpił więc do okresowego odświerzania tylko jednego IA za pomocą wiadomości RENEW (rysunek 10.34, na co serwer odpowiadał poprawną już wiadomością REPLY (rysunek 10.35). Należy zauważyć, że wina w niepoprawnym zachowaniu leży po stronie obcego serwera. Nie jest on w stanie poprawnie obsłużyć więcej niż jednego opcji IA, chociaż dokument RFC ([18]) w punkcie 18.1.1 stwierdza wyraźnie, że: The client uses a Request message to populate IAs with addresses and obtain other

Testy 143 configuration information. The client includes one or more IA options in the Request message. The server then returns addresses and other information about the IAs to the client in IA options in a Reply message. Interpretacja nie pozostawia wątpliwości opcja IA może występować wielokrotnie. Pewnego komentarza wymaga fakt wystąpienia nierozpoznanych opcji o numerach 25 oraz 26 widocznych na rysunkach 10.31 oraz 10.33. Są to opcje DNS-SERVERS oraz DOMAIN SEARCH LIST. Ich specyfikacja znajduje się obecnie w fazie roboczej (draft) i nie posiada przydzielonych oficjalnie numerów. Nasza implementacja przyjęła te wartości na 30 i 31. Takie same wartości zostały przyjęte przez twórców programu Ethereal, więc rozpoznał on nasze opcje poprawnie, natomiast opcji obcego serwera nie. Pomimo pewnych problemów z obsługą wielu IA (jest to konfiguracja jak najbardziej poprawna, ale niestandardowa), możliwa jest owocna współpraca klienta z obcym serwerem. Wynik: Sukcesów: 2, porażek: 0 Rysunek 10.30: Test 10: Wiadomość SOLICIT

144 Testy Rysunek 10.31: Test 10: Wiadomość ADVERTISE od obcego serwera

Testy 145 Rysunek 10.32: Test 10: Wiadomość REQUEST

146 Testy Rysunek 10.33: Test 10: Wiadomość REPLY od obcego serwera

Testy 147 Rysunek 10.34: Test 10: Wiadomość RENEW

148 Testy Rysunek 10.35: Test 10: Wiadomość REPLY (odpowiedź na RENEW ) od obcego serwera 10.11 Test 11: Interoperability serwera Cel: Demonstracja współpracy serwera z obcym klientem. Opis: Obcy klient rozpoczyna odnajdowanie serwera wysyłają wiadomość SOLICIT. Zawiera ona niepoprawnie zbudowaną opcję IA : brak zawartych opcji IAADDR reprezentujących adresy (rysunek 10.36). Serwer odpowiada wiadomością ADVERTISE z ustawioną opcją STATUS-CODE na wartość UnspecFail oraz komunikatem No addresses in this IA NA option. (rysunek 10.37). Klient stwierdza, że nie znalazł ani jednego serwera, którego odpowiedź by go satysfakcjonowała, więc rozpoczyna proces odkrywania serwerów na nowo w nadzei znalezienia innych serwerów (zachowanie zgodne z RFC). W ten sposób proces zapętla się. Wynik: Sukcesów: 0, porażek: 2

Testy 149 Rysunek 10.36: Test 11: Wiadomość SOLICIT obcego klienta

150 Testy Rysunek 10.37: Test 11: Wiadomość ADVERTISE

Rozdział 11 Podsumowanie Piętnaście lat temu komputery osobiste zaczęły odgrywać istotną rolę w życiu przeciętnego człowieka. Były traktowane jak elektroniczne deski kreślarskie, nowoczesne maszyny do pisania lub złożone narzędzia wspomagania księgowości. Każde stanowisko stanowiło jednak odrębną całość i brak jakiegokolwiek połączenia ze światem był standardem. Ludzie dopiero uświadamiali sobie, jak potężne narzędzie otrzymują wyposażając swój komputer w modem. Tak naprawdę w ten sposób rozpoczął się wielki trend do integracji poszczególnych urządzeń. Prawdziwym przełomem okazał się Internet. Dokładnie 10 lat temu, w roku 1993 Narodowa Fundacja Nauki USA (NSF) przyznała trzem firmom Network Solutions, AT&T oraz General Atomics kontrakty na zarządzanie tym, co w ówczesnych czasach było szkieletem Internetu. Dzięki połączeniu wielu komputerów razem, użytkownik zyskiwał nagle dostęp do ogromnej ilości informacji, niemożliwej przedtem do zgromadzenia na jednej stacji roboczej. To w połączeniu z wyjściem poza kręgi akademickie spowodowało lawinowy rozwój Internetu. Internet, a w szczególności protokoły będące jego podstawą TCP/IP, nie były projektowane z myślą o globalnym zastosowaniu. Najszybciej objawiającym i najbardziej dającym się we znaki mankamentem używanej obecnie wersji protokołu TCP/IP w wersji 4 jest gwałtownie zmniejszająca się ilość dostępnych adresów, zwłasza że ze względu na strukturę przestrzeni adresowej, nie można wykorzystać wszystkich dostępnych adresów. Innym znaczącym problemem jest pojawianie się coraz to nowszych urządzeń obsługujących połączenia sieciowe. Dwa lata temu najnowszą ciekawostką technologiczną był zestaw lodówki oraz kuchenki mikrofalowej, które to porozumiewały się właśnie za pomocą TCP/IP 1 W tej chwili tego typu rozwiązania budzą uśmiech na twarzy, jednak za kilka lat widoczny będzie wyraźny trend podłączania do sieci jak największej ilości urządzeń. Wady obecnej wersji protokołu TCP/IP zostały dostrzeżone już dawno. Od roku 1995 prowadzone są prace standaryzujące na nową wersją rodziną protokołów IPv6. W stosunku do poprzedniej wersji stanowi ogromny postęp. Jest on jednak okupiony dużo większą złożonością. O ile w przypadku IPv4 było jeszcze możliwe ręczne konfigurowanie poszczególnych urządzeń, to w przypadku IPv6 jest to prawie niemożliwe. Dlatego wraz z masowym przejściem na platformę IPv6 równie masowo zaczną pojawiać się rozwiązania oferujące automatyczną konfigurację urządzeń. Jedynym standardem oferującym takie usługi w zakresie IPv6 jest właśnie protokół Dynamic Host Configuration Protocol w wersji 6. Jest to bardzo nowoczesne rozwiązanie ostateczna wersja specyfikacji tego protokołu została opublikowana w lipcu 2003 roku. Właśnie na tej wersji bazuje przedstawiona tutaj implementacja. 11.1 Implementacja W chwili obecnej autorowi niniejszej pracy znane są trzy inne implementacje protokołu DHCPv6: 1 Lodówka po otrzymaniu od kuchenki informacji o zużytej pizzy i stwierdzeniu, że zapas dostępnych pizz się kończy, była w stanie skontaktować się ze specjalnym centrum, które następnie wysyłało dostawcę z nowymi pizzami.

152 Podsumowanie Implementacja projektu KAME systemy BSD, obecnie w fazie testing, tylko rodzina BSD Nieoficjalna Implementacja IBM dostępna na stronach dhcpv6.sourceforge.net, bazuje na nieaktualnej specyfikacji [19] Implementacja HP wersja komercyjna, dostępna tylko na platformy HP-UX Wszystkie z tych implementacji bazują na wersjach roboczych specyfikacji (draftach) i jako takie można uznać je za przedawnione. Dodatkowo żadna z tych implementacji nie jest w najmniejszym stopniu przenośna. Implementacja będąca integralną częścią tej pracy jest pozbawiona tych wad. Dodatkowo posiada szereg innych zalet: Rozbudowana konfiguracja serwera wiele klas, rezerwacje adresów, dostępna drobiazgowa kontrola, opcje określane dla całego serwera, danej klasy lub danego klienta, zabezpieczenia przez atakami typu DOS Zerowa konfiguracja klienta szybkość uruchomienia po stronie klienta jest sprawą kluczową dla sukcesu całej implementacji. Wystarczy zainstalować demona. Reszta wykona się sama. Nieobowiązkowa możliwość konfiguracji klienta w przypadku bardziej zaawansowanych przypadków istnieje możliwość drobiazgowej konfiguracji serwera. Przenośność w tej chwili implementację można uruchomić na dowolnej maszynie wyposażonej w system Linux w wersji 2.4 lub nowszej, a także systemach Windows 2000/XP. Dzięki zastosowaniu C++ przeniesienie na inne systemy wymaga zaimplementowania tylko kilku (około 10) niskopoziomowych funkcji związanych z interfejsami sieciowymi. Rozszerzalność oprócz standardowych opcji DHCPv6 (opisanych w [18]), zaimplementowano dodatkowe, takie jak DNS-SERVERS oraz NTP-SERVERS opisane odpowiednio w roboczych specyfikacjach [22] i [21]. Nie ma jednak żadnych przeszód, aby system rozszerzyć o nowe opcje, nad którymi dopiero są prowadzone prace. Przejrzysta architektura dzięki zastosowaniu programowania zorientowanego obiektowo, implementacja jest przejrzysta, a jej analiza nie nastręcza większych problemów Otwartość dzięki dostępności na zasadach licencji GNU GPL, każdy użytkownik Internetu ma możliwość dostosowania tej implementacji do własnych potrzeb (np. przeniesienie na swój ulubiony system operacyjny) 11.2 Wartość dydaktyczna laboratorium Z myślą o studentach młodszych lat, na podstawie niniejszej pracy została przygotowana propozycja laboratorium. Jej celem jest zapoznanie studentów z najnowszymi trendami w zakresie automatycznej konfiguracji hostów i pogłębienie znajomości podstaw IPv6. Znajomość rodziny IPv6 zostanie poszerzona o protokół DHCPv6. Propozycja laboratorium została opracowana z zamiarem jej realizacji w sali 436 wydziału ETI Politechniki Gdańskiej. Propozycja laboratorium została podzielona na 2 części: część dla prowadzącego zajęcia (dodatek A) oraz część dla studentów (dodatek B). Obie opisują przebieg ćwiczenia, jednak w nieco inny sposób. Autor ma nadzieję, że dzięki wprowadzeniu zajęć z DHCPv6 do programu studiów, przyszli absolwenci będą dysponowali wystarczającą wiedzą do wykorzystania protokołu w praktyce.

Podsumowanie 153 11.3 Wykorzystne narzędzia Narzędzia wykorzystane w trakcie pisania pracy: system Linux dostępny na licencji GPL pod adresem http://www.kernel.org system Debian GNU/Linux dostępny na licencji GPL pod adresem http://www.debian.org kompilator C++: g++ część pakietu Gnu Complilers Collection, dostępny na licencji GPL pod adresem http://gcc.gnu.org/ edytor tekstu Emacs dostępny na licencji GPL pod adresem http://www.gnu.org/software/emacs/emacs.html analizator pakietów Ethereal dostępny na licencji GPL pod adresem http://ethereal.com system składu tekstu L A TEX dostępny na licencji LPPL pod adresem http://www.latex-project.org/ debugger gdb dostępny na licencji GPL pod adresem http://www.gnu.org/software/gdb/gdb.html system kontroli wersji CVS dostępny na licencji GPL pod adresem http://www.cvshome.org profiler pamięci Electric Fence dostępny na licencji GPL pod adresem http://perens.com/freesoftware/ biblioteka libxml2 odpowiedzialna za odczyt bazy danych w formacie libxml, dostępna na na licencji MIT pod adresem http://www.xmlsoft.org 11.4 Licencja GPL Wszystkie z wykorzystanych narzędzi są dostępne na licencji GPL lub zbliżonej. Oznacza to, że są one dostępne nieodpłatnie, razem ze źródłami, a każdy użytkownik posiada pełne prawo przeglądania, poprawiania oraz dowolnej edycji kodu. Dodatkowo ma pełne prawo do dalszego rozpowszechniania zmodyfikowanych wersji kodu. Jedyne wymóg, jaki jest stawiany, to dalsze rozpowszechnianie również na licencji GPL. Taki model rozwoju doskonale sprawdził się w przypadku Linuxa oraz wszystkich z nim związanych narzędzi, czyli tzw. wolnego oprogramowania. Autor, na codzień korzystając wyłącznie z wolnego oprogramowania, uznał, że niniejsza implementacja również została upubliczniona na licencji GPL i powinna być traktowana jako wkład w rozwój wolnego oprogramowania. Pełna wersja wraz z kodem źródłowym jest dostępna pod adresem http://klub.com.pl/dhcpv6. Pełna treść licencji GPL została przedstawiona w dodatku D.

154 Podsumowanie

Dodatek A Laboratorium: wersja dla prowadzącego A.1 Cel laboratorium Celem laboratorium jest: Rozwinięcie umiejętności konfiguracji typu statefull hostów i serwerów w śrdowisku IPv6 poprzez opanowanie protokołu DHCPv6 Porównanie możliwości konfiguracji typu stateless i statefull Rozszerzenie wiadomości dotyczących protokołu ND Przedstawienie koncepcji demona (Linux) i usługi (Windows) A.2 Zakres umiejętności wymaganych od studenta Do wykonania laboratorium potrzebne będą następujące umiejętności: Znajomość zagadnień IPv6 (rodzaje adresów, stany adresów w systemie, protokół ND) Znajomość protkołu DHCPv6 Umiejętność posługiwania się poleceniami netsh/ipv6 w systemie Windows i ip -6 w systemie Linux oraz polecenia ping6 Korzystanie z programu Ethereal A.3 Pytania kontrolne Pyt: Jakie są stany adresów IPv6 i co one oznaczają? Odp: secondary (adres należy do grupy adresów i nie jest w niej adresem nadrzędnym), permanent/static (adres jest statyczny), dynamic (adres został przydzielony dynamicznie), deprecated (upłynął już prefered-lifetime, ale jeszcze nie minął valid-lifetime. Adres jest jeszcze poprawny, ale nie wolno go używać do tworzenia nowych połączeń.), tentative/duplicated (adres został wykryty jako duplikat, tzn.

156 Laboratorium: wersja dla prowadzącego ktoś w sieci już używa tego adresu) Pyt: Czy, a jeżeli tak, to w jakich warunkach serwer może odpowiedzieć na wiadomość SOLICIT wiadomością REPLY? Jeżeli nie, to dlaczego? Odp: Po otrzymaniu od serwera opcji Rapid Commit i przy założeniu, że serwer jest skonfigurowany do odpowiadania w tym trybie. (Trzeci warunek: musi mieć adresy do przydzielenia brak adresów to rzecz mało spotykana dla IPv6) Pyt: Klient wysyła 3 wiadomości REQUEST, RENEW, RELEASE. Następnie otrzymuje kolejno 3 odpowiedzi REPLY. Na jakiej podstawie serwer dopasowuje odpowiedzi do wysłanych zapytań? Odp: Na podstawie TRANSACTION-ID, identyfikatorów DUID swoim i serwera. (Ale nie na podstawie kolejności otrzymanych wiadomości) Pyt: W jakim przypadku serwer retransmituje wiadomość? Odp: Tylko, gdy klient wyśle ponownie zaytanie to klient jest odpowiedzialny za mechanizm retransmisji! Pyt: Opisz typowy proces przyznawania adresu. Jakie wiadomości biorą w nim udział i jakie jest ich zadanie? Odp: SOLICIT, jedna lub więcej wiadomości ADVERTISE, wiadomości REQUEST i REPLY W komunikacie SOLICIT przenoszone są parametry i adresy preferowane przez klienta Serwer(y) odpowiada(ją) komunikatem(ami) ADVERTISE Klient wybiera jeden z nich i wysyła do niego komunikat REQUEST Serwer odpowiada przyznanymi adresami i parametrami w komunikacie REPLY Klient przypisuje otrzymane adresy i paramtery. Pyt: W jaki sposób klient sprawdza, czy dany adres jest poprawny. Podaj na przykładzie adresu fe80::1234:5678. Odp: Przeprowadzana jest procedura detekcji podwójnych adresów: Klient przydziela adres multicastowy adres skrócony węzła(ff02::1:ff34:5678) i wysyła komunikat Neighbour Solicitation na ten adres z adresu (::). Jeżeli otrzyma odpowiedź Neighbour Advertisment z adresu fe80::1234:5678 oznacza, że adres jest używany. Jeżeli nie oznacza to, że adres jest poprawny. Pyt: Opisz przykładową transakcję RENEW-REPLY w wersji podstawowej i z opcją Unicast. Podaj adresy i porty na które będą transmitowane dane. Odp: Bez opcji UNICAST: Komunikat RENEW: adres-lokalny klienta ff02::1:2, REPLY: ff02::1:2 adres-lokalny-klienta. Odp: Z opcją UNICAST: Komunikat RENEW: adres-klienta adres-serwera, REPLY: adres-serwera adres-klienta. Pyt: Na czym polega usługa systemowa? Czy różni się demon od zwykłego procesu? (do wyboru) Odp: Usługa systemowa/demon jest to program działający zazwyczaj w tle i wykonujący na rzecz systemu, bądź aplikacji pewne zadania. Usługi są uruchamiane/kończone zazwyczaj przy starcie/zamykaniu systemu.

Laboratorium: wersja dla prowadzącego 157 Odp: Usługa w Windows: Usługi w Windows są programi, które zazwyczj są nieinteraktywne(chociaż mogą być). Kontrolę nad nimi sprawuje Menedżer usług. Umożliwia on nie tylko wykonywanie zadań administracyjnych związanych z usługami np. dodawanie/usuwanie, ale także udostępnia interfejs pozwalają na sterowanie zachowaniem usług poprzez wysyłanie do nich żądań kontrolnych np. start/zatrzymaj. Odp: Demon: zamknięcie deskryptorów plików, zmiana katalogu roboczego na /, wyzerowanie maski dostępu do plików, działanie jako proces w tle, odłączenie od grupy procesów, zablokowanie sygnałów. A.4 Schemat laboratorium Rysunek A.1: Grupy dwustanowiskowe W początkowej części zajęć studenci pracują w parach. W każdej parze znajduje się stanowisko z Windowsami oraz Linuxem. A.5 Ręczna konfiguracja Pyt: Co to jest adres lokalny łącza? Ile adresów lokalnych łącza może posiadać jeden interfejs? Odp: Jest to adres o zasięgu ważności łącza. Standardowo w trakcie procesu Stateless Address Autoconfiguration generowany jest jeden adres na podstawie adresu MAC karty sieciowej. Ręcznie można przypisać dowolną ilość adresów. Polecenie dla studenta: Proszę przypisać adresy oraz parametry konfiguracyjne do poszczególnych hostów. Adresy zostaną podane przez prowadzącego. Poprawność konfiguracji proszę udowodnić poprzez spingowanie sąsiada. Wskazówka: Użyj polecenia ip -6 oraz w Linuxie oraz ipv6 lub netsh w Windowsach. Rady dla prowadzącego: Proszę porozdawać adresy poszczególnym parom zgodnie z poniższym rysunkiem. Prefiksy dla wszystkich

158 Laboratorium: wersja dla prowadzącego adresów są takie same: 112. (W toku całego ćwiczenia prefiksy nie mają istotnego znaczenia, gdyż nie jest wogóle konfigurowany routing.) Wskazówka: W przypadku problemów z pingami należy pamiętać o podaniu interfejsu, przez który ma być transmitowany pakiet ICMP. Dla Linuxa: ping6 -I eth0 fe80::1:1 Dla Windowsa: ping6 fe80::1:2%4 Rysunek A.2: Adresy dla grup 2-stanowiskowych Pyt: Dlaczego należy podać i w jakich warunkach podajemy numer/nazwę interfejsu? Odp: Interfejs określamy w przypadku pingowania adresów lokalnych łącza. Jest to konieczne, ponieważ na podstawie adresu lokalnego nie można określić, na którym interfejsie znajduje się odbiorca. A.6 Instalacja oprogramowania Polecenie dla studenta: Proszę zainstalować klienta i serwer DHCPv6 w obydwóch systemach. Sprawdź, czy są one aktywne. W Windows proszę zatrzymać usługi DHCP, a w Linuxie proszę wyłączyć demona. Wskazówka: Linux: polecenie /etc/init.d/dhcpv6server stop Windows: Panel sterowania Narzędzia administracyjne Usługi

Laboratorium: wersja dla prowadzącego 159 Rady dla prowadzącego: Sprawdzenie, czy dana usługa jest aktywna: Windows: Panel sterowania Narzędzia administracyjne Usługi, kolumna Stan. W przypadku Linuxa: ps aux grep dhcpv6, potem kill nr procesu A.7 Standardowa przyznanie adresu Pyt: Czym się różni konfiguracja stateless od statefull? Skąd takie nazwy? Odp: W statefull jest przechowywany stan klientów, w stateless nie. Nazwa wzięła się od stanu klienta lub jego braku. Polecenie dla studenta: Proszę skonfigurować serwer do przydzielania odpowiedniej puli adresowej. Zakresy dla każdej pary poda prowadzący. Proszę uruchomić klinta i zademonstrować przyznanie adresu. Całą transakcję SOLI- CIT/ADVERTISE/REQUEST/REPLY proszę zaobserwować w Etherealu. Szczególną uwagę proszę zwrócić na moment, kiedy przyznawane są adresy. Rady dla prowadzącego: Dla każdej pary X przydziel klasę 20::X:0/112, np. dla pary 5 20::5:0/112. Najprostszy plik konfiguracyjny serwera dla pary 5 wygląda następująco: iface eth0 { class { pool 20::5:1-20:5:ffff } } Najprostsza konfiguracja klienta: iface eth0 { IA { ADDRESS { } } } Przyznanie adresu można sprawdzić listując dostępne adresy na interfejsie. Linux: ip -6 a Windows: ipv6 if nr interfejsu W Etherealu studenci powinni zademonstrować złapanie pakietów: SOLICIT, ADVERTISE, REQU- EST, REPLY. Przykładowy zrzut ekranu:

160 Laboratorium: wersja dla prowadzącego Rysunek A.3: Ćwiczenie 1: Wiadomość SOLICIT

Laboratorium: wersja dla prowadzącego 161 Rysunek A.4: Ćwiczenie 1: Wiadomość ADVERTISE

162 Laboratorium: wersja dla prowadzącego Rysunek A.5: Ćwiczenie 1: Wiadomość REPLY wraz z przydzielonym adresem.

Laboratorium: wersja dla prowadzącego 163 Rysunek A.6: Ćwiczenie 1: Wiadomość REQUEST Wskazówka: W Etherealu łatwiej zorientować się w sytuacji korzystając z filtrów wyłapywania ramek (capture filter): ip6 and port 546. A.8 Odświeżanie adresów RENEW Pyt: Jak można odświeżać adresy? Odp: Wiadomościami RENEW lub REBIND. Polecenie dla studenta: Dodaj do poprzedniego pliku konfiguracyjnego wpisy powodujące okresowe odświeżanie adresów za pomocą pakietu RENEW. Proszę w Etherealu zademonstrować wiadomość RENEW, a także pokazać, gdzie ten parametr został przekazany. Wskazówka: Jakie timeouty występują w protokole DHCPv6? Który z nich powinieneś ustawić na niewielką wartość (kilka/kilkanaście sekund)? Czy nie zapomniałeś zrestartować usługi/demona?

164 Laboratorium: wersja dla prowadzącego Rady dla prowadzącego: Najprostszy konfig serwera nie zawierał czasów T1, zatem domyślnie przyjęto nieskończoność. Należy poprawić odpowiedni fragment konfiguracji serwera: iface eth0 { class { T1 15 pool 20::5:1-20:5:ffff } } W takiej konfiguracji co 15 sekund klient będzie generował RENEW. Opcja ta jest przykazywana w odpowiedzi REPLY na pakiet REQUEST, w opcji IA. Uwaga: Analogiczna opcja jest ustawiana w AD- VERTISE, ale ADVERTISE zawiera tylko parametry próbne przekazywane klientowi w celu oceny przytaności danego serwera. Wartość T1 jest powtarzana w każdym REPLY. Proszę pamiętać o każdorazowym zrestartowaniu serwera po zmianie pliku konfiguracyjnego. Przykładowy zrzut ekranu z wiadomością RENEW: Rysunek A.7: Ćwiczenie 1: Wiadomość RENEW z prośbą o odświerzenie adresu,

Laboratorium: wersja dla prowadzącego 165 Rysunek A.8: Ćwiczenie 1: Wiadomość REPLY z odświerzonym adresem A.9 Odświeżanie w przypadku problemów REBIND Pyt: Jak wygenerować wiadomość REBIND? Odp: Sposób 1: Wstrzymanie usługi pod Linexem (ctrl-z) Odp: Sposób 2: Wyciągnięcie wtyczki. Po przekroczeniu timeoutu T2 poleci REBIND. Polecenie dla studenta: Proszę skonfigurować usługi do generowania wiadomości REBIND, a następnie zademonstrować w Etherealu odświeżanie adresu za pomocą wiadomości REBIND. Proszę również pokazać, gdzie przekazywana jest wartość timeoutu odpowiedzialnego za transmisję REBIND. Wskazówka: Jaki timeout odpowiada za generowanie REBIND? Jak chcesz sprowokować jego przekroczenie? Wolisz metodę softwareową czy sprzętową? Rady dla prowadzącego: Kluczem do poprawnego przeprowadzenia ćwiczenia jest niedopuszczenie do odpowiedzi serwera na wysyłane RENEW. Można to osiągnąć rozłączając przewody łączące komputery lub wstrzymując działanie

166 Laboratorium: wersja dla prowadzącego demona (tylko gdy demon działa na konsoli, kombinacja ctrl-z, przywrócenie do działania: polecenie fg). Po przekroczeniu timeoutu T1 rozpoczyna się generowanie RENEW. W przypadku braku odpowiedzi i po przekroczeniu T2 zamiast RENEW generowane jest REBIND. Proponowany wpis w konfigu: iface eth0 { class { T1 10 T2 35 pool 20::5:1-20:5:ffff } } Zostaną wygenrowane 3 pakiety RENEW: po 10, 12, 16 i 24 sekundach (po osiągnięciu 10 sekund retransmisje co 2 n sekund). Potem zostanie przekroczone T2 i rozpocznie się generowanie REBIND. Wartość T2 jest poraz pierwszy przekazywana we wiadomości REPLY na wiadomość REQUEST (tak jak poprzednio, wartości podane w ADVERTISE służą tylko do oceny serwera przez klienta i nie są nigdzie używane). Zrzut ekranu demonstrujący przekazanie wartości T2 został przedstawiony na rysunku A.9. Zrzut ekranu demonstrujący wiadomość REBIND został przedstawiony na rysunku A.10. Proszę zwrócić uwagę na brak opcji SERVER-ID, obecną w RENEW. Pyt: Czym różni się RENEW od REBIND? Odp: RENEW kierowane jest do serwera (zawarta opcja SERVER-ID), który przyznał adresy. Jeżeli on nie odpowiada, to REBIND kierowane jest już ogólnie do wszystkich serwerów (brak opcji SERVER-ID). A.10 Zwalnianie adresu RELEASE Polecenie dla studenta: Proszę spowodować wygnerowanie pakietu RELEASE i pokazać ten fakt w Etherealu. Pyt: W jakich sytuacjach generowany jest pakiet RELEASE? Odp: Pakiet RELEASE generowany jest w momencie zamykania usługi. Pyt: Co się stanie w przypadku zaginięcia pakietu REPLY? Odp: W przypadku zaginięcia pierwszaj odpowiedzi, klient wykona retransmisję pakietu RELEASE, po otrzymaniu którego serwer wygeneruje odpowiedź REPLY z opcją STATUSCODE o wartości NOBIN- DING oznaczający, że dane adresy nie są już używane. Pyt: W jakim stanie znajduje się adres w systemie klienta przed otrzymaniem komunikatu REPLY, a po wysłaniu RELEASE? Odp: Adres musi zostać zdjęty z interfejsu przed wysłaniem RELEASE. Prawidłowa odpowiedź: w żadnym. Rady dla prowadzącego: Wiadomość RELEASE jest generowana przy zwalnianiu adresów, zwykle przy zamykaniu usługi. Przykładowy zrzut ekranu prezentujący tą wiadomość:

Laboratorium: wersja dla prowadzącego 167 Rysunek A.9: Ćwiczenie 3: Wiadomość REPLY jako odpowiedź na REQUEST z ustawioną warotścią T2

168 Laboratorium: wersja dla prowadzącego Rysunek A.10: Ćwiczenie 3: Wiadomość REBIND

Laboratorium: wersja dla prowadzącego 169 Rysunek A.11: Ćwiczenie 4: Wiadomość RELEASE A.11 Pytanie o opcje INFORMATION-REQUEST Pyt: DHCP to konfiguracja stateless czy statefull? Odp: W normalnym trybie (przyznawanie adresów) to statefull, jeżeli tylko INFORMATION-REQUEST, to stateless. Pyt: W jakich warunkach wykorzystywane jest INFORMATION-REQUEST, zamiast normalnego trybu? Odp: Kiedy klient ubiega się tylko o opcje, a nie o adresy. Jest to przypadek, w który DHCPv6 pracuje jako uzupełnienie protokołu Stateless Address Autoconfiguration. Polecenie dla studenta: Proszę wygenerować wiadomość INFORMATION-REQUEST, a jej zawartość zademonstrować w Etherealu. Wskazówka: Do czego służy opcja NO-IA?

170 Laboratorium: wersja dla prowadzącego Rady dla prowadzącego: Aby otrzymać wiadomość INOFRMATION-REQUEST, należy skonfigurować klienta, aby nie żądał żadnych adresów na danym interfejsie. Należy też podać jedną lub więcej z podanych opcji: DNS-Servers NTP-Servers Doamin TimeZone Przykładowy konfig klienta pytający o DNSy: iface eth0 { DNS-Servers 20::1 no-ia } Również serwer musi obsługiwać żądane opcje. Ze względu na to, że nie wiadomo z góry, jakich opcji zażąda klient, najlepiej skonfigurować je wszystkie. Przykładowy konfig serwera: iface eth0 { DNS-SERVER 20::1,20::2 NTP-SERVER 30::1,30::2 Domain pg.gda.pl Time-Zone EST class { pool 20::1:1-20::1:ffff } } Przykładowy zrzut ekranu prezentujący wiadomość INFORMATION-REQUEST:

Laboratorium: wersja dla prowadzącego 171 Rysunek A.12: Ćwiczenie 5: Wiadomość INFORMATION-REQUEST z opcją OPTION-REQUEST A.12 Wykrywanie zdublowanych adresów DECLINE Pyt: Skąd klient wie, że trzeba wysłać DECLINE? Odp: Stwierdza zduplikowany adres za pomocą procedury DAD (Duplicate Address Detection) z Neighbour Discovery (pakiety Neighbour Solicit, jeżeli przyjdzie odpowiedź Neighbour Advertisement, to mamy duplikat). Polecenie dla studenta: Proszę sprowokować wygenerowanie wiadomości DECLINE i w Etherealu prześledzić reakcję serwera i klienta. Proszę zademonstrować zarówno pakiet klienta, jak i potwierdzenie serwera, że adres zaznaczył adres jako zduplikowany. Wskazówka: Kiedy generowana jest wiadomość DECLINE? Jak zapewnić odrzucenie adresu przez klienta? Rady dla prowadzącego: Kluczem do poprawnego przeprowadzenia ćwiczenia jest sprowokowanie sytuacji, w której klient otrzyma