Subject: [dhcwg] Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

From: Sunil Gandhewar <[email-masked]>
Date: Mon, 3 Aug 2015 15:58:38 +0000

Hi All,
I see total 4 comments after the presentation during IETF 93 at Prague on July 23rd, 2015 from Ted Lemon, Ian Farrar, Bernie Volz and Shrinivas Joshi. I am trying to compile and respond to these 4 comments. Please let me know if I missed anything or misunderstood any comments. There were few whom I talked offline and told me their use cases Tomek Mrugalski, Ole Toran, Marcin Siodelski, Suresh Krishnan. Thanks you all for comments and suggestions.

1. Ted Lemon: I think it's actually a good idea. Why do we need this for DHCPv6?  Looks good for v4. Would the hg actually reuse the lease in this case?  In case this comes up after meetecho dies, I favor adoption of v4 draft, don't see point of v6 draft, and if we need it for v6, it should be a single draft, because most of the v6 draft is just a copy of the v4 draft. there is no shortage of IPV6 addresses. I am willing to think harder about v6.

Sunil's Response: Thanks Ted for the comments and seeing the importance of the v4 case. Although this is usuaful in many areas, I have feedback from Service providers which provide Broadband Edge services. They explained that the resources on the Broadband Network Gateway (BNG), which delivers and manages the subscriber services are limited. These resources are similar whether it's for v4 subscriber or v6 subscriber (DHCP client). They are not much concerned about the number of addresses. It could be probably because they have the address range which they can use for their subscribers. But the BNG has fixed size of resources for routes, QoS, policy, other services. So the bottleneck they are facing is what can be supported by the box or resources on the box. Usually they oversubscribe, due to resources they need to scale the subscription rate differently. With PPP subscribers, connection breaks immediately and that subscriber re-establishes later. This feature is helpful for them for all their DHCPv4 and DHCPv6 subscribers (clients). I really appreciate if you can bring their perspective into picture. In the next comment Ian described the problem he is facing is for the v6 version.

Regarding merging the v4 and v6 drafts, I actually started with one draft. Since the terms (e.g. forcerenew/reconfigure) and options used for v4 and v6 are different, I tried with terms used for v6 in brackets which was not very easy to read with too many brackets. Then I tried with having separate subsections for v4 and v6. It was very clumsy document to read and one had to constantly skip sections for v4 and v6. Abstract and Introduction sections are like a copy-n-paste except the difference in terms used. It is because both the drafts are addressing the same set of problems. The 3rd section in both the documents is similar, except organized differently because RFC 3315 is organized differently from RFC 2131. I think it's easy to understand and implement if the organization of the extension is similar to the original RFC. Section 4 where the main functionality is described is very different. It is because the message format, options are totally different for v4 and v6. How the options can be included in one another in case of v6 also brings complexity. Section 5 security considerations is also different for both the versions. When I had combined version of the draft, it was difficult to understand for the reviewers and hence I separated them out. Now it is more clear and less confusing. I think it should be simple for any implementer. I feel simple is better than one big complex document as it is anyways for two distinct versions. I really appreciate if you can go through the sections 3, 4 and 5 in both the drafts and let me know your suggestion.

2. Ian Farrar: I experienced similar kind of problem where client got a lease for 2 days. In between he closed laptop and reopened next day. This will cause problems - Client will think it has a lease but it has gone from underneath it. I am talking about v6 case. Example with the STB being replaced is fine as it does not keep any states, but for the cases where terminal mgmt is done by keep alive mechanism is going to be hard.
3. Bernie Volz: Ian described a weird case where client has powered down without actually sending the release. It remembers the lease it has. There is no refresh. Network has old state and there is no good way to flush that. Include applicability statement that the circuit will go down and will have to reestablish - that will guarantee that the binding has to come back with the normal mechanism.

