From fda8c0e71e709e176a78927ebdb33e9dfa7d92bd Mon Sep 17 00:00:00 2001 From: HackTricks News Bot Date: Thu, 12 Mar 2026 16:47:50 +0000 Subject: [PATCH] Add content from: Research Update Enhanced src/generic-methodologies-and-resou... --- .../pentesting-network/dhcpv6.md | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/src/generic-methodologies-and-resources/pentesting-network/dhcpv6.md b/src/generic-methodologies-and-resources/pentesting-network/dhcpv6.md index c5b4964eb07..688248eb82b 100644 --- a/src/generic-methodologies-and-resources/pentesting-network/dhcpv6.md +++ b/src/generic-methodologies-and-resources/pentesting-network/dhcpv6.md @@ -35,9 +35,49 @@ A comparative view of DHCPv6 and DHCPv4 message types is presented in the table 12. **Relay-Forw (12)**: Relay agents forward messages to servers. 13. **Relay-Repl (13)**: Servers reply to relay agents, who then deliver the message to the client. +## DHCPv6 On-the-Wire Basics + +- **UDP ports**: clients listen on `546`, servers/relays on `547`. +- **Well-known multicast**: `ff02::1:2` (All_DHCP_Relay_Agents_and_Servers) is used by clients to reach on-link relays/servers. +- **Relay flow**: clients send to multicast; relays encapsulate into `Relay-Forward` toward servers; responses come back as `Relay-Reply` and are decapsulated on-link. + +## Client/Server Identifiers (Targeting & Exhaustion) + +DHCPv6 uses **DUIDs** (client/server identifiers) plus **IAIDs** (per-interface identity). Common DUID types include: + +- **DUID-LLT** (link-layer + time) +- **DUID-EN** (enterprise number + identifier) +- **DUID-LL** (link-layer) +- **DUID-UUID** (UUID) + +**Pentest angles:** + +- **Targeted reservations**: if the network uses DUID-based reservations, spoofing a known DUID+IAID can trigger assignment of the reserved address/prefix. +- **Pool exhaustion**: rapidly generating many DUID/IAID pairs forces the server to allocate more leases or prefixes, degrading availability or revealing rate limits. + +## Relay-Agent Metadata Abuse (Remote-ID) + +Relay agents can add a **Remote-ID** option that provides extra subscriber/port identity to the server, and servers may use it when deciding which address or delegated prefix to assign. If a network doesn't strictly enforce that only trusted relays can add these options, an attacker can test policy bypasses by crafting Relay-Forward messages with a spoofed Remote-ID. + +**Practical checks:** + +- Capture DHCPv6 traffic and verify whether **Relay-Forward** messages appear on access ports (they should not): + +```bash +sudo tcpdump -i -n -vv ip6 and udp and \(port 546 or port 547\) +``` + +- If you can inject packets, try sending a Relay-Forward with a fake Remote-ID and compare the lease/prefix or options returned. + +{{#ref}} +pentesting-ipv6.md +{{#endref}} + ## References - [https://support.huawei.com/enterprise/en/doc/EDOC1100306163/d427e938/introduction-to-dhcpv6-messages](https://support.huawei.com/enterprise/en/doc/EDOC1100306163/d427e938/introduction-to-dhcpv6-messages) +- [https://www.rfc-editor.org/rfc/rfc8415.txt](https://www.rfc-editor.org/rfc/rfc8415.txt) +- [https://www.rfc-editor.org/rfc/rfc4649.txt](https://www.rfc-editor.org/rfc/rfc4649.txt) {{#include ../../banners/hacktricks-training.md}}