Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 440330

Summary: duplicate IAIDs
Product: Red Hat Enterprise Linux 5 Reporter: rob <rob.myers>
Component: dhcpv6Assignee: Dave Cantrell <dcantrell>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: urgent    
Version: 5.2CC: josh.kayse
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-20 21:38:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 253764, 449326    
Attachments:
Description Flags
Sample patch of proposed solution/workaround. none

Description rob 2008-04-02 20:39:45 UTC
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 20:39:45 UTC
Created attachment 300135 [details]
Sample patch of proposed solution/workaround.

Comment 2 Dave Cantrell 2008-04-02 21:49:47 UTC
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 22:50:09 UTC
(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 21:38:31 UTC
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