[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] DHCPv6 and DHCPv4 Vendor Message Drafts (IndividualSubmissions) / Agenda Time Request
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:shengjiang at huawei.com]
Sent: Wednesday, July 16, 2008 11:58 PM
To: Bernie Volz (volz); dhcwg at ietf.org
Cc: Ralph Droms (rdroms)
Subject: RE: [dhcwg] DHCPv6 and DHCPv4 Vendor Message Drafts
(IndividualSubmissions) / Agenda Time Request
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
>>-----Original Message-----
>>From: Bernie Volz (volz) [mailto:volz at cisco.com]
>>Sent: Thursday, July 17, 2008 11:27 AM
>>To: JiangSheng 66104; dhcwg at ietf.org
>>Cc: Ralph Droms (rdroms)
>>Subject: RE: [dhcwg] DHCPv6 and DHCPv4 Vendor Message Drafts
>>(IndividualSubmissions) / Agenda Time Request
>>
>>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: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org]
>>On Behalf Of JiangSheng 66104
>>Sent: Wednesday, July 16, 2008 11:12 PM
>>To: Bernie Volz (volz); dhcwg at ietf.org
>>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.
>>
>>
>>>>-----Original Message-----
>>>>From: dhcwg-bounces at ietf.org
>>[mailto:dhcwg-bounces at ietf.org] On Behalf
>>>>Of Bernie Volz (volz)
>>>>Sent: Thursday, July 17, 2008 6:26 AM
>>>>To: dhcwg at ietf.org
>>>>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
>>>>dhcwg at ietf.org
>>>>https://www.ietf.org/mailman/listinfo/dhcwg
>>>>
>>_______________________________________________
>>dhcwg mailing list
>>dhcwg at ietf.org
>>https://www.ietf.org/mailman/listinfo/dhcwg
>>
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg