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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 09 October 2020 15:41 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F6C3A09E1; Fri, 9 Oct 2020 08:41: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 5p0_u_MlfiZ1; Fri, 9 Oct 2020 08:41:24 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404213A09DB; Fri, 9 Oct 2020 08:41:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DD2B9389AB; Fri, 9 Oct 2020 11:46:51 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20ys6r092Duf; Fri, 9 Oct 2020 11:46:49 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CB2E2389A3; Fri, 9 Oct 2020 11:46:49 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E9706733; Fri, 9 Oct 2020 11:41:18 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jen Linkova <furry13@gmail.com>, "Bernie Volz (volz)" <volz=40cisco.com@dmarc.ietf.org>, dhcwg <dhcwg@ietf.org>, 6man <ipv6@ietf.org>, v6ops list <v6ops@ietf.org>
Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
In-Reply-To: <CAFU7BARUKw_c2c9+3k9kJ0UqrATTruGKPGkVb5NPTo=vspb0NA@mail.gmail.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>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 09 Oct 2020 11:41:18 -0400
Message-ID: <19432.1602258078@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Ki6e-8QYXH9MkSkVpDlvlJM1BdI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2020 15:41:26 -0000

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