Re: [MBONED] mboned: UDP port conflict mtrace/traceroute

[Joe Touch <[e-mail]>]

Hi, Warren, 

On 2019-09-11 08:27, Warren Kumari wrote:

> On Mon, Jul 29, 2019 at 1:36 PM Joe Touch <[e-mail]> wrote: 
> 
>> On 2019-07-29 10:09, Warren Kumari wrote:
>> 
>> ...
>> 
>> Just FYI, I sent email to IANA letting them know that ports 33435 -
>> 33534 should probably be listed it as "Known Unauthorized Use".
>> From some archaeology, 33434 is apparently 2^15 + 666, and the
>> "standard" traceroutes use up to 100 ports.
>> I based this on the Van Jacobson ([e-mail]) - 1988 which he
>> "stole" (credited) from Steve Deering -- easiest location of code is:
>> https://github.com/freebsd/freebsd/blob/master/contrib/traceroute/traceroute.c
>> 
>> I don't much like referring to it as "Known Unauthorized Use" but
>> that's technically what it is -- the important bit to me seems to be
>> that we make in some way so they don't get handed out, exactly what
>> they should be called is a less pressing problem.
>> 
>> Although that's helpful to those seeing traffic on those ports, it does not prevent IANA from assigning those values when requested.
>> 
>> The only way to do that would be to make them ASSIGNED. That happens by the process indicated in RFCs 6335 and 7605 and notably is not driven by this sort of "squatting".
>> 
>> NOTE: at the time that code was originally developed (1988), that range was OK for such uses without registration, but times changed in 1992.
>> 
>> That code ought to be fixed.
> 
> Yes, that is true -- that code ought to be fixed; however, it doesn't
> change the fact that mtrace cannot realistically be deployed using
> this port -- enabling it on a router breaks traceroutes through that
> router, leading to asterisks (I'd thought that we'd agreed on that,
> but while looking back through my mail on this topic, it's possible
> I'd misunderstood, and you don't actually agree that this port isn't
> fit *for this particular purpose*).

No, I don't. I don't understand the issue. On machines where traceroute
is deployed, I would assume it is already possible to acquire those
ports (bind to them) as needed, at which point the only components that
don't play nice are those where mtrace isn't deployed yet. 

Now if you are saying you don't WANT to do that because you WANT to
support traceroute's use of squatted ports, that's not IANA's business
IMO - and, more importantly, it's not justification for changing a port.
IANA's policies on this are that squatter's use of ports are simply not
a factor at all. They can't be, otherwise there's no point in having an
assignment process. 

> Just wanting to make sure we are all on the same page, and they MBONED
> will be publishing a -bis, deprecating this RFC and publishing a new
> one with a different port...

At best, that would requires releasing the current assignment, which
requires a statement as to the extent of the current deployment using
that assignment since 2012 and a plan for changing that codebase - all
this is described in RFC 6335. 

Joe