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

ianfarrer@gmx.com Wed, 09 September 2020 09:29 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 282623A11A7; Wed, 9 Sep 2020 02:29:12 -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 9stktwYHNXDC; Wed, 9 Sep 2020 02:29:10 -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 085D03A11A3; Wed, 9 Sep 2020 02:29:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1599643742; bh=guh/hEbzITOwDPDQo0ZY84ETAzVIDCoVMKUPJWUXf38=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=MXRBE68KZN3VA5EDnodVuHKqagWNRchGswQj3DV6A4u1VltUmbSZBqjA09eK8B/Eg l3utSyezblYiS3ktqXmHcBlrGtz6tKMl4aGZe0e9xm7Q8BYAk16xAJkyxZW2vjxRsV aUUdg9fUIYMgqMh9OrT5nw1vFnJtczCn6jZFXoyA=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.128.43] ([78.35.214.132]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1Md6R1-1kppWg44N1-00aDyN; Wed, 09 Sep 2020 11:29:02 +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: <BN7PR11MB25472678D6ACAB82912141A6CF5C0@BN7PR11MB2547.namprd11.prod.outlook.com>
Date: Wed, 9 Sep 2020 11:28:56 +0200
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C503DF9C-7798-43A3-9E7F-7D7E09B0D98B@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>
To: "Bernie Volz (volz)" <volz=40cisco.com@dmarc.ietf.org>, Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.3445.104.15)
X-Provags-ID: V03:K1:2fI5X/3t9d0Aid1kHiNaZiLTJwuB+w87Dl+nSpFL1U7sRAxMXHq fAAgtfuu5RsYOs+FZZz6iPwQcceBNgZnM5lW+uleGXu/IDCV9xKdC0cMNjbXjFARSa24MOU mn2yIVl8UYAFUoDkS/fqhWV3BZzaoAggSjCMOCppRZMvmmYxQWBIJiVTsnDCv3gWdSlSkYI cPLsU0xoJp5sPzTsfngxA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:oMDCFPGtAUY=:2mnXYae8SZpqcT9+xLoX+i dMf7UMM/wDyjDBh5Im/lAy8EX2ett4FhCc/n60ZJhwDAi/QyMgNRbXNxbY5EsPeN114N/bD8A NYoupeJgAuIcL/+45kIdvEehurm84+oXLSJaXsVgSzhipVp8gAm96gA2IqRWGPZQoFmG851Kb zE8rluM8UdULYHH7Mj4smflC2kQHRumaT8ZDhByT7HLyEbe4uPgMdjA1CYKGNHhDwLEyA04qL B1X5pSd+KVGtIngurf0/DiiJMxKVQ0y+nw2juwP6Nh1ioJ7QeGlvsTzD7KZ4zJCV/uDse7Xs3 ZuSVhS9paOzNOLRKHITC/fPWVJRivmDajQyYBWUObMH/mRoWur0+CEWrisXM/yVH5RK7p4UbQ 4KzIAcDkRopASlnoc6LWuVd+GJMRamlLOY3lOMpFe4aWBOkvq+m609xOQedYlY26QUl3rrT6d PsZvux2rIXMxmWZFqf9Q+SpoPxCFeLHOCOpGcT2fv6f92XZClMAX3OCWXwIs9s413EqgnbnZQ tCtgGEjyQC8eA46GRUoXNtTYAEPKchmvxPFdvUQlui4wYIshX/lfYQsX5GvABExYvwHqQM3wG HASDpGgWo+b3Jp9eWgEHoRKtRy6kjtFn6Nyk/W7BJfDu5oVTNUJlAZGkiJKuVo8dgjel6FYHu X8K6hP6KPqnzWmm2mBfyyXkgs5wGLFs8+D3lskIWpwMJmQxryeau8nokfeWrzjDqaJVVKKX6o ZHjS1fu6p5dZiz1VP4EoMXE9rCpTylYis50+1umzahPzVD9RWmFuZn17liFKEIQkpvMTI64bx OOcu2XwFPaR29G+qcaxFgllCps7YUCwOiNm24vnjSDfRXnjeNbkzyrWXf8vTxGN7vprIfW4tY VO4gkqB01iy+rZZWL0H2CSXyq4By7Nwe046EwhhIRGvyfkuBs1G98BLvSt3wJogyRk28ez0wQ aePXeFiF+SVYAF6hzl4mJiROJqrs32Tc+uDwhcfehPxt4qkhf/oNLSm9x5m7CJyaPtg6Z1v/l ClqtR+zpiaF/wLwlYFaDoY7gTE7yo4nbyZXiL5kdgbjA6yFCncg6TEdGWtIPXnRW0QsQZiO78 PAEAzhJCuY9tD0DWRNNS6rup10Hv3gYsw9+py0n+BP/jABfvOS9SCd30BvBdOYl8/DnGi6t3/ qaw4MWCGS+lZGgcpkyWvAkPdWOI7/jNXRBJdZbIH8e0z2Tg1sfJ42CVuv6IU11qF8B9gXbs0o 1I+AG0Fuvqv2Kehcl1xchIXlik9wTxNba9chr+Q==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/k70AgAzy_4tESTja-iwTGNnhx_s>
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: Wed, 09 Sep 2020 09:29:12 -0000

Hi Bernie / Ole

Please see inline below. Where there is no additional comment, we’ve adopted Bernie’s suggestions.

Thanks,


> On 19. Aug 2020, at 00:15, Bernie Volz (volz) <volz=40cisco.com@dmarc.ietf.org> wrote:
> 
> Thanks Ole ... I had also flagged that requirement as an issue in my shepherd review as it is not very clear.
> 
> I think the not configured on the relay means that the destination address hasn't been assigned as an address on one of the relay's interfaces.
> 
> I do wonder though what the "normal" router behavior would be - would it not just send the packet back and also send an ICMP redirect? And, why does this needs to be called out specially isn't clear?

[if - Yes, 

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.

> 
> 
> Anyway, here's my comments for the shepherd review.
> 
> First, I do support this document moving forward.
> 
> Abstract:
> 
> "when the DHCPv6 relay function is not co-located with the DHCPv6 server function" is a bit weird as why would the relay even be needed in this case?

[if - The abstract is now Ted’s suggested wording:

This memo describes operational problems that are known to
    occur when using DHCPv6 relays with Prefix Delegation. These
    problems can prevent successful delegation and in result routing
    failures. To address these problems, this memo provides necessary
    functional requirements for operating DHCPv6 relays with Prefix
    Delegation.]

> 
> And, "time synchronization between DHCP functional elements" is really not covered much - it translate into O-3 as best I can gather? Just wondering if it is really worth mentioning in the abstract - but that leaves just "rejection of client's messages and other problems". Perhaps reworking this to provide a list of the main problems is worth considering? FYI  - you could add some kind of data recovery/persistence in case of 'crash'/restart?

[if - It did read ’timer syncronization’ - i.e. related to the times present in DHCP messages, but this text is no longer present.]

——


> 
> I'm not so clear why the last paragraph is important. And, it doesn't translate into a requirement? Perhaps one should be added if you think this is worth pointing out (over and above what RFC8415 has). Note that section 3.1 deals more with known messages and 'acting as a server’.

[if - Removed the last paragraph.]

-----


> 
> Would adding something about "or contains an unknown option" be useful to include here ... we don’t want relay's to not forward messages because they don't understand a "new" option? But this is already covered in Section 16 of RFC8415 (see below), so it may not be worth re-enforcing this as RFC8415 is already clear on this. I just raise it for your consideration (feel free to ignore).
> 
>   Clients, relay agents, and servers MUST NOT discard messages that
>   contain unknown options (or instances of vendor options with unknown
>   enterprise-number values).  These should be ignored as if they were
>   not present.  This is critical to provide for future extensions of
>   DHCP.
> 
> I might add that perhaps a new paragraph to this section that reads something like:
> 
> 	Relay implementers are reminded that RFC8415 makes it clear that relays MUST NOT drop
> 	(and hence not relay) packets that either contains message codes (Section 19 of RFC8415)
> 	it may not understand or contain options that it does not understand (Section 16 of RFC8415).
> 
> Or perhaps just add to General Requirements?

[if - removed this as requirement G-2, and now have your suggested ‘Relay implementors are reminded…’ text in the General Requirements intro.]


----

> 
> Section 4
> 
> Comment related to the requirements ... should these be tied back to the earlier sections? In some cases, it seems that requirements were added that aren't directly related to the earlier discussions? Should there be a "See section 3.x" added to identify where the requirement came from?
> 

[if - As the functionality of a delegating relay have not previously been defined, there isn’t a direct mapping between each of the requirements and a problem which has been observed in implementations.  The aim behind this draft is to resolve what we have seen, and hopefully pre-empt other undesirable behaviour.]

---

> 
> Section 4.2:
> I had issues with R-4 ... see Ole's discussion and the top of this message.

[if - See above]


> 

> - Bernie
> 
> -----Original Message-----
> From: otroan@employees.org <otroan@employees.org> 
> Sent: Tuesday, August 18, 2020 3:24 AM
> To: Bernie Volz (volz) <volz@cisco.com>
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020
> 
> I have read through the document, reading section 4 thoroughly.
> I think it looks fine and ready to advance.
> 
> A comment:
> 
>   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.
> 
> I struggle to understand what R-4 is trying to say.
> In one sentence it says it has a delegated prefix, then it says "not configured on the relay"...?
> 
> 
> Best regards,
> Ole
> 
> 
> 
>> On 17 Aug 2020, at 19:23, Bernie Volz (volz) <volz=40cisco.com@dmarc.ietf.org> wrote:
>> 
>> Hi … just a friendly reminder. We’ve had very little input to the WGLC.
>> 
>> Tim and I will review the responses and evaluate the WGLC later this week (Friday), so you do have a few more days to respond.
>> 
>> 	• Bernie
>> 
>> From: dhcwg <dhcwg-bounces@ietf.org> On Behalf Of Bernie Volz (volz)
>> Sent: Tuesday, August 11, 2020 8:20 AM
>> To: dhcwg@ietf.org
>> Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020
>> 
>> Hi … just a friendly reminder regarding this WGLC.
>> 
>> Thanks to Ted Lemon for reviewing and commenting!
>> 
>> 	• Bernie
>> 
>> From: Bernie Volz (volz) <volz@cisco.com> 
>> Sent: Saturday, August 1, 2020 11:07 AM
>> To: dhcwg@ietf.org
>> Cc: dhc-chairs@ietf.org
>> Subject: WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020
>> 
>> Hi:
>> 
>> The authors believe this document is ready for WGLC. Therefore, the chairs are initiating a WGLC on this document.
>> 
>> Please review this document and provide your comments and whether you support this document moving forward or not by end of day on Monday, August 17th, 2020.
>> 
>> Please see https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-01.. This is a Standards Track document.
>> 
>> There are no IPR notices filed against this work (as of this writing).
>> 
>> Thank you!
>> 
>> 	• Tim & Bernie
>> 
>> --
>> 
>> From: Naveen Kottapalli <naveen.sarma@gmail.com> 
>> Sent: Saturday, August 1, 2020 8:20 AM
>> To: dhcwg@ietf.org; dhc-chairs@ietf.org
>> Subject: Requesting a WGLC of draft-ietf-dhc-dhcpv6-pd-relay-requirements
>> 
>> Hello chairs,
>> 
>> We, as authors of the draft, are of the opinion that the draft is ready for WGLC.  Can you please check and initiate the same?
>> 
>> Yours,
>> Naveen.
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg