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

Sunil Gandhewar <sgandhewar@juniper.net> Mon, 03 August 2015 17:48 UTC

Return-Path: <sgandhewar@juniper.net>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7931B2D6A for <dhcwg@ietfa.amsl.com>; Mon, 3 Aug 2015 10:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 ntUmcvCA2UNP for <dhcwg@ietfa.amsl.com>; Mon, 3 Aug 2015 10:48:21 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD8E1B2D67 for <dhcwg@ietf.org>; Mon, 3 Aug 2015 10:48:20 -0700 (PDT)
Received: from BLUPR0501MB1043.namprd05.prod.outlook.com (10.160.35.142) by BLUPR0501MB881.namprd05.prod.outlook.com (10.141.254.152) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 3 Aug 2015 17:48:19 +0000
Received: from BLUPR0501MB1043.namprd05.prod.outlook.com (10.160.35.142) by BLUPR0501MB1043.namprd05.prod.outlook.com (10.160.35.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 3 Aug 2015 17:48:17 +0000
Received: from BLUPR0501MB1043.namprd05.prod.outlook.com ([10.160.35.142]) by BLUPR0501MB1043.namprd05.prod.outlook.com ([10.160.35.142]) with mapi id 15.01.0225.018; Mon, 3 Aug 2015 17:48:17 +0000
From: Sunil Gandhewar <sgandhewar@juniper.net>
To: "Bernie Volz (volz)" <volz@cisco.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt
Thread-Index: AdDOBUDbRxBUVYvET6+lvnoej2ZZ3gAAMSvgAALW15A=
Date: Mon, 03 Aug 2015 17:48:17 +0000
Message-ID: <BLUPR0501MB104311B2C33604B0D73699FDC2770@BLUPR0501MB1043.namprd05.prod.outlook.com>
References: <BLUPR0501MB1043459A62E93FD0442F8253C2770@BLUPR0501MB1043.namprd05.prod.outlook.com> <489D13FBFA9B3E41812EA89F188F018E1CC23471@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1CC23471@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sgandhewar@juniper.net;
x-originating-ip: [116.197.184.11]
x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1043; 5:X8tzpSN5pPGn+I45h4+6qNONqoAEv4WrPHOD72ioyJS8Rj1RjcJkzoKwS3CvIvcFeS3oTr/Q+C879WEtlXtDoxAtHt2xnl2yNNJ0wrw+YjT5rDPL++G3gITIWgs2lnMe+yKw7gPth0/5/KKYgwwy0g==; 24:47Q9hbePfGxYXOl85h0IilaXFAUosLCZ9AHuKg3IQx+GNUwYFYHkLfPB120n3rg8HbWiM8zcOp6zQ44u29VL4jKiXwOd6WheomUnAvEdVIA=; 20:8lvqt7ZFteyZubF2JheviueJmiYSWyGvdQhkNBGABs6RiyJ9E9GBj1hB6cmTeZqAlsUpAKsKWKlZCrN+L36J2A==
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001)(42140001); SRVR:BLUPR0501MB1043; UriScan:; BCL:0; PCL:0; RULEID:(42139001)(42140001); SRVR:BLUPR0501MB881;
x-microsoft-antispam-prvs: <BLUPR0501MB10437630A4C64E184B1FB638C2770@BLUPR0501MB1043.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR0501MB1043; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1043;
x-forefront-prvs: 0657D528EC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(501624003)(57704003)(51914003)(189002)(85664002)(16064003)(199003)(377454003)(53754006)(52314003)(51444003)(87936001)(86362001)(2501003)(33656002)(81156007)(76176999)(5001960100002)(76576001)(46102003)(97736004)(64706001)(4001540100001)(66066001)(2656002)(50986999)(5001770100001)(5002640100001)(5890100001)(54356999)(101416001)(19625215002)(5001860100001)(5003600100002)(18717965001)(5001830100001)(19609705001)(106356001)(189998001)(2950100001)(16236675004)(2900100001)(122556002)(230783001)(105586002)(77156002)(40100003)(62966003)(102836002)(92566002)(77096005)(107886002)(19300405004)(19617315012)(68736005)(99286002)(15975445007)(19580405001)(74316001)(19580395003)(341764005)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1043; H:BLUPR0501MB1043.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB104311B2C33604B0D73699FDC2770BLUPR0501MB1043_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2015 17:48:17.0338 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1043
X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB881; 2:bUcGRkrJ/aq7Nj75tBecU1+dFh1tVjcyKAQSuv40F80P8La/wTctQceAgnFPHDrHQHVTSHEL6lwr6pahTuYDSiz2VAbpoVRpOKNHQn7IYw26QMR7Bpm12Dr5us+yO3Gj2vrv6/EDfsGIwo6fabKKHHd7za92ucb2ceRqnfkgsk0=; 3:jWWB/RS/6SaI/qVMlCb57E/No6k43aCDxseSy3nDRxQNA4gcVANLyqytcHFIO1ru58PyVRopJIR8dn3ZdcSAq2//44cXFrL0IpVPrnd4oh6KgbbHDzj/c3xgGCtXle+3e8zOtok0BrLw8M/35niGv9hzhDwC2XIGxaTwT+h0O+lsadFKPgagwCI62CzSli0y; 25:4jgY5jVGz/biO9Iqn+bNyQpGXH1gtynUHIdW0TnYxxuPvD63G8EJSwcrWJ2hlbXKPmZN1HbMOk3YGIcZMJ9i4E4SiximQlJ3MaKR+6UIPEEVY1wViG/RlVmVEn6iVoKTpL6NA1Y8BEF07F7dQ5s2jBt7Rgg/YcSzuJnlwv03LH3sCJkVI+ZZ4Z78QyPFxxReAC0NpxoRg43lLzT7WZ1y1W71dncUoYawpW6wJ9sIP2TqK7k9o2U4Q0DXWMI/LSPWIrNJ0J+dOBMa7tfzErlLKg==; 23:I1MAGR5I0+bbsaY3hfG81tOKmZf90goGxYd0qdUzPa8GNhwnFBNZIXSFrbE8fsT6Vzl+6OtMRXmKFPj1AfF3pc1+GIsYO6K7sAFG22y+a0ohZisx37dPZD/P7BChD0JwhOBUwLz42E6rBRWljfufcg1Q/qpYJewNV85E/0n3ojaohHZlU5NGLFl9z9z/PR1qYpj8hLmYuTGbmGJbwwf1FPye0dHlx00aqEf13CkQDyK9+9nXIrVsfTdcyiM3qf2b
X-OriginatorOrg: juniper.net
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/yK8F4gQjMgkwd7awNsUtiO5bbk4>
Subject: Re: [dhcwg] Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 03 Aug 2015 17:48:30 -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 NoBinding might imply IA_NA/IA_TA/IA_PD, but not sure.)
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.
sgandhewar@juniper.net<mailto:sgandhewar@juniper.net>

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

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:sgandhewar@juniper.net]
Sent: Monday, August 03, 2015 11:59 AM
To: Ted.Lemon@nominum.com<mailto:Ted.Lemon@nominum.com>; ian.farrer@telekom.de<mailto:ian.farrer@telekom.de>; Bernie Volz (volz); JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)
Cc: Tomek Mrugalski; suresh.krishnan@ericsson.com<mailto:suresh.krishnan@ericsson.com>; ot@cisco.com<mailto:ot@cisco.com>; Sunil Gandhewar; dhcwg@ietf.org<mailto:dhcwg@ietf.org>; asullivan@dyn.com<mailto:asullivan@dyn.com>
Subject: Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt

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.
sgandhewar@juniper.net<mailto:sgandhewar@juniper.net>