Section 2 – TCP/IP in a Nutshell
TCP/IP
The DOD developed the Transmission Control Protocol/Internet Protocol, or TCP/IP, in the early
1970s. It was designed to be robust and survive any loss on the network. It provides application protocols
that allow file transfers, electronic mail, host-to-host terminal emulation, and a naming service. The
INTERNIC has the authoritative responsibility to assign IP addresses and IP address ranges for business,
government, and private use.
TRANSPORT
NETWORK
Syslog
Remote Procedure Call (RPC)
Network File Systems (NFS)
TCP
Simple Network Management Protocol
(SMNP)
Directory Name Services (DNS)
Secure Shell Protocl (SSH)
SESSION
File Transfer Protocol (FTP)
PRESENTATION
TELNET
APPLICATION
HyperText Markup Langauge Protocol
(HTTP)
TCP/IP Suite
Simple Mail Transfer Protocol (SMTP)
OSI MODEL
UDP
Transmission Control
Protocol
User Datagram Protocol
ICMP
Internet Control
Message Protocol
IP
Internet Protocol
DATALINK
Ethernet, Token Ring, Token Bus, FDDI, ATM,
Frame Relay, ISDN, X.25
PHYSICAL
Copper, Fiber, Wireless
At the transport layer TCP/IP provides for 2 user protocols and 1 system protocol. The two user
protocols are TCP or Transmission Control Protocol and UDP or User Datagram Protocol. The system
protocol is called the Internet Control Message Protocol or ICMP. These protocols are carried in the IP
packet. Normally, ICMP is not shown when displaying TCP/IP protocol stack against the OSI or DOD
models. Frames carrying IP packets have a protocol identifier of x0800.
Page 1
An IP Packet
TCP and UDP are encapsulated in to the payload of an IP packet. The layout of an IP packet
contains information about the source and destination, fragment controls, error detection, and other options.
Specifically, below is an IP packet in its entirety. The minimum length of an IP packet is 576 bytes. The
maximum size of the packet is 64 Kilobytes. The IP header is either 20 bytes or 24 bytes, depending on the
options and padding fields.
IP Version
4 bits
Header
Length
4 bits
Type of Service
8 Bits
Total Length
16 Bits
Fragment Identifier
16 Bits
Fragment Control
16 Bits
Time To Live (TTL)
8 Bits
00
00
64
20
60
2c
fe
00
97
ea
0c
1b
bf
b9
81
e3
ca
40
00
00
bf
00
8b
00
00
80
00
02
60
06
01
04
97
c4
03
05
bf
5d
ea
b4
ca
c0
00
00
32 08 00 45 68
a8 64 fd c0 a8
00 00 00 60 02
00
Protocol Type
8 Bits
Header CRC
16 Bits
DLC:
bytes.
----- DLC Header ----DLC:
DLC: Frame 1 arrived at
23:37:24.5400; frame size is 60 (003C hex)
DLC: Destination = Station 006097BFCABF
DLC: Source
= Station 006097BFCA32
DLC: Ethertype
= 0800 (IP)
DLC:
IP: ----- IP Header ----IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 68
IP:
011. .... = flash
IP:
...0 .... = normal delay
IP:
.... 1... = high throughput
IP:
.... .0.. = normal reliability
IP: Total length
= 44 bytes
IP: Identification = 60089
IP: Flags
= 4X
IP:
.1.. .... = don't fragment
IP:
..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live
= 128 seconds/hops
IP: Protocol
= 6 (TCP)
IP: Header checksum = C45D (correct)
IP: Source address
= [192.168.100.253]
IP: Destination address = [192.168.100.254]
IP: No options
IP:
TCP: ----- TCP header ----TCP:
TCP: Source port
= 3201
TCP: Destination port
= 139 (NetBIOS-ssn)
TCP: Initial sequence number = 66538
TCP: Data offset
= 24 bytes
TCP: Flags
= 02
TCP:
..0. .... = (No urgent pointer)
TCP:
...0 .... = (No acknowledgment)
TCP:
.... 0... = (No push)
TCP:
.... .0.. = (No reset)
TCP:
.... ..1. = SYN
TCP:
.... ...0 = (No FIN)
TCP: Window
= 8192
TCP: Checksum
= 1BE3 (correct)
TCP:
TCP: Options follow
TCP: Maximum segment size = 1460
TCP:
ADDR HEX
ASCII
0000: 00 60 97 bf ca bf 00 60 97 bf ca 32 08 00 45 68 | .`-.Ê..`-.Ê2..Eh
0010: 00 2c ea b9 40 00 80 06 c4 5d c0 a8 64 fd c0 a8 | .,ê¹@....]..dý..
0020: 64 fe 0c 81 00 8b 00 01 03 ea 00 00 00 00 60 02 | d...‹...ê....`.
0030: 20 00 1b e3 00 00 02 04 05 b4 00 00
| ..ã.....´..
Source Address
32 Bits
Destination Address
32 Bits
TCP/IP Options
32 Bits
Data/Payload
Up to 552 Bytes
Version  currently it has a value of 4
Header Length  the number of 32bit words in the header
Type of Service  A 3 bit (bits 0,1,2) precedence field. 000  Routine packet, 001  Priority Packet, 010
 Immediate Delivery, 011  Flash, 100  Flash Override, 101  Critical, 110  Internetwork Control,
and 111  Network Control. The 5 bit TOS field, can be set to (x can be either 0 or 1): 0000x  0 is
Normal Delay, 1 is Low Delay, 000x0  0 is Normal Throughput, 1 is High Throughput, 00x00  0 is
Normal Reliability, 1 is High Reliability, and xx000  reserved for future use
Total Length  total length, in bytes, of the packet.
Fragment Identification  uniquely identifies the Datagram as belonging to a specific transmission.
Fragmentation control  really 2 fields in one. Flags field (3bits) from highest order to lowest order: Bit 0
 Not used, Bit 1  When set to 1, means don’t fragment, Bit 2  When set to 1, means more fragments
to come, When set to 0, means no more fragments to come. Fragment number field (13bits) is simply the
identifier, or ordered place, of this particular fragment.
Time to live  Maximum number of hops the packet can make.
Protocol  Tells the TCP/IP software, which transport protocol to send the packet to. For example: 6 is
TCP and 17 is UDP
Header Checksum  The CRC only includes a checksum for the Header only.
Source Address  Senders Address
Destination Address  Receivers address
Options  Optional Data.
Page 2
Fragmentation and Reassembly
Fragmentation, the segmenting of an IP Packet in to chunks that can fit in to the MTU of the
underlying infrastructure framing, is handled at Layer 3. The Fragment Identifier and Fragment Control
fields of the IP packet control fragmentation. The Fragment Identifier is a 16bit number that represents all
the components of a particular IP packet, i.e. all the fragments that when put together become 1 IP packet.
The Fragment Control field contains the OFFSET or sequence number for each segment, or fragment, and
the Fragment FLAGS field. The Fragment FLAGS field contains the MF and DF bits which control how
IP packets are fragmented.
IP Version
4 bits
Header
Length
4 bits
Type of Service
8 Bits
Total Length
16 Bits
Fragment Identifier
16 Bits
FLAGS
Fragment Control
16 Bits
Time To Live (TTL)
8 Bits
Protocol Type
8 Bits
Header CRC
16 Bits
Source Address
32 Bits
Destination Address
32 Bits
TCP/IP Options
32 Bits
Data/Payload
Up to 552
Bytes
OFFSET
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
MF Bit
DF Bit
Always
set to 0
RFC 791 & 815 governs fragmentation. When a packet must be fragmented, as in the case when
crossing between different Layer 2 networks, the router performs the following actions:
The router checks the DF, don’t fragment, bit in the FLAGS field of the IP packet. If this bit is set
to 1, then it cannot be fragmented and the router will issue an ICMP Type 3 Code 4, Fragmentation
Needed, to the sending host. If this bit is set to 0, the router will continue the fragmentation process.
The router places the original IP packet’s IP Header Identification Field in to each segment.
The router reduces the TTL of the original packet by 1 then puts this value in to each fragment.
The router then places a value in to the Fragment Offset Field of each fragment. This value denotes the
location of the fragment within the packet based on its offset from the beginning of the packet. This value
is calculated as the number of bytes of the underlying MTU, 1500 for Ethernet, minus the 20 Byte IP
header, times the sequence of the packet, divided by 8. For every segment, the router sets the MF, more
fragments to come, bit to 1 until the last segment is sent. When the last segment is sent the MF bit is set to
0. When set to 0, this bit means last fragment.
Below is a table showing an example of IP Fragmentation and its results on an IP packet that is 6k
with the fragment ID of 11691. Assume a MTU of 1500.
Sequence
0
1
2
3
4
IP Packet Length
6000
Original packet Information
Frag ID
MF Bit
DF Bit
11691
0
0
Offset
0
IP Packet Length
Fragment Packet Information
Frag ID
MF Bit
DF Bit
Offset
Data Left to Tx
0
185
370
555
740
4520
3040
1560
80
0
1500
1500
1500
1500
100
11691
11691
11691
11691
11691
1
1
1
1
0
0
0
0
0
0
Reassembly is the opposing process to fragmentation. Reassembly happens at the destination.
The receiving host orders the IP packet fragments in order of their offset id, low to high and then
reassembles the original packet from the fragments.
Page 3
PMTUD – Path MTU Discovery
Governed by RFC 1191, PMTUD or Path MTU Discovery is a host-based protocol that allows the
detection of the largest common MTU from source to destination. This lowers the amount of IP
fragmentation that is present on a network. PMTUD only works with TCP. The largest common MTU is
detected by sending IP packets at different sizes with the DF bit set to 1. When a router that must fragment
it processes the packet, the router sends an ICMP Type 3 Code 4 to the sending host. That host then
reduces the size of the packet and attempts again until the packet gets through to the destination.
Unfortunately, IP routing devices that have ICMP turned off, due to security concerns, often foil
the PMTUD process. These routers are called blackwhole routers. PMTUD should be shutdown when
used in networks that ICMP is turned off. Each of the following OS support PMTUD: Windows 3.x,
Windows NT, Windows 2K, Windows XP, OS/2, AIX, Linux, Solaris, Sun OS, HP-UX, Windows 9x,
Windows ME, and DOS.
Page 4
IP Addressing
IP Addresses are 32 bit address, grouped in octets, noted in decimal, separated by periods, for
example: 100.232.21.56. The bits are designated as belonging to either the network address or the host
address. A net mask is used designate what bits belong to the network address. The net mask is also 32
bits, grouped in octets, noted in decimal, separated by periods, for example: 255.255.0.0. Hosts attached to
the same network contain the same network number
IP Addresses are grouped in to 4 classes. Each class is identified by a unique bit pattern that is
present at the beginning of the bit stream. The bits used in the host portion of an address cannot be all 1’s.
A host portion that is set to all 1’s is interpreted to mean “all” hosts. The bits used in the host portion of an
address cannot be all 0’s. A host portion that is set to all 0’s is interpreted to mean “this network”.
The addresses 255.255.255.255 and 0.0.0.0 are interpreted as a local, or limited, broadcast. Local, or
limited, broadcasts should not be allowed to traverse any device that operates higher than the Datalink
layer. Any packet with the host portion set to all 1’s or all 0’s is interpreted as a “directed broadcast”.
Directed broadcasts should be allowed to traverse devices above the Datalink layer and will be received by
all hosts on the requested network.
The class A network 10.0.0.0/8, the class B network 172.16.0.0/16, and the class C network
192.168.0.0/16 have been designated as public domain address and do not need to be registered with
INTERNIC. These addresses are referred to in RFC 1918. All others are required to register. INTERNIC
has also reserved the IP address 127.0.0.1 for diagnostic loopback addresses. Frames carrying IP packets
have a protocol identifier of 0800
The TCP/IP Address Classes
Class A IP Address







Range from 1-127
Has the leading bit turned off, i.e. set to 0
Has a network address field that consists of 7 bits
Has a host address field that consists of 24 bits.
Has a classic network mask of 255.0.0.0
There are 126 class A networks
Each network can support 16,777,214 hosts
Class Identifier
Host Address field


0

Network address field
Page 5
Class B IP Addresses







Range from 128..191
The leading bits order is 10
Has a network address field that consists of 14 bits
Has a host address field that consists of 16 bits.
Has a classic network mask of 255.255.0.0
There are 16,382 class B networks
Each network can support 65,534 hosts
Class Identifier

1 0

Network Address Field
Host Address Field

Class C IP Addresses







Range from 192..223
The leading bits order is 110
Has a network address field that consists of 21 bits.
Has a host address field that consists of 8 bits.
Has a classic network mask of 255.255.255.0
There are 2,097,150 class C networks
Each network can support 254 hosts
Class Identifier

1 1 0

Network Address Field
Host Address Field

Class D IP Addresses





Is used as a multicast address, i.e. address a group of hosts
The leading bit order is 1110
Has a network mask of 255.0.0.0
Is used extensively by routing protocols.
Does not represent a network or host address
Class Identifier

1 1 1 0

Multicast Group Address field
Page 6
The IP Subnet Mask
A network mask is used to partition an IP address and designate which bits are to be used for the
network id and which are to be used for the host id. When a bit in the network mask is turned on, set to 1,
it signifies that the bit in the IP address that corresponds to that bit is used for the network address. For
example, given the following information: IP Address 120.1.32.17 with a network mask of 255.0.0.0
120.1.32.17, in binary, is laid out below. Notice the highlighted area. This is the network bits as denoted
by the subnet mask 255.0.0.0 Those bits with in the IP address that have a corresponding bit turned on in
the network mask are part of the network id.
120.1.32.17
0
1
1
255.0.0.0
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
1
0
0
1
0
0
0
0
0
0
0
0
1
0
0
0
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
All the bits in the IP address that correspond to the bits in the network mask do not all have to be
used. The reverse is not true. All the bits in the address that are used to identify the network must be turned
on in the mask whether used or not.
IP Host Routing (Router IDs)
A 32-bit mask may be used when using loopback addresses on a Cisco Router. This address/mask
then becomes the Router ID. Since the mask is 32 bits, any IP address may be used. It is common, and
recommended, that the Router ID of all routers within one’s network be given a Class C address using the
32-bit mask. This will allow for one’s router ids to be able to be routed in the IP routing tables. An
example routing id would be: “10.0.0.9 255.255.255.255”.
Page 7
Configuring IP Addresses on Unix Family OS
Changing the IP address of a Unix or OS/2 machine is very simple. The commands can be typed
at a command line prompt or from a terminal session in X-Windows or through a Telnet session. The
commands are case sensitive and should be type in lower case.
“ifconfig –a” displays what interfaces are in use.
“ifconfig <interface name> down” shuts down an interface.
“ifconfig <interface name> up” turns on an interface.
“ifconfig <interface name> <ip address> netmask <mask>” assigns an IP address to an interface.
Alternatively, edit the following file: “/etc/<hostname>.<interface name>”. “<interface name>” is the
interface name as shown in “ifconfig –a”.
If netmask is not specified the default, classful, net mask will be assigned.
Page 8
Configuring IP Addresses on DOS Family OS
PCTCP by FTP, Inc.
PCTCP is the most common TCP/IP software package for DOS. PCTCP requires that the file
PCTCP.INI be edited to assign an IP address.
Loading PCTCP
In most instances the installation program has created a batch file called AUTOEXEC.BAT
containing the drivers for the FTP software. Below is the source code for the batch file and the output it
produces when running.
The Ethernet BAT file sample source code.
The Token Ring BAT file sample source code
Page 9
The output of the BAT file.
Changing IP addresses in PCTCP
Changing the IP address is easy. First, edit the file C:\PCTCP\PCTCP.INI and change the IP
address parameters in the file; then, reboot or reload the program drivers. The statement “router =” may be
added when a default gateway is needed. It is added 1 line below the “subnet-mask” statement in the
PCTCP.INI file.
Below is the PCTCP.INI file, notice the highlighted area; this is where the IP address, the subnet
mask, and Gateway Address are changed.
Page 10
Simply editing the IP address in the file is not enough. In order for the change to take effect the
software must be unloaded and then reload. This may require the machine to be rebooted. Once reloaded
command “inet status” can be used to check the status of the configuration, as shown below.
An alternate command is “inet config”. This command also displays the configuration
information for the PCTCP software.
Page 11
Configuring IP Addresses on Windows Family OS
To change the IP address of Windows 9x/NT 4.0/2000/XP, right mouse click on the icon for
Network Neighborhood/My Network Places, and click on properties.
To configure NT4, use the protocol tab click on TCP/IP then properties. Under the IP Address tab,
add or change the address, as well as, configure Windows to search for a DHCP server.
Page 12
With Windows 9x, the configuration tab in the network window will have to open before being
able to edit the TCP/IP properties of the particular adapter.
With Windows 2000, right click on “Local Area Connection” to get the connection properties
page. Once there, go to “Internet Protocol (TCP/IP)” properties.
Page 13
With Windows For Workgroups 3.1x, the process is similar: find the “Network” group in the
program manager and click on the “Network Setup” icon.
Once in the “Network Setup” click on TCP/IP stack identifier, most likely it will be “Microsoft
TCP/IP-32 3.11” or better, then “Drivers” button.
Page 14
Then press the “Setup” button.
Once in the TCP/IP configuration all of the TCP/IP parameters will be available for modification.
Page 15
With Windows NT 3.x, find the Main group with in the program manager and double click on
“control panel”.
In control panel, double click on “network”.
Page 16
Select “TCP/IP Configuration” from the “Installed Network Software” and click on “configure”.
Once in the TCP/IP configuration, modify all of the TCP/IP parameters.
Page 17
To check the IP address configuration of a windows machine, except Windows 95, use the
“ipconfig” command to determine what the IP address is and how it was ascertained. The command
option “/all” gives more information on the interfaces in use. The Windows 95 command is “winipcfg”.
The output of “ipconfig /all” is shown below.
The output of Windows 95’s “winipcfg” command is shown below.
Page 18
Configuring IP Addresses on OS/2 Family OS
In addition to the method above, the TCP/IP settings in OS/2 Warp can also be changed in the
following manner:
From the desktop choose the “OS/2 System” icon.
From the “OS/2 System” window choose the TCP/IP icon
Page 19
From the “TCP/IP” window choose TCP/IP configuration icon.
In the TCP/IP configuration window any of the TCP/IP options can be modified.
Page 20
Configuring IP Addresses on Netware Family OS
The Netware family OS configurations are kept in the “Autoexec.ncf” file. This file is executed
when the SYS volume is mounted; it is located in the directory sys:\system. The “Autoexec.ncf” file is a
plain ASCII text file and can be edited from a workstation using any ASCII text editor or from the server
console using the command line “load edit sys:\system\autoexec.ncf” or by “load install” and following the
prompts.
The TCP/IP address can be edited there, for Netware 2.x -> 4.10 Native, or by using “INETCFG”
NLM at the command console, Netware 4.11 -> 5.0. Other TCPIP options can be controlled by
“INETCFG” such as routing protocols and other network layer protocols such as AppleTalk.
Below is an example of the Auotexec.ncf file
SET TIME ZONE = EST5EDT
SET DAYLIGHT SAVINGS TIME OFFSET = 1:00:00
SET START OF DAYLIGHT SAVINGS TIME = (APRIL SUNDAY FIRST 2:00:00 AM)
SET END OF DAYLIGHT SAVINGS TIME = (OCTOBER SUNDAY LAST 2:00:00 AM)
SET TIMESYNC TYPE = SINGLE
SET DEFAULT TIME SERVER TYPE = SINGLE
# SET THE BINDARY CONTEXT OF THE SERVER
# SET BINDERY CONTEXT = O=MYGIRONA
# SET THE SERVER NAME, MUST BE UNIQUE IN ENTIRE NETWORK
FILE SERVER NAME NWFS1
# SET THE SERVERID OR THE INTERNAL IPX NETWORK NUMBER
SERVERID 431FF3E
# CONFIGURE FRAME TYPES ON THE ETHERNET CARD
LOAD 3C90X NAME=IPXNET SLOT=2 FRAME=ETHERNET_802.2
LOAD 3C90X NAME=TCPNET SLOT=2 FRAME=Ethernet_II
# LOAD THE IPX ROUTER AND DENOTE C0A86400 AS THE EXTERNAL NET
LOAD IPXRTR
LOAD IPXRTRNM
BIND IPX IPXNET NET=c0a86400
# LOAD THE IP ROUTER SET RIP OFF, DENOTE SUBNET AS 192.168.100.0/24
LOAD Tcpip RIP=No Static=Yes LoadSharing=No Forward=No
BIND IP TCPNET ARP=Yes Mask=FF.FF.FF.0 Address=192.168.100.252
# Load the NTP for Time Synchronization
NTP
# Load all the console monitoring program
IPXCON
TCPCON
MONITOR
# Load the CDROM control NLM
CDROM
The highlighted portion of the Autoexec.ncf file is where IP and other protocols would be
configured. Novell also provides the inetcfg.nlm that is a menu driven interface, which makes
modifications to all the protocols, and interfaces used on a NetWare file server.
Page 21
Configuring IP Addresses on the MAC OS Family
TCP/IP is available for Mac OS in two forms: native and MACTCP. Both are configured the
same. MACTCP is an add-on on older Mac computers. To configure TCP/IP on an Ethernet interface of
an Apple Macintosh, running native TCP/IP, click on the Apple icon and choose control panels then tcp/ip.
At that point the TCP/IP configuration panel will allow the user to choose the device with witch to
connect to and how to get the configuration. The options in Configure include: Manually, DHCP, BOOTP,
and RARP.
Page 22
Configuring IP Addresses on Cisco Family OS
To configure an interface, on a Cisco Router, from enabled mode enter the terminal configuration
mode, then enter the interface configuration mode, then use the interface command: ip address a.a.a.a
m.m.m.m Replace a.a.a.a with the IP address and m.m.m.m with the network mask. The example below
illustrates the configuration steps for a Token Ring interface.
Enable  Config T  Interface TokenRing #  IP Address <ip address> <net mask>
In the above example, int tok 0 is short for Interface Token Ring 0. Cisco routers can recognize
the shortest unique command. Above, the word “secondary” is used to add more than one IP address to a
single interface. Up to 256 IP addresses can be added to an interface. Interfaces may have options that
need to be set. For example, in the above picture, the command “ring-speed 16” tells the router to set the
interface to 16Mbs speed. On other interfaces, the operator may need to set the media type. In any case,
there should be instructions that come with the interfaces that describe which options are mandatory and
must be set. Now, this configuration may be complete but in order for the interface to function the “no
shutdown” command must be issued after setting the last option at the interface configuration level.
Page 23
IP Addressing and Variable Length Subnet Masking
Up to now the “Classic” network masks have been used to address hosts. There is a problem with
this: Networks are limited to the number of hosts defined by its class. One solution would be to bridge
networks together but this is not recommended. Also, there may be times where bridging is not an option
and one must route between locations that are dispersed over a public or private WAN. Managing the
networks within an administrative domain may become overwhelming. Using a single network and
breaking it down into subnets can make things more manageable. Subneting has the added advantage of
saving IP address space. Routing protocols that use the Classic network mask are said to be “CLASSFUL”
while those who use VLSM are said to be “CLASSLESS”. This should not be confused with Superneting.
VLSM allows the use of more bits to designate a subnetwork within an address space. IP version 4
subnetting is governed by RFC 1878.
To use VLSM, take the address space and lay it out in terms of its bits: for example: 10.0.0.0 and
apply the classic network mask to it, 255.0.0.0
0
1
0
1
0
1
0
1
1
1
0
1
1
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Then calculate the minimum number of bits needed by determining how many subnets are
required. For example, if 7 subnetworks are required then at least 3 bits would be needed to accommodate
the requirement because 7 is 0111b. The left most three bits are used and network mask is adjusted. The
network mask is no longer called a netmask because it is now subnetted, and is now call a SUBNET
MASK.
0
1
0
1
0
1
0
1
1
1
0
1
1
1
0
1
0
1
0
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
The original mask was 255.0.0.0, after subneting it, the mask is 255.224.0.0 The reason for this is
the change in the number of new bits used for the network id. The mask is written as dotted decimal
notation so the second octet of bits is 11100000b, which translates to 224.
The boundaries of the useful networks can be found using this new mask. The right most bit in
the second octet is in the “32” or 25 position. Based on this information it can infer that the subnetworks
border on 32, so the subnets would be 32, 64, 96, 128, 160, 192, and 224.
It should be noted that there is really address space for 8 networks, if the 0 subnet is counted.
Though not always used or implemented the 0 subnet is available for use. To use subnet 0 on a Cisco
router use the following command in global configuration mode: “ip subnet-zero”. Of course, this assumes
classless routing is enabled. To enable classless routing type the command “ip classless” at the global
configuration prompt.
Subnetting Rules



The total number of networks is 2N, where “N” is the number of bits used to designate the subnet.
The total number of hosts is 2N-2, where “N” is the number of bits used to designate the hosts.
Remember hosts cannot be all 1’s or all 0’s.
Remember that a network cannot be all 1’s, and never will be, but a subnet can be all 1’s.
Page 24
IP Superneting and Classless Interdomain Routing
Superneting – Route Summarization
Superneting or route summarization is a process where by shifting the subnet mask to the left
summarizes a network. The effect of this is that multiple contiguous networks can be advertised by 1
single IP address. Poor IP address planning impacts route summarization. The benefits of route
summarization are: lower bandwidth usage, and smaller routing tables.
Here is an example. To summarize: 149.83.120.0/24 through 149.83.127.0/24



Task #1, layout the last octet involved in the network address.
Task #2, Identify all the bits that are shared, unchanged, among the addresses.
Task #3, Identify the right most bits that change among the addresses.
.120
.121
.122
.123
.124
.125
.126
.127


0
0
0
0
0
0
0
0
128
1
1
1
1
1
1
1
1
64
1
1
1
1
1
1
1
1
32
1
1
1
1
1
1
1
1
16
1
1
1
1
1
1
1
1
8
0
0
0
0
1
1
1
1
4
0
0
1
1
0
0
1
1
2
0
1
0
1
0
1
0
1
1
1
0
0
0
Task #4, Compute a netmask based on these bits.
Task #5, Adjust the netmask to the new netmask
Netmask computation = 248
1
1
1
1
Instead of 255.255.255.0, we now have 255.255.248.0

Task #6, Sum the shared, unchanged, bits to get the new network address
Network computation = 120
0
1
1
1
1
0
0
0
Instead of 8 addresses we now have a single address, 149.83.120.0.
The summarized address and mask is 149.83.120.0 255.255.248.0.
CIDR – Classless Interdomain Routing
CIDR is a strategy that looks at an IP address not as classful but as Classless. Routers must now use both
IP and Subnet mask to make routing decisions. Routes can now also be summarized. CIDR calls for a
deployment strategy to lower the amount of routes at the root routers of INTERNIC using route
summarization.
Configuring Summary Routes
Summary routes can be manually configured at the interface configuration prompt with the
following command: ip summary-address <routing-protocol> <supernet number> <supernet mask>.
Where the routing protocol is RIP or EIGRP. When using EIGRP the AS number must be specified after
the routing protocol. An example configuration would be: ip summary address rip 149.83.120.0
255.255.248.0 In OSPF the summary route can be configured in the router configuration prompt using the
command: AREA # RANGE <supernet number> <supernet mask>.
Page 25
TCP/IP, Transmission Control Protocol over IP
The Transmission Control Protocol, or TCP, is a Layer 4 protocol that provides for connectionoriented services. All transmissions are acknowledged. Packet delivery is guaranteed. TCP is a stream
protocol, data is sent as a stream of bytes with no distinguishing borders. This means that it is up to the
application to force a structure on the stream of data. The stream attribute forces TCP to create a virtual
circuit connection. The virtual circuit connection (VCC) is established by the applications on both the
sending and receiving end. Each side monitors the VCC, if a problem occurs; each side detects it and
executes predefined application actions. Full-Duplex communication is available in a VCC. This means an
application can send and receive at the same time. TCP connections are point-to-point and therefore cannot
be used in Broadcast or Multicast communications. The TCP packet contains the “Source Port” and the
“Destination Port”, the sequencing numbers, a checksum, codes bits, header length, and other important
information. Below is an illustration of the TCP Packets with field definitions.
Source Port
16 Bits
Destination Port
16 Bits
Sequence Number
32 Bits
Acknowledge Number
32 Bits
Data Offset
4 Bits
Reserved
6 Bits
Window
16 Bits
Code
6 Bits
Header Checksum
16 Bits
Urgent Pointers
16 Bits
Options
32 Bits
DATA/Payload
DLC:
08
00
05
20








00
2c
fe
00
20
3b
04
0e
7e
84
c9
4a
9e
40
1f
00
de
00
90
00
00
7e
01
02
b0
06
64
04
64
97
0f
11
03
f2
56
28
ce
c6
00
f2
23 08 00 45 00
4a 9c 64 c0 a8
00 00 00 60 02
e5
----- DLC Header ----DLC:
DLC: Destination = Station Sun7E9EDE
DLC: Source
= Station 00B06403CE23
DLC: Ethertype
= 0800 (IP)
DLC:
IP: ----- IP Header ----IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP:
000. .... = routine
IP:
...0 .... = normal delay
IP:
.... 0... = normal throughput
IP:
.... .0.. = normal reliability
IP: Total length
= 44 bytes
IP: Identification = 15236
IP: Flags
= 4X
IP:
.1.. .... = don't fragment
IP:
..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live
= 126 seconds/hops
IP: Protocol
= 6 (TCP)
IP: Header checksum = 97F2 (correct)
IP: Source address
= [198.74.156.100]
IP: Destination address = [192.168.5.254]
IP: No options
IP:
TCP: ----- TCP header ----TCP:
TCP: Source port
= 1225
TCP: Destination port
= 8080
TCP: Initial sequence number = 23334742
TCP: Data offset
= 24 bytes
TCP: Flags
= 02
TCP:
..0. .... = (No urgent pointer)
TCP:
...0 .... = (No acknowledgment)
TCP:
.... 0... = (No push)
TCP:
.... .0.. = (No reset)
TCP:
.... ..1. = SYN
TCP:
.... ...0 = (No FIN)
TCP: Window
= 8192
TCP: Checksum
= 0E4A (correct)
TCP:
TCP: Options follow
TCP: Maximum segment size = 4392
TCP:
ADDR HEX
ASCII
0000: 08 00 20 7e 9e de 00 b0 64 03 ce 23 08 00 45 00 | .. ~....d..#..E.
0010: 00 2c 3b 84 40 00 7e 06 97 f2 c6 4a 9c 64 c0 a8 | .,;.@.~....J.d..
0020: 05 fe 04 c9 1f 90 01 64 0f 56 00 00 00 00 60 02 | .......d.V....`.
0030: 20 00 0e 4a 00 00 02 04 11 28 f2 e5
| ..J.....(..
The header length is in multiples of 32.
Code bits when set to 1 are, (starting from the highest order bit to lowest order bit), URG – urgent
point field is active, ACK – acknowledgement of packet, PSH – segment requests a push, RST –
reset the connection, SYN – synchronize segment numbers, and FIN – sender has reached the end
of its data.
Window bits specify the size of the sliding window.
The checksum is covers the TCP header and Data. A pseudo header is used for this calculation
that consists of the destination and source IP addresses, a byte set to all 0’s, a byte set to 0x06, and
the length of the segment in words.
Urgent Pointer points to data within the data field that requires urgent attention, if any. This field
is optional.
Options can be any type of added information for the receiver, also optional.
Padding, usually in the form of 0s.
The Data is the payload.
Page 26
The TCP Handshake
To establish a TCP connection from one host to another, both hosts perform a handshake. During
this handshake the first host sends a SYN packet with a randomly generated sequence number. The second
host replies with a SYN/ACK with its own randomly generated sequence. And then the original host sends
an acknowledgement. During this time configuration parameters are passed and the TCP sliding window is
determined. The hosts set there “send” window size to the “receive” window size of the other host if it can.
If the host cannot, then it halves the window size until it reaches a size that it can handle. Below is the
handshake illustrated along with segments of sniffer trace. Note that when a host acknowledges a packet it
sends out a sequence number that is one higher than the packet it is acknowledging.
Page 27
Page 28
TCP Sliding Windows
TCP connections use buffers to control the flow of information. The buffers determine how much
data is on the wire at any given time. The protocol governing the use of the TCP buffers is called Sliding
Windows. Sliding Windows has a dramatic effect on network performance. Sliding Windows works on a
send and wait-for-acknowledgement model. Each transmission is acknowledged before the window is
“SLID” to the next element to be transmitted. Below is an example of how sliding windows works.
Window size is determined during the handshake. Initially, for Ethernet, the size of the window is
set to 8760 bytes, or 6 segments of 1460, and incremented by 1460 on each successive request until the
maximum window is reached on one of the systems or 64KB, whichever is first. In the previous captions,
the first PC issues a window size of 8192 bytes, 8192 is 8 packets at 1024 bytes or 8KB. 8KB is the default
window size on Windows based machines. On other operating systems the default window size is 16KB or
16,384 bytes. The second PC responds that it can receive 17520 bytes (1460 x 12 segments), or twice what
the first PC can send. The first PC responds with 8760(1460 x 6 segments) or ½ of 17520, the maximum
frames it can receive. For Token Ring and FDDI the size is 16K or 4096 bytes x 4 segments.
A Sliding Windows Example
Let’s say a machine has a window size of 8, it has data that will take 10 IP packets to send,
assuming a MTU of 1500 bytes, and the data is 15000 bytes or 15KB. The first 8 packets are sent and their
retransmit timers are started. The sending PC then waits for the first series of packets to be acknowledged.
If the retransmit timers expire before the packets are acknowledged, the sending PC retransmits the packets.
1
2
3
4
5
6
7
8
9
10
All packets are sent sequentially but acknowledgements do not have to occur in that same order.
Depending on the reliability of the network, some packets may be lost during transmissions.
For example, say packets 1,2,3,4,5,6,7,8 were sent in order but the receiving host only replied to
2,5,6,7,8 the window stays unchanged until a series of packets, starting at the first packet, get
acknowledged.
Once, the series of packets is acknowledged the window slides. Using the same example, we
receive an acknowledgement for packets 1 and 4. The window slides to the first unacknowledged packet.
In this way the delivery of a packet guaranteed. So, how does the computer know to resend? It
waits a specific amount of time, which is configurable but, usually 2 * RTT, Round Trip Time. Round Trip
Time is the time the packet takes to reach its destination and an acknowledgement for that packet can return
to the sending host. If no response is received the sending host retransmits the unacknowledged packets.
This continues until all the packets are transmitted or the TCP/IP software reaches a preset threshold.
Some hosts can be set to acknowledge several packets received with one acknowledgement. This is called
“packet burst mode”. In packet burst mode, if any one of the packets within a frame are not acknowledged
Page 29
the entire series is retransmitted. This can cause excessive bandwidth utilization due to the fact that an
entire window must be retransmitted.
Each of the packets sent in the stream, as above, is called a segment. Segmentation occurs when
the data is too large to fit in to the payload of an IP packet. The size of the payload, or MTU, is governed
by the bandwidth of the network. Each packet is given an IP segment id and the segment control bits are
set to designate the transmission id and the packet sequence.
TCP uses sequence numbers and acknowledgement numbers to identify the TCP packet and its
respective response. For a TCP packet to be acknowledged, a packet had to be send to a host, who sends a
packet back with the acknowledge number set to the sequence number that is one higher than the one
received. Sequence numbers are also used to reconstruct the data stream if packets do not arrive in the
order.
Terminating a TCP Connection
Much like the TCP connection handshake there is a three way disconnect sequence: FIN ACK,
FIN ACK, ACK.
Page 30
Page 31
UDP/IP, User Datagram Protocol over IP
UDP provides for connectionless oriented services. Transmissions are sent without requiring
acknowledgement. Packet delivery is not guaranteed. No virtual connection is created. Messages do not
have to be acknowledged. Due to these facts, the UDP packet is very simple. Its structure is reflective of
the simplicity of the protocol.
Any application that uses UDP to send/receive messages must compensate for its lack of
robustness. The basic idea behind a UDP packet is to differentiate between multiple destinations within a
host.
DLC:
Source Port
16 Bits
Destination Port
16 Bits
Packet Length
16 Bits
CRC
16 Bits
Data Payload
01
00
00
01
00
30
02
00




5e
00
07
63
00
00
c1
69
00
00
07
73
02
00
c1
63
00
02
00
6f
00
11
1c
00
0c
17
33
00
8d
12
a1
00
ac
c0
00
c0
af
a8
00
a8
08
01
08
01
00 45 00
01 e0 00
03 0a 0a
64
----- DLC Header ----DLC:
DLC: Destination = Multicast 01005E000002
DLC: Source
= Station cisco8DACAF
DLC: Ethertype
= 0800 (IP)
DLC:
IP: ----- IP Header ----IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP:
000. .... = routine
IP:
...0 .... = normal delay
IP:
.... 0... = normal throughput
IP:
.... .0.. = normal reliability
IP: Total length
= 48 bytes
IP: Identification = 0
IP: Flags
= 0X
IP:
.0.. .... = may fragment
IP:
..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live
= 2 seconds/hops
IP: Protocol
= 17 (UDP)
IP: Header checksum = 1712 (correct)
IP: Source address
= [192.168.1.1]
IP: Destination address = [224.0.0.2]
IP: No options
IP:
UDP: ----- UDP Header ----UDP:
UDP: Source port
= 1985 (Cisco HSRP)
UDP: Destination port = 1985 (Cisco HSRP)
UDP: Length
= 28
UDP: Checksum
= 33A1 (correct)
UDP: [20 byte(s) of data]
UDP:
HSRP: ----- Hot Standby Router Protocol (HSRP) Header
HSRP:
HSRP: Version
= 0
HSRP: Opcode
= 0 (Hello)
HSRP: Sending router's state = 8 (Standby)
HSRP: Hello time
= 3
HSRP: Hold time
= 10
HSRP: Router's priority
= 10
HSRP: Group number
= 1
HSRP: Reserved
HSRP: Authentication
= "cisco"
HSRP: IP address
= 192.168.1.100
ADDR HEX
0000: 01 00 5e 00 00 02 00 00 0c 8d ac af 08 00 45 00
0010: 00 30 00 00 00 00 02 11 17 12 c0 a8 01 01 e0 00
0020: 00 02 07 c1 07 c1 00 1c 33 a1 00 00 08 03 0a 0a
0030: 01 00 63 69 73 63 6f 00 00 00 c0 a8 01 64
-----
|
|
|
|
ASCII
..^......•¬¯..E.
.0........ˬ....
...Á.Á..3¡......
..cisco...ˬ.d
Source Port  Port sending the message
Destination Port  Port receiving the message
Message Length  The length, in bytes, of the entire packet, both header and data. By this fact,
the minimum length of an UDP packet is the length of the header or 64bits, or 8 bytes.
Checksum, though not always used, if set to 0 means checksum not in use.
Page 32
IP Ports and Sockets
TCP and UDP use ports, also called sockets, to distinguish an application on a host. Conceptually,
an application requests a port, to be used for network communication from the operating system, which
then, makes the request from the TCP/IP software. This process of differentiating between applications by
the use of port assignments is called Multiplexing/Demultiplexing. There are applications that have been
written and given static ports to use. These applications all have RFC and the ports they use are reserved.
These reserved ports are called the “well known” ports. Ports that are not “well known” are free to be used
by users. The range of user ports, not “well known” ports, is called the ephemeral range. The ephemeral
range starts at port 1025 and runs to 65535. Ports 1 through 512 are reserved for well-known applications,
such as TELNET, FTP, and FINGER. UNIX uses ports 513 through 1024 for other applications. On most
computers with TCP/IP software the list of ports that are reserved is kept in a file called the services file.
This file is located is the following areas (based on operating system):
Operating System
Windows 9x
DOS
Windows 3.x
Unix/Linux/Solaris
OS/2
File Location
C:\WINDOWS
C:\DOSTCP\ETC
C:\WINDOWS
\ETC
C:\MPTN\ETC
File Name
SERVICES
SERVICES
SERVICES
SERVICES
SERVICES
Below is an example of the SERVICES file. Note that each protocol has a port number, and that
each port number can be shared between the two protocols TCP and UDP.
echo
echo
daytime
daytime
chargen
chargen
ftp-data
ftp
telnet
smtp
time
time
domain
domain
bootps
bootpc
tftp
gopher
finger
http
7/tcp
7/udp
13/tcp
13/udp
19/tcp
19/udp
20/tcp
21/tcp
23/tcp
25/tcp
37/tcp
37/udp
53/tcp
53/udp
67/udp
68/udp
69/udp
70/tcp
79/tcp
80/tcp
ttytst source
ttytst source
mail
timserver
timserver
#Character generator
#Character generator
#FTP, data
#FTP. control
#Simple Mail Transfer Protocol
#Domain Name Server
#Domain Name Server
#Bootstrap Protocol Server
#Bootstrap Protocol Client
#Trivial File Transfer
dhcps
dhcpc
www www-http
Page 33
#World Wide Web
ICMP/IP, Internet Control Message Protocol over IP
ICMP is not usually shown in the TCP/IP stack diagram due to the fact that it was not meant to be
used by the user but rather the TCP/IP software. It is an implementation of a protocol to pass error
messages and “control” messages, such as redirection, between routers and host. ICMP is a very simple
protocol. It is an error reporting protocol not error correcting. In other words, ICMP can only report a
problem, it cannot fix it. There are several different types of ICMP messages. Below is a short list of those
messages along with the packet format and field definitions:
Message Type
Type Field Identifier
Echo Reply
0
Destination Unreachable
3
Source Quench
4
Redirect
5
Echo Request
8
TTL Expired
11
Parameter Error
12
Timestamp Request
13
Timestamp Reply
14
Information Request*
15
Information Reply*
16
Netmask Request
17
Netmask Reply
18
ICMP Packet - Basic
At its most basic implementation the ICMP message format simply contains a Type field, an 8 Bit
code enhancement filed and a 16 Bit CRC.
Type
Code
CRC
8 Bits
8 Bits
16 Bits
ICMP DATA
ICMP Echo Request / Reply Message
Used by common applications, like PING and TRACEROUTE, this ICMP packet is sent with a
string of characters for data that is expected to be returned unaltered.
Set the Identifier of the flow
for the packets.
Standard 16 Bit CRC
The CODE bit is not used
and should be set to 0
Set to 0 for Echo Reply
Set to 8 for Echo Request
Type
Code
CRC
8 Bits
8 Bits
16 Bits
Identifier
Sequence Number
16 Bits
16 Bits
Sequence number of the
packet within the flow
ICMP DATA
ICMP Data is usually a string of
sequential characters.
Page 34
ICMP Unreachable Messages
The ICMP Unreachable message is used by routers to report paths that are blocked by Access
Control lists.
The CODE bit is used to tell
the sending host why the
destination is unreachable.
Standard 16 Bit CRC
Set to 3
Type
Code
CRC
8 Bits
8 Bits
16 Bits
Unused - Must be set to to all 0's
32 Bits
Unused 16 bits
ICMP DATA
IP Header and first 64 bits of TPDU
Code
0
1
2
3
4
5
6
7
8
9
10
11
12
Description
Network Unreachable
Host Unreachable
Protocol Unreachable
Port Unreachable
Fragmentation needed
Source route failed
Destination network unknown
Destination host unknown
Source host isolated
Communication with destination Network administratively blocked
Communication with destination host administratively blocked
Network unreachable for type of service
Host unreachable for type of service
ICMP Source Quench Messages
When a host gets overwhelmed with IP packets it sends an ICMP message back to the senders to
“quench” or slow down their transmissions. A host will send this message each time a packet arrives that
cannot be processed and therefore, is dropped. To identify, to the sending host, the receiver sends back the
ICMP message with the header of the packet that is has been discarded.
The CODE bit is no used
and should be set to 0
Standard 16 Bit CRC
Set to 4
Type
Code
CRC
8 Bits
8 Bits
16 Bits
Unused - Must be set to to all 0's
32 Bits
Unused 16 bits
ICMP DATA
IP Header and first 64 bits of TPDU
Page 35
ICMP Redirect Messages
RULE: routers know all best routes.
If a router detects a host using a less than optimum route, the router will issue a route “redirect”
message to the sending host. The host is then, according to the protocol, adjusts its routing table
accordingly.
The CODE bit is set based
on type of redirect
Standard 16 Bit CRC
Set to 5
Type
Code
CRC
8 Bits
8 Bits
16 Bits
IP Address of Best Route - Router
32 Bits
IP Address of Router
ICMP DATA
IP Header and first 64 bits of TPDU
Code
0
1
2
3
Description
Redirect datagrams for the network
Redirect datagrams for the host
Redirect for type of service and network
Redirect for type of service and host
Page 36
ICMP Time-To-Live expired Message
RULE: when a host processes an IP packet it decrements the TTL.
RULE: When a host decrements the TTL to 0 is sends an ICMP message back to the sending host notifying
it that the TTL expired and what router turned the TTL to 0.
The CODE bit is set based
on type of expiration has
occurred.
Standard 16 Bit CRC
Set to 11
Type
Code
CRC
8 Bits
8 Bits
16 Bits
Unused - Must be set to ALL 0's
32 Bits
Unused 32 bits
ICMP DATA
IP Header and first 64 bits of TPDU
Code
0
1
Description
TTL count exceeded
Fragment reassembly time exceeded
ICMP Timestamp Request / Reply Message
Here is how this message works: The original sender places a timestamp in the “ORIGINATE
TIMESTAMP” just before transmitting the message. The receiving host places his timestamp in the
“RECEIVE TIMESTAMP” field when he receives the message. The receiving host then transmits the
message back to the sending host but, prior to transmission the receiving host places a timestamp in the
“TRANSMIT TIMESTAMP” field.
Set to 13 for Message.
Set to 14 for Replay.
Type
Code
CRC
8 Bits
8 Bits
16 Bits
Message Identifier
Sequence Number
16 Bits
16 Bits
Timestamp at Originator before sending
32 Bits
Timestamp at Destination when received
32 Bits
Timestamp at Destination before reply sent
32 Bits
Page 37
ICMP Subnet Mask Request / Reply Message
This message is used by hosts to obtain the subnet mask used with in a network. It can be
specifically addressed to a host or broadcast to a network.
The CODE bit is not used
and should be set to 0.
Standard 16 Bit CRC
Set to 17 for request.
Set to 18 for reply.
Type
Code
CRC
8 Bits
8 Bits
16 Bits
Identifier
Sequence Number
16 Bits
16 Bits
Subnet Mask
Packet sequence with flow
32 Bits
Flow Identifier
ICMP other Error Messages
All other errors, not covered by any of the preceding, are handled by the “Parameter Error”
message. The message structure is similar to the preceding messages.
The CODE bit is set to 1
when a parameter in the
sent message is missing.
Set to 15 for request.
Set to 16 for reply.
Standard 16 Bit CRC
Type
Code
CRC
8 Bits
8 Bits
16 Bits
Pointer
Unused
8 Bits
24 Bits
IP Header and first 64bits of packet that caused the error
Pointer to a location within the
packet that caused the error.
A “CODE” set to 1 indicates that a required option in the datagram is missing.
The “POINTER” is used to indicate what octet with in the datagram caused the problem.
Page 38
Utilities that use ICMP
To confirm configurations on the network there are two, extremely useful, utilities. The utilities
are called PING or the Packet Internet Groper and TRACERT or Trace Route. Both use ICMP packets to
send information to a target host and determine its availability.
PING – Packet Internet Groper
PING, basically, sends out an ICMP packet type 8, Echo Request, and expects back ICMP packet
type 0, or Echo Reply.
PING reports about the quality of our network in terms of response time. All OS that have a
TCP/IP stack have PING. The command line is basically the same: PING followed by either a host name
or an IP address. NetWare uses the PING NLM at the console. Below are sniffer traces of a PING packet.
Sniffer trace of ICMP Echo Request.
DLC:
----DLC:
DLC:
DLC:
DLC:
DLC:
DLC:
IP: ----IP:
IP:
IP:
IP:
IP:
IP:
IP:
IP:
IP:
IP:
IP:
IP:
IP:
IP:
IP:
IP:
DLC Header ----Frame 1 arrived at 21:14:06.6110; frame size is 74 (004A hex) bytes.
Destination = Station 00104B21437C
Source
= Station 006097BFCA32
Ethertype
= 0800 (IP)
IP Header ----Version = 4, header length = 20 bytes
Type of service = 00
000. .... = routine
...0 .... = normal delay
.... 0... = normal throughput
.... .0.. = normal reliability
Total length
= 60 bytes
Identification = 26446
Flags
= 0X
.0.. .... = may fragment
..0. .... = last fragment
Fragment offset = 0 bytes
Time to live
= 32 seconds/hops
Protocol
= 1 (ICMP)
Header checksum = E923 (correct)
Page 39
ICMP:
ADDR
0000:
0010:
0020:
0030:
0040:
IP: Source address
= [192.168.100.253]
IP: Destination address = [192.168.100.1]
IP: No options
IP:
----- ICMP header ----ICMP:
ICMP: Type = 8 (Echo)
ICMP: Code = 0
ICMP: Checksum = 4B5C (correct)
ICMP: Identifier = 256
ICMP: Sequence number = 256
ICMP: [32 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
ICMP:
HEX
00 10 4b 21 43 7c 00 60 97 bf ca 32 08 00 45
00 3c 67 4e 00 00 20 01 e9 23 c0 a8 64 fd c0
64 01 08 00 4b 5c 01 00 01 00 61 62 63 64 65
67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75
77 61 62 63 64 65 66 67 68 69
00
a8
66
76
|
|
|
|
|
ASCII
..K!C|.`—.Ê2..E.
.<gN.. .é#..dý..
d...K\....abcdef
ghijklmnopqrstuv
wabcdefghi
Sniffer trace of ICMP Echo Reply.
DLC:
----- DLC Header ----DLC:
DLC: Frame 2 arrived at 21:14:06.6112; frame size is 74 (004A hex) bytes.
DLC: Destination = Station 006097BFCA32
DLC: Source
= Station 00104B21437C
DLC: Ethertype
= 0800 (IP)
DLC:
IP: ----- IP Header ----IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP:
000. .... = routine
IP:
...0 .... = normal delay
IP:
.... 0... = normal throughput
IP:
.... .0.. = normal reliability
IP: Total length
= 60 bytes
IP: Identification = 23319
IP: Flags
= 0X
IP:
.0.. .... = may fragment
IP:
..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live
= 128 seconds/hops
IP: Protocol
= 1 (ICMP)
IP: Header checksum = 955A (correct)
IP: Source address
= [192.168.100.1]
IP: Destination address = [192.168.100.253]
IP: No options
IP:
ICMP: ----- ICMP header ----ICMP:
ICMP: Type = 0 (Echo reply)
ICMP: Code = 0
ICMP: Checksum = 535C (correct)
ICMP: Identifier = 256
ICMP: Sequence number = 256
ICMP: [32 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
ICMP:
ADDR HEX
ASCII
0000: 00 60 97 bf ca 32 00 10 4b 21 43 7c 08 00 45 00 | .`—.Ê2..K!C|..E.
0010: 00 3c 5b 17 00 00 80 01 95 5a c0 a8 64 01 c0 a8 | .<[.....•Z..d...
0020: 64 fd 00 00 53 5c 01 00 01 00 61 62 63 64 65 66 | dý..S\....abcdef
0030: 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 | ghijklmnopqrstuv
0040: 77 61 62 63 64 65 66 67 68 69
| wabcdefghi
Page 40
Trace Route
Remember the rule of TTL and ICMP: Whichever router sets the TTL to 0 must send an ICMP
message back to the source of the packet with its IP address. Tracert uses this rule by sending out packets
with the TTL set, at the onset, to 1 incremented by 1 until the final destination is reached. Because of this
serialization of the TTL the 1st router to set the TTL to 0 returns its address. All subsequent routers do the
same revealing their IP addresses.
Below is An example output from tracert.
Below are the ICMP packet fragments from the above Tracert…
Initial Request.. Notice the TTL set to 1
IP: ----- IP Header ----IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP:
000. .... = routine
IP:
...0 .... = normal delay
IP:
.... 0... = normal throughput
IP:
.... .0.. = normal reliability
IP: Total length
= 92 bytes
IP: Identification = 33358
IP: Flags
= 0X
IP:
.0.. .... = may fragment
IP:
..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live
= 1 seconds/hops
IP: Protocol
= 1 (ICMP)
IP: Header checksum = 7D24 (correct)
IP: Source address
= [192.168.100.253]
IP: Destination address = [128.122.20.15]
IP: No options
IP:
ICMP: ----- ICMP header ----ICMP: Type = 8 (Echo)
ICMP: Code = 0
ICMP: Checksum = ECFF (correct)
ICMP: Identifier = 256
ICMP: Sequence number = 2560
ICMP: [64 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
ICMP:
Page 41
Second Request, Notice TTL set to 2
IP: ----- IP Header ----IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP:
000. .... = routine
IP:
...0 .... = normal delay
IP:
.... 0... = normal throughput
IP:
.... .0.. = normal reliability
IP: Total length
= 92 bytes
IP: Identification = 33870
IP: Flags
= 0X
IP:
.0.. .... = may fragment
IP:
..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live
= 2 seconds/hops
IP: Protocol
= 1 (ICMP)
IP: Header checksum = 7A24 (correct)
IP: Source address
= [192.168.100.253]
IP: Destination address = [128.122.20.15]
IP: No options
IP:
ICMP: ----- ICMP header ----ICMP:
ICMP: Type = 8 (Echo)
ICMP: Code = 0
ICMP: Checksum = EAFF (correct)
ICMP: Identifier = 256
ICMP: Sequence number = 3072
ICMP: [64 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
ICMP:
Reply to tracert… Notice the ICMP reply type 11 code 0 and the header of the packet
replied in the data area…
IP: ----- IP Header ----IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP:
000. .... = routine
IP:
...0 .... = normal delay
IP:
.... 0... = normal throughput
IP:
.... .0.. = normal reliability
IP: Total length
= 56 bytes
IP: Identification = 58071
IP: Flags
= 0X
IP:
.0.. .... = may fragment
IP:
..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live
= 128 seconds/hops
IP: Protocol
= 1 (ICMP)
IP: Header checksum = 0CA1 (correct)
IP: Source address
= [192.168.100.254]
IP: Destination address = [192.168.100.253]
IP: No options
IP:
ICMP: ----- ICMP header ----ICMP:
ICMP: Type = 11 (Time exceeded)
ICMP: Code = 0 (Time to live exceeded in transit)
ICMP: Checksum = F4FF (correct)
ICMP:
ICMP: [Normal end of "ICMP header".]
ICMP:
ICMP: IP header of originating message (description follows)
ICMP:
ICMP: ----- IP Header -----
Page 42
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
ICMP:
Version = 4, header length = 20 bytes
Type of service = 00
000. .... = routine
...0 .... = normal delay
.... 0... = normal throughput
.... .0.. = normal reliability
Total length
= 92 bytes
Identification = 33614
Flags
= 0X
.0.. .... = may fragment
..0. .... = last fragment
Fragment offset = 0 bytes
Time to live
= 1 seconds/hops
Protocol
= 1 (ICMP)
Header checksum = 7C24 (correct)
Source address
= [192.168.100.253]
Destination address = [128.122.20.15]
No options
[First 8 byte(s) of data of originating message]
The TRACERT standards
There are two paradigms of philosophy when it comes to the trace route program’s functionality.
The first, as explained above uses the ICMP Echo Request and Echo Reply. The second uses UDP
datagrams bound for a port on the destination that is registered for trace route. The port, UDP 33434, is not
really used by a service just registered. Functionally, the source sends out 3 UDP packets per hop. Each
UDP packet is bound for the destination but the TTL is set to 1 initially, then incremented consecutively.
When the UDP packets reach their destination the destination host responds to the UDP packet with ICMP
Type 3 Code 3, Port Unreachable. When the source host receives the ICMP Type 3 message it knows that
the UDP packets have reached their destination.
Page 43
Name Resolution using the Domain Name Service
Name resolution in IP is enabled by the Domain Name Service or DNS, RFC 1034 and 1035, and
by the HOST file. The latter, the HOSTS file, is simply a text file that contains the IP address and aliases
of machines. The file is located in the same locations as the SERVICES file. DNS is hierarchical in
structure. Each computer belongs in a domain, which in turn lives in a larger domain, etc., up until the
root. The root is controlled by INTERNIC and all sub-domains from the root are registered with
INTERNIC. The entire DNS structure looks like a multilink tree. The names are written in dotted decimal
notation. A dot is placed between each level of the name. For example: Using a computer called MoePC.
MoePC is located at the Courant Institute at NYU. NYU has a domain name called NYU.EDU assigned to
it from INTERNIC. NYU assigned Courant its own sub-domain called CS. So the name of the pc is
“MoePC.CS.NYU.EDU”.
Below is what the hierarchical tree looks like.
INTERNIC ROOT
COM
(commerical)
EDU
(educational)
GOV
(governement)
NJIT
NYU
(New York University)
New Jersey Institute of
Technology
SCPS
CS
School Of Continuing
and Professional
Studies
MoePC
Courant Institute
MikePC
Page 44
US
(United States)
NET
(Internet Providers)
The DNS process
When a machine needs to identify another machine by name, it makes a request to its configured
DNS server. If it does not have a DNS server configured it looks in to its HOSTS table. The HOSTS table
is a simple text file that maps IP addresses to text names. It is usually located in the same place as the
“SERVICES” file.
MyGirona.Com
DNS Server
DNSEthernet
REQUEST
Computer
DNS REPLY
A host makes a direct request
to a DNS server. The host
must have the DNS server
configured to use DNS.
Drag the side
handles to
change the width
of the text block.
An example HOSTS file.
#------------------------------------------------#
# Diagnostic IP Address
#
#------------------------------------------------#
127.0.0.1
localhost
#------------------------------------------------#
# All the service servers with in the Enterprise #
#------------------------------------------------#
192.168.100.254 ntgw1 # Windows NT 4.0 Server
192.168.100.253 ntfs1
# Windows NT 4.0 Server
#------------------------------------------------#
# All the workstations with in the Enterprise
#
#------------------------------------------------#
192.168.100.1
w98ws1 # Windows 98 Version 2 Workstation 1 - Desktop
192.168.100.20 cmpq
# Windows NT 4.0 Workstation 1 - Laptop
Page 45
DNS works on as a request/reply system. When a host needs the IP address for a name it sends
out a “DNS COMMAND” and expects a “DNS REPLY”. If the DNS server can not resolve the name it
sends back a DNS error report with the DNS Response Code set to “3” or “Name Error” otherwise, the
DNS Repose Code is set to “0” or “OK”.
Sniffer trace of a DNS Command
DLC:
----- DLC Header ----DLC:
DLC: Destination = Station 3Com9 BFCABF
DLC: Source
= Station 0010A4B3A05C
DLC: Ethertype
= 0800 (IP)
DLC:
IP: ----- IP Header ----IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP:
000. ....
= routine
IP:
...0 .... = normal delay
IP:
.... 0... = normal throughput
IP:
.... .0.. = normal reliability
IP:
.... ..0. = ECT bit - transport protocol will ignore the CE bit
IP:
.... ...0 = CE bit - no congestion
IP: Total length
= 58 bytes
IP: Identification = 19203
IP: Flags
= 0X
IP:
.0.. .... = may fragment
IP:
..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live
= 128 seconds/hops
IP: Protocol
= 17 (UDP)
IP: Header checksum = 22CF (correct)
IP: Source address
= [192.168.100.20]
IP: Destination address = [24.3.144.33]
IP: No options
IP:
UDP: ----- UDP Header ----UDP:
UDP: Source port
= 1043
UDP: Destination port = 53 (Domain)
UDP: Length
= 38
UDP: Checksum
= A14C (correct)
UDP: [30 byte(s) of data]
UDP:
DNS: ----- Internet Domain Name Service header ----DNS:
DNS: ID = 1
DNS: Flags = 01
DNS: 0... .... = Command
DNS: .000 0...
= Query
DNS: .... ..0. = Not truncated
DNS: .... ...1 = Recursion desired
DNS: Flags = 0X
DNS: ...0 .... = Non Verified data NOT acceptable
DNS: Question count = 1, Answer count = 0
DNS: Authority count = 0, Additional record count = 0
DNS:
DNS: ZONE Section
DNS:
Name = mygirona.com
DNS:
Type = Host address (A,1)
DNS:
Class = Internet (IN,1)
DNS:
ADDR HEX
ASCII
0000: 00 60 97 bf ca bf 00 10 a4 b3 a0 5c 08 00 45 00 | .`—¿Ê¿..¤³ \..E.
0010: 00 3a 4b 03 00 00 80 11 22 cf c0 a8 64 14 18 03 | .:K...€."ÏÀ¨d...
0020: 90 21 04 13 00 35 00 26 a1 4c 00 01 01 00 00 01 | •!...5.&¡L......
0030: 00 00 00 00 00 00 08 6d 79 67 69 72 6f 6e 61 03 | .......mygirona.
0040: 63 6f 6d 00 00 01 00 01
| com.....
Page 46
Sniffer trace of a DNS Reply. DNS information only. Partial listing.
DNS: ----- Internet Domain Name Service header ----DNS:
DNS: ID = 1
DNS: Flags = 81
DNS: 1... .... = Response
DNS: .... .0.. = Not authoritative answer
DNS: .000 0...
= Query
DNS: .... ..0. = Not truncated
DNS: Flags = 8X
DNS: ..0. .... = Data NOT verified
DNS: 1... .... = Recursion available
DNS: Response code = OK (0)
DNS: ...0 .... = Unicast packet
DNS: Question count = 1, Answer count = 1
DNS: Authority count = 1, Additional record count = 2
DNS:
DNS: ZONE Section
DNS:
Name = mygirona.com
DNS:
Type = Host address (A,1)
DNS:
Class = Internet (IN,1)
DNS:
DNS: Answer section:
DNS:
Name = mygirona.com
DNS:
Type = Host address (A,1)
DNS:
Class = Internet (IN,1)
DNS:
Time-to-live = 31727 (seconds)
DNS:
Length = 4
DNS:
Address = [24.3.153.142]
DNS:
DNS: Authority section:
DNS:
Name = mygirona.com
DNS:
Type = Authoritative name server (NS,2)
DNS:
Class = Internet (IN,1)
DNS:
Time-to-live = 31727 (seconds)
DNS:
Length = 18
DNS:
Name server domain name = ns1.namehost.COM
DNS:
DNS: Additional record section 1:
DNS:
Name = ns1.namehost.COM
DNS:
Type = Host address (A,1)
DNS:
Class = Internet (IN,1)
DNS:
Time-to-live = 9764 (seconds)
DNS:
Length = 4
DNS:
Address = [64.39.29.250]
DNS: Additional record section 2:
DNS:
Name = ns1.namehost.COM
DNS:
Type = Host address (A,1)
DNS:
Class = Internet (IN,1)
DNS:
Time-to-live = 9764 (seconds)
DNS:
Length = 4
DNS:
Address = [209.61.129.208]
DNS:
ADDR HEX
ASCII
0000: 00 10 a4 b3 a0 5c 00 60 97 bf ca bf 08 00 45 00 | ..¤³ \.`—¿Ê¿..E.
0010: 00 88 37 06 00 00 39 11 7d 7e 18 03 90 21 c0 a8 | .ˆ7...9.}~..•!À¨
0020: 64 14 00 35 04 13 00 74 be e3 00 01 81 80 00 01 | d..5...t¾ã..€..
0030: 00 01 00 01 00 02 08 6d 79 67 69 72 6f 6e 61 03 | .......mygirona.
0040: 63 6f 6d 00 00 01 00 01 c0 0c 00 01 00 01 00 00 | com.....À.......
0050: 7b ef 00 04 18 03 99 8e c0 0c 00 02 00 01 00 00 | {ï....™ŽÀ.......
0060: 7b ef 00 12 03 6e 73 31 08 6e 61 6d 65 68 6f 73 | {ï...ns1.namehos
0070: 74 03 43 4f 4d 00 c0 3a 00 01 00 01 00 00 26 24 | t.COM.À:......&$
0080: 00 04 40 27 1d fa c0 3a 00 01 00 01 00 00 26 24 | ..@'.úÀ:......&$
0090: 00 04 d1 3d 81 d0
| ..Ñ=•Ð
Notice the highlighted area above. The “Answer Section” tells the recipient what the IP address is
for the request. The “Authority Section” tells the recipient who controls that domain and what name
servers are responsible for generating, i.e. creating, the name.
Page 47
TCP/IP Version 6
As the number of devices on the Internet proliferates, the supply of IP Version 4 address dwindles.
An enhancement to TCP/IP version 4 was created to address this issue. It is called TCP/IP Version 6.
TCP/IP Version 6 is defined in RFC 2460. The IANA retains control over IP address assignments.
The IPv6 Packet
The IPv6 packet format removes fields from the IP packet and increases the size of the IP address
fields. IPv6 addresses are 128 bits long; that’s 4 times the space of IP Version 4. Below are the packet
format and field definitions.
Version
4 Bits
Traffic
Class
8 Bits
Flow Label
20 Bits
Payload
Length
16 Bits
Next
Header
8 Bits
Hop
Limit
8 Bits
Source
IP v6 Address
128 Bits
Destination
IP v6 Address
128 Bits
Version  4 Bits set to 0110b or 6.
Traffic Class  This 8 Bit field is has a similar function as the TOS field of IP v4.
Flow Label  This 20 Bit field that identifies the flow between source and destination. The IETF
does not specify what to do with this field.
Payload Length  This 16 Bit field covers the entire length of the data/payload.
Next Header  This 8 Bit field replaces the Protocol field of IP v4.
Hop Limit  This 8 Bit field replaces the TTL field in IP v4.
Source/Destination Address  IP v6 address.
Page 48
IPv6 Header Extensions
According to RFC 2460, IP Version 6 can have 0 or more extension headers. These headers form
a chain of headers each listed in its predecessors Next Header field. The extension headers defined by the
RFC are:

Hop-by-Hop (protocol 0)  This header notifies routers that there is a Jumbogram in the
payload. As defined in RFC 2675, a Jumbogram is an IP datagram that is greater than
65,535 Bytes long. A Jumbogram has a limit of 4,294,967,295 bytes.

Destination Options Header (protocol 60)  This header carries data specifically for the
destination host.

Routing Header (protocol 43)  This header is used by IP v6 to designate a specific
routing path. This path has priority over those known by routers.

Fragment Header (protocol 44)  This header is inserted by a source device when it has
to break up large IPv6 packets in to fragments.

Authentication Header (protocol 51)  This header is used by IPSEC.

Encapsulating Security Payload Header (protocol 50)  This header is also used by
IPSEC.

User Datagram Protocol (protocol 17)  UDP or User Datagram Protocol does not
change in IPv6. The only difference is that the CRC is required in IPv6.

Transport Control Protocol (protocol 6)  There are no changes to TCP in IPv6. It is the
same as in IPv4.
IPv6 MTU
The minimum payload of an IPv4 packet was 556 bytes and the maximum was 64 Kilobytes. In
IPv6 the minimum payload is 1500 bytes. This maxes out the MTU of an Ethernet frame. Because
fragmentation is normal in IPv6, IPv6 implements PMTUD. The large payload size was created to take
advantage of the larger frame types available in newer technologies, such as 10GbE technology’s 9216 byte
MTU.
Page 49
IPv6 Representations
In accordance to RFC 2373, IPv6 addresses have 2 possible formats: long method and compressed
method. Frames carrying IPv6 Packet have an Ether-type of 0x86DD.
Long Method
In the longest method the IPv6 address is represented as 8 x 16bit hexadecimal values separated by
colons. The IPv6 format is shown as follows: ####:####:####:####:####:####:####:####. The # is a
hexadecimal value from 0 to F. For example: 2001:3030:0001:1023:0223:8bff:fed2:b22f
Compressed Method
In the compressed method the IPv6 address is also represented as 8 x 16 bit hexadecimal value
separated by colons. A series of 0s is represented as a single – double colon entity. For example:
2001:0003:0000:0000:0223:8bff:fed2:b22f can be represented as 2001:0003::0223:8bff:fed2:b22f. The
compressed method also allows for the suppression of leading zeros. The same address can be represented
as 2001:3::223:8bff:fed2:b22f.
IPv6 Subnetting
IPv6 subnetting works in the same way as IPv4. The notation is /## where ## is the number of bits
used in subnetting. The only two reserved addresses are the first and last addresses within the subnets.
There are no other reserved addresses in IPv6.
Page 50
IPv6 Address Types
There are three types of addresses in IPv6: Unicast, Multicast, and Anycast.
Unicast Address Space
There are 2 types of addresses in the Unicast Address Space: Aggregatable Global Unicast
Address and Private Unicast Address space.
Aggregatable Global Unicast Address
Aggregatable Global Unicast addresses are addresses that are routable through the Internet. These
addresses have a standard format imposed on them. The format is as follows: <48 bit header assigned by
to the provider>: <16 bit site identifier>: <64 bit host identifier>. The 48 bit provider address includes
the Unicast prefix of 001b followed by a 13 bit TLA, this is assigned to each ISP, followed by 8 bits of
reserved space, followed a 24 bit NLA, the ISP assigns this to individual entities, followed by the 16 bit
site subnet space, followed by the 64 bit host address.
001
3 Bit Unicast Identifier
13 Bit ISP Address
TLA – Top Level Aggregation Identifier
8 Bit Reserved
Set to 0x00
24 Bit ISP-to-Customer Identifier
NLA – Next Level Aggregation Identifier
16 Bits
64 bit Host address
Site specific
addressing
001
3 Bit Unicast Identifier
48 Bit Provider Address
64 bit EUI-64 Format Address
The IANA assigns addresses to providers based on the 2xxx::/3 address range
Host Address
Host addresses in IPv6 are not assigned but are automatically configured by a host based on the
EUI-64 Format. The format takes the 48 Bit MAC address, inserts a shim between the 3rd and 4th bytes of
the address and then requires that the 7th highest order bit be set to 1, as shown below.
0023:8bd2:b22f
48 bit NIC MAC address
7th Highest Order bit set to 1
64 bit EUI-64 Format Address
02
23:8b
ff:fe
d2:b22f
Shim of 0xFFFE inserted in between 3rd and 4th Highest order bytes.
Page 51
Private Address Space
The private address space within IPv6 is similar in function to the IPv4 RFC 1918 address space.
Addresses within the space are not routable on the Internet. Addresses within this space begin with the hex
value 0xFFFE and have the 33rd highest order bit set to 1. All private addresses have a mask of /10. There
are two types of private addresses in IPv6: Site Local and Link Local.
IP Version 6 Private Address Space
1111 1110
8 Bit Private Identifier
1x
2 Bits
118 bits of address space
Private Address Prefix
Possible Values
For mask /10
FE8x
FE9x
FEAx
FEBx
FECx
FEDx
FFEx
FEFx
1111 1110
10
8 Bits Private
2 Bits
Identifier
Private Address Prefix
Link Local Addresses - 118 bits
Possible Values
FE8x
FE9x
FEAx
FEBx
1111 1110
11
8 Bits Private
2 Bits
Identifier
Private Address Prefix
Site Local Addresses - 118 bits
Possible Values
FECx
FEDx
FEEx
FEFx
Link – Local Address Prefixes
A Link local address is an address that is local only to the link it is on. The defined link local
address prefixes as follows: FE80::/10, FE90::/10, FEA0::/10, FEB0::/10. Routers are identified locally
by their Link Local address and not by their aggregatable global address.
Site – Local Address Prefixes
A site local address is a Unicast address that is only used within a site. This is similar to the IPv4
RFC 1918 addresses. Site local addresses are not routed by internet routers. All site local addresses have
the one of the following prefixes: FEC0::/10, FED0::/10, FEE0::/10 or FEF0::/10.
Page 52
Below is the output of the IPv6 nc command on Windows XP. It shows the link local addresses
assigned to a PC.
Loopback Addresses
The IPv4 loopback address is replaced by the IPv6 address ::1/128. The local-link equivalent if
FC80::1/128
Page 53
Multicast Address Space
Multicast addresses are assigned or solicited. They can be known or user-assigned. All multicast
addresses begin with the 8 highest ordered bits set to 1, followed by 3 bits set to 0, followed by a 1 bit
Transient flag, immediately followed by a 4 bit Scope ID. The Transient flag, when set, indicates that the
multicast address is user-assigned. The Scope ID indicates the limit of the multicast and replaces the TTL
function in IPv4 Multicast.
IP Version 6 Multicast Address Space
Multicast Scope
Transient Flag
0000 = Reserved
0001 = Node-Local
0010 = Link-Local
0101 = Site-Local
1000 = Organization-Local
1110 = Global
1111 = Reserved
0 = Well Known assigned
Multicast Address
1 = User assigned
Multicast Address
1111 1111
8 Bit Multicast
Identifier
000
Unused
3 Bits
x
1 Bit
Flag
xxxx
4 Bit
Scope
112 Bit Group Address
Multicast Address Prefix
1111 1111 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001
F
F
0
1
0
0
0 0
0
0 0
0
0
0
0
0
0
0 0
0
0 0
0
0
0
0
0
0
0
0
0 1
FF01:0000:0000:0000:0000:0000:0000:0001 or FF01:0:0:0:0:0:0:1 or FF01::1
All Nodes Multicast Address

Assigned addresses are addressed by RFC 2373 and are shown in the table below.
Multicast Address
FF01::1
FF01::2
FF02::1
FF02::2
FF05::2

Scope
Node
Node
Link Local
Link Local
Site
Meaning
All the nodes on the local link
All routers on the local link
All nodes on the local link scope
All router on the local link scope
All routers in a site scope
Solicited addresses are used to resolve layer 3 addresses to MAC using the IPv6 Neighbor
Discovery Protocol. This takes the place of the ARP process in IPv4. The address is create, by
each node, by taking the prefix FF02:0000:0000:0000:0000:0001:FF/104 or FF02::1:FF/104
and appending the lower 24 bits of a nodes Unicast address to it. For example: given the IPv6
address 2001:0003::0223:8bff:fed2:b22f the solicited address would be calculated as
FF02::1:FFd2:b22f
Anycast Address
Anycast addresses are multicast addresses that are used to address the nearest multicast node. At
present time only inter-router communications use Anycast addresses.
Page 54
IPv6 Addresses Required on Nodes
Each node in an IPv6 environment, which does not participate in routing, has more than one single
IPv6 address assigned to it. The required addresses and their use are shown below.
Address
FE80::/10
::1/128, FE80::1/128
FF01::1, FF02::1
2000::/3
FF02::1:FF<24 bit address>
FF00::/8
Use
Link Local address for each interface
Loopback address
All nodes multicast address
Assigned Aggregate Global Address
Solicit-mode multicast address
All groups multicast address
Each router in an IPv6 environment has more than node IPv6 addresses assigned to it. The
required, in addition to the node addresses, addresses and their use are shown below:
Address
FF01::2, FF02::2, FF05::2
Unicast prefix::
Other anycast address
Use
All routers multicast address
Subnet router anycast address
2000::/3
Configuring IPv6 on Cisco Routers
The global command to enable IPv6 on a router is ipv6 unicast-routing. To configure an interface
to use an IPv6 address the interface command is ipv6 address ipv6-address/prefix-length {link-local}. An
interface can be configured to automatically self configure using the interface command ipv6 enable.
Page 55