So, I picked 6789 way back in commit
dc38de9b14c5386f9f446124ca6d6673eb8a1e20 because it was unused according
to nmap-services. It's there now, in use by smc-https (whatever that is),
and says it was registered in 2002. I guess the nmap-services file I
looked at at the time was out of date?
In any case, if we want an IANA assigned number, we'll need to change it.
We should be able to make a transition reasonably painless by making
clients try both ports when none is specified for some period.
I'm assuming it's worth the effort... what do you think?
sage
--- Begin Message ---
Dear Sage Weil:
Thank you for submitting this application. We have one question regarding
the proposed port number:
Desired Port Number: [6789]
You explained that you've been using the number for years:
8. Please explain the state of development of your protocol.
[The protocol was initially developed in the 2008-2010 timeframe and has been deployed in production systems for the last 3-4 years. The existing protocol versioning and other features have proven effective to handle all of the protocol and system changes we have dealt with over that period.]
This port number has already been assigned to other service, so you need
to pick another number. As noted in the online template form, unassigned
service names and port numbers should not be used prior to assignment.
When we receive your reply, we can continue the processing of the request.
Thank you,
Pearl Liang
ICANN
On Mon Apr 27 21:58:40 2015, sage@xxxxxxxxxxxx wrote:
>
> Application for a Port Number and/or Service Name
>
> Assignee: Sage Weil <sage@xxxxxxxxxxxx>
> Contact Person: Sage Weil <sage@xxxxxxxxxxxx>
>
> Resource Request:
>
> [x] Port Number
> [x] Service Name
>
> Transport Protocols:
> [x] TCP
> [ ] UDP
> [ ] SCTP
> [ ] DCCP
>
> Service Code: []
> Service Name: [ceph]
> Desired Port Number: [6789]
> Description: [Ceph monitor]
>
> Reference:
> [The Ceph storage cluster monitor daemon runs on a known port and is
> responsible for orchestrating and arbitrating access to Ceph storage
> services. All other components of the system use dynamically port
> numbers and do not require a fixed assignment.
>
> The protocol is a TCP based message passing protocol.]
>
> Defined TXT Keys:
>
> 1. If broadcast/multicast is used, how and what for?
> [n/a]
>
> 2. If UDP is requested, please explain how traffic is limited, and
> whether the
> protocol reacts to congestion.
> [n/a]
>
> 3. If UDP is requested, please indicate whether the service is solely
> for the discovery of hosts supporting this protocol.
> [n/a]
>
> 4. Please explain how your protocol supports versioning.
> [There is an initial handshake that includes protocol feature bits
> supported. After the exchange either end can choose to adjust the
> format of subsequent message accordingly (e.g., for backward
> compatibility), adjust its behavior, or opt to disconnect entirely
> with an error message.]
>
> 5. If your request is for more than one transport, please explain in
> detail how the protocol differs over each transport.
> [n/a]
>
> 6. Please describe how your protocol supports security. Note that
> presently
> there is no IETF consensus on when it is appropriate to use a
> second port
> for an insecure version of a protocol.
> [Part of the early handshake with monitors provides for mutual
> authentication of client and server using a shared secret. The client
> is then provided capabilities that are used when interacting with
> other Ceph services in the system. The overall model is based on
> Kerberos and uses a similar cryptographic scheme.]
>
> 7. Please explain why a unique port assignment is necessary as
> opposed to a
> port in range (49152-65535) or existing port.
> [The Ceph monitor is the only service in the system that runs on a
> fixed port as it is used for initial client authentication and to
> learn the addresses of other services in the cluster (which all
> dynamically allocate ports within a range).]
>
> 8. Please explain the state of development of your protocol.
> [The protocol was initially developed in the 2008-2010 timeframe and
> has been deployed in production systems for the last 3-4 years. The
> existing protocol versioning and other features have proven effective
> to handle all of the protocol and system changes we have dealt with
> over that period.]
>
> 9. If SCTP is requested, is there an existing TCP and/or UDP service
> name or
> port number assignment? If yes, provide the existing service name
> and port number.
> [n/a]
>
> 10. What specific SCTP capability is used by the application such
> that a
> user who has the choice of both TCP (and/or UDP) and SCTP ports
> for
> this application would choose SCTP? See RFC 4960 section 7.1.
> [n/a]
>
> 11. Please provide any other information that would be helpful in
> understanding how this protocol differs from existing assigned
> services.
> []
--- End Message ---
