draft-ietf-dhc-isnsoption-13.txt   rfc4174.txt 
DHC Working Group Charles Monia
INTERNET DRAFT Josh Tseng
Expires: May 2005 Kevin Gibbons
Internet Draft McDATA
Corporation
Document: <draft-ietf-dhc-isnsoption-13.txt>
Category: Standards Track November 2004
The IPv4 DHCP Option for the Internet Storage Name Service
Status of this Memo Network Working Group C. Monia
Request for Comments: 4174 Consultant
Category: Standards Track J. Tseng
Riverbed Technology
K. Gibbons
McDATA Corporation
September 2005
By submitting this Internet-Draft, I certify that any applicable The IPv4 Dynamic Host Configuration Protocol (DHCP) Option
patent or other IPR claims of which I am aware have been disclosed, for the Internet Storage Name Service
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
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 made obsolete 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 This document specifies an Internet standards track protocol for the
http://www.ietf.org/ietf/1id-abstracts.txt Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html.
Comments Copyright (C) The Internet Society (2005).
Comments should be sent to the DHCP mailing list (dhcwg@ietf.org) or Abstract
to the authors.
DHCP Option Number for iSNS Revision 13 November 2004 This document describes the Dynamic Host Configuration Protocol
(DHCP) option to allow Internet Storage Name Service (iSNS) clients
to discover the location of the iSNS server automatically through the
use of DHCP for IPv4. iSNS provides discovery and management
capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel
Protocol (iFCP) storage devices in an enterprise-scale IP storage
network. iSNS provides intelligent storage management services
comparable to those found in Fibre Channel networks, allowing a
commodity IP network to function in a similar capacity to that of a
storage area network.
Table of Contents Table of Contents
Status of this Memo...................................................1 1. Introduction ................................................. 2
Comments..............................................................1 1.1. Conventions Used in This Document ...................... 2
Abstract..............................................................3 2. iSNS Option for DHCP ......................................... 3
Conventions used in this document.....................................3 2.1. iSNS Functions Field ................................... 5
1. Introduction.......................................................3 2.2. Discovery Domain Access Field .......................... 6
2. iSNS Option for DHCP...............................................4 2.3. Administrative Flags Field ............................. 7
2.1 iSNS Functions Field..............................................5 2.4. iSNS Server Security Bitmap ............................ 8
2.2 Discovery Domain Access Field.....................................7 3. Security Considerations ...................................... 9
2.3 Administrative Flags Field........................................8 4. IANA Considerations .......................................... 11
2.4 iSNS Server Security Bitmap.......................................9 5. Normative References ......................................... 11
3. Security Considerations...........................................10 6. Informative References ....................................... 11
4. IANA Considerations...............................................11
5. Normative References..............................................12
6. Non-Normative References..........................................12
7. Author's Addresses................................................13
8. Intellectual Property.............................................13
9. Full Copyright Statement..........................................13
10. Disclaimer of Validity...........................................13
11. Acknowledgement..................................................14
12. Expiration Notice................................................14
DHCP Option Number for iSNS Revision 13 November 2004 1. Introduction
Abstract The Dynamic Host Configuration Protocol for IPv4 provides a framework
for passing configuration information to hosts. Its usefulness
extends to hosts and devices using the iSCSI and iFCP protocols to
connect to block level storage assets over a TCP/IP network.
This document describes the DHCP option to allow Internet Storage The iSNS Protocol provides a framework for automated discovery,
Name Service (iSNS) clients to automatically discover the location management, and configuration of iSCSI and iFCP devices on a TCP/IP
of the iSNS server through the use of DHCP for IPv4. iSNS provides network. It provides functionality similar to that found on Fibre
discovery and management capabilities for Internet SCSI (iSCSI) and Channel networks, except that iSNS works within the context of an IP
Internet Fibre Channel Protocol (iFCP) storage devices in an network. iSNS thereby provides the requisite storage intelligence to
enterprise-scale IP storage network. iSNS provides intelligent IP networks that are standard on existing Fibre Channel networks.
storage management services comparable to those found in Fibre
Channel networks, allowing a commodity IP network to function in a
similar capacity as a storage area network.
Conventions used in this document Existing DHCP options cannot be used to find iSNS servers for the
following reasons:
iSNS refers to the Internet Storage Name Service framework a) iSNS functionality is distinctly different from other protocols
consisting of the storage network model and associated services. using DHCP options. Specifically, iSNS provides a significant
superset of capabilities compared to typical name resolution
protocols such as DNS. It is designed to support client devices
that allow themselves to be configured and managed from a central
iSNS server.
b) iSNS requires a DHCP option format that provides more than the
location of the iSNS server. The DHCP option has to specify the
subset of iSNS services that may be actively used by the iSNS
client.
The DHCP option number for iSNS is used by iSCSI and iFCP devices to
discover the location and role of the iSNS server. The DHCP option
number assigned for iSNS by IANA is 83.
1.1. Conventions Used in This Document
iSNS refers to the Internet Storage Name Service framework, which
consists of the storage network model and associated services.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
All frame formats are in big endian network byte order. RESERVED All frame formats are in big-endian network byte order. RESERVED
fields SHOULD be set to zero. fields SHOULD be set to zero.
This document uses the following terms: This document uses the following terms:
"iSNS Client" - iSNS clients are processes resident in iSCSI and "iSNS Client" - iSNS clients are processes resident in iSCSI and
iFCP devices that initiate transactions with the iSNS server using iFCP devices that initiate transactions with the iSNS server using
the iSNS Protocol. the iSNS Protocol.
"iSNS Server" - The iSNS server responds to iSNS protocol query and "iSNS Server" - The iSNS server responds to iSNS protocol query
registration messages, and initiates asynchronous notification and registration messages and initiates asynchronous notification
messages. The iSNS server stores information registered by iSNS messages. The iSNS server stores information registered by iSNS
clients. clients.
"iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a "iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a
new generation of storage devices interconnected with TCP/IP. new generation of storage devices interconnected with TCP/IP.
"iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to- "iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to-
gateway protocol designed to interconnect existing Fibre Channel gateway protocol designed to interconnect existing Fibre Channel
devices using TCP/IP. iFCP maps the Fibre Channel transport and devices using TCP/IP. iFCP maps the Fibre Channel transport and
fabric services to TCP/IP. fabric services to TCP/IP.
1. Introduction
The Dynamic Host Configuration Protocol for IPv4 provides a
framework for passing configuration information to hosts. Its
usefulness extends to hosts and devices using the iSCSI and iFCP
protocols to connect to block level storage assets over a TCP/IP
network.
DHCP Option Number for iSNS Revision 13 November 2004
The iSNS Protocol provides a framework for automated discovery,
management, and configuration of iSCSI and iFCP devices on a TCP/IP
network. It provides functionality similar to that found on Fibre
Channel networks, except that iSNS works within the context of an IP
network. iSNS thereby provides the requisite storage intelligence
to IP networks that are standard on existing Fibre Channel networks.
Existing DHCP options cannot be used to find iSNS servers for the
following reasons:
a) iSNS functionality is distinctly different from other protocols
using DHCP options. Specifically, iSNS provides a significant
superset of capabilities compared to typical name resolution
protocols such as DNS. It is designed to support client devices
that allow themselves to be configured and managed from a
central iSNS server
b) iSNS requires a DHCP option format that provides more than the
location of the iSNS server. The DHCP option needs to specify
the subset of iSNS services that may be actively used by the
iSNS client.
The DHCP option number for iSNS is used by iSCSI and iFCP devices to
discover the location and role of the iSNS server. The DHCP option
number assigned for iSNS by IANA is <<TBD>>.
2. iSNS Option for DHCP 2. iSNS Option for DHCP
This option specifies the location of the primary and backup iSNS This option specifies the location of the primary and backup iSNS
servers and the iSNS services available to an iSNS client. servers and the iSNS services available to an iSNS client.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code = TBD | Length | iSNS Functions | | Code = 83 | Length | iSNS Functions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD Access | Administrative FLAGS | | DD Access | Administrative FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| iSNS Server Security Bitmap | | iSNS Server Security Bitmap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| a1 | a2 | a3 | a4 | | a1 | a2 | a3 | a4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| b1 | b2 | b3 | b4 | | b1 | b2 | b3 | b4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . . | | . . . . |
| 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 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.
Administrative Flags field: Contains the administrative settings for Administrative Flags field: Contains the administrative settings
the iSNS servers discovered through the DHCP query. The for the iSNS servers discovered through the DHCP query. The
contents of this field are described in section 2.3. contents of this field are described in section 2.3.
iSNS Server Security Bitmap: Contains the iSNS server security iSNS Server Security Bitmap: Contains the iSNS server security
settings specified in section 2.4. settings specified in section 2.4.
a1...a4: Depending on the setting of the Heartbeat bit in the a1...a4: Depending on the setting of the Heartbeat bit in the
Administrative Flags field (see section 2.3), this field Administrative Flags field (see section 2.3), this field
contains either the IP address from which the iSNS heartbeat contains either the IP address from which the iSNS heartbeat
originates (see [ISNS]) or the IP address of the primary originates (see [iSNS]) or the IP address of the primary
iSNS server. iSNS server.
b1...b4: Depending on the setting of Heartbeat bit in the b1...b4: Depending on the setting of Heartbeat bit in the
Administrative Flags field (see section 2.3), this field Administrative Flags field (see section 2.3), this field
contains either the IP address of the primary iSNS server or contains either the IP address of the primary iSNS server or
a secondary iSNS server. that of a secondary iSNS server.
Additional Secondary iSNS Servers: Each set of four octets specifies Additional Secondary iSNS Servers: Each set of four octets
the IP address of a secondary iSNS server. specifies the IP address of a secondary iSNS server.
The Code field through IP address field a1...a4 MUST be present in The Code field through IP address field a1...a4 MUST be present in
every response to the iSNS query, hence the Length field has a every response to the iSNS query; therefore the Length field has a
minimum value of 14. minimum value of 14.
If the Heartbeat bit is set in the Administrative Flags field (see If the Heartbeat bit is set in the Administrative Flags field (see
section 2.3), then b1...b4 MUST also be present. In this case, the section 2.3), then b1...b4 MUST also be present. In this case, the
minimum value of the Length field is 18. minimum value of the Length field is 18.
The inclusion of Additional Secondary iSNS Servers in the response The inclusion of Additional Secondary iSNS Servers in the response
MUST be indicated by increasing the Length field accordingly. MUST be indicated by increasing the Length field accordingly.
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
certificates for the use of iSCSI and iFCP devices. The format of for the use of iSCSI and iFCP devices. The format of the iSNS
the iSNS Functions field is shown in Figure 2: Functions field is shown in Figure 2.
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
Bit field Significance Figure 2. iSNS Functions Field
Bit Field Significance
--------- ------------ --------- ------------
15 Function Fields Enabled 15 Function Fields Enabled
14 DD-Based Authorization 14 DD-Based Authorization
13 Security Policy Distribution 13 Security Policy Distribution
iSNS Functions Field definitions: The following are iSNS Functions Field definitions:
Function Fields This bit specifies the validity of the Function Fields Specifies the validity of the remaining
Enabled: remaining iSNS Function fields. If set to Enabled: iSNS Function fields. If it is set to one, then
one, then the contents of all other iSNS the contents of all other iSNS Function fields
Function fields are valid. If set to zero, are valid. If it is set to zero, then the
then the contents of all other iSNS contents of all other iSNS Function fields MUST
Function fields MUST be ignored. be ignored.
DD-based Indicates whether or not devices in a DD-based Indicates whether devices in a common
Authorization: common Discovery Domain (DD) are implicitly Authorization: Discovery Domain (DD) are implicitly authorized
authorized to access one another. Although to access one another. Although Discovery
Discovery Domains control the scope of Domains control the scope of device discovery,
device discovery, they do not necessarily they do not necessarily indicate whether a domain
indicate whether or not a domain member is member is authorized to access discovered
authorized to access discovered devices. devices. If this bit is set to one, then devices
If this bit is set to one, then devices in in a common Discovery Domain are automatically
a common Discovery Domain are automatically allowed access to each other (if successfully
allowed access to each other (if authenticated). If this bit is set to zero, then
successfully authenticated). If this bit access authorization is not implied by domain
is set to zero, then access authorization membership and must be explicitly performed by
is not implied by domain membership and each device. In either case, devices not in a
must be explicitly performed by each common discovery domain are not allowed to access
device. In either case, devices not in a each other.
common discovery domain are not allowed to
access each other.
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 it
If set to one, then the policy is stored in is set to one, then the policy is stored in the
the iSNS server and must be used by the iSNS server and must be used by the iSNS client
iSNS client for its own security policy. for its own security policy. If it is set to
If set to zero, then the iSNS client must zero, then the iSNS client must obtain its
obtain its security policy configuration by security policy configuration by other means.
other means.
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 |
+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+
Figure 3 -- Discovery Domain Access Field
Bit field Significance Figure 3. Discovery Domain Access Field
Bit Field Significance
--------- ------------ --------- ------------
15 Enabled 15 Enabled
14 Control Node 14 Control Node
13 iSCSI Target 13 iSCSI Target
12 iSCSI Initiator 12 iSCSI Initiator
11 iFCP Target Port 11 iFCP Target Port
10 iFCP Initiator Port 10 iFCP Initiator Port
Discovery Domain Access Field Definitions: The following are Discovery Domain Access Field definitions:
Enabled: This bit specifies the validity of the
remaining DD Access bit fields. If this Enabled: Specifies the validity of the remaining DD
bit is set to one, then the contents of Access bit field. If it is set to one, then
the remainder of the DD Access field are the contents of the remainder of the DD Access
valid. If this bit is set to zero, then field are valid. If it is set to zero, then
the contents of the remainder of this the contents of the remainder of this field
field MUST be ignored. MUST be ignored.
Control Node: Specifies whether the iSNS server allows Control Node: Specifies whether the iSNS server allows
Discovery Domains to be added, modified Discovery Domains to be added, modified, or
or deleted by means of Control Nodes. If deleted by means of Control Nodes. If it is
set to one, then Control Nodes are set to one, then Control Nodes are allowed to
allowed to modify the Discovery Domain modify the Discovery Domain configuration. If
configuration. If set to zero, then it is set to zero, then Control Nodes are not
Control Nodes are not allowed to modify allowed to modify Discovery Domain
Discovery Domain configurations. configurations.
iSCSI Target, These bits determine whether the
iSCSI Initiator, respective registered iSNS client
iFCP Target Port, (determined by iSCSI Node Type or iFCP
iFCP Initiator Port Role) is allowed to add, delete, or
Port: modify Discovery Domains. If set to
one, then modification by the specified
client type is allowed. If set to zero,
then modification by the specified
client type is not allowed.
(A node may implement multiple node
DHCP Option Number for iSNS Revision 13 November 2004 iSCSI Target, Determine whether the respective
iSCSI Initiator, registered iSNS client (determined
iFCP Target Port, by iSCSI Node Type or iFCP Port Role)
iFCP Initiator is allowed to add, delete, or modify
Port: Discovery Domains. If they are set to one,
then modification by the specified client type
is allowed. If they are set to zero, then
modification by the specified client type is
not allowed.
types.) (A node may implement multiple node 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
Figure 4: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |D|M|H|E| | RESERVED |D|M|H|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 -- Administrative Flags
Figure 4. Administrative Flags
Bit Field Significance Bit Field Significance
--------- ------------ --------- ------------
15 Enabled 15 Enabled
14 Heartbeat 14 Heartbeat
13 Management SCNs 13 Management SCNs
12 Default Discovery Domain 12 Default Discovery Domain
Administrative Flags Field definitions: The following are Administrative Flags Field definitions:
Enabled: Specifies the validity of the remainder
of the Administrative Flags field. If
set to one, then the contents of the
remaining Administrative Flags are
valid. If set to zero, then the
remaining contents MUST be ignored,
indicating that iSNS administrative
settings are obtained through means
other than DHCP.
Heartbeat: Indicates whether the first IP address
is the multicast address to which the
iSNS heartbeat message is sent. If set
to one, then a1-a4 contains the
heartbeat multicast address and b1-b4
contains the IP address of the primary
iSNS server, followed by the IP
address(es) of any backup servers (see
Figure 1). If set to zero, then a1-a4
contains the IP address of the primary
iSNS server, followed by the IP
address(es) of any backup servers.
Management SCNs: Indicates whether control nodes are Enabled: Specifies the validity of the remainder of the
authorized to register to receive Administrative Flags field. If it is set to
Management State Change Notifications one, then the contents of the remaining
Administrative Flags are valid. If it is set
to zero, then the remaining contents MUST be
ignored, indicating that iSNS administrative
settings are obtained through means other than
DHCP.
DHCP Option Number for iSNS Revision 13 November 2004 Heartbeat: Indicates whether the first IP address is the
multicast address to which the iSNS heartbeat
message is sent. If it is set to one, then
a1-a4 contains the heartbeat multicast address
and b1-b4 contains the IP address of the
primary iSNS server, followed by the IP
address(es) of any backup servers (see Figure
1). If it is set to zero, then a1-a4 contain
the IP address of the primary iSNS server,
followed by the IP address(es) of any backup
servers.
(SCN's). Management SCN's are a special Management SCNs: Indicates whether control nodes are authorized
class of State Change Notification whose to register for receiving Management State
scope is the entire iSNS database. If Change Notifications (SCNs). Management SCNs
set to one, then control nodes are are a special class of State Change
authorized to register to receive Notification whose scope is the entire iSNS
Management SCN's. If set to zero, then database. If this bit is set to one, then
control nodes are not authorized to control nodes are authorized to register for
receive Management SCN's (although they receiving Management SCNs. If it is set to
may receive normal SCN's). zero, then control nodes are not authorized to
receive Management SCNs (although they may
receive normal SCNs).
Default Discovery Indicates whether a newly registered Default Discovery Indicates whether a newly registered
Domain: device that is not explicitly placed Domain: device that is not explicitly placed into a
into a Discovery Domain (DD) and Discovery Domain (DD) and Discovery Domain Set
Discovery Domain Set (DDS) should be (DDS) should be automatically placed into a
automatically placed into a default DD default DD and DDS. If it is set to one, then
and DDS. If set to one, then a default a default DD shall contain all devices in the
DD shall contain all devices in the iSNS iSNS database that have not been explicitly
database that have not been explicitly placed into a DD by an iSNS client. If it is
placed into a DD by an iSNS client. If set to zero, then devices not explicitly placed
set to zero, then devices not explicitly into a DD are not members of any DD.
placed into a DD are not members of any
DD.
2.4 iSNS Server Security Bitmap 2.4. iSNS Server Security Bitmap
The format of the iSNS server security Bitmap field is shown in The format of the iSNS server security Bitmap field is shown in
Figure 5. If valid, this field communicates to the DHCP client the Figure 5. If valid, this field communicates to the DHCP client the
security settings that are required to communicate with the security settings that are required to communicate with the indicated
indicated iSNS server. iSNS server.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED |T|X|P|A|M|S|E| | RESERVED |T|X|P|A|M|S|E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 -- iSNS Server Security Bitmap
Figure 5. iSNS Server Security Bitmap
Bit Field Significance Bit Field Significance
--------- ---------------- --------- ----------------
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: The following are iSNS Server Security Bitmap definitions:
DHCP Option Number for iSNS Revision 13 November 2004
Enabled This bit specifies the validity of the Enabled: Specifies the validity of the remainder of the
remainder of the iSNS server security iSNS server security bitmap. If it is set to
bitmap. If set to one, then the contents one, then the contents of the remainder of the
of the remainder of the field are valid. field are valid. If it is set to zero, then
If set to zero, then the contents of the the contents of the rest of the field are
rest of the field are undefined and MUST 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 disabled.
disabled.
Main Mode 1 = Main Mode enabled; 0 = Main Mode Main Mode: 1 = Main Mode enabled; 0 = Main Mode disabled.
disabled.
Aggressive Mode 1 = Aggressive mode enabled; 0 = Aggressive Mode: 1 = Aggressive Mode enabled;
Aggressive mode disabled. 0 = Aggressive Mode disabled.
PFS 1 = PFS enabled; 0 = PFS disabled. PFS: 1 = PFS enabled; 0 = PFS disabled.
Transport Mode 1 = Transport mode preferred; 0 = No Transport Mode: 1 = Transport Mode preferred; 0 = No
preference. preference.
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
an IPSec security association for the iSNS session. IPSec security association for the iSNS session.
If IKE/IPsec is enabled, then for each of the bit pairs If IKE/IPsec is enabled, then for each of the bit pairs <Main Mode,
<Main Mode, Aggressive Mode> and <Transport Mode, Tunnel Mode>, Aggressive Mode> and <Transport Mode, Tunnel Mode>, one of the two
one of the two bits MUST be set to 1 and the other bit bits MUST be set to 1, and the other MUST be set to 0.
MUST be set to 0.
3. Security Considerations 3. Security Considerations
The DHCP Authentication security option as specified in [RFC3118] For protecting the iSNS option, the DHCP Authentication security
to protect the iSNS option may present a problem due to the limited option as specified in [RFC3118] may present a problem due to the
implementation and deployment of the DHCP authentication option. limited implementation and deployment of the DHCP authentication
The IPsec security mechanisms for iSNS itself are specified in option. The IPsec security mechanisms for iSNS itself are specified
[iSNS] to provide confidentiality when sensitive information is in [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 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 DHCP security is used, there is a risk of distribution of When no DHCP security is used, there is a risk of distribution of
false discovery information (e.g., via the iSNS DHCP option false discovery information (e.g., via the iSNS DHCP option
identifying a false iSNS server that distributes the false identifying a false iSNS server that distributes the false discovery
discovery information). The primary countermeasure for this risk information). The primary countermeasure for this risk is
is authentication by the IP storage protocols discovered through authentication by the IP storage protocols discovered through iSNS.
iSNS. When this risk is a significant concern, IPsec SAs SHOULD be When this risk is a significant concern, IPsec SAs SHOULD be used (as
used (as specified in RFC 3723). For example, if an attacker uses specified in RFC 3723). For example, if an attacker uses DHCP and
DHCP and iSNS to distribute discovery information that falsely iSNS to distribute discovery information that falsely identifies an
identifies an iSCSI endpoint, that endpoint will lack the iSCSI endpoint, that endpoint will lack the credentials necessary to
credentials necessary to successfully complete IKE authentication, complete IKE authentication successfully, and therefore 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 iSNS
SHOULD also be used for iSNS traffic to prevent use of a false iSNS traffic to prevent use of a false iSNS server; this is more robust
server; this is more robust than relying only on the IP Storage than relying only on the IP Storage protocols to detect false
protocols to detect false discovery information. discovery information.
When IPsec is implemented for iSNS, there is a risk of a denial of When IPsec is implemented for iSNS, there is a risk of a denial-of-
service attack based on repeated use of false discovery information service attack based on repeated use of false discovery information
that will cause initiation of IKE negotiation. The countermeasures that will cause initiation of IKE negotiation. The countermeasures
for this are administrative configuration of each iSNS 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 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) range limits, DNS domain limits, negative authentication cache) MUST
MUST be implemented for iSNS entities when this DHCP option is be implemented for iSNS entities when this DHCP option is used. An
used. An analogous argument applies to the IP storage protocols analogous argument applies to the IP storage protocols that can be
that can be discovered via iSNS as discussed in RFC 3723. discovered via iSNS as discussed in RFC 3723.
In addition, use of the techniques described in [RFC2827] and In addition, use of the techniques described in [RFC2827] and
[RFC3833] may also be relevant to reduce denial of service attacks. [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 83 for this option.
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,
2131, Bucknell University, March 1997. March 1997.
[iSNS] Tseng, J. et al., "iSNS - Internet Storage Name
Service", Internet draft (work in progress), draft-ietf-
ips-isns-12.txt, August 2002
[RFC2026] Bradner, S., "The Internet Standards Process -- [iSNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and
Revision 3", BCP 9, RFC 2026, October 1996 J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171,
September 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997 Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3118] Arbaugh, W., Droms, R., "Authentication for DHCP
Messages", RFC 3118, June 2001
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004
[RFC3720] Satran, J., et al., "Internet Small Computer Systems [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Interface (iSCSI)", RFC 3720, April 2004 Messages", RFC 3118, June 2001.
[RFC3723] Aboba, B., et al., "Securing Block Storage Protocols [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and
over IP", RFC 3723, April 2004 E. Zeidner, "Internet Small Computer Systems Interface
(iSCSI)", RFC 3720, April 2004.
6. Non-Normative References [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols over IP", RFC
3723, April 2004.
[iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre 6. Informative References
Channel Storage Networking", Internet draft (work in
progress), draft-ietf-ips-ifcp-13.txt, May 2002
[RFC2827] Ferguson, P., et al., "Network Ingress Filtering: [iFCP] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and
Defeating Denial of Service Attacks which employ IP M. Edwards, "iFCP - A Protocol for Internet Fibre Channel
Source Address Spoofing", BCP 38, RFC 2827, May 2000 Storage Networking", RFC 4172, September 2005.
[RFC3833] Atkins, D., et al., "Threat Analysis of the Domain [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Name System (DNS)", RFC 3833, August 2004 Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
7. Author's Addresses [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004.
Kevin Gibbons, Authors' Addresses
Charles Monia,
Josh Tseng
Kevin Gibbons
McDATA Corporation McDATA Corporation
3850 North First Street 4555 Great America Parkway
San Jose, CA 95134-1702 Santa Clara, CA 95054-1208
Phone: (408) 519-3700
Email: charles.monia@mcdata.com
joshtseng@yahoo.com
kevin.gibbons@mcdata.com
8. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP 78
and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances
of licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such proprietary
rights by implementers or users of this specification can be obtained
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 Phone: (408) 567-5765
copyrights, patents or patent applications, or other proprietary rights EMail: kevin.gibbons@mcdata.com
that may cover technology that may be required to implement this
standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
9. Full Copyright Statement Charles Monia
7553 Morevern Circle
San Jose, CA 95135
Copyright (C) The Inter EMail: charles_monia@yahoo.com
net Society July 2004. This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
10. Disclaimer of Validity Josh Tseng
Riverbed Technology
501 2nd Street, Suite 410
San Francisco, CA 94107
This document and the information contained herein are provided on an "AS Phone: (650)274-2109
IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS EMail: joshtseng@yahoo.com
SPONSORED BY (IF ANY), 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
DHCP Option Number for iSNS Revision 13 November 2004 Full Copyright Statement
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR Copyright (C) The Internet Society (2005).
FITNESS FOR A PARTICULAR PURPOSE.
Internet-Drafts are working documents of the Internet Engineering Task This document is subject to the rights, licenses and restrictions
Force (IETF), its areas, and its working groups. Note that other groups contained in BCP 78, and except as set forth therein, the authors
may also distribute working documents as Internet-Drafts. retain all their rights.
Internet-Drafts are draft documents valid for a maximum of six months and This document and the information contained herein are provided on an
may be upated, replaced, or obsoleted by other documents at any time. It "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
is inappropriate to use Internet-Drafts as reference material or to cite OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
them other than a "work in progress." ENGINEERING TASK FORCE DISCLAIM 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.
The list of current Internet-Drafts can be accessed at Intellectual Property
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The IETF takes no position regarding the validity or scope of any
http://www.ietf.org/shadow.html Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
11. Acknowledgement Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
Funding for the RFC Editor function is currently provided by the Internet The IETF invites any interested party to bring to its attention any
Society. copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
12. Expiration Notice Acknowledgement
This Internet-Draft expires in May 2005. Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 104 change blocks. 
401 lines changed or deleted 320 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/