Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

Alexandre Petrescu <> Thu, 08 October 2020 14:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97D953A084A for <>; Thu, 8 Oct 2020 07:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.458
X-Spam-Level: *
X-Spam-Status: No, score=1.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.213, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wKz8HONFB5eq for <>; Thu, 8 Oct 2020 07:03:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3CE73A03EC for <>; Thu, 8 Oct 2020 07:03:00 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 098E2wJw001914; Thu, 8 Oct 2020 16:02:58 +0200
Received: from (localhost []) by localhost (Postfix) with SMTP id 15AB7205039; Thu, 8 Oct 2020 16:02:58 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 07640205007; Thu, 8 Oct 2020 16:02:58 +0200 (CEST)
Received: from [] ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 098E2vmu024053; Thu, 8 Oct 2020 16:02:57 +0200
References: <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Thu, 8 Oct 2020 16:02:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Oct 2020 14:03:03 -0000

Le 08/10/2020 à 15:33, a écrit :
> Hi Alexandre,
> Thanks for your comments, please see inline.
> Ian
>> On 7. Oct 2020, at 12:38, Alexandre Petrescu <> wrote:
>> There are few things I could comment on here...
>> Le 07/10/2020 à 12:25, a écrit :
>>> Hi,
>>> We are currently finishing WGLC for this draft. It describes requirements for a 'DHCPv6 Delegating Relay' - this is a router functioning as the L3 edge and DHCPv6 relay (only) with prefix delegation. This is a common deployment scenario, but RFC3633/8415 only really describes PD using a Delegating Router - i.e the L3 edge also functions as a DHCPv6 server with no relay. When the relay and server functions are performed by separate devices a number of problems with how relays behave have
>>> been observed, so this document addresses them.
>>> During WGLC for this, Ole raised a comment related to one of the routing requirements:
>>> R-4:    If the relay has learned a route for a delegated prefix via a
>>>             given interface, and receives traffic on this interface with
>>>             a destination address within the delegated prefix (that is
>>>             not an on-link prefix for the relay), then it MUST be
>>>             dropped.
>> 'within' the delegated prefix?  How is the operation of finding whether an address is within a prefix implemented?  REmember the 64bit limit is not frozen and as such a longest prefix match operation might be the only possible; such an operation is however not offering the result one might expect.  Lpm is good for matching an address among a few prefixes, but is not good for deciding whether an address is 'within' a given prefix.
>> 2. there is a new RFC now that suggests addition of an NC entry in router's table such that incoming packets to that Host dont get dropped.  Such an operation would contradict R-4.
> [if - The operation would be via normal destination route lookup - if the dest address egress interface matches the ingress interface.
> Do you have a number for the RFC that you mention?]

Sorry, I meant to say it is an RFC in the making.  It is
draft-ietf-6man-grand-03.  In it is suggested the addition of an NC 
entry, as I see it.

>>    This is to prevent routing loops.  An ICMPv6 Type
>>>             1, Code 6 (Destination Unreachable, reject route to
>>>             destination) error message MAY be sent back to the client.
>>>             The ICMP policy SHOULD be configurable.
>>> The problem that this is trying to solve is:
>>> 3.5.  Forwarding Loops between Client and Relay
>>>     If the client loses information about a prefix that it is delegated
>>>     while the lease entry and associated route is still active in the
>>>     delegating relay, then the relay will forward traffic to the client
>>>     which the client will return to the relay
>> Will a client return a packet to relay?  Or will it generate an ICMP error carrying the packet?
> [if - In the case described, yes. The client has a default route via the relay (learned via RA) so it will send it back to the relay.]

I dont think the Host would forward a packet that it received, further 
to its default router.  It would do so only if it originated it.

>> (which is the client's
>>>     default gateway (learnt via an RA).  The loop will continue until
>>>     either the client is successfully reprovisioned via DHCP, or the lease
>>>     ages out in the relay.
>> I would dare to wonder whether such loop has been seen with a packet capture tool such as wireshark?  Or is it that we worry that such a loop might appear?  Both are valid points to consider.
> [if - I’ve seen this in lab conditions a while ago due to a DHCP client bug]



>>> Ole’s comment: "And I would also be happy if we could have some implementors chime in with a "we are happy and able to implement this requirement”.”
>>> We would appreciate any feedback on this, especially from anyone with experience implementing DHCPv6 relays with PD.
>> I do have some experience implementing relays and server doing PD, but it was some years ago.  The server was doing PD and the relay  just adding a route.  I dont remember having seen loops, but I have not tried the scenario described above (expiration of prefix lease).
>> Alex
>>> Thanks,
>>> Ian
>>> Current draft version: <>
>>> _______________________________________________
>>> dhcwg mailing list
>> _______________________________________________
>> dhcwg mailing list