TCP/IP Su|te

1he Deense Adance Research Projects Agency ,DARPA, originally

deeloped 1ransmission Control Protocol,Internet Protocol ,1CP,IP, to
interconnect arious deense department computer networks. 1he Internet,
an international \ide Area Network, uses 1CP,IP to connect goernment
and educational institutions across the world. 1CP,IP is also in widespread
use on commercial and priate networks. 1he 1CP,IP suite includes the
ollowing protocols:
IP , IP6: Internet Protocol.
1CP: 1ransmission Control Protocol.
UDP: User Datagram Protocol.
Data Link Layer
ARP,RARP: Address Resolution Protocol,Reerse Address.
7unn.I1ng jro:o.oIo
A1MP: Ascend 1unnel Management Protocol.
L2l: Layer 2 lorwarding Protocol.
L21P: Layer 2 1unneling Protocol.
PP1P: Point-to-Point 1unneling Protocol.
40 TCP/IP Su|te
Network Layer
DHCP , DHCP6: Dynamic Host Coniguration Protocol.
DVMRP: Distance Vector Multicast Routing Protocol.
ICMP , ICMP6: Internet Control Message Protocol.
IGMP: Internet Group Management Protocol.
MARS: Multicast Address Resolution Serer.
PIM: Protocol Independent Multicast.
RIP: Routing Inormation Protocol.
RIPng or IP6.
RSVP: Resource ReSerVation setup Protocol.
5..ur1:,
AH: Authentication Header.
LSP: Lncapsulating Security Payload.
1ou:1ng
BGP-4: Border Gateway Protocol.
LGP: Lxterior Gateway Protocol.
LIGRP: Lnhanced Interior Gateway Routing Protocol.
GRL: Generic Routing Lncapsulation.
HSRP: Cisco Hot Standby Router Protocol.
IGRP: Interior Gateway Routing.
NARP: NBMA Address Resolution Protocol.
NHRP: Next Hop Resolution Protocol.
OSPl: Open Shortest Path lirst.
1ransport Layer
Mobile IP.
Van Jacobson: compressed 1CP.
XO1: X.25 oer 1CP.
1o11
MGCP: Media Gateway Control Protocol.
SGCP: Simple Gateway Control Protocol.
Session Layer
DNS: Domain Name Serice.
NetBIOS,IP.
TCP/IP Su|te 41
Application Layer
l1P: lile 1ranser Protocol.
1l1P: 1riial lile 1ranser Protocol.
linger: User Inormation Protocol.
Gopher: Internet Gopher Protocol.
H11P: Hypertext 1ranser Protocol.
S-H11P: Secure Hypertext 1ranser Protocol.
IMAP4: Internet Message Access Protocol re 4.
IPDC: IP Deice Control.
ISAPMP: Internet Key Lxchange.
N1P: Network 1ime Protocol.
POP3: Post Oice Protocol ersion 3.
Radius.
RLOGIN: Remote Login.
R1SP: Real-time Streaming Protocol.
SM1P: Simple Mail 1ranser Protocol.
SNMP: Simple Network Management Protocol.
1ACACS-: 1erminal Access Controller Access Control System.
1LLNL1.
X-\indow.
42 TCP/IP Su|te
1he ollowing diagram illustrates the 1CP,IP suite in relation to the OSI
model:
1CP,P iv reatiov to tbe O voae
Data Link
Application
FTP, Telnet, SMTP, POP3
Session
Transport
Network
Presentation
TFTP
NTP
TACACS+, TACACS
X-WIndows
GDP
HTTP
DNS
RLOGIN, RSHELL,
PRINT, REXEC, RWHO
CMOT, SNMP
IMAP4
XOT
DSMCC (MPEG)
ISO DE
NetBIOS-SSN
TCP
DVMRP
TPKT
Physical
RTSP HTTP-S
SSH
RADIUS
ISAKMP
NetBIOS-DGM
Mobile IP
XTP UDP
IGMP
PIM
Trailers
L2F, PPTP,
L2TP, ATMP
RSRB
TDP MPLS
ESP AH
BGP, RIP, GRE, E-IGRP,
NHRP, GGP, HSRP, EGP,
IGRP, OSPF, NARP
BOOTP DHCP
IP
ICMP RSVP
STUN-SDLC
CSLIP
SLIP
ARP, RARP, IARP, SLARP
NetBIOS-NS LDAP
X.25

IP
IL1l RlC 91 1981-09 http:,,www.cis.ohio-state.edu,htbin,rc,rc91.html
IL1l RlC 1853 1995-1 http:,,www.cis.ohio-state.edu,htbin,rc,rc1853.html
1he Internet Protocol ,IP, is the routing layer datagram serice o the
1CP,IP suite. All other protocols within the 1CP,IP suite, except ARP and
RARP, use IP to route rames rom host to host. 1he IP rame header
contains routing inormation and control inormation associated with
datagram deliery.
1he IP header structure is as ollows:
4 8 16 32 bits
Ver. IHL Type of service Total length
Identification Flags Fragment offset
Time to live Protocol Header checksum
Source address
Destination address
Option + Padding
Data
! 0,/07 897:.9:70
Vers|on
Version ield indicates the ormat o the Internet header.
IHL
Internet header length is the length o the Internet header in 32-bit words.
Points to the beginning o the data. 1he minimum alue or a correct header
is 5.
Type of serv|ce
Indicates the quality o serice desired. Networks may oer serice
precedence, meaning that they accept traic only aboe a certain precedence
at times o high load. 1here is a three-way trade-o between low delay, high
reliability and high throughput.
Bits 0-2: Precedence
111 Network control.
110 Internetwork control.
44 TCP/IP Su|te
101 CRI1IC,LCP.
100 llash oerride.
011 llash.
010 Immediate.
001 Priority.
000 Routine.
Bit 3: Delay
0 Normal delay.
1 Low delay.
Bit 4: 1hroughput
0 Normal throughput.
1 High throughput.
Bit 5: Reliability
0 Normal reliability.
1 High reliability.
Bits 6-: Resered or uture use.
Total length
Length o the datagram measured in bytes, including the Internet header and
data. 1his ield allows the length o a datagram to be up to 65,535 bytes,
although such long datagrams are impractical or most hosts and networks.
All hosts must be prepared to accept datagrams o up to 56 bytes,
regardless o whether they arrie whole or in ragments. It is recommended
that hosts send datagrams larger than 56 bytes only i the destination is
prepared to accept the larger datagrams.
Ident|f|cat|on
Identiying alue assigned by the sender to aid in assembling the ragments
o a datagram.
Flags
3 bits. Control lags:
Bit 0 is resered and must be zero.
Bit 1: Dont ragment bit:
0 May ragment.
1 Dont ragment.
IP 45
Bit 2: More ragments bit:
0 Last ragment.
1 More ragments.
Fragment offset
13 bits. Indicates where this ragment belongs in the datagram. 1he
ragment oset is measured in units o 8 bytes ,64 bits,. 1he irst ragment
has oset zero.
T|me to l|ve
Indicates the maximum time the datagram is allowed to remain in the
Internet system. I this ield contains the alue zero, the datagram must be
destroyed. 1his ield is modiied in Internet header processing. 1he time is
measured in units o seconds. Howeer, since eery module that processes a
datagram must decrease the 11L by at least one ,een i it processes the
datagram in less than 1 second,, the 11L must be thought o only as an
upper limit on the time a datagram may exist. 1he intention is to cause
undelierable datagrams to be discarded and to bound the maximum
datagram lietime.
Protocol
Indicates the next leel protocol used in the data portion o the Internet
datagram.
Header checksum
A checksum on the header only. Since some header ields change, e.g., 1ime
1o Lie, this is recomputed and eriied at each point that the Internet
header is processed.
Source address / dest|nat|on address
32 bits each. A distinction is made between names, addresses and routes. A
vave indicates an object to be sought. An aaare.. indicates the location o the
object. A rovte indicates how to arrie at the object. 1he Internet protocol
deals primarily with addresses. It is the task o higher leel protocols ,such
as host-to-host or application, to make the mapping rom names to
addresses. 1he Internet module maps Internet addresses to local net
addresses. It is the task o lower leel procedures ,such as local net or
gateways, to make the mapping rom local net addresses to routes.
4 TCP/IP Su|te
48327
Options may or may not appear in datagrams. 1hey must be implemented
by all IP modules ,host and gateways,. \hat is optional is their transmission
in any particular datagram, not their implementation. In some enironments,
the security option may be required in all datagrams.
1he option ield is ariable in length. 1here may be zero or more options.
1here are two possible ormats or an option:
A single octet o option type.
An option type octet, an option length octet and the actual option data
octets.
1he length octet includes the option type octet and the actual option data
octets.
1he option type octet has 3 ields:
1 bit: Copied lag. Indicates that this option is copied into all ragments
during ragmentation:
0 Copied.
1 Not copied.
2 bits: Option class.
0 Control.
1 Resered or uture use.
2 Debugging and measurement.
3 Resered or uture use.
5 bits: Option number.
+8+
IP data or higher layer protocol header.
:
:
IL1l RlC 1883 http:,,www.cis.ohio-state.edu,htbin,rc,rc1883.html
IL1l RlC 1826 http:,,www.cis.ohio-state.edu,htbin,rc,rc1826.html
IL1l RlC 182 1995-12 http:,,www.cis.ohio-state.edu,htbin,rc,rc182.html
IP ersion 6 ,IP6, is an updated ersion o the Internet Protocol based on
IP4. IP4 and IP6 are demultiplexed at the media layer. lor example,
IP6 packets are carried oer Lthernet with the content type 86DD
,hexadecimal, instead o IP4`s 0800.
IP6 increases the IP address size rom 32 bits to 128 bits, to support more
leels o addressing hierarchy, a much greater number o addressable nodes
and simpler auto-coniguration o addresses. Scalability o multicast
addresses is introduced. A new type o address called an avyca.t aaare.. is also
deined, to send a packet to any one o a group o nodes.
Improved support for extensions and options - IP6 options are placed
in separate headers that are located between the IP6 header and the
transport layer header. Changes in the way IP header options are encoded
allow more eicient orwarding, less stringent limits on the length o
options, and greater lexibility or introducing new options in the uture.
1he extension headers are: Hop-by-Hop Option, Routing ,1ype 0,,
lragment, Destination Option, Authentication, Lncapsulation Payload.
Ilow labeling capability - A new capability has been added to enable the
labeling o packets belonging to particular traic lows or which the sender
requests special handling, such as non-deault Quality o Serice or real-time
serice.
1he IP6 header structure is as ollows:
4 4 16 24 32 bits
Ver. Priority Flow label
Payload length Next header Hop limit
Source address
(128 Bytes)
Destination address
(128 bytes)
Pr beaaer .trvctvre
48 TCP/IP Su|te
Vers|on
Internet Protocol Version number ,IP6 is 6,.
Pr|or|ty
Lnables a source to identiy the desired deliery priority o the packets.
Priority alues are diided into ranges: traic where the source proides
congestion control and non-congestion control traic.
Flow label
Used by a source to label those products or which it requests special
handling by the IP6 router. 1he low is uniquely identiied by the
combination o a source address and a non-zero low label.
Payload length
Length o payload ,in octets,.
Next header
Identiies the type o header immediately ollowing the IP6 header.
Hop l|m|t
8-bit integer that is decremented by one, by each node that orwards the
packet. 1he packet is discarded i the Hop Limit is decremented to zero.
Source address
128-bit address o the originator o the packet.
Dest|nat|on address
128-bit address o the intended recipient o the packet.
$
TCP
IL1l RlC 93 1981-09 http:,,www.cis.ohio-state.edu,htbin,rc,rc93.html
IL1l RlC 102 1988-10 http:,,www.cis.ohio-state.edu,htbin,rc,rc102.html
IL1l RlC 1693 1994-11 http:,,www.cis.ohio-state.edu,htbin,rc,rc1693.html
IL1l RlC 1146 1990-03 http:,,www.cis.ohio-state.edu,htbin,rc,rc1146.html
IL1l RlC 1323 1992-05 http:,,www.cis.ohio-state.edu,htbin,rc,rc1323.html
1he 1ransmission Control Protocol ,1CP, proides a reliable stream
deliery and irtual connection serice to applications through the use o
sequenced acknowledgment with retransmission o packets when necessary.
1he 1CP header structure is as ollows:
4 10 16 32 bits
Source port Destination port
Sequence number
Acknowledgement number
Offset Resrvd U A P R S F Window
Checksum Urgent pointer
Option + Padding
Data
%! 0,/07 897:.9:70
Source port
Source port number.
Dest|nat|on port
Destination port number.
Sequence number
1he sequence number o the irst data octet in this segment ,except when
S\N is present,. I S\N is present, the sequence number is the initial
sequence number ,ISN, and the irst data octet is ISN-1.
Acknowledgment number
I the ACK control bit is set, this ield contains the alue o the next
sequence number which the sender o the segment is expecting to receie.
Once a connection is established, this alue is always sent.
500 TCP/IP Su|te
Data offset
4 bits. 1he number o 32-bit words in the 1CP header, which indicates
where the data begins. 1he 1CP header ,een one including options, has a
length which is an integral number o 32 bits.
Keserved
6 bits. Resered or uture use. Must be zero.
Control b|ts
6 bits. 1he control bits may be ,rom right to let,:
U ,URG, Urgent pointer ield signiicant.
A ,ACK, Acknowledgment ield signiicant.
P ,PSH, Push unction.
R ,RS1, Reset the connection.
S ,S\N, Synchronize sequence numbers.
l ,lIN, No more data rom sender.
W|ndow
16 bits. 1he number o data octets which the sender o this segment is
willing to accept, beginning with the octet indicated in the acknowledgment
ield.
Checksum
16 bits. 1he checksum ield is the 16 bit ones complement o the ones
complement sum o all 16-bit words in the header and text. I a segment
contains an odd number o header and text octets to be checksummed, the
last octet is padded on the right with zeros to orm a 16-bit word or
checksum purposes. 1he pad is not transmitted as part o the segment.
\hile computing the checksum, the checksum ield itsel is replaced with
zeros.
Urgent Po|nter
16 bits. 1his ield communicates the current alue o the urgent pointer as a
positie oset rom the sequence number in this segment. 1he urgent
pointer points to the sequence number o the octet ollowing the urgent
data. 1his ield can only be interpreted in segments or which the URG
control bit has been set.
TCP 501
Cpt|ons
Options may be transmitted at the end o the 1CP header and always hae a
length which is a multiple o 8 bits. All options are included in the
checksum. An option may begin on any octet boundary.
1here are two possible ormats or an option:
A single octet o option type.
An octet o option type, an octet o option length, and the actual option
data octets.
1he option length includes the option type and option length, as well as the
option data octets.
1he list o options may be shorter than that designated by the data oset
ield because the contents o the header beyond the Lnd-o-Option option
must be header padding i.e., zero.
A 1CP must implement all options.
Data
1CP data or higher layer protocol.
1CP,P orer .1M aecoae
502 TCP/IP Su|te
UDP
RlC 68 1980-08 http:,,www.cis.ohio-state.edu,htbin,rc,rc68.html
1he User Datagram Protocol ,UDP, proides a simple, but unreliable
message serice or transaction-oriented serices. Lach UDP header carries
both a source port identiier and destination port identiier, allowing high-
leel protocols to target speciic applications and serices among hosts.
1he UDP header structure is shown as ollows:
16 32 bits
Source port Destination port
Length Checksum
Data
|DP beaaer .trvctvre
Source port
Source port is an optional ield. \hen used, it indicates the port o the
sending process and may be assumed to be the port to which a reply should
be addressed in the absence o any other inormation. I not used, a alue o
zero is inserted.
Dest|nat|on port
Destination port has a meaning within the context o a particular Internet
destination address.
Length
1he length in octets o this user datagram, including this header and the
data. 1he minimum alue o the length is eight.
Checksum
1he 16-bit ones complement o the ones complement sum o a pseudo
header o inormation rom the IP header, the UDP header and the data,
padded with zero octets at the end ,i necessary, to make a multiple o two
octets.
UDP 503
Data
UDP data ield.
504 TCP/IP Su|te
AKP/KAKP
IL1l RlC 826 1982-11 http:,,www.cis.ohio-state.edu,htbin,rc,rc826.html
IL1l RlC 1390 1993-01 http:,,www.cis.ohio-state.edu,htbin,rc,rc1390.html
IL1l RlC 1293 1992-01 http:,,www.cis.ohio-state.edu,htbin,rc,rc1293.html
1CP,IP uses the Address Resolution Protocol ,ARP, and the Reerse
Address Resolution Protocol ,RARP, to initialize the use o Internet
addressing on an Lthernet or other network that uses its own media access
control ,MAC,. ARP allows a host to communicate with other hosts when
only the Internet address o its neighbors is known. Beore using IP, the
host sends a broadcast ARP request containing the Internet address o the
desired destination system.
1he ARP,RARP header structure is shown in the illustration below.
16 32 bits
Hardware Type Protocol Type
HLen (8) Plen (8) Operation
Sender Hardware Address
Sender Protocol Address
Target Hardware Address
Target Protocol Address
.RP,R.RP beaaer .trvctvre
Hardware type
Speciies a hardware interace type or which the sender requires a response.
Protocol type
Speciies the type o high-leel protocol address the sender has supplied.
HLen
Hardware address length.
PLen
Protocol address length.
AKP/KAKP 505
Cperat|on
1he alues are as ollows:
1 ARP request.
2 ARP response.
3 RARP request.
4 RARP response.
5 Dynamic RARP request.
6 Dynamic RARP reply.
Dynamic RARP error.
8 InARP request.
9 InARP reply.
Sender hardware address
HLen bytes in length.
Sender protocol address
PLen bytes in length.
Target hardware address
HLen bytes in length.
Target protocol address
PLen bytes in length.
50 TCP/IP Su|te
ATMP
RlC 210 http:,,www.cis.ohio-state.edu,htbin,rc,rc210.html
1he Ascend 1unnel Management Protocol ,A1MP, is a protocol currently
being used in Ascend Communication products to allow dial-in client
sotware to obtain irtual presence on a user's home network rom remote
locations. A user calls into a remote NAS but instead o using an address
belonging to a network directly supported by the NAS, the client sotware
uses an address belonging to the user's "Home Network". 1his address can
be either proided by the client sotware or assigned rom a pool o
addresses rom the Home Network address space. In either case, this
address belongs to the Home Network and thereore special routing
considerations are required in order to route packets to and rom these
clients. A tunnel between the NAS and a special Home Agent` ,HA,
located on the Home Network is used to carry data to and rom the client.
1he ormat o the A1MP header is shown in the ollowing illustration:
Version Message type Identifier
.1MP acet .trvctvre
Vers|on
1he A1MP protocol ersion must be 1.
Message type
A1MP deines a set o request and reply messages sent with UDP. 1here
are dierent A1MP message types represented by the ollowing alues.
m.ooug.7,j. 7,j. Cod.
Registration Request 1
Challenge Request 2
Challenge Reply 3
Registration Reply 4
Deregister Request 5
Deregister Reply 6
Lrror Notiication
$
./280/6
A 16 bit number used to match replies with requests. A new alue should be
proided in each new request. Retransmissions o the same request should
use the same identiier.
508 TCP/IP Su|te
L2F
RlC 2341 http:,,www.cis.ohio-state.edu,htbin,rc,rc2341.html
1he Layer 2 lorwarding protocol ,L2l, permits the tunneling o the link
layer o higher layer protocols. Using such tunnels it is possible to diorce
the location o the initial dial-up serer rom the location at which the dial-
up protocol connection is terminated and access to the network proided.
1he ormat o the packet is shown in the ollowing illustration:
13 16 24 32
F K P S 0 0 0 0 0 0 0 0 C Ver Protocol Sequence (opt)
Multiplex ID Client ID
Length Payload offset
Packet key (optional)
Payload
Checksum
2| acet .trvctvre
Vers|on
1he major ersion o the L2l sotware creating the packet.
Protocol
1he protocol ield speciies the protocol carried within the L2l packet.
Sequence
1he sequence number is present i the S bit in the L2l header is set to 1.
Mult|plex ID
1he packet multiplex ID identiies a particular connection within a tunnel.
Cl|ent ID
1he client ID ,CLID, assists endpoints in demultiplexing tunnels.
Length
1he length is the size in octets o the entire packet, including the header, all
the ields and the payload.

