Computer Networks Notes

Networks Notes: RFC 1149 – IP over Avian Carriers

This is a series containing notes I made while reading RFCs.

Link to this RFC.


Avian carrier

A Standard for the Transmission of IP Datagrams on Avian Carriers.

Note: this was the April Fool’s RFC for the year 1990. ūüôā

  • Describes an experimental method for sending IP datagrams over “avian carriers” (pigeons!)
  • Primarily useful in Metropolitan Area Networks
  • Experimental, not recommended standard.

Overview and Rational

  • Avian carriers provide:
    • high delay
    • low throughput
    • low altitude service
  • Connection path limited to a single point-to-point path for each carrier.
  • Many carriers can be used without significant interference with each other, outside of early spring.

Frame Format

  • Scroll of paper wrapped around avian carrier’s leg.
  • Bandwidth depends on leg length.
  • MTU typically 256 mg. Paradoxically, generally increases as carrier ages.


  • Prioritized pecking order can be used for multiple types of service.
  • Built-in worm detection and eradication
  • Storms can cause dataloss.
  • Persistent delivery retry, until the carrrier drops.

Security Considerations

  • Not generally a problem in normal operation
  • Data encryption needed in tactical environments.

Networks Notes: RFC 792 – Internet Control Message Protocol

This is a series containing notes I made while reading RFCs.

Link to this RFC.

Internet Control Message Protocol (ICMP)

  • Used by a gateway or destination to communicate with a source host. To report an error, for example.
  • Uses the basic support of IP as if it was a higher-level protocol. Actually a part of IP, is implemented in every IP module.
  • Control messages provide feedback about problems in the communication environment.
  • Not¬†designed to make IP reliable, IP is not designed to be completely reliable. For main purpose, see previous point.
  • No guarantees that a control message will be returned. Datagrams can still be undelivered without being reported by a control message.
  • Reliability is implemented in higher-level protocols that use IP (e.g TCP).
  • ICMP messages typically report errors in the processing of datagrams.
  • No ICMP messages are sent¬†about¬†ICMP messages (to avoid infinite loop).
  • ICMP messages only sent about errors in handing fragment zero of fragmented datagrams (the fragment with the fragment offset equal to zero).

Message Formats

  • Sent using the basic IP header.
  • First octet of the data portion of the datagram is a¬†ICMP type field. Its value determines format of remaining data.
  • Protocol number of ICMP is¬†1.

For values of an ICMP message’s IP header, see the “Message Formats” section of the linked RFC.

ICMP Fields

  • Type
  • Code
  • Checksum

For details on ICMP message types see pages 4 to 19 of the linked RFC.


Networks Notes: RFC791 -Internet Protocol

This is a series containing notes I made while reading RFCs.

Link to this RFC.

Internet Protocol

  • Implements two basic functions:
    • Addressing
    • Fragmentation
  • Addresses carried in the internet header are used to transmit internet datagrams to their destinations.
  • The selection of a path for transmission is called¬†routing.
  • Internet modules use fields in the internet header to fragment and reassemble internet datagrams when necessary in “small packet” networks.
  • An internet module resides in:
    • each host engaged in communication
    • each gateway interconnecting networks
  • Modules share common rules for interpreting the address fields and for fragmenting and assembling internet datagrams.
  • Modules have procedures for making routing decisions and other functions.
  • The protocol treats each internet datagram as an independent entity unrelated to any other internet datagram (i.e no connections or logical circuits).
  • The protocol uses four key mechanisms to provide service:
    • Type of Service
    • Time to Live
    • Options
    • Header Checksum


  • Type of Service
    • Indicates the quality of the service desired.
    • Used by gateways for:
      • selecting tranmission parameters for a particular network
      • selecting the network to be used for the next hop
      • selecting the next gateway when routing the internet datagram.
  • Time to Live
    • Indication of an upper bound on the lifetime of an internet datagram.
    • Set by sender of the datagram.
    • Decremented at points in the route where it is processed.
    • The internet datagram is destroyed if this ¬†reaches zero before reaching the destination.
    • A “self-destruct” time limit.
  • Options
    • provide for control functions needed or sometimes useful.
    • unnecessary in most common communications.
    • can include provisions for timestamps, security, routing etc.
  • Header Checksum
    • provides a verification that the internet datagram has been transmitted correctly.
    • the internet datagram is discarded if the header checksum fails.
  • The internet protocol does¬†not provide a reliable communication facility. There are¬†no:
    • acknowledgements
    • error control for data, aside from the header checksum
    • retranmissions
    • flow control
  • Errors detected can be reported using the Internet Control Message Protocol (ICMP), implemented in the IP module.


  • Name – what we seek
  • Address¬†– where it is
  • Route – how to get there

