RE: [dhcwg] Stateless DHCPv6 and Elapsed time option ?

"Bernie Volz" <volz@cisco.com> Wed, 28 July 2004 17:13 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18018; Wed, 28 Jul 2004 13:13:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bprpc-0005XR-6M; Wed, 28 Jul 2004 13:03:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bprkl-0004Zq-AS for dhcwg@megatron.ietf.org; Wed, 28 Jul 2004 12:58:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15844 for <dhcwg@ietf.org>; Wed, 28 Jul 2004 12:58:04 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bprmb-0002GI-3V for dhcwg@ietf.org; Wed, 28 Jul 2004 13:00:02 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2004 10:02:06 +0000
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i6SGvVCv026132; Wed, 28 Jul 2004 09:57:31 -0700 (PDT)
Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKL39775; Wed, 28 Jul 2004 12:57:29 -0400 (EDT)
From: Bernie Volz <volz@cisco.com>
To: 'Grubmair Peter' <peter.grubmair@siemens.com>, "'DHCPV6_WG (E-mail)'" <dhcwg@ietf.org>
Subject: RE: [dhcwg] Stateless DHCPv6 and Elapsed time option ?
Date: Wed, 28 Jul 2004 12:57:28 -0400
Organization: Cisco
Message-ID: <000001c474c3$f7f52760$d0412ca1@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.5709
In-Reply-To: <4D50D5110555D5119F270800062B41650532ABE4@viee10pa.erd.siemens.at>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: quoted-printable
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

Hi:

You mean section 22.9 in RFC 3315. And, yes this does seem to be a
contradiction. However, it is just a "may", not a MAY, in RFC 3736 (section
5.4) whereas it is a MUST in RFC 3315 section 22.9. I also believe that RFC
3315 overrides anything stated in RFC 3736, as 3736 is just trying to
explain the stateless subset of 3315.

As there is little harm in sending the option, send it. If you're
implementing a server, don't discard a client request just because it
doesn't include this option - the option is not that fundamental to server
operation (those fundamental requirements are given in Sectin 15 of 3315). 

In many ways, this option is likely not that important for stateless as
there is very little work a server needs to perform, so it would usually
always respond. One could envision stateful servers where one is a "primary"
and another is a "backup" and the backup might only respond if the elapsed
time has reached some threshold for messages in which there was no server
identifier option?

- Bernie

> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 
> On Behalf Of Grubmair Peter
> Sent: Tuesday, July 27, 2004 5:32 AM
> To: DHCPV6_WG (E-mail)
> Subject: [dhcwg] Stateless DHCPv6 and Elapsed time option ?
> 
> 
> RFC3315 (DHCPv6), chapter 2.9 says
> a clinet MUST include elapsed time option,
> whereas RFC3736(stateless DHCPv6) chapter 5.4
> says a client may implement elapsed time option.
> Is it correct, if in a statelss DHCP client
> elapsed time option is not sent in Information request ?
> Best regards
>    Peter 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg