IPv4 and IPv6 Explained: Headers, Addressing and Security Differences

IP, the Internet Protocol, is the network layer protocol that gives every host an address and carries each packet hop by hop from source to destination, with no promise of delivery, order or secrecy. IPv4 is defined in RFC 791 (September 1981) and uses 32 bit addresses; IPv6 is defined in RFC 8200 (July 2017, Internet Standard STD 86) and uses 128 bit addresses, a fixed 40 byte header and a chain of optional extension headers.

Neither version encrypts or authenticates anything by default. The security differences come from what IPv6 changed around the header: self-configured addresses, fragmentation and options moved into extension headers, ICMPv6 as essential plumbing, and IPv6 quietly running on "IPv4 only" networks. This post covers both headers field by field, IPv6 addressing, the weakness classes the RFCs describe, and the commands that show what your own hosts and firewalls really do.

Key takeaways

• IPv4 (RFC 791, September 1981) has a 20 byte minimum header with options that can extend it to 60 bytes, and routers on the path may fragment packets. IPv6 (RFC 8200, July 2017, which obsoleted RFC 2460) has a fixed 40 byte header with no checksum, and only the source may fragment.
• IPv6 addresses are 128 bits. RFC 4291 defines scopes (link-local fe80::/10, multicast ff00::/8, loopback ::1) and hosts usually configure themselves with SLAAC (RFC 4862) from router advertisements, often with temporary addresses (RFC 8981, February 2021) for privacy.
• RFC 8200 says IPv6 shares IPv4's threats: eavesdropping, replay, insertion, deletion, modification, man in the middle and denial of service. IPsec and TLS address all but the last.
• Extension headers make filtering harder: a firewall must walk the whole chain to find the transport header. RFC 7112 (January 2014) requires the first fragment to carry the entire header chain, and RFC 9099 (August 2021) advises firewalls to drop first fragments that do not.
• ICMPv6 is not optional. RFC 4890 lists Destination Unreachable, Packet Too Big, Time Exceeded code 0 and Parameter Problem codes 1 and 2 as traffic that must not be dropped, and Neighbor Discovery runs over ICMPv6.
• Hosts have had IPv6 on by default for years (RFC 9099), so "IPv4 only" networks are still exposed through link-local addresses, rogue router advertisements and tunnels. IPv6 policy must match IPv4 policy.

What IP is for, where it sits, and the standards

IP solves one problem: getting a datagram from one host to another across many independent networks. It sits at the network layer (layer 3 in the OSI model, the internet layer in the TCP/IP model; our post on the TCP/IP and OSI models covers the layering). Below it sit link technologies such as Ethernet and Wi-Fi. Above it sit transports such as TCP, UDP and QUIC, plus control protocols such as ICMP.

RFC 791 states the scope plainly. IP provides for "transmitting blocks of data called datagrams from sources to destinations", identified by fixed length addresses, and for fragmenting and reassembling long datagrams when a network can only carry small packets. It has no end to end reliability, flow control or sequencing. Those are left to higher layers.

RFC 8200 lists the five areas where IPv6 changed IPv4: expanded addressing, a simplified header, better support for extensions and options, flow labelling, and authentication and privacy capabilities. The addressing change is the famous one. The header and extension changes are where most of the security behaviour actually differs.

How the IPv4 header works on the wire

The IPv4 header in RFC 791 is at least 20 bytes. The 4 bit Internet Header Length field counts 32 bit words, and RFC 791 says the minimum value for a correct header is 5, so options can grow it to 15 words, or 60 bytes.

RFC 791 also sets a floor: every destination must be able to receive a datagram of 576 octets, either whole or in fragments. Any router on the path may split a datagram that is too large for the next link, unless the DF bit is set, in which case the router drops it and reports the problem with an ICMP message. Reassembly happens only at the final destination.

An IPv4 datagram crossing a smaller link

