Subject: New I-D: draft-ietf-dhc-useraddr-00.txt

From: Ye Gu <[email-masked]>
Date: Mon, 2 Nov 1998 18:17:01 -0500 (EST)

This is a new Internet Draft.  This draft is a work item of the Dynamic
Host Configuration Working Group of the IETF.  If you have any questions
concerning the draft, please email me at [email-masked].

	Title		: DHCP Use of the User Class Option for Address
                    Assignment
	Author(s)	: Y. Gu, R. Vyaghrapuri, B. Beser
	Filename	: draft-ietf-dhc-useraddr-00.txt
	Pages		: 5
	Date		: 02-Nov-98

   This document proposes a mechanism that DHCP clients can use optionally
   to obtain their IP addresses from different address pools configured on
   a DHCP server.  A DHCP client can specify a class to which it belongs.
   Based on the class, a DHCP server selects the appropriate address pool
   to assign an address to the client.

Thanks!

Ye Gu

----------

Network Working Group                                 Ye Gu, Microsoft 
INTERNET DRAFT                           Ramesh Vyaghrapuri, Microsoft
                                                    Burcak Beser, 3Com  
                                                          October 1998
                                                    Expires April 1999

       DHCP Use of the User Class Option for Address Assignment
                  <draft-ietf-dhc-useraddr-00.txt>

Status of this Memo

This document is an Internet Draft.  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.  
Internet Drafts may be updated, replaced, or obsoleted by other 
documents at any time.  It is not appropriate to use Internet Drafts as 
reference material or to cite them other than as a "working draft" or 
"work in progress".

To learn the current status of any Internet-Draft, please check the 
1id-abstracts.txt listing contained in the Internet-Drafts Shadow 
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 
munnari.oz.au.

Abstract

This document proposes a mechanism that DHCP clients can use optionally 
to obtain their IP addresses from different address pools configured on 
a DHCP server.  A DHCP client can specify a class to which it belongs.  
Based on the class, a DHCP server selects the appropriate address pool 
to assign an address to the client.

1. Introduction

With the popularity and importance of the Internet growing, many 
organizations and public carriers are deploying IP-based networks.  An 
IP network is a heterogeneous environment that supports various kinds 
of devices, users and applications (which are referred to generically 
as "users" in the rest of this document).  Often IP network 
administrators are faced with the need to provide different levels of 
service quality or access privilege to different users.

In order for an IP network to implement differentiated services, it 
needs a way to classify users.  A simple solution to this is to use 
source IP addresses for classification.

Under this scheme, network administrators first configure network 

Gu, Vyaghrapuri, Beser                                        [Page 1]

Internet Draft    User Class Option for Address Assignment    Nov 1998

devices such as routers to recognize traffic from a particular source 
IP address (or address range) and handle it specially to meet the 
desired level of service.  Next, they assign the IP address(es) to the 
host(s) of the intended user(s) so that the user(s) will receive the 
appropriate level(s) of service.  They can configure the hosts manually 
with these addresses.  However, they cannot use DHCP [1] for address 
assignment, even if they are already running a DHCP server in their 
network.  A current RFC-compliant DHCP server assigns IP addresses 
based on the location of the DHCP Client in the network topology, not 
the type of user it supports.

This document describes a simple extension of the DHCP protocol that 
enables a DHCP server to assign IP addresses from different address 
pools depending on the types of client from which it receive DHCP 
requests.  With this new extension, network administrators will be able 
to use DHCP to hand out the appropriate addresses to users (assuming 
that the user type maps to the client type).

An example intended usage is a corporate network subnet consisting of 
different departments of users, such as Accounting, Legal, Staff etc.   
It may be desirable to allocate logical address pools to each of the 
departments so that network policies may be implemented easily on IP 
address ranges; and this would facilitate providing differential 
services, such as network reachability.

2. Definitions

Throughout this document, the words that are used to define the  
significance of particular requirements are capitalized.  These words 
are:

      o "MUST"

        This word or the adjective "REQUIRED" means that the
        item is an absolute requirement of this specification.

      o "MUST NOT"

        This phrase means that the item is an absolute prohibition
        of this specification.

      o "SHOULD"

        This word or the adjective "RECOMMENDED" means that there
        may exist valid reasons in particular circumstances to 
        ignore this item, but the full implications should be 
        understood and the case carefully weighed before choosing a 
        different course.

Gu, Vyaghrapuri, Beser                                        [Page 2]

Internet Draft    User Class Option for Address Assignment    Nov 1998

      o "SHOULD NOT"

        This phrase means that there may exist valid reasons in
        particular circumstances when the listed behavior is 
        acceptable or even useful, but the full implications should 
        be understood and the case carefully weighed before 
        implementing any behavior described with this label.

      o "MAY"

        This word or the adjective "OPTIONAL" means that this item 
        is truly optional.  One vendor may choose to include the 
        item because a particular marketplace requires it or because 
        it enhances the product, for example; another vendor may 
        omit the same item.

3. Schema Overview

The user class option [3] is used by a DHCP client to inform DHCP 
servers about the category of system, user or application it 
represents.

In the following section, it is assumed that the DHCP Client MAY send 
multiple User Class options in the same message.  (They may or may not 
occur consequetively).  

