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

ianfarrer@gmx.com Thu, 08 October 2020 16:16 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 DF5DB3A0E52; Thu, 8 Oct 2020 09:16:10 -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 Zl_iiViBshEy; Thu, 8 Oct 2020 09:16:08 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 7FA713A0E5C; Thu, 8 Oct 2020 09:16:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602173758; bh=z/YxokhOxoGZ1LQ6iYIOzazXvi13XROxeWSYBjgReQc=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=P7mZ6I3wlJ+ubyRQMue0KeL1HOZexPb98Q//M9w60zrZVCdW/Fz/uoTlaCcPcWiWo dSBIQjD8CIcOEbrU8NDZZYX4oB0xl19w+47KYQ3gwscaV3pJdJ42rIoExxpgwKZPsT cUudvrsPWN76/COdagiOCBEgW6RFVj+iRm5/dSP8=
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 1MJE6F-1k5zSX1ALL-00Kcyr; Thu, 08 Oct 2020 18:15:58 +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: <f2a9e0188cd84f52adce279cfb04cbcc@boeing.com>
Date: Thu, 8 Oct 2020 18:15:55 +0200
Cc: Jen Linkova <furry13@gmail.com>, dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D259F559-8528-428A-A9DF-0D9FB07E6BE4@gmx.com>
References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <CAFU7BAT87uhUKZM-G9MjCgtmGbdCwXorP3SfMJm7_Ax7pvwDjg@mail.gmail.com> <f2a9e0188cd84f52adce279cfb04cbcc@boeing.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.3445.104.15)
X-Provags-ID: V03:K1:k5DQHcRjYSBWRLb0FA0Xo31K/gAHUKfAmzsaJI2qy8CNcmqipij kp1hn3qFN7zy/kH2/eEMVSAr/YIzOAsasxfIYNB0v4Z82CaIsk37VdKvzs+/D1zczxNDRRH Gdd44NtkV3iGoB09ceCJTwFrDf7TFjoqJgzF8D+j2UQEkjvTWZUn7BBlHiq+INVNeXhBtQl idyuw3ipgTjKvYXz8xUhw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:jeXRExWMa3U=:zYI9rwwgtcfAJ3qlQgD+Zb DaDdBG1rO1YbKqeXcY43AVUynJtK3mAs3XyBFtg3AXRV2LIiys1ne0x8pWiVCWMSuUain1M8z kvvVLvO8uBQsU5S+rRRow1n+qt40O7JuywPUlwHDetyT5lExX/YQgShBH3TM2OFXDomX2orwD K4TIdsRjagodmza7B/ohn/mPeVRqG/4Q3XNBNetN9P1N9ycVy54J1sRMCaJPJ3HdHx1bWM9ON iwN0Vzos7iU7pCvlRDpmAEdFilY2fyNOZcrlxbAzOCPvYwL9Lh3NGg6z6xOXuDX8d7GT37hr3 7ThIbN1+EUX6KR3y0MAatn4sb6XnoWhosTgRlkNvZSk/ylXJeHWWzI/My4MhmWpRgYnBKhMap 0hCsQzO62iB35JCYuFkUVMz4w3P7un+M7PJ0pzwPpOmMqM2nwRp6Xggvrbc1vVawg9CuYhkMm J5otqFMmcxnWZdJ+H0caC8WnHEI1T6PSQhyrTMJ4LITJlrdHBWcBjCBSo7G2+zwoU5inNTA3k FdTk0EXdZxqtFmuK8D2T7WQB6Z3HFk5qILdU1OKHQozoOobZ+0SrnQ+bCxNacPA7m2qGstt1+ H/KQUdqui+Jl/wl+lH/uov3SVWCCF/v//4u5OY66w4fIlKYQYcWwBCWsBKKKf7jl2qrtfOIhk YhDXP2wcJx3qvxntn2XFzYRb00BGKehyV2gG7JW0vfeqBwJsfILeJObcOYm4+BdAS/47Sdj76 Q7fjE332NJvmTUkTazKSY4VqIsnzcxTXP5rNKHH79OZ7jf1eX9P5KvaNp5m8lD8R6T99jl/l6 Z6AN2QniHpSIhG4sgL443CiWiK20+mofPAAt6oim+BM9f2UZIb/iJtwGpB5V8lNcrJ9h1lIV4 ncrPoTNYJfD9fTAAdIPeIYtayYU11HUEJw9/s9/qd3vp8msYHs5y8F+3KTwLZlvnQIjAEx5fb W5wX5ly91mx7vSJYhhBX5nyi9SE0TTVWpO4Ct42gpuNPWycuJXtlvqPAVx7g3ne/xIRs9K24R COeZx/WgRtyz69mhCYPO5qPNtZyGOqVDnZpwqbJlTPGV2pOkxcEAXZgERryOPEZRuW7qvYo85 NrgRZ+j0cJUtpy3ocChC0GT87qJiUeRYQsbkKhHTnKQpoW/Pv61Uey/2DyHRtuHbg/mNH04fB +Dblo8KpwnyyNqP8h0cBPCeryMctowyR86E9X6sR8OPI/R0akBQ5pgj+jXympEfZey/tbKWeT 3JUOkX5+44M2gDNdbjv+pZ0906jklbIx8EgmQAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/ISlQI-Rv5y19pprxyu0DEh7NoZg>
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 16:16:11 -0000

Hi Fred / Jen

Please see inline below.

Thanks,
Ian

> On 8. Oct 2020, at 17:51, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> 
> 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

[if - If I understand Jen’s question correctly, it’s related to the ‘working’ case.
i.e. the client has completed PD, installed the routes and the relay has
the relevant lease info/routes.

When the second device sends via the default route with a destination address
in the delegated prefix, R-4 in it’s current form would cause the traffic to be dropped.
As the relay doesn’t forward the packet, it can’t send a redirect (per RFC4681), so
the second device can’t forward.

Looking at this, I think there are deployment scenarios where R-4 isn’t going to 
work. 

My suggestion would be to make R-4 disable-able.]



> 
> 
>> -----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
>> --------------------------------------------------------------------
>