There is this protocol called TCP that runs over IP which provides the logical connection.
Sniping at the use of vocabulary is not helpful here. You are refering to the extant architecture and so the vocaulary precisely matches the concepts you wish to refer to. I am proposing to make a few modest tweaks to the architecture. While the tweaks I propose bring it closer to the original vision of Cerf, Clark, Postel et al. I cannot explain it using the standard vocabulary.
My objective as an application designer is precisely to get to the point where the application running on top of the Internet stack can exist in blisfull ignorance of what is going on at the lower layers.
OK lets try code, at the moment to start up a TCP socket you have code of the form:
struct sockaddr_in local, mask;
SOCKET s;
local.sin_port = htons (port);
local.sin_family = AF_INET;
local.sin_addr.s_addr = inet_addr(address);
// Create a socket
s = socket (AF_INET, SOCK_STREAM, 0);
Assert (s != INVALID_SOCKET, -1, ("Could not allocate socket"));
// Bind the socket to the TCP interface and port
int b = bind(s, (struct sockaddr*)&local, sizeof(local));
Assert (b != SOCKET_ERROR, -1, ("Could not bind to socket"));
The application should not be dealling with any of this. The IP address should never be exposed to the application in any form. Same goes for the protocol.
It should be possible to define an API call of the form (again using a C idiom although one would hope to use C# or Java):
s = serve ( dns_name, service_name, profile )
s = connect ( dns_name, service_name, profile )
Where profile contains information that describes the service (protocol options, versions supported &ct.) on the serve call and those desired on the connect call. (alternatively implement via a callback structure or split connect into a resolution and connection phases)
I don't think that the application should know anything about the details of the IP level, not the port and certainly not the address.
It should be possible to implement the serve and connect API using only the information in the DNS combined with a static table of information relating to legacy protocols that use the well known port scheme.
It might be advantageous for the platform to decide to supplement that information with additional sources but that should not be visible at the application layer.
I think that this architecture is a lot more disciplined than what we have today. It observes the encapsulation property / layering principle much better.
-----Original Message-----
From: Brian E Carpenter [mailto:brc at zurich.ibm.com]
Sent: Thursday, March 08, 2007 9:57 AM
To: Hallam-Baker, Phillip
Cc: Harald Tveit Alvestrand; ietf at ietf.org
Subject: Re: DNS role (RE: NATs as firewalls, cryptography,
and curbing DDoS threats.)
Ah. Well I always learnt that an IP network was a
connectionless network. Maybe you'd like to define what you
mean by a connection.
Brian
On 2007-03-08 14:42, Hallam-Baker, Phillip wrote:
DHCP: of course not, its routing address acquisition, not
connection
initiation Default Gateway: Again no connection.
DNS server: of course, itâs a tautology that interactions
with the DNS are mediated by the DNS, but again its not
connection initiation.
The most complicated case here is SLP. The primary problem
in SLP is that it has failed to establish a sufficiently
diverse adoption community. There are four competing
protocols in the space, few signs of life in any of them.
The secondary problem in SLP is that it appears to be
grounded in the conception of the local network being the
locally contiguous network. Using multicast is in theory more
scalable than Ethernet broadcast and could take the scheme
beyond the SOHO network. In practice you have to believe in
Tinkerbell. I don't.
Since I can do everything that SLP does using the pure DNS
and an announcement service that is my preferred option. If
SLP was ubiquitously supported it would be a different matter.
Getting three out of four camps to admit that their
proposal is not likely to make it and converge on the fourth
is likely to be very difficult and the spec that wins is
probably not going to do so on technical merit. Again, its
five years since this was all promised to the consumer.
Grafting the schemas developed onto an existing
infrastructure everyone already agrees on is probably an
easier prospect politically.
-----Original Message-----
From: Brian E Carpenter [mailto:brc at zurich.ibm.com]
Sent: Thursday, March 08, 2007 5:13 AM
To: Hallam-Baker, Phillip
Cc: Harald Tveit Alvestrand; ietf at ietf.org
Subject: Re: DNS role (RE: NATs as firewalls, cryptography, and
curbing DDoS threats.)
On 2007-03-08 02:06, Hallam-Baker, Phillip wrote:
OK I will restate.
All connection initiation should be exclusively mediated
through the DNS and only the DNS.
Would that include connections to one's DHCP server, SLP server,
default gateway, and DNS server?
Hmm...
Brian
