21 Eylül 2017 Perşembe

IPV4 Header

Giriş
Şöyledir
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPV4 zarfı şöyle düşünülebilir. 12 byte kontrol bilgisi + 8 byte adres bilgisi. Yani toplam 20 byte.

TCP/IP kullanılan bant genişliği düşük hatlarda Van Jacobson TCP/IP Header Compression kullanılarak byte sayısı düşürülebiliyor.

Struct
IPv4 Header şeklen şöyle. Linux'ta şu satırı dahil ederiz.
#include <netinet/in.h>
typedef struct header
{
  //IP-Header
  unsigned char ip_v:4, ip_hl:4;
  unsigned char ip_tos;       //1 Byte
  unsigned short int ip_len;  //2 Byte
  unsigned short int ip_id;   //2 Byte
  unsigned short int ip_off;  //2 Byte
  unsigned char ip_ttl;       //1 Byte
  unsigned char ip_p;         //1 Byte
  unsigned short int ip_sum;  //2 Byte
  unsigned int ip_src;        //4 Byte
  unsigned int ip_dst;        //4 Byte

}
Yukarıdaki tanımda eksik olan şey makinenin Most Significant Bit'inin (MSB) ne olduğuna dikkat edilmemesi. IPV4 ilginç bir şekilde MSB 0 olacak şekilde tanımlı. Dolayısıyla version ve header alanlarının yeri mimariye göre değişe. Örneğin Linux'ta gerçek kod şöyle tanımlı. Little Endian mimaride MSB 7. bit. Yani en solda. Big Endian'da ise MSB 0. bit yani en sağda. Dolayısıyla ters sırada tanımlı.
struct ip
{
  #if __BYTE_ORDER == __LITTLE_ENDIAN
    unsigned int ip_hl:4;               /* header length */
    unsigned int ip_v:4;                /* version */
  #endif
  #if __BYTE_ORDER == __BIG_ENDIAN
    unsigned int ip_v:4;                /* version */
    unsigned int ip_hl:4;               /* header length */
  #endif
  ...
};
Direkt bellek alanı ile çalışınca bu tür detaylara dikkat etmek gerekiyor. Eğer sadece kod ile çalışsaydık okuma esnasında bu tür detaylara dikkat etmezdik. Yani şu kod çalışırdı.
int ip_vhl; // version and header togather
#define IP_HL(ip) (((ip)->ip_vhl) & 0x0f) //split header length
#define IP_V(ip) (((ip)->ip_vhl) >> 4) //split IP version


1. Version Alanı - ip_v
4 bit büyüklüğünde. Bu alanlar sabit. Version her zaman IPv4 olduğu için 4.

2. Header Length Alanı - ip_hl
4 bit büyüklüğünde. IP Header'ın uzunluğu. Data hariçtir. Birim olarak 4 byte kullanır. 20 byte'lık header için 5 değeri yazılır. Bu alan Total Length alanından farklıdır. Şöyle yaparız.
struct ipheader* ip = ....; 
int ip_header_len = ip->iph_ihl * 4; 
Bu alan en çok Ip'den sonra gelen veriye erişmek için kullanılır. Şöyle yaparız.
int ip_header_len = ip->iph_ihl * 4;

struct icmpheader* icmp = (struct icmpheader *) ((u_char *)ip + ip_header_len);

3. Service Type Alanı  - Eski Kullanım 
8 bit büyüklüğünde.İlk 2 bit MBZ (Must be Zero), sonraki 3 bit precedence, sonraki 3 bit Type of Service (ToS) anlamına gelirdi.

3.1 MBZ
Hep sıfırdır.

3.2 Precedence
Precedence ile IP paketleri 0-7 değerleri arasında öncelik kazanabiliyordu. Precedence (ServiceType & 0xE0) >> 5) yapılarak okunur.

3.3 ToS
Açıklama yaz

