From owner-multi6@ops.ietf.org Fri Aug 1 18:11:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14937 for ; Fri, 1 Aug 2003 18:11:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ii4j-000Gx7-6z for multi6-data@psg.com; Fri, 01 Aug 2003 22:08:37 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.20) id 19ii4d-000Gwe-49 for multi6@ops.ietf.org; Fri, 01 Aug 2003 22:08:31 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h71M93xS002515 for ; Sat, 2 Aug 2003 00:09:03 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 2 Aug 2003 00:08:25 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Identification, layering, transactions and universal connectivity From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_20,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Identity is a very interesting concept. What exactly makes a person, an object or some piece of information exactly that person, object or information and not someone or something else? One school of thought is that the total of all attributes provides identity. Then there is the notion that some attributes are fundamental while others are inconsequential to the identity of the person, object or information. Finally, there is the view that identity is a fundamental property that doesn't depend on any attributes that may or may not be present. In the real world the first method of identification works to some degree, as it is impossible for two objects to be identical in all aspects, including occupying the same place at the same time. However, for information this doesn't work so well, since this way the identity of a piece of information is identical to the information itself, so referring to information by its identifier becomes useless. The latter two concepts of identification surface in relational databases and object oriented databases respectively. In a relational database model, links between objects are made using one or more key attributes in the destination object, while in object oriented databases objects are assigned an identifier that remains stable regardless of changes to any or all of an object's attributes. So what do we use on the internet today? At first glance it seems that we use a relatively ephemeral attribute as the identifier: the host address. The FQDNs we generally use can be seen as simple mnemonics for addresses. However, I think over the years the role of FQDNs has expanded and they now generally provide the unchanging identifier that remains the same through changes of just about anything, such as the IP address, IP version or even hardware platform. FQDNs also change from time to time, which undermines this viewpoint to some degree, but not to the degree of invalidating it, IMO. The question at this point is: are we happy with the way identification of resources happens at this level? While I agree that the DNS suffers from many problems, I assert (for now at least) that none of these are fundamental and/or easily fixable by ditching the DNS/FQDN system and adopt something substantially different. Identification on the internet, especially by means of IP addresses or FQDNs, has traditionally concerned itself with hosts. However, at other levels of abstraction identification is also useful or required: - a service running on a host or a group of hosts - a process implementing a service on a host - a (reply to a) transaction - a position within a stream - a combination of resource and service / service location providing the resource - a resource independent of the service / service location providing it For each of these there is a suitable identification mechanism that works (reasonably) well within the scope of the entity being identified. (Aside: the difficulty in mapping from an identifier at the current layer to one at the next lower layer seems to be especially hard at the top abstraction level: for instance, a person's name to email address or song name to file location.) The trouble starts when multihoming and resiliency against failure enter the picture. The basic idea here is: select options (destination address etc) when multiple are available, execute transaction. Repeat with different options on failure. Stop on success or either all options have been tried. This works very well of course, unless the transaction is sufficiently expensive to perform or has side-effects that make repeating it after failure problematic. In those cases repeating the transaction and possibly failing multiple times isn't optimal or acceptable. Solution: split up a large transaction into smaller ones that can each be repeated. This is something that TCP does very well, within the limitations imposed by the protocol (= no changing addresses during a session). HTTP can also do it, by allowing parts of files to be transferred. A smart application can request parts of a file from different hosts and thereby easily recover from failures in one of those hosts. So HTTP provides better functionality than TCP. Unfortunately, TCP comes with the OS, while handling partial transfers over HTTP is something applications have to do for themselves. (And TCP can do many things that HTTP can't (properly).) In some cases it is completely appropriate for applications to implement load balancing and failover, because the dynamics are very specific to the application. A good example is peer to peer file sharing. (Although some reseach into n-on-m transport protocols might be interesting.) In other cases this doesn't make sense at all as it leads to pretty much re-implementing TCP but now with the single address for each end limitation removed, with all the duplication of effort and interoperability issues that must ensue. But the most important reason why this shouldn't go in applications is because the transition to IPv6 has proven that it it much harder to get applications to support new network features than doing the same in the OS. Multiply by the number of applications in existence compared to the number of OSes and the scale of the potential catastrophe becomes apparent. I think now is the time to admit that the IETF in its enthousiasm to improve IP has actually broken it: we no longer have universal connectivity in IPv6. This is even worse than in IPv4, where this is still relatively common in at least the client-to-server direction. With IPv4-style multihoming out the window and in the presence of address scoping, it is now very easy for two hosts to have a set of addresses each, without any way to know which combination of addresses makes bidirectional communication possible, except to try all combinations. For someone doing traditional IP on a box sitting in a fixed place this may not seem like a huge problem. But now try again with a laptop that connects to a variety of networks throughout the day. And then consider an airplane that must communicate with the ground when possible, but also needs stable addresses for its internal communication. Or ad hoc networks where some people connect to the internet (using different ISPs of course) and others don't, but they all want to communicate locally at high speed. Solutions? The good part is that we have a number of partial solutions on the table today. If we integrate those, we're more than halfway there. First of all, we have the domain name system. Unfortunately the DNS was tacked on to the IP architecture very late in the game, and we're still suffering because of this. Traditionally, the DNS needs root servers to lend authority to name claims and to help the resolving process. Multicast DNS solves the latter and makes it possible to use names in ad hoc networks. DNSSEC could hopefully solve the authority problem so authorative use of names would be possible in ad hoc environments. We have SCTP and proof of concept TCP modifications that allow TCP to jump addresses in the middle of a session. We also have proposals for locator/identifier splits, some of which are even implemented. There are also some proposals to take the edge off of the address selection problem, but unfortunately nothing that completely solves this problem yet. The only thing we need to do is integrate it all: - Hide the use of multiple addresses from 99% of the applications, including the ones that use existing APIs (by implementing this somewhere between IP and the transport protocols). Unfortunately this means another identifier that sits between the real identifier = the FQDN and the addresses. - Work on the address selection problem. - Improve the DNS by making it faster and have it work in ad hoc networks where the root is unreachable too. - Create namespace and protocol independent APIs with extensions for handling multiple addresses. To use someone's favorite quote: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." (Antoine de Saint-Exupery) There is still lots left to take away. From owner-multi6@ops.ietf.org Fri Aug 1 18:56:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16388 for ; Fri, 1 Aug 2003 18:56:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19iiox-000JfZ-FQ for multi6-data@psg.com; Fri, 01 Aug 2003 22:56:23 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.20) id 19iiou-000JdX-BS for multi6@ops.ietf.org; Fri, 01 Aug 2003 22:56:20 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 5EDBC34444; Fri, 1 Aug 2003 15:52:36 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h71MuJYB018439; Fri, 1 Aug 2003 15:56:19 -0700 (PDT) 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: Identification, layering, transactions and universal connectivity Date: Fri, 1 Aug 2003 15:56:19 -0700 Message-ID: Thread-Topic: Identification, layering, transactions and universal connectivity Thread-Index: AcNYe9712TcsAk1SRW2vMcPrAqbRdAAAjirA From: "Tony Li" To: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable | - Work on the address selection problem. I don't want to discourage all of the metaphysics, but I would like to mumble a bit about this part of the problem. What are the boundaries of the solution space for this particular area? Ultimately, in a utopian world, we'd like an oracle that gives us the perfect pair of addresses to use for any given communication. These addresses would not only provide reachability, but would provide optimality in routing, latency etc. Back in realityland, we have no such oracle. If we want to=20 make an intelligent decision, we need to have data to base that decision upon. Without the data, possibly via indirect access, we are guessing, tho that's not necessarily a bad thing. See Ethernet. =20 The data that we would like to have includes topological connectivity, including policy constraints, available bandwidth, latency, QoS availability, etc. ad nauseum. Where is that data today? Some of it is in the routing subsystem. Most of it is not collected today. Much of it is real-time information, so=20 not maintaining a 'current' copy would make the information worthless. And the overhead of storing the information and distributing it is pretty clearly daunting. =20 Instead of trying to swallow this huge mountain of data, we have a very simple alternative: perform experiments. By simply trying the addresses that we get from our addressing system and actually sending the packets, we are, in effect, gathering the data that we want to make a decision in the first place. =20 This also has the advantage that we can vary the amount of effort that a particular application/host puts into selection. Some hosts that only require reachability can do simple=20 linear search. Other hosts can do parallel searches of the possible connections, plus do periodic evaluations to see if there are more optimal alternatives over time. =20 The network control plane does not change from the functions that we have available today. In other words, the problem is already solved. Tony From owner-multi6@ops.ietf.org Sat Aug 2 04:51:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08644 for ; Sat, 2 Aug 2003 04:51:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19is3m-000JxE-U6 for multi6-data@psg.com; Sat, 02 Aug 2003 08:48:18 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.20) id 19is3j-000Jwx-JY for multi6@ops.ietf.org; Sat, 02 Aug 2003 08:48:16 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h728mkxS012020; Sat, 2 Aug 2003 10:48:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 2 Aug 2003 10:48:09 +0200 Subject: Re: Identification, layering, transactions and universal connectivity Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <0AFEE9A9-C4C6-11D7-91F1-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zaterdag, aug 2, 2003, at 00:56 Europe/Amsterdam, Tony Li wrote: > | - Work on the address selection problem. > I don't want to discourage all of the metaphysics, but I would > like to mumble a bit about this part of the problem. What are > the boundaries of the solution space for this particular area? > Ultimately, in a utopian world, we'd like an oracle that gives > us the perfect pair of addresses to use for any given communication. > These addresses would not only provide reachability, but would > provide optimality in routing, latency etc. > Back in realityland, we have no such oracle. Not something that magically knows which address pairs are good and which are bad, no. But it should be possible to leverage information that exists already or discover information when needed. > If we want to > make an intelligent decision, we need to have data to base that > decision upon. Without the data, possibly via indirect access, > we are guessing, tho that's not necessarily a bad thing. See > Ethernet. Ethernet is not a bad thing??? I think blindly guessing is pretty pathetic, especially if you consider that in large sites, many other hosts may be doing the same thing a little earlier or a little later. And the same host will very likely done the same thing before. It's not so much that we must desperately try to find the best address pair. BGP doesn't give us that either. But it's essential that we're able to weed out the very bad pairs quickly. It would be very helpful if we had some hints in the mapping system for this, such as "this is a low bandwidth/expensive address, only use as a backup" or "this is an address with partial connectivity (ie globally unique not globally routable) so only use when you know it's reachable". > The data that we would like to have includes topological connectivity, > including policy constraints, available bandwidth, latency, QoS > availability, etc. ad nauseum. Where is that data today? > Some of it is in the routing subsystem. Most of it is not > collected today. Much of it is real-time information, so > not maintaining a 'current' copy would make the information > worthless. And the overhead of storing the information and > distributing it is pretty clearly daunting. 80/20 rule? > Instead of trying to swallow this huge mountain of data, we > have a very simple alternative: perform experiments. By > simply trying the addresses that we get from our addressing > system and actually sending the packets, we are, in effect, > gathering the data that we want to make a decision in the > first place. Yes. But the question is: do we want to go evaluate connectivity properties for half a dozen round trips before we do anything, do we choose something and go with it until we notice it doesn't work so well, or do we combine these by starting the communication immediately using one address pair and then evaluate connectivity in the background? > This also has the advantage that we can vary the amount of > effort that a particular application/host puts into selection. > Some hosts that only require reachability can do simple > linear search. Other hosts can do parallel searches of the > possible connections, plus do periodic evaluations to see if > there are more optimal alternatives over time. How much magic do we need in the application to enable this differentiation? > The network control plane does not change from the functions > that we have available today. In other words, the problem > is already solved. ??? From owner-multi6@ops.ietf.org Sat Aug 2 05:27:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09157 for ; Sat, 2 Aug 2003 05:27:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19isea-000LRr-AI for multi6-data@psg.com; Sat, 02 Aug 2003 09:26:20 +0000 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 4.20) id 19iseY-000LRc-4j for multi6@ops.ietf.org; Sat, 02 Aug 2003 09:26:18 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id C09AC23C44; Sat, 2 Aug 2003 01:36:48 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h729QHYB003207; Sat, 2 Aug 2003 02:26:17 -0700 (PDT) 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: Identification, layering, transactions and universal connectivity Date: Sat, 2 Aug 2003 02:26:17 -0700 Message-ID: Thread-Topic: Identification, layering, transactions and universal connectivity Thread-Index: AcNY0tjr5Sw6Zc3LSgWGxjDl1QX0SwABC4vg From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable | It's not so much that we must desperately try to find the=20 | best address=20 | pair. BGP doesn't give us that either. But it's essential=20 | that we're=20 | able to weed out the very bad pairs quickly. It would be=20 | very helpful=20 | if we had some hints in the mapping system for this, such=20 | as "this is a=20 | low bandwidth/expensive address, only use as a backup" or=20 | "this is an=20 | address with partial connectivity (ie globally unique not globally=20 | routable) so only use when you know it's reachable". Well, you're already into developing a global policy language=20 for locators. Seems expensive. | 80/20 rule? Exactly. | Yes. But the question is: do we want to go evaluate connectivity=20 | properties for half a dozen round trips before we do=20 | anything, do we=20 | choose something and go with it until we notice it doesn't work so=20 | well, or do we combine these by starting the communication=20 | immediately=20 | using one address pair and then evaluate connectivity in=20 | the background? If we don't proscribe or prescribe, then this is just left as an implementation detail. | How much magic do we need in the application to enable this=20 | differentiation? Or in the kernel. It depends on whether or not you're willing to add to the API. If you're willing to say, make it a socket option, then all of it just goes in the kernel once. | > The network control plane does not change from the functions | > that we have available today. In other words, the problem | > is already solved. | =20 | ??? Restated: if we don't have to distribute more/new/timely information to support 'intelligent' locator selection, then we don't have to=20 make modifications to the routing subsystem and can defer all of the 'magic'. This makes migration easier as even the simplest of algorithms can be used initially to select locators and can then become more sophisticated as time progresses. Put yet another way: let's remove the complexity of locator selection. If simplistic turns out to be insufficient, then let's at least take out fancy information distribution and be a bit nearer perfection. Tony From owner-multi6@ops.ietf.org Sat Aug 2 12:39:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16804 for ; Sat, 2 Aug 2003 12:39:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19izMF-000CQr-Ik for multi6-data@psg.com; Sat, 02 Aug 2003 16:35:51 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.20) id 19izMC-000CQd-PO for multi6@ops.ietf.org; Sat, 02 Aug 2003 16:35:49 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h72GaKxS016784; Sat, 2 Aug 2003 18:36:21 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 2 Aug 2003 18:35:44 +0200 Subject: Re: Identification, layering, transactions and universal connectivity Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <5CC0BA6A-C507-11D7-91F1-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zaterdag, aug 2, 2003, at 11:26 Europe/Amsterdam, Tony Li wrote: > Well, you're already into developing a global policy language > for locators. Seems expensive. I believe that not having it will be more expensive in the long run. > If we don't proscribe or prescribe, then this is just left as an > implementation detail. Ok. > | ??? > Restated: if we don't have to distribute more/new/timely information > to support 'intelligent' locator selection, then we don't have to > make modifications to the routing subsystem and can defer all of > the 'magic'. This makes migration easier as even the simplest of > algorithms can be used initially to select locators and can then > become more sophisticated as time progresses. > Put yet another way: let's remove the complexity of locator selection. > If simplistic turns out to be insufficient, then let's at least take > out fancy information distribution and be a bit nearer perfection. I don't think that's good enough. Today having multiple addresses from different ISPs doesn't work if the ISP does ingress filtering. To solve this, we need to be able to change addresses for existing sessions, and we need to figure out the right source address reasonably fast. But we also need to figure out the right destination address pretty quickly or publishing addresses that may not be reachable (for everyone) becomes too expensive. This is an integral part of the multihoming package so we must deliver on it. From owner-multi6@ops.ietf.org Sat Aug 2 14:06:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17923 for ; Sat, 2 Aug 2003 14:06:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19j0jl-000GEJ-D8 for multi6-data@psg.com; Sat, 02 Aug 2003 18:04:13 +0000 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 4.20) id 19j0jj-000GE7-3d for multi6@ops.ietf.org; Sat, 02 Aug 2003 18:04:11 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 8984323C64; Sat, 2 Aug 2003 10:14:41 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h72I4AYB012187; Sat, 2 Aug 2003 11:04:10 -0700 (PDT) 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: Identification, layering, transactions and universal connectivity Date: Sat, 2 Aug 2003 11:04:10 -0700 Message-ID: Thread-Topic: Identification, layering, transactions and universal connectivity Thread-Index: AcNZFChfc78IAG5xT/i+TW6/qtVBlgACsE9A From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable | I don't think that's good enough. Today having multiple=20 | addresses from=20 | different ISPs doesn't work if the ISP does ingress=20 | filtering. To solve=20 | this, we need to be able to change addresses for existing=20 | sessions, and=20 | we need to figure out the right source address reasonably=20 | fast. But we=20 | also need to figure out the right destination address=20 | pretty quickly or=20 | publishing addresses that may not be reachable (for=20 | everyone) becomes=20 | too expensive. This is an integral part of the multihoming=20 | package so=20 | we must deliver on it. Good point. I consider that to be a different problem, however: insuring that the packet departs via the ISP matching the source locator. We'd really like routing to choose the right ISP once the host has chosen its source locator. Unfortunately, we don't have a great deal of control. Most enterprises simply have an internal default that points 'thataway' and may or may not fail over when an SBR or its link fails. [Aside: solving this with the 'little' proposal was actually a bit easier. The SBR simply changed the locator to match the ISP as the packet exited.] A simple approach here would be to give the host a 'hint' as to the source locator preference. These hints would be set up so that they match the most common state of routing, but would allow a host to rotate amongst its locators. For the destination locator, I see only one tractable solution. Since we're already doing a lookup to get the locators, we could also publish a 'hint' about the order that the source should try destination locators. By analogy, look what we do for preferences of mail servers in MX records. =20 Will this suffice? Tony From owner-multi6@ops.ietf.org Sat Aug 2 16:25:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21440 for ; Sat, 2 Aug 2003 16:25:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19j2sq-000Mn7-93 for multi6-data@psg.com; Sat, 02 Aug 2003 20:21:44 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.20) id 19j2sm-000Mmv-US for multi6@ops.ietf.org; Sat, 02 Aug 2003 20:21:40 +0000 Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250](untrusted sender)) by comcast.net (rwcrmhc13) with SMTP id <2003080220213701500oatt0e> (Authid: sdawkins@comcast.net); Sat, 2 Aug 2003 20:21:37 +0000 Message-ID: <12af01c35933$af654680$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: Subject: Re: Identification, layering, transactions and universal connectivity Date: Sat, 2 Aug 2003 15:21:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-6.5 required=5.0 tests=REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Iljitsch/Tony, You're both chewing on something that seems important - in today's systems, a lot of the experimenting goes into applications. Or "doesn't go into applications", to be more precise. My understanding of the Late Unpleasantness on site-local was that at least some of the problem wasn't that applications couldn't figure out what addresses to use, given time and failures to motivate more experiments, it was that we had decades of applications that didn't try to figure out another address when a failure occured. (Please correct me if I'm confused here). (1) At the recent IAB workshop on addressing, I watched several speakers who COULD have used the phrase "session layer" not do so, and I'm still trying to figure out whether this is a religious choice or a technical choice. But at least some of what we're taking about has been described as a "session layer" that survives transitions in transport connections. (2) At that workshop, I noted that I'm hearing more and more people talking about applications that were making interface selections (based on what? from Iljitsch's original note, but I digress), so that applications want to switch from GPRS to 802.11 when 802.11 becomes available, etc. My concern here is that if we do as Tony (correctly, I think) suggests and find some way to perform these selections below the application level, we may find that applications that learned how to make these selections will still want to do so - I'm using the NAT analogy, where one might make the case that NAT made sense in IPv4 "but now you can get rid of your NATs in IPv6", except that network administrators STILL want NATs in IPv6, because that's the way they do things now... (3) I also note that failed experiments are more painful in some environments than in others, and are especially painful in high-latency environments. If you get back an ICMP Unreachable message in 50 ms, that's one view of the world. If you take 600-800 ms to set up a GPRS uplink channel for each experiment, that's another view of the world. I hear what Tony is saying about the difficulty of "knowing without experimenting", but I also hear what Iljitsch is saying about how nice it is when we can have enough of a clue to prune some experiments off the decision tree a priori... Spencer p.s. How off-topic is this thread for multi6? ----- Original Message ----- From: "Tony Li" To: "Iljitsch van Beijnum" Cc: Sent: Saturday, August 02, 2003 4:26 AM Subject: RE: Identification, layering, transactions and universal connectivity | Yes. But the question is: do we want to go evaluate connectivity | properties for half a dozen round trips before we do | anything, do we | choose something and go with it until we notice it doesn't work so | well, or do we combine these by starting the communication | immediately | using one address pair and then evaluate connectivity in | the background? If we don't proscribe or prescribe, then this is just left as an implementation detail. | How much magic do we need in the application to enable this | differentiation? Or in the kernel. It depends on whether or not you're willing to add to the API. If you're willing to say, make it a socket option, then all of it just goes in the kernel once. From owner-multi6@ops.ietf.org Sat Aug 2 17:01:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22155 for ; Sat, 2 Aug 2003 17:01:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19j3Tl-000OgZ-AJ for multi6-data@psg.com; Sat, 02 Aug 2003 20:59:53 +0000 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 4.20) id 19j3Tj-000OgN-IG for multi6@ops.ietf.org; Sat, 02 Aug 2003 20:59:51 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 2AB8C23C63; Sat, 2 Aug 2003 13:10:16 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h72KxiYB015355; Sat, 2 Aug 2003 13:59:44 -0700 (PDT) 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: Identification, layering, transactions and universal connectivity Date: Sat, 2 Aug 2003 13:59:44 -0700 Message-ID: Thread-Topic: Identification, layering, transactions and universal connectivity Thread-Index: AcNZNY8suUx1rLV7QLS+dpbj19nXCwAA0qbQ From: "Tony Li" To: "Spencer Dawkins" , X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable One note: multiple experiments can be performed in parallel, if the host is willing to devote the resources and complexity to it. This can be used=20 to hide the latency of experimenting. Tony From owner-multi6@ops.ietf.org Sun Aug 3 18:24:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29430 for ; Sun, 3 Aug 2003 18:24:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19jRDl-000JVb-Fi for multi6-data@psg.com; Sun, 03 Aug 2003 22:20:57 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.20) id 19jRDg-000JVN-St for multi6@ops.ietf.org; Sun, 03 Aug 2003 22:20:53 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h73MLLxS035254; Mon, 4 Aug 2003 00:21:22 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 4 Aug 2003 00:20:44 +0200 Subject: Re: Identification, layering, transactions and universal connectivity Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Spencer Dawkins" From: Iljitsch van Beijnum In-Reply-To: <12af01c35933$af654680$0400a8c0@DFNJGL21> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-25.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zaterdag, aug 2, 2003, at 22:21 Europe/Amsterdam, Spencer Dawkins wrote: > My understanding of the Late Unpleasantness on site-local > was that at least some of the problem wasn't that applications > couldn't figure out what addresses to use, given time and > failures to motivate more experiments, it was that we had > decades of applications that didn't try to figure out another > address when a failure occured. (Please correct me if I'm > confused here). That is one argument against this. But I think the really bad problem here is that once something goes into the general application populace, it becomes essentially impossible to get rid of it so when something better is developed later, the old way of doing it must be supported for *many* years. > (1) At the recent IAB workshop on addressing, I watched > several speakers who COULD have used the phrase > "session layer" not do so, and I'm still trying to figure out > whether this is a religious choice or a technical choice. But > at least some of what we're taking about has been described > as a "session layer" that survives transitions in transport > connections. A session layer is an interesting idea. But I don't think there is any agreement on what such a new layer should look like. Myself, I think IPsec already took us halfway there by introducing a negotiation mechanism for security associations. We could generalize this to encompass other features as well, such as address agility. But first we have to get rid of the limitation that you must negotiate with the other end directly, as this leads to security problems and it isn't flexible enough. > (2) At that workshop, I noted that I'm hearing more and > more people talking about applications that were making > interface selections (based on what? from Iljitsch's original > note, but I digress), so that applications want to switch from > GPRS to 802.11 when 802.11 becomes available, etc. My > concern here is that if we do as Tony (correctly, I think) > suggests and find some way to perform these selections > below the application level, we may find that applications > that learned how to make these selections will still want to > do so So where is this huge list of applications that do this today? > I'm using the NAT analogy, where one might make > the case that NAT made sense in IPv4 "but now you can > get rid of your NATs in IPv6", except that network > administrators STILL want NATs in IPv6, because that's > the way they do things now... For this particular use NAT doesn't help at all as sessions still break. > (3) I also note that failed experiments are more painful in > some environments than in others, and are especially painful > in high-latency environments. If you get back an ICMP > Unreachable message in 50 ms, that's one view of the > world. If you take 600-800 ms to set up a GPRS uplink > channel (Aaargghh, 600 ms, who told those bellhead halfwits they were allowed to create data protocols in the first place?!?) > for each experiment, that's another view of the > world. I hear what Tony is saying about the difficulty of > "knowing without experimenting", but I also hear what > Iljitsch is saying about how nice it is when we can > have enough of a clue to prune some experiments off > the decision tree a priori... If the GPRS link terminates not on a router but on the host itself (which would be the usual case here) there shouldn't be much of a problem: if the application specifically asks for "high delay, low throughput, low reliability, high cost" then we look at addresses tied to the GRPS link. If not, we only try this after everything else has failed. But Tony's hint system, along with some knowledge of link characteristics, would be good enough to get us started. We should leave some stuff to work on for the next generation of protocol designers and implementers. :-) > p.s. How off-topic is this thread for multi6? There doesn't seem any other place where it is on topic, though... Wasn't the IAB going to create a list? From owner-multi6@ops.ietf.org Wed Aug 6 11:12:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20438 for ; Wed, 6 Aug 2003 11:12:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kPuv-0008vj-Hf for multi6-data@psg.com; Wed, 06 Aug 2003 15:09:33 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.20) id 19kPuq-0008ur-6t for multi6@ops.ietf.org; Wed, 06 Aug 2003 15:09:28 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 9ACAE1C; Wed, 6 Aug 2003 18:18:56 +0300 (EEST) Message-ID: <3F311A23.2030403@nomadiclab.com> Date: Wed, 06 Aug 2003 18:09:23 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: marcelo bagnulo , multi6@ops.ietf.org Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Slowly catching up some old e-mail] Pekka Nikander wrote: >> What comes to crypto binding, I am only aware of two possibilities: >> Using asymmetric keys (or something similar) as primary identifiers, >> or using CGA (or something similar). All the other solutions that >> I know about require some kind of infrastructure, some kind of >> an enrollment procedure, or both. Erik Nordmark wrote: > I guess I don't really understand your categorization. Maybe I have to set up some context for the statement of mine above. Firstly, my understanding is that we are still discussing the proposed identifier/locator separation. There are certainly several possible ways of achieving the separation, some of which involve existing higher level identifiers. However, I tend to think more in the line of just "splitting" the IP address roles, and perhaps introducing a new name space for the identifiers. Secondly, the question at hand was how to secure a binding between a given identifier and a set of locators. (There are documents that include descriptions of at least some of the threats involved, see draft-nikander-mobileip-v6-ro-sec-01.txt and draft-nikander-hip-mm-00.txt) Now, for making secure the binding between the identifiers (entities that applications use to denote their peers) and the locators (routing location identifiers), I am aware of two basic mechanisms: A. return routability (RR) B. cryptographic binding between the locators and identifiers Return routability, with its built in cryptographic challenge- response protocol, basically provides assurance that a single party is reachable with the given set of locators. From this point of view, the reachable party remains anonymous. That is, the RR procedure does not give the identifier any (other) semantic meaning, e.g., there is no assurance that the party is the same one than during the previous "session". The only assurance gained is about the time-restricted "sameness" (identity) of the peer. Cryptographic binding, on the other hand, is able to create something different. It provides assurance that the identifier and the locator *somehow* belong together. Now, the very question is the exact nature of that "somehow". There I am aware of three options: B1. CGA. In the case of CGA, the locator (IP address) acts (still) as a primary "identifier" in some sense. That is, given an IP address and a public key, one can be sure that the holder of the private key corresponding to the public key wants to use that particular IP address, and that (with high probability) no-one else can claim the same (i.e. the desire to use that IP address). CGA has the drawback that it requires that everybody is using CGA, or at least that those using CGA are given preference over those that do not use CGA. B2. Using asymmetric keys as primary identifiers (e.g. HIP). Here the public key of an asymmetric key pair acts as the primary identifier. It is fairly simple to check that the private key corresponding to a given public key is "reachable" at any given point of time. Here it must be understood that a public key (or a crypto- graphic hash of a public key) is a perfectly fine identifier for computers. There is still a need to map human readable names to public key identifiers, but that is a separate problem, and IMHO outside the scope of this discussion. B3. Relying on an external public key infrastructure, providing external assurance for the binding between the identifier and the locators. There are two subcases: Firstly, one can bind the identifier to a public key (as in a PKI), and then use procedures similar to B2. Secondly, one can bind the identifier directly to a set of locators. The properties of these are fairly well understood in the general case, and there is no need to repeat them here. It is noteworthy that in B1 and B2 the publicly known identifier (IP address or public key) is constructed in such a way - that there is a corresponding secret piece of information, - that deriving the secret piece of information from the public identifier is believed to be computationally infeasible, and - that it is (fairly) easy to prove the possession of the secret information without revealing it. CGA and using PKs as primary identifiers are not the only possibilities; there are others. However, as far as I know they all rely on the same computational principles, and are structurally more or less similar. The biggest difference is between B1/2 vs. B3. In the B3 case the primary identifier has no cryptograhic properties. In both B1 and B2 it *is* cryptographically constructed. Erik Nordmark wrote: > If one wants to have the IP packets be bound to some existing identity > (like something one would find in a PKI: subject-name erik.nordmar@sun.com > with some particular trust anchor) then one would always need something > at least approximating a PKI. As I tried to explain above, all depends on the nature of the identifier. If the identifier itself carries cryptographic properties, we can do without any external infrastructure. We just rely on the computational complexity of someone being able to construct the necessary secret piece of information. In my view, identity is independent of the identifier. Hence, even if we want to identify existing identities, we can fabricate a new set of primary identifiers for them. That would turn the currently used identifiers as plain names (or secondary identifiers), and there is certainly a need to securely provide the new primary identifier for every existing name. However, that could be a one-time operation, and all new identities could be primarily identified with the new identifiers. Returning to the context set up in the beginning, any existing (upper layer) identifiers are mostly beyond the scope. Even today we need a secure mapping from the upper layer identifiers to IP addresses. If we replace that mapping with a mapping from upper layer identifiers to primary, cryptographic identifiers, the change is small. The real problem is the binding from the primary identifiers to the locators. That is something new, and needs to be secured. > If one is only concerned about the IP packets be bound to some ephemeral > (and meaningless to higher level protocols?) identity than one can either > have the primary identifier be variable length (e.g. a public key; > a (self-signed) certificate), or fixed length (e.g. a hash of a public key > or a hash of a (self-signed) certificate). > That still allows the identifiers to be long-term stable, as well as new > identifiers being fabricated on the fly to get "anonymity". Well, I don't see why the identity identified by such a primary identifier needs to be somehow ephemeral. I do agree that it is then easy to fabricate identifiers, but if one uses a given identifier consistently over a long period of time, I would not call it ephemeral. Secondly, it is always possible to use any given external infrastructure to provide additional semantics for the identifiers. That is, one can (and probably should) use a PKI (or secure DNS) to provide additional properties for the primary identifiers. However, any such infrastructure could be (and should be) architecturally distinct from the binding between the primary identifier and the locators. > Finally, if one only is concerned about being able to verify that some IP > packet is sent by the same entity that sent some previous IP packet, then > PBK type approaches would seem to fit (e.g. do an anonymous DH exchange up > front and use the resulting key to protect changes to the id/loc mapping.) Overall, I think that we need to understand here the temporal and spatial (topological) properties of various (weak) cryptographic protocols. Our 2002 Cambridge Security Protocols Workshop paper discusses that point-of-view in some length. We are currently turning that paper into an Internet-Draft for easier access. --Pekka Nikander From owner-multi6@ops.ietf.org Wed Aug 6 13:24:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25516 for ; Wed, 6 Aug 2003 13:24:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kRzi-000Hhr-OC for multi6-data@psg.com; Wed, 06 Aug 2003 17:22:38 +0000 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 4.20) id 19kRzg-000Hgh-26 for multi6@ops.ietf.org; Wed, 06 Aug 2003 17:22:36 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id E2E0423C59 for ; Wed, 6 Aug 2003 09:32:58 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h76HMZYB009084 for ; Wed, 6 Aug 2003 10:22:35 -0700 (PDT) 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: Consensus on identifier/locator split? Date: Wed, 6 Aug 2003 10:22:35 -0700 Message-ID: Thread-Topic: Consensus on identifier/locator split? Thread-Index: AcNcP1OvbzWv7KXSQhCjNqxLT+aKLw== From: "Tony Li" To: X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Folks, I don't mean to disrupt other constructive conversations, so please carry on with those. I'd just like to get a sense from the group about where we are so far. Do we have consensus about splitting the address into locators and identifiers? Note that I'm NOT asking about specifics, like "how big", "what mappings exist", "is it secure", etc. Do we agree that we want to go down this path? Silence is not assent... Thanks, Tony From owner-multi6@ops.ietf.org Wed Aug 6 13:29:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25711 for ; Wed, 6 Aug 2003 13:29:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kS5z-000I5z-0F for multi6-data@psg.com; Wed, 06 Aug 2003 17:29:07 +0000 Received: from [130.85.25.12] (helo=mx3out.umbc.edu) by psg.com with esmtp (Exim 4.20) id 19kS5w-000I5k-HQ for multi6@ops.ietf.org; Wed, 06 Aug 2003 17:29:04 +0000 Received: from irix2.gl.umbc.edu (guest@irix2.gl.umbc.edu [130.85.60.11]) by mx3out.umbc.edu (8.12.8/8.12.8/UMBC-Central 1.11 mxout 1.2.2.3 $) with ESMTP id h76HT000025865; Wed, 6 Aug 2003 13:29:00 -0400 (EDT) Received: from localhost (vijay@localhost) by irix2.gl.umbc.edu (8.12.8/8.12.8) with ESMTP id h76HT03D174982; Wed, 6 Aug 2003 13:29:00 -0400 (EDT) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Wed, 6 Aug 2003 13:28:59 -0400 From: Vijay Gill X-X-Sender: vijay@irix2.gl.umbc.edu To: Tony Li cc: multi6@ops.ietf.org Subject: Re: Consensus on identifier/locator split? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-AvMilter-Key: 1060191241:de9981b9480ed5f28725c605bc54255d X-Avmilter: Message Skipped, too small X-Processed-By: MilterMonkey Version 0.9 -- http://www.membrain.com/miltermonkey X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTE_TWICE_1, USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 6 Aug 2003, Tony Li wrote: > > Folks, > > I don't mean to disrupt other constructive conversations, > so please carry on with those. > > I'd just like to get a sense from the group about where > we are so far. Do we have consensus about splitting > the address into locators and identifiers? Note that I believe we should. /vijay From owner-multi6@ops.ietf.org Wed Aug 6 13:46:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26430 for ; Wed, 6 Aug 2003 13:46:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kSMY-000JVy-9l for multi6-data@psg.com; Wed, 06 Aug 2003 17:46:14 +0000 Received: from [208.184.15.238] (helo=EXECDSL.COM) by psg.com with esmtp (Exim 4.20) id 19kSMW-000JVl-5X for multi6@ops.ietf.org; Wed, 06 Aug 2003 17:46:12 +0000 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5164238 for multi6@ops.ietf.org; Wed, 06 Aug 2003 13:46:11 -0400 Message-Id: <5.1.0.14.0.20030806134427.0264e4d8@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Aug 2003 13:45:02 -0400 To: multi6@ops.ietf.org From: "Joel M. Halpern" Subject: Re: Consensus on identifier/locator split? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-9.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Yes, I think we should go down the path of explicitly splitting locators and identifiers. Yours, Joel M. Halpern t 10:22 AM 8/6/2003 -0700, Tony Li wrote: >Folks, > >I don't mean to disrupt other constructive conversations, >so please carry on with those. > >I'd just like to get a sense from the group about where >we are so far. Do we have consensus about splitting >the address into locators and identifiers? Note that >I'm NOT asking about specifics, like "how big", "what >mappings exist", "is it secure", etc. Do we agree that >we want to go down this path? > >Silence is not assent... > >Thanks, >Tony From owner-multi6@ops.ietf.org Wed Aug 6 14:12:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27695 for ; Wed, 6 Aug 2003 14:12:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kSlV-000LQJ-KE for multi6-data@psg.com; Wed, 06 Aug 2003 18:12:01 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.20) id 19kSlT-000LQ7-Cf for multi6@ops.ietf.org; Wed, 06 Aug 2003 18:11:59 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 11:12:01 -0700 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Aug 2003 11:12:05 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 11:11:51 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 11:11:31 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 11:11:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus on identifier/locator split? Date: Wed, 6 Aug 2003 11:07:20 -0700 Message-ID: Thread-Topic: Consensus on identifier/locator split? Thread-Index: AcNcP1OvbzWv7KXSQhCjNqxLT+aKLwABkCkC From: "Christian Huitema" To: "Tony Li" , X-OriginalArrivalTime: 06 Aug 2003 18:11:59.0309 (UTC) FILETIME=[3A5C27D0:01C35C46] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I'd just like to get a sense from the group about where > we are so far. Do we have consensus about splitting > the address into locators and identifiers? Note that > I'm NOT asking about specifics, like "how big", "what > mappings exist", "is it secure", etc. Do we agree that > we want to go down this path? No, I don't believe we have this consensus. Specifically, we don't have = a consensus that a new category of identifiers should be created, and = that this new category should be used by all applications and processed = by all nodes. We also definitely don't have a consensus that any such = identifiers should be visible "in the network", by opposition to say, = session identifiers that are only visible end-to-end. =20 -- Christian Huitema From owner-multi6@ops.ietf.org Wed Aug 6 14:16:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27821 for ; Wed, 6 Aug 2003 14:16:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kSpX-000LjW-Ax for multi6-data@psg.com; Wed, 06 Aug 2003 18:16:11 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.20) id 19kSpV-000LjJ-40 for multi6@ops.ietf.org; Wed, 06 Aug 2003 18:16:09 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 1FAB0344AF; Wed, 6 Aug 2003 11:09:45 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h76IG8YB010919; Wed, 6 Aug 2003 11:16:08 -0700 (PDT) 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: Consensus on identifier/locator split? Date: Wed, 6 Aug 2003 11:16:08 -0700 Message-ID: Thread-Topic: Consensus on identifier/locator split? Thread-Index: AcNcP1OvbzWv7KXSQhCjNqxLT+aKLwABkCkCAAA1PlA= From: "Tony Li" To: "Christian Huitema" , X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Christian, =20 You're getting specific on me and I was trying to stay at the broad architectural level, in the hopes of making baby steps forward. Is there some version of the identifier/locator split that you WOULD agree to? Tony | -----Original Message----- | From: Christian Huitema [mailto:huitema@windows.microsoft.com]=20 | Sent: Wednesday, August 06, 2003 11:07 AM | To: Tony Li; multi6@ops.ietf.org | Subject: RE: Consensus on identifier/locator split? | =20 | =20 | > I'd just like to get a sense from the group about where | > we are so far. Do we have consensus about splitting | > the address into locators and identifiers? Note that | > I'm NOT asking about specifics, like "how big", "what | > mappings exist", "is it secure", etc. Do we agree that | > we want to go down this path? | =20 | No, I don't believe we have this consensus. Specifically,=20 | we don't have a consensus that a new category of=20 | identifiers should be created, and that this new category=20 | should be used by all applications and processed by all=20 | nodes. We also definitely don't have a consensus that any=20 | such identifiers should be visible "in the network", by=20 | opposition to say, session identifiers that are only=20 | visible end-to-end. | =20 | -- Christian Huitema | =20 From owner-multi6@ops.ietf.org Wed Aug 6 14:17:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27918 for ; Wed, 6 Aug 2003 14:17:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kSqy-000Lrj-DB for multi6-data@psg.com; Wed, 06 Aug 2003 18:17:40 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.20) id 19kSqv-000LrW-B8 for multi6@ops.ietf.org; Wed, 06 Aug 2003 18:17:38 +0000 Received: from cisco.com ([128.107.176.152]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h76IHZ7F001478; Wed, 6 Aug 2003 11:17:35 -0700 (PDT) Message-ID: <3F31463E.4000908@cisco.com> Date: Wed, 06 Aug 2003 11:17:34 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: multi6@ops.ietf.org Subject: Re: Consensus on identifier/locator split? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't know whether we have consensus but I think it's a good idea. Eliot From owner-multi6@ops.ietf.org Wed Aug 6 14:42:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29039 for ; Wed, 6 Aug 2003 14:42:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kTDt-000Nck-O3 for multi6-data@psg.com; Wed, 06 Aug 2003 18:41:21 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.20) id 19kTDq-000NcD-Kx for multi6@ops.ietf.org; Wed, 06 Aug 2003 18:41:18 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 11:39:57 -0700 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Aug 2003 11:39:52 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 11:39:53 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 11:38:22 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 11:39:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus on identifier/locator split? Date: Wed, 6 Aug 2003 11:35:18 -0700 Message-ID: Thread-Topic: Consensus on identifier/locator split? Thread-Index: AcNcP1OvbzWv7KXSQhCjNqxLT+aKLwABkCkCAAA1PlAAAMTGFg== From: "Christian Huitema" To: "Tony Li" , X-OriginalArrivalTime: 06 Aug 2003 18:39:56.0933 (UTC) FILETIME=[224D4350:01C35C4A] X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > You're getting specific on me and I was trying to stay at the > broad architectural level, in the hopes of making baby steps > forward. Is there some version of the identifier/locator > split that you WOULD agree to? =20 I believe the question cannot be resolved in a general sense, and = specifically not if you ask for a "locator/identifier split", which by = its very wording is tied to the Internet Protocol layer. If you are = going to change the IP protocol, then you should move the debate to the = IPv6 working group. The proper way for multi6 to proceed is to evaluate = a set of possibilities, and to look at the operational issues associated = with the different possibilities. =20 -- Christian Huitema =20 From owner-multi6@ops.ietf.org Wed Aug 6 17:04:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04850 for ; Wed, 6 Aug 2003 17:04:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kVQS-0007Uz-RU for multi6-data@psg.com; Wed, 06 Aug 2003 21:02:28 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.20) id 19kVQP-0007Uh-IQ for multi6@ops.ietf.org; Wed, 06 Aug 2003 21:02:25 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h76L2qxS080455; Wed, 6 Aug 2003 23:02:52 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 6 Aug 2003 23:02:21 +0200 Subject: Re: Consensus on identifier/locator split? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Christian Huitema" , To: "Tony Li" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <45513406-C851-11D7-9FEB-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, aug 6, 2003, at 20:16 Europe/Amsterdam, Tony Li wrote: > Christian, > You're getting specific on me and I was trying to stay at the > broad architectural level, in the hopes of making baby steps > forward. Is there some version of the identifier/locator > split that you WOULD agree to? I would like to note at this point that consensus isn't the same as unanimity, and rough consensus certainly isn't. I agree that we should follow the loc/id split path. If this path leads to a dead end, that's unfortunate, but still a very valuable result if we document it well. From owner-multi6@ops.ietf.org Wed Aug 6 17:15:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05215 for ; Wed, 6 Aug 2003 17:15:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kVc5-0008HP-C4 for multi6-data@psg.com; Wed, 06 Aug 2003 21:14:29 +0000 Received: from [4.65.19.240] (helo=tndh.net) by psg.com with esmtp (Exim 4.20) id 19kVc2-0008H4-U5 for multi6@ops.ietf.org; Wed, 06 Aug 2003 21:14:27 +0000 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 06 Aug 2003 14:14:21 -0700 From: "Tony Hain" To: "'Tony Li'" , Subject: RE: Consensus on identifier/locator split? Date: Wed, 6 Aug 2003 14:14:00 -0700 Message-ID: <041901c35c5f$aa0d4230$70144104@eagleswings> 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, Build 10.0.4510 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would say there is consensus that splitting would solve several problems, but I wouldn't go so far to say there is consensus that it is the right approach. Fundamentally, splitting amounts to rearchitecting the Internet since many current assumptions would be invalidated. While this is a fine thing for an IRTF wg to take on, an IETF Ops WG should be focused on realistic things that can be done in our working lifetimes. Tony > -----Original Message----- > From: owner-multi6@ops.ietf.org > [mailto:owner-multi6@ops.ietf.org] On Behalf Of Tony Li > Sent: Wednesday, August 06, 2003 10:23 AM > To: multi6@ops.ietf.org > Subject: Consensus on identifier/locator split? > > > > Folks, > > I don't mean to disrupt other constructive conversations, > so please carry on with those. > > I'd just like to get a sense from the group about where > we are so far. Do we have consensus about splitting > the address into locators and identifiers? Note that > I'm NOT asking about specifics, like "how big", "what > mappings exist", "is it secure", etc. Do we agree that > we want to go down this path? > > Silence is not assent... > > Thanks, > Tony > From owner-multi6@ops.ietf.org Wed Aug 6 17:25:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05608 for ; Wed, 6 Aug 2003 17:25:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kVmY-0008zZ-Ne for multi6-data@psg.com; Wed, 06 Aug 2003 21:25:18 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.20) id 19kVmV-0008zI-Om for multi6@ops.ietf.org; Wed, 06 Aug 2003 21:25:15 +0000 Received: from cisco.com (dhcp-171-71-119-135.cisco.com [171.71.119.135]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h76LPDuG026689; Wed, 6 Aug 2003 14:25:13 -0700 (PDT) Message-ID: <3F317238.8020802@cisco.com> Date: Wed, 06 Aug 2003 14:25:12 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Hain CC: "'Tony Li'" , multi6@ops.ietf.org Subject: Re: Consensus on identifier/locator split? References: <041901c35c5f$aa0d4230$70144104@eagleswings> In-Reply-To: <041901c35c5f$aa0d4230$70144104@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Hain wrote: > I would say there is consensus that splitting would solve several problems, > but I wouldn't go so far to say there is consensus that it is the right > approach. Fundamentally, splitting amounts to rearchitecting the Internet > since many current assumptions would be invalidated. While this is a fine > thing for an IRTF wg to take on, an IETF Ops WG should be focused on > realistic things that can be done in our working lifetimes. We (the NSRG) looked at this, albeit obliquely. While there was not even rough consensus as to results, there are several possible alternatives that we discussed. How developed should a solution be before it hits the IETF? HIP has implementations as does MIPv6. There are some limitations to MIPv6 that Christian has done a good job of both illuminating and attempting to provide some answers to. So it seems to me that the iEtf is well suited to look at the problem at this point in time, so long as the ieSG understands that the results will hit multiple working groups. Trying to do this in isolation from the rest of the IETF would be silly. Eliot From owner-multi6@ops.ietf.org Wed Aug 6 17:56:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06678 for ; Wed, 6 Aug 2003 17:56:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kWGM-000BFm-3K for multi6-data@psg.com; Wed, 06 Aug 2003 21:56:06 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.20) id 19kWGJ-000BFW-FU for multi6@ops.ietf.org; Wed, 06 Aug 2003 21:56:03 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h76LuRxS081047; Wed, 6 Aug 2003 23:56:27 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 6 Aug 2003 23:55:56 +0200 Subject: Re: Consensus on identifier/locator split? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Eliot Lear From: Iljitsch van Beijnum In-Reply-To: <3F317238.8020802@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, aug 6, 2003, at 23:25 Europe/Amsterdam, Eliot Lear wrote: > So it seems to me that the iEtf is well suited to look at the problem > at this point in time, so long as the ieSG understands that the > results will hit multiple working groups. Trying to do this in > isolation from the rest of the IETF would be silly. I think the relevant other working groups and the IAB (hopefully the IESG too) are well aware that we're looking at this in multi6. At least the word "multi6" was mentioned several times in the open IAB thing and ipv6/v6ops (somehow can't keep those straight) sessions. Let's first get a coherent draft on the table and then take it from there. From owner-multi6@ops.ietf.org Wed Aug 6 18:24:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08547 for ; Wed, 6 Aug 2003 18:24:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kWfn-000DAX-KN for multi6-data@psg.com; Wed, 06 Aug 2003 22:22:23 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.20) id 19kWfk-000DAK-I0 for multi6@ops.ietf.org; Wed, 06 Aug 2003 22:22:20 +0000 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 h76MMItU000455; Wed, 6 Aug 2003 18:22:18 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h76MMIh3000452; Wed, 6 Aug 2003 18:22:18 -0400 Date: Wed, 6 Aug 2003 18:22:18 -0400 From: "J. Noel Chiappa" Message-Id: <200308062222.h76MMIh3000452@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Consensus on identifier/locator split? Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Li" > Do we have consensus about splitting the address into locators and > identifiers? Note that I'm NOT asking about specifics, like "how big", > "what mappings exist", "is it secure", etc. Do we agree that we want to > go down this path? Tony, I'm a little unclear on what your initial question means. Do you mean: "splitting the 128-bit IPv6 address into two fields, N bits of locator and 128-N bits of identifier", or do you mean "split the concept of address into two separate concepts, locator and identifier"? Assuming the latter, I would like to re-make to everyone a point I tried to make previously, which is that *if you do certain things, you #are# separating location and identification*, whether you call it that or not. For instance, if you want to i) keep TCP basically unchanged, and ii) be able to keep a TCP connection open while switching from one address to another, then you are, de facto, separating location and identification. (And as I keep pointing out, MIPv6 is another place that, de facto, separates location and identification.) So really the question should not be "do we want to separate location and identification", which in the IETF always turns into a big wrangle. Rather, a more productive question would be "do we want to support any capabilities that require separation of location and identification, such as keeping TCP connections open when switching from provider A to provider B". Noel From owner-multi6@ops.ietf.org Wed Aug 6 18:40:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08904 for ; Wed, 6 Aug 2003 18:40:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kWwQ-000EG3-2k for multi6-data@psg.com; Wed, 06 Aug 2003 22:39:34 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.20) id 19kWwM-000EFr-Mu for multi6@ops.ietf.org; Wed, 06 Aug 2003 22:39:31 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h76MdxxS081503; Thu, 7 Aug 2003 00:40:00 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 7 Aug 2003 00:39:28 +0200 Subject: Re: Consensus on identifier/locator split? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "J. Noel Chiappa" From: Iljitsch van Beijnum In-Reply-To: <200308062222.h76MMIh3000452@ginger.lcs.mit.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, aug 7, 2003, at 00:22 Europe/Amsterdam, J. Noel Chiappa wrote: > Rather, a more productive question would be "do we want to support any > capabilities that require separation of location and identification, > such as keeping TCP connections open when switching from provider A to > provider B". For mobility the answer is "yes". If it isn't acceptable for a single host to break TCP sessions when it moves around, I would expect the same for an entire site that stays in the same place. From owner-multi6@ops.ietf.org Wed Aug 6 18:40:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08924 for ; Wed, 6 Aug 2003 18:40:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kWwz-000EKT-Nw for multi6-data@psg.com; Wed, 06 Aug 2003 22:40:09 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.20) id 19kWwx-000EKD-DB for multi6@ops.ietf.org; Wed, 06 Aug 2003 22:40:07 +0000 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 h76Me5tU000572; Wed, 6 Aug 2003 18:40:05 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h76Me511000569; Wed, 6 Aug 2003 18:40:05 -0400 Date: Wed, 6 Aug 2003 18:40:05 -0400 From: "J. Noel Chiappa" Message-Id: <200308062240.h76Me511000569@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: Consensus on identifier/locator split? Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Christian Huitema" >> Do we have consensus about splitting the address into locators and >> identifiers? Note that I'm NOT asking about specifics, like "how big", >> "what mappings exist", "is it secure", etc. > Specifically, we don't have a consensus that a new category of > identifiers should be created, and that this new category should be > used by all applications and processed by all nodes. True, but that's not the question Tony is asking. If you have a problem with Tony's question, what's your answer to my reformulated question "do we want to do things that inherently separate location and identity, like keep TCP connections open when switching providers"? > We also definitely don't have a consensus that any such identifiers > should be visible "in the network", by opposition to say, session > identifiers that are only visible end-to-end. Another good question, and one I also believe Tony was putting off for now. Noel From owner-multi6@ops.ietf.org Wed Aug 6 19:08:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09692 for ; Wed, 6 Aug 2003 19:08:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kXNn-000GqY-1U for multi6-data@psg.com; Wed, 06 Aug 2003 23:07:51 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.20) id 19kXNk-000GqL-Q9 for multi6@ops.ietf.org; Wed, 06 Aug 2003 23:07:48 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h76N7mZ21458; Wed, 6 Aug 2003 16:07:48 -0700 X-mProtect: <200308062307> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.79, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8vVKqV; Wed, 06 Aug 2003 16:07:46 PDT Received: (from david@localhost) by iprg.nokia.com (8.11.2/8.11.2) id h76N7qh13986; Wed, 6 Aug 2003 16:07:52 -0700 Date: Wed, 6 Aug 2003 16:07:52 -0700 From: David Kessens To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: Consensus on identifier/locator split? Message-ID: <20030806160752.F12323@iprg.nokia.com> References: <45513406-C851-11D7-9FEB-00039388672E@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <45513406-C851-11D7-9FEB-00039388672E@muada.com>; from iljitsch@muada.com on Wed, Aug 06, 2003 at 11:02:21PM +0200 X-Spam-Status: No, hits=-35.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch, On Wed, Aug 06, 2003 at 11:02:21PM +0200, Iljitsch van Beijnum wrote: > On woensdag, aug 6, 2003, at 20:16 Europe/Amsterdam, Tony Li wrote: > > > Christian, > > > You're getting specific on me and I was trying to stay at the > > broad architectural level, in the hopes of making baby steps > > forward. Is there some version of the identifier/locator > > split that you WOULD agree to? > > I would like to note at this point that consensus isn't the same as > unanimity, and rough consensus certainly isn't. > > I agree that we should follow the loc/id split path. It's bit a hard to talk about a seperation while everybody seems to have a different definition of what that seperation could entail. It seems that the correct question to ask is whether people think it is useful if the designteam will go further on it's choosen path and come up with a more concrete proposal so that we have a chance to really evaluate a more fully baked proposal. I don't think there is consensus though that the designteam choices are the only possible route to a solution or that only one solution is the answer to the problem. We are still in a stage where other groups could work on quite different ideas and they are not well defined enough (yet) so that we are able to do a full analysis and make a final choice (if we even need to do that). David K. --- From owner-multi6@ops.ietf.org Wed Aug 6 19:13:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09786 for ; Wed, 6 Aug 2003 19:13:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kXSc-000HC5-5Q for multi6-data@psg.com; Wed, 06 Aug 2003 23:12:50 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.20) id 19kXSZ-000HBt-QU for multi6@ops.ietf.org; Wed, 06 Aug 2003 23:12:47 +0000 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 h76NCktU000805; Wed, 6 Aug 2003 19:12:46 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h76NCjGO000804; Wed, 6 Aug 2003 19:12:45 -0400 Date: Wed, 6 Aug 2003 19:12:45 -0400 From: "J. Noel Chiappa" Message-Id: <200308062312.h76NCjGO000804@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: Consensus on identifier/locator split? Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Christian Huitema" > I believe the question cannot be resolved in a general sense I don't agree. If you decide it's absolutely necessary to provide a capability which inherently separates location and identity (be it switching providers while keeping "connections" open - even if it's sessions, not classical TCP connections - or mobility, or whatever), they you *have* answered the question "in a general sense". Perhaps a more useful question is "do we want to provide one set of underlying architectural capabilities which can be used to provide separation of location and identity to a number of different "applications" - such as mobility, multi-homing, etc. > specifically not if you ask for a "locator/identifier split", which by > its very wording is tied to the Internet Protocol layer. Well, not really. I can easily imagine providing the "identification" part at another layer - e.g. as part of some sort of session thingy. However, if you want to keep the existing TCP (and I would think that's a good idea, if you want to try and keep within the bounds of what's vaguely feasible), then I suppose you have a point. Noel From owner-multi6@ops.ietf.org Thu Aug 7 00:15:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17036 for ; Thu, 7 Aug 2003 00:15:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kcAi-000Crl-5l for multi6-data@psg.com; Thu, 07 Aug 2003 04:14:40 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.20) id 19kcAf-000Cr9-6e for multi6@ops.ietf.org; Thu, 07 Aug 2003 04:14:37 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 21:14:36 -0700 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Aug 2003 21:14:36 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 21:13:31 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 21:14:33 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 21:14:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus on identifier/locator split? Date: Wed, 6 Aug 2003 21:14:38 -0700 Message-ID: Thread-Topic: Consensus on identifier/locator split? Thread-Index: AcNccVstoP/lbm8NQeeATzk+wEbmIAAJ5R1I From: "Christian Huitema" To: "J. Noel Chiappa" , Cc: X-OriginalArrivalTime: 07 Aug 2003 04:14:26.0712 (UTC) FILETIME=[63E42180:01C35C9A] X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > However, if you want to keep the existing TCP (and I would think = that's a > good idea, if you want to try and keep within the bounds of what's = vaguely > feasible), then I suppose you have a point. I am not sure that I want to keep the existing TCP, and in fact I wrote = a draft back in 1995 explaining how TCP could be rather simply upgraded = to make sure that connections can survive address changes. The trick is = simple: create an identifier inside TCP, and then associate several = addresses/locators to the connection. I actually like the fact that TCP = can see and manage "locators", because the transport is one of the best = places to maintain short term knowledge about the relative performance = of a specific path, and thus arbitrage between the various paths. The idea of an optional upgrade to TCP is interesting because it allows = hosts to "opt in" the new facility. I would expect that many hosts would = actually opt out, either because they only use short lived sessions and = thus don't care for an exceptional failure, or because their = applications know how to manage sessions and patch together multiple = connections. Indeed, this is a generic requirement for any identifier = scheme: hosts that don't see the point should be able to opt-out and not = bear the burden associated with the "layer of indirection." -- Christian Huitema=20 =20 From owner-multi6@ops.ietf.org Thu Aug 7 00:21:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17337 for ; Thu, 7 Aug 2003 00:21:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kcH9-000DGH-83 for multi6-data@psg.com; Thu, 07 Aug 2003 04:21:19 +0000 Received: from [3ffe:501:100c:d120::53] (helo=shonan.sfc.wide.ad.jp) by psg.com with esmtp (Exim 4.20) id 19kcH5-000DFF-D2 for multi6@ops.ietf.org; Thu, 07 Aug 2003 04:21:15 +0000 Received: from huez (L071225.ppp.dion.ne.jp [211.126.71.225]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 47CCA5D0B5 for ; Thu, 7 Aug 2003 13:21:13 +0900 (JST) Date: Thu, 7 Aug 2003 12:52:15 +0900 From: Thierry Ernst To: multi6@ops.ietf.org Subject: Re: Consensus on identifier/locator split? Message-Id: <20030807125215.3f09e7b5.ernst@sfc.wide.ad.jp> In-Reply-To: <200308062312.h76NCjGO000804@ginger.lcs.mit.edu> References: <200308062312.h76NCjGO000804@ginger.lcs.mit.edu> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-26.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > I believe the question cannot be resolved in a general sense > > I don't agree. If you decide it's absolutely necessary to provide a > capability which inherently separates location and identity (be it switching > providers while keeping "connections" open - even if it's sessions, not > classical TCP connections - or mobility, or whatever), they you *have* > answered the question "in a general sense". > Perhaps a more useful question is "do we want to provide one set of > underlying architectural capabilities which can be used to provide separation > of location and identity to a number of different "applications" - such as > mobility, multi-homing, etc. I would personally support that path, but is multi6 the right working group for a genenal purposed loc+id separation solution ? If the idea is to standardize a solution which can be used for multihoming, mobility, etc - (which I would like to see happening), I think it goes further than the multi6 charter. > > > specifically not if you ask for a "locator/identifier split", which by > > its very wording is tied to the Internet Protocol layer. > > Well, not really. I can easily imagine providing the "identification" part at > another layer - e.g. as part of some sort of session thingy. > > However, if you want to keep the existing TCP (and I would think that's a > good idea, if you want to try and keep within the bounds of what's vaguely > feasible), then I suppose you have a point. Thierry. From owner-multi6@ops.ietf.org Thu Aug 7 05:10:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05182 for ; Thu, 7 Aug 2003 05:10:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kgkO-0009gN-4E for multi6-data@psg.com; Thu, 07 Aug 2003 09:07:48 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.20) id 19kgkL-0009ft-4f for multi6@ops.ietf.org; Thu, 07 Aug 2003 09:07:45 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 5EF874323A; Thu, 7 Aug 2003 11:07:44 +0200 (CEST) Received: from lolo (lolo.it.uc3m.es [163.117.139.224]) by smtp01.uc3m.es (Postfix) with SMTP id 6C50099E73; Thu, 7 Aug 2003 11:07:43 +0200 (CEST) From: "marcelo bagnulo" To: "Tony Li" , Subject: RE: Consensus on identifier/locator split? Date: Sat, 7 Aug 2004 11:05:37 +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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, I think that a previous question that we may ask is whether we agree that we will use PA addresses (topologically meaningfull addresses) or we will assign PI addresses. If we choose to use PA addresses, then we need to have multiple PA addresses in multi-hmed environments, this implies that when a node A is communication with a multi-homed node, node A has to know that all the PA addresses belogn to the same mh node, so the location and id function are splitted at some level (IP, transport, application), because somewhere someone knows that multiple locators are linked to a sinlge entity. If we use PI addresses we only have a single address which accomplishes both the id and the loc fucntion so we don't have to split. So, the question fo me is, do we agree we will use multiple PA addresses in multi-homed environments? if so i would say we agree that the identifier function and the location function are splitted. Regards, marcelo PS: I know smoe are unconfortable with this PA PI terminology, please read as topology meaningfull and topology independent > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Tony Li > Enviado el: miercoles, 06 de agosto de 2003 19:23 > Para: multi6@ops.ietf.org > Asunto: Consensus on identifier/locator split? > > > > Folks, > > I don't mean to disrupt other constructive conversations, > so please carry on with those. > > I'd just like to get a sense from the group about where > we are so far. Do we have consensus about splitting > the address into locators and identifiers? Note that > I'm NOT asking about specifics, like "how big", "what > mappings exist", "is it secure", etc. Do we agree that > we want to go down this path? > > Silence is not assent... > > Thanks, > Tony > From owner-multi6@ops.ietf.org Thu Aug 7 05:48:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05744 for ; Thu, 7 Aug 2003 05:48:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19khN8-000Bs8-3i for multi6-data@psg.com; Thu, 07 Aug 2003 09:47:50 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.20) id 19khMx-000BrY-0n for multi6@ops.ietf.org; Thu, 07 Aug 2003 09:47:39 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h779m9xS088681; Thu, 7 Aug 2003 11:48:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 7 Aug 2003 11:47:37 +0200 Subject: Re: Consensus on identifier/locator split? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Christian Huitema" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <2DE131BC-C8BC-11D7-9FEB-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, aug 7, 2003, at 06:14 Europe/Amsterdam, Christian Huitema wrote: > create an identifier inside TCP, and then associate several > addresses/locators to the connection. I actually like the fact that > TCP can see and manage "locators", because the transport is one of the > best places to maintain short term knowledge about the relative > performance of a specific path, and thus arbitrage between the various > paths. Yes, this way I want it to happen too, for the cases where the transport is TCP. I believe that the current approach by the design team is compatible with this goal. > Indeed, this is a generic requirement for any identifier scheme: hosts > that don't see the point should be able to opt-out and not bear the > burden associated with the "layer of indirection." Obviously any and all mechanisms we come up with are going to be optional. The problem is that the usefulness of these mechanisms is probably something that differs more from application to application rather than from host to host and we must be able to make existing applications support it. From owner-multi6@ops.ietf.org Thu Aug 7 09:03:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10935 for ; Thu, 7 Aug 2003 09:03:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kkNp-000N5Q-Uo for multi6-data@psg.com; Thu, 07 Aug 2003 13:00:45 +0000 Received: from [194.196.100.235] (helo=d12lmsgate-2.de.ibm.com) by psg.com with esmtp (Exim 4.20) id 19kkNm-000N4i-Gb for multi6@ops.ietf.org; Thu, 07 Aug 2003 13:00:42 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h77D0e7o137972 for ; Thu, 7 Aug 2003 15:00:40 +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.5) with ESMTP id h77D0eBY250876 for ; Thu, 7 Aug 2003 15:00:40 +0200 Received: from zurich.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA32214 for ; Thu, 7 Aug 2003 15:00:39 +0200 Message-ID: <3F324D76.98A9975D@zurich.ibm.com> Date: Thu, 07 Aug 2003 15:00:38 +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: multi6@ops.ietf.org Subject: Re: Consensus on identifier/locator split? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-19.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My answer is yes, this is the way to go. In answer to Christian, I would comment that *everything* I say on this list is conditioned by sections 3.2.2 and 3.2.3 of draft-ietf-multi6-multihoming-requirements-07. That rather drastically limits the forms of id/loc split I am willing to contemplate, when we fly down from the 10,000 meter level of Tony's question. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK Tony Li wrote: > > Folks, > > I don't mean to disrupt other constructive conversations, > so please carry on with those. > > I'd just like to get a sense from the group about where > we are so far. Do we have consensus about splitting > the address into locators and identifiers? Note that > I'm NOT asking about specifics, like "how big", "what > mappings exist", "is it secure", etc. Do we agree that > we want to go down this path? > > Silence is not assent... > > Thanks, > Tony From owner-multi6@ops.ietf.org Thu Aug 7 09:16:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11168 for ; Thu, 7 Aug 2003 09:16:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kkcC-000Ny0-4x for multi6-data@psg.com; Thu, 07 Aug 2003 13:15:36 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.20) id 19kkc9-000Nxm-C0 for multi6@ops.ietf.org; Thu, 07 Aug 2003 13:15:33 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA02869 for ; Thu, 7 Aug 2003 14:15:31 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id OAA24212 for ; Thu, 7 Aug 2003 14:15:31 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h77DFVG23732 for multi6@ops.ietf.org; Thu, 7 Aug 2003 14:15:31 +0100 Date: Thu, 7 Aug 2003 14:15:31 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Consensus on identifier/locator split? Message-ID: <20030807131531.GD20233@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <3F324D76.98A9975D@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F324D76.98A9975D@zurich.ibm.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk I think this approach is one to attempt, though of course the where and how will take a while :) On Thu, Aug 07, 2003 at 03:00:38PM +0200, Brian E Carpenter wrote: > My answer is yes, this is the way to go. > > In answer to Christian, I would comment that *everything* > I say on this list is conditioned by sections 3.2.2 and 3.2.3 > of draft-ietf-multi6-multihoming-requirements-07. That > rather drastically limits the forms of id/loc split > I am willing to contemplate, when we fly down from > the 10,000 meter level of Tony's question. > > Brian > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK > > Tony Li wrote: > > > > Folks, > > > > I don't mean to disrupt other constructive conversations, > > so please carry on with those. > > > > I'd just like to get a sense from the group about where > > we are so far. Do we have consensus about splitting > > the address into locators and identifiers? Note that > > I'm NOT asking about specifics, like "how big", "what > > mappings exist", "is it secure", etc. Do we agree that > > we want to go down this path? > > > > Silence is not assent... > > > > Thanks, > > Tony From owner-multi6@ops.ietf.org Thu Aug 7 10:47:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17397 for ; Thu, 7 Aug 2003 10:47:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19km1n-0003cM-S1 for multi6-data@psg.com; Thu, 07 Aug 2003 14:46:07 +0000 Received: from [204.127.202.64] (helo=sccrmhc13.comcast.net) by psg.com with esmtp (Exim 4.20) id 19km1j-0003c3-PE for multi6@ops.ietf.org; Thu, 07 Aug 2003 14:46:03 +0000 Received: from dfnjgl21 (autoimage.com[216.62.6.129](untrusted sender)) by comcast.net (sccrmhc13) with SMTP id <2003080714460201600fq5cje> (Authid: sdawkins@comcast.net); Thu, 7 Aug 2003 14:46:02 +0000 Message-ID: <011d01c35cf2$a0975860$8100000a@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <200308062312.h76NCjGO000804@ginger.lcs.mit.edu> <20030807125215.3f09e7b5.ernst@sfc.wide.ad.jp> Subject: Re: Consensus on identifier/locator split? Date: Thu, 7 Aug 2003 09:45:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Thierry here, both in my personal support and my curiosity about the right place for the discussion to take place. On the other hand, - multi6 does have a charter that leads in this topic area, and - while an OPS area working group isn't the right place to do major protocol/ architecture changes, it's not a bad place to think about the impacts of those changes. Spencer ----- Original Message ----- From: "Thierry Ernst" To: Sent: Wednesday, August 06, 2003 10:52 PM Subject: Re: Consensus on identifier/locator split? > > I would personally support that path, but is multi6 the right working > group for a genenal purposed loc+id separation solution ? If the idea is > to standardize a solution which can be used for multihoming, mobility, > etc - (which I would like to see happening), I think it goes further > than the multi6 charter. From owner-multi6@ops.ietf.org Thu Aug 7 12:06:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20308 for ; Thu, 7 Aug 2003 12:06:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19knEp-0008fL-EK for multi6-data@psg.com; Thu, 07 Aug 2003 16:03:39 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.20) id 19knEm-0008f9-GK for multi6@ops.ietf.org; Thu, 07 Aug 2003 16:03:36 +0000 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 h77G3VtU006602; Thu, 7 Aug 2003 12:03:31 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h77G3RUR006600; Thu, 7 Aug 2003 12:03:27 -0400 Date: Thu, 7 Aug 2003 12:03:27 -0400 From: "J. Noel Chiappa" Message-Id: <200308071603.h77G3RUR006600@ginger.lcs.mit.edu> To: huitema@windows.microsoft.com, multi6@ops.ietf.org Subject: RE: Consensus on identifier/locator split? Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Christian Huitema" >> if you want to keep the existing TCP > I am not sure that I want to keep the existing TCP Well, either ways has pros and cons. From my position (which these days is purely architectural) I have no position on that particular question. I suspect that others, who weigh practicalities more highly, may not agree, but they should speak up for themselves. > create an identifier inside TCP, and then associate several > addresses/locators to the connection. I'll be mildly irritating by first pointing out that you separating location and identity there, too... :-) On a more serious note, whether or not you make identity, and the bindings from identity to location, a function of the transport layer (or perhaps even higher, maybe at some sort of session layer - which is what HTML does with cookies) is a good question. The pros of doing it at the higher layers are that i) you can add it a protocol at a time; and ii) that you can optimize each namespace/binding mechanism to the protocol which uses it. The cons of doing it at a higher layer are that i) you have to do over and over again for each protocol; ii) protocols which don't make themselves more complex by including these mechanisms lose those capabilities; iii) there is more archiectural/engineering complexity since basically the same mechanism will be repeated over and over again; iv) there is potentially more operational overhead since when an endpoint moves, if there is more than one protocol (or connection, if the mechanism's on a per-connection basis) to a correspondent host, each protocol (or connection) will have to be moved separately. Looking at all that, it seems to me, from an architectural point of view, to be wiser to put it somewhat lower down in the stack. YMMV if you take other considerations more highly. I don't know if MIPv6 made this kind of analysis, but they certainly wound up putting the identification/location split, and the binding mechanisms, at a low level, gaining the benefits listed above under "cons". > I actually like the fact that TCP can see and manage "locators", > because the transport is one of the best places to maintain short term > knowledge about the relative performance of a specific path, and thus > arbitrage between the various paths. I concur that location does need to be *visible* to higher layers, and they need the *ability* to manage it *if they chose*. Of course, many applications may not care, and may not want the responsibility, so some "default" behaviour needs to be provided for them. > The idea of an optional upgrade to TCP is interesting because it allows > hosts to "opt in" the new facility. I would expect that many hosts > would actually opt out, either because they only use short lived > sessions and thus don't care for an exceptional failure, or because > their applications know how to manage sessions and patch together > multiple connections. Yes, but this is true whether one puts the identification/location split, and the binding mechanisms, at a high layer, or a low one, no? E.g. if you aren't mobile yourself, and don't care to talk to anyone who is, you can leave out MIPv6. > Indeed, this is a generic requirement for any identifier scheme: hosts > that don't see the point should be able to opt-out and not bear the > burden associated with the "layer of indirection." The problem with this attitude is revealed in my comment above about "don't care to talk to anyone who is". *You* may not be multi-homed, and therefore have no interest in implementing a multi-homing mechanism, but if the entity you're talking to is, it loses the ability to make use of its multi-homing if you don't play ball. Of course, we could always (as previously discussed at length here) have different levels of functionality, so that at the base layer of functionality a host can be multi-homed, and can switch from one ISP to another for new TCP connections, but existing TCP connections to it won't survive if it switches ISP's - the advantage being that the former will work with *unmodified* hosts on the far end, whilst the second is only available with *modified* hosts. Actually, if you reuse MIPv6 mechanisms to handle the "existing TCP connections" case, you might be able to get both levels of functionality without any changes. Noel From owner-multi6@ops.ietf.org Thu Aug 7 12:17:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20912 for ; Thu, 7 Aug 2003 12:17:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19knRu-0009WA-7H for multi6-data@psg.com; Thu, 07 Aug 2003 16:17:10 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.20) id 19knRr-0009Vr-H9 for multi6@ops.ietf.org; Thu, 07 Aug 2003 16:17:07 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Aug 2003 09:17:03 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Aug 2003 09:16:59 -0700 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 07 Aug 2003 09:17:06 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Aug 2003 09:17:05 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Aug 2003 09:17:02 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Aug 2003 09:17:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus on identifier/locator split? Date: Thu, 7 Aug 2003 09:17:05 -0700 Message-ID: Thread-Topic: Consensus on identifier/locator split? Thread-Index: AcNc/XjOtkituttTTOO+W30D4lJeSAAAPbYL From: "Christian Huitema" To: "J. Noel Chiappa" , Cc: X-OriginalArrivalTime: 07 Aug 2003 16:17:05.0158 (UTC) FILETIME=[5789F260:01C35CFF] X-Spam-Status: No, hits=-7.8 required=5.0 tests=BAYES_10,OPT_IN,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Actually, if you reuse MIPv6 mechanisms to handle the "existing TCP > connections" case, you might be able to get both levels of = functionality > without any changes. That is certainly a reasonable option. In fact, back in 1995, the reason = we did not pursue the "TCP optimization" path was that the "binding = update" mechanism of MIPv6 was thought to provide equivalent = functionality. MIPv6 also provides a reasonable "opt-in" mechanism: = hosts implement the correspondent node facility if they want to enable = TCP connection to survive a "re-homing event" at their peers; = applications can opt for binding to a "long duration" source address if = they want to use long duration connections, and to the "short term best" = if they don't, or if they have another way to deal with mobility. Which is to say, I would be much more confortable examining a specific = proposition, such as "use of MIPv6 to survive re-homing events", rather = than a generic proposition of "let's split". -- Christian Huitema =20 From owner-multi6@ops.ietf.org Thu Aug 7 13:11:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22533 for ; Thu, 7 Aug 2003 13:11:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19koH7-000DIA-Ne for multi6-data@psg.com; Thu, 07 Aug 2003 17:10:05 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.20) id 19koH4-000DHC-CR for multi6@ops.ietf.org; Thu, 07 Aug 2003 17:10:02 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h77HAOxS093284; Thu, 7 Aug 2003 19:10:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 7 Aug 2003 19:09:53 +0200 Subject: Re: Consensus on identifier/locator split? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "J. Noel Chiappa" From: Iljitsch van Beijnum In-Reply-To: <200308071603.h77G3RUR006600@ginger.lcs.mit.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, aug 7, 2003, at 18:03 Europe/Amsterdam, J. Noel Chiappa wrote: > Looking at all that, it seems to me, from an architectural point of > view, to be wiser to put it somewhat lower down in the stack. YMMV if > you take other considerations more highly. I don't see how we could put the necessary information anywhere but in IP options/extension headers, if only because the TCP option space is too cramped and most other transport protocols don't have options at all. On the other hand, TCP knows what's happening end-to-end. So we probably want impementations to blur the layer boundaries a bit to take advantage of the opportunities at both the network and transport layers. From owner-multi6@ops.ietf.org Thu Aug 7 13:47:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23933 for ; Thu, 7 Aug 2003 13:47:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19koqY-000Fn0-43 for multi6-data@psg.com; Thu, 07 Aug 2003 17:46:42 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.20) id 19koqV-000Fmn-Tj for multi6@ops.ietf.org; Thu, 07 Aug 2003 17:46:39 +0000 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Aug 2003 10:51:39 -0700 Received: from cisco.com (sjc-vpn1-521.cisco.com [10.21.98.9]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h77HkW7F001604; Thu, 7 Aug 2003 10:46:37 -0700 (PDT) Message-ID: <3F329077.3070909@cisco.com> Date: Thu, 07 Aug 2003 10:46:31 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: "J. Noel Chiappa" , multi6@ops.ietf.org Subject: Re: Consensus on identifier/locator split? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-19.1 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Noel and all, How ought we (if at all) deal with the notion of a virtual end point such as a "content routed" service like CNN? Particularly in the face of mobile nodes. If we deal with it at all we don't want TCP connections breaking, and yet one wants to find the closest server hosting this identity (whatever that means). I raise this because one way of looking at the answer would be to simply have a server appear with multiple agencies in the routing system. That's inelegant and expensive. DNS and anycast is incomplete due to mobility. If CNN doesn't do it for you, think some sort of media gateway service (a 'la your long distance company or Vonage or some such). Regards, Eliot From owner-multi6@ops.ietf.org Thu Aug 7 14:42:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26379 for ; Thu, 7 Aug 2003 14:42:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kphN-000JRj-CX for multi6-data@psg.com; Thu, 07 Aug 2003 18:41:17 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.20) id 19kphK-000JRX-QB for multi6@ops.ietf.org; Thu, 07 Aug 2003 18:41:14 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 9ECE743281; Thu, 7 Aug 2003 20:36:47 +0200 (CEST) Received: from bagnulo (vpn-252-68.uc3m.es [163.117.252.68]) by smtp01.uc3m.es (Postfix) with ESMTP id 2EFB499E73; Thu, 7 Aug 2003 20:36:45 +0200 (CEST) From: "marcelo bagnulo" To: "'J. Noel Chiappa'" , , Subject: RE: Consensus on identifier/locator split? Date: Thu, 7 Aug 2003 20:36:44 +0200 Message-ID: <005f01c35d12$db1a1520$44fc75a3@bagnulo> 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, Build 10.0.2627 In-Reply-To: <200308071603.h77G3RUR006600@ginger.lcs.mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Status: No, hits=-9.6 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Actually, if you reuse MIPv6 mechanisms to handle the > "existing TCP connections" case, you might be able to get > both levels of functionality without any changes. Well this is not completelly accurate, according to my analysis, you need to make some minnor changes (in the CN too), in order to preserve the RR working.(i would like to be convinced otherwise) Another issue is that the only solution that i could find to this relies on icmp messages, which i am not sure that's acceptable. Regards, marcelo > > Noel > From owner-multi6@ops.ietf.org Thu Aug 7 16:42:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01865 for ; Thu, 7 Aug 2003 16:42:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19krYz-00014B-Ij for multi6-data@psg.com; Thu, 07 Aug 2003 20:40:45 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.20) id 19krYw-00013z-KT for multi6@ops.ietf.org; Thu, 07 Aug 2003 20:40:43 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h77Kf6xS095512; Thu, 7 Aug 2003 22:41:06 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 7 Aug 2003 22:40:37 +0200 Subject: Re: Consensus on identifier/locator split? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Eliot Lear From: Iljitsch van Beijnum In-Reply-To: <3F329077.3070909@cisco.com> Message-Id: <66747170-C917-11D7-9FEB-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, aug 7, 2003, at 19:46 Europe/Amsterdam, Eliot Lear wrote: > How ought we (if at all) deal with the notion of a virtual end point > such as a "content routed" service like CNN? First of all: is there a pressing need to do this below the application layer in the first place??? I know vendors make good money selling "layer 7 switches" but this looks an awful lot like asking for trouble to me. ("No, we can't IPv6-enable our website, the load balancers don't support it.") If we want to, it should be possible to go from a single very high level identifier to one of several possible lower level identifiers (where we select the "best" lower level identifier, such as the closest or least busy one) and then to several locators for this lower level identifier. To do this well we very likely need some kind of negotiation mechanism here, but this is something I haven't been able to convince everyone else we need yet. :-) > Particularly in the face of mobile nodes. I guess that if you want to be really cool you should jump end-hosts in mid session if your idea of "best" changes... This would entail stopping whatever is happening, connecting to a new endpoint and starting the communication at a specific point. I guess this could work for things like file transfer and streaming, but hard to make it work without involving the app. From owner-multi6@ops.ietf.org Thu Aug 7 18:58:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07685 for ; Thu, 7 Aug 2003 18:58:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ktgw-0009YG-CM for multi6-data@psg.com; Thu, 07 Aug 2003 22:57:06 +0000 Received: from [209.226.175.187] (helo=tomts24-srv.bellnexxia.net) by psg.com with esmtp (Exim 4.20) id 19ktgs-0009Xp-L9 for multi6@ops.ietf.org; Thu, 07 Aug 2003 22:57:02 +0000 Received: from yahoo.com ([65.93.186.207]) by tomts24-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030807225701.GTHK20400.tomts24-srv.bellnexxia.net@yahoo.com>; Thu, 7 Aug 2003 18:57:01 -0400 Date: Thu, 7 Aug 2003 18:57:01 -0400 Subject: Re: fixed wireless mesh Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Charlie Perkins From: S Woodside In-Reply-To: <3F32753A.9060106@iprg.nokia.com> Message-Id: <748776B4-C92A-11D7-8AA0-000A9573F104@yahoo.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_FAKE_HELO_DOTCOM, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Global connectivity for IPv6 Mobile Ad Hoc Networks http://people.nokia.net/charliep/txt/aodvid/globalv6.txt Interesting I-D Charlie. It satisfies some / many of my concerns, I think. Given your draft, I would like to ask the Multi6 group, if this mesh-based gateway solution would be compatible with multihoming in v6 . I.e., would a host on a mesh with multiple gateways, be able to multihome and load-balance using those gateways. Perhaps it could be called ad-hoc multihoming? :) simon On Thursday, August 7, 2003, at 11:50 AM, Charlie Perkins wrote: > > Hello folks, > > In fact, AODV (RFC 3561) would work for the fixed mesh case > also. Some of the features for preventing loops in dynamic topologies > would not do much, but then they would not get in the way either. > The lifetimes for active routes "should" be configured to be longer > than in the case of mobile devices, but that isn't hard to do. > Moreover, > even "fixed" wireless mesh topologies probably undergo changes now > and then, so that a wireless routing protocol would be useful even > after > the first few minutes of operation. Plus, we have a specification to > show how the fixed mesh could be hooked up to an Internet Gateway. > > Regards, > Charlie P. > > > S Woodside wrote: > >> >> On Wednesday, August 6, 2003, at 06:40 PM, Vernon Schryver wrote: >> >>>> Obviously having wireless mesh nodes route IP would be much too >>>> simple. >>> >>> >>> That statement is not obvious to me, except in standards committee >>> turf war terms. My intuition does suggest that none of RIP, IGRP, >>> EGP, BGP, HELO, or any other IP routing protocol would work well for >>> what they're trying to do. >> >> >> Errr... what about AODV??? >> >> As I said before, MANET is chartered for MOBILE applications and not >> fixed ad-hoc mesh as is the case with 802.16 with the new IEEE >> activities. Correct me if I'm wrong, the IETF doesn't have any >> activities looking at the fixed mesh case. >> >> simon -- simonwoodside.com -- openict.net -- 99% Devil, 1% Angel From owner-multi6@ops.ietf.org Thu Aug 7 21:10:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10973 for ; Thu, 7 Aug 2003 21:10:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kvku-000HSh-7B for multi6-data@psg.com; Fri, 08 Aug 2003 01:09:20 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.20) id 19kvkq-000HST-EM for multi6@ops.ietf.org; Fri, 08 Aug 2003 01:09:17 +0000 Received: from cisco.com (dhcp-171-71-119-135.cisco.com [171.71.119.135]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7819DLH002307; Thu, 7 Aug 2003 18:09:14 -0700 (PDT) Message-ID: <3F32F839.9070305@cisco.com> Date: Thu, 07 Aug 2003 18:09:13 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: Consensus on identifier/locator split? References: <66747170-C917-11D7-9FEB-00039388672E@muada.com> In-Reply-To: <66747170-C917-11D7-9FEB-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On donderdag, aug 7, 2003, at 19:46 Europe/Amsterdam, Eliot Lear wrote: > >> How ought we (if at all) deal with the notion of a virtual end point >> such as a "content routed" service like CNN? > > > First of all: is there a pressing need to do this below the application > layer in the first place??? It's already done below the application layer in many cases, particularly when trying to determine the "closest" data center. All I'm asking really is that we consider all the knobs that exist today, across a broad set of areas, when looking at architectural choices. I'm not asking anything more specific. Do I need to explain why I think this is related or is that glaringly obvious? Eliot From owner-multi6@ops.ietf.org Fri Aug 8 00:41:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15758 for ; Fri, 8 Aug 2003 00:41:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kz1x-0003G1-0D for multi6-data@psg.com; Fri, 08 Aug 2003 04:39:09 +0000 Received: from [134.193.143.167] (helo=kc-msxproto1.kc.umkc.edu) by psg.com with esmtp (Exim 4.20) id 19kz1s-0003FZ-M3 for multi6@ops.ietf.org; Fri, 08 Aug 2003 04:39:04 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Aug 2003 23:39:03 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: Consensus on identifier/locator split? Date: Thu, 7 Aug 2003 23:39:02 -0500 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108052@KC-MAIL4.kc.umkc.edu> Thread-Topic: Consensus on identifier/locator split? thread-index: AcNdDZ+MckjnLGXzRByjY95qqgLwRgAStqEA From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "Eliot Lear" , "Iljitsch van Beijnum" Cc: "J. Noel Chiappa" , X-OriginalArrivalTime: 08 Aug 2003 04:39:03.0044 (UTC) FILETIME=[FE444440:01C35D66] X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,FROM_ENDS_IN_NUMS version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >How ought we (if at all) deal with the notion of a virtual end point=20 >such as a "content routed" service like CNN? Particularly in the face=20 >of mobile nodes. If we deal with it at all we don't want TCP=20 >connections breaking, and yet one wants to find the closest server=20 >hosting this identity (whatever that means). I raise this because one=20 >way of looking at the answer would be to simply have a server appear=20 >with multiple agencies in the routing system. That's inelegant and=20 >expensive. DNS and anycast is incomplete due to mobility. Currently, content routing is done by putting the burden onto=20 DNS. The scheme is attractive, because it requires no change=20 to both the router and host. But, makes changes to DNS (like=20 CNAME record etc) depending on the content distribution type. I guess, many in IETF are so much concerned about overloading=20 critical infrastructures like BGP and DNS. Other than that, a lot of measurement based local optimization and assumptions affect the granularity of the server selection process. so, we need a solution which does not depend on DNS.=20 as you mention above, content routing can be done using IP=20 mobility; there by preserving transport level connectivity. MIP6 can be used for redirection without the need for DNS.=20 For example, consider CNN server (replicated) as a mobile=20 node, request router being the home agent and the client be the correspodent node. In our case, the request router(home agent) must make a server selection based on server load,=20 available BW info and proximity etc; unlike DNS based=20 server selection. Here, the load/proximity information is the equivalent of "location update" as in MIP.=20 btw, I agree with you that it is one way of looking at=20 the locator/identifier separation. >If CNN doesn't do it for you, CNN doesn't do the request routing. They are just a=20 content provider. All the intelligent routing control=20 is done by third party distribution service providers=20 like akamai.=20 [ from your other mail ] >It's already done below the application layer in many cases,=20 >particularly when trying to determine the "closest" data=20 >center. All I'm asking really is that we consider all the=20 >knobs that exist today, across a broad set of areas, when=20 >looking at architectural choices. I'm not asking anything=20 >more specific. something more tangible? so, whatever solutions proposed in=20 multi6 should purely be judged by: o its dependence on previous loc/id separation solutions,like=20 MIP. major architectural changes (like new namespace)=20 should be done else where. o required change to routers/hosts o offcourse, other requirements listed in the draft. MIP6 based proposals seems like a way to move forward.=20 [replying to Tony's post] > Do we have consensus about splitting the address into=20 > locators and identifiers? Yes. But, a dedicated group of experts (NSRG) was not=20 able to come to a conclusion on the "type" of loc/id split. so, multi6 should avoid making major long term architectural changes.=20 -- senthil =20 From owner-multi6@ops.ietf.org Fri Aug 8 11:53:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15861 for ; Fri, 8 Aug 2003 11:53:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19l9W8-0004Il-0n for multi6-data@psg.com; Fri, 08 Aug 2003 15:51:00 +0000 Received: from [47.103.122.112] (helo=zrc2s0jx.nortelnetworks.com) by psg.com with esmtp (Exim 4.20) id 19l9W4-0004IO-HB for multi6@ops.ietf.org; Fri, 08 Aug 2003 15:50:56 +0000 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h78FoYd29623; Fri, 8 Aug 2003 10:50:34 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <3014AH76>; Fri, 8 Aug 2003 10:50:35 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF6487B8@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Pekka Nikander'" , hipsec@lists.freeswan.org, multi6@ops.ietf.org Subject: RE: New version of HIP base protocol submitted Date: Fri, 8 Aug 2003 10:50:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35DC4.C6D2F796" X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_01,HTML_30_40,ORIGINAL_MESSAGE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35DC4.C6D2F796 Content-Type: text/plain; charset="iso-8859-1" Hi, In "Host Identity Protocol", June 2003, there is a reference citing the following I-D: "Using Domain Name System (DNS) with Host Identity Protocol (HIP)", June 2003. However, I have been unable to locate this I-D. Is it available publicly? Thanks. Regards, Pete -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Thursday, June 19, 2003 6:32 AM To: hipsec@lists.freeswan.org; multi6@ops.ietf.org Subject: New version of HIP base protocol submitted A new version of the HIP base protocol draft has been submitted to the repositories. In the meanwhile, it is available at the following URLs: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-07.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-07.html The following version contains change bars wrt. -06: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-07-chbar.txt The following version is an HTML side-by-side comparison: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-07-diff.html --Pekka Nikander ------_=_NextPart_001_01C35DC4.C6D2F796 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: New version of HIP base protocol submitted

