[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] DHCPv6 and DHCPv4 Vendor Message Drafts (IndividualSubmissions) / Agenda Time Request
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
>>-----Original Message-----
>>From: Bernie Volz (volz) [mailto:volz at cisco.com]
>>Sent: Thursday, July 17, 2008 12:20 PM
>>To: Sheng Jiang; dhcwg at ietf.org
>>Cc: Ralph Droms (rdroms)
>>Subject: 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