Bug 798735

Thanks Neil,

however do we really need this to have in RHEL-6 ?
I mean, I have no idea what's RFC5970 about at the moment but
you're mentioning grub2 - do we have grub2 in RHEL-6 ?
What about postponing this to RHEL-7 ?

Peterm asked if we could get this in place for 6.3.  We don't currently have grub2 in place for rhel6 (not sure what Pjones plans are there).  UEFI netboot will also be using the RFC5970 options, and that will definately be available in RHEL6.  

Also, these options are parsed by both the client and the server. And while RHEL6 clients may not immediately need these options, RHEL6 servers definately will, as they will be serving future clients that will need this ability.

Thanks.

OK, will you help Release Test Team test this feature once I build the packages ?

Created attachment 566816 [details]
Patch - RFC5970 - DHCPv6 Options for Network Boot

I'm attaching the patch also here.

I tested it like this:

1) add to /etc/dhcp/dhcpd6.conf:
  option dhcp6.bootfile-url "bootfile url test string";
  option dhcp6.arch-type 666, 777, 888, 999;
  option dhcp6.net-id 2 3 4;
2) service dhcpd6 start
3) add to /etc/dhcp/dhclient6.conf
  also request dhcp6.bootfile-url, dhcp6.arch-type, dhcp6.net-id;
4) dhclient -6 -d -cf /etc/dhcp/dhclient6.conf eth0
5) check in wireshark that server sends options number 59,61,62

In response to comment 3:
gladly, thank you Jiri.  What you did in comment 4 is exactly how I tested it origionally.  I also preformed the following test (as option 61 is typically sent from client to server)

1: modified dhclient.conf with this line:
also send dhcp6.arch-type 9;

2:
modified dhcpd6.conf as follows:
if option dhcp6.arch-type == 00:09 {
     option dhcp6.net-id 1,2,3;
} else
     option dhcp6.net-id 4,5,6;
}

3: 
Use wireshark to validate that server sends net-id of 123

4:
Change dhclient arch-type to 8

5:
use whireshark to validate that server sends net-id of 456

I've been able to successfully verify newly added functionality to the DHCPv6 server and dhclient on dhcp-4.1.1-30.P1.el6 and dhclient-4.1.1-30.P1.el6.

dhcpd6.conf:

default-lease-time 2592000;
preferred-lifetime 604800;
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
allow leasequery;
option dhcp6.info-refresh-time 21600;dhcpv6-lease-file-name "/var/lib/dhcpd/dhcpd6.leases";

option dhcp6.name-servers fdf1:9f98:7dd9:808a::dbb9;
option dhcp6.domain-search "redhat.priv";

subnet6 fd1f:9f98:7dd9:808a::/64 {
        range6 fd1f:9f98:7dd9:808a::1 fd1f:9f98:7dd9:808a::ffff;
        option dhcp6.bootfile-url "[fd1f:9f98:7dd9:808a::dbb9]/test.cfg"; 

        if option dhcp6.arch-type = 00:09 {
                option dhcp6.net-id 2 3 4;
        } else {
                option dhcp6.net-id 4 5 6;
        }
}

dhclient6-eth0.conf:
also request dhcp6.bootfile-url, dhcp6.arch-type, dhcp6.net-id;
send dhcp6.arch-type 8;

In order to see the new options in tcpdump, the /var/lib/dhclient/dhclient6-<interface>.leases file must not exist or must not be valid on the client machine. Otherwise, the client sends a DHCPv6 Confirm message with options that were used when the lease was first obtained and server responds with  'All addresses still on link'.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0793.html