ipv6 host resolution in resolv.conf will break dhcpd3

Bug #190662 reported by Kain
4
Affects Status Importance Assigned to Milestone
dhcp3 (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

If you have inet6-type host resolution enabled via 'options inet6' in your resolv.conf, using hostnames that happen to have ipv6 address in /etc/hosts or dns resolution will cause the contents of those addresses to get dumped into multiple ipv4 address option records in the DHCP packets dhcpd3 sends out. DHCPDv3 does not need to perform correct resolver option setting or return record type verification in its resolver calls (gethostmyname &c.)

To reproduce:
/etc/resolv.conf
options inet6

/etc/hosts
10.0.0.1 dhcp-router

/etc/dhcp3/dhcpd.conf:
ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
authoritative;
subned 10.0.0.0 netmask 255.255.255.0 {
    range 10.0.0.100 10.0.0.200;
    option routers dhcp-router;
}

on a network configured as such, take a network capture of dhcp traffic and have a client get a DHCP lease on the network.
On a windows XP machine you will end up with 2 default routes listed, 0.0.255.255 and 10.0.0.1. This is consistent with a
ipv4-in-ipv6 address formatted response (i.e. ::ffff::10.0.0.1), and examination of the DHCP traffic will show that this is, in fact, what the DHCP server is reporting.

Anyone trying to set up a dual-stack ipv4+ipv6 network can run into this issue.

Version tested: 3.0.6.dfsg-1ubuntu3

Revision history for this message
Kain (kain-kain) wrote :

whoops, meant ::ffff:10.0.0.1, not ::ffff::10.0.0.1

Revision history for this message
Kenyon Ralph (kralph) wrote :

Does this bug still occur in newer versions of the package and Ubuntu?

Changed in dhcp3 (Ubuntu):
status: New → Incomplete
Revision history for this message
Chuck Short (zulcss) wrote :

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

Revision history for this message
Chuck Short (zulcss) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in dhcp3 (Ubuntu):
status: Incomplete → Won't Fix
Revision history for this message
Kain (kain-kain) wrote :

Hell. I explain exactly how to reproduce the bug and where you probably need to look in the code to find it. Pretty much any developer or bug fixer should be able to look at the code and find that or at least verify the bug via my directions and a packet tracer.

Closing bugs because you can't get people to do free re-testing and coding for you 2 years after a bug is reported is no way to triage any sort of bug. Did anyone responsible for packing this particular daemon even see this bug?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.