The Internet Protocol provides the network layer (layer 3) transport functionality in the InternetProtocolFamily.
This page describes IP version 4, which is widely used. There's also an IPv6 protocol page available.
The IP protocol is used to transfer packets from one IP-address to another. The user of this layer will give a packet and a remote IP address, and IP is responsible to transfer the packet to that host.
IP will (hopefully) guide the packet the right way to the remote host. The data transfer is independent of the underlying network hardware (e.g. ATM, Ethernet, or even a SerialLine). If the underlying hardware is not able to transfer the maximum length required (especially on SerialLine's or ATM), IP will split the data into several smaller IP fragments and reassemble it into a complete one at the receiving host.
When IP wants to send a packet on a LAN, it must first translate the IP-address given into the underlying hardware address (e.g. an Ethernet address). IP uses ARP for this translation, which is done dynamically. On a point-to-point line, this is obviously not necessary, as there's only one host to which a given machine can send a packet.
Version 4 of the IP protocol is widely used all over the world. As the available IP-address range is becoming short, version 6 with a much wider address range is becoming more and more popular these days.
The RFC791 "INTERNET PROTOCOL" was released in September 1981.
XXX - Add example traffic here (as plain text or Wireshark screenshot).
IP dissector is fully functional. Wireshark provides some advanced features such as IP defragmentation.
Decode IPv4 TOS field as DiffServ field: Whether the IPv4 type-of-service field should be decoded as a Differentiated Services field (see RFC2474/RFC2475)
Reassemble fragmented IP datagrams: Whether fragmented IP datagrams should be reassembled
Show IP summary in protocol tree: Whether the IP summary line should be shown in the protocol tree
Validate the IP checksum if possible: Whether to validate the IP checksum
Support packet-capture from IP TSO-enabled hardware: Whether to correct for TSO-enabled hardware captures, such as spoofing the IP packet length
Enable GeoIP lookups: Whether to look up IP addresses in each GeoIP database we have loaded
Interpret Reserved flag as Security flag (RFC 3514): Whether to interpret the originally reserved flag as security flag
XXX - Add a simple example capture file. Keep it short, it's also a good idea to gzip it to make it even smaller, as Wireshark can open gzipped files automatically.
A complete list of IP display filter fields can be found in the display filter reference
Show only IPv4-based traffic (beware: you won't see any ARP packets if you use this filter!):
Show only the IP-based traffic to or from host 192.168.0.10:
Show only the IP-based traffic to or from the subnet 192.168.43.0/24 (The /24 is CIDR notation for a network address with a mask of 24 one bits, that is, a subnet mask of 255.255.255.0):
Show only the IP-based traffic not to or from host 192.168.0.10 (beware: this is not identical to ip.addr!=192.168.0.10):
Capture IPv4-based traffic only:
Capture only the IP-based traffic to or from host 192.168.0.10:
Capture only the IP-based traffic to or from the subnet 192.168.43.0/24 (The /24 is CIDR notation for a network address with a mask of 24 one bits, that is, a subnet mask of 255.255.255.0):
ip net 192.168.43.0/24
Capture only the IP-based traffic not to or from host 192.168.0.10:
not host 192.168.0.10
RFC791 INTERNET PROTOCOL
RFC894 Transmission of IP Datagrams over Ethernet Networks
RFC950 Internet Standard Subnetting Procedure
RFC1112 Host Extensions for IP Multicasting
RFC1812 Requirements for IP Version 4 Routers === Differentiated Services (replaces Type of Service) ===
RFC2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
RFC2475 An Architecture for Differentiated Services
Imported from https://wiki.wireshark.org/Internet_Protocol on 2020-08-11 23:15:08 UTC