> From: Keith Moore <moore@xxxxxxxxxx>
> Regarding SRV, it's not acceptable to expect that as a condition of
> deploying a new application, every user who wishes to run that
> application be able to write to a DNS zone. Most users do not have DNS
> zones that they can write to.
Yes. Architecturally speaking, it's somewhat dubious that information which
really only needs to be localized to the host (application<->port binding)
has to be sent to the DNS.
It would be easy to run a tiny little USP "binding" server that took in an
application name (yes, we'd have to register those, but string-space is
infinite), and returned the port.
About the only reason I can see that that would not be desirable would be to
avoid an extra RTT to the do that binding lookup. (DNS/SRV solutions might
avoid this RTT too, but in that case that benefit doesn't outweigh the
costs.) The "obvious" way to do it, which is have the ICP use the strings
directly (as the CHAOS protocols did) is not really feasible now - it would
require a change to TCP.
Another option, now that I think about it, though, is a TCP option which
contained the service name - one well-known port would be the "demux port",
and which actual application you connected to would depend on the value in
the TCP option.
> Furthermore it's increasingly necessary that applications be able to
> work in environments that do not use DNS - such as ad hoc networks or
> networks that become isolated.
Also a good point.
> Probably the worst problem with destination port numbers is that there
> aren't enough of them. That's probably something that needs to be
> addressed in TCP and UDP
No, 65K is probably enough (because, recall that a single port can have
connections to hundreds of thosands of foreign ports) *provided* that we
don't have to assign a well-known port to each application.
It's the concept of well-known ports that's broken, not the provision for 65K
ports.
Noel
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf