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

Ulrich Herberg <ulrich@herberg.name> Mon, 02 August 2010 16:54 UTC

Return-Path: <ulrich@herberg.name>
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 F3E3D3A6902 for <autoconf@core3.amsl.com>; Mon, 2 Aug 2010 09:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.054
X-Spam-Level:
X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 8pHzE7idmk6l for <autoconf@core3.amsl.com>; Mon, 2 Aug 2010 09:54:50 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C32283A6965 for <autoconf@ietf.org>; Mon, 2 Aug 2010 09:54:49 -0700 (PDT)
Received: by bwz7 with SMTP id 7so2314472bwz.31 for <autoconf@ietf.org>; Mon, 02 Aug 2010 09:55:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.101.72 with SMTP id b8mr4192650bko.192.1280768116801; Mon, 02 Aug 2010 09:55:16 -0700 (PDT)
Received: by 10.204.163.5 with HTTP; Mon, 2 Aug 2010 09:55:16 -0700 (PDT)
In-Reply-To: <DB76629A-3BC9-46A0-BE4E-8E918E6AD63B@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>
Date: Mon, 2 Aug 2010 18:55:16 +0200
Message-ID: <AANLkTi=OQvQew9rRaHkH=62NjF6Qe-gcLz70VyiWogdK@mail.gmail.com>
From: Ulrich Herberg <ulrich@herberg.name>
To: Teco Boot <teco@inf-net.nl>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 16:54:51 -0000

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

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. And I also
don't think that DHCP relaying allows duplicate packet detection.

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

>
> 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 ;-)

Ulrich

>
> Teco
>
>
>
>
> Op 30 jul 2010, om 17:40 heeft Templin, Fred L het volgende geschreven:
>
>> Teco,
>>
>>> -----Original Message-----
>>> From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behalf Of Teco Boot
>>> Sent: Friday, July 30, 2010 4:58 AM
>>> To: autoconf@ietf.org autoconf@ietf.org
>>> Subject: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces?
>>>
>>> RFC3315:
>>>   ...     The client
>>>   MUST use a link-local address assigned to the interface for which it
>>>   is requesting configuration information as the source address in the
>>>   header of the IP datagram.
>>>
>>> Question: can we get around a MUST in a standards track RFC?
>>> I don't think so.
>>
>> If the MANET router only behaves as a client on an internal
>> link (e.g., a loopback) but behaves as a relay on its MANET
>> interfaces, then link-locals need not be exposed for DHCPv6
>> purposes. There are other reasons why link-locals might need
>> to be considered for MANETs, but I'm not sure this is one
>> of them.
>>
>> Fred
>> fred.l.templin@boeing.com
>>
>>> The to be posted proposed text for to be RFC5889 would say that if link-locals are used, there are
>>> potential problems when using other than modified EUI-64 IIDs, and therefore must be based on
>>> modified EUI-64 IIDs.
>>>
>>> Second question, on first item in charter: do we limit ourself to MANET routers that has modified
>>> EUI-64 link-locals?
>>> I think: better think twice.
>>>
>>> Opinions?
>>>
>>> Teco.
>>>
>>>
>>> _______________________________________________
>>> Autoconf mailing list
>>> Autoconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/autoconf
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>