On Wed, Jun 21, 2023 at 08:25:55PM +0000, Salz, Rich wrote:
> > No, IP addresses are not DNS names. And IP address SANs are octet
> > strings, 4 bytes for IPv4 and 16 bytes for IPv6.
>
> So I tweaked the last part of section 6.4:
> This document does not specify how an SRV-ID reference identity can include an
> IP address, as {{SRVNAME}} only defines string names, not octet identifiers
> such as an IP address.
>
> Seem reasonable?
I think it is possible to do better. The point being that an SRV-ID is
fundamentally a distinct identifier type from either DNS-ID (hostnames)
or IP-ID (IP v4/v6 addresses). It consists of a service name and a
domain name. It makes no sense to ask whether an SRV-ID can hold an IP
address, it is a distinct type:
https://datatracker.ietf.org/doc/html/rfc4985#section-2
That said, the question is perhaps whether SRV-ID is applicable to the
use of a client that, for example, is connecting to the IMAP service at
192.0.2.1 (the IP address!). Since the client does not know the
associated hostname (or cannot obtain it securely), there is no way to
formulate an associated SRV-ID. In particular:
_imap.192.0.2.1
isn't an SRV-ID that one should expect to find as a presented identifier
at the server. And IPv6 addresses would resemble DNS names even less.
If someone wants to define an address-literal + service SAN type,
perhaps:
- [192.0.2.1]:imap
- [2001:DB8::1]:imap
That'd require a new RFC, and perhaps a new associated SAN type, rather
than shoehorn a new value format into SRV-ID.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
