Re: [mif] route-option implementation

[Alexandru Petrescu <[e-mail]>]

Le 28/10/2011 10:06, [e-mail] a écrit :
>>> 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.

I understand.

Let me tell further how I understand it.

The way ISC DHCP software is written, it does not allow to define new
options in the DHCP messages such as to convey lifetime and MAC address
(be it for a default route, or for other route) in an efficient manner
(i.e. avoid artificial "type" and "len" separators).  If one wants to do
that then one has to modify the ISC software more than just reusing its
standard software way of extensions like option dhcp6.option-ia-rt.

This further modification (MAC, lifetime) can only be done by C code.

If find it artificial to limit the specification of protocol to the way
one particular implementation (ISC, which is very good) lets an
implementer to do.

In this sense, I do not think the current route-option spec is
extensible in a way my requirements needs it (limited ressources
wireless, interactions with ND); the current route-option spec is
extensible only in the way that ISC software is extensible.

If route-option draft would not do "default route" - but do "all routes
except default" - then another later option will be able to do "default
route" in a more efficient manner.

Alex

Let me put it otherwise: because ISC implementation doesn't allow one to
avoid touching C code defining new option (e.g. MAC), or a more
efficient way of sequencing
>
> 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
>
>
>