Hi,

In <draft-moskowitz-hip-06.txt> "Host = Identity Protocol", June 2003, there is a reference citing the = following I-D:

<draft-nikiander-hip-dns-00.txt> "Using = Domain Name System (DNS) with Host Identity Protocol (HIP)", June = 2003.

However, I have been unable to locate this I-D. Is it = available publicly? Thanks.

Regards,

Pete

-----Original Message-----
From: Pekka Nikander [mailto:pekka.nikander@noma= diclab.com]
Sent: Thursday, June 19, 2003 6:32 AM
To: hipsec@lists.freeswan.org; = multi6@ops.ietf.org
Subject: New version of HIP base protocol = submitted


A new version of the HIP base protocol draft has = been
submitted to the repositories.  In the = meanwhile, it
is available at the following URLs:

http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-07.= txt
http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-07.= html

The following version contains change bars wrt. = -06:

http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-07-= chbar.txt

The following version is an HTML side-by-side = comparison:

http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-07-= diff.html

--Pekka Nikander


------_=_NextPart_001_01C35DC4.C6D2F796-- From owner-multi6@ops.ietf.org Fri Aug 8 18:32:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29601 for ; Fri, 8 Aug 2003 18:32:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19lFjT-000MD7-FQ for multi6-data@psg.com; Fri, 08 Aug 2003 22:29:11 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.20) id 19lFjM-000MBf-Uz for multi6@ops.ietf.org; Fri, 08 Aug 2003 22:29:08 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h78MT41i019349 for ; Fri, 8 Aug 2003 16:29:04 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HJB00BDKNSF1A@edgemail1.Central.Sun.COM> for multi6@ops.ietf.org; Fri, 08 Aug 2003 16:29:04 -0600 (MDT) Received: from sun.com ([129.146.12.17]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HJB005VYNSE5C@mail.sun.net> for multi6@ops.ietf.org; Fri, 08 Aug 2003 16:29:03 -0600 (MDT) Date: Fri, 08 Aug 2003 15:29:02 -0700 From: Alain Durand Subject: Re: Consensus on identifier/locator split? To: marcelo bagnulo Cc: Tony Li , multi6@ops.ietf.org Message-id: <3F34242E.7000702@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: X-Spam-Status: No, hits=-24.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,OPT_IN,REFERENCES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Are you making the assumption that all your ISPs will route your PI? If not, you will always end-up with multiple addresses anyway. To answer Tony's question, I think this split is unavoidable. The question is where it happens (bellow TCP, in TCP or above) and how to opt-in. For transition reasons, I think that opt-out is not realistic. - Alain. marcelo bagnulo wrote: >Hi Tony, > >I think that a previous question that we may ask is whether we agree that we >will use PA addresses (topologically meaningfull addresses) or we will >assign PI addresses. > >If we choose to use PA addresses, then we need to have multiple PA addresses >in multi-hmed environments, this implies that when a node A is communication >with a multi-homed node, node A has to know that all the PA addresses belogn >to the same mh node, so the location and id function are splitted at some >level (IP, transport, application), because somewhere someone knows that >multiple locators are linked to a sinlge entity. > >If we use PI addresses we only have a single address which accomplishes both >the id and the loc fucntion so we don't have to split. > >So, the question fo me is, do we agree we will use multiple PA addresses in >multi-homed environments? if so i would say we agree that the identifier >function and the location function are splitted. > >Regards, marcelo > >PS: I know smoe are unconfortable with this PA PI terminology, please read >as topology meaningfull and topology independent > > > >>-----Mensaje original----- >>De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En >>nombre de Tony Li >>Enviado el: miercoles, 06 de agosto de 2003 19:23 >>Para: multi6@ops.ietf.org >>Asunto: Consensus on identifier/locator split? >> >> >> >>Folks, >> >>I don't mean to disrupt other constructive conversations, >>so please carry on with those. >> >>I'd just like to get a sense from the group about where >>we are so far. Do we have consensus about splitting >>the address into locators and identifiers? Note that >>I'm NOT asking about specifics, like "how big", "what >>mappings exist", "is it secure", etc. Do we agree that >>we want to go down this path? >> >>Silence is not assent... >> >>Thanks, >>Tony >> >> >> > > > > From owner-multi6@ops.ietf.org Sat Aug 9 06:29:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24881 for ; Sat, 9 Aug 2003 06:29:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19lQvr-000OWi-1p for multi6-data@psg.com; Sat, 09 Aug 2003 10:26:43 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.20) id 19lQvo-000OWG-B7 for multi6@ops.ietf.org; Sat, 09 Aug 2003 10:26:40 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA10069 for ; Sat, 9 Aug 2003 11:26:38 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id LAA26131 for ; Sat, 9 Aug 2003 11:26:38 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h79AQbX09643 for multi6@ops.ietf.org; Sat, 9 Aug 2003 11:26:37 +0100 Date: Sat, 9 Aug 2003 11:26:37 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Consensus on identifier/locator split? Message-ID: <20030809102637.GE9484@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <3F34242E.7000702@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F34242E.7000702@sun.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-31.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Aug 08, 2003 at 03:29:02PM -0700, Alain Durand wrote: > > To answer Tony's question, I think this split is unavoidable. > The question is where it happens (bellow TCP, in TCP or above) > and how to opt-in. For transition reasons, I think that opt-out is not > realistic. Agreed - and which WG would consider it? Tim From owner-multi6@ops.ietf.org Sat Aug 9 23:45:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14782 for ; Sat, 9 Aug 2003 23:45:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19lh60-000Ce5-8F for multi6-data@psg.com; Sun, 10 Aug 2003 03:42:16 +0000 Received: from [217.37.202.105] (helo=ab.use.net) by psg.com with esmtp (Exim 4.20) id 19lh5x-000Cdt-SV for multi6@ops.ietf.org; Sun, 10 Aug 2003 03:42:14 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id 1C2E939690 for ; Sun, 10 Aug 2003 03:42:07 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v582) In-Reply-To: <20030809102637.GE9484@login.ecs.soton.ac.uk> References: <3F34242E.7000702@sun.com> <20030809102637.GE9484@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <84CEA57D-CA9D-11D7-8D5B-0003938E4DE4@ab.use.net> Content-Transfer-Encoding: 7bit From: Sean Doran Subject: Re: Consensus on identifier/locator split? Date: Sat, 9 Aug 2003 20:13:11 +0100 To: multi6@ops.ietf.org X-Mailer: Apple Mail (2.582) X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,DATE_IN_PAST_06_12,EMAIL_ATTRIBUTION,IN_REP_TO, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Saturday, 9 August 2003, at 11:26AM, Tim Chown wrote: > Agreed - and which WG would consider it? Does that really matter? There is a decent set of people in this one, and I* seems pretty content to let work develop in situ, moving it when and if that seems more obviously productive. Sean. From owner-multi6@ops.ietf.org Sat Aug 9 23:45:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14810 for ; Sat, 9 Aug 2003 23:45:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19lh71-000Cg9-EP for multi6-data@psg.com; Sun, 10 Aug 2003 03:43:19 +0000 Received: from [217.37.202.105] (helo=ab.use.net) by psg.com with esmtp (Exim 4.20) id 19lh6z-000Cft-DY for multi6@ops.ietf.org; Sun, 10 Aug 2003 03:43:17 +0000 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id 28F6939690 for ; Sun, 10 Aug 2003 03:43:16 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v582) In-Reply-To: <20030809102637.GE9484@login.ecs.soton.ac.uk> References: <3F34242E.7000702@sun.com> <20030809102637.GE9484@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <84CEA57D-CA9D-11D7-8D5B-0003938E4DE4@ab.use.net> Content-Transfer-Encoding: 7bit From: Sean Doran Subject: Re: Consensus on identifier/locator split? Date: Sat, 9 Aug 2003 20:13:11 +0100 To: multi6@ops.ietf.org X-Mailer: Apple Mail (2.582) X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,DATE_IN_PAST_06_12,EMAIL_ATTRIBUTION,IN_REP_TO, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Saturday, 9 August 2003, at 11:26AM, Tim Chown wrote: > Agreed - and which WG would consider it? Does that really matter? There is a decent set of people in this one, and I* seems pretty content to let work develop in situ, moving it when and if that seems more obviously productive. Sean. From owner-multi6@ops.ietf.org Mon Aug 11 01:47:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25145 for ; Mon, 11 Aug 2003 01:47:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19m5SG-00051t-17 for multi6-data@psg.com; Mon, 11 Aug 2003 05:42:52 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.20) id 19m5SD-00051f-G6 for multi6@ops.ietf.org; Mon, 11 Aug 2003 05:42:49 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 066291C; Mon, 11 Aug 2003 08:52:21 +0300 (EEST) Message-ID: <3F372CE2.2090805@nomadiclab.com> Date: Mon, 11 Aug 2003 08:42:58 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Barany Cc: hipsec@lists.freeswan.org, multi6@ops.ietf.org Subject: Re: New version of HIP base protocol submitted References: <870397D7C140C84DB081B88396458DAF6487B8@zrc2c000.us.nortel.com> In-Reply-To: <870397D7C140C84DB081B88396458DAF6487B8@zrc2c000.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-33.8 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Peter, Peter Bar any wrote: > In "Host Identity Protocol", June 2003, > there is a reference citing the following I-D: > > "Using Domain Name System (DNS) with > Host Identity Protocol (HIP)", June 2003. > > However, I have been unable to locate this I-D. Is it available > publicly? Thanks. A preliminary version is available at http://www.tml.hut.fi/~pnr/HIP/ It is far from ready to be submitted yet. Unfortunately I have lots of things in pipe before that, so I will be able to return to it only sometime in September. In the meanwhile, if you have any suggestions, especially text just to plug in, feel free to contribute. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Aug 11 21:41:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13270 for ; Mon, 11 Aug 2003 21:41:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mO8O-000A0v-BX for multi6-data@psg.com; Tue, 12 Aug 2003 01:39:36 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19mO8L-000A06-AT for multi6@ops.ietf.org; Tue, 12 Aug 2003 01:39:33 +0000 From: Masataka Ohta Message-Id: <200308120128.KAA02635@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA02635; Tue, 12 Aug 2003 10:28:11 +0900 Subject: Re: Consensus on identifier/locator split? In-Reply-To: <041901c35c5f$aa0d4230$70144104@eagleswings> from Tony Hain at "Aug 6, 2003 02:14:00 pm" To: Tony Hain Date: Tue, 12 Aug 2003 10:28:09 +0859 () CC: "'Tony Li'" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-8.6 required=5.0 tests=BAYES_20,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony; > I would say there is consensus that splitting would solve several problems, > but I wouldn't go so far to say there is consensus that it is the right > approach. Fundamentally, splitting amounts to rearchitecting the Internet > since many current assumptions would be invalidated. While this is a fine > thing for an IRTF wg to take on, For constructive discussion, what, do you think, are the current assumptions which would be invalidated? I think it is merely that the current assumptions using the terminology of "address" should be more precisely phrased with "address" replaced by "id" or "locator", which does not change the architecture of the current Internet. Or, do you have any exception? Masataka Ohta From owner-multi6@ops.ietf.org Mon Aug 11 21:42:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13313 for ; Mon, 11 Aug 2003 21:42:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mO8G-0009zt-AO for multi6-data@psg.com; Tue, 12 Aug 2003 01:39:28 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19mO88-0009yo-T0 for multi6@ops.ietf.org; Tue, 12 Aug 2003 01:39:21 +0000 From: Masataka Ohta Message-Id: <200308120124.KAA02631@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA02631; Tue, 12 Aug 2003 10:24:16 +0900 Subject: MIPv6 hopeless In-Reply-To: from Christian Huitema at "Aug 7, 2003 09:17:05 am" To: Christian Huitema Date: Tue, 12 Aug 2003 10:24:15 +0859 () CC: "J. Noel Chiappa" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-8.1 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Christian; > Which is to say, I would be much more confortable examining a specific proposition, such as "use of MIPv6 to survive re-homing events", rather than a generic proposition of "let's split". At Vienna, I explained three reasons on why MIPv6 is hopeless. That is, its handover is too slow to be useful for any realistic application it is server (home agent) based it reduces MTU to violate the IPv6 specification The second one is multi6 specific, while the first and the third ones are generic. But, I think any of the reason is fatal. Now, you have a chance for counter argument. Masataka Ohta From owner-multi6@ops.ietf.org Mon Aug 11 21:49:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13546 for ; Mon, 11 Aug 2003 21:49:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mOHy-000AbK-BY for multi6-data@psg.com; Tue, 12 Aug 2003 01:49:30 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19mOHv-000Ab8-Bg for multi6@ops.ietf.org; Tue, 12 Aug 2003 01:49:28 +0000 From: Masataka Ohta Message-Id: <200308120142.KAA02705@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA02705; Tue, 12 Aug 2003 10:41:55 +0859 Subject: Re: Consensus on identifier/locator split? In-Reply-To: <3F34242E.7000702@sun.com> from Alain Durand at "Aug 8, 2003 03:29:02 pm" To: Alain Durand Date: Tue, 12 Aug 2003 10:41:55 +0859 () CC: marcelo bagnulo , Tony Li , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-8.6 required=5.0 tests=BAYES_20,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Alain; > Are you making the assumption that all your ISPs will route your PI? > If not, you will always end-up with multiple addresses anyway. > > To answer Tony's question, I think this split is unavoidable. > The question is where it happens (bellow TCP, in TCP or above) Wrong. As I presented in Vienna, Web is not the Internet. TCP is not the Internet Protocol. That is, there is no room for such a question for sites wanting stability to the Internet. Multihomed site needs its connections kept alive on path changes, regardless of transport protocols. That is, the split is at IP. Masataka Ohta From owner-multi6@ops.ietf.org Tue Aug 12 12:49:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21164 for ; Tue, 12 Aug 2003 12:49:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mcIz-000OrX-F0 for multi6-data@psg.com; Tue, 12 Aug 2003 16:47:29 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.20) id 19mcIq-000OqZ-Sx for multi6@ops.ietf.org; Tue, 12 Aug 2003 16:47:25 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7CGlK2O022167 for ; Tue, 12 Aug 2003 10:47:20 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HJI000XSMMVXK@edgemail1.Central.Sun.COM> for multi6@ops.ietf.org; Tue, 12 Aug 2003 10:47:20 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HJI00LWKMMUTG@mail.sun.net> for multi6@ops.ietf.org; Tue, 12 Aug 2003 10:47:19 -0600 (MDT) Date: Tue, 12 Aug 2003 09:49:37 -0700 From: Alain Durand Subject: Re: Consensus on identifier/locator split? In-reply-to: <200308120142.KAA02705@necom830.hpcl.titech.ac.jp> To: Masataka Ohta Cc: marcelo bagnulo , Tony Li , multi6@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Monday, August 11, 2003, at 06:42 PM, Masataka Ohta wrote: > Alain; > >> Are you making the assumption that all your ISPs will route your PI? >> If not, you will always end-up with multiple addresses anyway. >> >> To answer Tony's question, I think this split is unavoidable. >> The question is where it happens (bellow TCP, in TCP or above) > > Wrong. > > As I presented in Vienna, Web is not the Internet. > > TCP is not the Internet Protocol. Correct, I should have said transport instead of TCP. > Multihomed site needs its connections kept alive on path changes, > regardless of transport protocols. > > That is, the split is at IP. That is one solution, but not the only one, and we may be OK with a solution that modifies a limited number of transport protocol, or with a solution that builds multihoming in a session layer on top of transport and that would work regardless of the underneath protocols. - Alain, From owner-multi6@ops.ietf.org Tue Aug 12 13:19:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21959 for ; Tue, 12 Aug 2003 13:19:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mcnB-0002P3-Un for multi6-data@psg.com; Tue, 12 Aug 2003 17:18:41 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.20) id 19mcn8-0002Om-MB for multi6@ops.ietf.org; Tue, 12 Aug 2003 17:18:39 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h7CHJ5xS071323; Tue, 12 Aug 2003 19:19:05 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 12 Aug 2003 19:18:34 +0200 Subject: Re: Consensus on identifier/locator split? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Alain Durand From: Iljitsch van Beijnum In-Reply-To: Message-Id: <00E51AA0-CCE9-11D7-9024-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, aug 12, 2003, at 18:49 Europe/Amsterdam, Alain Durand wrote: > or with a solution that builds multihoming in a session layer on top > of transport and that would work regardless of the underneath > protocols. Such a session layer would have keep track of how much data has been successfully transmitted to the other side in order to be able to retransmit it when the underlying transport dies and another one must be used. Essentially it would replicate a good part of the existing transport functionality. A much more useful approach would be to run the session layer _underneath_ the transport layer so the transport protocol can do its magic and the session layer can juggle the addresses. From owner-multi6@ops.ietf.org Tue Aug 12 14:24:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23565 for ; Tue, 12 Aug 2003 14:24:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mdnU-0009Zr-Es for multi6-data@psg.com; Tue, 12 Aug 2003 18:23:04 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.20) id 19mdnR-0009Yj-HE for multi6@ops.ietf.org; Tue, 12 Aug 2003 18:23:01 +0000 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 h7CIMxtU012514; Tue, 12 Aug 2003 14:23:00 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h7CIMxOg012513; Tue, 12 Aug 2003 14:22:59 -0400 Date: Tue, 12 Aug 2003 14:22:59 -0400 From: "J. Noel Chiappa" Message-Id: <200308121822.h7CIMxOg012513@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: MIPv6 hopeless Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Masataka Ohta > I explained three reasons on why MIPv6 is hopeless. > .. its handover is too slow to be useful for any realistic application > .. > The second one is multi6 specific, while the first and the third ones > are generic. I'm interested in your claim that the "handover is too slow to be useful" is generic; i.e. would apply to any mechanism. Are you saying that any attempt to switch from use of one address to use of another, while a connection is open, is bound to be too slow to be useful? That would be of interest, if true, since people want that as a goal. Are Noel From owner-multi6@ops.ietf.org Tue Aug 12 15:26:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27006 for ; Tue, 12 Aug 2003 15:26:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mekc-000HHI-4Z for multi6-data@psg.com; Tue, 12 Aug 2003 19:24:10 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.20) id 19mekY-000HGu-I8 for multi6@ops.ietf.org; Tue, 12 Aug 2003 19:24:06 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 761681C; Tue, 12 Aug 2003 22:33:37 +0300 (EEST) Message-ID: <3F393EE0.8050809@nomadiclab.com> Date: Tue, 12 Aug 2003 22:24:16 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: Alain Durand , multi6@ops.ietf.org Subject: Whither a session layer, and where (was Re: Consensus on identifier/locator split?) References: <00E51AA0-CCE9-11D7-9024-00039388672E@muada.com> In-Reply-To: <00E51AA0-CCE9-11D7-9024-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > A much more useful approach would be to run the session layer > _underneath_ the transport layer so the transport protocol can do its > magic and the session layer can juggle the addresses. I concur. The interface between such a session layer and the transport layer seems to become very interesting. For example, which layer is going to keep track of MTU and RTT? How to do traffic shaping between several transport connections going over a single endpoint-to-endpoint "session"? Etc. --Pekka Nikander From owner-multi6@ops.ietf.org Tue Aug 12 17:52:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00114 for ; Tue, 12 Aug 2003 17:52:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mh1B-000A9X-FH for multi6-data@psg.com; Tue, 12 Aug 2003 21:49:25 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19mh18-000A5j-LC for multi6@ops.ietf.org; Tue, 12 Aug 2003 21:49:22 +0000 From: Masataka Ohta Message-Id: <200308122134.GAA03116@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA03116; Wed, 13 Aug 2003 06:34:04 +0900 Subject: Re: MIPv6 hopeless In-Reply-To: <200308121822.h7CIMxOg012513@ginger.lcs.mit.edu> from "J. Noel Chiappa" at "Aug 12, 2003 02:22:59 pm" To: "J. Noel Chiappa" Date: Wed, 13 Aug 2003 06:34:03 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Noe; > > I explained three reasons on why MIPv6 is hopeless. > > .. its handover is too slow to be useful for any realistic application > > .. > > The second one is multi6 specific, while the first and the third ones > > are generic. > > I'm interested in your claim that the "handover is too slow to be useful" is > generic; i.e. would apply to any mechanism. No, I wrote "its handover is too slow to be useful" that it is MIPv6 specific. I said "generic", because it is a problem of MIPv6 not specifically related to multi6. > Are you saying that any attempt to switch from use of one address to use of > another, while a connection is open, is bound to be too slow to be useful? No. However, it should also be noted that, as I presented at Vienna, handover timeout of any mobile protocl is not useful for multihoming, because the timing must be determined based on the mobile cell size divided by movement speed, which has nothing to do with the requirement of applications. Masataka Ohta From owner-multi6@ops.ietf.org Tue Aug 12 18:00:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00275 for ; Tue, 12 Aug 2003 18:00:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mhAt-000BaS-EN for multi6-data@psg.com; Tue, 12 Aug 2003 21:59:27 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19mhAq-000BaF-RP for multi6@ops.ietf.org; Tue, 12 Aug 2003 21:59:25 +0000 From: Masataka Ohta Message-Id: <200308122143.GAA03188@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA03188; Wed, 13 Aug 2003 06:43:05 +0900 Subject: Re: Consensus on identifier/locator split? In-Reply-To: from Alain Durand at "Aug 12, 2003 09:49:37 am" To: Alain Durand Date: Wed, 13 Aug 2003 06:43:04 +0859 () CC: marcelo bagnulo , Tony Li , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.9 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Alain; > >> To answer Tony's question, I think this split is unavoidable. > >> The question is where it happens (bellow TCP, in TCP or above) > > As I presented in Vienna, Web is not the Internet. > > > > TCP is not the Internet Protocol. > > Correct, I should have said transport instead of TCP. > That is one solution, but not the only one, and we may be OK > with a solution that modifies a limited number of transport protocol, > or with a solution that builds multihoming in a session layer on top > of transport and that would work regardless of the underneath > protocols. Solution? As for solutions, transport and application layers must, of course, be modified, as has been pointed out in my draft. There can be no generic session layer defined over, say, UDP. However, the split is at the IP layer, because it should be available to all the transport layers. The set of a limited number of transport protocol is not the Internet Protocol. Masataka Ohta From owner-multi6@ops.ietf.org Tue Aug 12 19:09:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02417 for ; Tue, 12 Aug 2003 19:09:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19miFW-000Lb8-5M for multi6-data@psg.com; Tue, 12 Aug 2003 23:08:18 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.20) id 19miFR-000LZy-II for multi6@ops.ietf.org; Tue, 12 Aug 2003 23:08:13 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id C521E43181; Wed, 13 Aug 2003 01:08:12 +0200 (CEST) Received: from bagnulo (vpn-252-210.uc3m.es [163.117.252.210]) by smtp01.uc3m.es (Postfix) with ESMTP id BB13199E83; Wed, 13 Aug 2003 01:08:09 +0200 (CEST) From: "marcelo bagnulo" To: "'Masataka Ohta'" , "'Christian Huitema'" Cc: "'J. Noel Chiappa'" , Subject: RE: MIPv6 hopeless Date: Tue, 12 Aug 2003 20:08:11 -0300 Message-ID: <000001c36126$9b985890$efe3fea9@bagnulo> 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, Build 10.0.2627 Importance: Normal In-Reply-To: <200308120124.KAA02631@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-8.0 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Masataka, I concur that MIPv6 as is cannot be used to provide multi-homing support. I think that there are parts of MIPv6 that may be recycled into a multi-homing solution. That is: The basic protocol, i.e. the packet formats required to provide multi-homing support are similar to those required to provide mobility support (BU, BA), so the protocol itself can be reused (i am not talking about node behaviors or even roles defined by MIPv6) Another benefit that could be achieved with a MIPv6 based multi-homing solution would be to use the CN functionality with the minimum amount of changes, reducing the deployment effort (since these capabilities are already there) I agree with you that the mobile node behavior (in particular the timers) are not suitable to be used to provide multi-homing support. Moreover, as you mention, the role of the HA is not appropriate for multi-homing support. But at this point it must be noted that the important changes required are limited to the behavior of the nodes within the multi-homed site i.e. the nodes that are actually benefiting from the solution, So in this case it seems reasonable to impose that these nodes have to be modified. Regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org > [mailto:owner-multi6@ops.ietf.org] En nombre de Masataka Ohta > Enviado el: lunes, 11 de agosto de 2003 22:25 > Para: Christian Huitema > CC: J. Noel Chiappa; multi6@ops.ietf.org > Asunto: MIPv6 hopeless > > > Christian; > > > Which is to say, I would be much more confortable examining > a specific > > proposition, such as "use of MIPv6 to survive re-homing events", > > rather than a generic proposition of "let's split". > > At Vienna, I explained three reasons on why MIPv6 is hopeless. > > That is, > > its handover is too slow to be useful for any realistic > application > > it is server (home agent) based > > it reduces MTU to violate the IPv6 specification > > The second one is multi6 specific, while the first and the > third ones are generic. But, I think any of the reason is fatal. > > Now, you have a chance for counter argument. > > Masataka Ohta > From owner-multi6@ops.ietf.org Wed Aug 13 03:26:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11192 for ; Wed, 13 Aug 2003 03:26:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mpzu-000MP5-MN for multi6-data@psg.com; Wed, 13 Aug 2003 07:24:42 +0000 Received: from [2001:6b0:7::26] (helo=bardisk.pilsnet.sunet.se) by psg.com with esmtp (Exim 4.20) id 19mpzr-000MOt-Rb for multi6@ops.ietf.org; Wed, 13 Aug 2003 07:24:40 +0000 Received: from bardisk.pilsnet.sunet.se (localhost [IPv6:::1]) by bardisk.pilsnet.sunet.se (8.12.9/8.12.8) with ESMTP id h7D7OcgT061896 for ; Wed, 13 Aug 2003 09:24:38 +0200 (CEST) (envelope-from mansaxel@bardisk.pilsnet.sunet.se) Received: (from mansaxel@localhost) by bardisk.pilsnet.sunet.se (8.12.9/8.12.3/Submit) id h7D7Oc5G061895 for multi6@ops.ietf.org; Wed, 13 Aug 2003 09:24:38 +0200 (CEST) Date: Wed, 13 Aug 2003 09:24:38 +0200 From: Mans Nilsson To: multi6@ops.ietf.org Subject: Re: Consensus on identifier/locator split? Message-ID: <20030813072438.GB61550@sunet.se> References: <200308122143.GAA03188@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline In-Reply-To: <200308122143.GAA03188@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4.1i X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-synced-from: Pilsnet X-Spam-Status: No, hits=-37.8 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: Consensus on identifier/locator split? Date: Wed, Aug 13, 2003= at 06:43:04AM +0859 Quoting Masataka Ohta (mohta@necom830.hpcl.titech.ac.j= p): >=20 > However, the split is at the IP layer, because it should be available > to all the transport layers. >=20 > The set of a limited number of transport protocol is not the Internet > Protocol. This follows the path of least surprise for applications. Me likes.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE One FISHWICH coming up!! --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE/Oee202/pMZDM1cURAsLnAJ90bqYaCcgL/crrE7tfwxGh921ziQCfbGQH ThnW+B400c/xrEsobvItxRY= =bkqA -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG-- From owner-multi6@ops.ietf.org Wed Aug 13 09:28:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18610 for ; Wed, 13 Aug 2003 09:28:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mvdc-000FUg-CZ for multi6-data@psg.com; Wed, 13 Aug 2003 13:26:04 +0000 Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.20) id 19mvdW-000FUD-Dl for multi6@ops.ietf.org; Wed, 13 Aug 2003 13:25:58 +0000 Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250](untrusted sender)) by comcast.net (rwcrmhc11) with SMTP id <2003081313255701300kktkqe> (Authid: sdawkins@comcast.net); Wed, 13 Aug 2003 13:25:58 +0000 Message-ID: <024801c3619e$6fb907b0$0300000c@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <00E51AA0-CCE9-11D7-9024-00039388672E@muada.com> <3F393EE0.8050809@nomadiclab.com> Subject: Re: Whither a session layer, and where (was Re: Consensus on identifier/locator split?) Date: Wed, 13 Aug 2003 08:25:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To the chairs - if this is seriously off-topic for multi6, please feel free to say so... The problem with having session layer functionality (as I understand it) underneath the transport layer, is that so much of transport-layer functionality is tied to a single connection path (P-MTU and RTT, to name two). If path changes reset all of this functionality, it's not clear to me what the benefits of being "above" session-layer functionality might be. And the bigger problem is that we have so many transport protocols that are implemented in kernel space - this was a huge problem for SCTP, and I expect it will be a huge problem for DCCP as well. If session-layer functionality is above transport, end users can make decisions about deploying it; if it's below transport, we're waiting for OS releases before anything is possible. This shouldn't be "fatal", but we even ended up deploying RTP-over-UDP so we didn't have to wait for OS support of RTP in kernels... Spencer ----- Original Message ----- From: "Pekka Nikander" To: "Iljitsch van Beijnum" Cc: "Alain Durand" ; Sent: Tuesday, August 12, 2003 2:24 PM Subject: Whither a session layer, and where (was Re: Consensus on identifier/locator split?) > Iljitsch van Beijnum wrote: > > A much more useful approach would be to run the session layer > > _underneath_ the transport layer so the transport protocol can do its > > magic and the session layer can juggle the addresses. > > I concur. > > The interface between such a session layer and the transport layer > seems to become very interesting. For example, which layer is going > to keep track of MTU and RTT? How to do traffic shaping between > several transport connections going over a single endpoint-to-endpoint > "session"? Etc. > > --Pekka Nikander > > > From owner-multi6@ops.ietf.org Wed Aug 13 13:25:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26643 for ; Wed, 13 Aug 2003 13:25:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mzLJ-00046y-1B for multi6-data@psg.com; Wed, 13 Aug 2003 17:23:25 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.20) id 19mzLG-00046h-Le for multi6@ops.ietf.org; Wed, 13 Aug 2003 17:23:22 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 6BC7C1C; Wed, 13 Aug 2003 20:32:53 +0300 (EEST) Message-ID: <3F3A7416.4030401@nomadiclab.com> Date: Wed, 13 Aug 2003 20:23:34 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Spencer Dawkins Cc: multi6@ops.ietf.org Subject: Re: Whither a session layer, and where (was Re: Consensus on identifier/locator split?) References: <00E51AA0-CCE9-11D7-9024-00039388672E@muada.com> <3F393EE0.8050809@nomadiclab.com> <024801c3619e$6fb907b0$0300000c@DFNJGL21> In-Reply-To: <024801c3619e$6fb907b0$0300000c@DFNJGL21> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Spencer Dawkins wrote: > To the chairs - if this is seriously off-topic for multi6, please > feel free to say so... I don't have any problem to move this elsewhere, if needed.... > The problem with having session layer functionality (as > I understand it) underneath the transport layer, is that > so much of transport-layer functionality is tied to a > single connection path (P-MTU and RTT, to name two). Exactly. Now, if we do the id/loc split at the IP layer, or anywhere between the packet forwarding function in the IP layer and the connection/transaction management at the upper layer, much of the above has to be thought again. Or at least we have to have a mechanism to tell the transport layer that the underlaying connection path is not the same any more. And if we want to have real load balancing, that is not enough. But I am certainly not a transport area person, and most probably I underestimate the potential problems... > If path changes reset all of this functionality, it's not clear > to me what the benefits of being "above" session-layer > functionality might be. Well, the transport API is one thing.... Another benefit might be found in the amount of signalling that is necessary to establish and change the paths. > And the bigger problem is that we have so many > transport protocols that are implemented in kernel > space - this was a huge problem for SCTP, and I > expect it will be a huge problem for DCCP as > well. If session-layer functionality is above transport, > end users can make decisions about deploying it; > if it's below transport, we're waiting for OS releases > before anything is possible. This shouldn't be "fatal", > but we even ended up deploying RTP-over-UDP > so we didn't have to wait for OS support of RTP > in kernels... OTOH, if the "session" layer was implemented in the kernel, it would become available to all applications at the same time. N.B. I am not quite sure whether we should call this "session" layer or not. In some ways it provides some of the same services that the OSI session layer presumably did, but in other ways it doesn't. --Pekka Nikander From owner-multi6@ops.ietf.org Wed Aug 13 13:48:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27573 for ; Wed, 13 Aug 2003 13:48:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mzjJ-0005Z8-Tv for multi6-data@psg.com; Wed, 13 Aug 2003 17:48:13 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.20) id 19mzj8-0005YV-Lc for multi6@ops.ietf.org; Wed, 13 Aug 2003 17:48:03 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h7DHmExS086778; Wed, 13 Aug 2003 19:48:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 13 Aug 2003 19:47:42 +0200 Subject: Re: Whither a session layer, and where (was Re: Consensus on identifier/locator split?) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Pekka Nikander From: Iljitsch van Beijnum In-Reply-To: <3F3A7416.4030401@nomadiclab.com> Message-Id: <3CEB2B55-CDB6-11D7-9024-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-19.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On woensdag, aug 13, 2003, at 19:23 Europe/Amsterdam, Pekka Nikander wrote: >> The problem with having session layer functionality (as >> I understand it) underneath the transport layer, is that >> so much of transport-layer functionality is tied to a >> single connection path (P-MTU and RTT, to name two). > Exactly. All of this is dynamic. If we only change this when necessary there shouldn't be too many problems. (Could even drop a few packets on purpose to trigger slow start for TCP.) > Now, if we do the id/loc split at the IP layer, > or anywhere between the packet forwarding function in the > IP layer and the connection/transaction management at the > upper layer, much of the above has to be thought again. There are two cases: 1. Existing applications 2. Applications that are modified to take advantage of new opportunities offered by the new paradigm I think we need to focus mostly on 1., but some people are only interested in 2. Yes, if we can throw out all the existing stuff we can make it much cleaner but we can't so we can't. > Or at least we have to have a mechanism to tell the > transport layer that the underlaying connection path is > not the same any more. Obviously if session and transport are both in the kernel there is a lot that can be done to make them work better together. It would be cool to have standardized mechanisms for this but in practice this is all about TCP anyway. >> And the bigger problem is that we have so many >> transport protocols that are implemented in kernel >> space - this was a huge problem for SCTP, > OTOH, if the "session" layer was implemented in the > kernel, it would become available to all applications > at the same time. We made the mistake of requiring changes to all applications once, let's not do it again. > N.B. I am not quite sure whether we should call this > "session" layer or not. In some ways it provides some > of the same services that the OSI session layer presumably > did, but in other ways it doesn't. You're right, but we don't have anything on the table at this point so how can we come up with a good name? From owner-multi6@ops.ietf.org Wed Aug 13 21:51:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14195 for ; Wed, 13 Aug 2003 21:51:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19n7F3-00078Y-HS for multi6-data@psg.com; Thu, 14 Aug 2003 01:49:29 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19n7F0-00076T-Ta for multi6@ops.ietf.org; Thu, 14 Aug 2003 01:49:27 +0000 From: Masataka Ohta Message-Id: <200308140139.KAA13268@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA13268; Thu, 14 Aug 2003 10:38:54 +0859 Subject: Re: Consensus on identifier/locator split? In-Reply-To: <20030813072438.GB61550@sunet.se> from Mans Nilsson at "Aug 13, 2003 09:24:38 am" To: Mans Nilsson Date: Thu, 14 Aug 2003 10:38:54 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Mans; > Subject: Re: Consensus on identifier/locator split? Date: Wed, Aug 13, 2003 at 06:43:04AM +0859 Quoting Masataka Ohta (mohta@necom830.hpcl.titech.ac.jp): > > > > However, the split is at the IP layer, because it should be available > > to all the transport layers. > > > > The set of a limited number of transport protocol is not the Internet > > Protocol. > > This follows the path of least surprise for applications. Me likes. It is just an API issue to let applications over TCP work with least surprise, having nothing to do with the layer of separation. Read my draft. Masataka Ohta From owner-multi6@ops.ietf.org Wed Aug 13 21:52:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14214 for ; Wed, 13 Aug 2003 21:52:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19n7FO-00079G-25 for multi6-data@psg.com; Thu, 14 Aug 2003 01:49:50 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19n7FL-00078y-FH for multi6@ops.ietf.org; Thu, 14 Aug 2003 01:49:47 +0000 From: Masataka Ohta Message-Id: <200308140134.KAA13243@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA13243; Thu, 14 Aug 2003 10:34:34 +0900 Subject: Re: MIPv6 hopeless In-Reply-To: <000001c36126$9b985890$efe3fea9@bagnulo> from marcelo bagnulo at "Aug 12, 2003 08:08:11 pm" To: marcelo bagnulo Date: Thu, 14 Aug 2003 10:34:33 +0859 () CC: "'Christian Huitema'" , "'J. Noel Chiappa'" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Marcelo; > Moreover, as you mention, the role of the HA is not appropriate for > multi-homing support. Then, which part of MIPv6 basic protocol, > The basic protocol, i.e. the packet formats required to provide > multi-homing support are similar to those required to provide mobility > support (BU, BA), so the protocol itself can be reused (i am not talking > about node behaviors or even roles defined by MIPv6) are you saying, can be reused? Ones between MN and CN? How is the security, then? > I agree with you that the mobile node behavior (in particular the > timers) are not suitable to be used to provide multi-homing support. It should be noted that the behavior is not suitable to be used to provide mobility (because it is not suitable for any application), either, which is one of a reason among many why I say MIPv6 hopeless. Masataka Ohta From owner-multi6@ops.ietf.org Thu Aug 14 11:08:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14265 for ; Thu, 14 Aug 2003 11:08:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19nJfz-0000Iw-P3 for multi6-data@psg.com; Thu, 14 Aug 2003 15:06:07 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.20) id 19nJfv-0000Ii-Gb for multi6@ops.ietf.org; Thu, 14 Aug 2003 15:06:03 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id AB95943164; Thu, 14 Aug 2003 17:06:02 +0200 (CEST) Received: from bagnulo (vpn-252-210.uc3m.es [163.117.252.210]) by smtp02.uc3m.es (Postfix) with ESMTP id 3D30599FBC; Thu, 14 Aug 2003 17:05:54 +0200 (CEST) From: "marcelo bagnulo" To: "'Masataka Ohta'" Cc: "'Christian Huitema'" , "'J. Noel Chiappa'" , Subject: RE: MIPv6 hopeless Date: Thu, 14 Aug 2003 12:06:01 -0300 Message-ID: <000001c36275$95c2c090$c4ba28c8@bagnulo> 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, Build 10.0.2627 Importance: Normal In-Reply-To: <200308140134.KAA13243@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-13.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > The basic protocol, i.e. the packet formats required to provide > > multi-homing support are similar to those required to > provide mobility > > support (BU, BA), so the protocol itself can be reused (i am not > > talking about node behaviors or even roles defined by MIPv6) > > are you saying, can be reused? Yes. I mean, suppose you (host1) are in a multi-homed site and you have multiple addresses. You are currently using one to communicate with host2. Suddenly a outage occurs along the path that you are using to communicate. What you need is a signaling mechanism that allows you to: 1- Inform host2 that an alternative address is to be used to continue with the communication. This is what BU message is for in mobility, so it seems reasonable that it is suitable for this task) 2- A mechanism to enable the end of the communication to identify packets with alternative addresses as belonging to the initial communication (this is what the Type 2 Routing header and Home address option is used for in mobility, so again they are good candidates) Clearly, you need to build alternative triggering mechanism. I mean, in mobility, BUs are triggered by movement detection mechanism. In this case you are not moving so this is not useful. What is needed is a failure detection mechanism that is the one that will trigger the BUs. This mechanism is not provided by MIP. Important benefits are achieved if this mechanism does not impose modification in host2 > > Ones between MN and CN? How is the security, then? > This is the difficult part, i guess. MIP security is based in the RR procedure, which implies connectivity through both paths. However in the multi-homing scenario, you want to use an alternative path because the former path is no longer available, so you cannot perform the RR procedure once that the outage has occurred. However, there is another relevant difference between multi-homing and mobility that is that the multihomed host knows all the available addresses in advance. So, it is possible to perform the RR procedure authorizing future bindings with all the alternative addresses available, so that in case of an outage, there is BU authorization data available for all the alternative addresses. The problem with this is that the authorization data has a limited lifetime, so you need to acquire valid authorization data periodically. This may not be problem, since you could use the RR procedure packet exchange as a failure detection mechanism if the frequency is increased. Another problem is that the binding information in the CN has a limited lifetime also in order to prevent time shifting attacks (yes, time shifting attacks do exist and no, i am not inventing new terminology here) IMHO this issue cannot be solved without introducing some (minor) changes in host2 behavior. The problem here is that time shifting attacks prevention is based in probing that the communication end is still there. However in the multi-homing case, the other node is not there (i mean, it is there but there is no path to it), so you need to differentiate the case of a time shifting attack where the other end is not there and the case where the host is still there but there is no path to it. The tool that can be use to cope with this is ICMP messaging, since when there is no route to the hosts, an ICMP message is generated. This way, the communication parties can tell whether they are victims of a time shifting attack (there is an available route, but the host is no longer there) or there is no route to the host. Regards, marcelo > > I agree with you that the mobile node behavior (in particular the > > timers) are not suitable to be used to provide multi-homing support. > > It should be noted that the behavior is not suitable to be > used to provide mobility (because it is not suitable for any > application), either, which is one of a reason among many why > I say MIPv6 hopeless. > > Masataka Ohta > From owner-multi6@ops.ietf.org Fri Aug 15 13:12:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04882 for ; Fri, 15 Aug 2003 13:12:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ni49-000D6A-R8 for multi6-data@psg.com; Fri, 15 Aug 2003 17:08:41 +0000 Received: from [139.175.54.12] (helo=seed.net.tw) by psg.com with esmtp (Exim 4.20) id 19ni46-000D5v-TG for multi6@ops.ietf.org; Fri, 15 Aug 2003 17:08:39 +0000 Received: from [203.70.216.162] (port=3334 helo=companyua5it71) by seed.net.tw with smtp (Seednet 4.14:1) id 19ni44-0005E1-IJ for multi6@ops.ietf.org; Sat, 16 Aug 2003 01:08:36 +0800 Message-ID: <002b01c3634f$d440ab40$0100a8c0@companyua5it71> From: "Su Po-chou" To: Subject: storage size of ifr6 isn't know Date: Sat, 16 Aug 2003 01:08:02 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C36392.D77F3900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,HTML_30_40 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C36392.D77F3900 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi all, I wrote a program which want to show my ipv6 addr, but it does = work. Could there anyone can give me some suggestions? Thanks. When I compile my code, it will show =20 =20 [root@localhost else]# gcc -o ipmac ipmac.c ipmac.c: In function `main': ipmac.c:33: storage size of `ifr6' isn't known [root@localhost else]# Below is my source code. #include #include #include #include #include #include #include #include #include #include #include #include #include #include char iface[] =3D "eth1"; int main (int argc, char **argv) { int s; char mac[6]; char ip[12]; struct sockaddr_in6 sa6; struct in6_ifreq ifr6; unsigned long prefix_len; s =3D socket (AF_INET6, SOCK_STREAM, 0); if (s < 0) { printf ("socket screwup\n"); exit (1); } =20 memset(&ifr6, 0, sizeof(ifr6)); strncpy(ifr6.ifr_name, iface, sizeof(ifr6.ifr_name)); =20 memcpy((char *) &ifr6.ifr6_addr, (char *) &sa6.sin6_addr, sizeof(struct in6_addr)); =20 if (ioctl (s, SIOCDIFADDR, &ifr6) < 0) printf ("ip screwed up\n"); /* then printf the addr */ return 0; } ------=_NextPart_000_0021_01C36392.D77F3900 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi all,
          I=20 wrote a program which want to show my ipv6 addr, but it does = work.
          Could=20 there anyone can give me some suggestions?   = Thanks.
 
          &nbs= p;      When=20 I compile my code, it will=20 show       
  
          &nbs= p;   =20   [root@localhost else]# gcc -o ipmac=20 ipmac.c
          &n= bsp;     =20 ipmac.c: In function=20 `main':
          &n= bsp;     =20 ipmac.c:33: storage size of `ifr6' isn't=20 known
          &nbs= p;     =20 [root@localhost else]#
