Longer address field:

IPv6

128 bits can support up to 3.4 x 1038 hosts

Simplified header format:

Simpler format to speed up processing of each header All fields are of fixed size IPv4 vs IPv6 fields:
Same: Version Dropped: Header length, ID/flags/frag offset, header checksum Replaced: Datagram length by Payload length Protocol type by Next header TTL by Hop limit TOS by traffic class New: Flow label

 Flexible support for options: more efficient and flexible options encoded in optional extension headers Flow label capability: flow label to identify a packet flow that requires a certain QoS Security: built-in authentication and confidentiality Large packets: supports payloads that are longer than 64 K bytes, called jumbo payloads. Fragmentation at source only: source should check the minimum MTU along the path No checksum field: removed to reduce packet processing time in a router

Other IPv6 Features

IPv6 Header Format

0 4 12 16 24 31

Version

Traffic Class
Payload Length Next Header

Flow Label
Hop Limit

Source Address

Destination Address

Version field same size, same location Traffic class to support differentiated services Flow: sequence of packets from particular source to particular destination for which source requires special handling

IPv6 Header Format

0 4 12 16 24 31

Version

Traffic Class
Payload Length Next Header

Flow Label
Hop Limit

Source Address

Destination Address

Payload length: length of data excluding header, up to 65535 B Next header: type of extension header that follows basic header Hop limit: # hops packet can travel before being dropped by a router

 Address Categories Unicast: single network interface Multicast: group of network interfaces, typically at different locations. Packet sent to all. Anycast: group of network interfaces. Packet sent to only one interface in group, e.g. nearest. Hexadecimal notation Groups of 16 bits represented by 4 hex digits Separated by colons
4BF5:AA12:0216:FEBC:BA5F:039A:BE9A:2176

IPv6 Addressing

Shortened forms:
4BF5:0000:0000:0000:BA5F:039A:000A:2176 To 4BF5:0:0:0:BA5F:39A:A:2176 To 4BF5::BA5F:39A:A:2176

Mixed notation:
::FFFF:128.155.12.198

Address Types based on Prefixes

Binary prefix 0000 0000 Types Percentage of address space 0.39 Reserved

0000 0001
0000 001 0000 010 0000 011 0000 1 0001 001 010 011 100 101 110 1110 1111 0 1111 10 1111 110 1111 1110 0 1111 1110 10 1111 1110 11 1111 1111

Unassigned
ISO network addresses IPX network addresses Unassigned Unassigned Unassigned Unassigned Provider-based unicast addresses Unassigned Geographic-based unicast addresses Unassigned Unassigned Unassigned Unassigned Unassigned Unassigned Unassigned Link local use addresses Site local use addresses Multicast addresses

0.39
0.78 0.78 0.78 3.12 6.25 12.5 12.5 12.5 12.5 12.5 12.5 6.25 3.12 1.56 0.78 0.2 0.098 0.098 0.39

Special Purpose Addresses

n bits 010 Registry ID m bits Provider ID o bits Subscriber ID p bits Subnet ID (125-m-n-o-p) bits Interface ID

Provider-based Addresses: 010 prefix

Assigned by providers to their customers Hierarchical structure promotes aggregation

Registry ID: ARIN, RIPE, APNIC ISP Subscriber ID: subnet ID & interface ID

Local Addresses: do not connect to global Internet

Link-local: for single link Site-local: for single site Designed to facilitate transition to connection to Internet

Special Purpose Addresses

Unspecified Address: 0::0
Used by source station to learn own address

Loopback Address: ::1 IPv4-compatible addresses: 96 0s + IPv4

For tunneling by IPv6 routers connected to IPv4 networks ::135.150.10.247

IP-mapped addresses: 80 0s + 16 1s + IPv4

Denote IPv4 hosts & routers that do not support

Extension Headers
Daisy chains of extension headers
Basic header Next header = TCP TCP segment

Basic header Next header = routing

Routing header Next header = fragment

Fragment header Next header = authentication

Authentication header Next header = TCP

TCP segment

Extension headers processed in order of appearance

Six Extension Headers

Header code 0 Header type Hop-by-hop options header

43
44 51 52 60

