QUIC & IP address

This lecture introduces QUIC, a modern protocol designed to improve on the traditional TCP + TLS + HTTP stack.

The central question is:

Why was QUIC introduced, and how is it different from TCP?

QUIC was originally developed and deployed by Google around 2012. Later, it was standardized by the IETF. The final core specification, RFC 9000, was published in 2021 after many drafts.

Although QUIC originally stood for “Quick UDP Internet Connections”, the current specification treats QUIC as a name, not an acronym.

The lecturer emphasizes that QUIC does not fit perfectly into the traditional layered model. It uses UDP below, integrates TLS security, provides transport-like reliability and congestion control, and also includes stream multiplexing features that previously belonged more to HTTP/2. Therefore, whether QUIC is “just a transport protocol” is partly a philosophical question.

QUIC tries to keep useful TCP-like features while avoiding several deployment and performance problems.

The main goals are:

• reduce connection establishment latency;
• integrate security by default;
• avoid TCP head-of-line blocking when multiple logical streams are used;
• be deployable without changing routers, middleboxes, or operating system kernels;
• allow future extensions such as multipath and forward error correction;
• support IP mobility through connection IDs.

A simplified view:

Traditional web stack:

HTTP/1.1 or HTTP/2
TLS
TCP
IP

QUIC-based web stack:

HTTP/3
QUIC
UDP
IP

QUIC uses UDP, but it is not “just UDP”. UDP is mainly used as a compatibility layer so that existing networks will carry QUIC traffic.

A natural question is:

Why not define a completely new layer-4 protocol directly on top of IP?

The answer is deployment.

The Internet contains many middleboxes:

• firewalls;
• NATs;
• traffic optimizers;
• load balancers;
• enterprise boxes;
• vendor-specific devices with strange assumptions.

Many middleboxes only understand TCP and UDP. Unknown transport protocols may be blocked or mishandled.

Using UDP makes QUIC deployable on the existing Internet. The UDP header provides ports and a familiar protocol number, so firewalls and NATs are more likely to allow the traffic.

QUIC then encrypts most protocol information above UDP. This reduces the ability of middleboxes to inspect, modify, or ossify the protocol.

TCP connections are usually identified by the 5-tuple:

source IP
source port
destination IP
destination port
transport protocol

This creates a problem when a client’s IP address or port changes.

Examples:

• a phone moves from Wi-Fi to mobile data;
• a mobile device changes cell towers or networks;
• a NAT mapping expires and the external port changes;
• a DSL connection is re-established.

With TCP, such a change usually breaks the connection.

QUIC introduces connection IDs. A connection ID identifies the QUIC connection independently of the lower-layer IP address and UDP port.

Thus, if a valid packet arrives with the same connection ID and proper cryptographic authentication, the endpoint can treat it as belonging to the same QUIC connection even if the IP address or port changed.

This enables IP mobility.

QUIC is designed to be more flexible and extensible than TCP.

In TCP, ACK information is part of the TCP header and acknowledges bytes, typically using cumulative ACKs.

In QUIC, acknowledgements are ACK frames. They acknowledge packet numbers, not byte offsets.

An endpoint acknowledges a packet after it has:

1. received the packet;
2. decrypted it;
3. checked integrity;
4. processed the frames.

QUIC still needs congestion control.

The goal is the same as in TCP:

• use a fair share of the network;
• avoid overloading the network;
• react to loss and congestion signals.

Congestion control is usually done at the connection level, not separately for each stream. From the network’s perspective, packets consume capacity regardless of which stream they belong to.

Many QUIC implementations reimplement existing TCP congestion-control algorithms, commonly CUBIC or Reno-like algorithms. Some also experiment with BBR.

The lecturer emphasizes that implementing congestion control correctly is difficult. QUIC’s flexibility does not automatically make congestion control easier. Different QUIC libraries may implement the same conceptual algorithm in subtly different and imperfect ways.