Below is my source code.
 
#include <sys/types.h>
#include=20 <sys/socket.h>
#include <sys/ioctl.h>
#include=20 <netinet/in.h>
#include <net/if.h>
#include=20 <net/if_arp.h>
#include <stdio.h>
#include=20 <errno.h>
#include <fcntl.h>
#include=20 <ctype.h>
#include <stdlib.h>
#include=20 <string.h>
#include <unistd.h>
#include=20 <netdb.h>
 
char iface[] =3D "eth1";
int
main (int argc, char **argv)
{
  = int=20 s;
  char mac[6];
  char ip[12];
 =20 struct sockaddr_in6 sa6;
  struct in6_ifreq ifr6;
  = unsigned=20 long prefix_len;
 
 
  s =3D socket (AF_INET6, SOCK_STREAM, = 0);
  if (s=20 < 0)
    {
      printf = ("socket screwup\n");
      exit=20 (1);
    }
  
memset(&ifr6, 0, = sizeof(ifr6));
strncpy(ifr6.ifr_name,=20 iface, sizeof(ifr6.ifr_name));
 
memcpy((char *)=20 &ifr6.ifr6_addr, (char *)=20 &sa6.sin6_addr,
      sizeof(struct=20 in6_addr));
 
  if (ioctl (s, SIOCDIFADDR, &ifr6) = <=20 0)
    printf ("ip screwed up\n");
 
  /* then printf the addr */
 
  return 0;
}
------=_NextPart_000_0021_01C36392.D77F3900-- From owner-multi6@ops.ietf.org Mon Aug 18 08:28:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17504 for ; Mon, 18 Aug 2003 08:28:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19oj2h-000AYC-Qk for multi6-data@psg.com; Mon, 18 Aug 2003 12:23:23 +0000 Received: from [130.244.10.138] (helo=dhcp-168-17-23.autonomica.se) by psg.com with esmtp (Exim 4.20) id 19oj2e-000AXz-Vi for multi6@ops.ietf.org; Mon, 18 Aug 2003 12:23:21 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-23.autonomica.se (8.12.9/8.10.2) with ESMTP id h7ICNKpC000575 for ; Mon, 18 Aug 2003 14:23:20 +0200 (CEST) Date: Tue, 12 Aug 2003 15:48:40 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Subject: Some comments on Tonys question From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-11.1 required=5.0 tests=BAYES_20,DATE_IN_PAST_96_XX,PGP_SIGNATURE, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After Vienna, there are two design teams working on solutions. I expect the discussion following Tonys question to be useful input to both of the teams. Calling consensus for or against is hard to do without more specific details. We have also in front of us the task of merging or picking the result of one of the teams. I don't see a point in discussing this before we in more detail know what they will propose. But I think the discussion following Tonys post was good. As for if the id/loc discussion belongs in multi6, I absolutely think it does. As Sean said, as long as work is being done somewhere that is better than arguing where it should be. In general I believe that multi6 should weigh the operational impact for and against all solutions, as well as look at what solution is most scalable, feasible, etc in the long run. multi6 job is to define this solution to the detail we need. Where the development of a protocol for this is done, will be for the ADs in the future to decide. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPzjwOqarNKXTPFCVEQLQUgCg/R4KiF2wlgJ5qEjfqNcITiVqaZ4AniKA PZ+0oOkdO/c4ORK9LTno8/7q =ZkGY -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Aug 18 08:29:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17556 for ; Mon, 18 Aug 2003 08:29:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19oj2p-000AYt-3Y for multi6-data@psg.com; Mon, 18 Aug 2003 12:23:31 +0000 Received: from [130.244.10.138] (helo=dhcp-168-17-23.autonomica.se) by psg.com with esmtp (Exim 4.20) id 19oj2m-000AYZ-Rb for multi6@ops.ietf.org; Mon, 18 Aug 2003 12:23:29 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-23.autonomica.se (8.12.9/8.10.2) with ESMTP id h7ICNEpC000572; Mon, 18 Aug 2003 14:23:17 +0200 (CEST) Date: Mon, 11 Aug 2003 19:38:06 +0200 Subject: Re: Identification, layering, transactions and universal connectivity Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Spencer Dawkins" , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <914C6C64-CC22-11D7-9832-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.6 required=5.0 tests=BAYES_01,DATE_IN_PAST_96_XX,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I should have sent this mail to the list a week ago, I am on vacation and am having some troubles with accessing my email. Sean and Randy are watching instead. >> p.s. How off-topic is this thread for multi6? > There doesn't seem any other place where it is on topic, though... I think this is on topic for multi6 > > Wasn't the IAB going to create a list? Uhm ,where they? I thought they where going to come back with some comments? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPzfUhKarNKXTPFCVEQLdFwCgw7ZKR5HKEUBoq+tizSfqpB604WUAoInc DlDYspcVAQWOfAZTTeFIPDDc =C9v2 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Aug 19 08:37:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07374 for ; Tue, 19 Aug 2003 08:37:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19p5gr-000BUx-1N for multi6-data@psg.com; Tue, 19 Aug 2003 12:34:21 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.20) id 19p5gn-000BUc-JA for multi6@ops.ietf.org; Tue, 19 Aug 2003 12:34:17 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7JCXT4C008790; Tue, 19 Aug 2003 06:33:30 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h7JCXSQ02605; Tue, 19 Aug 2003 14:33:28 +0200 (MEST) Date: Tue, 19 Aug 2003 14:30:21 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Consensus on identifier/locator split? To: Tony Li Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > I'd just like to get a sense from the group about where > we are so far. Do we have consensus about splitting > the address into locators and identifiers? Note that > I'm NOT asking about specifics, like "how big", "what > mappings exist", "is it secure", etc. Do we agree that > we want to go down this path? [Catching up on email] Yes, I think we should go down this path. Erik From owner-multi6@ops.ietf.org Tue Aug 19 12:10:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20611 for ; Tue, 19 Aug 2003 12:10:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19p928-0005Zf-6k for multi6-data@psg.com; Tue, 19 Aug 2003 16:08:32 +0000 Received: from [198.24.6.3] (helo=imr2.ericy.com) by psg.com with esmtp (Exim 4.20) id 19p921-0005ZN-U4 for multi6@ops.ietf.org; Tue, 19 Aug 2003 16:08:26 +0000 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h7JG8PAP008330 for ; Tue, 19 Aug 2003 11:08:25 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 19 Aug 2003 11:06:24 -0500 Received: from [142.133.72.84] (142.133.72.84 [142.133.72.84]) by eammlex033.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QQQ7PZRZ; Tue, 19 Aug 2003 12:03:44 -0400 Subject: TEST From: Wassim Haddad Reply-To: Wassim.Haddad@ericsson.ca To: multi6@ops.ietf.org Content-Type: text/plain Organization: Ericsson Research Canada Message-Id: <1061309015.4361.174.camel@ddgflw21> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 19 Aug 2003 12:03:35 -0400 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Please ignore From owner-multi6@ops.ietf.org Tue Aug 19 14:26:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28116 for ; Tue, 19 Aug 2003 14:26:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pB8o-000JOw-Eg for multi6-data@psg.com; Tue, 19 Aug 2003 18:23:34 +0000 Received: from [198.24.6.3] (helo=imr2.ericy.com) by psg.com with esmtp (Exim 4.20) id 19pB8m-000JOk-AS for multi6@ops.ietf.org; Tue, 19 Aug 2003 18:23:32 +0000 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h7JINWAP026847; Tue, 19 Aug 2003 13:23:32 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 19 Aug 2003 13:23:17 -0500 Received: from [142.133.72.84] (142.133.72.84 [142.133.72.84]) by eammlex033.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QQQ7P5Q4; Tue, 19 Aug 2003 14:25:06 -0400 Subject: Re: Consensus on identifier/locator split? From: Wassim Haddad Reply-To: Wassim.Haddad@ericsson.ca To: Tony Li Cc: multi6@ops.ietf.org Content-Type: text/plain Organization: Ericsson Research Canada Message-Id: <1061317497.4355.5.camel@ddgflw21> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 19 Aug 2003 14:24:57 -0400 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I believe that an explicit split between locator and identifier will solve many problems. I personally support this idea. Regards, Wassim Haddad Ericsson Research Canada From owner-multi6@ops.ietf.org Wed Aug 20 17:44:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13029 for ; Wed, 20 Aug 2003 17:44:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pah6-000FL3-7k for multi6-data@psg.com; Wed, 20 Aug 2003 21:40:40 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19pah3-000FKB-3f for multi6@ops.ietf.org; Wed, 20 Aug 2003 21:40:37 +0000 From: Masataka Ohta Message-Id: <200308202124.GAA13734@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA13734; Thu, 21 Aug 2003 06:24:34 +0900 Subject: Re: MIPv6 hopeless In-Reply-To: <000001c36275$95c2c090$c4ba28c8@bagnulo> from marcelo bagnulo at "Aug 14, 2003 12:06:01 pm" To: marcelo bagnulo Date: Thu, 21 Aug 2003 06:24:33 +0859 () CC: "'Christian Huitema'" , "'J. Noel Chiappa'" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-7.7 required=5.0 tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Marcelo; As I presented at Vienna, there is certain relationship between mobility and multihoming, because both handles multiple addresses, but the relationship is less than expected. > 1- Inform host2 that an alternative address is to be used to continue > with the communication. This is what BU message is for in mobility, so > it seems reasonable that it is suitable for this task) And security is the issue. > 2- A mechanism to enable the end of the communication to identify > packets with alternative addresses as belonging to the initial > communication (this is what the Type 2 Routing header and Home address > option is used for in mobility, so again they are good candidates) Routing header is a waste of bytes and a possible cause of MTU reduction problem. > Clearly, you need to build alternative triggering mechanism. I mean, in > mobility, BUs are triggered by movement detection mechanism. In this > case you are not moving so this is not useful. What is needed is a > failure detection mechanism that is the one that will trigger the BUs. > This mechanism is not provided by MIP. Important benefits are achieved > if this mechanism does not impose modification in host2 A properly designed mobility protocol should support multiple home agents at multiple locations. But, the feature is missing in MIPv6. Note that an MIPv6 feature of having multiple home agents at a single subnet is nothing more than a useless complication. So, there is nothing to be reused and we should define a packet format to support site multihoming, which can be reused to support multiple home agents at multiple subnets. > > Ones between MN and CN? How is the security, then? > This is the difficult part, i guess. > > MIP security is based in the RR procedure, MIP security is based on shared secret shared between mobile hosts and home agents. Masataka Ohta From owner-multi6@ops.ietf.org Wed Aug 20 21:56:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25298 for ; Wed, 20 Aug 2003 21:56:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pedX-000Il1-6Z for multi6-data@psg.com; Thu, 21 Aug 2003 01:53:15 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.20) id 19pedU-000IkS-9r for multi6@ops.ietf.org; Thu, 21 Aug 2003 01:53:12 +0000 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 h7L1r7tU005457; Wed, 20 Aug 2003 21:53:08 -0400 Message-Id: <200308210153.h7L1r7tU005457@ginger.lcs.mit.edu> From: Tim Shepard To: Masataka Ohta cc: multi6@ops.ietf.org Subject: Re: MIPv6 hopeless In-reply-to: Your message of Thu, 21 Aug 2003 06:24:33 +0859. <200308202124.GAA13734@necom830.hpcl.titech.ac.jp> Date: Wed, 20 Aug 2003 21:53:07 -0400 X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > A properly designed mobility protocol should support multiple > home agents at multiple locations. And I would also like to see support for the homeless mobile node. So "multiple home agents" should range from zero to many. -Tim Shepard From owner-multi6@ops.ietf.org Wed Aug 20 22:40:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26887 for ; Wed, 20 Aug 2003 22:40:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pfMm-000OuC-1F for multi6-data@psg.com; Thu, 21 Aug 2003 02:40:00 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19pfMj-000Ott-Iu for multi6@ops.ietf.org; Thu, 21 Aug 2003 02:39:57 +0000 From: Masataka Ohta Message-Id: <200308210225.LAA15104@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA15104; Thu, 21 Aug 2003 11:25:20 +0900 Subject: Re: MIPv6 hopeless In-Reply-To: <200308210153.h7L1r7tU005457@ginger.lcs.mit.edu> from Tim Shepard at "Aug 20, 2003 09:53:07 pm" To: Tim Shepard Date: Thu, 21 Aug 2003 11:25:19 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Tim Shepard; > > A properly designed mobility protocol should support multiple > > home agents at multiple locations. > > And I would also like to see support for the homeless mobile node. > So "multiple home agents" should range from zero to many. I'm afraid that the analogy between multihoming and mobility works here and that the homeless mobile node will be as useful as a zero homed sites in which hosts have zero prefixes. Masataka Ohta From owner-multi6@ops.ietf.org Thu Aug 21 02:21:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18817 for ; Thu, 21 Aug 2003 02:21:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pinN-000PCG-Am for multi6-data@psg.com; Thu, 21 Aug 2003 06:19:41 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.20) id 19pinJ-000PBr-Ec for multi6@ops.ietf.org; Thu, 21 Aug 2003 06:19:37 +0000 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id D33A71C; Thu, 21 Aug 2003 09:29:06 +0300 (EEST) Message-ID: <3F446487.6030201@nomadiclab.com> Date: Thu, 21 Aug 2003 09:19:51 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta Cc: Tim Shepard , multi6@ops.ietf.org Subject: Re: MIPv6 hopeless References: <200308210225.LAA15104@necom830.hpcl.titech.ac.jp> In-Reply-To: <200308210225.LAA15104@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> A properly designed mobility protocol should support multiple >>> home agents at multiple locations. >> >> And I would also like to see support for the homeless mobile node. >> So "multiple home agents" should range from zero to many. > > I'm afraid that the analogy between multihoming and mobility > works here and that the homeless mobile node will be as useful > as a zero homed sites in which hosts have zero prefixes. Which, IMHO, are both fairly useful in certain situations :-) --Pekka NIkander From owner-multi6@ops.ietf.org Thu Aug 21 02:31:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19086 for ; Thu, 21 Aug 2003 02:31:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19piy9-0000Jr-ER for multi6-data@psg.com; Thu, 21 Aug 2003 06:30:49 +0000 Received: from [65.174.124.36] (helo=dmz1.procket.com) by psg.com with esmtp (Exim 4.20) id 19piy5-0000JA-CK for multi6@ops.ietf.org; Thu, 21 Aug 2003 06:30:45 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id D099223C54; Wed, 20 Aug 2003 22:40:39 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h7L6UhYB007537; Wed, 20 Aug 2003 23:30:43 -0700 (PDT) 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: MIPv6 hopeless Date: Wed, 20 Aug 2003 23:30:43 -0700 Message-ID: Thread-Topic: MIPv6 hopeless Thread-Index: AcNnj00+9g4gwoVZRo2FKV6kNlIYdwAHinmQ From: "Tony Li" To: "Masataka Ohta" , "Tim Shepard" Cc: X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Indeed. What's the difference between a zero homed host and one that simply acquired a DHCP address? Also, the protocol should not require modifications to support multiple home agents. That should be a property of the implementation since the interaction should only be pairwise at any given time. Tony | -----Original Message----- | From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp]=20 | Sent: Wednesday, August 20, 2003 7:26 PM | To: Tim Shepard | Cc: multi6@ops.ietf.org | Subject: Re: MIPv6 hopeless | =20 | =20 | Tim Shepard; | =20 | > > A properly designed mobility protocol should support multiple | > > home agents at multiple locations. | >=20 | > And I would also like to see support for the homeless=20 | mobile node. | > So "multiple home agents" should range from zero to many. | =20 | I'm afraid that the analogy between multihoming and mobility | works here and that the homeless mobile node will be as useful | as a zero homed sites in which hosts have zero prefixes. | =20 | Masataka Ohta | =20 | =20 From owner-multi6@ops.ietf.org Thu Aug 21 04:58:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23759 for ; Thu, 21 Aug 2003 04:58:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pkoQ-000DGE-4I for multi6-data@psg.com; Thu, 21 Aug 2003 08:28:54 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.20) id 19pkoN-000DG2-D8 for multi6@ops.ietf.org; Thu, 21 Aug 2003 08:28:51 +0000 Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h7L8R3Rc029464; Thu, 21 Aug 2003 18:27:13 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030821174347.019facf0@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Aug 2003 17:45:23 +1000 To: Kurt Erik Lindqvist , Iljitsch van Beijnum From: Geoff Huston Subject: Re: Identification, layering, transactions and universal connectivity Cc: "Spencer Dawkins" , In-Reply-To: <914C6C64-CC22-11D7-9832-000393A638B2@kurtis.pp.se> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-12.8 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > Wasn't the IAB going to create a list? >Uhm ,where they? I thought they where going to come back with some >comments? Look for the list announcement and related activity in early September. regards, Geoff From owner-multi6@ops.ietf.org Thu Aug 21 07:24:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29047 for ; Thu, 21 Aug 2003 07:24:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pnVU-0008Mk-ID for multi6-data@psg.com; Thu, 21 Aug 2003 11:21:32 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19pnVR-0008Lg-KW for multi6@ops.ietf.org; Thu, 21 Aug 2003 11:21:29 +0000 From: Masataka Ohta Message-Id: <200308211107.UAA17247@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA17247; Thu, 21 Aug 2003 20:07:39 +0900 Subject: Re: MIPv6 hopeless In-Reply-To: from Tony Li at "Aug 20, 2003 11:30:43 pm" To: Tony Li Date: Thu, 21 Aug 2003 20:07:37 +0859 () CC: Tim Shepard , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.3 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony; > Indeed. What's the difference between a zero homed host and > one that simply acquired a DHCP address? The number of addresses. > Also, the protocol should not require modifications to support > multiple home agents. That should be a property of the implementation > since the interaction should only be pairwise at any given time. Which protocol? As for the multihoming protocol, yes. Masataka Ohta From owner-multi6@ops.ietf.org Thu Aug 21 09:22:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04283 for ; Thu, 21 Aug 2003 09:22:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ppMU-000LO6-JH for multi6-data@psg.com; Thu, 21 Aug 2003 13:20:22 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.20) id 19ppMP-000LN7-9R for multi6@ops.ietf.org; Thu, 21 Aug 2003 13:20:17 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 7F7984313D; Thu, 21 Aug 2003 15:20:16 +0200 (CEST) Received: from bagnulo (vpn-252-210.uc3m.es [163.117.252.210]) by smtp01.uc3m.es (Postfix) with ESMTP id A7A2399E66; Thu, 21 Aug 2003 15:20:13 +0200 (CEST) From: "marcelo bagnulo" To: "'Masataka Ohta'" Cc: "'Christian Huitema'" , "'J. Noel Chiappa'" , Subject: RE: MIPv6 hopeless Date: Thu, 21 Aug 2003 10:20:07 -0300 Message-ID: <007301c367e6$f5981670$efe3fea9@bagnulo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200308202124.GAA13734@necom830.hpcl.titech.ac.jp> X-Spam-Status: No, hits=-13.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Mensaje original----- > De: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp]=20 > Enviado el: mi=E9rcoles, 20 de agosto de 2003 18:26 > Para: marcelo bagnulo > CC: 'Christian Huitema'; 'J. Noel Chiappa'; multi6@ops.ietf.org > Asunto: Re: MIPv6 hopeless >=20 >=20 > Marcelo; >=20 > As I presented at Vienna, there is certain relationship=20 > between mobility and multihoming, because both handles=20 > multiple addresses, but the relationship is less than expected. >=20 > > 1- Inform host2 that an alternative address is to be used=20 > to continue=20 > > with the communication. This is what BU message is for in=20 > mobility, so=20 > > it seems reasonable that it is suitable for this task) >=20 > And security is the issue. agree >=20 > > 2- A mechanism to enable the end of the communication to identify=20 > > packets with alternative addresses as belonging to the initial=20 > > communication (this is what the Type 2 Routing header and=20 > Home address=20 > > option is used for in mobility, so again they are good candidates) >=20 > Routing header is a waste of bytes and a possible cause of > MTU reduction problem. >=20 May agree with this also. However, reusing existing aproved protocols also has benefits > > Clearly, you need to build alternative triggering=20 > mechanism. I mean,=20 > > in mobility, BUs are triggered by movement detection mechanism. In=20 > > this case you are not moving so this is not useful. What is=20 > needed is=20 > > a failure detection mechanism that is the one that will trigger the=20 > > BUs. This mechanism is not provided by MIP. Important benefits are=20 > > achieved if this mechanism does not impose modification in host2 >=20 > A properly designed mobility protocol should support multiple=20 > home agents at multiple locations. >=20 The aplication of MIP to multi-homing support that i am describing does not use a home agent > But, the feature is missing in MIPv6. Note that an MIPv6=20 > feature of having multiple home agents at a single subnet is=20 > nothing more than a useless complication. >=20 > So, there is nothing to be reused and we should define a=20 > packet format to support site multihoming, which can be=20 > reused to support multiple home agents at multiple subnets. >=20 > > > Ones between MN and CN? How is the security, then? >=20 > > This is the difficult part, i guess. > >=20 > > MIP security is based in the RR procedure, >=20 > MIP security is based on shared secret shared between mobile=20 > hosts and home agents. >=20 NO. Read mipv6 specification and in particular read the description of return routability procedure Regards, marcelo > Masataka Ohta >=20 >=20 From owner-multi6@ops.ietf.org Thu Aug 21 09:30:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04677 for ; Thu, 21 Aug 2003 09:30:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ppVp-000MTx-BC for multi6-data@psg.com; Thu, 21 Aug 2003 13:30:01 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.20) id 19ppVl-000MT3-9f for multi6@ops.ietf.org; Thu, 21 Aug 2003 13:29:57 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 7CDE74313A; Thu, 21 Aug 2003 15:29:56 +0200 (CEST) Received: from bagnulo (vpn-252-210.uc3m.es [163.117.252.210]) by smtp01.uc3m.es (Postfix) with ESMTP id 8558A99E66; Thu, 21 Aug 2003 15:29:53 +0200 (CEST) From: "marcelo bagnulo" To: "'Tony Li'" , "'Masataka Ohta'" , "'Tim Shepard'" Cc: Subject: RE: MIPv6 hopeless Date: Thu, 21 Aug 2003 10:29:56 -0300 Message-ID: <007401c367e8$51926c90$efe3fea9@bagnulo> 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, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > -----Mensaje original----- > De: owner-multi6@ops.ietf.org > [mailto:owner-multi6@ops.ietf.org] En nombre de Tony Li > Enviado el: jueves, 21 de agosto de 2003 3:31 > Para: Masataka Ohta; Tim Shepard > CC: multi6@ops.ietf.org > Asunto: RE: MIPv6 hopeless > > > > > Indeed. What's the difference between a zero homed host and > one that simply acquired a DHCP address? > > Also, the protocol should not require modifications to > support multiple home agents. I guess you are talking about MIPv6 here, right? If not, stop reading. If yes, i think that in order tu use the mipv6 protocol in a multi-homed scenario, there is no need of a home agent. I mean, a host within the multi-homed site has multiple prefixes, and suppose that all of them can be used to initiate a communication. So dependin on a number of considerations (policing, availability, which prefix is selected by the other end, etc) one of those prefixes (PrefA) is selected to be used in a certain communication. T that moment, PrefA::Host becomes the Home address and all the other addresses available becomes potential Care-off addresses. Whene there is a failure, the host send a BU to move the communication from the HoA to one of the other CoA available. So no need of HA (or if you want, the mobile node is also the HA) Regards, marcelo > That should be a property of > the implementation since the interaction should only be > pairwise at any given time. > > Tony > > > | -----Original Message----- > | From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > | Sent: Wednesday, August 20, 2003 7:26 PM > | To: Tim Shepard > | Cc: multi6@ops.ietf.org > | Subject: Re: MIPv6 hopeless > | > | > | Tim Shepard; > | > | > > A properly designed mobility protocol should support multiple > | > > home agents at multiple locations. > | > > | > And I would also like to see support for the homeless > | mobile node. > | > So "multiple home agents" should range from zero to many. > | > | I'm afraid that the analogy between multihoming and mobility > | works here and that the homeless mobile node will be as useful > | as a zero homed sites in which hosts have zero prefixes. > | > | Masataka Ohta > | > | > From owner-multi6@ops.ietf.org Thu Aug 21 15:33:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25219 for ; Thu, 21 Aug 2003 15:33:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pv89-00067K-Nz for multi6-data@psg.com; Thu, 21 Aug 2003 19:29:57 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19pv84-00064t-1a for multi6@ops.ietf.org; Thu, 21 Aug 2003 19:29:52 +0000 From: Masataka Ohta Message-Id: <200308211914.EAA25512@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id EAA25512; Fri, 22 Aug 2003 04:14:32 +0900 Subject: Re: MIPv6 hopeless In-Reply-To: <007301c367e6$f5981670$efe3fea9@bagnulo> from marcelo bagnulo at "Aug 21, 2003 10:20:07 am" To: marcelo bagnulo Date: Fri, 22 Aug 2003 04:14:32 +0859 () CC: "'Christian Huitema'" , "'J. Noel Chiappa'" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-11.9 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Marcelo; > May agree with this also. However, reusing existing aproved protocols > also has benefits If only the protocols were hopeful. > > A properly designed mobility protocol should support multiple > > home agents at multiple locations. > The aplication of MIP to multi-homing support that i am describing does > not use a home agent A mobile host has a stable address(es) to be published by, say, DNS. Something taking care of the address(es) is the home agent. That is, you are either not describing mobility (because address changes as hosts move) or describing home agent aspect of mobility. > > MIP security is based on shared secret shared between mobile > > hosts and home agents. > > > > NO. > Read mipv6 specification and in particular read the description of > return routability procedure Read the draft and think. There is no return packet, if you have no idea on where to send a initial packet. Masataka Ohta From owner-multi6@ops.ietf.org Fri Aug 22 10:09:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25767 for ; Fri, 22 Aug 2003 10:09:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qCZD-000H1b-56 for multi6-data@psg.com; Fri, 22 Aug 2003 14:07:03 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.20) id 19qCYg-000Gyt-J7 for multi6@ops.ietf.org; Fri, 22 Aug 2003 14:06:30 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id D2FF143217; Fri, 22 Aug 2003 16:06:29 +0200 (CEST) Received: from bagnulo (vpn-252-210.uc3m.es [163.117.252.210]) by smtp01.uc3m.es (Postfix) with ESMTP id 8EF2E99E82; Fri, 22 Aug 2003 16:06:27 +0200 (CEST) From: "marcelo bagnulo" To: "'Masataka Ohta'" Cc: Subject: RE: MIPv6 hopeless Date: Fri, 22 Aug 2003 11:06:20 -0300 Message-ID: <000001c368b6$94fde670$efe3fea9@bagnulo> 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, Build 10.0.2627 Importance: Normal In-Reply-To: <200308211914.EAA25512@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-12.8 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > The aplication of MIP to multi-homing support that i am describing > > does not use a home agent > > A mobile host has a stable address(es) to be published by, say, DNS. > > Something taking care of the address(es) is the home agent. and the mobile node when it is at the home network? > > That is, you are either not describing mobility (because > address changes as hosts move) or describing home agent > aspect of mobility. > > > > MIP security is based on shared secret shared between mobile hosts > > > and home agents. > > > > > > > NO. > > Read mipv6 specification and in particular read the description of > > return routability procedure > > Read the draft and think. > > There is no return packet, if you have no idea on where to > send a initial packet. So, where is the shared secret? Regards, marcelo > > Masataka Ohta > > From owner-multi6@ops.ietf.org Mon Aug 25 02:46:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28631 for ; Mon, 25 Aug 2003 02:46:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rB2P-000Kdy-Ls for multi6-data@psg.com; Mon, 25 Aug 2003 06:41:13 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.20) id 19rB1e-000KJb-3e for multi6@ops.ietf.org; Mon, 25 Aug 2003 06:40:26 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.20) id 19rB1d-0001px-D5 for multi6@ops.ietf.org; Mon, 25 Aug 2003 15:40:25 +0900 Message-Id: <200308212140.h7LLeAN02198@gamma.isi.edu> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart To: IETF-Announce: ; Subject: RFC 3582 on Goals for IPv6 Site-Multihoming Architectures Cc: rfc-editor@rfc-editor.org, multi6@ops.ietf.org From: rfc-editor@rfc-editor.org Date: Thu, 21 Aug 2003 14:40:09 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_20,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3582 Title: Goals for IPv6 Site-Multihoming Architectures Author(s): J. Abley, B. Black, V. Gill Status: Informational Date: August 2003 Mailbox: jabley@isc.org, ben@layer8.net, vijaygill9@aol.com Pages: 9 Characters: 17045 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-multi6-multihoming-requirements-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3582.txt This document outlines a set of goals for proposed new IPv6 site-multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. This document is a product of the Site Multihoming in IPv6 Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030821143838.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3582 --OtherAccess Content-Type: Message/External-body; name="rfc3582.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030821143838.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Mon Aug 25 05:32:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06238 for ; Mon, 25 Aug 2003 05:32:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rDfc-000F0v-CC for multi6-data@psg.com; Mon, 25 Aug 2003 09:29:52 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.20) id 19rDfQ-000Euj-Pv for multi6@ops.ietf.org; Mon, 25 Aug 2003 09:29:41 +0000 From: Masataka Ohta Message-Id: <200308250909.SAA16424@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA16424; Mon, 25 Aug 2003 18:09:37 +0900 Subject: RE: MIPv6 hopeless To: marcelo@it.uc3m.es (marcelo bagnulo) Date: Mon, 25 Aug 3 18:09:35 JST Cc: mohta@necom830.hpcl.titech.ac.jp, multi6@ops.ietf.org In-Reply-To: <000001c368b6$94fde670$efe3fea9@bagnulo>; from "marcelo bagnulo" at Aug 22, 103 11:02 pm X-Mailer: ELM [version 2.3 PL11] X-Spam-Status: No, hits=-8.7 required=5.0 tests=BAYES_20,INVALID_DATE,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Marcelo; > > > The aplication of MIP to multi-homing support that i am describing > > > does not use a home agent > > > > A mobile host has a stable address(es) to be published by, say, DNS. > > > > Something taking care of the address(es) is the home agent. > > and the mobile node when it is at the home network? Are you saying that the mobile node is always at the home network? So? > > > NO. > > > Read mipv6 specification and in particular read the description of > > > return routability procedure > > > > Read the draft and think. > > > > There is no return packet, if you have no idea on where to > > send a initial packet. > > > So, where is the shared secret? Read the draft. Masataka Ohta From owner-multi6@ops.ietf.org Fri Aug 29 03:20:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20973 for ; Fri, 29 Aug 2003 03:20:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sdUB-0002zB-EG for multi6-data@psg.com; Fri, 29 Aug 2003 07:15:55 +0000 Received: from [134.193.143.167] (helo=kc-msxproto1.kc.umkc.edu) by psg.com with esmtp (Exim 4.22) id 19sdR5-0002h8-E5 for multi6@ops.ietf.org; Fri, 29 Aug 2003 07:12:43 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Aug 2003 02:12:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiple Address Service for Transport (MAST) Date: Fri, 29 Aug 2003 02:12:41 -0500 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390BAA77C4@KC-MAIL4.kc.umkc.edu> Thread-Topic: Multiple Address Service for Transport (MAST) Thread-Index: AcNt+Y98jVS8ely4TP+HZ3mWrRw/DAAAo2VA From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Dave Crocker" , X-OriginalArrivalTime: 29 Aug 2003 07:12:42.0017 (UTC) FILETIME=[EFE0A910:01C36DFC] X-Spam-Status: No, hits=0.2 required=5.0 tests=FROM_ENDS_IN_NUMS,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 >sal-00.txt> > > >Herewith the abstract for the proposal: > > Classic Internet transport protocols use a single source IP > address and a single destination IP address, as part of the > identification for an individual data flow. TCP includes > these in its definition of a connection and its calculation > of the header checksum. Hence the transport service is tied > to a particular IP address pair. This is problematic for > multi-homed hosts and for mobile hosts. Both have multiple > IP addresses but cannot use more than one, for any single > transport association (context). Multiple Address Service > for Transport (MAST) defines a mechanism that transparently > supports association of multiple IP addresses with any > transport association. It requires no change to the IP > infrastructure, and no change to IP modules or transport > modules in the end-systems. Instead, it defines a wedge > layer between IP and transport that operates only in the end > systems and affects only participating hosts. can you compare your proposal with=20 http://www.cs.ucla.edu/~bzhang/etcp/etcp_draft.txt They do have a running code.=20 From owner-multi6@ops.ietf.org Fri Aug 29 08:34:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17848 for ; Fri, 29 Aug 2003 08:34:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19siPg-00032O-AX for multi6-data@psg.com; Fri, 29 Aug 2003 12:31:36 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.22) id 19siPA-0002yN-Co for multi6@ops.ietf.org; Fri, 29 Aug 2003 12:31:04 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h7TCVJxS033901; Fri, 29 Aug 2003 14:31:21 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 29 Aug 2003 14:30:56 +0200 Subject: Re: where the indirection layer belongs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf@ietf.org, multi6@ops.ietf.org To: "Yuri Ismailov (KI/EAB)" From: Iljitsch van Beijnum In-Reply-To: <4E85E49D1F0CBF4F96EA08E335750D7D03F52BD3@Esealnt877.al.sw.ericsson.se> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [CC'ing multi6 as I don't think everyone there knows about this thread on the IETF discussion list, but please remove either ietf or multi6 if this discussion continues.] On vrijdag, aug 29, 2003, at 11:10 Europe/Amsterdam, Yuri Ismailov (KI/EAB) wrote: > Thirdly, if to stay below transport layer all efforts will not let go > beyond a device (host) level. Obviously, there is a need for naming > users, devices, content, services or anything else one might think > about. But aren't we squarely inside the application domain here? > This is still multihoming of devices, what about "multideviced" users? > If one has more than one device and wants to move a flow between > devices would this be possible if implemented below transport layer? > .... That's a good point. But first of all: let's not get too carried away with new and interesting problems thereby forgetting about actual needs that users have today. We need a way to allow multihoming in IPv6 that doesn't have the scaling problems our current IPv4 multihoming practices have. It's not uncommon to see a FQDN point to several IP addresses so that the service identified by the FQDN can be provided either by (a) multiple hosts, or (b) a host with multiple addresses. Now if we want to support moving from one addresses to another in the middle of an (application level) session, we have two choices: build a mechanism that assumes (a) and by extension also works with (b), or focus on (b) exclusively. It looks like Tony Hain wants to go for (a) while Keith Moore assumes (b), hence the insanity claims because a solution for (a), which by its nature can only reasonably implemented above TCP, is much more involved and less efficient than one that only supports (b), which can work on a per-packet basis below TCP and other transports. As a member of the multi6 design team that works on a (b) solution I'm convinced that such a solution will provide many benefits and should be developed and implemented. However, this doesn't say anything about the need for an (a) solution. Obviously (a) would be good to have. Peer to peer file sharing applications extensively use mechanisms like this, where they download parts of a file from different hosts. Also, the current socket API isn't exactly the optimum way for applications to interact with the network. It would make sense to create something new that sits between the transport(s) and the application, and delegate some tasks that are done by applications today, most notably name resolution. This allows us to implement new namespaces or new address formats without any pain to application developers or users stuck with applications that aren't actively maintained by developers. This would also be a good opportunity to create sensible ways for applications to ask for advanced services from the network. But the real question here is: does this new "thing" have to be a layer? In the layering system we have today, each layer talks to the underlying one on the local system, but it also interacts with the same layer on the remote end. I'm not convinced this is called for here. For instance, a host that implements the above could use a new advanced API to open a set of TCP sessions to all the addresses that a FQDN points to, and then distribute HTTP requests for the different parts of a file over these sessions. But on the other end of one or more of these sessions, there could be a regular HTTP server that is completely unaware of the new mechanisms and uses existing socket API calls. So yes, we need something new above the transport layer, but no, it shouldn't be a "layer". Iljitsch From owner-multi6@ops.ietf.org Fri Aug 29 17:15:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05830 for ; Fri, 29 Aug 2003 17:15:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sqWq-0008M4-Qm for multi6-data@psg.com; Fri, 29 Aug 2003 21:11:32 +0000 Received: from [160.36.56.50] (helo=klutz.cs.utk.edu) by psg.com with esmtp (Exim 4.22) id 19sqRw-0007xy-GJ for multi6@ops.ietf.org; Fri, 29 Aug 2003 21:06:28 +0000 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 17D981409D; Fri, 29 Aug 2003 17:06:28 -0400 (EDT) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07528-02; Fri, 29 Aug 2003 17:06:27 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 7167513FEA; Fri, 29 Aug 2003 17:06:27 -0400 (EDT) Date: Fri, 29 Aug 2003 17:06:27 -0400 From: Keith Moore To: Iljitsch van Beijnum Cc: moore@cs.utk.edu, yuri.ismailov@ericsson.com, ietf@ietf.org, multi6@ops.ietf.org Subject: Re: where the indirection layer belongs Message-Id: <20030829170627.49778fa0.moore@cs.utk.edu> In-Reply-To: References: <4E85E49D1F0CBF4F96EA08E335750D7D03F52BD3@Esealnt877.al.sw.ericsson.se> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > It's not uncommon to see a FQDN point to several IP addresses so that > the service identified by the FQDN can be provided either by > > (a) multiple hosts, or > (b) a host with multiple addresses. > > Now if we want to support moving from one addresses to another in the > middle of an (application level) session, we have two choices: build a > mechanism that assumes (a) and by extension also works with (b), or > focus on (b) exclusively. > > It looks like Tony Hain wants to go for (a) while Keith Moore assumes > (b), No. A client can't tell whether multiple addresses associated with an DNS name indicate multiple hosts or multiple addresses for the same host. No matter where the stabilization layer(s) live, using DNS as a means to map from identity to locations simply won't work. It might be good enough for initial connection (assuming that if a service exists on multiple hosts, any of them will do), but it's not good enough for re-establishing an already-open connection, because you might get a different host the next time. > hence the insanity claims because a solution for (a), I don't know whether Tony assumes (a) or not. But that has nothing to do with why I made that particular claim. > As a member of the multi6 design team that works on a (b) solution I'm > convinced that such a solution will provide many benefits and should > be developed and implemented. And I'm equally convinced that a solution that assumes (b) is a nonstarter. There is already too much practice that conflicts with it. Like it or not, DNS names are no longer "host" names in practice; they're "service" names. A service can be a host but it's not reasonable to assume that a service _is_ a host. > Also, the current socket API isn't exactly the optimum way for > applications to interact with the network. It would make sense to > create something new that sits between the transport(s) and the > application, and delegate some tasks that are done by applications > today, most notably name resolution. This allows us to implement new > namespaces or new address formats without any pain to application > developers or users stuck with applications that aren't actively > maintained by developers. No it doesn't. What it allows "us" to do is impose subtle changes in the behavior of lower layers, and introduce new failure modes, without giving applications any way to deal with them. > But the real question here is: does this new "thing" have to be a > layer? It depends on which "thing" you are talking about. For the L3-L4 thing, it's either a new layer or a change to an existing layer. If you have both the L4-L7 thing and the L3-L4 thing, the former is either a new layer or (my personal opinion) a new API that knowledgable apps call explicitly.