Internet - Protokoły

Protokoły internetowe

Najważniejsze protokoły internetowe

• DNS (Domain Name Service) konwersja adresu pomiędzy postaciami liczbowymi i domenowymi (używa TCP i UDP)
• FTP (File Transfer Protocol - Protokół Transferu Plików) służy do kopiowania plików pomiędzy komputerami w sieci (używa TCP)
• ICMP (Internet Control Message Protocol) kontrola statusu urządzeń w sieci, umożliwia dostrojenie parametrów transmisji i sterowanie przepływem danych pomiędzy ruterami
• IP (Internet Protokol - Protokół (Międzysieciowy) Internetowy) wysyłanie danych do węzłów w sieci, określa strukturę adresów internetowych i pakietów danych
• NFS (Network File System - Sieciowy System Plików) definiuje system plików umożliwiając ich współdzielenie przez wiele komputerów w sieci (używa UDP)
• TCP (Transfer Control Protocol - Protokół Kontroli Transferu) formowanie i przesyłanie danych z kontrolą ich poprawności; określa strukturę zabezpieczonego kanału komunikacyjnego pomiędzy aplikacjami internetowymi
• Telnet praca na zdalnym komputerze (używa TCP)
• TFTP (Trivial File Transfer Protocol - Uproszczony Protokół Transferu Plików), uproszczona wersja FTP; m.in. brak kontroli uprawnień użytkowników (używa UDP)
• SMTP (Simple Mail Transfer Protocol - Prosty Protokół Transferu Poczty) przesyłanie poczty (używa TCP)
• SNMP (Simple Network Management Protocol - Prosty Protokół Zarządzania Siecią) zarządzanie siecią, udostępnia dane o zdarzeniach w sieci
• UDP (User Datagram Protocol - Protokół Datagramu Użytkownika) przesyłanie danych bez kontroli poprawności dostarczenia ich do adresata zapewnia transport pakietów danych pomiędzy aplikacjami internetowymi ale bez gwarancji ich dostarczenia

W sieci komputery komunikują się za pośrednictwem urządzeń pośrednich, tzw. węzłów (ang. node lub hop)

Stos protokołów TCP/IP jest sposobem na połączenie niepodobnych do siebie systemów komputerowych. Istnieją dokładne wytyczne dotyczące sposobu ich implementacji. Dzięki ich restrykcyjności poszczególne stosy są kompatybilne i umożliwiają komunikację między różnymi systemami. Protokół jest rutowalny, dlatego umożliwia tworzenie rozległych sieci i daje pewność, że dane biegną optymalną drogą.

TCP/IP to wspólna nazwa dwóch podstawowych protokołów sieci Internet. Powstała oczywiście przez połączenie nazw TCP i IP. Udostępnia metody transmisji informacji pomiędzy poszczególnymi komputerami w sieci, obsługując pojawiające się błędy oraz tworząc wymagane do transmisji dodatkowe informacje.

TCP/IP zwane jest także stosem protokołów ze względu na strukturę warstwową i zastosowanie modelu OSI. Tymi warstwami dla modelu TCP/IP są:

• warstwa aplikacji (programów użytkowych)
• warstwa transportu
• warstwa sieci (warstwa intersieci, internet)
• łącza danych warstwa interfejsu sieciowego

Warstwa aplikacji

SMTP, FTP, TFTP, HTTP, POP3

Warstwa transportowa (TCP i UDP)

Jest długa lista usług, które mogą być opcjonalnie zapewniane na tym poziomie, żadna z nich nie jest obowiązkowa, ponieważ nie wszystkie aplikacje potrzebują wszystkich usług. Niektóre z nich są nadmiarowe lub mogłyby obniżać wydajność.

Musi zapewnić:

• Podstawowy transfer danych (basic data transfer) - Przesyła ciągi oktetów (8-bitowe porcje danych) w obu kierunkach transmisji. Oktety przed transmisją pakowane są w segmenty danych. Protokół sam decyduje czy blok danych należy wysłać, czy poczekać na jeszcze większą porcję. Czasem jednak użytkownik musi mieć pewność, że dane przesłane do protokołu TCP zostały wysłane do sieci (konkretnie do warstwy niższej, czyli IP) i nie są buforowane, wtedy wykorzystywana jest funkcja push powodująca wypchnięcie wszystkich oczekujących na transmisję danych - ale odbiorca nie otrzymuje żadnego znaku, że to ma miejsce i odbiera dane jak zwykły ciąg transmisji.

• Wiarygodność transmisji (reliability) - Ma za zadanie naprawić wszystkie błedy jakie mogły pojawić się w niższej warstwie. Musi zapewnić odzyskanie danych, które zostały zagubione, zniekształcone, zniszczone, zduplikowane, albo dostarczone w niewłaściwej kolejności. Każdy oktet otrzymuje swój unikalny numer sekwencyjny, dzięki czemu po odebraniu danych można je zebrać w odpowiedniej kolejności oraz wyeliminować duplikaty. Host odbierający musi potwierdzić odbiór segmentu przez wysłanie sygnału ACK (ang. acknowledgement - potwierdzenie), jeśli w określonym czasie komputer wysyłający nie otrzyma potwierdzenia odbioru nastąpi retransmisja danych; ewentualne uszkodzenie lub przekłamanie danych można wykryć dzięki zastosowaniu odpowiednich sum kontrolnych. Cały ten system zapewnia, że błędy w transmisji nie powinny mieć wpływu na poprawność przesyłanych danych. W przypadku bardzo złej jakości łączy dane w ogóle mogą zostać nie dostarczone, na to jednak nie ma rady.

• Kontrola przepływu (flow control) - Komputer odbierający może sterować ilością danych wysyłanych przez komputer źródłowy ponieważ wysyła z każdym sygnałem potwierdzającym (ACK) tzw. okna, które informuje komputer wysyłający ile jeszcze oktetów może wysłać przed otrzymaniem kolejnego pozwolenia. Ilość pamięci w każdym komputerze jest ograniczona i bez kontroli przepływu szybszy komputer mógłby zalać każdego hosta taką ilością informacji z jaką tamten mógłby sobie nie poradzić. Kontrola przepływu zapewnia regulację szybkości przesyłania danych. Czasem jest to zapewnione przez samą sieć, jeśli jednak nie to warstwa transportowa może może dodać tę funkcję.

• Multipleksowanie (multiplexing) - Ponieważ zwykle działa wiele programów, procesów, które potrzebują skorzystać z usług TCP/IP trzeba im umożliwić równoczesne korzystanie z sieci. W tym celu TCP udostępnia dodatkowy zbiór adresów (inaczej portów) przypisywanych konkretnym procesom. Porty są podstawowym sposobem na adresowanie do wielu jednostek w jednej lokacji, np. pierwsza linia adresu pocztowego jest rodzajem portu i rozróżnia pomiędzy różnymi mieszkańcami tego samego domu. Aplikacja będzie nasłuchiwała na informację na własnym porcie dzięki czemu można używać wielu aplikacji sieciowych w tym samym czasie. Numer takiego portu (jest to 16-bitowa liczba) w połączeniu z adresem sieci i hosta wziętymi z warstwy komunikacyjnej tworzy tzw. gniazdo (ang. socket), a para gniazd identyfikuje każde połączenie.

• Połączenia (connections) - Opisane powyżej mechanizmy wymagają najpierw zainicjowania a potem utrzymywania pewnych informacji statusowych dotyczących każdego przesyłanego strumienia danych. Kombinacja tych informacji (gniazda, numery sekwencyjne oraz wielkości okien) nazywana jest "połączeniem", każde z nich jest jednoznacznie identyfikowane przez dwa gniazda, po jednym na każdą ze stron. Kiedy dwa procesy mają zacząć komunikację, muszą najpierw nawiązać połączenie (czyli wymienić informację statusową) a po zakończeniu komunikacji połączenie jest zamykane w celu zwolnienia zasobów

• Dostarczenie w tej samej kolejności (same order delivery) - Warstwa sieciowa generalnie nie gwarantuje, że pakiety danych dotrą w tej samej kolejności w jakiej zostały wysłane, ale często jest to pożądana właściwość i zapewnia ją warstwa transportowa. Najprostszym sposobem na zrobienie tego jest danie każdemu pakietowi numeru i pozwolenie odbiorcy na powtórne zamówienie pakietów.

• Przetworzenie na strumień bajtów (byte orientation) - zamiast operowania na zestawach pakietów warstwa transportowa może umożliwić komunikację przez strumień bajtów.

TCP (Transmission Control Protocol)

TCP jest protokołem komunikacyjnym warstwy transportowej, zdefiniowanym w IETF RFC 793. Zapewnia wiarygodność transmisji (reliable-delivery), przesyła ciąg bajtów (byte-stream) i jest połączeniowym (connection-oriented) protokołem. Został stworzony przez Vintona Cerfa i Roberta Kahna w latach 70-tych w ramach projektu ARPANET.

Przekłada proces komunikacji z poziomu łatwego do użycia przez człowieka na poziom łatwy do użycia (transmisji) przez sieć.

Jest on częścią większej całości określanej jako stos TCP/IP. W modelu OSI TCP odpowiada warstwie transportowej. W zestawie protokołów internetowych TCP jest pośrednią warstwą pomiędzy leżącym poniżej IP i aplikacjami z wyższej warstwy, które często potrzebują wiarygodnej, połączeniowej (pipe-like) komunikacji - czego IP nie zapewnia, bo zajmuje się tylko przesyłaniem pakietów pomiędzy różnymi hostami.

Pierwsza specyfikacja powstała w 1974, była to opublikowana w IEEE Transactions praca "A Protocol for Packet Network Intercommunication". Trzy lata później, w lipcu 1977 odbył się eksperyment, w którym tego protokołu użyto do transmisji danych przez różne media (sieć ARPANET, Packet Radio i łącza satelitarne) na dużą odległość (USA - Anglia i z powrotem).

W pierwotnej wersji protokołu nie było rozróżnienia pomiędzy TCP i IP ale w trakcie eksperymentów nad przesyłaniem zakodowanego głosu okazało się, że retransmisja błędnych pakietów powoduje przerwy w odtwarzaniu dźwięku. Oddzielono więc protokół IP odpowiedzialny za adresowanie od TCP odpowiedzialnego za pakietowanie i oprócz TCP powstał UDP, w którym brak jest kontroli prawidłowości przesyłanych pakietów. W ten sposób transmisja danych została podzielona między dwie warstwy, z których jedna (IP) zajmuje się dostarczeniem ich do docelowego hosta poprzez różne rodzaje sieci, a druga (TCP lub UDP) komunikuje między sobą procesy na tych hostach.

TCP jest złożonym i rozwijającym się protokołem. Ale pomimo upływu czasu podstawowe zasady nie uległy większym zmianom od RFC 739 opublikowanego w 1981.

• RFC 739
• RFC 1122, Host Requirements for Internet Hosts - wyjaśnił wymagania wobec implementacji protokołu TCP.
• RFC 2581, TCP Congestion Control - opisuje uaktualnione algorytmy jakie powinny zostać użyte w celu uniknięcia nadmiernego przeciążenia.
• RFC 3168 (2001) opisuje ECM (Explicit Congestion Notification) mechanizm unikania przeciążenia.

Obecnie TCP jest używane w około 95% internetowych pakietów. Najpopularniejsze aplikacje używające TCP to m.in.: HTTP/HTTPS, SMTP/POP3/IMAP i FTP. W ciągu ostatnich lat znacznie wzrosła prędkość łączy sieciowych, protokół zaprojektowany dla powolnych sieci (kilka KBps) teraz musi przesyłać 1 Gbps. Implementacje wymagają więć znacznie wiecej mocy - 1 Gb komunikacji TCP pochłania 100% mocy procesora Pentium 2.4 GHz.

TCP używa pojęcia numerów portów, żeby zidentyfikować wysyłające i odbierające aplikacje. Każda strona połączenia ma skojarzony 16-bitowy numer portu przydzielony do wysyłającej lub odbierającej aplikacji. Oficjalnie uznanych jest 65535 portów. Podzielone są na trzy podstawowe kategorie:

dobrze znane:

przydzielone przez IANA, są zwykle używane na poziomie systemu lub procesów roota, dobrze znane aplikacje, które działają jako serwery lub pasywnie nasłuchują na połączenia używają właśnie tych portów; przykłady: FTP (21), Telnet (23), SMTP (25), HTTP (80)

zarejestrowane:

zwykle używane przez aplikacje końcowego użytkownika jako efemeryczne porty źródłowe podczas kontaktowania się z serwerami, ale mogą także identyfikować usługi, które zostały zarejestrowane przez trzecią stronę.

dynamiczne/prywatne:

mogą być także używane przez aplikacje użytkownika, ale jest to rzadsze; nie posiadają żadnego znaczenia poza konkretnym połączeniem TCP

W przeciwieństwie do UDP, TCP jest zorientowany na połączenie i zapewnia niezawodność, tworzy wiarygodne połączenie dla wyższych warstw komunikacyjnych przy pomocy sum kontrolnych i numerów sekwencyjnych pakietów, w celu weryfikacji wysyłki i odbioru. Brakujące pakiety są obsługiwane przez żądania retransmisji. Host odbierający pakiety TCP porządkuje je według numerów sekwencyjnych tak, by przekazać wyższym warstwom modelu OSI pełen, złożony segment. Protokół gwarantuje, że dane wysłane z jednego miejsca trafią do hosta docelowego w całości, bez utraty pakietów i we właściwej kolejności. Rozróżnia także dane skierowane do różnych aplikacji na tym samym komputerze. Posiada wbudowany mechanizm kontroli błędów, który naprawia błędy powstające w niższych warstwach, osiąga się to przez tworzenie odrębnych połączeń logicznych i zapewnienie, że wysyłane dane zostaną dostarczone do wyższych warstw we właściwej kolejności.

Aplikacje wysyłają strumienie bajtów do TCP w celu przesłania przez sieć. TCP dzieli te strumienie bajtów na segmenty odpowiedniej wielkości zwykle określonej przez rozmiar największej jednostki transmisji - MTU (maximum transmission unit) poziomu łącza danych sieci, do której podłaczony jest komputer.

Rozmiar okna TCP

U odbierającego TCP jest to ilość otrzymywanych danych (w bajtach) która może być buforowana w czasie połączenia. Wysyłający host może wysłać tylko taką ilość danych zanim nie musi poczekać na potwierdzenia i uaktualnienie okna odbierającego hosta. Okno stosu TCP/IP jest zaprojektowane do samodostrojenia się w większości środowisk i używa większych domyślnych rozmiarów okien niż we wcześniejszych wersjach. Skalowanie okien: dla bardziej wydajnego użycia przepustowości sieci może zostać użyty większy rozmiar okna TCP. Pole okna TCP kontroluje przepływ danych i jest ograniczone do 2 bajtów lub rozmiaru okna 65535 bajtów. Ponieważ wielkość tego okna nie może być zwiększona używany jest czynnik skalowania - jest to opcja używana do zwiększania maksymalnego rozmiaru okna z 65535 bajtów do 1 GB. Stosowane tylko w czasie potrójnego uścisku dłoni TCP. Wartość skali okna reprezentuje ilość bitów przesunięcia w lewo 16-bitowego pola rozmiaru okna, może mieć wartość od 0 (brak przesunięcia) do 14.

Potem TCP przekazuje pakiety do IP w celu przekazania przez internet do modułu TCP jednostki na drugim końcu połączenia. TCP nadaje każdemu bajtowi kolejny numer używany dla upewnienia się, że żadne pakiety nie zostały utracone, że dane zostały dostarczone we właściwej kolejności oraz, że nie są zduplikowane. Moduł TCP na drugim końcu odsyła potwierdzenia dla bajtów, które zostały odebrane pomyślnie. Zegar (timer) wysyłającego TCP określa limit czasu oczekiwania (timeout) - jeśli potwierdzenie nie zostało odebrane w przewidywanej ilości cyklów podróży i (przypuszczalnie utracony/zagubiony) dane będą wtedy retransmitowane. Zapewnia to wykrycie i dostosowanie się do utraty lub opóźnienia. TCP sprawdza czy żadne bajty nie zostały zniszczone używając sum kontrolnych - jedna jest wyliczana na komputerze wysyłającym dla każdego pakietu danych przed wysłaniem i sprawdzana u odbiorcy.

