-------------------[ Readings ]------------------- Please read Chapter 1 and Chapter 2 of the "TCP/IP Illustrated" textbook (henceforth, "textbook"). As I mentioned in class, if the cost is a concern to you, look for the used copies online; the specific edition doesn't matter to this class. Read Chapter 2 of http://www.mccme.ru/computers/Shalunov-inet.pdf . This short chapter describes an older form of Ethernet that I mentioned in class. Textbook's Chapter 3 mostly has details on other PHYs besides Ethernet. You can skip these at first reading. -------------------[ Read ahead ]------------------- In most class notes, I will give pointers on what I am going to cover during the next class. You may read these chapters ahead of the class to prepare. If you hear me contradicting something you read, ask---there will be extra credit for good questions :) Chapters 4 and 5 of the textbook on ARP and IP. Chapters 3 and 4 of Shalunov's book. -------------------[ Ethernet frames ]------------------- We looked at some Ethernet/IP frames today, which looked similar to: http://nerdcrunch.com/2011/05/09/how-to-decode-ethernet-frames/ For more info on Ethernet frame preamble and structure: http://www.infocellar.com/networks/ethernet/frame.htm Note that we only saw Ethernet II frames today, not the others (no LLC, no SNAP). You may skip reading about those, for now; skip right down to "Assembling a Frame". -------------------[ Pictures ]----------------- The IP header on a T-shirt: http://www.markhneedham.com/blog/wp-content/uploads/2012/07/IP-Header.jpeg -------------------[ Tools ]----------------- We saw the following tools today: ===[ ifconfig (Linux and MacOS X; a similar tool on Windows is "ipconfig") ]=== Ifconfig shows networking interfaces, physical and virtual, that the system currently has active. On my Mac: bash-3.2# ifconfig lo0: flags=8049 mtu 16384 options=3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=1 gif0: flags=8010 mtu 1280 stf0: flags=0<> mtu 1280 en0: flags=8863 mtu 1500 ether 60:f8:1d:c1:c6:4c <=== (1) inet6 fe80::62f8:1dff:fec1:c64c%en0 prefixlen 64 scopeid 0x4 <=== (3) inet 10.10.128.133 netmask 0xfffff800 broadcast 10.10.135.255 <=== (2) nd6 options=1 media: autoselect status: active lo0, gif0, and stf0 are all virtual interfaces. We'll talk about "lo" later---it's a pseudo-interface that lets you connect to your own machine as if it were remote; this is useful for testing networked programs when you only have one machine. en0 is my actual network interface (on Linux, it might be called eth0 or wlan0 if wireless). You can see this interface's MAC address (1), the IP address I got on the local network (2), and the system's attempt to automatically assign me an IPv6 address (3), which is derived from my MAC. We'll talk about other data here during next class. ifconfig or ipconfig is how you can find out what your MAC is. The first three bytes of a MAC address are purchased by vendors; current assignments are posted at http://standards-oui.ieee.org/oui.txt ===[ ping ]=== This tests basic connectivity by sending special "echo request" packets. Most hosts would respond to these with "echo reply" packets (see Shalunov Ch. 4.2). A host, of course, may choose to not reply, or to block these packets, in which case testing connectivity to it is hard. E.g., Macs in "stealth" mode would ignore these packets and not respond (see your "System Preferences > Security & Privacy > Firewall > Firewall Options > Enable Stealth Mode") Here's me pinging Google's private DNS: # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=27.439 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=34.068 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=34.669 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=27.346 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=46 time=36.741 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=46 time=32.422 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=46 time=37.985 ms Request timeout for icmp_seq 7 <=== (1) 64 bytes from 8.8.8.8: icmp_seq=8 ttl=46 time=122.588 ms <=== (2) 64 bytes from 8.8.8.8: icmp_seq=9 ttl=46 time=30.733 ms (1): either the outgoing packet or the echo response packet coming back got lost, possibly due to collisions (2): this request-response took longer than usual. Probably some burst of traffic on the network, which also possibly was the cause of loss in (1) ===[ traceroute ]=== Traceroute uses the TTL field of the IP protocol header to find out the path a packet travels. A well-behaved router subtracts 1 from the TTL field of the packet before forwarding it on. When the subtraction results in a TTL of 0, the router does _not_ forward the packet; instead, it sends back a special packet reporting this event, to the source IP in the original packet (see Shalunov Ch. 4.4 for a quick explanation). A handy diagram: https://2buntu.com/articles/1203/traceroute-how-does-it-work/ On Ubuntu Linux, you may need to "apt-get install traceroute". Here's me trying to trace a path to Google's public domain name server: # traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets 1 10.10.128.1 (10.10.128.1) 4.506 ms 2.466 ms 3.544 ms 2 vtelinet-216-66-104-1.vermontel.net (216.66.104.1) 6.697 ms 3.795 ms 3.295 ms 3 * vtelinet-216-66-105-25.vermontel.net (216.66.105.25) 99.203 ms 7.067 ms 4 vtelinet-216-66-105-26.vermontel.net (216.66.105.26) 17.541 ms 123.236 ms 16.471 ms 5 google.tienyc.telxgroup.net (206.126.115.20) 18.336 ms 132.773 ms 20.886 ms 6 216.239.50.139 (216.239.50.139) 14.870 ms 209.85.247.7 (209.85.247.7) 122.942 ms 216.239.50.139 (216.239.50.139) 14.594 ms 7 216.239.58.111 (216.239.58.111) 16.145 ms 216.239.40.135 (216.239.40.135) 167.409 ms 108.170.236.127 (108.170.236.127) 13.210 ms 8 108.177.3.53 (108.177.3.53) 18.832 ms 108.170.236.245 (108.170.236.245) 23.910 ms 19.516 ms 9 216.239.48.6 (216.239.48.6) 58.947 ms 216.239.48.31 (216.239.48.31) 27.897 ms 216.239.48.6 (216.239.48.6) 37.825 ms 10 209.85.250.247 (209.85.250.247) 26.663 ms 26.692 ms 209.85.251.243 (209.85.251.243) 26.759 ms 11 * * * 12 google-public-dns-a.google.com (8.8.8.8) 50.729 ms 121.576 ms 26.973 ms Note that the packet paths start varying widely once they get into Google's network, each packet taking its own path. This is probably due to Google's load-balancing. The path to our CS webserver is much simpler: # traceroute www.cs.dartmouth.edu traceroute to katahdin.cs.dartmouth.edu (129.170.213.101), 64 hops max, 52 byte packets 1 10.10.128.1 (10.10.128.1) 2.399 ms 1.491 ms 1.637 ms <=== (1) 2 vtelinet-216-66-104-1.vermontel.net (216.66.104.1) 3.221 ms 8.560 ms 3.705 ms <=== (2) 3 vtelinet-216-66-108-106.vermontel.net (216.66.108.106) 3.661 ms 3.692 ms 3.710 ms 4 border1-rt.berry1-crt.dartmouth.edu (129.170.1.41) 5.301 ms 4.494 ms 4.453 ms <=== (3) 5 129.170.1.118 (129.170.1.118) 4.712 ms 4.657 ms 4.490 ms <=== (4) 6 katahdin.cs.dartmouth.edu (129.170.213.101) 4.926 ms 4.193 ms 4.031 ms We go through out through "Dartmouth Public"'s gateway (1), through Vermont Telecom's link serving it (2), and into the college network through Dartmouth's border router in Berry (3). From there, we encounter an internal core router (4), and finally the webserver (which is really called katahdin; "www" is its alias). Suggestion: Trace the route to your favorite website. What can you find out about the route? Who carries your packets while you connect from home or from some other network? ===[ Wireshark ]=== Wireshark is the tool for capturing every packet your network interface device sends and receives. I am using the Mac version from https://www.wireshark.org/download.html A short and useful tutorial can be found here: http://www.computerweekly.com/tutorial/Quick-and-dirty-Wireshark-tutorial We'll be using Wireshark a lot, so download and install it on your system. For Ubuntu or Debian Linux, "apt-get install wireshark" will do the job. ===[ whois ]=== Whois queries the registrars in charge of assigning IP ranges about the owner of an IP address or a domain name. It is useful for finding out where the connections to your machine appear to be coming from or going to. Here is me asking about an IP from the above traceroute. The response gives me the registered IP block that this address belongs to (216.66.96.0 - 216.66.127.255), the owner of this block (Vermont Telecom), various organizational information, and the contract info in case I see addressed in this block having trouble or being abused, including the engineer's name (Robinson, Arianna). $ whois 216.66.105.25 # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # If you see inaccuracies in the results, please report at # https://www.arin.net/public/whoisinaccuracy/index.xhtml # # # Query terms are ambiguous. The query is assumed to be: # "n 216.66.105.25" # # Use "?" to get help. # # # The following results may also be obtained via: # https://whois.arin.net/rest/nets;q=216.66.105.25?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2 # NetRange: 216.66.96.0 - 216.66.127.255 CIDR: 216.66.96.0/19 NetName: VTEL-TELE-BLK-1 NetHandle: NET-216-66-96-0-1 Parent: NET216 (NET-216-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Vermont Telephone Company, Inc. (VRTC) RegDate: 2001-02-20 Updated: 2016-11-02 Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE Ref: https://whois.arin.net/rest/net/NET-216-66-96-0-1 OrgName: Vermont Telephone Company, Inc. OrgId: VRTC Address: 354 River St City: Springfield StateProv: VT PostalCode: 05156 Country: US RegDate: 2001-02-20 Updated: 2017-01-28 Ref: https://whois.arin.net/rest/org/VRTC OrgAbuseHandle: IAAC1-ARIN OrgAbuseName: IP Address Abuse Contact OrgAbusePhone: +1-802-885-9002 OrgAbuseEmail: abuse@vermontel.net OrgAbuseRef: https://whois.arin.net/rest/poc/IAAC1-ARIN OrgTechHandle: IATC-ARIN OrgTechName: IP Address Technical Contact OrgTechPhone: +1-802-885-9002 OrgTechEmail: techie@vermontel.net OrgTechRef: https://whois.arin.net/rest/poc/IATC-ARIN RNOCHandle: IATC-ARIN RNOCName: IP Address Technical Contact RNOCPhone: +1-802-885-9002 RNOCEmail: techie@vermontel.net RNOCRef: https://whois.arin.net/rest/poc/IATC-ARIN RAbuseHandle: IAAC1-ARIN RAbuseName: IP Address Abuse Contact RAbusePhone: +1-802-885-9002 RAbuseEmail: abuse@vermontel.net RAbuseRef: https://whois.arin.net/rest/poc/IAAC1-ARIN RTechHandle: ROBIN528-ARIN RTechName: Robinson, Arianna RTechPhone: +1-802-885-9000 RTechEmail: arianna@vermontel.com RTechRef: https://whois.arin.net/rest/poc/ROBIN528-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # # If you see inaccuracies in the results, please report at # https://www.arin.net/public/whoisinaccuracy/index.xhtml # Suggestion: Find out what Dartmouth's block looks like in this database, and who is the network contact for Dartmouth.