Re: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces?

Ulrich Herberg <> Mon, 02 August 2010 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F245D3A69DA for <>; Mon, 2 Aug 2010 14:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8faTR2Tosk8k for <>; Mon, 2 Aug 2010 14:46:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 888D73A686B for <>; Mon, 2 Aug 2010 14:46:21 -0700 (PDT)
Received: by bwz7 with SMTP id 7so2441974bwz.31 for <>; Mon, 02 Aug 2010 14:46:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id p8mr4515801bkg.163.1280785607479; Mon, 02 Aug 2010 14:46:47 -0700 (PDT)
Received: by with HTTP; Mon, 2 Aug 2010 14:46:47 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Mon, 2 Aug 2010 23:46:47 +0200
Message-ID: <>
From: Ulrich Herberg <>
To: Teco Boot <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Aug 2010 21:46:23 -0000


On Mon, Aug 2, 2010 at 7:56 PM, Teco Boot <> wrote:
>>> I think it could work this way:
>>> 1) Node queries with link-local to All_DHCP_Relay_Agents_and_Servers.
>>> 2a) Node acts as also relay and queries with ULA (site-local) to All_DHCP_Servers.
>> Do you mean that a node is DHCP client and relay in the same time?
>> That is not possible according to RFC3315, which says (i) in section
>> 15.13 "clients MUST discard any received Relay-forward messages" and
>> (ii) section 15.3 "servers and relay agents MUST discard any received
>> Advertise messages".
> I don't think there is such limitation.
> A node that combines client and relay would not send out a packet that does
> not conform to the spec.

Fred pointed that out. I wonder whether that demultiplexing is clearly
pointed out in the DHCPv6 RFC. But well, too late to change it ;-)
I assume that major DHCPv6 implementations do not implement that
demultiplexing (they'd need to share the UDP port, demultiplex
messsages etc.) (-- I know, that's not so much a problem of the
standardization process.. just wondering here)

>> Also, the relay would need to have a direct unicast connection to the
>> central node or use other relaying mechanisms such as SMF (as you
>> mentioned below), because multiple relaying is not really feasible in
>> DHCPv6 itself: Relaying uses encapsulation, so packets would be
>> encapsulated at every hop, quickly increasing overhead.
> Yes, relaying and encap on every hop is a bad idea, I think.
> But we don't have a standard track multicast protocol for MANETs.
> We also don't have a protocol for service discovery, for learning the
> DHCP server address.
> This makes our work experimental.

Indeed. It would make life easier to have such protocols as RFCs
already :-) With SMF, we have at least a protocol which is not so far
from being published as RFC.

>>    And I also
>> don't think that DHCP relaying allows duplicate packet detection.
> Why not?
> SMF hashing should work. Each packet has a random transaction ID.
> Or include a SMF-DPD header option.

True. But that is defined in SMF, not in DHCPv6 relaying.

>>> 2b) If node is provisioned with DHCP server unicast address, it could use that
>>>    instead of All_DHCP_Servers.
>> Sure, that is possible if a unicast routing protocol is used.
>>> I think this is in line with your RFC 5558.
>>> Drawback of 1: it can result in high number of relayed DHCP packets, in case
>>> of many neighbors.
>> True.
>>> Another drawback of 1: there is a timeout delay when there is no relay or server
>>> at one hop.
>> But I guess this timeout can be set dynamically?
> When 1 is used as a first try, looking for a DHCP-server at one hop, the node
> should wait some time for a response. If no response arrives, it could go to step 2.
> The timeout would be a configured parameter, I think.
> Maybe it is better to skip such a mechanism. Needs more thoughts.

Yes, I also have to think more about it.

>>> For 2a: the network needs multicast support. Could be SMF.
>> Yes, that could be a possibility.
>>> For both 2a and 2b: a temporally used unicast address must be routable. So this
>>> DHCP mechanism can only be used as a second step, moving from the self-generated
>>> address to a centrally managed address.
>> Yes, that seems possible (but I have to re-read the DHCPv6 RFC after
>> my vacations ;-)
> Not _during_ your vacation ??  :-))

hehe, well, my boss would like that ;-)