From owner-ietf-aulli Wed Jan 7 10:18:29 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07IITib065756 for ; Wed, 7 Jan 2004 10:18:29 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07IIT3c065754 for ietf-aulli-bks; Wed, 7 Jan 2004 10:18:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07IISib065749 for ; Wed, 7 Jan 2004 10:18:28 -0800 (PST) (envelope-from hardie@qualcomm.com) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i07IISH8024457 for ; Wed, 7 Jan 2004 10:18:28 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i07IIQhk016285 for ; Wed, 7 Jan 2004 10:18:27 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: Date: Wed, 7 Jan 2004 10:18:25 -0800 To: ietf-aulli@imc.org From: Ted Hardie Subject: Belated Welcome. Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Howdy folks, First off, an apology: after asking Paul to set this list up, I mistakenly co-mingled its output with that of some of the groups working on proposals in this area, and so thought the discussion had been kicked off some time ago. Since Paul was waiting for a "first post" from me, this has slowed our progress in this discussion. That's my fault, and I apologize for the delay. That said, welcome to the discussion. The main purpose of this list is to examine how application layer protocols should/will interact with lower layer identifiers. The main driver for the list is the set of proposals which propose new identifiers (e.g. HIP), but the discussion can and should include the interaction of application layer protocols with the existing IP address families (IPv4 and IPv6) as well as DNS-based schemes. I am not supposing that there is a single interaction type for all application protocols, but I am hoping that we can describe some basic groupings which will help those proposing specific solutions to see the applicability of their work. I have no agenda for setting up a working group on this set of topics, though I can imagine both BCP-type documents arising from this discussion as well as proposals for specific mechanisms that might be on the standards track. Before heading down that road, though, I think we need to have the more general discussion. As a first question, I'd like to ask for discussion of application-layer protocols which must have topology-specific identifiers to function correctly. Or to put that in terms of our current systems, which application-layer protocols currently need to use "raw" IP addresses to function? Thanks again for your subscription and interest, and, once again, my apologies for the delay. regards, Ted Hardie From owner-ietf-aulli Wed Jan 7 15:00:25 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07N0Pib079549 for ; Wed, 7 Jan 2004 15:00:25 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07N0PSV079548 for ietf-aulli-bks; Wed, 7 Jan 2004 15:00:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from mail3.dynamicsoft.com ([63.113.44.69]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07N0Nib079543 for ; Wed, 7 Jan 2004 15:00:24 -0800 (PST) (envelope-from jdrosen@dynamicsoft.com) Received: from dynamicsoft.com ([63.113.46.36]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i07N0TmR010675; Wed, 7 Jan 2004 18:00:30 -0500 (EST) Message-ID: <3FFC8F88.9010108@dynamicsoft.com> Date: Wed, 07 Jan 2004 18:00:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie CC: ietf-aulli@imc.org Subject: Re: Belated Welcome. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: inline. Ted Hardie wrote: As a first question, I'd like to > ask for discussion of application-layer protocols which must have > topology-specific identifiers to function correctly. Or to put that > in terms of our current systems, which application-layer protocols > currently need to use "raw" IP addresses to function? Thanks again > for your subscription and interest, and, once again, my apologies > for the delay. regards, Ted Hardie > Any of the protocols that do real time multimedia session establishment, such as SIP and Megaco, include address information in the protocol messages. In both cases, that address information is almost always an IP address (as opposed to a DNS host name) since the devices frequently do not have host names in the DNS. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From owner-ietf-aulli Wed Jan 7 20:35:34 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i084ZYib002540 for ; Wed, 7 Jan 2004 20:35:34 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i084ZYhV002539 for ietf-aulli-bks; Wed, 7 Jan 2004 20:35:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i084ZWib002530 for ; Wed, 7 Jan 2004 20:35:33 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 966B7AFE95; Wed, 7 Jan 2004 23:35:33 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15329-01; Wed, 7 Jan 2004 23:35:32 -0500 (EST) Received: from envy.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 04C40AFD78; Wed, 7 Jan 2004 23:35:32 -0500 (EST) Date: Wed, 7 Jan 2004 23:27:59 -0500 From: Keith Moore To: Ted Hardie Cc: moore@cs.utk.edu, ietf-aulli@imc.org Subject: Re: Belated Welcome. Message-Id: <20040107232759.0b77c7e5.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 7 Jan 2004 10:18:25 -0800 Ted Hardie wrote: > As a first question, I'd like to ask for discussion of > application-layer > protocols which must have topology-specific identifiers to function > correctly. Or to put that in terms of our current systems, which > application-layer protocols currently need to use "raw" IP addresses to > function? I don't think they're the same question at all. there are apps protocols that need reliable endpoint identifiers that can be used in referrals (so that the endpoint identifier for A is sufficient to allow any other host on the net to reliably, quickly, and efficiently reach A, assuming that the network permits such access). the need for such an endpoint identifier is not the same thing as the need for topology-specific information, it's just that in the current architecture the closest thing we have to such an endpoint identifier is the IP address. DNS names don't work nearly as well for lots of reasons. if there were no relationship between IP addresses and topology, but IP addresses still functioned as unique and reasonably stable endpoint identifiers, most of the apps using raw IP addresses would still work. now, there *are* some apps that do need to know about topology. these include network management apps, and apps that need to exploit network locality (say to aggregate traffic, or to find the nearest location of some resource). From owner-ietf-aulli Wed Jan 7 22:12:40 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i086Ceib009939 for ; Wed, 7 Jan 2004 22:12:40 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i086Ce26009938 for ietf-aulli-bks; Wed, 7 Jan 2004 22:12:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i086Ccib009905 for ; Wed, 7 Jan 2004 22:12:38 -0800 (PST) (envelope-from paf@cisco.com) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Jan 2004 07:13:24 +0100 Received: from xbe-ams-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i086CG3Y028108; Thu, 8 Jan 2004 07:12:17 +0100 (MET) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jan 2004 07:12:34 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jan 2004 07:12:34 +0100 In-Reply-To: <3FFC8F88.9010108@dynamicsoft.com> References: <3FFC8F88.9010108@dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <94AED278-41A1-11D8-9140-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: ietf-aulli@imc.org, Ted Hardie From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Belated Welcome. Date: Thu, 8 Jan 2004 07:12:04 +0100 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 08 Jan 2004 06:12:34.0578 (UTC) FILETIME=[68342720:01C3D5AE] Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2004-01-08, at 00.00, Jonathan Rosenberg wrote: > Any of the protocols that do real time multimedia session > establishment, such as SIP and Megaco, include address information in > the protocol messages. To be more clear, any protocol which made the choice of using a verbatim SDP description instead of their own description of the RTP stream have this problem. Choosing SDP descriptions is a big mistake. My view is that SDP should be obsoleted by a better format which then is inherited by all these protocols. FYI: I blame myself as an IESG member to not discover SIP using SDP until we had to approve or not approve the SIP specification. I brought the issue up, but the responsible AD's (in transport) thought the comment came too late. I.e. I tried to stop SIP in 1999 when it was going through IESG, because I wanted hostnames (and because of that not real plain SDP descriptions) in SIP. This would have solved _some_ (but not all) problems with SIP I claim. paf From owner-ietf-aulli Thu Jan 8 03:57:45 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08Bvjib093853 for ; Thu, 8 Jan 2004 03:57:45 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08BvjYJ093852 for ietf-aulli-bks; Thu, 8 Jan 2004 03:57:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from mail3.dynamicsoft.com ([63.113.44.69]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08Bvhib093847 for ; Thu, 8 Jan 2004 03:57:44 -0800 (PST) (envelope-from jdrosen@dynamicsoft.com) Received: from dynamicsoft.com ([63.113.46.48]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i08BvcmR011048; Thu, 8 Jan 2004 06:57:40 -0500 (EST) Message-ID: <3FFD45AC.7080409@dynamicsoft.com> Date: Thu, 08 Jan 2004 06:57:32 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: ietf-aulli@imc.org, Ted Hardie Subject: Re: Belated Welcome. References: <3FFC8F88.9010108@dynamicsoft.com> <94AED278-41A1-11D8-9140-000A959CF516@cisco.com> In-Reply-To: <94AED278-41A1-11D8-9140-000A959CF516@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Patrik Fältström wrote: > On 2004-01-08, at 00.00, Jonathan Rosenberg wrote: > >> Any of the protocols that do real time multimedia session >> establishment, such as SIP and Megaco, include address information in >> the protocol messages. > > > To be more clear, any protocol which made the choice of using a verbatim > SDP description instead of their own description of the RTP stream have > this problem. Choosing SDP descriptions is a big mistake. My view is > that SDP should be obsoleted by a better format which then is inherited > by all these protocols. I dont see what SDP has to do with it. SDP allows either IP addresses or fully qualified hostnames to be carried. The problem is that, (1) session protocols inherently need to carry the address where the media session should be connected to, and (2) most of the endpoints creating these sessions simply dont have hostnames in DNS. As such, I dont see how an alternative design of SDP could have avoided the problem of carrying IP addresses in the protocols. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From owner-ietf-aulli Thu Jan 8 04:03:43 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08C3hib094054 for ; Thu, 8 Jan 2004 04:03:43 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08C3h38094053 for ietf-aulli-bks; Thu, 8 Jan 2004 04:03:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08C3fib094036 for ; Thu, 8 Jan 2004 04:03:42 -0800 (PST) (envelope-from paf@cisco.com) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Jan 2004 13:04:25 +0100 Received: from XBE-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i08C3Hub020528; Thu, 8 Jan 2004 13:03:17 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jan 2004 12:57:53 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jan 2004 13:03:34 +0100 In-Reply-To: <3FFD45AC.7080409@dynamicsoft.com> References: <3FFC8F88.9010108@dynamicsoft.com> <94AED278-41A1-11D8-9140-000A959CF516@cisco.com> <3FFD45AC.7080409@dynamicsoft.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <9CE906E6-41D2-11D8-AAD8-000A959CF516@cisco.com> Cc: ietf-aulli@imc.org, Ted Hardie From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Belated Welcome. Date: Thu, 8 Jan 2004 13:03:03 +0100 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 08 Jan 2004 12:03:34.0770 (UTC) FILETIME=[710E6D20:01C3D5DF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i08C3gib094041 Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2004-01-08, at 12.57, Jonathan Rosenberg wrote: > Patrik Fältström wrote: > >> On 2004-01-08, at 00.00, Jonathan Rosenberg wrote: >>> Any of the protocols that do real time multimedia session >>> establishment, such as SIP and Megaco, include address information >>> in the protocol messages. >> To be more clear, any protocol which made the choice of using a >> verbatim SDP description instead of their own description of the RTP >> stream have this problem. Choosing SDP descriptions is a big mistake. >> My view is that SDP should be obsoleted by a better format which then >> is inherited by all these protocols. > > I dont see what SDP has to do with it. SDP allows either IP addresses > or fully qualified hostnames to be carried. The problem is that, (1) > session protocols inherently need to carry the address where the media > session should be connected to, and (2) most of the endpoints creating > these sessions simply dont have hostnames in DNS. As such, I dont see > how an alternative design of SDP could have avoided the problem of > carrying IP addresses in the protocols. Then how come people use IP addresses all the time, for example in SIP? paf From owner-ietf-aulli Thu Jan 8 07:04:59 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08F4xib003118 for ; Thu, 8 Jan 2004 07:04:59 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08F4wG0003117 for ietf-aulli-bks; Thu, 8 Jan 2004 07:04:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08F4tib003108 for ; Thu, 8 Jan 2004 07:04:57 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id C83C1AFEAF; Thu, 8 Jan 2004 10:04:52 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14276-12; Thu, 8 Jan 2004 10:04:51 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 2FC8CAFEA9; Thu, 8 Jan 2004 10:04:51 -0500 (EST) In-Reply-To: <94AED278-41A1-11D8-9140-000A959CF516@cisco.com> References: <3FFC8F88.9010108@dynamicsoft.com> <94AED278-41A1-11D8-9140-000A959CF516@cisco.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <11BEAD07-41EC-11D8-AA7E-000393DB5366@cs.utk.edu> Cc: Keith Moore , Jonathan Rosenberg , ietf-aulli@imc.org, Ted Hardie From: Keith Moore Subject: Re: Belated Welcome. Date: Thu, 8 Jan 2004 10:05:17 -0500 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.609) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i08F4vib003113 Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: IMHO, it would not have been reasonable to require SIP to use hostnames. that would have made call completion times unacceptably slow and variable. DNS has never been good enough to serve as a universal endpoint identifier, and it cannot be made good enough - the limitations are inherent in DNS's design. On Jan 8, 2004, at 1:12 AM, Patrik Fältström wrote: > > On 2004-01-08, at 00.00, Jonathan Rosenberg wrote: > >> Any of the protocols that do real time multimedia session >> establishment, such as SIP and Megaco, include address information in >> the protocol messages. > > To be more clear, any protocol which made the choice of using a > verbatim SDP description instead of their own description of the RTP > stream have this problem. Choosing SDP descriptions is a big mistake. > My view is that SDP should be obsoleted by a better format which then > is inherited by all these protocols. > > FYI: I blame myself as an IESG member to not discover SIP using SDP > until we had to approve or not approve the SIP specification. I > brought the issue up, but the responsible AD's (in transport) thought > the comment came too late. I.e. I tried to stop SIP in 1999 when it > was going through IESG, because I wanted hostnames (and because of > that not real plain SDP descriptions) in SIP. This would have solved > _some_ (but not all) problems with SIP I claim. > > paf > From owner-ietf-aulli Thu Jan 8 07:15:42 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08FFgib003471 for ; Thu, 8 Jan 2004 07:15:42 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08FFgOZ003470 for ietf-aulli-bks; Thu, 8 Jan 2004 07:15:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08FFeib003452 for ; Thu, 8 Jan 2004 07:15:40 -0800 (PST) (envelope-from paf@cisco.com) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Jan 2004 16:16:23 +0100 Received: from XBE-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i08FFG9I016545; Thu, 8 Jan 2004 16:15:16 +0100 (MET) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jan 2004 16:09:52 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jan 2004 16:15:34 +0100 In-Reply-To: <11BEAD07-41EC-11D8-AA7E-000393DB5366@cs.utk.edu> References: <3FFC8F88.9010108@dynamicsoft.com> <94AED278-41A1-11D8-9140-000A959CF516@cisco.com> <11BEAD07-41EC-11D8-AA7E-000393DB5366@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <81201959-41ED-11D8-AAD8-000A959CF516@cisco.com> Cc: ietf-aulli@imc.org, Jonathan Rosenberg , Ted Hardie From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Belated Welcome. Date: Thu, 8 Jan 2004 16:15:33 +0100 To: Keith Moore X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 08 Jan 2004 15:15:34.0178 (UTC) FILETIME=[43289820:01C3D5FA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i08FFfib003466 Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2004-01-08, at 16.05, Keith Moore wrote: > IMHO, it would not have been reasonable to require SIP to use > hostnames. that would have made call completion times unacceptably > slow and variable. DNS has never been good enough to serve as a > universal endpoint identifier, and it cannot be made good enough - the > limitations are inherent in DNS's design. IMHO, if this was an issue, we would already have other problems with SIP given the amount of DNS interaction already happening when "finding the called party". But, the overall issue is that I think in SIP one should have picked a different mechanism to name the other endpoint because the IP-address/port-number is not in general the same between two endpoints which are so far into a network like a phone (so far in == deep inside layers and layers of firewalls). The response I got when I asked "Why do you use IP-addresses and port numbers explicitly" was then "we only use SDP, and we inherit what they do, so we have to use it, and we can not change now -- it is too late" which I now understand was the wrong answer. I am happy to now have been corrected so I have a better view of the world. paf > On Jan 8, 2004, at 1:12 AM, Patrik Fältström wrote: > >> >> On 2004-01-08, at 00.00, Jonathan Rosenberg wrote: >> >>> Any of the protocols that do real time multimedia session >>> establishment, such as SIP and Megaco, include address information >>> in the protocol messages. >> >> To be more clear, any protocol which made the choice of using a >> verbatim SDP description instead of their own description of the RTP >> stream have this problem. Choosing SDP descriptions is a big mistake. >> My view is that SDP should be obsoleted by a better format which then >> is inherited by all these protocols. >> >> FYI: I blame myself as an IESG member to not discover SIP using SDP >> until we had to approve or not approve the SIP specification. I >> brought the issue up, but the responsible AD's (in transport) thought >> the comment came too late. I.e. I tried to stop SIP in 1999 when it >> was going through IESG, because I wanted hostnames (and because of >> that not real plain SDP descriptions) in SIP. This would have solved >> _some_ (but not all) problems with SIP I claim. >> >> paf >> > From owner-ietf-aulli Thu Jan 8 07:26:33 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08FQXib003894 for ; Thu, 8 Jan 2004 07:26:33 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08FQXLx003893 for ietf-aulli-bks; Thu, 8 Jan 2004 07:26:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08FQWib003873 for ; Thu, 8 Jan 2004 07:26:32 -0800 (PST) (envelope-from mshore@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Jan 2004 07:34:20 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i08FQQGN028284; Thu, 8 Jan 2004 07:26:26 -0800 (PST) Received: from cisco.com (sjc-vpn2-558.cisco.com [10.21.114.46]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APR84025; Thu, 8 Jan 2004 07:26:25 -0800 (PST) Date: Thu, 8 Jan 2004 10:26:23 -0500 Subject: Re: Belated Welcome. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: ietf-aulli@imc.org To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= From: Melinda Shore In-Reply-To: <81201959-41ED-11D8-AAD8-000A959CF516@cisco.com> Message-Id: <049A94CD-41EF-11D8-AFFF-000A95E35274@cisco.com> X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i08FQWib003889 Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thursday, January 8, 2004, at 10:15 AM, Patrik Fältström wrote: > But, the overall issue is that I think in SIP one should have picked a > different mechanism to name the other endpoint because the > IP-address/port-number is not in general the same between two > endpoints which are so far into a network like a phone (so far in == > deep inside layers and layers of firewalls). I think the issue you're talking about is reachability, not naming, although IP addressing (and how we use addresses) conflates the two. The real question that SDP is trying to answer is "where do I send this data stream?" (i.e. routing) and we've been answering it with "here's the address and port for the endpoint" (i.e. naming). We could undoubtedly be making better use of DNS (or another database) here, but the first step is to start drawing clearer distinctions between naming and reachability. Melinda From owner-ietf-aulli Thu Jan 8 07:29:03 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08FT3ib004018 for ; Thu, 8 Jan 2004 07:29:03 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08FT3l5004016 for ietf-aulli-bks; Thu, 8 Jan 2004 07:29:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08FT2ib004010 for ; Thu, 8 Jan 2004 07:29:02 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i08Facc18688; Thu, 8 Jan 2004 07:36:39 -0800 From: Dave Crocker To: CC: , Ted Hardie X-Mailer: PocoMail 3.03 (1740) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Date: Thu, 8 Jan 2004 07:28:50 -0800 Message-ID: <20041872850.379678@bbprime> In-Reply-To: <11BEAD07-41EC-11D8-AA7E-000393DB5366@cs.utk.edu> Subject: Re: Re: Belated Welcome. Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Keith, > > IMHO, it would not have been reasonable to require SIP to use > hostnames. that would have made call completion times unacceptably > slow and variable. DNS has never been good enough to serve as a > universal endpoint identifier, and it cannot be made good enough - the > limitations are inherent in DNS's design. if the strings are used for identification, rather than addressing, then they do not need to incur a lookup. there is no 'cost' other than bits in the protocol field. "has never been good enough" is serving as a popular mantra, but it lacks any analytic substance. In other words, folks do not offer a clear set of requirements, on which there is general agreement, followed by an analysis of the reasons domain names cannot satisfy them. Obviously, if the string must be in every data packet, they are too long. However the arguments for having the string in every packet are still subject to controversy. Please feel free to break the logjam on analytic diligence. d/ -- Dave Crocker Brandenburg InternetWorking From owner-ietf-aulli Thu Jan 8 07:31:49 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08FVmib004157 for ; Thu, 8 Jan 2004 07:31:48 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08FVmxL004156 for ietf-aulli-bks; Thu, 8 Jan 2004 07:31:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08FVkib004144 for ; Thu, 8 Jan 2004 07:31:47 -0800 (PST) (envelope-from paf@cisco.com) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Jan 2004 16:32:31 +0100 Received: from XBE-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i08FVN6k021337; Thu, 8 Jan 2004 16:31:24 +0100 (MET) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jan 2004 16:25:59 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jan 2004 16:31:41 +0100 In-Reply-To: <049A94CD-41EF-11D8-AFFF-000A95E35274@cisco.com> References: <049A94CD-41EF-11D8-AFFF-000A95E35274@cisco.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Cc: ietf-aulli@imc.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Belated Welcome. Date: Thu, 8 Jan 2004 16:31:41 +0100 To: Melinda Shore X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 08 Jan 2004 15:31:41.0410 (UTC) FILETIME=[83AC7C20:01C3D5FC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i08FVlib004151 Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2004-01-08, at 16.26, Melinda Shore wrote: > On Thursday, January 8, 2004, at 10:15 AM, Patrik Fältström wrote: >> But, the overall issue is that I think in SIP one should have picked >> a different mechanism to name the other endpoint because the >> IP-address/port-number is not in general the same between two >> endpoints which are so far into a network like a phone (so far in == >> deep inside layers and layers of firewalls). > > I think the issue you're talking about is reachability, not naming, Actually, I don't think so. Let's say you do have port forwarding already in some firewall (by implicit or explicit intelligence in the firewall) you _can_ reach the other node, but not with the IP address and port number the device has, but instead whatever is used on the outside of the firewall. > although > IP addressing (and how we use addresses) conflates the two. Correct. > The real question > that SDP is trying to answer is "where do I send this data stream?" > (i.e. > routing) and we've been answering it with "here's the address and port > for > the endpoint" (i.e. naming). Yes. > We could undoubtedly be making better use of > DNS (or another database) here, but the first step is to start drawing > clearer > distinctions between naming and reachability. ...and what I understand is that Ted want us to not again agree on this problem (that it exists), but instead move forward by first talking about what protocols have problems. So, here we go: SIP FTP paf From owner-ietf-aulli Thu Jan 8 07:35:42 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08FZgib004548 for ; Thu, 8 Jan 2004 07:35:42 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08FZgse004547 for ietf-aulli-bks; Thu, 8 Jan 2004 07:35:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08FZfib004541 for ; Thu, 8 Jan 2004 07:35:41 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 0E2D6AFEAF; Thu, 8 Jan 2004 10:35:42 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17689-15; Thu, 8 Jan 2004 10:35:40 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 6C3BFAFEAC; Thu, 8 Jan 2004 10:35:40 -0500 (EST) In-Reply-To: <81201959-41ED-11D8-AAD8-000A959CF516@cisco.com> References: <3FFC8F88.9010108@dynamicsoft.com> <94AED278-41A1-11D8-9140-000A959CF516@cisco.com> <11BEAD07-41EC-11D8-AA7E-000393DB5366@cs.utk.edu> <81201959-41ED-11D8-AAD8-000A959CF516@cisco.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <6036BE54-41F0-11D8-AA7E-000393DB5366@cs.utk.edu> Cc: Keith Moore , ietf-aulli@imc.org, Jonathan Rosenberg , Ted Hardie From: Keith Moore Subject: Re: Belated Welcome. Date: Thu, 8 Jan 2004 10:36:06 -0500 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.609) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i08FZfib004542 Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 8, 2004, at 10:15 AM, Patrik Fältström wrote: > On 2004-01-08, at 16.05, Keith Moore wrote: > >> IMHO, it would not have been reasonable to require SIP to use >> hostnames. that would have made call completion times unacceptably >> slow and variable. DNS has never been good enough to serve as a >> universal endpoint identifier, and it cannot be made good enough - >> the limitations are inherent in DNS's design. > > IMHO, if this was an issue, we would already have other problems with > SIP given the amount of DNS interaction already happening when > "finding the called party". > > But, the overall issue is that I think in SIP one should have picked a > different mechanism to name the other endpoint because the > IP-address/port-number is not in general the same between two > endpoints That's completely reasonable, as this is how IP was defined to work, and IP routing depends on this. We already know that NATs break things, and the lack of consistency between address-to-host bindings across a NAT is only one of the things that NATs break -- and only one of the things about NATs that cause SIP to break. From owner-ietf-aulli Thu Jan 8 07:39:02 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08Fd2ib004647 for ; Thu, 8 Jan 2004 07:39:02 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08Fd2a0004646 for ietf-aulli-bks; Thu, 8 Jan 2004 07:39:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08Fd1ib004641 for ; Thu, 8 Jan 2004 07:39:01 -0800 (PST) (envelope-from mshore@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Jan 2004 07:46:27 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i08FctVM011033; Thu, 8 Jan 2004 07:38:55 -0800 (PST) Received: from cisco.com (sjc-vpn2-558.cisco.com [10.21.114.46]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APR84721; Thu, 8 Jan 2004 07:38:53 -0800 (PST) Date: Thu, 8 Jan 2004 10:38:52 -0500 Subject: Re: Belated Welcome. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: ietf-aulli@imc.org To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= From: Melinda Shore In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i08Fd1ib004642 Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thursday, January 8, 2004, at 10:31 AM, Patrik Fältström wrote: > Actually, I don't think so. Let's say you do have port forwarding > already in some firewall (by implicit or explicit intelligence in the > firewall) you _can_ reach the other node, but not with the IP address > and port number the device has, but instead whatever is used on the > outside of the firewall. But that assumes a particular solution. What we're seeing in practice, alas, is the increasing use of proxies and relays to solve the problem you're describing. But even so the outline of the problem is the same and it's that to reach me you have to send the data elsewhere, to some third party, rather than directly to me. That third party may be on the path or off the path, but to reach me you've got to address him. Melinda From owner-ietf-aulli Thu Jan 8 07:50:30 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08FoUib005121 for ; Thu, 8 Jan 2004 07:50:30 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08FoU9O005120 for ietf-aulli-bks; Thu, 8 Jan 2004 07:50:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08FoTib005115 for ; Thu, 8 Jan 2004 07:50:29 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 1216EAFEB3; Thu, 8 Jan 2004 10:50:30 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20176-07; Thu, 8 Jan 2004 10:50:28 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 84621AFEB2; Thu, 8 Jan 2004 10:50:27 -0500 (EST) In-Reply-To: <20041872850.379678@bbprime> References: <20041872850.379678@bbprime> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7137D53C-41F2-11D8-AA7E-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit Cc: Keith Moore , , Ted Hardie From: Keith Moore Subject: Re: Belated Welcome. Date: Thu, 8 Jan 2004 10:50:54 -0500 To: Dave Crocker X-Mailer: Apple Mail (2.609) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> IMHO, it would not have been reasonable to require SIP to use >> hostnames. that would have made call completion times unacceptably >> slow and variable. DNS has never been good enough to serve as a >> universal endpoint identifier, and it cannot be made good enough - >> the >> limitations are inherent in DNS's design. > > > if the strings are used for identification, rather than addressing, > then they > do not need to incur a lookup. there is no 'cost' other than bits in > the > protocol field. true, provided that those names are uniquely bound to the resource. > "has never been good enough" is serving as a popular mantra, but it > lacks any > analytic substance. In other words, folks do not offer a clear set of > requirements, on which there is general agreement, followed by an > analysis of > the reasons domain names cannot satisfy them. the same could be said of the folks who are arguing that domain names can satisfy them. actually I could state this the other way - IF you very carefully provision and monitor your DNS servers and their supporting networks, and IF you carefully organize your DNS tree for lookup efficiency, and IF you only use DNS names from those servers, and IF all of your clients are pre-configured with the addresses of those DNS servers (so they don't have to get their NS records from higher-level servers), and IF your clients aggressively timeout and retry DNS queries - then you can make DNS lookup only tens of milliseconds slower, and almost as reliable, as using IP addresses. on the other hand, if you want SIP to work through NAT, you have to stand on your head in several other ways - you have to make DNS addressing consistent across the NAT (often it's not), you have to find some way to let SIP set up and maintain address bindings in the NATs in order to complete and maintain calls across the NATs (and similarly, to open and maintain holes in firewalls). as it is, SIP is capable of using either IP addresses or DNS names. essentially SIP is being agnostic about how you organize your network. it's hard to fault that choice. > > Obviously, if the string must be in every data packet, they are too > long. > However the arguments for having the string in every packet are still > subject > to controversy. > > Please feel free to break the logjam on analytic diligence. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > > > > > From owner-ietf-aulli Thu Jan 8 07:52:54 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08Fqsib005454 for ; Thu, 8 Jan 2004 07:52:54 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08Fqs2W005451 for ietf-aulli-bks; Thu, 8 Jan 2004 07:52:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08Fqpib005411 for ; Thu, 8 Jan 2004 07:52:51 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 1AC51AFEB1; Thu, 8 Jan 2004 10:52:52 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20971-01; Thu, 8 Jan 2004 10:52:51 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id AA173AFEAC; Thu, 8 Jan 2004 10:52:50 -0500 (EST) In-Reply-To: References: <049A94CD-41EF-11D8-AFFF-000A95E35274@cisco.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Keith Moore , Melinda Shore , ietf-aulli@imc.org From: Keith Moore Subject: Re: Belated Welcome. Date: Thu, 8 Jan 2004 10:53:17 -0500 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.609) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > ...and what I understand is that Ted want us to not again agree on > this problem (that it exists), but instead move forward by first > talking about what protocols have problems. > > So, here we go: > > SIP > FTP specifics ones I know about: gnutella SONAR DNS BGP netsolve PVM From owner-ietf-aulli Thu Jan 8 07:53:42 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08Frgib005558 for ; Thu, 8 Jan 2004 07:53:42 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08FrgYQ005557 for ietf-aulli-bks; Thu, 8 Jan 2004 07:53:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08Freib005552 for ; Thu, 8 Jan 2004 07:53:41 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id CEFD5AFEB9 for ; Thu, 8 Jan 2004 10:53:41 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20738-07; Thu, 8 Jan 2004 10:53:40 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 6307CAFEAC; Thu, 8 Jan 2004 10:53:40 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Keith Moore From: Keith Moore Subject: why DNS names make lousy endpoint identifiers Date: Thu, 8 Jan 2004 10:54:09 -0500 To: ietf-aulli@imc.org X-Mailer: Apple Mail (2.609) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: rather than repeat this stuff here, I thought I'd just send a pointer to my web page on this topic: http://www.cs.utk.edu/~moore/opinions/ipv6/dns-as-endpoint-id.html From owner-ietf-aulli Thu Jan 8 07:56:04 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08Fu4ib005649 for ; Thu, 8 Jan 2004 07:56:04 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08Fu4IW005648 for ietf-aulli-bks; Thu, 8 Jan 2004 07:56:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08Fu2ib005635 for ; Thu, 8 Jan 2004 07:56:02 -0800 (PST) (envelope-from paf@cisco.com) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Jan 2004 16:56:47 +0100 Received: from XBE-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i08FtbNF029157; Thu, 8 Jan 2004 16:55:39 +0100 (MET) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jan 2004 16:50:14 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jan 2004 16:55:55 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <24D433A6-41F3-11D8-AAD8-000A959CF516@cisco.com> Cc: ietf-aulli@imc.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Belated Welcome. Date: Thu, 8 Jan 2004 16:55:55 +0100 To: Melinda Shore X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 08 Jan 2004 15:55:56.0078 (UTC) FILETIME=[E6B934E0:01C3D5FF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i08Fu3ib005644 Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2004-01-08, at 16.38, Melinda Shore wrote: > On Thursday, January 8, 2004, at 10:31 AM, Patrik Fältström wrote: >> Actually, I don't think so. Let's say you do have port forwarding >> already in some firewall (by implicit or explicit intelligence in the >> firewall) you _can_ reach the other node, but not with the IP address >> and port number the device has, but instead whatever is used on the >> outside of the firewall. > > But that assumes a particular solution. What we're seeing in > practice, alas, > is the increasing use of proxies and relays to solve the problem you're > describing. But even so the outline of the problem is the same and > it's that > to reach me you have to send the data elsewhere, to some third party, > rather > than directly to me. That third party may be on the path or off the > path, but > to reach me you've got to address him. From an addressing perspective, it doesn't matter if I have to address a proxy (which acts on the protocol level and actually terminates the flow), or the outside of a firewall (which only rewrite some of the elements in the 5-tuple identifying the flow), it is still from an addressing standpoint not you I address when I give someone elses IP address and port number. The problem we have is, I claim, that when using IP address and port number, I either try to address you (which might not work because of reachability problems) _or_ I have to address someone else. I don't like that. I want to still address you, but, the packets should go to the proxy, outside of firewall or whatever else which will make sure the packets will reach you. So, we have to use some indirect naming mechanism. paf From owner-ietf-aulli Thu Jan 8 09:43:31 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08HhVib010103 for ; Thu, 8 Jan 2004 09:43:31 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08HhV3l010102 for ietf-aulli-bks; Thu, 8 Jan 2004 09:43:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08HhUib010096 for ; Thu, 8 Jan 2004 09:43:30 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 8F152AFD0C; Thu, 8 Jan 2004 12:43:31 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05572-01; Thu, 8 Jan 2004 12:43:30 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 30BEEAFEC5; Thu, 8 Jan 2004 12:43:30 -0500 (EST) Date: Thu, 8 Jan 2004 12:43:29 -0500 From: Keith Moore To: Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?= Cc: moore@cs.utk.edu, mshore@cisco.com, ietf-aulli@imc.org Subject: Re: Belated Welcome. Message-Id: <20040108124329.33f98ccd.moore@cs.utk.edu> In-Reply-To: <24D433A6-41F3-11D8-AAD8-000A959CF516@cisco.com> References: <24D433A6-41F3-11D8-AAD8-000A959CF516@cisco.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: *I* will never be equivalent to a host, and even less so to an IP address. (unless they replace my brain with a simple computer and program me to not notice :) And no amount of management for IP addressing can make it stable enough to use as a telephone number that can be stored in people's speed dialing, etc. So yes, there will always be hosts that "proxy" for me in that they provide services that are closely associated with "me", and there will always need to be some layer of indirection between descriptions of, or identifiers associated with, "me" and the IP addresses of those proxies. The questions are really about where that layer is, whether DNS is a good way to do that indirection, and whether it's reasonable to use the existing DNS names and infrastructure to do that indirection or if you need a different infrastructure with different names. I'll claim that you can make ENUM with E.164 numbers work much better than typical DNS lookups precisely because you can provision DNS servers under e164.arpa differently than those in .com, .net, etc. But that still doesn't argue for expecting all apps, or even SIP, to use DNS names instead of IP addresses. > From an addressing perspective, it doesn't matter if I have to > address > a proxy (which acts on the protocol level and actually terminates the > flow), or the outside of a firewall (which only rewrite some of the > elements in the 5-tuple identifying the flow), it is still from an > addressing standpoint not you I address when I give someone elses IP > address and port number. > > The problem we have is, I claim, that when using IP address and port > number, I either try to address you (which might not work because of > reachability problems) _or_ I have to address someone else. > > I don't like that. > > I want to still address you, but, the packets should go to the proxy, > outside of firewall or whatever else which will make sure the packets > will reach you. So, we have to use some indirect naming mechanism. > > paf > > From owner-ietf-aulli Thu Jan 8 09:51:23 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08HpNib010480 for ; Thu, 8 Jan 2004 09:51:23 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08HpN3k010479 for ietf-aulli-bks; Thu, 8 Jan 2004 09:51:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08HpLib010473 for ; Thu, 8 Jan 2004 09:51:22 -0800 (PST) (envelope-from paf@cisco.com) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Jan 2004 18:52:06 +0100 Received: from xbe-ams-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i08How19000517; Thu, 8 Jan 2004 18:50:59 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jan 2004 18:51:16 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jan 2004 18:51:16 +0100 In-Reply-To: <20040108124329.33f98ccd.moore@cs.utk.edu> References: <24D433A6-41F3-11D8-AAD8-000A959CF516@cisco.com> <20040108124329.33f98ccd.moore@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <42B03724-4203-11D8-AAD8-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: ietf-aulli@imc.org, mshore@cisco.com From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: Belated Welcome. Date: Thu, 8 Jan 2004 18:51:17 +0100 To: Keith Moore X-Mailer: Apple Mail (2.609) X-OriginalArrivalTime: 08 Jan 2004 17:51:16.0467 (UTC) FILETIME=[0398C430:01C3D610] Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2004-01-08, at 18.43, Keith Moore wrote: > The questions are > really about where that layer is, whether DNS is a good way to do that > indirection, and whether it's reasonable to use the existing DNS names > and infrastructure to do that indirection or if you need a different > infrastructure with different names. In SIP they try to solve the problem by having you (when you "roam") tell a stable service (the SIP server) where you are. Problem is not even this guy might be able to contact "you" directly using the identifiers you think are ok. So, I think SIP is interesting when trying to solve this problem, but it doesn't (unfortunately) manage to go the whole way. Especially when this box you register at give the other peer of the "call" the same identifiers you gave to it. So, this box is just something like a "broker" for identifiers which might not be possible to use. > But that still doesn't argue for expecting all apps, or even SIP, to > use > DNS names instead of IP addresses. Correct. Especially as you expect the same DNS name resolv to different IP addresses depending on who queries (because that is network topology dependent). But, DNS is possible to update using DDNS, which IP address are not. $10.000 is how we do? Make sure we don't have scoped addresses in IPv6, pushing a simple allocation strategy to the RIR's so we don't get so many stupid NAT's... Or just go straight to the bar to design something else because "Internet" is broken? paf From owner-ietf-aulli Thu Jan 8 11:05:42 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08J5gib014580 for ; Thu, 8 Jan 2004 11:05:42 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08J5g6Q014579 for ietf-aulli-bks; Thu, 8 Jan 2004 11:05:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08J5cib014572 for ; Thu, 8 Jan 2004 11:05:40 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 249B2AFEDB; Thu, 8 Jan 2004 14:05:40 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15327-14; Thu, 8 Jan 2004 14:05:39 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id E7139AFED6; Thu, 8 Jan 2004 14:05:38 -0500 (EST) Date: Thu, 8 Jan 2004 14:05:38 -0500 From: Keith Moore To: Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?= Cc: moore@cs.utk.edu, ietf-aulli@imc.org, mshore@cisco.com Subject: Re: Belated Welcome. Message-Id: <20040108140538.1e331fba.moore@cs.utk.edu> In-Reply-To: <42B03724-4203-11D8-AAD8-000A959CF516@cisco.com> References: <24D433A6-41F3-11D8-AAD8-000A959CF516@cisco.com> <20040108124329.33f98ccd.moore@cs.utk.edu> <42B03724-4203-11D8-AAD8-000A959CF516@cisco.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > The questions are > > really about where that layer is, whether DNS is a good way to do > > that indirection, and whether it's reasonable to use the existing > > DNS names and infrastructure to do that indirection or if you need a > > different infrastructure with different names. > > In SIP they try to solve the problem by having you (when you "roam") > tell a stable service (the SIP server) where you are. Problem is not > even this guy might be able to contact "you" directly using the > identifiers you think are ok. well, that's not SIP's problem, that's the network's problem. apps shouldn't have to be aware of network topology and where NATs live. the network needs to provide coherent addressing, even though we admit that for various reasons those addresses cannot be perfectly stable. > $10.000 is how we do? > > Make sure we don't have scoped addresses in IPv6, pushing a simple > allocation strategy to the RIR's so we don't get so many stupid > NAT's... > > Or just go straight to the bar to design something else because > "Internet" is broken? I think we can make IPv6 coherent, and more easily than we can start from scratch. From owner-ietf-aulli Thu Jan 8 12:23:49 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08KNnib019285 for ; Thu, 8 Jan 2004 12:23:49 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08KNnhv019284 for ietf-aulli-bks; Thu, 8 Jan 2004 12:23:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08KNmib019279 for ; Thu, 8 Jan 2004 12:23:49 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i08KVQc06195; Thu, 8 Jan 2004 12:31:26 -0800 From: Dave Crocker To: , CC: Keith Moore X-Mailer: PocoMail 3.03 (1740) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Date: Thu, 8 Jan 2004 12:23:36 -0800 Message-ID: <200418122336.735194@bbprime> In-Reply-To: Subject: Re: why DNS names make lousy endpoint identifiers Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Keith, > rather than repeat this stuff here, I thought I'd just send a pointer > to my web page on this topic: > Why DNS names make lousy endpoint identifiers > The problem > > In IPv6 more often than in IPv4, attachment points (i.e. IP addresses) > change .... > Such changes can be expected to happen more often in the future .... > In order to allow applications to function without interruption across such > events, we need identifiers for connection endpoints which are stable across > such events, and which can be used by protocols to maintain contact across > such events. Let's take all of the above as being true. Such connection endpoint identifiers would have various uses: > > * used by TCP and other transport protocols (so that TCP connections can > stay up across renumbering) "used by" does not mean that it needs to be in each TCP segment and might not mean that TCP even uses the string. MAST is a demonstration of this point, but so are a number of the other proposals. > * can be used for rendezvous (e.g. "call me back at XXX when you're done") ok. > * can be used for referrals between hosts ok. > Requirements for connection endpoint identifiers > > * They must be unambiguous within the set of all processes that are > participating in an application ok. > * They must be usable with TCP, SCTP, etc. without major changes ok, except as I noted, above. in other words, none of this mandates that the transports be changed. > Requirements for mapping connection endpoint identifiers to addresses > > * The function that maps identifiers to addresses needs to be fast If you are suggesting that we have to do this better than the DNS, then you have moved into the area of long-term research. The only thing that mitigates against this is the distinction between public versus internal activity. If the activity must be between random hosts interacting for the first time, then we are in the realm of research. If we are in the realm of maintain an association that already exists between two hosts, then things like home agents and mapping agents provide adequate mechanisms that work internally to the association. > * The function that maps identifiers to addresses needs to be reliable Ditto. > * The function that maps identifiers to addresses needs to be appropriately > secure, so that (e.g.) it is not easily attacked for the purpose of > redirecting traffic to other locations or to deny service to the hosts using > those identifiers Partial ok. One slippery slope is the apparent tendency to design a security mechanism that attempts to do far more than just prevent redirection attacks. Another is to believe that this requires that the ID, itself, somehow be a security-related string. Both slopes are on a mountain that tries to make basic IP's security model better than it is now, even though we do not have a problem with the current functionality of IP, with respect to security issues. To the extent that some situations require more, we already have IPsec and TLS (and s/mime and pgp and...) > * The mapping must be effective within the set of all processes that are > participating in an application ok. > * The function must be able to quickly reflect address or prefix changes ok. > Problems with using DNS names > DNS names are > > * Incompatible with existing transport protocols. Sounds like a very bad thing, except I have no idea what you mean. This needs to be explained before it can be evaluated. > * Ambiguous and overloaded. Quite often, a DNS name doesn't refer to a host. This is true, but the reason this negates its use as an EID needs to be explained. As I have asked many times, there needs to be a description of a usage scenario that shows the problem. Let me take the logic that you appear to be using and apply it in a different situation, to show the problem in your assertion: We need to move the contents of a small house in one load. I suggest using a truck and you say that we can't do that because trucks come in many sizes. You are correctly worried that we might try to use one that is too small. So the real problem is not that we cannot use a truck but that we can only use _some_ trucks. The fact that _some_ domain names cannot be used as EIDs does not mean that _all_ domain names cannot be used as EIDs. > Instead it refers to a service (as in imap.example.com or www.example.com) > which might map to numerous hosts. There can also be many domains Again, this needs to distinguish between initial rendezvous, versus association maintenance. They have very different requirements and constraints. We can go into this in detail, since I've described a number of usages that are DNS-based, and they satisfy your concerns. To the extent they do not, it would be nice if you would respond to them. associated > with a single host and yet be semantically different; http://a.example.com > and http://b.example.com are different resources even if they are both > served by the same hosts. so? >The mapping from domains to hosts is essentially > arbitrary. so? > Therefore the > existing DNS names that we currently use to name services cannot be assumed > to be suitable as endpoint identifiers for rendezvous or referral. The fact that some names cannot be used does not mean that all names cannot be used. > * Not organized favorably. Existing DNS names are organized according to a > hierarchy of administrative entities, and write access to DNS RRs is also > organized in this fashion. This could be an interesting point. Please describe an administrative operation that you believe is essential for EID use and cannot reasonably be supported through the DNS. Then we can debate it. > The components of domain names are usually > intended to be recognizable by humans, and humans therefore attach meaning > to those names. So? > This further implies that those administrative entities > often want to restrict use of their domains, so that their names aren't > associated with behavior that they cannot control. So? > By contrast, users (and > their hosts) are often actors in multiple domains, sometimes concurrently. > Insisting that an existing domain name be tightly bound to such a host is > unrealistic. I have no idea what operational problem you are trying to claim exists. Please describe an EID usage that is concrete and which demonstrates this failing. (And, by the way folks, this is one of the problems with most dismissals of DNS usage. It is all abstract and theory based, and ignores the usage details of proposals that employ DNS.) > Of course, it would still be possible to create a new tree of domain names > that did not have these characteristics, but this would remove what many see > as the primary advantage of using DNS names - the ability to avoid creating > new infrastructure. Adding names to the DNS is far easier than creating a whole new global registration infrastructure. Please don't seriously try to tell me that you disagree. > Problems with using DNS lookup facilities > The DNS lookup service is > > * Slow. A substantial percentage of lookups take several seconds, and many faster global lookup? research. > * Slow to propagate changes. faster global propogation? research. > * Unreliable. More reliable global lookup? research. > * Not secure in practice. DNSSEC exists but is still in flux, and is not > widely used. More secure global lookup? research. > * Sometimes disconnected from reality. For a variety of reasons, hosts often > move and/or change addresses without DNS being updated. And what solution do you see that is not research? d/ -- Dave Crocker Brandenburg InternetWorking From owner-ietf-aulli Thu Jan 8 13:24:24 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08LOOib025882 for ; Thu, 8 Jan 2004 13:24:24 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08LOOR8025881 for ietf-aulli-bks; Thu, 8 Jan 2004 13:24:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08LOMib025875 for ; Thu, 8 Jan 2004 13:24:23 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 65E90AFEF6; Thu, 8 Jan 2004 16:24:24 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01266-12; Thu, 8 Jan 2004 16:24:22 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id A03DBAFC19; Thu, 8 Jan 2004 16:24:22 -0500 (EST) Date: Thu, 8 Jan 2004 16:24:22 -0500 From: Keith Moore To: Dave Crocker Cc: moore@cs.utk.edu, ietf-aulli@imc.org Subject: Re: why DNS names make lousy endpoint identifiers Message-Id: <20040108162422.1b4bbf35.moore@cs.utk.edu> In-Reply-To: <200418122336.735194@bbprime> References: <200418122336.735194@bbprime> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Such connection endpoint identifiers would have various uses: > > > > * used by TCP and other transport protocols (so that TCP > > connections can stay up across renumbering) > > "used by" does not mean that it needs to be in each TCP segment and > might not mean that TCP even uses the string. No, it doesn't. In general, if you change some things about the current architecture, you might be able to provide better endpoint identifiers than can be currently provided by IP addresses. Clearly there are various ways to use DNS for this purpose, some of which are more sophisticated than others. But some of the limitations of DNS names and DNS lookup for such identifiers really can't be fixed. > > * They must be usable with TCP, SCTP, etc. without major changes > > ok, except as I noted, above. in other words, none of this mandates > that the transports be changed. Even if you add a shim layer this does change the transports in subtle ways. For instance you probably want to recompute RTT estimates when you change underlying topology identifiers even if the endpoint identifiers remain the same. That doesn't mean we need to re-design TCP and/or SCTP - obviously we'd like to avoid having to do that. > > * The function that maps identifiers to addresses needs to be fast > > If you are suggesting that we have to do this better than the DNS, > then you have moved into the area of long-term research. Not at all. In some sense, BGP maps identifiers to locations very quickly. And we don't need long-term research to understand the effects of different design choices for how we propagate information between replicas and where the mappings are done - ordinary engineering analysis is good enough for that, if we only bother to do it. > The only thing that mitigates against this is the distinction between > public versus internal activity. If the activity must be between > random hosts interacting for the first time, then we are in the realm > of research. That's just handwaving on your part. There does exist a discipline called engineering, and there are lots of people who are trained to do it. > If we are in the realm of maintain an association that already exists > between two hosts, then things like home agents and mapping agents > provide adequate mechanisms that work internally to the association. We need to be able to maintain both kinds of mapping. we might or might not end up using separate mechanisms for these (there are certainly arguments for doing so, and maybe some for not doing so) > > * The function that maps identifiers to addresses needs to be > > appropriately secure, so that (e.g.) it is not easily attacked for > > the purpose of redirecting traffic to other locations or to deny > > service to the hosts using those identifiers > > Partial ok. One slippery slope is the apparent tendency to design a > security mechanism that attempts to do far more than just prevent > redirection attacks. Another is to believe that this requires that > the ID, itself, somehow be a security-related string. Agreed that it's really easy to try to impose more security than is either needed or achievable, and that the choice of security mechanisms needs especially careful scrutiny. > > Problems with using DNS names > > DNS names are > > > > * Incompatible with existing transport protocols. > > Sounds like a very bad thing, except I have no idea what you mean. > This needs to be explained before it can be evaluated. A DNS name won't fit into an IP header or a TCP pseudo-header, and IIRC SCTP can't redirect to a DNS name. Of course, that doesn't mean you can't find a workaroud, it just means that they're not a drop-in fix, as some people tend to assume. > > * Ambiguous and overloaded. Quite often, a DNS name doesn't refer > > to a host. > > This is true, but the reason this negates its use as an EID needs to > be explained. As I have asked many times, there needs to be a > description of a usage scenario that shows the problem. Basically the scenario is that a host or an app tries to use the same DNS name in multiple contexts - one of which treats the DNS name as an identifier for a resource that may have multiple instances, any of which will do; and another treats the DNS name as an identifier for a specific host which has a specific process listening on a specific socket, and only that specific process will do. A single DNS name can name multiple hosts, but if you're trying to redirect a TCP connection to one of those hosts, you can't use that same DNS name as an identifier for that specific host. > Let me take the logic that you appear to be using and apply it in a > different situation, to show the problem in your assertion: I believe that existing use of DNS is so widespread and entrenched that it is very difficult to get people to change the way they use it. I also believe that people have a hard time using the same kind of name at very different levels of specificity. We need different syntactic conventions to indicate to people (this includes programmers) the difference between a name of a resource and the name of a specific host. Now we could perhaps achieve that by inventing some naming convention for DNS - maybe we could say that any name of the form 1*DIGIT "._endpoint." domain (e.g. 123._endpoint.example.com) was actually an endpoint identifier and not an ordinary DNS name. But we'd still have the other problems associated with DNS lookup. In general, the claim is not that you cannot work around some, maybe even most, of the problems associated with using DNS for endpoint IDs - however, this list can serve as an attempt to list some of the obstacles that you need to overcome to make such proposals viable. > > Instead it refers to a service (as in imap.example.com or > > www.example.com) > > which might map to numerous hosts. There can also be many domains > > Again, this needs to distinguish between initial rendezvous, versus > association maintenance. They have very different requirements and > constraints. We can go into this in detail, since I've described a > number of usages that are DNS-based, and they satisfy your concerns. > To the extent they do not, it would be nice if you would respond to > them. I'm firmly convinced that DNS is too broken to fix for this. I won't claim that you can't fix a lot of the problems but once you do, there's not a piece of the DNS protocol that's worth saving for this purpose - not the syntax, nor the existing set of name delegations, nor the existing servers, nor the protocols, and certainly not the politics. What you end up with is just a lot of baggage. This shouldn't be surprising since DNS wasn't designed for this purpose, and given that DNS use for very different purposes is already well-entrenched. > associated > > with a single host and yet be semantically different; > > http://a.example.com > > and http://b.example.com are different resources even if they are > > both served by the same hosts. > > so? > > > >The mapping from domains to hosts is essentially > > arbitrary. > > so? By arbitrary I mean (among other things) that you can have one domain referring to multiple hosts, multiple domains referring to one host, or more generally, an arbitrary mapping from domain names onto hosts, e.g domain hosts A 1,2,3 B 1,3 C 2,3 D 1 That's not a desirable property for endpoint identifiers - for endpoint identifiers you want each identifier to unambiguously map to a single host. > > Therefore the > > existing DNS names that we currently use to name services cannot be > > assumed to be suitable as endpoint identifiers for rendezvous or > > referral. > > The fact that some names cannot be used does not mean that all names > cannot be used. True. But it does mean that DNS names are not as convenient to use or as appropriate for this purpose as some people (not necessarily you) naively assume. (Note that I didn't write this page as a specific response to MAST or to any other proposal, I wrote it as a general response to the variety of proposals - informal or formal, and at various levels of naivete or sophistication - that insist that we should just use DNS names as endpoint identifiers and everything will be hunky dory. Some of the limitations of DNS can be dealt with by more sophisticated proposals, some cannot.) > > * Not organized favorably. Existing DNS names are organized > > according to a hierarchy of administrative entities, and write > > access to DNS RRs is also organized in this fashion. > > This could be an interesting point. Please describe an administrative > operation that you believe is essential for EID use and cannot > reasonably be supported through the DNS. Then we can debate it. The point is that the existing names and delegation structures aren't really suitable for use in supporting EIDs, not that you can't somehow use DNS to support EIDs using different delegation structures. I have a laptop that moves from one place to another on the net. It should be able to keep the same EID no matter where it moves to. However, various networks and the laptop's operating system conspire to change the laptop's DNS name according to its location. The laptop's EID shouldn't be associated with any particular administrative entity (other than one I contract with), and certainly shouldn't be associated with the current location in the network, but the network is replete with mechanisms for doing both of these. > > The components of domain names are usually > > intended to be recognizable by humans, and humans therefore attach > > meaning to those names. > > So? > > > > This further implies that those administrative entities > > often want to restrict use of their domains, so that their names > > aren't associated with behavior that they cannot control. > > So? > > > > By contrast, users (and > > their hosts) are often actors in multiple domains, sometimes > > concurrently. Insisting that an existing domain name be tightly > > bound to such a host is unrealistic. > > I have no idea what operational problem you are trying to claim > exists. Organizations have their names embedded in domain names (or increasingly, the name of the organization is a domain name), and they see their reputations tied up in those names. They don't want those names associated with arbitrary activities. But a single host serves a user in many different roles - we don't want to carry separate PDAs or laptops for work and other purposes. This implies that organizational DNS names aren't good choices for host EIDs. > (And, by the way folks, this is one of the problems with most > dismissals of DNS usage. It is all abstract and theory based, and > ignores the usage details of proposals that employ DNS.) May I suggest that though humans' expectations of DNS usage and behavior are somewhat difficult to characterize (so they appear "abstract and theory based"), we ignore them at our peril. And may I also suggest that your own expectations of how people will use DNS are also abstract and theory based, they just aren't well articulated. Maybe you should try to state your assumptions rather than attacking mine out-of-hand. > > Of course, it would still be possible to create a new tree of > > domain names that did not have these characteristics, but this > > would remove what many see > > as the primary advantage of using DNS names - the ability to avoid > > creating new infrastructure. > > Adding names to the DNS is far easier than creating a whole new global > registration infrastructure. Please don't seriously try to tell me > that you disagree. I think you're mischaracterizing the difference. A lot of the baggage associated with adding names to the DNS seems to be related to the fact that existing DNS names are intended to be used by humans, and this assumption goes all the way to the DNS root. Theoretically, we could create a new TLD for use in EIDs, and we could set up a new delegation tree, but (again due to various kinds of baggage) that's a political minefield. So to me it really does look easier to create a new infrastructure, one based on giving out numbers rather than letting people fight over names. In some sense we create a new infrastructure either way. And again, I think if we use existing delegations we encumber use of EIDs in various other ways, and make them less reliable. > > Problems with using DNS lookup facilities > > The DNS lookup service is > > > > * Slow. A substantial percentage of lookups take several seconds, > > and many > > faster global lookup? research. Nope, that's just a handwaving dismissal on your part. BGP does it quite well. > > * Slow to propagate changes. > > faster global propogation? research. more handwaving. > > * Unreliable. > > More reliable global lookup? research. still more handwaving. > > * Not secure in practice. DNSSEC exists but is still in flux, and > > is not widely used. > > More secure global lookup? research. AFAIK, this one really is research. DNS doesn't solve it either, though. From owner-ietf-aulli Thu Jan 8 19:36:33 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i093aXib048988 for ; Thu, 8 Jan 2004 19:36:33 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i093aXs9048987 for ietf-aulli-bks; Thu, 8 Jan 2004 19:36:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i093aUib048981 for ; Thu, 8 Jan 2004 19:36:32 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i093i8c32397; Thu, 8 Jan 2004 19:44:08 -0800 From: Dave Crocker To: CC: , X-Mailer: PocoMail 3.03 (1740) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Date: Thu, 8 Jan 2004 19:36:28 -0800 Message-ID: <200418193628.917771@bbprime> In-Reply-To: <20040108162422.1b4bbf35.moore@cs.utk.edu> Subject: Re: Re: why DNS names make lousy endpoint identifiers Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Keith, > > "used by" does not mean that it needs to be in each TCP segment and > > might not mean that TCP even uses the string. > > No, it doesn't. In general, if you change some things about the > current architecture, you might be able to provide better endpoint > identifiers than can be currently provided by IP addresses. Clearly > there are various ways to use DNS for this purpose, some of which are > more sophisticated than others. But some of the limitations of DNS > names and DNS lookup for such identifiers really can't be fixed. When you describe a usage scenario that is necessary for the desired functionality, and you can demonstrate the DNS will not satisfy that requirement, then we will have something concrete to discuss. Heck, I'm even glad to explore the DNS part before you explain how it can't work. > > > * They must be usable with TCP, SCTP, etc. without major changes > > > > ok, except as I noted, above. in other words, none of this mandates > > that the transports be changed. > > Even if you add a shim layer this does change the transports in > subtle ways. For instance you probably want to recompute RTT estimates This, of course, has nothing to do with the EID. In fact, the more that the EID is distinct from the IP locator (address) -- no matter how it is obtained or structured -- then the more likely the mixing of calculations such as RTT. There has been extensive discussion about this already, of course. > > > * The function that maps identifiers to addresses needs to be fast > > > > If you are suggesting that we have to do this better than the DNS, > > then you have moved into the area of long-term research. > > Not at all. In some sense, BGP maps identifiers to locations very > quickly. You are proposing global distribution of a mapping table, to provide fast lookup? (Nevermind that the table is not, in fact, distributed in its entirety. That's what the CIDR aggregation is for, after all.) Really, Keith, as long as this all stays so abstract, then of course you are right and of course I am right, although we completely disagree. > And we don't need long-term research to understand the effects > of different design choices for how we propagate information between > replicas and where the mappings are done - ordinary engineering analysis > is good enough for that, if we only bother to do it. Every single new system that has been deployed over the global Internet has displayed unexpected dynamics. So your confidence does not have any basis with which I am familiar. > > The only thing that mitigates against this is the distinction between > > public versus internal activity. If the activity must be between > > random hosts interacting for the first time, then we are in the realm > > of research. > > That's just handwaving on your part. On the contrary, it is a key point of distinction made in the MAST design. > > If we are in the realm of maintain an association that already exists > > between two hosts, then things like home agents and mapping agents > > provide adequate mechanisms that work internally to the association. > > We need to be able to maintain both kinds of mapping. yup. > > > DNS names are > > > * Incompatible with existing transport protocols. ... > A DNS name won't fit into an IP header or a TCP pseudo-header, and > IIRC SCTP can't redirect to a DNS name. Of course, that doesn't mean > you can't find a workaroud, it just means that they're not a drop-in fix, > as some people tend to assume. Ahh. So you are asserting a requirement that the EID be in every packet. Well, yes, that overhead would be intolerable. The only problem is that the basis for this requirement is pretty elusive. I keep hoping that there will be a clear and careful discussion of the reasons that the EID must be in every packet. MAST was specifically written as a counter-example. If it it unacceptably problematic, I really would like to know how. > > > * Ambiguous and overloaded. Quite often, a DNS name doesn't refer > > > to a host. > > > > This is true, but the reason this negates its use as an EID needs to > > be explained. As I have asked many times, there needs to be a > > description of a usage scenario that shows the problem. > > Basically the scenario is that a host or an app tries to use the same > DNS name in multiple contexts - one of which treats the DNS name as an > identifier for a resource that may have multiple instances, any of which > will do; and another treats the DNS name as an identifier for a specific > host which has a specific process listening on a specific socket, and Certainly the semantic distinctions you describe in usage do occur. The question is how this affects any real-world application's use for the current topic. Please provide a concrete example from the current applications world. > > Let me take the logic that you appear to be using and apply it in a > > different situation, to show the problem in your assertion: > > I believe that existing use of DNS is so widespread and entrenched > that it is very difficult to get people to change the way they use it. If we were talking about changing an existing style of usage, you might be right. But this is a new style. New use. > I also believe that people have a hard time using the same kind of > name at very different levels of specificity. We need different > syntactic conventions to indicate to people (this includes programmers) > the difference between a name of a resource and the name of a specific > host. When we start looking at specific name registration and usage activities, we can start discussing the specifics of the human factors. Otherwise, you are saying that the street address to a house needs to be different than the street address to a business, or else people will get confused. > In general, the claim is not that you cannot work around some, maybe > even most, of the problems associated with using DNS for endpoint IDs - > however, this list can serve as an attempt to list some of the obstacles > that you need to overcome to make such proposals viable. Discussing realistic obstacles is good. We need to do more of that. For example, folks need to consider the cost of creating and running an entirely new registration service, and then correlating it with other registrations, such as domain names -- what? you think that EIDs will be entirely independent of domain names? -- and IP Addresses. > > Again, this needs to distinguish between initial rendezvous, versus > > association maintenance. They have very different requirements and > > constraints. > I'm firmly convinced that DNS is too broken to fix for this. I won't > claim that you can't fix a lot of the problems but once you do, there's You have yet to describe any usage requirement -- other that the per-packet bogeyman -- that suggests anything is broken. Until we have the specific set of requirements -- and agreement that they are required -- we can't know whether the DNS is "broken" with respect to this (new) set of requirements. As to per-packet, I know that Vint is among those who believe it is important to have the association context independently stored in every packet. However I do not know why. > > > The mapping from domains to hosts is essentially > > > arbitrary. > > > > so? > > By arbitrary I mean (among other things) that you can have one domain > referring to multiple hosts, multiple domains referring to one host, > or more generally, an arbitrary mapping from domain names onto hosts, Oh. You mean that you can choose to create a set of registrations that will prevent use of the mechanisms under discussion? You mean, like, administrators will actually have to have some planning in the design of their domain naming scheme? Wow. Well, yes, that is certainly an unreasonable -- and definitely brand new -- requirement to impose on them. (Please forgive the sarcasm, but comparisons of costs really do need to be equally weighted.) > (Note that I didn't write this page as a specific response to MAST or to > any other proposal, I wrote it as a general response to the variety of > proposals Unfortunately, this sounds as if your assertion that DNS absolutely cannot be used does not factor in specific existing proposals or else is dismissing all such proposals without needing to formulate specific responses? Given that I still look to improve MAST, the specific responses would be helpful, as well as providing necessary substance to your claims. > > > * Not organized favorably. Existing DNS names are organized .... > > This could be an interesting point. Please describe an administrative > > operation that you believe is essential for EID use and cannot .... > I have a laptop that moves from one place to another on the net. It > should be able to keep the same EID no matter where it moves to. > However, various networks and the laptop's operating system conspire to > change the laptop's DNS name according to its location. Oh. You want to start using a very substantial and brand new capability, but have no configuration or software change? And since of course that is not what you mean, please note the following: 1. There is currently no way to perform the desired functionality. Anything that attempts to perform it will be new. It will require new software and will likely require new administration. How much of each is, of course, an essential point of distinction among proposals and needs to be discussed very carefully. 2. Hosts can have more than one domain name, as you have so carefully pointed out. So the fact that one of those names changes does not mean that the others must. 3. well, i know there is another point, but it eludes me, just now. > > > By contrast, users (and their hosts) are often actors in multiple > > > domains, sometimes concurrently. Insisting that an existing domain name > > > be tightly bound to such a host is unrealistic. > > > > I have no idea what operational problem you are trying to claim > > exists. > > Organizations have their names embedded in domain names (or > increasingly, the name of the organization is a domain name), and they > see their reputations tied up in those names. They don't want those > names associated with arbitrary activities. But a single host serves a > user in many different roles - we don't want to carry separate PDAs or > laptops for work and other purposes. This implies that organizational > DNS names aren't good choices for host EIDs. I understood every word you wrote and maybe even agree with each sentence, up to the last one, but I'm still missing the point. EID's can't be domain names because domain names can have human semantics and the EID usage might impact those semantics negatively? > May I suggest that though humans' expectations of DNS usage and behavior > are somewhat difficult to characterize (so they appear "abstract and > theory based"), we ignore them at our peril. Given my own activities with the DNS, I'm not likely to ignore its human factors. But, again, the way any of the EID usage might involve human factors is something that I am simply not yet seeing, any more than those lovely SRV record domain name references seem to have a human impact. > And may I also suggest that your own expectations of how people will use > DNS are also abstract and theory based, they just aren't well > articulated. Maybe you should try to state your assumptions rather than > attacking mine out-of-hand. I believe that most existing domain names can be used just fine for basic multiaddressing scenarios. Certainly for the classic client/server scenario. MAST-related discussions, have explored this. We can record a detailed example for this list, if that's needed. Advanced multiaddressing -- eg, simultaneous use of multiple paths for a multihomed host, rather than just using a primary with quick switchover -- probably needs new registrations. > > Adding names to the DNS is far easier than creating a whole new global > > registration infrastructure. Please don't seriously try to tell me > > that you disagree. > > I think you're mischaracterizing the difference. A lot of the baggage > associated with adding names to the DNS seems to be related to the fact > that existing DNS names are intended to be used by humans, and this > assumption goes all the way to the DNS root. OK. Feel free to describe an EID global registration service that is vastly simpler than the DNS and which will not incur any significant startup hassles. > Theoretically, we could create a new TLD for use in EIDs, and we could This would make sense if none of the existing tree could be used. If I want to access my server while I am mobile here is a basic scenario: The laptop does a classic DNS lookup and connects to the brandenburg.com server in the classic way. Either at the start of the session or sometime after the start, the capability to do mobility-based preservation of the connection is securely negotiated. The laptop uses a unique domain name, such as dave.brandenburg.com and the server retains the name it was contacted with. As the laptop moves around the Internet, it notifies the server of the new addresses. It does this using the pre-existing secure exchange mechanism. This works even when contact was lost and the laptop shows up with a brand new address. The pre-existing secure context (based on the client's and server's domain names) protect against the new IP Address being a redirection attack. None of this required new registration. In the case of a laptop that currently gets its domain name from DHCP, then yes it needs to obtain another, unique domain name that is stable. My IT department will be glad to supply it. So, Keith, what's wrong with this scenario? > So to me it really does look > easier to create a new infrastructure, one based on giving out numbers > rather than letting people fight over names. In some sense we create a > new infrastructure either way. Not hardly. There are minor matters, such as global authorization for the new system, that are quite different. Let's pretend that we are not talking about the difficulty of creating yet-another global registration service involving the challenges of the DNS. Let's pretend that it's no more complex than the IP Address global registration service. You think that creating one of those is no more difficult than creating a new TLD? (All of this assumes that that level of invention is needed. As I've tried to show in the above scnenario, it isn't.) > And again, I think if we use existing > delegations we encumber use of EIDs in various other ways, and make > them less reliable. Less "reliable"? What does that mean? The name drops packets? The name fails to retransmit them? The purpose of the EID is to be unique. Will the domain names used in this way fail to be unique? > > > Problems with using DNS lookup facilities > > > The DNS lookup service is > > > > > > * Slow. A substantial percentage of lookups take several seconds, > > > and many > > > > faster global lookup? research. > > Nope, that's just a handwaving dismissal on your part. BGP does it > quite well. BGP is a compressed table. Senders do not need to access all of the bits for an arbitrary address. This is possible because the bits are organized in a way that directly relates to the usage. That won't be true for an EID, because the EID is specifically NOT topologically related. So, you appear to be obtaining faster lookup by having everyone hold a complete table of Internet EIDs. d/ -- Dave Crocker Brandenburg InternetWorking From owner-ietf-aulli Thu Jan 8 21:49:02 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i095n2ib055822; Thu, 8 Jan 2004 21:49:02 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i095n26w055821; Thu, 8 Jan 2004 21:49:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i095mwib055810 for ; Thu, 8 Jan 2004 21:49:00 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 6E86AAFEAB; Fri, 9 Jan 2004 00:49:01 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10134-03; Fri, 9 Jan 2004 00:48:59 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 1427BAFCAA; Fri, 9 Jan 2004 00:48:53 -0500 (EST) In-Reply-To: <200418193628.917771@bbprime> References: <200418193628.917771@bbprime> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <90EF0F2D-4267-11D8-BE61-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit Cc: Keith Moore , From: Keith Moore Subject: Re: why DNS names make lousy endpoint identifiers Date: Fri, 9 Jan 2004 00:49:18 -0500 To: Dave Crocker X-Mailer: Apple Mail (2.609) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>> "used by" does not mean that it needs to be in each TCP segment and >>> might not mean that TCP even uses the string. >> >> No, it doesn't. In general, if you change some things about the >> current architecture, you might be able to provide better endpoint >> identifiers than can be currently provided by IP addresses. Clearly >> there are various ways to use DNS for this purpose, some of which are >> more sophisticated than others. But some of the limitations of DNS >> names and DNS lookup for such identifiers really can't be fixed. > > When you describe a usage scenario that is necessary for the desired > functionality, and you can demonstrate the DNS will not satisfy that > requirement, then we will have something concrete to discuss. Call completion times can't be limited to a few milliseconds if the DNS lookups themselves take tens of milliseconds, and sometimes tens of seconds to complete (as DNS lookups often do). Maybe providers don't care about call completion times anymore, but old telephony providers used to care, and there are still some good reasons for them to care (for instance, emergency service). Massively parallel high performance computations being conducted over WANs incur unacceptably large delays (relative to the amount of computation that could be performed and/or the amount of data that could be transferred during that time) if their rendezvous operations (e.g. barrier operations) must wait tens of milliseconds or longer for DNS lookups to complete. >>>> * They must be usable with TCP, SCTP, etc. without major changes >>> >>> ok, except as I noted, above. in other words, none of this mandates >>> that the transports be changed. >> >> Even if you add a shim layer this does change the transports in >> subtle ways. For instance you probably want to recompute RTT >> estimates > > This, of course, has nothing to do with the EID. In fact, the more > that the > EID is distinct from the IP locator (address) -- no matter how it is > obtained > or structured -- then the more likely the mixing of calculations such > as RTT. > There has been extensive discussion about this already, of course. I'm not sure what you mean by that, and I don't recall participating in those discussions. >>>> * The function that maps identifiers to addresses needs to be fast >>> >>> If you are suggesting that we have to do this better than the DNS, >>> then you have moved into the area of long-term research. >> >> Not at all. In some sense, BGP maps identifiers to locations very >> quickly. > > You are proposing global distribution of a mapping table, to provide > fast > lookup? Yes, though not of the complete mapping table from EIDs to hosts. I'm proposing that EIDs have a structure similar to IP addresses (so that routes can be advertised for EID prefixes, and those routes can be aggregated), that EID-to-hostname lookups be a side-effect of sending a packet from the periphery of the network to the EID as a destination address (rather than having EID-to-hostname lookups explicitly done by the sending host). In a way this is similar to mobile IP home agents, except that an EID mapping server would operate on behalf of an entire EID prefix (and they could perhaps issue redirects for prefixes), though the mapping servers don't necessarily have to absorb the burden of forwarding packets sent their way (it would be convenient if they could do so in some cases). > Really, Keith, as long as this all stays so abstract, then of course > you are > right and of course I am right, although we completely disagree. And if I specify details, then the details can be shot down and the approach discredited, even though the general approach might be valid and workable with somewhat different details. To me it really seems premature to try to specify things in detail except as a proof-of-concept. We don't have a good problem definition yet. >> And we don't need long-term research to understand the effects >> of different design choices for how we propagate information between >> replicas and where the mappings are done - ordinary engineering >> analysis >> is good enough for that, if we only bother to do it. > > Every single new system that has been deployed over the global > Internet has > displayed unexpected dynamics. It's not possible to anticipate all unintended consequences of any new system. (That's as true of MAST as anything else). That doesn't mean that we should dismiss any new idea as unworkable or farfetched. It is possible to gain confidence in how a new system employing these ideas will operate via engineering analysis and small-scale experiments, without requiring long-term research. >>> The only thing that mitigates against this is the distinction >>> between >>> public versus internal activity. If the activity must be between >>> random hosts interacting for the first time, then we are in the >>> realm >>> of research. >> >> That's just handwaving on your part. > > On the contrary, it is a key point of distinction made in the MAST > design. The distinction is a useful one. The assertion that interaction between random hosts is in the realm of research is the handwaving part. >>>> DNS names are >>>> * Incompatible with existing transport protocols. > ... >> A DNS name won't fit into an IP header or a TCP pseudo-header, and >> IIRC SCTP can't redirect to a DNS name. Of course, that doesn't mean >> you can't find a workaroud, it just means that they're not a drop-in >> fix, >> as some people tend to assume. > > Ahh. So you are asserting a requirement that the EID be in every > packet. > Well, yes, that overhead would be intolerable. Well, it depends on how you define EIDs, doesn't it? But no, I'm not even assuming that. What I'm assuming is that if you want an EID that drops in without any changes to TCP, then the EID is in every packet, because TCP is designed and implemented with the assumption that the current endpoint identifier (IP address) is in every packet, because TCP apps assume that IP addresses of the endpoints have various properties (they cannot simply be randomly chosen without breaking apps) and the EIDs would have to provide that functionality. Any system that broke these assumptions would not be a drop-in replacement for TCP. > The only problem is that the basis for this requirement is pretty > elusive. > > I keep hoping that there will be a clear and careful discussion of the > reasons > that the EID must be in every packet. I certainly don't think it has to be in every packet. I do think that if the EID isn't in every packet, it forces some changes to TCP and SCTP and higher-layer apps. Those changes might be acceptable, but we want to think about the programming model and how much we want to impact existing apps. >>>> * Ambiguous and overloaded. Quite often, a DNS name doesn't refer >>>> to a host. >>> >>> This is true, but the reason this negates its use as an EID needs to >>> be explained. As I have asked many times, there needs to be a >>> description of a usage scenario that shows the problem. >> >> Basically the scenario is that a host or an app tries to use the same >> DNS name in multiple contexts - one of which treats the DNS name as >> an >> identifier for a resource that may have multiple instances, any of >> which >> will do; and another treats the DNS name as an identifier for a >> specific >> host which has a specific process listening on a specific socket, and > > Certainly the semantic distinctions you describe in usage do occur. > The > question is how this affects any real-world application's use for the > current > topic. Of course it does. > Please provide a concrete example from the current applications world. An NFS client opens up a TCP connection to the domain name of a file server, which maps to multiple IP addresses. At some point the address associated with that connection changes, maybe because the server moved, maybe because the destination network renumbered. The client host attempts to re-establish the connection to the server, using DNS to do the lookup, but this time it gets a different server host (that provides access to the same set of files). It can't resume the TCP connection, and the file handle is invalid, because both of these were only meaningful to that specific server host. A NetSolve server is running a computation on behalf of a client. During the time that the computation is taking place, the client's IP address changes. The server cannot contact the client to inform the client of the completion of that computation and to return the results to the client, because the client's DNS name (if it has one) was associated with the client's IP address, not with the client itself. (this is quite common). It is not an exaggeration to say that any change we make to the way hosts are referred to by applications, at any layer of the protocol stack, will break some applications - especially if we try to overload new functionality onto the existing APIs. What we really need to understand is how to accommodate the needs of various kinds of applications, and how to allow them to transition to an environment where IP addressing isn't as stable as originally assumed. >>> Let me take the logic that you appear to be using and apply it in a >>> different situation, to show the problem in your assertion: >> >> I believe that existing use of DNS is so widespread and entrenched >> that it is very difficult to get people to change the way they use >> it. > > If we were talking about changing an existing style of usage, you > might be > right. But this is a new style. New use. I believe that the existing use of DNS will make substantially new uses difficult, as DNS implementations and infrastructure and human users have all become highly adapted to existing uses. >> I also believe that people have a hard time using the same kind of >> name at very different levels of specificity. We need different >> syntactic conventions to indicate to people (this includes >> programmers) >> the difference between a name of a resource and the name of a >> specific >> host. > > When we start looking at specific name registration and usage > activities, we > can start discussing the specifics of the human factors. The effect on humans will certainly vary according to those specifics. But if we don't utilize the existing DNS servers and delegation infrastructure (and there are good reasons to not do so) then there is far less advantage to using DNS. >> In general, the claim is not that you cannot work around some, maybe >> even most, of the problems associated with using DNS for endpoint >> IDs - >> however, this list can serve as an attempt to list some of the >> obstacles >> that you need to overcome to make such proposals viable. > > Discussing realistic obstacles is good. We need to do more of that. > > For example, folks need to consider the cost of creating and running an > entirely new registration service, and then correlating it with other > registrations, such as domain names Note that the cost of that service will also vary according to the specifics of that service. To speculate about the cost without having any idea of what that service looks like is - well, speculative. > -- what? you think that EIDs will be > entirely independent of domain names? if they're done right. >>> Again, this needs to distinguish between initial rendezvous, versus >>> association maintenance. They have very different requirements and >>> constraints. > > >> I'm firmly convinced that DNS is too broken to fix for this. I won't >> claim that you can't fix a lot of the problems but once you do, >> there's > > You have yet to describe any usage requirement -- other that the > per-packet > bogeyman -- that suggests anything is broken. Dave, I've brought these requirements up many times in different discussions. Perhaps you missed those discussions. What I found in those discussions is that people (perhaps not you) are capable of dismissing anything that doesn't fit their world view, as irrelevant, no matter how much support is given. e.g. "no such app exists that works this way" "here's the web page describing one app that does, with references to papers, and here's the source code". "well, nobody uses that app anyway" "actually that app is used for very large scale computations involving computational fluid dynamics, climate modeling, etc., and these are important problems" "well, apps shouldn't work that way" "who are you to say how apps should work?" Frankly I'm already burned out from having those conversations. But this is a new discussion, and some of us probably weren't in on those conversations. It's reasonable to want some concrete examples, and I'll try find time to work up a list (or find one that I've already worked up and posted to some other list). What is not reasonable is to dismiss those examples (once they are provided) as irrelevant, or to try to generalize the needs of all applications from a small sample space. > Until we have the specific set > of requirements -- and agreement that they are required -- we can't > know > whether the DNS is "broken" with respect to this (new) set of > requirements. "Requirements" is the wrong tack. This is a pitfall many groups fall into. We need first a problem definition and design goals. It's way too early to nail down requirements, and the hard-and-fast requirements don't bound the problem adequately anyway. A successful design is one that satisfies most of the goals while meeting all of the requirements (if indeed there are any that can be agreed on). If you try to nail down requirements first the tendency is to overstate goals as requirements, which is counterproductive since you often have to compromise about the degree to which different goals are met. It's much easier to start treating desirable features as only goals, and only labeling a subset of those goals as requirements once it becomes clear that they really are absolutes. If you focus too early on the hard-and-fast requirements it's easy to lose sight of the overall goals, and you can't reasonably evaluate a solution by looking only at whether it meets the requirements anyway. >>>> The mapping from domains to hosts is essentially >>>> arbitrary. >>> >>> so? >> >> By arbitrary I mean (among other things) that you can have one domain >> referring to multiple hosts, multiple domains referring to one host, >> or more generally, an arbitrary mapping from domain names onto hosts, > > Oh. You mean that you can choose to create a set of registrations > that will > prevent use of the mechanisms under discussion? No, I'm saying that existing uses of DNS conflict with use of DNS for the mechanisms under discussion. (perhaps not in an absolute sense of preventing such use, but in the sense that DNS as currently deployed is sub-optimal for the new use.) And if you propose to use a different set of DNS names for these mechanisms, with infrastructure that is optimal for the new use, then there's less advantage to using DNS than it might initially seem to a reader. In a sense it just means that people need to be careful about assumptions they make when they evaluate proposals like MAST, as it's easy to make assumptions about how MAST will use DNS based on how DNS is currently used/managed/provisioned, how DNS servers work, how the names are delegated, etc. >> (Note that I didn't write this page as a specific response to MAST >> or to >> any other proposal, I wrote it as a general response to the variety >> of >> proposals > > Unfortunately, this sounds as if your assertion that DNS absolutely > cannot be > used I didn't say that. I said that DNS names are lousy endpoint identifiers. I stand by that assertion. > Given that I still look to improve MAST, the specific responses would > be > helpful, as well as providing necessary substance to your claims. I'll reread MAST (making sure I've read the current version) and consider providing specific comments about that proposal. >>>> * Not organized favorably. Existing DNS names are organized > .... >>> This could be an interesting point. Please describe an >>> administrative >>> operation that you believe is essential for EID use and cannot > .... >> I have a laptop that moves from one place to another on the net. It >> should be able to keep the same EID no matter where it moves to. >> However, various networks and the laptop's operating system conspire >> to >> change the laptop's DNS name according to its location. > > Oh. You want to start using a very substantial and brand new > capability, but > have no configuration or software change? nope. but a lot of people seem to assume that if we "just use DNS" then this will be the case. > And since of course that is not what you mean, please note the > following: > > 1. There is currently no way to perform the desired functionality. > Anything > that attempts to perform it will be new. It will require new software > and > will likely require new administration. How much of each is, of > course, an > essential point of distinction among proposals and needs to be > discussed very > carefully. agree. > 2. Hosts can have more than one domain name, as you have so carefully > pointed > out. So the fact that one of those names changes does not mean that > the > others must. agree. and no matter what EIDs end up looking like, hosts will need to be much more aware of EIDs (and at deeper levels) than they are currently of DNS names, and hosts and apps will have to exercise more discipline about use of EIDs than they currently exercise about DNS names. >>>> By contrast, users (and their hosts) are often actors in multiple >>>> domains, sometimes concurrently. Insisting that an existing domain >>>> name >>>> be tightly bound to such a host is unrealistic. >>> >>> I have no idea what operational problem you are trying to claim >>> exists. >> >> Organizations have their names embedded in domain names (or >> increasingly, the name of the organization is a domain name), and >> they >> see their reputations tied up in those names. They don't want those >> names associated with arbitrary activities. But a single host >> serves a >> user in many different roles - we don't want to carry separate PDAs >> or >> laptops for work and other purposes. This implies that >> organizational >> DNS names aren't good choices for host EIDs. > > I understood every word you wrote and maybe even agree with each > sentence, up > to the last one, but I'm still missing the point. EID's can't be > domain names > because domain names can have human semantics and the EID usage might > impact > those semantics negatively? I'm not sure how else to say it. If EIDs have human-meaningful components that are associated with organizations and enterprises, this conflicts with the desire to have EIDs stably bound to hosts that are used in multiple roles. >> May I suggest that though humans' expectations of DNS usage and >> behavior >> are somewhat difficult to characterize (so they appear "abstract and >> theory based"), we ignore them at our peril. > > Given my own activities with the DNS, I'm not likely to ignore its > human > factors. But, again, the way any of the EID usage might involve human > factors > is something that I am simply not yet seeing, any more than those > lovely SRV > record domain name references seem to have a human impact. well, the last N-2 components of SRV records do tend to be human meaningful, and people do make inferences about the services pointed to by SRV records based on the human meanings of those last components. >> And may I also suggest that your own expectations of how people will >> use >> DNS are also abstract and theory based, they just aren't well >> articulated. Maybe you should try to state your assumptions rather >> than >> attacking mine out-of-hand. > > I believe that most existing domain names can be used just fine for > basic > multiaddressing scenarios. Perhaps this is true (because most existing domain names aren't bound to multiple addresses), but that is a long way from saying that applications can assume that most existing domain names can be used, and it's an even longer way from saying that most existing domain names have the other properties desired of EIDs. > Certainly for the classic client/server scenario. > MAST-related discussions, have explored this. We can record a detailed > example > for this list, if that's needed. Client/server is only one scenario. It's the easiest one to analyze, but it's not the only one we want to support. > Advanced multiaddressing -- eg, simultaneous use of multiple paths > for a > multihomed host, rather than just using a primary with quick > switchover -- > probably needs new registrations. And software needs to be able to tell when to handle that case differently. >>> Adding names to the DNS is far easier than creating a whole new >>> global >>> registration infrastructure. Please don't seriously try to tell me >>> that you disagree. >> >> I think you're mischaracterizing the difference. A lot of the >> baggage >> associated with adding names to the DNS seems to be related to the >> fact >> that existing DNS names are intended to be used by humans, and this >> assumption goes all the way to the DNS root. > > OK. Feel free to describe an EID global registration service that is > vastly > simpler than the DNS and which will not incur any significant startup > hassles. As a first approximation - you get EIDs in approximately the same way you get registered IPv6 address blocks. You can either get them from a provider of redirection services, or you can get your own block but the prefixes won't be routable on the public network. Actually we could use IPv6 addresses as EIDs. >> Theoretically, we could create a new TLD for use in EIDs, and we >> could > > This would make sense if none of the existing tree could be used. > > If I want to access my server while I am mobile here is a basic > scenario: > > The laptop does a classic DNS lookup and connects to the > brandenburg.com > server in the classic way. > > Either at the start of the session or sometime after the start, the > capability > to do mobility-based preservation of the connection is securely > negotiated. > The laptop uses a unique domain name, such as dave.brandenburg.com and > the > server retains the name it was contacted with. > > As the laptop moves around the Internet, it notifies the server of the > new > addresses. It does this using the pre-existing secure exchange > mechanism. > This works even when contact was lost and the laptop shows up with a > brand new > address. The pre-existing secure context (based on the client's and > server's > domain names) protect against the new IP Address being a redirection > attack. Yes, this will work for the specific scenario you described. One thing it won't handle is the case where multiple endpoints move concurrently. Nor will it handle the case where the server has multiple addresses. >> So to me it really does look >> easier to create a new infrastructure, one based on giving out >> numbers >> rather than letting people fight over names. In some sense we >> create a >> new infrastructure either way. > > Not hardly. There are minor matters, such as global authorization for > the new > system, that are quite different. There certainly are some differences, but it's not as if one can be dismissed as inherently easier than the other. > Let's pretend that we are not talking about the difficulty of creating > yet-another global registration service involving the challenges of > the DNS. > Let's pretend that it's no more complex than the IP Address global > registration service. yes, lets. > You think that creating one of those is no more difficult than > creating a new > TLD? IPv6 is doing it, so we'll find out. And since it appears to me that we can use IPv6 addresses for EIDs anyway, I don't see this registration as a huge problem. Of course, we've been surprised before. >> And again, I think if we use existing >> delegations we encumber use of EIDs in various other ways, and make >> them less reliable. > > Less "reliable"? What does that mean? The name drops packets? The > name > fails to retransmit them? The DNS servers and the networks supporting them become even more significant sources of failure than they are now. > The purpose of the EID is to be unique. That's not the only purpose. We need EIDs that can be used for rendezvous also. Unique names are easy - public keys suffice for those. >>>> Problems with using DNS lookup facilities >>>> The DNS lookup service is >>>> >>>> * Slow. A substantial percentage of lookups take several seconds, >>>> and many >>> >>> faster global lookup? research. >> >> Nope, that's just a handwaving dismissal on your part. BGP does it >> quite well. > > BGP is a compressed table. Senders do not need to access all of the > bits for > an arbitrary address. This is possible because the bits are organized > in a > way that directly relates to the usage. > > That won't be true for an EID, because the EID is specifically NOT > topologically related. So, you appear to be obtaining faster lookup > by having > everyone hold a complete table of Internet EIDs. No matter what kind of EID you have, if you want to allow a host to contact the host with that EID then the host wanting to establish contact has to send a message to a server that knows the current location of the host with the EID. One way to do this is to do a DNS lookup of the EID. Another way is to use BGP to advertise routing from EID prefixes to those servers. Either way provides the desired result, but BGP does it much faster and more reliably - provided, of course, that the BGP table is small enough to be kept in routers, and that the routing computation for those prefixes is not onerous. From owner-ietf-aulli Fri Jan 9 11:50:47 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i09Jolib069609; Fri, 9 Jan 2004 11:50:47 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i09JolxI069608; Fri, 9 Jan 2004 11:50:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i09Jokib069603 for ; Fri, 9 Jan 2004 11:50:46 -0800 (PST) (envelope-from dhc@dcrocker.net) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i09JwNc25206; Fri, 9 Jan 2004 11:58:23 -0800 From: Dave Crocker To: CC: X-Mailer: PocoMail 3.03 (1740) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Date: Fri, 9 Jan 2004 11:50:37 -0800 Message-ID: <200419115037.715289@bbprime> In-Reply-To: <90EF0F2D-4267-11D8-BE61-000393DB5366@cs.utk.edu> Subject: EID requirements and issues Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (I've changed the subject line because I think we are finally starting to get into some issues that can be discussed among the group. Let me encourage others to validate this by posting comments. /d) Keith, > > When you describe a usage scenario that is necessary for the desired > > functionality, and you can demonstrate the DNS will not satisfy that > > requirement, then we will have something concrete to discuss. > > Call completion times can't be limited to a few milliseconds if the DNS > lookups themselves take tens of milliseconds, and sometimes tens of Let's distinguish between domain names as unique identifiers and domain names as referents to IP Addresses. The referral function requires the lookup. The uniqueness function does not. The usage being discussed in this thread is identification. So, lookup latencies are not a factor. To the extent that lookup _is_ an issue I am still not understanding what global lookup service you are proposing that will do better than DNS, but that's a different thread. Saying "BGP" does not resolve the considerable disparities between the real world of BGP and the service environment needed for EIDs. > > In fact, the more that the EID is distinct from the IP locator (address) > > -- no matter how it is obtained or structured -- then the more likely the > > mixing of calculations such as RTT. There has been extensive discussion > > about this already, of course. > > I'm not sure what you mean by that, and I don't recall participating in > those discussions. A challenge in this realm of the IETF has been the number of different venues for discussion, as well as the number of proposals This topic particularly came up during discussions of the SLAP proposal, I believe on the multi6 mailing list, 15-19 November. It occurs to me that we do need to be some incremental review of that history, given that this is a new mailing list with new participants. (Given the number of interesting and different proposals and the number of discussion venues, this is going to be challenge. Think of it as a separate thread, needing several folks with the history to contribute over time.) At base, there are "identifications" that transports perform currently using IP Addresses, and there are "performance-related" functions, notably congestion control and reliability problem detection and recovery. Any scheme that aggregates different paths and makes them invisible to transport may seriously impact the performance functions, as you note. Immediate requirements for both mobility and multihoming can live with the restriction of using one locator(IP Address) and keeping others only for backup. This avoids having to deal with the aggregation impact on performance mechanism. This has nothing to do with the nature of the particular EID string that is used! It has to do with the EID's effect of obscuring differential performance through different paths (represented by different source and/or destination IP Addresses.) > > You are proposing global distribution of a mapping table, to provide > > fast lookup? > > Yes, though not of the complete mapping table from EIDs to hosts. I'm > proposing that EIDs have a structure similar to IP addresses (so that > routes can be advertised for EID prefixes, and those routes can be > aggregated), I cannot guess how this would be meaningfully different from the existing IP Address scheme. You are saying that EIDs would be topologically related and that is _exactly_ what they must _not_ do. They must not be tied to routing. And it's fine for you to disagree, but further consideration of what you are proposing requires you to present far more detail, so it can be evaluated on the specifics. > that EID-to-hostname lookups be a side-effect of sending a > packet from the periphery of the network to the EID as a destination > address (rather than having EID-to-hostname lookups explicitly done by > the sending host). So, this is not a global lookup service, but a mapping that is created by interaction between the endpoints? If so, then please comment on the MAST proposal, which provides exactly this sort of mechanism. This sort of approach does not have the third-party lookup latencies, but the design of it can still delay start of application exchange, if the mechanism must take place during association startup. At a minimum, that's a round-trip latency. > > Really, Keith, as long as this all stays so abstract, then of course > > you are > > right and of course I am right, although we completely disagree. > > And if I specify details, then the details can be shot down and the > approach discredited, even though the general approach might be valid > and workable with somewhat different details. To me it really seems > premature to try to specify things in detail except as a > proof-of-concept. We don't have a good problem definition yet. Yes, it is always disquieting to have to provide specifics so that people can do concrete analysis of them. At any rate, please note that this thread began with your deciding to shoot down a specific design choice. If you want to back things up and worry first about 'requirements', 'goals' or the like, that's fine. > > Every single new system that has been deployed over the global > > Internet has displayed unexpected dynamics. > > It's not possible to anticipate all unintended consequences of any new > system. (That's as true of MAST as anything else). That doesn't > mean that we should dismiss any new idea as unworkable or farfetched. > It is possible to gain confidence in how a new system employing these > ideas will operate via engineering analysis and small-scale > experiments, without requiring long-term research. I think you are suggesting an activity that belongs in the IRTF, not the IETF. Yes, I know you do not want to call it research, but that is what you are proposing. It certainly means there will not be any usable spec for at least 5 years. > > > The only thing that mitigates against this is the distinction between > > > public versus internal activity. If the activity must be between > > > random hosts interacting for the first time, then we are in the realm > > > of research. >... > The distinction is a useful one. The assertion that interaction > between random hosts is in the realm of research is the handwaving > part. If that were what I said, I'd agree with you. However the issue that you are raising is public (global) initial contact that involves a mapping effort that works better than the DNS. That's rather more specific than any old "interaction between random hosts." Let's not lose the context. > > Ahh. So you are asserting a requirement that the EID be in every > > packet. Well, yes, that overhead would be intolerable. > > Well, it depends on how you define EIDs, doesn't it? No. It depends on you you _use_ them. > But no, I'm not even assuming that. What I'm assuming is that if you > want an EID that drops in without any changes to TCP, then the EID is Let's skip over the fact that your assumption is not automatically correct and that, instead, it may be correct for some aspects of the problem, but essentially impossible for other aspects. The differences between - EID for rendezvous at the start of an association, - EID for rendezvous during an association, and - EID for unique identification as part of regular data exchange during an association are fundamental. The "invisible to TCP" requirement turns out to have multiple faces. You highlighted the performance impact that comes from IP Address aggregation. Rendezvous is another. At the start of an association, we have an existing mechanism that works well, namely the DNS I hope you are not proposing to change it. The third-party agent (eg, home agent) approach works fine for rendezvous needed to recover from disruption of an existing association. However the interaction characteristics of this do not constrain design choices of the EID. Domain names work fine. (Actually, the real work for this recovery situation is done by a security string or mechanism that is internal to the association.) > in every packet, because TCP is designed and implemented with the > assumption that the current endpoint identifier (IP address) is in > every packet, because TCP apps assume that IP addresses of the > endpoints have various properties (they cannot simply be randomly > chosen without breaking apps) and the EIDs would have to provide that > functionality. Any system that broke these assumptions would not be a > drop-in replacement for TCP. The EID usage you cite is for connection identification. Interestingly, the identifiers only need to work internally to the host, rather than between association participants or more publicly. This permits what I believe Bellovin called "Host NAT". Several proposals provide this sort of private mapping. (MAST is one of them) Yes it needs to look like an IP Address and yes it needs to be transparent to transport, for identification functions. But it can be done by a mapping function that is internal to the endpoint. > > I keep hoping that there will be a clear and careful discussion of the > > reasons that the EID must be in every packet. > > I certainly don't think it has to be in every packet. I do think that > if the EID isn't in every packet, it forces some changes to TCP and > SCTP and higher-layer apps. Multiple proposals manage to take care of this without making the changes you believe are needed. Besides general interest, I'm particularly interested to know what the problems are with this, since MAST is one of those proposals. > An NFS client opens up a TCP connection to the domain name of a file > server, which maps to multiple IP addresses. At some point the address > associated with that connection changes, maybe because the server > moved, maybe because the destination network renumbered. The client > host attempts to re-establish the connection to the server, using DNS > to do the lookup, but this time it gets a different server host (that > provides access to the same set of files). It can't resume the TCP > connection, and the file handle is invalid, because both of these were > only meaningful to that specific server host. Here's the problem: "The client host attempts to re-establish the connection to the server". From a transport standpoint, this is a new association. I do not know of any proposal that seeks to provide continuity across different associations. They seek to provide continuity _within_ an association. To date, that has meant continuity within a single transport connection. So, the scenario you describe does not appear to be within the purview of any existing or planned work. That said, we can start playing with distinctions between "association" and "transport connection" in order to have the same association provide the same endpoints across multiple transport connections. Yes, having an EID in every packet is one way to do this. So is caching of association information in the endpoints, to be used for new transport activities. All of the shim models would accomplish this. > A NetSolve server is running a computation on behalf of a client. > During the time that the computation is taking place, the client's IP > address changes. The server cannot contact the client to inform the > client of the completion of that computation and to return the results > to the client, because the client's DNS name (if it has one) was > associated with the client's IP address, not with the client itself. > (this is quite common). If this is another example of the above behavior, the answer is the same. But let's move to the case that there is a continuing association but the infrastructure is changing the address, due to multihoming failover or mobility transition. So the goal is to preserve an existing association. The shim and transport-based proposals all do a mapping from an application-level string (which looks like an IP Address and might even be one) to an actual IP Address. The question is whether the pool of actual addresses only points to one endpoint. And the answer is yes, because that is what each of the proposals is designed to do. > > > I believe that existing use of DNS is so widespread and entrenched > > > that it is very difficult to get people to change the way they use it. > > > > If we were talking about changing an existing style of usage, you > > might be right. But this is a new style. New use. > > I believe that the existing use of DNS will make substantially new uses > difficult, as DNS implementations and infrastructure and human users > have all become highly adapted to existing uses. Stated that abstractly it is certainly true, and certainly false. It of course depends upon what the particular new behaviors/uses are. > But if we don't utilize the existing DNS servers and delegation > infrastructure (and there are good reasons to not do so) then there is > far less advantage to using DNS. We agree. That's why I want to re-use them, rather than invent a whole new infrastructure. > > For example, folks need to consider the cost of creating and running an > > entirely new registration service, and then correlating it with other > > registrations, such as domain names > > Note that the cost of that service will also vary according to the > specifics of that service. To speculate about the cost without having > any idea of what that service looks like is - well, speculative. If we are talking about the cost of _any_ global infrastructure that requires registration, we know that the required, basic cost is enormous. That is one reason there is so much interest in the statistically unique strings that are generated without registration. It is also why some of us try to distinguish between initial, rendezvous use, versus use that is internal to the communicating endpoints. These eliminates the need for global registration. > > Until we have the specific set of requirements -- and agreement that > > they are required -- we can't know > > whether the DNS is "broken" with respect to this (new) set of > > requirements. > > "Requirements" is the wrong tack. This is a pitfall many groups fall > into. We need first a problem definition and design goals. I don't like the word requirement, either. "Problem def and Design goals" is better. > No, I'm saying that existing uses of DNS conflict with use of DNS for > the mechanisms under discussion. Given that there exist quite a few proposals and that some of them use DNS, please explain how these proposals are flawed. > > Oh. You want to start using a very substantial and brand new > > capability, but have no configuration or software change? > > nope. but a lot of people seem to assume that if we "just use DNS" > then this will be the case. As much as I disagree with many aspects of most other proposals, everyone who is active in this arena seems to be pretty careful about what they say, and about claims and requirements. Hence the debate usually is about real and basic paradigm issues, rather than distortions, misunderstandings or trivializations. So I do not know who the "a lot of people" might be. > I'm not sure how else to say it. If EIDs have human-meaningful > components that are associated with organizations and enterprises, this > conflicts with the desire to have EIDs stably bound to hosts that are > used in multiple roles. Organizations support multiple naming schemas quite handily. And someone has to do the administration. Delegating leaf administration to organizations scales nicely. So I have no idea what alternative you have in mind that we know will scale well. > > Given my own activities with the DNS, I'm not likely to ignore its > > human factors. But, again, the way any of the EID usage might involve > > human factors > > is something that I am simply not yet seeing, any more than those > > lovely SRV record domain name references seem to have a human impact. > > well, the last N-2 components of SRV records do tend to be human > meaningful, and people do make inferences about the services pointed to > by SRV records based on the human meanings of those last components. No doubt this has relevance to the use of these strings as EIDs, but this level of discussion affords me no insight. > > Certainly for the classic client/server scenario. > > MAST-related discussions, have explored this. We can record a detailed > > example for this list, if that's needed. > > Client/server is only one scenario. It's the easiest one to analyze, > but it's not the only one we want to support. That's why I used the word "basic". When you describe a scenario that we know we must support and which cannot be supported by one or another of the existing proposals, then we will have something concrete to discuss. > > OK. Feel free to describe an EID global registration service that is > > vastly > > simpler than the DNS and which will not incur any significant startup > > hassles. > > As a first approximation - you get EIDs in approximately the same way > you get registered IPv6 address blocks. You can either get them from > a provider of redirection services, or you can get your own block but > the prefixes won't be routable on the public network. Actually we > could use IPv6 addresses as EIDs. And some proposals suggest that. But all you are describing is a globally hierarchical registration and delegation service. And that's what existing IP Address and DNS administrative mechanisms provide. It appears that either you are suggesting re-using an existing one -- and that's what I am proposing -- or creating a new, third scheme. The cost of a new, third scheme is huge. > Yes, this will work for the specific scenario you described. One thing > it won't handle is the case where multiple endpoints move concurrently. > Nor will it handle the case where the server has multiple addresses. Yes, Mutual Mobility requires a stable, third-party rendezvous service, a la home agents, mapping agents, etc. However we need to note that server mobility is not a pressing, near-term requirement. It's clear we want it for the long term, but it is not needed to obtain initial utility for the scenarios that people _do_ want to support right now. > > > In some sense we create a new infrastructure either way. > > > > Not hardly. There are minor matters, such as global authorization for > > the new system, that are quite different. > > There certainly are some differences, but it's not as if one can be > dismissed as inherently easier than the other. Go get a block of 10 telephone numbers from the current registration service and that you will use in some new, clever way. Then go and create a brand new, global registration service to assign 10 numbers. I think it is entirely reasonable to make a blanket statement that the latter is massively more difficult and expensive. > > Let's pretend that we are not talking about the difficulty of creating > > yet-another global registration service involving the challenges of > > the DNS. > > Let's pretend that it's no more complex than the IP Address global > > registration service. > > yes, lets. > > > You think that creating one of those is no more difficult than > > creating a new TLD? > > IPv6 is doing it, so we'll find out. They are creating a new set of bits to be registered, but they are using an existing registration service. The new set of bits have quite a bit of registration similarity to the existing set. Hence the incremental cost of adding the ability to register this new set of strings is relatively modest. (And we can all skip over the irony of calling it modest.) So you are postulating that this new set of bits that are completely independent of IP Addresses and Domain Names will be administered by an existing registration service? > And since it appears to me that > we can use IPv6 addresses for EIDs anyway, I don't see this > registration as a huge problem. Of course, we've been surprised > before. Oh. You want to preclude IPv4 use. I don't. However the LIN6 proposal is an excellent example of going down this path with a good specifcation. I suppose HIP is also an example, though its details are much more complicated. But then, it does provide a means of supporting IPv4. > > Less "reliable"? What does that mean? The name drops packets? The > > name fails to retransmit them? > > The DNS servers and the networks supporting them become even more > significant sources of failure than they are now. It is certainly true that using DNS lookups as part of a multiaddressing service will require depending on DNS lookups to work. Yes, this is architecturally significant. However, folks might have noticed that the Internet is not practically usable without the DNS already. (Just to be architecturally pure, my own view is that we should not change IP at all. Not one little bit. It works too well to burden with more mechanism. Hence the choice is between a module between IP and transport, versus modifying transport.) In any event, when you define a lookup service that does not have this dependency problem, we can discus it. > > The purpose of the EID is to be unique. > > That's not the only purpose. We need EIDs that can be used for > rendezvous also. Unique names are easy - public keys suffice for > those. "Used for"? If you mean the EID needs to have information encoded into it that permits rendezvous without a mapping service, then no. If you mean that an EID needs to be usable by a rendezvous service, then that is not a different "purpose". It is an application of a string that satisfies that purpose. The EID does not do the rendezvous. All it "does" is provide unique identification. > No matter what kind of EID you have, if you want to allow a host to > contact the host with that EID then the host wanting to establish > contact has to send a message to a server that knows the current > location of the host with the EID. One way to do this is to do a DNS > lookup of the EID. Another way is to use BGP to advertise routing from > EID prefixes to those servers. Either way provides the desired result, > but BGP does it much faster and more reliably - provided, of course, > that the BGP table is small enough to be kept in routers, and that the > routing computation for those prefixes is not onerous. You keep citing BGP as if the citation solves a problem. However I've noted that BGP has encoding and usage characterics that do not work for the kinds of EID usage folks are discussing. d/ -- Dave Crocker Brandenburg InternetWorking From owner-ietf-aulli Fri Jan 9 13:17:52 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i09LHqib073947; Fri, 9 Jan 2004 13:17:52 -0800 (PST) (envelope-from owner-ietf-aulli@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i09LHqhH073946; Fri, 9 Jan 2004 13:17:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-aulli@mail.imc.org using -f Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i09LHmib073940 for ; Fri, 9 Jan 2004 13:17:51 -0800 (PST) (envelope-from moore@cs.utk.edu) Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 1CD13AFF3D; Fri, 9 Jan 2004 16:17:50 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32575-13; Fri, 9 Jan 2004 16:17:47 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id CCE6BAFEDD; Fri, 9 Jan 2004 16:17:47 -0500 (EST) Date: Fri, 9 Jan 2004 16:17:47 -0500 From: Keith Moore To: Dave Crocker Cc: moore@cs.utk.edu, ietf-aulli@imc.org Subject: Re: EID requirements and issues Message-Id: <20040109161747.63bc101a.moore@cs.utk.edu> In-Reply-To: <200419115037.715289@bbprime> References: <90EF0F2D-4267-11D8-BE61-000393DB5366@cs.utk.edu> <200419115037.715289@bbprime> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Sender: owner-ietf-aulli@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > When you describe a usage scenario that is necessary for the > > > desired functionality, and you can demonstrate the DNS will not > > > satisfy that requirement, then we will have something concrete to > > > discuss. > > > > Call completion times can't be limited to a few milliseconds if the > > DNS lookups themselves take tens of milliseconds, and sometimes > > tens of > > Let's distinguish between domain names as unique identifiers and > domain names as referents to IP Addresses. > > The referral function requires the lookup. The uniqueness function > does not. The usage being discussed in this thread is identification. > No, that's only your assumption. But we should make it explicit - EIDs that support a lookup function are a different problem than EIDs that only support identification. If an EID scheme isn't useful for referrals then IMHO it is of very marginal utility, and if we had such a scheme in place already we would need to define an EID scheme that did work for referrals. > To the extent that lookup _is_ an issue I am still not understanding > what global lookup service you are proposing that will do better than > DNS, but that's a different thread. Saying "BGP" does not resolve the > considerable disparities between the real world of BGP and the service > environment needed for EIDs. Obviously just saying "BGP" is short on detail... but so is your assertion of "disparities". > It occurs to me that we do need to be some incremental review of that > history, given that this is a new mailing list with new participants. Perhaps, but we should probably define the problem first, otherwise we'll have people trying to insist that other participants review history that is irrelevant to the problem at hand. > Immediate requirements for both mobility and multihoming can live with > the restriction of using one locator(IP Address) and keeping others > only for backup. That's clearly false, or at best an overgeneralization. > > > You are proposing global distribution of a mapping table, to > > > provide fast lookup? > > > > Yes, though not of the complete mapping table from EIDs to hosts. > > I'm proposing that EIDs have a structure similar to IP addresses > > (so that routes can be advertised for EID prefixes, and those > > routes can be aggregated), > > I cannot guess how this would be meaningfully different from the > existing IP Address scheme. You are saying that EIDs would be > topologically related and that is _exactly_ what they must _not_ do. > They must not be tied to routing. Not clear, and your blanket assertion certainly doesn't support anything. Any server has to live at some point or points within the network topology. This is as true of DNS servers as of servers that can issue redirects for IP addresses. Advertising paths to redirect servers over BGP does require that if a EID prefix is delegated beyond a certain length, that the delegation happens more-or-less conicidental with links between routers. But this is not the same thing as saying that EID servers are wired to fixed locations, or that the EID mapping servers have to be co-located with the hosts to which those EIDs are assigned. An EID mapping server would be a replicated database that looked to BGP much like (perhaps exactly like) a network that advertised connectivity over multiple paths. People have certainly been working on using anycast addresses for DNS root servers - this is a fairly similar idea. > And it's fine for you to disagree, but further consideration of what > you are proposing requires you to present far more detail, so it can > be evaluated on the specifics. Arguing about specifics before we have the problem definition agreed on is just a waste of energy. The only reason to mentioning specifics at this stage is to point out that the solution doesn't have to look like you think it does - and the reason for that is to get us _out_ of this premature discussion of solution space. > > that EID-to-hostname lookups be a side-effect of sending a > > packet from the periphery of the network to the EID as a > > destination address (rather than having EID-to-hostname lookups > > explicitly done by the sending host). > > So, this is not a global lookup service, but a mapping that is created > by interaction between the endpoints? If so, then please comment on > the MAST proposal, which provides exactly this sort of mechanism. I will comment on MAST in due time, after I've been able to re-read it in detail. > This sort of approach does not have the third-party lookup latencies, > but the design of it can still delay start of application exchange, if > the mechanism must take place during association startup. At a > minimum, that's a round-trip latency. That's true if the redirect servers can't or don't forward packets, and if the endpoints or network periphery can't cache redirects. And there are security issues with doing the latter. > > > Really, Keith, as long as this all stays so abstract, then of > > > course you are > > > right and of course I am right, although we completely disagree. > > > > And if I specify details, then the details can be shot down and the > > approach discredited, even though the general approach might be > > valid and workable with somewhat different details. To me it > > really seems premature to try to specify things in detail except as > > a proof-of-concept. We don't have a good problem definition yet. > > Yes, it is always disquieting to have to provide specifics so that > people can do concrete analysis of them. Dave, you're out of line, and you know better - or at least you ought to. > At any rate, please note that this thread began with your deciding to > shoot down a specific design choice. Well, for the time being my goal is simply to show that use of DNS for EIDs is at least questionable - and certainly not something that should be assumed a priori. We can revisit the choice of EID format and mapping mechanism once we have an agreed-on problem definition and goals. > > > Every single new system that has been deployed over the global > > > Internet has displayed unexpected dynamics. > > > > It's not possible to anticipate all unintended consequences of any > > new system. (That's as true of MAST as anything else). That > > doesn't mean that we should dismiss any new idea as unworkable or > > farfetched. It is possible to gain confidence in how a new system > > employing these ideas will operate via engineering analysis and > > small-scale experiments, without requiring long-term research. > > I think you are suggesting an activity that belongs in the IRTF, not > the IETF. Yes, I assumed that's what you were thinking. But your attempt to dismiss this as research, and by doing so to discourage IETF from solving the problem in a technically sound fashion, is disingeneous. > Yes, I know you do not want to call it research, but that is what you > are proposing. That's unsupported handwaving, Dave. Tt's insulting and disruptive. > It certainly means there will not be any usable spec for at least > 5 years. I suppose that depends on how many uninformed people make irrelevant objections. > > > > The only thing that mitigates against this is the distinction > > > > between public versus internal activity. If the activity must > > > > be between random hosts interacting for the first time, then we > > > > are in the realm of research. > >... > > The distinction is a useful one. The assertion that interaction > > between random hosts is in the realm of research is the handwaving > > part. > > If that were what I said, I'd agree with you. > > However the issue that you are raising is public (global) initial > contact that involves a mapping effort that works better than the DNS. > That's rather more > specific than any old "interaction between random hosts." Let's not > lose the context. And your attempt to label it as research is still handwaving. > > > Ahh. So you are asserting a requirement that the EID be in every > > > packet. Well, yes, that overhead would be intolerable. > > > > Well, it depends on how you define EIDs, doesn't it? > > No. It depends on you you _use_ them. I assume that the definition of EIDs would be useless without definition of the protocols for using them. > The differences between > > - EID for rendezvous at the start of an association, > > - EID for rendezvous during an association, and > > - EID for unique identification as part of regular data exchange > during an > association > > are fundamental. There are fundamental, or at least important, differences between each of these operations. That doesn't mean that having different EIDs for each of these is useful or desirable. (though one could certainly consider having an EID that consisted of two parts, one which was purely an identifier, and one of which was a token that could be used to find locators for that identifier - sort of like 8+8 but not necessarily limited to fit into a 128-bit string.) > The "invisible to TCP" requirement turns out to have multiple faces. > You highlighted the performance impact that comes from IP Address > aggregation. Rendezvous is another. At the start of an association, > we have an existing mechanism that works well, namely the DNS I hope > you are not proposing to change it. IMHO, DNS does need to change, but that has nothing to do with the current discussion. > The third-party agent (eg, home agent) approach works fine for > rendezvous needed to recover from disruption of an existing > association. Many people would disagree with the idea that the "home agent" works fine. But in general it's the case that you have to have some kind of third-party agent to make some of these cases work - in particular, referrals between hosts that have not communicated recently, and recovering a broken connection when multiple endpoints move. > However the > interaction characteristics of this do not constrain design choices of > the EID. Domain names work fine. Sigh. Go back and read my web page again. > > in every packet, because TCP is designed and implemented with the > > assumption that the current endpoint identifier (IP address) is in > > every packet, because TCP apps assume that IP addresses of the > > endpoints have various properties (they cannot simply be randomly > > chosen without breaking apps) and the EIDs would have to provide > > that functionality. Any system that broke these assumptions would > > not be a drop-in replacement for TCP. > > The EID usage you cite is for connection identification. > Interestingly, the identifiers only need to work internally to the > host, rather than between association participants or more publicly. That's true only if you ignore the impact on applications, and only if you assume that this is the only thing that EIDs need to be used for (with which I'd strongly disagree) or that you're going to use different EIDs in different contexts (which I'd consider extremely suboptimal). > This permits what I believe Bellovin called "Host NAT". Several > proposals provide this sort of private mapping. (MAST is one of them) > > Yes it needs to look like an IP Address and yes it needs to be > transparent to transport, for identification functions. But it can be > done by a mapping function that is internal to the endpoint. No it cannot, at least not without breaking apps that use getlocalname() and getpeername(). > > > I keep hoping that there will be a clear and careful discussion > > > of the reasons that the EID must be in every packet. > > > > I certainly don't think it has to be in every packet. I do think > > that if the EID isn't in every packet, it forces some changes to > > TCP and SCTP and higher-layer apps. > > Multiple proposals manage to take care of this without making the > changes you believe are needed. Proposals prove nothing. Widely deployed running code that didn't break any applications would prove something, but it's rather expensive to try things out and find out that they don't work as well as naively expected (witness NAT). If those proposals "take care of this", where's the analysis to support such conclusions? > > An NFS client opens up a TCP connection to the domain name of a > > file server, which maps to multiple IP addresses. At some point > > the address associated with that connection changes, maybe because > > the server moved, maybe because the destination network renumbered. > > The client > > host attempts to re-establish the connection to the server, using > > DNS to do the lookup, but this time it gets a different server host > > (that provides access to the same set of files). It can't resume > > the TCP connection, and the file handle is invalid, because both of > > these were only meaningful to that specific server host. > > Here's the problem: "The client host attempts to re-establish the > connection to the server". From a transport standpoint, this is a new > association. No, it could be an extension to TCP that tried to re-connect an existing association to the same host at a new IP address. The point is that having an EID for that host isn't sufficient to re-connect an already-open connection if you can't use the EID to find the current IP address of that host, and trying to use existing DNS names for EIDs doesn't solve the problem because it conflicts with other uses of DNS to do load-sharing. > > A NetSolve server is running a computation on behalf of a client. > > During the time that the computation is taking place, the client's > > IP address changes. The server cannot contact the client to inform > > the client of the completion of that computation and to return the > > results to the client, because the client's DNS name (if it has > > one) was associated with the client's IP address, not with the > > client itself.(this is quite common). > > If this is another example of the above behavior, the answer is the > same. It's not another example of the above behavior. > But let's move to the case that there is a continuing association but > the infrastructure is changing the address, due to multihoming > failover or mobility transition. So the goal is to preserve an > existing association. > > The shim and transport-based proposals all do a mapping from an > application-level string (which looks like an IP Address and might > even be one) to an actual IP Address. The question is whether the > pool of actual addresses only points to one endpoint. And the answer > is yes, because that is what each of the proposals is designed to do. Then the question becomes one of how that application-level string is mapped onto a current, "real", IP address, and whether that mapping happens quickly and reliably and consistently enough. > > > > I believe that existing use of DNS is so widespread and > > > > entrenched that it is very difficult to get people to change > > > > the way they use it. > > > > > > If we were talking about changing an existing style of usage, you > > > might be right. But this is a new style. New use. > > > > I believe that the existing use of DNS will make substantially new > > uses difficult, as DNS implementations and infrastructure and human > > users have all become highly adapted to existing uses. > > Stated that abstractly it is certainly true, and certainly false. It > of course depends upon what the particular new behaviors/uses are. It's speculation based on experience. Your assumption that a new use of DNS will not have such problems is no more than that. > > But if we don't utilize the existing DNS servers and delegation > > infrastructure (and there are good reasons to not do so) then there > > is far less advantage to using DNS. > > We agree. That's why I want to re-use them, rather than invent a > whole new infrastructure. Yes, but reusing the existing infrastructure means that the mapping service is slow and unreliable - unless you somehow assume that DNS service will be drastically improved. Since a lot of DNS problems are inherent in the design of DNS itself, I fail to see how you can expect them to be solved without changing the current DNS infrastructure. > > > For example, folks need to consider the cost of creating and > > > running an entirely new registration service, and then > > > correlating it with other registrations, such as domain names > > > > Note that the cost of that service will also vary according to the > > specifics of that service. To speculate about the cost without > > having any idea of what that service looks like is - well, > > speculative. > > If we are talking about the cost of _any_ global infrastructure that > requires registration, we know that the required, basic cost is > enormous. More handwaving. We don't "know" any such thing. > That is one reason there is so much interest in the statistically > unique strings that are generated without registration. It is also > why some of us try to distinguish between initial, rendezvous use, > versus use that is internal to the communicating endpoints. These > eliminates the need for global registration. Well, it piggybacks on an existing scheme which is already replete with problems, and it produces EIDs that seem to me to only be marginally useful. Or to put it another way, it fragments the EID problem, makes it even more difficult to solve the rest of the problem, and makes the overall solution unnecessarily complex. > > No, I'm saying that existing uses of DNS conflict with use of DNS > > for the mechanisms under discussion. > > Given that there exist quite a few proposals and that some of them use > DNS, please explain how these proposals are flawed. I'm not going to waste my time responding to several different specific proposals. I've already explained in general terms why DNS is problematic, and that should be sufficient for my immediate purposes - which is to get people out of the habit of assuming a priori that DNS is The Answer. If after understanding the problem and establishing goals and doing analysis it really does look like some way of using DNS is the best solution, then we could go with it. But we can't skip steps - there are too many reasons to be skeptical that DNS is the way to go. > > I'm not sure how else to say it. If EIDs have human-meaningful > > components that are associated with organizations and enterprises, > > this conflicts with the desire to have EIDs stably bound to hosts > > that are used in multiple roles. > > Organizations support multiple naming schemas quite handily. And > someone has to do the administration. Delegating leaf administration > to organizations scales nicely. So I have no idea what alternative > you have in mind that we know will scale well. There's no need to wire organizational names into EIDs. It serves no purpose other than to impair the use of those EIDs. > When you describe a scenario that we know we must support and which > cannot be supported by one or another of the existing proposals, then > we will have something concrete to discuss. I have already done so. Reread my previous message. > > As a first approximation - you get EIDs in approximately the same > > way you get registered IPv6 address blocks. You can either get > > them from a provider of redirection services, or you can get your > > own block but the prefixes won't be routable on the public network. > > Actually we > > could use IPv6 addresses as EIDs. > > And some proposals suggest that. But all you are describing is a > globally hierarchical registration and delegation service. And that's > what existing IP Address and DNS administrative mechanisms provide. Well, there are some differences between the two. Looking at those differences might be instructive. > It appears that either you are suggesting re-using an existing one -- > and that's what I am proposing -- or creating a new, third scheme. > The cost of a new, third scheme is huge. Indeed, I would prefer to use BGP infrastructure, and IPv6 address block delegation, if these can be made to work - much as you would prefer to use DNS if those can be made to work. But I don't immediately assume that the cost of a completely different numbering scheme would be prohibitive. I want to keep an open mind about it. I do assume that there would need to be some compelling argument for how the delegation and mapping infrastructure would be maintained and funded in order to make a completely different numbering scheme seem viable. > > Yes, this will work for the specific scenario you described. One > > thing it won't handle is the case where multiple endpoints move > > concurrently. Nor will it handle the case where the server has > > multiple addresses. > > Yes, Mutual Mobility requires a stable, third-party rendezvous > service, a la home agents, mapping agents, etc. > > However we need to note that server mobility is not a pressing, > near-term requirement. Disagree. The client/server distinction is artificial. Would you really want to have a cell phone that could only place calls to wired phones? > > > > In some sense we create a new infrastructure either way. > > > > > > Not hardly. There are minor matters, such as global > > > authorization for the new system, that are quite different. > > > > There certainly are some differences, but it's not as if one can be > > dismissed as inherently easier than the other. > > Go get a block of 10 telephone numbers from the current registration > service and that you will use in some new, clever way. Then go and > create a brand new, global registration service to assign 10 numbers. That's a meaningless exercise. > I think it is entirely reasonable to make a blanket statement that the > latter is massively more difficult and expensive. And I think you're being ridiculous. > > > Let's pretend that we are not talking about the difficulty of > > > creating yet-another global registration service involving the > > > challenges of the DNS. > > > Let's pretend that it's no more complex than the IP Address > > > global registration service. > > > > yes, lets. > > > > > You think that creating one of those is no more difficult than > > > creating a new TLD? > > > > IPv6 is doing it, so we'll find out. > > They are creating a new set of bits to be registered, but they are > using an existing registration service. The new set of bits have > quite a bit of registration similarity to the existing set. Hence the > incremental cost of adding the ability to register this new set of > strings is relatively modest. (And we can all skip over the irony of > calling it modest.) "modest" incremental cost seems like a desirable thing to exploit if we can do it. After all, that's part of why you're proposing DNS, right? > So you are postulating that this new set of bits that are completely > independent of IP Addresses and Domain Names will be administered by > an existing registration service? It's not immediately clear that they should be independent of IP addresses. Offhand it looks like defining a new IPv6 prefix for EIDs would work well. > > And since it appears to me that > > we can use IPv6 addresses for EIDs anyway, I don't see this > > registration as a huge problem. Of course, we've been surprised > > before. > > Oh. You want to preclude IPv4 use. I don't. I wouldn't really say "preclude" IPv4 use. You might be able to use IPv4 apps that don't make too many assumptions - probably a subset of the IPv4 apps that work over NATs. But by the time any of this stuff gets deployed, IPv4 will be obsolete - or at least of marginal utility. IPv4 will be the way you talk to legacy apps and legacy devices. And if your app depends on EIDs it will be easier for that app to use IPv6 than IPv4. > > > Less "reliable"? What does that mean? The name drops packets? > > > The name fails to retransmit them? > > > > The DNS servers and the networks supporting them become even more > > significant sources of failure than they are now. > > It is certainly true that using DNS lookups as part of a > multiaddressing service will require depending on DNS lookups to work. > Yes, this is > architecturally significant. However, folks might have noticed that > the Internet is not practically usable without the DNS already. Folks might or might not have noticed that the DNS is pretty slow and unreliable already. (Ever type in a URL and have to wait a couple of minutes before the page wouldn't load, then hit reload and having it load immediately? It's almost certainly the DNS at fault.) > > > The purpose of the EID is to be unique. > > > > That's not the only purpose. We need EIDs that can be used for > > rendezvous also. Unique names are easy - public keys suffice for > > those. > > "Used for"? If you mean the EID needs to have information encoded > into it that permits rendezvous without a mapping service, then no. You can think of it either way - either the EID contains information that can be used to find the address of the host associated with the EID, or a separate mapping token and the associated service exist, the EID can be "used with" such tokens and the APIs for using EIDs make it easy to do so. I don't want to argue over what these things are "called" (at least not now) -- the point is that having rendezvous functionality is imperative. > > No matter what kind of EID you have, if you want to allow a host to > > contact the host with that EID then the host wanting to establish > > contact has to send a message to a server that knows the current > > location of the host with the EID. One way to do this is to do a > > DNS lookup of the EID. Another way is to use BGP to advertise > > routing from EID prefixes to those servers. Either way provides > > the desired result, but BGP does it much faster and more reliably - > > provided, of course, that the BGP table is small enough to be kept > > in routers, and that the routing computation for those prefixes is > > not onerous. > > You keep citing BGP as if the citation solves a problem. However I've > noted that BGP has encoding and usage characterics that do not work > for the kinds of EID usage folks are discussing. And I keep noticing that some of the EID usages overconstrain the problem, or confuse the solution with the problem. Keith