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

Jen Linkova <furry13@gmail.com> Fri, 09 October 2020 01:50 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A9E3A1258; Thu, 8 Oct 2020 18:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0CUvZ00SVEr; Thu, 8 Oct 2020 18:50:13 -0700 (PDT)
Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4AEB3A1257; Thu, 8 Oct 2020 18:50:12 -0700 (PDT)
Received: by mail-qt1-x841.google.com with SMTP id z33so2958296qth.8; Thu, 08 Oct 2020 18:50:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com>
In-Reply-To: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com>
From: Jen Linkova <furry13@gmail.com>
Date: Fri, 9 Oct 2020 12:50:00 +1100
Message-ID: <CAFU7BARt2jqW+9ASuPAL2dVNQGZ-1RVBmyg0CpJpgjG1ge+s2A@mail.gmail.com>
To: ianfarrer@gmx.com
Cc: v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>, dhcwg <dhcwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/DQhw_1tk8GU0OU2K8-QoZCdV7T8>
Subject: Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=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
(sonehow)?

On Wed, Oct 7, 2020 at 9:25 PM <ianfarrer@gmx.com> 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: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requirements/
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg



-- 
SY, Jen Linkova aka Furry