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

Teco Boot <teco@inf-net.nl> Mon, 02 August 2010 17:56 UTC

Return-Path: <teco@inf-net.nl>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1A53A6B0F for <autoconf@core3.amsl.com>; Mon, 2 Aug 2010 10:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6fl8kxFri08 for <autoconf@core3.amsl.com>; Mon, 2 Aug 2010 10:56:15 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 8DB4A3A6B9D for <autoconf@ietf.org>; Mon, 2 Aug 2010 10:56:14 -0700 (PDT)
Received: by ewy22 with SMTP id 22so1566589ewy.31 for <autoconf@ietf.org>; Mon, 02 Aug 2010 10:56:42 -0700 (PDT)
Received: by 10.213.35.6 with SMTP id n6mr4481482ebd.0.1280771802231; Mon, 02 Aug 2010 10:56:42 -0700 (PDT)
Received: from [172.16.4.99] ([77.61.241.196]) by mx.google.com with ESMTPS id a48sm9227157eei.7.2010.08.02.10.56.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Aug 2010 10:56:41 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <AANLkTi=OQvQew9rRaHkH=62NjF6Qe-gcLz70VyiWogdK@mail.gmail.com>
Date: Mon, 2 Aug 2010 19:56:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A14891DE-61C3-41EF-A22A-40FE71C722DA@inf-net.nl>
References: <EBE1B970-DADA-4643-BB75-4EDEDE41F758@inf-net.nl> <E1829B60731D1740BB7A0626B4FAF0A649E15C3F6E@XCH-NW-01V.nw.nos.boeing.com> <DB76629A-3BC9-46A0-BE4E-8E918E6AD63B@inf-net.nl> <AANLkTi=OQvQew9rRaHkH=62NjF6Qe-gcLz70VyiWogdK@mail.gmail.com>
To: Ulrich Herberg <ulrich@herberg.name>
X-Mailer: Apple Mail (2.1081)
Cc: "autoconf@ietf.org autoconf@ietf.org" <autoconf@ietf.org>
Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces?
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Aug 2010 17:56:16 -0000

Op 2 aug 2010, om 18:55 heeft Ulrich Herberg het volgende geschreven:

> Teco,
> 
> On Sat, Jul 31, 2010 at 3:56 PM, Teco Boot <teco@inf-net.nl> wrote:
>> Fred,
>> 
>> Do you mean DHCP relay can be used on a node, that request an address
>> for itself?
> 
> I have tried that a while ago. It works with some limitations (see below).
> 
>> 
>> 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.


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


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


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


>> 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 ??  :-))


Teco