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

ianfarrer@gmx.com Thu, 08 October 2020 15:57 UTC

Return-Path: <ianfarrer@gmx.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 A88563A0E44; Thu, 8 Oct 2020 08:57:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.net
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 88Fpo4a1-TIV; Thu, 8 Oct 2020 08:57:07 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753D63A0E2D; Thu, 8 Oct 2020 08:57:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602172619; bh=b2UmeVdzi8ImyU0iOM7w7OnDBH7RIGTTE+Qb3MFPCiE=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=G2Qc94yL4z2Tc85JkBdfIcejKRQQ3eM5l4YiD+gHFFQIc1hBhJh9FsDJW9StVOgyz SZEgY91kxwmajWhkCqGCAuu4QX5iySFe7k3sI699IiXKMJlQ2TQjU51B9DD5Je7eOr WluXXDvClrUQF6+AeOZuPj/xyqwkAEyBRbd2HaRQ=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.128.43] ([87.79.171.64]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MtOGU-1keVbJ1obO-00uoiy; Thu, 08 Oct 2020 17:56:59 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
From: ianfarrer@gmx.com
In-Reply-To: <15177.1602095087@localhost>
Date: Thu, 8 Oct 2020 17:56:57 +0200
Cc: v6ops list <v6ops@ietf.org>, ipv6@ietf.org, dhcwg <dhcwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C8CA95A4-55D8-4397-AC8F-C862C976C953@gmx.com>
References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <15177.1602095087@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3445.104.15)
X-Provags-ID: V03:K1:jrvelnOy7FV+W5phhGlFcswCfyj24jxM4TQsCokFgKBIzueRnLz vNRHKoaiuwSLeOywOwpe8sRKqnPG5DLSRg3h/uqupM70kTYxuij/i+Kq/pWaJN7iszZ48qH roFo3YFMD398P30Nte7Jg0tmuDinTBo81MeAUn5sBNqahLMtRBsI8RnYbBlDNu+aZxG0hGq o0Z2Q/A0kJK2PxMGCL/og==
X-UI-Out-Filterresults: notjunk:1;V03:K0:UrPwX6t/Dk4=:+wPBqjmZY/4SW1nUHtQbsX MBj3O611UE+wd72V1SaGek0VBlhZ80r3opSEzxOEWE1p36Qvt+Bhs8aQASQOnB6J8yiQe1bzd dU2/LJPEu3wHG45xRZqMocZPsJ0mtt1/CcLu9KDHTAXKExBZfYGN5XR9i3XpnleiCnNkKgoKm zEM9VW1Iy28yqwmuU+uQGdUEGlEFO4SDSX+TQvagYwGwfsS9f6btZIJ9IbLR0iTHu2/yKD2TK 6n5Zea4wYziyhY5gYtBokuLlsekDfdv3CqymrT/nbnH7YS6c22I0+0mmbnNl/yv3x0s8zXdKq 9f0iW/kYlC6g3DDcOWlcMYWjl4AcFYg6es2iWisX2tOdWux9f2jUy6YwGbA6eJgyxKkC1SlE9 YPAgdjCYm2bHbW9O/cqqGhzGPRRftsWf6oYcBNQVBxAW0TwDNuuIa/D19zGLSC5SMafor8wzG NOChJLD/niwCJAlQlecA4yvaOp1ZkpFKhwdiDHAXVijRI4AhVyCSMmudLPUqsktK7WUvtf/40 jic1qTCMEpaRD8s/HVQy7BcT9kPz5CRXSdYKpSNpzZsILydHXxS9VBvk8KeNQ7PdWNsB1OHbG wg/97b9YJ8yDg+vsxRq+/2qHRTB8wzje5Z3FMY08GQOfC3dEUfCCfFop7Rt8vwSv1jUPG1gyL JeuV30iDns06aWc/oKtbnF9Q9gX1Svsq4Nm4qtPQJ6G8Sh+Y856H+gQ3WrUjIBVsDkrU6Qzds +FjOxwDZngK5s5/1Kw4w0C8WFggmhR7+X89BfE2ovnj4QsUCJ/B/LZlinJHN/d1lWKGVwBerj ikIHzK01T8qai1A/TuOY4UaJDPxT1VThL28b0vk+mwTU6MPWoKLvipxjPl6JXdrlaBPRmH0tW nd5Stql78xbfV/HRUfVQe5jZwTvC79wvpAcLHVFn4HWGpHollEpHatLs1uyzE/do1TiPXiN7h JMvPICi7z8uK7Nm7wmANXqrZwyCskHTNfx0EJ/Ef9dGADIrbpsD/e8cjUPfree01+bLtolUY9 G1PLlfMap6QjVP0sJvtSkmcPU2Y+twvFRn5hrThfA5cdH5U01Pnst4gTjL7uFN8NjNEWno/tZ vBTcS/WiBjyvS5z+u0PvERhcPdJBNXMh4/hV0aSirmaXPmTrmN7+piI8zdRY3N0F2TDnsAeZC pOBxvFkuCiOq5ZVxY19Obt8M3kDJXFxC/aYtA3xL5vingIeZHgWWvBry6wKfhcRrijsr7A+7f ZkfnXKOFhjT6KsfaGVxOZB09lkqStnWSzHOaEYQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/lkazxGvxshYM29hf0ULhs0pPcCA>
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: Thu, 08 Oct 2020 15:57:09 -0000

Hi Michael,

Thanks for the comments. Pleased see inline below.

Ian

> On 7. Oct 2020, at 20:24, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> 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.

[if - We didn’t consider this scenario but it could certainly be a problem here. 
Do you think that the current problem description text and requirement 
adequately cover this case?]

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

[if - I’m not sure how that could work. if the relay isn’t aware that the client’s DHCP
state is out of sync with its own, how can the server know this to tell the relay to
blackhole?]

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