Payload offset
1his ield speciies the number o bytes past the L2l header at which the
payload data is expected to start. 1his ield is present i the l bit in the L2l
header is set to 1.
Packet key
1he key ield is present i the K bit is set in the L2l header. 1his is part o
the authentication process.
Checksum
1he checksum o the packet. 1he checksum ield is present i the C bit in
the L2l header is set to 1.
Cpt|on Messages
\hen the link is initiated, the endpoints communicate to eriy the presence
o L2l on the remote end, and to permit any needed authentication. 1he
protocol or such negotiation is always 1, indicating L2l management. 1he
message itsel is structured as a sequence o single octets indicating an
option. \hen the protocol ield o an L2l speciies L2l management, the
body o the packet is encoded as zero or more options. An option is a single
octet message type, ollowed by zero or more sub-options. Lach sub-option
is a single byte sub-option alue, and ollowed by additional bytes as
appropriate or the sub-option.
Possible option messages are:
Inalid Inalid message.
L2l_CONl Request coniguration.
L2l_CONl_NAML Name o peer sending L2l_CONl.
L2l_CONl_CHAL Random number peer challenges.
L2l_CONl_CLID Assigned_CLID or peer to use.
L2l_OPLN Accept coniguration.
L2l_OPLN_NAML Name receied rom client.
L2l_OPLN_CHAL Challenge client receied.
L2l_OPLN_RLSP Challenge response rom client.
L2l_ACK_LCP1 LCP CONlACK accepted rom client.
L2l_ACK_LCP2 LCP CONlACK sent to client.
L2l_OPLN_1\PL 1ype o authentication used.
L2l_OPLN_ID ID associated with authentication.
L2l_RLQ_LCP0 lirst LCP CONlRLQ rom client.
L2l_CLOSL Request disconnect.
510 TCP/IP Su|te
L2l_CLOSL_\H\ Reason code or close.
L2l_CLOSL_S1R ASCII string description.
L2l_LCHO Veriy presence o peer.
L2l_LCHO_RLSP Respond to L2l_LCHO.
$
$
IL1l drat
http:,,ino.internet.isi.edu:80,in-drats,iles,drat-iet-pppext-l2tp-11.txt
1he L21P Protocol is used or integrating multi-protocol dial-up serices
into existing Internet Serice Proiders Point o Presence ,hereater reerred
to as ISP and POP, respectiely,. 1his protocol may also be used to sole
the "multilink hunt-group splitting" problem. Multilink PPP, oten used to
aggregate ISDN B channels, requires that all channels composing a multilink
bundle be grouped at a single Network Access Serer ,NAS,. Because L21P
makes a PPP session appear at a location other than the physical point at
which the session was physically receied, it can be used to make all
channels appear at a single NAS, allowing or a multilink operation een
when the physical calls are spread across distinct physical NASs.
1he ormat o the L21P packet is shown in the ollowing illustration:
8 16 32 bits
T L I C F K O 0 0 Ver (3 bits) Length
Tunnel ID Call ID
Ns Nr
AVP
(8 bytes)
21P acet .trvctvre
$
1he 1 bit is 1 or control messages and 0 or payload messages. lor control
messages, the ollowing seen bits must be set to 1001000, making the
header more compatible in encoding with the payload message.

