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

Teco Boot <teco@inf-net.nl> Wed, 04 August 2010 06:10 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 C1D1D3A6BE7 for <autoconf@core3.amsl.com>; Tue, 3 Aug 2010 23:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level:
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 byXsEd6r-Ksm for <autoconf@core3.amsl.com>; Tue, 3 Aug 2010 23:10:03 -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 38BE93A69FA for <autoconf@ietf.org>; Tue, 3 Aug 2010 23:10:03 -0700 (PDT)
Received: by ewy22 with SMTP id 22so2117457ewy.31 for <autoconf@ietf.org>; Tue, 03 Aug 2010 23:10:31 -0700 (PDT)
Received: by 10.213.22.18 with SMTP id l18mr1620889ebb.58.1280902231427; Tue, 03 Aug 2010 23:10:31 -0700 (PDT)
Received: from [192.168.2.196] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm12158143eei.6.2010.08.03.23.10.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Aug 2010 23:10:30 -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: <AANLkTik3dsDw6_BLhskSJ3Yp-PtivGfF=h+YOJnseRQE@mail.gmail.com>
Date: Wed, 4 Aug 2010 08:10:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D235582-112C-4217-A646-34139CAB49F9@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> <A14891DE-61C3-41EF-A22A-40FE71C722DA@inf-net.nl> <AANLkTik3dsDw6_BLhskSJ3Yp-PtivGfF=h+YOJnseRQE@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: Wed, 04 Aug 2010 06:10:04 -0000

Op 2 aug 2010, om 23:46 heeft Ulrich Herberg het volgende geschreven:

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

I don't see the problem.


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

SMF is experimental.


Teco