Host A                   Router R1 (MTU 1500 to 576)          Host B
  |  datagram, 1400 bytes, DF=0  |                               |
  |----------------------------->|                               |
  |                              | fragment 1, MF=1, offset 0    |
  |                              |------------------------------>|
  |                              | fragment 2, MF=1, offset 69   |
  |                              |------------------------------>|
  |                              | fragment 3, MF=0, offset 138  |
  |                              |------------------------------>|
  |                              |        B reassembles by       |
  |                              |   source, dest, protocol, ID  |

Offsets are in 8 octet units and the numbers are illustrative. The point is the shape: in IPv4 the middle of the network may fragment, and only the receiver reassembles.

How the IPv6 header works on the wire

RFC 8200 defines a fixed 40 byte header. There is no length field for the header itself because it never varies, and there is no options area. Anything optional goes into a separate extension header that follows.

IPv4 versus IPv6, field by field

Losing the header checksum costs no security: a checksum only detects accidental corruption, and anyone who alters a packet on purpose can recompute it.

Extension headers and the Next Header chain

RFC 8200 section 4.1 recommends this order when more than one extension header is present:

Header                          Identified by Next Header value
------------------------------  -------------------------------
IPv6 header                     (fixed 40 bytes, always first)
Hop-by-Hop Options header       0
Destination Options header      60  (for the first destination and Routing header waypoints)
Routing header                  43
Fragment header                 44
Authentication Header (AH)      51
Encapsulating Security Payload  50
Destination Options header      60  (for the final destination only)
Upper-layer header              e.g. TCP 6, UDP 17, ICMPv6 58

Each header names the type of the one after it. A receiver, and any middlebox that wants to see the transport ports, must walk the chain one header at a time. RFC 8200 also says nodes must accept and attempt to process extension headers in any order and any number of times, except Hop-by-Hop, which may only appear immediately after the IPv6 header. RFC 9099 points out the operational consequence: in IPv4 it is "trivial" to find the upper layer header, while in IPv6 the whole chain must be parsed first.

Fragmentation only at the source

RFC 8200 says that unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers. A router facing a packet that is too large for the next link drops it and sends an ICMPv6 Packet Too Big message (type 2) back to the source. The source then lowers its packet size. That process is Path MTU Discovery, specified for IPv6 in RFC 8201 (July 2017).

Source                      Router (next link MTU 1280)          Destination
  | packet, 1500 bytes         |                                      |
  |--------------------------->|                                      |
  |  ICMPv6 Packet Too Big     |                                      |
  |  (type 2, MTU = 1280)      |                                      |
  |<---------------------------|                                      |
  | packet, 1280 bytes (or source-fragmented with a Fragment header)  |
  |------------------------------------------------------------------>|

IPv6 also raises the floor. RFC 8200 requires every link to carry at least 1280 octets, and recommends links be configured with an MTU of 1500 octets or more. A node must be able to reassemble packets of at least 1500 octets.

Two rules added after RFC 2460 matter for security. First, RFC 8200 says that if any fragment of a packet overlaps another, the whole packet must be silently discarded, an approach first standardised in RFC 5722 (December 2009). Second, all headers up to and including the first upper layer header must be in the first fragment, which is RFC 7112's requirement. Without it, the TCP or UDP ports might only appear in a later fragment, and a stateless filter looking at the first fragment cannot decide what the packet is.

How IPv6 addressing works

Notation and scopes

An IPv6 address is 128 bits written as eight groups of four hex digits, with leading zeros dropped and one run of zero groups shortened to ::. RFC 4291 defines the address types and how to recognise them from the prefix.

There is no broadcast address in IPv6. Functions that used broadcast in IPv4, such as ARP, use multicast instead. Site-local addresses (fec0::/10) and IPv4-compatible addresses were deprecated by RFC 4291. The IANA IPv6 Special-Purpose Address Registry, set up under RFC 6890 (April 2013), is the authoritative list of special blocks; its IPv4 counterpart lists 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 as Private-Use under RFC 1918 (February 1996), 100.64.0.0/10 as Shared Address Space, 169.254.0.0/16 as link local and 127.0.0.0/8 as loopback.

The interface identifier, and why it used to leak your MAC address

A unicast address is a network prefix plus an interface identifier (IID). For almost all unicast addresses RFC 4291 sets the IID at 64 bits, which is why a LAN subnet is a /64. RFC 4291 originally described building the IID from the network card's MAC address in Modified EUI-64 format. That made the low 64 bits of a laptop's address identical on every network it joined, which is a tracking identifier visible to every server it talks to.

The fixes came in stages:

• RFC 7217 (April 2014) specifies "semantically opaque" stable IIDs. The address is stable within a subnet but changes when the host moves to a different network, so it does not follow the device around.
• RFC 8064 (February 2017) changed the recommended default to RFC 7217 and "recommends against embedding stable link-layer addresses in IPv6 IIDs". It formally updates RFC 4291.
• RFC 8981 (February 2021) obsoletes RFC 4941 (September 2007) and specifies temporary addresses, covered below.

SLAAC, step by step

Stateless Address Autoconfiguration, RFC 4862 (September 2007), lets a host configure itself with no server. It runs over Neighbor Discovery messages carried in ICMPv6.

Host                                  Link (routers, other hosts)
 | 1. Build link-local fe80::IID                  |
 | 2. Neighbor Solicitation (DAD) for that addr   |
 |----------------------------------------------->|   no answer = unique
 | 3. Router Solicitation (ICMPv6 133)            |
 |----------------------------------------------->|
 | 4. Router Advertisement (ICMPv6 134):          |
 |    prefix 2001:db8:1::/64, lifetimes, flags    |
 |<-----------------------------------------------|
 | 5. Build global addr = prefix + IID            |
 | 6. DAD again, then use the address             |
 | 7. Default router = source of the RA           |

RFC 4861 defines five Neighbor Discovery message types: Router Solicitation (133), Router Advertisement (134), Neighbor Solicitation (135), Neighbor Advertisement (136) and Redirect (137). They are sent with a Hop Limit of 255 and receivers check it, which RFC 4861 says makes Neighbor Discovery immune to off-link senders. The flip side is that anything on the link can send them.

DHCPv6 is the stateful alternative. It was specified in RFC 8415 (November 2018), which was obsoleted in January 2026 by RFC 9915, now an Internet Standard. Routers tell hosts which method to use through flags in the Router Advertisement.

Temporary addresses (RFC 8981)

Temporary addresses use random IIDs that change over time, so outbound connections cannot easily be linked to one host. RFC 8981 sets the defaults: a preferred lifetime (TEMP_PREFERRED_LIFETIME) of one day and a valid lifetime (TEMP_VALID_LIFETIME) of two days, down from one week in RFC 4941. That reduces the typical number of concurrent temporary addresses per prefix from seven to three. RFC 8981 also removed RFC 4941's recommendation that temporary addresses be off by default, stopped using MD5 to generate them, and allows a host to use only temporary addresses.

The Linux kernel documentation shows the same numbers: temp_valid_lft defaults to 172800 seconds (2 days) and temp_prefered_lft to 86400 seconds (1 day). It also notes use_tempaddr defaults to 0, disabled, for most devices at the kernel level, so whether a Linux host uses temporary addresses depends on the distribution and network manager configuration rather than the kernel alone.

Temporary addresses help privacy but make logs harder to tie to a host, which is why RFC 9099 discusses logging router neighbour caches and DHCPv6 leases for accountability.

Versions and history

What is still deployed in practice: IPv4 everywhere, almost always with private addressing and NAT at the edge, and IPv6 alongside it on most modern operating systems, mobile networks and cloud platforms. Dual stack is the norm. Some transition mechanisms are fading: RFC 9099 says Teredo "is now hardly ever used" and client use of 6to4 by default is discouraged, but older hosts may still run them.

