draft-ietf-ips-iscsi-slp-08.txt   draft-ietf-ips-iscsi-slp-09.txt 
Internet Draft Mark Bakke Internet Draft Mark Bakke
<draft-ietf-ips-iscsi-slp-08.txt> Cisco <draft-ietf-ips-iscsi-slp-09.txt> Cisco
Expires October 2004 Expires February 2005
John Hufferd John Hufferd
Kaladhar Voruganti Kaladhar Voruganti
IBM IBM
Marjorie Krueger Marjorie Krueger
HP HP
Todd Sperry Todd Sperry
Adaptec Adaptec
April 2004 August 2004
Finding iSCSI Targets and Name Servers Using SLP Finding Internet Small Computer Systems Interface (iSCSI) Targets
and Name Servers using Service Location Protocol version 2 (SLPv2)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 30 skipping to change at page 2, line 30
(IBM) for suggesting the use of SLP for iSCSI discovery, and to Matt (IBM) for suggesting the use of SLP for iSCSI discovery, and to Matt
Peterson (Caldera) and James Kempf (Sun) for reviewing the document Peterson (Caldera) and James Kempf (Sun) for reviewing the document
from an SLP perspective. from an SLP perspective.
Table of Contents Table of Contents
1. Introduction.................................................2 1. Introduction.................................................2
2. Notation Conventions.........................................3 2. Notation Conventions.........................................3
3. Terminology..................................................3 3. Terminology..................................................3
4. Using SLP for iSCSI Service Discovery........................4 4. Using SLP for iSCSI Service Discovery........................4
5. iSCSI SLP Templates.........................................13 5. iSCSI SLP Templates.........................................12
6. Security Considerations.....................................19 6. Security Considerations.....................................18
7. IANA Considerations.........................................20 7. IANA Considerations.........................................20
8. Summary.....................................................20 8. Summary.....................................................20
9. Normative References........................................20 9. Normative References........................................20
10. Informative References......................................21 10. Informative References......................................21
11. Authors' Addresses..........................................22 11. Authors' Addresses..........................................21
12. Full Copyright Notice.......................................22 12. Full Copyright Notice.......................................22
1. Introduction 1. Introduction
iSCSI [RFC3720] is a protocol used to transport SCSI [SAM2] commands, iSCSI [RFC3720] is a protocol used to transport SCSI [SAM2] commands,
data, and status across an IP network. This protocol is connection- data, and status across an IP network. This protocol is connection-
oriented, and is currently defined over TCP. iSCSI uses a client- oriented, and is currently defined over TCP. iSCSI uses a client-
server relationship. The client end of the connection is an server relationship. The client end of the connection is an
initiator, and sends SCSI commands; the server end of the connection initiator, and sends SCSI commands; the server end of the connection
is called a target, and receives and executes the commands. is called a target, and receives and executes the commands.
skipping to change at page 7, line 21 skipping to change at page 7, line 21
Each iSCSI target and initiator has a unique name, called an iSCSI Each iSCSI target and initiator has a unique name, called an iSCSI
Name. This identifier is the same regardless of the network path Name. This identifier is the same regardless of the network path
(through adapter cards, networks, interfaces on the storage device) (through adapter cards, networks, interfaces on the storage device)
over which the target is discovered and accessed. For this example, over which the target is discovered and accessed. For this example,
the iSCSI names "one" and "two", and "three" are used for the the iSCSI names "one" and "two", and "three" are used for the
targets; the initiator uses the name "myhost". An actual iSCSI name targets; the initiator uses the name "myhost". An actual iSCSI name
would incorporate more structure, including a naming authority, and would incorporate more structure, including a naming authority, and
is not described here. is not described here.
Each of the iSCSI targets in the drawing can appear at two addresses, Each of the iSCSI targets in the drawing can appear at two addresses,
since two network interfaces are present. Each target, would have since two network interfaces are present. Each target would have two
two service URLs. service URLs, unless a single service URL included a DNS host name
mapping to both addresses.
An iSCSI target URL consists of its fully qualified host name or IP An iSCSI target URL consists of its fully qualified host name or IP
address, the TCP port on which it is listening, and its iSCSI name. address, the TCP port on which it is listening, and its iSCSI name.
An iSCSI server must register each of its individual targets at each An iSCSI server must register each of its individual targets at each
of its network addresses. of its network addresses.
The iSCSI server constructs a service advertisement of the type The iSCSI server constructs a service advertisement of the type
"service:iscsi:target" for each of the service URLs it wishes to "service:iscsi:target" for each of the service URLs it wishes to
register. The advertisement contains a lifetime, along with other register. The advertisement contains a lifetime, along with other
attributes which are defined in the service template. attributes which are defined in the service template.
skipping to change at page 9, line 18 skipping to change at page 9, line 18
host name is required. If a large number of addresses is to host name is required. If a large number of addresses is to
be allowed (perhaps a subnet), this attribute may contain the be allowed (perhaps a subnet), this attribute may contain the
value "any". value "any".
3. auth-cred - This attribute contains a list of "method/identifier" 3. auth-cred - This attribute contains a list of "method/identifier"
credentials that will be allowed access to the target, provided credentials that will be allowed access to the target, provided
they can produce the correct password or other verifier during they can produce the correct password or other verifier during
the login process. If no specific credentials are required, the the login process. If no specific credentials are required, the
value "any" is used. value "any" is used.
The above identifiers follow the semantics described in the IP The list of valid method strings for auth-cred are defined in
Storage Authentication MIB [AUTH-MIB]. Examples showing initiator [RFC3720], section 11.1 "AuthMethod". The identifier used after the
searches based on auth-xxxx attributes are shown in the target- "/" is defined by the specific AuthMethod, also in [RFC3720].
specific template section below. Examples showing initiator searches based on auth-xxxx attributes are
shown in the target-specific template section below.
Also note that the auth-xxxx attributes are considered to be security Also note that the auth-xxxx attributes are considered to be security
policy information. If these attributes are distributed, IPsec MUST policy information. If these attributes are distributed, IPsec MUST
be implemented as specified in the Security Implementation section be implemented as specified in the Security Implementation section
below. below.
4.1.2. Supporting Access by Multiple Identities to the Same Target 4.1.2. Supporting Access by Multiple Identities to the Same Target
If a target is to allow access to multiple host identities, more than If a target is to allow access to multiple host identities, more than
one combination of auth-xxxx attributes will need to be present. one combination of auth-xxxx attributes will need to be allowed. In
Since service URLs must be unique, each of these must be registered some of these cases, it is not possible to express the entire set of
under its own service URL. valid combinations of auth-xxxx attributes within a single registered
service URL. For example, if a target can be addressed by:
auth-name=myhost1 AND auth-cred=CHAP/user1 (identity1)
OR
auth-name-myhost2 AND auth-cred=CHAP/user2 (identity2)
the above cannot be specified in a single registered service URL,
since (auth-name=myhost1, auth-name=myhost2, auth-cred=CHAP/user1,
auth-cred=CHAP/user2) would allow either auth-name to be used with
either auth-cred. This necessitates the ability to register a target
and address under more than one service URL; one for (identity1) and
one for (identity2).
Since service URLs must be unique, (identity1) and (identity2) must
each be registered under its own unique service URL.
For systems that support the configuration of multiple identities to For systems that support the configuration of multiple identities to
access a target, the service URL must contain an additional, opaque access a target, the service URL must contain an additional, opaque
string defining the identity. This appears after the iSCSI name in string defining the identity. This appears after the iSCSI name in
the URL string, and is separated by a "/". Each registered (target- the URL string, and is separated by a "/". Each registered (target-
address, target-name, initiator-identity) tuple can then register its address, target-name, initiator-identity) tuple can then register its
own set of auth-xxxx attributes. own set of auth-xxxx attributes.
An initiator-identity is equivalent to the authentication identity
defined in [AUTH-MIB].
4.1.3. Using SLP in a Non-Multicast Environment 4.1.3. Using SLP in a Non-Multicast Environment
In some networks, the use of multicast for discovery purposes is In some networks, the use of multicast for discovery purposes is
either unavailable or not allowed. Such networks include public or either unavailable or not allowed. Such networks include public or
service-provider networks that are placed in between an iSCSI client service-provider networks that are placed in between an iSCSI client
and server; these are probably most common between two iSCSI and server; these are probably most common between two iSCSI
gateways, one at a storage service provider site, and one at a gateways, one at a storage service provider site, and one at a
customer site. customer site.
In these networks, an initiator may, instead or in addition to its DA In these networks, an initiator may, instead or in addition to its DA
configuration, allow the addresses of one or more SAs to be configuration, allow the addresses of one or more SAs to be
configured. The initiator would then make unicast SLP service configured. The initiator would then make unicast SLP service
requests directly to these SAs, without the use of multicast to first requests directly to these SAs, without the use of multicast to first
discover them. discover them.
This functionality is well within the scope of the current SLP This functionality is well within the scope of the current SLP
protocol. However, it does have two consequences for implementors: protocol. The main consequence for implementors is that an initiator
configured to make direct, unicast requests to an SA will have to add
- A service-agent responding to requests for iSCSI targets MUST this to the SLP API, if it is following the service location API
implement SLP over TCP; UDP only is not enough. This is not defined in [RFC2614]. This capability is being added to the next
an issue, since TCP is a requirement for iSCSI implementations revision of the API, in [2614BIS].
that use SLP for other reasons.
- An initiator configured to make direct, unicast requests to an
SA will have to add this to the SLP API, if it is following the
service location API defined in [RFC2614]. This capability
is being added to the next revision of the API, in [2614BIS].
4.2. Discovering Storage Management Services using SLP 4.2. Discovering Storage Management Services using SLP
Storage management servers can be built to manage and control access Storage management servers can be built to manage and control access
to targets in a variety of ways. They can also provide extended to targets in a variety of ways. They can also provide extended
services beyond discovery, which could include storage allocation and services beyond discovery, which could include storage allocation and
management. None of these services are defined here; the intent of management. None of these services are defined here; the intent of
this document is to allow these services to be discovered by both this document is to allow these services to be discovered by both
clients and servers, in addition to the target discovery already clients and servers, in addition to the target discovery already
being performed. being performed.
skipping to change at page 12, line 22 skipping to change at page 12, line 22
appropriately by providing an SA and registering the appropriate appropriately by providing an SA and registering the appropriate
service:iscsi:target registrations on the target's behalf; the target service:iscsi:target registrations on the target's behalf; the target
device would not have to advertise its own targets. This has no device would not have to advertise its own targets. This has no
impact on the initiator. impact on the initiator.
This allows the initiators' discovery of targets to be completely This allows the initiators' discovery of targets to be completely
interoperable regardless of which storage management service is used, interoperable regardless of which storage management service is used,
or whether one is used at all, or whether the target registrations or whether one is used at all, or whether the target registrations
are provided directly by the target or by the management service. are provided directly by the target or by the management service.
4.3. NAT and NAPT Considerations 4.3. Internationalization Considerations
Since SLP provides IP address and TCP port information within its
payload, the addresses an SA or DA advertise may not be the same as
those a UA must use if a Network Address(/Port) Translation
(NAT/NAPT) device is present between the UA and the SA. This may
result in the UA discovering address information that is unusable.
Also note that SLP advertisements that occur inside a private address
realm may be unreachable outside that realm. Below are some
recommendations for dealing with SLPv2 and NAT/NAPT devices:
- A fully-qualified domain name (i.e. not an IP address) SHOULD be
used in service URLs, the mgmt-entity attribute, and the auth-addr
attribute [RFC1900].
- Configure the NAPT device to provide default mapping(s) for the
well-known port(s) and use the default IANA-assigned iSCSI TCP port
number in service URLs, when possible.
4.4. Internationalization Considerations
SLP allows internationalized strings to be registered and retrieved. SLP allows internationalized strings to be registered and retrieved.
Attributes in the template that are not marked with an 'L' (literal) Attributes in the template that are not marked with an 'L' (literal)
will be registered in a localized manner. An "en" (English) will be registered in a localized manner. An "en" (English)
localization MUST be registered, and others MAY be registered. localization MUST be registered, and others MAY be registered.
Attributes that include non-ASCII characters will be encoded using Attributes that include non-ASCII characters will be encoded using
UTF-8, as discussed in [RFC3722] and [RFC3491]. UTF-8, as discussed in [RFC3722] and [RFC3491].
5. iSCSI SLP Templates 5. iSCSI SLP Templates
skipping to change at page 15, line 40 skipping to change at page 15, line 21
- the service URL - the service URL
template-url-syntax= template-url-syntax=
url-path = hostport "/" iscsi-name [ "/" identity ] url-path = hostport "/" iscsi-name [ "/" identity ]
hostport = host [ ":" port ] hostport = host [ ":" port ]
host = hostname / hostnumber ; DNS name or IP address host = hostname / hostnumber ; DNS name or IP address
hostname = *( domainlabel "." ) toplabel hostname = *( domainlabel "." ) toplabel
alphanum = ALPHA / DIGIT alphanum = ALPHA / DIGIT
domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum
toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
hostnumber = ipv4-number hostnumber = ipv4-number / ipv6-addr ; IPv4 or IPv6 address
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT) ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)
ipv6-addr = "[" ipv6-number "]"
ipv6-number = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
ls32 = ( h16 ":" h16 ) / ipv4-number
; least-significant 32 bits of ipv6 address
h16 = 1*4HEXDIG
port = 1*DIGIT port = 1*DIGIT
iscsi-name = iscsi-char ; iSCSI target name iscsi-name = iscsi-char ; iSCSI target name
identity = iscsi-char ; optional identity string identity = iscsi-char ; optional identity string
iscsi-char = ALPHA / DIGIT / escaped / ":" / "-" / "." iscsi-char = ALPHA / DIGIT / escaped / ":" / "-" / "."
; Intended to allow UTF-8 encoded strings ; Intended to allow UTF-8 encoded strings
escaped = 1*(`' HEXDIG HEXDIG) escaped = 1*(`' HEXDIG HEXDIG)
; ;
; The iscsi-name part of the URL is required and must be the iSCSI ; The iscsi-name part of the URL is required and must be the iSCSI
; name of the target being registered. ; name of the target being registered.
; A device representing multiple targets must individually ; A device representing multiple targets must individually
; register each target/address combination with SLP. ; register each target/address combination with SLP.
; The identity part of the URL is optional, and is used to ; The identity part of the URL is optional, and is used to
; indicate an identity that is allowed to access this target. ; indicate an identity that is allowed to access this target.
; ;
; Example (split into two lines for clarity): ; Example (split into two lines for clarity):
; service:iscsi:target://192.0.2.3:3260/ ; service:iscsi:target://192.0.2.3:3260/
; iqn.2001-04.com.example.sn.45678 ; iqn.2001-04.com.example.sn.45678
;
; IPv6 addresses are also supported; they use the notation specified
; above and in [RFC3513], section 2.2
iscsi-name = string iscsi-name = string
# The iSCSI Name of this target. # The iSCSI Name of this target.
# This must match the iscsi-name in the url-path. # This must match the iscsi-name in the url-path.
portal-group = integer portal-group = integer
# The iSCSI portal group tag for this address. Addresses sharing # The iSCSI portal group tag for this address. Addresses sharing
# the same iscsi-name and portal-group tag can be used within the # the same iscsi-name and portal-group tag can be used within the
# same iSCSI session. Portal groups are described in [RFC3720]. # same iSCSI session. Portal groups are described in [RFC3720].
skipping to change at page 21, line 14 skipping to change at page 21, line 5
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, version 2", RFC 2608, June 1999. Location Protocol, version 2", RFC 2608, June 1999.
[RFC2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates [RFC2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates
and service: Schemes", RFC 2609, June 1999. and service: Schemes", RFC 2609, June 1999.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile
for Internationalized Domain Names", RFC 3491, March 2003.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M. and [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M. and
E. Zeidner, "Internet Small Computer Systems Interface E. Zeidner, "Internet Small Computer Systems Interface
(iSCSI)", RFC 3720, March 2004. (iSCSI)", RFC 3720, March 2004.
[RFC3722] Bakke, M., "String Profile for iSCSI Names", RFC 3722,
March 2004.
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F.
Travostino, "Securing Block Storage Protocols over IP", RFC Travostino, "Securing Block Storage Protocols over IP", RFC
3723, March 2004. 3723, March 2004.
10. Informative References 10. Informative References
[RFC2614] Kempf, J. and E. Guttman, "An API for Service Location", [RFC2614] Kempf, J. and E. Guttman, "An API for Service Location",
RFC 2614, June 1999. RFC 2614, June 1999.
[2614BIS] Kempf, J. and E. Guttman, "An API for Service Location", [2614BIS] Kempf, J. and E. Guttman, "An API for Service Location",
draft-kempf-svrloc-rfc2614bis-00.txt, February 2002. draft-kempf-svrloc-rfc2614bis-00.txt, February 2002.
[SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000. [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000.
[RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M.
Krueger, "Internet Small Computer Systems Interface (iSCSI) Krueger, "Internet Small Computer Systems Interface (iSCSI)
Naming and Discovery", RFC 3721, March 2004. Naming and Discovery", RFC 3721, March 2004.
[AUTH-MIB] Bakke, M. and J. Muchow, "Definitions of Managed Objects for
User Identity Authentication", Work in Progress, draft-ietf-
ips-auth-mib-04.txt, March 2003.
[ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C. and J. [ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C. and J.
Souza, "Internet Storage Name Service", Work in Progress, Souza, "Internet Storage Name Service", Work in Progress,
draft-ietf-ips-isns-22.txt, February 2004. draft-ietf-ips-isns-22.txt, February 2004.
[BOOT] Sarkar, P., Missimer, D. and C. Sapuntzakis, "A Standard [BOOT] Sarkar, P., Missimer, D. and C. Sapuntzakis, "A Standard
for Bootstrapping Clients using the iSCSI Protocol", Work in for Bootstrapping Clients using the iSCSI Protocol", Work in
Progress, draft-ietf-ips-iscsi-boot-12.txt, March 2004. Progress, draft-ietf-ips-iscsi-boot-12.txt, March 2004.
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.
[RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with [RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with
SLP", RFC 3105, October 2001. SLP", RFC 3105, October 2001.
[RFC3722] Bakke, M., "String Profile for iSCSI Names", RFC 3722,
March 2004.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile
for Internationalized Domain Names", RFC 3491, March 2003.
11. Authors' Addresses 11. Authors' Addresses
Mark Bakke Mark Bakke
Cisco Systems, Inc. Cisco Systems, Inc.
6450 Wedgwood Road 6450 Wedgwood Road
Maple Grove, MN 55311 Maple Grove, MN 55311
Voice: +1 763-398-1000 Voice: +1 763-398-1000
EMail: mbakke@cisco.com EMail: mbakke@cisco.com
 End of changes. 

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