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

ianfarrer@gmx.com Thu, 05 November 2020 15:05 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 C512C3A12AC; Thu, 5 Nov 2020 07:05:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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_DNSWL_BLOCKED=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 7fpgT54JCFGe; Thu, 5 Nov 2020 07:05:07 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 1BDBD3A129A; Thu, 5 Nov 2020 07:05:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1604588704; bh=W4qKeuXP5leY7idxpByfkUyZ9iZ57S6UZkTlvBnh08E=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=CNftGoS95SME12Kw1Z7CfBP8VRU6PMJcmYsxi4qPaptC14RjmPLd9El8v0DVfNglh t8fdrw7lGGE6Ker0CrMLZFVCCOFn2PzbuJaxcZSvHNituKw72JR2JTOenn/D3rcwWv DoCQGk/jVZILpowP/svAJwUhTwe3MZdddmpW811g=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.128.43] ([89.1.62.143]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1M7sDq-1kfclR3dZK-004yhu; Thu, 05 Nov 2020 16:05:03 +0100
From: ianfarrer@gmx.com
Message-Id: <1F66C58E-720B-4D2A-8832-BBDC67D521EF@gmx.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_674673F2-67E3-4E5A-AA6B-FEBA04556372"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Thu, 5 Nov 2020 16:05:01 +0100
In-Reply-To: <BN7PR11MB2547DD143D784940F5524DA5CFEF0@BN7PR11MB2547.namprd11.prod.outlook.com>
Cc: "draft-ietf-dhc-dhcpv6-pd-relay-requirements@ietf.org" <draft-ietf-dhc-dhcpv6-pd-relay-requirements@ietf.org>, dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@ietf.org>
To: "Bernie Volz (volz)" <volz=40cisco.com@dmarc.ietf.org>
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> <BDA018BA-70A6-4DC3-92FA-21506C72F6D9@cisco.com> <CAJgLMKt6Zd4H9SdFog3y36HMbCizQ-SsSL0p+DsdtVchz2xjUg@mail.gmail.com> <BN7PR11MB2547DD143D784940F5524DA5CFEF0@BN7PR11MB2547.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:kHk7TLvABK6L6RKoDS3J+OBtEgmRgazwLLr0C8yI7Ckl6lnt6bL JZooJsMQzLtN3NqdJlaKFcKvISrpvWHmB8HoqzJqQwQoEH6wUUstazhXP1ohyddbae0x/JK bP+thz1ETcLD7E4PDINwifo07aswTuHkomEulVhcOQJvgve5mm0Pduzt0izoNeNZWLBia32 SFmP9gXdie3uFVNC22sMg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:9g7r07eVkSg=:Xqyi9rf3lUgnSpCpkmYFSp 4PoTOL09F/CASk6sZTuqYySiX/Jj1boAdp5gIxuc3yGU2Vof0p19K5qzo+OF3DpKAcEh4Pe6R TXqtDyESPIVNTys2UpyzXlvVlGRN6Bbyat+JZgukCAibF6olO6hWoTf0uAazdcw0oR44fiYkM O9pTLpbfIqBhv4u7OeBYc9IgsNkmM1jDY6A5M38F3f7P92JNDp10eMD3RszsdNMKLNMfHTd4H 21mHtshyA3ov6z+0QRqinQJ5+vdI24mIq3lJXwSogfqyCsKyebnLRyWf2SvOpAj8LYswcs249 d5OlbtGZ+32cTgePVpjL72hRswvB35lDsvitry04W6a1Fg+gUGT8+CSCGo7KYMq/P9ln6IQXc xPpjxIteqvf7SzrbZJLGkX+Y8qR3XYaF6/k+Ge8oxjcsbOWjSuZGLTcWOuJt0na3m6thc95dt PGiLiJDdEjz1EdCYUoWXZmL99OD7HqYr/Qy354XH3Pz3qM8DykSVYYuk9lIfLBdpv98Juskq1 tesWH6ZWRrfcKcUX/gI0gKsfWSn3g3x2xDPYX0y7O6zfouKutbucxlv6+tQxBi28UDMnppxBV tB63l8AI2hVtHwP7KWgWvgZYFUmycOu1l/vBOANr0IXGCgPlH+u1f/ayHW0tWmNIQ1cPcJGm7 v8J5Pn96rEoK/LNGGOSfeDg8Pc3qppCnmSXQ3MwgVdN90Hz5j3yvlx6o3IlvP5nKqcjSRhN8x 7ngM5POBy5ICH0VPTWcexZJ27ga9LFi2NDhJZDlypCdf0aRXpAv8jZlyWu9y+76y2zNFRtQ9M kU3Ndmu2p0BZ3a1+XkvTJTdJLgAFc6/qTq3N+Zf3KKBzCapZlrN+slZU720sazS9Uk4ivy8bl DMAjc754JDIwXxAMZphg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/ilYjawRD7igaMKmoOqr2YRWIBNI>
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, 05 Nov 2020 15:05:11 -0000

Hi Bernie,

The Requirements text for this was taken from RFC7084 as originally it was expected that this draft would be similar in its format and approach. However, as the draft has developed, I don’t think that is still true. The main difference is that RFC7084 requirements are largely a list of ’these are the RFC’s that you need to implement' (hence the Requirements text).

The delegating relay draft’s requirements are mostly ‘standalone’ functional requirements, with only a small number referencing other RFCs, so I think the best approach here would just be to move to using the standard boilerplate. I’ll update.

Thanks,
Ian

> On 5. Nov 2020, at 00:57, Bernie Volz (volz) <volz=40cisco.com@dmarc.ietf.org> wrote:
> 
> I’m also wondering given issues the IESG raised for the https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum <https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum> document regarding the text…
>  <>2 <https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-05#section-2>.  Requirements Language
>  
>    Take careful note: Unlike other IETF documents, the key words "MUST",
>    "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
>    "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as
>    described in [RFC2119 <https://tools.ietf.org/html/rfc2119>].  This document uses these keywords not
>    strictly for the purpose of interoperability, but rather for the
>    purpose of establishing industry-common baseline functionality.  As
>    such, the document points to several other specifications (preferable
>    in RFC or stable form) to provide additional guidance to implementers
>    regarding any protocol implementation required to produce a
>    successful CE router that interoperates successfully with a
>    particular subset of currently deploying and planned common IPv6
>    access networks.
>  
>    Note: the aforementioned terms are used in exactly the same way as in
>    [RFC7084 <https://tools.ietf.org/html/rfc7084>], with the above explanation copied verbatim from
>    Section 1.1 of [RFC7084] <https://tools.ietf.org/html/rfc7084#section-1.1>.
>  
> See https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ballot/ <https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ballot/>.
>  
> … whether it would be wise to follow the IESG guidance and drop the special use (in section 2.3)? Otherwise, you may run into the same issues the cpe-slaac-renum document did.
>  
> It may be wise to wait until the dust settles with that document and the text that it ends up using (perhaps just the default boilerplate for the keywords). And apply that.
>  
> I WILL assume you will do that (as I am currently the one holding the document) unless I hear otherwise from you. Or, you could decide to just update it to follow the standard boilerplate for these keywords – if so, be sure to use the latest version, such as what was used in https://tools.ietf.org/html/rfc8925 <https://tools.ietf.org/html/rfc8925> (section 1.1).
>  
> Thanks!
>  
> Bernie
>  
> From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of Timothy Winters
> Sent: Wednesday, November 4, 2020 8:02 AM
> To: Bernie Volz (volz) <volz=40cisco.com@dmarc.ietf.org>
> Cc: v6ops list <v6ops@ietf.org>rg>; dhcwg <dhcwg@ietf.org>
> Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
>  
>  
> I agree with Bernie, link-layer address would be an improvement to the Mac Address.
>  
> ~Tim
>  
> On Wed, Nov 4, 2020 at 7:15 AM Bernie Volz (volz) <volz=40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org>> wrote:
> Hi ... looks good but perhaps MAC address is too Ethernet specific and just link-layer address would be better?
> 
> - Bernie
> 
> 
> On Oct 29, 2020, at 12:24 PM, "ianfarrer@gmx.com <mailto:ianfarrer@gmx.com>" <ianfarrer@gmx.com <mailto:ianfarrer@gmx.com>> wrote:
> 
>  
> 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 <mailto:furry13@gmail.com>> wrote:
>  
> On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) <volz@cisco.com <mailto: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 <mailto:ianfarrer@gmx.com> <ianfarrer@gmx.com <mailto:ianfarrer@gmx.com>>
> Sent: Tuesday, October 13, 2020 9:16 AM
> To: Michael Richardson <mcr+ietf@sandelman.ca <mailto:mcr+ietf@sandelman.ca>>; Jen Linkova <furry13@gmail.com <mailto:furry13@gmail.com>>
> Cc: Bernie Volz (volz) <volz@cisco.com <mailto:volz@cisco.com>>; dhcwg <dhcwg@ietf.org <mailto:dhcwg@ietf.org>>; 6man <ipv6@ietf.org <mailto:ipv6@ietf.org>>; v6ops list <v6ops@ietf.org <mailto: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 <mailto:mcr+ietf@sandelman.ca>> wrote:
> 
> 
> Jen Linkova <furry13@gmail.com <mailto: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 <mailto: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 <mailto:ipv6@ietf.org>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------
>  
> 
> 
> -- 
> SY, Jen Linkova aka Furry
>  
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>_______________________________________________
> v6ops mailing list
> v6ops@ietf.org <mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>