Re: [mif] route-option implementation

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 28 October 2011 12:04 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9818521F84F8 for <mif@ietfa.amsl.com>; Fri, 28 Oct 2011 05:04:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxsIaiZ7qxYN for <mif@ietfa.amsl.com>; Fri, 28 Oct 2011 05:04:32 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 98A7821F84F5 for <mif@ietf.org>; Fri, 28 Oct 2011 05:04:32 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p9SC4SIY021183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Oct 2011 14:04:28 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p9SC4R73006837; Fri, 28 Oct 2011 14:04:27 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p9SC4NrB023948; Fri, 28 Oct 2011 14:04:27 +0200
Message-ID: <4EAA9A47.3060707@gmail.com>
Date: Fri, 28 Oct 2011 14:04:23 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: teemu.savolainen@nokia.com
References: <4E88B6EF.9050800@gmail.com> <COL118-W23789C049B5BE989F7B721B1D20@phx.gbl> <4EA93870.4020302@gmail.com> <4EA94CB3.5090606@gmail.com> <4EA9654D.2010506@gmail.com> <4EA96BCA.204@gmail.com> <E6AE72A6-B520-475D-BC3C-27567745D1C0@nominum.com> <4EA98398.5010901@gmail.com> <916CE6CF87173740BC8A2CE44309696203792B9B@008-AM1MPN1-037.mgdnok.nokia.com>
In-Reply-To: <916CE6CF87173740BC8A2CE44309696203792B9B@008-AM1MPN1-037.mgdnok.nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: mif@ietf.org, margaretw42@gmail.com, maximouton@gmail.com, denghui02@hotmail.com
Subject: Re: [mif] route-option implementation
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2011 12:04:33 -0000

Le 28/10/2011 10:06, teemu.savolainen@nokia.com 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
>
>
>