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

Jen Linkova <> Fri, 09 October 2020 01:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21A9E3A1258; Thu, 8 Oct 2020 18:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e0CUvZ00SVEr; Thu, 8 Oct 2020 18:50:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4AEB3A1257; Thu, 8 Oct 2020 18:50:12 -0700 (PDT)
Received: by with SMTP id z33so2958296qth.8; Thu, 08 Oct 2020 18:50:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OdisY4lM7E/UzCy6px0wbnUAxaXK+2Ioy/S+bcu4fJs=; b=LAhDqr6vt6IKO+kDHJueqMS04t+gKOWgg4az43KGe/bRP0P8KFeq+VdN/RrFMKP3nR ndpfrDEO0XqHchJLEZYTk86aKJQZjzCAENmHhf92OCvEKdHUH+0DU5WuIONWl5ZfOn/f V4l31BQWbeWDrQ2CZ0CzKpKe33oTez303DEnn/rR+rMZu8DVy96QTQt2W+u61nWH60im n73WyuiG4GP8OrhUCMZOHZnBnRJGAWi/1D4hY5Cue7TjsZjeMywiV0a4SaOYe9Y+/wDz 4Lw9EgoeVepkKJYhQUEzH7pAG0sJ5DcpHG6iBWGHBRvCYpDAaCZjpsH+rYrkA8gPMx4q Hmmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OdisY4lM7E/UzCy6px0wbnUAxaXK+2Ioy/S+bcu4fJs=; b=IB1qpqCJBO2+n0vY0d8KFGQ3gocgmOZez1FHqQ6pzQHzTCl0jbyko+xKqjOlJBd3Iv z46XKxmr0HPt3yVYVjOuT49IEt/3johWCHYQlIDJ28JyuBbmf7938/BNcjb9AI4jZ3N6 KKD7Y//oYS8jyZICZX6S6I+bLba5AY5V1TbwNUZ4PpCbP/L3EV/uY8aysVItly5bp+uW vGhNUnAqYlrpguQjTQ3odfIyh6J4N8fwX46afKrhkvOizTmakYHIbBSeNAjLue657jve G4j53DSdyEomkXcTCr0NTw/5hPO4R9kvZX7uoNRXhQ5n1NW1cZAkwOY2mGux+Umjo5ze AO1Q==
X-Gm-Message-State: AOAM533fRu1FTy0ebArutGDWkf8Avaws7vzU9HrZenNKDt/eU2cuygon RH6MkPYbRyOrcSSou6d5FQScGM0kXkqF0FR7Hjg=
X-Google-Smtp-Source: ABdhPJxbyfZW9CYb8v4vYM09+1mRULPjsnxXlf/mOwbJkEPdJQh+hRoui5UA8NU7ARjWOTcDKFUAmRE7+3RraXsXK4o=
X-Received: by 2002:ac8:1923:: with SMTP id t32mr151648qtj.384.1602208211683; Thu, 08 Oct 2020 18:50:11 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Jen Linkova <>
Date: Fri, 9 Oct 2020 12:50:00 +1100
Message-ID: <>
Cc: v6ops list <>, 6man <>, dhcwg <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Fri, 09 Oct 2020 01:50:16 -0000

Actually it looks like this requirement is another piece of the
'renumbering from one PD prefix to another' puzzle.
SLAAC renumbering drafts are solving the issue of 'a DHCP-PD client
forgot about the prefix but connected downstream hosts are not aware
the prefix is not in use'.
This requirement is about 'a DHCP-PD client forgot about the prefix
and the upstream router/relay is not aware the prefix is not in use'.

Maybe it's dumb idea but is there any way DHCP-PD can be improved to
help 'amnesiac' clients with 'total recall'(c) and signal the prefix
disappearance both downstream (via prefix deprecation) and upstream

On Wed, Oct 7, 2020 at 9:25 PM <> wrote:
> 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.  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 (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.
> 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.
> Thanks,
> Ian
> Current draft version:
> _______________________________________________
> dhcwg mailing list

SY, Jen Linkova aka Furry