Subject: Re: [dhcwg] DHCPv6 and DHCPv4 Vendor Message Drafts (IndividualSubmissions) / Agenda Time Request

From: JiangSheng 66104 <[email-masked]>
Date: Thu, 17 Jul 2008 11:12:06 +0800

Hi, Bernie,

I have just quitely reviewed these two drafts. They looks quite interesting for me. Your "to allow communication between DHCP entities for data that would not normally be standardized or there is little interest for" is a useful scenario for us too.

However, for me, these two drafts does not give enough technical solution as it is now. If I understand you correctly, the most important scenario is to allow communication between DIFFERENT vendors' devices (the communication between the devices from the same vendor can be achieveed by vender's own implementation, no need to define a standard message type). Your current draft is lack of the support for intercommunication. As suggestion, for the "vendor-data " field, more detailed definitions or recommandations on how to describe/organize these vendor data should be given so that a DHCP entity from vendor A MAY be able to understand a vendor message sent by another DHCP entity from vendor B.

Best regards,

Sheng JIANG, Ph.D.

IP Research Department, Networking Research Department, Network Product Line, Huawei Technologies Co. Ltd.

PS: I also cc this message to Ralph because a, he will represent Bernie's draft; b, my emails to DHC rarely get through and show up on the maillist recently due to some problems between my email server and IETF email server.

>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] 
>>On Behalf Of Bernie Volz (volz)
>>Sent: Thursday, July 17, 2008 6:26 AM
>>To: [email-masked]
>>Subject: [dhcwg] DHCPv6 and DHCPv4 Vendor Message Drafts 
>>(IndividualSubmissions) / Agenda Time Request
>>
>>Folks:
>> 
>>I recently submitted an updated
>>draft-volz-dhc-dhcpv6-vendor-message-01.txt and also a new 
>>draft-volz-dhc-dhcpv4-vendor-message-00.txt.
>>
>>The DHCPv6 draft was originally presented at the Prague IETF 
>>(IETF-68) and wasn't warmly received. One of the issues was 
>>the reserved option space, which has been removed. The more 
>>significant concern, if I recall correctly, was that vendors 
>>would use these messages in place of going the standards 
>>route, and while I can't say that isn't a valid concern, I 
>>suspect that in most cases that won't be an issue. My purpose 
>>for this message is to allow communication between DHCP 
>>entities for data that would not normally be standardized or 
>>there is little interest for. For example, it could be used 
>>by DHCP servers to exchange configuration data or implement 
>>failover (we know the long and tortured road that DHCPv4 
>>failover has followed and while there was a LOT of value to 
>>that work, we still don't have a standards track document and 
>>there's little interest to doing the work necessary to get it done).
>>
>>The DHCPv4 draft is new and was a natural extension. Of 
>>course, DHCPv4 is a bit different from DHCPv6, so there are 
>>some differences (a new option is needed to convey the 
>>enterprise-id number).
>>
>>I will not be at the Dublin IETF and may try to participate 
>>virtually (it will be 4AM for me, but I likely shouldn't 
>>complain as most will still be jet lagged).
>>
>>I've asked Ralph (with his working co-chair hat off) to 
>>present something briefly. Hopefully he and John can work it 
>>into the schedule if time permits (it is a very late agenda addition).
>>
>>If anyone on the list supports the concept (as several folks 
>>did privately communicate interest to me), please speak up - 
>>either at the meeting or on the list.
>>
>>- Bernie
>>_______________________________________________
>>dhcwg mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/dhcwg
>>
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 16 Jul 2008 23:27:13 -0400

Hi:

I actually disagree that this is a cross-vendor mechanism. If you're
planning to do that, why not go to the DHC WG/IETF and standardize it?

I do admit that it may be possible for an organization, such as
CableLabs or the DSLForum, to define messages and the format of the data
to allow application specific exchanges (such as Cablelabs DOCSIS 3.0
made use of the vendor options). But, I would discourage that as it is
likely that other technologies will likely find these new messages to be
useful as well and hence they should be defined through the IETF.

I suspect that this is exactly what people feared would happen and we do
need to avoid that.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of JiangSheng 66104
Sent: Wednesday, July 16, 2008 11:12 PM
To: Bernie Volz (volz); [email-masked]
Cc: Ralph Droms (rdroms)
Subject: Re: [dhcwg] DHCPv6 and DHCPv4 Vendor Message Drafts
(IndividualSubmissions) / Agenda Time Request

Hi, Bernie,

I have just quitely reviewed these two drafts. They looks quite
interesting for me. Your "to allow communication between DHCP entities
for data that would not normally be standardized or there is little
interest for" is a useful scenario for us too.

However, for me, these two drafts does not give enough technical
solution as it is now. If I understand you correctly, the most important
scenario is to allow communication between DIFFERENT vendors' devices
(the communication between the devices from the same vendor can be
achieveed by vender's own implementation, no need to define a standard
message type). Your current draft is lack of the support for
intercommunication. As suggestion, for the "vendor-data " field, more
detailed definitions or recommandations on how to describe/organize
these vendor data should be given so that a DHCP entity from vendor A
MAY be able to understand a vendor message sent by another DHCP entity
from vendor B.

Best regards,

Sheng JIANG, Ph.D.

IP Research Department, Networking Research Department, Network Product
Line, Huawei Technologies Co. Ltd.

PS: I also cc this message to Ralph because a, he will represent
Bernie's draft; b, my emails to DHC rarely get through and show up on
the maillist recently due to some problems between my email server and
IETF email server.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 17 Jul 2008 00:20:14 -0400

Sure, you can always use a separate protocol. Or send the "DHCP"
messages over a different port.

But that complicates deployments because it requires customers to
potentially open additional firewall ports or protect other ports. And
it means you have to get a new port assignment or "hijack" a value you
believe no one else is using (and allowing customers to change it should
there be an issue).

And, it means more ports open on the clients and servers. And, you can't
use the relay agent to forward the packets between network elements.

And, you may get fragmented behavior if normal DHCP traffic flows but
this "other" traffic doesn't (such as because of firewalls or other
misconfigurations).

Those are the main reasons why using a DHCPv4/DHCPv6 message would be
benefical.

- Bernie 

-----Original Message-----
From: Sheng Jiang [mailto:[email-masked]] 
Sent: Wednesday, July 16, 2008 11:58 PM
To: Bernie Volz (volz); [email-masked]
Cc: Ralph Droms (rdroms)
Subject: RE: [dhcwg] DHCPv6 and DHCPv4 Vendor Message Drafts

Hi, Bernie,

If it is a single-vendor mechanism, why do it need to be a standard RFC?
Vendor A
can always achieve it in its devices with whatever format it wants.
Vendor B can
also achieve it in its own devices in whatever format it wants without
consider the
consistency with Vendor A or a standard, even there is a standard
available. And the
non-standard way has probably less security issues.

If you do agree cross-vendor mechanism is a useful scenario, but don't
want to do it
in these two draft, we may do it together with new drafts to the DHC
WG/IETF.

Cheers,

Sheng 

>>From: Bernie Volz (volz) [mailto:[email-masked]] 
>>Sent: Thursday, July 17, 2008 11:27 AM
>>To: JiangSheng 66104; [email-masked]
>>Cc: Ralph Droms (rdroms)
>>Subject: RE: [dhcwg] DHCPv6 and DHCPv4 Vendor Message Drafts 
>>I actually disagree that this is a cross-vendor mechanism. If 
>>you're planning to do that, why not go to the DHC WG/IETF and 
>>standardize it?
>>
>>I do admit that it may be possible for an organization, such 
>>as CableLabs or the DSLForum, to define messages and the 
>>format of the data to allow application specific exchanges 
>>(such as Cablelabs DOCSIS 3.0 made use of the vendor 
>>options). But, I would discourage that as it is likely that 
>>other technologies will likely find these new messages to be 
>>I suspect that this is exactly what people feared would 
>>happen and we do need to avoid that.
>>
>>- Bernie
>>
>>On Behalf Of JiangSheng 66104
>>I have just quitely reviewed these two drafts. They looks 
>>quite interesting for me. Your "to allow communication 
>>between DHCP entities for data that would not normally be 
>>standardized or there is little interest for" is a useful 
>>scenario for us too.
>>
>>However, for me, these two drafts does not give enough 
>>technical solution as it is now. If I understand you 
>>correctly, the most important scenario is to allow 
>>communication between DIFFERENT vendors' devices (the 
>>communication between the devices from the same vendor can be 
>>achieveed by vender's own implementation, no need to define a 
>>standard message type). Your current draft is lack of the 
>>support for intercommunication. As suggestion, for the 
>>"vendor-data " field, more detailed definitions or 
>>recommandations on how to describe/organize these vendor data 
>>should be given so that a DHCP entity from vendor A MAY be 
>>able to understand a vendor message sent by another DHCP 
>>entity from vendor B.
>>
>>Best regards,
>>
>>Sheng JIANG, Ph.D.
>>
>>IP Research Department, Networking Research Department, 
>>Network Product Line, Huawei Technologies Co. Ltd.
>>
>>PS: I also cc this message to Ralph because a, he will 
>>represent Bernie's draft; b, my emails to DHC rarely get 
>>through and show up on the maillist recently due to some 
>>problems between my email server and IETF email server.
>> 
>>
>>>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf 
>>>>Of Bernie Volz (volz)
>>>>(IETF-68) and wasn't warmly received. One of the issues was the 
>>>>reserved option space, which has been removed. The more significant 
>>>>concern, if I recall correctly, was that vendors would use these 
>>>>messages in place of going the standards route, and while I 
>>can't say 
>>>>that isn't a valid concern, I suspect that in most cases 
>>that won't be 
>>>>an issue. My purpose for this message is to allow communication 
>>>>between DHCP entities for data that would not normally be 
>>standardized 
>>>>or there is little interest for. For example, it could be 
>>used by DHCP 
>>>>servers to exchange configuration data or implement 
>>failover (we know 
>>>>the long and tortured road that DHCPv4 failover has 
>>followed and while 
>>>>there was a LOT of value to that work, we still don't have 
>>a standards 
>>>>track document and there's little interest to doing the 
>>work necessary 
>>>>to get it done).
>>>>
>>course, DHCPv4 
>>>>is a bit different from DHCPv6, so there are some 
>>differences (a new 
>>>>option is needed to convey the enterprise-id number).
>>>>
>>virtually 
>>>>(it will be 4AM for me, but I likely shouldn't complain as 
>>most will 
>>>>still be jet lagged).
>>>>
>>>>I've asked Ralph (with his working co-chair hat off) to present 
>>>>something briefly. Hopefully he and John can work it into 
>>the schedule 
>>>>if time permits (it is a very late agenda addition).
>>>>
>>>>If anyone on the list supports the concept (as several folks did 
>>>>privately communicate interest to me), please speak up - 
>>either at the 
>>>>meeting or on the list.
>>>>
>>>>- Bernie

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 17 Jul 2008 11:57:52 +0800

Hi, Bernie,

If it is a single-vendor mechanism, why do it need to be a standard RFC? Vendor A
can always achieve it in its devices with whatever format it wants. Vendor B can
also achieve it in its own devices in whatever format it wants without consider the
consistency with Vendor A or a standard, even there is a standard available. And the
non-standard way has probably less security issues.

If you do agree cross-vendor mechanism is a useful scenario, but don't want to do it
in these two draft, we may do it together with new drafts to the DHC WG/IETF.

Cheers,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 17 Jul 2008 14:18:50 +0800

For single-vendor scenario, an implementation using non-standard DHCP
message with the regular port or even using non-standard DHCP option with standard
DHCP
message header can meet the purpose, and there is no extra deployment problems.
Firewalls
or reply agents do not check whether the contents of a DHCP message are standard or
not.

Don't get me worry. I am not here against your drafts. I just think cross-vendor
scenarios are
consistent with single-vendor scenarios. Adding them together will make the
foundation/requirements
of these drafts to be more solid.

Cheers

Sheng

>>Sent: Thursday, July 17, 2008 12:20 PM
>>To: Sheng Jiang; [email-masked]
>>Cc: Ralph Droms (rdroms)
>>But that complicates deployments because it requires 
>>customers to potentially open additional firewall ports or 
>>protect other ports. And it means you have to get a new port 
>>assignment or "hijack" a value you believe no one else is 
>>using (and allowing customers to change it should there be an issue).
>>
>>And, it means more ports open on the clients and servers. 
>>And, you can't use the relay agent to forward the packets 
>>between network elements.
>>
>>And, you may get fragmented behavior if normal DHCP traffic 
>>flows but this "other" traffic doesn't (such as because of 
>>firewalls or other misconfigurations).
>>
>>Those are the main reasons why using a DHCPv4/DHCPv6 message 
>>would be benefical.
>>
>>- Bernie 
>>
>>also achieve it in its own devices in whatever format it 
>>wants without consider the consistency with Vendor A or a 
>>standard, even there is a standard available. And the 
>>If you do agree cross-vendor mechanism is a useful scenario, 
>>but don't want to do it in these two draft, we may do it 
>>together with new drafts to the DHC WG/IETF.
>>
>>Cheers,
>>
>>Sheng 
>>
>>>>CableLabs or the DSLForum, to define messages and the format of the 
>>>>data to allow application specific exchanges (such as 
>>Cablelabs DOCSIS 
>>>>3.0 made use of the vendor options). But, I would 
>>discourage that as 
>>>>it is likely that other technologies will likely find these new 
>>>>messages to be useful as well and hence they should be 
>>defined through 
>>>>the IETF.
>>>>
>>>>solution as it is now. If I understand you correctly, the most 
>>>>important scenario is to allow communication between DIFFERENT 
>>>>vendors' devices (the communication between the devices 
>>from the same 
>>>>vendor can be achieveed by vender's own implementation, no need to 
>>>>define a standard message type). Your current draft is lack of the 
>>"vendor-data " 
>>>>field, more detailed definitions or recommandations on how to 
>>>>describe/organize these vendor data should be given so that a DHCP 
>>>>entity from vendor A MAY be able to understand a vendor 
>>message sent 
>>>>by another DHCP entity from vendor B.
>>>>
>>>>Best regards,
>>>>
>>>>Sheng JIANG, Ph.D.
>>>>
>>>>IP Research Department, Networking Research Department, Network 
>>>>Product Line, Huawei Technologies Co. Ltd.
>>>>

