skip to content

Why can an IPv4-only firewall policy miss IPv6 traffic carried by 6in4, 6to4 or Teredo tunnels, and how would you bring it under control?

level: seniorimportance: should knowfreq 18%

answer

  1. the filter reads only the outer header
  2. protocol 41 or a UDP payload
  3. Teredo opens a hole in the NAT
  4. control the outer markers

basics

~20 s

Tunnels wrap IPv6 inside IPv4, so an IPv4 filter sees only protocol 41 or a UDP flow, never the inner IPv6 addresses and ports. Control means filtering those outer markers and giving IPv6 a policy of its own.

solid answer

~40 s

A filter written for IPv4 judges the outer header. A 6in4 or 6to4 packet is just IPv4 with Protocol 41; a Teredo packet is a UDP datagram, its server on port 3544. The IPv6 addresses, ports and protocol inside are invisible, so a host can reach — and be reached from — the IPv6 internet without any IPv4 rule matching. Teredo also gives the host a global IPv6 address through its NAT, and RFC 4380 says that host gives up whatever filtering the NAT provided. The tunnel looks like one hop to traceroute. To control it, drop protocol 41 at the border except for sanctioned tunnel endpoints, block outbound UDP to port 3544 so clients cannot qualify, turn off automatic tunnelling on hosts, and give native IPv6 a policy that matches IPv4's.

go deeper

for a junior

Recall that a tunnel hides an IPv6 packet inside IPv4, so a filter that reads only IPv4 headers cannot see the IPv6 addresses inside.

for a middle

Name each mechanism's outer marker — protocol 41 for 6in4 and 6to4, UDP with server port 3544 for Teredo — and what each lets through an IPv4-only policy.

for a senior

Explain Teredo's loss of the NAT's implicit filtering and decapsulator spoofing, then lay out the controls: protocol-41 filtering, blocking port 3544, host settings, native IPv6 policy.

for a principal

Weigh blocking transition tunnels against deploying native IPv6 with real policy, and decide how to verify that no unreviewed IPv6 path exists across the estate.

## What an IPv4 filter actually sees A packet filter or stateful firewall written for IPv4 matches on the **IPv4 header** and, for TCP and UDP, the transport ports right behind it. Tunnelling puts a whole IPv6 packet *after* those fields: | Mechanism | What the IPv4 filter sees | What it does not see | |---|---|---| | 6in4 configured tunnel (RFC 4213) | IPv4 packet, **Protocol 41**, between two endpoints | Inner IPv6 source, destination, ports, protocol | | 6to4 (RFC 3056) | IPv4 packet, **Protocol 41**, often to a relay | The same — plus that the peer may be any 6to4 site | | Teredo (RFC 4380) | **UDP** datagrams; the server listens on **port 3544** | Everything IPv6, inside an ordinary-looking UDP flow | If the IPv4 policy permits protocol 41, or permits outbound UDP generally, IPv6 traffic passes **without any IPv4 rule ever judging it**. A network "without IPv6" can therefore carry IPv6 whenever hosts enable a tunnel by themselves. ## Teredo and the NAT's implicit filtering Many networks rely on an IPv4 NAT's side effect: nothing reaches an inside host unless that host started the conversation. Teredo exists to make a NATed host reachable over IPv6. RFC 4380 §7.1 says it plainly: the machine using the service gives up whatever firewall service the NAT box provided, and services listening on its Teredo address become targets from the entire IPv6 internet. RFC 4380's own mitigations are host-side: restrict services to link-local scope, run a local firewall, use IPsec. ## Spoofing at decapsulators A decapsulator accepts packets whose inner IPv6 source is whatever the sender wrote. RFC 4213 §3.6 therefore requires a configured-tunnel endpoint to verify that the **outer IPv4 source** is the configured peer and to discard mismatches. Automatic mechanisms accept packets from many possible peers, so they cannot check against one configured address, which makes them easier to abuse for injected or spoofed traffic. For ISATAP, RFC 5214 tells site border routers to apply IPv4 ingress filtering and **protocol-41 filtering** so outsiders cannot inject packets onto the site's ISATAP link. ## Why the tunnel is hard to notice - RFC 4213 §3.3 models IPv6-over-IPv4 tunnels as **single-hop**: the tunnel is not detectable by traceroute, so path tests do not reveal it. - Inner addresses carry the giveaway prefixes — `2002::/16` for 6to4, `2001:0000::/32` for Teredo — but only to something that inspects inside the tunnel or watches IPv6 traffic. - RFC 6724 ranks 6to4 and Teredo below IPv4 for address selection, so such tunnels may sit idle until a destination is IPv6-only — which is precisely the traffic nobody reviewed. ## Bringing it under control 1. **Inventory what is allowed.** List where protocol 41 and outbound UDP are permitted at the border, and which hosts enable automatic tunnelling by default. 2. **Filter protocol 41** at the border, with exceptions only for sanctioned configured-tunnel endpoints. 3. **Block outbound UDP to port 3544.** A Teredo client qualifies by sending a Router Solicitation to its server's port 3544; without qualification it never obtains a Teredo address. 4. **Turn automatic tunnels off on hosts** — 6to4, Teredo and ISATAP — through the operating system's configuration rather than relying on the border alone. 5. **Give IPv6 a real policy.** Deploy native IPv6 with filtering equivalent to IPv4's, so that IPv6 traffic exists where it can be seen and judged. 6. **Watch for the markers.** Alert on protocol 41 to unknown endpoints, UDP to port 3544, and inner sources in `2002::/16` or `2001:0000::/32` anywhere IPv6 is visible. ## The limit of any of this Encapsulation is general: IPv6 can also ride inside other tunnels, VPNs or application-layer protocols that no IPv4 header reveals. Filtering the classic transition markers closes the accidental, default-on paths; it does not stop a host that deliberately builds its own tunnel over an allowed protocol.

  • Does dropping IP protocol 41 at the border also stop Teredo?
    No. Teredo carries IPv6 inside UDP precisely so it can cross NATs that would not pass protocol 41, so a protocol-41 rule never matches it. Stopping Teredo needs its own control: blocking outbound UDP to port 3544 so clients cannot qualify with a server, and disabling the client on hosts.
  • Why is it often better to deploy native IPv6 than to block every tunnel?
    Blocking only closes the paths you know about, while hosts keep preferring IPv6 wherever they find it. Native IPv6 with its own filtering puts IPv6 traffic where firewalls and logs can see the real addresses and ports, and it removes the reason hosts fall back to automatic tunnels in the first place.

saying these in an interview costs you the question

  • A network with no IPv6 deployed carries no IPv6 traffic.
  • Dropping IP protocol 41 at the border also stops Teredo.
  • An IPv4 rule set permitting only TCP and UDP stops every IPv6 tunnel.
  • The IPv4 NAT still shields a Teredo client from unsolicited IPv6 traffic.
  • Traceroute will show a tunnel's IPv4 hops, so it is easy to spot.