Každá realizace přenosu IP-datagramů využívá nějakého systému komunikace. IP-datagramy se obvykle vkládají do jednotlivých paketů tohoto komunikačního systému. ( Analogickým způsobem jako jsou ze segmentů TCP vytvořeny jednotlivé IP-datagramy. ) Stále je asi nejčastějším konkrétním příkladem princip vkládání IP-datagramů do paketů Ethernetu. A na to pak navazují i způsoby transformace 32-bitových IP-adres počítačů na 48-bitové adresy používané v kartách Ethernetu. Způsoby implementace nejen do Ethernetu, ale i do jiných komunikačních prostředí jsou náplní řady RFC-dokumentů [5], z nichž ovšem některé jsou pro obyčejného uživatele Internetu už těžko čitelné.

Zpravidla ovšem nemohou mít pakety komunikačního prostředí až takovou velikost jako IP-datagramy. Potom je nejsnazším řešením připustit přenos pouze IP-datagramů menší velikosti, které lze ještě jednoduše vkládat do komunikačních paketů. Tato omezující hodnota může být pro různé přenosové cesty odlišná a pro určitý úsek je dána hodnotou MTU , tj. Maximum Transmission Unit. Minimální možná velikost MTU pro každé místo v Internetu musí být alespoň 576 oktetů. ( Tedy vidíme, že ony čtyři IP-datagramy z příkladu přenosu naší zaplněné obrazovky by měly být schopny bez problémů dorazit kamkoliv v síti Internet.) Pokud do paketů komunikačního prostředí se nedá vložit 576 oktetů, je pak implementace IP-přenosu složitější. Každý IP-datagram musí být rozdělen a následně zase složen z několika komunikačních paketů. To je konkrétně případ rozhraní (komunikačního prostředí) X.25 , kde velikost používaných komunikačních paketů je 128 bytů.


V tom, že lidé, kteří stáli u zrodu Internetu, velmi prakticky z důvodů snadného propojení různých sítí principiálně připustili libovolnou velikost IP-datagramů, je například jeden z důvodů velkého rozšíření Internetu. S rozvojem nových přenosových technologií vzrůstají nejen přenosové rychlosti, ale je možné používat i větší komunikační pakety. To je samozřejmě výhodné, neboť pro větší soubory dat nemusí výrazněji stoupat režie přenosu daná rozkladem na (malé) IP-datagramy. Pochopitelně ovšem může dojít k situaci, že velikost přenášeného datagramu je větší než MTU v některém místě sítě Internet ( a jiná cesta není možná ). Takováto situace se pak řeší fragmentováním IP-datagramu, tedy rozdělením na IP-datagramy menší velikosti. Fragmentované datagramy se pak znova nespojují, putují už takto na cílové místo. Jejich vzájemná návaznost je pak uvedena v IP-hlavičce v poli "Fragment Offset".

Offset obvykle znamená počet znaků od začátku, v tomto případě tedy původního IP-datagramu, a tím lze v něm fragment lokalizovat. Nelogické pak ovšem je, že pro tento údaj je v hlavičce vyhrazeno pouze 13 bitů, původní datagram přitom mohl teoreticky mít velikost, k jejímuž zapsání 13 bitů nepostačuje. Při fragmentaci se však nové (menší) datagramy vytvářejí tak, aby vždy obsahovaly počet oktetů dělitelný osmi. "Fragment Offset" zde tedy neznamená počet oktetů od počátku původního datagramu, ale takovýto údaj vydělený číslem 8 ( anebo tedy offset vyjádřený počtem 64-bitových řetězců ). Neboť 8 = 2 ** 3 , lze pro údaj "Fragment Offset" vystačit s 16 - 3 , tj. 13 bity. Snad ještě doplňme, že (číselný) údaj "Identification" je při fragmentaci naplněn stejnou hodnotou jen pro fragmenty z téhož IP-datagramu. Tak je na cílovém počítači známo, které fragmenty mají patřit k sobě - viz RFC791 [6] .

Problémy spojené s fragmentováním by snad blíže mohla ilustrovat následující situace. Řekněme, že v našem předchozím příkladě by TCP-část zasílala 1000 znaků. Obrazovka se tak pošle ve dvou částech, 1000 a 600 znaků. A nyní si představme, že zaslané IP-datagramy narazí někde na linku, kde MTU bude třeba jen 784. Každý zaslaný IP-datagram obsahuje IP-hlavičku o 20 bytech (oktetech) a ještě TCP-záhlaví standardně také 20 oktetů, tedy jejich celková velikost je 1040 resp. 640 oktetů. První IP-datagram proto bude muset být rozdělen na fragmenty, které mimo IP-hlavičku budou oktetů obsahovat nanejvýše 764. Oktety ve fragmenu (nezapočítává se IP-hlavička) musí být dělitelné 8 , tedy do prvního fragmentu se může zahrnout maximálně 760 oktetů, ( Za TCP-záhlavím je v něm tedy dále přenášeno jen 740 znaků z obrazovky.) Zbývající fragment bude obsahovat zbylých 260 znaků obrazovky. ( Datová velikost posledního fragmentu pochopitelně již nemusí být dělitelená 8 .) U tohoto IP-datagramu je jen IP-hlavička, tedy jeho celková velikost je 280 oktetů.