---

From: Bud Millwood <[email-masked]>
Date: Tue, 29 Jul 2008 17:00:51 +0200

On Thursday 17 July 2008, Sheng Jiang wrote:
> message with the regular port or even using non-standard DHCP option with
> standard DHCP

I think that's exactly what this is about - a *standard* way to make sure that 
implementations throw away these messages if they're not specifically for 
that vendor.

I can't randomly choose a new DHCP message type and declare it as being 
specific to my company, because it could be defined as a standard in the 
future.

- Bud

> Firewalls
> or reply agents do not check whether the contents of a DHCP message are
> standard or not.
>
> Don't get me worry. I am not here against your drafts. I just think
> cross-vendor scenarios are
> >>>>I actually disagree that this is a cross-vendor mechanism.
> >>
> >>If you're
> >>
> >>>>planning to do that, why not go to the DHC WG/IETF and
> >>
> >>standardize it?
> >>
> >>happen and we
> >>>>do need to avoid that.
> >>>>interesting for me. Your "to allow communication between
> >>
> >>DHCP entities
> >>
> >>>>Bernie's draft; b, my emails to DHC rarely get through and
> >>
> >>show up on
> >>
> >>>>the maillist recently due to some problems between my email
> >>
> >>server and
> >>
> >>>>IETF email server.
> >>>>
> >>>>>>reserved option space, which has been removed. The more
> >>
> >>significant
> >>
> >>>>either at the
> >>>>>>meeting or on the list.

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg