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

ianfarrer@gmx.com Thu, 08 October 2020 13:33 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 41FA13A0B93 for <dhcwg@ietfa.amsl.com>; Thu, 8 Oct 2020 06:33:20 -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 W-Im91lReoWA for <dhcwg@ietfa.amsl.com>; Thu, 8 Oct 2020 06:33:17 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 1023F3A0B80 for <dhcwg@ietf.org>; Thu, 8 Oct 2020 06:33:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602163994; bh=OshrSqsYuYV3jB2up/O8Tm5LRQkyj7l3HAWQM55es4A=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=X1XVy5QQ+qrdrshlZOcUWhpXUzxdihkMYCWgkhntJHHru8XlkpXaxRO9LKHeHArs2 wWBnzvkt20QvydZ0D0SkEGgRwYl6Iid/aSsv5J4YaWiCtWaYXMxZsS/Eq/NuYL9wfh FdeZ6Wzpylj7jhESX8/F3p+xUcqRkcxL6fspj7bo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.128.43] ([87.79.171.64]) by mail.gmx.com (mrgmx004 [212.227.17.184]) with ESMTPSA (Nemesis) id 1MQ5rO-1k4ZL80cRk-00M560; Thu, 08 Oct 2020 15:33:14 +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: <21b04a09-758c-44ce-2357-10fee16780d2@gmail.com>
Date: Thu, 8 Oct 2020 15:33:13 +0200
Cc: dhcwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <87A86029-D0A3-48DC-85F6-518736F94A44@gmx.com>
References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <21b04a09-758c-44ce-2357-10fee16780d2@gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
X-Mailer: Apple Mail (2.3445.104.15)
X-Provags-ID: V03:K1:hGpsTKeMhcGWsX/6lmdehMcW94Qt9jAPpEOQCXWONmBSa/V4qZD 6F+SRKkc1Ss5wXy2Jw1AmO/iWobBbU5jg4Z466w5ec6lrzUUHFQ51m7DHbEfVlwwXKFyDWe r9oiwx+XSMm9rMlJFM80IJ8XKDIQmXzovB3qFWpFleM9rhSkRXriUEIpeDIOQReg999vHxH kg5RkbefhBQtNV9jxHSTQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:TZUK11Owdh0=:GsjUm4qFBcj8QEhnUW80MJ DJqz83HpfIckZI2gbH9SuZXmceY0Q6j/NIM2DxyzscRSLlYjkmMSee+ADekc05gr9Bdt0WD94 CBxpXMd1YUVdelFqlYshGiSHifwsE9MzlvXJTmni+05sxMC8fbeS/aDcx5CleLaNhvkHlukgY g6rHclTTvmbtXJqsFmWbDQGZmIfh/nftp869zlHa4bMae3ax+UOTwEK81lCpqAjmbg8pZXDRI wkVlc6k13XtMmJkXd2P53JxjRa7X0wKIYB8+4PnDtbeptPv1crV/yj1yAN7paONHXALX4S+eD sose7KMUAR+nJeW6Fli6FMEqdCVCZNgs5cxxqTrdcAnGUwW2GXRIjvzDvVhUOZoKMSs9i6Dhn rMp54wM2hgY3QF2Mp7WQPPR3Ft+xe+y/DAYugS6rFmQCij52bpyZoae/cOWI7f8vSd66Zp0kX GLHCRIL25+Jts3/GvqctDx6W3y6yGOQYUQjMr8DhRM8E8EQPAeuFlLORWia0Na9C75Db13Oys 9Iw1ueM3nO+Iv49s1J7/qIcBw1LEXeMcZ1QwIY2ZFcJxiGRSSg+ju97Tmn0lc75f+9IptHeAo /WFKDjSIgTElMveAHz9p2GXhDo336mBajZJQNnvjMlP2V2wZF4ASiA3HH+p3wqK3fdM8ADki4 JMIQ0tYul6njEUdL788mRIEisJUpgpcoSyzq9TAxHcYObeaTZiexQ5qE/OJfeGr0D3OzYgYI9 C0nsKq3ym0NDWslFMjz7NPPxG0DMMgMZ2CBoBhYqyxvp61RkZcdJgLLzXLIicg1Ug+4hl4fwK 940CX3cTiMvH+ekXFhM8W2WjujjrWENUx82NQzzPvesWM3HhDy9e+6reqOIs0dY3hYMXEuW3n +zVFZu8v9gg70234z9yErbDcW+ULEtm0M9qMmzN0psCN4+Nk6dt1FwFGaDHecuvsOHitgTu89 qBhDemgdof7RgAUGEU3yJ23azNDYmuBjFZpuZu0/Y0WN09eeR65eKt8NslCw7pFayjXxsTSVv oGEjc/8N3NWgJ5KiWuQYeq/YYe+9uwI10qfXMgyfv39x7x2iZzUsBeL8jXuu6v7I2q2amFmRg xBCPVUIFDYR2+qhtgWhGHu1eBqQbiSFPh7Goj4AhUNxeDzUzL/R3a/kVleSYDf2bPCpIk4fbU N0xseEQesh5ujGmZ7spsrhvn4KphepsIXSoTzuqnAlzURLRErEfjLgcy3TUkYzAdJWvTHHtdm K2HjtMX0qhIR2GAyg
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/Zl2hHrkikEZ2Lmr98N3-hLPrJjg>
Subject: Re: [dhcwg] 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, 08 Oct 2020 13:33:20 -0000