QUIC may enable future improvements because ACK frames and extensions can carry richer information, for example ranges and timing information.

Flow control prevents the receiver from being overwhelmed.

TCP has a receiver window. The receiver tells the sender how many bytes it is willing to receive. As ACKs advance, the window slides.

QUIC has a more fine-grained model:

• connection-level flow control;
• per-stream flow control.

Important QUIC limits:

• max_data: maximum data allowed on the whole connection;
• max_stream_data: maximum data allowed on a particular stream.

Unlike TCP’s sliding receive window, QUIC uses limits that must be increased explicitly. The receiver must regularly send frames increasing these limits if it wants to allow more data.

This gives more control but also more complexity.

The original core QUIC model is reliable and stream-based.

But some applications also want unreliable delivery. Therefore, QUIC has an unreliable datagram extension.

QUIC datagrams are:

• unreliable;
• not retransmitted;
• not ordered;
• still protected by QUIC security;
• still part of congestion control;
• not subject to normal stream flow control.

This may sound strange because QUIC already runs over UDP, and now it reintroduces UDP-like unreliable datagrams inside QUIC. But it makes sense because datagrams can share:

• one QUIC handshake;
• one security context;
• one congestion-control loop;
• the same connection infrastructure.

Use cases include:

• video or real-time media;
• proxies;
• tunnels;
• MASQUE-style protocols;
• cases where reliable control data and unreliable media data should share one connection.

TCP is typically implemented in the kernel.

Changing TCP behavior requires:

• kernel changes;
• OS updates;
• careful compatibility testing;
• slow deployment.

QUIC is implemented in user space on top of UDP.

This means application vendors can deploy new protocol versions by updating their applications rather than waiting for kernel updates.

This enabled Google, for example, to experiment with multiple versions of QUIC quickly.

The downside is performance overhead:

• user-space networking is often less optimized than kernel TCP;
• more system calls may be needed;
• UDP offload support is less mature than TCP offload support;
• encryption happens per QUIC packet;
• each packet has to be individually protected and processed.

For large bulk transfers, highly optimized TCP/TLS stacks may still outperform QUIC.

Main use cases:

• HTTP/3;
• MASQUE proxying and tunneling;
• iCloud Private Relay-like systems;
• DNS over QUIC;
• experimental SSH over QUIC or other protocols.

HTTP/3 is not simply “HTTP/2 but newer”. It is HTTP over QUIC. HTTP/2 runs over TCP/TLS, while HTTP/3 uses QUIC streams directly.

There are many QUIC implementations, for example:

• quiche by Cloudflare;
• mvfst by Meta/Facebook;
• quic-go in Go;
• LSQUIC by LiteSpeed;
• Google implementations;
• libraries in Rust, C, C++, Go, Python, and other languages.

The lecture also mentions qlog/qvis: since QUIC encrypts most packet internals, passive packet captures reveal much less than with TCP. qlog is an endpoint-side logging format, and qvis is a visualization tool for inspecting QUIC and HTTP/3 behavior.

QUIC combines several ideas:

• TCP-like reliability;
• TCP-like congestion control;
• flow control;
• TLS 1.3 security;
• multiple logical streams;
• UDP-based deployability;
• user-space implementation;
• connection IDs for mobility.

Its main benefits are:

• lower handshake latency;
• integrated security;
• less head-of-line blocking for multiplexed applications;
• easier deployment and experimentation;
• better support for mobile clients.

Its main costs are:

• higher implementation complexity;
• higher CPU and packet-processing overhead;
• less mature optimization compared with TCP;
• many different implementations with different behavior.

Lecture 12 moves downward in the protocol stack.

Previous lectures focused on application and transport layers. This lecture introduces:

• the network layer;
• IP addressing;
• IPv4 and IPv6;
• IP datagram structure;
• subnetting and CIDR;
• forwarding and longest prefix matching;
• the link layer;
• MAC addresses;
• ARP and IPv6 neighbor discovery;
• how IP and MAC addresses interact when sending across subnets.

