Microsoft Word – assignment2key.docx
CMPT 471 Assignment 2 SOLUTION
1) Explain how you would set up a simple laboratory experiment to capture and display in
Wireshark each of the following ICMPv6 messages.
a) [10 points] IPv6 destination unreachable/address unreachable:
b) [10 points] IPv6 router solicitation and the resulting router announcement/s followed by
periodic router announcements from the routers that responded to the router
solicitation.
Give detailed step by step instructions for each experiment. So you know what is expected
an example is presented on the next page. Your audience is a student just starting to learn
about IPv6. This student is not familiar with Linux
In your experiments
Do not use the traceroute command
Do not send a packet to a host that does not exist or is powered down
For part a) you must use the traffic generation tool mgen to generate packets to send
through these networks. Please write and submit mgen scripts as a part of part a).
You will also be asked to use mgen in later assignments.
The tool mgen can be used from the command line or from a script. The first script you write
will send a series of packets and the second mgen script will receive those packets. You will
be given a few sample mgen command line instructions below. The mgen manual is posted
in Canvas as a pdf file. The following examples are some of those available in this manual.
The mgen manual also explains how to write mgen scripts.
mgen instance mgen1 event “on 1 UDP DST 10.20.1.5/5555 periodic [2 1200] COUNT=5”
This example mgen command creates an instance called mgen1 of mgen to generate a
particular group of packets. For this example we are generating UDP packets that will be sent
to port 5555 on host 10.20.1.5. The packets will be sent periodically (two packets every
second) and each of the packet will have 1200 bytes of data. The event will sent 5 packets.
mgen event “listen UDP 5555”
The example mgen command listens for UDP traffic on port 5555
EXAMPLE: Experiment to capture an IPv4 ICMP time exceeded message
The ICMP time exceeded message is sent by a router when the router drops a packet because
it has a ttl of 0 after the ttl has been decremented during the forwarding process.
a) Log into cs-vnl-01 or cs-vnl-03, to access the CMPT 471 network lab then log in to lab1-05
b) Prepare to capture the packets on network 19.
i) Open a copy of the packet sniffer on lab1-05 using the command wireshark
ii) In the Wireshark window choose options from the capture menu.
iii) In the resulting popup menu
Choose your interface, you want to see the packets that your chosen host is
sending to host may through net 19 so choose eth1.
Choose a capture filter to collect only the ICMP protocol packets by typing “icmp”
into the field labeled capture filter (do not type the quotes).
Start your capture (press the start button in the options popup window).
c) Place Wireshark into the background. Type cntrl
and hit the return key to put Wireshark into the background.
d) Traceroute is a system utility that will tell you each of the intermediate routers that your
packet passed through to reach its destination and the time it took to get to each of
those routers. The algorithm that is used by the traceroute utility generates time
exceeded messages. Try and find the route taken to october running system tool
traceroute traceroute 10.19.1.10
e) You should capture 3 ICMP time exceeded messages generated by the IPv4 traceroute.
You will also capture IPv4 destination unreachable (port unreachable) messages.
f) When you are done examining your captured messages bring wireshark back into the
foreground by typing fg followed by
g) To terminate wireshark type
h) Log out of lab1-05
PLEASE UNDERSTAND THESE ARE ONLY SAMPLE SOLUTIONS, THERE ARE MANY CORRECT WAYS
TO GENERATE EACH OF THE FOLLOWING TYPES OF PACKETS.
Experiment to capture an IPv6 ICMP destination unreachable (address unreachable) message
a) The ICMP time destination unreachable (host unreachable) is sent by a router when the
host drops a packet because the destination interface of the host cannot be reached
b) Log into cs-vnl-01 or cs-vnl-03, to access the CMPT 471 network lab. Log in to year.
c) Prepare to capture the packets on net 19.
i) Open the packet sniffer Wireshark using the command wireshark
ii) In the resulting popup menu for wireshark select the options menu.
iii) Choose your interface; you want to see the packets on net 19 so choose eth1 the
interface connected to net 19.
iv) Enter a capture filter that will select only the ICMP packets travelling through
network 19. You can choose to capture only packets associated with the IPv6 ICMP
protocol by typing “icmp6” (do not type the quotes) into the field labeled capture
filter.
v) After making these two selections in the options window you can start your
capture by pressing the start button in the options popup window.
vi) Place Wireshark into the background. Type cntrl
return key
d) Next open another window and log into winter.
e) You will disconnect winter from network 18 so that packets sent to winter will not be able
to reach winter by way of net 18. Winter is connected to network 18 and receives packets
sent through network 18 through eth1. To disconnect winter from network 18 turn off the
Ethernet interface connecting winter to network 18 using the command sudo
ifdown eth2. You will need to supply your virtual network password before the command
is executed.
f) Return to the window connected to year.
g) Next we want to generate the ICMP destination unreachable (port unreachable) packets.
We will use a call to a traffic generator utility, mgen, to generate these packets. The
packets will be sent to the IPv6 address of winter on net 18. The interface on net 18 is
down so the packets will not be able to reach the host
h) enter the mgen command:
mgen instance mgen1 event “on 1 UDP DST fdd0:8184:d967:18:250:56ff:fe85:7d6f/5555
periodic [2 1300] COUNT=5”
This example mgen command creates an instance called mgen1 of mgen to generate a
particular group of packets. For this example we are generating IPv6 UDP packets that will be
sent to port 5555 on host winter. The packets will be sent periodically (two packets every
second) and each of the packet will have 1300 bytes of data. The event will send 5 packets.
i) You will capture 5 ICMP destination unreachable (address unreachable) messages. The
messages will not be visible on network 18 because they are generated by the router
March when the address cannot be reached. When you are done examining your captured
messages save the file and bring wireshark back into the foreground by typing fg
followed by
j) To terminate wireshark type
k) Log out of august
l) In your window on winter enter the command sudo ifup eth1 to turn the interface back
on
m) Log out of winter
Experiment to capture an IPv6 ICMP router solicitation and solicited response message
a) The ICMP6 router solicitation message is generated when a host is booting. It is used to
request router information and cause the router to send an immediate solicited router
announcement to provide the information.
b) Log into cs-vnl-01 or cs-vnl-03, to access the CMPT 471 network lab. Log in to november.
c) Prepare to capture the packets on net 18.
i) Open the packet sniffer Wireshark using the command wireshark
ii) In the resulting popup menu for wireshark select the options menu.
iii) Choose your interface; you want to see the packets on net 18 so choose eth1 the
interface connected to net 18.
iv) Enter a capture filter that will select only the ICMP packets travelling through
network 19. You can choose to capture only packets associated with the IPv6 ICMP
protocol by typing “icmp6” (do not type the quotes) into the field labeled capture
filter.
v) After making these two selections in the options window you can start your
capture by pressing the start button in the options popup window.
vi) Place Wireshark into the background. Type cntrl
return key
d) Next open another window and log into spring.
e) You will restart spring so that it will send a router solicitation message while it is booting.
Restart autumn from network 18 by using the command sudo shutdown –r now. You
will need to supply your virtual network password before the command is executed. DO
NOT FORGET the –r or spring will not restart.
f) Return to the window connected to year. You may have to wait about 30 seconds before
your router solicitation packet and responding router announcements appear and longer
for the periodic router announcements to arrive.
g) You will capture one router solicitation and two responses to it one from each router
connected to net 18. Then you will receive periodic router announcements from each of the
routers your received immediate responses from. When you have received the periodic router
announcement stop the capture. You will also received other packets while waiting for your
periodic router announcements (mostly neighbor solicitations and announcements). When
you are done examining your captured messages save the file and bring wireshark back into
the foreground by typing fg followed by
h) To terminate wireshark type
i) Log out of november and spring
2) Consider automatic generation of IPv6 addresses. You will provide evidence from at least
one of the following sources for each assertion you make.
Output from any of the following commands used in the virtual network:
o ip, ip route, ip -6 route,
o ifconfig
Any configuration files on the hosts in the virtual network.
Any RFC.
You should refer to earlier discussions in your answer rather than repeating them.
a) For host may and eth0 answer the following questions:
i. [3 points] What are the Ethernet and IPv6 addresses (link local and global) being
used for your chosen host. Consider only the interface on network 18. Give
evidence from output of one of the suggested commands.
ii. [3 points] Show where each piece of information needed to determine the ipv6
link local and global addresses for the interfaces on net 18 might be obtained.
Give evidence that shows a source for each needed piece of data. Note: the
calculated IPv6 addresses themselves are not considered as evidence for this part
of the problem.
iii. [4 points] Consider how the EUI-64 based global address is determined. Use the
values from your evidence in i. and ii. to give an example step by step calculation
of the IPv6 link local address and global address.
iv. [2 points] Are temporary privacy addresses used on network18? Give evidence.
Choose eth1 on may for the example on net18:
i. On may the addresses are
(3 points: for evidence of addresses, 1 for Ethernet, 1 for link local
and 1 for global IPv6 addresses)
ii. So we have the the link local Ethernet address 00:50:56:85:d1:d8 from the
output given in i. (1 point: for Ethernet Address)
We also have the prefixes being used are given in the /etc/radvd.conf files for
march and december.
(2 points: 1 point for evidence of each prefix on net 18)
iii. Determine the link local address (using the EUI-64 algorithm)
#MARCH
prefix fdd0:8184:d967:18::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvPreferredLifetime 8000;
AdvValidLifetime 16100;
};
#DECEMBER
prefix fdd0:8184:d967:8018::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvPreferredLifetime 8000;
AdvValidLifetime 16100;
};
The link local address is determined starting with the link local prefix
fe80:0:0:0::
The Ethernet interface of may has address 00:50:56:85:d1:d8 so we divide
this in half and insert ff:fe between the two halves to give
00:50:56:ff:fe:85:d1:d8.
The seventh bit of the first eight bits of the address ( the 00 hex ) is flipped to
make the host portion of the address 02:50:56:85:d1:d8
The results of the previous step are added to the link local prefix to give
fe80::250:5685:d1d8
(2 points: ½ point for each step of example)
Determine the link local address
Remember that steps ii) and iii) give 02:50:56:85:d1:d8 as the EUI-48 address
Add this to the global prefix found in the /etc/radvd.conf file on march
(fdd0:81824:d967:18:: ) or in the router announcements from march to give
the global address fdd0:8184:d967:18:250:5685:d1d8
Repeat steps v) and vi) for the prefix fdd0:8184:d967:8018 advertised by
december.
(2 points: ½ point for each step of example)
iv. No temporary private addresses are used. Temporary private addresses are
turned off in /etc/sysctl.conf. To turn off the temporary private addresses the
following lines are added to the /etc/sysctl.conf file:
(2 points: 1 point for evidence, 1 point for saying no temporary
private addresses are used)
b) For host October on network 19 answer the following questions.
i. [2 point] What are the Ethernet and IPv6 addresses (link local and global) being used
for october. Consider only the interface on network 19. Give evidence from output of
one of the suggested commands.
ii. [2 point] Are any EUI-64 based address being used on october? Give one reason why
you think that EUI-64 based addresses are or are not being used.
iii. [1 point] Are privacy extension addresses being used on october? Give evidence
iv. [3 points] What is the key used to generate the automatic IPv6 link local and global
addresses? Give evidence from the RFC or online sources AND from the existence or
value of one sysctl variable.
v. [2 points] If you reboot the machine do the addresses change? Give evidence using a
quote from an RFC.
i. On october the addresses are
(2 points)
ii. It is immediately clear that none of the link local and global addresses directly
depend on the Ethernet address of the interface. The IPv6 addresses do not end with
the last four digits of the Ethernet address. (2 points)
iii. “Privacy extension addresses” are turned off (1 point) by adding the same four lines
to the /etc/sysctl.conf file (discussed for net18). These lines are in the file on October
as well.
(1 points)
iv. This leaves “semantically opaque” addresses. (1 point)
These addresses are based on a private key rather than the Ethernet address of the
interface. The key is used to generate the link local or global interface address that
is added to the prefix. The private key is stored in the kernel (sysctl variable). If we
look in /etc/sysctl.conf for any host on network 19 we will see such a key. For
example on October the following line has been added to the default sysctl.com
(2 point for giving the sysctl variable value as proof that the addresses
are semantically opaque )
This line provides the key from which the “semantically opaque” addresses are
determined. Since the key is permanent the same address will be generated each
time the host boots.
v. After rebooting the host October the IPv6 link local and global addresses were not
changed from those given in i. [1 point].
This behavior is specified in the RFC. In RFC
It should be noted that (not part of solution)
Different “semantically opaque” addresses are calculated for each prefix to
increase security.
When using “semantically opaque” addresses it is possible to resolve DAD
conflicts by calculating a new address.
c) For host august on network 17 answer the following questions.
i. [1 points] Provide the output from the command ifconfig eth1 executed on august
ii. [2 points] Are there any EUI-64 based addresses being used on eth1 on august? Which
address in the output provided in I are EUI-64 based?
iii. [2 points] Are privacy extension addresses being used on October? Give evidence.
iv. [3 points] Give evidence from output in i.. Indicate which addresses would currently
be used for a new connection, and which addresses might currently be being used by
older connections.
v. [1 points] If you reboot the machine do the addresses change?
On august the addresses are
i. The output below shows a large number of addresses.
(1 point for providing the output)
ii. There are EUI-64 based addresses available on august (1 point), they are shown in the
box at the bottom of the output. (1 point, for graphically or verbally locating
these addresses in the provided output).You can verify these are EUI-64 by using
Ethernet address as the top of the output to derive automatic addresses. The result will
EUI-64 based addresses given at the bottom of the output.
iii. Privacy extension addresses are turned on in /etc/sysctl.conf. To cause the temporary
private addresses to be created the following lines are added to the /etc/sysctl.conf file:
net.ipv6.conf.default.use_tempaddr = 2
net.ipv6.conf.eth0.use_tempaddr = 0
net.ipv6.conf.eth1.use_tempaddr = 2
(1 point, for indicating setting for august and location in /etc/sysctl.conf )
The values of these variables can be 0 1 and 2. If the value is 0 no “privacy extension”
addresses are created. If the value is 1 then “privacy extension” addresses are created
but not preferred over EUI-64 addresses. If the value is 2 then “privacy extension”
addresses are created and preferred over EUI-64 addresses. (1 point) .
iv.
EUI-64 addresses
Currently valid
privacy extension
addresses
Not part of solution
When new privacy extension addresses are created they are based on a stored string
(key) derived from the present “privacy extension” address. Each time a new “privacy
extension address” is generated the string is updated, a new string based on the present
address is saved. This means that the privacy address will change when a host is
rebooted. A new privacy extension address based on the presently stored string will be
generated when the host boots. The addresses are generated using a technique similar
to pseudo random number generation.
Each time the preferred lifetime of an IPv6 “privacy extension” address expires it
becomes deprecated. This means that new outgoing connections will no longer choose
the deprecated address. Existing outgoing connections may continue to use the
deprecated address until the valid lifetime expires. Incoming connections use the EUI-
64 addresses which do not vary with time (making stable addresses for servers possible.
3) In this problem you will investigate the use DNS, an d the use of the resolver dig.
You will capture DNS queries in the virtual lab.
Choose any host on net 16, 17 or 18. You will capture packets on eth0. To be sure that you
do not create files so large that you crash the host you are working on be sure to use a
capture filter that captures only DNS queries and replies. (filter using the well-known port,
53, for DNS.)
Choose any host on net 18 (not the same host you are running wireshark on). On that host
run the three commands below. Save your capture file for analysis and submission.
dig october +search
dig november +search
dig june +search
a) [12 points] The information you need to answer this part of the question is contained in
the /etc/resolv.conf file on the host you used to run the commands and the list packets you
captured when you ran your commands. Include a screen capture of each at the start of
your solution for this part of this problem. You will then be able to refer to them as
needed.Explain how the resolver dig uses the contents of the /etc/resolve.conf file to
complete the dns domain names and search for october. Consider the frames generated by
the query for the address of october. Give a step by step description, including what each
captured packet requesting/receiving as a response and how this relates to the search line
in the /etc/resolv.conf file. Refer directly to the packets in your capture by frame number in
each step of your explanation that relates to one of the packets.
(3 points for evidence)
The captured packets for the command “dig october +search” are shown above along with
the resolv.conf file from the host used to run the dig commands to generate the capture.
The command is searching for the IP address of october.
October is not a fully qualified domain name so the search line in the resolv.conf will be used.
The first completion in the search line is net16. Using the first completion gives the FQDN
october.net16 for the first query. The first query we see in the capture is for october.net16
(frame 1),
There is not an october on net16 so the response to the query is “No such name” (frame 2)
As the first query produced a “no such name” we consider the second completion in the search
line of the resolv.conf file. Using the second completion in the search line, net17, gives the
FQDN october.net17 for the second query (frame 3)
There is not an october on net17 so the response to the query is “No such name” (frame 4)
As the second query produced a “no such name” we consider the third completion in the search
line of the resolv.conf file, net18., to give the FQDN october.net18 for the third query. (frame 5)
There is not an october on net18 so the response to the query is “No such name” (frame 6)
As the third query produced a “no such name” we consider the fourth completion in the search
line of the resolv.conf file. Using the fourth completion in the search line, net19, gives FQDN
october.net19.. (frame7)
There is an october on net19 so the response to the query is the A record for october.net19
(frame8)
(9 points, 1 point for the ideas in each bullet point, ½ of this for the frame
number )
b) [10 points] Look at the supplied DNS database files for the virtual network. (Available below
the pdf containing the assignment on Canvas). The DNS database files for most networks
are given. Based on the discussions in class and the information in the supplied database
files write a database file for net 17 and a reverse lookup file for net 17.
These files will be added to the DNS files present before the submission date after the
submission date has passed.
c) [8 points] Consider the resolvers dig and host. For example the command host year would
return the IPv4 and IPv6 addresses of host year on net 19. Write host and dig resolver
commands to get the IPv4 and IPv6 addresses of spring for net 17 and the admin network.
Also write the host and dig resolver commands to get the IPV6 address on net 8017. For
each command indicate which of the addresses will be returned.
For IPv4 and IPv6 addresses on net 17 (2 points, 1 for querying each address)
host spring or dig spring +search
dig AAAA spring +search
For IPv4 and IPv6 addresses on net admin
(3 points, 1 for identifying the network, 1 for querying for each addr)
Host spring.admin or dig spring.admin +search
dig AAAA spring.admin +search
For IPv6 addresses on net 8017 (1 point)
(2 points, 1 for identifying the network, 1 for querying for address)
host spring.net8017 or dig AAAA spring.net8017 +search
4) [20 points] Consider fragmentation in IPv6. Consider the IPv6 “Packet too big” message. Consider 3
networks,
Network 1, between router A and router B has an MTU of 1500
Network 2, between router B and router C has an MTU of 1430
Network 3, between router C and router D has an MTU of 1310
Also consider router A is sending a stream of 4866 octets of data to router D.
Assume 2 data packets are sent by Router A before router A receives a “Packet too big”
message from router B.
Also assume that 3 data packets are sent by router A after receiving a “Packet too big” from
router B and before receiving a “Packet too big” message from router C.
Make the following assumptions
Router A is sending a stream of application data 5234 bytes in length to router D.
The IPv6 header is 40 bytes in length
The TCP header is 28 bytes in length
Remember that the MTU is the length of the IP datagram (including the IP header).
The TCP process interacts with the “packet too big message” so that TCP will begin
resending all unacknowledged data using the smaller MTU. The resent packets will not be
fragments, just smaller packets.
Add each data packet sent to the diagram of the type illustrated below. Annotate each packet
sent with the amount of data it contains, its MTU and the number of times that that data has
been transmitted. Add any and all ICMP “Packet too big” messages should be added to your
diagram and annotated to indicate the important information in those messages.
Calculate how much data is retransmitted once
Calculate how much data is retransmitted twice
Consider the 5234 octets of data to be sent. Assume a 28 byte TCP header and a 40 byte IPv6
header (minimum size for IPv6 header, includes no extension headers). Then
1. On network 1 each 1500 byte IP datagram will have 1500-40-28=1432 bytes of data from the
data stream. (1 point) This means the data stream will fill 3 full datagrams and 1 partially
full datagrams (1 point) (containing 5234-3*1432=938 bytes)
Two packets are sent before the first packet too big message is received
Therefore, the first 2*1432=2864 bytes will need to be transmitted(1 point)
After sending these bytes have been transmitted once
2. On networks 1 and 2 each 1430 byte IP datagram will have 1430-40-28=1362 bytes of data
from the data stream. (1 point) This means the data stream will fill 3 full datagrams and 1
partially full datagram (1 point) (containing 5234-3*1362=1148 bytes)
Three packets are sent before the first packet too big message is received
Therefore, the first 3*1362=4086 bytes will need to be transmitted(1 point)
So 2864 bytes are retransmitted (those transmitted already in 1) (1 point)
2864 – 2*1362 = 140 The first two packets hold all retransmitted data,
the third packet holds 140 bytes of retransmitted data(1 point)
4086-2864 = 1222 bytes or 1362-140=1222 will be transmitted for the first time
(1 point)
3. On networks 1,2 and 3 each 1310 byte IP datagram will have 1310-40-28=1242 bytes of data
from the data stream. (1 point) This means the data stream will fill 4 full datagrams and 1
partially full datagram (containing 5234-4*1242=266 byte (1 point)s, 4*1242=4968)
All five packets are sent, and are received by the destination
the first 2864 bytes have been retransmitted twice (sent 3 times), so this is the
first two packets(1 point) and the first 2864-(2*1242)=380 bytes of the third
packet (1 point) are transmitted three times (retransmitted twice)
The next 1222 bytes have been retransmitted once (sent 2 times)(1 point)
The remainder of the third packet is 1242-380=862 bytes. Since 862 < 1222 the
remainder of the fourth packet is transmitted twice (retransmitted once) (1 point)
This leaves 1222-862=360 bytes of data that has been transmitted twice
(retransmitted once) for the fourth packet. (1 point)
The remaining 882 bytes of the fourth packet has been transmitted once(1 point)
All values will first be checked on the diagram, if they are missing or incorrect
the description of the calculation will be looked at to see if ½ points for correct
logic can be given.
3 points given for the packets illustrated on the diagram
1 for the correct number of packets in each group (for each MTU)
1 point for the correct number of packet too big messages.
1 point for MTU’s on diagram, subtract ½ for each that is incorrect
ROUTER A ROUTER B ROUTER C ROUTER D
MTU 1500, 1432 bytes 1X
MTU 1500, 1432 bytes 1X
MTU 1430, 1362 bytes 2X
MTU 1430, 1362 bytes 2X
MTU 1430, 1222 bytes 1X , 140 bytes 2X
MTU 1310, 1242 bytes 3X
MTU 1310, 1242 bytes 3X
MTU 1310, 360 2X, 882 1X
MTU 1310, 380 bytes 3X, 862 bytes 2X
MTU 1310, 266 1X