Björn Landfeldt School of Information Technologies NETS 3303 Network Layer, Internet Protocol IP.

Björn LandfeldtSchool of Information Technologies

NETS 3303

Network Layer, Internet Protocol IP


Overview• intro• IP addresses• subnetting• header

– fragmentation, ttl, options

• routing/algorithms/architecture• ARP


Fundamental, IPv4

• fundamental TCP/IP protocol• RFC 791, other related RFCs

– Inet checksum, rfc 1071, 1141, 1624

– path mtu, rfc 1191– ip datagram reassembly 815– 1122, communications


Fundamental idea

• ip implements a ip virtual network on top of different kinds of hw where ip address is endpoint

• hw is hidden by network layer (except for a few things like MTU)


what does IP do (and not do?)

• sends and recvs packets to/from ip addresses - ip datagrams

• no retries, doesn’t promise reliable delivery

• packets due to various reasons may be lost,

• duplicated, delayed, delivered out of order, or corrupted -

• best effort - don’t lose them on purpose but only when nets busy - resources unavailable


IP functions• route packets

– routing: process of determining path for data

– ip routes packets when they come from• transport layer (down stack)• link layer (up stack) - we are router and forward pkts

• fragmentation acc. to link-layer MTU• handle ip options• send/recv ICMP error and control messages


IP address• 32 bits, “dotted-decimal” notation

– 1.2.3.4, big-endian byte order, 0..255 is range

• associated with interface, not machine• if machine > 1 i/f, then multi-homed• if multi-homed, not necessarily router• ip address in UNIX assigned to i/f with

– #ifconfig ed0 inet 131.253.1.2 netmask 255.255.255.0


IP address structure

• each address has structure in it: (network, subnet, host)

• classically address consists of (net, host) portions

• subnet mask used to determine subnet part– taken from host bits– ipaddress & subnet mask


IP address table (net/host)type prefix bytes range

class A 0 1 net:3 host 1-126.h.h.h

class B 10 2:2 128-191.n.h.h

class C 110 3:1 192-223.n.n.h

class D 1110 flat 224..239

class E 11110 - 240..254

class D: multicastclass E: experimental (unused at present), note 255 used for broadcast


IP addresses, examples

• 0.0.0.0 - if src, then boot == “this net, this host” if dest, old 4.2 BSD broadcast address

• 127.0.0.0 - localhost (loopback)• 1.2.3.4 - class A• 143.1.2.3 - class B• 201.1.2.3 - class C• 224.0.0.1 - multicast• 255.255.255.255 - limited broadcast• 200.0.1.255 - directed broadcast (assume subnet == class C part)


IP address problems

• assigning class by bit means class A takes 1/2 of range, class B 1/4, class C 1/8, etc.

• problems with current setup– class assignment is wasteful– ip host addresses not necessarily utilized well

– too many networks in core routers– running out of ip addresses ??


Subnetting• subnet - use single IP network address to hide multiple physical nets

• subnet notion converts (net, host) into slightly more hierarchical (net, subnet, host)

• associate subnet mask with i/f ip address

• Example, class B, one byte of subnet: ip = 148.1.1.1 subnet=255.255.255.0


Subnetting• subnetting functions:• 1. you can subnet an ip address and split it up on separate networks across routers (conserve address space)

• 2. you hide your routing structure from remote routers, thus reducing routes in their routing tables

• if dest ip addr & subnet mask == my ip addr and subnet mask

dest is on same subnet else on different subnet (send pkt to router)


IP encapsulation


IP Header


IP Header• ip version == 4• header length in 32-bit words, h == 5 with no options (20 bytes)

• type of service and precedence– not used much in past but starting to be used

– bits 0-2, precedence– bits 3-5, TOS, hint to routing about how to queue• D (bit 3) - low delay (telnet),• T (4) - high thruput (FTP), R (5) - reliability


IP Header• total length - max ip datagram is 64k• fragmentation

– fragment ip_id stays the same for all fragments

– flags (DONT_FRAGMENT, MORE_FRAGMENTS)– fragment offset from 0 start of packet, e.g.,

– 0, 0x400, 0x800– ip length is length of fragment, not total datagram


How it works• ip fragments because outgoing packet is too big for MTU of i/f

• fragments must be reassembled at final ip destination and can be fragmented again on way

• if any fragment lost, all of datagram must be resent (not by IP)

• IP uses best effort even to allocate internal buffers

• TCP tries to avoid, UDP not smart enough• IP fragmentation not a STRONG mechanism


IP Fragmentation

ip_id, ip_src retained in all (new) fragments


More fragmentation• reassembly done at ultimate destination

– pros:• simplicity - fragments can be routed independently

• simplicity - intermediate routers don’t have to store

– cons:• any fragment lost, entire datagram lost

• path MTU is a way around• note: routers may not see all fragments


IP header

• proto type - TCP, UDP, ICMP• checksum

– over header only, useful?– same algorithm used by tcp/udp– with ip itself, only over header

•deemed not useful in IPv6

– routers must redo IP checksum since ttl changes


TTL

• TTL - time to live, actually hop count, not time

• when packet crosses router– ttl--– if ttl == 0

• discard and send ICMP ttl exceeded to ip src

• important guarantee that datagrams will be discarded even if network loops


