Re: [dhcwg] Updated Draft "DHCP Discovery Extensions"

Presumably this is only aimed at DHCPv4?

Tim

On Wed, Nov 19, 2003 at 04:15:14PM +0100, Rentschler, Markus wrote:
> Hello DHC-WG,
> 
> I updated my draft  "DHCP Discovery Extensions" to address the issues raised
> in the past threads in this mailing list.
> 
> * state diagram drawn
> 
> * Use of Authentication (RFC 3118) proposed to address the possible
> DDoS-Attack problem through DHCPNETSCAN. 
> 
> * Default settings on the client defined (NORMAL MODE).
> 
> * New "Discovery Option" introduced that allows the Server to enable/disable
> the Discovery Extensions on the client. 
> 
> * Outlined standalone implementation of the "DHCP Discovery Extensions"
> without full RFC 2131 functionality.
>   (this is of interest for certain types of clients with limited resources,
> i.e. in the field of industrial automation)
> 
>  <<draft-rentschler-dhc-discovery-01.txt>> 
> 
> Please don't hesitate to submit your comments :-)
> 
> Best Regards,
>           Markus Rentschler

> 
> DHC                                                 Markus Rentschler
> Internet Draft                                 Hirschmann Electronics          
> Expires: May 2004                                       November 2003
> 
> 
>                       DHCP Discovery Extensions
>                <draft-rentschler-dhc-discovery-01.txt>
> 
> Status of this Memo
> 
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups. Note that other
>    groups may also distribute working documents as Internet-Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time. It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at http://
>    www.ietf.org/ietf/1id-abstracts.txt.
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
> 
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society (2003). All Rights Reserved.
> 
> 
> 
> Abstract
> 
>    The discovery mechanism described here is built upon and coexists
>    with BOOTP according to RFC 1542 and DHCP according to RFC 2131 
>    and RFC 3203.
>    It allows server-initiated communication to specific or all clients 
>    in the network, using the DHCP packet format and with that the
>    relay agent functionality. 
>    The Discovery Extensons are a powerful and flexible add-on to 
>    client-initiated DHCP that allow a variety of applications.
>    
> 
> 
> 
> 
> 
> 
> 
> 
> Rentschler                Expires May 2004                      [Page 1]
> 
> Internet-Draft         DHCP Discovery Extensions                Dec 2003
> 
> 
> Requirements terminology
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119.
> 
> 
> 
> 1. Introduction
> 
>    Host Configuration using "traditional" DHCP according to RFC 2131
>    is based on host- (client-) initiated communication. If a network
>    is booting, all the clients start sending DHCP requests until 
>    accepting an answer from a DHCP server.
>    The server may either allocate IP addresses out of a pool of 
>    available adresses or, similar to BOOTP, pre-configured static
>    IP addresses and configuration parameters for each known client.
> 
>    These concepts did not intend server-initiated and -controlled
>    configuration or reconfiguration of clients. This capability was
>    later partially added with RFC 3203, but the mechanism there does
>    not allow to discover "silent" clients yet unknown to a server or
>    trigger the configuration of such a client.  
>    This is especially limiting when a server is later plugged to an
>    already configured network. 
>    These shortcomings will be overcome with the protocol extensions 
>    described in this document, which will provide useful functionality
>    for centralized network administration, for example:
> 
>    - scanning the network for clients even prior to their 
>      initialization with IP parameters. Building a database of all 
>      clients present in a network. 
>    - detecting and identifying duplicate network addresses
>    - administrator controlled reconfiguration of certain clients 
>    - server redundancy mechanism
> 
>    The main goal of the discovery extension is to allow as much
>    flexibility as possible for the server to communicate with the
>    client(s) to allow a wide range of applications, which are not
>    subject of this document. 
> 
>    The DHCP Discovery Extensions may also be adopted for DHCPv6.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Rentschler                Expires May 2004                      [Page 2]
> 
> Internet-Draft         DHCP Discovery Extensions                Dec 2003
> 
> 
> 2. The DHCP Discovery Protocol
> 
>    The Discovery Extensions provide a server-initiated communication
>    mechanism that work as follows:
> 
>    The server sends the new DHCPNETSCAN message into the network, 
>    either as broadcast to all clients or directed to a certain client. 
>    The client responds with the new DHCPREPORT message containing 
>    the client's actual parameter settings. A server that receives 
>    the DHCPREPORT message SHOULD use the information contained in 
>    this message to maintain its internal database (list of clients 
>    and leases). 
> 
>    For the configuration of a certain client the server sends the 
>    new DHCPCONFIGURE message to this client that contains all
>    parameters that the server wishes to transfer to the client.
>    The client responds with a DHCPREPORT message back to the 
>    server(s) to indicate if it accepted the new configuration 
>    parameters. The DHCP client MUST maintain its internal database
>    and MUST -if it accepted new IP settings- terminate an already
>    existing lease by sending a DHCPRELEASE message towards the
>    initially lease granting server.
> 
>    One of the intentions of the DHCP Discovery Extension is to work
>    with an inactive DHCP client (in terms that the client is not sending
>    initial DHCPDISCOVER messages) to allow the configuration process be
>    entirely performed and controlled by the administrator's
>    management station, without having the network flooded with 
>    DHCPDISCOVER-Requests at powerup. 
>    This mode shall be referred to as SILENT MODE.
>    In SILENT MODE The client is always ready to receive and processs the
>    new DHCPNETSCAN and DHCPDISCOVER messages according to the procedures
>    described in this document. In this mode the Authentication Option
>    [RFC 3118] from a server MAY be ignored.
>    The SILENT MODE is however only an optional mode of operation that
>    MAY be configured on the client. Clients with limited resources MAY
>    only implement the Discovery Extensions, therefore not supporting
>    full DHCP functionality according to RFC 2131.
> 
>    The DHCP Discovery Extensions MUST also work with an active client
>    that is sending initial DHCPDISCOVER messages. 
>    This mode shall be referred to as NORMAL MODE.
>    In NORMAL MODE the Discovery Extensions MUST only be enabled through
>    the DHCP Server by the new "Discovery Option" that MAY be transferred
>    for this purpose from the server to the client.
>    If in this mode the authentication mechanism according to RFC 3118 
>    is used, authentication MUST also be applied to the new Discovery 
>    Extension messages. 
>    The NORMAL MODE is RECOMMENDED as default setting on the client.
> 
> 
> Rentschler                Expires May 2004                      [Page 3]
> 
> Internet-Draft         DHCP Discovery Extensions                Dec 2003
> 
> 
> 3. New DHCP message types and options
> 
>    Three messages MUST be added to the set of existing DHCP messages:
> 
>    DHCPNETSCAN
>    DHCPCONFIGURE
>    DHCPREPORT
> 
>    The value of the message types -to be encoded in DHCP option 53-
>    is left as TBD until assigned by IANA.
> 
>    Existing correct implementations of DHCP clients or servers SHOULD
>    ignore and discard these new message types.  
>    To existing correct implementations of BOOTP relay agents these new
>    message types SHOULD be transparent.
>    The usage of the 'Parameter Request List' Option gets extended within
>    the scope of this document. RFC 2131 and RFC 2132 limit the use of
>    this option in direction from client to server. The new message 
>    types defined in this document are allowed to transfer the 'Parameter
>    Request List' option also from server to client.
> 
> 
> 3.1 DHCPNETSCAN message
> 
>    The DHCPNETSCAN message is sent from a server to one client
>    (unicast) or to all clients (broadcast). A broadcasted DHCPNETSCAN
>    message SHOULD be broadcasted into a relay agent's other subnets. 
>    Its purpose is to request the client's actual parameter settings 
>    and report them to the server(s) by triggering a DHCPREPORT message.
> 
>    Field      Contents
>    -----      ------------ 
>    'op'       BOOTREPLY  (RFC 2131: server to client direction)
>    'xid'      'xid' from server 
>    'secs'     0
>    'flags'    Set 'BROADCAST' flag if server requires broadcast reply
>    'ciaddr'   0 or client's network address 
>    'yiaddr'   0
>    'siaddr'   IP address of server
>    'giaddr'   0 or the target relay agent's interface IP adress
>    'chaddr'   0 or client's hardware address
>    'sname'    unused
>    'file'     unused
>    'options'  53: DHCP Message Type: DHCPNETSCAN
>               54: Server Identifier
>               55: Parameter Request List 
>               82: Relay information option (MAY be used for path information, 
>                   if a relay is involved in transportation to the client)
> 
> 
> 
> Rentschler                Expires May 2004                      [Page 4]
> 
> Internet-Draft         DHCP Discovery Extensions                Dec 2003
> 
> 
> 3.2 DHCPCONFIGURE message
> 
>    The DHCPCONFIGURE message is sent from a server to a certain client.
>    Its purpose is to provide the client with new parameter settings. 
> 
> 
>    Field      Contents
>    -----      ------------ 
>    'op'       BOOTREPLY  (RFC 2131: server to client direction)
>    'xid'      'xid' from server 
>    'secs'     0
>    'flags'    Set 'BROADCAST' flag if server requires broadcast reply
>    'ciaddr'   0 or client's network address 
>    'yiaddr'   IP address for client
>    'siaddr'   IP address of server
>    'giaddr'   0    
>    'chaddr'   0 or client's hardware address
>    'sname'    Server host name or options
>    'file'     Client boot file name or options
>    'options'  53: DHCP Message Type: DHCPCONFIGURE
>               54: Server Identifier
>               55: Parameter Request List 
>   	      additional any other option, which must then also be
>               present in the parameter request list.	
> 
>     It is RECOMMENDED that upon ip configuration the following options
>     SHOULD be included:
>             01: Subnet Mask
>             03: Router
>             51: IP address lease time
>             61: Client-Identifier
> 
>     For reconfiguration of single non-ip parameters, only the options 
>     representing these parameters are required to transmit.
>     
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
> 
> 
> 
> 
> 
> Rentschler                Expires May 2004                      [Page 5]
> 
> Internet-Draft         DHCP Discovery Extensions                Dec 2003
> 
> 
> 3.3 DHCPREPORT message
> 
>    The purpose of this message is to report the client's actual 
>    parameter settings to one or all servers. It is the acknowledgement
>    towards the server upon a DHCPNETSCAN or DHCPCONFIGURE request.
> 
>    The DHCPREPORT message is sent from a client to a server as
>    broadcast or unicast, depending on the 'BROADCAST' flag in the
>    original DHCPNETSCAN or DHCPCONFIGURE message and the state of
>    the client's IP stack. A client that has not yet assigned a 
>    valid IP address SHOULD always broadcast this message, 
>    using 0.0.0.0 as source address and the limited broadcast 
>    address 255.255.255.255 as destination address.
> 
> 
>    Field      Contents
>    -----      ------------ 
>    'op'       BOOTREQUEST  (RFC 2131: client to server direction)
>    'xid'      'xid' from server 
>    'secs'     0 or seconds since DHCP process started
>    'flags'    flags from DHCPNETSCAN or DHCPNETCONIFG message
>    'ciaddr'   0 or client's network address 
>    'yiaddr'   IP address of client
>    'siaddr'   0 
>    'giaddr'   0    
>    'chaddr'   client's hardware address
>    'sname'    Server host name or options
>    'file'     Client boot file name or options
>    'options'  53: DHCP Message Type: DHCPREPORT
>               54: Server Identifier
>               57: Maximum DHCP Message Size
> 	      additional all supported options requested 
>               in DHCPNETSCAN or DHCPCONFIGURE.
> 
>    The client MUST omit any options it cannot provide.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Rentschler                Expires May 2004                      [Page 6]
> 
> Internet-Draft         DHCP Discovery Extensions                Dec 2003
> 
> 
> 3.4 Discovery Option
> 
>    The purpose of this option is to configure and report the state
>    of the Discovery Extensions on the client. 
>    The Discovery Option is an 8-bit number.
> 
>         Code   Len   Value
>        +-----+-----+-----+
>        | TBD |  1  |  a  |
>        +-----+-----+-----+
> 
>    The code for this option is TBD, and its length is 1.
> 
>    The Discovery Option uses the following values:
> 
>             DiscoveryDisabled      0
>             DiscoveryEnabled       1
>             DiscoveryOnly          2
> 
>    Clients that support the Discovery Extensions MUST add the Discovery
>    Option to the list of options included in its DHCPDISCOVER and 
>    DHCPREQUEST messages. An absence of this option indicates
>    that the client does not support the Discovery Extensions.
> 
>    If this option is requested by the server in a DHCPNETSCAN or 
>    DHCPCONFIGURE message, it MUST be included in the DHCPREPORT message.
> 
>    The server MAY include the Discovery Option in a DHCPACK message or 
>    a DHCPCONFIGURE message to configure the Discovery Extensions on the
>    client. 
> 
>    The value DiscoveryOnly(3) MUST be transferred from client to server
>    to indicate that only the Discovery Extensions are supported on this
>    client, but not full RFC 2131 functionality. In this case a server 
>    MUST always assign infinite leases.
> 
>    In SILENT MODE the client MAY ignore the Discovery Option sent from 
>    a server.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Rentschler                Expires May 2004                      [Page 7]
> 
> Internet-Draft         DHCP Discovery Extensions                Dec 2003
> 
> 
> 4. Extended DHCP state diagram
> 
> +--------+             +------+
> | Init / |         +-->+ Init +<---------------+-------------------+
> | Reboot |         |   +--+---+                |                   |
> +---+----+     DHCPNAK/ -/Send DHCPDISCOVER    |                   |
>     |          Restart    |     (broadcast)    |                   |
>     |              |      v   v-------------+  |                   |
>  -/Send DHCPREQUEST| +----+------+    DHCPOFFER/DHCPDECLINE        |
>     |   (broadcast)| | Selecting |----------+  |                   |
>     v              | +----+------+             |                   |
> +---+----+         |   DHCPOFFER/DHCPREQUEST   |                   |
> | Reboot +---------+  (broadcast)              |                   |
> +---+----+                v                    |                   |
>     |                +----+-------+            DHCPNAK /halt network
>     |                + Requesting |            |       lease expired
>    DHCPACK/          +----+-------+            |                   |
>    Record lease           |                    |                   |
>    set timers         DHCPACK/Record lease     |                   |
>     |                     v   Set T1 & T2      |                   |
>     |                  +--+----+DHCPFORCE  +---+---+          +----+---+
>     +----------------->+ BOUND +---------->+ Renew +--------->+ Rebind |
>                        +--+-+--+T1 expires +-+-+---+T2 expires+----+---+
>                           ^     /DHCPREQUEST | |    /broadcast     |
>                        DHCPACK    to leasing | |    DHCPREQUEST    |
>                           |        server    | |                   |
>                           +----------------------------------------+
>                                          
>                                                              
>                                       
>                                +----------+     
>                  +------------>+ Discover |  
>                  |             +-----+----+    
>                  |                   |     
>                  |        DHCPNETSCAN/Send DHCPREPORT          
>                  |                   |                         
>                  |                   |                         
>                  |                   |                         
>                  |       DHCPCONFIGURE/Send DHCPRELEASE if appropriate      
>                  |                   | Send DHCPREPORT        
>                  |                   | Record lease            
>                  |                   | Set T1 & T2             
>                  |                   | Set main state = BOUND         
>                  |                   |                         
>                  +-------------------+
> 
> 
> Note:  The "Discover" state is a parallel state that runs independently
>        from the DHCP main state machine.
> 
> 
> Rentschler                Expires May 2004                      [Page 8]
> 
> Internet-Draft         DHCP Discovery Extensions                Dec 2003  
> 
> 
> 5. The DHCP Server
> 
>    DHCP Server implementations MAY incorporate any administrative 
>    controls or policies desired by network administrators that make use
>    of the underlying protocol described in this and related documents.
> 
>    DHCP servers that support the protocol described in this document
>    MUST be able to send DHCPNETSCAN and DHCPCONFIGURE messages, 
>    either automatically at startup, program controlled, in certain
>    intervals and/or on manual requests. 
> 
>    The content of the BROADCAST flag in the DHCPNETSCAN and
>    DHCPCONFIGURE messages SHOULD be configurable and disabled
>    by default.
> 
>    The DHCP server MUST be able to receive DHCPREPORT messages and 
>    SHOULD use them to verify the state of pending requests. 
> 
>    The 'xid' field SHOULD be used by the server to match incoming DHCP 
>    messages with pending requests. 
>    Pending requests SHOULD be supervised using a timeout mechanism. 
>    The timeout value MUST be configurable and SHOULD have a default
>    value of 4 seconds. 
>    A retransmission strategy for unacknowledged requests SHOULD be 
>    implemented.
> 
>    The server MAY use all received DHCPREPORT messages to build and
>    maintain an internal database (based on IP addresses), that MAY 
>    contain all known leases in the network. This database MAY be 
>    periodically updated by sending DHCPNETSCAN messages. 
>    If a server receives a DHCPREPORT message for a lease that was 
>    granted by itself, the contents MUST be checked for consistency
>    with the internal lease database. 
>    If any inconsistency is detected (i.e. unknown MAC address or 
>    wrong relay agent information option contents), these DHCPREPORTS
>    MUST be ignored and their occurence MUST be reported to the 
>    administrator.
> 
>    It is RECOMMENDED that a timeout mechanism removes expired leases 
>    in this database.
>    The server MUST be able to renew and rebind existing leases which
>    were granted by itself.
>    The server MAY be able to rebind existing leases which were not 
>    granted by itself, but are listed in its internal database as known
>    leases. This feature should be configurable and disabled by default.
> 
>    If duplicate IP addresses are detected in the database, the server
>    SHOULD report this to the administrator.
>    If duplicate client identifiers (DHCP Option 61) are detected in
>    the database, the server SHOULD report this to the administrator.
> 
> Rentschler                Expires May 2004                      [Page 9]
> 
> Internet-Draft         DHCP Discovery Extensions                Dec 2003
> 
> 
> 6. The DHCP Client
> 
>    The DHCP client needs to be modified to incorporate the handling of 
>    the new message types.
> 
>    In NORMAL MODE the use of message authentication following the 
>    procedures described in RFC 3118 is RECOMMENDED. 
>    If authentication is used, the DHCPNETSCAN and DHCPCONFIGURE 
>    messages MUST also be authenticated by the client.
> 
>    If the Discovery Extensions are enabled and -if applicable- proper 
>    authentication took place, the client MUST process received 
>    DHCPNETSCAN and DHCPCONFIGURE messages as described in this document.
>    It answers these messages from the server with the message DHCPREPORT
>    and return in it the requested parameters to the server.
>    DHCPREPORT contains always the client's current parameter settings.
>    The client MUST omit any parameters it cannot provide.
> 
>    The sending of a broadcast DHCPREPORT message that was generated
>    in response to a DHCPNETSCAN message SHOULD be delayed a random time
>    interval up to 2 seconds to prevent broadcast storms on the network.
>    DHCPNETSCAN messages that arrive in the meantime, SHOULD be silently
>    discarded and not queued for processing.
>    
>    The Discovery Extensions run in their own parallel state 'Discover',
>    that is not influenced by the client's main state.
>    The client's handling of a received DHCPNETSCAN message SHOULD be
>    the same in every state of the DHCP client's state machine. It SHOULD
>    not affect the current state of the client's state machine. 
> 
>    The receipt of a DHCPCONFIGURE message MUST result in the
>    following actions:
>    If the message and the parameters offered to the client are correct
>    the new parameters MUST be accepted. An existing lease MUST be 
>    terminated by sending a DHCPRELEASE message. Then the client's IP 
>    stack is initialized with the new parameters and the client sends a
>    DHCPREPORT to the server, containing the new parameter settings.
>    Then the DHCP client's main state machine is set to the state BOUND
>    and starts its timers T1 and T2 for the renewing/rebinding process.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Rentschler                Expires May 2004                     [Page 10]
> 
> Internet-Draft         DHCP Discovery Extensions                Dec 2003
> 
> 
> 7. The BOOTP Relay Agent
>  
>    DHCPNETSCAN messages that are received as IP broadcast on one of
>    the relay's interfaces MUST be broadcasted in all other IP subnets
>    accessible by this relay agent. 
>    This option SHOULD be configurable and disabled by default. 
> 
>    DHCPNETSCAN messages that are received as IP unicast directed to 
>    one of the relay agent's IP interfaces and have the giaddr field
>    set to the same interface address MUST be broadcasted only on the
>    physical ports attached to this IP interface. This allows scanning
>    of a specified subnet.
>    This option SHOULD be configurable and disabled by default. 
> 
>    If one of the above packets -directed to the client- has the relay
>    agent information option present, this field SHOULD be examined.
>    If the contents of the Agent Remote ID matches the relay agent's
>    unique identifier (i.e. MAC, Client-Id or an IP address) AND the 
>    Agent Circuit ID suboption contains a valid physical port number,
>    this information SHOULD be used to forward the DHCPNETSCAN 
>    message to the client. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Rentschler                Expires May 2004                     [Page 11]
> 
> Internet-Draft         DHCP Discovery Extensions                Dec 2003
> 
> 
> 8. Security Considerations
> 
>    In this section possible security attacks and prevention 
>    mechanisms will be discussed.
> 
>    - Distributed Denial of Service attacks through DHCPNETSCAN
> 
>    A bogus server may flood the network with broadcast DHCPNETSCAN
>    messages at such a rate, that due to multiple client responses 
>    other communication will slow down.
>    In order to keep damage low in case of such an attack, the client
>    delays the generation of the DHCPREPORT message and discards 
>    DHCPNETSCAN messages that were received in the meantime. 
>    In NORMAL MODE an authentication mechanism [RFC 3118] SHOULD be used
>    to verify the integrity of the server.
> 
> 
>    - Denial of Service attacks through DHCPCONFIGURE
> 
>    A bogus server may send DHCPCONFIGURE packets to misconfigure 
>    clients in the network. 
>    In Normal MODE an authentication mechanism [RFC 3118] SHOULD be used
>    to verify the integrity of the server.
> 
> 
>    - Denial of Service attacks through DHCPREPORT
> 
>    A bogus client may send DHCPREPORT packets into the network to
>    misinform servers about existing leases in the network. 
>    A server that has granted a lease needs to check incoming 
>    DHCPREPORTS concerning this lease for consistency.
>    If authentication [RFC 3118] is used, the integrity of such bogus 
>    messages can be checked and subsequently discarded.   
> 
>    
> 
> 9. IANA Considerations
> 
>    The value for the new message types 
>    
>    DHCPNETSCAN
>    DHCPCONFIGURE
>    DHCPREPORT
> 
>    and the new "Discovery Option" must be assigned from the numbering
>    space defined for message types ond options in RFC 2939.
> 
> 
> 
> 
> 
> Rentschler                Expires May 2004                     [Page 12]
> 
> Internet-Draft         DHCP Discovery Extensions                Dec 2003
> 
> 
> 10. References
> 
>     RFC 1542  W. Wimer, October 1993,
>               "Clarifications/Extensions for the Bootstrap Protocol",
>     RFC 2131  R. Droms, March 1997, 
>               "The Dynamic Host Configuration Protocol", 
>     RFC 2939  R. Droms, September 2000, 
>               "Procedures an IANA guidelines for Definition
>                of new DHCP Options and Message Types", 
>     RFC 3046, M. Patrick, January 2001, 
>               "DHCP Relay Agent Information Option", 
>     RFC 3118  R. Droms and W. Arbaugh, June 2001, 
>               "Authentication for DHCP Messages",
>     RFC 3203, Y. T'Joens et. al., December 2001, 
>               "DHCP reconfigure extension", 
> 
> 
> 11. Acknowledgments
> 
>    We Acknowledge the help of .... and all the members of the
>    development department at Hirschmann Electronics GmbH & Co. KG.
> 
> 12. Author's Address
> 
>    Markus Rentschler
>    Hirschmann Electronics GmbH & Co. KG,
>    Neckartenzlingen,
>    Germany.
>    Email: mrentsch@nt.hirschmann.de
> 
> 
> Full Copyright Statement
> 
>    Copyright (C) The Internet Society (2003). All Rights Reserved.
> 
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph
>    are included on all such copies and derivative works. However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into.
> 
> 
> 
> 
> Rentschler                Expires May 2004                     [Page 13]
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg