regarding IANA port assignments

Hi, all,
<IANA ports review team lead hat on>
Some points from RFCs 6335 and 7605, which define IANA port assignments, which I’d like to reiterate:
- IANA assigns ports in the registered range, from 0-49151
	As indicated in RFC 8487, IANA has assigned port 33435 to mtracev2
	That is true regardless of whether any other system “squats” on this use, i.e., uses it without assignment.
	That value was not assigned to any other party prior to its assignment to mtracev2.
IANA’s lists do NOT indicate any other assigned use to this - or any other port. Each port has one assignee. Note that there are certainly lists that claim to summarize IANA assignments, but only those at iana.org are authoritative; where others disagree, it is those other lists that are in error.
Responding in order to those on the thread:
----------------------------------
On Feb 1 and 8 Hooman said:
> IANA has assigned port 33435 for RFC 8487 mtracev2 this port also coincides with Linux unicast traceroute. Actually if you look at this UDP port in IANA you will see it for both unix trace route and mtracev2.
That is incorrect; 33435 UDP is for mtracev2; TCP is reserved and not yet assigned. 
traceroute is assigned 33434 for both UDP and TCP
> Would this cause some issues from implementation point of view? 
It could.
> Do we need to reconsider the port to be outside of Linux traceroute port range?
The opposite is true; implementations should follow IANA assignments.
It is not the prerogative of any entity other than IANA to assign ports.
---------------------------------
On Feb 18 Hitoshi said:
> Port 33435 is assigned for Mtrace v2 (UDP) and "reserved" for TCP traceroute.
That is not correct; that UDP port is assigned to mtracev2 and the TCP value is RESERVED, presumably for a TCP variant of mtracev2, but not necessarily. IANA currently assigns only those transports in active use and reserves the other(s) with priority given the current assignee (see RFC 6335). traceroute is assigned 33434
> I don't know why 33435 is separately "reserved”, 
See RFC 6335, Sec 7.2
> ...but since 33434 is officially assigned for traceroute (for both TCP and UDP), why 33435 is needed for unicast traceroute, and why linux uses it?
33435 is for mtracev2, which is not traceroute. Any systems using 33435 for traceroute are in error.
> ...Moreover, although "TCP" port 33435 is "reserved", "UDP" port 33435 is only assigned for Mtrace v2.
correct.
> There isn't any contradiction for the 33435 port assignment, IMO.
I agree.
---------------------------------
On Feb 18 Hooman then said:
> For unix a range of ports are assigned not just a single port…
That would be an implementation error - traceroute is assigned only one port by IANA.
> 33434-33523  udp traceroute incoming traceroute - under Unix-like operating systems, the traceroute utility uses User Datagram Protocol (UDP) datagrams with destination port numbers from 33434 to 33534 by default

That “default” is a bug and should be fixed.
> Under Windows, the tracert command sends ICMP requests.
FWIW, the original traceroute did that too; it sent ICMP pings (in specific) with increasing TTLs.
> I would imagine the unix traceroute would be implemented in most routers out there and mtrace v2 port 33435 is in its range. If within the software we assign port 33435 to mtrace v2 then unix trace route will fail,
That is Unix’s fault and again, should be fixed in Unix.
> ... as unix will send a its 2nd traceroute packet with udp port 33435 and will not get a response because in software it is assigned to mtrace v2 now. This is what we are seeing currently.
Then you have an opportunity to fix an error. 
<hat off>
Joe

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned