IP header is 32 bits in length and is added to the front of a frame before being handed up to the transport layer, it contains the following fields:
Version: a 4 bit field indicating the IP version, set to binary 0100 for IPv4 or 0110 for IPv6
Header length: a 4 bit field indicating the length of the IP header because the option field can vary in size depending on the options field as described below, the total Header length can vary from a min of 20 bits to 60 bits.
TOS or Diffserv:
The TOS field is an 8 bit field that can be used to specify special handling of the packet, it is broken down into two sub fields, precedence and TOS, this field is not commonly used these days, however it can be used for QOS applications. These days the TOS field has been redefined as a part of the Differentiated Services framework, it creates a much more flexible handling of IP packets, with diffserv you can define service classes on a router and then sort packets into these classes, the router can then que and forward packets with different levels of priority according to their classification, each que and forward action is called a per-hop behaviour, while diffserv defines the framework, the mechanism itself is called Differentiated Class of Service (COS). As you can see the first 6 bits have been redefined as the Diffserv code point, up to 64 different service classes that can then be sorted into PHB's where the old TOS precedence architecture could only define 8 different levels of "priority" The ECN portion - 2 bits, is the Explicit Congestion Notification and can be used to signal congestion.
Total length: a 16 bit field inticating the total length of the IP Packet including header, max including header is 65,535 bits because that is the max that can be expressed by 16 bits!
Identifier: a 16 bit field used in conjunction with the flags and fragment offset fields for fragmentation of a packet, if a packet is fragmented the router marks this field with the same value so the receiver knows what packets go together.
Flags: a 3 bit field where the first bit us not used and set to zero, the second is the DF bit which can be set via the extended ping command, the third is the MF bit, that is set when a router fragments a packet and more fragments should be expected by the receiver, the last packet this bit is set to zero.
Fragment Offset: a 13 bit field that indicates the offset in units of eight bits, from the beginning of the header to the beginning of the fragment.
TTL : an 8 bit field that is set to a certain number when the packet is first generated, as the packet passes through a router, the TTL field is decremented by 1 (in most circumstances)
Protocol: a 8 bit field that indicates the protocol number; see below for a few well known numbers. Assigned Internet Protocol Numbers Decimal Keyword Protocol References ------- ------- -------- ---------- 0 Reserved 1 ICMP Internet Control Message [RFC792,JBP] 2 IGMP Internet Group Management [RFC1112,JBP] 4 IP IP in IP (encasulation) [JBP] 6 TCP Transmission Control [RFC793,JBP] 8 EGP Exterior Gateway Protocol [RFC888,DLM1] 9 IGP any private interior gateway [JBP] 17 UDP User Datagram [RFC768,JBP]
Header Checksum: is the checksum for the IP header, not for the data, the header only, it is a 16 bit one's checksum, routers decrement TTL as the packet leaves an interface so the Header checksum must be recalculated at every router....see below from RFC 1141
In the oft-mentioned case of updating the IP TTL field, subtracting one from the TTL means ADDING 1 or 256 as appropriate to the checksum field in the packet, using one's complement addition.
Source Address: IP address of the originating device. 32 bit
Destination Address: IP address of the final destination. 32 bit
Options: this is a variable length field, and all are optional, space is "reserved" in the header for information to be added along the way if needed, options are primarily used for testing purposes and can be accessed through the exended ping command, most common are;Loose Source Routing; in which a series of IP addresses for router interfaces is listed, the packet must pass through each of these addresses, although multiple hops can occure between them.Strict Source Routing; in which a series of IP addresses for router interfaces is listed, the packet must pass through each of these addresses, but unlike LSR the packet must follow the exact path without additional hops in between, if the next hop is not the next hop in the list, an error is returned. RecordRoute; provides room for each router to enter the address of the outgoing interface as the packet transits, so a record is kept of all routers the packet encounters, similar to traceroute but records the whole path, to and from, there are a max of 9 hops, see below; R3#ping Protocol [ip]: Target IP address: 10.10.1.100 Repeat count [5]: 1 Datagram size [100]: 1000 Timeout in seconds [2]: Extended commands [n]: y Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: record Number of hops [ 9 ]: Loose, Strict, Record, Timestamp, Verbose[RV]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 1, 1000-byte ICMP Echos to 10.10.1.100, timeout is 2 seconds: Packet has IP options: Total option bytes= 39, padded length=40 Record route: <*> (0.0.0.0) (0.0.0.0) (0.0.0.0) (0.0.0.0) (0.0.0.0) (0.0.0.0) (0.0.0.0) (0.0.0.0) (0.0.0.0)
Reply to request 0 (236 ms). Received packet has options Total option bytes= 40, padded length=40 Record route: (172.16.123.3) (172.16.123.1) (172.16.25.2) (10.10.1.5) (10.10.1.100) (10.10.1.100) (172.16.25.5) (172.16.123.2) (172.16.123.1) <*> End of list
Success rate is 100 percent (1/1), round-trip min/avg/max = 236/236/236 ms R3# Timestamp; same as record route but with a timestamp of when it left the router interfaces.
Padding: simply ensures that the header ends on a 32 bit boundary by adding 0's after the options field until a multi
Loose Source Routing - a security threat? Loose source routing has been an IP option for ages, and people who have looked at it in depth have realized that it provides a massive security hole.
The loose source route option was added to the IP protocol in order to assist in route debugging. These days, it seems to be mainly used by large ISPs, to make sure that their peers aren't inappropriately dumping traffic onto their backbone links. A packet is given a list of desired hops that should be taken on the way to the final destination.
A loose source routed packet carries the same source IP address through all of its hops. The destination IP address will be set to whatever the IP of its next hop is. The IP option field will consist of the following:
|-1byte--|-1byte-----|-1byte----|---4 bytes--|---4 bytes---| ... ---------------------------------------------------------------- | TYPE | LENGTH | OFFSET | IP ADDR 1 | IP ADDR 2 | ... | (131) | | | | | | ----------------------------------------------------------------
The type is simply the value for the loose source route option, 131. The length is the total length of the option, in bytes, including the type, length, and offset fields. The offset is the value, in bytes of the location of the next hop that the packet hopes to travel to. An offset past the end of the option signifies that the current destination IP address is the final hop.
For example, if a packet was generated from 10.1.1.1, with a final destination of 172.16.1.1 via a hop to 192.168.1.1, the intial packet would have a source of 10.1.1.1, a dest of 192.168.1.1, and an IP option with a length of 7, an offset of 4, and the IP address starting at byte 4 of 172.16.1.1. If 192.168.1.1 forwards LSR packets, it would re-emit the packet with a source of 10.1.1.1, dest of 172.16.1.1, offset of 8, and the IP address at offset 4 of 192.168.1.1.
The main security problem with LSR is that several IP stacks will reverse a source route when responding to a source routed packet. This means that it would be trivial for an attacker to spoof a packet as coming from a trusted IP address that just so happens to be source routed through an IP address that the attacker can sniff on. The unsuspecting victim would then send return traffic to the spoofed source, but LSR it through the attacker. The attacker can carry on whole TCP sessions in this way without worrying about attacking weaknesses in TCP sequence numbers or lost packets.
Another security problem is that if you've got a NAT box, or some other internal, non-publically routed IP space that sits adjacent to a box that forwards source routed packets, a remote attacker will still be able to access boxes without public IPs by using the box that forwards LSR packets as a bounce point.