[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Guidance needed on well known ports
While in general I would like to see this approach taken, this
particular case is a perfect example of where I think one can not
reasonably do that. The protocol is for the purpose of configuring a
router. The router that needs to be configured could easily be
between the network engineer and the DNS server. The protocol can
not rationally depend upon DNS (no matter how much I like the
elegance of removing ports, using dynamic port numbers, and using dynamic DNS.)
Yes, we could invent a better way to make things work. And maybe we should.
But Netconf should not be held up waiting for that to be developed.
Until we develop such a beast, we have to use port numbers.
Given that constraint, what guidelines ought to be used for whether a
protocol gets a port number above or below 1024?
Yours,
Joel
At 05:09 PM 3/18/2006, Hallam-Baker, Phillip wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=SHA1; boundary="----=_NextPart_000_0011_01C64AAE.C23D25B0"
The whole idea of fixed ports is broken.
The idea that there are only 1024 or even 65535 Internet applications is
broken.
The Internet has a signalling layer, the DNS. Applications should use it.
The SRV record provides an infinitely extensible mechanism for advertising
ports.
Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be
well advised to pay careful attention to that restriction. SRV ports work
just fine behind a NAT.
IANA should be told to close the well known ports registry. Applications
should use DNS SRV records for service location.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>