IPv6 Source Guard

IPv6 Source Guard does one thing: it checks that a packet's source address matches the port it arrived on.
To see why you need it, look at an attack.

The Hacker Steals PC1's Identity

The Hacker builds an ordinary data packet: a simple ping toward the gateway R1.
Nothing special, except one detail.

In the IPv6 source field, it puts PC1's global IPv6 address instead of its own.

Figure 1 – The Hacker spoofs PC1's address in a plain data packet

The packet leaves, and when it reaches R1, it appears to have come from PC1.
The Hacker just impersonated another host.

Everything else in the packet is honest. It even carries the Hacker's own MAC address.
Only the source IPv6 address is a lie, and that is all it takes.

IPv6 Source Guard

You have already built three IPv6 First Hop Security features.
Each one watches a single kind of control message:

• RA Guard → Router Advertisements

• DHCPv6 Guard → DHCPv6 replies

• ND inspection → Neighbor Solicitations and Advertisements

Figure 2 – SW1 forwards it: ND inspection never checks data packets

A ping is none of these, It is plain data traffic, so it slips straight through.
SW1 forwards the spoofed ping, and R1 accepts it as PC1.

The switch knows PC1's real address sits on another port, but nothing checks a data packet against that knowledge.
That is exactly the gap IPv6 Source Guard closes. Let's see how.

Source Guard uses the binding table you already know from the last lesson.

Each entry records several fields: the IPv6 address, its MAC, the interface, the VLAN, and how it was learned. The part Source Guard cares about is the address tied to its interface, which tells the switch where each source is allowed to come from.

Binding Table

On a guarded port, every packet gets one check: its source address must be bound to that same port in the table.

Figure 3 – Source Guard reads the same binding table: each source must match its port

Look at the green entry: 2001:db8:10::10 lives on Gi0/1.
A packet with that source arriving on Gi0/1 is what the table expects, so it is forwarded untouched.

The Hacker Tries Again

Now Source Guard is active, and the Hacker sends the same spoofed ping from Gi0/2.
Its source still claims 2001:db8:10::10, but the binding table binds that address to Gi0/1.

Figure 4 – The source is bound to Gi0/1, the packet arrives on Gi0/2: dropped at the port

Wrong port!
The switch knows this source belongs on Gi0/1, so the packet is dropped before it enters the switch.

The Empty Table Trap

One trap to know before you configure anything.
Source Guard trusts the binding table completely, so what happens if the table is empty?