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

Teco Boot <teco@inf-net.nl> Sat, 31 July 2010 13: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 5B0513A69A6 for <autoconf@core3.amsl.com>; Sat, 31 Jul 2010 06:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 xrvQFK8B+5vQ for <autoconf@core3.amsl.com>; Sat, 31 Jul 2010 06:56:36 -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 0099D3A69B2 for <autoconf@ietf.org>; Sat, 31 Jul 2010 06:56:35 -0700 (PDT)
Received: by ewy22 with SMTP id 22so1038303ewy.31 for <autoconf@ietf.org>; Sat, 31 Jul 2010 06:57:00 -0700 (PDT)
Received: by 10.213.31.141 with SMTP id y13mr1773104ebc.70.1280584620558; Sat, 31 Jul 2010 06:57:00 -0700 (PDT)
Received: from [192.168.2.190] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id z55sm5171794eeh.21.2010.07.31.06.56.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 31 Jul 2010 06:56:59 -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: <E1829B60731D1740BB7A0626B4FAF0A649E15C3F6E@XCH-NW-01V.nw.nos.boeing.com>
Date: Sat, 31 Jul 2010 15:56:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
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: Sat, 31 Jul 2010 13:56:38 -0000

Fred,

Do you mean DHCP relay can be used on a node, that request an address 
for itself?

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.
2b) If node is provisioned with DHCP server unicast address, it could use that 
    instead of All_DHCP_Servers.
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.
Another drawback of 1: there is a timeout delay when there is no relay or server
at one hop.

For 2a: the network needs multicast support. Could be SMF.

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.

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