W czasie fazy ustanowienia połaczenia TCP pomiędzy dwoma modułami TCP wymieniane są numery sekwencji począkowej (ISN - initial sequence numbers). Te numery sekwencji są używane do identyfikacji danych w strumieniu bajtów i są numerami, które identyfikują (i liczą) bajty danych aplikacji. Zawsze jest para numerów sekwencji włączonych w każdy segment TCP, które są określane jako numer sekwencji i numer potwierdzenia. Wysyłający TCP odnosi się do swojego własnego numeru sekwencji jako numer sekwencji, a do numeru sekwencji odbierającego jako numer potwierdzenia. Aby zapewnić wiarygodność odbiorca potwierdza segment danych przez wskazanie, że został przyjęty do pewnego miejsca w strumieniu bajtów. Rozszerzenie TCP nazwane selektywnym potwierdzeniem (SACK) pozwala odbierającemu na potwierdzenie popsutych bloków. Dzięki użyciu sekwencji i numerów potwierdzeń TCP może we właściwy sposób dostarczyć otrzymane segmenty we właściwym strumieniu bajtów do aplikacji. Numery sekwencji są to 32-bitowe niepodpisane numery, które wracają do zera w następnym bajcie w strumieniu po 232-1. Wybór ISN jest podstawowym mechanizmem bezpieczeństwa TCP.

16-bitowa, suma kontrolna jest wyliczana przez nadawcę i włączana w transmisje segmentów. Suma TCP pokrywa także 96-bitowy pseudonagłówek zawierający adres źródłowy, adres przeznaczenia, protokół i długość TCP. To zabezpiecza przed błędnie rutowanymi segmentami. Jest jak na współczesne standardy dość słabe zabezpieczenie. Warstwa łącza danych z wysokim prawdopodobieństwem stopnia błędu bitów może wymagać dodatkowych możliwości wykrycia i naprawy błędu łącza. Słabość sumy jest częściowo kompensowana przez powszechne użycie CRC lub lepszą kontrolę na warstwie 2 poniżej TCP i IP - tak jak jest użyte w ramce PPP lub Ethernetu. Jednakże nie znaczy to wcale, że 16-bitowa suma kontrolna TCP jest redundantna. Badania ruchu internetowego pokazały, że programowe i sprzętowe błędy są pomimo tych zabezpieczeń powszechne, a 16 bitowa suma nagłówka TCP wychwytuje tylko większość z nich.

Procedura nawiązania połączenia ponieważ zawiera trzy fazy nazywana jest potrójnym uściskiem dłoni (ang. three-way handshake), jest to sposób na nawiązanie sesji. Ma ona na celu synchronizację wysyłania i odebrania segmentu danych, informowania drugiego hosta o rozmiarze paczki (okna) danych, które jesteśmy w stanie odebrać, oraz utworzenie wirtualnego połączenia w sieci.

1. Ustanowienie połączenia - inicjalizowane są parametry takie jak numery sekwencji, by można było zapewnić odpowiednią sprawność połączenia; chociaż zainicjowanie połaczenia równocześnie jest możliwe dla pary końcowych hostów, zazwyczaj jeden koniec otwiera gniazdo i biernie nasłuchuje na połączenie z drugiego - jest to powszechnie określane jako bierne/pasywne otwarcie i wyznacza stronę serwera w połączeniu
2. Strona klienta inicjuje aktywne połączenie wysyłając inicjujący segment SYN do serwera; jeśli to host inicjuje połączenie wysyła pakiet zawierający segment TCP z ustawioną flagą SYN (Synchronize).
3. Host (serwer) odbierający połączenie powinien odpowiedzieć na prawidłowe żądanie SYN przez SYN/ACK - odsyła pakiet z ustawionymi flagami SYN i ACK (Acknowledge - potwierdzenie).
4. Na końcu inicjujący host (klient) powinient eraz wysłać pierwszą porcję danych, ustawiając już tylko flagę ACK (gasząc SYN). Odpowiedź ACK kończy trzystopniowy uścisk dłoni i fazę ustanowienia połączenia. Jeśli host odbierający połączenie nie chce lub nie może odebrać połączenia, powinien odpowiedzieć pakietem z ustawioną flagą RST (Reset).
5. Transfer danych
6. Zakończenie połączenia - używa poczwórnego uścisku dłoni, przy czym każda strona może zacząć niezależnie, typowe przerwanie połączenia (teardown) wymaga pary segmentów FIN i ACK z każdego końca TCP

Potwierdzenia dla wysłanych danych lub brak potwierdzeń są używane przez wysyłąjącego do pośredniego wnioskowania o stanie sieci pomiędzy wysyłającym a odbierającym. Dzięki użyciu zegara (timer) wysyłający i odbierający mogą zmieniać zachowanie strumienia danych, jest to nazywane jest kontrolą strumienia, przeciążenia i/lub unikaniem przeciążenia. TCP używa pewnych mechanizmów by osiągnąć wysoką wydajność i uniknąć przeciążenia sieci (np. przez wysyłanie danych szybciej niż odbierający może je przyjąć), te mechanizmy to: użycie przesuwanego okna, algorytm powolnego startu, algorytm unikania przeciążenia, algorytm szybkiej retransmisji i szybkiego odzyskania i inne.

Aplikacje, w których zalety TCP przeważają nad wadami (większy koszt związany z utrzymaniem sesji TCP przez stos sieciowy) to między innymi HTTP, SSH, FTP czy SMTP/POP3 i IMAP4. Jednakże dla wielu aplikacji TCP nie jest właściwym rozwiązaniem. Nowsze protokoły warstwy transportowej są projektowane i wdrażane by zminimalizować wady komunikacji bezpołączeniowej. Dla przykładu niektóre aplikacje czasu rzeczywistego nie potrzebują takiej kontroli wiarygodności transmisji i łatwiej sobie radzą ze stratami danych. Przykładowe aplikacje tego typu to: streaming czasu rzeczywistego (np. radio internetowe), wieloosobowe gry czasu rzeczywistego i VoIP. W wielu przypadkach kiedy wymagany jest tylko multipleksing usług właściwszym wyborem będzie UDP.

UDP (User Datagram Protocol)

Wszystkie implementacje TCP/IP muszą również wspierać prostszy protokół.

UDP jest minimalnym protokołem warstwy transportowej zorientowanym na wiadomość; udokmentowanym w IETF RFC 768. UDP często jest używany w aplikacjach działających na zasadzie żądanie - odpowiedź, lub kiedy transmisja skierowana jest do wszystkich urządzeń w danym segmencie (broadcast) lub do pewnej grupy urządzeń (unicast) - użycie w takim przypadku TCP spowodowałoby nadmiar niepotrzebnych informacji. Prośba o retransmisję segmentu danych jest zupełnie nieprzydatna w aplikacjach działajacych w czasie rzeczywistym.

Został zaprojektowany tak aby jego implementacja była możliwie najprostsza. Nie zapewnia kontroli dostarczenia datagramu ani nie sprawdza czy nie wystąpiły błędy transmisji.

W modelu TCP/IP UDP zapewnia bardzo prosty interfejs pomiędzy siecią leżącą poniżej a aplikacją z wyższych warstw. UDP nie gwarantuje dostarczenia wiadomości i wysłający UDP nie zachowuje stanu wiadomości UDP już wysłanych do sieci (i z tego powodu czasem skrót UDP jest rozwijany do "Unreliable Datagram Protocol".) UDP umożliwia tylko multipleksowanie i sprawdzanie sum kontrolnych na szczycie datagramu IP.

Nagłówek UDP zawiera tylko 4 pola, z czego dwa są opcjonalne: porty źródłowy i przeznaczenia są 16 bitowymi polami, które identyfikują proces wysyłający i odbierający. Ponieważ UDP jest bezstanowe i wysyłający UDP może nie zwracać odpowiedzi port źródłowy jest opcjonalny (jeśli nie jest ustawiony powinien być ustawiony na zero). Po polach portów są pole o określonej długości określone jako bajty datagramu UDP zawierające dane, minimalna wartość długości pola jest 8 (oktetów). Pozostałe pole nagłówka jest 16 bitową sumą kontrolną obejmującą nagłówek i dane, która również jest opcjonalna, ale prawie zawsze używana.

Ponieważ nie zapewniające wiarygodności transmisji aplikacje UDP muszą pogodzić się z pewną ilością utraconych, zduplikowanych i błędnych pakietów, niektóre aplikacje takie jak TFTP mogą dodać jakieś podstawowe mechanizmy wiarygodności w warstwie aplikacji jeśli jest to potrzebne. Ale najcześciej aplikacje UDP nie tylko nie wymagają mechanizmu wiarygodności, ale takie mechanizmy by im przeszkadzały. Media strumieniowe, wielosobowe gry czasu rzeczywistego i VoIP są przykładami takich aplikacji, które często używają UDP.

