An RFC a day..

The Internet Engineering Task Force (IETF) and the Internet Society (ISOC) are the main organizations for setting the standards that run what some of us know as the Internet. These standards are made up of Request For Comments or RFC’s that are put together by engineers or not engineers. Once they are published, they are reviewed and sometimes published as new standards creatively called Internet Standards.

One of the most famous tech Interview questions is the famous ‘What happens when I type google.com into my browser?’. Just think, if you knew every RFC by heart, you would blow the socks off your interviewer! So just learn them all, it’s like being required to know what a car looks like so you go to school to be a car engineer or something. Its only like a couple thousand RFC’s.

Just Kidding.

But this tech series will be a ‘What you need to know’ about some of the most important and foundational RFC’s.

[DISCLAIMER: All RFC’s are probably important and if you feel strongly about my error in choosing the ‘most important’ that’s okay! Just tell me what RFC’s to add and maybe I will add them or maybe I won’t]

 

RFC 791

RFC 791 is probably the most important RFC. RFC 791 specified the Internet Protocol or IP. If you only learn one thing from these posts, IP should be it. Understanding an IP Header and what each field does is something that every IT professional should learn.

There are a bunch of easy fields to remember and a couple that aren’t so straight forward.

Version: Only two main versions, 4 and 6. http://archive.oreilly.com/pub/post/what_ever_happened_to_ipv5.html

IHL: Internet Header Length. This specifies the length of the IP Header. This tells a device where this header ends and the next header starts.

Type of Service: Can be used to specify Differentiated Services or Diff Serv Code Point (DSCP). Can be used to tell the network what level of service to serve the packet.

Total Length: Total length of the entire packet, header + data.

Identification: This will be used to help nodes on the network divide and put packets back together without forgetting where each ‘fragment’ goes.

Flags: This has 3 positions, the first is always a 0 (its reserved), position 2 indicates if this packet can be fragmented (0) or cannot be fragmented (1). And position 3 indicates that this is the last fragment (1) or is is not the last fragment (0).

Fragment Offset: Used to specify the offset when a packet is fragmented.

Time To Live: This will tell the packet not to travel over X amount of hops to get to its destination. Trace Route uses this to determine the path to a destination by setting this to one, then 2 and so on until it reaches its destination.

Protocol: This indicates the protocol ‘under’ the IP Header. For example, TCP would be 6. [RFC 790] https://tools.ietf.org/html/rfc790

Header Checksum: This is a checksum of the header. It is recalculated at every node in the network since some of the fields change at every node.

Source Address: This will be the IP Address of the device that sent the packet.

Destination Address: This is the destination IP Address of course.

Options: These are optional. Additional values can be added here for various purposes like security or debugging.

Padding: This is just junk that is sent to make sure the IP Header is a multiple of 32 bits.

See, that wasn’t so hard! The IP Header takes care of addressing and is why we use IP addresses so it’s a pretty big deal! The IP packet is called a datagram and the rest of the data goes inside the datagram, think of it like an onion, the IP packet is the outermost peel. The next piece would be the TCP packet or something similar.