\hen set, this indicates that the Length ield is present, indicating the total
length o the receied packet. Must be set or control messages.

1he I and C bits are resered and must be set to 0. 1hese bit positions
represent options no longer present in L21P.
512 TCP/IP Su|te
F
I the l bit is set, both the Nr and Ns ields are present. l must be set or
control messages.
K
1he K bit is resered and must be set to 0.
C
\hen set, this ield indicates that the Oset Size ield is present in payload
messages.
Ver
1he alue o the er bit is always 002. 1his indicates a ersion 1 L21P
message.
Length
Oerall length o the message, including header, message type AVP, plus
any additional AVP's associated with a gien control message type.
Tunnel ID
Identiies the tunnel to which a control message applies. I an Assigned
1unnel ID has not yet been receied rom the peer, 1unnel ID must be set
to 0. Once an Assigned 1unnel ID is receied, all urther packets must be
sent with 1unnel ID set to the indicated alue.
Call ID
Identiies the user session within a tunnel to which a control message
applies. I a control message does not apply to a single user session within
the tunnel ,or instance, a Stop-Control-Connection-Notiication message,,
Call ID must be set to 0.
Nr
Currently transmitted packet.
Ns
Latest receied packet.
Payload messages hae two additional ields beore the AVP as ollows:
Offset size (16 bits) Offset pad (16 bits)
.aaitiova fiea. iv 21P a,oaa ve..age
$
Cffset s|te
1his ield speciies the number o bytes past the L21P header at which the
payload data is expected to start. It is recommended that data thus skipped
be initialized to 0s. I the oset size is 0, or the O bit is not set, the irst byte
ollowing the last byte o the L21P header is the irst byte o payload data.
AVP
1he AVP ,Attribute-Value Pair, is a uniorm method used or encoding
message types and bodies throughout L21P. 1he ormat o the AVP is
gien below:
16 32 bits
M H 0 0 0 0 Overall length Vendor ID
Attribute
Value
21P .1P .trvctvre
M
1he irst six bits are a bit mask, describing the general attributes o the AVP.
1he M bit, known as the mandatory bit, controls the behaior required o an
implementation which receies an AVP which it does not recognize.
H
1he hidden bit controls the hiding o the data in the alue ield o an AVP.
1his capability can be used to aoid the passing o sensitie data, such as
user passwords, as cleartext in an AVP.
Cverall length
Lncodes the number o octets ,including the oerall length ield itsel,
contained in this AVP. It is 10 bits, permitting a maximum o 1024 bytes o
data in a single AVP.
Vendor ID
1he IANA assigned SMI Network Management Priate Lnterprise Codes
alue, encoded in network byte order.
Attr|bute
1he actual attribute, a 16-bit alue with a unique interpretation across all
AVP's deined under a gien Vendor ID.
514 TCP/IP Su|te
&+9/
1he alue ield ollows immediately ater the Attribute ield, and runs or
the remaining octets indicated in the oerall length ,i.e., oerall length minus
six octets o header,.
%! /0.4/0
$
PPTP
IL1l drat
http:,,ino.internet.isi.edu:80,in-drats,iles,drat-iet-pppext-pptp-04.txt
PP1P ,Point to Point 1unneling Protocol, allows PPP to be channeled
through an IP network. It uses a client-serer architecture to decouple
unctions which exist in current Network Access Serers and support
Virtual Priate Networks. It speciies a call-control and management
protocol which allows the serer to control access or dial-in circuit
switched calls originating rom a PS1N or ISDN, or to initiate outbound
circuit switched connections. PP1P uses a GRL-like ,Generic Routing
Lncapsulation, mechanism to proide a low- and congestion-controlled
encapsulated datagram serice or carrying PPP packets.
1he ormat o the header is shown in the ollowing illustration:
16 32 bits
Length PPTP message type
Magic cookie
Control message type Reserved 0
!!%! 0,/07 897:.9:70
Length
1otal length in octets o this PP1P message including the entire PP1P
header.
PPTP message type
1he message type. Possible alues are:
1 Control message.
2 Management message.
Mag|c cook|e
1he magic cookie is always sent as the constant 0x1A2B3C4D. Its basic
purpose is to allow the receier to ensure that it is properly synchronized
with the 1CP data stream.
51 TCP/IP Su|te
Control Message Type
Values may be:
1 Start-Control-Connection-Request.
2 Start-Control-Connection-Reply.
3 Stop-Control-Connection-Request.
4 Stop-Control-Connection-Reply.
5 Lcho-Request.
6 Lcho-Reply.
Call Management
Outgoing-Call-Request.
8 Outgoing-Call-Reply.
9 Incoming-Call-Request.
10 Incoming-Call-Reply.
11 Incoming-Call-Connected.
12 Call-Clear-Request.
13 Call-Disconnect-Notiy.
Lrror Reporting
14 \AN-Lrror-Notiy.
PPP Session Control
15 Set-Link-Ino.
Keserved
A resered ield, must be set to 0.

DHCP
RlC 1531 http:,,www.cis.ohio-state.edu,htbin,rc,rc1531.html
1he Dynamic Host Coniguration Protocol ,DHCP, proides Internet hosts
with coniguration parameters. DHCP is an extension o BOO1P. DHCP
consists o two components: a protocol or deliering host-speciic
coniguration parameters rom a DHCP serer to a host and a mechanism
or allocation o network addresses to hosts.
1he ormat o the header is shown in the ollowing illustration:
8 16 24 32 bits
Op Htype Hlen Hops
XID
Secs Flags
Ciaddr
Yiaddr
Siaddr
Giaddr
Chaddr (16 bytes)
DCP beaaer .trvctvre
Cp
1he message operation code. Messages can be either BOO1RLQULS1 or
BOO1RLPL\.
Htype
1he hardware address type.
Hlen
1he hardware address length.
XID
1he transaction ID.
518 TCP/IP Su|te
Secs
1he seconds elapsed since the client began the address acquisition or
renewal process.
Flags
1he lags.
C|addr
1he client IP address.
|addr
1he \our` ,client, IP address.
S|addr
1he IP address o the next serer to use in bootstrap.
G|addr
1he relay agent IP address used in booting ia a relay agent.
Chaddr
1he client hardware address.
DHCPv 51
DHCPv
http:,,www.iet.org,internet-drats,drat-iet-dhc-dhcp6-14.txt
1he Dynamic Host Coniguration Protocol or IP6 ,DHCP6, enables
DHCP serers to pass coniguration inormation, ia extensions, to IP6
nodes. It oers the capability o automatic allocation o reusable network
addresses and additional coniguration lexibility. 1his protocol is a stateul
counterpart to the IP6 Stateless Address Autoconiguration protocol, and
can be used separately or together with the latter to obtain coniguration
inormation.
DHCP6 has 6 dierent message types: Solicit, Adertise, Request, Reply,
Release and Reconigure.
DHCP Sol|c|t message
A client transmits a DHCP Solicit message oer the interace to be
conigured, to obtain one or more serer addresses. Unless otherwise noted,
the alue o all ields are set by the client.
8 16 24 25 32 bits
Message type C reserved Prefix-size
Client link local address (16 octets)
Relay address (16 octets)
Saved agent address (16 octets)
DCP oicit ve..age .trvctvre
Message type
Value o 1 speciies a Solicit message.
C
Indicates that the client requests that all serers receiing the message
deallocate the resources associated with the client. \hen set, the client
should proide a saed agent address to locate the clients binding by a
serer.
Pref|x s|te
\hen non-zero, indicates the number o let-most bits o the agent`s IP6
address which conprise the routing preix.
520 TCP/IP Su|te
Keserved
Set to zero.
Cl|ent l|nk local address
IP link local address o the client interace rom which the client issued the
DHCP Request message.
Kelay address
Set by the client to zero. I receied by a DHCP relay this is set by the relay
to the IP address o the interace on which the relay receied the client`s
DHCP Solicit message.
Saved agent address
\hen present, indicates the IP address o an agent`s interace retained by
the client rom a preious DHCP transaction.
DHCP Advert|se message
A DHCP agent sends a DHCP Adertise message to inorm a prospectie
client about the IP address o a serer to which a DHCP Request message
may be sent. \hen the client and serer are on dierent links, the serer
sends the adertisement back through the relay whence the solicitation
came. 1he alue o all ields in the DHCP Adertise message are illed in by
the DHCP serer and not changed by any DHCP relay.
8 16 24 25 32 bits
Message type S reserved Preference
Client link local address (16 octets)
Agent address (16 octets)
Server address (16 octets)
Extensions
DCP .arerti.e ve..age .trvctvre
Message type
Value o 2 speciies an Adertise message.
S
I set, speciies that the serer address is present.
DHCPv 521
Preference
Indicates a serer`s willingness to proide serice to the client.
Cl|ent l|nk local address
IP link local address o the client interace rom which the client issued the
DHCP Request message.
Agent address
IP address o a DHCP agent interace on the same link as the client.
Server address
\hen present, the IP address o the DHCP serer.
Extens|ons
Described in the standard.
DHCP Kequest message
In order to request coniguration parameters rom a serer, a client sends a
DHCP Request message, and may append extensions. I the client does not
know any serer address, it must irst obtain one by multicasting a DHCP
Solicit message. 1ypically, when a client reboots, it does not hae a alid IP
address o suicient scope or the serer to communicate with the client. In
such cases, the client cannot send the message directly to the serer because
the serer could not return any response to the client. In this case, the client
must send the message to the local relay and insert the relay address as the
agent address in the message header.
8 16 24 25 32 bits
Message type C S R rsvd Transaction ID
Client link local address (16 octets)
Agent address (16 octets)
Server address (16 octets)
Extensions
DCP Reqve.t ve..age .trvctvre
Message type
Value o 3 speciies a Request message.
522 TCP/IP Su|te
K
I set, speciies that the client has rebooted and requests that all o its
preious transaction IDs be expunged and made aailable or reuse.
Transact|on ID
Unsigned integer identiier used to identiy this request.
1he remaining ields are described in the Solicit and Adertise messages.
DHCP Keply message
1he serer sends one DHCP Reply message in response to eery DHCP
Request or DHCP Release receied. I the request comes with the S bit set,
the client could not directly send the Request to the serer and had to use a
neighboring relay agent. In that case, the serer sends back the DHCP Reply
with the L bit set, and the DHCP Reply is addressed to the agent-address
ound in the DHCP Request message. All the ields in the DHCP Reply
message are set by the DHCP serer.
8 16 24 25 32 bits
Message type L Status Transaction ID
Client link local address (16 octets)
Extensions
DCP Re, ve..age .trvctvre
Message type
Value o 4 speciies a Reply message.
L
I set, the client link local address is present.
Status
May hae the ollowing alues:
0 Success
16 lailure, reason unspeciied
1 Authentication ailed or nonexistent
18 Poorly ormed Request or Release
19 Resources unaailable
20 Client record unaailable
21 Inalid client IP address in Release
DHCPv 523
23 Relay cannot ind serer address
64 Serer unreachable ,ICMP error,
Transact|on ID
Unsigned integer identiier used to identiy this Reply, copied rom the
client Request.
Cl|ent l|nk local address
I present, the IP address o the client interace which issued the
corresponding DHCP Request message. I the L bit is set, the client`s link-
local address is present in the Reply message. 1hen the Reply is sent by the
serer to the relay`s address which was speciied as the agent-address in the
DHCP Request message, and the relay uses the link-local address to delier
the Reply message to the client. 1he transaction-ID in the DHCP Reply is
copied by the serer rom the client Request message.
DHCP Kelease message
1he DHCP Release message is sent without the assistance o any DHCP
relay. \hen a client sends a Release message, it is assumed to hae a alid IP
address with suicient scope to allow access to the target serer. I
parameters are speciied in the extensions, only those parameters are
released. 1he alues o all ields o the DHCP Release message are entered
by the Client. 1he DHCP serer acknowledges the Release message by
sending a DHCP Reply.
8 16 24 25 32 bits
Message type D Reserved Transaction ID
Client link local address (16 octets)
Agent address (16 octets)
Client address (16 octets)
Extensions
DCP Reea.e ve..age .trvctvre
Message type
Value o 5 speciies a Release message.
524 TCP/IP Su|te
D
\hen set, the client instructs the serer to send the DHCP Reply directly
back to the client instead o using the gien agent address and link local
address to relay the Reply message.
Transact|on ID
Unsigned integer identiier used to identiy this Release, and copied into the
Reply.
1he remaining ields are described in the other DHCP messages.
DHCP Keconf|gure message
DHCP Reconigure messages can only be sent to clients which hae
established an IP address which routes to the link at which they are
reachable, hence, the DHCP Reconigure message is sent without the
assistance o any DHCP relay. \hen a serer sends a Reconigure message,
the receiers are assumed to hae a alid IP address with suicient scope to
be accessible by the serer. Only the parameters which are speciied in the
extensions to the Reconigure message need be requested again by the
client. A Reconigure message can either be unicast or multicast by the
serer. 1he client extracts the extensions proided by the serer and sends a
DHCP Request message to the serer using those extensions.
8 16 24 32 bits
Message type N Reserved Transaction ID
Server address (16 octets)
Extensions
DCP Recovfigvre ve..age .trvctvre
Message type
Value o 6 speciies a Reconigure message.
N
Indicates that the client should not expect a DHCP Reply in response to the
DHCP Request it sends as a result o the DHCP Reconigure message.
1he remaining ields are described in the other DHCP messages.
DVMKP 525
DVMKP
RlC 105: http:,,www.cis.ohio-state.edu,htbin,rc,rc105.html
IL1l drat:
http:,,www.iet.org,internet-drats,drat-iet-idmr-dmrp-3-08.txt
Distance Vector Multicast Routing Protocol ,DVMRP, is an Internet
routing protocol that proides an eicient mechanism or connectionless
datagram deliery to a group o hosts across an internetwork. It is a
distributed protocol that dynamically generates IP multicast deliery trees
using a technique called Reerse Path Multicasting
DVMRP combines many o the eatures o RIP with the 1runcated Reerse
Path Broadcasting ,1RPB, algorithm. DVMRP is deeloped based upon
RIP because an implementation was aailable and distance ector algorithms
are simple, as compared to link-state algorithms. In addition, to allow
experiments to traerse networks that do not support multicasting, a
mechanism called tvvveivg was deeloped.
DVMRP diers rom RIP in one ery important way. RIP routes and
orwards datagrams to a particular destination. 1he purpose o DVMRP is
to keep track o the return paths to the source o multicast datagrams. 1o
make the explanation o DVMRP more consistent with RIP, the term
ae.tivatiov is used instead o the more proper term .ovrce, howeer, datagrams
are not orwarded to these destinations, but rather, originate rom them.
DVMRP packets are encapsulated in IP datagrams, with an IP protocol
number o 2 ,IGMP,. All ields are transmitted in Network Byte Order.
DVMRP packets use a common protocol header that speciies the IGMP
Packet 1ype as DVMRP. DVMRP protocol packets should be sent with the
Precedence ield in the IP header set to Internetwork Control ,hexadecimal
0xc0 or the 1ype o Serice Octet,. 1he common protocol header is as
shown in the ollowing illustration:
8 16 24 32 bits
Type Code Checksum
Reserved Min version Maj version
D1MRP .trvctvre
Type
Packet type. 0x13 indicates a DVMRP packet.
52 TCP/IP Su|te
Code
Determines the type o DVMRP packet. Currently, there are codes or
DVMRP protocol message types as well as protocol analysis and
troubleshooting packets. 1he protocol message codes may be as ollows:
Probe Neighbor discoery.
Report Route exchange.
Prune Pruning multicast deliery trees.
Grat Grating multicast deliery trees.
Grat ack Acknowledging grat messages.
Checksum
16-bit one's complement o the one's complement sum o the DVMRP
message. 1he checksum must be calculated upon transmission and must be
alidated on reception o a packet. 1he checksum o the DVMRP message
should be calculated with the checksum ield set to zero.
Keserved
Resered or later use.
M|n vers|on
Minor ersion. Value must be 0xll or this ersion o DVMRP.
Maj vers|on
Major ersion. Value must be 3 or this ersion o DVMRP.

RlC 92 http:,,www.cis.ohio-state.edu,htbin,rc,rc92.html
Internet Control Message Protocol ,ICMP, messages generally contain
inormation about routing diiculties with IP datagrams or simple
exchanges such as time-stamp or echo transactions.
1he ICMP header structure is shown as ollows:
8 16 32 bits
Type Code Checksum
Identifier Sequence number
Address mask
CMP beaaer .trvctvre
1ype Code Description
0 Lcho reply.
3 Destination unreachable.
3 0 Net unreachable.
3 1 Host unreachable.
3 2 Protocol unreachable.
3 3 Port unreachable.
3 4 lragmentation needed and Dl set.
3 5 Source route ailed.
4 Source quench.
5 Redirect.
5 0 Redirect datagrams or the network.
5 1 Redirect datagrams or the host.
5 2 Redirect datagrams or the type o serice and
network.
5 3 Redirect datagrams or the type o serice and host.
8 Lcho.
11 1ime exceeded.
11 0 1ime to lie exceeded in transit.
11 1 lragment reassemble time exceeded.
12 Parameter problem.
13 1imestamp.
14 1imestamp reply.
528 TCP/IP Su|te
1ype Code Description
15 Inormation request.
16 Inormation reply.
Checksum
1he 16-bit ones complement o the ones complement sum o the ICMP
message starting with the ICMP 1ype. lor computing the checksum, the
checksum ield should be zero.
Ident|f|er
An identiier to aid in matching requests,replies, may be zero.
Sequence number
Sequence number to aid in matching requests,replies, may be zero.
Address mask
A 32-bit mask.
ICMPv 52
ICMPv
IL1l RlC 1885 190, 1995-12
http:,,www.cis.ohio-state.edu,htbin,rc,rc1885.html
1he Internet Control Message Protocol ,ICMP, was reised during the
deinition o IP6. In addition, the multicast control unctions o the IP4
Group Membership Protocol ,IGMP, are now incorporated with the
ICMP6.
1he structure o the ICMP6 header is shown in the ollowing illustration.
8 16 32 bits
Type Code Checksum
CMPr beaaer .trvctvre
Type
1he type o the message. Messages can be error or inormational messages.
Lrror messages can be Destination unreachable, Packet too big, 1ime
exceed, Parameter problem. 1he possible inormational messages are, Lcho
Request, Lcho Reply, Group Membership Query, Group Membership
Report, Group Membership Reduction.
Code
lor each type o message seeral dierent codes are deined.
An example o this is the Destination Unreachable message, where possible
messages are: no route to destination, communication with destination
administratiely prohibited, not a neighbor, address unreachable, port
unreachable. lor urther details, reer to the standard.
Checksum
Used to check data corruption in the ICMP6 message and parts o the
IP6 header.
530 TCP/IP Su|te
IGMP
IL1l RlC 1112 1989-08 http:,,www.cis.ohio-state.edu,htbin,rc,rc1885.html
1he Internet Group Management Protocol ,IGMP, is used by IP hosts to
report their host group memberships to any immediately neighboring
multicast routers. IGMP is a integral part o IP. It must be implemented by
all hosts conorming to leel 2 o the IP multicasting speciication. IGMP
messages are encapsulated in IP datagrams, with an IP protocol number o
2.
1he ormat o the IGMP packet is shown in the ollowing illustration:
4 8 16 32 bits
Ver Type Unused Checksum
Group address
CMP acet .trvctvre
Vers|on
1he protocol ersion.
Type
1he message type:
1 Host Membership Query.
2 Host Membership Report.
Unused
An unused ield.
Checksum
1he checksum.
Group address
In a Host Membership Report Message this ield holds the IP host group
address o the group being reported.