Brak unikania przeciążenia i mechanizmów kontroli powoduje, że konieczne są oparte na sieci mechanizmy, które by zapobiegły przeciążeniu sieci przez niekontrolowany napływ pakietów UDP. Ponieważ wysyłający UDP nie jest w stanie wykryć przeciążenia potrzebne są oparte na sieci elementy takie jak rutery używające kolejkowanie pakietów i techniki porzucania, które będą czasem jedynym narzędziem które zmniejszy ruch UDP. DCCP (Datagram Congestion Control Protocol) jest zaprojektowany jako częściowe rozwiązanie tego potencjalnego problemu poprzez dodanie kontroli przeciążenia końcowego hosta dla szybkich strumieni UDP takich jak media strumieniowe.

Chociaż całkowita ilość ruchu UDP w przeciętnej sieci nie przekracza kilku procent - tego protokołu używa duża liczba aplikacji: DNS, SNMP (simple network management protocol), DHCP, RIP (Routing Information Protocol).

Warstwa internetowa (IP i ICMP)

IP (Internet Protocol)

IP jest zorientowanym na dane protokołem używanym do przesyłania danych pomiędzy hostem źródłowym a przeznaczenia poprzez sieć pakietów kumutowanych (packet-switched internetwork). Dane w międzysieci IP są wysyłane w blokach nazywanych pakietami lub datagramami (te terminy są w zasadzie synonimami w IP).

IP zapewnia usługi datagramu bez wiarygodności (nazwane czasem "best effort", czyli najlepszych starań) tzn. nie daje gwarancji co do pakietów, które mogą dotrzeć zniszczone, w zmienionym porządku, zduplikowane lub całkiem porzucone. Jeśli więc aplikacja wymaga wiarygodności musi go zapewnić innymi sposobami.

Przełączniki pakietów lub międzysieciowe rutery przekazują datagramy IP poprzez dwie połączone sieci. Brak mechanizmów zapewniających gwarancjię dostarczenia, powoduje, że ten mechanizm jest prosty. Choć jeśli sieć porzuca, zmienia porządek lub w jakiś inny sposób psuje dużą ilość pakietów, efekt otrzymany przez użytkownika będzie kiepski.

IP jest powszechnym elementem sieci, obecnie najpopularniejszym protokołem warstwy sieci jest IPv4, którego adresy się kończą i nastąpi zmiana na IPv6. Wersje 0 do 3 były zarezerwowane lub nieużywane, wersja 5 była używana dla ekperymentalnego protokołu strumieniowego. Inne numery zostały przydzielone zwykle dla eksperymentalnych protokołów ale nie były zeroko stosowane.

Adresowanie i rutowanie jest prawdopodobnie najbardziej złożonym aspektem IP. Adresowanie odnosi się do tego jak końcowym hostom przydziela się adresy IP i jak podsieci adresów IP są podzielone i grupowane razem. Ruting IP jest wykonywany przez wszystkie hosty, ale najważniejszy przez rutery międzysieciowe, które zwykle używają IGPs (interior gateway protocols) lub EGPs (external gateway protocols), umożliwiających przekazywanie pakietów przez połączone sieci.

Protokół IP pracuje w warstwie 2 modelu DoD, ale jego funkcjonalność odpowiada warstwie 3 modelu OSI. Przynależność do tej warstwy sprawia, że jest bezpołączeniowy, nie jest w stanie rozpoznać, które pakiety powinny zostać retransmitowane w przypadku wystąpienia błędu, ani nie zajmuje się ustawieniem pakietów w kolejności.

IPv4

Aktualnie obowiązującą wersją IP jest IPv4. Zawsze kiedy mowa o tym protokole bez uwzględnienia wersji chodzi właśnie o IPv4. Opisany jest w IETF RFC 791, opublikowanym we wrześniu 1981. IPv4 był pierwszą szeroko stosowaną wersją tego protokołu i tworzy większość współczesnego internetu. Obecnie używany protokół IP wykorzystuje 32 bitowy achemat adresowania, który umożliwia identyfikację sieci i urządzeń do niej podłączonych.

Ponieważ ilość dostępnych adresów IPv4 jest na wyczerpaniu zostanie zamieniony na następną wersje, którą jest - zachowującą wsteczną kompatybilność - IPv6. Znacznie zwiększa możliwości adresowania i jest gotowa do wdrożenia, jednak przez najbliższe lata IP będzie oznaczało po prostu IPv4.

Adresowanie: W wersji 4 adres IP ma 32 bity co teoretycznie daje ponad 4 miliardy (4,294,967,296) unikalnych hostów. Jednak w praktyce przestrzeń adresowa jest znacznie mniejsza stąd więc rosnąca potrzeba zmiany na IPv6. Wiele z adresów jest zarezerwowanych do specjalnych celów takich jak sieci lokalne lub adresy multicastowe. Adres IP jest najczęście wyrażony w postaci "kropkowo dziesiętnej" (dotted decimal): cztery oktety podzielone przez kropki. Np. host znany jako wikipedia.org ma w rzeczywistości numer 3482223596, zapisany jako 207.142.131.236: 3482223596 równa się 207x2563 + 142x2562 + 131x2561 + 236x2560.

Rozwiązanie nazwy domenowej np. "www.isoc.org.pl" do właściwego numeru IP jest zadaniem, które wykonuje DNS.

Historycznie adresy IP miały tylko dwie części, późniejsze zmiany zmieniły to na trzy części: sieć, podsieć i hosta, jednakże powszechne zastosowanie CIDR zmieniło ten stan rzeczy i adres może mieć dowolną liczbę poziomów hierarchii Technicznie to było zawsze możliwe z pojawieniem się podsieci, ponieważ witryna mogła zawierać więcej niż jedną warstwę podsieci.

Sposoby zapisu: adresy IPv4 są zapisywane w formacie:

• Kropkowo dziesiętnym (Dotted Decimal) - najczęściej używany

207.142.131.235

• Kropkowo heksadecymalny (Dotted Hexadecimal):

0xCF.0x8E.0x83.0xEB

• Kropkowo oktalny (Dotted Octal)

0317.0216.0203.0353

• dziesiętny (Decimal):

3482223595

• heksadecymalny (Hexadecimal)

0xCF8E83EB

Powyższe adresy działają w większości przeglądarek i wskazują na wikipedia.org.

Fragmentacja i powtórne złożenie. IPv4 umożliwia zastosowanie elementów sieci (np. łączy punkt-punkt) używających pakietów o małych rozmiarach. Zatosowanie fragmentacji i złożenia na lokalnym łączu wymagałoby od rutera na drugim końcu zebrania oddzielnych kawałków i złożenia pakietu (skomplikowany proces szczególnie jeśli pakiety się gubiły by na skutek błędów na łączu). Ruter, który wykrywa, że pakiet jest za duży by zmieścić się na następnym łączu i pozwala na podzielenie go na fragmenty (oddzielne pakiety IPv4, z których każdy będzie zawierał część danych oryginalnego pakietu IPv4) dzieli go przy użyciu standardowych procedur, które pozwalają hostowi docelowemu złożyć pakiet z fragmentów, po tym jak je oddzielnie odebrał. Kiedy duży pakiet IPv4 jest podzielony na mniejsze (co zwykle, ale nie zawsze ma miejsce na ruterze gdzieś na drodze do przeznaczenia), to wszystkie fragmenty są normalnymi pakietami IPv4, np. mają pełen nagłówek IPv4. Porcja danych oryginalnego pakietu jest podzielona na mniejsze, które są dość małe (łącznie z nagłówkiem) by przejść do następnego łącza i w każdym fragmencie znajduje się jeden segment oryginalnych danych. Prawie wszystkie pola nagłówka mają takie same wartości jak w oryginalnym pakiecie, a w szczególności mają identyczną wartość pola identyfikacji. Różnice:

• pole całkowitej długości będzie mniejsze, bo dostosowane do rozmiaru każdego z fragmentów
• flaga pojedynczego bitu "more fragment" będzie ustawiona na 1 za wyjątkiem ostatniego fragmentu
• pole "fragment offset" będzie niezerowe we wszystkich oprócz pierwszego fragmentu

Czyli pakiet jest sfragmentowany jeśli w miejscu przeznaczenia w którymś z przychodzących pakietów:

• flaga pojedynczego bitu "more fragments" jest ustawiona jeden
• lub pole "fragment offset" jest niezerowe

Żeby złożyć fragmenty z powrotem w oryginalny pakiet w miejscu przeznaczenia, host szuka przychodzących pakietów z tą samą wartością pola identyfikacji, wszystkie należą do tego samego oryginalnego pakietu. Pola offsetu i całkowitej długości wskazują gdzie jest miejsce każdej części oraz jaką cześć oryginalnego pakietu zawiera. Może to funkcjonować niezależnie od całkowitej wielkości oryginalnego pakietu. Dla pakietu z czystą flagą "more fragments", wartość pola wielkości w tym pakiecie plus wartość pola offsetu daje całkowitą długość oryginalnego pakietu.

Ruter może powtarzać proces fragmentacji, nawet jeśli ma pojedynczy fragment (np. ostatni ruter po drodze) - dzieli go w taki sam sposób dzieląc na dwa lub więcej nowych fragmentów i dodając właściwe pola offsetu i całkowitej długości. Jedyną komplikacją jest jeśli flaga "more fragments" jest ustawiona na zero, potrzebuje je ustawić na jeden za wyjątkiem ostatniego fragmentu (jest to względnie proste ustawić proces tak, żeby ruter nie potrzebował wiedzieć czy dzieli oryginalny pakiet czy już fragment)

Jeśli pakiet jest sfragmentowany i niektóre z fragmentów zostały stracone, wtedy w całości jest retransmitowany z tym samym numerem identyfikacyjnym i ta druga kopia również jest fragmentowana (z możliwością utraty niektórych fragmentów). Wtedy fragmenty z drugiej kopii mogą zostać użyte do wypełnienia dziur w pierwszym.

Rzeczywisty przydział pakietów nie jest arbitralny, organizacja - zazwyczaj ISP - żąda przydzielenie bloku numerów z rejestru takiego jak np. American Registry for Internet Numbers (ARIN). Numer sieci zawiera zasięg adresów, które organizacja ma do dyspozycji i jeśli wyczerpie znaczącą ilość przestrzeni adresowej, może zażądać następnego bloku numerów. Na przykład ARIN alokował adresy 64.78.200.0 do 64.78.207.255 dla Verado, Inc. Verado alokowało adresy 64.78.205.0 do 64.78.205.15 dla Bomis. Bomis przydzielił konkretny adres 64.78.205.6 dla interfejsu hosta nazwanego www.wikipedia.com.

Na styczeń 2005, niektóre duże bloki przydziału zawierają: Klasa A

• [Organization] [Block]
• Internet Assigned Numbers Authority 0.0.0.0 - 2.255.255.255
• General Electric 3.0.0.0 - 3.255.255.255
• Level 3 Communications 4.0.0.0 - 4.255.255.255
• Internet Assigned Numbers Authority 5.0.0.0 - 5.255.255.255
• Department of Defense Network Information Center 6.0.0.0 - 7.255.255.255
• Level 3 Communications 8.0.0.0 - 8.255.255.255
• IBM 9.0.0.0 - 9.255.255.255
• Internet Assigned Numbers Authority 10.0.0.0 - 10.255.255.255
• Department of Defense Network Information Center 11.0.0.0 - 11.255.255.255
• AT&T WorldNet Services 12.0.0.0 - 12.255.255.255
• Xerox Palo Alto Research Center 13.0.0.0 - 13.255.255.255
• Internet Assigned Numbers Authority 14.0.0.0 - 14.255.255.255
• Hewlett-Packard Company 15.0.0.0 - 15.255.255.255
• Digital Equipment Corporation 16.0.0.0 - 16.255.255.255
• Apple Computer, Inc. 17.0.0.0 - 17.255.255.255
• Massachusetts Institute of Technology 18.0.0.0 - 18.255.255.255
• Ford Motor Company 19.0.0.0 - 19.255.255.255
• Computer Sciences Corporation 20.0.0.0 - 20.255.255.255
• Department of Defense Network Information Center 21.0.0.0 - 22.255.255.255
• Internet Assigned Numbers Authority 23.0.0.0 - 23.255.255.255
• Various U.S. Cable Networks 24.0.0.0 - 24.255.255.255
• Royal Signals and Radar Establishment 25.0.0.0 - 25.255.255.255
• Department of Defense Network Information Center 26.0.0.0 - 26.255.255.255
• Internet Assigned Numbers Authority 27.0.0.0 - 27.255.255.255
• Department of Defense Network Information Center 28.0.0.0 - 30.255.255.255
• Internet Assigned Numbers Authority 31.0.0.0 - 31.255.255.255
• AT&T Global Network Services 32.0.0.0 - 32.255.255.255
• Department of Defense Network Information Center 33.0.0.0 - 33.255.255.255
• Halliburton Company 34.0.0.0 - 34.255.255.255
• Merit Network, Inc. 35.0.0.0 - 35.255.255.255
• Internet Assigned Numbers Authority 36.0.0.0 - 37.255.255.255
• Performance Systems International, Inc. 38.0.0.0 - 38.255.255.255
• Internet Assigned Numbers Authority 39.0.0.0 - 39.255.255.255
• Eli Lilly and Company 40.0.0.0 - 40.255.255.255
• Internet Assigned Numbers Authority 41.0.0.0 - 42.255.255.255
• Japan Inet 43.0.0.0 - 43.255.255.255
• Amateur Radio Digital Communications 44.0.0.0 - 44.255.255.255
• Interop Show Network 45.0.0.0 - 45.255.255.255
• Internet Assigned Numbers Authority 46.0.0.0 - 46.255.255.255
• Bell-Northern Research 47.0.0.0 - 47.255.255.255
• Prudential Securities Inc. 48.0.0.0 - 48.255.255.255
• Internet Assigned Numbers Authority 49.0.0.0 - 50.255.255.255
• Department of Social Security of UK 51.0.0.0 - 51.255.255.255
• E.I. DuPont de Nemours and Co., Inc. 52.0.0.0 - 52.255.255.255
• Cap debis ccs (Mercedes-Benz) 53.0.0.0 - 53.255.255.255
• Merck and Co., Inc. 54.0.0.0 - 54.255.255.255
• Department of Defense Network Information Center 55.0.0.0 - 55.255.255.255
• United States Postal Service 56.0.0.0 - 56.255.255.255
• SITA - Société Internationale De Telecommunications Aeronautiques 57.0.0.0 - 57.255.255.255
• Asia-Pacific Network Information Centre (APNIC) 58.0.0.0 - 61.255.255.255
• RIPE Network Coordination Centre 62.0.0.0 - 62.255.255.255
• UUNet Technologies, Inc. 63.0.0.0 - 63.127.255.255
• Internet Assigned Numbers Authority 73.0.0.0 - 79.255.255.255
• RIPE Network Coordination Centre 80.0.0.0 - 80.255.255.255

Część prywatnej przestrzeni adresowej została alokowana w RFC 1918, oznacza to, że te adresy są dostępne dla każdego użytku przez wszystkich więc te adresu mogą być powtórnie użyte. Jednakże nie są one rutowalne w internecie. Są uzywane intensywnie z powodu braku rejestrowalnych adresów., żeby połaczyć takie sieci z internetem wymagany jest NAT. Pomimo pewnych działań mających zaoszczędzić istniejącą przestrzeń adresową IPv4 (takich jak NAT i DHCP) liczba 32-bitowych adresów IP nie jest wystarczająca by zapewnić wzrost internetu na dłuższą metę, z tego powodu 128 bitowe adresowanie IPv6 zostanie zastosowane w przeciągu najbliższych 5 do 15 lat.

IPv6

W latach 90-tych opracowano następną wersję IP, która ma zapobiec wyczerpaniu się dostępnej puli adresów IP. Różne techniki oszczędzania adresów jak maski podsieci o zmiennej długości (VLSM) lub tłumaczenie adresów za pomocą NAT są rozwiązaniem krótkotrwałym. Początkowa nazwa - zanim został wybrany w procesie selekcji IETF - IP Next Generation (IPng).

IPv6 jest drugą wersją IP jaka będzie powszechnie stosowana (było IPv5 ale nie był to następca IPv4 a raczej eksperymentalny zorientowany na przepływ protokół streamingu multimediów) Chociaż został adoptowany przez IETF jako następca IPv4 jeszcze w 1994 nadal nie ma więcej niż kilka procent internetu.

Powodem dla utworzenia IPv6 był brak przestrzeni adresowej, szczególnie w zaludnionych krajach Azji takich jak Indie i Chiny. Problem ten częściowo jest rozwiązywany przez NAT, ale sprawia to problemy techniczne, lub w ogóle uniemożliwia działanie takich aplikacji jak VoIP i niektórych gier wielosobowych. Istotną przyczyną dla zastosowania IPv6 są nowe możliwości takie jak mobilność, jakość usług, rozszerzenia prywatności itd. IPv4 będzie wspierane nadal do 2025, żeby dać czas na naprawę błędów nowego systemu.

Celem IPv6 jest zastąpienie poprzedniego standardu, IPv4, który ma do około 4 miliardów (4 x 109) adresów, podczas kiedy IPv6 ma ich 2128 inaczej mówiąc 3.4 x 1038 (34 undecyliony), co jest odpowiednikiem:

• 4.3 x 1020 (430 kwintylionów) na cal kwadratowy powierzchni Ziemi
• 6.7 x 1017 (670 kwadrylionów) na milimetr kwadratowy powierzchni Ziemi

Tą ilość można wyrazić takim porównaniem: jeśli Ziemia zrobiona by była w całości z ziarenek piasku wielkości jednego milimetra sześciennego, można by dać unikalny adres każdemu ziarenku dla 300 milionów planet wielkości Ziemi.

Adresy IPv6 są złożone z dwóch logicznych części:

• 64-bitowy prefix sieci
• 64-bitowa część adresu hosta, która często jest generowana automatycznie z adresu MAC interfejsu

Czasem argumentuje się, że 128-bitów to za dużo i internet nigdy nie będzie potrzebował tak dużej ilości. Główną przyczyną dla takiej długości nie jest wcale upewnienie się, że adresów nigdy nie zabraknie, ale raczej zapewnienie łatwości przeprowadzenia rutingu dzięki utrzymaniu części adresowej sieci niezfragmentowanej. Taka fragmentacja jest częsta w IPv4, gdzie duża ilość segmentów adresowych może być i często jest przydzielana dla jednej organizacji.

Adresy IPv6 mają 128 bitów długości, wyrażonych w postaciu ośmiu wartości 16-bitowych, oddzielonych dwukropkami i zapisanych w notacji szesnastkowej (heksadecymalnej), na przykład:

1111:2222:3333:4444:5555:6666:7777:8888

Każda wartość jest liczona od 0x0 do 0xFFF (dziesiętnie od 0 do 65 535). Granica części hostowej została ustalona po 64 bitach. Przyjęto zasadę, że można usunąc zera rozpoczynające każdy segment

Zapisany jest jako osiem 4-cyfrowych (16-bitów) heksadecymalnych liczb oddzielonych dwukropkiem, nieprzerwany ciąg zer może zostać pominięty więć 1080::800:0:417A jest tym samym co 1080:0:0:0:0:800:0:417A.

• zwykle są zapisywane jako osiem grup po cztery heksadecymalne cyfry, np.: 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 jest poprawnym adresem IPv6
• jeśli czterocyfrową grupą jest 0000 może zostać pominięte, np: 2001:0db8:85a3:0000:1319:8a2e:0370:7344 jest tym samym adresem co: 2001:0db8:85a3::1319:8a2e:0370:7344
• zgodnie z tą regułą jeśli dwa kolejne dwukropki wynikają z takiego ominięcia mogą być zredukowane do dwóch dwukropków, tak długo jak jest to tylko jedna grupa sąsiadujacych dwukropków, tak więc

2001:0DB8:0000:0000:0000:0000:1428:57ab
2001:0DB8:0000:0000:0000::1428:57ab
2001:0DB8:0:0:0:0:1428:57ab
2001:0DB8:0::0:1428:57ab
2001:0DB8::1428:57ab

są poprawnymi adresami, w przeciwieństwie do: 2001::25de::cade który jest nieprawidłowy bo nie wiadomo jak duża ilość grup 0000 jest po każdej stronie

• zera z przodu mogą zostać pominięte, więc: 2001:0DB8:02de::0e13 jest tym samym co 2001:DB8:2de::e13
• jeśli jest to przebrany adres IPv4 ostatnie 32 bity mogą zostać zapisane dziesiętnie, więc: ::ffff:192.168.89.9 jest tym samym co: ::ffff:c0a8:5909 ale nie tym samym co: ::192.168.89.9 lub ::c0a8:5909
• mapowany adres IPv4 ::ffff:1.2.3.4

format 1.2.3.4 jest kompatybilny z IPv4

Adresy IPv4 są łatwe do konwersji na format IPv6, np. jeśli dziesiętny adres IPv4 to 135.75.43.52 (heksadecymalnie 0x874B2B34) może być konwertowany na 0000:0000:0000:0000:0000:0000:874B:2B34 lub ::874B:2B34. I znowu: możliwa jest hybrydowa notacja, w której ten adres to ::135.75.43.52. Te kompatybilne z IPv4 adresy mają status deprecated ponieważ przejściowe mechanizmy IPv6 już ich nie używają.

Segmenty adresowe są określone jak w nowoczesnej alternatywie dla IPv4: numer sieci potem slasz i liczba właściwych bitów w numerze sieci (w formie dziesiętnej). Przykład: 12AB::CD30:0:0:0:0/60 zawiera wszystkie adresy zaczynające się od 12AB00000000CD3.

Adresy specjalne: Istnieje pewna liczba adresów, które mają specjalne znaczenie w IPv6 oto krótka lista w notacji CIDR.

• ::/128 - adres składający się z samych zer używany jest by określić jakikolwiek adres i używany jest wyłącznie w oprogramowaniu.
• ::1/128 - adres pętli zwrotnej - jest to lokalny adres hosta, który odnosi sie do niego samego, wszystkie wysłane tam pakiety wracają do niego (odpowiednik 127.0.0.1 z IPv4).
• ::/96 - kompatybilny z IPv4 adres używany w w mechanizmach przejściowych w sieciach IPv4/IPv6.
• ::ffff:0:0/96 - mapowany adres IPv4 (IPv4-mapped address) używany w mechanizmach przejściowych w hostach o podwójnym stosie.
• fe80::/10 - prefiks lokalnego łącza określający, że ten adres jest prawidłowy tylko w łaczu lokalnej sieci fizycznej.
• fec0::/10 - prefiks lokalnego łącza określający, że ten adres jest prawidłowy tylko w lokalnej organizacji. RFC 3879 (IX 2004) określa go jako deprecated i przyszłe systemy nie muszą implementować jakiegokolwiek wsparcia dla tego typu specjalnych adresów.
• ff00::/8 - prefiks multicastu, używany w adresach multicastowych.

HMPTODO

Jak widać witryny mają 16 bitów na utworzenie podsieci. Cały początkowy przedrostek złożony z 48 bitów dostarczają usługodawcy internetowi (ISP). Jedną z zalet adresów IPv6 jest to, że adresy hostów można tworzyć automatycznie na podstawie adresu MAC urządzenia, co pozwoli (ewentualnie) wyeliminować potrzebę konfigurowania hosta. Obecnie tablice przekierowań ruterów mogą liczyć nawet kilkadziesiąt tysięcy wpisów, wprowadzenie modelu hierarchicznego spowoduje znaczące odciążenie - każdy ruter będzie tłumaczył tylko część adresu: rutery obsługujące ruch na poziomie TLA będą interpretowały tylko segment TLA całego adresu i skierują go do właściwego TLA, który skieruje go do właściwego NLA (nie interpretując już TLA), który prześle go do określonego w segmencie SLA lokalnego dostawcy usług. Taki sposób organizacji ruchu pakietów pozwala by każdy ruter znał tylko swoje bezpośrednie otoczenie: ruter struktury nadrzędnej i podlegające mu urządzenia struktur niższego rzędu.

Pakiet IPv6 złożony jest z dwóch części:

• nagłówek (header) - pierwsze 40 bajtów pakietu zawiera zarówno adres przeznaczenia i źródła (każdy 128 bitów), również wersję IP (4 bity), klasę ruchu (traffic class - 8 bitów Pacet Priority), wskaźnik przepływu (flow label - 20 bitów, QoS management), długość ładunku (16 bitów) i limit skoków (hops limit) (8 bitów TTL)
• ładunek (payload) - do 64 K w normalnym rozmiarze lub większy z opcją "jumbo payload".

Istnieją dwie trochę odmienne wersje IPv6, obecnie obsolete początkowa wersja opisana w RFC 1883 różniąca się od obecnej proponowanej wersji standardu opisanej w RFC 2460 w dwóch polach: 4 bity zostały przyznane z flow label do traffic class, wszystkie inne róznice są drugorzędne. Fragmentacja jest przeprowadzana tylko przez hosta.

