draft-ietf-dhc-isnsoption-12.txt		draft-ietf-dhc-isnsoption-13.txt
	DHC Working Group Charles Monia		DHC Working Group Charles Monia
	INTERNET DRAFT Josh Tseng		INTERNET DRAFT Josh Tseng
	Expires: January 2005 Kevin Gibbons		Expires: May 2005 Kevin Gibbons
	Internet Draft McDATA		Internet Draft McDATA
	Corporation		Corporation
	Document: <draft-ietf-dhc-isnsoption-12.txt>		Document: <draft-ietf-dhc-isnsoption-13.txt>
	Category: Standards Track July 2004		Category: Standards Track November 2004
	The IPv4 DHCP Option for the Internet Storage Name Service		The IPv4 DHCP Option for the Internet Storage Name Service
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	or will be disclosed, and any of which I become aware will be		or will be disclosed, and any of which I become aware will be
	disclosed, in accordance with RFC 3668.		disclosed, in accordance with RFC 3668.
	skipping to change at page 2, line 5		skipping to change at page 2, line 5
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Comments		Comments
	Comments should be sent to the DHCP mailing list (dhcwg@ietf.org) or		Comments should be sent to the DHCP mailing list (dhcwg@ietf.org) or
	to the authors.		to the authors.
	DHCP Option Number for iSNS Revision 12 July 2004		DHCP Option Number for iSNS Revision 13 November 2004
	Table of Contents		Table of Contents
	Status of this Memo...................................................1		Status of this Memo...................................................1
	Comments..............................................................1		Comments..............................................................1
	Abstract..............................................................3		Abstract..............................................................3
	Conventions used in this document.....................................3		Conventions used in this document.....................................3
	1. Introduction.......................................................3		1. Introduction.......................................................3
	2. iSNS Option for DHCP...............................................4		2. iSNS Option for DHCP...............................................4
	2.1 iSNS Functions Field..............................................5		2.1 iSNS Functions Field..............................................5
	skipping to change at page 3, line 5		skipping to change at page 3, line 5
	4. IANA Considerations...............................................11		4. IANA Considerations...............................................11
	5. Normative References..............................................12		5. Normative References..............................................12
	6. Non-Normative References..........................................12		6. Non-Normative References..........................................12
	7. Author's Addresses................................................13		7. Author's Addresses................................................13
	8. Intellectual Property.............................................13		8. Intellectual Property.............................................13
	9. Full Copyright Statement..........................................13		9. Full Copyright Statement..........................................13
	10. Disclaimer of Validity...........................................13		10. Disclaimer of Validity...........................................13
	11. Acknowledgement..................................................14		11. Acknowledgement..................................................14
	12. Expiration Notice................................................14		12. Expiration Notice................................................14
	DHCP Option Number for iSNS Revision 12 July 2004		DHCP Option Number for iSNS Revision 13 November 2004
	Abstract		Abstract
	This document describes the DHCP option to allow Internet Storage		This document describes the DHCP option to allow Internet Storage
	Name Service (iSNS) clients to automatically discover the location		Name Service (iSNS) clients to automatically discover the location
	of the iSNS server through the use of DHCP for IPv4. iSNS provides		of the iSNS server through the use of DHCP for IPv4. iSNS provides
	discovery and management capabilities for Internet SCSI (iSCSI) and		discovery and management capabilities for Internet SCSI (iSCSI) and
	Internet Fibre Channel Protocol (iFCP) storage devices in an		Internet Fibre Channel Protocol (iFCP) storage devices in an
	enterprise-scale IP storage network. iSNS provides intelligent		enterprise-scale IP storage network. iSNS provides intelligent
	storage management services comparable to those found in Fibre		storage management services comparable to those found in Fibre
	skipping to change at page 4, line 5		skipping to change at page 4, line 5
	fabric services to TCP/IP.		fabric services to TCP/IP.
	1. Introduction		1. Introduction
	The Dynamic Host Configuration Protocol for IPv4 provides a		The Dynamic Host Configuration Protocol for IPv4 provides a
	framework for passing configuration information to hosts. Its		framework for passing configuration information to hosts. Its
	usefulness extends to hosts and devices using the iSCSI and iFCP		usefulness extends to hosts and devices using the iSCSI and iFCP
	protocols to connect to block level storage assets over a TCP/IP		protocols to connect to block level storage assets over a TCP/IP
	network.		network.
	DHCP Option Number for iSNS Revision 12 July 2004		DHCP Option Number for iSNS Revision 13 November 2004
	The iSNS Protocol provides a framework for automated discovery,		The iSNS Protocol provides a framework for automated discovery,
	management, and configuration of iSCSI and iFCP devices on a TCP/IP		management, and configuration of iSCSI and iFCP devices on a TCP/IP
	network. It provides functionality similar to that found on Fibre		network. It provides functionality similar to that found on Fibre
	Channel networks, except that iSNS works within the context of an IP		Channel networks, except that iSNS works within the context of an IP
	network. iSNS thereby provides the requisite storage intelligence		network. iSNS thereby provides the requisite storage intelligence
	to IP networks that are standard on existing Fibre Channel networks.		to IP networks that are standard on existing Fibre Channel networks.
	Existing DHCP options cannot be used to find iSNS servers for the		Existing DHCP options cannot be used to find iSNS servers for the
	following reasons:		following reasons:
	skipping to change at page 5, line 5		skipping to change at page 5, line 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| . . . . |		| . . . . |
	| Additional Secondary iSNS Servers |		| Additional Secondary iSNS Servers |
	| . . . . |		| . . . . |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1 -- iSNS Server Option		Figure 1 -- iSNS Server Option
	The iSNS Option specifies a list of IP addresses used by iSNS		The iSNS Option specifies a list of IP addresses used by iSNS
	servers. The option contains the following parameters:		servers. The option contains the following parameters:
	DHCP Option Number for iSNS Revision 12 July 2004		DHCP Option Number for iSNS Revision 13 November 2004
	Length: the number of bytes that follow the Length field.		Length: the number of bytes that follow the Length field.
	iSNS Functions: A bitmapped field defining the functions supported		iSNS Functions: A bitmapped field defining the functions supported
	by the iSNS servers. The format of this field is described		by the iSNS servers. The format of this field is described
	in section 2.1.		in section 2.1.
	Discovery Domain Access: A bit field indicating the types of iSNS		Discovery Domain Access: A bit field indicating the types of iSNS
	clients that are allowed to modify Discovery Domains. The		clients that are allowed to modify Discovery Domains. The
	field contents are described in section 2.2.		field contents are described in section 2.2.
	skipping to change at page 6, line 5		skipping to change at page 6, line 5
	2.1 iSNS Functions Field		2.1 iSNS Functions Field
	The iSNS Functions Field defines the iSNS server's operational role		The iSNS Functions Field defines the iSNS server's operational role
	(i.e., how the iSNS server is to be used). The iSNS server's role		(i.e., how the iSNS server is to be used). The iSNS server's role
	can be as basic as providing simple discovery information, or as		can be as basic as providing simple discovery information, or as
	significant as providing IKE/IPSec security policies and		significant as providing IKE/IPSec security policies and
	certificates for the use of iSCSI and iFCP devices. The format of		certificates for the use of iSCSI and iFCP devices. The format of
	the iSNS Functions field is shown in Figure 2:		the iSNS Functions field is shown in Figure 2:
	DHCP Option Number for iSNS Revision 12 July 2004		DHCP Option Number for iSNS Revision 13 November 2004
	0 1 1		0 1 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RESERVED |S|A|E|		| RESERVED |S|A|E|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2 -- iSNS Functions Field		Figure 2 -- iSNS Functions Field
	Bit field Significance		Bit field Significance
	--------- ------------		--------- ------------
	skipping to change at page 7, line 5		skipping to change at page 7, line 5
	Security Policy Indicates whether the iSNS client is to		Security Policy Indicates whether the iSNS client is to
	Distribution: download and use the security policy		Distribution: download and use the security policy
	configuration stored in the iSNS server.		configuration stored in the iSNS server.
	If set to one, then the policy is stored in		If set to one, then the policy is stored in
	the iSNS server and must be used by the		the iSNS server and must be used by the
	iSNS client for its own security policy.		iSNS client for its own security policy.
	If set to zero, then the iSNS client must		If set to zero, then the iSNS client must
	obtain its security policy configuration by		obtain its security policy configuration by
	other means.		other means.
	DHCP Option Number for iSNS Revision 12 July 2004		DHCP Option Number for iSNS Revision 13 November 2004
	2.2 Discovery Domain Access Field		2.2 Discovery Domain Access Field
	The format of the DD Access bit field is shown in Figure 3:		The format of the DD Access bit field is shown in Figure 3:
	0 1 1 1 1 1 1		0 1 1 1 1 1 1
	0 ... 9 0 1 2 3 4 5		0 ... 9 0 1 2 3 4 5
	+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+
	| RESERVED | if| tf| is| ts| C | E |		| RESERVED | if| tf| is| ts| C | E |
	+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+
	skipping to change at page 8, line 5		skipping to change at page 8, line 5
	iFCP Target Port, (determined by iSCSI Node Type or iFCP		iFCP Target Port, (determined by iSCSI Node Type or iFCP
	iFCP Initiator Port Role) is allowed to add, delete, or		iFCP Initiator Port Role) is allowed to add, delete, or
	Port: modify Discovery Domains. If set to		Port: modify Discovery Domains. If set to
	one, then modification by the specified		one, then modification by the specified
	client type is allowed. If set to zero,		client type is allowed. If set to zero,
	then modification by the specified		then modification by the specified
	client type is not allowed.		client type is not allowed.
	(A node may implement multiple node		(A node may implement multiple node
	DHCP Option Number for iSNS Revision 12 July 2004		DHCP Option Number for iSNS Revision 13 November 2004
	types.)		types.)
	2.3 Administrative Flags Field		2.3 Administrative Flags Field
	The format of the Administrative Flags bit field is shown in		The format of the Administrative Flags bit field is shown in
	Figure 4:		Figure 4:
	0 1 1		0 1 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	skipping to change at page 9, line 5		skipping to change at page 9, line 5
	address(es) of any backup servers (see		address(es) of any backup servers (see
	Figure 1). If set to zero, then a1-a4		Figure 1). If set to zero, then a1-a4
	contains the IP address of the primary		contains the IP address of the primary
	iSNS server, followed by the IP		iSNS server, followed by the IP
	address(es) of any backup servers.		address(es) of any backup servers.
	Management SCNs: Indicates whether control nodes are		Management SCNs: Indicates whether control nodes are
	authorized to register to receive		authorized to register to receive
	Management State Change Notifications		Management State Change Notifications
	DHCP Option Number for iSNS Revision 12 July 2004		DHCP Option Number for iSNS Revision 13 November 2004
	(SCN's). Management SCN's are a special		(SCN's). Management SCN's are a special
	class of State Change Notification whose		class of State Change Notification whose
	scope is the entire iSNS database. If		scope is the entire iSNS database. If
	set to one, then control nodes are		set to one, then control nodes are
	authorized to register to receive		authorized to register to receive
	Management SCN's. If set to zero, then		Management SCN's. If set to zero, then
	control nodes are not authorized to		control nodes are not authorized to
	receive Management SCN's (although they		receive Management SCN's (although they
	may receive normal SCN's).		may receive normal SCN's).
	skipping to change at page 10, line 5		skipping to change at page 10, line 5
	31 Enabled		31 Enabled
	30 IKE/IPSec		30 IKE/IPSec
	29 Main Mode		29 Main Mode
	28 Aggressive Mode		28 Aggressive Mode
	27 PFS		27 PFS
	26 Transport Mode		26 Transport Mode
	25 Tunnel Mode		25 Tunnel Mode
	iSNS Server Security Bitmap definitions:		iSNS Server Security Bitmap definitions:
	DHCP Option Number for iSNS Revision 12 July 2004		DHCP Option Number for iSNS Revision 13 November 2004
	Enabled This bit specifies the validity of the		Enabled This bit specifies the validity of the
	remainder of the iSNS server security		remainder of the iSNS server security
	bitmap. If set to one, then the contents		bitmap. If set to one, then the contents
	of the remainder of the field are valid.		of the remainder of the field are valid.
	If set to zero, then the contents of the		If set to zero, then the contents of the
	rest of the field are undefined and MUST		rest of the field are undefined and MUST
	be ignored.		be ignored.
	IKE/IPSec 1 = IKE/IPSec enabled; 0 = IKE/IPSec		IKE/IPSec 1 = IKE/IPSec enabled; 0 = IKE/IPSec
	skipping to change at page 10, line 38		skipping to change at page 10, line 38
	Tunnel Mode 1 = Tunnel mode preferred; 0 = No		Tunnel Mode 1 = Tunnel mode preferred; 0 = No
	preference.		preference.
	If IKE/IPSec is disabled, this indicates that the Internet Key		If IKE/IPSec is disabled, this indicates that the Internet Key
	Exchange (IKE) Protocol is not available to configure IPSec keys for		Exchange (IKE) Protocol is not available to configure IPSec keys for
	iSNS sessions to this iSNS server. It does not necessarily preclude		iSNS sessions to this iSNS server. It does not necessarily preclude
	other key exchange methods (e.g., manual keying) from establishing		other key exchange methods (e.g., manual keying) from establishing
	an IPSec security association for the iSNS session.		an IPSec security association for the iSNS session.
	If IKE/IPsec is enabled, an implementation SHALL enable:		If IKE/IPsec is enabled, then for each of the bit pairs
			<Main Mode, Aggressive Mode> and <Transport Mode, Tunnel Mode>,
	a) One of Main Mode or Aggressive Mode but not both and		one of the two bits MUST be set to 1 and the other bit
			MUST be set to 0.
	b) One of Transport Mode or Tunnel Mode but not both.
	3. Security Considerations		3. Security Considerations
	The DHCP Authentication security option as specified in [RFC3118]		The DHCP Authentication security option as specified in [RFC3118]
	to protect the iSNS option may present a problem due to the limited		to protect the iSNS option may present a problem due to the limited
	implementation and deployment of the DHCP authentication option.		implementation and deployment of the DHCP authentication option.
	The IPSec security mechanisms for iSNS itself are specified in		The IPsec security mechanisms for iSNS itself are specified in
	[iSNS] to provide confidentiality when sensitive information is		[iSNS] to provide confidentiality when sensitive information is
	distributed via iSNS. See the Security Considerations section of		distributed via iSNS. See the Security Considerations section of
	[iSNS] for details and specific requirements for implementation of		[iSNS] for details and specific requirements for implementation of
	IPSec.		IPsec.
	In addition,[iSNS] describes an authentication block that provides		In addition,[iSNS] describes an authentication block that provides
	message integrity for multicast or broadcast iSNS messages (i.e. for		message integrity for multicast or broadcast iSNS messages (i.e. for
	DHCP Option Number for iSNS Revision 12 July 2004		DHCP Option Number for iSNS Revision 13 November 2004
	heartbeat/discovery messages only). See [RFC 3723] for further		heartbeat/discovery messages only). See [RFC 3723] for further
	discussion of security for these protocols.		discussion of security for these protocols.
	If no sensitive information, as described in [iSNS], is being		If no sensitive information, as described in [iSNS], is being
	distributed via iSNS, and an Entity is discovered via iSNS,		distributed via iSNS, and an Entity is discovered via iSNS,
	authentication and authorization are handled by the IP Storage		authentication and authorization are handled by the IP Storage
	protocols whose endpoints are discovered via iSNS, specifically iFCP		protocols whose endpoints are discovered via iSNS, specifically iFCP
	[iFCP] and iSCSI [RFC 3720]. It is the responsibility of the		[iFCP] and iSCSI [RFC 3720]. It is the responsibility of the
	providers of these services to ensure that an inappropriately		providers of these services to ensure that an inappropriately
	advertised or discovered service does not compromise their security.		advertised or discovered service does not compromise their security.
	When no security is used, there is a risk of distribution of false		When no DHCP security is used, there is a risk of distribution of
	discovery information (e.g., via the iSNS DHCP option identifying a		false discovery information (e.g., via the iSNS DHCP option
	false iSNS server that distributes the false discovery information).		identifying a false iSNS server that distributes the false
	The primary countermeasure for this risk is authentication. When		discovery information). The primary countermeasure for this risk
	this risk is a significant concern, IPsec SAs SHOULD be used for IP		is authentication by the IP storage protocols discovered through
	Storage protocol (iSCSI and iFCP) traffic subject to this risk to		iSNS. When this risk is a significant concern, IPsec SAs SHOULD be
	ensure that such traffic only flows between endpoints that have		used (as specified in RFC 3723). For example, if an attacker uses
	participated in IKE authentication. For example, if an attacker		DHCP and iSNS to distribute discovery information that falsely
	distributes discovery information falsely identifying an iSCSI		identifies an iSCSI endpoint, that endpoint will lack the
	endpoint, that endpoint will lack the secret information necessary		credentials necessary to successfully complete IKE authentication,
	to successfully complete IKE authentication, and hence will be		and hence will be prevented from falsely sending or receiving iSCSI
	prevented from falsely sending or receiving iSCSI traffic. When this		traffic. When this risk of false discovery information is a
	risk of false discovery information is a significant concern and		significant concern and IPsec is implemented for iSNS, IPsec SAs
	IPSec is implemented for iSNS, IPSec SAs SHOULD also be used for		SHOULD also be used for iSNS traffic to prevent use of a false iSNS
	iSNS traffic to prevent use of a false iSNS server rather than		server; this is more robust than relying only on the IP Storage
	relying only on the IP Storage protocols to detect false discovery		protocols to detect false discovery information.
	information.
	There remains a risk of a denial of service attack based on repeated		When IPsec is implemented for iSNS, there is a risk of a denial of
	use of false discovery information that will cause initiation of IKE		service attack based on repeated use of false discovery information
	negotiation. The countermeasures for this are administrative		that will cause initiation of IKE negotiation. The countermeasures
	configuration of each iSNS and IP Storage (iSCSI and FCIP) Entity to		for this are administrative configuration of each iSNS Entity to
	limit the peers that it is willing to communicate with (i.e., by IP		limit the peers that it is willing to communicate with (i.e., by IP
	address range and/or DNS domain), and maintenance of a negative		address range and/or DNS domain), and maintenance of a negative
	authentication cache to avoid repeatedly contacting an iSNS Entity		authentication cache to avoid repeatedly contacting an iSNS Entity
	that fails to authenticate. These three measures (i.e., IP address		that fails to authenticate. These three measures (i.e., IP address
	range limits, DNS domain limits, negative authentication cache) MUST		range limits, DNS domain limits, negative authentication cache)
	be implemented for IP Storage (iSCSI and iFCP) protocols and iSNS		MUST be implemented for iSNS entities when this DHCP option is
	Entities. For iSNS, these requirements apply only when this DHCP		used. An analogous argument applies to the IP storage protocols
	option is used, and in addition, the negative authentication cache		that can be discovered via iSNS as discussed in RFC 3723.
	requirement applies only when IPSec support is implemented for iSNS,
	as a negative authentication cache is of no value in the absence of		In addition, use of the techniques described in [RFC2827] and
	authentication.		[RFC3833] may also be relevant to reduce denial of service attacks.
	4. IANA Considerations		4. IANA Considerations
	In accordance with the policy defined in [DHCP], IANA has assigned a		In accordance with the policy defined in [DHCP], IANA has assigned a
	value of TBD for this option.		value of TBD for this option.
	DHCP Option Number for iSNS Revision 12 July 2004		DHCP Option Number for iSNS Revision 13 November 2004
	There are no other IANA-assigned values defined by this		There are no other IANA-assigned values defined by this
	specification.		specification.
	5. Normative References		5. Normative References
	[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC		[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC
	2131, Bucknell University, March 1997.		2131, Bucknell University, March 1997.
	[iSNS] Tseng, J. et al., "iSNS - Internet Storage Name		[iSNS] Tseng, J. et al., "iSNS - Internet Storage Name
	skipping to change at page 13, line 5		skipping to change at page 12, line 46
	[RFC3723] Aboba, B., et al., "Securing Block Storage Protocols		[RFC3723] Aboba, B., et al., "Securing Block Storage Protocols
	over IP", RFC 3723, April 2004		over IP", RFC 3723, April 2004
	6. Non-Normative References		6. Non-Normative References
	[iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre		[iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre
	Channel Storage Networking", Internet draft (work in		Channel Storage Networking", Internet draft (work in
	progress), draft-ietf-ips-ifcp-13.txt, May 2002		progress), draft-ietf-ips-ifcp-13.txt, May 2002
			[RFC2827] Ferguson, P., et al., "Network Ingress Filtering:
			Defeating Denial of Service Attacks which employ IP
			Source Address Spoofing", BCP 38, RFC 2827, May 2000
			[RFC3833] Atkins, D., et al., "Threat Analysis of the Domain
			Name System (DNS)", RFC 3833, August 2004
	7. Author's Addresses		7. Author's Addresses
	Kevin Gibbons,		Kevin Gibbons,
	Charles Monia,		Charles Monia,
	Josh Tseng		Josh Tseng
	McDATA Corporation		McDATA Corporation
	3850 North First Street		3850 North First Street
	San Jose, CA 95134-1702		San Jose, CA 95134-1702
	Phone: (408) 519-3700		Phone: (408) 519-3700
	skipping to change at page 13, line 44		skipping to change at page 13, line 44
	from the IETF on-line IPR repository at http://www.ietf.org/ipr.		from the IETF on-line IPR repository at http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary rights		copyrights, patents or patent applications, or other proprietary rights
	that may cover technology that may be required to implement this		that may cover technology that may be required to implement this
	standard. Please address the information to the IETF at ietf-		standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	9. Full Copyright Statement		9. Full Copyright Statement
	Copyright (C) The Internet Society July 2004. This document is subject to		Copyright (C) The Inter
			net Society July 2004. This document is subject to
	the rights, licenses and restrictions contained in BCP 78, and except as		the rights, licenses and restrictions contained in BCP 78, and except as
	set forth therein, the authors retain all their rights.		set forth therein, the authors retain all their rights.
	10. Disclaimer of Validity		10. Disclaimer of Validity
	This document and the information contained herein are provided on an "AS		This document and the information contained herein are provided on an "AS
	IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS		IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS
	SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
	NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL		NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
	DHCP Option Number for iSNS Revision 12 July 2004		DHCP Option Number for iSNS Revision 13 November 2004
	NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR		NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
	FITNESS FOR A PARTICULAR PURPOSE.		FITNESS FOR A PARTICULAR PURPOSE.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other groups		Force (IETF), its areas, and its working groups. Note that other groups
	may also distribute working documents as Internet-Drafts.		may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months and		Internet-Drafts are draft documents valid for a maximum of six months and
	may be upated, replaced, or obsoleted by other documents at any time. It		may be upated, replaced, or obsoleted by other documents at any time. It
	skipping to change at page 14, line 32		skipping to change at page 14, line 32
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	11. Acknowledgement		11. Acknowledgement
	Funding for the RFC Editor function is currently provided by the Internet		Funding for the RFC Editor function is currently provided by the Internet
	Society.		Society.
	12. Expiration Notice		12. Expiration Notice
	This Internet-Draft expires in January 2005.		This Internet-Draft expires in May 2005.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/