Re: [v6ops] Operational Headache: DHCP V6 Relay

Martin Hunek <martin.hunek@tul.cz> Mon, 01 April 2019 12:11 UTC

Return-Path: <martin.hunek@tul.cz>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9826A12010C for <v6ops@ietfa.amsl.com>; Mon, 1 Apr 2019 05:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2gijgLhvEvS for <v6ops@ietfa.amsl.com>; Mon, 1 Apr 2019 05:11:46 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311E1120100 for <v6ops@ietf.org>; Mon, 1 Apr 2019 05:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from rumburak.ite.tul.cz (rumburak.ite.ip6.tul.cz [IPv6:2001:718:1c01:72:224:1dff:fe77:e35c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id 97438180651F1; Mon, 1 Apr 2019 14:11:42 +0200 (CEST)
From: Martin Hunek <martin.hunek@tul.cz>
To: Richard Patterson <richard@helix.net.nz>, v6ops@ietf.org
Date: Mon, 01 Apr 2019 14:11:38 +0200
Message-ID: <3278909.DE8sFe37VJ@rumburak.ite.tul.cz>
Organization: Technical University of Liberec
In-Reply-To: <CAHL_VyD3vFBkJ0nC7adM-xitSFAzUN13bV9JUBq9osstrK-C4w@mail.gmail.com>
References: <9101D413-7CEB-4B50-931A-CF30E6501299@gmail.com> <5222213.mTn1hNnrTJ@rumburak.ite.tul.cz> <CAHL_VyD3vFBkJ0nC7adM-xitSFAzUN13bV9JUBq9osstrK-C4w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3941558.1zU8iMPKNK"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/nfPx3ZNbKz2ikdGs03AiIY-iiPw>
Subject: Re: [v6ops] Operational Headache: DHCP V6 Relay
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2019 12:11:49 -0000

Hi Richard,

It has been a while, but basically I had a problem with DHCPv6 server not doing (or providing) routing of prefixes handed out by it.

When I had tested this (with Debian 8 and included ISC DHCP), there was a possibility of doing hook but this would work only if:
1) Client is using DUID-LL (type 3) or DUID-LLT (type 1)
2) Source of calculation of DUID is MAC of WAN interface
3) CPE is using EUI-64 for Link-local address

How ever this is not every time the case. Some operating systems are using DUID-UUID, some calculate DUID from LAN interface and some are even using sort of privacy extension on Link-local address instead of EUI-64. I even had a device which was using DUID-UUID generated on every boot, how ever it should be fixed by now.

My idea for the draft would be a very short document saying something like:

"DHCPv6-PD capable service MUST provide routing information for every active lease, consisting at least: leased prefix, next hop and time when lease expires. Service SHOULD also provide every other information send and receive either as part of any request or reply of DHCPv6 service."

"DHCPv6-PD capable service MUST provide way how to directly insert and update routing information in the routing table of device on which it is hosted."

"Routing information on active leases MUST be either persistent or the DHCPv6-PD service MUST be capable of recovering this information."

"Information provided by DHCPv6-PD MUST be accessible by other services on the same device and MUST provide the way for remote logging."

I will do some more recent test of DHCPv6 Servers and Relays and I'll try to put it in writing. What I understand from feedback I have been getting over a years is that routing is usually fine on DHCPv6 Relays however so far I have seen just one DHCPv6 Server which allows to directly export active leases into routing table.

So we are talking about different things here. One thing is the fault recovery on DHCPv6 Relay and one is DHCPv6 Server/Relay not doing routing at all.

Martin

Dne pondělí 1. dubna 2019 11:57:34 CEST jste napsal(a):
> Hi Martin,
> 
> I'd be interested in hearing more detail about the problems that
> you're experiencing related to this, if possible?
> One of the intentions of draft-patterson-intarea-ipoe-health is to
> detect and recover from invalid state in a DHCP relay.
> 
> -Rich
> 
> On Mon, 1 Apr 2019 at 10:32, Martin Hunek <martin.hunek@tul.cz> wrote:
> >
> > Hi Fred,
> >
> > I would be interested to address this issue, as it is the one I'm also having. But I would need some assistance, as I don't really know my ways around IETF processes yet.
> >
> > Martin
> >
> > Dne pátek 29. března 2019 6:37:25 CEST, Fred Baker napsal(a):
> > > https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastream/, slide 3-4
> > >
> > > What do we want to say about DHCPv6 issues in vendor product and/or services? This headache doesn't have an obvious draft. I think that probably calls for a person or design team to create such a draft for discussion on the list and in Montreal.
> > >
> > > Any takers?
> > > --------------------------------------------------------------------------------
> > > The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...
> > >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops