Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020 Mon, 14 September 2020 11:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DB333A08E5 for <>; Mon, 14 Sep 2020 04:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tJ2tqzHcKHv8 for <>; Mon, 14 Sep 2020 04:40:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45B6B3A08DE for <>; Mon, 14 Sep 2020 04:40:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1600083645; bh=Dp0lebhul2P2K4IcO7IZQ1MVbZy5QYUSMQf9Ljll2HU=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=EoFEOqdeImzK5iF3vhhwwpIuWYStJ+HdpVL8f8bJIdffKBbZlk1ODwbHRF8SiKcft AmA7xFWCSGhpsxw5fYBgrWmbcaAyPPTEKOFphVKlzm2sBPtudYxhaIMoD7HBIdQnIE mxS+QWpBXv7OXdJOxdzR53HXH/2qrVsrzeee3PVc=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx005 []) with ESMTPSA (Nemesis) id 1MXp9i-1k1EzB1tJE-00Y841; Mon, 14 Sep 2020 13:40:45 +0200
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_660BE7D3-B99C-4AD6-9DE8-A8799038BE9A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
Date: Mon, 14 Sep 2020 13:40:42 +0200
In-Reply-To: <>
Cc: Ole Troan <>, "" <>
To: "Bernie Volz (volz)" <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.15)
X-Provags-ID: V03:K1:5LEe1vrWNNLogxk+y3kkgFnGpzNyRTswr0mFZCiwMLH06uJRmtw hWXOazR2vvbWRlBKehd2nVekeqK5tJI7SHhmgxrbQ32UJkESBpNZJYN5O2iOVnYXKMUOWEa mGd2JTP+9z6bYOmNOsCqayU85tqtZeVKvfsT1uhbMH6LWYeUu8uffq7ojElUHbWjwBAMjwd nM0cFPZIU/jk1ET+dUr3Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:1WaZbdwNkis=:ETCSlqbSdCvrHB0GGKdX8g pVnSwR4xEINWWQnYXsF4mRd5movJhXhlkZYpwd3XjdwWYdNEMeHw/UVxt6iFu4keAU8tPCKp0 N4ov5ZRdZq25Ge6W9cOZgq6x41R00EF28TJHGWQi3914DjoJz27hZvrFuSKKYvICNgw/i1+9e afMc1cOMbUnTPIjHC7u4/0o8IcjNYRa/jfiLM2jFbAEZzFkzXKBCimy1D82GfwbUsseJ+vHdS L+GrzjA255BwZMOtE9JjK61lZVTaSLg3TzD1C4bkTzI1Mby1Mq2DKH4dUAH7XvUzD0d9ii3/4 lkLHFEjF8RZLD7ydzFiiAFNBd9qsIaPibxpz9DsPAT1UsUvz8aaTAzJ7fM7O0VwAGiT8aw8wM YltMIV11B1ePMn9/FbG2ZpjqDm2EYjh+Meqw7hm57QETeuYpol3mg07j2Y6UZ6ZsBnBIfdNOd N9CvHjPPoc0uMXN7CWnU88kdMjbL7F8qk+PpzSUplrDoUQLAsBxSmz7cw5/1xlQsDDRkvbfOl lg7g6imQUMjdB335L+Tr0iLtspAgxBOKpWLvBsIH74Mdogozg8Z6XRTw7HmZ37/DjBRFfdePm wVactqCkDQwAx6mtlOaa41hox4o+nXvSd2qpxMJKoTPhPJvIkTyQrRm5pz1271OnRmuhhEpgc dDc6mN2oq7629ywuAvKdfuFEXz1OekJFG8X8mXqGjVzV0EySEypdnvyt+KjSson2SJcWxbEe3 UguVxBmRyDkOOJ6RBf4Cmn8TRQx+FnyxHFi6dz2sJY9oTMc4EKOjTCL+Ekbj546gZQs/icZZW 2uXEgWAe3Qym97Cxa6Ujl7Lkt2rWNSq1m+CUQXLbuSt/lg5qXhivIzD+3rzv0DD4Unsc//t31 lNFEegPGER5dUHCCMBcgI2TSmPmd3//mipSUBQ6a3bFHGmOHr2lXeSB4hMRTa7u/xKLAEcJ6X 5kEmZv09OwHXzfXYeZekoy8jyAE8O01jx8PbOohPD6azrbOiBunai6ScV/l31GTCgT6TpZ0ko ZkxaY/MOU2SSuqhAScpyt02v5wn8HXi2e54jc8kr4iLLZN57ZTNNUwvKozJDKZjaSOgEH79xO acrUFvTBVcQTIpA1/eo50xxVXDR94liH4+BuAmXN798em4wO6v9t4qrfoQb96qhXvRedX0yPG TIlJ1scEVJr9NRucapD5/pnCJxpN2trX3/WSuZWGfwocpLO3Po0mjDlgCN+CtA11gmEZIqz5o 3R8b0K5wW1lV1XWumb1MLUy+OOpikcrVub+PVzQ==
Archived-At: <>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Sep 2020 11:40:59 -0000

Hi Bernie,

Thanks for your response. Please see inline below.


>> On 19. Aug 2020, at 00:15, Bernie Volz (volz) <> 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.
> 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."

> BV> Additional question ... RFC7084 has WPD-5 and they added an (a) about ICMPv6 Destination Unreachable ... do you want to say anything about whether to send ICMPv6 or not (probably not)?

[if - I think it makes sense. I’ve added the following to R-4:

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.]


>> 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.]
> BV> So, I'm not sure what the plan is with respect to this text? DHCP has a generic time synchronization problem in that everything is relative to when received (not necessarily transmitted) and resolution is seconds and no strong requirement for clocks to tic consistently. This is often why grace periods are applied to lease expiration times (though in most cases, this is probably also not necessary given that the client is probably not there as otherwise it would have renewed).

[if - I’m a little confused as to which text you’re referring to now. The original comment was related to the ‘..issues such as timer synchronization between..’ wording in the abstract. The abstract text has now been replaced using Ted’s suggested wording and does not mention timers at all. This is the current abstract 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 result in routing
    failures. To address these problems, this memo provides necessary
    functional requirements for operating DHCPv6 relays with Prefix

   It is recommended that any network operator that is using DHCPv6
    prefix delegation with relays should ensure that these requirements
    are followed on their networks.

Req G-8 is for DHCP lease timer synchronisation:

    G-8: The delegating relay MUST update the lease
    lifetimes based on the Client Reply messages it forwards to the
    client and only expire the delegated prefixes when the valid
    lifetime has elapsed.]