unsubscribe please

unsubscribe please

Please unsubscribe this Email Address:

 <mailto:archanag <at> ishoni.com > archanag <at> ishoni.com 

 best regards

Archana Gudi 

I-D ACTION:draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: IPv6 Prefix Options for DHCPv6
	Author(s)	: O. Troan, R. Droms
	Filename	: draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt
	Pages		: 18
	Date		: 2002-12-2
	
The Prefix Delegation options provide a mechanism for automated
delegation of IPv6 prefixes using DHCP.  This mechanism is intended
for delegating long-lived prefix from a delegating router to a
requesting router, across an administrative boundary, where the
delegating router does not require knowledge about the topology of
the links in the network to which the prefixes will be assigned.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

rfc2131 and releasing leases

Hi,

I understand under rfc2131 that there is no way to acknowledge a
release from a DHCP client. Are there any extensions, or any plans
on incorporating a release acknowledgement?

Problem:

Client sends DHCP release. Client shuts down.

Server doesn't get the release datagram because it was dropped
before it reached the Server. The server holds onto the lease.

How is this scenario avoided by the server if no acknowledgement is
ever sent to the client? The problem becomes worse when the client
machine reboots to another OS and tries to acquire the same lease
with a different client-id.

--

-- 
Thamer Al-Harbash            http://www.whitefang.com/
          team dresch made me do it

Editorial changes to DHCPv6 specification

draft-ietf-dhc-suboptions-kdc-serveraddress-02

INTERNET-DRAFT                                          K. Luehrs
Dynamic Host Configuration Working Group                CableLabs
Expires June 2003                                       R. Woundy
							AT&T Broadband
							J. Bevilacqua 
                                                        YAS Corporation   
                                                        December 2002


		KDC Server Address Sub-option 
         <draft-ietf-dhc-suboptions-kdc-serveraddress-02.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 (2002). All Rights Reserved.

Abstract

   This document defines a new sub-option for the CableLabs Client
   Configuration (CCC) DHCP option code for conveying the network 
   addresses of Key Distribution Center (KDC) servers.

1.  Introduction

   The need for a CCC DHCP Option code is described in [1]. The CCC 
   DHCP option code will be used to address specific needs of CableLabs
   client devices during their configuration processes. This document 
   proposes a sub-option for the CCC DHCP option.
   
   
   
   
   
   
   Luehrs, Woundy, & Bevilacqua        Expires June 2003         [Page 1]   Internet Draft	  KDC Server Address Sub-option      
December 2002
   
   
   Configuration of a class of CableLabs client devices described in 
   [2] requires a DHCP sub-option to provide the client with the 
   network address of a KDC server in the cable operator's data 
   network. The class of devices assumed in [2] is unlike the class
   of devices considered in [1], which perform a DNS lookup of the 
   Kerberos Realm name to find the KDC server network address. 
   
   This document proposes a sub-option of the CCC DHCP option
   code for use with CableLabs client devices. The proposed sub-option
   encodes an identifier for the network address of each of one or more
   Key Distribution Center servers with which the CableLabs client 
   device exchanges security information. 

   CableLabs plans to assign sub-option code ranges for the CCC option 
   according to CableLabs projects. The range (51 - 100) is assigned 
   to the CableHome project. Use of the initial value of this range is
   specified in [2].

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" 
   in this document are to be interpreted as described in RFC 2119 [3].


2.  Key Distribution Center IP Address Sub-option

   The CableHome 1.0 specification [2] specifies the Key Distribution 
   Center network address encoding as a sub-option of the CCC DHCP 
   Option code. This field is used to inform the client device of the
   network address of one or more Key Distribution Center servers. 

   The encoding of the KDC Server Address sub-option will adhere to the 
   format of an IPv4 address using the default port. The minimum length
   for this option is 4 octets, and the length MUST always be a 
   multiple of 4. If multiple KDC Servers are listed, they MUST be
   listed in decreasing order of priority. The format of the KDC Server
   Address sub-option of the CCC option code is as shown below:

    SubOpt  Len      Address 1               Address 2
   +------+-----+-----+-----+-----+-----+-----+-----+--
   |  51  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
   +------+-----+-----+-----+-----+-----+-----+-----+--


3.  Security Considerations

   This document relies upon the DHCP protocol [4] for authentication
   and security, i.e., it does not provide security in excess of what
   DHCP is (or will be) providing. It does not expose any security
   threats beyond what is currently exposed by other DHCP options.

   



   
Luehrs, Woundy, & Bevilacqua        Expires June 2003         [Page 2]
Internet Draft	  KDC Server Address Sub-option       December 2002


4.  IANA Considerations

   The KDC Server Address sub-option described in this document is 
   intended to be a sub-option of the CableLabs Client Configuration
   (CCC) option described in [1]. IANA will be requested to register
   sub-option code 51 of the CCC option to the KDC Server Address    
   sub-option.

5.  Normative References


   [1] "DHCP Option for CableLabs Client Configuration  draft-ietf-dhc-
        packetcable-05", IETF, December 2002.

   [2] "CableHome 1.0 Specification SP-CH1.0-I02-020920", CableLabs,
      	September 2002, http://www.cablelabs.com/projects/cablehome/

	specifications/.

   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
       1997.

6.  Authors' Addresses

	Kevin Luehrs
	CableLabs
	400 Centennial Parkway
	Louisville, CO 80027
	Phone:  (303) 661-9100
	EMail:  k.luehrs <at> cablelabs.com

	Richard Woundy
	AT&T Broadband
	27 Industrial Drive
	Chelmsford, MA 01824
	Phone: (978) 244-4010
	EMail: rwoundy <at> broadband.att.com

        John Bevilacqua
        YAS Corporation
        300 Brickstone Square
        Andover, MA 01810
        Phone: (978) 749-9999
        EMail: john <at> yas.com









Luehrs, Woundy, & Bevilacqua        Expires June 2003         [Page 3]
Internet Draft	  KDC Server Address Sub-option       December 2002


7.  Full Copyright Statement

   Copyright (C) The Internet Society (2002). 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 develop-
   ing 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 languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.


   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



























Luehrs, Woundy, & Bevilacqua        Expires June 2003         [Page 4]

Draft minutes from Atlanta

			DHC WG Meeting minutes
			 (Draft, 12/12/2002)
		      IETF 55, Atlanta, 11/2002
		      =========================

Administrivia, agenda bashing, Ralph Droms
------------------------------------------
CableLabs Client Configuration option draft is in IETF last call.  So
far, the last call has elicited comments requiring some editorial and
minor specification changes.

DHCPv6 specification has been reviewed by IESG, and requires small
edits to text describing relay agent security.  Droms will post
summary of changes to WG mailing list.

Use of IPsec for Securing DHCPv4 Messages Exchanged Between Relay
Agents and Servers, Ralph Droms
-----------------------------------------------------------------
draft-droms-dhcp-relay-agent-ipsec-00.txt describes use of IPsec for
securing messages between relay agents and servers.  Carl Smith asked
if it is different than the mechanism in the DHCPv6 draft; answer:
no.  Narten asked for comparison with Stapp's
draft-ietf-dhc-auth-suboption-01.txt.   Droms noted IPsec mechanism is
hop-by-hop while authentication options covers entire path; IPsec
mechanism incurs extra complexity if there are multiple relay agents
in the path to the server.  The WG agreed to take the document on as
a WG document.

The Authentication Suboption for the DHCP Relay Agent Option,
Mark Stapp
------------------------------------------------------------------
draft-ietf-dhc-auth-suboption-01.txt specifies a DHCP-specific
mechanism, based on a relay agent suboption that contains a message
digest for checking message integrity.  This mechanism uses shared
keys and includes an identifier mechanism to accommodate edge devices
that don't use giaddr.  With additional changes, this mechanism can
accommodate multiple, nested relay agents.

The WG was asked what to do with the two proposals: advance both,
adopt one?  Does the WG have a clear understanding of the two
proposals?  Ted Lemon asked how we might weight the pros and cons.
Thomas Narten and Stuart Cheshie asked if there is any data on whether
IPsec implementations are available to relay agents today.  Mark Stapp
asked about potential computational complexity issues.  Stapp, Lemon
and John Schnizlein all asked what the perceived customer requirements
are.  Droms expressed concern about interoperability if both proposals
are advanced.  Erik Nordmark asked how relay agents would be
configured to use IPsec or with the keys for the relay agent option.
Droms pointed out that reuse of IPsec technology implies the
availability of future IPsec enhancements.  Schnizlein volunteered to
organize discussion of pros and cons of both proposals on the WG
mailing list.

DHCP Option for SNMP Notifications, Mark Bakke
----------------------------------------------
draft-bakke-dhc-snmp-trap-01.txt was developed to address requirements
for systems using diskless boot to obtain a list of IP addresses to
which to send SNMP traps.  Narten asked which WG is best for
discussion of this option - in theory, details should be discussed in
an SNMP WG with final review of syntax and compatibility in the dhc
WG.  Narten will coordinate review of the document with MIB groups in
the IETF, and the document will ultimately be a dhc WG work item, as
there are no appropriate active SNMP WGs.  There was a question about
whether the option should be expanded with multiple sub-options for
different trap types.

Subnet Allocation using DHCP, Richard Johnson
---------------------------------------------
This proposal describes a mechanism through which a DHCP server can
delegate a block of addresses (IPv4), collect usage data on the
delegated addresses and deprecate use of addresses.  It is similar to
the prefix delegation mechanism for DHCPv6.  Ted Lemon pointed out
that this proposal would require a major revision to existing
server, and he suggested that the authors review previous, related
work by Walt Lazear.  The WG agreed to take on this document as a WG
work item.

DHCP Server-ID Override Suboption, Richard Johnson
--------------------------------------------------
Some DHCP client messages, such as DHCPRENEW, are unicast directly to
the DHCP server and not received by a relay agent.  Thus, relay agents
are unable to add relay agent options to those messages.  This
proposal provides a mechanism through which the DHCP server can
configure the client to respond to the relay agent rather than
directly to the server.  Narten asked if continued expansion of relay
agent options is a good thing.  WG consensus is that relay agent
options have been found to provide function that cannot be provided in
other ways, and the full range of application for relay agent options
is still being explored.  Stapp suggested revisiting the relay agent
option specification, RFC3046, as a WG charter item.  The WG agreed to
take on this document as a WG work item.

Considerations for the use of the Host Name option, Carl Smith
--------------------------------------------------------------
Carl had one question for the WG: how can a client request that its
name/address association be removed from DNS?  Can we use the FQDN to
accomplish this result?  Kim Kinnear and Ted Lemon asked what customer
requires this result.  Bernie Volz suggested revisiting this question
after the DHCPv6 FQDN model is completed.

Load Balancing for DHCPv6, Bernie Volz
--------------------------------------
Any more changes needed in this draft?  No; so this document is ready
for WG last call after DHCPv6 spec has advanced.

Other DHCPv6 options, Ralph Droms
---------------------------------
draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt has folded prefix
delegation into identity associations; the document is also under
discussion in the ipv6 WG.

draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt,
draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt,
draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt are all ready for WG last
call as soon as DHCPv6 advances.

draft-ietf-dhc-dhcpv6-opt-dstm-01.txt and
draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt are to be synced up with
v6ops work.

Lemon, Volz and Narten all asked about the requirement for the
mechanism proposed in draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt.
A K Vijayabhaskar (author) to clarify motivation and requirements in
the specification.

A Guide to Implementing Stateless DHCPv6 Service, Ralph Droms
-------------------------------------------------------------
Droms asked the WG about the best way to specify the parts of DHCPv6
required for stateless DHCPv6 operation ("DHCPv6-lite") - for example,
for providing DNS server configuration without address assignment.
Stuart Cheshire asked if the document should be informational or
standards-track.  Another possibility would be BCP.  The WG asked that
the Reconfigure message be added to
draft-droms-dhcpv6-stateless-guide-01.txt and accepted the document as
a dhc WG work item.

