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

Sunil Gandhewar <> Mon, 17 August 2015 16:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D75DC1ACE32 for <>; Mon, 17 Aug 2015 09:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1XT-vQCdfrG0 for <>; Mon, 17 Aug 2015 09:26:35 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::1:778]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5F211A8934 for <>; Mon, 17 Aug 2015 09:25:54 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 17 Aug 2015 16:25:31 +0000
Received: from ([]) by ([]) with mapi id 15.01.0231.024; Mon, 17 Aug 2015 16:25:31 +0000
From: Sunil Gandhewar <>
To: "" <>
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+lvnoej2ZZ3gKnuIggABkYvgA=
Date: Mon, 17 Aug 2015 16:25:31 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1041; 5:mlTcEmnvGtpqZFmyhVzA0B/CeNuZvvuypizggiCCCU2MedabtI8EW0SwB9VlsKtWCrRxnJTaPbGHrOIxXzS+yVdOsPVnEP9gOnieG0A+e6kCSrYb9nVr9GNJvTQcrIqVzuhu6skpvsPwtNB6S1eOOw==; 24:tm2ibr7HNi155AclmN234U0GxsbUPK3IXOxdHpNBTLnjoPMb6fI6FPu5NeX0ky9EYnASxtJcZ4nC7q9jD0SNSSu8vI4zxNlrFz7r9xI3Mtw=; 20:ecGFkMm3aFo8Y9BtM3+/x0r2QhNhzU312xAT2ux7V4uPlI+67iYDHPe3IMhXmL1FTEQc42i1lCAv8Tmoz51x7w==
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001)(42140001); SRVR:BLUPR0501MB1041;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BLUPR0501MB1041; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1041;
x-forefront-prvs: 0671F32598
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(53754006)(85664002)(199003)(16064003)(501624003)(57704003)(189002)(377454003)(62966003)(5001830100001)(5001860100001)(5001960100002)(4001540100001)(97736004)(81156007)(122556002)(19625215002)(5003600100002)(189998001)(110136002)(230783001)(5002640100001)(18717965001)(74316001)(19580395003)(2351001)(2656002)(40100003)(19300405004)(19580405001)(33656002)(107886002)(16236675004)(46102003)(102836002)(86362001)(19609705001)(15975445007)(2950100001)(68736005)(10400500002)(5001920100001)(2900100001)(19617315012)(76576001)(2501003)(76176999)(77096005)(101416001)(106356001)(77156002)(92566002)(54356999)(105586002)(50986999)(99286002)(87936001)(66066001)(5890100001)(64706001)(341764005)(4001430100001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1041;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB10433BCCCDF408C8FA101F6CC2790BLUPR0501MB1043_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2015 16:25:31.8359 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1041
Archived-At: <>
Cc: Sunil Gandhewar <>
Subject: Re: [dhcwg] Comments on draft-gandhewar-dhc-relay-initiated-release-00.txt and draft-gandhewar-dhc-v6-relay-initiated-release-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Aug 2015 16:26:43 -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.

Sunil Gandhewar
Juniper Networks, Inc.

Sent: Monday, August 17, 2015 9:54 AM
To: Sunil Gandhewar
Cc: Tomek Mrugalski;;;;;;; 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


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

From: Sunil Gandhewar []
Sent: Monday, August 03, 2015 9:29 PM
Cc: Tomek Mrugalski;<>;<>; Sunil Gandhewar;<>;<>
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:
DHCPv6 version:

Sunil Gandhewar
Juniper Networks, Inc.<>