From exim@www1.ietf.org Tue Oct 14 22:14:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13862 for ; Tue, 14 Oct 2003 22:14:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9bAp-000481-E4 for saad-archive@odin.ietf.org; Tue, 14 Oct 2003 22:14:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F2E3Hg015865 for saad-archive@odin.ietf.org; Tue, 14 Oct 2003 22:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9bAo-00047o-J2 for saad-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 22:14:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13841 for ; Tue, 14 Oct 2003 22:13:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9bAl-0005A4-00 for saad-web-archive@ietf.org; Tue, 14 Oct 2003 22:13:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9bAk-00059w-00 for saad-web-archive@ietf.org; Tue, 14 Oct 2003 22:13:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9bAm-00047A-Py; Tue, 14 Oct 2003 22:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9bAA-00045S-OQ for saad@optimus.ietf.org; Tue, 14 Oct 2003 22:13:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13802 for ; Tue, 14 Oct 2003 22:13:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9bA7-000586-00 for saad@ietf.org; Tue, 14 Oct 2003 22:13:19 -0400 Received: from zak.ecotroph.net ([216.93.164.123]) by ietf-mx with esmtp (Exim 4.12) id 1A9bA6-000582-00 for saad@ietf.org; Tue, 14 Oct 2003 22:13:18 -0400 Received: from thinkingcat.com ([::ffff:24.51.102.130]) (AUTH: LOGIN leslie, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zak.ecotroph.net with esmtp; Tue, 14 Oct 2003 22:13:17 -0400 Message-ID: <3F8CACE3.30507@thinkingcat.com> Date: Tue, 14 Oct 2003 22:11:47 -0400 From: Leslie Daigle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saad@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Saad] Some initiating thoughts... Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As an initial contribution to this discussion list, I'm attaching a pre-draft that was prepared by IAB member Mark Handley as a result of reviewing the material of the IAB's Open Architecture meeting in Vienna. As noted in the text -- this is a first draft of thinking. While the IAB hasn't yet decided if this should be pursued as an IAB document, we thought it would be a useful discussion starting point for this mailing list. Leslie, for the IAB. -------- Internet Engineering Task Force IAB INTERNET-DRAFT Mark Handley (ed) draft-iab-addressing-2003815.txt 15 August 2003 $Revision: 1.1 $ Expires: NOT PUBLISHED Architectural Issues with IP Addressing 1. Introduction This document examines a range of architectural issues related to IP addressing. The motivation is that we perceive that a number of significant requirements are not being met by the currently deployed addressing architecture. In this document we do not attempt to find solutions to these problems; our goal is merely to collect the requirements to permit a reasoned discussion of solutions to take place. The initial content in this document was drawn from the proceedings of an Open IAB Meeting, held at the 57th IETF in Vienna in July 2003. 2. Background IP addresses have served both as a means of uniquely identifying a device interface that is attached to a network (an endpoint identifier), and as a means of identifying where a device is located within the network (a forwarding or routing identifier). IPv4 has two address types: o Unique addresses, which are normally global-use. o Private addresses [1], which are for local-use internets. Although it is not strictly required, the IPv4 address architecture largely assmed a unique binding of a device interface to an IP address. Essentially this means a device interface existed as a member of a single addressing realm. Private addresses were not originally intended to be connected to the global Internet, but the use of Network Address Translators has since become commonplace. A NAT enables limited communication between a host with a private address and hosts outside of its local-use internet. However NATs raise a large number of architectural problems in the way they do this [2]. Handley Section 2. [Page 1] INTERNET-DRAFT Expires: NOT PUBLISHED August 2003 In contrast, IPv6 defined three address types: o Unique addresses, which are normally global-use. o Site-Local addresses, which are for scoped local-use internets. o Link-Local addresses, which are for very local use. The IPv6 address architecture explicitly explored the potential of explicitly 'scoped' address realms coexisting with a global realm. Thus a device interface may have a globally unique address, a site-local address, and a link-local address simultaneously, and use them for different communications. At the time this model was devised, it was not entirely clear how this would work in practice, what architectural issues it addressed, and what new issues it raises. As IPv6 has moved into deployment, it has become clear that the complexity issues raised by the new addressing architecture, and in particular by the use of site-local addresses, are not negligable. Thus it behooves us to re-examine the requirements for Internet addressing in the light of more recent experience. 3. IP Addressing Requirements The Internet is a complex and heterogeneous network, and becoming more heterogeneous as time goes on. Different people and different subsystems in the network have different requirements on the addressing architecture; this is a classic example of a "tussle space" [3] between conflicting demands. 3.1. Addressing Requirements of Routing The structure of the address space should minimize the number of routing table entries. This is an issue both due to the sheer size of the forwarding table, and due to the rate of change of the forwarding table. Ideally the addressing architecture should allow for significant information hiding, such that the number of forwarding entries and number of updates to the forwarding table both scale O(log(n)) or better in number of connected subnets. Routing convergence times are dependent on the underlying topology of the network, on the routing protocols in use, and on the suitability of the addressing architecture for information hiding. Thus the structure of the address space should be suitable for minimizing routing convergence times. Handley Section 3.1. [Page 2] INTERNET-DRAFT Expires: NOT PUBLISHED August 2003 Forwarding performance cannot be neglected. Any address structure must permit efficient route lookup operations at backbone speeds. Secondary requirements here might also include multipath routing for load balancing purposes, and QoS-based scheduling [4]. Site multihoming is becoming commonplace, and should be regarded as being a nearly ubiquitous requirement in the future. The address architecture should provide support for multihoming, while simultaneously satisfying the requirements above. Mobility of both hosts and networks is likely to be a significant requirement in the future. While host mobility can be handled with solutions such as Mobile IP, this still imposes requirements on the address architecture related to moving between addressing realms. Network mobility imposes stronger requirements on addressing architecture, related to both disconnected operation and to the process of reconnecting to a new network attachment point without disrupting ongoing communications with the mobile network. While we do not see too many mobile networks in the current Internet, it is highly likely that there they will be a significant presense in the future. 3.2. Addressing Requirements of Enterprises A key requrirement of enterprises with regard to addressing is independence from their ISPs. To ensure good service from their ISP that matches their needs, an enterprise needs to be able to change ISP relatively easily. However, if an enterprise's internal network is numbered out of their ISP's address space then they need to renumber their internal network when changing ISP. As site-renumbering is considered painful and costly, this leads to provider lock-in which is clearly undesirable from the enterprise's point of view. Additional enterprise requirements include the ability to multi-home important hosts, server virtualization, and server load balancing. All of these may impact addressing architectures in different ways. Security is clearly a major concern for enterprises, and an important requirement is to be able to perform some degree of traffic isolation at security domain boundaries. While this is really the task of a firewall, there is a widespread view that the use of RFC 1918 private IPv4 addresses when combined with a SOCKS firewall or a NAT is an effective mechanism for enhancing traffic isolation. We note that the use of private addresses with a NAT instead of a correctly configured firewall has significant shortcomings from a security point of view, but it does have the advantage of being very simple to set up. Handley Section 3.2. [Page 3] INTERNET-DRAFT Expires: NOT PUBLISHED August 2003 Irrespective of the technology used to accomplish it, the specific security requirement that enterprises have on addressing is that it should be easy to set up a well-known and well-understood filter at security boundaries that reduces the exposure profile from individual configuration errors. Some enterprises have addressing requirements caused by the need to set up inter-enterprise Virtual Private Networks (VPNs). Also, at some point in their existence most enterprises undergo some form of merger or acquisition, and discover that they need to merge internal networks. In both these circumstances there is a requirement to avoid the need to renumber or to suffer from ambiguous addressing resulting from the merger of two private address spaces. 3.3. Addressing Requirements of Consumers As networking equipment becomes ubiquitous, an increasing fraction of networks will be owned and operated by people with minimal technical skills. The primary requirement that these users have is that addressing is autoconfiguring (or at the very least, trivial to configure). The user must not have to explicitly register their network addresses. Their network must function when first set up while being dsiconnected from the global Internet, and must permit later and intermittent commectivity without disrupting local communications. Consumer appliances must be able to ship with appropriate defaults so that they work "out of the box". At the same time, their default exposure to attack and denial-of-service needs to be minimalized. A key requirement on addressing is that much of this consumer equipment (printers, light switches, etc) needs to be able to communicate locally without being directly exposed to the global Internet. At the same time the same network infrastructure will be used by devices that do need global Internet access. 3.4. Addressing Requirements of Transport Protocols, Middleware and Applications Transport protocols including TCP and security associations may use the endpoint's IP address as an endpoint identifier. In the case of TCP, the binding is a loose one - so long as the IP address in incoming packets doesn't change during the connection lifetime, then TCP is happy. Other protocols may have more stringent requirements requiring both endpoints to have the same understanding of each other's addresses. Other protocols including SCTP may be address-agile. The transport association may be with multiple addresses rather than a single one, Handley Section 3.4. [Page 4] INTERNET-DRAFT Expires: NOT PUBLISHED August 2003 permitting failover. Alternatively this may be done at the middleware or application layers. If each endpoint has multiple addresses, the transport, middleware or application layer has the complex problem of choosing the correct pair of addresses to enable communication. There are two conflicting goals here: o To guarantee reachability between the endpoints. o To ensure that the traffic stays within the tightest possible administrative and security boundaries. Non-globally unique addresses present a particular problem. Essentially this is a routing problem, but one that must be solved above the network layer. Some applications have a requirement to support third-party references to addresses across both space and time. The simplest example is ftp, which uses the control channel to communicate the IP addresses to use for the data channel. However, while third-party ftp is rare, the problem is a more significant one for signalling protocols such as SIP [5] and RTSP [6]. Such protocols by their nature set up a signalling channel first, then initiate additional data channels. The need to do user-location with SIP or server load-balancing with RTSP means that it is commonplace for the initial control channel to be set up between different hosts than the final data channels, and so there is an inherent need to signal the identities of the end-systems that should comprise the data channel. While it may be safer to pass domain names instead of IP addresses in such cases, this may not always be possible. Finally, most applications would really prefer to never see addresses at all. They should not need to care whether a communiation is between IPv4 addresses, IPv6 addresses, or a mixture of the two. Notes Intermittently committed nets (ships, planes). 4. References [1] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. Handley Section 4. [Page 5] INTERNET-DRAFT Expires: NOT PUBLISHED August 2003 [2] B. Carpenter, "Internet Transparency", RFC 2775, February 2000. [3] David D. Clark, John Wroclawski, Karen R. Sollins, Robert Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", Proc. ACM SIGCOMM 2002. [4] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [5] [6] Handley Section 4. [Page 6] _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Wed Oct 15 11:36:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05140 for ; Wed, 15 Oct 2003 11:36:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ngw-00068r-CB for saad-archive@odin.ietf.org; Wed, 15 Oct 2003 11:36:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FFa2UV023603 for saad-archive@odin.ietf.org; Wed, 15 Oct 2003 11:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ngw-00068c-7W for saad-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 11:36:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05110 for ; Wed, 15 Oct 2003 11:35:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ngv-00064j-00 for saad-web-archive@ietf.org; Wed, 15 Oct 2003 11:36:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9ngu-00064g-00 for saad-web-archive@ietf.org; Wed, 15 Oct 2003 11:36:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ngv-00068L-A6; Wed, 15 Oct 2003 11:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ngp-00067M-PW for saad@optimus.ietf.org; Wed, 15 Oct 2003 11:35:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05106 for ; Wed, 15 Oct 2003 11:35:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ngo-00064V-00 for saad@ietf.org; Wed, 15 Oct 2003 11:35:54 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A9ngo-00063g-00 for saad@ietf.org; Wed, 15 Oct 2003 11:35:54 -0400 Subject: [saad] About saad MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 08:35:23 -0700 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: [saad] About saad thread-index: AcOTMgaIoqMhcwgbT3qOBGob+CWrwA== From: "Michel Py" To: Content-Transfer-Encoding: quoted-printable Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I think a mention in the "about saad" that would say it's specific to IPv6 would be appropriate (if it's not, there are many things that need to be revisited then). Michel. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Wed Oct 15 12:00:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06390 for ; Wed, 15 Oct 2003 12:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9o4D-0008Ey-BZ for saad-archive@odin.ietf.org; Wed, 15 Oct 2003 12:00:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FG04oj031669 for saad-archive@odin.ietf.org; Wed, 15 Oct 2003 12:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9o4C-0008Ei-7X for saad-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 12:00:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06336 for ; Wed, 15 Oct 2003 11:59:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9o4A-0006U4-00 for saad-web-archive@ietf.org; Wed, 15 Oct 2003 12:00:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9o4A-0006U1-00 for saad-web-archive@ietf.org; Wed, 15 Oct 2003 12:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9o4A-0008EF-Ld; Wed, 15 Oct 2003 12:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9o3V-0008DH-Dw for saad@optimus.ietf.org; Wed, 15 Oct 2003 11:59:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06268 for ; Wed, 15 Oct 2003 11:59:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9o3S-0006SC-00 for saad@ietf.org; Wed, 15 Oct 2003 11:59:18 -0400 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by ietf-mx with esmtp (Exim 4.12) id 1A9o3M-0006QZ-00 for saad@ietf.org; Wed, 15 Oct 2003 11:59:13 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 0C77C43143; Wed, 15 Oct 2003 17:58:37 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp02.uc3m.es (Postfix) with SMTP id 9595599FEF; Wed, 15 Oct 2003 17:58:36 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Michel Py" , Subject: RE: [saad] About saad Date: Wed, 15 Oct 2003 17:53:20 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Michel, I don't think that the discussion should be focused on IPv6 only a priori. IMHO it is very interesting if we can find an approach that is version independent. Perhaps many things need to be revisited, but there are approaches that work for IPv6 and IPv4 simultaneously (HIp for instance) Regards, marcelo > -----Mensaje original----- > De: saad-admin@ietf.org [mailto:saad-admin@ietf.org]En nombre de Michel > Py > Enviado el: miercoles, 15 de octubre de 2003 17:35 > Para: saad@ietf.org > Asunto: [saad] About saad > > > I think a mention in the "about saad" that would say it's specific to > IPv6 would be appropriate (if it's not, there are many things that need > to be revisited then). > > Michel. > > > _______________________________________________ > Saad mailing list > Saad@ietf.org > https://www1.ietf.org/mailman/listinfo/saad > _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Wed Oct 15 18:10:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26790 for ; Wed, 15 Oct 2003 18:10:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9tqG-0003fU-UZ for saad-archive@odin.ietf.org; Wed, 15 Oct 2003 18:10:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FMA4AC014093 for saad-archive@odin.ietf.org; Wed, 15 Oct 2003 18:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9tqG-0003eq-FO for saad-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 18:10:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26751 for ; Wed, 15 Oct 2003 18:09:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9tqD-0004aa-00 for saad-web-archive@ietf.org; Wed, 15 Oct 2003 18:10:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9tqD-0004aX-00 for saad-web-archive@ietf.org; Wed, 15 Oct 2003 18:10:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9tqD-0003eW-W7; Wed, 15 Oct 2003 18:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9tqC-0003eB-D8 for saad@optimus.ietf.org; Wed, 15 Oct 2003 18:10:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26740 for ; Wed, 15 Oct 2003 18:09:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9tq9-0004aU-00 for saad@ietf.org; Wed, 15 Oct 2003 18:09:57 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 1A9tq8-0004aE-00 for saad@ietf.org; Wed, 15 Oct 2003 18:09:56 -0400 Received: from gih505.telstra.net (dhcp12.potaroo.net [203.10.60.12]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h9FLwHRc018403; Thu, 16 Oct 2003 07:58:19 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20031016073221.00baa300@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 16 Oct 2003 07:36:36 +1000 To: "Michel Py" , From: Geoff Huston Subject: Re: [saad] About saad In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , At 08:35 AM 15/10/2003 -0700, Michel Py wrote: >I think a mention in the "about saad" that would say it's specific to >IPv6 would be appropriate (if it's not, there are many things that need >to be revisited then). To be honest I'm not sure that such an explicit constraint would be entirely helpful The basic issue here is that of scoped addresses, where the address only has referential significance within some form of defined realm, and loses that significance outside of that realm, and the consideration of the utility of such addresses within the environment and architecture of the Internet. For me this area of consideration is somewhat orthogonal to the V4 / V6 considerations. regards, Geoff Huston _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Wed Oct 15 21:06:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01699 for ; Wed, 15 Oct 2003 21:06:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9waZ-0002x3-Ht for saad-archive@odin.ietf.org; Wed, 15 Oct 2003 21:06:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G163jU011342 for saad-archive@odin.ietf.org; Wed, 15 Oct 2003 21:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9waZ-0002wr-CP for saad-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 21:06:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01691 for ; Wed, 15 Oct 2003 21:05:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9waW-00067z-00 for saad-web-archive@ietf.org; Wed, 15 Oct 2003 21:06:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9waW-00067w-00 for saad-web-archive@ietf.org; Wed, 15 Oct 2003 21:06:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9waX-0002wA-EA; Wed, 15 Oct 2003 21:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9wa9-0002vd-B4 for saad@optimus.ietf.org; Wed, 15 Oct 2003 21:05:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01685 for ; Wed, 15 Oct 2003 21:05:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9wa6-00067e-00 for saad@ietf.org; Wed, 15 Oct 2003 21:05:34 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1A9wa5-00067R-00 for saad@ietf.org; Wed, 15 Oct 2003 21:05:33 -0400 Subject: RE: [saad] About saad MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 18:05:03 -0700 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: [saad] About saad thread-index: AcOTaklFShz0yAcWRHGvvcuOhPbVugAFOLQw From: "Michel Py" To: "Geoff Huston" , Content-Transfer-Encoding: quoted-printable Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Marcelo / Geoff, > marcelo bagnulo wrote: > I don't think that the discussion should be focused on IPv6 > only a priori. > Geoff Huston wrote: > For me this area of consideration is somewhat orthogonal to > the V4 / V6 considerations. That's fine by me, but then we do have some work with the about text: > We have specified an Internet that works, at the network > layer, using relatively stable but not permanent identifiers > for connection endpoints, which are allocated and > administered using a topology dependent model, implying a > service provider dependent model For IPv4 this is untrue, as PI addresses are not allocated using a topology dependent model and do not imply a server provider dependant model. > But we run into problems (the architecture doesn't quite > fit when we try to address some scenarios encountered in > real life: multihoming Untrue for IPv4. The issue with IPv4 multihoming is a scalability issue: the growth of the routing table (resulting in part from the announcement of multihomed blocks) induces instability, which is not good. Possibly, a protocol other than BGP4+ would have a lot less of a scalability issue, so I don't consider this an architecture issue. > assembling a local network without necessarily having to contact > an ISP to obtain address space(e.g.,home net) Not a problem with IPv4: we have RFC1918. > Some proposed solutions are challenged in terms of:=20 > providing referential integrity - how is referential=20 > integrity maintained when identifiers are not globally=20 > unique or are overloaded? The answer to this is simple: either make the identifiers globally unique, or manage that ambiguous identifiers never collide (or make the collision risk extremely slow). > choosing between different identifiers for an object ^^^^^^^^^^^ > which has different "reachability" and the reachability > is context-dependent Shouldn't "identifiers" above be "locators"? I vaguely assume that an object can have multiple locators but should have only one identifier. Michel. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Thu Oct 16 11:31:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07124 for ; Thu, 16 Oct 2003 11:31:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA5m-0008JZ-AL for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 11:31:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GFVAEp031955 for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 11:31:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA5m-0008JK-4m for saad-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 11:31:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07092 for ; Thu, 16 Oct 2003 11:30:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAA5h-0005xs-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 11:31:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAA5h-0005xo-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 11:31:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA5d-0008I8-T2; Thu, 16 Oct 2003 11:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAA4k-000866-Bk for saad@optimus.ietf.org; Thu, 16 Oct 2003 11:30:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07048 for ; Thu, 16 Oct 2003 11:29:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAA4j-0005xA-00 for saad@ietf.org; Thu, 16 Oct 2003 11:30:05 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AAA4i-0005x6-00 for saad@ietf.org; Thu, 16 Oct 2003 11:30:05 -0400 Message-ID: <003201c393f9$008398f0$396015ac@dclkempt40> From: "James Kempf" To: "Michel Py" , "Geoff Huston" , References: Subject: Re: [saad] About saad Date: Thu, 16 Oct 2003 08:20:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit IPv4 still has the node identifier v.s. routing locater conflation problem for addresses, however. jak ----- Original Message ----- From: "Michel Py" To: "Geoff Huston" ; Sent: Wednesday, October 15, 2003 6:05 PM Subject: RE: [saad] About saad > Marcelo / Geoff, > > > marcelo bagnulo wrote: > > I don't think that the discussion should be focused on IPv6 > > only a priori. > > > Geoff Huston wrote: > > For me this area of consideration is somewhat orthogonal to > > the V4 / V6 considerations. > > That's fine by me, but then we do have some work with the about text: > > > We have specified an Internet that works, at the network > > layer, using relatively stable but not permanent identifiers > > for connection endpoints, which are allocated and > > administered using a topology dependent model, implying a > > service provider dependent model > > For IPv4 this is untrue, as PI addresses are not allocated using a > topology dependent model and do not imply a server provider dependant > model. > > > > But we run into problems (the architecture doesn't quite > > fit when we try to address some scenarios encountered in > > real life: multihoming > > Untrue for IPv4. The issue with IPv4 multihoming is a scalability issue: > the growth of the routing table (resulting in part from the announcement > of multihomed blocks) induces instability, which is not good. Possibly, > a protocol other than BGP4+ would have a lot less of a scalability > issue, so I don't consider this an architecture issue. > > > > assembling a local network without necessarily having to contact > > an ISP to obtain address space(e.g.,home net) > > Not a problem with IPv4: we have RFC1918. > > > > Some proposed solutions are challenged in terms of: > > providing referential integrity - how is referential > > integrity maintained when identifiers are not globally > > unique or are overloaded? > > The answer to this is simple: either make the identifiers globally > unique, or manage that ambiguous identifiers never collide (or make the > collision risk extremely slow). > > > > choosing between different identifiers for an object > ^^^^^^^^^^^ > > which has different "reachability" and the reachability > > is context-dependent > > Shouldn't "identifiers" above be "locators"? I vaguely assume that an > object can have multiple locators but should have only one identifier. > > Michel. > > > _______________________________________________ > Saad mailing list > Saad@ietf.org > https://www1.ietf.org/mailman/listinfo/saad > > _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Thu Oct 16 12:00:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08076 for ; Thu, 16 Oct 2003 12:00:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAXo-0001gJ-NJ for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 12:00:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GG07mH006414 for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 12:00:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAXm-0001fF-E1 for saad-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 12:00:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08047 for ; Thu, 16 Oct 2003 11:59:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAXl-0006CQ-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 12:00:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAXl-0006CN-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 12:00:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAXk-0001ew-Ll; Thu, 16 Oct 2003 12:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAXc-0001do-7M for saad@optimus.ietf.org; Thu, 16 Oct 2003 11:59:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08036 for ; Thu, 16 Oct 2003 11:59:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAXb-0006C6-00 for saad@ietf.org; Thu, 16 Oct 2003 11:59:55 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1AAAXa-0006Bv-00 for saad@ietf.org; Thu, 16 Oct 2003 11:59:54 -0400 Subject: RE: [saad] About saad Date: Thu, 16 Oct 2003 08:59:22 -0700 MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Thread-Topic: [saad] About saad X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 thread-index: AcOT+ojOnniwVtvyR12x+od0YczgTwAA+43w From: "Michel Py" To: "James Kempf" , "Geoff Huston" , Content-Transfer-Encoding: quoted-printable Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > James Kempf wrote: > IPv4 still has the node identifier v.s. routing locater > conflation problem for addresses, however. Can you explain "conflation" please? Michel. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Thu Oct 16 12:16:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08594 for ; Thu, 16 Oct 2003 12:16:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAnC-00038U-OK for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 12:16:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GGG2xg012053 for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 12:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAnC-00038K-Kx for saad-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 12:16:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08583 for ; Thu, 16 Oct 2003 12:15:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAnB-0006LY-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 12:16:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAnB-0006LT-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 12:16:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAnB-00037v-EC; Thu, 16 Oct 2003 12:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAn8-00037R-KA for saad@optimus.ietf.org; Thu, 16 Oct 2003 12:15:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08577 for ; Thu, 16 Oct 2003 12:15:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAn7-0006LM-00 for saad@ietf.org; Thu, 16 Oct 2003 12:15:57 -0400 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by ietf-mx with esmtp (Exim 4.12) id 1AAAn6-0006LJ-00 for saad@ietf.org; Thu, 16 Oct 2003 12:15:56 -0400 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h9GGFsWB000449; Thu, 16 Oct 2003 12:15:54 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h9GGFrgS000448; Thu, 16 Oct 2003 12:15:53 -0400 Date: Thu, 16 Oct 2003 12:15:53 -0400 From: "J. Noel Chiappa" Message-Id: <200310161615.h9GGFrgS000448@ginger.lcs.mit.edu> To: saad@ietf.org Subject: RE: [saad] About saad Cc: jnc@ginger.lcs.mit.edu Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , > From: "Michel Py" >> which are allocated and administered using a topology dependent model, >> implying a service provider dependent model > For IPv4 this is untrue, as PI addresses are not allocated using a > topology dependent model and do not imply a server provider dependant > model. IPv4 tries to make sparing use of PI addresses for *exactly* the same reasons as in IPv6 - too many will overload the routing. The only difference is that with its greater address space, IPv6 has even *more* rope to hang itself with, if it starts handing out PI addresses. >> But we run into problems (the architecture doesn't quite fit when we >> try to address some scenarios encountered in real life: multihoming > Untrue for IPv4. The semantics of IPv4 and IPv6 addresses are basically identical. The only difference is in the number of bits. > The issue with IPv4 multihoming is a scalability issue: the growth of > the routing table (resulting in part from the announcement of > multihomed blocks) induces instability, which is not good. Well, I suppose the eventual "real" IPv6 multi-homing will have fixed this, but if anyone's using "naive" IPv6 multihoming now - i.e. doing it like IPv4 does it, with a PI address (or a chunk of PA address which it advertises globally - the two are indistinguishable technically) - it has exactly the same scaling problem. > Possibly, a protocol other than BGP4+ would have a lot less of a > scalability issue, so I don't consider this an architecture issue. A different routing algorithm/protocol might have a *one-time* improvement in overhead, but in the long run, the curve is going to have the same kind of shape. Having to track too many distinct destinations (which is roughly equivalent to "routing table size") will overwhelm *any* routing architecture. So, it *is* an architectural issue. >> choosing between different identifiers for an object ^^^^^^^^^^^ >> which has different "reachability" and the reachability >> is context-dependent > Shouldn't "identifiers" above be "locators"? I vaguely assume that an > object can have multiple locators but should have only one identifier. It all depends on what is meant by the term "identifier" here. (The document probably needs some editing for precision, etc.) If it means "a name used for end-end identification", it would be a problem; and I would like to understand what the architectural need is for multiple end-end names for a single end-end entity. If it means "address" or "locator", it ought to say so. Noel _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Thu Oct 16 12:18:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08683 for ; Thu, 16 Oct 2003 12:18:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAp8-0003Qb-Om for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 12:18:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GGI2rn013121 for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 12:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAp8-0003PJ-BB for saad-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 12:18:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08661 for ; Thu, 16 Oct 2003 12:17:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAp6-0006Mj-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 12:18:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAAp6-0006Mg-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 12:18:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAp7-0003Nj-6S; Thu, 16 Oct 2003 12:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAAok-0003Mw-03 for saad@optimus.ietf.org; Thu, 16 Oct 2003 12:17:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08649 for ; Thu, 16 Oct 2003 12:17:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAAoi-0006MX-00 for saad@ietf.org; Thu, 16 Oct 2003 12:17:36 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AAAoh-0006MU-00 for saad@ietf.org; Thu, 16 Oct 2003 12:17:36 -0400 Message-ID: <018201c393ff$a7431200$396015ac@dclkempt40> From: "James Kempf" To: "Michel Py" , "Geoff Huston" , References: Subject: Re: [saad] About saad Date: Thu, 16 Oct 2003 09:07:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit An IP address acts in two roles: 1) As a node or endpoint identifier to the transport layer for an end to end conversation. 2) As a locator for routing packets to a particular topological location. If a host is not mobile, there is no difficulty. However, for mobile hosts, there needs to be some way of separating out the two, because when the host moves to a different subnet, the original IP address can no longer be used as a routing locator. Mobile IP uses one method (the home address becomes the node identifier, the care of address becomes the routing locator), HIP uses another (the HID is the node identifier, the IP address is the routing locator) and MAST uses yet another (a case-based node identifier, the IP address as routing locator). jak ----- Original Message ----- From: "Michel Py" To: "James Kempf" ; "Geoff Huston" ; Sent: Thursday, October 16, 2003 8:59 AM Subject: RE: [saad] About saad > > James Kempf wrote: > > IPv4 still has the node identifier v.s. routing locater > > conflation problem for addresses, however. > > Can you explain "conflation" please? > > Michel. > > _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Thu Oct 16 22:17:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03424 for ; Thu, 16 Oct 2003 22:17:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAKAY-0008EZ-CC for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 22:16:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H2GkoH031647 for saad-archive@odin.ietf.org; Thu, 16 Oct 2003 22:16:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAKAY-0008EM-36 for saad-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 22:16:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03375 for ; Thu, 16 Oct 2003 22:16:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAKAU-0005Lx-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 22:16:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAKAU-0005Lm-00 for saad-web-archive@ietf.org; Thu, 16 Oct 2003 22:16:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAK9o-0008Ap-Ua; Thu, 16 Oct 2003 22:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAK8t-00088b-DO for saad@optimus.ietf.org; Thu, 16 Oct 2003 22:15:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03362 for ; Thu, 16 Oct 2003 22:14:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAK8l-0005LZ-00 for saad@ietf.org; Thu, 16 Oct 2003 22:14:55 -0400 Received: from zak.ecotroph.net ([216.93.164.123]) by ietf-mx with esmtp (Exim 4.12) id 1AAK8k-0005LW-00 for saad@ietf.org; Thu, 16 Oct 2003 22:14:54 -0400 Received: from thinkingcat.com ([::ffff:24.51.102.130]) (AUTH: LOGIN leslie, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zak.ecotroph.net with esmtp; Thu, 16 Oct 2003 22:14:54 -0400 Message-ID: <3F8F5044.5050004@thinkingcat.com> Date: Thu, 16 Oct 2003 22:13:24 -0400 From: Leslie Daigle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saad@ietf.org Subject: [Fwd: [Saad] Some initiating thoughts...] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I posted this a few days ago -- before, I think, people had a chance to get subscribed. So, let me re-post it for further discussion... Thanks, Leslie. -------- Original Message -------- Subject: [Saad] Some initiating thoughts... Date: Tue, 14 Oct 2003 22:11:47 -0400 From: Leslie Daigle To: saad@ietf.org As an initial contribution to this discussion list, I'm attaching a pre-draft that was prepared by IAB member Mark Handley as a result of reviewing the material of the IAB's Open Architecture meeting in Vienna. As noted in the text -- this is a first draft of thinking. While the IAB hasn't yet decided if this should be pursued as an IAB document, we thought it would be a useful discussion starting point for this mailing list. Leslie, for the IAB. -------- Internet Engineering Task Force IAB INTERNET-DRAFT Mark Handley (ed) draft-iab-addressing-2003815.txt 15 August 2003 $Revision: 1.1 $ Expires: NOT PUBLISHED Architectural Issues with IP Addressing 1. Introduction This document examines a range of architectural issues related to IP addressing. The motivation is that we perceive that a number of significant requirements are not being met by the currently deployed addressing architecture. In this document we do not attempt to find solutions to these problems; our goal is merely to collect the requirements to permit a reasoned discussion of solutions to take place. The initial content in this document was drawn from the proceedings of an Open IAB Meeting, held at the 57th IETF in Vienna in July 2003. 2. Background IP addresses have served both as a means of uniquely identifying a device interface that is attached to a network (an endpoint identifier), and as a means of identifying where a device is located within the network (a forwarding or routing identifier). IPv4 has two address types: o Unique addresses, which are normally global-use. o Private addresses [1], which are for local-use internets. Although it is not strictly required, the IPv4 address architecture largely assmed a unique binding of a device interface to an IP address. Essentially this means a device interface existed as a member of a single addressing realm. Private addresses were not originally intended to be connected to the global Internet, but the use of Network Address Translators has since become commonplace. A NAT enables limited communication between a host with a private address and hosts outside of its local-use internet. However NATs raise a large number of architectural problems in the way they do this [2]. Handley Section 2. [Page 1] INTERNET-DRAFT Expires: NOT PUBLISHED August 2003 In contrast, IPv6 defined three address types: o Unique addresses, which are normally global-use. o Site-Local addresses, which are for scoped local-use internets. o Link-Local addresses, which are for very local use. The IPv6 address architecture explicitly explored the potential of explicitly 'scoped' address realms coexisting with a global realm. Thus a device interface may have a globally unique address, a site-local address, and a link-local address simultaneously, and use them for different communications. At the time this model was devised, it was not entirely clear how this would work in practice, what architectural issues it addressed, and what new issues it raises. As IPv6 has moved into deployment, it has become clear that the complexity issues raised by the new addressing architecture, and in particular by the use of site-local addresses, are not negligable. Thus it behooves us to re-examine the requirements for Internet addressing in the light of more recent experience. 3. IP Addressing Requirements The Internet is a complex and heterogeneous network, and becoming more heterogeneous as time goes on. Different people and different subsystems in the network have different requirements on the addressing architecture; this is a classic example of a "tussle space" [3] between conflicting demands. 3.1. Addressing Requirements of Routing The structure of the address space should minimize the number of routing table entries. This is an issue both due to the sheer size of the forwarding table, and due to the rate of change of the forwarding table. Ideally the addressing architecture should allow for significant information hiding, such that the number of forwarding entries and number of updates to the forwarding table both scale O(log(n)) or better in number of connected subnets. Routing convergence times are dependent on the underlying topology of the network, on the routing protocols in use, and on the suitability of the addressing architecture for information hiding. Thus the structure of the address space should be suitable for minimizing routing convergence times. Handley Section 3.1. [Page 2] INTERNET-DRAFT Expires: NOT PUBLISHED August 2003 Forwarding performance cannot be neglected. Any address structure must permit efficient route lookup operations at backbone speeds. Secondary requirements here might also include multipath routing for load balancing purposes, and QoS-based scheduling [4]. Site multihoming is becoming commonplace, and should be regarded as being a nearly ubiquitous requirement in the future. The address architecture should provide support for multihoming, while simultaneously satisfying the requirements above. Mobility of both hosts and networks is likely to be a significant requirement in the future. While host mobility can be handled with solutions such as Mobile IP, this still imposes requirements on the address architecture related to moving between addressing realms. Network mobility imposes stronger requirements on addressing architecture, related to both disconnected operation and to the process of reconnecting to a new network attachment point without disrupting ongoing communications with the mobile network. While we do not see too many mobile networks in the current Internet, it is highly likely that there they will be a significant presense in the future. 3.2. Addressing Requirements of Enterprises A key requrirement of enterprises with regard to addressing is independence from their ISPs. To ensure good service from their ISP that matches their needs, an enterprise needs to be able to change ISP relatively easily. However, if an enterprise's internal network is numbered out of their ISP's address space then they need to renumber their internal network when changing ISP. As site-renumbering is considered painful and costly, this leads to provider lock-in which is clearly undesirable from the enterprise's point of view. Additional enterprise requirements include the ability to multi-home important hosts, server virtualization, and server load balancing. All of these may impact addressing architectures in different ways. Security is clearly a major concern for enterprises, and an important requirement is to be able to perform some degree of traffic isolation at security domain boundaries. While this is really the task of a firewall, there is a widespread view that the use of RFC 1918 private IPv4 addresses when combined with a SOCKS firewall or a NAT is an effective mechanism for enhancing traffic isolation. We note that the use of private addresses with a NAT instead of a correctly configured firewall has significant shortcomings from a security point of view, but it does have the advantage of being very simple to set up. Handley Section 3.2. [Page 3] INTERNET-DRAFT Expires: NOT PUBLISHED August 2003 Irrespective of the technology used to accomplish it, the specific security requirement that enterprises have on addressing is that it should be easy to set up a well-known and well-understood filter at security boundaries that reduces the exposure profile from individual configuration errors. Some enterprises have addressing requirements caused by the need to set up inter-enterprise Virtual Private Networks (VPNs). Also, at some point in their existence most enterprises undergo some form of merger or acquisition, and discover that they need to merge internal networks. In both these circumstances there is a requirement to avoid the need to renumber or to suffer from ambiguous addressing resulting from the merger of two private address spaces. 3.3. Addressing Requirements of Consumers As networking equipment becomes ubiquitous, an increasing fraction of networks will be owned and operated by people with minimal technical skills. The primary requirement that these users have is that addressing is autoconfiguring (or at the very least, trivial to configure). The user must not have to explicitly register their network addresses. Their network must function when first set up while being dsiconnected from the global Internet, and must permit later and intermittent commectivity without disrupting local communications. Consumer appliances must be able to ship with appropriate defaults so that they work "out of the box". At the same time, their default exposure to attack and denial-of-service needs to be minimalized. A key requirement on addressing is that much of this consumer equipment (printers, light switches, etc) needs to be able to communicate locally without being directly exposed to the global Internet. At the same time the same network infrastructure will be used by devices that do need global Internet access. 3.4. Addressing Requirements of Transport Protocols, Middleware and Applications Transport protocols including TCP and security associations may use the endpoint's IP address as an endpoint identifier. In the case of TCP, the binding is a loose one - so long as the IP address in incoming packets doesn't change during the connection lifetime, then TCP is happy. Other protocols may have more stringent requirements requiring both endpoints to have the same understanding of each other's addresses. Other protocols including SCTP may be address-agile. The transport association may be with multiple addresses rather than a single one, Handley Section 3.4. [Page 4] INTERNET-DRAFT Expires: NOT PUBLISHED August 2003 permitting failover. Alternatively this may be done at the middleware or application layers. If each endpoint has multiple addresses, the transport, middleware or application layer has the complex problem of choosing the correct pair of addresses to enable communication. There are two conflicting goals here: o To guarantee reachability between the endpoints. o To ensure that the traffic stays within the tightest possible administrative and security boundaries. Non-globally unique addresses present a particular problem. Essentially this is a routing problem, but one that must be solved above the network layer. Some applications have a requirement to support third-party references to addresses across both space and time. The simplest example is ftp, which uses the control channel to communicate the IP addresses to use for the data channel. However, while third-party ftp is rare, the problem is a more significant one for signalling protocols such as SIP [5] and RTSP [6]. Such protocols by their nature set up a signalling channel first, then initiate additional data channels. The need to do user-location with SIP or server load-balancing with RTSP means that it is commonplace for the initial control channel to be set up between different hosts than the final data channels, and so there is an inherent need to signal the identities of the end-systems that should comprise the data channel. While it may be safer to pass domain names instead of IP addresses in such cases, this may not always be possible. Finally, most applications would really prefer to never see addresses at all. They should not need to care whether a communiation is between IPv4 addresses, IPv6 addresses, or a mixture of the two. Notes Intermittently committed nets (ships, planes). 4. References [1] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. Handley Section 4. [Page 5] INTERNET-DRAFT Expires: NOT PUBLISHED August 2003 [2] B. Carpenter, "Internet Transparency", RFC 2775, February 2000. [3] David D. Clark, John Wroclawski, Karen R. Sollins, Robert Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", Proc. ACM SIGCOMM 2002. [4] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [5] [6] Handley Section 4. [Page 6] _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 00:38:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06329 for ; Fri, 17 Oct 2003 00:38:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMNG-0004ud-Dy for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 00:38:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H4c2jX018877 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 00:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMNG-0004uO-8S for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 00:38:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06319 for ; Fri, 17 Oct 2003 00:37:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAMND-0006Ms-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 00:37:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAMND-0006Mo-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 00:37:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMNE-0004u2-Li; Fri, 17 Oct 2003 00:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMMi-0004lc-G6 for saad@optimus.ietf.org; Fri, 17 Oct 2003 00:37:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06315 for ; Fri, 17 Oct 2003 00:37:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAMMf-0006Mk-00 for saad@ietf.org; Fri, 17 Oct 2003 00:37:25 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1AAMMf-0006Md-00 for saad@ietf.org; Fri, 17 Oct 2003 00:37:25 -0400 Subject: RE: [saad] About saad MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 16 Oct 2003 21:36:54 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: [saad] About saad thread-index: AcOUAM8sSjem6NP+Q7uWok2jqTQhgAAY8fYw From: "Michel Py" To: "J. Noel Chiappa" , Content-Transfer-Encoding: quoted-printable Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Noel, > J. Noel Chiappa wrote: > IPv4 tries to make sparing use of PI addresses for *exactly* the > same reasons as in IPv6 - too many will overload the routing. > The only difference is that with its greater address space, IPv6 > has even *more* rope to hang itself with, if it starts handing > out PI addresses. Indeed. Which is why we should not create PI addresses for IPv6. =20 > The semantics of IPv4 and IPv6 addresses are basically identical. > The only difference is in the number of bits. No. the difference is that IPv4 does officially have PI addresses, when IPv6 does not. It's a matter of hypocrisy for a large part, but here is our quandary: We can't have IPv6 PI the same way we have IPv4 PI (because then there will be very little incentive to move away from IPv4+NAT, especially when the predicted exhaustion of IPv4 is years ahead). But, if we don't have PI addresses this leads us to PA specifics announced in the GRT, NATv6, or both. To worsen the situation, the requirements to become a LIR are weak, which creates de-facto PI addresses. In other words: if we create IPv6 PI, we lose because then IPv6 would indeed be no more than IPv4 with more bits, which in turn will induce that nobody would buy it until the exhaustion of IPv4 becomes an urgent problem. If we do not create IPv6 PI, the demand for it will pervert other mechanisms such as announcing long PA prefixes (de-aggregation) or prefixes issued from the proposed Hinden/Haberman draft that are not aggregatable at all. Lose/Lose. The way out of this is to provide PI IDENTIFIERS carried on the network using PA LOCATORS, which are aggregatable. > A different routing algorithm/protocol might have a *one-time* > improvement in overhead, but in the long run, the curve is going > to have the same kind of shape. Having to track too many distinct > destinations (which is roughly equivalent to "routing table size") > will overwhelm *any* routing architecture. I personally agree, but I will point out that there is a large and rather silent camp that thinks we don't have a problem as long as we ride Moore's law. >> choosing between different identifiers for an object >> ^^^^^^^^^^^ >> which has different "reachability" and the reachability >> is context-dependent >> Shouldn't "identifiers" above be "locators"? I vaguely assume that an >> object can have multiple locators but should have only one identifier. =20 > It all depends on what is meant by the term "identifier" here. > (The document probably needs some editing for precision, etc.) > If it means "a name used for end-end identification", it would be > a problem; and I would like to understand what the architectural > need is for multiple end-end names for a single end-end entity. > If it means "address" or "locator", it ought to say so. Given what I mentioned above, it can't mean "locator". Michel. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 01:18:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07048 for ; Fri, 17 Oct 2003 01:18:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMzx-0006Kh-UR for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 01:18:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H5I1mt024337 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 01:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMzx-0006KS-Or for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 01:18:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07045 for ; Fri, 17 Oct 2003 01:17:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAMzu-0006d3-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 01:17:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAMzu-0006d0-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 01:17:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMzw-0006K6-RH; Fri, 17 Oct 2003 01:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMzH-0006JO-C0 for saad@optimus.ietf.org; Fri, 17 Oct 2003 01:17:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07037 for ; Fri, 17 Oct 2003 01:17:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAMzE-0006cm-00 for saad@ietf.org; Fri, 17 Oct 2003 01:17:16 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1AAMzD-0006ch-00 for saad@ietf.org; Fri, 17 Oct 2003 01:17:15 -0400 Subject: RE: [Fwd: [Saad] Some initiating thoughts...] MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 16 Oct 2003 22:16:46 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: [Fwd: [Saad] Some initiating thoughts...] thread-index: AcOUWBrvqtIuv5R6R/qq+Xf8KhnzGgACv98g From: "Michel Py" To: "Leslie Daigle" , Content-Transfer-Encoding: quoted-printable Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Leslie, > Leslie Daigle wrote: > I posted this a few days ago -- before, I think, people had > a chance to get subscribed IMHO, this text is a good short assessment of the situation. Needs some more work, but a good base. > [draft-iab-addressing-2003815.txt] > Although it is not strictly required, the IPv4 address > architecture largely assumed a unique binding of a device > interface to an IP address. Essentially this means a > device interface existed as a member of a single > addressing realm. With IPv6, a large number of issues with SLs and scoping are a direct consequence of the disappearance of this unique binding. Save for LLs which are a different kind of animal because they are not routable, the very assumption of multiple addresses per host has caused us a lot of trouble. IMHO the only way we could make any kind of scoping architecture work is to accept the following restriction: If scope is to be used, a host can have only two IPv6 addresses per interface: a link-local and another one, which would be routable but with possibly a have limited reachability depending on the scope. It would then be a design element to decide to use either multiaddressing or scoping. The idea behind scoping is that it should be a largely-automatic access control system, likely as a fail-safe for explicit filtering or firewalling. This means that hosts would not need to be aware of the scope except to make the distinction between LL and routable. Note that, for a many enterprise operators, the "restriction" of having only two addresses per host per interface which is very similar to the existing IPv4 situation is a feature, not a bug. Regardless of issues with scoping, multiple routable addresses per interface simply are too much complication. I am not saying that multiadressing is bad, what I am saying is that multiaddressing does not work in certain situations. This list is focused on scoping. I am aware that some identifier/locator solutions propose that the IPv6 address is used only as a locator, the identifier being a different type of animal. In the situations where scoping is desired, the way out IMHO is that the host's routable address is the identifier (the reason being it would be a lot simpler to scope than a flexible-shape identifier) and that there is a shim layer between Transport and Network that does the identifier / locator mapping. Michel. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 01:38:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07522 for ; Fri, 17 Oct 2003 01:38:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AANJL-000774-At for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 01:38:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H5c3WC027336 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 01:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AANJL-00076R-4y for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 01:38:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07500 for ; Fri, 17 Oct 2003 01:37:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AANJH-0006nt-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 01:37:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AANJH-0006nq-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 01:37:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AANJJ-00075t-FS; Fri, 17 Oct 2003 01:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AANJD-000745-9I for saad@optimus.ietf.org; Fri, 17 Oct 2003 01:37:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07490 for ; Fri, 17 Oct 2003 01:37:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AANJ9-0006nc-00 for saad@ietf.org; Fri, 17 Oct 2003 01:37:52 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AANJ9-0006n0-00 for saad@ietf.org; Fri, 17 Oct 2003 01:37:51 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9H5bKQY027418; Thu, 16 Oct 2003 22:37:20 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (rtp-vpn1-107.cisco.com [10.82.224.107]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMP62295; Thu, 16 Oct 2003 22:36:47 -0700 (PDT) Message-Id: <6.0.0.22.2.20031016120745.04522090@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 16 Oct 2003 15:13:30 -0400 To: "James Kempf" From: Fred Baker Subject: Re: [saad] About saad Cc: In-Reply-To: <018201c393ff$a7431200$396015ac@dclkempt40> References: <018201c393ff$a7431200$396015ac@dclkempt40> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , At 12:07 PM 10/16/2003, James Kempf wrote: >An IP address acts in two roles: > >1) As a node or endpoint identifier to the transport layer for an end to end >conversation. > >2) As a locator for routing packets to a particular topological location. actually, I will argue that the endpoint identifier is the dns name. That has problems in that - it needs to be able to name a service and get the address of the most serviceable instance of a computer offering it to the requestor; it currently simply offers *an* address of a list of addresses from which the requestor needs to choose at random - it presumes a global address space (there is no concept of "source route to this gateway address and then to that private address", or the obvious generalization) - A list of other things I will think of just after I send this email But it in fact acts to identify the intended endpoint. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 09:39:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01761 for ; Fri, 17 Oct 2003 09:39:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUos-0005QK-Uf for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 09:39:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HDd6hf020842 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 09:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUos-0005Q5-Lq for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 09:39:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01757 for ; Fri, 17 Oct 2003 09:38:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUoq-0003Ug-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 09:39:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAUoq-0003Ud-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 09:39:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUoo-0005PN-76; Fri, 17 Oct 2003 09:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUog-0005P4-LT for saad@optimus.ietf.org; Fri, 17 Oct 2003 09:38:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01754 for ; Fri, 17 Oct 2003 09:38:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUoe-0003Ua-00 for saad@ietf.org; Fri, 17 Oct 2003 09:38:52 -0400 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AAUod-0003UL-00 for saad@ietf.org; Fri, 17 Oct 2003 09:38:51 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9HDc6oS115336; Fri, 17 Oct 2003 15:38:06 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9HDc5mw237662; Fri, 17 Oct 2003 15:38:05 +0200 Received: from zurich.ibm.com (sig-9-145-145-206.de.ibm.com [9.145.145.206]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA70426; Fri, 17 Oct 2003 15:38:04 +0200 Message-ID: <3F8FF09D.7A9B0787@zurich.ibm.com> Date: Fri, 17 Oct 2003 15:37:34 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Fred Baker CC: saad@ietf.org Subject: Re: [saad] About saad References: <018201c393ff$a7431200$396015ac@dclkempt40> <6.0.0.22.2.20031016120745.04522090@mira-sjc5-b.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This raises a meta-question in my mind. How are we going to prevent this list simply repeating all the discussion that took place in the NSRG and elsewhere? The reasons why FQDNs are imperfect EIDs have been listed quite recently (on one of the IPV6 lists I think). Brian Fred Baker wrote: > > At 12:07 PM 10/16/2003, James Kempf wrote: > >An IP address acts in two roles: > > > >1) As a node or endpoint identifier to the transport layer for an end to end > >conversation. > > > >2) As a locator for routing packets to a particular topological location. > > actually, I will argue that the endpoint identifier is the dns name. That > has problems in that > > - it needs to be able to name a service and get the address of the most > serviceable instance of a computer offering it to the requestor; it > currently simply offers *an* address of a list of addresses from which the > requestor needs to choose at random > > - it presumes a global address space (there is no concept of "source > route to this gateway address and then to that private address", or the > obvious generalization) > > - A list of other things I will think of just after I send this email > > But it in fact acts to identify the intended endpoint. > > _______________________________________________ > Saad mailing list > Saad@ietf.org > https://www1.ietf.org/mailman/listinfo/saad -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 11:32:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06643 for ; Fri, 17 Oct 2003 11:32:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWa9-00023T-Rw for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 11:32:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HFW18Z007897 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 11:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWa9-00023I-HC for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 11:32:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06584 for ; Fri, 17 Oct 2003 11:31:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWa8-0004XZ-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 11:32:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAWa8-0004XV-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 11:32:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWa8-00022s-8K; Fri, 17 Oct 2003 11:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWZl-00021v-KM for saad@optimus.ietf.org; Fri, 17 Oct 2003 11:31:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06557 for ; Fri, 17 Oct 2003 11:31:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWZk-0004Wi-00 for saad@ietf.org; Fri, 17 Oct 2003 11:31:36 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AAWZj-0004We-00 for saad@ietf.org; Fri, 17 Oct 2003 11:31:35 -0400 Message-ID: <009d01c394c3$c91c3b30$396015ac@dclkempt40> From: "James Kempf" To: "Fred Baker" Cc: References: <018201c393ff$a7431200$396015ac@dclkempt40> <6.0.0.22.2.20031016120745.04522090@mira-sjc5-b.cisco.com> Subject: Re: [saad] About saad Date: Fri, 17 Oct 2003 08:31:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Fred, The DNS is a node identifier, but it currently can't be used by the transport layer as a connection endpoint identifier. There are have also been some experimental proposals (viz. Cheriton's TRIAD work) to use DNS names for routing. jak ----- Original Message ----- From: "Fred Baker" To: "James Kempf" Cc: Sent: Thursday, October 16, 2003 12:13 PM Subject: Re: [saad] About saad > At 12:07 PM 10/16/2003, James Kempf wrote: > >An IP address acts in two roles: > > > >1) As a node or endpoint identifier to the transport layer for an end to end > >conversation. > > > >2) As a locator for routing packets to a particular topological location. > > actually, I will argue that the endpoint identifier is the dns name. That > has problems in that > > - it needs to be able to name a service and get the address of the most > serviceable instance of a computer offering it to the requestor; it > currently simply offers *an* address of a list of addresses from which the > requestor needs to choose at random > > - it presumes a global address space (there is no concept of "source > route to this gateway address and then to that private address", or the > obvious generalization) > > - A list of other things I will think of just after I send this email > > But it in fact acts to identify the intended endpoint. > > _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 12:55:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10204 for ; Fri, 17 Oct 2003 12:55:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAXsU-0006cy-W6 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 12:55:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HGt2JZ025470 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 12:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAXsU-0006cj-R4 for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 12:55:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10176 for ; Fri, 17 Oct 2003 12:54:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAXsT-0005Zo-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 12:55:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAXsS-0005Zl-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 12:55:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAXsT-0006bk-F0; Fri, 17 Oct 2003 12:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAXrq-0006X3-Bi for saad@optimus.ietf.org; Fri, 17 Oct 2003 12:54:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10122 for ; Fri, 17 Oct 2003 12:54:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAXro-0005YW-00 for saad@ietf.org; Fri, 17 Oct 2003 12:54:20 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1AAXro-0005Xk-00 for saad@ietf.org; Fri, 17 Oct 2003 12:54:20 -0400 Subject: RE: [saad] About saad Date: Fri, 17 Oct 2003 09:53:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: [saad] About saad thread-index: AcOUxMTRzVdxm9knRQi2wwPjA+ul+gABVmsg From: "Michel Py" To: "James Kempf" , "Fred Baker" Cc: Content-Transfer-Encoding: quoted-printable Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Folks, > James Kempf wrote: > The DNS is a node identifier, but it currently can't be used by > the transport layer as a connection endpoint identifier. Nor by the network layer. > Brian E Carpenter wrote: > The reasons why FQDNs are imperfect EIDs have been listed quite > recently (on one of the IPV6 lists I think). Indeed. Besides, what we are talking about is scoping, and one of the things that is totally in scope is to discuss at which layer(s) scoping shall occur. IMHO, scoping shall occur at the IP layer. The fact of the matter is (as this discussion as shown) it seems that scoping is tied to the identifier. I think that one of the sound discussions we should have is to identify if indeed this is true. My vote is yes. Now, _if_ the identifier is moved above the network layer, and if scope is tied to the identifier as we might or might not decide it is, we suddenly have a layer violation, because scope is going to be used at the routing layer (the IP layer) and for the same reason routing must not use DNS (because DNS needs routing) we will likely bump into the issue that scope could not use {whatever the identifier in an upper layer is} because of the same circular reference issue. So, IMHO the beginning of the decision tree is: | v | /\ / \ / Is \ +----------------------------+ /scope \ | Since we don't have | / tied \ | identifiers at another | / to the \ yes | layer than IP now, | \identifier/--->---+ scoping is to be done | \or not? / | at the network layer. | \ / | if we ever get identifiers | \ / | in other layers, situation | \ / | will be revisited then. | \/ +----------------------------+ | v no | +----+----------+ | what are the | | reasons to | | move scope to | | another layer | | than IP? | +----+----------+ | | ??? | Comments? Michel. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 13:13:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11064 for ; Fri, 17 Oct 2003 13:13:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAY9v-0007hM-2G for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 13:13:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HHD3bJ029589 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 13:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAY9u-0007hA-FA for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 13:13:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11054 for ; Fri, 17 Oct 2003 13:12:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAY9s-0005py-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 13:13:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAY9s-0005pv-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 13:13:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAY9t-0007gl-EB; Fri, 17 Oct 2003 13:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAY9e-0007fj-SD for saad@optimus.ietf.org; Fri, 17 Oct 2003 13:12:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11047 for ; Fri, 17 Oct 2003 13:12:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAY9c-0005ps-00 for saad@ietf.org; Fri, 17 Oct 2003 13:12:44 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AAY9b-0005pp-00 for saad@ietf.org; Fri, 17 Oct 2003 13:12:44 -0400 Message-ID: <021401c394d0$861298e0$396015ac@dclkempt40> From: "James Kempf" To: "Michel Py" Cc: References: Subject: Why Scopes? (was: Re: [saad] About saad) Date: Fri, 17 Oct 2003 10:03:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One of the things I'd like to see is a list of why people use scoped addresses (RFC 1918) in IPv4. Clearly, NATs are popular in IPv4 for reasons other than lack of address space, and simply condemning them as evil or even arguing against them without understanding why people want them isn't likely to result in a usable technical solution, and probably won't persuade people to stop using them anyway. Given that list, one could then go through it and figure out what reasons really do need to be dealt with at the network layer and what reasons could more easily be dealt with at another layer. The result could be a kind of list of requirements for a technical solution. The solution need not be a new one, but it also could be. I've never seen such an analysis done during the entire discussion on the IPv6 list, though occasionally people do mention some reasons in email. jak ----- Original Message ----- From: "Michel Py" To: "James Kempf" ; "Fred Baker" Cc: Sent: Friday, October 17, 2003 9:53 AM Subject: RE: [saad] About saad > Folks, > > > > James Kempf wrote: > > The DNS is a node identifier, but it currently can't be used by > > the transport layer as a connection endpoint identifier. > > Nor by the network layer. > > > > Brian E Carpenter wrote: > > The reasons why FQDNs are imperfect EIDs have been listed quite > > recently (on one of the IPV6 lists I think). > > Indeed. Besides, what we are talking about is scoping, and one of the > things that is totally in scope is to discuss at which layer(s) scoping > shall occur. > > > IMHO, scoping shall occur at the IP layer. The fact of the matter is (as > this discussion as shown) it seems that scoping is tied to the > identifier. I think that one of the sound discussions we should have is > to identify if indeed this is true. My vote is yes. > > Now, _if_ the identifier is moved above the network layer, and if scope > is tied to the identifier as we might or might not decide it is, we > suddenly have a layer violation, because scope is going to be used at > the routing layer (the IP layer) and for the same reason routing must > not use DNS (because DNS needs routing) we will likely bump into the > issue that scope could not use {whatever the identifier in an upper > layer is} because of the same circular reference issue. > > So, IMHO the beginning of the decision tree is: > > | > v > | > /\ > / \ > / Is \ +----------------------------+ > /scope \ | Since we don't have | > / tied \ | identifiers at another | > / to the \ yes | layer than IP now, | > \identifier/--->---+ scoping is to be done | > \or not? / | at the network layer. | > \ / | if we ever get identifiers | > \ / | in other layers, situation | > \ / | will be revisited then. | > \/ +----------------------------+ > | > v no > | > +----+----------+ > | what are the | > | reasons to | > | move scope to | > | another layer | > | than IP? | > +----+----------+ > | > | ??? > | > > > Comments? > > Michel. > > > _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 13:59:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13563 for ; Fri, 17 Oct 2003 13:59:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYsQ-000248-3w for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 13:59:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HHx2dc007934 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 13:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYsP-00023t-V8 for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 13:59:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13515 for ; Fri, 17 Oct 2003 13:58:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYsN-0006WI-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 13:58:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAYsN-0006WF-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 13:58:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYsO-00023W-Eh; Fri, 17 Oct 2003 13:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYrU-0001yi-LG for saad@optimus.ietf.org; Fri, 17 Oct 2003 13:58:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13408 for ; Fri, 17 Oct 2003 13:57:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYrS-0006Tm-00 for saad@ietf.org; Fri, 17 Oct 2003 13:58:02 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AAYrR-0006Sb-00 for saad@ietf.org; Fri, 17 Oct 2003 13:58:01 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9HHvSeA005555; Fri, 17 Oct 2003 10:57:29 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (sjc-vpn4-871.cisco.com [10.21.83.102]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMQ03697; Fri, 17 Oct 2003 10:57:13 -0700 (PDT) Message-Id: <6.0.0.22.2.20031017133440.045fb7e8@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 17 Oct 2003 13:38:11 -0400 To: "James Kempf" From: Fred Baker Subject: Re: [saad] About saad Cc: In-Reply-To: <009d01c394c3$c91c3b30$396015ac@dclkempt40> References: <018201c393ff$a7431200$396015ac@dclkempt40> <6.0.0.22.2.20031016120745.04522090@mira-sjc5-b.cisco.com> <009d01c394c3$c91c3b30$396015ac@dclkempt40> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , At 11:31 AM 10/17/2003, James Kempf wrote: >The DNS is a node identifier, but it currently can't be used by the >transport layer as a connection endpoint identifier. And neither can a interface address, at least not in the same way. As you noted, one could use a MIP Home Address as a CEPID, because it is invariant across interface failures, routing changes, and motion. >There are have also been some experimental proposals (viz. Cheriton's >TRIAD work) to use DNS names for routing. Yes. If you believe that names should be in the application layer and addresses should be in the network layer, moving names down is as problematic as moving addresses up, for the same reason. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 14:32:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15084 for ; Fri, 17 Oct 2003 14:32:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZON-0003dQ-QG for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 14:32:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HIW3WO013971 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 14:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZON-0003dG-MR for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 14:32:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15080 for ; Fri, 17 Oct 2003 14:31:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZOL-0006yI-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 14:32:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAZOK-0006yF-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 14:32:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZOL-0003co-Ju; Fri, 17 Oct 2003 14:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZO8-0003cS-2h for saad@optimus.ietf.org; Fri, 17 Oct 2003 14:31:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15074 for ; Fri, 17 Oct 2003 14:31:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZO5-0006y6-00 for saad@ietf.org; Fri, 17 Oct 2003 14:31:45 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AAZO4-0006y3-00 for saad@ietf.org; Fri, 17 Oct 2003 14:31:45 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Oct 2003 11:28:28 -0700 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 h9HIVCeA015650; Fri, 17 Oct 2003 11:31:12 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-42.cisco.com [10.32.241.42]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANG51414; Fri, 17 Oct 2003 11:31:10 -0700 (PDT) Date: Fri, 17 Oct 2003 14:31:09 -0400 Subject: Re: Why Scopes? (was: Re: [saad] About saad) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "James Kempf" From: Melinda Shore In-Reply-To: <021401c394d0$861298e0$396015ac@dclkempt40> Message-Id: <13D76828-00D0-11D8-B6D5-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, October 17, 2003, at 01:03 PM, James Kempf wrote: > One of the things I'd like to see is a list of why people use scoped > addresses (RFC 1918) in IPv4. I've talked to a very large number of people about this (or rather why they use NATs, which is a slightly different question), and the most common reasons are: 1) don't want to buy more addresses 2) simplification of network management/renumbering 3) security/firewalling/unreachability The first two are already being dealt with in one form or another. The third is only peripherally being addressed and certainly not satisfactorily (for whatever value of "satisfactory"). The reality is that some large number of users, including some users who consider themselves relatively expert (network administrators, etc.) don't want their hosts to be reachable by default but they do want them to be able to initiate connections themselves. I'm not sure there's a good answer to this question, since the users' wishes are incompatible with the IETF's working assumptions about reachability. There was a BOF on distributed firewalls several meetings ago that I think is at least in some way relevant, but 1) there doesn't seem to be a lot of momentum behind it, and 2) some jiggering would be required. Also, this really is a big-A architecture problem that involves pulling together some disparate technologies, and has been noted elsewhere, the IETF doesn't do this sort of thing very well. Melinda _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 15:09:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16717 for ; Fri, 17 Oct 2003 15:09:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZyB-0005Le-3Y for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 15:09:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HJ93rn020552 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 15:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZyA-0005LO-TH for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 15:09:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16638 for ; Fri, 17 Oct 2003 15:08:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZy7-0007E3-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 15:08:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAZy7-0007E0-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 15:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZy9-0005KX-Gu; Fri, 17 Oct 2003 15:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZy3-0005KJ-Pf for saad@optimus.ietf.org; Fri, 17 Oct 2003 15:08:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16625 for ; Fri, 17 Oct 2003 15:08:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZy0-0007Dx-00 for saad@ietf.org; Fri, 17 Oct 2003 15:08:52 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AAZy0-0007Du-00 for saad@ietf.org; Fri, 17 Oct 2003 15:08:52 -0400 Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9HJE7f07745 for ; Fri, 17 Oct 2003 12:14:08 -0700 Date: Fri, 17 Oct 2003 15:10:23 -0400 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <7325372774.20031017151023@brandenburg.com> To: saad@ietf.org Subject: Re: [saad] About saad In-Reply-To: <3F8FF09D.7A9B0787@zurich.ibm.com> References: <018201c393ff$a7431200$396015ac@dclkempt40> <6.0.0.22.2.20031016120745.04522090@mira-sjc5-b.cisco.com> <3F8FF09D.7A9B0787@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, BEC> The reasons why FQDNs are imperfect EIDs have been listed quite recently BEC> (on one of the IPV6 lists I think). As a proponent of using domain names as endpoint identifiers -- for those situations requiring only occasional exchanges -- I have put some effort into looking for the discussions that argue against their use. My goal is, of course, to then try to refute the arguments. If I can't find convincing counter-arguments, I'll change my advocacy. So far, I have not found arguments that are pragmatic and operational. The arguments against domain names have primarily been based on principles and aesthetics. These are important for guidance, but should not get in the way of pragmatics. New namespaces are expensive, particularly when they need global administration. What I am looking for are arguments that explain how use of domain names as EIDs "will not work" or arguments that explain how use of them will break other things. I've even tried to ask such questions in a few venues. Sadly, responses that attend to pragmatics have not been forthcoming. So, if there is a discussion that really explains the pragmatic problems with using domain names, I would greatly appreciate being pointed at it. Failing that, I'm afraid that, yes, this list should discuss the question. Let me prime the pump: 1. Concern: Domain names are overloaded; they get used for too many things already. Response: So? What problems are caused by this and how does it prevent them from being used as EIDs? How will using them as EIDs -- and we can skip over the argument that they already _are_ EIDs, for the moment -- break any of the other uses for domain names? 2. Concern: DNS administration is difficult Response: But it exists and it works. Persistent names need administration. Why is something new going to be easier? What can't the mechanisms that make it easier be applied to the DNS? Why won't adding them to DNS be substantially easier than creating a new, global administrative mechanism? 3. Concern: Domain names are inefficient to use Response: If they must be used in every packet, that is true. If they must be used only occasionally, such as at the start of an association or at major state change events, then the bit-inefficiency of domain names is irrelevant to the overall efficiency of the service that is using it. 4. Concern: Domain names are administered by a different entity than the folks who administer IP operations Response: Is this a turf war? Is there some reason to believe that having the new namespace administered by another group is somehow going to make the new names trivial to administer, compared with domain names? The mere fact that the new namespace _might_ be administered by a different group does not guarantee that the reality of administering it is any better than the reality of administering domain names. 5. Concern: Not all machines have domain names. Response: _No_ machines have whatever the alternative might be. And so on. OK. Consider the pump primed. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 16:01:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20926 for ; Fri, 17 Oct 2003 16:01:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAamX-0007hT-8m for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 16:01:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HK15Ip029598 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 16:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAamX-0007hJ-4H for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 16:01:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20897 for ; Fri, 17 Oct 2003 16:00:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAamV-0000PU-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 16:01:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAamV-0000PR-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 16:01:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAamU-0007fv-5m; Fri, 17 Oct 2003 16:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAala-0007d0-2W for saad@optimus.ietf.org; Fri, 17 Oct 2003 16:00:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20837 for ; Fri, 17 Oct 2003 15:59:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAalY-0000OT-00 for saad@ietf.org; Fri, 17 Oct 2003 16:00:04 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AAalX-0000OH-00 for saad@ietf.org; Fri, 17 Oct 2003 16:00:03 -0400 Message-ID: <034f01c394e9$49bb7a60$396015ac@dclkempt40> From: "James Kempf" To: "Dave Crocker" , References: <018201c393ff$a7431200$396015ac@dclkempt40> <6.0.0.22.2.20031016120745.04522090@mira-sjc5-b.cisco.com> <3F8FF09D.7A9B0787@zurich.ibm.com> <7325372774.20031017151023@brandenburg.com> Subject: Re: [saad] About saad Date: Fri, 17 Oct 2003 13:00:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dave, So, as I understand it (and having read through the MAST paper), what you are proposing is a Layer 3.5 or maybe Layer 4 Session-like Layer in which the FQDNs are used for global node identification initially to set up a more compact temporary node identifier. Is that right? jak ----- Original Message ----- From: "Dave Crocker" To: Sent: Friday, October 17, 2003 12:10 PM Subject: Re: [saad] About saad > Brian, > > BEC> The reasons why FQDNs are imperfect EIDs have been listed quite recently > BEC> (on one of the IPV6 lists I think). > > As a proponent of using domain names as endpoint identifiers -- for those > situations requiring only occasional exchanges -- I have put some effort > into looking for the discussions that argue against their use. > > My goal is, of course, to then try to refute the arguments. If I can't > find convincing counter-arguments, I'll change my advocacy. > > So far, I have not found arguments that are pragmatic and operational. > The arguments against domain names have primarily been based on > principles and aesthetics. These are important for guidance, but should > not get in the way of pragmatics. New namespaces are expensive, > particularly when they need global administration. > > What I am looking for are arguments that explain how use of domain names > as EIDs "will not work" or arguments that explain how use of them will > break other things. > > I've even tried to ask such questions in a few venues. Sadly, responses > that attend to pragmatics have not been forthcoming. > > So, if there is a discussion that really explains the pragmatic problems > with using domain names, I would greatly appreciate being pointed at it. > > Failing that, I'm afraid that, yes, this list should discuss the > question. > > Let me prime the pump: > > > 1. Concern: Domain names are overloaded; they get used for too many things > already. > > Response: So? What problems are caused by this and how does it prevent > them from being used as EIDs? How will using them as EIDs -- and we can > skip over the argument that they already _are_ EIDs, for the moment -- > break any of the other uses for domain names? > > > 2. Concern: DNS administration is difficult > > Response: But it exists and it works. Persistent names need > administration. Why is something new going to be easier? What can't the > mechanisms that make it easier be applied to the DNS? Why won't adding > them to DNS be substantially easier than creating a new, global > administrative mechanism? > > > 3. Concern: Domain names are inefficient to use > > Response: If they must be used in every packet, that is true. If they > must be used only occasionally, such as at the start of an association > or at major state change events, then the bit-inefficiency of domain > names is irrelevant to the overall efficiency of the service that is > using it. > > > 4. Concern: Domain names are administered by a different entity than the > folks who administer IP operations > > Response: Is this a turf war? Is there some reason to believe that > having the new namespace administered by another group is somehow going > to make the new names trivial to administer, compared with domain names? > The mere fact that the new namespace _might_ be administered by a > different group does not guarantee that the reality of administering it > is any better than the reality of administering domain names. > > > 5. Concern: Not all machines have domain names. > > Response: _No_ machines have whatever the alternative might be. > > And so on. > > OK. Consider the pump primed. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > > > _______________________________________________ > Saad mailing list > Saad@ietf.org > https://www1.ietf.org/mailman/listinfo/saad > _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 16:10:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21720 for ; Fri, 17 Oct 2003 16:10:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAavF-0008IG-1u for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 16:10:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HKA5a0031874 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 16:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAavD-0008HY-FG for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 16:10:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21635 for ; Fri, 17 Oct 2003 16:09:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAavB-0000dX-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 16:10:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAavB-0000dU-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 16:10:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAavB-0008H7-0X; Fri, 17 Oct 2003 16:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAauT-0008EL-Fo for saad@optimus.ietf.org; Fri, 17 Oct 2003 16:09:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21525 for ; Fri, 17 Oct 2003 16:09:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAauR-0000bg-00 for saad@ietf.org; Fri, 17 Oct 2003 16:09:15 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AAauQ-0000aX-00 for saad@ietf.org; Fri, 17 Oct 2003 16:09:14 -0400 Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9HKETf12093; Fri, 17 Oct 2003 13:14:29 -0700 Date: Fri, 17 Oct 2003 16:10:41 -0400 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <2728990866.20031017161041@brandenburg.com> To: "James Kempf" CC: saad@ietf.org Subject: Re: [saad] About saad In-Reply-To: <034f01c394e9$49bb7a60$396015ac@dclkempt40> References: <018201c393ff$a7431200$396015ac@dclkempt40> <6.0.0.22.2.20031016120745.04522090@mira-sjc5-b.cisco.com> <3F8FF09D.7A9B0787@zurich.ibm.com> <7325372774.20031017151023@brandenburg.com> <034f01c394e9$49bb7a60$396015ac@dclkempt40> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, JK> So, as I understand it (and having read through the MAST paper), what you JK> are proposing is a Layer 3.5 or maybe Layer 4 Session-like Layer in which JK> the FQDNs are used for global node identification initially to set up a more JK> compact temporary node identifier. JK> Is that right? That is remarkably more concise (compact) than I have been saying, but I think the answer is yes. In particular, I have not been noting explicitly is the relationship between the two identifiers. Your description is very helpful. Thanks! d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 16:18:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22403 for ; Fri, 17 Oct 2003 16:18:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAb2w-00006I-0v for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 16:18:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HKI1Tr000380 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 16:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAb2v-000063-R7 for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 16:18:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22376 for ; Fri, 17 Oct 2003 16:17:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAb2u-0000te-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 16:18:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAb2t-0000tb-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 16:17:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAb2v-00005g-1B; Fri, 17 Oct 2003 16:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAb2d-00005T-Fp for saad@optimus.ietf.org; Fri, 17 Oct 2003 16:17:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22365 for ; Fri, 17 Oct 2003 16:17:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAb2b-0000tM-00 for saad@ietf.org; Fri, 17 Oct 2003 16:17:41 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AAb2a-0000tE-00 for saad@ietf.org; Fri, 17 Oct 2003 16:17:41 -0400 Message-ID: <035501c394eb$c0f0fc70$396015ac@dclkempt40> From: "James Kempf" To: "Melinda Shore" Cc: References: <13D76828-00D0-11D8-B6D5-000A95E35274@cisco.com> Subject: Re: Why Scopes? (was: Re: [saad] About saad) Date: Fri, 17 Oct 2003 13:17:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > On Friday, October 17, 2003, at 01:03 PM, James Kempf wrote: > > One of the things I'd like to see is a list of why people use scoped > > addresses (RFC 1918) in IPv4. > > I've talked to a very large number of people about this (or > rather why they use NATs, which is a slightly different > question), and the most common reasons are: > > 1) don't want to buy more addresses > 2) simplification of network management/renumbering > 3) security/firewalling/unreachability > > The first two are already being dealt with in one form > or another. The third is only peripherally being addressed > and certainly not satisfactorily (for whatever value of > "satisfactory"). The reality is that some large number > of users, including some users who consider themselves > relatively expert (network administrators, etc.) don't want > their hosts to be reachable by default but they do want > them to be able to initiate connections themselves. I'm > not sure there's a good answer to this question, since > the users' wishes are incompatible with the IETF's working > assumptions about reachability. > But there are other ways that one could imagine doing this and still maintain global routability only on the outbound connection. For example, I've got a NAT at home on my 802.11/802.3/DSL access box. Now, as a consumer, I don't have much choice in the matter: it's the only technology out there that provides the functionality I want. And, it was really easy to set up: plug it in, configure via a Web page, and it worked. I suppose I could pay my DSL provider for more addresses, but I typically just use one machine at a time (it might not be the same machine) but not always and I don't leave it on all the time (due to electricity cost). Suppose that, instead of a NAT, I could buy a box that had some number of globally routable IP addresses preconfigured into it (and I could get more by downloading them from the manufacturer via their Web page, maybe paying a small fee). Suppose also there were some way for that box to communicate with my service provider, without requiring a complex human intermediated (and perhaps suits intermediated) business and technical conversation to set up routing characteristics between the box and my ISP's network. The communication would allow global routing outbound for purposes of initiating a connection, but not inbound, and would be driven off my service profile with the ISP (so that, for example, if I had a server, was paying more, and needed the inbound connectivity, that would happen). This would have no impact on the address architecture. The addressess on the box could be globally routable, they could be HH IPv6 provider-independent (if I'm using IPv6), but they need not be, since the manufacturer of the box could apply to their local RIR for the address block like anybody else that wants addresses. It would only require the routing reachability to be configured properly, and in a way that is considerably more automated than today. jak _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 17:35:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25514 for ; Fri, 17 Oct 2003 17:35:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAcFT-0004GX-Ue for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 17:35:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HLZ3O2016397 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 17:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAcFT-0004GO-JT for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 17:35:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25496 for ; Fri, 17 Oct 2003 17:34:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAcFR-0001tQ-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 17:35:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAcFQ-0001tN-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 17:35:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAcFR-0004Fy-UV; Fri, 17 Oct 2003 17:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAcEg-0004Ey-RT for saad@optimus.ietf.org; Fri, 17 Oct 2003 17:34:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25464 for ; Fri, 17 Oct 2003 17:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAcEe-0001sW-00 for saad@ietf.org; Fri, 17 Oct 2003 17:34:12 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1AAcEc-0001rp-00 for saad@ietf.org; Fri, 17 Oct 2003 17:34:10 -0400 Content-class: urn:content-classes:message Subject: RE: Why Scopes? (was: Re: [saad] About saad) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 17 Oct 2003 14:33:39 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Why Scopes? (was: Re: [saad] About saad) thread-index: AcOU0e+VBggjjp1nT2y8ylRc4UCEwgAAragg From: "Michel Py" To: "James Kempf" Cc: Content-Transfer-Encoding: quoted-printable Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable James, > James Kempf wrote: > One of the things I'd like to see is a list of why people > use scoped addresses (RFC 1918) in IPv4. I have some text about this, see below. Note: in the text below, the reason I state that some reasons are actually non-reasons is because the motive behind the use of scoped addresses (RFC1918) is _not_ their scoping but some other property of RFC1918 addresses or because the motive is a by-product of some other thing that results in RFC1918 addresses being used. Non-reason #1: "lots of addresses for free". -------------------------------------------- This is why people have moved to NAT, not why people have moved to RFC1918; the multiplication of addresses is a feature of NAT, and the use of RFC1918 in this situation is only a by-product of the use of NAT because it just happens that RFC1918 addresses are the best choice to put behind NAT (compared to hijacking a random prefix). It is generally believed that if we do see IPv6 NAT, it will not be because of address scarcity nor because ISPs would charge for a /48. Similar to the reason "lots of addresses for free" is not why people use RFC1918 (NAT is the reason), price, scarcity or unavailability of IPv6 PA addresses is likely not why people would want to use IPv6 scoped addresses. Non-reason #2: Cheap alternative to PI/portable addresses. ---------------------------------------------------------- I have _tons_ of customers that have no problem whatsoever obtaining enough PA addresses for their needs. They won't get extra ones, but they will get enough. Although it is true that for the home market obtaining more than one static address is some extra money that could be spent on something else, it is a non-existent issue for businesses; PA addresses are typically good enough for home use. For small businesses that get low grade connectivity such as DSL, $20/mo or $50/mo to get a /27 or a /26 is insignificant. For larger business that get T1 and above connectivity, enough PA IPv4 addresses are typically part of the deal with the ISP. So for businesses there are enough addresses, but these addresses are not PI. In this situation, people use RFC1918 addresses because they are portable, not because they are scoped. Here again the real reason is NAT. The main driving force behind this is cost of renumbering is so high that it offsets by far the annoyances of NAT; besides most enterprises use a combination of public and private addresses. Conservation of address space is here nothing more than an added bonus of NAT, because businesses might not request as many public addresses as they would have if they were not using NAT. Security/isolation/defense-in-depth. ------------------------------------ This is a non-reason for the home market and a valid one for the business/enterprise. For the home market: besides having more addresses (described above) what the home user likes is the security provided by RFC1918 addresses. Why do RFC1918 addresses provide security? Because they are not publicly routable, so using those mandates NAT, which does provide a basic firewall. In this case, scoping =3D=3D not-publicly-routable. So, the home market = uses RFC1918 not because of their scope but because of the property they have being not-publicly-routable, which means NAT, which means basic firewall. Security could be provided with a non-NAT firewall, but since NAT is already there because the home user wants multiple addresses and the cheapest available firewall is a NAT box anyway, NAT it is. For the business/enterprise is where scoping comes to a use. In this case, scoping !=3D not-publicly-routable. There are perfectly valid uses for publicly routable but nevertheless scoped addresses. In this environment, the use of RFC1918 addresses provides both a fail-safe against firewall/access-list SNAFUs, and a supplemental annoyance for hackers. None of these are miracles, but are part of defense-in-depth strategies and are palatable to the taste of the experienced enterprise operators that do not like to have all the eggs in the same basket. Also, network administrators like the comfort of this big 10/8 block. In short: why do people use scoped (RFC1918) addresses? ------------------------------------------------------- Home users: It has nothing to do with scoping and everything to do with NAT. The home user wants a) more addresses for free and b) a basic firewall, both of which are features of NAT not scoping. Usage of RFC1918 address is only a by-product of NAT. Business/enterprise: Part of it has nothing to do with scoping either. The #1 reason behind using RFC1918 in a business environment is independence from the ISP / easy renumbering. The other part of it is where scoping takes place: automatic/fail-safe access control (to be used in combination with manually configured security) and an extra annoyance for the hacker (needs to tunnel out on top of hacking). How does this apply to IPv6? Home users: The number of address is solved. What is left to provide is a basic firewall. This brings the question whether or not this basic firewall should be a feature of scoping or not. IMHO, these are two different topics, and home usage does not care about scoping. Business/enterprise: There is a need for scoping that is currently not fulfilled. This is the same concept as IPv4 RFC1918 address, except that the reason for non-global-routability should be the scoping mechanism opposed to ambiguity for IPv4.=20 Note that there also is a need for a PI equivalent that is not fulfilled either and the lack of it leads us directly to NATv6. > Clearly, NATs are popular in IPv4 for reasons other than lack > of address space, and simply condemning them as evil or even > arguing against them without understanding why people want > them isn't likely to result in a usable technical solution, > and probably won't persuade people to stop using them anyway. Indeed; I hope the analysis above helps to clarify this. Michel. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 17:46:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25690 for ; Fri, 17 Oct 2003 17:46:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAcQ5-0004tL-Cv for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 17:46:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HLk1jQ018797 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 17:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAcQ5-0004t6-7D for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 17:46:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25681 for ; Fri, 17 Oct 2003 17:45:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAcQ2-0001xu-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 17:45:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAcQ2-0001xr-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 17:45:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAcQ4-0004sa-3r; Fri, 17 Oct 2003 17:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAcPI-0004ru-46 for saad@optimus.ietf.org; Fri, 17 Oct 2003 17:45:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25660 for ; Fri, 17 Oct 2003 17:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAcPF-0001xc-00 for saad@ietf.org; Fri, 17 Oct 2003 17:45:09 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1AAcPF-0001xH-00 for saad@ietf.org; Fri, 17 Oct 2003 17:45:09 -0400 Content-class: urn:content-classes:message Subject: RE: [saad] About saad MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Oct 2003 14:44:39 -0700 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: [saad] About saad thread-index: AcOU4iJvovE9yDO4Th6lkf9M9BNlWAAFOrDQ From: "Michel Py" To: "Dave Crocker" , Content-Transfer-Encoding: quoted-printable Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dave, > Dave Crocker wrote: > 5. Concern: Not all machines have domain names. > Response: _No_ machines have whatever the alternative might be. I'm sorry, but every machine already has an alternative: use the IP address as the identifier. On the following point I'm only the devil's advocate, but here it is anyway: 6. Concern: the use of identifiers has been made necessary to compensate for shortcomings in the existing routing. Using DNS for routing purposes is both a layer violation and a magnet for circular reference issues. Whether true or not, good luck with this one. Michel. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 17:58:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25966 for ; Fri, 17 Oct 2003 17:58:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAcbh-0005QH-JP for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 17:58:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HLw1Ij020839 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 17:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAcbh-0005Q2-ET for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 17:58:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25963 for ; Fri, 17 Oct 2003 17:57:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAcbe-00021o-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 17:57:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAcbe-00021l-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 17:57:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAcbg-0005Pf-JO; Fri, 17 Oct 2003 17:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAcbY-0005PN-I2 for saad@optimus.ietf.org; Fri, 17 Oct 2003 17:57:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25960 for ; Fri, 17 Oct 2003 17:57:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAcbV-00021i-00 for saad@ietf.org; Fri, 17 Oct 2003 17:57:49 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1AAcbV-00021Z-00 for saad@ietf.org; Fri, 17 Oct 2003 17:57:49 -0400 Content-class: urn:content-classes:message Subject: RE: Why Scopes? (was: Re: [saad] About saad) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 17 Oct 2003 14:57:19 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Why Scopes? (was: Re: [saad] About saad) thread-index: AcOU3ej23AdhnuHwQ7OFDCJHEHVSwQAGldQg From: "Michel Py" To: "Melinda Shore" , "James Kempf" Cc: Content-Transfer-Encoding: quoted-printable Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Melinda, > Melinda Shore wrote: > I've talked to a very large number of people about this > (or rather why they use NATs, which is a slightly > different question), Indeed. > and the most common reasons are: > 1) don't want to buy more addresses > 2) simplification of network management/renumbering > 3) security/firewalling/unreachability Yes. I just posted a more detailed analysis along the same lines. > The reality is that some large number of users, including > some users who consider themselves relatively expert > (network administrators, etc.) don't want their hosts to > be reachable by default but they do want them to be able > to initiate connections themselves. I'm not sure there's > a good answer to this question, since the users' wishes > are incompatible with the IETF's working assumptions > about reachability. IMHO the answer to this is a firewall, not scoping. I just raised this question: should scoping provide firewall features or not? IMHO no because these are two different issues. Since we don't want NATv6, the requirement that hosts should be able to access the outside implies that their scope must be compatible with doing so. If these hosts must be protected from the outside when they are not initiating the connection, this function shall be provided by a firewall. Yes, firewalls are a PITA because they build hard state, and hard state is evil and distributed hard state is worse, but I don't think this is a topic for this list. Michel. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 18:05:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26386 for ; Fri, 17 Oct 2003 18:05:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAciU-0005eR-Up for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 18:05:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HM52Vm021724 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 18:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAciU-0005eH-Oo for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 18:05:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26331 for ; Fri, 17 Oct 2003 18:04:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAciR-00027K-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 18:05:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAciR-00027H-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 18:04:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAciT-0005df-7A; Fri, 17 Oct 2003 18:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAchZ-0005d5-1N for saad@optimus.ietf.org; Fri, 17 Oct 2003 18:04:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26228 for ; Fri, 17 Oct 2003 18:03:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAchW-00026w-00 for saad@ietf.org; Fri, 17 Oct 2003 18:04:02 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AAchV-00026X-00 for saad@ietf.org; Fri, 17 Oct 2003 18:04:01 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Oct 2003 15:13:40 -0700 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 h9HM3T1b005677; Fri, 17 Oct 2003 15:03:29 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-42.cisco.com [10.32.241.42]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANG77459; Fri, 17 Oct 2003 15:03:28 -0700 (PDT) Date: Fri, 17 Oct 2003 18:03:26 -0400 Subject: Re: Why Scopes? (was: Re: [saad] About saad) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "James Kempf" From: Melinda Shore In-Reply-To: <035501c394eb$c0f0fc70$396015ac@dclkempt40> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, October 17, 2003, at 04:17 PM, James Kempf wrote: > Suppose that, instead of a NAT, I could buy a box that had some number > of > globally routable IP addresses preconfigured into it (and I could get > more > by downloading them from the manufacturer via their Web page, maybe > paying a > small fee). This is not obviously going to work for v4 but I think is one piece of a reasonably attractive approach. Conflating reachability and routing has caused some real problems. But when we look at stuff like VoIP applications it becomes reasonably clear (at least to me, but obviously I'm biased) that that sort of access device is still going to introduce a heap of problems unless there's some sort of communication with the host about what the host *really* wants (instead of having the software on the access device make informed guesses). Receiving end-to-end (i.e. unmediated signaling) telephone calls is a good test case for whether or not these things can work. Melinda _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 17 19:04:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28967 for ; Fri, 17 Oct 2003 19:04:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAdda-0008Dw-5Z for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 19:04:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HN42ip031611 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 19:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAdda-0008Dm-1O for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 19:04:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28947 for ; Fri, 17 Oct 2003 19:03:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAddW-0002gq-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 19:03:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAddW-0002gn-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 19:03:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAddY-0008DO-TG; Fri, 17 Oct 2003 19:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAdd1-0008Cz-TY for saad@optimus.ietf.org; Fri, 17 Oct 2003 19:03:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28921 for ; Fri, 17 Oct 2003 19:03:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAdcy-0002gS-00 for saad@ietf.org; Fri, 17 Oct 2003 19:03:24 -0400 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by ietf-mx with esmtp (Exim 4.12) id 1AAdcy-0002gP-00 for saad@ietf.org; Fri, 17 Oct 2003 19:03:24 -0400 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h9HN3MWB013400; Fri, 17 Oct 2003 19:03:22 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h9HN3MaZ013399; Fri, 17 Oct 2003 19:03:22 -0400 Date: Fri, 17 Oct 2003 19:03:22 -0400 From: "J. Noel Chiappa" Message-Id: <200310172303.h9HN3MaZ013399@ginger.lcs.mit.edu> To: saad@ietf.org Subject: Re: [Fwd: [Saad] Some initiating thoughts...] Cc: jnc@ginger.lcs.mit.edu Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , > From: Leslie Daigle > I'm attaching a pre-draft that was prepared by IAB member Mark Handley I have a number of comments, but this one is important enough that I thought I'd send it along separately - it makes a point about IP addresses that I'm not sure people are keeping in mind. > 2. Background > IP addresses have served both as a means of uniquely identifying a > device interface that is attached to a network (an endpoint > identifier) This is broken terminology. The term "endpoint identifier" identifies it an *end-end* entity - i.e. something that is the termination of an end-end communication (see: http://users.exis.net/~jnc/tech/endpoints.txt for more). An "interface" is obviously not such an entity. (And in MIPv6 this is clear, because the end-end entity keeps its identity even when it has a new name for its interface.) IP addresses also do identify interfaces - but that's a separate function (see the next comment). > and as a means of identifying where a device is located > within the network (a forwarding or routing identifier). Actually, IP addresses have *three* roles (actually there are several more, but let me torque peoples' brains incrementally :-), and the last clause here ("where a device ... forwarding") conflates two of them. I have described a functionality which I call a "forwarding tag", which is "the bits in a packet header that a switch looks at to tell it how to forward the packet". Now, in IPvN, the "address" field(s) in the header are the forwarding tag, so people tend to think of the "address" namespace as having forwarding functionality. However, this is not necessarily so - e.g. in pure circuit ATM the forwarding tag is *not* an address, and addresses have no forwarding function. So in the Internet architecture, IP addresses serve at least these three functions: 1 - Identify an end-end entity 2 - Describe where its interface(s) is in the network (location) 3 - Serve as a forwarding tag for packets. Identifying an interface (previous comment) is a fourth, less important one (that's kind of mixed up with number 2 above). That this is a separate function is easy to see - IEEE 48-bit numbers identify interfaces, but don't tell you where in the Internet they are. Noel _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Sat Oct 18 23:31:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16889 for ; Sat, 18 Oct 2003 23:31:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB4Hc-0005Ri-9S for saad-archive@odin.ietf.org; Sat, 18 Oct 2003 23:31:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9J3V89O020931 for saad-archive@odin.ietf.org; Sat, 18 Oct 2003 23:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB4Hc-0005RW-2O for saad-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 23:31:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16877 for ; Sat, 18 Oct 2003 23:30:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB4Ha-0001ct-00 for saad-web-archive@ietf.org; Sat, 18 Oct 2003 23:31:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AB4HZ-0001cp-00 for saad-web-archive@ietf.org; Sat, 18 Oct 2003 23:31:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB4HW-0005Q8-3g; Sat, 18 Oct 2003 23:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AB4Gy-0005EH-7y for saad@optimus.ietf.org; Sat, 18 Oct 2003 23:30:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16869 for ; Sat, 18 Oct 2003 23:30:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AB4Gw-0001ch-00 for saad@ietf.org; Sat, 18 Oct 2003 23:30:26 -0400 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by ietf-mx with esmtp (Exim 4.12) id 1AB4Gv-0001cd-00 for saad@ietf.org; Sat, 18 Oct 2003 23:30:25 -0400 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h9J3ULWB027864; Sat, 18 Oct 2003 23:30:21 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h9J3UL2n027861; Sat, 18 Oct 2003 23:30:21 -0400 Date: Sat, 18 Oct 2003 23:30:21 -0400 From: "J. Noel Chiappa" Message-Id: <200310190330.h9J3UL2n027861@ginger.lcs.mit.edu> To: saad@ietf.org Subject: Re: Why Scopes? (was: Re: [saad] About saad) Cc: jnc@ginger.lcs.mit.edu Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , > From: "James Kempf" > Suppose that .. I could buy a box that had some number of globally > routable IP addresses preconfigured into it (and I could get more by > downloading them from the manufacturer via their Web page, maybe paying > a small fee). Hey, while you're picking that up from the store, would you mind buying me one of those 300 mile/gallon carburettors? Whether or not "address" as a generic term ought to include the concept of "identity" is open to debate (in practise, in IPv[46], it does), but I've not heard of anyone who says that "address" should not include the concept of "location". And clearly you don't know the location until the box is connected up to the network. So the concept of having "addresses preconfigued into it" is self-contradictory. It might have some sort of identifier wihtout any topological significance configured into it (just as your average box has a 48-bit IEEE address), but that's a whole different thing; it would not be an "address". Noel _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Mon Oct 20 03:21:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15726 for ; Mon, 20 Oct 2003 03:21:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABULn-0002R7-8e for saad-archive@odin.ietf.org; Mon, 20 Oct 2003 03:21:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K7LBrN009363 for saad-archive@odin.ietf.org; Mon, 20 Oct 2003 03:21:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABULm-0002QE-SZ for saad-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 03:21:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15709 for ; Mon, 20 Oct 2003 03:21:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABULk-00053V-00 for saad-web-archive@ietf.org; Mon, 20 Oct 2003 03:21:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABULk-00053R-00 for saad-web-archive@ietf.org; Mon, 20 Oct 2003 03:21:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABULe-0002OR-EU; Mon, 20 Oct 2003 03:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABULO-0002MX-41 for saad@optimus.ietf.org; Mon, 20 Oct 2003 03:20:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15682 for ; Mon, 20 Oct 2003 03:20:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABULL-00052q-00 for saad@ietf.org; Mon, 20 Oct 2003 03:20:43 -0400 Received: from maya20.nic.fr ([192.134.4.152]) by ietf-mx with esmtp (Exim 4.12) id 1ABULK-00052m-00 for saad@ietf.org; Mon, 20 Oct 2003 03:20:42 -0400 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h9K7BMQW1571667; Mon, 20 Oct 2003 09:11:28 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 4D053FF47; Mon, 20 Oct 2003 09:11:22 +0200 (CEST) Date: Mon, 20 Oct 2003 09:11:22 +0200 From: Stephane Bortzmeyer To: Michel Py Cc: Dave Crocker , saad@ietf.org Subject: Re: [saad] About saad Message-ID: <20031020071122.GB19985@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.21-3-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.4i Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , On Fri, Oct 17, 2003 at 02:44:39PM -0700, Michel Py wrote a message of 26 lines which said: > > Dave Crocker wrote: > > 5. Concern: Not all machines have domain names. > > Response: _No_ machines have whatever the alternative might be. ... > 6. Concern: the use of identifiers has been made necessary to compensate > for shortcomings in the existing routing. Using DNS for routing purposes > is both a layer violation and a magnet for circular reference issues. I cannot read in Dave Crocker's mind but I do not think he suggested to use DNS names for routing. Quite the contrary. Fred Baker explained it well: >So, as I understand it (and having read through the MAST paper), what you >are proposing is a Layer 3.5 or maybe Layer 4 Session-like Layer in which >the FQDNs are used for global node identification initially to set up a more >compact temporary node identifier. So, the DNS names will only be used at the setup stage, not in actual forwarding of packets. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Mon Oct 20 03:22:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15760 for ; Mon, 20 Oct 2003 03:22:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABUMd-0002ZD-Pv for saad-archive@odin.ietf.org; Mon, 20 Oct 2003 03:22:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K7M355009868 for saad-archive@odin.ietf.org; Mon, 20 Oct 2003 03:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABUMd-0002Z5-Jt for saad-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 03:22:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15749 for ; Mon, 20 Oct 2003 03:21:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABUMb-000546-00 for saad-web-archive@ietf.org; Mon, 20 Oct 2003 03:22:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABUMa-000543-00 for saad-web-archive@ietf.org; Mon, 20 Oct 2003 03:22:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABUMc-0002Xs-0S; Mon, 20 Oct 2003 03:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABULr-0002Rp-7W for saad@optimus.ietf.org; Mon, 20 Oct 2003 03:21:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15713 for ; Mon, 20 Oct 2003 03:21:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABULo-00053c-00 for saad@ietf.org; Mon, 20 Oct 2003 03:21:12 -0400 Received: from maya20.nic.fr ([192.134.4.152]) by ietf-mx with esmtp (Exim 4.12) id 1ABULn-00053Z-00 for saad@ietf.org; Mon, 20 Oct 2003 03:21:12 -0400 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h9K7BMQW1571667; Mon, 20 Oct 2003 09:11:28 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 4D053FF47; Mon, 20 Oct 2003 09:11:22 +0200 (CEST) Date: Mon, 20 Oct 2003 09:11:22 +0200 From: Stephane Bortzmeyer To: Michel Py Cc: Dave Crocker , saad@ietf.org Subject: Re: [saad] About saad Message-ID: <20031020071122.GB19985@nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.21-3-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.4i Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , On Fri, Oct 17, 2003 at 02:44:39PM -0700, Michel Py wrote a message of 26 lines which said: > > Dave Crocker wrote: > > 5. Concern: Not all machines have domain names. > > Response: _No_ machines have whatever the alternative might be. ... > 6. Concern: the use of identifiers has been made necessary to compensate > for shortcomings in the existing routing. Using DNS for routing purposes > is both a layer violation and a magnet for circular reference issues. I cannot read in Dave Crocker's mind but I do not think he suggested to use DNS names for routing. Quite the contrary. Fred Baker explained it well: >So, as I understand it (and having read through the MAST paper), what you >are proposing is a Layer 3.5 or maybe Layer 4 Session-like Layer in which >the FQDNs are used for global node identification initially to set up a more >compact temporary node identifier. So, the DNS names will only be used at the setup stage, not in actual forwarding of packets. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Mon Oct 20 15:04:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09595 for ; Mon, 20 Oct 2003 15:04:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfJz-0004uv-5L for saad-archive@odin.ietf.org; Mon, 20 Oct 2003 15:04:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KJ43Lm018900 for saad-archive@odin.ietf.org; Mon, 20 Oct 2003 15:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfJy-0004ul-VA for saad-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 15:04:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09426 for ; Mon, 20 Oct 2003 15:03:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABfJv-0003ga-00 for saad-web-archive@ietf.org; Mon, 20 Oct 2003 15:03:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABfJv-0003gV-00 for saad-web-archive@ietf.org; Mon, 20 Oct 2003 15:03:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfJx-0004sU-35; Mon, 20 Oct 2003 15:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfJ6-0004Xd-Mv for saad@optimus.ietf.org; Mon, 20 Oct 2003 15:03:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09219 for ; Mon, 20 Oct 2003 15:02:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABfJ3-0003eR-00 for saad@ietf.org; Mon, 20 Oct 2003 15:03:05 -0400 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1ABfJ2-0003cl-00 for saad@ietf.org; Mon, 20 Oct 2003 15:03:04 -0400 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9KJ0oNb047534; Mon, 20 Oct 2003 21:00:50 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9KJ0naA215434; Mon, 20 Oct 2003 21:00:49 +0200 Received: from zurich.ibm.com (sig-9-145-243-139.de.ibm.com [9.145.243.139]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id VAA59880; Mon, 20 Oct 2003 21:00:34 +0200 Message-ID: <3F9430AA.275235C5@zurich.ibm.com> Date: Mon, 20 Oct 2003 20:59:54 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Michel Py CC: James Kempf , saad@ietf.org Subject: Re: Why Scopes? (was: Re: [saad] About saad) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think Michel is basically correct here. And I think that draft-hain-templin-ipv6-limitedrange-02.txt should be read at this point. Brian Michel Py wrote: > > James, > > > James Kempf wrote: > > One of the things I'd like to see is a list of why people > > use scoped addresses (RFC 1918) in IPv4. > > I have some text about this, see below. > > Note: in the text below, the reason I state that some reasons are > actually non-reasons is because the motive behind the use of scoped > addresses (RFC1918) is _not_ their scoping but some other property of > RFC1918 addresses or because the motive is a by-product of some other > thing that results in RFC1918 addresses being used. > > Non-reason #1: "lots of addresses for free". > -------------------------------------------- > This is why people have moved to NAT, not why people have moved to > RFC1918; the multiplication of addresses is a feature of NAT, and the > use of RFC1918 in this situation is only a by-product of the use of NAT > because it just happens that RFC1918 addresses are the best choice to > put behind NAT (compared to hijacking a random prefix). > > It is generally believed that if we do see IPv6 NAT, it will not be > because of address scarcity nor because ISPs would charge for a /48. > Similar to the reason "lots of addresses for free" is not why people use > RFC1918 (NAT is the reason), price, scarcity or unavailability of IPv6 > PA addresses is likely not why people would want to use IPv6 scoped > addresses. > > Non-reason #2: Cheap alternative to PI/portable addresses. > ---------------------------------------------------------- > I have _tons_ of customers that have no problem whatsoever obtaining > enough PA addresses for their needs. They won't get extra ones, but they > will get enough. Although it is true that for the home market obtaining > more than one static address is some extra money that could be spent on > something else, it is a non-existent issue for businesses; PA addresses > are typically good enough for home use. > > For small businesses that get low grade connectivity such as DSL, $20/mo > or $50/mo to get a /27 or a /26 is insignificant. For larger business > that get T1 and above connectivity, enough PA IPv4 addresses are > typically part of the deal with the ISP. > > So for businesses there are enough addresses, but these addresses are > not PI. In this situation, people use RFC1918 addresses because they are > portable, not because they are scoped. Here again the real reason is > NAT. The main driving force behind this is cost of renumbering is so > high that it offsets by far the annoyances of NAT; besides most > enterprises use a combination of public and private addresses. > Conservation of address space is here nothing more than an added bonus > of NAT, because businesses might not request as many public addresses as > they would have if they were not using NAT. > > Security/isolation/defense-in-depth. > ------------------------------------ > This is a non-reason for the home market and a valid one for the > business/enterprise. > > For the home market: besides having more addresses (described above) > what the home user likes is the security provided by RFC1918 addresses. > Why do RFC1918 addresses provide security? Because they are not publicly > routable, so using those mandates NAT, which does provide a basic > firewall. > > In this case, scoping == not-publicly-routable. So, the home market uses > RFC1918 not because of their scope but because of the property they have > being not-publicly-routable, which means NAT, which means basic > firewall. Security could be provided with a non-NAT firewall, but since > NAT is already there because the home user wants multiple addresses and > the cheapest available firewall is a NAT box anyway, NAT it is. > > For the business/enterprise is where scoping comes to a use. In this > case, scoping != not-publicly-routable. There are perfectly valid uses > for publicly routable but nevertheless scoped addresses. In this > environment, the use of RFC1918 addresses provides both a fail-safe > against firewall/access-list SNAFUs, and a supplemental annoyance for > hackers. None of these are miracles, but are part of defense-in-depth > strategies and are palatable to the taste of the experienced enterprise > operators that do not like to have all the eggs in the same basket. > Also, network administrators like the comfort of this big 10/8 block. > > In short: why do people use scoped (RFC1918) addresses? > ------------------------------------------------------- > Home users: > It has nothing to do with scoping and everything to do with NAT. The > home user wants a) more addresses for free and b) a basic firewall, both > of which are features of NAT not scoping. Usage of RFC1918 address is > only a by-product of NAT. > > Business/enterprise: > Part of it has nothing to do with scoping either. The #1 reason behind > using RFC1918 in a business environment is independence from the ISP / > easy renumbering. > The other part of it is where scoping takes place: automatic/fail-safe > access control (to be used in combination with manually configured > security) and an extra annoyance for the hacker (needs to tunnel out on > top of hacking). > > How does this apply to IPv6? > > Home users: > The number of address is solved. What is left to provide is a basic > firewall. > This brings the question whether or not this basic firewall should be a > feature of scoping or not. IMHO, these are two different topics, and > home usage does not care about scoping. > > Business/enterprise: > There is a need for scoping that is currently not fulfilled. This is the > same concept as IPv4 RFC1918 address, except that the reason for > non-global-routability should be the scoping mechanism opposed to > ambiguity for IPv4. > > Note that there also is a need for a PI equivalent that is not fulfilled > either and the lack of it leads us directly to NATv6. > > > Clearly, NATs are popular in IPv4 for reasons other than lack > > of address space, and simply condemning them as evil or even > > arguing against them without understanding why people want > > them isn't likely to result in a usable technical solution, > > and probably won't persuade people to stop using them anyway. > > Indeed; I hope the analysis above helps to clarify this. > > Michel. > > _______________________________________________ > Saad mailing list > Saad@ietf.org > https://www1.ietf.org/mailman/listinfo/saad -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Mon Oct 20 16:40:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03739 for ; Mon, 20 Oct 2003 16:40:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgoy-0005eP-Dk for saad-archive@odin.ietf.org; Mon, 20 Oct 2003 16:40:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KKe8Zx021715 for saad-archive@odin.ietf.org; Mon, 20 Oct 2003 16:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgox-0005e8-EH for saad-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 16:40:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03721 for ; Mon, 20 Oct 2003 16:39:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABgov-00001D-00 for saad-web-archive@ietf.org; Mon, 20 Oct 2003 16:40:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABgov-00001A-00 for saad-web-archive@ietf.org; Mon, 20 Oct 2003 16:40:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgot-0005cf-HI; Mon, 20 Oct 2003 16:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABgoo-0005b8-OK for saad@optimus.ietf.org; Mon, 20 Oct 2003 16:40:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03710 for ; Mon, 20 Oct 2003 16:39:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABgom-00000r-00 for saad@ietf.org; Mon, 20 Oct 2003 16:39:56 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ABgol-00000T-00 for saad@ietf.org; Mon, 20 Oct 2003 16:39:55 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 20 Oct 2003 13:40:44 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9KKdLFQ016579; Mon, 20 Oct 2003 16:39:22 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-575.cisco.com [10.82.242.63]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADH79417; Mon, 20 Oct 2003 16:39:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20031020163757.01e7e938@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Oct 2003 16:39:15 -0400 To: Brian E Carpenter From: Ralph Droms Subject: Re: Why Scopes? (was: Re: [saad] About saad) Cc: Michel Py , James Kempf , saad@ietf.org In-Reply-To: <3F9430AA.275235C5@zurich.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , draft-hain-templin-ipv6-limitedrange-02.txt should be read *and commented on* - I don't think the draft is a finished product, yet, but it might serve to focus our discussion... - Ralph At 08:59 PM 10/20/2003 +0200, Brian E Carpenter wrote: >I think Michel is basically correct here. And I think that >draft-hain-templin-ipv6-limitedrange-02.txt should be >read at this point. > > Brian > >Michel Py wrote: > > > > James, > > > > > James Kempf wrote: > > > One of the things I'd like to see is a list of why people > > > use scoped addresses (RFC 1918) in IPv4. > > > > I have some text about this, see below. > > > > Note: in the text below, the reason I state that some reasons are > > actually non-reasons is because the motive behind the use of scoped > > addresses (RFC1918) is _not_ their scoping but some other property of > > RFC1918 addresses or because the motive is a by-product of some other > > thing that results in RFC1918 addresses being used. > > > > Non-reason #1: "lots of addresses for free". > > -------------------------------------------- > > This is why people have moved to NAT, not why people have moved to > > RFC1918; the multiplication of addresses is a feature of NAT, and the > > use of RFC1918 in this situation is only a by-product of the use of NAT > > because it just happens that RFC1918 addresses are the best choice to > > put behind NAT (compared to hijacking a random prefix). > > > > It is generally believed that if we do see IPv6 NAT, it will not be > > because of address scarcity nor because ISPs would charge for a /48. > > Similar to the reason "lots of addresses for free" is not why people use > > RFC1918 (NAT is the reason), price, scarcity or unavailability of IPv6 > > PA addresses is likely not why people would want to use IPv6 scoped > > addresses. > > > > Non-reason #2: Cheap alternative to PI/portable addresses. > > ---------------------------------------------------------- > > I have _tons_ of customers that have no problem whatsoever obtaining > > enough PA addresses for their needs. They won't get extra ones, but they > > will get enough. Although it is true that for the home market obtaining > > more than one static address is some extra money that could be spent on > > something else, it is a non-existent issue for businesses; PA addresses > > are typically good enough for home use. > > > > For small businesses that get low grade connectivity such as DSL, $20/mo > > or $50/mo to get a /27 or a /26 is insignificant. For larger business > > that get T1 and above connectivity, enough PA IPv4 addresses are > > typically part of the deal with the ISP. > > > > So for businesses there are enough addresses, but these addresses are > > not PI. In this situation, people use RFC1918 addresses because they are > > portable, not because they are scoped. Here again the real reason is > > NAT. The main driving force behind this is cost of renumbering is so > > high that it offsets by far the annoyances of NAT; besides most > > enterprises use a combination of public and private addresses. > > Conservation of address space is here nothing more than an added bonus > > of NAT, because businesses might not request as many public addresses as > > they would have if they were not using NAT. > > > > Security/isolation/defense-in-depth. > > ------------------------------------ > > This is a non-reason for the home market and a valid one for the > > business/enterprise. > > > > For the home market: besides having more addresses (described above) > > what the home user likes is the security provided by RFC1918 addresses. > > Why do RFC1918 addresses provide security? Because they are not publicly > > routable, so using those mandates NAT, which does provide a basic > > firewall. > > > > In this case, scoping == not-publicly-routable. So, the home market uses > > RFC1918 not because of their scope but because of the property they have > > being not-publicly-routable, which means NAT, which means basic > > firewall. Security could be provided with a non-NAT firewall, but since > > NAT is already there because the home user wants multiple addresses and > > the cheapest available firewall is a NAT box anyway, NAT it is. > > > > For the business/enterprise is where scoping comes to a use. In this > > case, scoping != not-publicly-routable. There are perfectly valid uses > > for publicly routable but nevertheless scoped addresses. In this > > environment, the use of RFC1918 addresses provides both a fail-safe > > against firewall/access-list SNAFUs, and a supplemental annoyance for > > hackers. None of these are miracles, but are part of defense-in-depth > > strategies and are palatable to the taste of the experienced enterprise > > operators that do not like to have all the eggs in the same basket. > > Also, network administrators like the comfort of this big 10/8 block. > > > > In short: why do people use scoped (RFC1918) addresses? > > ------------------------------------------------------- > > Home users: > > It has nothing to do with scoping and everything to do with NAT. The > > home user wants a) more addresses for free and b) a basic firewall, both > > of which are features of NAT not scoping. Usage of RFC1918 address is > > only a by-product of NAT. > > > > Business/enterprise: > > Part of it has nothing to do with scoping either. The #1 reason behind > > using RFC1918 in a business environment is independence from the ISP / > > easy renumbering. > > The other part of it is where scoping takes place: automatic/fail-safe > > access control (to be used in combination with manually configured > > security) and an extra annoyance for the hacker (needs to tunnel out on > > top of hacking). > > > > How does this apply to IPv6? > > > > Home users: > > The number of address is solved. What is left to provide is a basic > > firewall. > > This brings the question whether or not this basic firewall should be a > > feature of scoping or not. IMHO, these are two different topics, and > > home usage does not care about scoping. > > > > Business/enterprise: > > There is a need for scoping that is currently not fulfilled. This is the > > same concept as IPv4 RFC1918 address, except that the reason for > > non-global-routability should be the scoping mechanism opposed to > > ambiguity for IPv4. > > > > Note that there also is a need for a PI equivalent that is not fulfilled > > either and the lack of it leads us directly to NATv6. > > > > > Clearly, NATs are popular in IPv4 for reasons other than lack > > > of address space, and simply condemning them as evil or even > > > arguing against them without understanding why people want > > > them isn't likely to result in a usable technical solution, > > > and probably won't persuade people to stop using them anyway. > > > > Indeed; I hope the analysis above helps to clarify this. > > > > Michel. > > > > _______________________________________________ > > Saad mailing list > > Saad@ietf.org > > https://www1.ietf.org/mailman/listinfo/saad > >-- >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Brian E Carpenter >Distinguished Engineer, Internet Standards & Technology, IBM > >NEW ADDRESS PLEASE UPDATE ADDRESS BOOK > >_______________________________________________ >Saad mailing list >Saad@ietf.org >https://www1.ietf.org/mailman/listinfo/saad _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Tue Oct 21 09:11:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16454 for ; Tue, 21 Oct 2003 09:11:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABwHz-0005h9-Mn for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 09:11:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LDB7Rb021892 for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 09:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABwHz-0005h1-Di for saad-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 09:11:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16404 for ; Tue, 21 Oct 2003 09:10:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABwHx-0003Gf-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 09:11:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABwHx-0003Gb-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 09:11:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABwHs-0005fG-Uj; Tue, 21 Oct 2003 09:11:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABwHA-0005TZ-GK for saad@optimus.ietf.org; Tue, 21 Oct 2003 09:10:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16364 for ; Tue, 21 Oct 2003 09:10:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABwH8-0003GG-00 for saad@ietf.org; Tue, 21 Oct 2003 09:10:14 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1ABwH7-0003GC-00 for saad@ietf.org; Tue, 21 Oct 2003 09:10:13 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9LD0u5u002057; Tue, 21 Oct 2003 07:00:57 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9LD0uS16805; Tue, 21 Oct 2003 15:00:56 +0200 (MEST) Date: Tue, 21 Oct 2003 14:54:50 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Why Scopes? (was: Re: [saad] About saad) To: Michel Py Cc: James Kempf , saad@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , > For the business/enterprise is where scoping comes to a use. In this > case, scoping != not-publicly-routable. There are perfectly valid uses > for publicly routable but nevertheless scoped addresses. In this > environment, the use of RFC1918 addresses provides both a fail-safe > against firewall/access-list SNAFUs, and a supplemental annoyance for > hackers. None of these are miracles, but are part of defense-in-depth > strategies and are palatable to the taste of the experienced enterprise > operators that do not like to have all the eggs in the same basket. One could argue that the defense in depth against misconfiguring firewalls could be handled with a different UI-abstraction in an existing firewall. For instance, being able to declare that a set of IP address ranges or interfaces on the firewall are "outbound only" (what NAT gives you) and no other rule in the firewall config can override this. This separation of the "outbound only" set of nodes seems to be to provide the same defense-in-depth as NAT when used for the above purpose. Whether it would provide the same perception of confort is a different matter. Erik _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Tue Oct 21 09:57:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17682 for ; Tue, 21 Oct 2003 09:57:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABx0V-0001lJ-2Y for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 09:57:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LDv7WN006767 for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 09:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABx0U-0001l4-Um for saad-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 09:57:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17676 for ; Tue, 21 Oct 2003 09:56:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABx0T-0003ex-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 09:57:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABx0S-0003eu-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 09:57:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABx0P-0001hi-4a; Tue, 21 Oct 2003 09:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABx0K-0001fT-Bi for saad@optimus.ietf.org; Tue, 21 Oct 2003 09:56:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17669 for ; Tue, 21 Oct 2003 09:56:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABx0I-0003em-00 for saad@ietf.org; Tue, 21 Oct 2003 09:56:54 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1ABx0H-0003ei-00 for saad@ietf.org; Tue, 21 Oct 2003 09:56:53 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9LDuGUP013311; Tue, 21 Oct 2003 06:56:16 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9LDuFS25192; Tue, 21 Oct 2003 15:56:15 +0200 (MEST) Date: Tue, 21 Oct 2003 15:50:10 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [saad] About saad To: Dave Crocker Cc: saad@ietf.org In-Reply-To: "Your message with ID" <7325372774.20031017151023@brandenburg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , > 1. Concern: Domain names are overloaded; they get used for too many things > already. > > Response: So? What problems are caused by this and how does it prevent > them from being used as EIDs? How will using them as EIDs -- and we can > skip over the argument that they already _are_ EIDs, for the moment -- > break any of the other uses for domain names? It isn't the domain names per-see that are the issues but any implied semantics of having multiple AAAA records for the same RRset. For instance, the AAAA RRset for www.example.com might return 5 addresses. Does that mean that that those are different locators for the same stack/entity, 5 separate stacks, or some combination? Additional information in the DNS, or some negotation protocol between the endpoints can presumably be used to resolve this question. > 2. Concern: DNS administration is difficult > > Response: But it exists and it works. Persistent names need > administration. Depending on your definition of "administration" this might not be the case for statistically unique and cryptographically verifiable identifiers (also known as CBIDs or hashes of public keys). Any node could generate a 128 bit ID by generating a public/private key pair and doing the SHA1 hash of the public key; doesn't require any name space administration. > Why is something new going to be easier? What can't the > mechanisms that make it easier be applied to the DNS? Why won't adding > them to DNS be substantially easier than creating a new, global > administrative mechanism? > > > 3. Concern: Domain names are inefficient to use > > Response: If they must be used in every packet, that is true. If they > must be used only occasionally, such as at the start of an association > or at major state change events, then the bit-inefficiency of domain > names is irrelevant to the overall efficiency of the service that is > using it. There is an aspect called "the DNS is inefficient to use" which doesn't seem to be part of your #3. Using domain names while preventing the redirection attacks that are implicit in any attempt to make ULP communication survive locator changes implies that some more DNS lookups will be performed. Understanding the performance of using the DNS for such a lookup (with and without DNSsec) with schemes based on CBIDs is definitely a worth-while effort. > 4. Concern: Domain names are administered by a different entity than the > folks who administer IP operations > > Response: Is this a turf war? Is there some reason to believe that > having the new namespace administered by another group is somehow going > to make the new names trivial to administer, compared with domain names? > The mere fact that the new namespace _might_ be administered by a > different group does not guarantee that the reality of administering it > is any better than the reality of administering domain names. There is a level 9 meta-issue related to this. If a new rooted, hierarchical name space is needed somebody needs to be appointed to control and operate the root of that namespace. Resolving the food fight of who should be in control might take some time. FWIW neither using the DNS as in MAST or using flat CBIDs have this problem. > 5. Concern: Not all machines have domain names. > > Response: _No_ machines have whatever the alternative might be. Question is how hard it would be to add them. I could get a CBID for my machines at home in a few seconds (the time it takes to generate the key pair). Convincing the ISP to assign me a domain name would take a lot longer. Thus if both ends of the communication need a domain name this might be an impediment for deployment. Erik _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Tue Oct 21 11:08:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22482 for ; Tue, 21 Oct 2003 11:08:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABy7D-0004Gj-F0 for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 11:08:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LF87vY016394 for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 11:08:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABy7C-0004GD-Rz for saad-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 11:08:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22470 for ; Tue, 21 Oct 2003 11:07:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABy7A-0004lP-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 11:08:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABy79-0004lM-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 11:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABy77-0004D9-Ck; Tue, 21 Oct 2003 11:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABy6I-0003pB-7i for saad@optimus.ietf.org; Tue, 21 Oct 2003 11:07:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22427 for ; Tue, 21 Oct 2003 11:06:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABy6F-0004kZ-00 for saad@ietf.org; Tue, 21 Oct 2003 11:07:07 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1ABy6E-0004k7-00 for saad@ietf.org; Tue, 21 Oct 2003 11:07:07 -0400 Subject: RE: Why Scopes? (was: Re: [saad] About saad) Date: Tue, 21 Oct 2003 08:06:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Why Scopes? (was: Re: [saad] About saad) Thread-Index: AcOX1VwcowBKRoYJQAm7v5pHBsBafwACxkJA From: "Michel Py" To: "Erik Nordmark" Cc: "James Kempf" , Content-Transfer-Encoding: quoted-printable Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Erik, > Erik Nordmark > For instance, being able to declare that a set of IP address > ranges or interfaces on the firewall are "outbound only" > (what NAT gives you) and no other rule in the firewall > config can override this. That's what I have a problem with. There are always ways to override things; doing so is a significant part of SNAFUs. This is why scoping comes to mind: no matter how bad one misconfigures the firewall, there is another line of defense. Keep in mind that at times firewalls that do not NAT could be replaced by a cross-over cable (for short periods of time, in case of upgrades for example). I know, nobody is supposed to do that; nevertheless it is being done every day. When there are two physical firewalls that replicate hard state between them, you can take one off-line, upgrade it and then do the same with the other one, but this is not always the case. > This separation of the "outbound only" set of nodes seems to > be to provide the same defense-in-depth as NAT when used for > the above purpose. Perhaps, but this is not typically what enterprises are interested in when they want scoping. The purpose of scoping is to make no communication possible, not egress-only (because egress-only could be used to create a tunnel). Michel. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Tue Oct 21 11:46:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24057 for ; Tue, 21 Oct 2003 11:46:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByhw-0006rN-EM for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 11:46:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LFk4am026363 for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 11:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByhw-0006r8-8m for saad-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 11:46:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24050 for ; Tue, 21 Oct 2003 11:45:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByhv-0005Eg-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 11:46:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AByhu-0005Ed-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 11:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByht-0006oW-B7; Tue, 21 Oct 2003 11:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AByh9-0006dX-1v for saad@optimus.ietf.org; Tue, 21 Oct 2003 11:45:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24002 for ; Tue, 21 Oct 2003 11:45:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AByh7-0005Dj-00 for saad@ietf.org; Tue, 21 Oct 2003 11:45:13 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1AByh6-0005Df-00 for saad@ietf.org; Tue, 21 Oct 2003 11:45:12 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9LFZuPh019061; Tue, 21 Oct 2003 09:35:57 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9LFZtS14516; Tue, 21 Oct 2003 17:35:55 +0200 (MEST) Date: Tue, 21 Oct 2003 17:29:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Why Scopes? (was: Re: [saad] About saad) To: Michel Py Cc: Erik Nordmark , James Kempf , saad@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , > Perhaps, but this is not typically what enterprises are interested in > when they want scoping. The purpose of scoping is to make no > communication possible, not egress-only (because egress-only could be > used to create a tunnel). Having a conceptual model with 3 top-level classes defined in the firewall 1. no communication through the firewall 2. outbound only 3. open is simple enough to prevent unintended side-effects of other filters. Then you can have the ability to further *restrict* the classes with more detailed rules (e.g. to restrict certain IP addresses in 2 to not allow outbound for certain protocols and ports) but no ability to have rules which are less restrictive that the basis for the class. This is not rocket science - just sound conceptual models for a UI. > Keep in mind that at times firewalls that do not NAT could be replaced > by a cross-over cable (for short periods of time, in case of upgrades > for example). I know, nobody is supposed to do that; nevertheless it is And people rewire light switches at home without turning off the power too. In many cases that works if you are careful, even though it isn't recommended practise! Point being that neither household electrical appliances nor the nationwide electrical grid had any additional requirements placed upon it to make it safer rewiring with the power on. I don't think it makes sense placing additional requirements on the Internet applications or the IP infrastructure to make firewall temporary replacement with a cross-over cable any safer either. Erik _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Tue Oct 21 12:09:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24916 for ; Tue, 21 Oct 2003 12:09:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABz4C-0004Ir-9c for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 12:09:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LG941M016535 for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 12:09:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABz4C-0004Ic-3Q for saad-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 12:09:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24870 for ; Tue, 21 Oct 2003 12:08:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABz4A-0005Vi-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 12:09:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABz4A-0005Vf-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 12:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABz48-0004HN-HX; Tue, 21 Oct 2003 12:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABz3F-00044M-2I for saad@optimus.ietf.org; Tue, 21 Oct 2003 12:08:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24824 for ; Tue, 21 Oct 2003 12:07:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABz3D-0005UN-00 for saad@ietf.org; Tue, 21 Oct 2003 12:08:03 -0400 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1ABz3D-0005SY-00 for saad@ietf.org; Tue, 21 Oct 2003 12:08:03 -0400 Subject: RE: Why Scopes? (was: Re: [saad] About saad) Date: Tue, 21 Oct 2003 09:07:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Why Scopes? (was: Re: [saad] About saad) Thread-Index: AcOX6w2UcomcC/w0QdWJMQjE6BsuSwAAiDyA From: "Michel Py" To: "Erik Nordmark" Cc: "James Kempf" , Content-Transfer-Encoding: quoted-printable Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Erik Nordmark > Having a conceptual model with 3 top-level classes defined in the > firewall > 1. no communication through the firewall > 2. outbound only > 3. open > is simple enough to prevent unintended side-effects of other > filters. Even if we could force firewall vendors to do this (which we can't) it's not flexible enough. A significant part of access control is performed by regular routers and there we can't pre-define which interface belongs to which class, it's all configuration that unfortunately can be SNAFUed. Michel. _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Tue Oct 21 13:35:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27428 for ; Tue, 21 Oct 2003 13:35:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0PS-000354-Jq for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 13:35:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LHZ6Af011838 for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 13:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0PS-00034n-8f for saad-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 13:35:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27398 for ; Tue, 21 Oct 2003 13:34:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0PQ-0006Q2-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 13:35:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC0PP-0006Pz-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 13:35:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0PN-000311-Jz; Tue, 21 Oct 2003 13:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0Og-0002nZ-Et for saad@optimus.ietf.org; Tue, 21 Oct 2003 13:34:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27360 for ; Tue, 21 Oct 2003 13:34:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0Oe-0006Ot-00 for saad@ietf.org; Tue, 21 Oct 2003 13:34:16 -0400 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AC0Od-0006OE-00 for saad@ietf.org; Tue, 21 Oct 2003 13:34:15 -0400 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9LHXhNb111110 for ; Tue, 21 Oct 2003 19:33:43 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9LHXhZu159582 for ; Tue, 21 Oct 2003 19:33:43 +0200 Received: from zurich.ibm.com (sig-9-145-224-49.de.ibm.com [9.145.224.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA61282 for ; Tue, 21 Oct 2003 19:33:42 +0200 Message-ID: <3F956DD8.89B5E845@zurich.ibm.com> Date: Tue, 21 Oct 2003 19:33:12 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: saad@ietf.org Subject: Re: [saad] About saad References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > > 1. Concern: Domain names are overloaded; they get used for too many things > > already. > > > > Response: So? What problems are caused by this and how does it prevent > > them from being used as EIDs? How will using them as EIDs -- and we can > > skip over the argument that they already _are_ EIDs, for the moment -- > > break any of the other uses for domain names? > > It isn't the domain names per-see that are the issues but any implied > semantics of having multiple AAAA records for the same RRset. > > For instance, the AAAA RRset for www.example.com might return 5 addresses. And might return different addresses on consecutive calls, if round robin load sharing is in use. And the addresses returned might well be virtual, i.e. dynamically assigned to a particular server at packet-delivery time. So what such an FQDN actually refers to (except itself) is fuzzy indeed. Brian > Does that mean that that those are different locators for the same > stack/entity, 5 separate stacks, or some combination? > Additional information in the DNS, or some negotation protocol between the > endpoints can presumably be used to resolve this question. > > > 2. Concern: DNS administration is difficult > > > > Response: But it exists and it works. Persistent names need > > administration. > > Depending on your definition of "administration" this might not be the > case for statistically unique and cryptographically verifiable identifiers > (also known as CBIDs or hashes of public keys). > Any node could generate a 128 bit ID by generating a public/private key > pair and doing the SHA1 hash of the public key; doesn't require any > name space administration. > > > Why is something new going to be easier? What can't the > > mechanisms that make it easier be applied to the DNS? Why won't adding > > them to DNS be substantially easier than creating a new, global > > administrative mechanism? > > > > > > 3. Concern: Domain names are inefficient to use > > > > Response: If they must be used in every packet, that is true. If they > > must be used only occasionally, such as at the start of an association > > or at major state change events, then the bit-inefficiency of domain > > names is irrelevant to the overall efficiency of the service that is > > using it. > > There is an aspect called "the DNS is inefficient to use" which > doesn't seem to be part of your #3. > Using domain names while preventing the redirection attacks that are > implicit in any attempt to make ULP communication survive locator changes > implies that some more DNS lookups will be performed. > Understanding the performance of using the DNS for such > a lookup (with and without DNSsec) with schemes based on CBIDs is > definitely a worth-while effort. > > > 4. Concern: Domain names are administered by a different entity than the > > folks who administer IP operations > > > > Response: Is this a turf war? Is there some reason to believe that > > having the new namespace administered by another group is somehow going > > to make the new names trivial to administer, compared with domain names? > > The mere fact that the new namespace _might_ be administered by a > > different group does not guarantee that the reality of administering it > > is any better than the reality of administering domain names. > > There is a level 9 meta-issue related to this. > If a new rooted, hierarchical name space is needed somebody needs > to be appointed to control and operate the root of that namespace. > Resolving the food fight of who should be in control might take some > time. > > FWIW neither using the DNS as in MAST or using flat CBIDs have this > problem. > > > 5. Concern: Not all machines have domain names. > > > > Response: _No_ machines have whatever the alternative might be. > > Question is how hard it would be to add them. > > I could get a CBID for my machines at home in a few seconds (the time > it takes to generate the key pair). Convincing the ISP to assign me a domain > name would take a lot longer. > > Thus if both ends of the communication need a domain name this might be an > impediment for deployment. > > Erik _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Wed Oct 22 09:28:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07952 for ; Wed, 22 Oct 2003 09:28:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJ1x-0007mB-Qg for saad-archive@odin.ietf.org; Wed, 22 Oct 2003 09:28:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MDS5LK029885 for saad-archive@odin.ietf.org; Wed, 22 Oct 2003 09:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJ1x-0007lw-MG for saad-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 09:28:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07910 for ; Wed, 22 Oct 2003 09:27:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJ1w-000554-00 for saad-web-archive@ietf.org; Wed, 22 Oct 2003 09:28:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACJ1v-000550-00 for saad-web-archive@ietf.org; Wed, 22 Oct 2003 09:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJ1s-0007jo-Qk; Wed, 22 Oct 2003 09:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJ1j-0007iY-VO for saad@optimus.ietf.org; Wed, 22 Oct 2003 09:27:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07900 for ; Wed, 22 Oct 2003 09:27:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJ1i-00054u-00 for saad@ietf.org; Wed, 22 Oct 2003 09:27:50 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1ACJ1g-00054j-00 for saad@ietf.org; Wed, 22 Oct 2003 09:27:49 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9MDRDUP023605; Wed, 22 Oct 2003 06:27:14 -0700 (PDT) Received: from lillen (vpn-129-156-97-186.EMEA.Sun.COM [129.156.97.186]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9MDRAS11726; Wed, 22 Oct 2003 15:27:10 +0200 (MEST) Date: Wed, 22 Oct 2003 15:21:02 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [Fwd: [Saad] Some initiating thoughts...] To: Leslie Daigle Cc: saad@ietf.org, M.Handley@cs.ucl.ac.uk In-Reply-To: "Your message with ID" <3F8F5044.5050004@thinkingcat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , > > Internet Engineering Task Force IAB > INTERNET-DRAFT Mark Handley (ed) > draft-iab-addressing-2003815.txt 15 August 2003 > $Revision: 1.1 $ Expires: NOT PUBLISHED > > > Architectural Issues with IP Addressing Some comments on this draft. > The Internet is a complex and heterogeneous network, and becoming more > heterogeneous as time goes on. Different people and different > subsystems in the network have different requirements on the addressing > architecture; this is a classic example of a "tussle space" [3] between > conflicting demands. A very interesting and important question in my mind is whether the underlying requirements are on the addressing architecture, or whether this is merely one way to express some functional requirements. For instance, one stated requirement can be expressed as: - the need to do more fool-proof configuration of IP address-based filtering in firewalls (and provide defense in depth for IP address-based filtering) or it could be expressed as - need to encode security domains in the syntax of the IP addresses (in order make IP-address based filtering easier) My gut feel is that the underlying issue is that firewall/filtering configuration is complex and error prone and that there is a question on the table how we can make this easier. For instance, are there architectural modifications that can improve the situation? In section 3.2: > We note that the > use of private addresses with a NAT instead of a correctly configured > firewall has significant shortcomings from a security point of view, but > it does have the advantage of being very simple to set up. This seem to implicitly imply that a non-NATting firewall is (significantly) more difficult than setting up a NATting firewall. My observations (from SOHO DSL routers at home) is that the configuration task (i.e. not the administrative task of requesting a /29 IPv4 prefix) with IPv4 is just the ISP configuring the prefix into the router. With protocols like DHCPv6 prefix delegation that manual task goes away. The set of SOHO routers I've been exposed have by default a "outbound only" firewall; whether or not NAT is used. I don't know how common this is, and whether it applies in the enterprise space. Thus the above statement in the draft my reflect common perception more than reality; while perception is important we should try to separate that out from reality. Next paragraph: > Irrespective of the technology used to accomplish it, the specific > security requirement that enterprises have on addressing is that it > should be easy to set up a well-known and well-understood filter at > security boundaries that reduces the exposure profile from individual > configuration errors. Since the whole draft is about IP address architecture there is an implicit statement that the above security requirements and filters at the boundary are only about IP addresses. Of course that is false since the wast majority of such filtering also look at protocols, TCP/UDP port numbers, and higher-level state. I think the draft failing to make this point can lead us to incorrectly believethat having multiple of addressing scopes to match multiple of "security domains" is a pannacea for filtering at the boundaries. Section 3.3: > A key requirement on addressing is that much of this consumer equipment > (printers, light switches, etc) needs to be able to communicate locally > without being directly exposed to the global Internet. At the same time > the same network infrastructure will be used by devices that do need > global Internet access. I think this view of consumer equipment not benefitting from globally communication is very short-sighted. For instance, today I see benefits of being able to send video directly from a camcorder at home to the vcr/display at my parents house, to be able to turn up the thermostat in a winter vacation house before driving over there, and to be able to print on a printer at home when I'm on the road. The key is how to secure this. I think the above statement reflects this short-sighted resignation that we as a communication don't know how to make usable security work for small devices used by consumers. But there is at least research on this topic (using various imprinting techniques etc); for certain classes of interaction I think usable security for small devices is not very far away. Section 3.4: > If each endpoint has multiple addresses, the transport, middleware or > application layer has the complex problem of choosing the correct pair > of addresses to enable communication. There are two conflicting goals > here: > > o To guarantee reachability between the endpoints. > > o To ensure that the traffic stays within the tightest possible > administrative and security boundaries. I don't seem to be able to understand the second bullet and its origin. Perhaps it is just the "tightest possible" that is causing problems for me; I think applications/middleware/etc might have some security requirements themselves (whether expressable and expressed directly by those entities, or expressed separate e.g. as part of a corporate IT security policy), but I don't see how "tightest possible" is security requirement that fulfills a particular (business) objective. Let me try to illustrate with an example: A policy that makes some sense is "when in a company office do NFS in the clear; when not in an office or using 802.11 in an office apply IPsec for NFS". But a policy that says "make sure (cleartext) NFS traffic stays within the tightest security boundary" means that when I'm in the IETF terminal room my corporate NFS traffic travels unprotected; the tightest possible security boundary encompasses the terminal room network and the Internet path back to the corporation. Can somebody try to enlighten me on what the second bullet is trying to say? Erik _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Wed Oct 22 09:49:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08590 for ; Wed, 22 Oct 2003 09:49:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJMG-0004Dp-Rx for saad-archive@odin.ietf.org; Wed, 22 Oct 2003 09:49:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MDn4AU016223 for saad-archive@odin.ietf.org; Wed, 22 Oct 2003 09:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJMG-0004Da-M1 for saad-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 09:49:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08572 for ; Wed, 22 Oct 2003 09:48:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJME-0005L5-00 for saad-web-archive@ietf.org; Wed, 22 Oct 2003 09:49:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACJME-0005L2-00 for saad-web-archive@ietf.org; Wed, 22 Oct 2003 09:49:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJMD-0004CG-Eo; Wed, 22 Oct 2003 09:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJLg-0003zc-UZ for saad@optimus.ietf.org; Wed, 22 Oct 2003 09:48:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08512 for ; Wed, 22 Oct 2003 09:48:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJLe-0005K7-00 for saad@ietf.org; Wed, 22 Oct 2003 09:48:27 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ACJLe-0005JG-00 for saad@ietf.org; Wed, 22 Oct 2003 09:48:26 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 22 Oct 2003 06:48:10 -0700 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 h9MDlCjP017578; Wed, 22 Oct 2003 06:47:13 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-42.cisco.com [10.32.241.42]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANK08053; Wed, 22 Oct 2003 06:47:09 -0700 (PDT) Date: Wed, 22 Oct 2003 09:47:08 -0400 Subject: Re: [Fwd: [Saad] Some initiating thoughts...] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Leslie Daigle , saad@ietf.org, M.Handley@cs.ucl.ac.uk To: Erik Nordmark From: Melinda Shore In-Reply-To: Message-Id: <3A7F56BE-0496-11D8-A84F-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, October 22, 2003, at 09:21 AM, Erik Nordmark wrote: > My gut feel is that the underlying issue is that firewall/filtering > configuration is complex and error prone and that there is a question > on the table how we can make this easier. For instance, are there > architectural > modifications that can improve the situation? There are a lot of different questions there, actually, and I think they tend to have different answers. Firewall configuration, for example, is not the same question as firewall policy expression. In practice it turns out that it's an enormous problem that the policy language we're currently using to express firewall (or border access) rules is incredibly crude. Port numbers and transport protocols are used to describe applications, and addresses are used to describe policy domains. There are obvious limitations to what can actually be achieved using 5-tuples as policy tags, and consequently firewall vendors have implemented stateful inspection of data streams to make sure, for example, that the stuff passing through on port 80 is actually html. And because they need to inspect data to make sure that firewall policy isn't being contraverted, they disallow encrypted traffic, which in turn means that security practice is being substantially undermined. So there's a considerable ripple effect created when a policy function is overloaded on addresses. Presumably this could be mitigated through the use of more refined policy language and a somewhat different enforcement architecture, but that would introduce different architectural problems as yet pretty much undiscussed. Melinda _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Wed Oct 22 18:02:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29897 for ; Wed, 22 Oct 2003 18:02:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACR3Q-0002oX-7B for saad-archive@odin.ietf.org; Wed, 22 Oct 2003 18:02:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MM28t8010813 for saad-archive@odin.ietf.org; Wed, 22 Oct 2003 18:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACR3Q-0002nn-1n for saad-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 18:02:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29881 for ; Wed, 22 Oct 2003 18:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACR3N-0003EB-00 for saad-web-archive@ietf.org; Wed, 22 Oct 2003 18:02:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACR3M-0003E8-00 for saad-web-archive@ietf.org; Wed, 22 Oct 2003 18:02:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACR3I-0002mJ-Jq; Wed, 22 Oct 2003 18:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACR2M-0002g7-8z for saad@optimus.ietf.org; Wed, 22 Oct 2003 18:01:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29849 for ; Wed, 22 Oct 2003 18:00:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACR2J-0003Dc-00 for saad@ietf.org; Wed, 22 Oct 2003 18:00:59 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1ACR2I-0003DV-00 for saad@ietf.org; Wed, 22 Oct 2003 18:00:58 -0400 Message-ID: <017a01c398e7$ff74d520$2a6015ac@dclkempt40> From: "James Kempf" To: "Erik Nordmark" , "Leslie Daigle" Cc: , References: Subject: Re: [Fwd: [Saad] Some initiating thoughts...] Date: Wed, 22 Oct 2003 15:01:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, Just one comment on your email: > > A key requirement on addressing is that much of this consumer equipment > > (printers, light switches, etc) needs to be able to communicate locally > > without being directly exposed to the global Internet. At the same time > > the same network infrastructure will be used by devices that do need > > global Internet access. > > I think this view of consumer equipment not benefitting from globally > communication is very short-sighted. > For instance, today I see benefits of being able to send video directly > from a camcorder at home to the vcr/display at my parents house, to be > able to turn up the thermostat in a winter vacation house before driving > over there, and to be able to print on a printer at home when I'm on the road. > The key is how to secure this. > > I think the above statement reflects this short-sighted resignation that we > as a communication don't know how to make usable security work for small > devices used by consumers. But there is at least research on this > topic (using various imprinting techniques etc); for certain classes > of interaction I think usable security for small devices is not very far away. > I agree with your point that security is the issue, and I agree that research coming along may lead to the potential for better, simpler security between consumer devices. But much of the appeal for firewalls (and some people extend this to limited scope addressing, but I'm not sure if the extension is really necessary) lies in their ability to limit DoS attacks. DoS attacks are essentially attacks on a network and I have some trouble seeing how end to end security between two devices can limit a DoS attack. Maybe I am missing something, however. jak _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Wed Oct 22 21:43:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12861 for ; Wed, 22 Oct 2003 21:43:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUVG-00046w-B9 for saad-archive@odin.ietf.org; Wed, 22 Oct 2003 21:43:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N1h682015798 for saad-archive@odin.ietf.org; Wed, 22 Oct 2003 21:43:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUVG-00046j-5v for saad-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 21:43:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12855 for ; Wed, 22 Oct 2003 21:42:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACUVD-0006do-00 for saad-web-archive@ietf.org; Wed, 22 Oct 2003 21:43:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACUVC-0006dl-00 for saad-web-archive@ietf.org; Wed, 22 Oct 2003 21:43:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUVC-00045c-8E; Wed, 22 Oct 2003 21:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACUV3-00043r-Aa for saad@optimus.ietf.org; Wed, 22 Oct 2003 21:42:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12846 for ; Wed, 22 Oct 2003 21:42:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACUV0-0006dW-00 for saad@ietf.org; Wed, 22 Oct 2003 21:42:50 -0400 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1ACUUz-0006dQ-00 for saad@ietf.org; Wed, 22 Oct 2003 21:42:49 -0400 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9N1mEf04567 for ; Wed, 22 Oct 2003 18:48:14 -0700 Date: Wed, 22 Oct 2003 18:42:15 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <183209229185.20031022184215@brandenburg.com> To: saad@ietf.org In-Reply-To: <200310222234.SAA02302@ietf.org> References: <200310222234.SAA02302@ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------102971CF5A7A165" Subject: [Saad] Fwd: I-D ACTION:draft-crocker-mast-analysis-01.txt Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , ------------102971CF5A7A165 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit I have been directing conversation about this draft to the multi-6 mailing list, but perhaps it is better now to use the SAAD forum? This paper is not part of the MAST proposal. It is an attempt to understand the range of proposals and specifications. This version is a substantial revision. Much of the credit goes to Marcelo Bagnulo. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA ===== Forwarded Message ===== From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: Date: Wednesday, October 22, 2003, 3:34:39 PM Subject: I-D ACTION:draft-crocker-mast-analysis-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CHOICES FOR MULTIADDRESSING Author(s) : D. Crocker Filename : draft-crocker-mast-analysis-01.txt Pages : 0 Date : 2003-10-22 An IP Address serves the dual roles as references to a 'place' on the Internet and to a host on the Internet, labeled 'locator' and 'identifier', respectively. Systems that use IP Addresses as identifiers cannot support dynamic changes in the mapping between the identifier and the locator. For a system to use a different IP Address pair, participants must initiate a new exchange. In the case of TCP, this means a new connection. In recent years, there have been efforts to overcome this limitation, through different approaches at different places in the Internet architecture. This paper reviews the basic requirements for support of multiaddressing (mobility and multihoming), and the efforts to support them. Barriers to adoption, administrative overhead, and operational efficiency are of particular concern. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crocker-mast-analysis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-crocker-mast-analysis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-crocker-mast-analysis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ===== End of Forwarded Message ===== ------------102971CF5A7A165 Content-Type: MESSAGE/EXTERNAL-BODY; name="1.msg" Content-Disposition: attachment; filename="1.msg" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2003-10-22182652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crocker-mast-analysis-01.txt ------------102971CF5A7A165 Content-Type: MESSAGE/EXTERNAL-BODY; name="draft-crocker-mast-analysis-01.txt" Content-Disposition: attachment; filename="draft-crocker-mast-analysis-01.txt" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2003-10-22182652.I-D@ietf.org> ------------102971CF5A7A165-- _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Thu Oct 23 07:37:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13829 for ; Thu, 23 Oct 2003 07:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACdm9-0002QW-QT for saad-archive@odin.ietf.org; Thu, 23 Oct 2003 07:37:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NBb9eZ009328 for saad-archive@odin.ietf.org; Thu, 23 Oct 2003 07:37:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACdm8-0002Ps-4U for saad-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 07:37:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13812 for ; Thu, 23 Oct 2003 07:36:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACdm7-0005kw-00 for saad-web-archive@ietf.org; Thu, 23 Oct 2003 07:37:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACdm7-0005kt-00 for saad-web-archive@ietf.org; Thu, 23 Oct 2003 07:37:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACdm3-0002O2-H0; Thu, 23 Oct 2003 07:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACdlx-0002MW-73 for saad@optimus.ietf.org; Thu, 23 Oct 2003 07:36:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13803 for ; Thu, 23 Oct 2003 07:36:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACdlw-0005kc-00 for saad@ietf.org; Thu, 23 Oct 2003 07:36:56 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1ACdlv-0005kZ-00 for saad@ietf.org; Thu, 23 Oct 2003 07:36:55 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9NBan5u027009; Thu, 23 Oct 2003 05:36:50 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9NBamS27567; Thu, 23 Oct 2003 13:36:49 +0200 (MEST) Date: Thu, 23 Oct 2003 13:36:46 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [Fwd: [Saad] Some initiating thoughts...] To: James Kempf Cc: Erik Nordmark , Leslie Daigle , saad@ietf.org, M.Handley@cs.ucl.ac.uk In-Reply-To: "Your message with ID" <017a01c398e7$ff74d520$2a6015ac@dclkempt40> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , > But much of the appeal for firewalls (and some people extend this to limited > scope addressing, but I'm not sure if the extension is really necessary) > lies in their ability to limit DoS attacks. DoS attacks are essentially > attacks on a network and I have some trouble seeing how end to end security > between two devices can limit a DoS attack. Maybe I am missing something, > however. Yep - end2end security isn't sufficient if you have a wide range of network bandwidth (and too some extent also CPU capacity to deal with network packets) across the network. Some approaches to deal with DoS is thus needed. I don't know if anybody is working on host-assisted approaches. I can imagine interesting approaches like hosts on slow links sending "priority lists" upstream (to specify the relative priority of packets - based on a class description - that are destined towards the host) as one way of being able to cope with DoS flooding attacks. Erik _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Thu Oct 23 09:55:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21581 for ; Thu, 23 Oct 2003 09:55:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfvg-0006EV-PD for saad-archive@odin.ietf.org; Thu, 23 Oct 2003 09:55:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NDt8Fk023953 for saad-archive@odin.ietf.org; Thu, 23 Oct 2003 09:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfvg-0006EG-98 for saad-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 09:55:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21543 for ; Thu, 23 Oct 2003 09:54:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACfve-0000KA-00 for saad-web-archive@ietf.org; Thu, 23 Oct 2003 09:55:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACfvd-0000K6-00 for saad-web-archive@ietf.org; Thu, 23 Oct 2003 09:55:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfva-0006Aq-59; Thu, 23 Oct 2003 09:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACfua-0005l4-Sc for saad@optimus.ietf.org; Thu, 23 Oct 2003 09:54:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21461 for ; Thu, 23 Oct 2003 09:53:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACfuX-0000IR-00 for saad@ietf.org; Thu, 23 Oct 2003 09:53:57 -0400 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1ACfuW-0000IN-00 for saad@ietf.org; Thu, 23 Oct 2003 09:53:56 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id JAA15168 for ; Thu, 23 Oct 2003 09:54:28 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma014166; Thu, 23 Oct 03 09:51:24 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 23 Oct 2003 09:50:48 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 23 Oct 2003 09:50:48 -0400 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Oct 2003 09:50:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Fwd: [Saad] Some initiating thoughts...] Date: Thu, 23 Oct 2003 09:50:47 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA01139371@NHROCMBX1.ets.enterasys.com> Thread-Topic: [Fwd: [Saad] Some initiating thoughts...] Thread-Index: AcOZWgLieC5eOmWLSROJjK0NMbolWgAETkvg From: "Harrington, David" To: "Erik Nordmark" , "James Kempf" Cc: "Leslie Daigle" , , X-OriginalArrivalTime: 23 Oct 2003 13:50:48.0122 (UTC) FILETIME=[A9D349A0:01C3996C] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:80.8653 M:99.5542 P:95.9108 R:95.9108 S:52.8031 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: quoted-printable Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Erik, Typically, a DoS attack will be sourced from a host. Having the host be responsible for advising the network how to prioritize packets is akin to locking the henhouse to prevent fox attacks and then giving the fox the key. I believe the right place to apply policy is in the access switch. The operators should know what types of traffic are likely to be generated by the host, based on the role of the host in the organization, and can preset policies to prioritize the desirable traffic. To handle mobility, and finer-grained role-based policies, the operator can base the expected traffic and priorities on the user's identity, qualified by location and other factors. dbh > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]=20 > Sent: Thursday, October 23, 2003 7:37 AM > To: James Kempf > Cc: Erik Nordmark; Leslie Daigle; saad@ietf.org;=20 > M.Handley@cs.ucl.ac.uk > Subject: Re: [Fwd: [Saad] Some initiating thoughts...] >=20 >=20 > > But much of the appeal for firewalls (and some people=20 > extend this to limited > > scope addressing, but I'm not sure if the extension is=20 > really necessary) > > lies in their ability to limit DoS attacks. DoS attacks are=20 > essentially > > attacks on a network and I have some trouble seeing how end=20 > to end security > > between two devices can limit a DoS attack. Maybe I am=20 > missing something, > > however. >=20 > Yep - end2end security isn't sufficient if you have a wide range of > network bandwidth (and too some extent also CPU capacity to deal > with network packets) across the network. >=20 > Some approaches to deal with DoS is thus needed. >=20 > I don't know if anybody is working on host-assisted approaches. > I can imagine interesting approaches like hosts on slow links sending=20 > "priority lists" upstream (to specify the relative priority=20 > of packets -=20 > based on a class description - that are destined towards the=20 > host) as one > way of being able to cope with DoS flooding attacks. >=20 > Erik >=20 >=20 > _______________________________________________ > Saad mailing list > Saad@ietf.org > https://www1.ietf.org/mailman/listinfo/saad >=20 _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Thu Oct 23 10:03:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22060 for ; Thu, 23 Oct 2003 10:03:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACg3M-0007Y3-0k for saad-archive@odin.ietf.org; Thu, 23 Oct 2003 10:03:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NE33R4029009 for saad-archive@odin.ietf.org; Thu, 23 Oct 2003 10:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACg3L-0007Xo-RJ for saad-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 10:03:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22051 for ; Thu, 23 Oct 2003 10:02:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACg3J-0000Sw-00 for saad-web-archive@ietf.org; Thu, 23 Oct 2003 10:03:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACg3J-0000St-00 for saad-web-archive@ietf.org; Thu, 23 Oct 2003 10:03:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACg3I-0007WJ-Gw; Thu, 23 Oct 2003 10:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACg2d-0007Nm-27 for saad@optimus.ietf.org; Thu, 23 Oct 2003 10:02:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22013 for ; Thu, 23 Oct 2003 10:02:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACg2a-0000Sg-00 for saad@ietf.org; Thu, 23 Oct 2003 10:02:16 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ACg2a-0000S6-00 for saad@ietf.org; Thu, 23 Oct 2003 10:02:16 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Oct 2003 06:59:13 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9NE1hQY028426; Thu, 23 Oct 2003 07:01:44 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-42.cisco.com [10.32.241.42]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANL30025; Thu, 23 Oct 2003 07:01:42 -0700 (PDT) Date: Thu, 23 Oct 2003 10:01:41 -0400 Subject: Re: [Fwd: [Saad] Some initiating thoughts...] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: saad@ietf.org To: "Harrington, David" From: Melinda Shore In-Reply-To: <6D745637A7E0F94DA070743C55CDA9BA01139371@NHROCMBX1.ets.enterasys.com> Message-Id: <6D3BD34A-0561-11D8-8EB9-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, October 23, 2003, at 09:50 AM, Harrington, David wrote: > I believe the right place to apply policy is in the access switch. I believe that *a* right place to apply policy is in the access switch. I don't see how the user's identity is sufficient to be able to answer the question of whether or not a particular stream of data should be afforded various sorts of treatment, etc. It may be sufficient for admission control, though, and it would certainly be a substantial improvement over current common practice. Melinda _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Thu Oct 23 10:33:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25867 for ; Thu, 23 Oct 2003 10:33:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgWO-0003z7-GR for saad-archive@odin.ietf.org; Thu, 23 Oct 2003 10:33:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NEX4Kt015311 for saad-archive@odin.ietf.org; Thu, 23 Oct 2003 10:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgWO-0003ys-A9 for saad-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 10:33:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25856 for ; Thu, 23 Oct 2003 10:32:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACgWL-0001Gk-00 for saad-web-archive@ietf.org; Thu, 23 Oct 2003 10:33:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACgWL-0001Gh-00 for saad-web-archive@ietf.org; Thu, 23 Oct 2003 10:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgWK-0003ws-MV; Thu, 23 Oct 2003 10:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgWA-0003te-Fd for saad@optimus.ietf.org; Thu, 23 Oct 2003 10:32:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25834 for ; Thu, 23 Oct 2003 10:32:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACgW8-0001GZ-00 for saad@ietf.org; Thu, 23 Oct 2003 10:32:48 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1ACgW7-0001GJ-00 for saad@ietf.org; Thu, 23 Oct 2003 10:32:47 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9NEW8xA008240; Thu, 23 Oct 2003 07:32:09 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9NEW8S23691; Thu, 23 Oct 2003 16:32:08 +0200 (MEST) Date: Thu, 23 Oct 2003 16:32:06 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [Fwd: [Saad] Some initiating thoughts...] To: "Harrington, David" Cc: saad@ietf.org In-Reply-To: "Your message with ID" <6D745637A7E0F94DA070743C55CDA9BA01139371@NHROCMBX1.ets.enterasys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , > Typically, a DoS attack will be sourced from a host. Having the host be > responsible for advising the network how to prioritize packets is akin > to locking the henhouse to prevent fox attacks and then giving the fox > the key. David, Your comment would make sense if I had suggested doing this for packets *sent from the host*. I did not. I was talking about packets being delivered *towards the host*. And only in terms of a *relative priority* compared to other packets sent towards the same IP address. Erik _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Mon Oct 27 11:57:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24870 for ; Mon, 27 Oct 2003 11:57:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEAg0-0006yM-H7 for saad-archive@odin.ietf.org; Mon, 27 Oct 2003 11:57:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RGv83X026796 for saad-archive@odin.ietf.org; Mon, 27 Oct 2003 11:57:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEAg0-0006y7-At for saad-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 11:57:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24850 for ; Mon, 27 Oct 2003 11:56:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEAfz-0000M5-00 for saad-web-archive@ietf.org; Mon, 27 Oct 2003 11:57:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEAfy-0000M1-00 for saad-web-archive@ietf.org; Mon, 27 Oct 2003 11:57:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEAft-0006vb-Af; Mon, 27 Oct 2003 11:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEAf1-0006qk-Bo for saad@optimus.ietf.org; Mon, 27 Oct 2003 11:56:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24794 for ; Mon, 27 Oct 2003 11:55:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEAf0-0000Kp-00 for saad@ietf.org; Mon, 27 Oct 2003 11:56:06 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEAex-0000KB-00 for saad@ietf.org; Mon, 27 Oct 2003 11:56:04 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9RGt8v13093; Mon, 27 Oct 2003 18:55:08 +0200 Date: Mon, 27 Oct 2003 18:55:07 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: James Kempf , Leslie Daigle , , Subject: Re: [Fwd: [Saad] Some initiating thoughts...] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , On Thu, 23 Oct 2003, Erik Nordmark wrote: > I don't know if anybody is working on host-assisted approaches. > I can imagine interesting approaches like hosts on slow links sending > "priority lists" upstream (to specify the relative priority of packets - > based on a class description - that are destined towards the host) as one > way of being able to cope with DoS flooding attacks. Sounds a lot like a potential applicability for DiffServ marking, letting the users configure (with a few rules) how the ISP should prioritize the packets going towards the customer? Do this through a web page, install the rules on a router, and you're done. From the IETF perspective, the problem may be that there is no IETF problem (requiring standards action, etc.) as such.. Btw, I, too, would be interested to hear why the end-host/distributed firewalling BOF/WG died off.. it had a lot of promise (but a lot of difficult problems, as well).. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Tue Oct 28 04:28:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11613 for ; Tue, 28 Oct 2003 04:28:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQ91-0002un-6i for saad-archive@odin.ietf.org; Tue, 28 Oct 2003 04:28:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S9S7uA011204 for saad-archive@odin.ietf.org; Tue, 28 Oct 2003 04:28:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQ90-0002ud-VM for saad-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 04:28:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11596 for ; Tue, 28 Oct 2003 04:27:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEQ8y-0006EK-00 for saad-web-archive@ietf.org; Tue, 28 Oct 2003 04:28:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEQ8x-0006EH-00 for saad-web-archive@ietf.org; Tue, 28 Oct 2003 04:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQ8v-0002sv-3t; Tue, 28 Oct 2003 04:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEQ8f-0002s7-O7 for saad@optimus.ietf.org; Tue, 28 Oct 2003 04:27:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11590 for ; Tue, 28 Oct 2003 04:27:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEQ8c-0006E8-00 for saad@ietf.org; Tue, 28 Oct 2003 04:27:42 -0500 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 1AEQ8c-0006Dr-00 for saad@ietf.org; Tue, 28 Oct 2003 04:27:42 -0500 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 408B91C for ; Tue, 28 Oct 2003 11:40:25 +0200 (EET) Message-ID: <3F9E3672.9020902@nomadiclab.com> Date: Tue, 28 Oct 2003 11:27:14 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saad@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Saad] About forwarding tags Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > So in the Internet architecture, IP addresses serve at least these three > functions: > > 1 - Identify an end-end entity > 2 - Describe where its interface(s) is in the network (location) > 3 - Serve as a forwarding tag for packets. I think this is a very important point, and worth pursuing much more. (I am also looking forward to more brain torque with more functions of IP addresses...) To start with, a small observation: - In a vanilla IP-layer router, the forwarding tag is the destination address. - In a QoS-enabled router, the forwarding tag is something more, e.g. - In a NAT box, the forwarding tag depends on the direction of the traffic, and for inbound traffic it is typically but may be even smaller (e.g ) or larger (), depending on implementation. [I hope I got it right, I am not a NATologist.] And the maybe more important one: - If IPsec is used, or if a new "session ID" is introduced (as in SIM), the or could be used as a forwarding tag, thereby enabling cross-realm communication. Hence, the important question is whether we want to limit our considerations to solutions where the forwarding tag is solely the IP address or whether we want to consider the cases where it actually is or can be something more. A related question is whether it is acceptable to rewrite forwarding tags on the fly. --Pekka Nikander _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Wed Oct 29 06:05:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02949 for ; Wed, 29 Oct 2003 06:05:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEo8T-0001hg-Oi for saad-archive@odin.ietf.org; Wed, 29 Oct 2003 06:05:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TB59qn006549 for saad-archive@odin.ietf.org; Wed, 29 Oct 2003 06:05:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEo8T-0001hY-IN for saad-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 06:05:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02934 for ; Wed, 29 Oct 2003 06:04:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEo8P-00069X-00 for saad-web-archive@ietf.org; Wed, 29 Oct 2003 06:05:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEo8P-00069S-00 for saad-web-archive@ietf.org; Wed, 29 Oct 2003 06:05:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEo8M-0001fR-87; Wed, 29 Oct 2003 06:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEo7N-0001ar-EI for saad@optimus.ietf.org; Wed, 29 Oct 2003 06:04:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02919 for ; Wed, 29 Oct 2003 06:03:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEo7J-00068z-00 for saad@ietf.org; Wed, 29 Oct 2003 06:03:57 -0500 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AEo7I-00068l-00 for saad@ietf.org; Wed, 29 Oct 2003 06:03:56 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9TB3QNb117998 for ; Wed, 29 Oct 2003 12:03:26 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9TB0LZp151472 for ; Wed, 29 Oct 2003 12:00:21 +0100 Received: from zurich.ibm.com (dyn-9-13-127-0.ge.ch.ibm.com [9.13.127.0]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA64108 for ; Wed, 29 Oct 2003 12:00:20 +0100 Message-ID: <3F9F9DA4.152A4E7F@zurich.ibm.com> Date: Wed, 29 Oct 2003 11:59:48 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: saad@ietf.org Subject: Re: [Fwd: [Saad] Some initiating thoughts...] References: <3F8F5044.5050004@thinkingcat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Leslie Daigle wrote: > > I posted this a few days ago -- before, I think, people had > a chance to get subscribed. So, let me re-post it for > further discussion... And I've been carrying the attached minor comment around for two weeks... ... > > 3.2. Addressing Requirements of Enterprises ... > Some enterprises have addressing requirements caused by the need to set > up inter-enterprise Virtual Private Networks (VPNs). Also, at some > point in their existence most enterprises undergo some form of merger or > acquisition, and discover that they need to merge internal networks. In > both these circumstances there is a requirement to avoid the need to > renumber or to suffer from ambiguous addressing resulting from the > merger of two private address spaces. I think this misses another related requirement that may become very significant, in a future consisting of virtual organizations and on-demand computing environments. It may often be required for a set of enterprises to create a short-term "closed user group" of hosts that need transparent (firewall-free) interconnection for a period of time; this is like a dynamic merger followed some time later by a demerger. This is more demanding on the addressing (and routing) architecture than relatively static VPNs or one-time events like mergers. Brian _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Wed Oct 29 09:33:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09304 for ; Wed, 29 Oct 2003 09:33:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AErNh-0004vE-Hg for saad-archive@odin.ietf.org; Wed, 29 Oct 2003 09:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TEX5M6018919 for saad-archive@odin.ietf.org; Wed, 29 Oct 2003 09:33:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AErNh-0004v4-CB for saad-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 09:33:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09286 for ; Wed, 29 Oct 2003 09:32:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AErNf-0001hh-00 for saad-web-archive@ietf.org; Wed, 29 Oct 2003 09:33:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AErNf-0001he-00 for saad-web-archive@ietf.org; Wed, 29 Oct 2003 09:33:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AErNb-0004tV-TI; Wed, 29 Oct 2003 09:32:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AErMw-0004oh-UP for saad@optimus.ietf.org; Wed, 29 Oct 2003 09:32:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09228 for ; Wed, 29 Oct 2003 09:32:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AErMv-0001hA-00 for saad@ietf.org; Wed, 29 Oct 2003 09:32:17 -0500 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1AErMu-0001h5-00 for saad@ietf.org; Wed, 29 Oct 2003 09:32:16 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id JAA01011 for ; Wed, 29 Oct 2003 09:32:54 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma000994; Wed, 29 Oct 03 09:32:31 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 29 Oct 2003 09:31:46 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 29 Oct 2003 09:31:46 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 09:31:47 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Fwd: [Saad] Some initiating thoughts...] Date: Wed, 29 Oct 2003 09:31:47 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA0113950D@NHROCMBX1.ets.enterasys.com> Thread-Topic: [Fwd: [Saad] Some initiating thoughts...] Thread-Index: AcOeDIZodw09veXHRJuepdTlE9RkSQAHIPsg From: "Harrington, David" To: "Brian E Carpenter" , X-OriginalArrivalTime: 29 Oct 2003 14:31:47.0001 (UTC) FILETIME=[61E8F290:01C39E29] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:83.3688 M:99.5542 P:95.9108 R:95.9108 S:62.4530 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Content-Transfer-Encoding: quoted-printable Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Brian, I'm having difficulty understanding the use-case scenario. Can you expand on a scenario when this would be needed so I can better grasp your point? Thanks, dbh > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Wednesday, October 29, 2003 6:00 AM > To: saad@ietf.org > Subject: Re: [Fwd: [Saad] Some initiating thoughts...] >=20 >=20 > Leslie Daigle wrote: > >=20 > > I posted this a few days ago -- before, I think, people had > > a chance to get subscribed. So, let me re-post it for > > further discussion... >=20 > And I've been carrying the attached minor comment around for=20 > two weeks... > ... > >=20 > > 3.2. Addressing Requirements of Enterprises > ... > > Some enterprises have addressing requirements caused by the=20 > need to set > > up inter-enterprise Virtual Private Networks (VPNs). Also, at some > > point in their existence most enterprises undergo some form=20 > of merger or > > acquisition, and discover that they need to merge internal=20 > networks. In > > both these circumstances there is a requirement to avoid the need to > > renumber or to suffer from ambiguous addressing resulting from the > > merger of two private address spaces. >=20 > I think this misses another related requirement that may become very > significant, in a future consisting of virtual organizations=20 > and on-demand > computing environments. It may often be required for a set of=20 > enterprises > to create a short-term "closed user group" of hosts that need=20 > transparent > (firewall-free) interconnection for a period of time; this is=20 > like a dynamic > merger followed some time later by a demerger. This is more=20 > demanding on the > addressing (and routing) architecture than relatively static=20 > VPNs or one-time > events like mergers. >=20 > Brian >=20 > _______________________________________________ > Saad mailing list > Saad@ietf.org > https://www1.ietf.org/mailman/listinfo/saad >=20 _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Wed Oct 29 11:36:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17842 for ; Wed, 29 Oct 2003 11:36:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtIi-00055E-PD for saad-archive@odin.ietf.org; Wed, 29 Oct 2003 11:36:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TGa4se019536 for saad-archive@odin.ietf.org; Wed, 29 Oct 2003 11:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtIi-00054z-Js for saad-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 11:36:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17826 for ; Wed, 29 Oct 2003 11:35:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEtIh-0004WQ-00 for saad-web-archive@ietf.org; Wed, 29 Oct 2003 11:36:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEtIh-0004WM-00 for saad-web-archive@ietf.org; Wed, 29 Oct 2003 11:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtIf-00053M-9M; Wed, 29 Oct 2003 11:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEtHj-0004yR-CY for saad@optimus.ietf.org; Wed, 29 Oct 2003 11:35:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17787 for ; Wed, 29 Oct 2003 11:34:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEtHi-0004Vf-00 for saad@ietf.org; Wed, 29 Oct 2003 11:35:02 -0500 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AEtHh-0004V2-00 for saad@ietf.org; Wed, 29 Oct 2003 11:35:01 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9TGYIXZ087648; Wed, 29 Oct 2003 17:34:18 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9TGYIMt248134; Wed, 29 Oct 2003 17:34:19 +0100 Received: from zurich.ibm.com ([9.145.174.1]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA22154; Wed, 29 Oct 2003 17:34:17 +0100 Message-ID: <3F9FEBE9.B63027C6@zurich.ibm.com> Date: Wed, 29 Oct 2003 17:33:45 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "Harrington, David" CC: saad@ietf.org Subject: Re: [Fwd: [Saad] Some initiating thoughts...] References: <6D745637A7E0F94DA070743C55CDA9BA0113950D@NHROCMBX1.ets.enterasys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David, Virtual organizations are a fundamental feature of grid computing. A group of users scattered around a selection of sites come together to tackle a particular problem during a particular period of time. (In existing grids it would typically be a particular computational scientific problem.) During that time they pool their resources across organizations and these resources (servers, storage, etc) need to communicate transparently among themselves as if they were a single physical site, separate from their normal organizational affiliation (i.e. NATs and firewalls are a big barrier, so today's addressing and security model is a problem). You could conceive this as a set of VPN connnections but that is a clumsy way to actually implement it. There is some discussion of virtual organizations at https://forge.gridforum.org/docman2/ViewProperties.php?group_id=42&document_content_id=919 Brian "Harrington, David" wrote: > > Hi Brian, > > I'm having difficulty understanding the use-case scenario. Can you > expand on a scenario when this would be needed so I can better grasp > your point? > > Thanks, > dbh > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > > Sent: Wednesday, October 29, 2003 6:00 AM > > To: saad@ietf.org > > Subject: Re: [Fwd: [Saad] Some initiating thoughts...] > > > > > > Leslie Daigle wrote: > > > > > > I posted this a few days ago -- before, I think, people had > > > a chance to get subscribed. So, let me re-post it for > > > further discussion... > > > > And I've been carrying the attached minor comment around for > > two weeks... > > ... > > > > > > 3.2. Addressing Requirements of Enterprises > > ... > > > Some enterprises have addressing requirements caused by the > > need to set > > > up inter-enterprise Virtual Private Networks (VPNs). Also, at some > > > point in their existence most enterprises undergo some form > > of merger or > > > acquisition, and discover that they need to merge internal > > networks. In > > > both these circumstances there is a requirement to avoid the need to > > > renumber or to suffer from ambiguous addressing resulting from the > > > merger of two private address spaces. > > > > I think this misses another related requirement that may become very > > significant, in a future consisting of virtual organizations > > and on-demand > > computing environments. It may often be required for a set of > > enterprises > > to create a short-term "closed user group" of hosts that need > > transparent > > (firewall-free) interconnection for a period of time; this is > > like a dynamic > > merger followed some time later by a demerger. This is more > > demanding on the > > addressing (and routing) architecture than relatively static > > VPNs or one-time > > events like mergers. > > > > Brian _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad From exim@www1.ietf.org Fri Oct 31 11:15:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05425 for ; Fri, 31 Oct 2003 11:15:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbvg-0000TX-DJ for saad-archive@odin.ietf.org; Fri, 31 Oct 2003 11:15:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VGFGkg001823 for saad-archive@odin.ietf.org; Fri, 31 Oct 2003 11:15:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbvg-0000TK-7S for saad-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 11:15:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05401 for ; Fri, 31 Oct 2003 11:15:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbvf-0002Sf-00 for saad-web-archive@ietf.org; Fri, 31 Oct 2003 11:15:15 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFbvf-0002SY-00 for saad-web-archive@ietf.org; Fri, 31 Oct 2003 11:15:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbvS-0000R1-O0; Fri, 31 Oct 2003 11:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFbuf-0000MK-OZ for saad@optimus.ietf.org; Fri, 31 Oct 2003 11:14:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05362 for ; Fri, 31 Oct 2003 11:14:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFbue-0002QW-00 for saad@ietf.org; Fri, 31 Oct 2003 11:14:12 -0500 Received: from joy.songbird.com ([208.184.79.7]) by ietf-mx with esmtp (Exim 4.12) id 1AFbue-0002Pw-00 for saad@ietf.org; Fri, 31 Oct 2003 11:14:12 -0500 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9VGJlf02978 for ; Fri, 31 Oct 2003 08:19:47 -0800 Date: Fri, 31 Oct 2003 08:13:35 -0800 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <125230797849.20031031081335@brandenburg.com> To: saad@ietf.org Subject: Re: [Saad] About forwarding tags In-Reply-To: <3F9E3672.9020902@nomadiclab.com> References: <3F9E3672.9020902@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: saad-admin@ietf.org Errors-To: saad-admin@ietf.org X-BeenThere: saad@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Scope Addressing Architecture Discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, >> So in the Internet architecture, IP addresses serve at least these three >> functions: >> >> 1 - Identify an end-end entity >> 2 - Describe where its interface(s) is in the network (location) >> 3 - Serve as a forwarding tag for packets. PN> I think this is a very important point, and worth pursuing much more. Normally, this sort of careful distinction sits quite well with me, too. However in this case, I suspect it is creating a difference that is not as real as it seems. Here's my thought: A reference string must balance between the needs of higher functionality and lower functionality. (In some cases, the altitude of the functionality is not a different layer. For example, we have quite a few different things going on inside IP. For this discussion, I am postulating some sort of internal hierarchy for them.) We need to describe how the reference string is used, in relation to those higher and lower functions. For example, note the change in perspective for the above list. The first two entries describe informational roles, while the third describes a functional role. I think the reason for this disparity is that the _purpose_ of a locator (#2 on the list) is to serve as a forwarding tag (or, at least, as part of one.) Take that purpose away and we really do not need locators. An identifier serves to uniquely distinguish one component from another. The "higher" functionality for an identifier only needs the uniqueness. The "lower" functionality needs to be able to map the identifier to another reference, such as a locator. Any information aggregation (hierarchy) built into an identifier is typically based on administrative relationships. A locator enables routing. The "higher" functionality for a locator needs unique identification. The "lower" functionality for a locator needs to perform routing. Any information aggregation build into a locator needs to facilitate routing table efficiencies. Given the nature of routing, this means that aggregation needs to be based on topology, or something related to topology. (I'm trying to leave room for geographic addresses.) The danger in having the list of 3 labels is that it will lead to thinking that we really do need 3 labels. We don't. We need two. Making specific choices for the two labels requires looking at when, where and how they need to be used. For example, as NOID notes, it is ok to use a public key if its computational overhead is used only occasionally. Similarly, a reference used in every datagram needs to be as short as feasible. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA _______________________________________________ Saad mailing list Saad@ietf.org https://www1.ietf.org/mailman/listinfo/saad