DHCPv6 and IAID+DUID or other means of selecting IPs by interface


  • Rebel Alliance Developer Netgate

    [EDIT: Apologies if this seems disjointed, I split it off the other topic since the other was a trouble report and this is a separate discussion.]

    There is little incentive to using a /48 directly on the LAN anyhow. A /64 is the best thing to do - it's not like you're going to run out of IPs in the /64.

    Something tells me you'll have way more problems than running out of IPs if you really have more than 18,446,744,073,709,551,616 nodes on a single segment. :-)



  • @jimp:

    There is little incentive to using a /48 directly on the LAN anyhow. A /64 is the best thing to do - it's not like you're going to run out of IPs in the /64.

    Something tells me you'll have way more problems than running out of IPs if you really have more than 18,446,744,073,709,551,616 nodes on a single segment. :-)

    well.., So I use /48 ipv6 years. all server and service use /48 address. and I like short address. So I want to use /48 addrss. maybe I may setup lucky name for ip address.  ;)


  • Rebel Alliance Developer Netgate

    Not sure what you mean by that, /48 addresses have more parts that vary than /64's. The prefix is shorter but the host part of the address is longer.

    From wikipedia:

    An RFC 4291 compliant subnet always uses IPv6 addresses with 64 bits for the host portion.[10] It therefore has a /64 routing prefix (128−64 = the 64 most significant bits). Although it is technically possible to use smaller subnets,[11] they are impractical for local area networks based on Ethernet technology, because 64 bits are required for stateless address auto configuration.[12] The Internet Engineering Task Force recommends the use of /64 subnets even for point-to-point links, which consist of only two hosts.[13]

    So if you decide to break the RFC and go against the IETF, you shouldn't be surprised to find things that don't work like you expect. :-)

    I know plenty of people who have been doing the wrong thing "for years" it doesn't make it right.



  • Such as 2001:470:15::2 use for my web server.

    now I setup 2001:470:15::1/64 in LAN interface,  just it is can get ipv6 address from DHCP6.

    if setup 2001:470:15::1/48 in LAN interface, it can't support all client system.



  • now I plan use fixed /48 address for web server etc.  use /64 subnet for client system and winfi etc.

    Could you tell me how setup static ipv6 address?

    where are get the DUID ?


  • Rebel Alliance Developer Netgate

    It still makes no sense to use a /48 for that - you can use the exact same prefix, just call it /64 - it will just assume all 0's in between, then use the xxx:1::/64, xxx:2::/64 and so on for other subnets.

    DUID and IAID vary by OS, not sure we have any kind of guide. usually found in ifconfig or ipconfig output. Easiest way is to add them in the DHCP leases list and click "+" to make an entry from there so it gets the right bits. IIRC You can't set static via autoconf, only with DHCPv6 or by hardcoding the info.



  • @jimp:

    It still makes no sense to use a /48 for that - you can use the exact same prefix, just call it /64 - it will just assume all 0's in between, then use the xxx:1::/64, xxx:2::/64 and so on for other subnets.

    DUID and IAID vary by OS, not sure we have any kind of guide. usually found in ifconfig or ipconfig output. Easiest way is to add them in the DHCP leases list and click "+" to make an entry from there so it gets the right bits. IIRC You can't set static via autoconf, only with DHCPv6 or by hardcoding the info.

    because my two NIC get the same DUID, So I can use input IAID for setup static ipv6 address?



  • @yon:

    because my two NIC get the same DUID,

    Discussed in http://forum.pfsense.org/index.php/topic,47658.0.html



  • just Different two MAC NIC still the same DUID.  So if maybe can use the IAID for setup static ipv6 address.


  • Rebel Alliance Developer Netgate

    It may be possible in the underlying software (isc-dhcpd) but not yet in our GUI.

    Are these two NICs plugged into the same subnet? I'm just wondering what the use case is where you need two DHCP NICs on a single host.



  • @jimp:

    It may be possible in the underlying software (isc-dhcpd) but not yet in our GUI.

    Are these two NICs plugged into the same subnet? I'm just wondering what the use case is where you need two DHCP NICs on a single host.

    Because the my mail server has install two mail server software. one for ipv4 mail server, and other for ipv6 ipv4 mail server.  such as: 192.168.101.3 NIC for ipv6 ipv4 mail server. 192.168.101.5 for ipv4 only mail server. its will has two 25 port can use in multi-wan.


  • Rebel Alliance Developer Netgate

    That doesn't make any sense with respect to the DUID and DHCPv6. Does it have multiple interfaces? Do they both need unique DHCP IPs?

    You should never, ever have multiple NICs in the same box on the same subnet just plugged into the same switch/vlan unless you're doing LAGG/LACP.



  • @jimp:

    That doesn't make any sense with respect to the DUID and DHCPv6. Does it have multiple interfaces? Do they both need unique DHCP IPs?

    You should never, ever have multiple NICs in the same box on the same subnet just plugged into the same switch/vlan unless you're doing LAGG/LACP.

    yes. I need stup static ipv4 and ipv6 address for client server.  because its have running a lot A variety of services. and I will do network link Aggregation.



  • just I need like ipv4 MAC bind fixed ip for each NIC. Can I use IAID or MAC for ipv6?



  • The server has only one DUID, not one per network interface. The link layer address of a (any of the available) interface is however often encoded into the DUID to guarantee uniqueness.


  • Rebel Alliance Developer Netgate

    But why "each nic"? The DUID would only be the same on a single machine. You shouldn't be trying to plug multiple interfaces from the same machine into the same network, so a DUID conflict shouldn't be an issue.

    We're looking into how to get the dhcpv6 daemon to go by MAC like the v4 version does. The new version of ISC DHCPD is supposed to support that but we haven't seen an example of the syntax yet.



  • It matches the MAC address in the DUID, not the interface MAC.

    host otherclient {
            # This host entry is hopefully matched if the client supplies a DUID-LL
            # or DUID-LLT containing this MAC address.
            hardware ethernet 01:00:80:a2:55:67;
    
            fixed-address6 3ffe:501:ffff:100::4321;
    }
    

  • Rebel Alliance Developer Netgate

    Ah, so if a client still provides the same DUID, including the mac of whatever interface it decided that should come from, then it would still be useless.

    Windows 7 does that - DUID is the same. It picks one MAC address from one NIC and then sends it along. It sends a different IAID for each one though, I believe. I didn't see that mentioned exactly in the docs though, presumably there is a way to match on IAID.



  • I just see get the different IAID. what's IAID?



  • Rebel Alliance Developer Netgate

    Identity association identifier. If I remember right it's meant to be an extra ID over and above the DUID to differentiate interfaces.

    From RFC3315:

    Identity association (IA) A collection of addresses assigned to
                                    a client.  Each IA has an associated
                                    IAID.  A client may have more than one
                                    IA assigned to it; for example, one for
                                    each of its interfaces.

    Identity association identifier (IAID) An identifier for an IA,
                                    chosen by the client.  Each IA has an
                                    IAID, which is chosen to be unique among
                                    all IAIDs for IAs belonging to that
                                    client.


  • Rebel Alliance Developer Netgate

    FYI you can confirm an IAID on Windows by looking at "ipconfig /all" - it will show both the IAID and DUID for an interface.



  • DHCPv6 allows in theory to configure multiple addresses and interfaces on a single host (unlike IPv4). However you may have to ask on the dhcp-users Mailinglist if it is already supported (e.g. using DUID+IAID to configure the addresses).

    Edit:
    Changed to DUID+IAID



  • We should choose an Only and not repeat the identity identifier. For a variety of applications client.

    Identity should not be repeated, whether in any environment.  ::)


  • Rebel Alliance Developer Netgate

    For each client the DIUD is unique. For each interface the IAID is unique. So the only truly unique thing to use would appear to be IAID+DUID. The IAID is nowhere near long enough to be guaranteed unique across any two clients.



  • @bardelot:

    DHCPv6 allows in theory to configure multiple addresses and interfaces on a single host (unlike IPv4). However you may have to ask on the dhcp-users Mailinglist if it is already supported (e.g. using DUID+IAID to configure the addresses).

    Edit:
    Changed to DUID+IAID

    I have post to that mail list now.  :)


  • Rebel Alliance Developer Netgate

    @mdpugh:

    I've been following the exchanges in dhcp-users@lists.isc.org and dhcwg@ietf.org for months now.  The first one is how I found this thread.  Please do not try to use the MAC address as a unique identifier for DHCPv6.  You will fundamentally break pfSense if you do and it will fly in the face of everything that has gone into DHCPv6 thus far.  The correct method is, as suggested, DUID and IAID.  I have been running IPv6 on three subnets for several months using Server 2008 as the DHCPv6 server and pfSense as the router with both Windows and FreeBSD clients.  All computers are multihomed to at least two of these subnets with no hitches on the DHCPv6 end (I still have router advertisement issues, which I hope is where you decide to focus your attention).

    I would much prefer the DUID+IAID if we can find a way to make it feasible. Seeing as we already extract this info from the leases view surely there is a way to apply that to a fixed address.

    @mdpugh:

    The only real reason that I can discern for why people seem to want to use the MAC as a unique identifier in DHCPv6 is for provisioning; they want to know the host with this IPv4 address has that IPv6 address (and vice versa).  But I still haven't seen a sufficient reason to break DHCPv6 as it currently stands to accomplish this.

    It would be nice to have a way to do that, yes, but it seems more to me that people want to use it because it's easy and familiar. You can read the MAC on a sticker on most cards but getting the DUID and IAID is not so cut and dry. Though as someone mentioned earlier in this thread the mac command for dhcpv6 seems to actually read the mac portion of the DUID so it would be worthless for distinguishing interfaces anyhow.

    @mdpugh:

    Incidentally, I gave an example of the syntax for IAID usage in the client configuration file in a much older post in this forum.  I've tested this, so I know it works.

    It looks like the example you gave was for the dhcp6c client not the server unless I missed the post. Do you have a link?

    If we can get the syntax hashed out then we just need to add another box to the GUI.

    Or if it's as simple as prepending the IAID onto the DUID (we have to split them in the leases view) then it may be even easier.


  • Rebel Alliance Developer Netgate

    http://osdir.com/ml/North-American-Network-Operators-Group/2012-01/msg00749.html implies it is not yet possible but a feature request now exists.

    Seeing as the most current release of the ISC DHCP daemon is before that message, I highly doubt it's possible at this point in time.



  • 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.


  • Rebel Alliance Developer Netgate

    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.


  • Rebel Alliance Developer Netgate

    @mdpugh:

    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.

    @mdpugh:

    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 ;-)

    @mdpugh:

    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.

    @mdpugh:

    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/bind

    ISC 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.asc

    ISC'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


  • Rebel Alliance Developer Netgate

    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?


  • Rebel Alliance Developer Netgate

    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?  ::)


Locked