Re: [tae] The Great Naming Debate (was Re: The internet architecture)
Hallam-Baker, Phillip wrote: 10.1.2.3 is simply a string litteral that may be used in place of a DNS name. In neither case should the application require knowledge of the IP address itself. In fact you don't want that as at some point in the distant future, 10.1.2.3 is actually going to map to an IPv6 address, not an IPv4 address. While I take your point in general, I do think it should be pointed out that DNS names are resolved prior to connection establishment through a directory lookup, while addresses are routed. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: The Great Naming Debate (was Re: The internet architecture)
Two points 1) Let us bury the idea that more parts reduces reliability. If anyone thinks that they do not understand the function of TCP and should go and read some basic networking architecture texts. TCP + IP is more reliable than IP. Ergo it is entirely possible to onfigure a service such that DNS + TCP + IP is more reliable than TCP + IP. It is also possible to design systems such that more layers create less reliability. 2) From an application point of view example.com and 10.1.2.3 may both be regarded as names. They are both rendered as an ascii/unicode string. They both require translation into IP format. 10.1.2.3 is simply a string litteral that may be used in place of a DNS name. In neither case should the application require knowledge of the IP address itself. In fact you don't want that as at some point in the distant future, 10.1.2.3 is actually going to map to an IPv6 address, not an IPv4 address. From: ietf-boun...@ietf.org on behalf of Bryan Ford Sent: Sun 12/14/2008 2:51 PM To: Keith Moore Cc: t...@ietf.org; ietf@ietf.org Subject: The Great Naming Debate (was Re: The internet architecture) So, after being distracted by OSDI last week, I'm now trying to catch up on the raging debates on TAE that are already exceeding all the wildest dreams I had before setting up the list... :) On the issue of weaning applications (and potentially transports) away from IP addresses in favor of names of some kind, I feel that a lot of the disagreement results from a misunderstanding of exactly what I (and perhaps others who have made similar proposals) was proposing... On Dec 4, 2008, at 10:29 PM, Keith Moore wrote: Hallam-Baker, Phillip wrote: I am trying to parse this claim. Are you saying that the DNS is fragile and raw IP relatively robust? DNS is layered on top of IP. So for a large class of IP failures, DNS won't work either. And if IP routing fails, DNS is likely to be irrelevant because the application using DNS won't work anyway. And in practice, DNS is quite likely to fail due to configuration errors, inadequate provisioning, outdated cache entries due to unanticipated changes, brain-damaged DNS caches built into NATs, failure of registries to transfer a DNS name in a timely fashion, etc. So it's not a question of whether DNS is less reliable than IP (it is), or even whether the reliability of DNS + IP is less than that of IP alone (it is). It's a question of whether increasing reliance on DNS by trying to get apps and other things to use DNS names exclusively, makes those apps and other things less reliable. And I'd argue that it does, except perhaps in a world where renumbering happened frequently, at irregular intervals, and without notice. And I don't think that's a realistic scenario. I entirely agree in principle with your concerns about reliability: if everything has to work correctly in two layers (DNS and IP), then that's strictly less likely to happen than hoping everything will work correctly in only one layer (just IP) - unless DNS can somehow make up for unreliability in the IP layer, which it occasionally might be able to do with some effort (e.g., via DNS-based load balancers that take end-to-end IP reachability information as input), but it usually doesn't because that's not the purpose of DNS. And I agree that some applications (and some users) sometimes need to deal with IP addresses directly, and probably still will need to for a long time, maybe forever. You seem to be assuming that my proposal was to disallow such visibility into the network entirely, but that wasn't my intent at all. I just would like it to become no longer _mandatory_ for every application to know about the structure IP addresses in order to accomplish anything. To be specific, there are (at least) three positions we might be in: 1. ALL applications MUST know about IP addresses, in each IP address format that exists, in order to operate at all. This is the current state of the world for applications that use the sockets API, because apps have to call gethostbyname etc. and copy the resulting IP address(es) into sockaddr_in or sockaddr_in6 structs to pass to connect() et al. Even though the sockets API is generic in that it supports multiple address families, its design forces the application to have code specific to each family in order to support that family at all, which is the key problem. 2. ALL applications MUST use only DNS names for all operations, and never provide or see IP addresses for any reason. This seems to be what you're assuming I'm suggesting (i.e., where you say ...by trying to get apps and other things to use DNS names exclusively). That's a world we might hold up as an ideal to strive for eventually, but it's indeed not realistic in the short term, and it's not what I'm pushing for. Besides, there may be many different naming or host identity
Re: [tae] The Great Naming Debate (was Re: The internet architecture)
Hallam-Baker, Phillip wrote: So to be strictly accurate here, applications deal in names, some of which are DNS names and some of which are IP address litterals. But an 'end user' application only deals in names. how many people are pure end users who never need their tools to be able to deal with IP address literals? nobody that I know of. even naive users who don't understand what IP addresses do, need for their apps to be able to deal with them for the cases where things break. for instance, when the external network connection goes down and they still want to be able to talk to their printers. [*] actually the vast majority of users that I know of do occasionally deal with IP addresses directly. and many of these guys aren't computer scientists or techies of any sort. again, this is not only hopelessly naive, it's harmful. you're trying to build a system that's even more broken than what we have now. we're a very long way from knowing how to build a naming system that works so reliably and transparently that we can completely hide IP addresses from users. Keith [*] and yeah, I know about LLMNR and even use it occasionally, but it also breaks when you take your laptop on the road and still want to be able to print to the printer at home. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
The Great Naming Debate (was Re: The internet architecture)
So, after being distracted by OSDI last week, I'm now trying to catch up on the raging debates on TAE that are already exceeding all the wildest dreams I had before setting up the list... :) On the issue of weaning applications (and potentially transports) away from IP addresses in favor of names of some kind, I feel that a lot of the disagreement results from a misunderstanding of exactly what I (and perhaps others who have made similar proposals) was proposing... On Dec 4, 2008, at 10:29 PM, Keith Moore wrote: Hallam-Baker, Phillip wrote: I am trying to parse this claim. Are you saying that the DNS is fragile and raw IP relatively robust? DNS is layered on top of IP. So for a large class of IP failures, DNS won't work either. And if IP routing fails, DNS is likely to be irrelevant because the application using DNS won't work anyway. And in practice, DNS is quite likely to fail due to configuration errors, inadequate provisioning, outdated cache entries due to unanticipated changes, brain-damaged DNS caches built into NATs, failure of registries to transfer a DNS name in a timely fashion, etc. So it's not a question of whether DNS is less reliable than IP (it is), or even whether the reliability of DNS + IP is less than that of IP alone (it is). It's a question of whether increasing reliance on DNS by trying to get apps and other things to use DNS names exclusively, makes those apps and other things less reliable. And I'd argue that it does, except perhaps in a world where renumbering happened frequently, at irregular intervals, and without notice. And I don't think that's a realistic scenario. I entirely agree in principle with your concerns about reliability: if everything has to work correctly in two layers (DNS and IP), then that's strictly less likely to happen than hoping everything will work correctly in only one layer (just IP) - unless DNS can somehow make up for unreliability in the IP layer, which it occasionally might be able to do with some effort (e.g., via DNS-based load balancers that take end-to-end IP reachability information as input), but it usually doesn't because that's not the purpose of DNS. And I agree that some applications (and some users) sometimes need to deal with IP addresses directly, and probably still will need to for a long time, maybe forever. You seem to be assuming that my proposal was to disallow such visibility into the network entirely, but that wasn't my intent at all. I just would like it to become no longer _mandatory_ for every application to know about the structure IP addresses in order to accomplish anything. To be specific, there are (at least) three positions we might be in: 1. ALL applications MUST know about IP addresses, in each IP address format that exists, in order to operate at all. This is the current state of the world for applications that use the sockets API, because apps have to call gethostbyname etc. and copy the resulting IP address(es) into sockaddr_in or sockaddr_in6 structs to pass to connect() et al. Even though the sockets API is generic in that it supports multiple address families, its design forces the application to have code specific to each family in order to support that family at all, which is the key problem. 2. ALL applications MUST use only DNS names for all operations, and never provide or see IP addresses for any reason. This seems to be what you're assuming I'm suggesting (i.e., where you say ...by trying to get apps and other things to use DNS names exclusively). That's a world we might hold up as an ideal to strive for eventually, but it's indeed not realistic in the short term, and it's not what I'm pushing for. Besides, there may be many different naming or host identity schemes we might eventually want to support besides DNS names - e.g., UIA personal names, HIP cryptographic host identities, ... 3. Applications MAY be aware of IP addresses if they need to be for whatever reason, but aren't ALWAYS forced to have hard-coded dependencies on the existence and structure of IP addresses by the API's design. Applications see IP addresses as variable-length string blobs of some kind - e.g., along the lines Florian Weimer suggested in another message. Applications can parse/interpret or create these blobs if they want/need to, but don't necessarily have to if they're just passing the blob through from the GUI or URL parser to the OS's protocol stack. This is the position I think we need to be pushing for. In short, I don't think either the current fascist extreme of an IP- address-only API or the opposite fascist extreme of a DNS-name-only protocol stack is very appealing; we need an environment in which different kinds of names/addresses/identities can coexist. You'll still be able to enter an IPv4 or IPv6 address instead of a host name when you need to, and applications will be
Re: The Great Naming Debate (was Re: The internet architecture)
This is a very anal retentive discussion your all having here. I support Ford here. Applications should be able to use names and IP addresses. We don't need the IP or DNS gestapo taking over application programs. regards joe baptista On Sun, Dec 14, 2008 at 2:51 PM, Bryan Ford brynosau...@gmail.com wrote: So, after being distracted by OSDI last week, I'm now trying to catch up on the raging debates on TAE that are already exceeding all the wildest dreams I had before setting up the list... :) On the issue of weaning applications (and potentially transports) away from IP addresses in favor of names of some kind, I feel that a lot of the disagreement results from a misunderstanding of exactly what I (and perhaps others who have made similar proposals) was proposing... On Dec 4, 2008, at 10:29 PM, Keith Moore wrote: Hallam-Baker, Phillip wrote: I am trying to parse this claim. Are you saying that the DNS is fragile and raw IP relatively robust? DNS is layered on top of IP. So for a large class of IP failures, DNS won't work either. And if IP routing fails, DNS is likely to be irrelevant because the application using DNS won't work anyway. And in practice, DNS is quite likely to fail due to configuration errors, inadequate provisioning, outdated cache entries due to unanticipated changes, brain-damaged DNS caches built into NATs, failure of registries to transfer a DNS name in a timely fashion, etc. So it's not a question of whether DNS is less reliable than IP (it is), or even whether the reliability of DNS + IP is less than that of IP alone (it is). It's a question of whether increasing reliance on DNS by trying to get apps and other things to use DNS names exclusively, makes those apps and other things less reliable. And I'd argue that it does, except perhaps in a world where renumbering happened frequently, at irregular intervals, and without notice. And I don't think that's a realistic scenario. I entirely agree in principle with your concerns about reliability: if everything has to work correctly in two layers (DNS and IP), then that's strictly less likely to happen than hoping everything will work correctly in only one layer (just IP) - unless DNS can somehow make up for unreliability in the IP layer, which it occasionally might be able to do with some effort (e.g., via DNS-based load balancers that take end-to-end IP reachability information as input), but it usually doesn't because that's not the purpose of DNS. And I agree that some applications (and some users) sometimes need to deal with IP addresses directly, and probably still will need to for a long time, maybe forever. You seem to be assuming that my proposal was to disallow such visibility into the network entirely, but that wasn't my intent at all. I just would like it to become no longer _mandatory_ for every application to know about the structure IP addresses in order to accomplish anything. To be specific, there are (at least) three positions we might be in: 1. ALL applications MUST know about IP addresses, in each IP address format that exists, in order to operate at all. This is the current state of the world for applications that use the sockets API, because apps have to call gethostbyname etc. and copy the resulting IP address(es) into sockaddr_in or sockaddr_in6 structs to pass to connect() et al. Even though the sockets API is generic in that it supports multiple address families, its design forces the application to have code specific to each family in order to support that family at all, which is the key problem. 2. ALL applications MUST use only DNS names for all operations, and never provide or see IP addresses for any reason. This seems to be what you're assuming I'm suggesting (i.e., where you say ...by trying to get apps and other things to use DNS names exclusively). That's a world we might hold up as an ideal to strive for eventually, but it's indeed not realistic in the short term, and it's not what I'm pushing for. Besides, there may be many different naming or host identity schemes we might eventually want to support besides DNS names - e.g., UIA personal names, HIP cryptographic host identities, ... 3. Applications MAY be aware of IP addresses if they need to be for whatever reason, but aren't ALWAYS forced to have hard-coded dependencies on the existence and structure of IP addresses by the API's design. Applications see IP addresses as variable-length string blobs of some kind - e.g., along the lines Florian Weimer suggested in another message. Applications can parse/interpret or create these blobs if they want/need to, but don't necessarily have to if they're just passing the blob through from the GUI or URL parser to the OS's protocol stack. This is the position I think we need to be pushing for. In short, I don't think either the current fascist extreme of an IP-address-only API or the opposite fascist
Re: The Great Naming Debate (was Re: The internet architecture)
I absolutly agree with brians posting and recomment all people reading this paper , IMHO, it solves some known problems , even when they don´t exist in real world yet . ;) http://pdos.csail.mit.edu/papers/uia:osdi06.pdf (e.g., via DNS-based load balancers that take end-to-end IP reachability information as input), this would take us beyound round robin indeed. cheers Marc -- Les Enfants Terribles - WWW.LET.DE Marc Manthey 50672 Köln - Germany Hildeboldplatz 1a Tel.:0049-221-3558032 Mobil:0049-1577-3329231 mail: m...@let.de PGP/GnuPG: 0x1ac02f3296b12b4d jabber :m...@kgraff.net IRC: #opencu freenode.net twitter: http://twitter.com/macbroadcast web: http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The Great Naming Debate (was Re: The internet architecture)
Bryan Ford wrote: You seem to be assuming that my proposal was to disallow such visibility into the network entirely, but that wasn't my intent at all. I just would like it to become no longer _mandatory_ for every application to know about the structure IP addresses in order to accomplish anything. In short, I don't think either the current fascist extreme of an IP-address-only API or the opposite fascist extreme of a DNS-name-only protocol stack is very appealing; we need an environment in which different kinds of names/addresses/identities can coexist. Ah, it seems I read far too much into what you wrote earlier. I certainly don't think it should be mandatory for all applications that use the network to know about the structure of IP addresses. The beef I had was with the various forms of all apps should always use DNS names arguments. Note that with getaddrinfo(), arguably they _don't_ need to know about the structure of IP addresses. The getaddrinfo() routine allocates a sockaddr_xx structure of appropriate type for each address found, but the pointers returned are (as far as the caller knows) to generic sockaddr structures. The caller can simply pass a pointer to this structure to connect(). And the idea was clearly to insulate apps from having to know about the structure or size of addresses, without compromising their flexibility. For several reasons, I don't happen to think that the result works very well, but the intent was there. If it turns out to not work well enough to prevent apps from needing to peek into addresses, maybe the problem isn't the API, but rather that there are subtle differences between v4 and v6 that nevertheless matter to applications. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
