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

ianfarrer@gmx.com Fri, 09 October 2020 11:18 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 D5A453A0DDD; Fri, 9 Oct 2020 04:18:25 -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 uD2k8HQGms8T; Fri, 9 Oct 2020 04:18:24 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 99C4B3A0D52; Fri, 9 Oct 2020 04:18:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602242289; bh=tQ/XCG6pniOhv9VSc1j9BU3/VnZDm1XMy7bXVE01M0g=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=UUzPFxEMqWSfXeMNBqGWbqR7mSn9WZUniVyiV+yIpcwhnjL/HTwTlYjaaH3KK0+jM 93BZx/RXLujSqb7h+22LEgUjZrc146tQZflYqBMmWqyifH/2ej10+9koYBYdynSaFf iY2h3jaARCrHLWra6dOY9PXD4SdjbpLENWxuVo50=
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 1MsHs0-1kC4Nv0akM-00tnNY; Fri, 09 Oct 2020 13:18:09 +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: <e6a27b2d0b5649bda13ee513f6a3a2e2@huawei.com>
Date: Fri, 9 Oct 2020 13:18:05 +0200
Cc: dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B57D44EC-4523-41D8-B6CE-3FD65ABC680E@gmx.com>
References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <CAFU7BAT87uhUKZM-G9MjCgtmGbdCwXorP3SfMJm7_Ax7pvwDjg@mail.gmail.com> <e6a27b2d0b5649bda13ee513f6a3a2e2@huawei.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
X-Mailer: Apple Mail (2.3445.104.15)
X-Provags-ID: V03:K1:mS/nJGmsivGITz5Wu7oFCYrontv8wOR391JWBFFDk1hwpaxOK9G OK69HBwRhNAZrqzr5pScPbxeK8WR6w8FeJNJIg5EJtILrbIxOgQGf/IltjZtWfL9O6Lc0Yv ssV2xuOZ3vWxj7kIhEpT2o+uvnYxg+sNSJK8SG9i8kImvc73tvYFpGPo4EgooeP+6WrR2DV I0U6yWRBzFhKqW+5vwtwQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:TANwVFEmSic=:7kpTjt4jKkN4GuZoOD7klM k02DMUbIg/kT8woHECBZRQH+dk31Zl+qydICbalJT5O799/JONJJmnHKCVeZb4p+qJ4qStWqO V1xU8Ks1L/2ACHMAisNcAPuacz4EQdy0Ll6gkMaefKuGHHrqxg2zcz6ehVWPyhwa/tQrmg1lw 3Kkiny+H/YXJ121Zxru+9eNO19/i+ikmY9MUrIqx150KmdINb0IWjhVEzrHaGNmmtpUuZdAWw NWJ9KMLWSRkGBJT4XcqIDxwJBsG9B4G2oefQ528DvaPu3mGxf7CmL5sE+FOAUMe5pmbNHfYa+ 9gcn1KY43Taf+UlmQslxVumAb7llVNRX/j2UibI4nuzna6xyT6ezAQRMF64U7u8fGSitsJVhW YXhZm7dGWA1f1ZxByagGzqXQ5BT5ngNuqwjYw7nSkVVkLPjLip46dIiKjK+FsUIZ0n+SwYXlP iDpLNBpt3dzw1whVSHK8M4rUEz2+gWw/AC7GFLfQKaUfXxc/kgQac3hBjJQCBenncvO0/lgVo CAzaprkbS0MfcmbVIopWkoT7PyKjB8MRG7McK47O53nqZmk7xN6hPYfMy39mFlJaog3w420m2 I/QlaJFchjyLB+FfPqM1X7v7f699f3GPTG7iEU9yjkMzUxzieVUTz6BfVEIweNZZ7bqnPOctK wN02iUn9CPFMtmHDpEjCCWYnMuj0qthXoj//Lm45pDPGV+7HTzfuxqlIKorKwdkR9f8UIQepu XO5deT7Pm/GLACWeljVMH24D4pleM2I7/IOWq2Qm9KUs2u6K+y8hsIm/JuJJI0U7fGEjL+kAg 3/td+THc8slGoPH3JACC95aixaPbPe1m+uHWqqHBxLi9CErB2/EDj37TwQwZ04q8HC2dzOcOW Khleq3qeisBCrpPsfsZObKQex7u9+Tv7J6cUV9zwsHwvdehFOVLijPa0S4f2EUfQQnKpyK5/h hbs96eAUPFT+nrxwCzjfaWaD48r29By/dLs6Rj5h1Dr2zhjD5fYNqLUAB1trma1H27cihEaP5 DuHylfEafODqSWusphXXniH5Mv4COQdgrWaS3HRnWoelFM9nFrMjXd9mF+nMJ8D4K5FKMgI8R lIUjqRDNC+lArlJbrHNuP9z0iOqypuiO1L+nS+FzcZWSK2ow656fJEoSPHbmI2Y0IsS2YZmIh Bdu/XYtPTBfNZYGfdDfDA4V9YgBhX/keqiZJ55N5prrxWoVUckFKd9HyfO6R/4PAmPjr8bT8P EZ+z1fx5vWYFbSi7A134IYfV/TU/j4D21r9QRPQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/6EYrPRRTnCkyiFw2D4mCSXET-H8>
Subject: Re: [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: Fri, 09 Oct 2020 11:18:26 -0000

Hi Eduard,

Please see inline.

Ian

> On 9. Oct 2020, at 11:57, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
> 
> Hi all,
> I believe that the current text behind requirement "R-4" is not accurate.
> it is not possible to install the route to just multi-access interface (Ethernet). Any vendor software would refuse to do it for the good reason.
> In that case, it should be not interface, but "next hop" (MAC address should be included).
> IMHO: requirement should be improved: "Interface" should be replaced by "next-hop”

[if - Good point. I’m reworking the requirement text at the moment, so I’ll incorporate this.]

> 
> Then it would be the real challenge to check that traffic has been received from specific MAC.
> It is not uRPF check, because RFP is about IP addresses only.
> Moreover, filtering should be done on the "destination IP" & "source MAC" (logical "AND")
> I did google a little - I have found no vendors implemented RPF check at MAC layer.
> Hence, this requirement is the strong new feature request.
> Probably, it would be ignored by vendors anyway.
> IMHO: if you could correct it to "nex-hop" then you would keep this "good wish" in the document. Just change "MUST" to "MAY”.

[if - As the requirement will be changed to a configurable policy, then it will become SHOULD.]

> 
> PS: Yea, DHCP is not routing protocol:-(
> Eduard
>> -----Original Message-----
>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova
>> Sent: 8 октября 2020 г. 4:25
>> To: ianfarrer@gmx.com
>> Cc: dhcwg <dhcwg@ietf.org>rg>; v6ops list <v6ops@ietf.org>rg>; 6man
>> <ipv6@ietf.org>
>> Subject: Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-
>> ietf-dhc-dhcpv6-pd-relay-requirements
>> 
>> 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
>> --------------------------------------------------------------------