Service Lists

The LS2 proposal 123 [Prop123] defined 'service records' that indicated a destination was participating in a global service. The floodfills would aggregate these records into global 'service lists'. This was never implemented due to complexity, lack of authentication, security, and spamming concerns.

This proposal is different in that it provides lookup for a service for a specific destination, not a global pool of destinations for some global service.

GNS

GNS [GNS] proposes that everybody runs their own DNS server. This proposal is complementary, in that we could use service records to specify that GNS (or DNS) is supported, with a standard service name of "domain" on port 53.

Dot well-known

In [DOTWELLKNOWN] it is proposed that services be looked up via an HTTP request to /.well-known/i2pmail.key. This requires that every service must have a related website to host the key. Most users do not run websites.

One workaround is that we could presume that a service for a b32 address is actually running on that b32 address. So that looking for the service for example.i2p requires the HTTP fetch from http://example.i2p/.well-known/i2pmail.key, but a service for aaa...aaa.b32.i2p does not require that lookup, it can just connect directly.

But there's an ambiguity there, because example.i2p can also be addressed by its b32.

MX Records

SRV records are simply a generic version of MX records for any service. "_smtp._tcp" is the "MX" record. There is no need for MX records if we have SRV records, and MX records alone does not provide a generic record for any service.

LS2 Option Specification

Defined as follows:

• serviceoption := optionkey optionvalue
• optionkey := _service._proto
• service := The symbolic name of the desired service. Must be lower case. Example: "smtp". Allowed chars are [a-z0-9-] and must not start or end with a '-'. Standard identifiers from [REGISTRY] or Linux /etc/services must be used if defined there.
• proto := The transport protocol of the desired service. Must be lower case, either "tcp" or "udp". "tcp" means streaming and "udp" means repliable datagrams. Protocol indicators for raw datagrams and datagram2 may be defined later. Allowed chars are [a-z0-9-] and must not start or end with a '-'.
• optionvalue := self | srvrecord[,srvrecord]*
• self := "0" ttl port [appoptions]
• srvrecord := "1" ttl priority weight port target [appoptions]
• ttl := time to live, integer seconds. Positive integer. Example: "86400". A minimum of 86400 (one day) is recommended, see Recommendations section below for details.
• priority := The priority of the target host, lower value means more preferred. Non-negative integer. Example: "0" Only useful if more than one record, but required even if just one record.
• weight := A relative weight for records with the same priority. Higher value means more chance of getting picked. Non-negative integer. Example: "0" Only useful if more than one record, but required even if just one record.
• port := The I2CP port on which the service is to be found. Non-negative integer. Example: "25" Port 0 is supported but not recommended.
• target := The hostname or b32 of the destination providing the service. A valid hostname as in [NAMING]. Must be lower case. Example: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p" or "example.i2p". b32 is recommended unless the hostname is "well known", i.e. in official or default address books.
• appoptions := arbitrary text specific to the application, must not contain " " or ",". Encoding is UTF-8.

Service Name Registry

Non-standard identifiers that are not listed in [REGISTRY] or Linux /etc/services may be requested and added to the common structures specification [LS2].

Service-specific appoptions formats may also be added there.

I2CP Specification

The [I2CP] protocol may need to be extended to support service lookups; or, maybe, just do a lookup for "_service._proto.xxx.b32.i2p" and the router figures it out. But no way to pass ttl and port back without changes. See Recommendations section below.

Additional MessageStatusMessage and/or HostReplyMessage error codes related to service lookup may be required and must be added to the [I2CP] document.

Configuration is implementation-dependent. We may define standard I2CP options for i2ptunnel and SAM, to be documented in [I2CP-OPTIONS].

TODO

SAM Specification

The [SAMv3] protocol may need to be extended to support service lookups; or, maybe, just do a lookup for "_service._proto.xxx.b32.i2p" and the router figures it out. But no way to pass ttl and port back without changes. See Recommendations section below.

TODO

Naming Specification

Update [NAMING] to specify handling of hostnames starting with '_', as documented in the implementation section below.

Recursive Lookups

It may be desirable to support recursive lookups, where each successive leaseset is checked for a service record pointing to another leaseset, DNS-style. This is probably not necessary, at least in an initial implementation.

TODO

Application-specific fields

It may be desirable to have application-specific data in the service record. For example, the operator of example.i2p may wish to indicate that email should be forwarded to example@mail.i2p. The "example@" part would need to be in a separate field of the service record, or stripped from the target.

Even if the operator runs his own email service, he may wish to indicate that email should be sent to example@example.i2p. Most I2P services are run by a single person. So a separate field may be helpful here as well.

TODO how to do this in a generic way

Changes required for Email

Out of the scope of this proposal. See [DOTWELLKNOWN] for a discussion.