Ruting IP w Linuksie





1 Wstęp



1.1 O czym jest ten artykuł?
Tekst ten omawia większość nowości dotyczących obsługi sieci IP, które pojawiły się w jądrze Linuxa 2.2. Nie jest to vademecum dla osób początkujących ani HOWTO. Jego zadaniem jest zapoznanie z użytecznymi funkcjami osób zajmujących się ruterami działającymi na Linuxie i posiadających podstawowe pojęcie o działaniu protokołu IP.

1.2 Nowości w jądrze
Początki wielkich zmian w Linuxie, dotyczących protokołu IP, to koniec 1996 roku, kiedy pojawiła się wersja 2.1.17. Zawierała ona pierwszą wersje przepisanego praktycznie od nowa kodu obsługującego IP. Nowością była zgodność z RFC 1812 [12] i ruting rozszerzony (policy routing). Do konfiguracji nowych funkcji służy program iproute, potem pojawił się pakiet iproute2, zawierający program ip. Kolejne wersje jądra wprowadziły także mechanizmy sterowania przepływem danych (tra_c control), obsługiwane za pomocą ddzielnego programu tc i opisane w osobnym artykule 1. Rozwijanie tej części jądra Linuxa oraz pakietu iproute2 to przede wszystkim zasługa Aleksieja N. Kuźniecowa z moskiewskiego Instytutu Fizyki Jądrowej.

1.3 Nowości w iproute2
Obsługa iproute2 różni się zasadniczo od dotychczas stosowanych narzędzi { ifconfig i route. W programach tych adres IP oraz maska podsieci były podawane oddzielnie, przy czym ta ostania była tradycyjnie zapisywana w postaci aaa.bbb.ccc.ddd. Program ip przyjmuje natomiast maską podsieci w formacie skróconym aaa.bbb.ccc.ddd/nn, gdzie nn jest która określa się jako liczbe bitów jedynkowych w masce. Przykładowo, maska sieci C zapisywana tradycyjnie jako 255.255.255.0 ma 24 bity jedynkowe, podsieci 255.255.255.240 { 28 itp.
Wiąże się z tym także możliwość używania skróconych postaci adresów IP, gdzie brakujace bajty sa zastąpowane zerami. Przykładowo:
Notacja skrócona Notacja pełna
127/8 127.0.0.0/8
192.168/16 192.168.0.0/16
0/0 0.0.0.0/0
Należy podkreślić, że jest to notacja zgodna z _lozo_Ą CIDR ([2], [3]) oraz IPv6 i zalecana przez RFC 1812 ([12]), gdzie tradycyjną konstrukcją adresu IP (adres sieci, adres podsieci, adres hosta) zastępuje się przez adres prefiksu i adres hosta. W konsekwencji wyżej opisana notacja maski podsieci odpowiada po prostu długości prefiksu w bitach.

1.4 Konfiguracja adresów interfejsów
Każdy interfejs może posiadać więcej niż jeden adres IP. Dodatkowe adresy są po prostu adresami, różniącymi się od podstawowego adresu tylko agĄ secondary, a nie samodzielnymi pseudo_intefejsami, jak to było w jądrach 2.0 i wcześniejszych. Do ustawiania adresu intefejsu służy polecenie ip addr:
ip addr add ADRES dev INTERFEJS
[ ( peer | remote ) P-T-P ]
[ ( broadcast | brd ) BROADCAST ]
[ anycast ANYCAST ] [ label NAZWA ]
[ scope ZASI.G ]


Parametr ADRES jest adresem dodawanym do interfejsu. Należy zaznaczyc, ze w odróznieniu od programu ifconfig adresy IPv4 podaje sie; razem z maska podsieci jako aaa.bbb.ccc.ddd/nn. Adresy IPv6 podaje sie standardowo jako aa:bb:. . . :zz/nnn, gdzie /nnn to dlugosc prefiksu (maski podsieci).
Wprzypadku intefejsów point-to-point (na przyklad PPP) parametr ADRES okre- sla adres lokalny intefejsu, natomiast adres drugiego konca nalezy podac po parametrze peer (akceptowane jest równiez slowo remote).
Do ustawiania adresu rozgloszeniowego (broadcast) sluzy parametr broadcast (lub krócej brd). W nowych wersjach iproute parametr + spowoduje adresu obliczonego automatycznie na podstawie dlugosci prefiksu. Adres anycast stosowany w IPv6 ustawia sie parametrem anycast. 2 Zasieg adresu (scope) okresla sie parametrem scope, który moze byc jednym ze standardowych zasiegów, albo nazwe (lub numerem) zasiegu zdefiniowanego przez uzytkownika.
Interfejsowi mozna nadawac nazwy za pomoca parametru label, co jest przydatne w przypadku dodawania kolejnych adresów do interfejsu (eth0:1, eth0:2,...). W ten sposób do dodatkowych adresów mozna sie takze odwoływac za pomoca starszych wersji polecenia ifconfig.

2 Konfiguracja parametrów interfejsu


Dodanie adresu do interfejsu nie powoduje jego automatycznej aktywacji (aga UP) Jest to zachowanie odmienne od znanego z jader 2.0 Do kon_gurowania tego { i innych { parametrów intefejsu sluzy polecenie ip link:
ip link set INTERFEJS [ ( up | down ) ]
[ arp ( on | off ) ]
[ multicast ( on | off ) ]
[ ( txqueuelen | txqlen ) PKT ]
[ name NAZWA ]
_ Flagi up i down powoduja odpowiednio aktywacje lub deaktywacjŚ interfejsu. W momencie aktywacji interfejsu kernel dodaje do tablicy rutingu trasy kierujace na ten interfejs pakiety do sieci do niego przylaczonej. Jest ona umieszczana w specjalnej tablicy local. Warto zauwazyc, ze w jadrach 2.0 i wczesniejszych taka trase trzeba bylo dodac explicite za pomoca polecenie route, obecnie nie jest to juz konieczne.
_ Opcja arp włacza lub wyłącza protokól ARP dla danego interfejsu. Oznacza to, ze interfejs nie bedzie odpowiadac na pytania ARP, nawet jezli pytanie dotyczy jego adresu IP. 4
_ Opcja multicast włącza lub wyłącza obsluge pakietów multicast na danym interfejsie.
_ Parametr txqueulen (akceptowany jest skrót txqlen) okresla wielkosc kolejki wyjlciowej danego interfejsu w pakietach. Wielkosc ta jest ustawiana przez system automatycznie na podstawie domyslnej wartosci { innej dla kazdego rodzaju interfejsu { a zaleznej od jego przepustowosci. Z reguly ustawienie domyslne jest wystarczajace, jego zmiana moze byc czasem korzystna na przyklad do poprawienia wspóldzielenia wolnego łącza PPP.

3 Komunikacja hostów w obrebie sieci lokalnej



3.1 Wprowadzenie
W IPv4 informacja o adresie w warstwie łącza (link layer address) interfejsu posiadającego dany adres IP jest uzyskiwana za pomocą protokolu ARP (Address Resolution Protocol, RFC 826 [1]), korzystającego z rozglaszania w warstwie łącza i różniącego się implementacją dla kazdego rodzaju sieci fizycznej (ARP dla Ethernetu rózni sie od ARP dla ATM). W IPv6 sluzy do tego protokól wyszukiwania hostów sasiadujących (Neighbor Discovery), oparty o pakiety multicast i dzialajacy nad warstwa IP. Dokladny jego opis { oraz terminologie { mozna znalesc w RFC 2461 [6]. W zwiazku z tym, kernel tablica sasiednich hostów, przechowywana przez kernel, jest niezalezna od protokolu i zawiera informacje uzyskane albo za pomoca ARP albo za pomoca ND. Sluzy ona takze jako baza danych do wprowadzonego jako standard przez IPv6, ale dzialajacego takze dla IPv4, mechanizmu weryfikacji osiagalnosci hosta (Neighbor Unreachability Discovery).
Tablica sasiednich hostów zawiera nastepujace informacje: adres IP hosta, adres hosta w warstwie lacza (link layer address) oraz aktualny stan rekordu. Dodatkowo sa w niej przechowywane takie informacje jak ilosc odwolan do danego rekordu oraz czas ostatniego odwolania. Glówne stany rekordów to: incomplete (zaden host nie odpowiedzią na pytanie o dany adres), reachable (host jest osiagalny) oraz stale (host byl osiagalny, lecz rekord jest przeterminowany). Ponadto istnieja dwa stany specjalne: noarp (rekord nie jest uaktualniany przez ARP ani ND) oraz permanent (rekord dodany recznie przez administatora). Oba nie sa nigdy zmieniane przez kernel, nie jest w stosunku do nich uzywany ARP, ND ani NUD, a rekordy w stanie permanent nie sa usuwane podczas okresowego czyszczenia tablicy (garbage collecting).

3.2 Obsługa tablicy sąsiadów
Do manipulacji tablica zawierajaca informacje o adresach fizycznych hostów i odpowiadaj acych im adresach IP sluzy polecenie ip neigh:
ip neigh ( add | del )
(ADRES [ lladdr LLADDR ] | proxy PROXY )
[ nud ( permanent | noarp | stale | reachable ) ]
dev INTERFEJS
Polecenie ip neigh moze dodawac dwa typy rekordów do tablicy: _ Adres rzeczywisty Parametr ADRES jest wtedy adresem IPv4 lub IPv6, któ- rego rekord chcemy dodac lub usunac z tablicy hostów sasiadujacych. Adres warstwy lacza zwiazany z dodawanym adresem IP podajemy natomiast w parametrze lladdr. _ Adres Proxy ARP Parametr PROXY okresla adres IP hosta, dla którego dany interfejs ma posredniczyc w protokole ARP. Wiecej informacji o technice ÿProxy ARP", której nie bedziemy tutaj opisywac, mozna znalesc na przyklad w ÿNetwork Administrator's Guide" [10] w rozdziale Con_guring TCP/IP Networking, sekcja Checking the ARP Tables.

4 Ruting



4.1 Wstep.
W kernelach 2.0 byla tylko jedna podstawowa tablica rutingu. W kernelach 2.2 tablic tych moze byc do 250 zde_niowanych tablic, z czego domyslnie aktywne sa trzy: _ local (255) _ main (254) _ default (253) Tablica local zawiera trasy dodawane automatycznie przez kernel, takie jak trasy do lokalnych interfejsów oraz trasy broadcastowe. Trasy w tej tablicy maja z reguly zasieg host lub link. Tablica main odpowiada starej tablicy rutingu w kernelach 2.0 i do niej trafiaja trasy dodawane przez uzytkownika, jezli nie poda on innej tablicy. Do niej dodawane sa równiez trasy tworzone automatycznie przez kernel w momencie aktywacji interfejsu. Tablica default jest domyslnie pusta. Ponadto istnieje takze tablica cache, która jest tworzona automatycznie i traktowana w odmienny sposób niz wyzej wymienione tablice.Wszczególnosci, jej zawartosc jest uzupelniana automatycznie przez kernel i nie jest ona dostepna do zapisu przez uzytkownika. Jej zawartosc mozna natomiast przegladac, co jest opisane ponizej. Tablice sa przegladane w kolejnosci: local, main, default. Pozostale tablice nie sa przeszukiwane automatycznie, znajduja natomiast zastosowanie w rutingu rozszerzonym (policy routing). Zasady nazewnictwa poszczególnych tablic nieco sie zmienily w kolejnych wersjach iproute2. W chwili obecnej odwzorowanie nazw na numery tablic jest de_niowane w pliku /etc/iproute2/rt tables. Domyslnie znajduja sie tam wlasnie take nazwy jak powyzej, nic nie stoi jednak na przeszkodzie, by definiowac i dodawac wlasne.

4.2 Obsługa tablic rutingu.
Do operacji na tablicach tras sluzy polecenie ip route. Jego skladnia jest bardzo rozbudowana, wiec w tej sekcji ograniczymy sie tylko do omówienia glówych funkcji polecenia ip route. Dodawanie oraz usuwanie tras z tablicy odbywa sie za pomoca polecenia ip route add (lub del), którego argumentem jest specy_kacja trasy. W najprostszym przypadku sklada sie ona z adresu sieci docelowego oraz adresu rutera do tej sieci prowadza- cego (next hop). Ponizej ograniczymy sie do omówienia mniej lub bardziej typowych przypadków.
ip route add 192.168.2.0/24 via 192.168.1.1
Powyzsze polecenie dodaje do glównej tablicy rutingu trase prowadzaca do sieci 192.168.2.0/24 przez ruter o adresie 192.168.1.1.
ip route add 192.168.2.0/24
via 192.168.1.1 table default
Dodaje taka sama trase, ale do tablicy default.
ip route add 0/0 via 192.168.0.1
Dodaje trase domyslna (default) przez ruter 192.168.0.1. Warto zwrócic uwage na skró- towa forme zapisu sieci przeznaczenia 0.0.0.0/0, oznaczajacej trase domyslna i zapisanej skrótowo jako 0/0.
ip route add 10.1/16 via 192.168.1.1
src 10.2.2.1
Trasa, która to polecenie dodaje nie jest tak interesujaca jak wystepujacy w nim parametr src. Powoduje on, ze pakiety wychodzace z hosta ta trasa, beda mialy adres ustawiony jako 10.2.2.1. Dotyczy to tylko pakietów inicjowanych przez host lokalny (tj. przy polaczeniach wychodzacych).
Taka konfiguracja moze byc przydatna na przyklad jesli nasza siec jest podlaczona do kilku providerów (multi-homed) bez rutingu dynamicznego i chcemy by pakiety wysylane do jednego z nich wracaly ta sama trasa. W przeciwnym razie wracalyby one trasa podyktowana przez adres wynikajacy z adresu naszego glównego interfejsu.
ip route add unreachable 10.1.2/24 Specjalny rodzaj trasy. Pakiety kierowane do sieci docelowej 10.1.2.0/24 zostana odrzucone, a w odpowiedzi zostanie odeslany komunikat ICMP „Host unreachable". Dostepne sa takze inne tego rodzaju trasy: prohibit i blackhole. Pierwsza z nich zwraca pakiet „Packet administratively prohibited", a druga usuwa pakiet bez zwracania zadnej informacji. Trasy te mozna efektywnie wykorzystac przynajmniej na trzy sposoby:
_ Jako znacznie szybsze wersje czesci regulek filtrujacych firewall, co jest dokladniej opisane w rozdziale 6
_ Do translacji adresów (Network Address Translation) przez trase nat. Patrz rozdzial 5.3 .
_ Wykorzystanie trasy unreachable dla unikniecia petli rutingu powstajacych przy dynamicznie tworzonych interfejsach typu PPP.

5 Ruting rozszerzony



5.1 Wstep
W tradycyjnym modelu ruter dokonuje wyboru trasy tylko na podstawie adresu przeznaczenia pakietu. Kryteria wyboru trasy dla konkretnego pakietu, z kilku o róznym zasiegu, okresla RFC 1812 [12]. Na przyklad, jesli w tablicy rutingu znajduja sie dwie trasy { jedna na podsiec i druga na hosta w tej podsieci { to pierwsze«stwo bedzie miala trasa bardziej szczegółlowa, na hosta. Jest to tzw. regula najdluzszego dopasowania" trasy (longest match). Pozostale reguly wyboru tras przez ruter mozna znaleźc w sekcji 5.2.4.3 RFC 1812 [12].
Linux 2.2 spelnia wszystkie zdefiniowane przez ten dokument wymagania wobec ruterów internetowych. Poza podstawowymi funkcjami posiada on potezny mechanizm w postaci rutingu rozszerzoneg (policy routing).

5.2 Ruting rozszerzony
Routing rozszerzony pozwala na wybranie trasy wedlug wymienionych ponizej selektor ów, które moga byc laczone w dowolnych kombinacjach. Selektory te, jak widac, odpowiadaja poszczególnym polom pakietu IP:
Parametr Selektor
Adres źródlowy from
Adres docelowy to
Typ uslugi (Type of Service) tos
Interfejs z którego przychodzi pakiet iif
Oznakowanie nadane przez _rewall fwmark 6
Do kazdej regulki, bedacej grupa selektorów , przypisany jest priorytet (pref) oraz akcja. Priorytet okresla kolejność sprawdzania regulek { regulki o nizszym priorytecie sa sprawdzane wczesniej. Akcja jest to sposób w jaki zostanie potraktowany pakiet pasujacy do danej regulki. Dostepne sa nastepujace podstawowe akcje:
_ table TABLICA Pakiet jest kierowany wedlug tradycyjnego algorytmu wyboru trasy, na podstawie tablicy rutingu okreslanej identyfikatorem TABLICA. 8
_ nat SIEC/MM Adres źródlowy pakietu jest tlumaczony na adres z sieci podanej w parametrze SIEC. Poniewaz tlumaczenie jest w stosunku 1:1, wiec rozmiar nowej sieci okreslany maska MM musi byc taki sam jak rozmiar sieci tlumaczonej. Nalezy podkreslic, ze za pomoca rutingu rozszerzonego tlumaczy sie jedynie adresy źródlowe pakietów. Translacji w druga strone dokonuje sie za pomoca odpowiedniego wpisu w tablicy rutingu, co jest opisane w sekcji 5.3 .
_ unreachable, prohibit, reject Odrzucaja pakiety na rózne sposoby, analogicznie jak trasy specjalne opisane w sekcji 4.2 . _ realms
Nalezy pamietac o dwóch rzeczach. Po pierwsze, regulka nakazujaca przeszukiwanie tablicy local ma zawsze pierwszenstwo i nie jest mozliwe zmiana jej priorytetu. Z tego powodu nie beda dzialac regulki w których selektorem jest adres docelowy jednego z interfejsów danego hosta. Takie przypadki mozna jednak rozwiazac dodajac stosowna trase do tablicy local.
Po drugie, pierwszenstwo maja takze trasy znajdujace sie w tablicy cache. W zwiazku z tym, po dodaniu nowych regulek nalezy ta tablice wyczyscic poleceniem ip route flush table cache.

5.3 Translacja adresów
Linux umozliwia translacje adresów IP na dwa sposoby:
_ dynamicznie, w stosunku wiele do 1",
_ statycznie, w stosunku 1 do 1"
Pierwszy algorytm byl dostepny juz w Linuxie 2.0 jako maskowanie adresów (IP masquerading). Jest to zaawansowana funkcja, pozwalajaca na schowanie nawet bardzo duzej sieci komputerów posiadajacych adresy prywatne (zdefiniowane w RFC 1918 [4]) za ruterem maskujacym. Istnieje wiele opisów dzialania i konfiguracji maskowania adresów IP 7.
Linux 2.2 umozliwia takze statyczne tlumaczenie adresów w stosunku 1 do 1. Oznacza to, ze okreslonej podsieci adresów prywatnych musi byc przyporzadkowana podsiec adresów publicznych o tej samej wielkosci. NAT jest realizowany na poziomie tablicy rutingu oraz rutingu rozszerzonego. Tlumaczenie adresów źródlowych i docelowych konfiguruje sie oddzielnie.
Tlumaczenie adresów docelowych konfiguruje sie za pomoca polecenia ip route i polega ono na stworzeniu specjalnej trasy nat. Siec docelowa okresla zakres adresów, które maja byc tlumaczone, a adres rutera (via) jest pierwszym adresem z sieci na która maja byc tlumaczone adresy docelowe. Trasa ta musi znaleźć sie w tablicy local:
ip route add nat 192.168.1.0/24 via 195.116.211.0 table local
Tlumaczenie adresów zródlowych ustawia sie za pomoca odpowiedniej regulki rutingu rozszerzonego. W tym wypadku selektor from okresla siec, która ma byc tlumaczona, a akcja nat { adres pierwszego adresu sieci, na która maja byc tlumaczone adresy zródlowe.
ip rule add from 195.116.211.0/24 nat 192.168.1.0
Trzeba pamietac, ze translacja adresów skonfigurowana w ten sposób dziala wy- lacznie dla pakietów rutowanych przez dany system, czyli wchodzacych jednym interfejsem i wychodzacych innym. W szczególnosci nie obejmuje ona pakietów generowanych przez sam ruter, czyli na przyklad polaczen wychodzacych z tego rutera. Adres zródlowy takich połączen mozna zdefiniowac natomiast przy pomocy parametru src polecenia ip route, który jest opisany w rozdziale 4.2.

.

6 Optymalizacja


Podczas projektowania oraz konfiguracji ruterów, majacych obslugiwac duzy ruch nalezy brac pod uwage wydajnosc systemu oraz opóznienia powstajace podczas przeszukiwania duzych tablic rutingu lub dlugich list filtra pakietów. Generalnie, przeszukiwanie tablic rutingu jest znacznie szybsze niz przeszukiwanie regulek filtra. To pierwsze odbywa sie z pomoca funkcji haszujacych, podczas gdy drugie jest zwyklym przeszukiwaniem liniowym 8.

6.1 Filtrowanie za pomocą tablicy rutingu
Filtrowanie pakietów przy pomocy ipchains zuzywa wiecej czasu procesora niz przeszukiwanie tablic rutingu. Jesli jedynymi kryteriami filtrowania sa adresy zródlowe lub docelowe pakietów IP, to optymalniejsze bedzie skorzystanie ze specjalnej trasy prohibit (opisanej w sekcji 4.2, str. 7). Na przyklad, regulka ipchains:
ipchains -A input -d 192.168.0.0/24 -j REJECT
Mozna zastapic przez:
ip route add prohibit 192.168.0.0/24
W przypadku regulek odrzucajacych pakiety na podstawie adresu zródlowego nale zy skorzystac z rutingu rozszerzonego i polecenia ip rule add from.

6.2 Optymalizacja filtra pakietów
Czas przeszukiwania listy regulek filtra pakietów mozna zredukowac ukladajac je w odpowiedniej kolejnosci. Dla kazdego sprawdzanego pakietu lista jest przeszukiwana od poczatku az do pierwszej pasujacej do niego regulki.
Po pierwsze, przy pomocy zliczania pakietów nalezy okreslic które regulki maja najwiecej trafien i umiescic je na poczaatku listy.
Po drugie, w przypadku protokolu TCP mozna zaszczedzic czas przeszukujac tablice tylko dla pakietów rozpoczynajac polaczenie. Mozna to zrealizowac dodajac na poczatku listy regulke przepuszczajaca wszystkie pakiety dla protokolu :
ipchains -A forward -p tcp ! -y

6.3 Optymalizacja tablicy rutingu
Jesli tablica rutingu danego rutera posiada lub ma w zalozeniu posiadac wiecej niz 100 pozycji, to podczas konfiguracji kernela nalezy wlaczyc opcja CONFIG IP ROUTE LARGE TABLES
(Networking options, IP: Advanced router, IP: large routing tables). Spowoduje to przebudowanie struktur odpowiedzialnych za szybkie wyszukiwanie pozycji w tablicy podczas kazdego dodawania do niej nowych pozycji.

7 Dodatki



7.1 Zasiegi adresów
Zasieg (scope) mozna rozpatrywac w kontekscie adresów interfejsów oraz tras. Jako standardowy element protokolu IP zasieg adresu jest zdefiniowany jednoznacznie w IPv6 w RFC 2373 [8]. W adresie IPv6 zasieg determinuja pierwsze 4 bity adresu. I tak, adres IPv6 moze posiadac nastepujacy zasieg:
node{local
host{local Adres lokalny oznaczajacy ta sama maszyne, tak jak adresy z klasy 127/8 w IPv4. Adres ten jest nadawany interfejsowi lokalnemu i nie moze byc przesy- lany przez rutery.
link{local Adres lokalny, obowiazujacy wylacznie w sieci lokalnej, do której nalezy dany host. Kazdy host IPv6 musi posiadac taki adres, konfigurowany automatycznie przez system w momencie aktywacji interfejsu sieciowego. Istnienie adres ów typu link-local jest bardzo wygodne, poniewaz pozwala na komunikacje miedzy hostami lezacymi w jednej sieci lokalnej bez uprzedniego przydzielania i konfiguracji adresów.Woparciu o adresy link-local mozna takze tworzyc sieci prywatne, do których w IPv4 slużyly klasy wydzielone z publicznej puli adresów 11 (192.168/16 itp.). Pakiety z adresami o tym zasiegu nie mogl byc przekazywane przez rutery.
site{local Adres lokalny, obowiazujacy w ramach administratcyjnie okreslonej sieci prywatnej. Adresy o tym zasiegu nie sa konfigurowanie automatycznie i musz a byc zdefiniowane przez administratora sieci. Jednak pakiety z adresami site-local moga byc przekazywane przez rutery, co pozwala na tworzenie sieci prywatnych obejmujacych wiele segmentów LAN.
global Adresy publiczne.
W przypadku IPv4 jadro Linuxa równiez rozróznia zasiegi adresów, nie sa one jednak czescia standardu tylko raczej przeniesieniem wygodnej metody rozrózniania adresów z IPv6. Dla IPv4 jadro rozróznia nastepujace zasiegi:
host{local Odpowiednik zasiegu host--local w IPv6, zarezerwowany dla adresów z klasy 127/8.
link{local Odpowiednik zasiegu link--local w IPv6. W przypadku IPv4 zasieg ten jest nadawany adresowi warstwy lacza danego interfejsu, czyli np. adresowi MAC karty sieciowej w Ethernecie.
site{local Odpowiednik zasiegu site-local w IPv6. Poniewaz jednak rezerwacja okreslonych klas adresów IPv4 dla sieci prywatnych (RFC 1918 [4]) jest tylko umowna, zasieg site-local mozna nadac kazdemu adresowi, chociac sens ma nadawanie go tylko adresom z klas zarezerwowanych.
universe, global Adresy publiczne.
Mozliwe jest definiowanie wlasnych wartosci zasiegów. [11] podaje przyklad zasi egu dla tras wewnatrzsieciowych (interior), którym przypisuje sie wartosc zasiegu pomiedzy universe i link.
Wiecej informacji na temat zasiegów mozna znalezc w dokumentach RFC 2373 [8] , RFC 2374 [5] oraz RFC 2462 [7].

7.2 Wykorzystanie tras unreachable
Jezli mamy serwer dostepowy z pula modemów, na które poswiecamy Podsiec okreslonej wielkosci, to z reguly na glównym ruterze jest ustawiona trasa kierujaca pakiety do tej podsieci na adres serwera dostepowego.
Jesli dany modem jest zajety to odpowiadajacy mu adres IP posiada trase w tablicy rutingu, kierujaca pakiety do niego na przydzielony dynamicznie interfejs. Natomiast w momencie gdy jakis adres nie jest przydzielony wdzwaniajacemu sie klientowi, pakiet przeznaczony na dany adres IP zostanie skierowany wedlug trasy domyslnej i wróci do rutera. Ten z powrotem odbije go na serwer dostepowy, i tak az do wyczerpania czasu zycia (TTL) pakietu.
Jesli na serwerze dostepowym stworzymy trase unreachable dla danej podsieci z { co istotne { duza miare metric, to pakiety kierowane na nieaktywne w danym momencie adresy IP zostana odrzucone z komunikatem „Host unreachable", co bedzie zgodne z prawda.

7.3 Znakowanie pakietów
Nowy kod filtra pakietów Linuxa posiada przydatna funkcje znakowania pakietów pasuj acych do danej regulki. Oznakowanie jest liczbe 32{bitowa, której wartosc okresla parametr -m polecenia ipchains. Najprosciej opisac to na przykladzie. Tworzymy odpowiedni lancuch:
# ipchains -A forward -p tcp -d 192.168.1.1/32 25 -j ACCEPT -m 0x1234
# ipchains -vL forward
Chain forward (policy ACCEPT: 315108 packets, 107748450 bytes):
pkts bytes target prot tosa tosx mark source destination ports
0 0 ACCEPT tcp 0xFF 0x00 0x1234 anywhere 192.168.1.1 any -> smtp
Wszystkie pakiety wysylane na port 25 hosta 192:168:1:1 zostana przepuszczone (docelowy lancuch ACCEPT) oraz opatrzone znakiem 0x1234. Jak mozna wykorzystac takie oznakowanie? Jest to bardzo uzyteczny mechanizm, pozwalajacy na zmiane zachowania rutera (dzialajacego w warstwie sieci) wobec pakietu w zaleznocci od cech charakterystycznych dla protokolów warstwy transportowej. Czyli przede wszystkim numerów portów protokolów TCP oraz UDP, jak równiez typów pakietów ICMP. Mozna to wykorzystac przynajmniej na dwa sposoby:
_ W rutingu rozszerzonym, do kierowania róznymi trasami pakietów nalezacych do róznych protokolów, za pomoca parametru fwmark (patrz rozdzial 5.2, ).
_ W kontroli przeplywu danych, do przydzialu pasma oraz priorytetów w zalezno- sci od protokolu. Sluzy do tego filtr fw oraz odpowiednio zdefiniowane oznaczenia pakietów: identyfikatorowi przeplywu 1:1 odpowiada oznaczenie 0x10001, 2:3 { 0x20003 itd.

7.4 Weryfikacja adresów
Sekcja RFC 1812 [12] sugeruje, by rutery posiadaly mozliwosc wery_kacji, czy pakiet przychodzacy danym interfejsem posiada adres zródlowy z sieci, która jest przez ten interfejs rutowana.
Wyobrazmy sobie, ze dany ruter posiada dwa interfejsy eth0 i eth1. Pierwszy z nich jest wyjsciem na swiat i skierowana jest na niego trasa domyslna. Na drugi interfejs jest ustawiona trasa 195.116.2111.0/24, kierujaca do znajdujacej sie za tym ruterem sieci LAN. W normalnej sytuacji pakiet z adresem zródlowym z sieci 195.116.211.0/24 nie ma prawa pojawic sie na zewnetrznym interfejsie eth0. Pakiety z tej sieci moga bowiem byc generowane wylacznie w sieci lokalnej, znajdujacej sie za intefejsem eth1.
Ruter posiadajacy filtr zgodny z RFC 1812 powinien takie pakiety przechwytywac i kasowac. Z reguly sa one efektem blednej konfiguracji gdzies w odleglych zakatkach sieci lub { co gorsza { próby przeprowadzenia ataku przez sfalszowanie adresów IP (address spoofing).
W Linuxie weryfikacje adresów wlacza sie za pomoca interfejsu systcl, czyli zapisuj ac odpowiednia wartosc w pliku znajdujacym sie w systemie plików /proc. Sa dostepne dwa poziomy werydikacji { silniejsza, w pelni zgodna z RFC 1812 (wartosc 2) i slabsza, dotyczaca tylko sieci bezposrednio przylaczone do danego hosta (wartosc 1). By zupelnie wylaczyc weryfikacje adresów nalezy zapisac wartosc 0, tak jak w ponisszym przykladzie:
echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter
Weryfikacji adresów nie nalezy włączac w okreslonych wypadkach, kiedy moglaby ona w ogóle uniemożliwić łącznosc. Na przyklad, jesli ruting do jakiejs sieci jest asymetryczny (pakiety wchodza jednym interfejsem, wychodza innym).

7.5 Ograniczenia predkosci odpowiedzi ICMP
Linux 2.2 posiada mozliwosc ograniczenia predkosci wysylania na okreslone pakiety ICMP. Ma to na celu zmiejszenie przeciązenia sieci, zasobów rutera oraz ograniczenie ataków polegajacych na zalewaniu ofiary potokiem odpowiedzi na falszywy pakiet ICMP. Jest to funkcja zalecana przez RFC 1812 [12] w punkcie 4.3.2.8. W przypadku Linuxa limity okresla sie przez podanie minimalnego odstepu czasowego pomiedzy dwoma odpowiedziami ICMP okreelonego typu. Czas ten okreela sie w jifies, czyli podstawowej wewnetrznej jednostce czasu jadra Linuxa. W systemach opartych o procesory Intela i kompatybi
lne jest to 1=100 sekundy, a w przypadku procesorów Alpha { 1=1024 sekundy. Limitowaniu podlegaja nastepujace pakiety ICMP wyliczone ponizej wraz z odpowiadajacymi im pozycjami w sysctl:
_ Destination unreachable
/proc/sys/net/ipv4/icmp_destunreach_rate
_ Parameter problem
/proc/sys/net/ipv4/icmp_paramprob_rate
_ Time exceeded
/proc/sys/net/ipv4/icmp_timeexceed_rate
_ Echo reply
/proc/sys/net/ipv4/icmp_echoreply_rate
Wszystkie wyzej wymienione limity sa domyslnie ustawione na 1 sekunde, za wyjatkiem icmp_echoreply_rate, które ma wartosc 0 { czyli brak limitu. W praktyce dzialanie limitów objawia sie na przyklad brakiem odpowiedzi na jedna z próbek polecenia traceroute, jak w ponizszym przykladzie:
$ traceroute tau2
traceroute to tau2.ceti.com.pl (195.116.211.16), 30 hops max, 40 byte packets
1 tau2 (195.116.211.16) 0.282 ms * 0.256 ms