Re: [mif] I won't be in Taipei for MIF WG

[<[e-mail]>]

> > There is no rough consensus for your proposal, Alexandru.
> 
> And  is there running code for route-option?

At the IETF#79 we had demonstration of our client side implementation (using ISC's DHCP-client) done with Nokia N900 against NTT's implementation of the DHCPv6 server: http://www.ietf.org/registration/MeetingWiki/wiki/79bofs (see section " Interoperability demonstration regarding IPv6 Multihoming with multiple prefixes and interfaces").

In addition to that, in my lab I configured ISC's DHCP-4.2.0 server with the following configuration (masquerading real addresses with 'x'). The unassigned option code 92 refers to DNS server selection option (as was specified in draft-savolainen-mif-dns-server-selection-04) and unassigned code 93 for DHCPv6 option (as was specified in draft-dec-dhcpv6-route-option-05). I had to use "string" type for OPTION-IA-RT as the grammar for some reason (bug or not-yet-implemented or my lack of skill, don't recall which) did not work with options having multiple sub-options. Please note that all option codes are just "random numbers" selected for implementation.
--
option dhcp6.option-dns-server-selection-policy code 92 = 
			{ ip6-address, integer 8, domain-list };

option dhcp6.option-ia-rt code 93 = string;

subnet6 2001:xxx:xxx:42::/64 {
option dhcp6.name-servers 2001:xxxx:xxxx:xx::x;
option dhcp6.option-dns-server-selection-policy
2001:xxxx:xxxx:xxxx::x 00 "nokia.com", "ovi.com";

option dhcp6.option-ia-rt	
00:01:00:3C:					       // OPTION_NEXT_HOP + len
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:  // next hop address
00:01:00:12:					       // OPTION_RT_PREFIX + len
60:01:                                                                                  // Prefix Length + metric
64:FF:9B:00:00:00:00:00:00:00:00:00:00:00:00:00:  // Prefix
00:01:00:12: 					      // OPTION_RT_PREFIX + len
30:02:				 	 	      // Prefix Length + metric
2A:00:xx:xx:xx:xx:00:00:00:00:00:00:00:00:00:00:   // Prefix
00:01:00:26:                                                                      // OPTION_NEXT_HOP + len
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: // Next Hop address
00:01:00:12:  					      // OPTION_RT_PREFIX + len
00:00:             					     // Prefix Length + metric
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 // Prefix == default route
--
The point here is  that the option could be defined without touching server's source code (or scripts) and I imagine some GUI-based configuration creation tool could also use the string-format without trouble.

The ISC's client side implementation was similarly unable to parse the sub-options, hence I used "string" also there:
--
option dhcp6.option-dns-server-selection-policy code 92 = { ip6-address, integer 8, domain-list };

option dhcp6.option-ia-rt code 93 = string;
--

I admit that on the client side I had to do quite many lines of scripting into "dhclient-enter-hooks" for fetching the data out of the said string.

I also had to modify the C-code of the client to fetch the IPv6 address of the DHCP server, as that was not provided by the ISC DHCP client via any environment variable (this was needed for this case:
--copy--
   When processing a received Route Option a client MUST substitute a
   received 0::0 value in the Next Hop Option with the source IPv6
   address of the received DHCPv6 message.
--copy--

Of course I then needed some addition code for implementing all the actions received information triggered (setting up routes etc), but I guess that part is out of scope of this thread. The dhclient-enter-hooks script actually called a small program that did the actual tricks:
--
/usr/sbin/parse_ia_rt $new_dhcp6_option_ia_rt $interface $dhcpv6_server_address
--

Best regards,

	Teemu