3. Differentiated Services Code Point - Yeni Kullanım 
3.1 Explicit Congestion Notification - ECN
Bir router'da tıkanıklık olursa, router IP paketindeki bu alanı işaretler.


4. Total Length Alanı- ip_len
2 byte büyüklüğünde. Header + Data yani toplam paket uzunluğu. Byte cinsindendir.
nthos (ip->ip_len) ile okunur. Yani Big Endian olarak kullanılır.

Bu alan en fazla 65,535 değerini alabilir. Ping of death saldırısı bu değerden daha büyük paketlerin gönderilmesine dayanıyordu.

IP fragmentli bir yapıya sahip olabildiği için en büyük zarf 60 byte, en küçük faydalı yük 8 byte olabilir. Bu durumda gönderilebilecek MTU 68 byte olur. Açıklaması şöyle
Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets.

5. Identification  Alanı
2 byte büyüklüğünde. Her IP paketin farklı bir sayı verilir.
Flags Alanı
3 bit büyüklüğünde.

6. Flags Alanı
3 bit büyüklüğünde. 3 tane flag var. Bunlar şöyle
Bit 0 - Reserved
Hep 0
Bit 1 - Don't Fragment (DF)
Açıklaması şöyle
IPv4 packets have a Don't-Fragment (DF) flag which indicates whether routers on the path are allowed to perform fragmentation when the packet doesn't fit the MTU of the next link. If you leave the DF flag off you can just send packets as large as possible on your local link, and routers along the path will fragment if/when necessary. You therefore as a sender don't need to discover the MTU for the whole path.

Only when you tell routers not to fragment IPv4 and turn the DF bit on do you need to learn about lower MTU's further along the path. Routers that would have fragmented will now send back ICMP messages (type 3: Destination Unreachable, subtype 4: Fragmentation Needed and Don't Fragment was Set) and the sender needs to receive these so they can adjust their packet size.

IPv6 doesn't have a DF flag, fragmentation along the path is always prohibited. It therefore behaves in a similar way as IPv4 with the DF flag on. Routers will send back ICMP messages (Type 2: Packet Too Big, it's not a subtype of Destination Unreachable anymore, it now is so important it has its own type) and the sender has to take those into account when determining the packet size.

So whether you have to implement Path MTU Discovery has nothing to do with where in the header the fragmentation is implemented (main header vs extension header), it depends on whether fragmentation is handled along the path or whether the sender has to determine the right packet size. If the routers along the path handle it (IPv4 with DF off) then the sender doesn't need to care, but otherwise (IPv4 with DF on, and IPv6) the sender must be able to receive those ICMP messages so it can adjust its behaviour accordingly.

Bit 2 - More Fragment (MF)
Açıklaması şöyle
Reassembly
A receiver knows that a packet is a fragment if at least one of the following conditions is true:
  • The "more fragments" flag is set. (This is true for all fragments except the last.)
  • The "fragment offset" field is nonzero. (This is true for all fragments except the first.)
The receiver identifies matching fragments using the foreign and local internet address, the protocol ID, and the identification field. The receiver will reassemble the data from fragments with the same ID using both the fragment offset and the more fragments flag. When the receiver receives the last fragment (which has the "more fragments" flag set to 0), it can calculate the length of the original data payload, by multiplying the last fragment's offset by eight, and adding the last fragment's data size. In the example above, this calculation was 495*8 + 540 = 4500 bytes.
When the receiver has all the fragments, it can put them in the correct order, by using their offsets. It can then pass their data up the stack for further processing.
7. Fragment Offset Alanı 
Prefragment yani paketlerin kaynakta bölünmesi ve daha sonra hedef'te birleştirilmesi IP protokolünü ilk tasarlayanların niyetiydi. Açıklama şöyle
I've read that fragmented IP packets "always" become reassembled at their ultimate destination, e.g. the recipient host.
Ancak bu niyet gerçekleşmedi. Açıklaması şöyle
That was the original intent of the Designers of IP, it's not so true nowadays though. Many firewalls will defragment packets because it's difficult to do effective firewalling on fragments.
Bu alanın açıklaması şöyle
To fragment a long internet datagram, an internet protocol module (for example, in a gateway), creates two new internet datagrams and copies the contents of the internet header fields from the long datagram into both new internet headers. The data of the long datagram is divided into two portions on a 8 octet (64 bit) boundary (the second portion might not be an integral multiple of 8 octets, but the first must be). Call the number of 8 octet blocks in the first portion NFB (for Number of Fragment Blocks). The first portion of the data is placed in the first new internet datagram, and the total length field is set to the length of the first datagram. The more-fragments flag is set to one. The second portion of the data is placed in the second new internet datagram, and the total length field is set to the length of the second datagram. The more-fragments flag carries the same value as the long datagram. The fragment offset field of the second new internet datagram is set to the value of that field in the long datagram plus NFB.
IPV6'da Fragment özelliği yok. Açıklaması şöyle
In contrast, IPv6, the next generation of the Internet Protocol, does not allow routers to perform fragmentation; hosts must determine the path MTU before sending datagrams.
IP, Ethernet MTU'dan daha büyük veri göndermek isterse veriyi parçalara böler (fragment). Aynı diziye ait fragmentlerde IP Header'daki identification alanı sabittir. Dizinin son elemanı hariç tüm elemanlarının "More Fragmentation Flag" bayrağına 1 değeri atanır. Ayrıca birleştirme işlemi için "Fragment Offset" alanı atanır.
Paketin data kısmının büyüklüğü, son paket hariç 8 byte'ın katı olmalıdır. Eğer router'ın çıkış MTU değeri çok küçük ise paketin kaynağına ICMP mesajı gönderir. Açıklaması şöyle
If the MTU of the outgoing interface is smaller than the packet, the router will fragment the packet unless the DF flag is set. In that case the router will drop the packet and send an ICMP packet too big message back to the sender.

Tam bölünme örneği
Elimizde 302 byte uzunluğunda paket olsun. 20 byte zarf + 282 byte data. Bu paket 128 byte MTU değerine sahip bir ağdan geçecek olsun. Paket şöyle bölünür.

Fragment 1 : 124 byte (20 byte zarf + 104 byte data) 104 / 8 = 13
Fragment 2 : 124 byte (20 byte zarf + 104 byte data) 104 / 8 = 13
Fragment 3 : 94 byte (20 byte zarf + 74 byte data) 104 / 8 = 13

Kısmi bölünme örneği
Elimizde 1396 byte uzunluğunda paket olsun. Ağda ise zarfları çıkarttıktan sonra 1356 byte veri için yer olsun.
1356 / 8 = 169.5
ancak bunu aşağı yuvarlarsak 169 elde ederiz.
169 * 8 = 1352.
Yani bir pakette en fazla 1352 byte gönderebiliriz.Dolayısıyla ilk paket 1352 byte içerir. İkinci paket ise 44 byte içerir.

8. TTL Alanı - ip_ttl
1 byte büyüklüğünde. 8 bit olduğu için en fazla 255 değerini alabilir. IPV4 için TTL genelde 1veya 128 veya 255 değeri ile dolduruluyor. Aslında TTL değerini ben Hop Count olarak düşünüyordum ancak paketin yaşaması gereken süreyi gösteriyormuş. Açıklaması şöyle
Time to Live: 8 bits
This field indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value zero, then the datagram must be destroyed. This field is modified in internet header processing. The time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime.
Bir çok router TTL alanını değiştirmiyor. Bu yüzden IPv6'te bu alan "Hop Limit" olarak değiştirilmiş.

9. Protocol Number Alanı - ip_p
IP paketinin hangi üst seviye protokole gönderilmesi gerektiğini belirten bir sayı. Açıklaması şöyle
The protocol number is used by the the layer-3 protocol (IPv4 or IPv6) to determine to which layer-4 protocol in the network stack it should send the payload of the packet.
Icmp, Tcp, Udp vs. olabilir. Ethernet paketindeki Type alanı benzer bir mantık kullanarak aynı işlevi görür. Şöyle yaparız.
if (ip->iph_protocol == IPPROTO_ICMP)
{
  ...
}
144 numaralı protocol "any 0-hop protocol" olarak adlandırılır. Çok eskiden kullanılan ve sadece 1
hop gitmesi istenen bir protokoller içindir.

10. Header Checksum Alanı - ip_sum
IPV4, TCP ve UDP hep checksum yöntemini kullanır. IPV6 nedense artık checksum yöntemini kullanmıyor. Bu alan sadece IP Header için checksum'dır. Paketin yükü için checksum değildir.  Açıklaması şöyle
The header checksum in an IP packet only detects errors in the header. There is no trailing checksum in IP. It's up to the upper layers to detect errors in the payload.
TCP ve UDP paketlerinde checksum header + data içindir.

Bazı network kartları checksum hesaplamasını yapabilir. Bu durumda IP protocol stack normalde kendisinin yapması gereken bu görevi devreder. Açıklaması şöyle
IPv4 has 16-bit header checksum. It is calculated using the Internet checksum algorithm. It is much less reliable than Ethernet's FCS, and each router must modify the packet by decrementing hop count (and thus recalculating checksum), so this is not true end-to-end checksum either. Due to the additional workload required on routers, IPv6 has eliminated this checksum.
Paketi tekrar gönderecek router şöyle yapar.
In Ipv4, the receiving router first checks the checksum then decrements TTL and then recomputes the checksum.
11. Source  Ip Address Alanı 
UDP iletişiminde bu alan "unicast RP"F kontrolü ile spoofed UDP paketlerini süzmek için kullanılabilir. Böylece DoS saldırıları önlenebilir.

inet_ntop ile 4 byte'lık adresler string'e çevrilir. inet_pton ile string 4'byte'a çevrilebilir. Private Source veya Destination Ip adresleri internete çıkamaz.

Adres alanları IPV6'daki gibi 0'ları atarak kısaltarak gösterilmez.

IPV4 adresleri 3 sıınıfta toplanır. Açıklaması şöyle
IP addresses can be divided into categories.

  • Routable on the public Internet.
  • Routable on private networks but not on the public Internet
  • Not routable at all.
Private
Açıklaması şöyle
The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:
Açıklaması şöyle
Private IPv4 addresses allow you to run a network without applying for public IP addresses at your regional registry. Since IPv4 addresses have run out it's the only way to set up a new network or expand an existing one.
Private Ip Adresleri şöyle
10.0.0.0       - 10.255.255.255   /8
172.16.0.0   - 172.31.255.255   /12
192.168.0.0 - 192.168.255.255 /16
Aynı tablo şöyledir
10.0.0.0        -   10.255.255.255  (10/8 prefix)
172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
192.168.0.0     -   192.168.255.255 (192.168/16 prefix)
Shared
Shared Address Space şöyle
100.64.0.0/10
Açıklaması şöyle
That block of addresses is reserved for service providers to be able to do NAT in such a way that it doesn't conflict with the normal private address space.
Açıklaması şöyle
Shared Address Space is similar to [RFC1918] private address space in that it is not globally routable address space and can be used by multiple pieces of equipment. However, Shared Address Space has limitations in its use that the current [RFC1918] private address space does not have. In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.
12.  Destination Ip Address Alanı 
Yukarıdaki açıklama ile aynı

13. Options Alanı
Açıklaması şöyle
There are IPv4 options that may increase the packet header size. That is one of the things that IPv6 fixed. The maximum IPv4 packet header length is 60 bytes.
Record Route Option
RFC 791 ile tanımlı ancak kullanılmıyor

Hiç yorum yok:

Yorum Gönder