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

ianfarrer@gmx.com Tue, 15 September 2020 12:15 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 1D5E33A0B93 for <dhcwg@ietfa.amsl.com>; Tue, 15 Sep 2020 05:15:37 -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 WrYwooJsB3o8 for <dhcwg@ietfa.amsl.com>; Tue, 15 Sep 2020 05:15:35 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 204683A0B8F for <dhcwg@ietf.org>; Tue, 15 Sep 2020 05:15:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1600172126; bh=rDCeGWIz+zXzs9ny/NLJZWuWQ1ywO5IyJfdJUl6oALk=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Swt41Xanos5g0U74+dWMsNy69XkA4y7n3aQ3965BV7ZFU3Cjw8adloTqcCB5ScbyJ FAlCS3ekYRqzirNm2OOknYRZAzb6DtZIG0hsrcrKEUQY60Ht+DRmc2eP+5XRLJBPyt f1R68zbqYGRMMbFY2on0wvtayl7/MKFY7NP9Mag8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.228] ([80.159.248.124]) by mail.gmx.com (mrgmx004 [212.227.17.184]) with ESMTPSA (Nemesis) id 1MHG8g-1kDhtO1jQu-00DCQ9; Tue, 15 Sep 2020 14:15:26 +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: <A2A9F390-5B5A-4DAC-9E8A-7F6BA51F7ECB@employees.org>
Date: Tue, 15 Sep 2020 14:15:24 +0200
Cc: Bernie Volz <volz@cisco.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7358EA97-7E61-45CB-8D32-3AF405B60768@gmx.com>
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> <A2A9F390-5B5A-4DAC-9E8A-7F6BA51F7ECB@employees.org>
To: otroan@employees.org
X-Mailer: Apple Mail (2.3445.104.15)
X-Provags-ID: V03:K1:H4RCwqWRqCrKamOrMdjVqoqy+B4mfX7veOMESGKrwrfhtq5lgR1 brpdNHUQ8x2r377etOiQMTn/ZdSYmCGKKALcZcpVGBTDZtmBB8+89gsqaynNnj4TrWO62Zm 9sh6ifxyjWgzzf7aNS7BKJi7U1zolBgiflNFxOLqB/aRWR9kxYZmPBt7Nz+M2ZrodcyMyQE Vy7t/qPHm+IQEpkZOG3Lw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:pPT4TLevwUY=:QfGrmgFJGNZhNOZV/4+5aN sW2CnNbt+lj9tvtdMeiERbJ2bhQjpcHXuTliuyq9iD9qajHazSNT2Pd38GH0sn0Vkp3OUfiZt UidoX2nYkOK8Vn20h6pek/mWL6bppBMyBbBmQn3azO5GJ8DQdJ2Stiyh9155pY8CQwnSRDSw6 RamnqfS9RSJfHBylsEnR4saFfW4TysMe6LVEEgnyLTlUzNckfywbX2TUOIBkdyl3g+xu/tDvO ZYqFXI+N5A7qfyGyUIOJGVgtpmARZtfVyD3yHuwtNIoSiqmh5DwBuyH6Y/CT7oH6qY5D8BO4D kN3u4dSO0PI9t27eoZu+Q+8DTC0vtyH/ybvJM2roj4FBm4HnNeNTm2wFKzZaRqVzklARp2f5G 12rcvxWOMrapcsvQ1OyEzUBzTAhso/nmdMkxaWOsMKen3/bxmEl+XzkMPijqz07uJc9I96xL9 NNm6FRuGJ7/OK2Jy6kYB96+jN2Wp0m2YB+P0COFpAADljJjgy7o17oz7IdMo7WUR7OZbzKOrp x9+NlPHvJLUALq010HuQc26VoXZD1xFFT74H0j5oGuE05pQg1eqa3KH4JiOnDvs1KDpllA/dL rm33sLvjD1dbsvDov2LBeNFczB/HPovLIsd1hcgGXzetBG5PHvmVj1mIcX7Wd/5GB1ESTu51v yOS2lOlvzwf61kDvR9scMR5TkpbGRbgPjzp93B7Ry6JpLJ6itdRZUWsc30ZqUOpv6SZQkqpPH aluGr3K+ZKcW7nnxg35ieQzmrsX4ml5kMYSpIoDeaiVru/ybKvsbdTsR1YI29VNO4VZlwYp1y QszyQoEmCQwyCbbfUhNqn3vY60EwIN+UvZFC4+SVP6dwhLCQGEPVubIXjod/xPWjozL8lZKEM JYPXkhoWiHmqhO9DvWqvEBsAb9nzMkO5XOgK2VxzFxVsBADs8ay6XhtqZgrCaas5CR1OZOYy+ E62jn41QSEeBNsfXc4Bl/YxNXao36TM1E+7yPO129O9LsAscEO78b2c9WqzOSh+yzZbSaMsM/ /KaPNkfRGPtf219svGUUKU12ngEkPMTfULRpnLj7Ks9TfCuodu4zuQ7tFASbDhIIrwBuodtWD Yk83hq1/zaz0DfW9jAAPc0aLM7ySVEqKgX8R1ipic0R2ENWLQR0TK8ZEO8Xik2dFtnAYZCjdz E2XTDjYYdyHwzQhBR78VxMX8/o7ANwWbis1LwazNzl7y/jykWLmsc9Muf7+m9BhEIoxWDOIty Dd3cnEJ87hJI//njO
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/ZCfBOW2RyIrxo1-87_kWsML0JQ4>
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 12:15:37 -0000

Hi Ole,

Please see inline below.

Thanks,
Ian

> On 15. Sep 2020, at 09:32, otroan@employees.org wrote:
> 
>> 
>> 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.

[if - There’s been quite a lot of iterations on this since -01. The current working version is:

R-4:
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 (that is not an on-link prefix for the relay),
then it MUST be dropped.  This is to prevent routing loops.
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.]

> 
> 
> Two questions:
> 
> 1) What is the case where this would triggered? That wouldn't be caught by uRPF (R-2)?

[if - The traffic is originated from a valid source prefix so uRPF (R-2) doesn't cover it. This requirement is concerned with the destination.]

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

[if - That sounds like it would cover it.]

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

[if - Please see current text above.]

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