dhc WG meeting at IETF67

The dhc WG will meet at 9AM on Wed, Nov8 during IETF 67:

WEDNESDAY, November 8, 2006
0900-1130 Morning Session I
INT   dhc       Dynamic Host Configuration WG
OPS   dime      Diameter Maintenance and Extensions WG
RAI   speermint Session PEERing for Multimedia INTerconnect WG
RTG   mpls      Multiprotocol Label Switching WG
RTG   sidr      Secure Inter-Domain Routing WG
SEC   msec      Multicast Security WG
TSV   behave    Behavior Engineering for Hindrance Avoidance WG

Another RFC 2131/2132 issue?

Seems like, somewhere in "Implementation Issues with RFC 2131, "Dynamic Host
Configuration Protocol (DHCPv4)" <draft-ietf-dhc-implementation-02.txt>,
there ought to be a discussion of...

What is the client behavior when options in a DHCPACK received during lease
renewal carry different values from those currently stored by the client
from the previous DHCPACK?

- Ralph

Re: Another RFC 2131/2132 issue?

Ralph Droms wrote:
> What is the client behavior when options in a DHCPACK received during lease
> renewal carry different values from those currently stored by the client
> from the previous DHCPACK?
>   
Yup, we've talked about this before.   I think the consensus at this 
point is that the client should use the new parameters.   Definitely 
something that needs to be added if we do an RFC2131/2132 reissue.

Re: Another RFC 2131/2132 issue?

Barr, Rob - I took a cursory look through
<draft-ietf-dhc-implementation-02.txt> and didn't see this specific issue;
if it's not already on the list of topics to be discussed, please add it.
Thanks...

- Ralph

On 10/3/06 1:30 PM, "Ted Lemon" <Ted.Lemon <at> nominum.com> wrote:

> Ralph Droms wrote:
>> What is the client behavior when options in a DHCPACK received during lease
>> renewal carry different values from those currently stored by the client
>> from the previous DHCPACK?
>>   
> Yup, we've talked about this before.   I think the consensus at this
> point is that the client should use the new parameters.   Definitely
> something that needs to be added if we do an RFC2131/2132 reissue.

RE: [New I-D] DHCPv6 Relay Agent Link Selection(RALS) Option

Bernie,

responding to:
> In other forums there has been some discussions as to whether to place
a
> link-local address into this field, but IMHO I think that is a bad
idea
> as it conveys no information
and:
> Just to be sure - I was talking only about the link-address field.
That
> is where a link-local address is useless.

OK, but then (RFC3315, Section 20.1.1) doesn't give clear guidance
on what the realy agent should write into "link-address" when there
there is no global/site-scoped address available for the link. Should
it say that the relay agent writes "0" into link-address in that case?
(Wouldn't writing a link-local address instead be better than "0"?)

Thanks - Fred
fred.l.templin <at> boeing.com

RE: [New I-D] DHCPv6 Relay Agent Link Selection(RALS) Option

How is it better? Perhaps because you only need to test the fe80 bits
instead of checking that all 16-octets are 0? While that may be a small
consideration, I don't give it much weight.

I think there is more value in having something be 0 if it is
unset/unspecified rather than having to check for a specific value (such
as fe80...) or range of values.

And, could there be cases where there is no link-local address? If so,
you'd still have to support the 0 value.

So, my feeling is that you should use 0 unless you have something of
real value to put there.

I fully agree that this is not clearly specified in RFC 3315 and that
should definitely be cleared up in a 3315-bis document. However, I also
feel that the existing RFC 3315 text gives more weight to don't set the
field (ie, leave it 0) if you have no global/site-scoped address. In
general, when an RFC doesn't say to add something to a message or set a
given field, we have assumed it is 0.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:Fred.L.Templin <at> boeing.com] 
Sent: Tuesday, October 03, 2006 1:51 PM
To: Bernie Volz (volz); Amy
Cc: dhcwg <at> ietf.org
Subject: RE: [dhcwg] [New I-D] DHCPv6 Relay Agent Link Selection(RALS)
Option

RE: [New I-D] DHCPv6 Relay Agent Link Selection(RALS) Opt ion

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

RE: [New I-D] DHCPv6 Relay Agent Link Selection(RALS) Option

Bernie,

> So, my feeling is that you should use 0 unless you have something of
> real value to put there.

I don't mind having the relay write 0, but:

> I fully agree that this is not clearly specified in RFC 3315 and that
> should definitely be cleared up in a 3315-bis document. However, I
also
> feel that the existing RFC 3315 text gives more weight to don't set
the
> field (ie, leave it 0) if you have no global/site-scoped address. In
> general, when an RFC doesn't say to add something to a message or set
a
> given field, we have assumed it is 0.

The final sentence of (RFC3315, Section 21.1.1) strongly implies
that something other than 0 should be written, so it seems like
at least that much should be clarified in a -bis.

Thanks - Fred
fred.l.templin <at> boeing.com

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:Fred.L.Templin <at> boeing.com] 
Sent: Tuesday, October 03, 2006 1:51 PM
To: Bernie Volz (volz); Amy
Cc: dhcwg <at> ietf.org
Subject: RE: [dhcwg] [New I-D] DHCPv6 Relay Agent Link Selection(RALS)
Option

Bernie,

responding to:
> In other forums there has been some discussions as to whether to place
a
> link-local address into this field, but IMHO I think that is a bad
idea
> as it conveys no information
and:
> Just to be sure - I was talking only about the link-address field.
That
> is where a link-local address is useless.

OK, but then (RFC3315, Section 20.1.1) doesn't give clear guidance
on what the realy agent should write into "link-address" when there
there is no global/site-scoped address available for the link. Should
it say that the relay agent writes "0" into link-address in that case?
(Wouldn't writing a link-local address instead be better than "0"?)

Thanks - Fred
fred.l.templin <at> boeing.com

Re: Another RFC 2131/2132 issue?

On Tue, Oct 03, 2006 at 10:30:33AM -0700, Ted Lemon wrote:
> Yup, we've talked about this before.   I think the consensus at this 
> point is that the client should use the new parameters.   Definitely 
> something that needs to be added if we do an RFC2131/2132 reissue.

To a certain extent, this can't be helped.  Some applications
consume the configuration value when they start running, and need
to be restarted to fetch the new value from the system.

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email training <at> isc.org.
--

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

RE: Another RFC 2131/2132 issue?

Yes, and we wouldn't expect a client to reboot itself on a RENEW if the
boot server and/or boot file changed in the options it got back.

I think the DHCP client *SHOULD* "set" the new configuration settings
(and remove those that might have disappeared) so that when that
configuration value is next needed by the client (ie, an application
running on the client), the newer value is used.

- Bernie

-----Original Message-----
From: David W. Hankins [mailto:David_Hankins <at> isc.org] 
Sent: Tuesday, October 03, 2006 2:58 PM
To: dhcwg <at> ietf.org
Subject: Re: [dhcwg] Another RFC 2131/2132 issue?

On Tue, Oct 03, 2006 at 10:30:33AM -0700, Ted Lemon wrote:
> Yup, we've talked about this before.   I think the consensus at this 
> point is that the client should use the new parameters.   Definitely 
> something that needs to be added if we do an RFC2131/2132 reissue.

To a certain extent, this can't be helped.  Some applications
consume the configuration value when they start running, and need
to be restarted to fetch the new value from the system.

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email training <at> isc.org.
--

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins