Protocols are a part of our everyday existence. We follow protocols in everything we do. Put simply, protocols are rules for doing things. You may say 'I walk the wild side and so rules or protocols apply to me', well then you are sadly mistaken. You have `set' yourself the `rule' that you will not follow any rules. Hence not following any rules becomes your rule and hence your protocol.
So much for protocols. Lets get to the point, you are here to know and understand PPP, which stands for the Point to Point Protocol. As of today, the most common means of surfing the Internet is via a 'dial-up service'. Remember we said the `most common means'. People using other services like radio links or leased lines belong to the `chosen' community and don't have to worry about these protocols. The Ethernet approach to the 'Net necessitates the use of Ethernet based protocols so check out our tutorial on them if you are interested.
PPP comes into play when you establish a connection to your ISP (Internet Service Provider) via a modem. The name PPP comes from the fact that when you are connected to your ISP, the ISP and you make up two points on the network hence the protocol that is used to get things `happening' between the two of you is the Point to Point Protocol or the PPP.
Danger ahead!!!
Non-techies please watch out as we are about to use some really techno-junkie terms. Don't worry about them too much, though, we will explain each in details in subsequent sections.
PPP is used to carry out the following functions
Remember the good old days when you used to smuggle comics and other goodies past your guardians. To do this, you hid the books behind more `acceptable' stuff. As you grew up, the magazines changed but the modus operandi remained the same. Well this is all there is to know about encapsulation. But why do we need encapsulation in computers?
Well here goes. As we are using a `dial-up service' we have to use a modem (obviously!). You would have realized by now that your modem is not as dumb as it looks. Well if it was so dumb then you would not have paid through your nose to get yourself one of those `high-end modems'. So as the story goes, the modem also has an instruction set. These instructions are in the forms of numbers from 0 to 20 (hex) which have been burnt into the memory of your modem. It might so happen that one fine day you are connected to the 'Net and you are sending an important file, the data moving through your modem. The file may contain a byte which part of the modem instruction set. To your horror you find your modem doing strange things. It might even disconnect your line. Now the million dollar question is how do we send this byte without having to pull out your hair in the process.
Time to time travel again. Let's go back to our school days. Assume the nasty byte is our favorite magazine and the modem happens to be our guardian. So what do we do? Simple, use an acceptable cover for our magazine. Well the same applies here. In PPP we use an acceptable byte 0x7d. As we are supposed to be techies, we call the 0x7d byte the escape character. The byte following the escape byte is XORed with 0x20 so that its value changes and can pass the modem without any trouble. Here's what we have to do. Shown below is a practical example of how we escape 0x03 (chosen at random, no bias whatsoever) .
0x03
| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 |
| 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
0x20
| 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
| 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
0x23
| 0 | 0 | 1 | 0 | 0 | 0 | 1 | 1 |
| 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
As seem from the diagram the sixth bit of the number to be escaped(0x03) is complemented (or inverted) to obtain the escaped character. In the data stream the escaped character is superseeded by a 0x7d. Now the question is should you escape an authentic 0x7d in the data stream. If you answered yes then we must admit that you are fast at learning. The authentic 0x7d must also be escaped and it becomes 0x5e. Now that you know all about escaping characters its time to move on.
All PPP data streams start and end with a 0x7e (It goes without saying that all occurrence of 0x7e inside the packets are also escaped). Its high time that we actually saw a PPP data packet. This will help us in our attempts at understanding PPP
LCP Configure Request Received
| Actual bytes | Unescaped bytes | Description |
| 7e | 7e | Flag |
| ff | ff | Control |
| 7d | ||
| 23 | 03 | Address |
| c0 | c0 | Link Control Protocol |
| 21 | 21 | |
| 7d | ||
| 21 | 1 | Configure Request |
| 49 | 49 | id |
| 7d | ||
| 20 | 0 | Length |
| 7d | ||
| 34 | 14 | |
| 7d | ||
| 22 | 2 | Code (ACCM) |
| 7d | ||
| 26 | 6 | Length |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 2a | a | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 25 | 5 | Code (Magic Number) |
| 7d | ||
| 26 | 6 | Length |
| 7d | ||
| 24 | 4 | |
| dd | dd | |
| ef | ef | |
| 7d | ||
| 3f | 1f | |
| 7d | ||
| 27 | 7 | Code -Addr & Ctrl Compression |
| 7d | ||
| 22 | 2 | Length |
| 7d | ||
| 28 | 8 | Code - Protocol Compression |
| 7d | ||
| 22 | 2 | Length |
| 41 | 41 | Checksum |
| d8 | d8 | |
| 7e | 7e | Flag |
Fig 1: The first PPP data packet
The machine at the other end unescapes the bytes to give you the original data which is now available for user manipulation. The packet starts and ends with a 0x7e. The second byte, 0xFF is the control byte. This is the start of the HDLC (High level Data Link Control) frame which is an integral part of PPP. The third byte is 0x03 and is called the address field. By now you would have realized the rationale behind 0x7d preceding 0x23. We have escaped the 0x03.
The third and second last bytes in a PPP packet is composed of the FCS or the Frame Check Sequence. People call it by other exotic names like checksum or CRC. They all mean the same thing. The moral of the whole story is that PPP has in-built error detection. The FCS is generated by a program, one of which has already been written and can be downloaded as and when required. The FCS involves some really complicated mathematical computations which are beyond the scope of ordinary mortals like us. Now you know everything about encapsulation lets move over to the next item on our agenda, Link control .
The link control is used during the starting phase of establishing the link also called the link establishment phase. To do so PPP uses a protocol called the Link Control Protocol or the LCP
As soon as a connection to the ISP is made, a lot of interesting questions must be answered before the link between peers can be safely established. An LCP packet can be easily recognized as the numbers 0xC0 0x21 appear immediately after the start of the HDLC frame. Each LCP packet also has a type, which in the case of the packet displayed above, is 0x01(escaped = 0x7d 0x21) This means that the packet shown is a Configure Request. The various options are:-
LCP configurations or negotiations (as they are called) are a bit like negotiating with a union. The workers representatives put forward their demands and you see if you accept them. Then you put forward your conditions and the workers ruminate and answer you with a yes or a no. If a condition is not negotiated, it's default value is accepted. Yet sometimes it isn't that simple and both parties have to sit down and hack the solution out. The options like NAK and REJECT may seem to be interchangeable but this is far from the truth. In case of a NAK the peer says that the option is not acceptable but negotiable. However in case of a REJECT the peer says that the option is not acceptable and not negotiable. The other options are self explanatory.
In this configure request, our ISP is offering certain conditions under which a link can be established. It's up to us whether to accept or reject them or perhaps negotiate a mutually acceptable solution.
After the type comes the packet ID, which unlike in IP, is very important here. When we respond to a packet, the PPP peer at the other end should know which packet is being responded to, so the ID's must match. In the start of an LCP connection, right after the authentication, you'll see lots of junk appear on the screen. This junk is the first LCP configure request being sent over and over again. Notice that the 0x7E appears as a ~. The packets are identical, except for the ID, which keeps being incremented by one every time.
Right after the ID comes the two byte length field which is 0x14, or 20 decimal. This includes the Type ID and the two bytes of the length field itself, leaving only 16 decimal for the data.
| 1 | 49 | 0 | 14 | 2 | 6 | 0 | a | 0 | 0 | 5 | 6 | 4 | dd | ef | 1f | 7 | 2 | 8 | 2 |
The first byte after the length is 0x02, which stands for Modem Control Characters, or so says the RFC. After that comes one byte of the length, which is 0x06, leaving only four bytes for the data. These things follow a certain format. The first byte will be the code number which will be one defined in the relevant RFC. After that will come the length of the complete structure which will include the code, data and the length bytes themselves. The data is information for the preceding code number and it's meaning can only be properly understood by reading the RFC's.
After this comes 0x05, which is a magic number, to be explained later. Then comes the length and after that four bytes of the data. Right after that we have 0x07 which tells us that Address and the Control Field compression is on, so once the IP packets start flowing, we'll save three bytes by not send the 0xFF 0x7d 0x23 every time. The length is 0x02, so there's no data. Then we have 0x08, which means Protocol field compression should be on. This means that once we start sending IP packets over the wire, we won't send the entire IP packet type which is 0x00 0x21 (just like LCP has a type 0xC0 0x21), we'll just send a 0x21 saving one byte on transmission. The length is two. After that we have the FCS and then the last 0x7E.
Since we have nothing to negotiate, we send our ISP an ACKnowledgment or ACK. This means that we have received their request and give our accent to all their conditions.
LCP - Configure ACK Sent
| Actual bytes | Unescaped bytes | Description |
| 7e | 7e | Flag |
| ff | ff | Control |
| 7d | ||
| 23 | 03 | Address |
| c0 | c0 | Link Control Protocol |
| 21 | 21 | |
| 7d | ||
| 22 | 2 | Configure Ack |
| 49 | 49 | id |
| 7d | ||
| 20 | 0 | Length |
| 7d | ||
| 34 | 14 | |
| 7d | ||
| 22 | 2 | Code (ACCM) |
| 7d | ||
| 26 | 6 | Length |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 2a | a | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 25 | 5 | Code (Magic Number) |
| 7d | ||
| 26 | 6 | Length |
| 7d | ||
| 24 | 4 | |
| dd | dd | |
| ef | ef | |
| 7d | ||
| 3f | 1f | |
| 7d | ||
| 27 | 7 | Code -Addr & Ctrl Compression |
| 7d | ||
| 22 | 2 | Length |
| 7d | ||
| 28 | 8 | Code - Protocol Compression |
| 7d | ||
| 22 | 2 | Length |
| aa | aa | Checksum |
| b1 | b1 | |
| 7e | 7e | Flag |
Fig 2: The second PPP data packet
This is the first PPP packet which we will send to our ISP. The packet is identical to the first one except for the type, which is 0x02 for Configure ACK and the checksum. The ID must remain the same. By sending over all the options present in the first packet, PPP makes double sure that everything is in order.
LCP - Configure Request Sent
| Actual bytes | Unescaped bytes | Description |
| 7e | 7e | Flag |
| ff | ff | Control |
| 7d | ||
| 23 | 03 | Address |
| c0 | c0 | Link Control Protocol |
| 21 | 21 | |
| 7d | ||
| 21 | 1 | Configure Request |
| 7d | ||
| 20 | 0 | id |
| 7d | ||
| 20 | 0 | Length |
| 7d | ||
| 24 | 4 | |
| 7d | ||
| 2d | d | Checksum |
| ef | ef | |
| 7e | 7e | flag |
Fig 3: The third PPP data packet
Now it's our turn to send a LCP Configure Request. Since we have nothing to negotiate, we'll just send a mostly empty packet over. Since we're the ones sending a request, our ID can be anything, we've set it to zero.
LCP - Configure Ack Received
| Actual bytes | Unescaped bytes | Description |
| 7e | 7e | Flag |
| ff | ff | Control |
| 7d | ||
| 23 | 03 | Address |
| c0 | c0 | Link Control Protocol |
| 21 | 21 | |
| 7d | ||
| 22 | 2 | Configure Ack |
| 7d | ||
| 20 | 0 | id |
| 7d | ||
| 20 | 0 | Length |
| 7d | ||
| 24 | 4 | |
| c0 | c0 | Checksum |
| ca | ca | |
| 7e | 7e | flag |
Fig 4: The fourth PPP data packet
VSNL (our much maligned ISP) responds by setting the type to Configure ACK and returning the packet. This is the simplest way we know of configuring LCP. We have now formed a connection with our ISP and are ready to surf the net. But to do such a simple thing we need to have our own IP address. To do this PPP uses another protocol called the Internet Protocol Control Protocol or the IPCP. If your gut feeling is that PPP is the mother of a lot of protocols then you are not for from the truth.
The advantage of PPP is that you can have many protocols running one after the on the same wire. So under PPP you can send DECNet, AppleTalk, IPX/SPX or IP packets. Since we'll be using PPP to get onto the Internet, we'll be sending IP packets. This means we must use a protocol to negotiate and set this link up, so we use IPCP which does just that. In our case, we receive the IPCP packet from our ISP.
IPCP - Configure Request Received
| Actual bytes | Unescaped bytes | Description |
| 7e | 7e | Flag |
| ff | ff | Control |
| 7d | ||
| 23 | 03 | Address |
| 80 | 80 | IPCP |
| 21 | 21 | |
| 7d | ||
| 21 | 01 | Configure Request |
| 28 | 28 | id |
| 7d | ||
| 20 | 00 | Length |
| 7d | ||
| 2a | 0a | |
| 7d | ||
| 23 | 03 | Type - IP Address |
| 7d | ||
| 26 | 6 | Length |
| ca | ca | |
| 36 | 36 | |
| 7d | ||
| 21 | 1 | |
| 7d | ||
| 38 | 18 | |
| 7d | ||
| 2c | 0c | checksum |
| df | df | |
| 7e | 7e | flag |
Fig 5: The first IPCP packet
Since this is a PPP packet, the initial bytes are the same as before. The difference is in the protocol type field. Instead of 0xC0 0x21, we have a 0x80 0x21 there, which stands for IPCP. After that we have the type which is 0x01 for Configure Request. We have Configure Requests and ACKs under IPCP too, to maintain a certain amount of standardization. Then we have the ID and the length. After these two, we have a 0x03 which means that this packet will be used to get an IP address from the ISP. After all, the reason we're using PPP in the first place is because all of us can't afford a router so we have to share them through PPP. To be on the Internet we need an IP address and the IPCP protocol is geared to do just that. After the type we have the length again, and then an IP address in hex. The IP address specified here, 202.54.1.18 in not our IP address, it is VSNL's
IPCP - Configure ACK Sent
| Actual bytes | Unescaped bytes | Description |
| 7e | 7e | Flag |
| ff | ff | Control |
| 7d | ||
| 23 | 03 | Address |
| 80 | 80 | IPCP |
| 21 | 21 | |
| 7d | ||
| 22 | 02 | Configure Ack |
| 28 | 28 | id |
| 7d | ||
| 20 | 00 | Length |
| 7d | ||
| 2a | 0a | |
| 7d | ||
| 23 | 03 | Type - IP Address |
| 7d | ||
| 26 | 6 | Length |
| ca | ca | |
| 36 | 36 | |
| 7d | ||
| 21 | 1 | |
| 7d | ||
| 38 | 18 | |
| 65 | 65 | checksum |
| ab | ab | |
| 7e | 7e | flag |
Fig 6: The second IPCP packet
Now we don't want VSNL's IP address, we want ours, so we just ACK his request and hope for the best.
IPCP - Configure Request Sent
| Actual bytes | Unescaped bytes | Description |
| 7e | 7e | Flag |
| ff | ff | Control |
| 7d | ||
| 23 | 03 | Address |
| 80 | 80 | IPCP |
| 21 | 21 | |
| 7d | ||
| 21 | 01 | Configure Request |
| 7d | ||
| 21 | 01 | id |
| 7d | ||
| 20 | 0 | Length |
| 7d | ||
| 2a | 0a | |
| 7d | ||
| 23 | 03 | Type - IP Address |
| 7d | ||
| 26 | 6 | Length |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 33 | 13 | checksum |
| 28 | 28 | |
| 7e | 7e | flag |
Fig 7: The third IPCP packet
We send a Configure Request where the code is 0x03 as usual. In our IP address field, we simply go and put four zeros. This means that we're requesting VSNL to give us IP address 0.0.0.0. Our ISP obviously cannot grant this request, so they send us a Configure NAK or Not ACKnowledge and the fun really starts.
IPCP - Configure Nak
| Actual bytes | Unescaped bytes | Description |
| 7e | 7e | Flag |
| ff | ff | Control |
| 7d | ||
| 23 | 03 | Address |
| 80 | 80 | IPCP |
| 21 | 21 | |
| 7d | ||
| 23 | 03 | Configure Nak |
| 7d | ||
| 21 | 01 | id |
| 7d | ||
| 20 | 0 | Length |
| 7d | ||
| 2a | 0a | |
| 7d | ||
| 23 | 03 | Type - IP Address |
| 7d | ||
| 26 | 6 | Length |
| ca | ca | |
| 36 | 36 | |
| 7d | ||
| 23 | 3 | |
| 32 | 32 | |
| a4 | a4 | Checksum |
| ff | ff | |
| 7e | 7e | flag |
Fig 8: The fourth IPCP packet
A Configure NAK means that we do not accept your conditions, but we are willing to negotiate. In it's NAK, VSNL offers us the IP address 202.54.3.50. We are at the liberty of either accepting it by ACKing the response or NAKing and re-negotiate for a different IP address.
IPCP - Configure Request Sent
| Actual bytes | Unescaped bytes | Description |
| 7e | 7e | Flag |
| ff | ff | Control |
| 7d | ||
| 23 | 03 | Address |
| 80 | 80 | IPCP |
| 21 | 21 | |
| 7d | ||
| 21 | 01 | Configure Request |
| 7d | ||
| 21 | 01 | id |
| 7d | ||
| 20 | 0 | Length |
| 7d | ||
| 2a | 0a | |
| 7d | ||
| 23 | 03 | Type - IP Address |
| 7d | ||
| 26 | 6 | Length |
| ca | ca | |
| 36 | 36 | |
| 7d | ||
| 23 | 3 | |
| 32 | 32 | |
| b5 | b5 | Checksum |
| d2 | d2 | |
| 7e | 7e | flag |
Fig 9: The fifth IPCP packet
We being the inhabitants of the land of the Gandhi, believe in humility and hence will accept the IP address offered to us. To do this we will send VSNL a Configure Request, requesting to be assigned the IP address specified in the Configure NAK displayed above. VSNL will now ACKnowledge this request and then grant it to us.
IPCP - Configure ACK Received
| Actual bytes | Unescaped bytes | Description |
| 7e | 7e | Flag |
| ff | ff | Control |
| 7d | ||
| 23 | 03 | Address |
| 80 | 80 | IPCP |
| 21 | 21 | |
| 7d | ||
| 22 | 02 | Configure Ack |
| 7d | ||
| 21 | 01 | id |
| 7d | ||
| 20 | 0 | Length |
| 7d | ||
| 2a | 0a | |
| 7d | ||
| 23 | 03 | Type - IP Address |
| 7d | ||
| 26 | 6 | Length |
| ca | ca | |
| 36 | 36 | |
| 7d | ||
| 23 | 3 | |
| 32 | 32 | |
| 83 | 83 | Checksum |
| d3 | d3 | |
| 7e | 7e | flag |
Fig 10: The sixth IPCP packet
This is it! Our ISP has ACKed our request and so we've got our IP address. Now the IP packets can begin to flow!! Time to starts surfing. Don't worry about any nasty bytes in the data stream, they have been taken care of by the encapsulations and escape characters. It so happens that besides establishing a link to your ISP, PPP is also responsible for the maintenance of the link during a session. PPP is not responsible for bad telephone lines and the resulting 'line drops'. PPP keeps checking the presence (or absence) of the modem at the client end by using the `Echo request & reply option'.
To understand these options lets use an simple analogy. Assume that you are conversing with someone on the phone How do you know that your friend's phone has not been accidentally disconnected during your talk 'session'. Simple, you hear his/her (where applicable) voice and know that he/she is there. PPP uses the same technique. The modem at the ISP's end keeps sending an Echo Request to the your modem every 10 seconds. You must reply to this request. This is called the Echo Reply. In case the ISP's modem fails to receive a reply to the Echo Request it assumes that the modem at the client end is 'dead' or off-line. The Echo Request packet is shown below. LCP - Echo Request Received
| Actual bytes | Unescaped bytes | Description |
| 7e | 7e | Flag |
| ff | ff | Control |
| 7d | ||
| 23 | 03 | Address |
| c0 | c0 | Link Control Protocol |
| 21 | 21 | |
| 7d | ||
| 29 | 9 | Echo Request |
| 7d | ||
| 21 | 1 | id |
| 7d | ||
| 20 | 0 | Length |
| 7d | ||
| 2c | c | |
| 7d | ||
| 24 | 4 | |
| dd | dd | |
| ef | ef | |
| 7d | ||
| 3f | 1f | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 30 | 10 | checksum |
| 8f | 8f | |
| 7e | 7e | flag |
Fig 11: The PPP packet
The packet which tells the ISP's modem that your modem is not off-line is shown below. This packet should be held in great reverence as it ensures that you are not disconnected by your ISP midway through a session.
LCP Echo Reply Sent
| Actual bytes | Unescaped bytes | Description |
| 7e | 7e | Flag |
| ff | ff | Control |
| 7d | ||
| 23 | 03 | Address |
| c0 | c0 | Link Control Protocol |
| 21 | 21 | |
| 7d | ||
| 2a | a | Echo Reply |
| 7d | ||
| 21 | 1 | id |
| 7d | ||
| 20 | 0 | Length |
| 7d | ||
| 2c | c | |
| 7d | ||
| 24 | 4 | |
| dd | dd | |
| ef | ef | |
| 7d | ||
| 3f | 1f | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| 20 | 0 | |
| 7d | ||
| fe | fe | checksum |
| 7d | ||
| 28 | 8 | |
| 7e | 7e | flag |
Fig 12: The PPP packet
Now we know all the bytes that will be floating around when we make a connection. Don't you think it would be a bright idea if we could actually write programs to generate the bits and bytes that that flow to and fro through the system. So don't sit there & stare at the screen. Check out those programs now !!!.
Mr. Vijay Mukhi
Ms. Sonal Kotecha
Mr. Arsalan Zaidi
Mr. Vinesh Kurup
Vijay Mukhi's Computer
Institute
VMCI, B-13, Everest Building, Tardeo, Mumbai 400 034, India
Tel : 91-22-496 4335 /6/7/8/9
Fax : 91-22-307 28 59
e-mail : vmukhi@giasbm01.vsnl.net.in
http://www.vijaymukhi.com