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

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<mailto: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<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
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<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/, 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

_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org<mailto:dhcwg@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg