Pokud by na svě cestě k cíli narazily IP-datagramy na linku, kde MTU je 576, opět by se fragmentovaly, a to i datagramy již jednou fragmentované. Tedy konkrétně první fragment celkové velikosti 780 oktetů, se může rozdělit na IP-datagram velikosti 572 nesoucí fragment 552 oktetů ( 552 = 8 * 69 ) a IP-datagram velikosti 228 oktetů s fragmentem, který bude také násobkem 8 , konkrétně tedy 208. Při následně fragmentaci pak je nutné zachovat položku "Identification". Tím, že návaznost fragmentů je dána polem "Fragment Offset" ( do něhož se nezpočítávají oktety IP-hlavičky ), je pro opětovné skládání jednotlivých fragmentů ( na cílovém počítači ) jedno, jak a kde k jejich fragmentaci došlo.

Zároveň je snad vidět, že prvotní volba maximální velikosti jednotlivých přenášených částí, pokud je při konfiguraci volitelná, musí nějak zohledňovat i hledisko nejčastějšího použití třeba zde zmiňovaného TELENETu. Pokud jej uživatelé používají většinou tam, kde je všude MTU alespoň 1040, bude práce podle této druhé varianty efektivnější, pokud se však při jeho použití dostávají velmi často do míst sítě s nizkou velikostí MTU, je efektivnější využívat prvně popisovanou situaci, kdy se vždy zasílá jen oněch 500 znaků obrazovky.


IP-konektivita Internetu

O odesílání a přijímání IP-datagramů se na počítači většinou stará IP-část programového vybavení počítače, velmi úzce spolupracující s TCP-částí. Často se jedná o jednotný programový produkt, schematicky značený v obrázku v předchozí kapitole jako TCP_/_IP . IP-část musí umět zpracovat i IP-datagramy, jež nemusí obsahovat TCP-záhlaví. Jde většinou o IP-datagramy, které zabezpečují servisní (systémové) funkce v Internetu, kde by bylo zbytečné a komplikované, aby procházely částí TCP, neboť se jedná zpravidla o krátké informace. To se týká příkladně IP-datagramů, které jsou popsány protokolem ICMP ( Internet Control Message Protocol ) nebo UDP ( User Datagram Protocol ).

ICMP-protokolem jsou například zasílány zprávy, že některý router není kapacitně schopen zajistit transfer datagramů dál. ( Počáteční počítač - pokud se ovšem nejedná o systém NT - se snaží alespoň prodloužit interval odesílání jednotlivých datagramů, aby nedocházelo ke zbytečnému zahlcování přenosové cesty.) Protokolem ICMP se také zjišťuje dostupnost počítače v síti. Ten by měl IP-datagram vrátit nezměněný odesílajícímu (počátečnímu) počítači, což je využíváno například programem ping.

Protokoly ICMP ( a obdobně UDP ) mají shora uváděnou IP-hlavičku a pak obsahují další pole počínaje 21. oktetem, tedy místem, kde v předchozím schématu začíná TCP header . ( Při jejich popisu se ale často mluvívá už jen o těchto dalších polích.) Strukturou definovaných polí by tedy ICMP-protokoly mohly patřit - analogicky TCP - do vy musejí být zpracovávány na stejné úrovni jako IP-datagramy, tedy IP-částmi programových systémů, neboť právě jejich funkce je jimi řízena. ( Typy ICMP-protokolů a jimi přenášených chybových zpráv lze nalézt v RFC792 [7] .)

UDP-protokol je určen pro informativní uživatelské aplikace, jako třeba nslookup . Obdobně protokolu TCP obsahuje tento protokol pole počáteční a cílový port a samozřejmě také datovou oblast. IP-část by měla aplikačnímu programu předávat i informace z IP-hlavičky, jako je počáteční a cílová IP-adresa. A protože ty nejsou součástí UDP-protokolu, hovoří se někdy o předávání informací z pseudozáhlaví.

Podstatný rozdíl je oproti spolupráci aplikačního programu s TCP-částí ( a s využitím TCP-protokolu ) v nezabezpečeném přenosu protokolů UDP. Aplikační program musí být napsán tak, aby pro jeho práci anebo pro uživatele se nestala zásadním problémem skutečnost, že některý datagram nedorazil úspěšně k cíli ( nebo situace, že to ani není známo ). Při využívání UDP ( případně protokolu ICMP ) se proto hovoří o tzv. nepotvrzovaných službách.