For my IPv6 training classes, I was missing a capture of a stateful DHCPv6 address assignment. That is: M-flag within the RA, followed by DHCPv6 messages handing out an IPv6 address among others. Therefore, I set up a DHCPv6 server on an Infoblox grid and furthermore used a Palo Alto NGFW as a DHCPv6 relay to it. I captured on two points: from the client’s point of view (getting to the relay) and from the server’s point of view (unicast messages from the relay). And since I was already there anyway, I additionally captured the same process for DHCPv4. So, here we go:
Basic Setup
A picture is worth a thousand words:
Yep, it’s getting a little complicated with all these addresses. ;)
Capture Details
First, you can download these captures here. I did not join those two capture files on purpose, since it’s much easier to open them side by side this way.
However, it’s in the Ultimate PCAP as well, of course. :)
- At the client’s broadcast domain: multicast via link-local (fe80::…) / All_DHCP_Relay_Agents_and_Servers (ff02::1:2) for IPv6 while broadcast for IPv4
- At the server’s segment: unicast with GUAs for IPv6 and unicast for IPv4
On the client side, I captured with my ProfiShark. (VLAN 69 tagged since I captured right at the firewall but before the ESXi.) On the server side, I used the built-in “Traffic Capture” feature of the Infoblox Grid. Hence a “Linux cooked capture” encapsulation rather than a classical Ethernet frame. Simply ignore it. More details concerning legacy IP DHCPv4 sequences can be found here.
Here are some Wireshark screenshots. On the left-hand side the client’s perspective and on the right-hand side the server’s perspective. Please note the packet comments that I added to all those messages (and displayed them as a column as well). Likewise, note the differences in the Info column. First, IPv6:
Second, legacy IP:
One major difference between DHCP and DHCPv6: While the default gateway is sent for legacy IP within the DHCP messages, it is NOT sent for IPv6 via DHCPv6, since the IPv6 host already knows its default gateway via the router advertisement.
Another difference: While DHCP for legacy IP always embeds the client’s MAC address, DHCPv6 does not. It uses the concept of a “DHCP Unique Identifier (DUID)” which can be made out of different options.
My Ubuntu 20.04.5 LTS (GNU/Linux 5.4.0-144-generic x86_64) VM did release the IPv4 address upon shutdown, but not the IPv6 address. That’s why you can only see this single v4 release, sent by the client *directly* to the DHCP server, not via the relay. Hence this captured message is exactly the same in both capture files.
Detailed Setup
DHCPv6 Server on the Infoblox
Using NIOS version 9.0.0. DHCPv4 is as always. Let’s have a look at DHCPv6.
At first some Grid DHCP Properties. Note that the “Domain Name” is not working as expected with regards to DHCPv4 (at least with my Ubuntu clients). It is used for DDNS within the Infoblox DDI. To have a DNS search list on your client, you have to use the custom option 24 “dhcp6.domain-search”. While the SNTP servers option is working, I was *not* able to get the NTP option running. This would be option 56, which is not yet implemented in NIOS. (Why?!? Some discussion here.) Finally, note that you do NOT have a “default router” option with DHCPv6 at all, since the default router always propagates itself using router advertisements on the local link!
I added one IPv6 DHCP Range within a /64 network:
Don’t forget to activate IPv6 on the appropriate members. (So did I… ;))
After some IPv6 addresses were handed out by the (stateful) DHCPv6 server, you can find them on the Active Leases page. Note the DUID for DHCPv6 rather than the mere MAC address for DHCPv4:
Relaying on the Palo
I’m using a PA-220 with PAN-OS 10.2.3 here in my lab. Quite simple: Network -> DHCP -> DHCP Relay -> adding the interface, activating the Internet Procols you want to use (in my case: both) and add the actual DHCP(v6) server addresses:
And don’t forget an appropriate policy allowing DHCP(v6) from this originating zone to the destination zone with the actual servers, such as:
Some, but not all (!) DHCP and DHCPv6 sessions are seen by the traffic log. The multicast (v6) respectively broadcast (v4) messages are not logged, but for v6 the unicast (relay) and link-local packets, while for v4 the unicast relay and the final release are:
Note 2: Some DHCP messages are sent from the DHCP server *directly* to the client (without the relay!). Refer to: DHCP Sequences: Broadcast vs. Unicast (written for IPv4-only, but anyhow). For these messages, you need another rule:
That’s it. Happy troubleshooting. :D
Further Reading
Photo by Arno Senoner on Unsplash.
Interesting reading, as always when you write about Infoblox, Palo Alto or IPv6 – and this time all three (das geht doch wirchlick nicht?) even.
I wonder how Infoblox chooses the IPv6 address to offer? For IPv4 is starts from the last available IP in the DCHP range, but apparently not so for IPv6 (2001:470:7250:69::fbc1).
Also a good point with the source port from a relay – I assume I’ve learned that too, but I didn’t remember it anymore.
Regards
/Uffe
( PCNSE, PCNSC, CDAT, IPv6 Sage)
Thanks for your comment, Uffe. I always appreciate feedback from readers.
Unfortunately, almost all just read through some posts, probably finding some answers, but leave without any notice. So it’s hard for me to realize which work was useful and which was not.
So again: Thanks. ;)
Dear Johannes ,
I’m writing you as a fellow German bloke and wanted to ask whether you could guide mit to an authoritative source which states, what the default Source IP Address of a DHCPv4 Discover / Request from a client via Relay Agent is.
I’m asking this because refering to my tests Cisco Routers in this regard behave differently to other Network manufacturers:
Behaviour with Cisco Router:
eth0:192.168.1.1 eth1:10.0.0.1 10.0.0.254
DHCP-Client ————- Cisco Router and IPv4 Relay Agent ————— DHCP-Server
sip 0.0.0.0 —> relayed with sip: 192.168.1.1
dip 255.255.255.255 dip:10.0.0.254
Behaviour with other Router systems:
eth0:192.168.1.1 eth1:10.0.0.1 10.0.0.254
DHCP-Client ————- Centos as Router / OpenWrt ———————— DHCP-Server
sip 0.0.0.0 —> relayed with sip: 10.0.0.1
dip 255.255.255.255 dip:10.0.0.254
Tested in a virtual environment (Hyper-V)
Screenshots of Wireshark traces could be supplied if needed.
Question is: Unicast from Relay to DHCP by default IP of DHCP-sided interface or client-sided interfaces?
I found amongst other the following sources stating that default should be DHCP-sided interface:
1. https://docs.commscope.com/bundle/fastiron-08030-l3guide/page/GUID-44165432-627D-48C8-87BF-8D304FEA253C.html
2. https://documentation.nokia.com/srlinux/23-3/books/interfaces/dhcp-relay.html
2. states that:
“…The DHCP relay agent relays the DHCP Discover message toward the DHCP server (unicast). If configured to do so, information is added for the circuit ID and remote ID sub-options in DHCP option 82. The relayed packet is unicast toward the DHCP servers with the following values:
SIP = outgoing interface IP address by default. If the source-address is configured, the relayed packet instead has SIP = configured source-address…”
Reference to the relevant RFC and i.e. for dhcrelay daemons option for “configured source-address” would be nice.
kind regards
Andreas, Munich
Hallo Andreas,
hm, das ist zunächst mal eine gute Frage. Ich musste mich erst mal etwas darauf konzentrieren, bis ich kapiert habe, worum es eigentlich genau geht. ;)
Fun fact zunächst mal: Ich hatte vor knapp 10 Jahren (!) schon mal einen Fall, wo die Source IP des DHCP-Relay Päckchens mir in die Suppe gespuckt hat, und zwar hier: https://weberblog.net/juniper-screenos-dhcp-relay-use-interface-as-source-ip-for-vpn/ Damals war es so, dass die Sourceadresse auf jeden Fall die des DHCP-Client-Netzes sein musste, damit die DHCP-Relay-Päckchen über ein Site-to-Site VPN sauber gerouted werden konnten.
Auch dachte ich, dass es eigentlich sinnvoller/logischer/nachvollziehbarer ist, wenn die DHCP-Relay-Pakete *immer* von dem Interface des DHCP-Client-Netzes aus geschickt werden. Wenn man eine Firewall mit 10 Netzen hat, welche alle per DHCP-Relay weitergehen, dann sieht man halt DHCP-Relay-Pakete von ebenso 10 verschiedenen Source-Interfaces kommen. Andererseits könnte man auch argumentieren, dass ja nur diese *eine* Firewall das DHCP-Relaying macht und es dann auch nur das *eine* Source-Interface in Richtung des DHCP-Servers sein sollte – und eben nicht gleich 10.
Am Ende des Tages ist es glaube ich vor allem wichtig, dass man es auf einem Router/Firewall in beide Arten konfigurieren kann. Und dann bitte in der gesamten Firma einheitlich umsetzen. ;) Bei der Palo zB ist es so, dass das Interface des DHCP-Client-Netzes das Päckchen schickt. Und ich weiß auch gerade gar nicht, ob sich das ändern lässt.
Was genau in den Standards (RFCs) bzgl. DHCP-Relay steht, weiß ich auch nicht. Das dürftest du gerne selber noch mal ergooglen und dann hier gerne auch das Ergebnis teilen.
Danke und lieben Gruß
Johannes