Sunil's Response: I am glad to know that more implementers came across similar problems, I am not alone.
In the draft I is mentioned that it can be configurable behavior at Relay as well as at the Server whether to support this functionality and in which cases. Our implementation has different knobs for initiating release on replacement and on detection of the client's unavailability. Initiating release on Administratively clearing binding is a separate CLI command. Thus there can be granular configurable control depending upon the situation. This will avoid the accidentally clearing the binding and the situation in the network where client might keep the state.

I consider this as client reboot. Hence v4 client should send init-reboot and for v6 case it should send Confirm message.
Tomek later clarified offline that in case of v6, confirm is a lightweight message, server need not go through the database lookup as in the case of v4. V4 RFC clearly specifies database lookup whereas v6 does not mention that. I am not sure about the reason. I do see that Juniper's server maintains state and goes through the database. So it may be implementation specific. Here I think it would have been good if server can reply with status code as NoBinding for the cases where binding is not present.

RFC 2131 page 31, last paragraph:
Determining whether a client in the INIT-REBOOT state is on the
correct network is done by examining the contents of 'giaddr', the
'requested IP address' option, and a database lookup. If the DHCP
server detects that the client is on the wrong net (i.e., the
result of applying the local subnet mask or remote subnet mask (if
'giaddr' is not zero) to 'requested IP address' option value
doesn't match reality), then the server SHOULD send a DHCPNAK
message to the client.

RFC 3315 page 40, last section:
18.1.2. Creation and Transmission of Confirm Messages
Whenever a client may have moved to a new link, the prefixes from the
addresses assigned to the interfaces on that link may no longer be
appropriate for the link to which the client is attached. Examples
of times when a client may have moved to a new link include:
o The client reboots.
o The client is physically connected to a wired connection.
o The client returns from sleep mode.
o The client using a wireless technology changes access points.
In any situation when a client may have moved to a new link, the
client MUST initiate a Confirm/Reply message exchange.

RFC 3315 page 50:
18.2.2. Receipt of Confirm Messages
If the server is unable to perform
this test (for example, the server does not have information about
prefixes on the link to which the client is connected), or there were
no addresses in any of the IAs sent by the client, the server MUST
NOT send a reply to the client.

Bernie, Ian, Tomek, how about following applicability statement as section 1.1 (under introduction) in v6 draft only:
Applicability Statement:
The state of the client binding gets cleared from Relay towards the Server. If client maintains the state across reboots (e.g. client does not send release on power down and remembers the address and lease period on reboot), it may start using the address for the remaining lease period. This will cause network issues as Relay and Server had cleared the binding whereas client is still using old state. This document is applicable only if the clients DOES NOT remember the state and MUST reestablish the binding when powered on. The binding MUST come back with the normal mechanism.
This will not be useful even if the client sends Confirm message unless Server responds with Status Code of NoBinding.

4. Shrinivas Joshi from ALU: - Described a case where this is useful where ONT moves across networks and also prefixes also moves.

Sunil's Response: Again I am glad to know that more useful cases where this is applicable, thanks.
Shrinivas, I could not clearly get the exact use case. I appreciate if you can describe that here in the ML. Also you asked me to check with some folks, can you please point me to them. Thanks

Here are the links to the drafts for easy reference:
DHCPv4 version: https://tools.ietf.org/html/draft-gandhewar-dhc-relay-initiated-release-00
DHCPv6 version: https://tools.ietf.org/html/draft-gandhewar-dhc-v6-relay-initiated-release-00

Regards,
Sunil Gandhewar
Juniper Networks, Inc.
[email-masked]<mailto:[email-masked]>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 3 Aug 2015 17:13:27 +0000

My concern is actually a case where a device has no knowledge that it has been disconnected. For example, the "modem" device is separate from the home router (or other CPE devices) and there is not be a 'signal' between them that the home router (or CPE) uses to re-initialization (Init-Reboot or Confirm/Rebind for v6). If loss of the "modem" connection causes the removal of both the modem's lease and the device(s) behind the modem, these device(s) may not know that this has happened and continue to use stale information.

The problem is that in some networks you have no way of knowing this (it depends on the end device(s) and how they are connected).

That is why I think that this document has to expose these issues so that this feature is ever only enabled in environment where this can be controlled (and behavior is known) or the risks with using this capability are clearly understood.

Other comments:

Section 4.1.1 (in two place similar text):

   If configuration allows, relay MAY choose to add Interface-Id option

   [RFC3315<https://tools.ietf.org/html/rfc3315>].

I'm not sure what "if configuration allows" and when this would be configured. 331 has that a relay may include this option, so why not just do that (i.e., drop "If configuration allows,")?

Also for:

   o  Include options containing the IAs for the addresses it is

      requesting to be released.

I think the text needs to be more clear what this should contain. Should it include the IA_NA, IA_TA, IA_PD options or just IAADDR and IAPREFIX? (The fact that one of the status codes is NoBinding might imply IA_NA/IA_TA/IA_PD, but not sure.)

5<https://tools.ietf.org/html/draft-gandhewar-dhc-v6-relay-initiated-release-00#section-5>.  Security Considerations
   In order to prevent using RELEASE-REQUEST messages as a denial-of-
   service attack on the DHCPv6 servers, DHCPv6 relay agents SHOULD
   combine release requests for multiple clients in one RELEASE-REQUEST
   as explained in Section Section 4.1.1<https://tools.ietf.org/html/draft-gandhewar-dhc-v6-relay-initiated-release-00#section-4.1.1>.

I do not follow the reasoning here.

Regarding Ted's question about v4 vs v6, while there are plenty of [v6] addresses, perhaps the Prefix Delegation space is more restricted and therefore that would be a more reasonable application. But as Sunil points out there is other state associated with addresses so if the "relay" device is dropping the state anyway, no reason not to inform the DHCP server as to that fact as well.

-          Bernie

From: Sunil Gandhewar [mailto:[email-masked]]
Sent: Monday, August 03, 2015 11:59 AM
To: [email-masked]; [email-masked]; Bernie Volz (volz); JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)
Cc: Tomek Mrugalski; [email-masked]; [email-masked]; Sunil Gandhewar; [email-masked]; [email-masked]
Subject: Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

Hi All,

RFC 3315 page 50:

Regards,
Sunil Gandhewar
Juniper Networks, Inc.

---

From: Sunil Gandhewar <[email-masked]>
Date: Mon, 3 Aug 2015 17:48:17 +0000

Hi Bernie,
Thanks for the quick reply.

There can be network issues and protocol issues, although one leads to other. The issue is due to the client not sending Release when it's done.
In the scenario you described, devices may be having private network address from the server running on the modem, right? Whereas the modem will actually get the public address from the network.
I agree that in some network topology there is no way of knowing this to the device. Hence I added the applicability statement as per your suggestion.
When I and Ole Troan were discussing, he told the network case he worked with where end device runs BFD and sends BFD packets on the interface towards the BNG with destination address of it's own. So BNG kind of loops-back the BFD packets. That way end device detects network connectivity.
What do you suggest, does the applicability statement I added is enough? Or shall I describe these network cases in that section?

I accept the comment regarding the interface-id.

>>> I think the text needs to be more clear what this should contain. Should it include the IA_NA, IA_TA, IA_PD options or just IAADDR and IAPREFIX? (The fact that one of the status codes is NoBindin…
Yes it means all the tyoes of IAs i.e. IA_NA, IA_TA and IA_PD. Should I mention that more specifically?

Regarding security considerations, multiple client data can be combined into one message under Client_Data_option. Thus it can avoid too many messages i.e. need not be one message per client.

Regards,
Sunil Gandhewar
Juniper Networks, Inc.

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Monday, August 03, 2015 10:43 PM
To: Sunil Gandhewar
Cc: [email-masked]
Subject: RE: Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

Other comments:

Also for:

-          Bernie

From: Sunil Gandhewar [mailto:[email-masked]]
Sent: Monday, August 03, 2015 11:59 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Bernie Volz (volz); JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)
Cc: Tomek Mrugalski; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Sunil Gandhewar; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

Hi All,

RFC 3315 page 50:

Regards,
Sunil Gandhewar
Juniper Networks, Inc.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 3 Aug 2015 18:01:25 +0000

> Regarding security considerations, multiple client data can be combined into one message under Client_Data_option. Thus it can avoid too many messages i.e. need not be one message per client.

I understand that combining. But your security considerations doesn't really mean anything with this respect. This does nothing related to Denial of Service.

I am thinking about the DOCSIS case where there is a CPE in the home connect to a cable modem. In this case, the CPE gets a lease just as the CM does. And while your document doesn't explicitly mention this case, I think it can easily be seen to extend to it - i.e., a Relay Agent (CMTS in DOCSIS) that determines the modem is no longer 'on-line', might decide it can discard BOTH the modem and CPE leases (since the CPE lease is associated with that modem) and that could be a mistake when the CPE may have no knowledge that the modem went offline and therefore the relay 'released' its lease. When the modem goes back online, it will get a new lease; but the CPE never knew this happened and therefore does not obtain a new lease or take steps to 'confirm' its existing lease.

You might not be directly considering that case, but without proper language in the document, there is nothing to preclude using these capabilities in that case.

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Sunil Gandhewar
Sent: Monday, August 03, 2015 1:48 PM
To: Bernie Volz (volz); [email-masked]
Subject: Re: [dhcwg] Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

Hi Bernie,

Regards,
Sunil Gandhewar
Juniper Networks, Inc.

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Monday, August 03, 2015 10:43 PM
To: Sunil Gandhewar
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

Other comments:

Also for:

-          Bernie

Hi All,

RFC 3315 page 50:

Regards,
Sunil Gandhewar
Juniper Networks, Inc.

---

From: Sunil Gandhewar <[email-masked]>
Date: Tue, 4 Aug 2015 14:52:22 +0000

Hi Bernie,

I think since multiple client data can be combined into one packet, it improves on packet-flooding DoS attacks.

I understood now the case where device is behind the CPE. I am wondering what might be better way to document this. I am trying to cover both the caases below, the one Ian pointed out and the one you explained below. Do you think more explainatory examples are needed here? Does this description below would be enough to exclude the cases due to the network? Please suggest. Thanks a lot Bernie.

Applicability Statement (section 1.1 under Introduction):
With the Relay Initiated Release, the DHCP client's binding gets cleared from Relay towards the Server. There is no way to inform this to the client. If client maintains the state across reboots (e.g. client does not send release on power down and remembers the address and lease period on it's reboot/wakeup), it may start using the address for the remaining lease period. This will cause network issues as Relay and Server had cleared the binding whereas client is still using it's old state. This document is not applicable where client remembers states across it's reboot. For Relay Initiated Release to function properly, client MUST reestablish the binding on every power-on. The binding MUST come back with the normal mechanism on every power on.

In the network topology where DHCP client is not directly connected to the relay, when the network connection goes down relay would initiate the release and clear the binding for the client in the network. When the network connection comes back up, client has not actually powered off/on, and so client will continue to use the address it was using. Relay Initiated Release should not be used in such cases where there is no clear way to distinguish between network issue and client actually went off.

Relay Initiated Release is useful in the cases where there is a way to clearly know that the client actually went down, replaced or moved and will re-establish the binding when comes back.

Regards,
Sunil Gandhewar
Juniper Networks, Inc.

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Monday, August 03, 2015 11:31 PM
To: Sunil Gandhewar; [email-masked]
Subject: RE: Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Sunil Gandhewar
Sent: Monday, August 03, 2015 1:48 PM
To: Bernie Volz (volz); [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

Hi Bernie,

Regards,
Sunil Gandhewar
Juniper Networks, Inc.

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Mon, 17 Aug 2015 04:23:47 +0000

Sunil,

> Shrinivas, I could not clearly get the exact use case. I appreciate if you can describe that here in the ML. Also you asked me to check with some folks, can you please point me to them. Thanks

[Shree] The use case is for a IPV6 L3 DHCP relay which adds/removes routes based on snooped prefixes,  in case the subscriber moves to a different relay port/equipment the route advertising the prefix should also move with the device.
This is more commonly seen in Cable use cases, I would suggest you check with one of the MSO operators (TWC/Comcast) or packetcable for use case applicability.

Sent: Monday, August 03, 2015 9:29 PM

Hi All,

RFC 3315 page 50:

Regards,
Sunil Gandhewar
Juniper Networks, Inc.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 17 Aug 2015 13:33:53 +0000

Just to be clear these are my personal comments and not as WG co-chair.

> If client maintains the state across reboots ... client MUST reestablish the binding on every power-on ...

There are cases where a reboot is not even necessary. Think of a Cable Modem with a CPE with some kind of bridge between them that does not provide any signaling when the CM link is dropped. In this case, the CPE will happily continue to try to use its lease(s) until they expire. There is no reboot of the CPE (or CM) involved.

This may be what your 2nd paragraph is trying to say? But I'm not sure what "client is not directly connected to the relay" means.

The applicability statement is difficult for this work because it is fairly complex - the kind of places this will work when there are multiple devices (such as CM + CPE) involved is pretty tricky. For a device that has a virtual circuit to the relay, it is pretty straight forward - if the virtual circuit goes down, the device will have to reestablish the circuit and also do DHCP. But for other devices 'behind' this device, it is less clear as you do not know if they are keeping state or not.

Also, in cases where a circuit may be bouncing up and down, there could be interesting timing issues - especially if the relay to server network connection itself is multi-path or bouncing ... think what would happen if a (early generated) release is delayed in the network and the DHCP client has in the meantime done a Solicit/A/R/R (which renewed the existing lease) ... the delayed packet will result in the lease being released when it should not have been since the client just reestablished it. You would have to deal with this issue on out-of-order packets between relay and server.

Anyway, I am really skeptical whether the complexity of doing this is worth it. And even more so in v6 as there at least for addresses, we have no shortage (and hopefully the same can be said for prefix delegation, but clearly the space available there is less than for addresses).

-          Bernie

From: Sunil Gandhewar [mailto:[email-masked]]
Sent: Tuesday, August 04, 2015 10:52 AM
To: Bernie Volz (volz); [email-masked]
Cc: Sunil Gandhewar
Subject: RE: Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

Hi Bernie,

Regards,
Sunil Gandhewar
Juniper Networks, Inc.

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Monday, August 03, 2015 11:31 PM
To: Sunil Gandhewar; [email-masked]<mailto:[email-masked]>
Subject: RE: Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

-          Bernie

Hi Bernie,

Regards,
Sunil Gandhewar
Juniper Networks, Inc.

---

From: Sunil Gandhewar <[email-masked]>
Date: Mon, 17 Aug 2015 16:25:31 +0000

Thanks Shree.

Hi Jason,
I really appreciate if you can please elaborate the use case Shree is mentioning here.
Basically it also falls in the category of relieving the resources due to the client move. Otherwise clients will use resources at 2 places.
Similar cases are also their in the mobile world where moves are very frequent.

Regards,
Sunil Gandhewar
Juniper Networks, Inc.
[email-masked]

From: JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) [mailto:[email-masked]]
Sent: Monday, August 17, 2015 9:54 AM
To: Sunil Gandhewar
Cc: Tomek Mrugalski; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Bernie Volz (volz)
Subject: RE: Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

Sunil,

Hi All,

RFC 3315 page 50:

Regards,
Sunil Gandhewar
Juniper Networks, Inc.