IP options• not much used and possibly not very useable

• variable length encoding mechanism

• options come in multiples of 32 bits

• pro: extensible format• con: not as easy to parse as fixed format


Options

• end of option list• loose source routing: specify inexact path

• strict source routing exact path (with ip addresses)

• record route - possibly useful

• gather timestamps


Options bad things

• encoding is not efficient for routers

• length is limited by IP header length – not big enough for size of Inet

• source routing not secure -- someone could stick in an intermediate route and spy on your packets


Routing• routing - the process of choosing a path over which to send datagrams

• hosts and routers route• input: ip destination address• output: next hop ip address and internally an interface to send it out

• routing does not change ip dest address


How configure routing table

• static routes - by hand, on unix with % route to_dest via_next_hop

• dynamically via routing daemon, routed or gated on UNIX, protocols=RIP/OSPF/BGP

• via ICMP redirect


View routing table

• unix host– % netstat -rn

• n is for NO dns, else you may cause DNS queries

• Linux– % route -n

• cisco router– (router) show ip route


Routing table• entries logically (destination, mask, via gateway, metric/s)

• destination - network or host address• mask - subnet mask for dst address• via gateway - next hop (maybe router)• metric/s - depends on routing table algorithm and dynamic routing protocols


Manual entries

• on FreeBSD unix host:– # route add default 204.1.2.3 (default route)

– # route add 1.1.1.1 2.2.2.2• 2.2.2.2 is the next-hop router for 1.1.1.1• we must have direct connection to 2.2.2.2 (i/f must be on same subnet and must exist)

• # ifconfig ed0 2.2.2.1 (our i/f must exist)

• Linux– Route add -net 1.1.1.1


SOME possible kinds of routes

• host, 210.1.3.21/32 (to specific host)• subnet, 131.253.1.2/24 (to specific subnet)

• network, 131.253.0.0/16 (to specific net)• default route - normally the router on a net, send it here when nothing else matches– expressed internally as 0.0.0.0

• note: default route to host route – least specific to most specific (natural ordering)


ARP, The problem• problem: how does ip address get mapped to ethernet address?

• 2 machines on same enet can only communicate if they know MAC/hw addr

• solutions:– configure addresses by hand (ouch!)– encode in IP address (48 bits in 32?)– use broadcast?


Solution, ARP• rfc 826• host A, wants to resolve IP addr B,

– send BROADCAST arp request– get UNICAST arp reply from B

• same link only• ethernet (or MAC) specific, although protocol designed to be extensible

• implemented in driver, not IP


% arp -a (SunOs)# arp -abanshee.cs.pdx.edu (131.252.20.128) at 0:0:a7:0:2d:a0pdx-gwy.cs.pdx.edu (131.252.20.1) at 0:0:c:0:f9:17longshot.cs.pdx.edu (131.252.20.129) at 8:0:11:1:44:68walt-suncs.cs.pdx.edu (131.252.21.2) at 8:0:20:e:21:25walt-cs.cs.pdx.edu (131.252.20.2) at 8:0:20:e:21:25connor.cs.pdx.edu (131.252.21.179) at 0:0:c0:c5:57:10dazzler.cs.pdx.edu (131.252.21.132) at 8:0:11:1:12:82sprite.cs.pdx.edu (131.252.21.133) at 8:0:11:1:12:e7

(DNS name,ip address,Ethernet address)


Arp command, functions

• ping someone and learn MAC address

• debugging• delete out of date ARP entry (you changed the IP address, and you don’t want to wait, OR somebody mucked up)


Refinements

• o.s. will cache arp replies in arp cache (ip , MAC, 20 minute timeout)– don’t need to do arp on every packet

• machine may store all arp broadcast to get sender ip/mac mapping

• recv. machines can update their cache


ARP protocol1. A to B, arp request/broadcast on link2. B to A, arp reply/unicast


ARP header


Header details• header format is not fixed, somewhat dynamic (not used though)

• hw type, ethernet == 1• protocol type, ip = 0x800• hwlen, 6 (MAC), plen 4 (ip)• operation: (used by rarp too)

– 1: arp request, 2: arp reply– 3: rarp request, 4: rarp reply


More Details

• sender hw addr, 6 bytes– the answer, if reply

• sender ip: 4 bytes• target hw address: 6 bytes

– 0 in request• target ip: 4 bytes


Proxy ARP

• basic idea: machine A answers requests for machine B (that can’t arp for some reason), forwards packets to B somehow– machine A might have 2 IP addresses associated with one interface


Proxy ARP pros, cons• pros

– same network numbers– can aid dumb host that can’t arp– remote serial host appears on same ethernet courtesy of terminal emulator/router

• cons– can drive you nuts -- debugging– not simple and not secure


gratuitous/promiscuous arp

• grat arp - at boot or change of ip address, issue broadcast arp request for YOURSELF– unix ifconfig does this– detect other boxes with same IP address– allow recv boxes to cache your MAC addr

• promiscuous arp - issue bcast arp to change other’s ideas of ip/mac mapping– problem: no one guaranteed to be listening

Björn Landfeldt School of Information Technologies NETS 3303 Network Layer, Internet Protocol IP.

Documents

Transcript of Björn Landfeldt School of Information Technologies NETS 3303 Network Layer, Internet Protocol IP.