Routing header
Fragment header Authentication header Encapsulating security payload header Destination options header

Extension Headers
Large Packet: payload>64K
0 Next header 8 0 Jumbo payload length 16 194 24 31 Opt len = 4

Fragmentation: At source only

8 Next header Reserved 16 Fragment offset Identification 29 31 Res M

Extension Headers
Source Routing: strict/loose routes
0 8 16 24 31

Next header
Reserved

Header length

Routing type = 0
Strict/loose bit mask

Segment left

Address 1

Address 2

...
Address 24

Migration from IPv4 to IPv6

Gradual transition from IPv4 to IPv6 Dual IP stacks: routers run IPv4 & IPv6
Type field used to direct packet to IP version

IPv6 islands can tunnel across IPv4 networks

Encapsulate user packet insider IPv4 packet Tunnel endpoint at source host, intermediate router, or destination host Tunneling can be recursive

Migration from IPv4 to IPv6

Source Tunnel head-end Tunnel Tunnel tail-end Destination

(a) IPv6 network

IPv6 header IPv4 network

IPv4 header

IPv6 network

Source Link

Destination

(b) IPv6 network IPv6 network

ARP and RARP

Position of ARP and RARP in TCP/IP protocol suite

ARP associates an IP address with its physical address. On a typical physical network, such as a LAN, each device on a link is identified by a physical or station address that is usually imprinted on the NIC

Case 1

Case 2

Case 3

Case 4

Example
A host with IP address 130.23.43.20 and physical address B2:34:55:10:22:10 has a packet to send to another host with IP address 130.23.43.25 and physical address A4:6E:F4:59:83:AB (which is unknown to the first host). The two hosts are on the same Ethernet network. Show the ARP request and reply packets encapsulated in Ethernet frames. Figure shows the ARP request and reply packets. Note that the ARP data field in this case is 28 bytes, and that the individual addresses do not fit in the 4-byte boundary. That is why we do not show the regular 4-byte boundaries for these addresses. Also note that the IP addresses are shown in hexadecimal.

Proxy ARP

RARP
RARP finds the logical address for a machine that only knows its physical address.

The RARP request packets are broadcast; the RARP reply packets are unicast.

RARP operation

RARP Packet

Encapsulation of RARP packet

Fragmentation and Reassembly

Identification identifies a particular packet Flags = (unused, dont fragment/DF, more fragment/MF) Fragment offset identifies the location of a fragment within a packet Reassemble at destination Fragment at source
IP Source Router Destination

Fragment at router

IP

Network

Network

Example: Fragmenting a Packet

A packet is to be forwarded to a network with MTU of 576 bytes. The packet has an IP header of 20 bytes and a data part of 1484 bytes. and of each fragment. Maximum data length per fragment = 576 - 20 = 556 bytes. We set maximum data length to 552 bytes to get multiple of 8.
Total Length Original packet Fragment 1 Fragment 2 Fragment 3 1504 572 572 400 Id MF x x x x 0 1 1 0 Fragment Offset 0 0 69 138

Internet Control Message Protocol (ICMP)

RFC 792; Encapsulated in IP packet (protocl type = 1) Handles error and control messages If router cannot deliver or forward a packet, it sends an ICMP host unreachable message to the source If router receives packet that should have been sent to another router, it sends an ICMP redirect message to the sender; Sender modifies its routing table ICMP router discovery messages allow host to learn about routers in its network and to initialize and update its routing tables ICMP echo request and reply facilitate diagnostic and used in ping

ICMP Basic Error Message Format

0 Type 8 Code Unused IP header and 64 bits of original datagram 16 Checksum 31

Type of message: some examples

0 Network Unreachable; 3 Port Unreachable 1 Host Unreachable 4 Fragmentation needed 2 Protocol Unreachable 5 Source route failed 11 Time-exceeded, code=0 if TTL exceeded

Code: purpose of message IP header & 64 bits of original datagram

To match ICMP message with original data in IP packet

TCP
Reliable byte-stream service More complex transmitter & receiver
Connection-oriented: full-duplex unicast connection between client & server processes Connection setup, connection state, connection release Higher header overhead Error control, flow control, and congestion control Higher delay than UDP

Most applications use TCP

