Bug 440330 - duplicate IAIDs
duplicate IAIDs
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcpv6 (Show other bugs)
5.2
All Linux
urgent Severity low
: rc
: ---
Assigned To: David Cantrell
: ZStream
Depends On:
Blocks: 253764 449326
  Show dependency treegraph
 
Reported: 2008-04-02 16:39 EDT by rob
Modified: 2009-01-20 16:38 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 16:38:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Sample patch of proposed solution/workaround. (682 bytes, patch)
2008-04-02 16:39 EDT, rob
no flags Details | Diff

  None (edit)
Description rob 2008-04-02 16:39:45 EDT
Description of problem:

According to RFC 3315:
Each IA has an IAID, which is chosen to be unique among all IAIDs for IAs
belonging to that client.

However, a machine with multiple nics and similar MAC addresses chooses
duplicate IAIDs.

Currently, the first four bytes of the MAC address are used to generate the
IAID.  In hosts with multiple interfaces, the MAC address for each interface can
vary solely in the last byte.  The current algorithm guarantees that duplicate
IAIDs will be generated in such situations, which violates the RFC as quoted
above.  Using the last 4 bytes of the MAC address to generate the IAID should be
unique enough for practical purposes.  Neither of these methods guarantee
uniqueness, but the current algorithm is more prone to collisions, than the
suggested one.

Thoughts?

Version-Release number of selected component (if applicable):
dhcpv6-1.0.10-1.el5

How reproducible:
Every time.
Comment 1 rob 2008-04-02 16:39:45 EDT
Created attachment 300135 [details]
Sample patch of proposed solution/workaround.
Comment 2 David Cantrell 2008-04-02 17:49:47 EDT
Reasonable solution, but it doesn't address all situations like you said.  For example, aliased interfaces 
or perhaps virt interfaces via Xen or something.  I want to dig in to this deeper, but don't have time 
today.

It's too late for any fix to make it in to 5.2, unfortunately.  I would really prefer to address this upstream 
first, so could you file it at http://fedorahosted.org/dhcpv6/ as a bug?  Don't worry, I'm not trying to 
pawn the bug off on someone else.  I am the upstream project for dhcpv6.

This bug will have to be postponed to RHEL 5.3 for a fix on that side, but I can get something in Fedora 
relatively quickly.

Thanks.

Out of curiosity, how are you using dhcpv6 at GTRI?  I worked two summers at GTRI while I was a 
student at GT.  Worked in the GCATT building with Jeff Evans.  That was about 10 years ago now, I 
guess.  Wow, time flies.
Comment 3 rob 2008-04-02 18:50:09 EDT
(In reply to comment #2)
> Reasonable solution, but it doesn't address all situations like you said.  For
example, aliased interfaces 
> or perhaps virt interfaces via Xen or something.  I want to dig in to this
deeper, but don't have time today.

Here is a list of most of those special cases:

eth0      Link encap:Ethernet  HWaddr 00:15:F2:BF:F7:F8  
eth0:1    Link encap:Ethernet  HWaddr 00:15:F2:BF:F7:F8  
eth0:2    Link encap:Ethernet  HWaddr 00:15:F2:BF:F7:F8  
veth1     Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
veth2     Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
vif0.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
vif0.1    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
xenbr0    Link encap:Ethernet  HWaddr 36:81:89:48:07:32  
tap0      Link encap:Ethernet  HWaddr 36:81:89:48:07:32  

> It's too late for any fix to make it in to 5.2, unfortunately.  I would really
prefer to address this upstream 
> first, so could you file it at http://fedorahosted.org/dhcpv6/ as a bug?

no problem:
https://fedorahosted.org/dhcpv6/ticket/14

> Out of curiosity, how are you using dhcpv6 at GTRI?

Our lab is working with GTRI on the best way to deploy ipv6.  We are currently
just testing feasibility on a test lan.  The goal is to come up with an ipv6
deployment plan.

>  I worked two summers at GTRI while I was a 
> student at GT.  Worked in the GCATT building with Jeff Evans.  That was about
10 years ago now, I 
> guess.  Wow, time flies.

*filed under it's a small world after all* :)

Comment 13 errata-xmlrpc 2009-01-20 16:38:31 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0165.html

Note You need to log in before you can comment on or make changes to this bug.