hpr-knowledge-base/hpr_transcripts/hpr0414.txt

Episode: 414
Title: HPR0414: Networking Basics Part 5
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0414/hpr0414.mp3
Transcribed: 2025-10-07 20:01:27

---

Hi everyone, this is Hacker Ball of Radio and my name is Kwatu and this is Networking
Basics of Soat I think 5. In this episode we're going to cover the internet protocol. That's
right, the Quittis IP. We've heard of IP of course from TCP IP and we discussed it a little
bit or hinted around that it's existence during our discussions of TCP and UDP. The internet
protocol is the layer upon TCP and UDP both sit. So the internet protocol deals abstractly
with the fact that networks need and want to interact with one another. You need the internet
protocol because you've got clusters of networks here, clusters of computers here, clusters
there and they want to talk to each other. It resides in the network layer and it provides
features for all the upper layer protocols for addressing fragmentation, reassembling security
and so on. Essentially what it deals with can be boiled down to two things. Addressing and
fragmenting. The advantage to having an IP layer or the IP protocol, internet protocol,
is that upper layers like TCP and UDP can just hand off the fact that hey, they need to
contact some far away remote network and IP gets to deal with the addressing and the fragmenting
of the message. Without a protocol like IP, a programmer would have to sit down and write
a different version of all the different ways for a message to get from one network to
another. So IP is kind of an almost a compatibility or abstraction layer if you will. So recall
from when we were talking about routers and switches and things like that that we said
that there were quote unquote layer three devices like a router which will route packets based
on the header information of a packet and the header contains the source and the destination
addresses, right? Well the way that IP deals with the addressing issue is that it determines
from a routing table what network a packet is destined for by looking at the source and
the destination addresses in the header files. And of course the address, the routing
table is going to contain a software address or a logical address. That is just an arbitrary
number assigned to a certain network. It's then going to determine the actual hardware
address of that destination. That is the actual location of the server or the computer
or the box that you're trying to reach. So it takes the packets from the transport layer
in the OSI model and sends the packets to the destination and it reassembles them there
on the destination on the remote side. There are four important mechanisms at work here.
There's the type of service which is going to indicate the quality of the service desired.
The type of service is just sort of a generalized set of parameters that kind of characterize
what kind of data this is. There's the time to live which is how long you want the data
to be hanging around within the ether before it reaches its destination. Obviously at a
certain point it will time out and the packet is destroyed and you assume that the host
is unreachable. There are option fields which include provisions for things like timestamps
and extra security, special routing, whatever. And there's the header checksum which provides
verification that the information used in processing the internet data gram has been transmitted
correctly. Now this isn't, again this isn't a TCP kind of stuff where it's verifying
that everything arrived in the correct order and the correct, you know, is uncorrupted
and stuff like that. It's just verifying that the information used to process the data
gram itself is correct. So keeping in mind that IP is not a reliable protocol. It doesn't
verify anything about the data that you're sending. It's just verifying the header information
that it's using to actually route packets and things like that. There's an error mechanism
dedicated to IP, the whole IP process. And this is called the ICNP which is the internet
control message protocol which will go over some other time. But that is the thing that
you'll see when you're pinging or trace routing. You'll sometimes see an ICNP message come
back to you. So as with all the other protocols that we've talked about like TCP and UDP, IP
sure enough attaches its own header to the information that it's sending before it goes
out towards its destination. And this is very similar to everything, you know, to the
TCP and UDP stuff, same kind of stuff. The first thing that the header contains is going
to be the version number. That's the version of IP being used. Then the header length,
which is the total length of the header. And then there's the priority in type of service.
The type of service is 8 bits and it provides an indication of the kind of the quality
of service that's the quality of service thing where it tells you whether it can stand
being delayed or whether it needs to be more reliable than fast or whatever. So they have
all those bits defined. Like bits 0 through 2 are the precedents. Bit 3 is 0 for normal
delay, 1 for low delay. Bit 4 is 0 for normal throughput, 1 for high throughput. Bit 5
is 0 for high reliability, I mean normal reliability, 1 for high reliability, and then bit 6 and 7
reserved for future use. And then there's an identification field which is an identifying
value assigned by the sender, the sending machine, to aid in the reassembling of all the
fragments. And then there are flags. Flags are 3 bits. They define whether the fragmentation
should occur. So this is important because, well, bit 0 is always 0. But then bit 1 is
going to be, if it's set, it means don't fragment. So if you go bit 1 set to 1, it's telling
the computers don't fragment this information. And then there's flags, which the flag contains
the flag contains 3 bits. And this is defining whether fragmentation should occur and how it
occurs. So you've got 0 bit 0, that's reserved, it's always 0. And then bit 1 you've got either
0 for, yes, you may fragment this or 1 for don't fragment. And then bit 2 you've got 0 for this
is the last fragment. And 1 if there are more fragments to come. So that's obviously important
because as you're sending data and a computer's receiving it, if it sees that more fragment
bits set, then it knows there's more to come. And it's going to continue to receive the
information until it's all received. There's the fragment offset field, which is 13 bits. And this
field indicates where in the datagram the fragment belongs. So this is kind of the ordering of
things. This is going to help with the reassembly of the complete datagram. Then there's the time to
live field, which is 8 bits. And this indicates the maximum time that the datagram is allowed to
remain in the internet cloud. How long are we going to wait for this datagram to get from the
source to the destination. And at some point you're going to want it to just time out and die. And you'll
usually, you'll get an ICMP message back if that occurs. Next field is a protocol field, which is
going to tell you what kind of protocol IP is going to be using to get something done, whatever
this datagram is. So if it's UDP, this is going to be set to UDP. If it's TCP, ARP, ICMP, whatever,
each of those have a little number that it's been assigned and that number is given there. And then
there's the header check sum, which again, this is just check something the header. This is just
verifying that, for instance, the protocol field came through uncorrupted. So, you know, I see
something that says, hey, I'm the UDP. I'm going to be using UDP protocol here. I can check some
that and say, oh, yes, that is true. It is supposed to be UDP and not, you know, ICMP or something
like that. Next field is the source IP address. That's the 32-bit IP address of the center. And then
right after that comes the destination IP address, which is the 32-bit IP address of where you're
sending the data to. And then there's the big option field. Option field is huge. It's got a lot
of different things. Like I said, it's got some securities and time stamp options. It's got some
routing options, things like that. And then finally, after that is your data. That's where all the
data that you're actually sending, that's where it lives. So obviously, we've talked about fragments a lot.
We've talked about fragments with TCP and UDP and IT, you know. So obviously, your data, especially if it's
fairly large amounts of data, it's being fragmented. It's being split up, sent somewhere and then reassembled.
It's a little bit like, you know, the transporter and Star Trek. It's kind of scary, you know, to think that all your
data is getting chopped up like this. It's getting little header files appended or prepended to it. And then it's
getting sent off through different layers and through different, through different networks. So how does it, how does
IP know how to do this? Well, we've just, we've just covered how it addresses, right? It uses a routing table. It
figures out where this destination lives. And then it finally figures out the actual box on that destination network where this
data needs to go to. That's how it addresses. That's simple enough. Simple in the sense that DNS and all that other
stuff is simple. And it turns out that fragmenting is kind of cool too. So we've already talked about the more
fragment flag. Remember that in the header. There's the don't fragment in the more fragment flag. So if there's a more
fragment flag, then the computer, then IP knows that there are more fragments to come. And when it finally reaches the last
fragment, then it knows that obviously there are no more fragments to come and it can reassemble everything safely.
Now, if a datagram wasn't fragmented because it wasn't big enough to need fragmentation, then it has zero fragmentation
information. That is more fragment flag is set to zero and the fragment offset is set to zero. The maximum sized
datagram that can be transmitted through a network is called the MTU. That's the maximum transmission unit. And if you
do an ifconfig on your system right now, right as you're listening to this, you will see where the MTU is set. Just do an
ifconfig and look at any of your active network interfaces. And you will see about on the fourth line where it says
up broadcast running multicast and it says MTU colon 1500. So that's right there. That's your MTU. That's the default size.
That is adjustable, of course, by you. You can make it smaller or larger. Okay, so what happens is that it that IP looks at that data and
says, okay, if the total length of this data is equal to or less than the maximum transmission unit that is MTU, then this
doesn't need to be fragmented. You can pass it on to the next step. And that's that. If is greater than the MTU, however, then it needs to be
fragmented. And the process for that is that it first copies the original internet header. So anything from
you know, everything that's got that this data has in its in its header is copied. The old internet header
length is now set to a new internet header length, right? Because now we've got new sizes for everything. The old total length is set to the new
total length. The old fragment offset is now set to a new fragment offset because everything's been cut up differently. And the old
more fragments flag is now set to the new more fragments flag. That is to say that certainly something that hasn't been
fragmented at all is going to show that there are no more fragments. And now we're going to set that to one show you. Actually, yes, there is another
fragment after this one. At that point, as well, the number of fragments block is going to be set. And you that'll be calculated, you know, defined by how many
fragments were going to end up with. And then we're going to attach the first number of fragment blocks, correct the header with the facts that there are more
fragments that there's a new total length. We're going to recompute the checks on. And then we're going to send on this little fragment to the next step in the
process. All of that for the first fragment. Okay, now we've just done. We've calculated how large the data is. We make a fragment. We process it and we
send it off. And then it's going to have to do all that again for the second fragment and the third fragment. However many fragments that needs in order to
fit it into that into you minute, that's what it's going to do over and over again. The only exception there would be the final fragment, the last fragment. And that is, of course, is going to know to set the more
fragment flag back to zero. And the fragment offset flag to zero so that now we have no fragmentation data in the last fragment so that the receiving end knows, okay, I've just received the final fragment. And that's how
IP manages to fragment all your data into lots of little data grams and send them across the world and have them be reassembled on the other end. Once again, this is just doing addressing and fragmentation. It doesn't
not establishing a virtual circuit. It's not doing any of that kind of thing. That's up to TCP or UDP or whatever protocol you end up using. All IP is
concerned with is the address of the of the destination and the source. How to get it there the fastest, especially since there's this time to live kind of deadline, where if it can't get the data from you to your
destination within the time allowable within that time to live field, then the data is going to die and the host is going to be declared unreachable or that there was a package timeout or whatever. And again, all that kind of information, all the feedback that you're getting
after after those kinds of errors occur occurs in ICMP, the internet control message protocol. And that is exactly what we will cover in the next networking basics episode. We'll do ICMP and probably ARP or SMNP or just other random little protocols like that that are helping all this internet magic work.
That's about all I've got on IP. So I hope that helps RSC 791 is what you're going to want to refer to if you want more information on this. It's an exhaustive document.
And I don't mean exhausting, but exhaustive. It has a ton of information in it. It's a real pleasure to read. So that's RSC 791.
You can search that on the internet. It'll come up probably an IEFT or whatever that addresses site. No problem. Find it. Read it. It's really good.
You can also refer to IANA.org slash assignments slash protocol, dash numbers to get more information on the protocol numbers of things like TCP and UDP and ARP and all those other different protocols that are mentioned in the
IP headers and hack you can refer to IANA.org for a lot more than that too. That's a good site to check out for some fun. So we'll come back to IANA at some point as well when we're talking more about IP addresses and that kind of scheme and that kind of stuff.
So thanks for listening to HackriPublic Radio. Feel free to submit either a networking-based episode if you know more about the stuff that I do or if you're playing around on networks and have found some cool things to try or cool things to do.
Or if you've recently broken your network and want to share the ways that you've broken your network or maybe your neighbor's network.
Whatever you've done, you know, if it's worthy of a HackriPublic Radio episode, I'm sure people are going to really be interested in hearing it so record it and send it in. I'm sure it'll be very fascinating.
HackriPublic Radio is a community-based podcast of course. So the more people we have contributing, the more variety we get to hear, the cooler stuff we all get to learn.
So thanks for listening and I will talk to you next time.
Thank you for listening to HackriPublic Radio.
HPR is sponsored by Carol.net so head on over to C-A-R-O dot-N-C for all of us here.
Thank you.