HTTP, SMTP, FTP, TELNET, POP3,

Reliable Byte-Stream Service

Stream Data Transfer

transfers a contiguous stream of bytes across the network, with no indication of boundaries groups bytes into segments transmits segments as convenient (Push function defined)
Reliability

error control mechanism to deal with IP transfer impairments

Write 45 bytes Write 15 bytes Write 20 bytes segments buffer

Application Transport
Error Detection & Retransmission

Read 40 bytes Read 40 bytes

ACKS, sequence #

buffer

Flow Control
Buffer limitations & speed mismatch can result in loss of data that arrives at destination Receiver controls rate at which sender transmits to prevent buffer overflow
Application Transport buffer segments advertised window size < B buffer used
buffer available = B

Congestion Control
Available bandwidth to destination varies with activity of other users Transmitter dynamically adjusts transmission rate according to network congestion as indicated by RTT (round trip time) & ACKs Elastic utilization of network bandwidth
Application Transport
RTT Estimation

segments buffer ACKS buffer

TCP Multiplexing
A TCP connection is specified by a 4-tuple (source IP address, source port, destination IP address, destination port) TCP allows multiplexing of multiple connections between end systems to support multiple applications simultaneously Arriving segment directed according to connection 4-tuple
1 2

...

...

...

TCP IP A
(A, 6234, B, 80) (A, 5234, B, 80)

TCP IP
B (C, 5234, B, 80)

TCP IP
C

TCP Segment Format

0 4 10 Source port Sequence number Acknowledgment number Header length Reserved Checksum
U A P R S F R C S S Y I G K H T N N

16

24 Destination port

31

Window size Urgent pointer

Options

Padding

Data

Each TCP segment has header of 20 or more bytes + 0 or more bytes of data

TCP Header
Port Numbers A socket identifies a connection endpoint
IP address + port

A connection specified by a socket pair Well-known ports

FTP Telnet DNS HTTP 20 23 53 80

Sequence Number Byte count First byte in segment 32 bits long 0 SN 232-1 Initial sequence number selected during connection setup

TCP Header
Acknowledgement Number SN of next byte expected by receiver Acknowledges that all prior bytes in stream have been received correctly Valid if ACK flag is set

Header length 4 bits Length of header in multiples of 32-bit words Minimum header length is 20 bytes Maximum header length is 60 bytes

TCP Header
Reserved 6 bits
Control 6 bits URG: urgent pointer flag
Urgent message end = SN + urgent pointer

ACK: ACK packet flag PSH: override TCP buffering RST: reset connection
Upon receipt of RST, connection is terminated and application layer notified

SYN: establish connection FIN: close connection

TCP Header
Window Size 16 bits to advertise window size Used for flow control Sender will accept bytes with SN from ACK to ACK + window Maximum window size is 65535 bytes

TCP Checksum Internet checksum method TCP pseudoheader + TCP segment

TCP Checksum Calculation

0 8 16 Source IP address Destination IP address 00000000 Protocol = 6 TCP segment length 31

TCP pseudoheader

TCP error detection uses same procedure as UDP

TCP Header
Options Variable length NOP (No Operation) option is used to pad TCP header to multiple of 32 bits Time stamp option is used for round trip measurements Options Maximum Segment Size (MSS) option specifices largest segment a receiver wants to receive Window Scale option increases TCP window from 16 to 32 bits

Initial Sequence Number

Select initial sequence numbers (ISN) to protect against segments from prior connections (that may circulate in the network and arrive at a much later time) Select ISN to avoid overlap with sequence numbers of prior connections Use local clock to select ISN sequence number Time for clock to go through a full cycle should be greater than the maximum lifetime of a segment (MSL); Typically MSL=120 seconds High bandwidth connections pose a problem 2n > 2 * max packet life * R bytes/second

TCP Connection Establishment

Host A

Three-way Handshake ISNs protect against segments from prior connections

Host B

If host always uses the same ISN

Host A Host B

Delayed segment with Seq_no = n+2 will be accepted

Maximum Segment Size

Maximum Segment Size
largest block of data that TCP sends to other end

