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

[Bud Millwood <budm at weird-solutions.com>]

On Thursday 17 July 2008, Sheng Jiang wrote:
> 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.

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



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