Re: [dhcwg] [v6ops] 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.

> On Jun 26, 2019, at 4:53 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> 
> 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
> 
> From: ianfarrer@gmx.com [mailto:ianfarrer@gmx.com]
> Sent: Wednesday, June 26, 2019 8:39 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Naveen Kottapalli <naveen.sarma@gmail.com>; v6ops list <v6ops@ietf.org>; dhcwg@ietf.org; Martin Hunek <martin.hunek@tul.cz>
> Subject: Re: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay
> 
> 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 <Fred.L.Templin@boeing.com> wrote:
> 
> 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: ianfarrer@gmx.com [mailto:ianfarrer@gmx.com]
> Sent: Wednesday, June 26, 2019 8:22 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Naveen Kottapalli <naveen.sarma@gmail.com>; v6ops list <v6ops@ietf.org>; dhcwg@ietf.org; Martin Hunek <martin.hunek@tul.cz>
> Subject: Re: [dhcwg] [v6ops] Operational Headache: DHCP V6 Relay
> 
> 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 <Fred.L.Templin@boeing.com> wrote:
> 
> 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:dhcwg-bounces@ietf.org] On Behalf Of Naveen Kottapalli
> Sent: Tuesday, June 25, 2019 9:14 AM
> To: v6ops list <v6ops@ietf.org>; dhcwg@ietf.org
> Cc: Martin Hunek <martin.hunek@tul.cz>
> 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.
> 
> ----
> 
> 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, <ianfarrer@gmx.com> 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 <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
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

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

Attachment: signature.asc