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

ianfarrer@gmx.com Tue, 13 October 2020 13: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 DC2253A0FBF; Tue, 13 Oct 2020 06:16:32 -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 JGHGf7PXxmEw; Tue, 13 Oct 2020 06:16:29 -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 531C83A0FC3; Tue, 13 Oct 2020 06:16:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602594978; bh=MUlrod63sPpELBIXNdF+bF872lewdh9caqKmhRvovUQ=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=ciY5/pT5ENX+APzoyWmhhhVuhhd2pQsbd5tlfB8jQ/Jcku5+6U9NV0hlEFWrn9wIM EwIeVN3CR8+S7MzKho+o7YCx1xFrB9dtsAjV4DNQQknBkepF+XCZ3xPycHt5bDt9Fz u69DIZ1/7hHxZ/B8mFcwWk/N9jbDju/b4rWMazeA=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from ians-mbp-5.fritz.box ([78.35.192.234]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MeCtj-1jsAfF2KLn-00bLxx; Tue, 13 Oct 2020 15:16:18 +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: <19432.1602258078@localhost>
Date: Tue, 13 Oct 2020 15:16:15 +0200
Cc: "Bernie Volz (volz)" <volz=40cisco.com@dmarc.ietf.org>, dhcwg <dhcwg@ietf.org>, 6man <ipv6@ietf.org>, v6ops list <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.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>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Jen Linkova <furry13@gmail.com>
X-Mailer: Apple Mail (2.3445.104.15)
X-Provags-ID: V03:K1:UObRgEoF2hwAUSAMwYsB+ZUJ8Bgw0o5lkof3H+RX9g4obm5MEnD Pli9CAql6xsh1sBYQmoqESh/W/75ySQ5WjrFjj1Pp7F3Y6Nq/8t8v2VHveM0dMiqU9GXMhl ghLNs7DKirVa9Y+col0ljo+KrVvBs0c2p0PcngqZEUqxWNQ4je7al2n1YMa2Y6zwcc/Bm+B pEtfFLRGCfxkU39MbtUfQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:AATCoIsjmAM=:neYXd+kRdGzY3S0kpB0aKA R2B28/XmAgqxNwOBofCWoDEDr4SM6rrFVN+J0OYTK4sgAksJvJr3E+PgW60bqzeeXt6/pg06P 8IgTpl4frn4LydUNsnsa58Vw2OHNSWphV8B1wKvS+D+egdHyDGBBtM/JtcSV8/0Yvl9YurBK0 qlB8VzBalcV1VQiIVa8ma4vNAkS0LDzusEaOmyXFTZN9Ejsvd5+XggzoiJU2X2HhuYdVYIvAa 5LPp9pCUvA1j9hoXqbyOxnDzBwSecPbEK/IJmFEPw7+aw9//TU+jvba6/qbNbdYfON8iqoh6Z OEMdLvZfucikBAP6u6rm7kekt5aLnIy8TdGVAB/rRnKRETjZxlok9GXdtfsl6v9WIdQXx6pwq Qj38UW45znZAPlzkeVgJa3nBkK5CY1nt2C3C0z46y2tkhmsgZvj0Q7UcVv2SwfPdfVGIziiuR KhUKxO6UJAvw3iovHHQkR35Hao4LsOk17/zcro+zSFEO1dy2AOJSjleTdkbU9kl/bQwQT5IdP dx37VINcAHEr/yre+vjyQRGSGl1Y7rXHuWQ6NFcXEQv+7GHieNAKDP6cmLOgzhqZXPVKniBjF cKjaXeCjg9SJUCEWI3iFEJNFyj8xs9O41bf0CgNBBgrQYG1nhKoK3IvSPQ6GK71EV+5h2ETeZ ZHU1pkXyYdw9zZxuBPeZKYSNcQDEYFmm91/oNtMqNhlZ+XckmrmdNBCglhQXQMXriV+6AgPsw tNHKIdy3mTE6b0bplOknC68HBI7pf0YTZTP/i5KNgokA7QeRKlPUtrICb6+GTxjzyy44UUUoo yapI1LjAceubu8nR9WxNc+YrQqB1Us/v33/rmnKvu05UZ0QEVF1WRZ11uGCzCZtb0KUpSCkvX t3qOhDw7XKmfdjbEj+I3qCFJVyC8+CI+kPUhRJGEi6CmmZxAr8AHMaj+BBZiYj0ezY1QTaLjw YP7Pic55uWpGM/Xv9nvXs6+fm8+qIHyGYDvAjJpnNj48zs3uJ3cW3nW7wv8o9lEbrXL6W8O5E HGUcFBu5M1lWdkZ4QYuQywXBHO3V3T/fBu6HGyYWkRo0Q4ZcRtzlIdXRBptbqjzBCBZL/JGqI USSTC985sfk7Pq6XwSE+9N0Rjf0ZLmMQo23b24xNXLP2vgRyhICzkITztQANga+qLR4UgZP24 HYZNH5Cj2XfazszcW3wlvoWm+HMLA542DasbR9lVSPa0fg2cbgfLMOcIhOsJogbm+PsPEtwPK Ls/CiI7HDXX8sAsoZ7Fnove82YeHD1l2+Pae/h7fHFmuOMO1nlviewMajrU8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/ap2WJtCKqvDlucT-mqpXSYxP-cI>
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: Tue, 13 Oct 2020 13:16:33 -0000

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