Subject: RE: [dhcwg] Internet Drafts to be reviewed by the dhc WG - midcom options

From: "Bernie Volz" <[email-masked]>
Date: Sun, 4 Apr 2004 21:13:28 -0400

Here's some nits regarding draft-tran-midcom-dhcpv6-option-00.txt (and
also -01 which is now posted but identical):

- Abstract: "Dynamic Host Configuration Protocol for IPv6" would be
better than "Dynamic Host Configuration Protocol version 6".

- 1 Terminology: MIDCOM should be Midcom to be consistent with usage
throughout doc? Functionnality should be functionality. There's also a
bunch of non 7-bit ASCII characters in the "Midcom Agent" definition?

- 2 Introduction: "the domain name[s] of the Midcom". And, also "or the
domain name[s] of Midcom middleboxes". (Make plural!)

- 4 Midcom Middlebox DHCPv6 Option - "list of [] 128-bit [] IPv6
addresses or, preferably, [a] DNS [RFC1035] domain name[s]."

- 4.2 Midcom Middlebox IPv4 Address List - should be "IPv6", not IPv4.

- Table 1 (in Section 5.2): There is a MUST, but this is only if there
is an address configured.

- 5.2 Midcom Middlebox DHCPv6 Server Option Operation: "This server MAY
send one" ... Is use of "MAY" correct here? I think it should be "This
server should send ..."? The table provides the rules.

I haven't looked at draft-tran-midcom-dhcp-option-01.txt (DHCPv4 option)
- but some of the above nits likely apply there as well.

I don't see anything particularily wrong with these DHCPv6 options,
though as I posted the other day, I think the DHC WG should take on the
issue as to whether this is the best way to handle the ability to
configure addresses and domain names (two options), or whether, as Ted
suggested in a response to my post, to send only addresses.

I guess a good question to Joel and Soumaya is whether just sending
addresses would cause any significant issues?

- Bernie Volz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ralph Droms
Sent: Wednesday, March 31, 2004 1:24 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Melinda Shore
Subject: [dhcwg] Internet Drafts to be reviewed by the dhc WG

There are a couple of Internet Drafts under review by the midcom WG that
specify new DHCP options:

draft-tran-midcom-dhcp-option-00.txt
draft-tran-midcom-dhcpv6-option-00.txt

Based on our current charter, the dhc WG should consider collaborating
with the midcom WG on the review of these specifications; specifically,
the dhc WG should review the syntax of the options for adherence to DHCP
requirements and consistency with other DHCP options, while the midcom
WG will review the semantics associated with the options.

Is there any objection to taking on this review as a dhc WG work item,
pending acceptance of the documents by the midcom WG?  Note that the
drafts themselves will appear as midcom WG documents (if taken on by the
midcom WG).

- Ralph

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 05 Apr 2004 15:54:57 +0200

--On Mittwoch, 31. März 2004 21:50 Uhr +0100 Tim Chown 
<[email-masked]> wrote:

| On Wed, Mar 31, 2004 at 01:24:05PM -0500, Ralph Droms wrote:
|> There are a couple of Internet Drafts under review by the midcom WG that
|> specify new DHCP options:
|>
|> draft-tran-midcom-dhcpv6-option-00.txt
|
| So this one assumes that IPv6 NATs exist and midcom will handle IPv6 NAT
| traversal?  Or s midcom for IPv6 a means to configure the middlebox for
| other ALG or firewall purposes?

Hmm, I don't see any assumption saying that there will be IPv6 NATs. The 
document ist just saying that the MIDCOM server can be reached via IPv6, 
whether there is a NAT at the box or not is a different story.

  Martin

|
| Luckily I don't think Keith Moore is on the dhc WG list :)
|
| Tim
|
| _______________________________________________
| dhcwg mailing list
| [email-masked]
| https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Tim Chown <[email-masked]>
Date: Mon, 5 Apr 2004 16:10:25 +0100

> whether there is a NAT at the box or not is a different story.

Taken from the intro draft-tran-midcom-dhcpv6-option-01:

  "Entities using the Midcom Protocol need to know the
   presence of Midcom middleboxes, such as firewalls and network address
   translators, in order to enable communication across theses devices.
   A DHCPv6 option provides a means for these entities to determine the
   Midcom middleboxes IPv6 address or the domain name."

But that text is cut and paste from the IPv4 version of the draft.
Perhaps the v6 version can omit mention of translators? (If people use
it for that, so be it, but we're not then "suggesting" it...)

Tim

---

From: "Kevin A. Noll" <[email-masked]>
Date: Mon, 05 Apr 2004 15:00:38 -0400

Paragraph 2 of Section 4.4.1 of RFC2131 implies that T1, 
T2, and the lease expiration time are all computed relative 
to the time that the client sends the DHCPDISCOVER.

Is this correct, or should these values be computed relative 
to the time that the client acquires the lease (i.e. when it
receives the DHCPACK)?

In a perfect world, the former would make sense because the
time to get from DISCOVER to ACK should be just a couple of 
seconds at most. 

In a not so perfect world, the latter would make sense. For
example, if the network or DHCP server is not performing very
well, it may take many seconds and several retries to actually
get from DISCOVER to ACK. If this happens and the DISCOVER time 
is the reference, then there could be a considerable discrepency 
between the client's and server's notion of when the lease 
should expire.

Am I correct, or did I miss another section of the document that
clarifies this?

--kan--
--
Kevin A. Noll, KD4WOZ
CCIE 10948, CCDP
Perfect Order, Inc.		
[email-masked]
717-796-1936

---

From: "Joel Tran" <[email-masked]>
Date: Mon, 5 Apr 2004 15:43:20 -0400

Hi Bernie,

Thanks for your input,

The two versions -00 and -01 are identical due to some posting mistakes made
with the DHCPv4 document. I reposted the two documents (DHCPv4/DHCPv6) to
avoid all confusions.

I will fix the topo mistake in the next version.

We use of two options (IP addresses/DNS addresses) for a reason. IP have
less overhead (implementation of a DNS client). However, in some large
corporate networks, DNS SRV could be used in order to provide a distributed
Midcom service.

...J

> -----Message d'origine-----
> De : Bernie Volz [mailto:[email-masked]]
> Envoyé : 4 avril, 2004 21:13
> À : [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : RE: [dhcwg] Internet Drafts to be reviewed by the dhc
> WG - midcom options
>
>
> Here's some nits regarding
> draft-tran-midcom-dhcpv6-option-00.txt (and also -01 which is
> now posted but identical):
>
> - Abstract: "Dynamic Host Configuration Protocol for IPv6"
> would be better than "Dynamic Host Configuration Protocol version 6".
>
> - 1 Terminology: MIDCOM should be Midcom to be consistent
> with usage throughout doc? Functionnality should be
> functionality. There's also a bunch of non 7-bit ASCII
> characters in the "Midcom Agent" definition?
>
> - 2 Introduction: "the domain name[s] of the Midcom". And,
> also "or the domain name[s] of Midcom middleboxes". (Make plural!)
>
> - 4 Midcom Middlebox DHCPv6 Option - "list of [] 128-bit []
> IPv6 addresses or, preferably, [a] DNS [RFC1035] domain name[s]."
>
> - Table 1 (in Section 5.2): There is a MUST, but this is only
> if there is an address configured.
>
> - 5.2 Midcom Middlebox DHCPv6 Server Option Operation: "This
> server MAY send one" ... Is use of "MAY" correct here? I
> think it should be "This server should send ..."? The table
> provides the rules.
>
> I don't see anything particularily wrong with these DHCPv6
> options, though as I posted the other day, I think the DHC WG
> should take on the issue as to whether this is the best way
> to handle the ability to configure addresses and domain names
> (two options), or whether, as Ted suggested in a response to
> my post, to send only addresses.
>
> I guess a good question to Joel and Soumaya is whether just
> sending addresses would cause any significant issues?
>
> - Bernie Volz
>
>
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ralph Droms
> There are a couple of Internet Drafts under review by the
> midcom WG that specify new DHCP options:
>
> Based on our current charter, the dhc WG should consider
> collaborating with the midcom WG on the review of these
> specifications; specifically, the dhc WG should review the
> syntax of the options for adherence to DHCP requirements and
> consistency with other DHCP options, while the midcom WG will
> review the semantics associated with the options.
>
> Is there any objection to taking on this review as a dhc WG
> work item, pending acceptance of the documents by the midcom
> WG?  Note that the drafts themselves will appear as midcom WG
> documents (if taken on by the midcom WG).
>
> - Ralph
>
>

---

From: "Joel Tran" <[email-masked]>
Date: Mon, 5 Apr 2004 15:49:27 -0400

When I wrote the document, my intention was not to make a debate nor promote
whatever there will be IPv6 NAT. As Tim suggested, I will change on the next
version the text concerning the NAT in order to avoid all "suggestions"
possible.

...J

> De : [email-masked] [mailto:[email-masked]] De la
> part de Tim Chown
> Envoyé : 5 avril, 2004 11:10
> À : Martin Stiemerling
> Cc : Ralph Droms; [email-masked]; [email-masked];
> [email-masked]; Melinda Shore
> Objet : Re: [dhcwg] Internet Drafts to be reviewed by the dhc WG
>
>
> > Hmm, I don't see any assumption saying that there will be
> IPv6 NATs.
> > The
> But that text is cut and paste from the IPv4 version of the
> draft. Perhaps the v6 version can omit mention of
> translators? (If people use it for that, so be it, but we're
> not then "suggesting" it...)
>
> Tim
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Apr 2004 15:06:53 -0500

> between the client's and server's notion of when the lease

Speaking in terms of what the RFC says, it says that the client should 
assume that the lease is computed from the time it sent the first 
DHCPDISCOVER.   So if the T1 or T2 time, plus the time that the first 
DHCPDISCOVER was sent, is less than the current time, then you do 
indeed have a problem.   However, if you are running such short leases 
that this becomes a real issue, you will probably have lots of 
problems, and this will be the least of them.

Practically speaking, I am not aware of any DHCP servers that do not 
compute the T1 and T2 times and the actual lease expiry time relative 
to the time when they generate the last DHCPACK they send to the 
client.   But I wouldn't write a client that makes this assumption.

---

From: "Bernie Volz" <[email-masked]>
Date: Mon, 5 Apr 2004 16:48:51 -0400

I think the text you refer to is:

   The client records the lease expiration time as the sum of
   the time at which the original request was sent and the duration of
   the lease from the DHCPACK message.

And, the question is what does "original request" refer to - the
DISCOVER or REQUEST?

To be completely safe, using the DISCOVER would be best (since that will
result in the shortest lease / T1 / T2 times for the client). But, I
think practially speaking that REQUEST is OK.

But, any client and server need to be prepared for some grace period for
leases as there is no requirement that the client and server have
synchronized clocks and their individual clocks may run fast or slow.

Perhaps this would be item to include in a future revision of
draft-ietf-dhc-implementation-01.txt?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kevin A. Noll
Sent: Monday, April 05, 2004 3:01 PM
To: [email-masked]
Subject: [dhcwg] Computation of T1, T2, and lease expiration time

Is this correct, or should these values be computed relative 
to the time that the client acquires the lease (i.e. when it receives
the DHCPACK)?

In a perfect world, the former would make sense because the time to get
from DISCOVER to ACK should be just a couple of 
seconds at most. 

In a not so perfect world, the latter would make sense. For example, if
the network or DHCP server is not performing very well, it may take many
seconds and several retries to actually get from DISCOVER to ACK. If
this happens and the DISCOVER time 
is the reference, then there could be a considerable discrepency 
between the client's and server's notion of when the lease 
should expire.

--kan--

---

From: "Kevin A. Noll" <[email-masked]>
Date: Mon, 05 Apr 2004 16:59:15 -0400

As usual, I missed that section of text.

Actually, I was referring to this sentence in paragraph two:

	The client records its own local time for later use in 
	computing the lease expiration.  The client then broadcasts 
	the DHCPDISCOVER...

If you consider both of these paragraphs, it appears that the
timers should be calculated from the DHCPDISCOVER.

I would be in favor of including this for clarification in 
a future version of draft-ietf-dhc-implementation-01.txt.

--kan--

> From: Bernie Volz [mailto:[email-masked]]
> Sent: Monday, 05 April, 2004 4:49 PM
> To: 'Kevin A. Noll'; [email-masked]
> Subject: RE: [dhcwg] Computation of T1, T2, and lease expiration time
> 
>

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 06 Apr 2004 10:54:54 +0200

Hi Tim,

--On Montag, 5. April 2004 16:10 Uhr +0100 Tim Chown <[email-masked]> 
wrote:

| On Mon, Apr 05, 2004 at 03:54:57PM +0200, Martin Stiemerling wrote:
|>
|> Hmm, I don't see any assumption saying that there will be IPv6 NATs. The
|> document ist just saying that the MIDCOM server can be reached via IPv6,
|> whether there is a NAT at the box or not is a different story.
|
| Taken from the intro draft-tran-midcom-dhcpv6-option-01:
|
|   "Entities using the Midcom Protocol need to know the
|    presence of Midcom middleboxes, such as firewalls and network address
|    translators, in order to enable communication across theses devices.
|    A DHCPv6 option provides a means for these entities to determine the
|    Midcom middleboxes IPv6 address or the domain name."
|
| But that text is cut and paste from the IPv4 version of the draft.
| Perhaps the v6 version can omit mention of translators? (If people use
| it for that, so be it, but we're not then "suggesting" it...)

The text gives the freedom to read it different ways. As a MIDCOM guy I do 
read it as "the configuration protocol's endpoint address might be IPv6 
capable, but not the middlebox engine (=firewall and/or NAT)".
But indeed I see the point of given a more elaborated text.

  Martin

---

From: Tim Chown <[email-masked]>
Date: Tue, 6 Apr 2004 14:22:41 +0100

> But indeed I see the point of given a more elaborated text.

I guess you're too close to the protocol to read it without assumptions :)

"Midcom middleboxes, such as firewalls and network address translators"
then
"Midcom middleboxes IPv6 address"
implies IPv6 NAT...

Just take the NAT reference out for the IPv6 option?

Tim