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

Ted Lemon <> Sat, 01 August 2020 16:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 640343A07A8 for <>; Sat, 1 Aug 2020 09:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z1FII62qvDOp for <>; Sat, 1 Aug 2020 09:33:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 199A53A077C for <>; Sat, 1 Aug 2020 09:33:50 -0700 (PDT)
Received: by with SMTP id 2so27586087qkf.10 for <>; Sat, 01 Aug 2020 09:33:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8qlHdv7K4K+F+/vax2wOiAeKam5BWCKAUmnb5Zm1tVI=; b=WfCNJekjEYEt62hJiuDsFXg9v0UKPhcF1ZbYuK1t/iCpSgLdlDUbp1KXMDlKOhwfCA LRUsC6HikJdfiJpj2f/NVjDMOA9t5/si/nDvo5PFedPy+rqD+idv9tOGepXgmTZ90RT8 xu0KA+pOKaYor3h88R+QQhDAzNzO4cfcjGLSQ1mBqZmGCzlgNsSpZisOtd+PIK3MS7MZ 6jSrGx//uwyd4p9S3Xm7jtFVZCefWii/SgvYLxhOFKrRLf8Ftg11qstFwOgo5NHNamFm Z1puXAERxnkuY81vM4LAoG/xYOLq2iIobD1eSIWuYFIJHe8eimwonhsBFITM3eAtHjCN ZdVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8qlHdv7K4K+F+/vax2wOiAeKam5BWCKAUmnb5Zm1tVI=; b=t+dEgHgHsN8c4YyZQvrPbIQAI3GMXHH/sYX0x+GfBjTfSbiJN79qSPBmsIW0UPYBlG eSPWbgFR3fh1scqmX0oUgvbQTEBFGHw4o/GxHwmeu6mbcCFDLmjcA90wLllkEmhZjqy+ +X4JKEjAkp6Wzs3Kzq+zizY8TqXIo9X5zvNe3xuwj0KjcemrEABMyGR6cN04hmnPee5z lp+JKKsGd7ik1Uwri6ouRf9H59ljDnKlcEfXQogbaAqWNspNbqupj3EaphY67K10I+5q nNwsr164rUEQTv4COoPZrH/c7VcbuXJpLR38JVSEJSUylm9rAzKFxDlObC0glV659DrH zymw==
X-Gm-Message-State: AOAM532f83dLrvBipEa66SBeJewEKsRPMi6E55Y7a0kMzLjjwbo64ZWW cpJ30aStVTQ0o+nddufjjeLG0w==
X-Google-Smtp-Source: ABdhPJwauH7XWQ+c93JV5F2ohf0wEwMuKMhDO4X1xRvq8ibSVIbjJIIJOiDvX/FKo3r0coC7eq/gug==
X-Received: by 2002:ae9:e882:: with SMTP id a124mr9078756qkg.24.1596299629894; Sat, 01 Aug 2020 09:33:49 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:566:cf88:3411:60f7? ([2601:18b:300:36ee:566:cf88:3411:60f7]) by with ESMTPSA id t83sm12341057qke.133.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Aug 2020 09:33:49 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Ted Lemon <>
In-Reply-To: <>
Date: Sat, 1 Aug 2020 12:33:47 -0400
Cc: "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Bernie Volz (volz)" <>
X-Mailer: Apple Mail (2.3608.
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: Sat, 01 Aug 2020 16:33:55 -0000

I think the document is important, and I support advancement. Some observations:

The abstract is quite long and doesn’t accomplish the purpose of telling the reader why they should read the document. Suggestion:

This memo describes operational problems that are known to occur when using DHCPv6 relay 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 relay with Prefix Delegation. 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.

In the introduction:

> Multi-hop relaying is also not considered as the functionality is solely required by a DHCP relay agent that is co-located with the first-hop router that the DHCPv6 client requesting the prefix is connected to

I didn’t actually see anything in this document that wouldn’t work for stacked relays.

In 2.1, it would be nice to have references here, if you can find stable pointers:
> In CableLabs DOCSIS environments, the Cable Modem Termination System (CMTS) would be considered a delegating relay with respect to Customer Premises Devices (CPEs).  A Broadband Network Gateway (BNG) in a DSL based access network may be a delegating relay if it does not implement a local DHCPv6 server function.

3.1, you introduce the concept here that the delegating router has a “lease”.  This is actually a new concept and should probably be explained. I assume that what’s meant here by “lease” is “route”. Routes can have preferred and valid lifetimes. Does it make sense to just use the term “route” rather than “lease?”  Is there information _other_ than routes bound to these leases?  It seems like you used the term “lease” in 4.1, but then switch to “prefixes and associated next-hops” in 4.2, but you probably mean the same thing in both cases, so defining the term here would help.

G-1, you should word this in a way that doesn’t make the reader wonder if encapsulating the message is okay. Obviously that’s the intent, but it would be worth removing that doubt by saying so explicitly. Also, do you mean “delegating router” or “delegating relay?” It doesn’t make sense to me if you really meant “delegating router."

G-2, you might consider framing this as “the relay MUST NOT discard messages because it doesn’t recognize one or more options in that message.”

G-5, I think by “device” you mean delegating relay; if so, should say so explicitly, because otherwise it’s a bit confusing. I suppose part of the problem is that you are saying that interfaces implement the delegating relay function, which seems weird. Maybe “A delegating relay may have one or more interfaces on which it acts as a relay, as well as one or more interfaces on which it does not (for example, in an ISP, it might act as a relay on all southbound interfaces, but not on the northbound interfaces). The relay SHOULD allow the same client identifier… etc

G-6, is a /60 one prefix or sixteen?

G-8, why “at least 8” and not “at least 16” or “at least 4”? Are these /64s, or /56’s, or doesn’t matter?  I ask because one model for doing this would be to just allocate /64s piecemeal to clients that request them, and to layer delegating routers to make the routing work, rather than delegating a whole /56 or /48 to each customer.  Is that what you have in mind?

R-2, do you need to specify that in addition to maintaining access control lists, the router needs to block packets from invalid sources?  The term “access control list” is not used in BCP-38. Is there a more recent reference that explains this, or does it need to be explained here?

R-4, is the goal to prevent routing loops? I’m not clear on why this needs to be said.

S-1 doesn’t completely solve the problem: there is no required behavior. Do you mean that the relay MUST do one of the two proposed solutions, and MAY do both, or do you really intend to leave this as a potential gap?

S-3 why MAY and not SHOULD?

O-2: how does this interact with active leasequery?

Thanks for working on this (authors)! Let me know if what I said doesn’t make sense. :)