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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 07 October 2020 18:24 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 9DB963A09E7; Wed, 7 Oct 2020 11:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 7aQtpoArjJ49; Wed, 7 Oct 2020 11:24:49 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B5F3A0A07; Wed, 7 Oct 2020 11:24:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7668B389E2; Wed, 7 Oct 2020 14:30:11 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nbBs77CnRzz8; Wed, 7 Oct 2020 14:30:10 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D3AB7389DF; Wed, 7 Oct 2020 14:30:10 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 19022F5; Wed, 7 Oct 2020 14:24:47 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ianfarrer@gmx.com
cc: v6ops list <v6ops@ietf.org>, ipv6@ietf.org, dhcwg <dhcwg@ietf.org>
In-Reply-To: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com>
References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 07 Oct 2020 14:24:47 -0400
Message-ID: <15177.1602095087@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/StUsZBaH7V4RD2fHcKj-oRFsVh0>
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: Wed, 07 Oct 2020 18:24:52 -0000

ianfarrer@gmx.com wrote:
    > 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.

I browsed through pd-relay-requirements, but I didn't know it was being
worked on.  (Did I fall off the dhc list again due to outsourced spam filter? Probably)

The document was seemed clear and direct.
It may be that it could explain more about the consequences of failing to
take some of the advice.

    > 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.

My BMS implementation (2014-ish) had a DHCPv6 server listening per PPPoE connection.
BMS/PPPoE operators often don't have DHCPv6 servers, and adding one isn't
something they want to do.  Making Radius run is hard enough....
In that context, the client can't drop without killing the PPPoE interface,
which drops the route, removing it from the IGP, etc.  So despite having
implemented, my experience is not particularly useful for you.

But, I'm very enthusiastic to have DHCPv6-PD be incorporated into hypervisors
and LXD and Docker, so I hope the problem you describe will be "common".

If a client goes way and does not properly restart, then the NCE entries
associated with the routes will be invalid, and the traffic will be dropped.
While the client is starting, the NCE entries will become valid, but the
client won't have the state.  The traffic will loop.
This could become a serious problems, particularly if the traffic loops at
very high speed, worse case, causing the client to fail again.

Best case, it goes on for a few seconds, then the client perhaps a DHCPv6-PD,
gets delegated the same prefix and everything is normal again.
Perhaps for this reason alone, delegated prefixes need to be stable across
their lifetime.   Perhaps that is obvious, but there are many flash
renumbering discussions...

The concerning case is, I think, that the client comes up fine, but declines
to do a DHCPv6-PD for some reason.  Maybe the option was turned off and the
CPE device rebooted.   Or maybe it won't do the PD until some event occurs,
like some VM gets started.

It seems to me that we need some additional protocol where the relay can be
informed to blackhole the traffic by the DHCP server.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide