DHCPv6 and IAID+DUID or other means of selecting IPs by interface
-
yeah, if they ship said firmware with a set duid, you have DUID conflicts, which will happen.
Compared with that, the chance of getting 2 realtek nics with the same mac is very small but still happened to me.
However, if you are a ISP and more then 1 device uses the same DUID you'll be affected a lot sooner, because the DUID can travel across multiple networks. In the case of a a duplicate mac it's often limited to a broadcast domain and a very slim chance of conflict.
So if a run is made that all has the same DUID because it wasn't cleared during build and they ship a 100k units of those there are going to be a number of confused DHCP6 servers.
-
First, I'd like to qualify everything that follows as quite possibly dead wrong, and if so, I apologize in advance for wasting the time and space.
Are you sure IAIDs (and, hence, DHCPv6 reservations) are not implemented in ISC's distribution? I got to thinking about this and it didn't make sense to me. IAIDs have been in the spec since its inception (I'm almost positive). Why implement part of the spec and not implement another part. After all, there is hardly any algorithmic difference between searching a list based on one key (or a simple key) and searching it based on two keys (or a compound key). In other words, it would have to have been omitted arbitrarily rather than because it would have required thousands of man-hours of coding and testing.
I found a posting at http://www.ietf.org/mail-archive/web/dhcwg/current/msg10320.html which was written by one of the principal developers of ISC's distro and which suggests that IAIDs are implemented in the ISC client. Would it make sense to develop the client and not the server? Maybe he's talking about a development version, but the post is over 28 months old.
Lastly, I downloaded dhcpv6s.c (source code to version 4.2.3-P2). I haven't had a chance to go through it thoroughly (printed, it's 61 pages in a small font), but I can say there are numerous occurences of "iaid" and "fixed_addr" (and others which look relevant) in it. Maybe I'm jumping the gun; further scrutiny of the code will give me answer, but I thought I'd just ask the question first.
-
Are you sure IAIDs (and, hence, DHCPv6 reservations) are not implemented in ISC's distribution?
Unless it's in the source and nowhere in the docs, I'm certain it's not in the config for setting fixed addresses. It is used for full dynamic allocation to ensure a client gets the right IPs on two interfaces from the normal pool. It's just not there for setting fixed addresses.
I got to thinking about this and it didn't make sense to me.
It doesn't make sense to me, either, but welcome to the real world ;-)
IAIDs have been in the spec since its inception (I'm almost positive). Why implement part of the spec and not implement another part.
I found a posting at http://www.ietf.org/mail-archive/web/dhcwg/current/msg10320.html which was written by one of the principal developers of ISC's distro and which suggests that IAIDs are implemented in the ISC client. Would it make sense to develop the client and not the server? Maybe he's talking about a development version, but the post is over 28 months old.As mentioned above they are used, just not in the fixed address path.
Lastly, I downloaded dhcpv6s.c (source code to version 4.2.3-P2). I haven't had a chance to go through it thoroughly (printed, it's 61 pages in a small font), but I can say there are numerous occurences of "iaid" and "fixed_addr" (and others which look relevant) in it. Maybe I'm jumping the gun; further scrutiny of the code will give me answer, but I thought I'd just ask the question first.
Check the thread I linked earlier. There is quite a lengthy discussion about it being missing and it's only from January of this year. Unfortunately, ISC's bug tracker isn't public that I could find so even though we know their ticket ID (see the linked post) we have no way to check on its status/response.
-
Now I have try use DUID setup static ipv6 address can't normal work. I think DHCPv6 should has issue. and client get from dhcpv6 often happen offline for ipv6. only ipv4 dhcpv4 work.
So I think DHCPv6 not stable now.
-
This appeared in yesterday's posts on dhcp-users@lists.isc.org (bold mine). It doesn't say they're using IAIDs in fixed addresses yet, but this is half the battle, I think. They also added this functionality to ISC DHCP 4.1-ESV-R5rc1.
–----------------------------
Message: 5
Date: Mon, 30 Apr 2012 14:50:56 -0700
From: Shawn Routhier sar@isc.orgTo: df-announce@isc.org, Users of ISC DHCP dhcp-users@lists.isc.org,
dhcp-announce@isc.org, dhcp-workers@lists.isc.org
Subject: ISC DHCP 4.2.4rc1 is now available
Message-ID: def4b2b2-ca9a-4259-8e45-88375340c3a1@isc.orgContent-Type: text/plain; charset="us-ascii"ISC DHCP 4.2.4rc1 is now available for download.
This is the first release candidate of ISC DHCP 4.2.4, a maintenance release which
contains many bug fixes including some previously released security patches.This release of ISC DHCP 4.2.4rc1 includes source code from ISC BIND 9.8.2,
which has been recently found to contain a bug that can cause a segmentation
fault. (Please see the advisory at: https://kb.isc.org/article/AA-00664 )The BIND bug does not affect the portions of code used by DHCP, but can
affect recursive resolvers. As a result, the copy of BIND provided with
this distribution of DHCP source should not be used to build standalone
DNS programs but only to produce the server and utilities built by the
DHCP package. If you need to build BIND for recursive nameservice purposes,
please download a version from http://www.isc.org/software/bindISC is producing a new release to replace BIND 9.8.2 but it was not available
in time to meet the schedule for this release. We shall release another
release candidate (rc2) containing the corrected version of BIND when the
updated BIND tarball is available.A list of the changes in this release has been appended to the end
of this message. This release includes changes to the code to
allocate and manage IPv6 addresses, please pay particular attention
to this area in any testing you do. For a complete list of changes
from any previous release, please consult the RELNOTES file within
the source distribution, or on our website:http://www.isc.org/software/dhcp/424rc1
This release, and its OpenPGP-signatures are available now from:
ftp://ftp.isc.org/isc/dhcp/4.2.4rc1/dhcp-4.2.4rc1.tar.gz
ftp://ftp.isc.org/isc/dhcp/4.2.4rc1/dhcp-4.2.4rc1.tar.gz.sha512.asc
ftp://ftp.isc.org/isc/dhcp/4.2.4rc1/dhcp-4.2.4rc1.tar.gz.sha256.asc
ftp://ftp.isc.org/isc/dhcp/4.2.4rc1/dhcp-4.2.4rc1.tar.gz.sha1.ascISC's Release Signing Key can be obtained at:
http://www.isc.org/about/openpgp/
Changes since 4.2.4b1
- None
Changes since 4.2.3
! Add a check for a null pointer before calling the regexec function.
Without this check we could, under some circumstances, pass
a null pointer to the regexec function causing it to segfault.
Thanks to a report from BlueCat Networks.
[ISC-Bugs #26704].
CVE: CVE-2011-4539! Modify the DDNS handling code. In a previous patch we added logging
code to the DDNS handling. This code included a bug that caused it
to attempt to dereference a NULL pointer and eventually segfault.
While reviewing the code as we addressed this problem, we determined
that some of the updates to the lease structures would not work as
planned since the structures being updated were in the process of
being freed: these updates were removed. In addition we removed an
incorrect call to the DDNS removal function that could cause a failure
during the removal of DDNS information from the DNS server.
Thanks to Jasper Jongmans for reporting this issue.
[ISC-Bugs #27078]
CVE: CVE-2011-4868-
Fixed the code that checks if an address the server is planning
to hand out is in a reserved range. This would appear as
the server being out of addresses in pools with particular ranges.
[ISC-Bugs #26498] -
In the DDNS code handle error conditions more gracefully and add more
logging code. The major change is to handle unexpected cancel events
from the DNS client code.
[ISC-Bugs #26287]. -
Tidy up the receive calls and eliminate the need for found_pkt
[ISC-Bugs #25066] -
Add support for Infiniband over sockets to the server and
relay code. We've tested this on Solaris and hope to expand
support for Infiniband in the future. This patch also corrects
some issues we found in the socket code. [ISC-Bugs #24245] -
Add a compile time check for the presence of the noreturn attribute
and use it for log_fatal if it's available. This will help code
checking programs to eliminate false positives.
[ISC-Bugs #27539] -
Fixed many compilation problems ("set, but not used" warnings) for
gcc 4.6 that may affect Ubuntu 11.10 users. [ISC-Bugs #27588] -
Modify the code that determines if an outstanding DDNS request
should be cancelled. This patch results in cancelling the
outstanding request less often. It fixes the problem caused
by a client doing a release where the txt and ptr records
weren't removed from the DNS.
[ISC-BUGS #27858] -
Use offsetof() instead of sizeof() to get the sizes for dhcpv6_relay_packet
and dhcpv6_packet in several more places. Thanks to a report from
Bruno Verstuyft and Vincent Demaertelaere of Excentis.
[ISC-Bugs #27941] -
Remove outdated note in the bootp keyword about the option not satisfying
the requirement of failover peers for denying dynamic bootp clients.
[ISC-bugs #28574] -
Multiple items to clean up IPv6 address processing.
When processing an IA that we've seen check to see if the
addresses are usable (not in use by somebody else) before
handing it out.
When reading in leases from the file discard expired addresses.
When picking an address for a client include the IA ID in
addition to the client ID to generally pick different addresses
for different IAs. [ISC-Bugs #23138] [ISC-Bugs #27945] [ISC-Bugs #25586]
[ISC-Bugs #27684] -
Remove unnecessary checks in the lease query code and clean up
several compiler issues (some dereferences of NULL and treating
an int as a boolean).
[ISC-Bugs #26203] -
Fix the NA and PD allocation code to handle the case where a client
provides a preference and the server doesn't have any addresses or
prefixes available. Previoulsy the server ignored the request with
this patch it replies with a NoAddrsAvail or NoPrefixAvai respone.
By default the code performs according to the errata of August 2010
for RFC 3315 section 17.2.2, to enable the previous style see the
seciton on RFC3315_PRE_ERRATA_2010_08 in includes/site.h. This option
may be removed in the future.
Thanks to Jiri Popelka at Red Hat for the patch.
[ISC-Bugs #22676] -
Fix up some issues found by static analysis
A potential memory leak and NULL dereference in omapi.
The use of a boolean test instead of a bitwise test in dst.
[ISC-Bugs #28941]
–------------ next part --------------
An HTML attachment was scrubbed...
URL: <https: 20120430="" lists.isc.org="" pipermail="" dhcp-users="" attachments="" 5d8f2a21="" attachment.html="">------------------------------</https:>/def4b2b2-ca9a-4259-8e45-88375340c3a1@isc.org/dhcp-users@lists.isc.org/sar@isc.org
-
Sounds promising at least… Once the FreeBSD ports tree catches up we'll have to bump it in ours.
-
MAC is more reliable than DUID+IAID in a corporate environment. We have atleast 30 computers here that have the exact same DUID+IAID and because of this we can't use the Windowss 2008 DHCPv6 with reservations.
Something tells me that Windows generates these numbers at install and never updates them so when you image machines all clones have the same numbers.
All MAC's are unique however.
I guess there might be something that can be run on the cloned machines to give them different numbers down the road?
-
Some Googling turned up a few hits on how to generate a new DUID on Windows, like this:
https://ike.its.uiowa.edu/article/3573 -
A repeat of a DUID+IAID pair has got to be a cloning issue as you suggest. I have never had that happen, but I didn't image any of these machines. I'd like to say I can't believe nobody thought of that during the design phase, but then this wouldn't be the real world, would it? ::)
-
why not use the MAC address for ipv6 ?
-
@yon:
why not use the MAC address for ipv6 ?
Please read this entire thread. That has already been discussed in depth on the earlier posts in this thread.
