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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 07 October 2020 10:38 UTC

Return-Path: <alexandre.petrescu@gmail.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 5DB523A08B9 for <dhcwg@ietfa.amsl.com>; Wed, 7 Oct 2020 03:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.458
X-Spam-Level: *
X-Spam-Status: No, score=1.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.213, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 eQ6iQz5mxiaj for <dhcwg@ietfa.amsl.com>; Wed, 7 Oct 2020 03:38:53 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 8258E3A08B8 for <dhcwg@ietf.org>; Wed, 7 Oct 2020 03:38:53 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 097AcpWi031393 for <dhcwg@ietf.org>; Wed, 7 Oct 2020 12:38:51 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 934AF204298 for <dhcwg@ietf.org>; Wed, 7 Oct 2020 12:38:51 +0200 (CEST)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8916C20362D for <dhcwg@ietf.org>; Wed, 7 Oct 2020 12:38:51 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 097AcpOQ014977 for <dhcwg@ietf.org>; Wed, 7 Oct 2020 12:38:51 +0200
To: dhcwg@ietf.org
References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <21b04a09-758c-44ce-2357-10fee16780d2@gmail.com>
Date: Wed, 7 Oct 2020 12:38:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2
MIME-Version: 1.0
In-Reply-To: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/1BkXkGViDU5rjcgJngWyl-gR9Hg>
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: Wed, 07 Oct 2020 10:38:55 -0000

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.

   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?

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

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