Vendor Extensions for Service Location Protocol, Version 2
updates
- rfc-2608 — Service Location Protocol, Version 2
Extracted elements (16)
A vendor's internal Extension Data within a Vendor Opaque Extension should include its own sub-ID field (e.g., a 1-byte ACME Ext ID) so that a single Enterprise Number can support up to 256 distinct vendor extensions, rather than being limited to one.
Three extension mechanisms are provided for SLPv2: (1) IANA-registered extension IDs via expert review (preferred, vendor-neutral); (2) experimental range 0x8000-0x8FFF (unregistered, collision risk); (3) Vendor Opaque Extension using Enterprise Numbers (collision-free, vendor-specific). The Vendor Opaque Extension is recommended over the experimental range when vendor-specific use is intended.
Vendors who wish to extend SLPv2 privately sacrifice ubiquitous automatic configuration, which is the primary benefit of a standard service discovery framework. For this reason, registration of service templates with IANA is strongly encouraged as the preferred alternative.
Vendor extensions preclude interoperation with compliant but non-extended implementations, creating a real danger of incompatibility if different implementations support different feature sets. The Vendor Opaque Extension ensures that compliant non-extended agents can safely ignore unknown vendor extensions without protocol failure.
Modification or extension of any feature of SLPv2 whatsoever, aside from those listed in Sections 3-5 (Enterprise Numbers, Naming Authorities, Vendor Defined Attributes, and Vendor Opaque Extension), requires a standards action as defined in RFC 2608.
Non-standard attribute names SHOULD begin with 'x-' followed by the vendor's Enterprise Number and a '-' to guarantee unambiguous interpretation. For example, Acme (Enterprise 9999) would use 'x-9999-cheat-mode'.
The Vendor Opaque Extension is OPTIONAL to implement. It allows a vendor to define their own extensions guaranteed to have a unique interpretation, keyed by the vendor's IANA-registered Enterprise Number.
To create a safe naming authority with no possibility of name collisions, a vendor SHOULD use their Enterprise Number as a naming authority string in SLPv2 Service Type URLs.
Vendor Extensions to SLPv2 SHOULD use Enterprise Numbers to avoid any possibility of a name space collision. Each vendor is responsible for ensuring that vendor extensions under their own authority are non-conflicting.
The Vendor Opaque Extension (Extension ID = 0x0003) embeds a 4-byte unsigned integer Enterprise Number immediately after the standard SLPv2 extension header, followed by vendor-defined Extension Data whose interpretation is determined solely by the vendor.
IANA maintains 'SMI Network Management Private Enterprise Codes' (prefix 1.3.6.1.4.1), from which vendors obtain unique Enterprise Numbers used as SLPv2 naming authorities and Vendor Opaque Extension discriminators.
The Vendor Opaque Extension ID 0x0003 is registered with IANA in the SLPv2 Extension ID registry. No new IANA action is required by this document as the ID was already registered.
The example Acme UA Authentication Extension (Section 5.2) using MD5 and a shared secret pass phrase is explicitly noted as unsuitable for production use: it requires per-UA shared secrets on all SAs and DAs, and the secret pass phrase is susceptible to a dictionary attack.
Vendor extensions may introduce additional security considerations into SLP beyond those in RFC 2608. The Vendor Opaque Extension mechanism itself is no less secure than 'private use' extensions defined in SLPv2, but vendor-defined payloads are unreviewed by the IETF community.
The generic SLPv2 extension format consists of a 2-byte Extension ID, a 3-byte Next Extension Offset (split across two words), and variable-length Extension Data. Extensions are appended at the end of SLPv2 messages.
The Vendor Opaque Extension wire format is: 2-byte Extension ID (0x0003), 3-byte Next Extension Offset, 4-byte Enterprise Number (unsigned integer), followed by variable-length Extension Data. The Enterprise Number field guarantees unambiguous vendor identification.