Re: [dhcwg] Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt
"Bernie Volz (volz)" <volz@cisco.com> Mon, 03 August 2015 17:13 UTC
Return-Path: <volz@cisco.com>
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 094E51AC44D for <dhcwg@ietfa.amsl.com>; Mon, 3 Aug 2015 10:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 kn6TpnWUFo87 for <dhcwg@ietfa.amsl.com>; Mon, 3 Aug 2015 10:13:32 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFAF1AC417 for <dhcwg@ietf.org>; Mon, 3 Aug 2015 10:13:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50234; q=dns/txt; s=iport; t=1438622011; x=1439831611; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XEw0UQMngmfhGjF6BWCP4116AThowtRirdZarzASMAY=; b=fKj4RG+HidRLGih4wE7h4/uo+dQjjGNIkntsCBDcrvpvgnre4xPy4xPN bgOQyddd5qxl1s3mkHIkgh1BHNy0vXs0fRs6l+L3kJK8yIsLHsORV/ua9 tSW5a1bRq1XVd3CGtPpeI5HVAC6n1DI/h0GcWkfnML2ekMe3mCz+/XeaZ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AcAwCnoL9V/4UNJK1bGQEBAYIxTVRpBqsUkTkJggaFdwKBMTgUAQEBAQEBAYEKhCMBAQEBAxoTTBACAQgOAwQBAQsDEwECBAcyFAkIAQEEDgUIiCYNylQBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItPhC8KBBomBwQGAQaDEoEUBYdoig+DAgGEemaBfIY2hCCDFIxpg2Qmgj+BPm8BAYEDQ4EEAQEB
X-IronPort-AV: E=Sophos;i="5.15,602,1432598400"; d="scan'208,217";a="174591357"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP; 03 Aug 2015 17:13:29 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t73HDT98027449 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Aug 2015 17:13:29 GMT
Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 3 Aug 2015 12:13:28 -0500
Received: from xhc-rcd-x03.cisco.com (173.37.183.77) by xch-aln-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1076.9 via Frontend Transport; Mon, 3 Aug 2015 12:13:28 -0500
Received: from xmb-rcd-x04.cisco.com ([169.254.8.103]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0248.002; Mon, 3 Aug 2015 12:13:28 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Sunil Gandhewar <sgandhewar@juniper.net>
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+lvnoej2ZZ3gAAMSvg
Date: Mon, 03 Aug 2015 17:13:27 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1CC23471@xmb-rcd-x04.cisco.com>
References: <BLUPR0501MB1043459A62E93FD0442F8253C2770@BLUPR0501MB1043.namprd05.prod.outlook.com>
In-Reply-To: <BLUPR0501MB1043459A62E93FD0442F8253C2770@BLUPR0501MB1043.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.98.1.198]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1CC23471xmbrcdx04ciscoc_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/3Nod3UMXRIbD5IHndm71Pz9KGCM>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
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:13:41 -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:sgandhewar@juniper.net] Sent: Monday, August 03, 2015 11:59 AM To: Ted.Lemon@nominum.com; ian.farrer@telekom.de; Bernie Volz (volz); JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) Cc: Tomek Mrugalski; suresh.krishnan@ericsson.com; ot@cisco.com; Sunil Gandhewar; dhcwg@ietf.org; 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>
- [dhcwg] Comments on draft-gandhewar-dhc-relay-ini… Sunil Gandhewar
- Re: [dhcwg] Comments on draft-gandhewar-dhc-relay… Bernie Volz (volz)
- Re: [dhcwg] Comments on draft-gandhewar-dhc-relay… Sunil Gandhewar
- Re: [dhcwg] Comments on draft-gandhewar-dhc-relay… Bernie Volz (volz)
- Re: [dhcwg] Comments on draft-gandhewar-dhc-relay… Sunil Gandhewar
- Re: [dhcwg] Comments on draft-gandhewar-dhc-relay… JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)
- Re: [dhcwg] Comments on draft-gandhewar-dhc-relay… Bernie Volz (volz)
- Re: [dhcwg] Comments on draft-gandhewar-dhc-relay… Sunil Gandhewar