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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Thu, 08 October 2020 15: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 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" <Fred.L.Templin@boeing.com>
To: Jen Linkova <furry13@gmail.com>, "ianfarrer@gmx.com" <ianfarrer@gmx.com>
CC: dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
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: <f2a9e0188cd84f52adce279cfb04cbcc@boeing.com>
References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <CAFU7BAT87uhUKZM-G9MjCgtmGbdCwXorP3SfMJm7_Ax7pvwDjg@mail.gmail.com>
In-Reply-To: <CAFU7BAT87uhUKZM-G9MjCgtmGbdCwXorP3SfMJm7_Ax7pvwDjg@mail.gmail.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: 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: <https://mailarchive.ietf.org/arch/msg/dhcwg/_3FONr9kRbL04T5p3yqM1eytvHU>
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: <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: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, which
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 <dhcwg@ietf.org>rg>; v6ops list <v6ops@ietf.org>rg>; 6man <ipv6@ietf.org>
> Subject: [EXTERNAL] Re: [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.
> 
> 
> On Wed, Oct 7, 2020 at 9:25 PM <ianfarrer@gmx.com> wrote:
> > 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
> 
> 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?
> 
> --
> SY, Jen Linkova aka Furry
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------