UNIX Network Programming Volume 1, Third Edition [Electronic resources] : The Sockets Networking API نسخه متنی

This is a Digital Library

With over 100,000 free electronic resource in Persian, Arabic and English

UNIX Network Programming Volume 1, Third Edition [Electronic resources] : The Sockets Networking API - نسخه متنی

Addison Wesley

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید










A.2 IPv4 Header


The IP layer provides a connectionless best-effort datagram delivery service (RFC 791 [Postel 1981a]). IP makes its best effort to deliver an IP datagram to the specified destination, but there is no guarantee that the datagram will arrive, will arrive in order relative to other packets, or will arrive only once. Any desired reliability, ordering, and duplicate suppression must be added by the upper layers. In the case of a TCP or SCTP application, this is performed by the transport layer. In the case of a UDP application, this must be done by the application since UDP is unreliable; we show an example of this in Section 22.5.

One of the most important functions of the IP layer is

routing . Every IP datagram contains a source and destination address. Figure A.1 shows the format of an IPv4 header.


Figure A.1. Format of the IPv4 header.


  • The 4-bit

    version field is 4. This has been the version of IP in use since the early 1980s.

  • The

    header length field is the length of the entire IP header, including any options, in whole 32-bit words. The maximum value for this 4-bit field is 15 (0xf), giving a maximum IP header length of 60 bytes. Therefore, with the fixed portion of the header occupying 20 bytes, this allows for up to 40 bytes of options.

  • The 6-bit

    Differentiated Services Code Point (DSCP) field (RFC 2474 [Nichols et al. 1998]) and the 2-bit

    Explicit Congestion Notification (ECN) field (RFC 3168 [Ramakrishnan, Floyd, and Black 2001]) replace the historical 8-bit

    type-of-service (TOS) field, which was described in RFC 1349 [Almquist 1992]. We can set all 8 bits of this field with the IP_TOS socket option (Section 7.6), although the kernel may overwrite any value we set to enforce Diffserv policy or implement ECN.

  • The 16-bit

    total length field is the total length in bytes of the IP datagram, including the IPv4 header. The amount of data in the datagram is this field minus 4 times the header length (recall that the header length is in units of whole 32-bit words, or 4 bytes). This field is required because some datalinks pad the frame to some minimum length (e.g., Ethernet) and it is possible for the size of a valid IP datagram to be less than the datalink minimum.

  • The 16-bit

    identification field is set to a different value for each IP datagram and enables fragmentation and reassembly (Section 2.11). The value must be unique for the packet's source, destination, and protocol, for the length of time that the datagram could be in transit. If there is no chance that the packet will be fragmented, for instance, the

    DF bit is set, there is no need to set this field.

  • The

    DF (don't fragment) bit, the

    MF (more fragments) bit, and the 13-bit

    fragment offset field are also used with fragmentation and reassembly. The

    DF bit is also used with path MTU discovery (Section 2.11).

  • The 8-bit

    time-to-live (TTL) field is set by the sender and then decremented by 1 each time a router forwards the datagram. The datagram is discarded by any router that decrements the value to 0. This limits the lifetime of any IP datagram to 255 hops. A common default for this field is 64, but we can query and change this default with the IP_TTL and IP_MULTICAST_TTL socket options (Section 7.6).

  • The 8-bit

    protocol field specifies the next layer protocol contained in the IP datagram. Typical values are 1 (ICMPv4), 2 (IGMPv4), 6 (TCP), and 17 (UDP). These values are specified in the IANA's "Protocol Numbers" registry [IANA].

  • The 16-bit

    header checksum is calculated over just the IP header (including any options). The algorithm is the standard Internet checksum algorithm, a simple 16-bit one's-complement addition, which we show in Figure 28.15.

  • The

    source IPv4 address and the

    destination IPv4 address are both 32-bit fields.

  • We describe the

    options field in Section 27.2 and show an example of the IPv4 source route option in Section 27.3.



/ 450