TDC 375-701 Student Name: Homework 3 Due 2009-09-30 From TCP/IP Protocol Suite, 4th Edition, answer: 6.7, Questions 1, 3, 5, 15, 18 7.12, Questions 1, 11, 15 Q. 6.7.1 Direct Q. 6.7.3. The question could be open to some interpretation based on the lack of information given. We can take some pretty good guesses at what it probably has though, especially given the example in the book. It probably has a default route (0.0.0.0/0) out interface m0. It also appears to have a route for 111.0.0.0/8 out m1. We don't know what routing protocols, if any are being used, but it is probably safe to assume that it also knows about 170.14.0.0/16, 145.80.0.0/16, and 192.16.7.0/24 via its m1 interface. So in table form, it would look something like this: prefix next-hop interface 0.0.0.0/0 [unknown] m0 111.0.0.0/8 connected m1 170.14.0.0/16 111.25.19.20 m1 145.80.0.0/16 111.25.19.20 m1 192.16.7.0/24 111.15.72.32 m1 Note, the text refers to these as Class A, B and C networks. Classful addressing is obsolete and deprecated. Don't do that. Q. 6.7.5. We don't know which is the ingress (incoming) interface and that may potentially matter. If it came into R1 on interface m0 it might send a ICMP redirect. Regardless, our approach to solving this problem is the same. A source host on the m1 or m2 LAN is probably the original sender. They did ARP to obtain the local R1 LAN interface address, which they put into the L2 destination address field. When R1 gets it and gives it to L3, it does some quick sanity checks (e.g. TTL !=0, checksum looks good). It'll then perform a route lookup. The book's example uses a classful-based approach to do the lookup. Pay no attention to that, obsolete, deprecated, yadda, yadda, yadda. A best match route is examined based on the destination and forwarding out the corresponding interface, in this case m0 to R3's m1 interface. R1 will need the L2 address associated with 111.15.17.32, the L3 address associated with the next hpo. R1 might have to ARP first if there is no cached entry, otherwise it makes the L2 destination m1 on R3 and away it goes. Q. 6.7.15. Sure. If a host on any of its attached networks off interfaces m0, m1 or m2 send something to that destination, R1 should get it and forward it along to R2, which should in turn forward it to R3. Of course, if routing is doing its job directly based on this topology, hosts on m0, m1 and m2 (and the router itself) are the sources that R1 should ever see sending a packet to that destination. Q. 6.7.18. This question is admittedly pretty vague. The answer really depends on how the routing protocols and routers are setup. Intuitively, and probably the best answer would be if it looked something like this: 120.14.64.0/23 interface_Small_ISP_1 ... ... 120.14.78.0/23 interface_Small_ISP_8 120.14.64.0/20 connected (link Regional ISP is on) 0.0.0.0/ (default) interface_Regional_ISP Based on the diagram, the easiest thing is to just static route everything and not use a routing protocol. If they wanted all the route table entries they could possibly get, they'd probably do BGP out all interfaces and not aggregate any routes. Then they could potentially have all the /23's from their downstreams, plus the /30's from their customers, plus the /20's from other Local ISPs, plus all their downstream prefixes, etc. Why might this occur? While all the /30's might not be in the routing table, the downstream /23's the prefixes from other Local ISPs might be in your routing table. This is likely if the topology is actually more redundant, that is, Local ISP has more than one upstream regional provider. In practice that is probably the case more often than not. Its also highly unlikely that'd have a /20 network between them and their regional ISP. This example is not very realistic, rarely is the topology so neat, hierarchical and clean looking. Q. 7.12.1. There are the fields that are very likely to change and then some fields that may change due to "packet mangling" devices, sometimes generically called middle boxes. I'll cover the first case first. In a nutshell, in practice the TTL and checksum fields are the only ones that will always change when crossing a router (if they don't not, then its either the router is broken or its not really a router :-). The service bits can change in theory, but rarely do and if they do, they are often changed only once at some "policy enforcement border ingress" point. Typically the application sets the service (ToS/DiffServ) bits and they'll stay that way end-to-end, but if someone is trying to actually implement CoS/QoS, routers or some middle boxes may adjust them along the way. Since these bits, even if utilized in one network, are often ignored across ASes, changes here are rare in practice on the public Internet. The ID field won't change in practice, but the use of this field to encode some information, such as source tracing has been proposed. Other fields, for example, options, total length and even addresses can change to a variety of circumstances. NATs are a good example of addresses changing. A firewall might try to remove or change fields, though this is not common. Options may change, such as record route, as the list gets populated with routers as the packet travels through the net, but options are rarely seen and often disallowed anyway. Fragmentation also makes a lot of things change. So your answer may vary depending on your perspective. Q. 7.12.11. With no options, the header length will be the minimum and typical value, 5. This is a value of the header length in 32-bit words, so its interpreted as 20 bytes of header. The total length will be the header plus the data, so 20 + 1024 = 1044 bytes in decimal notation. Q. 7.12.15. a. No (header length = 5, minimum size header) b. No (flags and fragment offset = 0) c. 64 bytes (total length = 84, subtract header of 20) d. Its not a matter of "used" or not, its not an option. This is actually a broken packet, because the checksum has an invalid value. The author is confused. Only in UDP are you permitted to forgo the checksum, and even then its highly discouraged. I did it quickly so it might not be right, but I computed the checksum to be 0x5841. e. It should be able to reach 32 routers (TTL = 32). f. 3 g. 00, default, best effort service Also answer the following questions: Q. Using your own computer or a lab computer you have access to, copy and paste the results of the command that shows the interface, IP address and network mask (Windows users: ipconfig /all, UNIX/Mac users: ifconfig). What is your address using the 'slash' (/) notation? A. There is no standard answer for this. Depends on your OS and IP address configuration. Q. Would you consider MPLS a good example of the end-to-end argument in practice or do you think its use is counter to the end-to-end argument on the Internet? Explain. A. This may be a bit subjective and you could potentially argue the case one way or another. Although it would probably take a lot to come close to convincing me that MPLS is a good example of the end-to-end argument in practice. I might argue that you should be able to build a network with no need for MPLS, but still accomplish most of what people do with MPLS today. So that would argue that it provides no additional benefit in that lower layer of the network. Someone else might argue that in the real world, with real complex networks they can't easily retrofit the network, performing billing and perform "traffic engineering" without it effectively. $Id: homework3.txt,v 1.5 2009/10/03 14:52:12 jtk Exp $