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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 1 Aug 2020 15:06:42 +0000

Hi:

The authors believe this document is ready for WGLC. Therefore, the chairs are initiating a WGLC on this document.

Please review this document and provide your comments and whether you support this document moving forward or not by end of day on Monday, August 17th, 2020.

Please see https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-01. This is a Standards Track document.

There are no IPR notices filed against this work (as of this writing).

Thank you!

  *   Tim & Bernie

--

From: Naveen Kottapalli <[email-masked]>

Sent: Saturday, August 1, 2020 8:20 AM

To: [email-masked]; [email-masked]

Subject: Requesting a WGLC of draft-ietf-dhc-dhcpv6-pd-relay-requirements

Hello chairs,

We, as authors of the draft, are of the opinion that the draft is ready for WGLC.  Can you please check and initiate the same?

Yours,

Naveen.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 1 Aug 2020 12:33:47 -0400

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. :)

---

From: Naveen Kottapalli <[email-masked]>
Date: Fri, 7 Aug 2020 09:15:25 +0530

Hello Ted,

Thanks a lot for the review.  Please find comments inline.

Yours,
Naveen

>
> On Sat, 1 Aug 2020 at 22:04, Ted Lemon <[email-masked]> wrote:
>
>> 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.
>>
>> Naveen] Will change the text as suggested.
>
>> 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
>>
>> > 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.
>>
>> Naveen] Will update.
>>
>
>
>> 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.
>>
>
>
>> Naveen]  Yes.  A mapping of route, incoming interface, lease timers,
>> etc., will be maintained against the lease.  Also, changed the prefixes to
>> leases in 4.2 as well.
>>
>
>
>> 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."
>>
>
> Naveen] Changed from delegating router to delegating relay
>
>>
>> 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.”
>>
>> Naveen] Done
>
>
>> 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
>>
>
> Naveen] Changed accordingly.
>
>>
> Naveen] One.
>> 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?
>>
>
> Naveen] It can be either /56 or /48.  The same lease that is given by the
> server will be maintained here.  There is not much logic behind the number
> 8.  Since the lease context information consumes memory, the reasonable
> number we came up with is 8.
>
>>
>> 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?
>>
>
> Naveen]  Changed accordingly.
>
>>
> Naveen] Yes.  This is added to be more explicit.
>
>>
>> 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?
>>
>
> Naveen] The idea is that relays MAY implement at least one of them to
> mitigate risk of reboot.
>
>>
> Naveen] Changed
> Naveen] This is an operational requirement at delegating relay node to
> clear the active bindings through CLI or REST API or any other means.
>
>>
>> _______________________________________________
>> dhcwg mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 11 Aug 2020 12:19:55 +0000

Hi … just a friendly reminder regarding this WGLC.

Thanks to Ted Lemon for reviewing and commenting!

  *   Bernie

From: Bernie Volz (volz) <[email-masked]>
Sent: Saturday, August 1, 2020 11:07 AM
To: [email-masked]
Cc: [email-masked]
Subject: WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

Hi:

Thank you!

  *   Tim & Bernie

--

Hello chairs,

Yours,

Naveen.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 17 Aug 2020 17:23:23 +0000

Hi … just a friendly reminder. We’ve had very little input to the WGLC.

Tim and I will review the responses and evaluate the WGLC later this week (Friday), so you do have a few more days to respond.

  *   Bernie

