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

From: Naveen Kottapalli <[email-masked]>
Date: Tue, 25 Jun 2019 21:43:48 +0530

Hello All,

A new draft on this subject is submitted today.  Please go through the same
in below link and let us know your feedback.

----

A new version of I-D, draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt
has been successfully submitted by Naveen Kottapalli and posted to the
IETF repository.

Name:           draft-fkhp-dhc-dhcpv6-pd-relay-requirements
Revision:       00
Title:          DHCPv6 Prefix Delegating relay
Document date:  2019-06-25
Group:          Individual Submission
Pages:          10
URL:
https://www.ietf.org/internet-drafts/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt
Status:
https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/
Htmlized:
https://tools.ietf.org/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements

Abstract:
   Operational experience with DHCPv6 prefix delegation has shown that
   when the DHCPv6 relay function is not co-located with the DHCPv6
   server function, issues such as timer synchronization between the
   DHCP functional elements, rejection of client's messages by the
   relay, and other problems have been observed.  These problems can
   result in prefix delegation failing or traffic to/from clients
   addressed from the delegated prefix being unrouteable.  Although
   [RFC8415] mentions this deployment scenario, it does not provide
   necessary detail on how the relay element should behave when used
   with PD.

   This document describes functional requirements for a DHCPv6 PD relay
   when used for relaying prefixes delegated by a separate DHCPv6
   server.

Yours,
Naveen.

On Mon, 1 Apr 2019 at 18:34, <[email-masked]> wrote:

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 26 Jun 2019 15:14:46 +0000

Hi Naveen,

Thanks for the draft – a quick question - what is meant by “DHCPv6 relay function is not co-located
with the DHCPv6 server function”. Does it mean “co-located” as in within the same process, within
the same virtual machine, within the same physical box, within the same LAN, etc.?

RFC6221 allows for the relay function to be in a separate process from the server function but
within the same operating system instance. So, the two processes share the same clock, IP
forwarding table, system memory, etc. In such an arrangement, can it be said that the DHCPv6
relay and server functions are in fact “co-located” even if they do not reside within the same
process context?

Thanks - Fred

From: dhcwg [mailto:[email-masked]] On Behalf Of Naveen Kottapalli
Sent: Tuesday, June 25, 2019 9:14 AM
To: v6ops list <[email-masked]>; [email-masked]
Cc: Martin Hunek <[email-masked]>
Subject: Re: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay

Hello All,

A new draft on this subject is submitted today.  Please go through the same in below link and let us know your feedback.

----

Name:           draft-fkhp-dhc-dhcpv6-pd-relay-requirements
Revision:       00
Title:          DHCPv6 Prefix Delegating relay
Document date:  2019-06-25
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt
Status:         https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/
Htmlized:       https://tools.ietf.org/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements

Abstract:

Yours,
Naveen.

On Mon, 1 Apr 2019 at 18:34, <[email-masked]<mailto:[email-masked]>> wrote:
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]<mailto:[email-masked]>> 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
>
>> 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...
>>
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: [email-masked]
Date: Wed, 26 Jun 2019 17:22:10 +0200

Hi Fred,

In this instance, we are talking about being in a separate physical box, or VM. The problems I’ve observed are with  L3 edge routers with
the relay function in the access network with a centralised DHCPv6 server. We can clarify this better in the next update.

Thanks,
Ian

> On 26. Jun 2019, at 17:14, Templin (US), Fred L <[email-masked]> wrote:
> 
> Hi Naveen,
>  
> From: dhcwg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Naveen Kottapalli
> To: v6ops list <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: Martin Hunek <[email-masked] <mailto:[email-masked]>>
> URL:            https://www.ietf.org/internet-drafts/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt <https://www.ietf.org/internet-drafts/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/ <https://datatracker.ietf.org/doc/draft-fkhp-dhc-dhcpv6-pd-relay-requirements/>
> Htmlized:       https://tools.ietf.org/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00 <https://tools.ietf.org/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements <https://datatracker.ietf.org/doc/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements>
> 
> 
> Abstract:
> On Mon, 1 Apr 2019 at 18:34, <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Martin,
> 
> > On 1. Apr 2019, at 11:31, Martin Hunek <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Hi Fred,
> > 
> >> https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastream/ <https://datatracker.ietf.org/doc/slides-104-v6ops-deutsche-telekom-terastream/>, slide 3-4
> >> 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>_______________________________________________
> dhcwg mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 26 Jun 2019 15:27:55 +0000

Hi Ian – yes, a clarification of “co-located” would be great. Sounds like there is
not a concern when the relay and server are in the same box or VM, right?

Thanks - Fred

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 26, 2019 8:22 AM
To: Templin (US), Fred L <[email-masked]>
Cc: Naveen Kottapalli <[email-masked]>; v6ops list <[email-masked]>; [email-masked]; Martin Hunek <[email-masked]>
Subject: Re: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay

Hi Fred,

Thanks,
Ian

On 26. Jun 2019, at 17:14, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Hi Naveen,

Thanks - Fred

From: dhcwg [mailto:[email-masked]] On Behalf Of Naveen Kottapalli
Sent: Tuesday, June 25, 2019 9:14 AM
To: v6ops list <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Martin Hunek <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay

Hello All,

----

Abstract:

Yours,
Naveen.

Cheers,
Ian

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: [email-masked]
Date: Wed, 26 Jun 2019 17:38:52 +0200

Hi Fred,

Will do.

I haven’t tried that particular deployment scenario. I suppose that if the relay and server processes didn’t share any state information then you could see these problems. Is there a case for running both server and relay functions on the same box, rather than just the server (as a delegating router)?

Thanks,
Ian

> On 26. Jun 2019, at 17:27, Templin (US), Fred L <[email-masked]> wrote:
> 
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Templin (US), Fred L <[email-masked] <mailto:[email-masked]>>
> Cc: Naveen Kottapalli <[email-masked] <mailto:[email-masked]>>; v6ops list <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Martin Hunek <[email-masked] <mailto:[email-masked]>>
> On 26. Jun 2019, at 17:14, Templin (US), Fred L <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Naveen,
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 26 Jun 2019 15:53:53 +0000

The server and relay run in the same operating system instance, but in two separate process
contexts – call them ‘relayd’ and ‘serverd’.

‘relayd’ receives a client prefix delegation request then prepares a ‘Relay-forward’ message
and ships it to ‘serverd’ over a local loopback. When ‘serverd’ sends back the ‘Relay-reply’
(again over the loopback), ‘relayd’ injects a route into the routing system and sends a
suitable reply to the client.

The only reason we do it this way is because the client cannot speak directly to ‘serverd’
and it would be difficult to merge ‘relayd’ and ‘serverd’ into a single process context. But,
everything else is coordinated within the same operating system instance.

Fred

Sent: Wednesday, June 26, 2019 8:39 AM

Hi Fred,

Will do.

Thanks,
Ian

On 26. Jun 2019, at 17:27, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Thanks - Fred

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, June 26, 2019 8:22 AM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: Naveen Kottapalli <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Martin Hunek <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay

Hi Fred,

Thanks,
Ian

Hi Naveen,

Thanks - Fred

Hello All,

----

Abstract:

Yours,
Naveen.

Cheers,
Ian

---

From: Fred Baker <[email-masked]>
Date: Thu, 27 Jun 2019 07:35:18 +0100

I don't see a prohibition of this sort of design, but it seems unnecessarily complex. The relay protocol is designed to communicate from a relay to another relay or to a server. Adding a relay process just to communicate with the server process via localhost seems an unnecessary step.

> On Jun 26, 2019, at 4:53 PM, Templin (US), Fred L <[email-masked]> wrote:
> 
> [email-masked]

---

From: Sander Steffann <[email-masked]>
Date: Thu, 27 Jun 2019 16:16:02 +0200

Hi Fred,

> I don't see a prohibition of this sort of design, but it seems unnecessarily complex. The relay protocol is designed to communicate from a relay to another relay or to a server. Adding a relay proc…

When implementing DHCPKit I implemented it in roughly the same way (although I did it inside a single process). Wrapping every incoming message inside a relay message makes it possible to handle layer-2 information uniformly.

The process/function that listens on the multicast address generates an internal relay message with all relevant information (interface, mac address, source link-local address etc) and sends that to the main server to be processed. The server can then always get all relevant information from the DHCPv6 packet stack, independent of how it was received. Otherwise you'd have to have an extra channel to communicate all that metadata to the server process.

Cheers,
Sander

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 28 Jun 2019 13:36:50 +0000

Sorry if you don't like it Fred, but that is the purpose of RFC6221. If you want more
details of what we are doing and why it makes sense to us let me know.

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Wednesday, June 26, 2019 11:35 PM
> Cc: [email-masked]; [email-masked]; v6ops list <[email-masked]>
> Subject: Re: [v6ops] [dhcwg] Operational Headache: DHCP V6 Relay
> 
> I don't see a prohibition of this sort of design, but it seems unnecessarily complex. The relay protocol is designed to communicate
> from a relay to another relay or to a server. Adding a relay process just to communicate with the server process via localhost seems an
> unnecessary step.
> 
> > I haven’t tried that particular deployment scenario. I suppose that if the relay and server processes didn’t share any state
> information then you could see these problems. Is there a case for running both server and relay functions on the same box, rather
> than just the server (as a delegating router)?
> >
> > Thanks,
> > Ian
> >
> >
> > >> 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?