Revised DHC WG charter and milestones, Ralph Droms
--------------------------------------------------
Droms reported that the revised charter and milestones have been
submitted to the IESG.  The IESG suggested adding a separate charter
item to develop a mechanism through which a client can authenticate a
server without authentication of the client by the server.  Droms will
add the relay agent charter item suggested by Stapp (see above).

Carl Smith, Bernie Volz and Barr Hibbs volunteered to be a design team
that will follow up on the charter item to review RFC3118; they will
develop a threat model and analysis of the authentication provided by
RFC3118.  Barr Hibbs volunteered to coordinate and act as editor for a
review of the DHCPv4 specification.

Recycling option codes, Ralph Droms
-----------------------------------
There are more than 15 options codes that have been assigned but never
used.  Droms will publish an Internet Draft identifying these option
codes and asking for feedback from the Internet community about
whether these option codes can be returned to IANA for reassignment.
After the Internet Draft has been reviewed by the dhc WG and by the
IESG, it will be submitted to IANA.

DHCP Lease Query, Kim Kinnear
-----------------------------
The WG last call on draft-ietf-dhc-leasequery-05.txt has completed.
Based on input from the last call, Kinnear has changed the draft to
use a new option rather than overloading the requested address
option, and has made other editorial changes.  The document is now
ready for submission to the IESG.

Link Selection sub-option for the Relay Agent Information Option,
Kim Kinnear
-----------------------------------------------------------------
Last call on draft-ietf-dhc-agent-subnet-selection-04.txt has
completed.  This document is waiting for authentication of relay agent
messages to be resolved.

DHCP Subscriber ID Suboption for the DHCP Relay Agent Option,
Richard Johnson
-------------------------------------------------------------
This option, in draft-johnson-dhc-subscriber-id-00.txt, is motivated
by a requirement to identify a subscriber in a relay agent option,
regardless of the port to which the subscriber is attached.  The WG
agreed to take on this document as a WG work item.

DHCP Option for Geographic Location, John Schnizlein
----------------------------------------------------
This option, in draft-polk-dhcp-geo-loc-option-00.txt, passes location
information about a DHCP client from the server to the client.  The
immediate purpose is to provide location information to IP phones.
The geopriv WG will own the semantics, while the dhc WG will own the
protocol and the syntax of the option.

The DHCP Client FQDN Option, Mark Stapp
DDNS-DHCP conflict resolution, Mark Stapp
-----------------------------------------

Stapp reported on draft-ietf-dhc-fqdn-option-05.txt,
draft-ietf-dhc-ddns-resolution-05.txt,
draft-ietf-dnsext-dhcid-rr-05.txt.  There are no deployed
implementations of these drafts.  Cisco and two others have
(non-interoperable) implementation that use TXT RRs, waiting for
approval of DHCID RR.  Droms asked for a summary of changes to the
current drafts.  Stapp will post summaries to WG mailing list.
Gudmundsson asked if the DHSID RR should become a more general RR
type.  WG consensus was no, as that would delay progress of these
drafts and there is no specific requirement for other, similar RR
types.  Gudmundsson and Droms agreed documents are ready for dnsext
and dhc WG last call.

FORCE RENEW questions

dhcp solaris client error

I got myself a cable modem and a wireless router
D-Link 614+.  The route is capable to run dhcp client
to get the internet IP address and dhcp server for the
clients inside the network.  The dhcp server is
working great with my windows' client but is giving me
this error, "no valid OFFER/BOOTP reply" when I try
running dhcp client on my Solaris 8 box.  

I received the above error message when I ran the
following commands:

1. blank hostname.hme0
2. blank dhcp.hme0
3. /sbin/dhcpagent -d 1 -f 1 &
4. ifconfig hme0 dhcp start

and this is when I the error "no valid OFFER/BOOTP
reply".  

I was hoping someone can help me out with this
problem.

Thank you,
Tim

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

RE: FORCE RENEW questions