One common misremembering: early IPv6 specifications mandated IPsec, but RFC 6434 relaxed that to a SHOULD and RFC 8504 keeps it there, noting IPsec "is not viewed as the ideal security technology in all cases". Both IP versions can use IPsec, and most traffic on both relies on TLS instead.

Security properties and known weakness classes

What IP guarantees, and what it does not

RFC 8200's Security Considerations say IPv6 has security properties "similar to IPv4" and list the threats: eavesdropping, replay, packet insertion, packet deletion, packet modification, man in the middle and denial of service. IPsec (RFC 4301) or upper layer protocols like TLS and SSH address all but the last. On denial of service, RFC 8200 is direct: there is not any mechanism to protect against it in the specification.

The sections below describe the weakness classes as concepts. They explain what goes wrong and why the design allows it, not how to do it.

Source address spoofing

Neither header authenticates the source address. Any host can put any value there, and routers forward on the destination alone. That enables reflection and amplification attacks against third parties, and lets an attacker bypass filters that trust an address. The fix is not in IP itself; it is ingress filtering at network edges (BCP 38) so packets with impossible sources never leave the network that originated them. RFC 5095 recommends ingress filtering at the site border for the same reason. Our post on what an eavesdropper can see and change in TCP and UDP covers the transport side.

Fragmentation abuse

Fragmentation has caused trouble in both versions. The classes are:

• Overlapping fragments. If two fragments cover the same bytes with different content, the receiver and a security device in front of it might reassemble differently, so the device inspects one packet and the host receives another. RFC 8200 closes this for IPv6 by requiring the whole packet to be discarded.
• Header chain split across fragments. If the transport header is not in the first fragment, a stateless filter cannot see the ports and has to guess. RFC 7112 and RFC 9099 say to drop such first fragments.
• Reassembly resource exhaustion. Incomplete fragments hold memory; RFC 8200 abandons a reassembly not completed within 60 seconds of the first fragment arriving.

Extension header abuse

RFC 8200 acknowledges that the extension header design "creates new security challenges". The classes:

• Slow path processing. RFC 9099 explains that under RFC 2460 every router had to inspect Hop-by-Hop Options, which most routers cannot do in hardware. Packets with this header were handled in software and competed with routing and management tasks, which enabled denial of service. RFC 8200 made Hop-by-Hop processing at intermediate routers configurable, and RFC 9673 (October 2024) updates those procedures further.
• Routing header amplification. RFC 5095 (December 2007) deprecated the Type 0 Routing Header because a single packet could list the same intermediate addresses repeatedly and bounce between two remote routers, amplifying traffic along an entire path. RFC 5095 records an 88-fold amplification being demonstrated. It also warns firewall operators not to block every Routing header type, because other types, such as type 2 for Mobile IPv6, are legitimate.
• Parser confusion. RFC 9099 notes some implementations accept non-recommended orders or illegal repetition of headers, which has crashed nodes, and recommends enforcing order and counts at the edge.
• Filter evasion versus breakage. Long header chains can hide the transport header from simple filters, yet RFC 7872 (June 2016) measured widespread dropping of extension header packets, which breaks legitimate traffic. Header-aware policy beats blanket drops.

Rogue Router Advertisements and Neighbor Discovery trust

Hosts take their default router and prefixes from whatever Router Advertisement they hear. RFC 6104 (February 2011) describes "rogue RAs", whether from misconfiguration or malice, which can send a host's traffic to the wrong router. RFC 9099 points to RA Guard (RFC 6105), which filters Router Advertisements on switch ports, as the solution framework. Neighbor Discovery spoofing has the same root cause as ARP spoofing in IPv4: messages on the link are trusted. The ARP and NDP post in this series covers the defences.

Unmanaged IPv6 on "IPv4-only" networks

This is the class that catches teams out most often. RFC 9099 says that "for many years, all host operating systems have IPv6 enabled by default", so even on an IPv4-only network an attacker on the same link can reach neighbours through their IPv6 link-local addresses, or give them global addresses by sending rogue RAs or running a rogue DHCPv6 service. RFC 7123 (February 2014) is a whole document on this problem. IPv4 firewall rules, monitoring and access lists do not see that traffic.