Each end can announce its MSS during connection establishment Default is 576 bytes including 20 bytes for IP header and 20 bytes for TCP header Ethernet implies MSS of 1460 bytes IEEE 802.3 implies 1452

Client-Server Application
Host A (client) Host B (server)

socket t1 connect (blocks) t2

socket bind listen accept (blocks)

connect returns t3

write read (blocks)

t5

t4 accept returns read (blocks) t6 read returns write read (blocks)

read returns

TCP Window Flow Control

Host A Host B t0

1024 bytes to transmit 1024 bytes to transmit

t1

t2

1024 bytes to transmit

t3

128 bytes to transmit

1024 bytes to transmit

t4

can only send 512 bytes

Nagle Algorithm
Situation: user types 1 character at a time

Transmitter sends TCP segment per character (41B) Receiver sends ACK (40B) Receiver echoes received character (41B) Transmitter ACKs echo (40 B) 162 bytes transmitted to transfer 1 character!
TCP sends data & waits for ACK New characters buffered Send new characters when ACK arrives Algorithm adjusts to RTT Short RTT send frequently at low efficiency Long RTT send less frequently at greater efficiency

Solution:

Silly Window Syndrome

Situation:
Transmitter sends large amount of data Receiver buffer depleted slowly, so buffer fills Every time a few bytes read from buffer, a new advertisement to transmitter is generated Sender immediately sends data & fills buffer Many small, inefficient segments are transmitted

Solution:
Receiver does not advertize window until window is at least of receiver buffer or maximum segment size Transmitter refrains from sending small segments

Sequence Number Wraparound

232 = 4.29x109 bytes = 34.3x109 bits
At 1 Gbps, sequence number wraparound in 34.3 seconds.

Timestamp option: Insert 32 bit timestamp in header of each segment

Timestamp + sequence no 64-bit seq. no Timestamp clock must:
tick forward at least once every 231 bits Not complete cycle in less than one MSL Example: clock tick every 1 ms @ 8 Tbps wraps around in 25 days

Delay-BW Product & Advertised Window Size

Suppose RTT=100 ms, R=2.4 Gbps
# bits in pipe = 3 Mbytes

If single TCP process occupies pipe, then required advertised window size is
RTT x Bit rate = 3 Mbytes Normal maximum window size is 65535 bytes

Solution: Window Scale Option

Window size up to 65535 x 214 = 1 Gbyte allowed Requested in SYN segment

TCP Connection Closing

Graceful Close
Host A Host B

Deliver 150 bytes

TIME_WAIT state

When TCP receives ACK to last FIN, TCP enters TIME_WAIT state
Protects future incarnations of connection from delayed segments TIME_WAIT = 2 x MSL Only valid segment that can arrive while in TIME_WAIT state is FIN retransmission
If such segment arrives, resent ACK & restart TIME_WAIT timer

When timer expires, close TCP connection & delete connection record

TCP StateTransition Diagram

CLOSED Applipassive open, cation create TCB close LISTEN
application close or timeout, SYN_SENT delete TCB

SYN_RCVD application close, send FIN

receive SYN, send ACK

ESTABLISHED

CLOSE_WAIT FIN_WAIT_1 CLOSING

LAST_ACK

FIN_WAIT_2

TIME_WAIT

2MSL timeout delete TCB

Typical TCP states visited by a client TCP

CLOSED
Wait 2 MSL Send SYN

TIME_WAIT
Receive FIN, Send ACK

SYN_SENT
Receive SYN & ACK, Send ACK

FIN_WAIT_2

ESTABLISHED
Send FIN

Receive ACK, Send nothing

FIN_WAIT_1

Typical TCP states visited by a serverside TCP

CLOSED
Receive ACK, Send nothing Server application creates a listen socket

LAST_ACK
Send FIN

LISTEN
Receive SYN Send SYN & ACK

CLOSE_WAIT

SYN_RCVD
Receive ACK, send nothing

Receive FIN, Send ACK

ESTABLISHED

TCP Congestion Control

Advertised window size is used to ensure that receivers buffer will not overflow However, buffers at intermediate routers between source and destination may overflow

Router
Packet flows from many sources R bps

Congestion occurs when total arrival rate from all packet flows exceeds R over a sustained period of time Buffers at multiplexer will fill and packets will be lost

