From nobody Thu Oct 8 08:52:02 2020 Return-Path: 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 F23E73A0E28; Thu, 8 Oct 2020 08:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 KErEkKHUrAad; Thu, 8 Oct 2020 08:51:58 -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 2F2313A0E44; Thu, 8 Oct 2020 08:51:58 -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 098FpqH5017737; Thu, 8 Oct 2020 11:51:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602172316; bh=oVcsI16Juma69mo7evob0dyQZHFzXvX3QabfoG0vMo4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=lAqHb53yfk354T/OGejRFqitztpDgA1RlrddERuiMs52c/xT0Mh5FB7H8KpSTjp3l qcEp1iSgAiqxyVtGUca37tPpnh8yZAYvpCQmZRaFeh7QkCo4in2oiYk7gzCksmoONT ce4KoGGriSiVW/M6pXpYjTkhZRxFPN7uz7enGRftLfM1dH++Xtod+Mf5M6fYGWQq0u 4bUs4Uq5/NCmm+w/Aqx7iyFb3j0MXQuu45CbFicM+Tibj8z4WIbHbch/RzGhMt6O1j K2HAFETot2ZhkKXfqEBE8WxeO/wsHbRUpBHsGc7+F5/RRJq9+05w3rM34Q+nakr0D4 kfCP7bbjStq9A== Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 098FpXeh015025 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 8 Oct 2020 11:51:33 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Thu, 8 Oct 2020 08:51:32 -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; Thu, 8 Oct 2020 08:51:32 -0700 From: "Templin (US), Fred L" To: Jen Linkova , "ianfarrer@gmx.com" CC: dhcwg , v6ops list , 6man Thread-Topic: [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnRHm524iPz3PtEmCznTLyJxcLqmN2bKg Date: Thu, 8 Oct 2020 15:51:32 +0000 Message-ID: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> In-Reply-To: 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: 2B51BD98083E59DCC6C3FB1EFA0521C29C7DAD2C4299DAD804C7FDCD438389482000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [dhcwg] [EXTERNAL] Re: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 15:52:00 -0000 Jen, > What would happen if the *second* device sends traffic towards the > delegated prefix? As that device is usig the relay as its default > gateway, the traffic would be sent there. > If I read the draft correctly, instead of forwarding the traffic and > maybe sending the redirect, the relay is expected to drop it? The way that I interpret it, when the second device sends the traffic to the relay, the relay would still forward the traffic to the client, whic= h would then forward the traffic back to the relay, then at that point the relay would drop the traffic. Unless the second node somehow has a way of knowing that the client has entered into an amnesiac state and then does a malicious "flood-ping", we can expect applications to quickly learn that the IP addresses of the client are no longer reachable. Plus, these amnesiac conditions can be expected to be rare and transient; not steady-state. Fred > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova > Sent: Wednesday, October 07, 2020 6:25 PM > To: ianfarrer@gmx.com > Cc: dhcwg ; v6ops list ; 6man > Subject: [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors reg= arding draft-ietf-dhc-dhcpv6-pd-relay-requirements >=20 > This message was sent from outside of Boeing. Please do not click links o= r open attachments unless you recognize the sender and > know that the content is safe. >=20 >=20 > On Wed, Oct 7, 2020 at 9:25 PM wrote: > > We are currently finishing WGLC for this draft. It describes requiremen= ts 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 a= s 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 routin= g 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 >=20 > I might be missing smth but... > Let's say I have a relay and it's 'south' (client-facing) interface is > connected to a switch. The client AND second device (another router or > a host) are connected to the same segment. > The client gets a prefix, the relay 'learned' (or shall we call it > 'install'?) the route for the delegated prefix pointing to its 'south' > interface with the client address as a next-hop. > What would happen if the *second* device sends traffic towards the > delegated prefix? As that device is usig the relay as its default > gateway, the traffic would be sent there. > If I read the draft correctly, instead of forwarding the traffic and > maybe sending the redirect, the relay is expected to drop it? >=20 > -- > SY, Jen Linkova aka Furry >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------