Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

otroan@employees.org Tue, 15 September 2020 07:32 UTC

Return-Path: <otroan@employees.org>
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 E3E8A3A082C for <dhcwg@ietfa.amsl.com>; Tue, 15 Sep 2020 00:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 nykMgHJsn_1j for <dhcwg@ietfa.amsl.com>; Tue, 15 Sep 2020 00:32:40 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5603A080F for <dhcwg@ietf.org>; Tue, 15 Sep 2020 00:32:40 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79d:53aa:d30:bdba:f064:a149:82c3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 633A84E11B9E; Tue, 15 Sep 2020 07:32:38 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 461D33D5B186; Tue, 15 Sep 2020 09:32:34 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: otroan@employees.org
In-Reply-To: <BN7PR11MB25473F7EBE67E1B51DE7AD46CF230@BN7PR11MB2547.namprd11.prod.outlook.com>
Date: Tue, 15 Sep 2020 09:32:33 +0200
Cc: "ianfarrer@gmx.com" <ianfarrer@gmx.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A2A9F390-5B5A-4DAC-9E8A-7F6BA51F7ECB@employees.org>
References: <BN7PR11MB254783295780CA79CDA1FAB3CF4F0@BN7PR11MB2547.namprd11.prod.outlook.com> <BN7PR11MB254779A3599EFC466605CD92CF450@BN7PR11MB2547.namprd11.prod.outlook.com> <BN7PR11MB25477ED8552DF78132E2F089CF5F0@BN7PR11MB2547.namprd11.prod.outlook.com> <DFF9367A-5D78-4795-988A-FCD37F3C6377@employees.org> <BN7PR11MB25472678D6ACAB82912141A6CF5C0@BN7PR11MB2547.namprd11.prod.outlook.com> <C503DF9C-7798-43A3-9E7F-7D7E09B0D98B@gmx.com> <BN7PR11MB25475DCDA3E215609BF3D8F5CF260@BN7PR11MB2547.namprd11.prod.outlook.com> <263B0965-AF60-4008-B55C-AF9803EB419F@gmx.com> <BN7PR11MB25473F7EBE67E1B51DE7AD46CF230@BN7PR11MB2547.namprd11.prod.outlook.com>
To: Bernie Volz <volz@cisco.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/gV5ETMOATEF8kSMd5F0DEiP-9QE>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020
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, 15 Sep 2020 07:32:42 -0000

> 
> The requirement is intended to hand the case where, for whatever reason, the client’s routing traffic towards the delegating relay with a destination in the prefix that it’s been delegated. i.e. something’s wrong with the client’s routing. The obvious exception to this is if the link between the client and delegating relay has a prefix that is part of the delegation (e.g. the PD exclude case). 
> 
> The current wording is pretty unclear. How about:
> 
> old:
> If the relay has an existing route for a delegated prefix via  an interface, and receives ingress traffic on this interface  with a destination address from the delegated prefix (not configured on the relay), then it MUST be dropped.
> 
> new:
> If the relay has learned a route for a delegated prefix via a given interface, and receives traffic on this interface with a destination address within the delegated prefix (but not directly connected to the relay), then it MUST be dropped.  This is to prevent routing loops.
> 
> BV> "(but not directly connected to the relay)" is a bit odd ... perhaps "where this address is not assigned to the relay" (remove the parentheses).
>  
> [if - I wondered about using something like this, but it only really makes sense if the client / relay are on a p-t-p link. If it’s a shared / NBMA link then other devices could be attached to segment and addressed from this prefix. Really, it’s an on-link prefix, so what about:
>  
> "and receives traffic on this interface with a destination address within the delegated prefix (that is not an on-link prefix for the relay), then it MUST be dropped."
>  
> BV2> Hum … Perhaps Ole has some thought. Not sure that really covers it.


OK, so here is the text again:

R-4:    If the relay has an existing route for a delegated prefix via
           an interface, and receives ingress traffic on this interface
           with a destination address from the delegated prefix (not
           configured on the relay), then it MUST be dropped.


Two questions:

1) What is the case where this would triggered? That wouldn't be caught by uRPF (R-2)?
2) On a multi-access link, how should this even be implemented?
   drop if rx-interface == tx-interface and packet source mac == next-hop mac?

- Is it supposed to be a silent discard or should you send a destination unreachable?

Depending on the answers to the above I do wonder if this requirement is needed or not.

Cheers,
Ole