Phases of Congestion Behavior

Throughput (bps) R

1. Light traffic
Arrival Rate Arrival Rate << R Low delay Can accommodate more Arrival rate approaches R Delay increases rapidly Throughput begins to saturate

2. Knee (congestion onset)

Delay (sec)

3. Congestion collapse
Arrival rate > R Large delays, packet loss Useful application throughput drops

Arrival Rate

Window Congestion Control

Desired operating point: just before knee
Sources must control their sending rates so that aggregate arrival rate is just before knee

TCP sender maintains a congestion window cwnd to control congestion at intermediate routers Effective window is minimum of congestion window and advertised window Problem: source does not know what its fair share of available bandwidth should be Solution: adapt dynamically to available BW
Sources probe the network by increasing cwnd When congestion detected, sources reduce rate Ideally, sources sending rate stabilizes near ideal point

Congestion Window
How does the TCP congestion algorithm change congestion window dynamically according to the most up-to-date state of the network? At light traffic: each segment is ACKed quickly
Increase cwnd aggresively

At knee: segment ACKs arrive, but more slowly

Slow down increase in cwnd

At congestion: segments encounter large delays (so retransmission timeouts occur); segments are dropped in router buffers (resulting in duplicate ACKs)
Reduce transmission rate, then probe again

TCP Congestion Control: Slow Start

Slow start: increase congestion window size by one segment upon receiving an ACK from receiver
initialized at 2 segments used at (re)start of data transfer congestion window increases exponentially cwnd
Seg

4
2 1
ACK

RTTs

TCP Congestion Control: Congestion Avoidance

Algorithm progressively sets a congestion threshold
When cwnd > threshold, slow down rate at which cwnd is increased
cwnd

threshold

Increase congestion window size by one segment per round-triptime (RTT)

Each time an ACK arrives, cwnd is increased by 1/cwnd In one RTT, cwnd segments are sent, so total increase in cwnd is cwnd x 1/cwnd = 1 cwnd grows linearly with time

4 2 1
RTTs

TCP Congestion Control: Congestion

20 Congestion avoidance Time-out Congestion window 15 Threshold

10 Slow start 5

0 Round-trip times

Congestion is detected upon timeout or receipt of duplicate ACKs Assume current cwnd corresponds to available bandwidth Adjust congestion threshold = x current cwnd Reset cwnd to 1 Go back to slow-start Over several cycles expect to converge to congestion threshold equal to about the available bandwidth

Fast Retransmit & Fast Recovery

Congestion causes many segments to be dropped If only a single segment is dropped, then subsequent segments trigger duplicate ACKs before timeout Can avoid large decrease in cwnd as follows:
When three duplicate ACKs arrive, retransmit lost segment immediately Reset congestion threshold to cwnd Reset cwnd to congestion threshold + 3 to account for the three segments that triggered duplicate ACKs Remain in congestion avoidance phase However if timeout expires, reset cwnd to 1 In absence of timeouts, cwnd will oscillate around optimal value

SN=1 SN=2 SN=3 SN=4 SN=5

ACK=2 ACK=2 ACK=2 ACK=2

TCP Congestion Control: Fast Retransmit & Fast Recovery

20 Congestion avoidance Time-out Congestion window 15 Threshold

10 Slow start 5

0 Round-trip times

TCP Retransmission Timeout

TCP retransmits a segment after timeout period
Timeout too short: excessive number of retransmissions Timeout too long: recovery too slow Timeout depends on RTT: time from when segment is sent to when ACK is received

Round trip time (RTT) in Internet is highly variable

Routes vary and can change in mid-connection Traffic fluctuates

TCP uses adaptive estimation of RTT

Measure RTT each time ACK received: tn tRTT(new) = a tRTT(old) + (1 a) tn a = 7/8 typical

RTT Variability
Estimate variance s2 of RTT variation Estimate for timeout: tout = tRTT + k sRTT If RTT highly variable, timeout increase accordingly If RTT nearly constant, timeout close to RTT estimate Approximate estimation of deviation dRTT(new) = b dRTT(old) + (1-b) | tn - tRTT | tout = tRTT + 4 dRTT