Why Win server 2022 did not respond when pinging IPv6 even DHCP is work?

Question

Hi,

I use the win server 2022 to create a DHCP server for my work needs.

Here are the steps below

1. Install DHCP function by "Add roles and features"
2. Setting static IP 4/6
3. Add the scope for IPv 4/6
4. Turn off all firewall

Now I have DHCP for IPv4/6

I connect my win server device directly to another device(call it B device) by lan port.

I can see the DHCP management is work, both of ipv4/6 had assigned valid IP addresses.

I try to ping my server device by ipv4 that is work but ipv6

when using the ipv6 to ping my server static IP I get no responds result.

plz help me figure out what happened.

Best Regards,

Sean

Answer 1

Hello Sean,

It sounds like you've set up your Windows Server 2022 as a DHCP server and are experiencing issues with IPv6 ping responses. Here are some steps to help diagnose and resolve this issue:

Troubleshooting Steps:

1. Check IPv6 Configuration:
   • Ensure that IPv6 is properly configured on your server. You can check this by running ipconfig on the server and verifying the IPv6 address is correctly assigned.
2. Check IPv6 Address Assignment:
   • On the client device (B device), run ipconfig and ensure it has been assigned an IPv6 address within the correct range from your DHCP server.

3. Verify IPv6 Scope Configuration:
   • Ensure the IPv6 scope in the DHCP server is configured correctly, including the address range, lease duration, and other settings.
4. Firewall Settings:
   • Although you mentioned that the firewall is turned off, double-check the firewall settings to ensure that there are no rules specifically blocking ICMPv6 (ping) traffic. Sometimes, specific rules for IPv6 can still be active.
   • You can check the firewall rules using the following command in PowerShell:
   powershell Get-NetFirewallRule | where {$_.DisplayName -like "*ICMPv6*"}
5. Enable ICMPv6 Echo Requests:
   • Make sure that ICMPv6 Echo Requests are allowed on your Windows Server 2022. You can enable this using the following PowerShell command:
   powershell New-NetFirewallRule -DisplayName "Allow ICMPv6-In" -Protocol ICMPv6 -IcmpType 128 -Action Allow

6. Check Network Interface Configuration:
   • Ensure that the network interface used for the LAN connection is correctly configured for IPv6 and that there are no issues with the network interface itself.
7. Neighbor Discovery:
   • Verify that neighbor discovery is working correctly. On the server, you can use the following command to check the neighbor cache: powershell netsh interface ipv6 show neighbors

8. Verify Connectivity:
   • On the client device (B device), try to ping the server's link-local IPv6 address (usually starts with fe80::). For example: powershell ping fe80::xxxx:xxxx:xxxx:xxxx%<interface_number>

Example Commands:

• To display the server's IP configuration: ipconfig /all
• To check the firewall rules: powershell Get-NetFirewallRule | where {$_.DisplayName -like "*ICMPv6*"}
• To add a firewall rule to allow ICMPv6: powershell New-NetFirewallRule -DisplayName "Allow ICMPv6-In" -Protocol ICMPv6 -IcmpType 128 -Action Allow

By following these steps, you should be able to diagnose and resolve the issue with your Windows Server 2022 not responding to IPv6 pings.

Best regards,

Rosy

Answer 2

Hi Rosy,

Thank you for your patiently help.

I followed your suggestion to check my DHCPv6 configuration tried and tested.

That still not work.

And I checked the tiano core/edk2 (UEFI firmware reference), the UEFL clearly expects the Option16 from DHCPv6 for the purpose of reaction of the HTTP & PXE Boot, and Option 59 for the Bootfile-Name(URL).

That means options 16、59 are necessary for my task.

I tried to add manually the pre-defined options with Option Code 16 and Option Code 59.

But the DHCPv6 server does not allow to define the options 16 and 59, because the options had been reserved.

It bothers me so much because I do really need those two options to set my DHCPv6.

Best Regards,

Sean

Answer 3

Hi Rosy,

thank you again for answering my question.

this root cause is my client had some wrong settings that blocked the ping out signal.

And I have further questions, maybe you can help.

