Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Joe, SRV records are not equivalent to either assigned or mutually-negotiated ports; they would require extra messages, extra round-trip times, and/or extra services (DNS) beyond what is currently required. Just to be clear, I am not suggesting that no assignments be done, but that SRV records be used where appropriate. If setup time or circular dependencies are a concern, SRV records may not be appropriate. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED] (2) As I understand it, for ports above 1024, the IANA does _not_ assign values - it just registers uses claimed by others. Eliminating well-known ports eliminates any assignment role, and leaves us with just a registry of what people have claimed. Note that this means there is no mechanism which prevents the same number from being registered by more than one registry. So how is a server to support two services that happen to have chosen the same port number? I think that what is indicated here is that service discovery by port number is broken and no longer scalable. There are only 65536 possible port numbers, we expect to see rather more Web Services become established. We have 10,000 registrations already. This is a failed discovery strategy. The scalable discovery strategy for the Internet is to use SRV records. For this to be possible it has to become as easy to register an SRV code point as it is currently to register a port. It makes no sense for there to be more restrictions on issue of the unlimited resource than on the limited one. Getting an SRV code point registered is not a trivial task and there is in fact a parallel non-IANA registry already operating because most people cannot be bothered to deal with the IETF process. It should not be necessary to write an RFC or go through the IESG to register a code point. The implicit assumption here is that the IESG controls the Internet through control of discovery aparatus, a silly notion that the other Internet standards bodies are not going to accept. If the W3C or OASIS develops a spec for a Web service it makes no sense for them to then be required to write an RFC and the group be required to grovel to the IESG and worse be held captive by the IESG work schedule. Not going to happen, nor does it. People who want SRVs cut in those groups just do it. I do _not_ support the introduction of a charging model, for a couple of reasons. First, I don't want to see port numbers become a politicized commodity, like IP address space and domain names have. I think this is a very bad idea at this stage. At this point introducing charging is more likely to lead to speculation and premature exhaustion of the supply. (*) Some years ago, there was a period of time lasting several months when users of a particular large network provider were unable to communicate with CMU, because that provider had usurped 128.2/16 for some private use within its network. This particular weakness with the allocation of IPv4 addresses is likely to be exercised with increasing frequency when the IPv4 address store begins to reach exhaustion. One can well imagine that a large ISP operating in Asia might decide that rather than pay an exhorbitant amount to buy another 4 million addresses it might just make a private agreement to divy up net 18 (18... = MIT) and make a private agreement with its neighboring ISPs to do so. The bad effects resulting from such practices hardly need to be stated. If we are lucky people will go for the Class D and Class E space first. But that is going to upset some people (Mbone users for instance). The governance mechanisms of the Internet assume a degree of authoritarian control that simply does not exist. It is goodwill rather than authority that keeps the Internet together. My theory (which I make no appologies for acting on) is that Vint Cerf and Jon Postel intended the mechanisms set up to control and allocate to act as the Gordian knot. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Eliot Lear wrote: Joe, SRV records are not equivalent to either assigned or mutually-negotiated ports; they would require extra messages, extra round-trip times, and/or extra services (DNS) beyond what is currently required. Just to be clear, I am not suggesting that no assignments be done, but that SRV records be used where appropriate. If setup time or circular dependencies are a concern, SRV records may not be appropriate. Right - I agree that assignments should not differentiate between privilege. SRV records serve two purposes: to unload the fixed list from IANA (like moving hosts.txt to the DNS did) and to allow local control over the map between service name and port (which can allow more than 65,000 services total). The first use is fine, but overkill IMO for a list with 65,000 entries at most. The second is a problem, for reasons explained in my I-D, because it puts control over host service offerings in the hands of whomever controls its DNS (e.g., another thing for ISPs to claim makes you a commercial customer at commercial prices) and because it's inefficient. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
From: Joe Touch [mailto:[EMAIL PROTECTED] The second is a problem, for reasons explained in my I-D, because it puts control over host service offerings in the hands of whomever controls its DNS (e.g., another thing for ISPs to claim makes you a commercial customer at commercial prices) and because it's inefficient. This is an irrelevant issue based on a premise that is absolutely and totally wrong. There is NO CHANGE OF CONTROL due to SRV, none, zip, nadda. If a party controls the DNS information for a host it controls all name based inbound connections to that host absolutely and irrevocably. Devolving additional functions to the DNS does not entail any change of control because that control is already lost. If I control example.com I control the inbound email, web, ftp services. If you are binding to a raw IP address then SRV is not exactly going to be very relevant in any case is it? The Internet is the DNS, the IP based packet transport is mere plumbing. If someone wants to be a first class citizen on the Internet they have to own and control their own DNS service. Otherwise they can have no meaningful control or security. DNS names are not free but they are exceptionaly cheap. If you want to put up some service and your ISP refuses to allow you control of the DNS there are plenty of DNS service providers who will be happy to help. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Hallam-Baker, Phillip wrote: From: Joe Touch [mailto:[EMAIL PROTECTED] The second is a problem, for reasons explained in my I-D, because it puts control over host service offerings in the hands of whomever controls its DNS (e.g., another thing for ISPs to claim makes you a commercial customer at commercial prices) and because it's inefficient. This is an irrelevant issue based on a premise that is absolutely and totally wrong. There is NO CHANGE OF CONTROL due to SRV, none, zip, nadda. If a party controls the DNS information for a host it controls all name based inbound connections to that host absolutely and irrevocably. The DNS controls the IP address; ISPs aren't reluctant to control the forward DNS lookup for an IP address, even when transient. Were the DNS to control the services available, customers would be at the mercy of their ISP to make new services widely available. ISPs already want to control that using port filtering. ... If someone wants to be a first class citizen on the Internet they have to own and control their own DNS service. How so? What defines first-class? All they really need is: - stable IP addresses - stable matching forward and reverse DNS entries - a lack of port filtering If they want control over their DNS name, they also need: - control over their IP address's reverse DNS entry Relying on SRV records puts more control in the DNS. While that may not matter much for users managing their own DNS*, it does matter a LOT for the five 9's of the rest of us who don't. DNS names are not free but they are exceptionaly cheap. If you want to put up some service and your ISP refuses to allow you control of the DNS there are plenty of DNS service providers who will be happy to help. That assumes the applications lookup the service name on the DNS name, rather than the IP address. The former may have multiple IP addresses with different service name:port bindings; the latter is more appropriate, IMO. That then results in dependence on the DNS under the control of the ISP - since they're unlikely to delegate the control of a single reverse entry to you. And 5 9's of users may want or need services (e.g., some OS diagnostics rely on web servers running on your host), but they're not about to run setup a DNS server, regardless of how inexpensive. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
From: Joe Touch [mailto:[EMAIL PROTECTED] Hallam-Baker, Phillip wrote: From: Joe Touch [mailto:[EMAIL PROTECTED] The second is a problem, for reasons explained in my I-D, because it puts control over host service offerings in the hands of whomever controls its DNS (e.g., another thing for ISPs to claim makes you a commercial customer at commercial prices) and because it's inefficient. This is an irrelevant issue based on a premise that is absolutely and totally wrong. There is NO CHANGE OF CONTROL due to SRV, none, zip, nadda. If a party controls the DNS information for a host it controls all name based inbound connections to that host absolutely and irrevocably. The DNS controls the IP address; ISPs aren't reluctant to control the forward DNS lookup for an IP address, even when transient. Mine is, I have no forward DNS pointing to my machine at all from my bandwidth provider. You do not have to use the DNS service provided by your ISP, if you do they control you. Were the DNS to control the services available, customers would be at the mercy of their ISP to make new services widely available. ISPs already want to control that using port filtering. You are confusing politics with technology and making a hash of both. You do not have to use the DNS service provided by your ISP. Regardless of whether you do or not their ability to filter services is far greater under the port allocation scheme you champion than under a DNS centric model. If the evil service is on port 666 it is a trivial matter to block it, not so if the evil service is being managed by an independent DNS service provider who maps the SRV record to a port that the ISP has not blocked. ... If someone wants to be a first class citizen on the Internet they have to own and control their own DNS service. How so? What defines first-class? All they really need is: - stable IP addresses - stable matching forward and reverse DNS entries - a lack of port filtering No you need to control your own name. Unless you can do that you are a serf. That is why it is better to be hallam-baker.com rather than hallam-baker.blogspot.com. Unless you own the DNS name you are permanently at the mercy of the owner of blogspot.com. If their conditions of service change in ways that are unfavorable to you you have no recourse. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Hallam-Baker, Phillip wrote: ... You are confusing politics with technology and making a hash of both. I would encourage you to review the doc; it discusses the details of the differences in technical terms. I'll refrain from repeating them here. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED] (2) As I understand it, for ports above 1024, the IANA does _not_ assign values - it just registers uses claimed by others. Eliminating well-known ports eliminates any assignment role, and leaves us with just a registry of what people have claimed. Note that this means there is no mechanism which prevents the same number from being registered by more than one registry. So how is a server to support two services that happen to have chosen the sam e port number? I think that what is indicated here is that service discovery by port number is broken and no longer scalable. There are only 65536 possible port numbers, we expect to see rather more Web Services become established. We have 10,000 registrations already. This is a failed discovery strategy. The scalable discovery strategy for the Internet is to use SRV records. For t his to be possible it has to become as easy to register an SRV code point as it is currently to register a port. It makes no sense for there to be more re strictions on issue of the unlimited resource than on the limited one. Getting an SRV code point registered is not a trivial task and there is in fa ct a parallel non-IANA registry already operating because most people cannot be bothered to deal with the IETF process. It should not be necessary to writ e an RFC or go through the IESG to register a code point. The implicit assump tion here is that the IESG controls the Internet through control of discovery aparatus, a silly notion that the other Internet standards bodies are not go ing to accept. There was never any intention of making getting SRV labels hard. The reason for the RFC was to handle *existing* protocols and to handle protocols which wished to use the fields in a non standard manner. Retrofiting SRV usage into a existing protocol is not straight forward. http://www.watersprings.org/pub/id/draft-andrews-http-srv-01.txt is a attempt to retrofit SRV into HTTP. Designing a new protocol to use SRV should be straight forward. I would expect it to be about 1 paragraph in the new protocol's description. If the W3C or OASIS develops a spec for a Web service it makes no sense for t hem to then be required to write an RFC and the group be required to grovel t o the IESG and worse be held captive by the IESG work schedule. Not going to happen, nor does it. People who want SRVs cut in those groups just do it. I do _not_ support the introduction of a charging model, for a couple of reasons. First, I don't want to see port numbers become a politicized commodity, like IP address space and domain names have. I think this is a very bad idea at this stage. At this point introducing char ging is more likely to lead to speculation and premature exhaustion of the su pply. (*) Some years ago, there was a period of time lasting several months when users of a particular large network provider were unable to communicate with CMU, because that provider had usurped 128.2/16 for some private use within its network. This particular weakness with the allocation of IPv4 addresses is likely to b e exercised with increasing frequency when the IPv4 address store begins to r each exhaustion. One can well imagine that a large ISP operating in Asia might decide that rat her than pay an exhorbitant amount to buy another 4 million addresses it migh t just make a private agreement to divy up net 18 (18... = MIT) and make a pr ivate agreement with its neighboring ISPs to do so. The bad effects resulting from such practices hardly need to be stated. If we are lucky people will go for the Class D and Class E space first. But that i s going to upset some people (Mbone users for instance). The governance mechanisms of the Internet assume a degree of authoritarian co ntrol that simply does not exist. It is goodwill rather than authority that k eeps the Internet together. My theory (which I make no appologies for acting on) is that Vint Cerf and Jo n Postel intended the mechanisms set up to control and allocate to act as the Gordian knot. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Eliot Lear wrote: Jeff, Disclaimer - I wasn't even aware of this document before reading this thread. However, I have now read it, so feel prepared to comment. As it only just came out, you haven't missed much of a debate. (1) The IANA is a group of adults, but it is no longer a group of protocol subject matter experts. IMHO there is probably no need for IESG oversight of port number allocation, especially if we are eliminating the (artificial) scarcity of so-called well-known ports. The point of the document is NOT really to deal with scarcity but to deal with an outdated process, and to attempt to encourage use of SRV records where appropriate, and to have some documentation for the port use. ... SRV records are not equivalent to either assigned or mutually-negotiated ports; they would require extra messages, extra round-trip times, and/or extra services (DNS) beyond what is currently required. There are other ways to reduce the limits of the current port space, as well as to reduce the dual-registration of service names (which are unique) and port numbers. See: draft-touch-tcp-portnames-00.txt (FYI there is a pending update that includes more detail on the difference between this and Tim Shepard's dynamic port reassignment proposal from 2004) Further discussion on this has already ensued on the TCPM WG mailing list, whose archives may be a useful resource as well. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Jeff, Disclaimer - I wasn't even aware of this document before reading this thread. However, I have now read it, so feel prepared to comment. As it only just came out, you haven't missed much of a debate. (1) The IANA is a group of adults, but it is no longer a group of protocol subject matter experts. IMHO there is probably no need for IESG oversight of port number allocation, especially if we are eliminating the (artificial) scarcity of so-called well-known ports. The point of the document is NOT really to deal with scarcity but to deal with an outdated process, and to attempt to encourage use of SRV records where appropriate, and to have some documentation for the port use. The charging aspect is something that should be explored really only as a means for encouraging people to document use via a normative persistent reference. And so... I do _not_ support the introduction of a charging model, for a couple of reasons. First, I don't want to see port numbers become a politicized commodity, like IP address space and domain names have. I do not think the draft calls for politicization. All it calls for is documentation. Failing documentation you might get charged a modest tax by the IANA for them to keep track of whether the port is still in use. Second, I believe that having a complete, accurate registry of port numbers is highly valuable. If there is a charge to register a port, and a recurring charge to maintain a registration, then no one will register their ports for private or vendor-specific use and/or minor protocols. That means that they won't be known to network administrators or network traffic analysis tools, and people looking for an unused port - even if they intend to register and pay for it - will have a difficult time finding one that is actually free. It also means that registrations will tend to disappear over time, such that valuable historical information is lost. The registry isn't accurate today. And traffic analysis tools really can't do much with a protocol that isn't documented. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Disclaimer - I wasn't even aware of this document before reading this thread. However, I have now read it, so feel prepared to comment. On Wednesday, May 24, 2006 03:11:29 PM +0200 Eliot Lear [EMAIL PROTECTED] wrote: Yes, the distinction between well known ports and just assigned ports is outdated. The overarching theme of the document is that the IANA should be treated as a group of adults and that they should use some discretion with oversight only where needed. Careful here... (1) The IANA is a group of adults, but it is no longer a group of protocol subject matter experts. IMHO there is probably no need for IESG oversight of port number allocation, especially if we are eliminating the (artificial) scarcity of so-called well-known ports. (2) As I understand it, for ports above 1024, the IANA does _not_ assign values - it just registers uses claimed by others. Eliminating well-known ports eliminates any assignment role, and leaves us with just a registry of what people have claimed. Note that this means there is no mechanism which prevents the same number from being registered by more than one registry. That said, I support the elimination of well-known ports and transformation of the port number registry into a flat registry in which all ports are basically considered equal. I do _not_ support the introduction of a charging model, for a couple of reasons. First, I don't want to see port numbers become a politicized commodity, like IP address space and domain names have. Second, I believe that having a complete, accurate registry of port numbers is highly valuable. If there is a charge to register a port, and a recurring charge to maintain a registration, then no one will register their ports for private or vendor-specific use and/or minor protocols. That means that they won't be known to network administrators or network traffic analysis tools, and people looking for an unused port - even if they intend to register and pay for it - will have a difficult time finding one that is actually free. It also means that registrations will tend to disappear over time, such that valuable historical information is lost. A charging model works for domain names because they have to appear in a central registry or they don't work. It works for IP addresses, mostly(*), because if two unrelated networks publish routes for the same address space, each of them loses some of the time, and no one wants to lose. It won't work for port numbers because only very widely-deployed protocols need port numbers that aren't in use by _anything_ else. (*) Some years ago, there was a period of time lasting several months when users of a particular large network provider were unable to communicate with CMU, because that provider had usurped 128.2/16 for some private use within its network. We were Not Amused(tm), and had quite a time getting it fixed. And that was in the days when you could usually look up a network in the internic whois server, then pick up the phone and reach someone who actually understood something about his network. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
--On Wednesday, 24 May, 2006 19:06 -0400 Jeffrey Hutzelman [EMAIL PROTECTED] wrote: Disclaimer - I wasn't even aware of this document before reading this thread. However, I have now read it, so feel prepared to comment. ... (2) As I understand it, for ports above 1024, the IANA does _not_ assign values - it just registers uses claimed by others. Eliminating well-known ports eliminates any assignment role, and leaves us with just a registry of what people have claimed. Note that this means there is no mechanism which prevents the same number from being registered by more than one registry. This is not correct. They do, indeed, assign values. They also apply some minimal rules in doing so. Squatting on unassigned values, while it does happen, is considered to be in bad taste. Second, I believe that having a complete, accurate registry of port numbers is highly valuable. If there is a charge to register a port, and a recurring charge to maintain a registration, then no one will register their ports for private or vendor-specific use and/or minor protocols. That means that they won't be known to network administrators or network traffic analysis tools, and people looking for an unused port - even if they intend to register and pay for it - will have a difficult time finding one that is actually free. It also means that registrations will tend to disappear over time, such that valuable historical information is lost. ... FWIW, I tend to agree. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Hi, On May 24, 2006, at 4:06 PM, Jeffrey Hutzelman wrote: On Wednesday, May 24, 2006 03:11:29 PM +0200 Eliot Lear [EMAIL PROTECTED] wrote: Yes, the distinction between well known ports and just assigned ports is outdated. The overarching theme of the document is that the IANA should be treated as a group of adults Heh. :-) and that they should use some discretion with oversight only where needed. Careful here... (1) The IANA is a group of adults, but it is no longer a group of protocol subject matter experts. IMHO there is probably no need for IESG oversight of port number allocation, especially if we are eliminating the (artificial) scarcity of so-called well-known ports. The scarcity of ports is not artificial. There are only 16 bits of port space and changing the number of bits in ports will be ... interesting. (2) As I understand it, for ports above 1024, the IANA does _not_ assign values - it just registers uses claimed by others. This is not accurate. The IESG has been explicit in that IANA assigns port numbers (both well known and user), it does not register use. Second, I believe that having a complete, accurate registry of port numbers is highly valuable. As do I. It does not currently exist. That means that they won't be known to network administrators or network traffic analysis tools, Of course, the port registry does nothing to stop any protocol using any port. It might be useful to figure out what function folks expect the IANA port registry to perform. Rgds, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Hi, On May 24, 2006, at 6:16 PM, John C Klensin wrote: This is not correct. They do, indeed, assign values. Yes. They also apply some minimal rules in doing so. IANA does a basic sanity check and if there is any question as to whether a port should be allocated, we pass the request to an IESG Designated Expert who says yes or no. Squatting on unassigned values, while it does happen, is considered to be in bad taste. It is often disappointing to folks who have gone to the trouble to obtain a port to find out that nothing stops someone else from using the same port for a different protocol. Rgds, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
