. 52
( 132 .)


is referred to as an IPv6/IPv4 node. The IPv6/IPv4 node has the capability to send and
receive both IPv4 and IPv6 packets, and can therefore interoperate with an IPv4 station
using IPv4 packets and with an IPv6 station using IPv6 packets. The IPv6/IPv4 node
would be con¬gured with addresses that support both protocols, and those addresses
might or might not be related to each other. Figure 5.58 illustrates a station with both
IPv4 and IPv6.

5.10.12 Tunnelling

Tunnelling is a process whereby information from one protocol is encapsulated inside the
frame or packet of another architecture, thus enabling the original data to be carried over
that second architecture. The tunnelling scenarios for IPv6/IPv4 are designed to enable an
existing IPv4 infrastructure to carry IPv6 packets by encapsulating the IPv6 information
inside IPv4 packets.
Figure 5.59 illustrates how two stations that use only the IPv6 protocol can commu-
nicate via an IPv4 network such as the current Internet. The IPv4 packets contain both
an IPv4 header and IPv6 header, as well as all of the upper-layer information, such
as the TCP header, application data, etc. The tunnelling process involves three distinct
steps: encapsulation, decapsulation and tunnel management. At the encapsulating node
(or tunnel entry point), the IPv4 header is created, and the encapsulated packet is trans-
mitted. At the decapsulating node (or tunnel exit point), the IPv4 header is removed
and the IPv6 packet is processed. In Figure 5.59, the encapsulation and decapsulation
is accomplished by the routers, which will have the capability of processing both IPv4
and IPv6.
RFC 1933 de¬nes four possible tunnel con¬gurations that could be established between
routers and hosts:

IPv4 IPv6
protocol protocol
stack stack


IPv4 IPv6

IPv4 IPv6
IPv4 IPv6

physical medium

Figure 5.58 IPv4 and IPv6 support

IPv4 IPv6 packet
IPv6 packet IPv6 packet

Router Router
Workstation Workstation

IPv6 IPv4 tunneling IPv6

Figure 5.59 IPv6 tunnelling

• Router-to-router: IPv6/IPv4 routers that are separated by an IPv4 infrastructure tunnel
IPv6 packets between themselves. In this case, the tunnel would span one segment of
the packet™s end-to-end path.
• Host-to-router: an IPv6/IPv4 host tunnels IPv6 packets to an IPv6/IPv4 router that
is reachable via an IPv4 infrastructure. In this case, the tunnel would span the ¬rst
segment of the packet™s end-to-end path.
• Host-to-host: IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can
tunnel IPv6 packets across the IPv4 infrastructure. In this case, the tunnel spans the
packet™s entire end-to-end path.
• Router-to-host: IPv6/IPv4 routers can tunnel IPv6 packets to an IPv6/IPv4 host which
is the ¬nal destination. In this case, the tunnel would span only the ¬nal segment of
the packet™s end-to-end path.


SLIP (RFC 1055) is an extremely simple protocol which can be used to encapsulate
IP packets on a serial line (or other point-to-point connection). SLIP de¬nes two special
character values, END (192 decimal) and ESC (219) decimal. Figure 5.60 shows the SLIP
packet. Each IP packet is sent as is and terminated with an END character. If the END
character is found inside the packet, two characters are sent instead: ESC END. If ESC
is found then ESC ESC is sent.


IP header Payload 192

Figure 5.60 SLIP packet format

Note that SLIP is only an encapsulation scheme and does not allow the automatic
allocation of IP addresses or other con¬guration information. It also does not support the
negotiation of such things as header compression. For these reasons it has been mainly
replaced by PPP.
Point-to-point protocol (PPP) is a datalink protocol that allow access to the Internet
and other networks using TCP/IP. It is a multi-protocol transport system which can also
transport IPX, AppleTalk and other protocols simultaneously over a single connection.
PPP negotiates con¬guration parameters at the beginning of your connection and these
details are transparent to the user. Further information can be found in RFC 1548.
PPP contains three main components:

1. A derivative of the high-level datalink control (HDLC) protocol for encapsulating
datagrams over serial links.
2. A link control protocol (LCP) to establish, con¬gure and test the datalink connection.
3. A group of network control protocols (NCPs) for establishing different network layer

To establish communication over a point-to-point link, PPP ¬rst sends out LCP frames
to con¬gure and optionally test the link. After the link has been negotiated and con¬gured
there is an optional authentication phase, where one or both parties have to prove their
identity. Finally, PPP sends out NCP packets to negotiate and con¬gure the actual network
layer protocols to be used over the link. Once this is complete then the link can be used
to transfer the actual data packets of the particular protocol setup. Figure 5.61, shows the
PPP packet format, each of the ¬elds in the packet is described below.

5.11.1 LCP link establishment
The ¬rst procedure required when connecting using PPP is link establishment. Figure 5.62
Table 5.16 shows the format of an LCP packet. The code determines the type of packet
and these types are describe in Table 5.18. The basic procedure for opening a connection
is as follows.
The initiator sends a con¬gure-request. This can contain a number of requested link
options, for example the maximum frame size or the authentication protocol for the link.
The responder will respond with one of the following:

• Con¬gure-ack, in which case the options have been accepted and the link is open.
• Con¬gure-nak is used to reject the options requested by the sender but allows for some
renegotiation of the options listed.
• Con¬gure-reject is used to reject the options requested by the sender.

Flag Address Control Protocol Information FCS
8 bits 8 bits 8 bits 16 bits variable 16 bits

Figure 5.61 Point-to-point protocol

Table 5.16 Summary of PPP ¬elds
Field Description
Flag A single byte that indicates the beginning or end of the
frame; it always consists of 01111110
A single byte that is always 11111111 (FFh ), since PPP
does not assign individual layer 2 addresses
Control A single byte that always contains the sequence
00000011, which means that the data will be
unsequenced frames
Protocol Identi¬es the datagram that is being transferred.
Protocols starting with a value of 0“3 indicate the
network layer being transported. A ¬eld starting with
8“b indicates an associated NCP. Values of c“f
indicate link layer control protocols such as LCP. A
number of example protocols and their associated
values are listed in Table 5.17.
Data Zero or more bytes that contain the datagram for the
protocol speci¬ed, i.e. if the protocol carried is IP,
then the user data will be encapsulated within this
packet. The default maximum size for the information
¬eld is 1500 bytes
FCS Frame check sequence for error detection.

Table 5.17 PPP protocol ¬eld
Value Protocol name
0021 Internet Protocol
002b Novell IPX
002d Van Jacobson compressed TCP/IP
002f Van Jacobson uncompressed TCP/IP
8021 Internet Protocol control protocol
802b Novell IPX control protocol
c021 Link control protocol
c023 Password authentication protocol
c223 Challenge-handshake authentication protocol

flag address control protocol code identifier length data
01111110 11111111 3 c021 8-bits 8-bits 16-bits variable FCS

Figure 5.62 PPP LCP packet

To close the link down, the terminate-request is sent followed by a response of the
terminate-Ack. Code-reject is sent if the responder does not understand the code number.
This could happen if different versions of PPP are used on each end of a link. Protocol-
reject is sent if one of the PPP peers has received a PPP packet with an unknown or
unauthorized PPP protocol ¬eld type. Echo-request and echo-reply are used to test the
link, as is discard-request.

Table 5.18 LCP packet codes
Code Name Description
1 Con¬gure-request Requests establishment of link, can include request for options
2 Con¬gure-ack Con¬rms establishment of link
3 Con¬gure-nak Rejects option values requested
4 Con¬gure-reject Rejects options outright
5 Terminate-request Request to close connection
6 Terminate-ack Con¬rms closing of connection
7 Code-reject Unrecognized code value
8 Protocol-reject Packet with unsupported or un-negotiated PPP protocol ¬eld
9 Echo-request Link test
10 Echo-reply Link test
11 Discard-request For test purposes; this packet is discarded silently

5.11.2 PPP authentication
PPP also offers two methods for automating logins: password authentication protocol
(PAP) and challenge-handshake authentication protocol (CHAP). PAP is an insecure
method of authentication since it sends the user™s login name and password unencrypted
across the channel. CHAP, on the other hand, is more secure since the login name and
password are encrypted before being sent across the channel.
CHAP, as described in RFC 1999, is an authentication protocol for use with PPP. Four
messages types are supported.

• challenge: contains the random number;
• response: contains hash of random number plus secret;
• success: indicates that the user was authenticated successfully;
• fail: indicates authentication failed.

Each CHAP message is encapsulated within a PPP frame with a protocol ID of c223.
The basic operation of the protocol is shown in Figure 5.63. In this case user B is request-
ing authentication from user A. User B sends a challenge to user A consisting of a long
random number. User A computes the response using a hash function and the shared
secret and sends this back to the user B. If user B sees that the hash value is correct, user
A is authenticated and success is indicated, otherwise a failure message is returned.
This protocol has a number of important features. Without the original secret the hash
value cannot be computed correctly. As long as the random number is long and random
enough, the challenge will nearly always be different. This makes it very dif¬cult for a
hacker to use recorded responses to fool the authenticating party. Also the password is
not sent over the network (only the hashed value), protecting the shared secret from being
RFC 1999 allows for various hash algorithms to be used but only requires support for
MD5. The algorithm type is negotiated using PPP protocol negotiation. The length of
the response values for MD5 is 16 bytes. The responder will concatenate the identi¬er,

User A User B

Challenge: R1

Response: hash(secret+R1)



. 52
( 132 .)