Let me lay down detail.

Last time you help me finish the configuration of PXE IPv4/6.

the key setting is Option 59 to guide the client device to the boot image.

In this case, I am trying to implement the Http boot and also it needs to support IPv4/6.

In the BIOS part, we have two kinds of settings.

1. Type the specific URL to search the boot image.
2. Type nothing let the DHCP setting guide the client device to search boot image.

(kind of PXE)

So here is my situation now.

I change the DHCP ivp4 scope option 60、67
60 From "PXEClinet" to "HTTPClient"

67 From "192.168.1.1" to "HTTP://192.168.1.1/EFI/Bootx54.efi" It can help me boot to shell phase no matter whether fill in URL or not.

The DHCPv4 will help the client device to search the correct image.

Now the problem is HTTP IPv6.

The case fill in the URL for HTTP v6 works but the case without filling in URL is not.

I tried to add Option 59 for DHCPv6 to info the client device where is the boot image but seems it does not works.

My scope option for DHCP v6 below:

Option 60 Vendor Class ID "HTTPClient"

Option 66 Boot Server Host Name "2001:db8::1"

Option 59 Bootfile Name "HTTP://[2001:db8::1]/EFI/Bootx64.efi"

I expect that option 59 could guide the client device to get the boot image, but it's not.

Reference to the Ubuntu system.

before starting the DHCP service we can edit the dhcp.conf file.

we can setting like this option bootfile-name “HTTP://[2001:db8::1]/EFI/Bootx64.efi”;

to guide the client device.

Anything I can check and tune to fix this problem?

Appreciate!

Best Regards,

Sean

Answer 4

Hi Sean,

Thank you for your detailed message and for explaining the situation clearly.

It seems you are trying to implement an HTTP boot that supports both IPv4 and IPv6. While your configuration works for IPv4, you are facing issues with the IPv6 configuration, specifically when the URL is not filled in and the DHCP settings should guide the client device to the boot image.

Here are some suggestions and steps to troubleshoot and resolve the issue:

1. Verify DHCPv6 Configuration
   • Ensure that the DHCPv6 server is correctly configured to support the HTTPClient and provide the necessary boot parameters.
   • Double-check the syntax and values of the DHCPv6 options you have set.
2. Check Option 59 in DHCPv6:
   • Option 59 is not a standard DHCPv6 option for specifying the bootfile name. Instead, DHCPv6 uses different options for this purpose.
   • Try using DHCPv6 options such as Option 59 for Vendor-specific information and ensure it is correctly formatted.
3. Use Option 60 and Option 67 for IPv6
   • Similar to your IPv4 setup, use Option 60 (Vendor Class Identifier) and Option 67 (Bootfile Name) for IPv6 if supported by your DHCP server.
   • Ensure that the bootfile name URL is correctly formatted for IPv6, including square brackets around the IPv6 address.
4. DHCPv6 Configuration Example:
   • Edit the dhcpd6.conf file and ensure it includes the correct settings for the bootfile name and other relevant options.
   • Example configuration: option dhcp6.bootfile-url "HTTP://[2001:db8::1]/EFI/Bootx64.efi"; option dhcp6.vendor-class-identifier "HTTPClient";
5. Vendor-Specific Information (Option 17):
   • If Option 59 does not work as expected, consider using Option 17 for Vendor-specific Information.
   • Ensure that the client device supports this option and is correctly interpreting it.
6. BIOS/UEFI Firmware Update:
   • Check if there are any updates for the BIOS/UEFI firmware of the client devices. Sometimes firmware updates include fixes and improvements for network boot functionality.
7. Logs and Debugging:
   • Enable detailed logging on both the DHCP server and the client device to capture more information about the DHCPv6 process.
   • Check the logs for any errors or warnings that could provide insights into why the bootfile URL is not being applied correctly.

If after trying these suggestions the issue persists, please provide any error messages or logs that you encounter, and we can further investigate the problem.

Thank you for your patience and understanding. If you have any further questions or need additional assistance, please do not hesitate to reach out.

Best regards,

Rosy

Microsoft Networking Team