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

ianfarrer@gmx.com Wed, 07 October 2020 10:25 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 AA58F3A0870; Wed, 7 Oct 2020 03:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 b6rxK_rQCpdD; Wed, 7 Oct 2020 03:25:44 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 6E5883A0898; Wed, 7 Oct 2020 03:25:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602066342; bh=fve7NsAI9YWcUvD6g0BTrbvIBk2vzVWFKsxtlvoonWs=; h=X-UI-Sender-Class:From:Subject:Date:Cc:To; b=g3wlBFy8CQSGYXYP7LjDPFQQurqLb9CzgNWxdQAa45B/i/kbINKGaC/KH4qkFn5IB BNv4b++Dm373RNd4VtNLPM1ByTk7C9Yr5xjcUDqiGegkyAnsFZrE09tNQ3TAqTjLtw 9MdMBZzokUXF23wpaGZaEOixvv1xlj56ORH0cj4Q=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.128.43] ([87.79.171.64]) by mail.gmx.com (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1Mkpav-1knNQg437H-00mGmm; Wed, 07 Oct 2020 12:25:42 +0200
From: ianfarrer@gmx.com
Content-Type: multipart/alternative; boundary="Apple-Mail=_C5BB3F12-51F9-4428-82D3-9625B9C870E2"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
Message-Id: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com>
Date: Wed, 07 Oct 2020 12:25:41 +0200
Cc: dhcwg <dhcwg@ietf.org>
To: v6ops list <v6ops@ietf.org>, ipv6@ietf.org
X-Mailer: Apple Mail (2.3445.104.15)
X-Provags-ID: V03:K1:Tq4ZaDYRAXB4u5Ub+YO4dfxT97lgonWz0zofiWCTtwKOvSkEmLk bBdV9/3KlQX56jFbxUnLtFW6mLcoPG0M0PAO+mj7mudskULNX5rDNYUx1PG7WlStm/nDPb4 jsc4UrSFW6ojHttF82ps9VbWdCGrvevUJnWKLYTadhFDffrs9qHLipuk8HuL3GBiFEE65W1 XtqWj1ALFEJdtRFbudt6w==
X-UI-Out-Filterresults: notjunk:1;V03:K0:NStZugTVbKg=:F/5+UBemrCgWNxj6zD7SOp lNvmh2HdQnM0AHfL9GGokZOQ/4cNIQXeKw2IB/ughwcJWEeOsjkTuMlrQa8WkCpOVMdDsxkR0 MlBrO8HcdwZlq4oHdgrZZpoH+NnfDtiz4zLrDzDHmn4LOUtMIVev9Gl05LK2lPFiAtKjI9Obo rjzBLxq0IOfoQE9n7uJBxKuAivNH/V7SZsXfxR5emWL1H4o/sGMkeo4hTZnrSylp5S/694NF8 dJjyAD3To5n2/5FRI8gIQHXRz9j7GdG9vaG8XNIb8XNm/JQPUFnomMUo+liF6kAFsWSAJLneM Jyk9P9vnaNU0j+c3ucUfbGVR7N5gaE7mQ61DLaNsG56O8kTFfJM9MdEXinMyo82DRgOfFzvjN dKsJbN1julUgBSDVto5aZXYPVOJgzW26AJ563ElDbHrWDWcDbiSueakljlvEQm9m9IVabD2JB 9hqtJWgFmr0crdb4rdozS24XgQvYmO6nLVXnl+WfLuANVvXS9zODTgn9ATQzYGzyi8GxKP+f9 q68Poy1fJQzLud2Oz72wn/uT9h6jMKpAkIEMJiX2P9zpmZCz/lHdre0XyIRaL4FAcYNHQ6S56 Ep2eQqGcYvEyHtkovPrsglb06uBN0geDx1U2bJFzTrNcS0UsKgAVy8fCnVVUBirYwKZSYhPOT 942b4lF0cA1cPo82azSSjP8zS3mfY+J75CZBfwC3WKoaY5seyNv1Mk1lApmyI+YD9JatBuEoj YMz7qo6EOJiTELKggzPcnbA5BQPizTRkD0HYJg/EJErBQpf7Nz0rFvDdvEQgKZuvSfUx8UXGA nW/+sm3hVaDjFxBfCvuN6Yly1rfupMHpJCemRmPkqXt/sJCm0DFOqUDn1t1i33WOsZKRJ7UwR TULCFdJxFYZI0gwug16p7vKwQrH9cFddxGbTzY8uLOhRMjnCM3CpaFP8i2DLlMYpWCQwKyWgE 6Ywdc7L17H6iB77OYSLDKzPJkwBwO+drv4sf489T294CTwQxF84T/nCiWNNAx3aFfZKX99BWl fCKongNMP/pdJo8w5/stppxXHawsRWwy2sQSp7ullipkh3FeoliGpb4AESsoBf/jMgPCuvoe4 K0sdvm5UQK62FqmWBlEU//aQ3i96SpyER8PHigsW03ZZngovrx0Q+CiSPmJ5a3RVH7uhcM1SQ eKYR6MG0w5r4mW7EZPSnR0Ox9EvXtRv42+3BSy2/BcQLKExIBhqhsJJxXcuW47wZwae39IT6K bXA2WqrYrksMCiqJSK40vwV4ki4E2gNRYa6//Xw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/gPF42aVmcPnCetwnANSUqlaQFbc>
Subject: [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 10:25:47 -0000

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/