W IPv6 również opcje zostały wyrzucone ze standardowego nagłówka i są określone przez pole Next Header - analogiczne z funkcją pola Protokołu z IPv4. Przykład: w IPv4 można dodać opcję SSRR (Strict Source and Record Routing) co wymusi konkretną drogę dla pakietu, ale w IPv6 można utworzyć pole Next Header, które będzie wskazywało, że nagłówek rutingu (Routing header) jest następny, wtedy nagłówek rutingu powinien wtedy określić dodatkową informację do pakietu i wskazać, że np. następny jest nagłowek TCP. Jest to analogiczne do AH i ESP w IPSec dla IPv4 (które stosuje się również do IPv6).

IPv6 i DNS. Adresy IPv6 są reprezentowane w DNS przez rekordy AAAA (tzw. quad-A) (przez analogię do rekordów A dla IPv4). Zapytania odwrotne (reversed lookups) mają miejsce w ip6.arpa (poprzednio ip6.int).Ten schemat jest zdefinowany w RFC 3596 i został uznany za standard w RFC 3363 (sierpień 2002)

Schemat IPv6 pozwoli zachować zgodność z modelem IPv4, przypisując adresy postaci 0:0:0:FFFF:a.b.c.d urządzeniom, które nie obsługują IPv6, gdzie a.b.c.d jest adresem IPv4. Takie adresy zapisuje się jako ::FFFF:a.b.c.d gdzie :: zastępuje ciągły blok zer (dowolnej długości) w adresie IPv6 (ale podwójny dwukropek może wystąpić tylko raz). Adres pętli zwrotnej jest zawsze zdefiniowany jako ::1, a adres rozgłoszeniowy - jako FF02::1.

Kompatybilność jest zapewniona w obie strony:

• adres IPv4 zapisywany jest na ostatnich 32 bitach adresu typu unicast a reszta wypełniana jest zerami
• w drugą stronę stosuje się tzw. tunelowanie - pakiet IPv6 jest pakowany do postaci pakietu IPv4 (enkapsulacja) przesyłany do odbiorcy za pośrednictwem sieci zgodnej w IPv4 i przekształcany z powrotem na IPv6 (dekapsulacja).

Mechanizmy tunelowania oraz szyfrowania przesyłanych danych, oprócz zapewnienia komunikacji pomiędzy sieciami pracującymi w w różnych wersjach protokołu ułatwiają również zestawienie VPN czyli bezpośrednich łącz komunikacyjnych przy wykorzystaniu sieci publicznej.

Ważne dokumenty: RFC 791, RFC 1519 (adresy IPv4), RFC 2373 (adresy IPv6).

Ponadto IPv6 zawiera dodatkowe informacje sterujące, posiada elastyczny format nagłówka i zapewnia przyszły rozwój (rozszerzalność) protokołu oraz wspiera rezerwowanie zasobów (QoS). Towarzyszy mu cały zestaw protokołów zabezpieczających IPSec zapewniających potwierdzenie tożsamości nadawcy i odbiorcy pakietu oraz szyfrowanie przesyłanych danych. IPSec działa niezależnie od aplikacji funkcjonujących w wyższych warstwach, więc nie zastępuje stosowanych w nich zabezpieczeń, a tylko je uzupełnia zabezpieczając przed próbami podszywania się pod innego nadawcę czy zmiany zawartości przesyłanego pakietu.

Trzy typy adresów:

• unicast - odpowiada point-to-point czyli o jednoznacznie zdefiniowanym odbiorcy, w celu ułatwienia organizacji ruchu pakietów w sieci lokalnej zdefiniowano dwa dodatkowe typy adresów unicastowych; rutery pośredniczące w komunikacji z resztą internetu nie będą tak adresowanych pakietów przesyłać dalej
• segmentowy (LLUA link local unicast address) - ograniczony do określonego fagmentu intranetu
• ośrodka (SLUA site local unicast address) ograniczony do wewnętrznej sieci firmy
• multicast odpowiednik typu broadcast z IPv4, określa wielu odbiorców jednego pakietu
• czasowe (transient) - definiuje się pod kątem konkretnego zastosowania, np. w celu zestawienie telekonferencji
• trwałe (permament) - funkcjonalne typy odbiorców, np. serwery prowadzące mirror danego serwisu muzycznego
• anycast - pakiety adresowane sa do grupy odbiorców, ale ich transmisja kończy się gdy dowolny z nich dotrze na miejsce przeznaczenia, mogą być używane tylko przez rutery, więc ich najpowszechniejszym zastosowaniem bedzie rozsyłanie zapytań w celu określenia najszybszej dostępnej ścieżki transmisji danych.

Dwa mechanizmy automatycznej konfiguracji i przydzielania adresów IP:

• autokonfiguracja z uwzględnieniem stanu (stateful autoconfiguration) analogiczny do DHCP host otrzymuje z serwera adres IP ze zdefiniowanej uprzednio puli wraz z informacją o dmyślnym ruterze i adresie serwera nazw
• autokonfiguracja bez uwzględnienia stanu (stateless autoconfiguration) - na podstawie numeru MAC host konstruuje 64-bitowy identyfikator hosta (LLUA Link Local Unicast Address) po czym rozsyła do ruterów SLA tzw. zapytanie konfiguracyjne (router solicitation) w odpowiedzi otrzymuje prefiks adresu zawierający pozostałe segmenty po czym automatycznie konfiguruje adres IP przez dodanie utworzonego ID do otrzymanego prefiksu. W tej technice, żeby zmienić adresy wszystkich hostów wystarczy tylko zdefiniować na ruterze nowy prefiksu, a ruter sam go roześle do obsługiwanych hostów.

6bone.net - zamknięty 6 VI 2006

ICMP (Internet Control Message Protocol)

ICMP jest częscią zestawu protokołów internetowych jak to zostało zdefiniowane w RFC 792. Wiadomości ICMP są zwykle generowane w odpowiedzi na błędy w datagramach IP (jak to określono w RFC 1122) lub dla celów diagnostycznych lub rutingu. Wersja dla IPv4 jest znana jako ICMPv4 ponieważ jest to część IPv4. IPv6 ma analogiczny protokół.

Urządzenia łączące sieci (gateways) komunikują się ze sobą przy użyciu protokołu GGP (Gateway-to-Gateway Protocol), ale do połączeń gatewaya z hostem używany jest ICMP.

Używa IP jako warstwy usługowej podobnie jak TCP i UDP, ale zwykle przedstawia się go na tym samym poziomie co IP, bo traktowany jest jako integralna część modułu IP w oprogramowaniu karty sieciowej i każdy moduł musi obsługę tego protokołu zawierać. Wiadomości ICMP mogą być wysyłane w kilku różnych sytuacjach - błędach zachodzących w sieci: jeśli datagram nie może dotrzeć do hosta docelowego, w gatewayu brak miejsc na buforowanie datagramów, lub kiedy gateway może skierować ruch na krótszą i mniej obciążoną trasę.

Wiadomości ICMP są opakowane w nagłówek IP (więc używają warstwy IP), wiadomość znajduje się w części danych datagramu IP. Zwykle powstaje z normalnego datagramu IP, który wygenerował odpowiedź ICMP. IP kapsułkuje odpowiednią wiadomość ICMP z nowym nagłowkiem IP (żeby otrzymać odpowiedź ICMP do wysyłającego hosta) i wysyła otrzymany datagram w zwykły sposób. Dla przykladu: każda maszyna (np. pośredniczące rutery), która przekazuje datagramy IP musi obniżyć TTL w nagłówku IP o jeden, jeśli TTL sięga 0 wiadomość ICMP "Time to live exceeded in transit" jest wysyłana do źródła datagramu.

Każda wiadomość ICMP jest kapsułkowana dokładnie w pojedynczym datagramie IP i podobnie jak UDP ICMP nie gwarantuje dostarczenia.

Chociaż wiadomości ICMP są zawarte w datagramie IP, są przetwarzane jako specjalny przypadek w odróżnieniu od reszty ruchu IP, a nie są traktowane jak po prostu pod-protokół IP. W wielu przypadkach niezbędne jest skontrolowanie zawartości wiadomości ICMP i dostarczenie właściwej wiadomości błędu do aplikacji, która wygenerowała błędny pakiet, który spowodował wysłanie wiadomości ICMP

