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

ianfarrer@gmx.com Thu, 29 October 2020 16:24 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 45B233A07E6; Thu, 29 Oct 2020 09:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 W5MGC00DDUfP; Thu, 29 Oct 2020 09:24:15 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 A75383A00C9; Thu, 29 Oct 2020 09:24:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1603988645; bh=+9VUI4kR5m1joxLAQOpi+IiPQZ76YpN6TCIZiPmusuQ=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=SyOLkDiit4rF8jV2zF06GBe9LTx7+Yqi68YuMkpmDHAN8ibGKRcoAvPMDWMw+N5ut N0EVbstIZ72K9IFJ7DPPVMKXN9WWB1o1I8AJNncKk/OhOuUyJ9BoqU4+Zw9BNqrMzV /n6+eWvEITHSgZdjOuckb8UpK/v95Kcu30EMNTMg=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.128.43] ([78.35.231.242]) by mail.gmx.com (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1M26rD-1kWEua02jR-002ZlF; Thu, 29 Oct 2020 17:24:05 +0100
From: ianfarrer@gmx.com
Message-Id: <BCD1B4F1-32F3-4ECB-8A97-C4E58D746F22@gmx.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_18A64C07-EA05-4998-A2EF-BD9727C302FF"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 29 Oct 2020 17:24:02 +0100
In-Reply-To: <CAFU7BARy-GFLDx=jRPu8Mst_Lc9fVRNTMT1MxOpEKqJ+qq9oaw@mail.gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@ietf.org>
To: Jen Linkova <furry13@gmail.com>, "Bernie Volz (volz)" <volz@cisco.com>
References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <CAFU7BAT87uhUKZM-G9MjCgtmGbdCwXorP3SfMJm7_Ax7pvwDjg@mail.gmail.com> <f2a9e0188cd84f52adce279cfb04cbcc@boeing.com> <D259F559-8528-428A-A9DF-0D9FB07E6BE4@gmx.com> <BN7PR11MB2547029C572CB32F3C593AD7CF0B0@BN7PR11MB2547.namprd11.prod.outlook.com> <ff36a6d9f0834b5bbf331c6c40df16b8@boeing.com> <A0B74F43-07A4-47C2-B773-3F2071CFCED3@cisco.com> <CAFU7BARUKw_c2c9+3k9kJ0UqrATTruGKPGkVb5NPTo=vspb0NA@mail.gmail.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> <BYAPR11MB25496B31F581D4E32D46542ACF040@BYAPR11MB2549.namprd11.prod.outlook.com> <CAFU7BARy-GFLDx=jRPu8Mst_Lc9fVRNTMT1MxOpEKqJ+qq9oaw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:rqvgvSzKjVDNLsOXqJ+gRWILOqxgUXyOKSC6v2/Yw3bwEtMFgKE jX4Z/WtkrugX6u8EIJQ8suUUCHRfCxwU7fjb2Zg90qIbLqh5pMGAfT52j/hGqn94HDgodQd GgEIcqmB9W7VKuN47euBVXbIP+JFJ7ofAyI9dMPjkIEJgkbjsK0jDf5L5ybxNx77V2rg3r5 z+By3IzhUPYIu8PEbE8WQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:t33abuAGv1g=:aVp2/PCKl/QA0fSArFhX03 lA0F4kaTeF5TD2VV8qRxj/rtRXMAc9EzdH/GWg3yXK2MryxtPN1xb803ANI8KPDmzkiF4GVsl eg9LAP/g6//5/4Q9MdVTYWwzT8/KO7mv9u8ZpVythOgR1OxHhympmll8BmPmH5ctduOCi9+lS i3n8rNwqQFzq8mIqwPPVzh7aTNsvl062jidlj5e6TsETbyEBYVhPx0/LuIxvIkhdlKH0K6174 yTVFkKr3a2ZSLJWIg+wGGo5DAb+nZtU1iAoXb+NlCcrO4GQH2XxgXSeM1I9/hH7qrMfAMxG78 ArFlpr5xt4qnNq/a5yfJdKhNlH0ULNLRrDjeJNFXAzowyRtjB72ZCGTjUkY0XtzSgYQpbNUn9 k6Jbjwr2zwqQUIJiJj8SffVszUIVepRqgh8XIGr0t9OYtWQDuiRPsvOb0Snfi2Dl4+6HCtSrG R7wXrbL/lEaaMdHikFpr+YbERAFtFtoBtDvdiiTS505mV7KIpp3myIDDAm0IAU2Gwt786FZlh xzFRCcaYdwRIDxHstHxu0lIIozibp3clwIBzJ2kqogjXTTMtTunVNFT7DLBwK87CTk4UN9h6B UaJ0c2/xMsM3TLdpL5M9wgflG/lFvwCgH0lvW3og6Q/fUP83CUwR2zGylduykIf3BFpJ0BB3b /svUjFwMcGsuqfxplaAIaiPjE1ktahZ5vgAu1KUccks35X+viysN6TNBXJxGYFUcHMvmSiYCP A7/wdcfS3WHd4q4XXA13IJqD4tNmnLjh3t0E+2aogQSz1SfYSXOa/Og6DQtjZ3Rh+qj7nPg5e 47TaaPYGYyW+4097SbUI+5rQ4PugHIUczuNRqQ5NPw3S/YhW387vvbCzAu/9KaZr+Efr6Frod 8uCmWrlLH0WOsqXq2Ekg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/Y5ZmVJFxRbCMuZ1fSfzqkL74uDs>
Subject: Re: [dhcwg] [v6ops] [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, 29 Oct 2020 16:24:17 -0000

Hi,

Sorry for the delay in reply, I’ve been out of the office for the last few weeks for various reasons.

Here’s a new wording proposal incorporating Jen & Bernie’s suggestions:

R-4
To prevent routing loops, the relay SHOULD implement a configurable policy to drop packets
received on a DHCP-PD client facing interface with a destination address in a prefix delegated
to a client connected to that interface, as follows:  For point-to-point links, when the packet’s
ingress and egress interfaces match. For multi-access links, when the packet’s ingress and
egress interface match, and the source MAC and next-hop MAC addresses match. An
ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to destination) error message MAY
be sent as per [RFC4443], section 3.1.  The ICMP policy SHOULD be configurable.

Thanks,
Ian

> On 15. Oct 2020, at 03:51, Jen Linkova <furry13@gmail.com> wrote:
> 
> On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) <volz@cisco.com> wrote:
>> If not, perhaps we just say:
>> 
>> R-4
>> To prevent routing loops, the relay SHOULD implement a configurable policy to drop traffic received from an uplink interface as follows:
> 
> I'm not sure 'from an uplink interface' makes sense. In the case of a
> routing loop caused by an amnesiac DHCP-PD client it would be a
> downstream interface.
> The scenario when such traffic arrives from an uplink interface is
> 'the uplink router believes the prefix is delegated to the client but
> the relay does not have a route pointing to the client so it sends
> traffic back' - so more likely 'an amnesiac relay' case.
> 
>> For point-to-point links, when the packet's ingress and egress interfaces match. For multi-access links, when the packet's ingress and egress interface match, and the source MAC and next-hop MAC addresses match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to
>> destination) error message MAY be sent as per [RFC4443], section 3.1.  The ICMP policy SHOULD be configurable.
>> 
>> - Bernie
>> 
>> -----Original Message-----
>> From: ianfarrer@gmx.com <ianfarrer@gmx.com>
>> Sent: Tuesday, October 13, 2020 9:16 AM
>> To: Michael Richardson <mcr+ietf@sandelman.ca>ca>; Jen Linkova <furry13@gmail.com>
>> Cc: Bernie Volz (volz) <volz@cisco.com>om>; dhcwg <dhcwg@ietf.org>rg>; 6man <ipv6@ietf.org>rg>; v6ops list <v6ops@ietf.org>
>> Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
>> 
>> Hi,
>> 
>> Thanks for all of the discussion on this. We’ve reworked the requirement as follows:
>> 
>> R-4
>> To prevent routing loops, the relay SHOULD implement a configurable policy to drop client traffic as follows:  For point-to-point links, when the packet's ingress and egress interfaces match. For multi-access links, when the packet's ingress and egress interface match, and the source MAC and next-hop MAC addresses match. 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.
>> 
>> Thanks,
>> Ian
>> 
>>> On 9. Oct 2020, at 17:41, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>>> 
>>> 
>>> Jen Linkova <furry13@gmail.com> wrote:
>>>> I think there is confusion re: the scenario we are talking about.
>>>> I've attached the diagram for the case which concerns me.
>>>> So:
>>>> - The Relay R has an interface eth0 connected to a switch S.
>>>> - Devices A and B are connected to the same switch and using R as a
>>>> default gateway.
>>>> - The prefix 2001:db8::/56 was delegated to a client A via the relay R.
>>> 
>>> a friendly amendment to your example to aid in human comprehension:
>>>    } - The prefix 2001:db8:0000:0123:/64 was delegated to a client A via the relay R.
>>>    }  - R installs a route for 2001:db8:0000:0123:/64 towards A via eth0.
>>> 
>>>> - The device B (which has an address NOT from the delegated prefix,
>>>> but from another /64 assigned to that common link, let's sat
>>>> 2001:db8:cafe::/64) sends a packet to an address from the delegated
>>> 
>>> now, my brain can more clearly see that 2001:db8:cafe::/64 is not
>>> within 2001:db8:0000:0123:/64, while I had to use a few extra brain
>>> cells to see that it wasn't in that ::/56 :-)
>>> 
>>>> What I'd expect to happen (with DHCP-PD or without - e.g. if R has a
>>>> static route towards A, not a dynamic route produced by PD):
>>>> - the packet is sent to A. Well, if A does not have a route to
>>>> 2001:db8::42 then indeed a routing loop might happen. But if A does
>>>> have a route, the packet will be delivered.
>>> 
>>>> What seems to be required by R4:
>>>> - R detects that the packet is received via eth0 and needs to be sent
>>>> back to eth0. R4 seems to require such packets to be dropped.
>>>> So if B would never be able to communicate to any address in the
>>>> delegated prefix, right?
>>> 
>>>> Am I missing anything?
>>> 
>>> I think that you got it right.
>>> 
>>>>> Perhaps the missing piece of the rule is don’t send it back to where it came from, based on link layer addresses (or link if point-to-point).
>>> 
>>>> Yes. If R4 was saying 'drop the packet if it comes from the same
>>>> link-layer address you are going to send it back' - it would make
>>>> total sense. But I don't think routers do *that*.
>>> 
>>> Yes, if we made the check on L2 address, then it would work.
>>> And I agree that routers are exactly doing that.
>>> 
>>> I think that it also works if B is a router with additional interfaces
>>> downstream, unless there are multiple paths.
>>> 
>>> --
>>> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>>>          Sandelman Software Works Inc, Ottawa and Worldwide
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
> 
> 
> -- 
> SY, Jen Linkova aka Furry