DHCPv6 and IAID+DUID or other means of selecting IPs by interface
-
Well, I'm not sure this is going into the right thread after the split but here goes.
DUID is indeed useless by itself. The computer generates the DUID from the first NIC's MAC and the time. If I remember correctly, for devices with fixed storage, the spec requires this method. Don't quote me; I'll have to look it up to be sure. From the moment of generation, the DUID is bound to the host. You'll have to edit the registry for Windows, edit the /var/db/dhcp6c_duid file for FreeBSD (it's encrypted and I'm not positive that's the only place it's stored), or reinstall the OS to change it. Even if you remove the NIC that was used to generate the DUID from the machine, the DUID does not change.
In Windows, each IAID is partially generated from each NIC's MAC. The first 24 bits of the MAC become the last 24 bits of the IAID (not very ingenious since that's the manufacturer's portion of the MAC). I have been unable to determine how the first 8 bits of the IAID are generated (although I'm about 99.9% positive I read it somewhere on the web).
I should have mentioned in the previous post that all of the machines on all of the subnets in my network are assigned reserved addresses by DHCPv6 (after all, getting a random address is easy). They're all multihomed machines, including the DHCPv6 server which is distributing addresses on four subnets (essentially LAN, DMZ, wireless, and management), all based on DUID+IAID.
I did give client syntax in the earlier post (http://forum.pfsense.org/index.php/topic,43951.msg227931.html#msg227931). At the time, as I remember, I couldn't find much in the way of examples for the client configuration, but there were several for the server end of things.
I confess that, having read the two threads, I'm not completely sure what the real question is, so I've got a few of my own. The only need for the IAID in a configuration file (client or server) is for DHCPv6 reservations (addresses that persist) (right?). Is this functionality in the pfSense DHCPv6 Server now? I didn't think it was. Are you going to add it if it isn't already there?
I see several mentions of the ISC distribution. What's in there now? I was under the impression you were using the WIDE distribution but were considering switching to ISC. Is this correct or has something changed? The syntax I got working was for the WIDE version, but I did experiment with ISC because Seth said that the WIDE distro used only one TCP/IP socket (problematic with multihomed computers).
-
I think if we install two or more NIC in computer,then How setup static and assign ip address to each NIC or any client Terminal. maybe It is a virtual terminal or equipment.
I think we should consider the different applications and requirements. Our main purpose is in any environment, a variety of distribution does not produce conflict or duplication.
just like Authentication of a person's DNA, it is the only.
by the way, How to manage and assign an address in accordance with management purposes？For example, I which addresses is reserved not assigned.
Which addresses can be prohibited and freedom of management.
Which addresses can be assigned by group or press equipment.such as:
2001:470:f188:15::18–25 only for A NIC or A group
2001:470:f188:15::50--100 disable for some NIC or groups. or only for admin's some NIC. -
Maybe I'm being obtuse, but I feel like I'm having to read between the lines to discern the actual nature of the problem. Each host has one DUID which is generated from the MAC of one of its interfaces (NICs) and the date/time. Once it is generated, it persists indefinitely even if the NIC used to generate it is removed from the machine. Each interface has one or more IAIDs which when used in conjunction with the DUID identifies a specific interface on a specific host. Notice I did not say "uniquely identifies." This is because one interface can have multiple IPv6 addresses (say link-local, unique-local, unique-global, temporary, etc.) and if the client (read host: one DUID) hopes to obtain these multiple addresses from the DHCPv6 server, it must present multiple IAIDs in its request(s) for addresses. Each DUID+IAID pair will result in a separate IPv6 address being served.
Now, this is how the RFCs read. I personally have only assigned one unique-local IPv6 address to each interface with DHCPv6 but I do have multiple interfaces in each machine. I used DHCPv6 reservations to make sure each interface in each machine gets the same IPv6 address every time it requests/renews. I use NPt in pfSense to translate between unique-local addresses and unique-global addresses for internet traffic. This works for most (but not all) protocols.
Making DHCPv6 reservations in Server 2008 is easy and isn't worth going into here. I haven't set up a FreeBSD-based DHCPv6 server yet, but I have worked extensively with the client side. Yesterday, I started setting up a FreeBSD DHCPv6 server to satisfy my own curiosity and hopefully to answer some of these questions. As I said, finding client-side configuration examples was near-impossible a few months ago when I first started working on this (and I resorted to the tried-and-true method of trial-and-error to figure it out), but there seemed to be plenty of server-side stuff out there. My only question now is: should I focus on the WIDE or the ISC version (which will pfSense use going forward)? One thing I can say before I go any further is that both the DUID and IAID will be required for reserving IPv6 addresses.
-
We're using the ISC server, and as I mentioned, it doesn't yet have a way to specify fixed addresses by both the IAID and DUID. That's the problem.
I still don't think using the MAC is a bad idea, not sure why they keep insisting it is. Sure the DUID is the same if you swap cards, but if you reinstall the OS, or multi-boot, or PXE, each of those can have a different DUID (until everyone decides to actually put the DUID in firmware… if that ever happens...)
In this thread we are speaking of the server issue on pfSense only - not the client on pfSense.
-
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.
