The question was asked in today’s CS35110 lecture, whether it is possible to force the Unix versions of traceroute to use ICMP echo packets rather than UDP packets to conduct the trace. The answer, on a Mac at least (which is a BSD variant) is to use the -I option.
From man tcpdump:
-I Use ICMP ECHO instead of UDP datagrams. (A synonym for “-P icmp”).
The Problem of Path MTU Discovery and RFC-1918 Private Addresses
Path MTU discovery is used to discover the smallest MTU (Maximum Transmission Unit) between two nodes communicating on the Internet. We have seen how path MTU discovery can be broken by inappropriate filtering of all ICMP messages (so that the “Destination Unreachable” ICMP messages are not returned to the sending node).
It turns out that there is another way that Path MTU discovery can be broken – and that is through the use of RFC-1918 private addresses on the network path.
If several routers are chained together within an organisation (or an “autonomous system” – more on that term later!) some orgaisations will now try to conserve public IP addresses by using RFC-1918 private addresses within the organisation. Packets are passed router to router and only need to come from a router with a public IP address when they leave the border gateway of the organisation.
Consider two nodes communicating on the Internet, A and B. Between A and B there are four routers, R1, R2, R3 and R4. The route from R1 to R2 uses public IP addresses, but the route from R2 to R3 and R3 to R4 is set up with private networks using the RFC-1918 addresses on networks 192.168.1.0/24 and 192.168.2.0/24 (say). Furthermore, let us suppose that the MTU of the link between R3 and R4 is lower than that between R1 and R2 and also between R2 and R3.
Now consider what happens when node A sends a full size datagram to B with the Don’t Fragment bit set (because it is doing Path MTU discovery). It is transmitted without problems through R1 to R2, and then on to R3. However R3 cannot deliver the packet to R4 because the MTU is too low. The result is that the packet is discarded and an ICMP destination unreachable packet is returned to node A.
The problem is that the ICMP datagram generated by router R3 is going to have an RFC-1918 address for its source IP address. This will be returned to node A.
This may not be a problem, but if the first router (R1) has a firewall, it is not unusual to filter out all traffic with source addresses in the RFC-1918 address range (because these numbers are not routable on the public Internet). This will break path MTU discovery just as surely as filtering ICMP messages.
Confused about subnets? Want to try some examples. Use this subnet calculator to try things out.
So who has the class A network addresses? Well it turns out that many of these have been recovered from their original allocations, and handed back to IANA (Internet Assigned Numbers Authority). Many of these have then been allocated to registries such as the American Registry for Internet Numbers (ARIN), and are being carved up into smaller blocks and allocated out. We will discuss how that works in lecture 3.
But there are still a good number of class A networks allocated to organisations that really don’t need blocks that large (although giving up their blocks would be an expensive process). The list below shows the current allocations of all class A networks on the Internet.
1 IANA – Reserved
2 IANA – Reserved
3 General Electric Company
4 Level3/Genuity-BBN (IANA INFO: Bolt Beranek and Newman Inc.)
5 IANA – Reserved
6 Army Information Systems Center
7 IANA – Reserved
8 Level3/Genuity-BBN (IANA INFO: Bolt Beranek and Newman Inc.)
9 IBM
10 IANA – Private Use. See RFC 1918
11 DoD Intel Information Systems
12 AT&T Bell Laboratories
13 Xerox Corporation
14 IANA – Public Data Network
15 Hewlett-Packard Company
16 Digital Equipment Corporation
17 Apple Computer Inc.
18 MIT
19 Ford Motor Company
20 Computer Sciences Corporation
21 DDN-RVN
22 Defense Information Systems Agency
23 IANA – Reserved
24 ARIN – Cable Block (Formerly IANA – Jul 95)
25 Royal Signals and Radar Establishment
26 Defense Information Systems Agency
27 IANA – Reserved
28 DSI-North
29 Defense Information Systems Agency
30 Defense Information Systems Agency
31 IANA – Reserved
32 AT&T (IANA INFO: Norsk Informasjonsteknologi)
33 DLA Systems Automation Center
34 Halliburton Company
35 MERIT Computer Network
36 IANA – Reserved (Formerly Stanford University – Apr 93 to
37 IANA – Reserved
38 COGENT/PSI (IANA INFO: Performance Systems International)
39 IANA – Reserved
40 Eli Lily and Company
41 AFRINIC
42 IANA – Reserved
43 V6NIC
44 Amateur Radio Digital Communications
45 Interop Show Network
46 Level3/Genuity-BBN (IANA INFO: Bolt Beranek and Newman Inc.)
47 Nortel (IANA INFO: Bell-Northern Research)
48 Prudential Securities Inc.
49 IANA (Formerly DoD – Joint Technical Command. Used: May 94
50 IANA (Formerly DoD – Joint Technical Command. Used: May 94
51 Deparment of Social Security of UK (EU territory should be
52 E.I. duPont de Nemours and Co., Inc.
53 Cap Debis CCS (EU territory should be in RIPE database)
54 Merck and Co., Inc.
55 Naval Ocean Systems Center (IANA INFO: Boeing Computer Services)
56 U.S. Postal Service
57 SITA (Equant.Net routable. EU territory should be in RIPE database)
58 APNIC
59 APNIC
60 APNIC
61 APNIC
62 RIPE
63 ARIN
64 ARIN
65 ARIN
66 ARIN
67 ARIN
68 ARIN
69 ARIN
70 ARIN
71 ARIN
72 ARIN
73 ARIN
74 ARIN
75 ARIN
76 ARIN
77 IANA – Reserved
78 IANA – Reserved
79 IANA – Reserved
80 RIPE
81 RIPE
82 RIPE
83 RIPE
84 RIPE
85 RIPE
86 RIPE
87 RIPE
88 RIPE
89 RIPE
90 RIPE
91 RIPE
92 IANA – Reserved
93 IANA – Reserved
94 IANA – Reserved
95 IANA – Reserved
96 IANA – Reserved
97 IANA – Reserved
98 IANA – Reserved
99 IANA – Reserved
100 IANA – Reserved
101 IANA – Reserved
102 IANA – Reserved
103 IANA – Reserved
104 IANA – Reserved
105 IANA – Reserved
106 IANA – Reserved
107 IANA – Reserved
108 IANA – Reserved
109 IANA – Reserved
110 IANA – Reserved
111 IANA – Reserved
112 IANA – Reserved
113 IANA – Reserved
114 IANA – Reserved
115 IANA – Reserved
116 IANA – Reserved
117 IANA – Reserved
118 IANA – Reserved
119 IANA – Reserved
120 IANA – Reserved
121 IANA – Reserved
122 IANA – Reserved
123 IANA – Reserved
124 APNIC
125 APNIC
126 APNIC
In yesterday’s lecture we looked at the network layer, and introduced some concepts. I have added some diagrams to the slides on the course website to make things a little clearer, including this one:
This diagram describes the data encapsulation involved in transmitting packets of data across the network. First the application data is broken up into small units, and then it is passed to the transport layer. The transport layer will add a header to the data unit and pass the protocol data unit (PDU) to the network layer. Now an IP header is added an the packet is passed to the link layer, where an frame header and usually a trailer is added to create a complete frame which is now transmitted across the network.
Encapsulation of these layers means that you can change what is happening at a layer without affecting the other layers. You can transmit frames over Ethernet, or WiFi or some other technology, without changing the upper layers at all. You can move from IPv4 to IPv6 without changing your link layer or ttansport leyer, and you can use any of a variety of transport layer protocols over the same network layer.
The IPv4 header looks like this:
The meaning of the fields in the header is fully described in RFC 791. There is also a good article on IPv4 including a description of the header on Wikipedia. The Wikipedia article also discusses IPv4 address exhaustion, which we mentioned in yesterday’s lecture.
The following diagram describes three of the IPv4 address classes – the “unicast” classes A, B and C. It shows how the first bits of the address can be used to determine the address class.
