Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 08 October 2020 14:03 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 97D953A084A for <dhcwg@ietfa.amsl.com>; Thu, 8 Oct 2020 07:03:02 -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_H3=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 wKz8HONFB5eq for <dhcwg@ietfa.amsl.com>; Thu, 8 Oct 2020 07:03:01 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 B3CE73A03EC for <dhcwg@ietf.org>; Thu, 8 Oct 2020 07:03:00 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 098E2wJw001914; Thu, 8 Oct 2020 16:02:58 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 15AB7205039; Thu, 8 Oct 2020 16:02:58 +0200 (CEST)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 07640205007; Thu, 8 Oct 2020 16:02:58 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 098E2vmu024053; Thu, 8 Oct 2020 16:02:57 +0200
To: ianfarrer@gmx.com
Cc: dhcwg@ietf.org
References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <21b04a09-758c-44ce-2357-10fee16780d2@gmail.com> <87A86029-D0A3-48DC-85F6-518736F94A44@gmx.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <17168193-2d96-14b2-17b0-6a5c3dc07c22@gmail.com>
Date: Thu, 08 Oct 2020 16:02:57 +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: <87A86029-D0A3-48DC-85F6-518736F94A44@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/TUSfLQ7RdJbld7yvzGHTTdtxlqk>
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 14:03:03 -0000
Le 08/10/2020 à 15:33, ianfarrer@gmx.com a écrit : > 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?] Sorry, I meant to say it is an RFC in the making. It is draft-ietf-6man-grand-03. In it is suggested the addition of an NC entry, as I see it. >> >> 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.] I dont think the Host would forward a packet that it received, further to its default router. It would do so only if it originated it. > >> >> (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] A-ha. Alex > >> >>> 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 >
- [dhcwg] Question to DHCPv6 Relay Implementors reg… ianfarrer
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… Alexandre Petrescu
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… otroan
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… otroan
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay I… Templin (US), Fred L
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… Michael Richardson
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… Jen Linkova
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… ianfarrer
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… Alexandre Petrescu
- Re: [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Rel… Templin (US), Fred L
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… ianfarrer
- Re: [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Rel… ianfarrer
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… Michael Richardson
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bernie Volz (volz)
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Templin (US), Fred L
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Ole Troan
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Templin (US), Fred L
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Templin (US), Fred L
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bernie Volz (volz)
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Jen Linkova
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Jen Linkova
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… Jen Linkova
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bjørn Mork
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Ole Troan
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bjørn Mork
- Re: [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Rel… Jen Linkova
- Re: [dhcwg] Question to DHCPv6 Relay Implementors… ianfarrer
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Templin (US), Fred L
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Michael Richardson
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… ianfarrer
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bernie Volz (volz)
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Templin (US), Fred L
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … ianfarrer
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Michael Richardson
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Ted Lemon
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Ted Lemon
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Philip Homburg
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Michael Richardson
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Bob Hinden
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Bob Hinden
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Bob Hinden
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Michael Richardson
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Michael Richardson
- [dhcwg] how do routers with DHCPv6 relays learn w… Michael Richardson
- Re: [dhcwg] [EXTERNAL] [v6ops] Re: Question to DH… Bob Hinden
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Jen Linkova
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Jen Linkova
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bernie Volz (volz)
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Templin (US), Fred L
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Templin (US), Fred L
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … otroan
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Timothy Winters
- Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay … Ted Lemon
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Templin (US), Fred L
- Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question t… Ms. Li HUANG
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… ianfarrer
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Michael Richardson
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… ianfarrer
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Michael Richardson
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Jen Linkova
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bernie Volz (volz)
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Timothy Winters
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… Bernie Volz (volz)
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… ianfarrer
- Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DH… ianfarrer