Tunnels that carry IPv6 through IPv4 controls

Transition tunnels wrap IPv6 inside IPv4. Without IPsec or other encryption, RFC 9099 lists their shared problems: tunnel injection, traffic interception, service theft, reflection, and bypassing security policy, because a firewall on the path may not inspect the IPv6 traffic inside. RFC 9099 recommends blocking automatic tunnels that are not required by denying IPv4 packets with IP protocol 41, which covers ISATAP, 6to4, 6rd and 6in4. Teredo uses UDP instead, so RFC 9099 warns it can "punch a hole" through a stateful IPv4 firewall that allows unrestricted outbound UDP; RFC 7123 notes Teredo's service port is UDP 3544.

Address-based tracking and scanning

A 64 bit IID makes brute-force scanning of an IPv6 subnet far harder than sweeping an IPv4 /24, as RFC 8200 notes with a reference to RFC 7707 (March 2016). Hosts are not invisible, though: addresses leak through DNS, logs, predictable patterns and MAC-derived IIDs. RFC 8200 also warns that with less address translation, IPv6 endpoints are easier to distinguish.

ICMPv6 over-filtering

This is a weakness you create yourself. IPv6 depends on ICMPv6 for Path MTU Discovery and for Neighbor Discovery. If a firewall drops Packet Too Big messages, large packets silently vanish while small ones work, which is one of the most confusing failures to diagnose. RFC 4890 (May 2007) lists the ICMPv6 transit traffic that must not be dropped: Destination Unreachable (type 1, all codes), Packet Too Big (type 2), Time Exceeded (type 3, code 0) and Parameter Problem (type 4, codes 1 and 2). It adds that Echo Request and Echo Reply need not be filtered in IPv6, because scanning risk is much lower. Our ICMP guide to what to allow and block covers both ICMP versions in detail.

Secure configuration, with defender-side checks

Only run these commands against systems you own or are authorised to test. Each one comes from the official documentation linked in the Sources section.

Policy first: make IPv6 policy congruent with IPv4

RFC 9099 states the core rule: the IPv6 security policy "must be congruent with the IPv4 security policy; otherwise, the attacker will use the protocol version that has the more relaxed security policy". It recommends a dual stack firewall or ACL manager that can apply one rule to a mixed group of IPv4 and IPv6 addresses. NIST SP 800-119 (December 2010) was written to help organisations understand the security risks they take on during an initial IPv6 deployment, and is still a useful planning companion.

A practical configuration checklist drawn from RFC 9099, RFC 4890, RFC 5095, RFC 7112 and RFC 8981:

1. Inventory where IPv6 is enabled, including on networks that are supposed to be IPv4 only.
2. Write IPv6 firewall rules that mirror IPv4 intent, and check the default policy for IPv6 is not "accept".
3. Permit the ICMPv6 types RFC 4890 says must not be dropped, and allow Neighbor Discovery on the local link.
4. Drop first fragments that do not contain the full header chain, and enforce extension header order and counts at the edge.
5. Do not process Type 0 Routing Headers; do not block all routing header types.
6. Block IP protocol 41 and Teredo (UDP 3544) where those tunnels are not needed.
7. Enable RA Guard on access switches, and DHCPv6 snooping where you run DHCPv6.
8. Use RFC 7217 identifiers on servers and temporary addresses on clients, and log router neighbour caches and DHCPv6 leases so addresses map back to devices.
9. Apply ingress filtering at your edges so spoofed sources do not leave your network.

Linux: addresses, routes and kernel settings

The ip command from iproute2 shows both families. From the ip(8), ip-address(8) and ip-route(8) man pages:

# All IPv4 and IPv6 addresses on every interface
ip address show

# IPv6 only (-6 is the shortcut for -family inet6)
ip -6 address show

# Only temporary (privacy) IPv6 addresses
ip -6 address show temporary

# Link-local addresses only
ip -6 address show scope link

# Any IPv6-in-IPv4 tunnel interfaces of type sit
ip address show type sit

# IPv6 routing table, including any default route learned from an RA
ip -6 route show

# Which route and source address the kernel would use for a destination
ip -6 route get 2001:db8::1

The kernel's IPv6 behaviour is controlled through sysctls documented in the kernel's ip-sysctl page. Read them with sysctl:

# Is IPv6 disabled on a given interface? (0 = enabled, the default)
sysctl net.ipv6.conf.eth0.disable_ipv6

# Does this interface accept Router Advertisements?
sysctl net.ipv6.conf.eth0.accept_ra

# Temporary address preference: 0 off, 1 on but prefer public, 2 on and prefer temporary
sysctl net.ipv6.conf.eth0.use_tempaddr

# How link-local and SLAAC addresses are generated: 0 EUI-64 (default), 2 or 3 RFC 7217 stable privacy
sysctl net.ipv6.conf.eth0.addr_gen_mode

# Routing header handling: 0 accepts only type 2, a negative value rejects routing headers
sysctl net.ipv6.conf.all.accept_source_route

# IPv4 source routed packets (FALSE by default on hosts)
sysctl net.ipv4.conf.all.accept_source_route

The kernel documentation warns that reading conf/all/disable_ipv6 "does not have any particular meaning", so check per interface. The kernel default addr_gen_mode is 0 (EUI-64); modes 2 and 3 give RFC 7217 behaviour, often set by the network manager.

To see what the host firewall does for IPv6, list the full ruleset. With nftables, rules in the inet family apply to both IPv4 and IPv6, while ip and ip6 family tables apply to one each:

# Whole nftables ruleset, every family
nft list ruleset

# Legacy ip6tables rules, printed as commands
ip6tables -S

Look for an ip6 or inet table at all, an input policy that is not accept, permits for the RFC 4890 ICMPv6 types and Neighbor Discovery, and fragment and protocol 41 rules that match your intent. A careful ip table with nothing for IPv6 is the classic RFC 9099 gap.

Windows: addresses, routes, IPv6 settings, Teredo, firewall

From Microsoft Learn, in PowerShell:

# All IPv6 addresses
Get-NetIPAddress -AddressFamily IPv6

# All IPv6 routes
Get-NetRoute -AddressFamily IPv6

# Global IPv6 settings, including UseTemporaryAddresses and RandomizeIdentifiers
Get-NetIPv6Protocol | Format-List -Property *

# Teredo configuration from the active store
Get-NetTeredoConfiguration

# Windows Firewall profile settings
Get-NetFirewallProfile

Get-NetIPv6Protocol exposes settings such as UseTemporaryAddresses, RandomizeIdentifiers and the temporary address lifetimes, so you can compare a Windows host against your privacy and logging policy.

macOS

On macOS, the manual pages installed with the system document ifconfig and netstat. ifconfig -L shows address lifetimes for IPv6 addresses, and netstat -rn -f inet6 prints the IPv6 routing table with numeric addresses.

ifconfig -L
netstat -rn -f inet6

Checking from the network side

Host checks show what a machine believes. Also record which router your hosts learn their default IPv6 route from (the via address in ip -6 route show, or the NextHop in Get-NetRoute -AddressFamily IPv6) and alert if it changes to one you do not recognise, since that is the visible sign of a rogue Router Advertisement.

When to use IPv4 only, dual stack, or IPv6 only

On dual stack clients, RFC 8305 (December 2017), Happy Eyeballs version 2, races IPv6 and IPv4 connection attempts with a recommended 250 millisecond delay. That is why a client may use IPv6 even when IPv4 works, and why your IPv6 path needs the same controls.

Common mistakes

