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

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:fredbaker.ietf@gmail.com]
> Sent: Wednesday, June 26, 2019 11:35 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: ianfarrer@gmx.com; dhcwg@ietf.org; v6ops list <v6ops@ietf.org>
> 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.
> 
> > 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...