FCIP SLPv2 Discovery: Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)
How Fibre Channel over TCP/IP endpoints find each other with the Service Location Protocol.
Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)", RFC 3822, DOI 10.17487/RFC3822, July 2004, <https://www.rfc-editor.org/info/rfc3822>.
@misc{rfc3822,
series = {Request for Comments},
number = 3822,
howpublished = {RFC 3822},
publisher = {RFC Editor},
doi = {10.17487/RFC3822},
url = {https://www.rfc-editor.org/info/rfc3822},
author = {D. Peterson},
title = {{Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)}},
pagetotal = 11,
year = 2004,
month = jul,
} RFC text
Contents
Network Working Group D. Peterson
Request for Comments: 3822 Computer Network Technology (CNT)
Category: Standards Track July 2004
Finding Fibre Channel over TCP/IP (FCIP) Entities
Using Service Location Protocol version 2 (SLPv2)
Status of this Memo
This document specifies an Internet standards track protocol for the
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.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document defines the use of Service Location Protocol version 2
(SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities.
1. Introduction
This document describes the use of the Service Location Protocol
version 2 in performing dynamic discovery of participating Fibre
Channel over TCP/IP (FCIP) Entities. Implementation guidelines,
service type templates, and security considerations are specified.
2. Notation Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Terminology
Here are some definitions that may aid readers that are unfamiliar
with either SLP or FCIP. Some of these definitions have been
reproduced from [RFC2608] and [RFC3105].
User Agent (UA) A process working on the client's behalf
to establish contact with some service.
The UA retrieves service information from
the Service Agents or Directory Agents.
Service Agent (SA) A process working on behalf of one or more
services to advertise the services and
their capabilities.
Directory Agent (DA) A process which collects service
advertisements. There can only be one DA
present per given host.
Scope A named set of services, typically making
up a logical administrative group.
Service Advertisement A URL, attributes, and a lifetime
(indicating how long the advertisement is
valid), providing service access
information and capabilities description
for a particular service.
FCIP Entity The principle FCIP interface point to the
IP network.
FCIP Entity Name The world wide name of the switch if the
FCIP Entity resides in a switch or the
world wide node name of the associated
Nx_Port.
FCIP Discovery Domain The FCIP Discovery Domain specifies which
FCIP Entities are allowed to discover each
other within the bounds of the scope.
4. Using SLPv2 for FCIP Service Discovery
At least two FCIP Entities must be involved in the entity discovery
process. The end result is that an FCIP Entity will discover one or
more peer FCIP Entities.
4.1. Discovering FCIP Entities using SLPv2
Figure 1 shows the relationship between FCIP Entities and their
associated SLPv2 agents.
+--------------------------------------+
| FCIP Entity |
+----------------------------------+ |
| FCIP Control and Services Module | |
+----------------+ | |
| SA | UA | | |
+----------------+-----------------+ |
| TCP/UDP/IP | |
+----------------+-----------------+ |
| Interface | |
| 192.0.2.10 | |
+----------------+-----------------+---|
|
+------------+ |
| SLPv2 DA |----+ IP Network
+------------+ |
|
+----------------+-----------------+---|
| Interface | |
| 192.0.2.20 | |
+----------------+-----------------+ |
| TCP/UDP/IP | |
+----------------+-----------------+ |
| SA | UA | | |
+----------------+ | |
| FCIP Control and Services Module | |
+--------------------------------- + |
| FCIP Entity |
+--------------------------------------+
Figure 1: FCIP Entity and SLPv2 Agent Relationship.
As indicated in Figure 1, each FCIP Entity contains an FCIP Control
and Services Module that interfaces to an SLPv2 SA and UA.
The SA constructs a service advertisement of the type
"service:fcip:entity" for each of the service URLs it wishes to
register. The service advertisement contains a lifetime, along with
other attributes defined in the service template.
The remainder of the discovery process is identical to that used by
any client/server pair implementing SLPv2:
1. If an SLPv2 DA is found [RFC2608], the SA contacts the DA and
registers the service advertisement. Whether or not one or more
SLPv2 DAs are discovered, the SA maintains the service
advertisement itself and answers multicast UA queries directly.
2. When the FCIP Entity requires contact information for a peer FCIP
Entity, the UA either contacts the DA using unicast or the SA
using multicast using an SLPv2 service request. The UA service
request includes a query, based on the attributes, to indicate the
characteristics of the peer FCIP Entities it requires.
3. Once the UA has the IP address and port number of a peer FCIP
Entity, it may begin the normal connection procedure, as described
in [RFC3821], to a peer FCIP Entity.
The use of a DA is RECOMMENDED for SLPv2 operations in an FCIP
environment.
4.1.1. FCIP Discovery Domains
The concept of a discovery domain provides further granularity of
control of allowed discovery between FCIP Entities within a specific
SLPv2 scope.
Figure 2 shows an example relationship between FCIP Entities and
their associated discovery domains within a specified SLPv2 scope.
=================fcip=======================================
= =
= *************************purple*********************** =
= * * =
= * #####orange###################### * =
= * # ------------ //////blue//////+/////////////// * =
= * # | FCIP | / # / * =
= * # | Entity A | / # / * =
= * # ------------ / # ------------ / * =
= * # / # | FCIP | / * =
= * # / # | Entity C | / * =
= * # / ------------ # ------------ / * =
= * # / | FCIP | # / * =
= * # / | Entity B | # / * =
= * # / ------------ # / * =
= * ################+################ / * =
= * //////////////////////////////// * =
= * * =
= ****************************************************** =
= =
============================================================
Figure 2: FCIP Entity and Discovery Domain Example.
Within the specified scope "fcip", the administrator has defined a
discovery domain "purple", allowing FCIP Entities A, B, and C to
discover each other. This discovery domain is illustrated using the
"*" character.
Within the specified scope "fcip", the administrator has defined a
discovery domain "orange", allowing FCIP Entity A to discover FCIP
Entity B, but not FCIP Entity C. This discovery domain is
illustrated using the "#" character.
Within the specified scope "fcip", the administrator has defined a
discovery domain "blue", allowing FCIP Entity C to discover FCIP
Entity B, but not FCIP Entity A. This discovery domain is
illustrated using the "/" character.
For the example relationship shown in Figure 2, the value of the
fcip-discovery-domain attribute for each FCIP Entity is as follows:
FCIP Entity A = orange,purple
FCIP Entity B = orange,blue,purple
FCIP Entity C = blue,purple
5. FCIP SLPv2 Templates
Two templates are provided: an FCIP Entity template, and an abstract
template to provide a means of adding other FCIP related templates in
the future.
5.1. The FCIP Abstract Service Type Template
This template defines the abstract service "service:fcip". It is
used as a top-level service to encapsulate all other FCIP related
services.
Name of submitter: David Peterson
Language of service template: en
Security Considerations: see section 6.
Template Text:
-------------------------template begins here-----------------------
template-type=fcip
template-version=0.1
template-description=
This is an abstract service type. The purpose of the fcip service
type is to encompass all of the services used to support the FCIP
protocol.
template-url-syntax =
url-path= ; Depends on the concrete service type.
--------------------------template ends here------------------------
5.2. The FCIP Entity Concrete Service Type Template
This template defines the service "service:fcip:entity". A device
containing FCIP Entities that wishes to have them discovered via
SLPv2 would register each of them with each of their addresses, as
this service type.
FCIP Entities wishing to discover other FCIP Entities in this manner
will generally use one of the following example query strings:
1. Find a specific FCIP Entity, given its FCIP Entity Name:
Service: service:fcip:entity
Scope: fcip-entity-scope-list
Query: (fcip-entity-name=\ff\10\00\00\60\69\20\34\0C)
2. Find all of the FCIP Entities within a specified FCIP Discovery
Domain:
Service: service:fcip:entity
Scope: fcip-entity-scope-list
Query: (fcip-discovery-domain=fcip-discovery-domain-name)
3. In addition, a management application may wish to discover all
FCIP Entities:
Service: service:fcip:entity
Scope: management-service-scope-list
Query: none
Name of submitter: David Peterson
Language of service template: en
Security Considerations: see section 6.
Template Text:
-------------------------template begins here-----------------------
template-type=fcip:entity
template-version=0.1
template-description=
This is a concrete service type. The fcip:entity service type is
used to register individual FCIP Entity addresses to be discovered
by others. UAs will generally search for these by including one of
the following:
- the FCIP Entity Name for which an address is needed
- the FCIP Discovery Domain Name for which addresses are requested
- the service URL
template-url-syntax =
url-path = hostport
hostport = host [ ":" port ]
host = hostname / hostnumber
hostname = *( domainlabel "." ) toplabel
alphanum = ALPHA / DIGIT
domainlabel = alphanum / alphanum * [alphanum / "-"] alphanum
toplabel = ALPHA / ALPHA * [ alphanum / "-" ] alphanum
hostnumber = ipv4-number
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)
port = 1*DIGIT
;
; A DNS host name should be used along with the well-known
; IANA FCIP port number for operation with NAT/NAPT devices.
;
; Examples:
; service:fcip:entity://host.example.com
; service:fcip:entity://192.0.2.0:4000
;
fcip-entity-name = opaque L
# If the FCIP Entity is a VE_Port/B_Access implementation [FC-BB-2]
# residing in a switch, the fcip-entity-name is the Fibre Channel
# Switch Name [FC-SW-3]. Otherwise, the fcip-entity-name is the
# Fibre Channel Node Name [FC-FS] of the port (e.g., an Nx_Port)
# associated with the FCIP Entity.
# An entity representing multiple endpoints must register each of
# the endpoints using SLPv2.
transports = string M L
tcp
# This is a list of transport protocols that the registered entity
# supports. FCIP is currently supported over TCP only.
tcp
mgmt-entity = string M O L
# The URL's of the management interface(s) are appropriate for SNMP,
# web-based, or telnet management of the FCIP Entity.
# Examples:
# http://fcipentity.example.com:1080/
# telnet://fcipentity.example.com
fcip-discovery-domain = string M L
fcip
# The fcip-discovery-domain string contains the name(s) of the FCIP
# discovery domain(s) to which this FCIP Entity belongs.
--------------------------template ends here------------------------
6. Security Considerations
The SLPv2 security model as specified in [RFC2608] does not provide
confidentiality, but does provide an authentication mechanism for UAs
to assure that service advertisements only come from trusted SAs with
the exception that it does not provide a mechanism for authenticating
"zero-result responses". See [RFC3723] for a discussion of the SLPv2
[RFC2608] security model.
Once an FCIP Entity is discovered, authentication and authorization
are handled by the FCIP protocol. It is the responsibility of the
providers of these services to ensure that an inappropriately
advertised or discovered service does not compromise their security.
When no security is used for SLPv2, there is a risk of distribution
of false discovery information. The primary countermeasure for this
risk is authentication. When this risk is a significant concern,
IPsec SAs SHOULD be used for FCIP traffic subject to this risk to
ensure that FCIP traffic only flows between endpoints that have
participated in IKE authentication. For example, if an attacker
distributes discovery information falsely claiming that it is an FCIP
endpoint, it will lack the secret information necessary to
successfully complete IKE authentication, and hence will be prevented
from falsely sending or receiving FCIP traffic.
There remains a risk of a denial of service attack based on repeated
use of false discovery information that will cause the initiation of
IKE negotiation. The countermeasures for this are administrative
configuration of each FCIP Entity to 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 authentication cache to avoid
repeatedly contacting an FCIP Entity that fails to authenticate.
These three measures (i.e., IP address range limits, DNS domain
limits, negative authentication cache) MUST be implemented.
6.1. Security Implementation
Security for SLPv2 in an IP storage environment is specified in
[RFC3723]. IPsec is mandatory-to-implement for IPS clients and
servers. Thus, all IP storage clients, including those invoking SLP,
can be assumed to support IPsec. SLP servers, however, cannot be
assumed to implement IPsec, since there is no such requirement in
standard SLP. In particular, SLP Directory Agents (DA) may be
running on machines other than those running the IPS protocols.
IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this
includes ESP with a non-null transform to provide both authentication
and confidentiality.
Because the IP storage services have their own authentication
capabilities when located, SLPv2 authentication is OPTIONAL to
implement and use (as discussed in more detail in [RFC3723]).
7. IANA Considerations
This document describes two SLP Templates in Section 5. They should
be registered in the IANA "SVRLOC Templates" registry. This process
is described in the IANA Considerations section of [RFC2609].
8. Internationalization Considerations
SLP allows internationalized strings to be registered and retrieved.
Attributes in the template that are not marked with an 'L' (literal)
will be registered in a localized manner. An "en" (English)
localization MUST be registered, and others MAY be registered.
9. Summary
This document describes how SLPv2 can be used by FCIP Entities to
find other FCIP Entities. Service type templates for FCIP Entities
are presented.
10. Acknowledgements
This document was produced by the FCIP discovery team, including Todd
Sperry (Adaptec), Larry Lamars (SanValley), Robert Snively (Brocade),
Ravi Natarajan (Lightsand), Anil Rijhsinghani (McData), and Venkat
Rangan (Rhapsody Networks). Thanks also to Mark Bakke (Cisco) for
initial help and consultation, and David Black, Erik Guttman, and
James Kempf for assistance during expert review.
11. References
11.1. Normative References
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day,
"Service Location Protocol, Version 2", RFC 2608, June
1999.
[RFC2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates
and Service: Schemes", RFC 2609, June 1999.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3821] Rajagopal, M., Bhagwat, R. and R. Weber, "Fibre Channel
Over TCP/IP (FCIP)", RFC 3821, July 2004.
[FC-SW-3] Fibre Channel Switch Fabric - 3, ANSI INCITS 384-2004.
[FC-BB-2] Fibre Channel Backbone - 2, ANSI INCITS 372-2003.
[FC-FS] Fibre Channel Framing and Signaling, T11 Project 1331-D,
Rev 1.90, April 9, 2003.
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F.
Travostino, "Securing Block Storage Protocols over IP",
RFC 3723, April 2004.
11.2. Informative References
[RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with
SLP", RFC 3105, October 2001.
12. Author's Address
David Peterson
Computer Network Technology (CNT)
6000 Nathan Lane North
Minneapolis, MN 55442
Phone: 763-268-6139
EMail: dap@cnt.com
13. Full Copyright Statement
Copyright (C) The Internet Society (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.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
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.
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
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ISO Plain Language
On this page
§1What the Document Covers
The RFC describes the use of the Service Location Protocol version 2 to perform dynamic discovery of participating Fibre Channel over TCP/IP entities. It specifies implementation guidelines, service type templates and security considerations.
The scope is narrow on purpose. It covers how FCIP entities are advertised and found; it does not change how they connect, which is defined in RFC 3821.
The document covers discovery only: how an endpoint advertises itself, how another endpoint finds it, and how an administrator limits who may find whom.
§3The Terms Used
Some definitions are reproduced from the SLP and FCIP specifications. A User Agent is a process working on the client's behalf to establish contact with some service; it retrieves service information from the Service Agents or Directory Agents. A Service Agent is a process working on behalf of one or more services to advertise the services and their capabilities. A Directory Agent is a process that collects service advertisements, and there can be only one on a given host.
A Scope is a named set of services, typically making up a logical administrative group. A Service Advertisement is a URL, attributes and a lifetime, which says how long the advertisement is valid, and it provides the service access information and a capabilities description for a particular service.
An FCIP Entity is the principal FCIP interface point to the IP network. Its FCIP Entity Name is the worldwide name of the switch if the entity resides in a switch, or the worldwide node name of the associated Nx_Port. An FCIP Discovery Domain specifies which FCIP entities are allowed to discover each other within the bounds of the scope.
Three SLP roles appear throughout: the service agent advertises, the user agent asks, and the directory agent collects the advertisements. An FCIP entity is one endpoint of the protocol, and it has a name and a set of discovery domains.
§4.1How Discovery Works
At least two FCIP entities must be involved, and the end result is that one entity discovers one or more peer entities. Each FCIP entity contains an FCIP control and services module that interfaces to an SLP service agent and user agent.
The service agent builds a service advertisement of the type service:fcip:entity for each of the service URLs it wishes to register, and the advertisement contains a lifetime along with the other attributes defined in the service template.
The rest of the discovery process is the same as for any client and server pair implementing SLPv2. If a directory agent is found, the service agent contacts it and registers the service advertisement. Whether or not a directory agent is found, the service agent keeps the advertisement itself and answers multicast user agent queries directly. When the FCIP entity needs contact information for a peer, the user agent either contacts the directory agent by unicast or the service agent by multicast, using an SLP service request. That request includes a query, based on the attributes, that says what characteristics the peer entities it requires must have. Once the user agent has the IP address and port number of a peer FCIP entity, it may begin the normal connection procedure described in RFC 3821.
The RFC recommends the use of a directory agent for SLPv2 operations in an FCIP environment.
Each endpoint advertises itself as a service of type service:fcip:entity, with a lifetime and a set of attributes. Another endpoint asks for the peers it needs, either through a directory agent or by a multicast query, and then connects in the ordinary way.
- Service registrationThe service agent registers the service:fcip:entity advertisement.
- Service requestThe user agent asks for the peers it needs, by attribute query.
- Service replyReturns the URLs of the matching peers, with their addresses and ports.
- FCIP connectionThe normal FCIP connection procedure starts from the address and port found.
§4.1.1FCIP Discovery Domains
A discovery domain gives finer control over which FCIP entities may discover each other inside a specific SLP scope. The example uses the scope fcip and three domains. The domain purple allows entities A, B and C to discover each other. The domain orange allows entity A to discover entity B but not entity C. The domain blue allows entity C to discover entity B but not entity A.
With that arrangement, the value of the fcip-discovery-domain attribute is orange,purple for entity A, orange,blue,purple for entity B, and blue,purple for entity C. A user agent searching for all entities in a named domain therefore only finds the peers that share that domain with it.
A discovery domain is a label that entities share. Two endpoints can find each other only if they have a domain in common, so the administrator can permit some pairs and forbid others inside one SLP scope.
| Entity | Domains it belongs to | Peers it can discover |
|---|---|---|
| Entity A | orange, purple | Entity B |
| Entity B THIS RFC | orange, blue, purple | Entity A and Entity C |
| Entity C | blue, purple | Entity B |
§5The Service Type Templates
Two templates are provided. The FCIP abstract service type template defines the abstract service service:fcip, used as a top-level service to encapsulate all other FCIP related services. Its URL syntax leaves the path to depend on the concrete service type, and its template version is 0.1.
The FCIP entity concrete service type template defines the service service:fcip:entity. A device holding FCIP entities that wants them discovered through SLPv2 registers each of them with each of its addresses under this service type. The template version is again 0.1, and the URL syntax is a host, optionally followed by a colon and a port. The RFC notes that a DNS host name should be used along with the well-known IANA FCIP port number when working with NAT or NAPT devices, and gives the examples service:fcip:entity://host.example.com and service:fcip:entity://192.0.2.0:4000.
The template defines four attributes. fcip-entity-name is an opaque string: if the entity is a VE_Port or B_Access implementation residing in a switch, the name is the Fibre Channel switch name, and otherwise it is the Fibre Channel node name of the associated port, such as an Nx_Port. An entity that represents multiple endpoints must register each endpoint separately. transports is a list of the transport protocols the registered entity supports, and FCIP is currently supported over TCP only. mgmt-entity holds the URLs of the management interfaces, appropriate for SNMP, web-based or telnet management, with examples such as http://fcipentity.example.com:1080/ and telnet://fcipentity.example.com. fcip-discovery-domain holds the names of the discovery domains the entity belongs to.
The RFC gives three example query strings. To find a specific entity, the query is on the FCIP entity name, in the scope fcip-entity-scope-list. To find all entities in a given discovery domain, the query is on the discovery domain name. A management application that wants every entity uses no query at all, in the scope management-service-scope-list.
The template says how to write the service URL and gives four attributes: the name of the endpoint, the transports it speaks, the addresses of its management interface, and the discovery domains it belongs to.
- fcip-entity-nameThe Fibre Channel switch name, or the node name of the associated port.
- transportsThe transport protocols the entity supports. FCIP is currently supported over TCP only.
- mgmt-entityThe URLs of the management interfaces, for SNMP, web-based or telnet management.
- fcip-discovery-domainThe names of the discovery domains the entity belongs to, which control who may find it.
§6Security Considerations
The SLPv2 security model does not provide confidentiality, but it does provide a way for user agents to be sure that service advertisements come only from trusted service agents, except that it offers no way to authenticate a response that returns no results.
Once an FCIP entity has been discovered, authentication and authorisation are handled by the FCIP protocol itself. It is the responsibility of the providers of those services to make sure that an inappropriately advertised or discovered service does not compromise their security.
Without security in SLPv2, there is a risk that false discovery information is distributed. The main countermeasure is authentication. Where that risk matters, IPsec security associations should be used for FCIP traffic so that it only flows between endpoints that took part in IKE authentication. An attacker who distributes discovery information claiming to be an FCIP endpoint will lack the secrets needed to complete IKE authentication, and so will be prevented from sending or receiving FCIP traffic falsely.
A denial of service risk remains, based on repeated use of false discovery information that triggers IKE negotiation. The countermeasures are administrative configuration of each FCIP entity to limit the peers it will talk to, by IP address range or DNS domain, and a negative authentication cache that avoids repeatedly contacting an entity that fails to authenticate. The RFC states that these three measures must be implemented.
For the implementation, the RFC points to RFC 3723. IPsec is mandatory to implement for the block storage clients and servers, so all of them, including those invoking SLP, can be assumed to support it. SLP servers cannot be assumed to implement it, because standard SLP has no such requirement, and in particular a directory agent may run on a machine that runs no block storage protocol. IPsec should be implemented for SLPv2, including ESP with a non-null transform to provide both authentication and confidentiality. Because the block storage services have their own authentication capabilities once located, SLPv2 authentication is optional to implement and use.
Discovery alone proves nothing, so the FCIP protocol still authenticates the peer it connects to. The RFC asks for three defences against a flood of false adverts: restrict which peers an endpoint will talk to, cache the failures, and use IPsec.
§7Registration and Internationalization
The two SLP templates described in section 5 should be registered in the IANA SVRLOC Templates registry, following the process in the IANA considerations of RFC 2609.
On internationalization, SLP allows internationalized strings to be registered and retrieved. Attributes in the template that are not marked as literal are registered in a localized manner. An English localization must be registered, and others may be.
The two templates are registered with IANA in the registry for SLP service templates, and the English wording of the attributes is the required one.