Wiele popularnych narzędzi jest bazowanych na wiadomościach ICMP. Polecenie traceroute jest zaimplementowane przez wysłanie datagramów ze specjalnie ustawionym polem TTL i wyczekiwaniem na wiadomości ICMP "Time to live exceeded in transit" i "Destination unreachable" generowane w odpowiedzi. Również ping jest zaimplementowany przez użycie wiadomości ICMP "Echo" i "Echo reply".

Lista dozwolonych wiadomości kontrolnych (niekompletna):

• 0 - Echo Reply
• 1 - Reserved
• 2 - Reserved
• 3 - Destination Unreachable
• 4 - Source Quench
• 5 - Redirect Message
• 6 - Alternate Host Address
• 7 - Reserved
• 8 - Echo Request
• 9 - Router Advertisement
• 10 - Router Solicitation
• 11 - Time Exceeded
• 12 - Parameter Problem
• 13 - Timestamp
• 14 - Timestamp Reply
• 15 - Information Request
• 16 - Information Reply
• 17 - Address Mask Request
• 18 - Address Mask Reply
• 19 - Reserved for security
• 20-29 - Reserved for robustness experiment
• 30 - Traceroute
• 31 - Datagram Conversion Error
• 32 - Mobile Host Redirect
• 33 - IPv6 Where-Are-You
• 34 - IPv6 Here-I-Am
• 35 - Mobile Registration Request
• 36 - Mobile Registration Reply
• 37 - Domain Name Request
• 38 - Domain Name Reply
• 39 - SKIP Algorithm Discovery Protocol
• 40 - Photuris, Security failures
• 41-255 - Reserved

Warstwa dostępu do sieci (ARP)

ARP (Address Resolution Protocol)

MAC - sprzętowy adres karty sieciowej zaszyty na stałe. Identyfkuje konkretne urządzenie a nie jak adres IP interfejs sieciowy. Składa się z dwóch części: 6 liczb poprzedzielanych dwukropkiem, gdzie pierwsze cztery identyfikują producenta, pozostałe są unikalnym numerem urządzenia. Nie mogą się pojawić dwie karty o tym samym adresie MAC - zapewniają to odpowiednie regulacje organizacyjne. Rzecz w tym, że jeśli w jednej sieci lokalnej znajdą się dwie lub więcej kart o tym samym numerze MAC komunikacja jest niemożliwa. Tylko karta sieciowa ma swój numer MAC, bo ma więcej niż jeden koniec. W modemie nie ma takiej potrzeby.

Wygląda na przykład tak:

H6:ef:45:sf:3g:68

ARP jest metodą na znalezienie adresu sprzętowego (MAC) hosta z jego adresu IP. Wysyłający nadaje pakiet ARP zawierający internetowy adres innego hosta i oczekuje na odpowiedź w postaci adresu ethernetowego. Każdy host przechowuje w buforze tłumaczenia adresów co zmniejsza obciążenie sieci. ARP pozwalają być adresom IP niezależnym od adresów ethernetowych ale może działać tylko kiedy wszystkie hosty go wspierają. ARP jest zdefiniowany w RFC 826. Alternatywą dla hostów, które nie wspierają ARP jest użycie prekonfigurowanego mapowania adresów IP na adresy MAC.

Warianty protokołu ARP: ARP może być użyty do tłumaczenia (rozwiązywania, resolve) adresów MAC na wiele różnych protokołów warstwy trzeciej. ARP został również zaadoptowany do tłumaczenia innych rodzajów adresów warstwy drugiej, np. ATMARP jest używany do tłumaczenia adresów ATM NSAP na IP poprzez protokół ATM.

Miejscem styku ze sprzętem jest warstwa łącza danych, która podzielona jest na dwie podwarstwy: górną LLC i dolną MAC. Zasadnicze znaczenie ma MAC, odpowiada ona za takie przygotowanie odebranego z warstwy sieciowej pakietu IP, aby nadawał się do transmisji w sieci o określonej topologii. Sieci lokalne wykonane są zwykle w standardzie Ethernet o topologii magistrali, ale istnieją inne rozwiązania, każde z nich ma własne interfejsy, kable, sygnalizacje i szybkości transmisji wykorzystując jednocześnie najbardziej właściwe dla realizacji tego celu ramki. Ramka to odpowiednio sformatowana ilość informacji jaką można przesłać za jednym zamachem, a formatowanie polega na ogół na podziale pakietu IP na mniejsze części, zgodnie z wymogami standardu i opatrzenie każdej z nich nagłówkiem zawierającym m.in. adres docelowy i źródłowy. Ale nie IP tylko MAC. Informację o tym zbiera protokół ARP, który jest dla użytkownika zupełnie niewidoczny i nie wymaga żadnej konfiguracji. Działa w tle ogłaszając komunikaty, których celem jest odnalezienie właściwego adresata dla przesyłki, którą jest pakiet IP już podzielony na ramki i gotowy do wysyłki.

Jeśli karta stwierdzi, że dany adres IP należy do tej samej podsieci, wysyła w sieć pytanie "jaki jest adres MAC komputera o danym adresie IP?". W polu adresu MAC takiej ramki są same jedynki, co określa wszystkie urządzenia podłączone do danego segmentu, więc przez wszystkie jest odbierany i przetwarzany.

Adres rozgłoszeniowy fizyczny (ang. broadcast address):

hh:hh:hh:hh:hh:hh

a może?[?]

FF:FF:FF:FF:FF:FF

Taką ramkę (ARP-request) odbierają wszystkie karty w sieci lokalnej

• adres IP nadawcy
• adres fizyczny nadawcy
• adres IP odbiorcy
• adres fizyczny odbiorcy czyli w tym przypadku rozgłoszeniowy

Każdy komputer na poziomie warstwy 3 porównuje podany w zapytaniu adres IP z własnym i odpowiada tylko ten, który wykryje zgodność - wyśle wypełnione pola nadawcy, czyli swój adres IP i fizyczny. Ramka odpowiedzi (ARP-reply) zawierająca adres sprzętowy skierowana jest tylko do pytającego, gdyż podał on swój adres.

Wtedy pytający wkłada ten adres do swoich ramek i je wysyła. Proces jest przyspieszany przez buforowanie w tzw. cache ARP, zawierającym tablicę ostatnio używanych odwzorowań pomiędzy adresami IP i MAC, jego zawartość uaktualniana jest dynamicznie bez ingerencji użytkownika, ale istnieje możliwość ręcznego wprowadzenia odwzorowań statycznych instrukcją:

arp

Zasady dostępu do medium transmisyjnego

Metoda określajaca kolejność nadawania przez dane medium (kabel lub eternet).

• CMA/CD - najczęstszy w sieciach Ethernet tzw. wielodostęp z wykrywaniem zajętości kanału i detekcją kolizji, "kto pierwszy ten lepszy" opisana standardem IEEE 802.3; jeśli dochodzi do kolizji wszyscy przerywają nadawanie
• Token Ring - pierścień z dostępem do znacznika, każde urządzenie uzyskuje dostęp w sposób cykliczny, w sieci krąży tzw. znacznik (token) który otrzymuje każdy z kolei i wtedy może nadawać (standard IEEE 802.5); stosowana w sieciach o tej samej nazwie oraz FDDI
• Token Bus - magistrala z dostępem za pomocą znacznika; podobna do Token Ring z tym, że znacznik nie jest przekazywany cyklicznie a według numeracji stacji, która nie musi być zgodna z kolejnością ich włączenia do linii (zdefinowana w IEEE 802.4), obecnie raczej nie używana
• Request Priority (Priorytet na żądanie) - scentralizowana metoda sterowania dostępem do medium, istnieje jednostka zarządzająca, która stale odpytuje stacje na okoliczność chęci przeprowadzenia transmisji (standard (IEEE 802.12); używana w systemie 100VG-AnyLAN

Polecenia

ifconfig

Polecenie, które pojawiło się w systemach uniksowych razem z 4.2BSD (sierpień 1983). W Linuksie jest częścią pakietu net-tools. W nowszych wersjach jądra cały ten pakiet - łącznie z ifconnfig i netstat - został zastąpiony przez narzędzia z pakietu iproute2.

lista interfejsów

ifconfig -a

netstat

tablica interfejsów sieciowych

netstat -i

nmcli

lista dostępnych urządzeń

nmcli device status

nmcli connection show

ip

ip route list |grep default

$ ip link show

$ ip addr show eth0

routing table

ip r