On addresses…

  • Addresses have a fixed length of four octets (32 bits).
  • An address:
    • begins with a network number
    • followed by the local address (“rest” field)
  • Addresses have three formats or classes.
    • Class A: high order bit is zero. Next 7 bits are the network. Last 24 bits are the local address.
    • Class B: high order two bits are one-zero. Next 14 bits are the network. Last 16 bits are the local address.
    • Class C: high order three bits are one-one-zero. Next 21 bits are the network. Last 8 bits are the local address.


  • Necessary when large packets have to pass through a local network that limits packets to a smaller size.
  • An internet datagram can be marked “don’t fragment”.
    • It will not be fragmented under any circumstances.
    • If it cannot be delivered without fragmentation, it will be discarded.
  • Needs to be able to break a datagram into an almost arbitrary number of pieces that can later be reassembled.
  • Receiver uses identification field to ensure fragments of different datagrams are not mixed.
  • Fragment offset field tells receiver the position of a fragment in the original datagram.
  • Fragment offset and length determine portion of the original datagram covered by the fragment.
  • More-fragments flag indicates (by being reset) the last fragment
  • Fields that provide sufficient information to reassemble datagrams:
    • identification field
    • fragment offset field
    • length
    • more-fragments flag
  • See RFC page 8-9 for a very well-written description of how fragmentation works.


  • Forward datagrams between networks
  • Also implement the Gateway to Gateway Protocol (GGP) to coordinate routing and other internet control information.
  • Higher level protocols need not be implemented in a gateway. GGP functions are added to the IP module.

The details on specification are very well written and I don’t think notes for them are needed. To read up the specification, refer to section 3 of the above linked RFC.

Networks Notes: RFC 768 – User Datagram Protocol

This is a series containing notes I made while reading RFCs.

Link to this RFC.

User Datagram Protocol


  • Uses IP as its underlying protool.
  • Does not guarantee reliable delivery of data streams
  • Protocol mechanism is minimal

Header contains:

  • Source port. (optional)
    • Contains the port of the sending process.
    • Any replies will be possibly addressed to this port.
    • Contains a zero value if unused.
  • Destination port.
    • Contains the port of the destination address.
  • Length.
    • Contains the length (in octets i.e bytes) of the datagram being sent including the header and the data.
    • Minimum value is eight because the header is eight bytes.
  • Checksum.
    • 16-bit one’s complement of the one’s complement sum of the information being sent.
    • Sums up the information in the IP header*, the UDP header and the data.
    • Pads data with zero octets to make a multiple of 2 octets (16-bits remember?)
    • Has a value of all zeroes if not generated (e.g for debugging purposes)
    • Same checksum procedure is also used in TCP.

* or, to be more precise, the pseudoheader which is assumed will be prefixed to the datagram.

A user-interface designed for this protocol should allow:

  • The creation of new receive ports
  • Functionality on the receive ports that does operations like returning the data octets and indicating the source port and address.
  • An operation allowing a datagram to be sent, specifying the data and destination ports and addresses to be sent.

IP Interface guidelines:

  • UDP module should get the source and destination addresses and the protocol field from the IP header.
  • One possible UDP/IP interface can:
    • return whole internet¬†datagram (including internet header) on a receive operation.
    • pass whole internet¬†datagram (again, including header) to the IP on a send operation.
    • Let the IP verify certain fields for consistency and compute the internet header checksum.

Possible applications of this protocol include:

  • Internet Name Server
  • Trivial File Transfer

When used in the Internet Protocol, the protocol number of UDP is 17 (21 in octal).