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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Wed, 07 October 2020 13:51 UTC

Return-Path: <Fred.L.Templin@boeing.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 D73883A08CB; Wed, 7 Oct 2020 06:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=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=boeing.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 pAYnq9EgwuzZ; Wed, 7 Oct 2020 06:51:06 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 C3C423A08C0; Wed, 7 Oct 2020 06:51:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 097Dp0RO017158; Wed, 7 Oct 2020 09:51:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602078663; bh=XqAnICtJQnBFKb39rCGyqCueopnwIHUVXLNizm+5B40=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=UG20sQBmxV4GMe1T98YRrJPdgXBdmdOdSoo1e52vs4g/s9kNmkHtZ7YJ60z/IIaN9 dvPkW/Hvr7isKiDCFRqy3PuPoo2wTp3WSkx9kIizwXuTFN5R5yx7AFrI2vFS/dN4x7 Yjre7qSP5vobRHEeGa2bYlNtPuw4FYHIF5quWcPFr6mLBSYUHCTBSt7FyBV5KBrSOM qpO68joZquBIleZFpRY3upmWX7tsQtfbzuz9LPUoC3dK5B/dHdlXUmoJIspxlxOASo L6kEzZJQEXEME9hoHBe0VPZXxTC1dnhQplbKxHfG8jJJwMtmplFd7fsCdnAPinG/cp YJcQo4SH3Tdig==
Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 097Dokba015676 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 7 Oct 2020 09:50:46 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 7 Oct 2020 06:50:45 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Wed, 7 Oct 2020 06:50:45 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "ianfarrer@gmx.com" <ianfarrer@gmx.com>, v6ops list <v6ops@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
CC: dhcwg <dhcwg@ietf.org>
Thread-Topic: [EXTERNAL] [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
Thread-Index: AQHWnJRBX3LaGeDRlkqgw1RNqcRYtKmMJ/JA
Date: Wed, 7 Oct 2020 13:50:45 +0000
Message-ID: <bb7c15dd4ba04730bd062a03861827ba@boeing.com>
References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com>
In-Reply-To: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 1AA45496FF24051883B1D36DC5CC29E53495E6A35C72910E80B10830694F4BA22000:8
Content-Type: multipart/alternative; boundary="_000_bb7c15dd4ba04730bd062a03861827baboeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/PSJrad9OEHn8cCjqXyFh6PSM8ls>
Subject: Re: [dhcwg] [EXTERNAL] 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 13:51:08 -0000

We implement DHCPv6 PD on relays. The relay is always co-resident with the
delegating server and behaves according to RFC6221. Are we covered?

Thanks - Fred

From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of ianfarrer@gmx.com
Sent: Wednesday, October 07, 2020 3:26 AM
To: v6ops list <v6ops@ietf.org>rg>; ipv6@ietf.org
Cc: dhcwg <dhcwg@ietf.org>
Subject: [EXTERNAL] [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements


This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.




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/