An IP address identifies an interface, not a whole host or router.

This is important.

A router normally has multiple interfaces, and each interface has its own IP address. A host may also have multiple interfaces, for example Ethernet and Wi-Fi.

IPv4 addresses are 32 bits.

IPv6 addresses are 128 bits.

IPv4 addresses are written as four 8-bit decimal octets.

Example:

203.0.113.1

In binary:

203        0         113       1
11001011   00000000  01110001  00000001

IPv4 was designed in the 1970s. A 32-bit address space gives about \(2^{32}\), roughly 4 billion, possible addresses. Not all are usable globally, and the Internet has long outgrown this space.

IPv6 addresses are 128 bits.

They are written as eight 16-bit groups in hexadecimal, separated by colons.

Example long form:

2001:0DB8:0000:0001:0000:0000:0000:0001

IPv6 notation can be shortened:

1. Leading zeros in each 16-bit group can be omitted.
2. One consecutive run of all-zero groups can be replaced by ::.

Example:

2001:0DB8:0000:0001:0000:0000:0000:0001
=> 2001:DB8:0:1::1

The :: abbreviation can only be used once in an address, otherwise the address would be ambiguous.

IPv6 has been discussed since the 1990s and standardized early, but deployment has been slow. IPv4 and IPv6 are not directly compatible, so IPv4 will remain in use for a long time.

A major difference in practice:

• IPv4 interfaces often have one address.
• IPv6 interfaces commonly have multiple addresses, including link-local addresses.

IPv6 link-local addresses often start with fe80::. They are only valid on the local link and are not globally routed.

From the IP-address perspective, a network/subnet is a group of interfaces that:

• can physically reach each other without an intervening router;
• share the same high-order address bits.

A practical way to find networks in a topology is:

Remove the routers. The remaining connected “islands” are separate networks.

Important: links between routers are also networks. A point-to-point link between two routers still forms an IP network.

The Internet network layer contains:

• IP;
• ICMP;
• routing/forwarding mechanisms.

IP defines:

• datagram format;
• addressing;
• packet-handling conventions.

ICMP is used for error reporting and signaling.

Examples:

• ping uses ICMP echo request and echo reply;
• traceroute relies on TTL/hop-limit expiration and ICMP time exceeded messages;
• routers may report destination unreachable or packet-too-big errors.

For IPv6, the corresponding protocol is ICMPv6, which is also used for neighbor discovery.

Important IPv4 header fields:

• version;
• header length;
• type of service / DSCP / ECN bits;
• total datagram length;
• 16-bit identifier;
• flags;
• fragment offset;
• time to live;
• upper-layer protocol;
• header checksum;
• source IP address;
• destination IP address;
• options, if any.

Subnetting divides an address into:

• network part / prefix;
• host part.

CIDR notation:

IPv4: a.b.c.d/m
Example: 192.0.2.0/24

IPv6: x:y:z::/m
Example: 2001:DB8:0:3::/64

The number after / is the prefix length, i.e. the number of network bits.

Example:

192.0.2.0/24

means:

• first 24 bits are the network prefix;
• remaining 8 bits are host bits.

So there are \(2^8 = 256\) addresses in the block.

For normal IPv4 LANs, the first address is the network address and the last is the broadcast address, leaving 254 usable host addresses.

Example:

192.0.2.0/24

network address:   192.0.2.0
usable addresses:  192.0.2.1 - 192.0.2.254
broadcast address: 192.0.2.255

Originally, IPv4 used classful addressing.

Main classes:

Problem:

• class A was too large for most organizations;
• class C was too small for many organizations;
• many organizations wanted class B networks;
• this wasted address space and accelerated IPv4 exhaustion.

CIDR replaced classful routing.

CIDR allows arbitrary prefix lengths, such as:

/23
/24
/27
/30
/31

This allows address blocks to be allocated much more flexibly.

Example:

A /23 contains \(2^9 = 512\) addresses, roughly two /24 networks.

A /30 contains 4 addresses, usually 2 usable host addresses, useful for point-to-point links.

A /31 can also be used for point-to-point links because there is no need for separate network and broadcast addresses in that special case.

Multicast addresses identify a group of receivers.

They are useful for:

• streaming;
• conferencing;
• signaling;
• IPv6 local network mechanisms.

IPv4 multicast uses a reserved range beginning at 224.0.0.0.

IPv6 multicast uses FF00::/8.

IPv6 relies more heavily on multicast for local signaling, such as neighbor discovery.

There are two different questions:

1. How does a host get an address inside its network?
2. How does a network get an address block?

Routers use forwarding tables.

A forwarding table entry has the form:

network/prefix-length -> next hop or output interface

When a packet arrives, the router examines the destination IP address and chooses the entry with the longest matching prefix.

Why longest?

Because a longer prefix is more specific.

Example:

134.96.0.0/16        -> C
134.96.240.0/20      -> B
134.96.252.0/24      -> A
134.96.252.192/28    -> B
134.96.252.196/30    -> A

For a destination such as:

134.96.252.200

several prefixes may match, but the router chooses the longest matching one.

Conceptually:

1. Convert address and prefixes to binary.
2. Compare only the prefix bits.
3. Among all matches, choose the one with the largest prefix length.

This is the core of CIDR forwarding.

An IP address is a network-layer address.

A MAC address is a link-layer address.

MAC addresses are used locally to move a frame from one interface to another physically connected interface on the same subnet.

Typical MAC addresses are 48 bits, written in hexadecimal.

Example:

1A-2F-BB-76-09-AD

or:

1A:2F:BB:76:09:AD

Each hexadecimal digit represents 4 bits.

MAC addresses are usually burned into the network interface card, although they can often be changed in software.

Problem:

A host knows the destination IP address on the same LAN, but to send an Ethernet frame, it needs the destination MAC address.

ARP solves this for IPv4.

Each IP node on a LAN has an ARP table containing mappings like:

IP address -> MAC address -> TTL

The TTL means the entry is soft state. It expires unless refreshed.

IPv6 does not use ARP.

Instead, IPv6 uses Neighbor Discovery, based on ICMPv6.

Each node has a neighbor table, conceptually similar to an ARP table:

IPv6 address -> interface identifier -> TTL

The interface identifier generalizes the idea of a MAC address, so it can work with different link technologies.

A key point:

IP source and destination usually stay end-to-end, but MAC source and destination change at every link.

Example:

A wants to send an IP datagram to B, but B is on another subnet. The packet must go through router R.

Assumptions:

• A knows B’s IP address.
• A knows the IP address of its first-hop router R, usually from DHCP or configuration.
• A knows R’s MAC address, usually via ARP or neighbor discovery.

Network layer:

• IP addresses identify interfaces, not whole hosts.
• IPv4 uses 32-bit addresses; IPv6 uses 128-bit addresses.
• IPv6 addresses can be shortened, but :: can only appear once.
• A network/subnet is a group of interfaces sharing high-order address bits and reachable without an intervening router.
• IP provides datagram format, addressing, and packet-handling conventions.
• ICMP provides error reporting and signaling.
• IPv4 fragmentation exists but is problematic; IPv6 routers do not fragment.
• CIDR replaces classful addressing and allows flexible prefix lengths.
• Forwarding uses longest prefix matching.

Link layer:

• The link layer transfers frames between physically adjacent nodes.
• MAC addresses are flat, local link-layer identifiers.
• ARP maps IPv4 addresses to MAC addresses on the same LAN.
• IPv6 uses ICMPv6 Neighbor Discovery instead of ARP.
• When sending across subnets, the IP destination remains the final host, but the MAC destination is only the next hop.