Subject: [dhcwg] Internet Drafts to be reviewed by the dhc WG

From: Ralph Droms <[email-masked]>
Date: Wed, 31 Mar 2004 13:24:05 -0500

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 31 Mar 2004 14:21:56 -0600

> themselves will appear as midcom WG documents (if taken on by the 

I think it's a very good idea to take this review as a dhcwg work item. 
   :')

---

From: Tim Chown <[email-masked]>
Date: Wed, 31 Mar 2004 21:50:44 +0100

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

Luckily I don't think Keith Moore is on the dhc WG list :)

Tim

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 31 Mar 2004 18:06:27 -0500

Hi:

Both of these drafts are IDENTICAL except that for the name of the
draft. I presume one should have been a DHCPv4 option
(draft-tran-midcom-dhcp-option-00.txt) and the other a DHCPv6 option?

- Bernie

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

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: "Bernie Volz" <[email-masked]>
Date: Wed, 31 Mar 2004 18:21:28 -0500

It says "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." in the abstract
of the draft. So, it looks like we're in for NAT with IPv6 ...

I think the WG should take up the issue of how best to handle options
that want to specify either or both domain names and IPv6 addresses. It
seems to me silly to have TWO options for every time this needs to occur
(as is the case in this midcom draft). And, this mechanism provides no
way to specify the preference between the two - order can be used within
each option to specify which to try first, but it can't be used across
the options. So, it is then left up to the draft (or implementor) to
pick which to use first.

The obvious answer would be to use a sub-option technique or a flag byte
before either an address or domain name. Something like:

	DHCP option (either 8-bits or 16-bits)
	Option length (either 8-bits or 16-bits)
	Encoding type (8-bits? - 0 for domain name, 1 for IP addresses)
	Encoding length (8 bits?)
	Data (either domain name or address)
	Encoding type (8-bits? - 0 for domain name, 1 for IP addresses)
	Encoding length (8 bits?)
	Data (either domain name or address)
	...

In the cases where only one type of encoding is used, this would cost 2
extra bytes. In the cases where multiple encodings are used, this would
either be the same length as the two-option method or potentially save
two bytes (depending on the encoding type/length field sizes).

Note: It would also be possible to specify IPv4 AND IPv6 addresses (1
for IPv4 address, 2 for IPv6 addresses for the encoding type, for
example).

- Bernie

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

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

Tim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 31 Mar 2004 18:05:59 -0600

On Mar 31, 2004, at 5:21 PM, Bernie Volz wrote:
> that want to specify either or both domain names and IPv6 addresses.

I would rephrase this.   The working group in the past has taken up the 
issue of *whether* to send IP addresses or domain names, and we've 
historically decided to send IP addresses, so that the client isn't 
required to contain a resolver.   Supporting (and requiring all clients 
to support) both options is expensive.   So if the wg needs to discuss 
this again, I think the question should be whether to make it possible 
to send domain names instead of IP addresses, before we answer the 
question of how to do it.

If we don't reopen that question, I would suggest that we advise the 
midcom folks to always send an IP address, and never a domain name, and 
to not have two different options.   Otherwise, as you say, they have 
to specify how to choose, and whether it's okay to only send the domain 
name, and that whole can of worms.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 31 Mar 2004 21:12:20 -0500

OK - the *original* question was "Is there any objection to taking on this
review as a dhc WG work item, pending acceptance of the documents by the
midcom WG?"

Let me extend that question to ask for positive responses, as well - please
respond "yes" or "no" to the question "Should the dhc WG take on review of
draft-tran-midcom-dhcp-option-00.txt and
draft-tran-midcom-dhcpv6-option-00.txt, pending acceptance of the documents
by the midcom WG?"

- Ralph

---

From: "S. Daniel Park" <[email-masked]>
Date: Thu, 01 Apr 2004 11:47:42 +0900

I second " YES"

I believe that kind of drafts (all DHCP Options) should be 
considered in the DHC WG, regarding technical aspect 
related WGs have to carefully review them of course.  

Regards

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics. 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ralph Droms
> Sent: Thursday, April 01, 2004 11:12 AM
> To: [email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Wed, 31 Mar 2004 22:22:16 -0500

We'll leave the interesting decision about "IPv6 NAT: threat or menace?" to 
the midcom, ipv6 and other WGs.  The dhc WG will focus on the syntax of the 
options and the mechanics of how the configuration data is passed through 
DHCP messages.

- Ralph