Application for Service Names and User Port Numbers

This form is used to register user port numbers and service names in the IANA Service Name and Transport Protocol Port Number Registry.

For detailed instructions on how to fill out the elements of this form, please read the procedures document (RFC 6335).

Please read the following before submitting your request:

  • Registration is open to any party that meets the eligibility requirements described in RFC 6335, section 8.1.2, and RFC 7605. This includes review under the "Expert Review" procedure documented in RFC 8126.
  • User port numbers range between 1024 and 49151. If you wish to register a system port — those numbered 1023 or less — it must be done through the standardisation process of the IETF. Dynamic port numbers (ranging from 49152-65535) are not assigned.
  • Assignment of a port number does not in any way imply an endorsement of an application or product, and the fact that network traffic is flowing to or from an assigned port does not mean that it is "good" traffic nor that the traffic corresponds to the assigned service. Firewall and system administrators should choose how to configure their systems based on their knowledge of the traffic in question, and any other relevant criteria.
  • A particular application or service should require at most one assigned user port number. For applications or services that offer multiple functions it is usually possible to utilize one port as a multiplexer or rendezvous service.
  • To add an additional transport protocol (TCP, UDP, SCTP or DCCP) to an existing assignment, a new template is required. The new request requires Expert Review.
  • In the Service Name and Description, avoid terms and acronyms referring to "service" and "protocol", as these are implied for all assignments. Please also avoid version-specific information, as new assignments are expected to be version-independent.
  • The entire process may take up to 1-2 months; given these are permanent changes to a limited global resource, applicants should plan accordingly. The process could take less time if the request is fully formed and all criteria are met.
  • Unassigned service names and port numbers should not be used prior to assignment. IANA will assign the service name and optionally a port number after your application has been approved.

Assignee

List the organization, company or individual person responsible for the initial assignment. If you are registering this on behalf of a company or organization, the company/organization name would go here.

See RFC 6335, section 8.1.1.
See RFC 6335, section 8.1.1.

Contact Person

The responsible person for the Internet community to send questions to. This person is also authorized to submit changes on behalf of the Assignee. In cases of conflict between the Assignee and the Contact, the Assignee decisions take precedence.

Resource Request

See RFC 6335, section 8.1.1.
See RFC 6335, section 8.1.1.
Required if DCCP is requested; leave blank otherwise. See RFC 6335, sections 8.1.1 and 10.3.
(REQUIRED, 15 character maximum) See RFC 6335, sections 5.1 and 8.1.1.
Leave blank if no preference. Note: It is inappropriate to use a port number until your application has been approved for assignment. See RFC 6335, section 8.1.1, and RFC 7605, sections 7.2 and 7.3.
See RFC 6335, section 8.1.1.
Please provide a brief and basic technical description of the protocol that will use the service name or port number, including message formats, types, sequences, functionalities, of your protocol. In addition, please address the specific questions included below to the extent possible. See RFC 6335, section 8.1.1.
The list of defined TXT record keys for this service or URL reference to document describing defined keys (see RFC 6763, section 6). Required for service names only. See RFC 6335, section 8.1.1.

Usage Questions (Required)

1) If broadcast/multicast is used, how and what for?

See RFC 7605, section 7.6.

2) If UDP is requested, please explain how traffic is limited, and whether the protocol reacts to congestion.

See RFC 7605, section 7.6, and RFC 8085. Please address RFC 8085 recommendations directly.

3) If UDP is requested, please indicate whether the service is solely for the discovery of hosts supporting this protocol.

See RFC 7605, sections 7.1, 7.2, and 7.6.

4) Please explain how your protocol supports versioning.

See RFC 7605, sections 7.1 and 7.5.

5) If your request is for more than one transport, please explain in detail how the protocol differs over each transport.

See RFC 7605, section 7.6.

6) Please describe how your protocol supports security. Note that new services are expected to support security capabilities and to avoid insecure variants.

See RFC 7605, sections 7.1, 7.4, and 8.

7) Please explain why a unique port assignment is necessary as opposed to a port in range (49152-65535) or existing port.

See RFC 7605, sections 7.1 and 7.2.

8) Please explain the state of development of your protocol.

See RFC 7605, sections 7.7 and 7.8.

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.



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, and RFC 7605, section 7.6.

11) Please provide any other information that would be helpful in understanding how this protocol differs from existing assigned services.

See RFC 7605 as a whole, but especially sections 7.2, 7.3, and 7.9.

By submitting my personal data, I agree that my personal data will be processed in accordance with our Privacy Policy and agree to abide by the website Terms of Service.

AltStyle によって変換されたページ (->オリジナル) /