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 <mailto:dhcwg-bounces@ietf.org>] On Behalf Of Naveen Kottapalli
> Sent: Tuesday, June 25, 2019 9:14 AM
> To: v6ops list <v6ops@ietf.org <mailto:v6ops@ietf.org>>; dhcwg@ietf.org <mailto:dhcwg@ietf.org>
> Cc: Martin Hunek <martin.hunek@tul.cz <mailto: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 <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:
>    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 <mailto: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 <mailto: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/ <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 <mailto:v6ops@ietf.org>
> > https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>_______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org <mailto:dhcwg@ietf.org>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>