• Thinking you are "IPv4 only". If the hosts have IPv6 enabled, the link has IPv6, whether or not your router routes it. Check with ip -6 address show or Get-NetIPAddress -AddressFamily IPv6 before writing that phrase in a design document.
• Copying the IPv4 rules and forgetting the IPv6 table. Many host firewalls keep separate IPv4 and IPv6 rule sets. An empty or permissive IPv6 set next to a careful IPv4 set is the most common gap RFC 9099 describes.
• Blocking all ICMPv6. This breaks Path MTU Discovery and Neighbor Discovery. Follow RFC 4890 instead of reusing an IPv4 "drop ICMP" rule.
• Blocking every extension header, or every routing header. RFC 5095 explicitly says not to block all routing header types, and RFC 7872 shows blanket drops already cause breakage. Be specific.
• Treating NAT as a firewall. NAT hides IPv4 addresses as a side effect. IPv6 networks usually have no NAT, so every host with a global address needs an explicit stateful policy in front of it.
• Leaving automatic tunnels on. Protocol 41 and Teredo carry IPv6 past IPv4 controls. Disable what you do not need.

FAQ

What is the main difference between IPv4 and IPv6?

Address size and header design. IPv4 uses 32 bit addresses and a variable length header of 20 to 60 bytes. IPv6 uses 128 bit addresses, a fixed 40 byte header with no checksum, and extension headers for options and fragmentation. IPv6 also replaces ARP with Neighbor Discovery and lets hosts configure their own addresses with SLAAC.

Is IPv6 more secure than IPv4?

Not inherently. RFC 8200 says IPv6 has security properties similar to IPv4: neither authenticates the source or encrypts the payload. IPv6 changes where the risks are. It removes router fragmentation and the IPv4 options area, but adds extension headers, SLAAC and rogue Router Advertisements, and a much larger address space that makes blind scanning harder.

Is IPv6 encrypted?

No. IPv6 supports IPsec through the AH and ESP extension headers, and RFC 8504 says all IPv6 nodes SHOULD support it, but nothing is encrypted unless IPsec, TLS, SSH or another protocol is used. The IPv6 header itself is always visible to anyone on the path.

What is a link-local address in IPv6?

An address in fe80::/10 that every IPv6 interface creates for itself. It is only valid on the local link and routers never forward it. Neighbor Discovery and router communication use it, which is also why a host with IPv6 enabled is reachable by its neighbours even on a network with no IPv6 router.

Does IPv6 use NAT?

Usually not. IPv6 has enough addresses that every host can have a global one, so there is no address translation hiding internal hosts. NAT64 exists for translating between IPv6-only clients and IPv4-only servers. Without NAT, a stateful firewall policy is what protects internal IPv6 hosts.

Should I block ICMPv6?

Not wholesale. RFC 4890 lists ICMPv6 messages that must not be dropped, including Packet Too Big, which IPv6 needs because routers do not fragment. Neighbor Discovery also runs over ICMPv6 on the local link. Filter selectively by type and code instead.

Should I disable IPv6 if I do not use it?

Managing IPv6 is usually safer than relying on it being off everywhere, because disabling it consistently on every host is harder than it sounds. If you do disable it, verify per interface on every host type and block protocol 41 and Teredo at the edge.

What port does IPv6 use?

None. IP versions do not have ports; ports belong to transport protocols such as TCP and UDP, which carry the same port numbers over IPv4 and IPv6. The IPv6 Next Header field and the IPv4 Protocol field identify which transport follows, for example 6 for TCP and 17 for UDP.

Where Safeguard fits

Safeguard does not inspect, capture or filter IP traffic, and it does not configure firewalls, routers, switches or kernels. None of the hardening above depends on it. The honest connection is the software that parses these headers: kernels and network daemons, and, inside your own applications and container images, open source libraries for packet parsing, DHCP and address handling. Safeguard's software composition analysis, generally available, inventories those libraries including transitive dependencies, and its SBOM generation, also generally available, produces SPDX and CycloneDX records of what each image contains. Vulnerability management with EPSS and KEV enrichment, generally available, helps you see which of those components carry known issues, and container scanning covers the base images where networking packages often hide. For using SBOM data during an incident, see finding affected products fast with SBOMs.

