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

<> Fri, 28 October 2011 08:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6337621F8AF4 for <>; Fri, 28 Oct 2011 01:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.968
X-Spam-Status: No, score=-2.968 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FESyVGppCeg8 for <>; Fri, 28 Oct 2011 01:07:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 78F6A21F8AEE for <>; Fri, 28 Oct 2011 01:07:10 -0700 (PDT)
Received: from ( []) by (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9S874ew027967; Fri, 28 Oct 2011 11:07:07 +0300
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 11:07:01 +0300
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 28 Oct 2011 10:07:00 +0200
Received: from ([]) by ([]) with mapi id 14.01.0339.002; Fri, 28 Oct 2011 10:06:59 +0200
Thread-Topic: I won't be in Taipei for MIF WG
Date: Fri, 28 Oct 2011 08:06:59 +0000
Message-ID: <>
References: <> <COL118-W23789C049B5BE989F7B721B1D20@phx.gbl> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Company Confidential; Project=None;
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IpQXDHt1zk6X9/SfGRWWDsRJk7rmELM52TQMlD/w5WK9K27zeZmGPyS3FOnTIEQDK5jS55UQumwz+iBF0K0p1sbVXICJ53WBGjsb/wpFrV2czDl5/Rm2zYvGRGGyhXG0vEjLhWm4KnM2rDCA0R472ujiN9ALdHeM1kUxk5k+ywfd3iDsnDpS93Y+neLYAHvSARSNezLNlrw17Z2gaiq7xFsNPEudFZlVQj08eA0JcD3M
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Oct 2011 08:07:01.0060 (UTC) FILETIME=[923DA840:01CC9548]
X-Nokia-AV: Clean
Subject: Re: [mif] I won't be in Taipei for MIF WG
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Oct 2011 08:07:11 -0000

> > 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: (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 2001:xxxx:xxxx:xx::x;
option dhcp6.option-dns-server-selection-policy
2001:xxxx:xxxx:xxxx::x 00 "", "";

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:
   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.

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,