Hi Alexandre,

Thanks for your comments, please see inline.

Ian

> On 7. Oct 2020, at 12:38, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> 
> There are few things I could comment on here...
> 
> Le 07/10/2020 à 12:25, ianfarrer@gmx.com a écrit :
>> Hi,
>> We are currently finishing WGLC for this draft. It describes requirements for a 'DHCPv6 Delegating Relay' - this is a router functioning as the L3 edge and DHCPv6 relay (only) with prefix delegation. This is a common deployment scenario, but RFC3633/8415 only really describes PD using a Delegating Router - i.e the L3 edge also functions as a DHCPv6 server with no relay. When the relay and server functions are performed by separate devices a number of problems with how relays behave have
>> been observed, so this document addresses them.
>> During WGLC for this, Ole raised a comment related to one of the routing requirements:
>> 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.
> 
> 'within' the delegated prefix?  How is the operation of finding whether an address is within a prefix implemented?  REmember the 64bit limit is not frozen and as such a longest prefix match operation might be the only possible; such an operation is however not offering the result one might expect.  Lpm is good for matching an address among a few prefixes, but is not good for deciding whether an address is 'within' a given prefix.
> 
> 2. there is a new RFC now that suggests addition of an NC entry in router's table such that incoming packets to that Host dont get dropped.  Such an operation would contradict R-4.

[if - The operation would be via normal destination route lookup - if the dest address egress interface matches the ingress interface.

Do you have a number for the RFC that you mention?]

> 
>   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.
>> The problem that this is trying to solve is:
>> 3.5.  Forwarding Loops between Client and Relay
>>    If the client loses information about a prefix that it is delegated
>>    while the lease entry and associated route is still active in the
>>    delegating relay, then the relay will forward traffic to the client
>>    which the client will return to the relay
> 
> Will a client return a packet to relay?  Or will it generate an ICMP error carrying the packet?

[if - In the case described, yes. The client has a default route via the relay (learned via RA) so it will send it back to the relay.]

> 
> (which is the client's
>>    default gateway (learnt via an RA).  The loop will continue until
>>    either the client is successfully reprovisioned via DHCP, or the lease
>>    ages out in the relay.
> 
> I would dare to wonder whether such loop has been seen with a packet capture tool such as wireshark?  Or is it that we worry that such a loop might appear?  Both are valid points to consider.

[if - I’ve seen this in lab conditions a while ago due to a DHCP client bug]

> 
>> Ole’s comment: "And I would also be happy if we could have some implementors chime in with a "we are happy and able to implement this requirement”.”
>> We would appreciate any feedback on this, especially from anyone with experience implementing DHCPv6 relays with PD.
> 
> I do have some experience implementing relays and server doing PD, but it was some years ago.  The server was doing PD and the relay  just adding a route.  I dont remember having seen loops, but I have not tried the scenario described above (expiration of prefix lease).
> 
> Alex
> 
>> Thanks,
>> Ian
>> Current draft version: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requirements/ <https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requirements/>
>> _______________________________________________
>> 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