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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Mon, 02 August 2010 17:30 UTC

Return-Path: <Fred.L.Templin@boeing.com>
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 DFE7C3A69CC for <autoconf@core3.amsl.com>; Mon, 2 Aug 2010 10:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.045
X-Spam-Level:
X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 6c7T+29ielHh for <autoconf@core3.amsl.com>; Mon, 2 Aug 2010 10:30:44 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 6302C3A6AB6 for <autoconf@ietf.org>; Mon, 2 Aug 2010 10:30:44 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o72HV6mJ025677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Aug 2010 10:31:08 -0700 (PDT)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o72HV6rm021119; Mon, 2 Aug 2010 12:31:06 -0500 (CDT)
Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o72HV5ox021084 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 2 Aug 2010 12:31:06 -0500 (CDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Mon, 2 Aug 2010 10:31:06 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Ulrich Herberg <ulrich@herberg.name>, Teco Boot <teco@inf-net.nl>
Date: Mon, 2 Aug 2010 10:31:05 -0700
Thread-Topic: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces?
Thread-Index: AcsyY5uQdm7XeRDYTlWNLgzUQ5ICgQAAtIeQ
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A649E15C43BE@XCH-NW-01V.nw.nos.boeing.com>
References: <EBE1B970-DADA-4643-BB75-4EDEDE41F758@inf-net.nl><E1829B60731D17 40BB7A0626B4FAF0A649E15C3F6E@XCH-NW-01V.nw.nos.boeing.com><DB76629A-3BC9-46A0-BE4E-8E918E6AD63B@inf-net.nl> <AANLkTi=OQvQew9rRaHkH=62NjF6Qe-gcLz70VyiWogdK@mail.gmail.com>
In-Reply-To: <AANLkTi=OQvQew9rRaHkH=62NjF6Qe-gcLz70VyiWogdK@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:30:46 -0000

Ulrich,

> -----Original Message-----
> From: Ulrich Herberg [mailto:ulrich@herberg.name]
> Sent: Monday, August 02, 2010 9:55 AM
> To: Teco Boot
> Cc: Templin, Fred L; autoconf@ietf.org autoconf@ietf.org
> Subject: Re: [Autoconf] Using DHCPv6 without link-local? Support only EUI-64interfaces?
> 
> 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"

The client function would never see a Relay-forward, because
that is generated by the relay function and sent to either the
unicast address of a server or All-DHCP-Servers multicast. Maybe
you meant section 15.14 "Clients and servers MUST discard any
received Relay-reply messages"? But, it is the node's relay
function (and not the client function) that gets the
Relay-reply so this is not in violation of the spec.

> and
> (ii) section 15.3 "servers and relay agents MUST discard any received
> Advertise messages".

The node's client function (and not the relay function) is the
one that gets the Advertise message when 4-message exchange is
used; the relay function sees only the Relay-reply and then
forwards the Advertise on to the client function. Also, in
2-message exchange there is no Advertise message.

Fred
fred.l.templin@boeing.com

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