From: dhcwg <[email-masked]> On Behalf Of Bernie Volz (volz)
Sent: Tuesday, August 11, 2020 8:20 AM
To: [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

  *   Bernie

Hi:

Thank you!

  *   Tim & Bernie

--

Hello chairs,

Yours,

Naveen.

---

From: [email-masked]
Date: Tue, 18 Aug 2020 09:24:24 +0200

I have read through the document, reading section 4 thoroughly.
I think it looks fine and ready to advance.

A comment:

   R-4:    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.

I struggle to understand what R-4 is trying to say.
In one sentence it says it has a delegated prefix, then it says "not configured on the relay"...?

Best regards,
Ole

> On 17 Aug 2020, at 19:23, Bernie Volz (volz) <volz=[email-masked]> wrote:
> 
> 	• Bernie
> 	• Bernie
> 	• Tim & Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 18 Aug 2020 22:15:24 +0000

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?

Anyway, here's my comments for the shepherd review.

First, I do support this document moving forward.

Abstract:

"when the DHCPv6 relay function is not co-located with the DHCPv6 server function" is a bit weird as why would the relay even be needed in this case?

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?

I also wonder if the last paragraph should just say "for a DHCPv6 relay when used for relaying prefixes delegated". Is PD really need here?

Section 1:

"mentions the deployment scenario", perhaps change the to this?

"on its network-facing interface" is a bit unclear. Network is too generic. Perhaps to its "uplink interface" (see https://en.wikipedia.org/wiki/Telecommunications_link#Uplink).

I'm not so clear why the last paragraph is important. And, it doesn't translate into a requirement? Perhaps one should be added if you think this is worth pointing out (over and above what RFC8415 has). Note that section 3.1 deals more with known messages and 'acting as a server'.

Section 2.2:

s/The client request prefixes/The client requests prefixes/

Also, wonder if adding something about uplink / downlink to the Figure 1 might help in clarifying things elsewhere? Also, nice to give figures titles.

If you do add uplink/downlink, you could say "client facing (downlink) interface" or something similar.

Section 3.1:

s/delegating router/delegating relay/?

Would adding something about "or contains an unknown option" be useful to include here ... we don’t want relay's to not forward messages because they don't understand a "new" option? But this is already covered in Section 16 of RFC8415 (see below), so it may not be worth re-enforcing this as RFC8415 is already clear on this. I just raise it for your consideration (feel free to ignore).

   Clients, relay agents, and servers MUST NOT discard messages that
   contain unknown options (or instances of vendor options with unknown
   enterprise-number values).  These should be ignored as if they were
   not present.  This is critical to provide for future extensions of
   DHCP.

I might add that perhaps a new paragraph to this section that reads something like:

	Relay implementers are reminded that RFC8415 makes it clear that relays MUST NOT drop
	(and hence not relay) packets that either contains message codes (Section 19 of RFC8415)
	it may not understand or contain options that it does not understand (Section 16 of RFC8415).

Or perhaps just add to General Requirements?

Section 3.2:

s/delegating router/delegating relay/?

Section 4

Comment related to the requirements ... should these be tied back to the earlier sections? In some cases, it seems that requirements were added that aren't directly related to the earlier discussions? Should there be a "See section 3.x" added to identify where the requirement came from?

Section 4.1:
G-1 - This one is a bit weird as is "delegating router" correct"? Isn't this all about relays? But if this is just a general "ROUTER" requirement, is it really appropriate here? I think this is related to "relays" and hence it should just be "relay"?

Section 4.2:
I had issues with R-4 ... see Ole's discussion and the top of this message.

Section 4.4:
O-3: "delegating routers" -> "delegating relays"? See your terminology in 2.1.

Section 7:

This is a bit light and may want to reference Section 22 of RFC8415? Perhaps something about "This document does not add any new security considerations beyond those mentioned in Section 22 of RFC8415."?

- Bernie

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Tuesday, August 18, 2020 3:24 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

A comment:

Best regards,
Ole

> Please see https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-01.. This is a Standards Track document.
>

---

From: [email-masked]
Date: Thu, 20 Aug 2020 16:05:18 +0200

Hi Ted,

Many thanks for the review.  In addition to Naveen’s comments from 1/8, please see below.

Cheers,
Ian

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

[if - Rewritten to:

    Multi-hop DHCPv6 relaying is not affected, as the requirements
    in this document are solely applicable to the DHCP relay agent
    co-located with the first-hop router that the DHCPv6 client
    requesting the prefix is connected to, no changes to any
    subsequent relays in the path are needed.
]

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

[if - In addition to the route for the delegated prefix, the relay also holds information about the client that it is delegated to (client-DUID, IAID) and timers for the delegation.

We use the term ‘lease entry’ in the text as it is a record of the relay relevant info contained in the prefix lease, not just a routing entry. What about the following:

old:
   For example, the delegating router already has an active PD lease
   entry for an existing client on a port.

new:
   For example, the delegating router already has an active PD lease
   entry bound to the client DUID of an existing client on a port.
]

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

[if - The above change to the wording for multi-hop relaying above should clear this up.

Delegating router should be delegating relay. Changed.]

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

[if - One.

Actually, this raised an interesting point about scalability of prefix routing entries in the relay if every shorter prefix is rendered into a set of component /64 (I have a vague memory of seeing this happen somewhere). What about adding an R-5 with:

The delegating relay’s routing entry MUST use the prefix length for the delegated prefix as given in the IA_PD.
]

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

[if - Originally, the text just said that there should be a configurable limit without suggesting a value. Bernie’s review suggested that a default number should be given and we hit on 8 for want of a better value:

https://mailarchive.ietf.org/arch/msg/dhcwg/sk-IM5gSQPrIistauhD3defIMEo/

Also see comment above.]

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

[if - S-1 only gives a RECOMMENDED and then 2 possible solutions. RECOMMENDED was used here as some relay devices can be fairly simple wouldn’t be able to implement either of the options.

Suggest that RECOMMENDED in the S-1 text is changed to read:

"the relay SHOULD implement at least one of the following:”

and then remove the MAY/SHOULD from the proposed solution wording.]

> S-3 why MAY and not SHOULD?

[OK]

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

[if - It doesn’t, AFAICT. I haven’t actually seen a relay which implements active lease query, but the intention behind the requirement is to allow the operator to manually fix sync problems between the relay/server when they occur. Active leasequery may help reduce the occurrences of such problems, but doesn’t offer a mechanism whereby the removal of a lease binding entry on a relay could be used to signal to the server that the client’s lease is released.]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 21 Aug 2020 15:53:25 +0000

Hi:

Tim and I discussed the WGLC and once the comments raised (by Ted, Ole, and myself) are addressed, we will send the document on to the AD (hence, the WGLC passed).

Thanks much for those that commented during the WGLC.

  *   Bernie

Hi:

Thank you!

  *   Tim & Bernie

--

Hello chairs,

Yours,

Naveen.