Fix it without waiting for upstream

IP stack bugs usually live in an operating system kernel, which you patch through your distribution or vendor. But much of the code that parses addresses, handles DHCPv6 or processes packets in user space comes from open source libraries bundled into the services and images you build, and those are yours to fix.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, image and SBOM workflows, not network monitoring. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Pointed at the container image for a network-facing service, the same scan lists the packet handling, DHCP and address parsing libraries inside it with their versions and any known vulnerabilities, so you know what code is really reading IPv4 and IPv6 headers in your stack.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the dependency to bump is a networking library pinned in your manifest or base image.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects include a particular version of a networking library, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RFC 791: Internet Protocol, September 1981
• RFC 8200: Internet Protocol, Version 6 (IPv6) Specification, July 2017 (STD 86)
• RFC 2460: IPv6 Specification, December 1998 (obsoleted)
• RFC 9673: IPv6 Hop-by-Hop Options Processing Procedures, October 2024
• RFC 6864: Updated Specification of the IPv4 ID Field
• RFC 4291: IP Version 6 Addressing Architecture
• RFC 4193: Unique Local IPv6 Unicast Addresses
• RFC 3849: IPv6 Address Prefix Reserved for Documentation
• RFC 4443: ICMPv6 for IPv6
• RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls
• RFC 4861: Neighbor Discovery for IPv6
• RFC 4862: IPv6 Stateless Address Autoconfiguration
• RFC 4941: Privacy Extensions for SLAAC (obsoleted)
• RFC 8981: Temporary Address Extensions for SLAAC
• RFC 7217: Semantically Opaque Interface Identifiers for SLAAC
• RFC 8064: Recommendation on Stable IPv6 Interface Identifiers
• RFC 6104: Rogue IPv6 Router Advertisement Problem Statement
• RFC 6105: IPv6 Router Advertisement Guard
• RFC 5095: Deprecation of Type 0 Routing Headers in IPv6
• RFC 7045: Transmission and Processing of IPv6 Extension Headers
• RFC 7112: Implications of Oversized IPv6 Header Chains
• RFC 7872: Observations on the Dropping of Packets with IPv6 Extension Headers
• RFC 7123: Security Implications of IPv6 on IPv4 Networks
• RFC 8201: Path MTU Discovery for IP version 6
• RFC 8504: IPv6 Node Requirements
• RFC 9099: Operational Security Considerations for IPv6 Networks, August 2021
• RFC 8305: Happy Eyeballs Version 2
• RFC 6146: Stateful NAT64
• RFC 6052: IPv6 Addressing of IPv4/IPv6 Translators
• RFC 1918: Address Allocation for Private Internets
• RFC 6890: Special-Purpose IP Address Registries
• RFC 8415: DHCPv6 (obsoleted by RFC 9915)
• RFC Editor metadata for RFC 9915, DHCPv6, January 2026
• IANA Assigned Internet Protocol Numbers
• IANA IPv4 Special-Purpose Address Registry
• IANA IPv6 Special-Purpose Address Registry
• IANA IPv6 Global Unicast Address Assignments
• NIST SP 800-119: Guidelines for the Secure Deployment of IPv6, December 2010
• Linux ip(8) man page
• Linux ip-address(8) man page
• Linux ip-route(8) man page
• Linux kernel documentation: IP sysctl
• nftables nft(8) manual page
• ip6tables(8) man page
• Microsoft Learn: Get-NetIPAddress
• Microsoft Learn: Get-NetRoute
• Microsoft Learn: Get-NetIPv6Protocol
• Microsoft Learn: Get-NetTeredoConfiguration
• Microsoft Learn: Get-NetFirewallProfile

Last reviewed: 23 October 2026. Operating system defaults for IPv6 addressing and firewalls change between releases; check your platform's documentation before relying on a default.