Subject: RE: [dhcwg] additional questions on dhcpv6-28

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 23 Jan 2003 16:25:57 -0600

Jinmei:

Regarding REL_MAX_RC, thanks. We will fix that in the author's review of the RFC.

Regarding issue 1 (preferred>valid lifetime), I agree that RFC 2462 behavior is best
(ie, ignore address if this happens as it is invalid).

Regarding issue 2 (infinite lifetimes), that is something we could discuss but I
don't think there is a need for infinite lifetimes (I suppose the authors of RFC
2462 felt that it is warranted and hence perhaps we too should consider it).
Perhaps Ralph or another author or WG mailing list subscriber has an opinion?

I definitely don't think infinite renewals times are a good idea, so I would not
recommend adding this for T1/T2.

BTW, please do keep issues coming. As there will hopefully soon be some DHCPv6
interop testing at various events (such as Connectathon, www.connectathon.org),
one idea I briefly discussed with Ralph was to publish an internet-draft on any
issues that were uncovered that either caused confusion or problems. That way,
we'd document any issues early on. So, please keep issues coming as they could
be used this draft.

Thanks!

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 3:19 AM
To: [email-masked]
Subject: [dhcwg] additional questions on dhcpv6-28

Hello,

I still have a couple of questions (and one tiny comment) of
draft-ietf-dhc-dhcpv6-28.txt.

This is the comment:

In the following line of Section 18.1.6.

      MRC   REL_MAX_MRC

should be

      MRC   REL_MAX_RC

And the followings are questions:

1. What should the client do if the preferred lifetime is larger than
   the valid lifetime for an IA address option in a reply message (to
   request/renew, etc)?

   I think the address should be ignored, as an analogy to the rule
   (c) of RFC 2462 Section 5.5.3, but the dhcpv6 draft is silent on
   this.

2. Does DHCPv6 have a notion of "infinite" lifetimes (and T1/T2
   values)?  If we apply an analogy to RFC 2461, 0xffffffff should be
   "infinity."  Does this make sense for DHCPv6 as well?  I don't have
   a particular opinion, but the DHCPv6 spec should be clear on this,
   because an implementation may or may not apply the analogy to RFC
   2461, which may cause interoperability issues.
   BTW: our current implementation applies the analogy, i.e., we treat
   0xffffffff as infinity.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 24 Jan 2003 14:49:01 -0600

Doesn't this contradict your previous email:

  Infinite T1/T2 may be helpful during network renumbering. It tells the
  client that the server is no longer willing to extend address/prefix
  lifetimes and that the addresses/prefixes assigned before should
  expire at a fixed future time.

And, this is just the case where I would expect T1/T2 to be greater than
any lifetime in the IA ... it tells the client that the server is NOT
willing to renew the lifetimes on the address.

So, it seems like the only time we would need infinite T1/T2 times is if
we allowed infinite lifetimes. But I don't have any major objection to
having 0xffffffff defined as "infinite" instead of 2^32-1 seconds.

We might also want to be clear that T1/T2, valid and preferred lifetimes
are all unsigned values. I didn't see that -28 did this. (RFC 2461 says
that lifetimes are 32-bit unsigned integers.)

- Bernie

-----Original Message-----
From: Jun Xie [mailto:[email-masked]]
Sent: Thursday, January 23, 2003 11:06 PM
To: Ralph Droms
Cc: [email-masked]
Subject: Re: [dhcwg] additional questions on dhcpv6-28

At 04:26 PM 1/23/03 -0500, Ralph Droms wrote:
[...]
>I suggest adding this text to follow the first paragraph of section
>18.1.8., Receipt of Reply Messages, in draft-ietf-dhc-dhcpv6-28.txt.
>
>    The client discards any addresses found in any IAs it receives for
>    which the preferred lifetime is greater than the valid lifetime.
>
>Are there other cases of invalid parameters or configuration that
>should be mentioned here?

How about T1/T2 greater than the shortest valid lifetime in an IA?
Is it valid or not? Should it explicitly mention that the combination
of preferred lifetime = 0 and valid lifetime > 0 is valid?

-Jun