Subject: Re: [v6ops] Operational Headache: DHCP V6 Relay

From: Martin Hunek <[email-masked]>
Date: Mon, 01 Apr 2019 11:31:54 +0200

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

---

From: Richard Patterson <[email-masked]>
Date: Mon, 1 Apr 2019 10:57:34 +0100

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 <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Martin Hunek <[email-masked]>
Date: Mon, 01 Apr 2019 14:11:38 +0200

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

---

From: [email-masked]
Date: Mon, 1 Apr 2019 15:04:15 +0200

Hi Martin,

I would also be interested in working on this as it’s a problem for us. I’ve got something I wrote a while back. I’ll share it as a starting point.

Cheers,
Ian

> On 1. Apr 2019, at 11:31, Martin Hunek <[email-masked]> wrote:
> 
> Hi Fred,
>