Each address pool on the DHCP Server MAY be configured with a set of 
ALLOWED USER CLASSES, specifying the category of clients accepted by 
the DHCP Server; and with a set of DISALLOWED USER CLASSES, specifying 
the category of clients that must NOT be offered addresses from the 
address pool.

4. Address Assignment

Whenever any DHCP client message is seen by the DHCP Server, it MUST do 
the regular processing [1] and if the DHCP Server determines that the 
Client is to be offered a new (or unbound)IP address, the following 
procedure MUST be adopted:

If the client DHCP message does not contain any User Class options, 
then the DHCP Server MUST attempt to choose an available address pool 
which has both the ALLOWED and DISALLOWED USER CLASSES empty.   If no 
such address pool is available, and if the DHCP Server has been 
specifically configured to do so, it MUST attempt chose any available 
address pool.

If the client DHCP Message contains any User Class options, then the 
DHCP Server MUST attempt to choose an available address pool for which 
the ALLOWED USER CLASSES set contains one of the user class options 

Gu, Vyaghrapuri, Beser                                        [Page 3]

Internet Draft    User Class Option for Address Assignment    Nov 1998

present in the DHCP message; and for which none of the User Class 
options present in the DHCP message are also present in the DISALLOWED 
USER CLASSES set.  If no such address pool is available, and if the 
DHCP Server has been specifically configured to do so, it MUST attempt 
to choose any address pool for which none of the User Class options 
present in the DHCP message are also present in the DISALLOWED USER 
CLASSES set.

If the DHCP Server is unable to find a suitable address pool, it MUST
NOT offer an IP address to the Client.  It MAY indicate the condition
to the administrator.

5. Address Renewal

At renewal time, before the DHCP Server sends an DHCP ACK as per [1], 
it MUST check to see if the address pool of the Client's IP address has 
any of the User Class option values in the DHCP message of the Client 
present in the DISALLOWED USER CLASSES set; or, if the ALLOWED USER 
CLASSES set has none of the User Class option values in the DHCP 
message, and the DHCP Server is NOT specifically configured to allow a 
client whose user class options do not belong to either of the two sets 
of USER CLASSES.   If either of the two checks above succeed, the DHCP 
Server MUST send a DHCP NACK message to the client and remove the 
binding information.   The DHCP Server MAY send an indication via the 
MESSAGE option.  

6. Security Considerations

DHCP currently provides no authentication or security mechanisms. 
Potential exposures to attack are discussed is section 7 of the 
protocol specification [1].

7. Acknowledgements

The authors would like to thank Munil Shah and Peter Ford for reviewing
this draft.

8. References

[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 
1997.
[2] Alexander, S., and Droms R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[3] Stump, G., and Droms R., "The User Class Option for DHCP", Internet 
Draft, November 1997.

Gu, Vyaghrapuri, Beser                                        [Page 4]

Internet Draft    User Class Option for Address Assignment    Nov 1998

9. Author's Address

   Ye Gu
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: 425 936 8601
   EMail: [email-masked]

   Ramesh Vyaghrapuri
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: 425 703 9581
   Email: [email-masked]

   Burcak Beser
   3Com Corporation
   3800 Golf Road
   Rolling Meadows, IL

   Phone: 847 262 2195
   Email: [email-masked]

   This document will expire in April 1999.

Gu, Vyaghrapuri, Beser                                        [Page 5]

---

From: "Ryan Troll" <[email-masked]>
Date: Tue, 3 Nov 1998 11:30:21 -0500 (EST)

A few comments inline:

> [ ... ]

consequetively -> consecutively

> At renewal time, before the DHCP Server sends an DHCP ACK as per [1],

.. sends a DHCP ACK ...

If the entire paragraph of section 5 could be split up into a few smaller
sentences, I think it would really flow better.  Right now, it's one huge
sentence, and I keep having problems reading it.  (I'm not a good reader to
begin with. :)

How do DHCP Informs fit into the picture?  I would assume that any user
class info included in an Inform is not checked, as there is no way to send
a NACK to an Inform.

-Ryan

---

From: [email-masked] (Glenn Waters)
Date: Thu, 5 Nov 1998 15:58:32 -0500 (EST)

> class info included in an Inform is not checked, as there is no

i didn't think you could send a NAK in response to a renew request. here is
what RFC2131 says about a renew.  maybe the draft needs clarification.

from 2131:

   o DHCPREQUEST generated during RENEWING state:

      'server identifier' MUST NOT be filled in, 'requested IP address'
      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
      client's IP address. In this situation, the client is completely
      configured, and is trying to extend its lease. This message will
      be unicast, so no relay agents will be involved in its
      transmission.  Because 'giaddr' is therefore not filled in, the
      DHCP server will trust the value in 'ciaddr', and use it when
      replying to the client.

      A client MAY choose to renew or extend its lease prior to T1.  The
      server may choose not to extend the lease (as a policy decision by
      the network administrator), but should return a DHCPACK message
      regardless.

nowhere is it implied that NAK is allowed. however it does seem to imply
that a ACK could be sent with a modified lease time.

---

From: Mark Stapp <[email-masked]>
Date: Thu, 5 Nov 1998 17:33:05 -0500 (EST)

The state machine for clients on p.34 of RFC2131 indicates transitions that
result from NAK'd RENEW and REBIND attempts. I agree that the
text/narrative should be brought into sync with the state machine.

Mark