Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 IP: putting it all together Part 2 G53ACC Chris Greenhalgh.

Similar presentations


Presentation on theme: "1 IP: putting it all together Part 2 G53ACC Chris Greenhalgh."— Presentation transcript:

1 1 IP: putting it all together Part 2 G53ACC Chris Greenhalgh

2 2 Contents l Fragmentation l Error reporting (ICMP) l Auto-configuration l Network Address Translation

3 3 Fragmentation l IP allows datagram sizes up to 64Kbytes l Physical networks often only support smaller frame types (Maximum Transmission Unit, MTU): –E.g. Ethernet 1500bytes, dialup PPP ~256bytes l  Single IP datagram may need to be divided into “fragments” for transmission…

4 4 IP fragmentation l Each fragment is a (new) IP packet –Has IP header, original source & destination –Identification field same for each fragment –Fragment offset identifies what bit it is –“More Fragments” flag set in all but last fragment

5 5 Fragmenting packets l May be done by sending host l May be done by intermediate router: l May be prevented with IP “Do not fragment” flag –  ICMP fragmentation required response if a router would have needed to fragment it –Used by TCP to learn path MTU and avoid fragmentation

6 6 Reassembling fragments l Done ONLY by the ultimate destination of the packet –After checking header checksum and destination, but before any more processing l Maintains a pool of fragments –Discarded after a time-out –If all fragments of a datagram received the datagram is reassembled and handled as before

7 7 Fragmentation and reassembly issues l Lose one segment and you lose the whole message –Bad if segment loss is likely or number of segments is large l E.g. NFS v.2 used UDP, v.3 uses TCP –because block size 8K -> 32K –many more segments! => higher effective packet loss rate with UDP and more wasted bandwidth

8 8 Error reporting l IP includes Internet Control Message Protocol (ICMP) RFC 792 l ICMP messages sent in IP packets –(i.e. same protocol level as UDP or TCP) –IP protocol number 2 l Not seen by applications - between hosts or routers OSs only –Error messages –Informational messages (mostly superceded by DHCP) l NOTE: some may be dropped by firewalls to avoid possible attacks e.g. denial of service (but makes diagnosis of problems harder)

9 9 ICMP message types

10 10 ICMP Error messages (i) l Source Quech –router to host, please slow down (buffer overflow) l Time exceeded –datagram discarded due to TTL=0 or lost fragment l can be used to trace a route by gradually increasing TTL and seeing which router it gets to before timing out l See commands: tracert (windows), traceroute (unix)

11 11 ICMP error messages (ii) l Destination unreachable –datagram discarded by router because host or network not reachable –Datagram discarded by host because UDP/TCP port not in use l Redirect –datagram sent to wrong next hop (gives alternative) l Fragmentation required –if fragmentation not allowed but necessary l can be used to determine path MTU (maximum transmission unit)

12 12 ICMP informational messages l Echo Request/Reply –ICMP software sends Reply when receives Request l test computer accessible (e.g. ping) l Address mask request/reply –allow host on booting to query local router for netmask (see DHCP, later) l Gateway discovery –allow host on booting to find default router (see DHCP)

13 13 Auto-configuration - low-level l ICMP address mask request/reply –=> netmask l Reverse ARP (RARP) RFC 903 –send Ethernet address and a server returns your IP address l ICMP gateway discovery –=> default route

14 14 Auto-configuration - higher- level (i) l Bootstrap Protocol (BOOTP) RFC 951 and RFC 1542 –single BOOTP request –BOOTP server replies with IP address, Router IP address, server information –requires server configuration for each machine

15 15 Auto-configuration - higher level (ii) l Dynamic Host Configuration Protocol (DHCP) RFC 1541 –conceptually an extension of BOOTP –server can maintain pool of IP addresses –no configuration for a new machine –but IP address (and therefore domain names) may change each time a machine is booted

16 16 Network Address Translation: motivations l IP requires every machine to have a unique IP address –But there are not enough IPv4 addresses to go round so… –Allow sites to have their own internal private addresses –And share just a few global IP addresses between all of their machines

17 17 Network Address Translation –NAT device at boundary between private network and Internet l translates to and from internal private addresses…

18 18 Simple NAT l Maps between an internal private IP address and an external global IP address –E.g. for a server machine –NAT device is configured (by hand?!) with the address mapping –Re-writes IP packet headers when forwarding:

19 19 Network Address and Port Translation (NAPT) l Allows a single external IP to be shared by many private IPs –By changing port numbers as well as IP addresses:

20 20 Configuring NAPT l Can be statically configured –E.g. for a web server l External IP, port 80  Internal server IP, port 80 l Can be dynamically configured by outgoing connections/packets –For normal clients, e.g. accessing external servers… –NB. Does NOT allow external hosts to initiate connections to internal hosts (good security )

21 21 NAPT dynamic configuration example l Internal IP I A, port P A sends a packet to external IP I B, port P B … –IP header has IPs, UDP/TCP header has ports l NAT device sees outgoing packet –Chooses a currently unused port number P C –for its own global IP address, I C –Creates a new translation mapping l I A, P A  I C,P C (leaves external IP/port) –Discards mapping if unused for some time (configurable)

22 22 NAT/NAPT deployment l Most ISPs –Hence need to apply specifically for “static” (globally routable) IP addresses l Many home/small office firewalls and broadband routers

23 23 Additional NAT/NAPT issues l Internet server sees NAT device’s IP address and translated port number (if NAPT) l Private network client only knows its private IP address and local port l  Client IP address not transferable (correct or useful) outside the NAT device –E.g. RMI references passed from client to server will contain private IP and so won’t work for server –The client and server will disagree about what they consider the client’s IP address to be (security issue?!)


Download ppt "1 IP: putting it all together Part 2 G53ACC Chris Greenhalgh."

Similar presentations


Ads by Google