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

Jen Linkova <furry13@gmail.com> Wed, 04 November 2020 07:28 UTC

Return-Path: <furry13@gmail.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 74CC23A0C92; Tue, 3 Nov 2020 23:28:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 KjtuFLi6yco8; Tue, 3 Nov 2020 23:28:03 -0800 (PST)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104413A0C8B; Tue, 3 Nov 2020 23:28:03 -0800 (PST)
Received: by mail-qk1-x732.google.com with SMTP id o205so11428818qke.10; Tue, 03 Nov 2020 23:28:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hHsblAHg7qt0rr0YgX7HY5VhRGwY1KDDcnRNE927q2c=; b=nDzdcG78Pwd+7H8rF0rjKMjGvE9VvcepwmE/2b9DYtumeou1g+JHYdPGpi9jmx+nv3 1Lx+egc3iw73F9uhY9hKj2Rgi6AYHgcU3wMLsvPlEipY76kAGTA2M5AZNeyzUpH1F7RW iebJb9cBbWXdY7byVV9FyfNb6/q3oJ3MwPaemNx8jCUOeHTldXeN8qmq9VRRmdN0bUWp Wrrz7IBQjqixuH/tmLZDNruPKLAkdp1EQfXeD+r0m0/t1K8AwMinALtm1iW7eF5KLw1x r8PJVMIHgP+a14B/hZgI/zS+S0H1Ke2LJknOWwLs6QlvK3tWBYoVDmKU3B/Q2Vbr1XLk O2NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hHsblAHg7qt0rr0YgX7HY5VhRGwY1KDDcnRNE927q2c=; b=l9vSn2Q0THbBnHqIf56mt6hBzfaY+C8v436oldAtFbVjCCX8y2FgUm23W0VEP5sXPL /He12D1VwtlpRloeYfsW/ge7onmybbGsVp4zarN/a2WtPBGZAAEJloaAE6ta/uw/0swi teP4ViguKSVmA946dqP9RLh8ubNJCBmij9KURIPxURBhFl4QGUJAxu8HoP8F5/iRYfl1 yGEvetkzNTLqC9xWydviAC33y+7lTJeqoyLHQV48MeEwn+RH/D6PZ7+DRybQ0bZwg7DT 1GjkyLS0JW4NDcTXe31694mEj/le8IUlp4HZcvjLteRf3C9WBECYhrI7QHjSxCKCZKqe QmWQ==
X-Gm-Message-State: AOAM531ZVYzUHmNLpR/mSEDyue2IUhwQobj6H1iSCEcvKaiZ+4w1/A2M qbRAXN2l0wqnkNRW3K0I8WzLG6je+QIG8iNfTyE=
X-Google-Smtp-Source: ABdhPJzVaxYvVyH9/ngpDhr8qUM8oM3krqS+wDzUxUT32soatjeEHRDaxLVtLOIZyXfRk3lghmi430ckeWIdsoXuUAk=
X-Received: by 2002:a37:e43:: with SMTP id 64mr24041463qko.466.1604474882135; Tue, 03 Nov 2020 23:28:02 -0800 (PST)
MIME-Version: 1.0
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> <BCD1B4F1-32F3-4ECB-8A97-C4E58D746F22@gmx.com>
In-Reply-To: <BCD1B4F1-32F3-4ECB-8A97-C4E58D746F22@gmx.com>
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 4 Nov 2020 18:27:50 +1100
Message-ID: <CAFU7BAR5eNmgCD7YASY39stjv_V1yLu717W-wu88k+-_0HNoaQ@mail.gmail.com>
To: ianfarrer@gmx.com
Cc: "Bernie Volz (volz)" <volz@cisco.com>, Michael Richardson <mcr+ietf@sandelman.ca>, dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/8C2zw7rg33xGgVB3GchRF_fduSM>
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: Wed, 04 Nov 2020 07:28:05 -0000

On Fri, Oct 30, 2020 at 3:24 AM <ianfarrer@gmx.com> wrote:
> 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.

That looks good, thanks for  updating the text!

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


-- 
SY, Jen Linkova aka Furry