From owner-multi6@ops.ietf.org Mon Sep 3 12:36:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11929 for ; Mon, 3 Sep 2001 12:36:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15dwfA-0004UC-00 for multi6-data@psg.com; Mon, 03 Sep 2001 09:33:28 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15dwf9-0004U6-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 09:33:27 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f83GYK212149; Mon, 3 Sep 2001 18:34:20 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 3 Sep 2001 18:34:20 +0200 (CEST) From: Iljitsch van Beijnum To: Ramakrishna Gummadi cc: Subject: Re: Transport level multihoming In-Reply-To: Message-ID: <20010903182327.C5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk I'm way behind, trying to catch up, so I apologise if I'm repeating something that has been said earlier, but... On Tue, 7 Aug 2001, Ramakrishna Gummadi wrote: > Another problem with the transport-level multihoming is that > the number of failure modes that can be tolerated in a multi-tier > multihoming are decreased. For > example, consider the scenario where a site is dually-multihomed, while > each of the providers are triply multihomed to three different providers > each. The question is---how many addresses do the hosts in the site have? > If it is two, then it means that the site can not tolerate failures in four of > the providers twice removed from it. If it is six, then it means we are > exposing the site to addressing issues not related to it. Obviously, ISPs of a reasonable size should be able to get an address block of their own. Obviously, the routing table will still continue to grow under such a policy. In the presence of a good multiple-addresses multihoming scheme, the requirement for getting an address block could be being globally visible over three or more transit networks. I would be very surprised if the number of networks that qualify under these conditions is more than a few thousand world wide. A customer would then never have to use more than two address ranges over a single ISP, or four when dual-homed. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Sep 3 14:35:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13166 for ; Mon, 3 Sep 2001 14:35:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15dyZK-00064J-00 for multi6-data@psg.com; Mon, 03 Sep 2001 11:35:34 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15dyZJ-00064D-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 11:35:33 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f83IacQ12302 for ; Mon, 3 Sep 2001 20:36:38 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 3 Sep 2001 20:36:38 +0200 (CEST) From: Iljitsch van Beijnum To: Subject: Multihoming by IP Layer Address Rewriting (MILAR) Message-ID: <20010903195134.R5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Before I write up a draft, let me run it by the list. Considering that: - using multiple address ranges is the only way disconnect the growth in multihoming from the growth of the global routing table - the transport layer is not the best place to implement multihoming: the natural place is layer 3 and implementing it there also avoids large amounts of API problems and higher layer changes - multihoming should work in all stages of a connection, including setup - tunnels are a Bad Thing: they waste bandwidth, hide the network topology and current PMTU discovery standards and implementations easily break in the presence of careless tunnel deployment - a host implementation is a good: no need to change routers and multihoming benefits trickle down all the way to the host, unlike current IPv4 multihoming - a router implementation is good: no need to change large numbers of hosts a multi-address multihoming system could work as follows: Transport layer entities connect to a remote host in exactly the same way as they do now. However, in the mean time the network layer takes steps to discover alternative addresses for the destination address. This can be done using the DNS ip6.int zone, a special ICMP message or some other means. When the IP layer decides that the destination address is unreachable or performance is not what it should be (because it receives an ICMP unreachable, an ICMP TTL exceeded or a hint from the transport layer), it chooses one of the alternative addresses, and starts to rewrite the destination address for packets to the destination host. Note that this happens for ALL packets to that host, the only exception being layer 4 sessions that have the new "I know about MILAR and I'll pick the destination address myself, thankyouverymuch" option in the layer 4 -> layer 3 interface enabled. When the destination host receives a packet that is addressed to one of its alternative addresses, it restores the original destination address and delivers the packet to the transport layer. (So the TCP pseudo-header will again produce a valid TCP checksum, among other things.) The rewriting and/or restoring of the destination address can also be performed by a router on behalf of a group of hosts. There is a security problem: a host may think it's communicating with host with a certain IP address, while it is in fact communicating with a very different host, which is not the owner of the IP address in question nor reachable over it using regular routing. This breaks "security by looking at the IP address", but this was never very secure to begin with anyway. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Sep 3 15:48:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13646 for ; Mon, 3 Sep 2001 15:48:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15dze7-0007U2-00 for multi6-data@psg.com; Mon, 03 Sep 2001 12:44:35 -0700 Received: from arpa.it.uc3m.es ([163.117.139.120]) by psg.com with esmtp (Exim 3.33 #1) id 15dze6-0007Tw-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 12:44:34 -0700 Received: from r200-40-178-192.adinet.com.uy (nobody@arpa.it.uc3m.es [163.117.139.120]) by arpa.it.uc3m.es (8.9.3/8.9.3) with SMTP id VAA17752; Mon, 3 Sep 2001 21:43:16 +0200 Message-Id: <200109031943.VAA17752@arpa.it.uc3m.es> To: masahiro@wide.ad.jp, tera@wide.ad.jp, kunishi@tokoro-lab.org, shio@csl.sony.co.jp Cc: multi6@ops.ietf.org From: marcelo@it.uc3m.es Subject: Multihoming specific LIN6 Date: Mon, 3 Sep 101 19:43:18 +0000 X-Mailer: Endymion MailMan v2.0 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, I have found LIN6 proposal very interesting, specially the usage of routing independent addresses in transport layer and above. However, I think that multi-homing issues and mobility issues have diferent constraints, specially when considering timing issues. In a mobile environement, network prefixes may change much more frecuently than in a multi-homing environement. This higher frecuency imposes the usage of some registration mechanism such as a Mapping Agent. In the multi-homing environement, this kind of mechanisms are perhaps not very necesary, and some simpler mechanisms could be used. For example, you could consider that the DNS returns several addresses,a LIN6 generalized ID and several LIN6 addresses. This would provide a simpler solution (and easier to deploy). Best regards, marcelo From owner-multi6@ops.ietf.org Mon Sep 3 16:52:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14096 for ; Mon, 3 Sep 2001 16:52:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e0fJ-0008FQ-00 for multi6-data@psg.com; Mon, 03 Sep 2001 13:49:53 -0700 Received: from ampere.iie.edu.uy ([164.73.224.40]) by psg.com with esmtp (Exim 3.33 #1) id 15e0fF-0008FH-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 13:49:50 -0700 Received: from 6b8j40j (r200-40-72-83.adinet.com.uy [200.40.72.83]) (authenticated) by ampere.iie.edu.uy (8.11.0/8.11.0) with ESMTP id f83KnNL01476; Mon, 3 Sep 2001 17:49:32 -0300 (UYT) From: "marcelo bagnulo" To: "Iljitsch van Beijnum" , Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Mon, 3 Sep 2001 22:49:34 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010903195134.R5044-100000@sequoia.muada.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think LIN6 is an implementation of the host translation case that you are proposing. Regards, marcelo -----Mensaje original----- De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En nombre de Iljitsch van Beijnum Enviado el: lunes, 03 de septiembre de 2001 20:37 Para: multi6@ops.ietf.org Asunto: Multihoming by IP Layer Address Rewriting (MILAR) Before I write up a draft, let me run it by the list. Considering that: - using multiple address ranges is the only way disconnect the growth in multihoming from the growth of the global routing table - the transport layer is not the best place to implement multihoming: the natural place is layer 3 and implementing it there also avoids large amounts of API problems and higher layer changes - multihoming should work in all stages of a connection, including setup - tunnels are a Bad Thing: they waste bandwidth, hide the network topology and current PMTU discovery standards and implementations easily break in the presence of careless tunnel deployment - a host implementation is a good: no need to change routers and multihoming benefits trickle down all the way to the host, unlike current IPv4 multihoming - a router implementation is good: no need to change large numbers of hosts a multi-address multihoming system could work as follows: Transport layer entities connect to a remote host in exactly the same way as they do now. However, in the mean time the network layer takes steps to discover alternative addresses for the destination address. This can be done using the DNS ip6.int zone, a special ICMP message or some other means. When the IP layer decides that the destination address is unreachable or performance is not what it should be (because it receives an ICMP unreachable, an ICMP TTL exceeded or a hint from the transport layer), it chooses one of the alternative addresses, and starts to rewrite the destination address for packets to the destination host. Note that this happens for ALL packets to that host, the only exception being layer 4 sessions that have the new "I know about MILAR and I'll pick the destination address myself, thankyouverymuch" option in the layer 4 -> layer 3 interface enabled. When the destination host receives a packet that is addressed to one of its alternative addresses, it restores the original destination address and delivers the packet to the transport layer. (So the TCP pseudo-header will again produce a valid TCP checksum, among other things.) The rewriting and/or restoring of the destination address can also be performed by a router on behalf of a group of hosts. There is a security problem: a host may think it's communicating with host with a certain IP address, while it is in fact communicating with a very different host, which is not the owner of the IP address in question nor reachable over it using regular routing. This breaks "security by looking at the IP address", but this was never very secure to begin with anyway. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Sep 3 17:09:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14229 for ; Mon, 3 Sep 2001 17:09:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e0xf-0008TA-00 for multi6-data@psg.com; Mon, 03 Sep 2001 14:08:51 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15e0xe-0008T3-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 14:08:50 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f83L9o912446; Mon, 3 Sep 2001 23:09:50 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 3 Sep 2001 23:09:50 +0200 (CEST) From: Iljitsch van Beijnum To: marcelo bagnulo cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: <20010903225531.G5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 3 Sep 2001, marcelo bagnulo wrote: > I think LIN6 is an implementation of the host translation case that you are > proposing. I have perused the LIN6 draft, but as far as I can tell without a much closer read, it requires IPsec (which makes it too heavy-weight for most current applications) and it also uses a special value in the rewritten address. What I want to do (but, granted, do not explain in much detail) is rewrite a prefix. That could be a /128 or a /64 or a /48 or anything else. Obviously, when a host is doing this itself, it will usually replace one /128 with another. On the other hand, if a proxy rewriting agent performs the operation, it might substitute one /64 prefix for another. The host bits remain the same. That way, the entire process is just about completely stateless. I am of course in now way claiming to be the inventor of address rewriting or even a particular way of address rewriting, all I did was to remove most of the complexity of earlier proposals and integrate everything. Iljitsch van Beijnum PS. Is it just me or are there severe bootstrapping problems when trying to understand drafts? I've read about 8 of them today, and in most cases you have to read the whole thing before understanding much... Please please please use a good abstract and/or introduction in longer drafts. From owner-multi6@ops.ietf.org Mon Sep 3 18:33:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14731 for ; Mon, 3 Sep 2001 18:33:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e2HH-000ATT-00 for multi6-data@psg.com; Mon, 03 Sep 2001 15:33:11 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15e2HG-000ATD-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 15:33:10 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id PAA23331; Mon, 3 Sep 2001 15:33:07 -0700 (PDT) Date: Mon, 3 Sep 2001 15:33:06 -0700 (PDT) From: Ramakrishna Gummadi To: Iljitsch van Beijnum cc: Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <20010903195134.R5044-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > - tunnels are a Bad Thing: they waste bandwidth, Don't host solutions waste b/w discovering alternate addresses? I think they waste even more than tunnels which are only used when routing reliably knows there are failures. > hide the network topology Tunnels, at least as I used them in my draft (draft-ramki-multi6-nlmp-00.txt) don't have to hide topology in any way. They only mask failures. Perhaps tunnels is a bad name; may be encapsulation is more appropriate. > and current PMTU discovery standards Current PMTU standard *requires* the host to cope with changes in MTU when routing changes MTU even with no tunnels. If one is so insistent on not adding encapsulated header, a router can rewrite the destination routing goop instead of adding an encapsulation header. > and implementations easily break in > the presence of careless tunnel deployment My draft shows how you can automate them as attributes to routing; no manual configuration is necessary. > > When the IP layer decides that the destination address is unreachable how can this be done without wasting b/w? > performance is not what it should be (because it receives an ICMP > unreachable, How do you deal with fake ICMP messages? > There is a security problem: a host may think it's communicating with host > with a certain IP address, while it is in fact communicating with a very > different host, which is not the owner of the IP address in question nor > reachable over it using regular routing. This breaks "security by looking > at the IP address", but this was never very secure to begin with anyway. Arbitrary change of addresses opens up lots of *new* "interesting" hijacking and DoS issues without a proper security architecture in place. Something along the lines of hip (host-identity payload) must be used. One other complexity in doing host-level multihoming is supporting multicast. regards, -ramki From owner-multi6@ops.ietf.org Mon Sep 3 20:49:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15677 for ; Mon, 3 Sep 2001 20:49:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e4L4-0000Ws-00 for multi6-data@psg.com; Mon, 03 Sep 2001 17:45:14 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15e4L3-0000Wl-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 17:45:13 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 4A5B78266F; Mon, 3 Sep 2001 20:19:17 -0400 (EDT) Message-Id: <5.1.0.14.2.20010903200901.00a27cc0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Sep 2001 20:13:23 -0400 To: Ramakrishna Gummadi From: RJ Atkinson Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) Cc: In-Reply-To: References: <20010903195134.R5044-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 18:33 03/09/01, Ramakrishna Gummadi wrote: >How do you deal with fake ICMP messages? > >> There is a security problem: a host may think it's communicating with host >> with a certain IP address, while it is in fact communicating with a very >> different host, which is not the owner of the IP address in question nor >> reachable over it using regular routing. This breaks "security by looking >> at the IP address", but this was never very secure to begin with anyway. > >Arbitrary change of addresses opens up lots of *new* "interesting" >hijacking and DoS issues without a proper security architecture in place. >Something along the lines of hip (host-identity payload) must be used. RFC-1825/2401 defines a Security Architecture that covers this case quite well (was designed to do so, oddly enough) and ESP/AH are mechanisms that work. AH was designed to handle things like ICMP authentication and works quite well for that. I demo'd AH authentication of ICMP in running code for ARPA back in late August 1995. Small vendors like Microsoft and Sun have shipping ESP/AH today (e.g. in Win2K, Solaris8). Free software vendors (Linux, *BSD) also have shipping ESP/AH today. So we don't have a security architecture or a security technology problem [1] today in this regard. Ran rja@inet.org [1] Caveat: IKE is arguably broken, but there is running IKE code these days and it will get the job above done at least until a replacement for IKE happens... From owner-multi6@ops.ietf.org Mon Sep 3 20:57:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15768 for ; Mon, 3 Sep 2001 20:57:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e4X3-0000gD-00 for multi6-data@psg.com; Mon, 03 Sep 2001 17:57:37 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15e4X2-0000g7-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 17:57:36 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id RAA24407; Mon, 3 Sep 2001 17:57:33 -0700 (PDT) Date: Mon, 3 Sep 2001 17:57:33 -0700 (PDT) From: Ramakrishna Gummadi To: RJ Atkinson cc: Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <5.1.0.14.2.20010903200901.00a27cc0@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > So we don't have a security architecture or a security technology > problem [1] today in this regard. But my concern is that without a scalable key distribution and revocation mechanism, wouldn't we be converting the problem of scalable routing into scalable security? thanks, ramki > > Ran > rja@inet.org > > [1] Caveat: IKE is arguably broken, but there is running IKE code > these days and it will get the job above done at least until > a replacement for IKE happens... > > > From owner-multi6@ops.ietf.org Mon Sep 3 21:01:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15805 for ; Mon, 3 Sep 2001 21:01:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e4c1-0000lk-00 for multi6-data@psg.com; Mon, 03 Sep 2001 18:02:45 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15e4bz-0000lV-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 18:02:43 -0700 Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Mon, 3 Sep 2001 18:02:37 -0700 Message-ID: <2B81403386729140A3A899A8B39B046403ADA6@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C134DD.49987BB0" X-MS-TNEF-Correlator: <2B81403386729140A3A899A8B39B046403ADA6@server2000.arneill-py.sacramento.ca.us> Thread-Topic: Multihoming by IP Layer Address Rewriting (MILAR) Thread-Index: AcE0qHNRVS6PqUN4T1CRc9Gj6vF3nQANI2t6 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 From: "Michel Py" content-class: urn:content-classes:message To: "Iljitsch van Beijnum" , Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C134DD.49987BB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWxqaXRzY2gsDQoNCkkgY29tcGxldGVseSBhZ3JlZSB3aXRoIHRoZSBmb2xsb3dpbmc6DQoNCkls aml0c2NoIHZhbiBCZWlqbnVtIHdyb3RlOg0KPj4NCj4+IC0gdGhlIHRyYW5zcG9ydCBsYXllciBp cyBub3QgdGhlIGJlc3QgcGxhY2UgdG8gaW1wbGVtZW50DQo+PiBtdWx0aWhvbWluZzogdGhlIG5h dHVyYWwgcGxhY2UgaXMgbGF5ZXIgMyBhbmQgaW1wbGVtZW50aW5nDQo+PiBpdCB0aGVyZSBhbHNv IGF2b2lkcyBsYXJnZSBhbW91bnRzIG9mIEFQSSBwcm9ibGVtcyBhbmQNCj4+IGhpZ2hlciBsYXll ciBjaGFuZ2VzDQo+Pg0KPj4tIG11bHRpaG9taW5nIHNob3VsZCB3b3JrIGluIGFsbCBzdGFnZXMg b2YgYSBjb25uZWN0aW9uLA0KPj4gaW5jbHVkaW5nIHNldHVwDQo+Pg0KPj4gLSB0dW5uZWxzIGFy ZSBhIEJhZCBUaGluZzogdGhleSB3YXN0ZSBiYW5kd2lkdGgsIGhpZGUNCj4+IHRoZSBuZXR3b3Jr IHRvcG9sb2d5IGFuZCBjdXJyZW50IFBNVFUgZGlzY292ZXJ5IHN0YW5kYXJkcw0KPj4gYW5kIGlt cGxlbWVudGF0aW9ucyBlYXNpbHkgYnJlYWsgaW4gdGhlIHByZXNlbmNlIG9mIGNhcmVsZXNzDQo+ PiB0dW5uZWwgZGVwbG95bWVudA0KPj4NCj4+IC0gYSByb3V0ZXIgaW1wbGVtZW50YXRpb24gaXMg Z29vZDogbm8gbmVlZCB0byBjaGFuZ2UgbGFyZ2UNCj4+IG51bWJlcnMgb2YgaG9zdHMNCg0KDQpJ IHdvdWxkIHRlbmQgdG8gc2F5ICJ2aXNpYmxlIG92ZXIgVFdPIG9yIG1vcmUgdHJhbnNpdCBuZXR3 b3JrcyINCmZvciB0aGUgZm9sbG93aW5nIGJ1dCBhZ3JlZSBvbiB0aGUgcmVzdC4NCg0KPj4gSW4g dGhlIHByZXNlbmNlIG9mIGEgZ29vZCBtdWx0aXBsZS1hZGRyZXNzZXMgbXVsdGlob21pbmcNCj4+ IHNjaGVtZSwgdGhlIHJlcXVpcmVtZW50IGZvciBnZXR0aW5nIGFuIGFkZHJlc3MgYmxvY2sgY291 bGQNCj4+IGJlIGJlaW5nIGdsb2JhbGx5IHZpc2libGUgb3ZlciB0aHJlZSBvciBtb3JlIHRyYW5z aXQgbmV0d29ya3MuDQo+PiBJIHdvdWxkIGJlIHZlcnkgc3VycHJpc2VkIGlmIHRoZSBudW1iZXIg b2YgbmV0d29ya3MgdGhhdA0KPj4gcXVhbGlmeSB1bmRlciB0aGVzZSBjb25kaXRpb25zIGlzIG1v cmUgdGhhbiBhIGZldw0KPj4gdGhvdXNhbmQgd29ybGQgd2lkZS4NCg0KDQpJIGFtIGEgbGl0dGxl IG1vcmUgcmVzZXJ2ZWQgYWJvdXQgdGhpczoNCg0KPj4gLSB1c2luZyBtdWx0aXBsZSBhZGRyZXNz IHJhbmdlcyBpcyB0aGUgb25seSB3YXkgZGlzY29ubmVjdA0KPj4gdGhlIGdyb3d0aCBpbiBtdWx0 aWhvbWluZyBmcm9tIHRoZSBncm93dGggb2YgdGhlIGdsb2JhbA0KPj4gcm91dGluZyB0YWJsZQ0K DQpVbnRpbCBzb21lb25lIGZpbmRzIGEgbWVjaGFuaXNtIHRoYXQgY2FuIGRvIGl0LiBCZXNpZGVz LCB0aGUNCmdyb3d0aCBvZiB0aGUgbXVsdGlob21pbmcgdGFibGUsIGlmIGl0IGNvbnRhaW4gbXVs dGlob21pbmcNCnByZWZpeGVzIG9ubHkgYW5kIG5vdCB0aGUgcmVzdWx0IG9mIHBvb3Igc3VtbWFy aXphdGlvbnMgY291bGQNCmJlIGNvbnRyb2xsYWJsZSBhcyB5b3UgbWVudGlvbm5lZCBhYm92ZS4N Cg0KDQo+PiBCZWZvcmUgSSB3cml0ZSB1cCBhIGRyYWZ0LCBsZXQgbWUgcnVuIGl0IGJ5IHRoZSBs aXN0Lg0KUGxlYXNlIHRha2UgdGhlIHRpbWUgdG8gaGF2ZSBhIGxvb2sgYXQ6DQoNCmh0dHA6Ly9h cm5laWxsLXB5LnNhY3JhbWVudG8uY2EudXMvZHJhZnQtcHktbXVsdGk2LW1odHAtMDEudHh0DQo8 aHR0cDovL2FybmVpbGwtcHkuc2FjcmFtZW50by5jYS51cy9kcmFmdC1weS1tdWx0aTYtbWh0cC0w MS50eHQ+IA0KDQooSSdkIHJhdGhlciBoYXZlIHRoZSBsaXN0IGxvb2sgYXQgdGhpcyB1bnB1Ymxp c2hlZCB2ZXJzaW9uDQpvcHBvc2VkIHRvIHRoZSBwdWJsaXNoZWQgLTAwKS4NCg0KVGhhbmtzDQpN aWNoZWwNCg0KDQo= ------_=_NextPart_001_01C134DD.49987BB0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiYBAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD AA4AAADRBwkAAwASAAIAJQABAB4BASCAAwAOAAAA0QcJAAMAEgACACUAAQAeAQEJgAEAIQAAADhF NDU1NzNCQkI2MTcwNDI4NTFCMjAwMDdDRDI0REFBAAsHAQOQBgBUFAAAOAAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAAGwAAABSAEUAOgAgAE0AdQBsAHQA aQBoAG8AbQBpAG4AZwAgAGIAeQAgAEkAUAAgAEwAYQB5AGUAcgAgAEEAZABkAHIAZQBzAHMAIABS AGUAdwByAGkAdABpAG4AZwAgACgATQBJAEwAQQBSACkAAABAADkAsHuYSd00wQEfAD0AAQAAAAoA AABSAEUAOgAgAAAAAAACAUcAAQAAADMAAABjPXVzO2E9IDtwPWFybmVpbGwtcHk7bD1TRVJWRVIy MDAwLTAxMDkwNDAxMDIzN1otNAAAHwBJAAEAAABkAAAATQB1AGwAdABpAGgAbwBtAGkAbgBnACAA YgB5ACAASQBQACAATABhAHkAZQByACAAQQBkAGQAcgBlAHMAcwAgAFIAZQB3AHIAaQB0AGkAbgBn ACAAKABNAEkATABBAFIAKQAAAEAATgAA/71dpzTBAR8AWgABAAAAKgAAAEkAbABqAGkAdABzAGMA aAAgAHYAYQBuACAAQgBlAGkAagBuAHUAbQAAAAAAAgFbAAEAAABFAAAAAAAAAIErH6S+oxAZnW4A 3QEPVAIAAAAASWxqaXRzY2ggdmFuIEJlaWpudW0AU01UUABpbGppdHNjaEBtdWFkYS5jb20AAAAA AgFcAAEAAAAYAAAAU01UUDpJTEpJVFNDSEBNVUFEQS5DT00AHwBdAAEAAAAqAAAASQBsAGoAaQB0 AHMAYwBoACAAdgBhAG4AIABCAGUAaQBqAG4AdQBtAAAAAAACAV4AAQAAAEUAAAAAAAAAgSsfpL6j EBmdbgDdAQ9UAgAAAABJbGppdHNjaCB2YW4gQmVpam51bQBTTVRQAGlsaml0c2NoQG11YWRhLmNv bQAAAAACAV8AAQAAABgAAABTTVRQOklMSklUU0NIQE1VQURBLkNPTQAfAGYAAQAAAAoAAABTAE0A VABQAAAAAAAfAGcAAQAAACYAAABpAGwAagBpAHQAcwBjAGgAQABtAHUAYQBkAGEALgBjAG8AbQAA AAAAHwBoAAEAAAAKAAAAUwBNAFQAUAAAAAAAHwBpAAEAAAAmAAAAaQBsAGoAaQB0AHMAYwBoAEAA bQB1AGEAZABhAC4AYwBvAG0AAAAAAB8AcAABAAAAZAAAAE0AdQBsAHQAaQBoAG8AbQBpAG4AZwAg AGIAeQAgAEkAUAAgAEwAYQB5AGUAcgAgAEEAZABkAHIAZQBzAHMAIABSAGUAdwByAGkAdABpAG4A ZwAgACgATQBJAEwAQQBSACkAAAACAXEAAQAAABsAAAABwTSoc1FVLo+pQ3hPUJFz0aPq8XedAA0j a3oAHwB0AAEAAAAoAAAAbQB1AGwAdABpADYAQABvAHAAcwAuAGkAZQB0AGYALgBvAHIAZwAAAB8A GgwBAAAAFAAAAE0AaQBjAGgAZQBsACAAUAB5AAAAHwAdDgEAAABkAAAATQB1AGwAdABpAGgAbwBt AGkAbgBnACAAYgB5ACAASQBQACAATABhAHkAZQByACAAQQBkAGQAcgBlAHMAcwAgAFIAZQB3AHIA aQB0AGkAbgBnACAAKABNAEkATABBAFIAKQAAAAIBCRABAAAA9goAAPIKAABOKAAATFpGdTIy8VcD AAoAcmNwZzEyNYIyA0NodG1sMQMw/wEDAfcKgAKkA+QHEwKAEAP/AFAEVghVB7IRNQ5RAwECAIRj aArAc2V0MgYA2wbDETUzBEYTxzASPwIAvjQDxhaLEUMI7wn3Oxnf7Q4wNREyDGBjAFALCQFkTDM2 FmALpTQgEAIq9lwOsgGQZxRQCqMRQx74AjQUUDwhRE9DVABZUEUgSFRNTAAgUFVCTElDIIAiLS8v VzNDIpCIRFREIaQzLjIikHBFTiI+H/0fnyTRMb44IQAhsiQfJS8noDMekPEmgEVBRCbdDvEn/yp/ BSYENg7wPE1FVEHFB7BBLXA9IkcJ8ASQFGF0BbAiFnBPTlRNI+BULgAF4UV4E+Fu9GdlBlJ2EpEw UQCQAiAAIDYuMC40NDGeNzEgJA4r3yYTNzchAOBUSVRMRSbeMWAF0DJ1J4BpaANwC4BnIABieSBJ UCBMYWJ5EpFBZGQZ4AQRUg8H0AUQNgA2YShNSUyoQVIpJX41IQAvNF9/Mo8nVTWhOgApXyevPdQ1 ARZgPEJPRFkgZOhpcj098HI9QD2zACFzAzBAUWRvAOBAUQqxXP5xGcBAURPgAzBAtRZgPWvTHgE+ b2c2KSFQQIkAACtCzyYENCZhRi7hIGa9ANBlLgAWiS6wAJB6SMA+MkXLF5ADsgHQQqlJbCZqOBAE 8GgsJYw1Nv858UhCQIlAl0toCqJO2AqB/0C3CrFQ6EM9AcA58UWxQ1//RG9Ff1H/R59Ir0m/Ss9L 1JogBaBtC1AUMGVsNqDrPhAJ0SAD8HRCkF4AMAB3O+xUxQIQbBlwA/Av4Dr/TL9Nz07fT+9Q/1cv Ux9UL/9VP1ZPZe9Yb1l/Wo9bn0wXAzCAA5FCZWlqbnXubV5vaJM38G9dMGBdLSBtP6FSQIsLgGVl jz22OLEekCZndAKAQKc+dc//dt9373NvdH91j3kvej9+T3N/X4BpIC1eI0BgAHFwnRmBIAtgNxIE ACBucyB9XiNiB5AFQAtRbPBeIG//ca9okwdwXQEHgAIwe498n799r4FPgl+LT4xfgvptNej6Ol4j bi5wCHAHQIYFhRHlhLQzXXBuZIafh6w2Uf+Ij4mfiq+OT49fmG+Zf4L6TzgQXiIZ4F1wbHOGgGFQ dm9pZJKyci/xYS0EYHUCMAQgb0EQQVD9XLBwA2ACYIgwBCCTn2ii/5NRla+Wv5fPm2+cf6VPpl9x gvpoaWeeEYSlL7Rz/6KPo5+kr6hPqV+uv6/PsN//rF+tb7Ofsh+zL7c/uE+5U/+DsJC5bfA2IDXg k39ypQWw/muFAAOgB0ADIIXgPhAHkdWgAWFcwW4uQGM2AAIg/0yttP+2D7mvur/Dn8SvnO78bmMK QEAQNmG9j2iiFCH8dXDBD8Ifwy/Gz8ffzj//z0/QX8vfzO/TH9Gf0q/Wv//Xz4NXn7AuQJ5wXXCe MnEgOmG9YFSqsJFFNqB3Ya+F4IWhk1ED8GReACzJz/9ok6qwAQDTn9Sv1b/ZX9pv/+Mv5D+C+pGD FDC+0y6AhGDtGXBnXWGTYWMIcBngAjCxIfBNVFVAAQTwbzBR/zag3t/K4wGQk2ALEavv4W//4n/m H+cv8C/xP4Lrk1KH93cucDDRBCBl3dADEDagYv0Z4GG/A14yoHAHkAnwhkH3oAHrn2iiY9xhXRAE EO1//+6P75/zP/RP/X/+j+fb2/P1QABlC1BvBsCIX/uf/K//AE8BXwaPB58IrwQvBT8GT38J7wr/ Dw8QH4MpwDBzEHU/XTBtkPjvh7v2c4UCZ2/8b2SRYIVA6MEZ8IZiL7X/nyMMHw0vDj8R3xLvG/8d D7+C+nFxhcAwsPiv36dvheD/+q1hT2JfY29kfxt/Zp9nr/9ov2nPKQ8ZvxrPLl9sH20v/24/b09c ob7QvULd8JNhhnGic6swICJ2hRBpoKHnn/DrQdzwV0+f8BTfK9Sfn5CeMYQTndHo1XMiLr//L88w 3F/AM+BeMl/HhbAUoM9ddRcBXjL4MXQuI78kz/8l3ybvJ/8xLyofKy8sPy1P/0b/Mm8zfzSPNZ8e vx/PUP/7Ug8TTkn3z9yRF2I5PzpE65DCiBEt3NBk+DH4UNxA/5C5O/89DzDfVD9VT14/X08fgvpw sYgx3rBA5HF1ae/6UAOyPuOfUHSVYlg/ogXv3JBaNIWwA4BjvwDrIL1B/1t/XI9dn2E/Yk9rX2xv gvr3hcCFsbzSZwOA3iC/YOtw/zgLhYBAc06gOpNl70myOu7/QW1pf2qPbi9vP3iPeZ9Vvvc2xXDB 60Nz6jCgcBcwGBH+aUYwkYMhcyHf36Y7ZoVx/5HQdf93D3gfe798z4W/hs//2wpkgL9Qf8DrcJ+w A1A/E//4UMBCyYD2hBcxOpQYgdyR+4DfSbJmTtCC/4QPhR+Iv/+Jz5JPk1/n3GhQN7Dp8b7R+71R 3mFlQW9Cf0OPRJ9Fr/+Uf0fPSN9J70r/nm+QL5E/v6O/TU9OX09vNb/ckG3ckd+l8GWAOFE6k/gy cutAWCA8YWIUkY3/dJTdEHM6/5j/mg+bH5wvnT+mb59foG//oX+ij7U/p6+ov6nPqt+VD/+WH78/ wE8TT4uQ9wBlsVmW/2dXOvEYsIzzrh+vJECS9yHv3cDrcOrzAwFjgu+k/6YP/8Jvw3/Mj82f589A YD+wPzD/96JaybwQFICsINIJgK/H+f9xVMnfyu/L/8+f0K/Zj9qf/8QqFIJloreAOEGvv7DPsd// su+z/9vPth+3L7g/uU/lT8+7b7x/vY++nyBVA9D3ELvtUNPAZRcAP1HY0GRnwP9X0AOwGHIXMNPS gtAYYGcxnmQX0NTfFgNBUCBCjCD9mLFzZAPWz9ff2OzUOD8y/9Lq33NkAH/BOzGMYeeQ0rH/8o9Z V1sf9Y/2n+qRVxHwoP54WpHIo5gCF8A7QEDlWaGdV5JwF3Ds8H8gbW3kwP/tcBbTxv/n5GhP/Y/+ n6PQf3DB+kIUgD+Q34JXwGfAef8EoPER79HJcq2TftCY7+DP/+Hf4u/j/+ov5h/nL+g/6U//D98F jwafFS/rn+yv7b++v//cb91/HQ8eH8QM9BA+8cXQb34hGmA3MIuQcFfBWkBh/GZ0ZAA4UK3/OjVB AYug/foCYjfQPzIXYEFPFk8XX85QOFAI4DrBYWuNcjrB/mkl0TeB8VB+0KwyAhBoIP+C0K+vC28M fw2PDp8fXxC/nxHPEt8T7zIfIJQ8QTS0DXLBZhoQIVB0cDovDi8xoIIg7/BsLXB5mi6X8GN08GTS by7yEFoul+AvI9M6YS38EzYDPDAhUHAtMDEudHh4dCIbbBpwBMAkomYHBMD6kCcAe0hZUEXAUkxJ TksgOX86jzM7nzyrfX0cEQTAcnPBjpBcY2YxXH5gHL//GM80wxnfGuA0wxsPHB9Fgv9AD0EfQi88 uSyvLb8uz1E/61JPM9s5M2JBKHgv/zEP/1QvMy80PzVPNl9Yvxk/Gk/jSV+q/ihJJ3+gdPDWIf85 ASvCJqYsFtHxxu9bJYug/HB1ciCNENYwf6B+0cUQz4xwJz8oTxeMb3ACAH+CzyuB1iJm+DzwMCkK X1BP/1KfVj9XT11/WW9af1uPXJ+/cl9ev1/PYN9h7xVAVPFRz4KAaA9pHxeMTWnxQD5g/31Pfl8X j20fbi9vP3BPcV9fg09zf3SPiw+MHDV40S/wQk9EWYq9imCNH4+hQjeEoUhUTUyB4H0BkdAAAB8A NRABAAAAoAAAADwAMgBCADgAMQA0ADAAMwAzADgANgA3ADIAOQAxADQAMABBADMAQQA4ADkAOQBB ADgAQgAzADkAQgAwADQANgA0ADAAMwBBAEQAQQA2AEAAcwBlAHIAdgBlAHIAMgAwADAAMAAuAGEA cgBuAGUAaQBsAGwALQBwAHkALgBzAGEAYwByAGEAbQBlAG4AdABvAC4AYwBhAC4AdQBzAD4AAAAf AEcQAQAAAB4AAABtAGUAcwBzAGEAZwBlAC8AcgBmAGMAOAAyADIAAAAAAAsA8hABAAAAHwDzEAEA AAB4AAAAUgBFACUAMwBBACAATQB1AGwAdABpAGgAbwBtAGkAbgBnACAAYgB5ACAASQBQACAATABh AHkAZQByACAAQQBkAGQAcgBlAHMAcwAgAFIAZQB3AHIAaQB0AGkAbgBnACAAKABNAEkATABBAFIA KQAuAEUATQBMAAAACwD2EAAAAABAAAcwMMz7AN00wQFAAAgw4HWySd00wQEDAN4/6f0AAAMA8T8J BAAAHwD4PwEAAAAUAAAATQBpAGMAaABlAGwAIABQAHkAAAACAfk/AQAAAGAAAAAAAAAA3KdAyMBC EBq0uQgAKy/hggEAAAAAAAAAL089QVJORUlMTC1QWS9PVT1GSVJTVCBBRE1JTklTVFJBVElWRSBH Uk9VUC9DTj1SRUNJUElFTlRTL0NOPU1JQ0hFTAAfAPo/AQAAACoAAABTAHkAcwB0AGUAbQAgAEEA ZABtAGkAbgBpAHMAdAByAGEAdABvAHIAAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAAr L+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAAAAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB8A MEABAAAADgAAAE0ASQBDAEgARQBMAAAAAAAfADFAAQAAAA4AAABNAEkAQwBIAEUATAAAAAAAHwAy QAEAAAAmAAAAaQBsAGoAaQB0AHMAYwBoAEAAbQB1AGEAZABhAC4AYwBvAG0AAAAAAB8AM0ABAAAA JgAAAGkAbABqAGkAdABzAGMAaABAAG0AdQBhAGQAYQAuAGMAbwBtAAAAAAAfADhAAQAAAA4AAABN AEkAQwBIAEUATAAAAAAAHwA5QAEAAAAEAAAALgAAAAsAKQAAAAAACwAjAAAAAAADAAYQbQ8P2gMA BxCmBQAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAElMSklUU0NILElDT01QTEVURUxZQUdS RUVXSVRIVEhFRk9MTE9XSU5HOklMSklUU0NIVkFOQkVJSk5VTVdST1RFOi1USEVUUkFOU1BPUlRM QVlFUklTTk9UVEhFQkVTVFBMQUMAAAAAAgF/AAEAAABQAAAAPDJCODE0MDMzODY3MjkxNDBBM0E4 OTlBOEIzOUIwNDY0MDNBREE2QHNlcnZlcjIwMDAuYXJuZWlsbC1weS5zYWNyYW1lbnRvLmNhLnVz PgAPhQ== ------_=_NextPart_001_01C134DD.49987BB0-- From owner-multi6@ops.ietf.org Mon Sep 3 21:10:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15847 for ; Mon, 3 Sep 2001 21:10:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e4k4-0000up-00 for multi6-data@psg.com; Mon, 03 Sep 2001 18:11:04 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15e4k2-0000uf-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 18:11:02 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id LAA12997; Tue, 4 Sep 2001 11:10:49 +1000 (EST) Date: Tue, 4 Sep 2001 11:10:48 +1000 (EST) From: Peter Tattam To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <20010903195134.R5044-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk The discovery of the alternative destination address is the crux of the problem and needs to be handled in such a manner as to prevent spoofing attacks. IPsec is too heavy to deal with the issue - my lightwieght proposal of a SYN/ACK exchange like TCP works but is subject to address list explosion issues which I hope to resolve through sending compressed address trees instead of lists or sets. Much of what you have suggested about processing incoming packets is also dealt with in my proposal. The most difficult task is knowing which addresses to choose first based on DNS queries, choosing alternative addresses when a failure occurs and knowing when to start choosing an alternative address. We don't have much empirical experience with this and we are only guessing at the right way to do this. I'm not sure that you have addressed these issues - I look forward to any new ideas on this front. Peter On Mon, 3 Sep 2001, Iljitsch van Beijnum wrote: > Before I write up a draft, let me run it by the list. > > Considering that: > > - using multiple address ranges is the only way disconnect the growth in > multihoming from the growth of the global routing table > > - the transport layer is not the best place to implement multihoming: > the natural place is layer 3 and implementing it there also avoids large > amounts of API problems and higher layer changes > > - multihoming should work in all stages of a connection, including setup > > - tunnels are a Bad Thing: they waste bandwidth, hide the network topology > and current PMTU discovery standards and implementations easily break in > the presence of careless tunnel deployment > > - a host implementation is a good: no need to change routers and > multihoming benefits trickle down all the way to the host, unlike > current IPv4 multihoming > > - a router implementation is good: no need to change large numbers of > hosts > > a multi-address multihoming system could work as follows: > > Transport layer entities connect to a remote host in exactly the same way > as they do now. However, in the mean time the network layer takes steps to > discover alternative addresses for the destination address. > > This can be done using the DNS ip6.int zone, a special ICMP message or > some other means. > > When the IP layer decides that the destination address is unreachable or > performance is not what it should be (because it receives an ICMP > unreachable, an ICMP TTL exceeded or a hint from the transport layer), it > chooses one of the alternative addresses, and starts to rewrite the > destination address for packets to the destination host. > > Note that this happens for ALL packets to that host, the only exception > being layer 4 sessions that have the new "I know about MILAR and I'll pick > the destination address myself, thankyouverymuch" option in the layer 4 -> > layer 3 interface enabled. > > When the destination host receives a packet that is addressed to one of > its alternative addresses, it restores the original destination address > and delivers the packet to the transport layer. (So the TCP pseudo-header > will again produce a valid TCP checksum, among other things.) > > The rewriting and/or restoring of the destination address can also be > performed by a router on behalf of a group of hosts. > > There is a security problem: a host may think it's communicating with host > with a certain IP address, while it is in fact communicating with a very > different host, which is not the owner of the IP address in question nor > reachable over it using regular routing. This breaks "security by looking > at the IP address", but this was never very secure to begin with anyway. > > Iljitsch van Beijnum > > > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Mon Sep 3 21:30:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15983 for ; Mon, 3 Sep 2001 21:30:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e54A-0001G8-00 for multi6-data@psg.com; Mon, 03 Sep 2001 18:31:50 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15e549-0001G0-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 18:31:49 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 96EF98266E for ; Mon, 3 Sep 2001 21:31:47 -0400 (EDT) Message-Id: <5.1.0.14.2.20010903212256.00aa82d0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Sep 2001 21:25:57 -0400 To: multi6@ops.ietf.org From: RJ Atkinson Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: References: <5.1.0.14.2.20010903200901.00a27cc0@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 20:57 03/09/01, Ramakrishna Gummadi wrote: >> So we don't have a security architecture or a security technology >> problem [1] today in this regard. > >But my concern is that without a scalable key distribution and revocation >mechanism, wouldn't we be converting the problem of scalable routing into >scalable security? IKE works fine for now and can provide scalable key distribution. Key revocation is a concept that applies to certificates, not really to session keys used with ESP/AH. In short, we have technology today that suffices. IKE could be better, but what we have is sufficient for now (until replaced with something else). Again, we do NOT have a security architecture or a security technology problem today that prevents address re-writing from being considered here. Ran rja@inet.org From owner-multi6@ops.ietf.org Mon Sep 3 21:36:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16965 for ; Mon, 3 Sep 2001 21:36:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e59g-0001Mm-00 for multi6-data@psg.com; Mon, 03 Sep 2001 18:37:32 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15e59f-0001Mf-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 18:37:31 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id LAA19192 for ; Tue, 4 Sep 2001 11:37:29 +1000 (EST) Date: Tue, 4 Sep 2001 11:37:29 +1000 (EST) From: Peter Tattam To: Multi6 Working Group Subject: some more transport MH ideas... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk I wanted to do this more formally by putting together a draft, but I'd like to run the ideas before everyone first. There is an important feature of strongly aggregated networks that I think is being ignored. If a path to a particular point of the aggregation tree is unreachable, it is highly likely that other addresses to that branch of the tree are unreachable too. This can provide hints to the address selection mechanisms to list addresses with prefixes for that branch to have lower priority in the selection process. If the aggregated structure of such an internet can be relied upon, I believe that through the use of what I coin "reachability trees", one can resolve some of the criticisms of transport layer multihoming has when it comes to address list explosion as such trees might be reasonably more compressible when exchanging address information and also lead to efficiencies in TCP stack design. To find forward reachability information, one would probably need to retain somewhere locally a "reachability cache" which contained many such reachability trees. Such a cache could live on the host itself, or could be operated in a similar manner to a DNS server or a router's routing table. The information in such a cache is likely to much more volatile than DNS though and less complete than a routing table. Personally, I think that each node should manage its own cache as it would have much finer control over the validity of the data in such a cache, and also a host is likely to have localized information for it's current connections. One could exchange information between nodes as there is likely to be reasonable correlation between host caches like there is in DNS, but there is then a difficulty with issues of security. If addresses are still exchanged between end points, spoofing is eliminated. It just leaves the issue of denial of service. If we used the 1 hop rule as in ND, this could be managed in a reasonable manner within a local network environment. Important network events could also be multicast by routers to expedite cache updating. Please note that while this sounds very similar to a routing tree, in practice it might be managed somewhat differently. It also sounds a bit like ARP for the wider internet. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Mon Sep 3 22:31:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18287 for ; Mon, 3 Sep 2001 22:31:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e614-00024s-00 for multi6-data@psg.com; Mon, 03 Sep 2001 19:32:42 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15e613-00024l-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 19:32:41 -0700 Subject: Re: Multihoming draft available Date: Mon, 3 Sep 2001 19:32:40 -0700 Message-ID: <2B81403386729140A3A899A8B39B046403ADA9@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Thread-Topic: Re: Multihoming draft available Thread-Index: AcE06d3oBaOcAXroSAekcfH6zqIkeQ== X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 From: "Michel Py" content-class: urn:content-classes:message To: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA18287 Ramki, How does NLMP address the following scenario? Entreprise ACME is multihomed. Acme's web server has either two NICs or two IPv6 addresses bound to the same interface. www.acme.com has two AAAA records: 1234:5678::1 from ISP "A" 2345:6789::1 from ISP "B" Joe's address is 2345:CAFE::1234. Joe wants to access Acme's web site. Joe types www.acme.com . Joe's DNS server returns both AAAA record and Joe's PC picks 1234:5678::1 as the IPv6 address for www.acme.com . Joe sends traffic to that IP address. Unless ISP "A" and "B" have a peering agreement (unlikely to happen; it would require each ISP to peer with every other ISP) Joe's traffic is going to hit the interconnect between A and B (if there is one) and then be carried by ISP "B". Since both Joe and Acme are connected to ISP "A", this is not good. I might have missed it, but I have not seen yet any DNS that would be smart enough to analyse the routing table and alter the order/preference of AAAA records. Thanks, Michel. From owner-multi6@ops.ietf.org Mon Sep 3 22:50:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18418 for ; Mon, 3 Sep 2001 22:50:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e6IV-0002Ln-00 for multi6-data@psg.com; Mon, 03 Sep 2001 19:50:43 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15e6IT-0002LW-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 19:50:41 -0700 Subject: RE: some more transport MH ideas... Date: Mon, 3 Sep 2001 19:50:39 -0700 Message-ID: <2B81403386729140A3A899A8B39B046403ADAA@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C134EC.6187A380" X-MS-TNEF-Correlator: <2B81403386729140A3A899A8B39B046403ADAA@server2000.arneill-py.sacramento.ca.us> Thread-Topic: some more transport MH ideas... Thread-Index: AcE0445P8sA0L+CSTF2mskxwjm4j1AAB9OjG X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 From: "Michel Py" content-class: urn:content-classes:message To: "Peter Tattam" , "Multi6 Working Group" Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C134EC.6187A380 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGV0ZXIsDQogDQpXaGF0IGtpbmQgb2YgIm1ldHJpYyIgb3IgImFzLXBhdGgiIHdvdWxkIHRoYXQg c29sdXRpb24gdXNlPyBBbW9uZyB0aGUNCnBvc3NpYmxlIHBhdGhzDQp0byB0aGUgdGFyZ2V0LCBo b3cgd291bGQgYSBob3N0IGtub3cgd2hpY2ggb25lIGlzIHRoZSBiZXN0PyBUaGUgZGVwdGggb2YN CnRoZSByZWFjaGFiaWxpdHkNCnRyZWUgZG9lcyBub3QgYXBwZWFsIHRvIG1lLCBiZWNhdXNlIGEg bXVsdGktaG9tZWQgZW50cmVwcmlzZSBtaWdodCBiZQ0KdmVyeQ0KY2xvc2UgdG8gdGhlIGFnZ3Jl Z2F0aW9uIHBvaW50IG9mIG9uZSBJU1AgYW5kIG5vdCBvZiBhbm90aGVyIG9uZS4NCiANClRoYW5r cywNCk1pY2hlbC4NCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IFBldGVy IFRhdHRhbSANCglTZW50OiBNb24gOS8zLzIwMDEgNjozNyBQTSANCglUbzogTXVsdGk2IFdvcmtp bmcgR3JvdXAgDQoJQ2M6IA0KCVN1YmplY3Q6IHNvbWUgbW9yZSB0cmFuc3BvcnQgTUggaWRlYXMu Li4NCgkNCgkNCg0KCUkgd2FudGVkIHRvIGRvIHRoaXMgbW9yZSBmb3JtYWxseSBieSBwdXR0aW5n IHRvZ2V0aGVyIGEgZHJhZnQsDQpidXQgSSdkIGxpa2UgdG8NCglydW4gdGhlIGlkZWFzIGJlZm9y ZSBldmVyeW9uZSBmaXJzdC4NCgkNCglUaGVyZSBpcyBhbiBpbXBvcnRhbnQgZmVhdHVyZSBvZiBz dHJvbmdseSBhZ2dyZWdhdGVkIG5ldHdvcmtzDQp0aGF0IEkgdGhpbmsgaXMNCgliZWluZyBpZ25v cmVkLiAgSWYgYSBwYXRoIHRvIGEgcGFydGljdWxhciBwb2ludCBvZiB0aGUNCmFnZ3JlZ2F0aW9u IHRyZWUgaXMNCgl1bnJlYWNoYWJsZSwgaXQgaXMgaGlnaGx5IGxpa2VseSB0aGF0IG90aGVyIGFk ZHJlc3NlcyB0byB0aGF0DQpicmFuY2ggb2YgdGhlDQoJdHJlZSBhcmUgdW5yZWFjaGFibGUgdG9v LiAgVGhpcyBjYW4gcHJvdmlkZSBoaW50cyB0byB0aGUgYWRkcmVzcw0Kc2VsZWN0aW9uDQoJbWVj aGFuaXNtcyB0byBsaXN0IGFkZHJlc3NlcyB3aXRoIHByZWZpeGVzIGZvciB0aGF0IGJyYW5jaCB0 bw0KaGF2ZSBsb3dlcg0KCXByaW9yaXR5IGluIHRoZSBzZWxlY3Rpb24gcHJvY2Vzcy4NCglJZiB0 aGUgYWdncmVnYXRlZCBzdHJ1Y3R1cmUgb2Ygc3VjaCBhbiBpbnRlcm5ldCBjYW4gYmUgcmVsaWVk DQp1cG9uLCBJIGJlbGlldmUNCgl0aGF0IHRocm91Z2ggdGhlIHVzZSBvZiB3aGF0IEkgY29pbiAi cmVhY2hhYmlsaXR5IHRyZWVzIiwgb25lDQpjYW4gcmVzb2x2ZSBzb21lDQoJb2YgdGhlIGNyaXRp Y2lzbXMgb2YgdHJhbnNwb3J0IGxheWVyIG11bHRpaG9taW5nIGhhcyB3aGVuIGl0DQpjb21lcyB0 byBhZGRyZXNzDQoJbGlzdCBleHBsb3Npb24gYXMgc3VjaCB0cmVlcyBtaWdodCBiZSByZWFzb25h Ymx5IG1vcmUNCmNvbXByZXNzaWJsZSB3aGVuDQoJZXhjaGFuZ2luZyBhZGRyZXNzIGluZm9ybWF0 aW9uIGFuZCBhbHNvIGxlYWQgdG8gZWZmaWNpZW5jaWVzIGluDQpUQ1Agc3RhY2sNCglkZXNpZ24u DQoJDQoJVG8gZmluZCBmb3J3YXJkIHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbiwgb25lIHdvdWxk IHByb2JhYmx5DQpuZWVkIHRvIHJldGFpbg0KCXNvbWV3aGVyZSBsb2NhbGx5IGEgInJlYWNoYWJp bGl0eSBjYWNoZSIgd2hpY2ggY29udGFpbmVkIG1hbnkNCnN1Y2ggcmVhY2hhYmlsaXR5DQoJdHJl ZXMuICBTdWNoIGEgY2FjaGUgY291bGQgbGl2ZSBvbiB0aGUgaG9zdCBpdHNlbGYsIG9yIGNvdWxk IGJlDQpvcGVyYXRlZCBpbiBhDQoJc2ltaWxhciBtYW5uZXIgdG8gYSBETlMgc2VydmVyIG9yIGEg cm91dGVyJ3Mgcm91dGluZyB0YWJsZS4gIFRoZQ0KaW5mb3JtYXRpb24gaW4NCglzdWNoIGEgY2Fj aGUgaXMgbGlrZWx5IHRvIG11Y2ggbW9yZSB2b2xhdGlsZSB0aGFuIEROUyB0aG91Z2ggYW5kDQps ZXNzIGNvbXBsZXRlDQoJdGhhbiBhIHJvdXRpbmcgdGFibGUuICBQZXJzb25hbGx5LCBJIHRoaW5r IHRoYXQgZWFjaCBub2RlIHNob3VsZA0KbWFuYWdlIGl0cyBvd24NCgljYWNoZSBhcyBpdCB3b3Vs ZCBoYXZlIG11Y2ggZmluZXIgY29udHJvbCBvdmVyIHRoZSB2YWxpZGl0eSBvZg0KdGhlIGRhdGEg aW4gc3VjaA0KCWEgY2FjaGUsIGFuZCBhbHNvIGEgaG9zdCBpcyBsaWtlbHkgdG8gaGF2ZSBsb2Nh bGl6ZWQgaW5mb3JtYXRpb24NCmZvciBpdCdzDQoJY3VycmVudCBjb25uZWN0aW9ucy4NCgkNCglP bmUgY291bGQgZXhjaGFuZ2UgaW5mb3JtYXRpb24gYmV0d2VlbiBub2RlcyBhcyB0aGVyZSBpcyBs aWtlbHkNCnRvIGJlDQoJcmVhc29uYWJsZSBjb3JyZWxhdGlvbiBiZXR3ZWVuIGhvc3QgY2FjaGVz IGxpa2UgdGhlcmUgaXMgaW4gRE5TLA0KYnV0IHRoZXJlIGlzDQoJdGhlbiBhIGRpZmZpY3VsdHkg d2l0aCBpc3N1ZXMgb2Ygc2VjdXJpdHkuICBJZiBhZGRyZXNzZXMgYXJlDQpzdGlsbCBleGNoYW5n ZWQNCgliZXR3ZWVuIGVuZCBwb2ludHMsIHNwb29maW5nIGlzIGVsaW1pbmF0ZWQuICBJdCBqdXN0 IGxlYXZlcyB0aGUNCmlzc3VlIG9mIGRlbmlhbA0KCW9mIHNlcnZpY2UuICBJZiB3ZSB1c2VkIHRo ZSAxIGhvcCBydWxlIGFzIGluIE5ELCB0aGlzIGNvdWxkIGJlDQptYW5hZ2VkIGluIGENCglyZWFz b25hYmxlIG1hbm5lciB3aXRoaW4gYSBsb2NhbCBuZXR3b3JrIGVudmlyb25tZW50Lg0KSW1wb3J0 YW50IG5ldHdvcmsNCglldmVudHMgY291bGQgYWxzbyBiZSBtdWx0aWNhc3QgYnkgcm91dGVycyB0 byBleHBlZGl0ZSBjYWNoZQ0KdXBkYXRpbmcuDQoJDQoJUGxlYXNlIG5vdGUgdGhhdCB3aGlsZSB0 aGlzIHNvdW5kcyB2ZXJ5IHNpbWlsYXIgdG8gYSByb3V0aW5nDQp0cmVlLCBpbiBwcmFjdGljZQ0K CWl0IG1pZ2h0IGJlIG1hbmFnZWQgc29tZXdoYXQgZGlmZmVyZW50bHkuICBJdCBhbHNvIHNvdW5k cyBhIGJpdA0KbGlrZSBBUlAgZm9yDQoJdGhlIHdpZGVyIGludGVybmV0Lg0KCQ0KCVBldGVyDQoJ DQoJLS0NCglQZXRlciBSLiBUYXR0YW0gICAgICAgICAgICAgICAgICAgICAgICAgICAgcGV0ZXJA dHJ1bXBldC5jb20NCglNYW5hZ2luZyBEaXJlY3RvciwgICAgVHJ1bXBldCBTb2Z0d2FyZSBJbnRl cm5hdGlvbmFsIFB0eSBMdGQNCglIb2JhcnQsIEF1c3RyYWxpYSwgIFBoLiArNjEtMy02MjQ1LTAy MjAsICBGYXggKzYxLTMtNjI0NTAyMTANCgkNCgkNCgkNCg0K ------_=_NextPart_001_01C134EC.6187A380 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IikCAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD AA4AAADRBwkAAwATADIAJwABAFEBASCAAwAOAAAA0QcJAAMAEwAyACcAAQBRAQEJgAEAIQAAAEE0 RkMzMDNBMjM1NTI3NDc4RkM5OUZFQTVBNEQ0Mjg2ADkHAQOQBgCIFwAAOAAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAAEgAAABSAEUAOgAgAHMAbwBtAGUA IABtAG8AcgBlACAAdAByAGEAbgBzAHAAbwByAHQAIABNAEgAIABpAGQAZQBhAHMALgAuAC4AAABA ADkAgKOHYew0wQEfAD0AAQAAAAoAAABSAEUAOgAgAAAAAAACAUcAAQAAADMAAABjPXVzO2E9IDtw PWFybmVpbGwtcHk7bD1TRVJWRVIyMDAwLTAxMDkwNDAyNTAzOVotNwAAHwBJAAEAAABAAAAAcwBv AG0AZQAgAG0AbwByAGUAIAB0AHIAYQBuAHMAcABvAHIAdAAgAE0ASAAgAGkAZABlAGEAcwAuAC4A LgAAAEAATgCA0oIo4jTBAR8AWgABAAAAGgAAAFAAZQB0AGUAcgAgAFQAYQB0AHQAYQBtAAAAAAAC AVsAAQAAAEYAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABQZXRlciBUYXR0YW0AU01UUABwZXRl ckBqYXp6LTEudHJ1bXBldC5jb20uYXUAAAACAVwAAQAAACEAAABTTVRQOlBFVEVSQEpBWlotMS5U UlVNUEVULkNPTS5BVQAAAAAfAF0AAQAAABoAAABQAGUAdABlAHIAIABUAGEAdAB0AGEAbQAAAAAA AgFeAAEAAABGAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAUGV0ZXIgVGF0dGFtAFNNVFAAcGV0 ZXJAamF6ei0xLnRydW1wZXQuY29tLmF1AAAAAgFfAAEAAAAhAAAAU01UUDpQRVRFUkBKQVpaLTEu VFJVTVBFVC5DT00uQVUAAAAAHwBmAAEAAAAKAAAAUwBNAFQAUAAAAAAAHwBnAAEAAAA4AAAAcABl AHQAZQByAEAAagBhAHoAegAtADEALgB0AHIAdQBtAHAAZQB0AC4AYwBvAG0ALgBhAHUAAAAfAGgA AQAAAAoAAABTAE0AVABQAAAAAAAfAGkAAQAAADgAAABwAGUAdABlAHIAQABqAGEAegB6AC0AMQAu AHQAcgB1AG0AcABlAHQALgBjAG8AbQAuAGEAdQAAAB8AcAABAAAAQAAAAHMAbwBtAGUAIABtAG8A cgBlACAAdAByAGEAbgBzAHAAbwByAHQAIABNAEgAIABpAGQAZQBhAHMALgAuAC4AAAACAXEAAQAA ABsAAAABwTTjjk/ywDQv4JJMXaayTHCObiPUAAH06MYAHwB0AAEAAAAqAAAATQB1AGwAdABpADYA IABXAG8AcgBrAGkAbgBnACAARwByAG8AdQBwAAAAAAAfABoMAQAAABQAAABNAGkAYwBoAGUAbAAg AFAAeQAAAB8AHQ4BAAAAQAAAAHMAbwBtAGUAIABtAG8AcgBlACAAdAByAGEAbgBzAHAAbwByAHQA IABNAEgAIABpAGQAZQBhAHMALgAuAC4AAAACAQkQAQAAAKEOAACdDgAAejIAAExaRnVZnHTAAwAK AHJjcGcxMjWCMgNDaHRtbDEDMD8BAwH3CoACpAPjAgBjaMEKwHNldDAgBxMCgP8QAwBQBFYIVQey EdUOUQMB3RDXMgYABsMR1TMERhDZbxLrEeMI7wn3OxjPDjA1OxHSDGBjAFALCQFkMzaTEWALpTQg EAIqXA6yvQGQZxTwCqMR4x3oNBTwADwhRE9DVFlQAEUgSFRNTCBQAFVCTElDICItIC8vVzNDIYBE VCJEIJQzLjIhgEVOnCI+Hu0ejyPBMTgf8G8goiMPJB8mkDMdgCVwRXxBRCXNDvEm7ylvJPQ2QQ7w PE1FVEEHsEExLGA9IkcJ8ASQYXRFBbAiEtBPTlQi0FQTLPAF4UV4EPFuZ2U9BlJ2EzEvQQCQAiAg NoAuMC40NDE3MBAnIv4qzyUDNzcf8FRJmFRMRSXOMFAgcwNwZy7wBGAY0CB0LVAAgHAjGHEF0Egg aQEAYXPWLjaAJG41H/AvM08xf78mRTSRN9AoTyafO6Q1EWAAPEJPRFkgZGn0cj07wHI7EDuDACED MDk+IWRvAOA+IQqxXHH/GLA+IRDwAzA+hRFgOzsc8RE8P2c5Nh/wRElWzz5ZAABAlztZNjRDz0Di 9lARQASQLDtZAcA+Zwqi9z5nCnEkfDAoESHgQ5tJOH9BH0IvQz9ET0VfT9s7OzhxHYAmbmI1oAKA Pngn/mEBQFAfSB9JL0o/S09Sb59Nb05/Ua9Qn12fIFcRAEUFQGsLgGQgbz7gIl8HgDVgDeAtoAWx IjZgLakKsHRoLaB3CGBsYVCvYsBg8TTACkB0L8J1ETD+PxFwBGAu0GNRLvA5vFuluzWwBBBpAmAu 8GKic1Wv/1a/V89Y31nvWv9cD10fXi9fXz9r9y1wZOMBkHIu4HSwLCBobwfgYwRhc3Hqc2EBbnOS aA3gQGACIFcu8AQAZONiB5B0ZHBU/2UBAQAFMHUhPuBlP22SZPIXGNAA0BEAYgMQaXR5/2dvaH9p j2qfa69sv23Pbt/fb+9w/3IICdE90G8HkXSgjnRSz1PfVOphcHA2UJ8DIHKRB4BzYHXwY2FkQe10 EW1jIGPwLXOAB4BhUBsJ8IShcAUQiYFtaWf/DrB14Xcff5MvQXlven97j/98n32vfr9/z4Dfge+C /5HovmMYYImBcpU74AnBZy1gPy/CNbALgAVAYXF1QklT/lB0EGFBhUFhYgBwhVBlAPsFwHVBLo1v jn+Pj5Cfka//kr+Tz5Tfle+W/6E/hf+HD/9Vb51/no+fn6Cvob+iz6Pfn6Tvpf+y+3ZQAHBrc0eP /6u/rM+t367vr/+xD7Ifsy/LtD+62E11AWVsnJ+3X7+4b7l/uo+7n7yvPXFMIDDwS1FVTy3wPdY0 sHlQA2bgLjFBUkdJTi0IUklHIKA6IDBw/ngi8T54CrEQAj+FQCM/4f9Af8d/HxsRYNFQyF+9z77f t7/vznc/AGkc0iR8NCVRpkYt0TSwaXrK4DLS26sL4s5ZLdpSTwUQZwuA1YiRTQeQczvgZdpT1r3b LBA9cVI+WwuAZQqBzn9XqFY9gNLbYs5ZRgNhOvvRnB/hL+AaxmlHJHZALWD9AZBti8/QD6iS0W7c 393v/97/4A/qWAZgAjDh/+MP5BdCTS/ROS8zLwHQMJEO8DY6MzMQUE3b/9/o/+oP6x/sL7V2b+3v 7v938AiJ4tJwVwWwYSFk0Ef5A2B1cOVv5n/nj/KP85/n9K/1v+DrQ2P3v/jP5Bc//j//TwBfAW8C f+1FdWL+aolA7d8FD+QINM811Pu///zP/dQ2Nga/B88I3xQvFT//FkkOP6qPwt/D78T/Gi8zvf0l US/X4jsdz9/Q79R3DdD+UMw/GV/Vj9af16/Yvx/H/kli8DWA5MBjQYjQP0BjUSt1gQ/TZmIwbdsA bHm7deAugHBj4GPwZMJvczHrnCJ0IGQ1cGZzURD/Iv9t/dRiY+Ca4Cd0AHkwa8+Y0hb/GA8WHHJ1 mgBk8m8Tc3XhLhGJkGWNInVCZv/KMHRgE+807xYPOU86Xztqf3ZROAF1gSywMG8xfxMGbc8Qciyx LgB4wHR1OAFhcX90YPtg+yAucZlmimF1UHT/c8D68HWSYPEsgC1xthB1cf88Lz0/O0yLoPsSP+9A /xMV9md0oISwZDkcqK+pvprg/5vBZwNygk/yHGBh8HPgSuH/mieZLoSjSd9K7xMVRm9Hf/87PTbw eLVm4HNgeUB1cnTwP4tgLnEzci5xY2OcBGFk3zAA20GFEXKTYPFiEDF1Ev93D1Q//bZk8VXvVv87 TISj715wiZBY6XKBb0zPTd9O7N92UHWBiVCaAftgdhNxWgH/mlBcJYmRW7RdX15v/cWJgP/K0Ayw meFgH2EvO0wPoHjhem51gG1cI3kwdGFbqHfPeUB1IIrgN9BpeIURLhH/XGuIwWn/aw/91FsAjSAz YPxvd40wbQ9uHztMiuE38L9ZsC6AOzBR42x3aBJj20H/OR94Dzs9T8GZKophc+90//tsFcpwdQyw Q0aC8HIAP7H/mkGNMETxZ9OLoXIwKJCKYf/7gPCgWZAsgIughTGNIHwv/30/Yj1bAkWA+2GLYIA/ gU+vX3hjkJjBXTF3RZRjmjF0ICJjxWkokHphUvJzniJZkJqyZ+JpoW9sdoH/D4KGf4ePO0xRxYpP i1/91H5jekHBkHBjUcIQN1EgefXk0W36cmgPkPsSWwBxsf9SAIPxhIEPkXCTW6WQ35HvHztMcOOU T5Vf/dRleHD/drAqYPChN5GDk48TD8BaIf9coYTyE6DwoGQRLoAtw5oh+3Ih21BpZCKef5+P/dSZ ov+bL5w/O0yg8HAi2tH7MGl2/zswLhN7UyywM1DbAA+AM2D/Y9As83JAOMCXEO2wrdGronnk8ENQ pM+l34JXY+Br/6efqK87TBOAKmBMYHwfsq//Oz+1P7ZPPmtcUDjArJEuEf0soHIzUI5Lq8mPdEUg +nDvgC+vz/22e6Fio2O3MCzk/3IwIoC3ILgfuS+3PA+CmaH/OAF2sGfgLmJQkI48Z+BzgPxlIo1h rcCKL79PlkfwoPfCAkTBLkBuLoCDk45Kwk//w19iP3KAZJ9lr07sDGCDsv/HVI3RvhIokHaB8KHI P8lP34xomPBxAVmwbHFmj3Hk4HPT1IThb3Dk0ESjepFh/8y/zc/EbUJgjrDVwctRtzCjctFQckRO U3rxcjhBf9Sv1b/9xXLBUJD7YeTBJ/9FYOGSLxNkEtAP0R9mvjdB/6vZwi/az9vf0xotkd7P39+/ /dRahlxQmKBzgS3DdpBA/1KRZDJwMd4DRYCJ86yCZDD/acGkAmQw4cDnH+gviJ+hcX/rD+wf/cXi L+M/5E/SaFD/duCjMi5hhcJF9EWDY9JE4PpvaHFz8AG+IctRI+A3Qe9o0fTv9f/g5XfnD/J/ty3/ 03Q3kVmxvfR2Y+4zu0EvsbvKsuGQbENw3oI3InbGEPcTcHpSUcVkQyD0z/9/Evf/e4CDkgE/Ak+3 PNNVMFCsh/9QkNd0RWDtmHZlxgEqcdly/6voCL8JzzKUcrJZsOHwC6//DL8DXUNAcjBRkcqxtzBs s798Dxavtx8aDxsfHCtPj6L/vgOqleYchOBFEFMQEp8Tr/9L1v0SP5FFYj9F7ZiE4Bz//x4PNg2j FqPiGNHu8iG513P/03P+byNf7RolaHqR3hGFwP8y8iV2Js8n3/OemcFQkAeg/62imLHHQHHTcGCD kHKBXT//LV9r6RixelH4P/lPTu9bqN9jYrFQjrAGsCCWZDEfMi/fSJ4iBJnA1BBRY3OFwDYv/zc/ bBVRYDXwqwJnsYUhmRHff/I5Lzo/O01xEGqNAJgh//zAdoAlUzV0g1K0oHBQxhD/Pi8/P5L/Qm9D f2wW3nCtwH/4L0dPOz+NYIzjrUEEYTE912Fwy+CYsAR0e4BORP+FwPwR8NLYlf3U2XNOn0+v/8pU 2c9MbyjfKefdVXHS2ZL/xdTBUSIA7pD8UJnAaFDhkP5ucADK0FGPUp9Tq2E/Yk/vO1tYX1lvylRJ pCCYActg/3EQX/Va71v/qb12gEIR08XfrMNXcpiy03BxAWLHQOGU/5pjoPHBgATApL9n/5ZHBEP/ hYAIYasBGe9rnxwPdI91n/12qlCtEY0R/RBwwfxzx9H37zNW4cVAdayQJVDegcuB/9zl3cNw/3IP 9w2iIYXAjgH/pDAEQJbxJr94b3Z9BMGid/9XpsVEiZE0gi9hytCjgGEv/2UfZi99737/aVKisKzD fCXP4XC8cJghLwJBUq6wEhH/gc+C3zM/XvG0oN6viz8KuP/hwWohdF+P33Z/la+Wv3mrf/FBjs+Z j5efm/+dD54aLZ4tnt+f75qvkkFSLpJv25N/CsVUe0CikG2HX4hv/2NfqL+pz6rfq++s/64Prx// sC+xP7JPs1+0b7V/to+3n/+4r7m/us+737zvvf+/D8Af/8Evwj/DT8RfxW/Gf8ePyJ//ya/Kv8vP zN/N787/0A/RH//SL9M/1E/VX9Zv13/Yj9mf/9qv27/cz93f3u/f/+EP4h//4y/kP+VP5l/nb+h/ 6Y/qn//rr+y/7c/u3+/v8P/yD4ovr6Z/CrZwgJURQICwdWmQn5VRGTCoXKLPo98gTf3i3UUyRGCg GXFqYCzzL/Q/f/Jv/h//LwA/AU8CXzvxVPn5BCBTTmAiADzy9h/3Ly9pJZUDIYNfwVA1AUx0Rz4f +q+d7UhvYn0wdN0wMEFJgYFQjhBh/b8EjwlTrFBopWArNjEtADMtNjI0NS0w+DIyMA9vEH/1Pwe/ CM8xlMFGYXgSmRNQMTD/C18Mb53/Gm8bfxyPHZ8erwsfvyDDNSEhL0ZPTv5UIXkVByAQFRYXgiVY IninF3MifxbmNzIkMVAhcA0gPDCUoCRAQkxPQ8BLUVVPVEUkryjPnmcl4RefLl8XEzU4K2J4T0RZ Kk0p8C/fMmE3oSQxSFRNTCFwfTSQAAAAHwA1EAEAAACgAAAAPAAyAEIAOAAxADQAMAAzADMAOAA2 ADcAMgA5ADEANAAwAEEAMwBBADgAOQA5AEEAOABCADMAOQBCADAANAA2ADQAMAAzAEEARABBAEEA QABzAGUAcgB2AGUAcgAyADAAMAAwAC4AYQByAG4AZQBpAGwAbAAtAHAAeQAuAHMAYQBjAHIAYQBt AGUAbgB0AG8ALgBjAGEALgB1AHMAPgAAAB8ARxABAAAAHgAAAG0AZQBzAHMAYQBnAGUALwByAGYA YwA4ADIAMgAAAAAACwDyEAEAAAAfAPMQAQAAAFQAAABSAEUAJQAzAEEAIABzAG8AbQBlACAAbQBv AHIAZQAgAHQAcgBhAG4AcwBwAG8AcgB0ACAATQBIACAAaQBkAGUAYQBzAC4ALgAuAC4ARQBNAEwA AAALAPYQAAAAAEAABzAAD+Vh6zTBAUAACDBgT7ph7DTBAQMA3j/p/QAAAwDxPwkEAAAfAPg/AQAA ABQAAABNAGkAYwBoAGUAbAAgAFAAeQAAAAIB+T8BAAAAYAAAAAAAAADcp0DIwEIQGrS5CAArL+GC AQAAAAAAAAAvTz1BUk5FSUxMLVBZL09VPUZJUlNUIEFETUlOSVNUUkFUSVZFIEdST1VQL0NOPVJF Q0lQSUVOVFMvQ049TUlDSEVMAB8A+j8BAAAAKgAAAFMAeQBzAHQAZQBtACAAQQBkAG0AaQBuAGkA cwB0AHIAYQB0AG8AcgAAAAAAAgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAA AC4AAAADAP0/5AQAAAMAGUAAAAAAAwAaQAAAAAADAB1AAAAAAAMAHkAAAAAAHwAwQAEAAAAOAAAA TQBJAEMASABFAEwAAAAAAB8AMUABAAAADgAAAE0ASQBDAEgARQBMAAAAAAAfADJAAQAAADgAAABw AGUAdABlAHIAQABqAGEAegB6AC0AMQAuAHQAcgB1AG0AcABlAHQALgBjAG8AbQAuAGEAdQAAAB8A M0ABAAAAOAAAAHAAZQB0AGUAcgBAAGoAYQB6AHoALQAxAC4AdAByAHUAbQBwAGUAdAAuAGMAbwBt AC4AYQB1AAAAHwA4QAEAAAAOAAAATQBJAEMASABFAEwAAAAAAB8AOUABAAAABAAAAC4AAAALACkA AAAAAAsAIwAAAAAAAwAGEIwSyGUDAAcQTwkAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABQ RVRFUixXSEFUS0lORE9GIk1FVFJJQyJPUiJBUy1QQVRIIldPVUxEVEhBVFNPTFVUSU9OVVNFP0FN T05HVEhFUE9TU0lCTEVQQVRIU1RPVEhFVEFSR0VULEhPV1dPVUxEQUhPAAAAAAIBfwABAAAAUAAA ADwyQjgxNDAzMzg2NzI5MTQwQTNBODk5QThCMzlCMDQ2NDAzQURBQUBzZXJ2ZXIyMDAwLmFybmVp bGwtcHkuc2FjcmFtZW50by5jYS51cz4A+lw= ------_=_NextPart_001_01C134EC.6187A380-- From owner-multi6@ops.ietf.org Mon Sep 3 23:08:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18528 for ; Mon, 3 Sep 2001 23:08:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e6aG-0002a9-00 for multi6-data@psg.com; Mon, 03 Sep 2001 20:09:04 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15e6aF-0002a3-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 20:09:03 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id UAA25570; Mon, 3 Sep 2001 20:08:57 -0700 (PDT) Date: Mon, 3 Sep 2001 20:08:57 -0700 (PDT) From: Ramakrishna Gummadi To: Michel Py cc: Subject: RE: Multihoming draft available In-Reply-To: <2B81403386729140A3A899A8B39B046403ADA7@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi Michel, This is the "performance" problem, and, like the draft says, all of a site's prefixes would be known to all of its direct ISPs (but not leaked outside any of the direct ISPs) to avoid this problem. Alternatively, DNS, etc., that returned the answer could be more intelligent (look at the source address and return a suitable destination address), but this is optional. On Mon, 3 Sep 2001, Michel Py wrote: > Ramki, > > How does NLMP address the following scenario? > > Entreprise ACME is multihomed. > > Acme's web server has either two NICs or two IPv6 addresses > bound to the same interface. > www.acme.com has two AAAA records: > 1234:5678::1 from ISP "A" > 2345:6789::1 from ISP "B" > > Joe's address is 2345:CAFE::1234. > Joe wants to access Acme's web site. Joe types www.acme.com > . > Joe's DNS server returns both AAAA record and Joe's PC picks > 1234:5678::1 as the IPv6 address for www.acme.com > . > Joe sends traffic to that IP address. > > Unless ISP "A" and "B" have a peering agreement (unlikely to > happen; it would require each ISP to peer with every other ISP) > Joe's traffic is going to hit the interconnect between A and B > (if there is one) and then be carried by ISP "B". > > Since both Joe and Acme are connected to ISP "A", this is not good. > > I might have missed it, but I have not seen yet any DNS that would > be smart enough to analyse the routing table and alter the > order/preference of AAAA records. > > Thanks, > Michel. > > > From owner-multi6@ops.ietf.org Mon Sep 3 23:17:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18611 for ; Mon, 3 Sep 2001 23:17:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e6k5-0002kH-00 for multi6-data@psg.com; Mon, 03 Sep 2001 20:19:13 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15e6k4-0002k9-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 20:19:12 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id UAA25666; Mon, 3 Sep 2001 20:19:07 -0700 (PDT) Date: Mon, 3 Sep 2001 20:19:03 -0700 (PDT) From: Ramakrishna Gummadi To: Peter Tattam cc: Multi6 Working Group Subject: Re: some more transport MH ideas... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi Peter, Doesn't BGP provide the reachability information? Can't the site's border router look at the BGP feeds from its upstream providers and deduce the reachability information? Am I missing something here? -ramki On Tue, 4 Sep 2001, Peter Tattam wrote: > I wanted to do this more formally by putting together a draft, but I'd like to > run the ideas before everyone first. > > There is an important feature of strongly aggregated networks that I think is > being ignored. If a path to a particular point of the aggregation tree is > unreachable, it is highly likely that other addresses to that branch of the > tree are unreachable too. This can provide hints to the address selection > mechanisms to list addresses with prefixes for that branch to have lower > priority in the selection process. > > If the aggregated structure of such an internet can be relied upon, I believe > that through the use of what I coin "reachability trees", one can resolve some > of the criticisms of transport layer multihoming has when it comes to address > list explosion as such trees might be reasonably more compressible when > exchanging address information and also lead to efficiencies in TCP stack > design. > > To find forward reachability information, one would probably need to retain > somewhere locally a "reachability cache" which contained many such reachability > trees. Such a cache could live on the host itself, or could be operated in a > similar manner to a DNS server or a router's routing table. The information in > such a cache is likely to much more volatile than DNS though and less complete > than a routing table. Personally, I think that each node should manage its own > cache as it would have much finer control over the validity of the data in such > a cache, and also a host is likely to have localized information for it's > current connections. > > One could exchange information between nodes as there is likely to be > reasonable correlation between host caches like there is in DNS, but there is > then a difficulty with issues of security. If addresses are still exchanged > between end points, spoofing is eliminated. It just leaves the issue of denial > of service. If we used the 1 hop rule as in ND, this could be managed in a > reasonable manner within a local network environment. Important network > events could also be multicast by routers to expedite cache updating. > > Please note that while this sounds very similar to a routing tree, in practice > it might be managed somewhat differently. It also sounds a bit like ARP for > the wider internet. > > Peter > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > > From owner-multi6@ops.ietf.org Mon Sep 3 23:34:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19099 for ; Mon, 3 Sep 2001 23:34:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e6zf-0002yu-00 for multi6-data@psg.com; Mon, 03 Sep 2001 20:35:19 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15e6zd-0002yn-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 20:35:18 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id NAA15336; Tue, 4 Sep 2001 13:35:09 +1000 (EST) Date: Tue, 4 Sep 2001 13:35:09 +1000 (EST) From: Peter Tattam To: Michel Py cc: Multi6 Working Group Subject: RE: some more transport MH ideas... In-Reply-To: <2B81403386729140A3A899A8B39B046403ADAA@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 3 Sep 2001, Michel Py wrote: > Peter, > > What kind of "metric" or "as-path" would that solution use? I'm not sure I understand the question and its relevance to what I'm suggesting. Regular routing would take place as normally. This is not a replacement for any kind of routing. I would envisage BGP holding together the strong aggregated framework as we currently do, just that BGP ripples should end up being localized. BGP generally provides a local picture of how to get to a particular destination. We are more concerned with what happens further away from the local picture we have. Ideally all MH paths would be possible, but in practice some will be better - I am not sure BGP or any protocol based on it will be able to provide detail on remote paths within violating our requirement to keep the DFZ small via aggregation. Strong aggregation essentially means we toss away the fine grained information about remote routing. We need to get that kind of information back, but not transfer it through the DFZ. > Among the possible paths to the target, how would a host know which one is > the best? I would also propose to add weights to branches of the tree in order to find the best address. The host should have some idea of which paths work & which don't, and hopefully build up a history in its cache. This information should be exchanged along with the address exchange. Because intervening routers need not have to participate in such an exchange other than sending unreachable messages either way, there need not be any routing protocol like BGP involved. We have traditionally pushed that burden onto routers withe the resulting scalability problems. Basically I'm asking the other end to tell me the best way to get to it rather than the next hop router. We have to start thinking that routers are going to have to be dumber and hosts are going to have to be smarter for any kind of scalability to happen. > The depth of the reachability tree does not appeal to me, because a > multi-homed entreprise might be very close to the aggregation point of one > ISP and not of another one. Just like we have suggested placing an artificial limit on the size of the DFZ, I think that it may be wise also to place a limit on the global aggregation depth. 3-4 does seem reasonable for the next 10-20 years. Alternatively, with careful design, one could use a b-tree approach to allocation. Start at the top & only suballocate on an as needs basis. If an aggregation point reaches it's capacity, split it into 2 or more aggregation points by network renumbering and redistribute the sub aggregations between them. To answer your question perhaps we need to qualify the distances not only down the tree but also between branches which would mean a trip up & down the tree (assuming the usual upside down trees) to the alternative addresses. The main cost is in address exchange between the nodes. For diverse addresses, the compression efficiency in exchanging addresses would be reduced. Of course if all reasonably large network providers insisted on having a presence in the DFZ, we would have a highly meshed network & the depth would be quite low. A measure of a provider's visibility would be how close they are to the DFZ. One would hope that the closer they are to the DFZ, the more redundacy those providers might have at layers below the IP layer. With the way the ISP industry is heading, I believe the number of tiers we have been used to is likely to decrease, so economics may sort out the depth problem for us anyway. Regards Peter > > Thanks, > Michel. > > -----Original Message----- > From: Peter Tattam > Sent: Mon 9/3/2001 6:37 PM > To: Multi6 Working Group > Cc: > Subject: some more transport MH ideas... > > > > I wanted to do this more formally by putting together a draft, > but I'd like to > run the ideas before everyone first. > > There is an important feature of strongly aggregated networks > that I think is > being ignored. If a path to a particular point of the > aggregation tree is > unreachable, it is highly likely that other addresses to that > branch of the > tree are unreachable too. This can provide hints to the address > selection > mechanisms to list addresses with prefixes for that branch to > have lower > priority in the selection process. > If the aggregated structure of such an internet can be relied > upon, I believe > that through the use of what I coin "reachability trees", one > can resolve some > of the criticisms of transport layer multihoming has when it > comes to address > list explosion as such trees might be reasonably more > compressible when > exchanging address information and also lead to efficiencies in > TCP stack > design. > > To find forward reachability information, one would probably > need to retain > somewhere locally a "reachability cache" which contained many > such reachability > trees. Such a cache could live on the host itself, or could be > operated in a > similar manner to a DNS server or a router's routing table. The > information in > such a cache is likely to much more volatile than DNS though and > less complete > than a routing table. Personally, I think that each node should > manage its own > cache as it would have much finer control over the validity of > the data in such > a cache, and also a host is likely to have localized information > for it's > current connections. > > One could exchange information between nodes as there is likely > to be > reasonable correlation between host caches like there is in DNS, > but there is > then a difficulty with issues of security. If addresses are > still exchanged > between end points, spoofing is eliminated. It just leaves the > issue of denial > of service. If we used the 1 hop rule as in ND, this could be > managed in a > reasonable manner within a local network environment. > Important network > events could also be multicast by routers to expedite cache > updating. > > Please note that while this sounds very similar to a routing > tree, in practice > it might be managed somewhat differently. It also sounds a bit > like ARP for > the wider internet. > > Peter > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > > > > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Mon Sep 3 23:36:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19117 for ; Mon, 3 Sep 2001 23:36:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e71Z-00030t-00 for multi6-data@psg.com; Mon, 03 Sep 2001 20:37:17 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15e71X-00030n-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 20:37:16 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id NAA15587; Tue, 4 Sep 2001 13:36:53 +1000 (EST) Date: Tue, 4 Sep 2001 13:36:53 +1000 (EST) From: Peter Tattam To: Ramakrishna Gummadi cc: Multi6 Working Group Subject: Re: some more transport MH ideas... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 3 Sep 2001, Ramakrishna Gummadi wrote: > Hi Peter, > Doesn't BGP provide the reachability information? Can't the site's border > router look at the BGP feeds from its upstream providers and deduce the > reachability information? Am I missing something here? see my other message. By strong aggregation, we remove a lot of information from the DFZ. We can see localized information, but not remote information unless the other end tells us. > > -ramki > > On Tue, 4 Sep 2001, Peter Tattam wrote: > > > I wanted to do this more formally by putting together a draft, but I'd like to > > run the ideas before everyone first. > > > > There is an important feature of strongly aggregated networks that I think is > > being ignored. If a path to a particular point of the aggregation tree is > > unreachable, it is highly likely that other addresses to that branch of the > > tree are unreachable too. This can provide hints to the address selection > > mechanisms to list addresses with prefixes for that branch to have lower > > priority in the selection process. > > > > If the aggregated structure of such an internet can be relied upon, I believe > > that through the use of what I coin "reachability trees", one can resolve some > > of the criticisms of transport layer multihoming has when it comes to address > > list explosion as such trees might be reasonably more compressible when > > exchanging address information and also lead to efficiencies in TCP stack > > design. > > > > To find forward reachability information, one would probably need to retain > > somewhere locally a "reachability cache" which contained many such reachability > > trees. Such a cache could live on the host itself, or could be operated in a > > similar manner to a DNS server or a router's routing table. The information in > > such a cache is likely to much more volatile than DNS though and less complete > > than a routing table. Personally, I think that each node should manage its own > > cache as it would have much finer control over the validity of the data in such > > a cache, and also a host is likely to have localized information for it's > > current connections. > > > > One could exchange information between nodes as there is likely to be > > reasonable correlation between host caches like there is in DNS, but there is > > then a difficulty with issues of security. If addresses are still exchanged > > between end points, spoofing is eliminated. It just leaves the issue of denial > > of service. If we used the 1 hop rule as in ND, this could be managed in a > > reasonable manner within a local network environment. Important network > > events could also be multicast by routers to expedite cache updating. > > > > Please note that while this sounds very similar to a routing tree, in practice > > it might be managed somewhat differently. It also sounds a bit like ARP for > > the wider internet. > > > > Peter > > > > -- > > Peter R. Tattam peter@trumpet.com > > Managing Director, Trumpet Software International Pty Ltd > > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > > > > > > > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Tue Sep 4 01:38:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24313 for ; Tue, 4 Sep 2001 01:38:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15e8un-0004fh-00 for multi6-data@psg.com; Mon, 03 Sep 2001 22:38:25 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15e8um-0004fb-00 for multi6@ops.ietf.org; Mon, 03 Sep 2001 22:38:24 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id PAA13896; Tue, 4 Sep 2001 15:38:12 +1000 (EST) Date: Tue, 4 Sep 2001 15:38:11 +1000 (EST) From: Peter Tattam To: Michel Py cc: Multi6 Working Group Subject: RE: some more transport MH ideas... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Peter Tattam wrote: > On Mon, 3 Sep 2001, Michel Py wrote: > > > Peter, > > > > What kind of "metric" or "as-path" would that solution use? > > I'm not sure I understand the question and its relevance to what I'm > suggesting. Regular routing would take place as normally. This is not a > replacement for any kind of routing. I would envisage BGP holding together the > strong aggregated framework as we currently do, just that BGP ripples should > end up being localized. BGP generally provides a local picture of how to get to > a particular destination. We are more concerned with what happens further away > from the local picture we have. Ideally all MH paths would be possible, but in > practice some will be better - I am not sure BGP or any protocol based on it > will be able to provide detail on remote paths within violating our requirement ^^^^^^ should read "without". > to keep the DFZ small via aggregation. Strong aggregation essentially means we > toss away the fine grained information about remote routing. We need to get > that kind of information back, but not transfer it through the DFZ. > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Tue Sep 4 03:05:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04923 for ; Tue, 4 Sep 2001 03:05:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eAGj-0005xs-00 for multi6-data@psg.com; Tue, 04 Sep 2001 00:05:09 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15eAGi-0005xm-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 00:05:08 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f84765613434; Tue, 4 Sep 2001 09:06:06 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 4 Sep 2001 09:06:05 +0200 (CEST) From: Iljitsch van Beijnum To: Peter Tattam cc: Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: <20010904083746.T5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Peter Tattam wrote: > The discovery of the alternative destination address is the crux of the problem > and needs to be handled in such a manner as to prevent spoofing attacks. IPsec > is too heavy to deal with the issue - my lightwieght proposal of a SYN/ACK > exchange like TCP works but is subject to address list explosion issues which I > hope to resolve through sending compressed address trees instead of lists or > sets. Doing this in the SYN/ACK handshake has the disadvantage that you have to do it over and over again for each TCP session. One popular application comes to mind that uses many short lived TCP sessions... I think we should definately not rule out the DNS for this, unless we're absolutely sure this will not work. Yes, the domain name system has many problem areas, but since it is already used for normal session setup, (A/AAAA record), the exposure to these problems is already there and using the DNS again will not do much, if any, additional harm. And even if the DNS can't be trusted, it could still be a valuable source of "hints" that can be validated through some more secure means later. Another way that could work reasonably well is to use ICMP messages. Incoming ICMP messages that claim to carry alternative addresses for some host are highly suspect, but we can work around this by having the source host first send an ICMP "what are your addresses" message, along with a certain amount of reasonably random data. (A challenge, if you will.) The destination host would then respond by echoing back the random data and supplying the alternative addresses. This is safe if the data is sufficiently random and the traffic is not intercepted, and there could be options for "real" security. The major drawback of ICMP or TCP solutions is that they can only work when the first address is reachable at the beginning of the session. > The most difficult task is knowing which addresses to choose first based on DNS > queries, You could check the addresses that come back from the DNS against the routing table, but I suspect that won't help much to find the best route, but would only help in avoiding a small set of failure modes. > choosing alternative addresses when a failure occurs and knowing when > to start choosing an alternative address. We don't have much empirical > experience with this and we are only guessing at the right way to do this. One system could be to periodically cycle through all available addresses and gather statistics for each. After a while, the system would know which addresses are best. We could even come up with a scheme to share this information with other hosts. Thinking about an implementation for my proposal, I came to the conclusion that there would need to be some kind of "address discovery daemon" because waiting for DNS replies in the kernel wouldn't be a very good idea. Such a daemon could of course communicate to other instances of itself on other hosts. This opens many cans of worms for sure, and massive amounts of work need to be done to get it right, but there are many interesting possibilities. Simple failover schemes are in use today and/or are available as experimental implementations and nothing suggests that "if A doesn't work, we'll use B" isn't at least a huge improvement over "if A doesn't work, we do nothing". Iljitsch From owner-multi6@ops.ietf.org Tue Sep 4 03:33:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05244 for ; Tue, 4 Sep 2001 03:33:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eAdl-0006Yb-00 for multi6-data@psg.com; Tue, 04 Sep 2001 00:28:57 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15eAdj-0006YT-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 00:28:56 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id RAA10747; Tue, 4 Sep 2001 17:28:42 +1000 (EST) Date: Tue, 4 Sep 2001 17:28:42 +1000 (EST) From: Peter Tattam To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <20010904083746.T5044-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Iljitsch van Beijnum wrote: > On Tue, 4 Sep 2001, Peter Tattam wrote: > > > The discovery of the alternative destination address is the crux of the problem > > and needs to be handled in such a manner as to prevent spoofing attacks. IPsec > > is too heavy to deal with the issue - my lightwieght proposal of a SYN/ACK > > exchange like TCP works but is subject to address list explosion issues which I > > hope to resolve through sending compressed address trees instead of lists or > > sets. > > Doing this in the SYN/ACK handshake has the disadvantage that you have to > do it over and over again for each TCP session. One popular application > comes to mind that uses many short lived TCP sessions... There is the chance that it can be made independent of the TCP session but still tied to the sessions so that it may only need to be done once, and could also work for other connection protocols. BTW, my current tcp proposal does piggy back on the syn/ack so it's only just a little extra baggage. It's more expensive to send extra packets than to piggy back on an existing packet IMHO. > > I think we should definately not rule out the DNS for this, unless we're > absolutely sure this will not work. Yes, the domain name system has many > problem areas, but since it is already used for normal session setup, > (A/AAAA record), the exposure to these problems is already there and using > the DNS again will not do much, if any, additional harm. In my experience, it's much easier to misconfigure DNS. There are a lot of clueless admins out there who would not understand the implications of getting it wrong. Even I'm guilty of stuffing up DNS delegations and SOA's in recent times :) > > And even if the DNS can't be trusted, it could still be a valuable source > of "hints" that can be validated through some more secure means later. I start to get nervous whenever I hear about needing a secure channel to exchange information. If the system can operate without requiring rigorous security, then it is one step more able to withstand a security attack than a system that requires it. > > Another way that could work reasonably well is to use ICMP messages. > Incoming ICMP messages that claim to carry alternative addresses for some > host are highly suspect, but we can work around this by having the source > host first send an ICMP "what are your addresses" message, along with a > certain amount of reasonably random data. (A challenge, if you will.) The > destination host would then respond by echoing back the random data and > supplying the alternative addresses. This is safe if the data is > sufficiently random and the traffic is not intercepted, and there could be > options for "real" security. > > The major drawback of ICMP or TCP solutions is that they can only work > when the first address is reachable at the beginning of the session. The DNS should have the initial set for connecting end for starters anyway. It was my assumption that this was a prerequisite to all the current discussion. It doesn't tell the other end what addresses you might be coming from though. That would require reverse DNS at the server end (assuming client/server type connections) and can be a matter of policy for heavily loaded sites. We do reverse dns on all our web servers because they are not loaded heavily, but I bet there are some heavily used sites which might not. In my experience having run web servers and also having written some too is that reverse DNS can significantly reduce the performance of the server. > > > The most difficult task is knowing which addresses to choose first based on DNS > > queries, > > You could check the addresses that come back from the DNS against the > routing table, but I suspect that won't help much to find the best route, > but would only help in avoiding a small set of failure modes. DNS will give roughly the same info, but may acquire it in a less efficient manner. Also current DNS has no mechanism for assigning address priorities. not unless we invent a new RR to do it. > > > choosing alternative addresses when a failure occurs and knowing when > > to start choosing an alternative address. We don't have much empirical > > experience with this and we are only guessing at the right way to do this. > > One system could be to periodically cycle through all available addresses > and gather statistics for each. After a while, the system would know which > addresses are best. We could even come up with a scheme to share this > information with other hosts. Thinking about an implementation for my > proposal, I came to the conclusion that there would need to be some kind > of "address discovery daemon" because waiting for DNS replies in the > kernel wouldn't be a very good idea. Such a daemon could of course > communicate to other instances of itself on other hosts. This opens many > cans of worms for sure, and massive amounts of work need to be done to get > it right, but there are many interesting possibilities. Depends if it's a passive or active approach to gather stats. If it involves extra traffic just for the sake of gathering statistics I don't think it will be popular. The passive approach would rely on traffic already taking place which I had already hinted at requiring doing in my proposal. > > Simple failover schemes are in use today and/or are available as > experimental implementations and nothing suggests that "if A doesn't work, > we'll use B" isn't at least a huge improvement over "if A doesn't work, > we do nothing". > > Iljitsch > > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Tue Sep 4 03:43:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05403 for ; Tue, 4 Sep 2001 03:43:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eArS-0006lK-00 for multi6-data@psg.com; Tue, 04 Sep 2001 00:43:06 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15eArR-0006lE-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 00:43:05 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id RAA14378 for ; Tue, 4 Sep 2001 17:43:03 +1000 (EST) Date: Tue, 4 Sep 2001 17:43:03 +1000 (EST) From: Peter Tattam To: Multi6 Working Group Subject: some research material Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk I ran into this about a month ago. http://physicsweb.org/article/world/14/7/09 some of the inferences about clustering may be important when discussion the implications of aggregation and multihoming. There is discussion relating to this article at http://slashdot.org/article.pl?sid=01/08/05/2025232 and another story cross referenced.. http://www.almaden.ibm.com/almaden/webmap_press.html Of course much of the material may actually be more related to hyperlinking than to connectivity, but it may be food for thought. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Tue Sep 4 05:04:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06236 for ; Tue, 4 Sep 2001 05:04:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eC8I-00082K-00 for multi6-data@psg.com; Tue, 04 Sep 2001 02:04:34 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15eC8H-00082C-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 02:04:33 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f8495Vx13573; Tue, 4 Sep 2001 11:05:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 4 Sep 2001 11:05:31 +0200 (CEST) From: Iljitsch van Beijnum To: Michel Py cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <2B81403386729140A3A899A8B39B046403ADA6@server2000.arneill-py.sacramento.ca.us> Message-ID: <20010904102846.O5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 3 Sep 2001, Michel Py wrote: > I would tend to say "visible over TWO or more transit networks" > for the following but agree on the rest. That way, every current style multihomer qualifies. I can see some dual-homed networks having a block of their own, but I certainly wouldn't want all of them to have an address block of their own. Also, using addresses from two blocks is not unreasonable, but a customer dual-homing to two triple-homing ISPs would have six address ranges, that is too much. Also note "globally visible". Here in The Netherlands many ISPs have one "real" uplink that is globally visible, but also connect to the Amsterdam Internet Exchange. I think it is reasonable in such a setup that they would use address space from their transit ISP and announce that space over the AMS-IX to local/regional peers. That way, the DFZ stays small but local/regional traffic can still find the shortest path. I know internet exchanges are out of vogue in the US, but they are a reality in Europe. The AMS-IX carries 3 Gbit/s of traffic, compared to 300 Mbit for the New York Internet Exchange, even though bandwidth is a lot cheaper in the US than in NL. The number of people that live in The Netherlands is comparable to that in the NYC metro area. (But then the AMS-IX is one of the four to six main exchange points in Europe.) > I am a little more reserved about this: > >> - using multiple address ranges is the only way disconnect > >> the growth in multihoming from the growth of the global > >> routing table > Until someone finds a mechanism that can do it. Ok, you're right, other ways, such as on-demand created routes, are possible, but I don't see it happening. > Besides, the > growth of the multihoming table, if it contain multihoming > prefixes only and not the result of poor summarizations could > be controllable as you mentionned above. I don't think it can be controlled, unless draconian measures are taken. I'm not as pessimistic as some others: I think the current multihoming practices could continue to work for the foreseeable future if BGP implementations can be optimized. Still, if we can create a good host-based multihoming solution, this will drain away much of the growth of current multihoming practices, giving us all more breathing room. Also, it makes multihoming reachable for everyone. With IPv6 we're in the unique position that the implementations are still very fluid, so we should take advantage of that. However, your proposal depends on changing the Internet core routing, which is very hard to change. Note that there is hardly any IPv6 routing in the core, while the changes in BGP necessary for this are minimal. Your approach is much more radical and I have a hard time seeing it happen. On the other hand, since there is so little IPv6 routing going on, there is a window of opportunity there as well. The main advantage of your proposal is that you solve the "alternative address discovery" problem. > Please take the time to have a look at: > http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt Note that a network that is part of the DFZ does not have "an ISP". You pay an ISP to route traffic to all destinations connected to the Net, in other words: you pay for a default. In the default-free zone there are no defaults (but the reverse is not always true: a network running without a default is not necessarily part of the DFZ) and you don't pay others to handle your traffic: you peer with them. (Although I'm sure there are some caveats there.) Iljitsch From owner-multi6@ops.ietf.org Tue Sep 4 05:51:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06770 for ; Tue, 4 Sep 2001 05:51:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eCs0-0008rR-00 for multi6-data@psg.com; Tue, 04 Sep 2001 02:51:48 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15eCrz-0008r9-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 02:51:47 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f849qkX13646; Tue, 4 Sep 2001 11:52:46 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 4 Sep 2001 11:52:46 +0200 (CEST) From: Iljitsch van Beijnum To: Peter Tattam cc: Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: <20010904111433.L5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Peter Tattam wrote: > > Doing this in the SYN/ACK handshake has the disadvantage that you have to > > do it over and over again for each TCP session. One popular application > > comes to mind that uses many short lived TCP sessions... > There is the chance that it can be made independent of the TCP session but > still tied to the sessions so that it may only need to be done once, and could > also work for other connection protocols. BTW, my current tcp proposal does > piggy back on the syn/ack so it's only just a little extra baggage. It's more > expensive to send extra packets than to piggy back on an existing packet IMHO. I'm not worried about something you might have to do once every hour or so: that may take a few packets. But these days many Web pages have more than 20 pictures. That could mean 20 TCP sessions, each negotiating all addresses all over again. That's not the best way to do it. But you could cache this information, of course. > > I think we should definately not rule out the DNS for this, unless we're > > absolutely sure this will not work. > In my experience, it's much easier to misconfigure DNS. There are a lot of > clueless admins out there who would not understand the implications of getting > it wrong. Even I'm guilty of stuffing up DNS delegations and SOA's in recent > times :) Sure it's easy to misconfigure the DNS. But it's easy to do a lot of things wrong. We're not trying to build a Word clone, where pressing random keys on the keybord has to result in the creation of a perfect business letter. > > And even if the DNS can't be trusted, it could still be a valuable source > > of "hints" that can be validated through some more secure means later. > I start to get nervous whenever I hear about needing a secure channel to > exchange information. If the system can operate without requiring rigorous > security, then it is one step more able to withstand a security attack than a > system that requires it. Security is a hot topic, with just about every IP weakness known and unknown to man being exploited today. We have to be sure the protocols we come up with aren't easily fooled by someone falsifying header information. But I agree with you: we shouldn't require all kinds of strong crypto in simple protocols. > > The major drawback of ICMP or TCP solutions is that they can only work > > when the first address is reachable at the beginning of the session. > The DNS should have the initial set for connecting end for starters anyway. In my proposal: not really. The alternative addresses can't be listed as valid A or AAAA records, since if these addresses can also receive regular traffic, the destination host can't easily determine if the destination address must be rewritten or not. On the other hand, if this is deemed very desirable, it could be done at the cost of keeping extra state and/or checking the TCP checksum with and without rewriting the destination address. The IP layer could discover the extra IP addresses through cooperation with the resolver library, bypassing the regular DNS -> application -> TCP -> IP path the destination address follows when creating application layer sessions so the socket API doesn't have to change. > It doesn't tell the other end what addresses you might be coming from though. Good point. But this information could easily be carried in an IP option. > > > choosing alternative addresses when a failure occurs and knowing when > > > to start choosing an alternative address. We don't have much empirical > > > experience with this and we are only guessing at the right way to do this. > > One system could be to periodically cycle through all available addresses > > and gather statistics for each. After a while, the system would know which > > addresses are best. > Depends if it's a passive or active approach to gather stats. If it involves > extra traffic just for the sake of gathering statistics I don't think it will > be popular. The passive approach would rely on traffic already taking place > which I had already hinted at requiring doing in my proposal. On hosts the passive approach would be appropriate. Changing to the next address periodically and keeping a copy of the RTT values for each address would probably do it. Maybe for routers that rewrite many sessions, the overhead of sending some extra packets is worth it. If we want to be really ambitious, we could come up with a TCP implementation that could actively take advantage of having multiple destination addresses. This TCP would load balance the traffic over the different destination addresses, exploiting different bandwidth and delay properties of the different paths. Iljitsch From owner-multi6@ops.ietf.org Tue Sep 4 06:48:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07215 for ; Tue, 4 Sep 2001 06:48:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eDkl-000BvR-00 for multi6-data@psg.com; Tue, 04 Sep 2001 03:48:23 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15eDkj-000BvK-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 03:48:22 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id UAA24378; Tue, 4 Sep 2001 20:48:14 +1000 (EST) Date: Tue, 4 Sep 2001 20:48:14 +1000 (EST) From: Peter Tattam To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <20010904111433.L5044-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Iljitsch van Beijnum wrote: > On Tue, 4 Sep 2001, Peter Tattam wrote: > > > > Doing this in the SYN/ACK handshake has the disadvantage that you have to > > > do it over and over again for each TCP session. One popular application > > > comes to mind that uses many short lived TCP sessions... > > > There is the chance that it can be made independent of the TCP session but > > still tied to the sessions so that it may only need to be done once, and could > > also work for other connection protocols. BTW, my current tcp proposal does > > piggy back on the syn/ack so it's only just a little extra baggage. It's more > > expensive to send extra packets than to piggy back on an existing packet IMHO. > > I'm not worried about something you might have to do once every hour or > so: that may take a few packets. But these days many Web pages have more > than 20 pictures. That could mean 20 TCP sessions, each negotiating all > addresses all over again. That's not the best way to do it. But you could > cache this information, of course. As the address exchange is controlled by the sender, I see no reason why a TCP stack should not use a cached value while any sessions exist in the established state. Any other states would need careful thought about whether the cached information s reliable enough. Of course the API should be able to control the desired behaviour if necessary. e.g. 1) normal behaviour (exchange addresses using cache if available) 2) IPv4 behaviour (single address) 3) normal behviour with no caching. BTW, web browsers these days are getting a little smarter by using keep alive HTTP connections - typically no more than 5-10 smultaneous connections. I recently added support for them into my web server. > > > > I think we should definately not rule out the DNS for this, unless we're > > > absolutely sure this will not work. > > > In my experience, it's much easier to misconfigure DNS. There are a lot of > > clueless admins out there who would not understand the implications of getting > > it wrong. Even I'm guilty of stuffing up DNS delegations and SOA's in recent > > times :) > > Sure it's easy to misconfigure the DNS. But it's easy to do a lot of > things wrong. We're not trying to build a Word clone, where pressing > random keys on the keybord has to result in the creation of a perfect > business letter. > > > > And even if the DNS can't be trusted, it could still be a valuable source > > > of "hints" that can be validated through some more secure means later. > > > I start to get nervous whenever I hear about needing a secure channel to > > exchange information. If the system can operate without requiring rigorous > > security, then it is one step more able to withstand a security attack than a > > system that requires it. > > Security is a hot topic, with just about every IP weakness known and > unknown to man being exploited today. We have to be sure the protocols we > come up with aren't easily fooled by someone falsifying header > information. But I agree with you: we shouldn't require all kinds of > strong crypto in simple protocols. > > > > The major drawback of ICMP or TCP solutions is that they can only work > > > when the first address is reachable at the beginning of the session. > > > The DNS should have the initial set for connecting end for starters anyway. > > In my proposal: not really. The alternative addresses can't be listed as > valid A or AAAA records, since if these addresses can also receive regular > traffic, the destination host can't easily determine if the destination > address must be rewritten or not. On the other hand, if this is deemed > very desirable, it could be done at the cost of keeping extra state and/or > checking the TCP checksum with and without rewriting the destination > address. > > The IP layer could discover the extra IP addresses through cooperation > with the resolver library, bypassing the regular DNS -> application -> TCP > -> IP path the destination address follows when creating application layer > sessions so the socket API doesn't have to change. so what are you suggesting? new RR's to list alternative addresses? Would this not be similar to reinventing AAAA records with priorities? Also, how do you plan to deal with stale DNS cache issues? If you flush DNS caches too quickly you would degenerate into getting information directly from the site. Why not just get the information directly from the site? A single packet exchange could carry quite a lot of information. With DNS only a single poorly configured server in the cache path to the destination would play havoc with any address determination. One of the reasons DNS works farily well now is that in general, name to address mapping & vice versa is relatively long lived. I typically see TLLs varying from 5 minutes up to 3 or more days. I don't have numbers on what the current distribution of TLLs is like but my guess is that 1 day would be about normal. And generally, the TLLs don't reflect how static a lot of the information in the DNS is. When we are talking about routability, that is likely to change on a per minute basis and you would want the change to be propagated globally as soon as possible. The more I think about DNS to do the job, less I am convinced that it can. I am of course assuming that you want to convey the best destination avilable via the DNS - forgive me if I misunderstand what you're saying. > > > It doesn't tell the other end what addresses you might be coming from though. > > Good point. But this information could easily be carried in an IP option. surprise surprise - that's what I'm proposing :) > > > > > choosing alternative addresses when a failure occurs and knowing when > > > > to start choosing an alternative address. We don't have much empirical > > > > experience with this and we are only guessing at the right way to do this. > > > > One system could be to periodically cycle through all available addresses > > > and gather statistics for each. After a while, the system would know which > > > addresses are best. > > > Depends if it's a passive or active approach to gather stats. If it involves > > extra traffic just for the sake of gathering statistics I don't think it will > > be popular. The passive approach would rely on traffic already taking place > > which I had already hinted at requiring doing in my proposal. > > On hosts the passive approach would be appropriate. Changing to the next > address periodically and keeping a copy of the RTT values for each address > would probably do it. Maybe for routers that rewrite many sessions, the > overhead of sending some extra packets is worth it. > > If we want to be really ambitious, we could come up with a TCP > implementation that could actively take advantage of having multiple > destination addresses. This TCP would load balance the traffic over the > different destination addresses, exploiting different bandwidth and delay > properties of the different paths. Umm. Nope. I don't think this will fly with the TCP people if done on an arbitrary basis. It's sure to screw around with RTT averages and muck up the retry mechanisms. You only want to send a packet by an alternative path as a last resort unless you are very sure that it will be. In my recent draft update, I suggested the idea of sending concurrent packets to all possible destinations at the start of the syn exchange. Basically you'd have an election to see which path wins & pick that. The downside is the duplicate traffic could send some people ballistic. In a TCP retry scenario which would suggest that the path may not be the optimal, you could pull the same trick to see if another path turns out to be better. The issue of load balancing is a thorny one & I'm not sure if any host based multihoming is going to be able to do that easily. I have to confess I can only guess at how load balancing is done with BGP. Perhaps those in the know might enlighten me. Another thought comes to mind. If we consider the possibility of hosts within a site "colluding" in the case of a provider path close by being down it might not take very many packets at all for most of the hosts in a site to shift their traffic pattern even before the individual connections start timing out. The connectiions could even send gratuitous acks ahead of time. It probably only takes a few to start the avalanche, but you would want to be damned sure that it couldn't be triggered by an attacker. Controlled multicast might be a good notification mechanism for this. Hmm.. we have something already in the way of router advertisements - why not use them properly. At the other end, if an ack for sent data in a TCP connection comes via a different path, it is a strong hint that the current path might not be the best and to start hunting for better paths. This is kind of advance warning that something has happened at the other end. This of course assumes that we are talking about symmetric network paths. Where traffic comes in via one provider and goes out by another it might be a waste of time. > > Iljitsch > > Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Tue Sep 4 07:43:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09418 for ; Tue, 4 Sep 2001 07:43:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eEd4-000Cxi-00 for multi6-data@psg.com; Tue, 04 Sep 2001 04:44:30 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15eEd2-000CxZ-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 04:44:29 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f84BjNv13753; Tue, 4 Sep 2001 13:45:23 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 4 Sep 2001 13:45:23 +0200 (CEST) From: Iljitsch van Beijnum To: Peter Tattam cc: Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: <20010904131044.Q5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Peter Tattam wrote: > As the address exchange is controlled by the sender, I see no reason why a TCP > stack should not use a cached value while any sessions exist in the established > state. Any other states would need careful thought about whether the cached > information s reliable enough. Of course the API should be able to control the > desired behaviour if necessary. Agree. > BTW, web browsers these days are getting a little smarter by using keep alive > HTTP connections - typically no more than 5-10 smultaneous connections. I > recently added support for them into my web server. I know the capability exists, but I have no idea to what extend it is actually used... > so what are you suggesting? new RR's to list alternative addresses? Would this > not be similar to reinventing AAAA records with priorities? In my proposal there would have to be a new type of resource record if the DNS is to be used for selecting alternative addresses. (Note that a host may have multiple "regular" addresses, each with one or more "alternatives".) I originally wanted to bind these RRs to the ip6.int zone, so they are easy to find with the "regular" address as the key. But if we hijack the DNS resolver library, we could find this information during the forward lookup stage. So this would not be the same as AAAA records with priorities, which seem like a good idea to be able to traffic engineer and load balance. > Also, how do you plan to deal with stale DNS cache issues? Not a problem: the DNS only lists addresses that might be valid, but does not convey any actual reachability information. The host has to discover if an address is reachable on its own. If proper host unreachables are sent, this can be done both easy and fast. > > > It doesn't tell the other end what addresses you might be coming from though. > > Good point. But this information could easily be carried in an IP option. > surprise surprise - that's what I'm proposing :) But you are proposing this in both directions, which is somewhat more problematic: you can only send an IP option if you can send period... But you could try each of the different addresses, of course. > > On hosts the passive approach would be appropriate. Changing to the next > > address periodically and keeping a copy of the RTT values for each address > > would probably do it. Maybe for routers that rewrite many sessions, the > > overhead of sending some extra packets is worth it. > > If we want to be really ambitious, we could come up with a TCP > > implementation that could actively take advantage of having multiple > > destination addresses. This TCP would load balance the traffic over the > > different destination addresses, exploiting different bandwidth and delay > > properties of the different paths. > Umm. Nope. I don't think this will fly with the TCP people if done on an > arbitrary basis. Are you commenting on the "really ambitious" part or the remark above it? > It's sure to screw around with RTT averages and muck up the retry mechanisms. Cycling through the list of addresses will of course have an impact on TCP operation (so it shouldn't be done too often), but it may be worth it if you discover a faster path. > You only want to send a packet by an alternative path as a > last resort unless you are very sure that it will be. That would be adequate. Better heuristics can be developed later. > In my recent draft update, I suggested the idea of sending concurrent packets > to all possible destinations at the start of the syn exchange. Basically you'd > have an election to see which path wins & pick that. The downside is the > duplicate traffic could send some people ballistic. :-) You would trigger all kinds of anti SYN-flood mechanisms. But if you need many TCP sessions anyway (such as when requesting HTML pages) I don't see anything wrong with it. > In a TCP retry scenario > which would suggest that the path may not be the optimal, you could pull the > same trick to see if another path turns out to be better. This would certainly not waste as many resources at the receiving end as doing it at the time of the SYN. However, in my rewriting mechanism the sender wouldn't normally know for which packet (to which address) an ACK is. That would require some more deep TCP magic. > The issue of load balancing is a thorny one & I'm not sure if any host based > multihoming is going to be able to do that easily. I agree that it wouldn't be easy. But since this could probably be implemented at the sender only, there is still incentive to do it anyway. > I have to confess I can only > guess at how load balancing is done with BGP. Perhaps those in the know might > enlighten me. In normal multihoming operation there is no load balancing at the session level. "Load balancing" in this context usually refers to trying to balance ALL traffic over the different pipes. BGP does support link-level load balancing when there are several pipes between two ASes: then BGP can add routes over each link to the forwarding information base so the links can be used concurrently. Depending on the router, they will be used in a per packet or per destination IP address round-robin fashion. > If we consider the possibility of hosts within a site "colluding" in the case > of a provider path close by being down it might not take very many packets at > all for most of the hosts in a site to shift their traffic pattern even before > the individual connections start timing out. The connectiions could even send > gratuitous acks ahead of time. It probably only takes a few to start the > avalanche, but you would want to be damned sure that it couldn't be triggered > by an attacker. Controlled multicast might be a good notification mechanism > for this. Hmm.. we have something already in the way of router advertisements > - why not use them properly. This could be very cool. > At the other end, if an ack for sent data in a TCP connection comes via a > different path, it is a strong hint that the current path might not be the best > and to start hunting for better paths. This is kind of advance warning that > something has happened at the other end. If the other side has interesting info, why not explicitly say so in an option? > This of course assumes that we are talking about symmetric network paths. > Where traffic comes in via one provider and goes out by another it might be a > waste of time. Asymmetric routing is very common in IPv4. However, short (and hopefully fast) paths are likelier to be symmetric. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Sep 4 09:04:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13542 for ; Tue, 4 Sep 2001 09:04:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eFsX-000EPQ-00 for multi6-data@psg.com; Tue, 04 Sep 2001 06:04:33 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.33 #1) id 15eFsW-000EOy-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 06:04:32 -0700 Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id JAA29361; Tue, 4 Sep 2001 09:04:22 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id JAA16292; Tue, 4 Sep 2001 09:03:40 -0400 (EDT) Date: Tue, 4 Sep 2001 09:03:40 -0400 (EDT) From: Greg Maxwell To: Iljitsch van Beijnum cc: Peter Tattam , Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <20010904083746.T5044-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Iljitsch van Beijnum wrote: > On Tue, 4 Sep 2001, Peter Tattam wrote: > > > The discovery of the alternative destination address is the crux of the problem > > and needs to be handled in such a manner as to prevent spoofing attacks. IPsec > > is too heavy to deal with the issue - my lightwieght proposal of a SYN/ACK > > exchange like TCP works but is subject to address list explosion issues which I > > hope to resolve through sending compressed address trees instead of lists or > > sets. > > Doing this in the SYN/ACK handshake has the disadvantage that you have to > do it over and over again for each TCP session. One popular application > comes to mind that uses many short lived TCP sessions... Intestingly enough SCTP addresses these applications (such as HTTP) rather well without overhead of assoication communication for every stream. From owner-multi6@ops.ietf.org Tue Sep 4 09:26:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14856 for ; Tue, 4 Sep 2001 09:26:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eGEm-000En8-00 for multi6-data@psg.com; Tue, 04 Sep 2001 06:27:32 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15eGEl-000Emu-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 06:27:31 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id GAA28946; Tue, 4 Sep 2001 06:27:10 -0700 (PDT) Date: Tue, 4 Sep 2001 06:27:10 -0700 (PDT) From: Ramakrishna Gummadi To: Greg Maxwell cc: Iljitsch van Beijnum , Peter Tattam , Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, I don't think that it is a good idea to assume that every multihomed host has a DNS entry (for whatever reason); such an "anonymous" multihomed host may initiate a connection, and a multihoming solution must work (redundancy, transport layer survivability, etc.) for these connections as well. This is my primary complaint with DNS-based solutions. My second complaint, and this applies to SCTP as well, is that we are implicitly assuming here that one end can do DNS lookups to learn the addresses of the other end---this may be impossible with busy servers. Also, I don't think it is a good idea to mandate every application to be aware of all multi-address details, which SCTP requires. We must remember that SCTP was invented primarily for carrying signaling messages (the abstract says as much), and one of its co-authors I talked to says he thinks that general applications should *not* have to deal with all these details. -ramki On Tue, 4 Sep 2001, Greg Maxwell wrote: > On Tue, 4 Sep 2001, Iljitsch van Beijnum wrote: > > > On Tue, 4 Sep 2001, Peter Tattam wrote: > > > > > The discovery of the alternative destination address is the crux of the problem > > > and needs to be handled in such a manner as to prevent spoofing attacks. IPsec > > > is too heavy to deal with the issue - my lightwieght proposal of a SYN/ACK > > > exchange like TCP works but is subject to address list explosion issues which I > > > hope to resolve through sending compressed address trees instead of lists or > > > sets. > > > > Doing this in the SYN/ACK handshake has the disadvantage that you have to > > do it over and over again for each TCP session. One popular application > > comes to mind that uses many short lived TCP sessions... > > Intestingly enough SCTP addresses these applications (such as HTTP) rather > well without overhead of assoication communication for every stream. > > > > > From owner-multi6@ops.ietf.org Tue Sep 4 09:31:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15136 for ; Tue, 4 Sep 2001 09:31:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eGKD-000Etn-00 for multi6-data@psg.com; Tue, 04 Sep 2001 06:33:09 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.33 #1) id 15eGKD-000Eth-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 06:33:09 -0700 Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id JAA00113; Tue, 4 Sep 2001 09:32:59 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id JAA20678; Tue, 4 Sep 2001 09:32:17 -0400 (EDT) Date: Tue, 4 Sep 2001 09:32:17 -0400 (EDT) From: Greg Maxwell To: Ramakrishna Gummadi cc: Iljitsch van Beijnum , Peter Tattam , Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Ramakrishna Gummadi wrote: [snip] > My second complaint, and this applies to SCTP as well, is that we are > implicitly assuming here that one end can do DNS lookups to learn the > addresses of the other end---this may be impossible with busy servers. This is not an issue for SCTP. SCTP learns assoiations from it's peer directly. The only time DNS plays into it is connection built-up, where DNS is required in the non-multihomed case as well. > Also, I don't think it is a good idea to mandate every application to be > aware of all multi-address details, which SCTP requires. We must remember > that SCTP was invented primarily for carrying signaling messages (the > abstract says as much), and one of its co-authors I talked to says he > thinks that general applications should *not* have to deal with all these > details. You can wrap a TCP like api so the application is unaware of any multihoming issues. Have you read the SCTP RFC? It's a very clear superset of TCP and every feature it has is an important feature that current apps are emulating at higher layers over TCP or UDP (like the use of concurant connections with HTTP to simulate multiple streams, or the abundance of UDP apps which impliment their own reliable deliverly (and usually misimpliment congestion control)). From owner-multi6@ops.ietf.org Tue Sep 4 09:57:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16281 for ; Tue, 4 Sep 2001 09:57:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eGiH-000FJq-00 for multi6-data@psg.com; Tue, 04 Sep 2001 06:58:01 -0700 Received: from viap090.atea.be ([194.78.143.90] helo=hrtades9.atea.be) by psg.com with esmtp (Exim 3.33 #1) id 15eGiF-000FJe-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 06:58:00 -0700 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SF8JX5LR; Tue, 4 Sep 2001 15:58:06 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 15:56:37 +0200 Message-ID: From: Coene Lode To: "'Ramakrishna Gummadi'" , Greg Maxwell Cc: Iljitsch van Beijnum , Peter Tattam , multi6@ops.ietf.org Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Tue, 4 Sep 2001 15:57:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-multi6@ops.ietf.org Precedence: bulk A few observations: > -----Original Message----- > From: Ramakrishna Gummadi [mailto:ramki@cs.berkeley.edu] > Sent: dinsdag 4 september 2001 15:27 > To: Greg Maxwell > Cc: Iljitsch van Beijnum; Peter Tattam; multi6@ops.ietf.org > Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) > > > Hi, > I don't think that it is a good idea to assume that every > multihomed host > has a DNS entry (for whatever reason); such an "anonymous" > multihomed host > may initiate a connection, and a multihoming solution must > work (redundancy, transport layer survivability, etc.) for these > connections as well. This is my primary complaint with DNS-based > solutions. > > My second complaint, and this applies to SCTP as well, is that we are > implicitly assuming here that one end can do DNS lookups to learn the > addresses of the other end---this may be impossible with busy servers. > I thought this was standard practice. Have a name of the other side, do a DNS lookup. And anyway, the busy servers are a DNS problem, not a SCTP problem. > Also, I don't think it is a good idea to mandate every > application to be > aware of all multi-address details, which SCTP requires. We > must remember > that SCTP was invented primarily for carrying signaling messages (the > abstract says as much), and one of its co-authors I talked to says he > thinks that general applications should *not* have to deal > with all these > details. As far as I know multihoming, having multiple addresses is the only way for SCTP to multihome. If we had had the ability for a single identifier to specify the multihomed association, I(amongst others) would have been more than joyfull. Unfortunally, that not how multihoming works in the internet. You have to come up with more than one IP address and each sour_destination pair should(in theory) have its own path between the 2 endnodes. and each of these paths should((which again in theory) not overlap wholly or partly. If multihoming is done via multiple addresses, then we have to live by its consequences. Yours sincerly, Lode Coene > > -ramki > > On Tue, 4 Sep 2001, Greg Maxwell wrote: > > > On Tue, 4 Sep 2001, Iljitsch van Beijnum wrote: > > > > > On Tue, 4 Sep 2001, Peter Tattam wrote: > > > > > > > The discovery of the alternative destination address is > the crux of the problem > > > > and needs to be handled in such a manner as to prevent > spoofing attacks. IPsec > > > > is too heavy to deal with the issue - my lightwieght > proposal of a SYN/ACK > > > > exchange like TCP works but is subject to address list > explosion issues which I > > > > hope to resolve through sending compressed address > trees instead of lists or > > > > sets. > > > > > > Doing this in the SYN/ACK handshake has the disadvantage > that you have to > > > do it over and over again for each TCP session. One > popular application > > > comes to mind that uses many short lived TCP sessions... > > > > Intestingly enough SCTP addresses these applications (such > as HTTP) rather > > well without overhead of assoication communication for every stream. > > > > > > > > > > > > From owner-multi6@ops.ietf.org Tue Sep 4 10:31:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17681 for ; Tue, 4 Sep 2001 10:31:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eHFJ-000Fxr-00 for multi6-data@psg.com; Tue, 04 Sep 2001 07:32:09 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15eHFI-000Fxc-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 07:32:09 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 766BE8266E; Tue, 4 Sep 2001 10:31:56 -0400 (EDT) Message-Id: <5.1.0.14.2.20010904101834.01da9a00@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 10:26:06 -0400 To: Iljitsch van Beijnum From: RJ Atkinson Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Cc: In-Reply-To: <20010904102846.O5044-100000@sequoia.muada.com> References: <2B81403386729140A3A899A8B39B046403ADA6@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 05:05 04/09/01, Iljitsch van Beijnum wrote: >I know internet exchanges are out of vogue in the US, but they are a >reality in Europe. The AMS-IX carries 3 Gbit/s of traffic, compared to 300 >Mbit for the New York Internet Exchange, even though bandwidth is a lot >cheaper in the US than in NL. The number of people that live in The >Netherlands is comparable to that in the NYC metro area. (But then the >AMS-IX is one of the four to six main exchange points in Europe.) The above is not a good comparison. Virtually no international links terminate in NYC metro (most US-side termination of trans-Atlantic links is in/near southern NJ instead). Lots of international links terminate in AMS metro area. AMS-IX, LINX, MAE-E, MAE-W, and Pennsauken NAP are all viable exchanges (and will be long into the future) because they facilitate *regional* and *international* interconnects, not merely metro interconnects. Ran rja@inet.org From owner-multi6@ops.ietf.org Tue Sep 4 10:34:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17762 for ; Tue, 4 Sep 2001 10:34:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eHIc-000G1v-00 for multi6-data@psg.com; Tue, 04 Sep 2001 07:35:34 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15eHIb-000G1p-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 07:35:33 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id C661D8266E; Tue, 4 Sep 2001 10:35:31 -0400 (EDT) Message-Id: <5.1.0.14.2.20010904102656.01daab90@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 10:29:41 -0400 To: Ramakrishna Gummadi From: RJ Atkinson Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 09:27 04/09/01, Ramakrishna Gummadi wrote: >Hi, >I don't think that it is a good idea to assume that every >multihomed host has a DNS entry (for whatever reason) Today if a host doesn't have a DNS entry, it generally has NIL incoming connectivity. The Internet Architecture expects hosts to have DNS entries, so such an assumption and constraint is totally reasonable. >My second complaint, and this applies to SCTP as well, is that we are >implicitly assuming here that one end can do DNS lookups to learn the >addresses of the other end---this may be impossible with busy servers. In deployed reality, this just is NOT an actual problem or issue. There are LOTS of real issues and problems with multi-homing. It would be a lot more constructive if you focused on those, rather than trying to invent new issues/problems artificially out of non-issue/non-problems. Cheers, Ran rj@inet.org From owner-multi6@ops.ietf.org Tue Sep 4 11:12:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18656 for ; Tue, 4 Sep 2001 11:11:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eHrq-000Gkk-00 for multi6-data@psg.com; Tue, 04 Sep 2001 08:11:58 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15eHrp-000Gke-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 08:11:57 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f84FCp914002; Tue, 4 Sep 2001 17:12:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 4 Sep 2001 17:12:51 +0200 (CEST) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <5.1.0.14.2.20010904101834.01da9a00@10.30.15.2> Message-ID: <20010904164422.L5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, RJ Atkinson wrote: > At 05:05 04/09/01, Iljitsch van Beijnum wrote: > >I know internet exchanges are out of vogue in the US, but they are a > >reality in Europe. The AMS-IX carries 3 Gbit/s of traffic, compared to 300 > >Mbit for the New York Internet Exchange, even though bandwidth is a lot > >cheaper in the US than in NL. The number of people that live in The > >Netherlands is comparable to that in the NYC metro area. (But then the > >AMS-IX is one of the four to six main exchange points in Europe.) > The above is not a good comparison. Granted, it shows only part of the picture. > Virtually no > international links terminate in NYC metro (most US-side termination > of trans-Atlantic links is in/near southern NJ instead). Lots of > international links terminate in AMS metro area. Chicken/egg: why would all those lines that come in in cities like Noordwijk, Domburg and Alkmaar go to Amsterdam? Because all the ISPs are there. And why are all the ISPs there? Because the AMS-IX is there. (Well, ok, the fact that some people fail to notice that there is more to NL than Amsterdam probably has something to do with it too.) I seem to remember many lines going directly into NYC in the past, though. > AMS-IX, LINX, MAE-E, MAE-W, and Pennsauken NAP are all viable > exchanges (and will be long into the future) because they facilitate > *regional* and *international* interconnects, not merely metro > interconnects. Apart from being a regional/international exchange, the AMS-IX also functions as a national exchange. In the US, it makes sense to transport traffic a few hundred kilometers to a large exchange point. In Europe, that often means you are in another country, which makes lines more expensive and harder to get. So every country has at least one national exchange, and not connecting to that exchange is very bad for business for ISPs. Look at the Brussels IX: an exchange 200 km from two of the largest echanges in the continent wouldn't have a chance in the US, while in a small country like Belgium it still carries 400 Mbps and has 45 members. Real metro interconnects haven't surfaced here either. Iljitsch From owner-multi6@ops.ietf.org Tue Sep 4 11:22:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19164 for ; Tue, 4 Sep 2001 11:22:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eI34-000GyJ-00 for multi6-data@psg.com; Tue, 04 Sep 2001 08:23:34 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15eI32-000Gy9-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 08:23:33 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f84FOWN14012; Tue, 4 Sep 2001 17:24:32 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 4 Sep 2001 17:24:32 +0200 (CEST) From: Iljitsch van Beijnum To: Ramakrishna Gummadi cc: Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: <20010904163046.T5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Ramakrishna Gummadi wrote: > I don't think that it is a good idea to assume that every multihomed host > has a DNS entry (for whatever reason); such an "anonymous" multihomed host > may initiate a connection, and a multihoming solution must > work (redundancy, transport layer survivability, etc.) for these > connections as well. This is my primary complaint with DNS-based > solutions. That is why I want this information to be in (somewhat) arbitrary places in the reversed mapping zone, so it is not necessary for each host to have DNS entries for all addresses. (Which is very unlikely for hosts implementing RFC 3041.) I think doing reverse lookups for the /128, /64 and /48 in question should do it. Requiring someone to run a reverse DNS with one entry so an entire /48 can be multihomed doesn't seem like a problematic requirement to me. On the other hand, ICMP and IP option based solutions could work well too. > My second complaint, and this applies to SCTP as well, is that we are > implicitly assuming here that one end can do DNS lookups to learn the > addresses of the other end---this may be impossible with busy servers. Generally, the communication over TCP/IP works like this: an application connects to a remote host, of which it almost always knows the host name (but sometimes just a (one) IP address). The remote host accepts the connection, communication happens, the connection is torn down. In this scenario it would be best if the originating side knows all (or at least: more than one) of the addresses of the "server" it wants to connect to, but it is not necessary for this server to know any addresses of the other side before the connection is established: the fact that a connection request comes in means that there is enough connectivity to negotiate additional addresses. If we want to keep the multihoming in layer 3, it is good to remember that additional address discovery / address status discovery mechanisms are not tied to a single session. From owner-multi6@ops.ietf.org Tue Sep 4 11:36:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19577 for ; Tue, 4 Sep 2001 11:36:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eIG8-000HG4-00 for multi6-data@psg.com; Tue, 04 Sep 2001 08:37:04 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15eIG7-000HFy-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 08:37:03 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id IAA01744; Tue, 4 Sep 2001 08:36:57 -0700 (PDT) Date: Tue, 4 Sep 2001 08:36:56 -0700 (PDT) From: Ramakrishna Gummadi To: RJ Atkinson cc: Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <5.1.0.14.2.20010904102656.01daab90@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > Today if a host doesn't have a DNS entry, it generally has NIL > incoming connectivity. The Internet Architecture expects hosts > to have DNS entries, so such an assumption and constraint > is totally reasonable. But it may still have outgoing activity. For example, it may be a mobile client in a multihomed site. We cannot assume only servers are going to be multihomed. cheers, ramki From owner-multi6@ops.ietf.org Tue Sep 4 12:12:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20256 for ; Tue, 4 Sep 2001 12:12:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eInz-000I3o-00 for multi6-data@psg.com; Tue, 04 Sep 2001 09:12:03 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15eIny-000I3i-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 09:12:02 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 414BB8266E; Tue, 4 Sep 2001 12:11:55 -0400 (EDT) Message-Id: <5.1.0.14.2.20010904115721.00a2e4c0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 12:06:04 -0400 To: Iljitsch van Beijnum From: RJ Atkinson Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Cc: In-Reply-To: <20010904164422.L5044-100000@sequoia.muada.com> References: <5.1.0.14.2.20010904101834.01da9a00@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 11:12 04/09/01, Iljitsch van Beijnum wrote: >Chicken/egg: why would all those lines that come in in cities like >Noordwijk, Domburg and Alkmaar go to Amsterdam? Because all the ISPs are >there. Actually, no. They go there because that is how the physical fibre runs -- and those aren't the driving cities in any event. It is the fibre runs from Amsterdam to Paris, Frankfurt, Scandanavia, under the ocean, and other longer distance places that make AMS-IX interesting to ISPs as an interconnect. >I seem to remember many lines going directly into NYC in the past, though. Not as the trans-Atlantic fibre runs it doesn't -- and hasn't ever. In NYC there is too much chance of a ship anchor or fishing boat or dredge accidentally pulling up the cable when it gets near to the shoreline. >Apart from being a regional/international exchange, the AMS-IX also >functions as a national exchange. ISPs are indifferent to national exchanges. It is the regional/ international exchanges that make economic sense to ISPs today. >So every country has at least one national exchange, and >not connecting to that exchange is very bad for business for ISPs. Not when I've seen the full economic analysis. For example in the EU our analysis was that LINX and AMS-IX were the only two exchange points that made economic sense for the particular multi-continent ISP at the time (which is reasonably recently). However, lets take this offline unless it gets tied firmly back to multi6 topics in the interest of good list S/N ratio. :-) Ran rja@inet.org From owner-multi6@ops.ietf.org Tue Sep 4 12:14:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20288 for ; Tue, 4 Sep 2001 12:14:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eIoh-000I4w-00 for multi6-data@psg.com; Tue, 04 Sep 2001 09:12:47 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15eIog-000I4q-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 09:12:47 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 702C78266E; Tue, 4 Sep 2001 12:12:45 -0400 (EDT) Message-Id: <5.1.0.14.2.20010904120616.009ee9a0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 12:06:55 -0400 To: Ramakrishna Gummadi From: RJ Atkinson Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) Cc: In-Reply-To: References: <5.1.0.14.2.20010904102656.01daab90@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 11:36 04/09/01, Ramakrishna Gummadi wrote: >But it may still have outgoing activity. For example, it may be a >mobile client in a multihomed site. We cannot assume only servers are >going to be multihomed. Didn't suggest as much. With Mobile IP, there is no reason why a mobile host does not have a stable IP address in DNS. In fact, such hosts normally do so today. Ran From owner-multi6@ops.ietf.org Tue Sep 4 12:28:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20600 for ; Tue, 4 Sep 2001 12:28:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eJ53-000IVB-00 for multi6-data@psg.com; Tue, 04 Sep 2001 09:29:41 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.33 #1) id 15eJ52-000IV4-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 09:29:40 -0700 Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id MAA04146; Tue, 4 Sep 2001 12:29:30 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id MAA05099; Tue, 4 Sep 2001 12:28:49 -0400 (EDT) Date: Tue, 4 Sep 2001 12:28:48 -0400 (EDT) From: Greg Maxwell To: RJ Atkinson cc: Ramakrishna Gummadi , Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <5.1.0.14.2.20010904120616.009ee9a0@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, RJ Atkinson wrote: > At 11:36 04/09/01, Ramakrishna Gummadi wrote: > >But it may still have outgoing activity. For example, it may be a > >mobile client in a multihomed site. We cannot assume only servers are > >going to be multihomed. > > Didn't suggest as much. With Mobile IP, there is no reason why > a mobile host does not have a stable IP address in DNS. In fact, > such hosts normally do so today. Such address is usually an unoptimum tunnled address. From owner-multi6@ops.ietf.org Tue Sep 4 12:43:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20930 for ; Tue, 4 Sep 2001 12:43:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eJJC-000IvA-00 for multi6-data@psg.com; Tue, 04 Sep 2001 09:44:18 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15eJJC-000Iv4-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 09:44:18 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id JAA04040; Tue, 4 Sep 2001 09:44:15 -0700 (PDT) Date: Tue, 4 Sep 2001 09:44:14 -0700 (PDT) From: Ramakrishna Gummadi To: Greg Maxwell cc: Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > On Tue, 4 Sep 2001, Ramakrishna Gummadi wrote: > > [snip] > > My second complaint, and this applies to SCTP as well, is that we are > > implicitly assuming here that one end can do DNS lookups to learn the > > addresses of the other end---this may be impossible with busy servers. > > This is not an issue for SCTP. SCTP learns assoiations from it's peer > directly. The only time DNS plays into it is connection built-up, where > DNS is required in the non-multihomed case as well. A busy public web server today can defer (reverse) DNS lookups (if it does lookups at all) and just record the client addresses in logs. In multihomed case, DNS lookup is necessary for connection survivability, which means it has to be done online. I don't think the semantics are the same in these two cases. > > Also, I don't think it is a good idea to mandate every application to be > > aware of all multi-address details, which SCTP requires. We must remember > > that SCTP was invented primarily for carrying signaling messages (the > > abstract says as much), and one of its co-authors I talked to says he > > thinks that general applications should *not* have to deal with all these > > details. > > You can wrap a TCP like api so the application is unaware of any > multihoming issues. May not be as simple as it sounds because SCTP is designed to be asynchronous, with notifications, etc. Supporting this transparently can be problematic without threading support to wrap SCTP behavior... > Have you read the SCTP RFC? It's a very clear superset of TCP and every > feature it has is an important feature that current apps are emulating at > higher layers over TCP or UDP (like the use of concurant connections with > HTTP to simulate multiple streams, or the abundance of UDP apps which > impliment their own reliable deliverly (and usually misimpliment > congestion control)). I read the RFC fairly carefully, and even though it may be a superset of TCP, the api is not app-transparent like tcp, and can not be directly used by simple single-threaded apps. -ramki From owner-multi6@ops.ietf.org Tue Sep 4 12:47:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21041 for ; Tue, 4 Sep 2001 12:47:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eJNC-000J12-00 for multi6-data@psg.com; Tue, 04 Sep 2001 09:48:26 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15eJNB-000J0v-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 09:48:25 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id JAA04245 for ; Tue, 4 Sep 2001 09:48:24 -0700 (PDT) Date: Tue, 4 Sep 2001 09:48:24 -0700 (PDT) From: Ramakrishna Gummadi To: Subject: Multicast question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, One question I have to this group is how easy do folks think it is to support the various forms of multicast (reliable, source-specific, etc.) with host-level solutions. thanks, ramki From owner-multi6@ops.ietf.org Tue Sep 4 12:59:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21404 for ; Tue, 4 Sep 2001 12:59:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eJYM-000JK1-00 for multi6-data@psg.com; Tue, 04 Sep 2001 09:59:58 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.33 #1) id 15eJYL-000JJv-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 09:59:58 -0700 Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id MAA04635; Tue, 4 Sep 2001 12:59:47 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id MAA06630; Tue, 4 Sep 2001 12:59:06 -0400 (EDT) Date: Tue, 4 Sep 2001 12:59:06 -0400 (EDT) From: Greg Maxwell To: Ramakrishna Gummadi cc: Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Ramakrishna Gummadi wrote: > > On Tue, 4 Sep 2001, Ramakrishna Gummadi wrote: > > > > [snip] > > > My second complaint, and this applies to SCTP as well, is that we are > > > implicitly assuming here that one end can do DNS lookups to learn the > > > addresses of the other end---this may be impossible with busy servers. > > > > This is not an issue for SCTP. SCTP learns assoiations from it's peer > > directly. The only time DNS plays into it is connection built-up, where > > DNS is required in the non-multihomed case as well. > > A busy public web server today can defer (reverse) DNS lookups (if it does > lookups at all) and just record the client addresses in logs. In > multihomed case, DNS lookup is necessary for connection survivability, > which means it has to be done online. I don't think the semantics are the > same in these two cases. It's a total layering violation to require DNS lookups in this place. SCTP has no such requirement, clear you confusion child. The only reason that DNS has to be aware of multiple prefixes AT ALL, is because the client needs 1 working prefix to bring up a connection. As the connection is brought up, the client may transmit the rest of it's prefixes to the server and ther server may do the same to the client. With a minor extension likely to be in most SCTP implimentations, nodes can transmit additional endpoint addresses at any time during communications. Again, the DNS lookup in the SCTP case is only needed where one would be needed anyways, but it provides just a little more information. > May not be as simple as it sounds because SCTP is designed to be > asynchronous, with notifications, etc. Supporting this transparently can > be problematic without threading support to wrap SCTP behavior... You can open a single stream and pretend it's TCP. Yes, if you want to take advantage of multiple streams (which HTTP really should do!) you will need some massive application chages. Nice thing is that it could be done totally transparently and SHTTP 1.1 could over time be migrated to SHTTP 1.2. > > Have you read the SCTP RFC? It's a very clear superset of TCP and every > > feature it has is an important feature that current apps are emulating at > > higher layers over TCP or UDP (like the use of concurant connections with > > HTTP to simulate multiple streams, or the abundance of UDP apps which > > impliment their own reliable deliverly (and usually misimpliment > > congestion control)). > > I read the RFC fairly carefully, and even though it may be a superset of > TCP, the api is not app-transparent like tcp, and can not be directly used > by simple single-threaded apps. Yes it can. You can open a single stream and pretend you are talking on a TCP connection totally transparently. Yes, you don't get all the advantages, but you do get multihoming. From owner-multi6@ops.ietf.org Tue Sep 4 13:52:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22779 for ; Tue, 4 Sep 2001 13:52:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eKNL-000KYo-00 for multi6-data@psg.com; Tue, 04 Sep 2001 10:52:39 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15eKNK-000KYY-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 10:52:38 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 373C18266F; Tue, 4 Sep 2001 13:52:37 -0400 (EDT) Message-Id: <5.1.0.14.2.20010904134606.00a1c1e0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 13:46:46 -0400 To: Greg Maxwell From: RJ Atkinson Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) Cc: In-Reply-To: References: <5.1.0.14.2.20010904120616.009ee9a0@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 12:28 04/09/01, Greg Maxwell wrote: >Such address is usually an unoptimum tunnled address. It moves bits fine and there are reportedly methods in Mobile IP for rapidly learning a more optimum address. From owner-multi6@ops.ietf.org Tue Sep 4 13:53:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22805 for ; Tue, 4 Sep 2001 13:53:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eKPI-000Kal-00 for multi6-data@psg.com; Tue, 04 Sep 2001 10:54:40 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15eKPI-000Kad-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 10:54:40 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 5A0268266F; Tue, 4 Sep 2001 13:54:33 -0400 (EDT) Message-Id: <5.1.0.14.2.20010904134708.00a35960@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 13:48:42 -0400 To: Ramakrishna Gummadi From: RJ Atkinson Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 12:44 04/09/01, Ramakrishna Gummadi wrote: >In multihomed case, DNS lookup is necessary for connection survivability, >which means it has to be done online. Disagree that a reverse DNS lookup is necessary for connection survivability when multihoming. Ran From owner-multi6@ops.ietf.org Tue Sep 4 15:17:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24979 for ; Tue, 4 Sep 2001 15:17:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eLhi-000MPK-00 for multi6-data@psg.com; Tue, 04 Sep 2001 12:17:46 -0700 Received: from mail2.microsoft.com ([131.107.3.124] helo=inet-vrs-02.redmond.corp.microsoft.com) by psg.com with smtp (Exim 3.33 #1) id 15eLhh-000MPE-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 12:17:45 -0700 Received: from 157.54.9.108 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Sep 2001 12:17:10 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Sep 2001 12:17:09 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Sep 2001 12:17:09 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Sep 2001 12:16:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Tue, 4 Sep 2001 12:16:40 -0700 Message-ID: Thread-Topic: Multihoming by IP Layer Address Rewriting (MILAR) Thread-Index: AcE1T32A0PxQVIyISDy/xBBjg+JxVQAJfB9w From: "Christian Huitema" To: "RJ Atkinson" , "Ramakrishna Gummadi" Cc: X-OriginalArrivalTime: 04 Sep 2001 19:16:41.0551 (UTC) FILETIME=[20C885F0:01C13576] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA24979 > From: RJ Atkinson [mailto:rja@inet.org] > At 09:27 04/09/01, Ramakrishna Gummadi wrote: > >Hi, > >I don't think that it is a good idea to assume that every > >multihomed host has a DNS entry (for whatever reason) > > Today if a host doesn't have a DNS entry, it generally has NIL > incoming connectivity. The Internet Architecture expects hosts > to have DNS entries, so such an assumption and constraint > is totally reasonable. Ran, this is false. Game stations, and PC running video-games, obtain incoming connectivity by registering their address in a game lobby. Instant messaging allows you to invite a peer to set up a connection to your address, for purposes such as file transfer, application sharing, or phone calls. SIP proxies allows you to receive invitation at whatever address you happen to be registered with. Napster clients receive file transfer requests because they register their addresses in the server. Nodes in peer-to-peer network obtain incoming connectivity by somehow publishing their address in the peer-to-peer cloud. There is no dependency between connectivity and the DNS, and there should not be. A multi-homing solution that depends on the DNS is a non starter. -- Christian Huitema From owner-multi6@ops.ietf.org Tue Sep 4 15:23:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25166 for ; Tue, 4 Sep 2001 15:23:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eLoI-000MYq-00 for multi6-data@psg.com; Tue, 04 Sep 2001 12:24:34 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15eLoH-000MYk-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 12:24:33 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id A07038266E; Tue, 4 Sep 2001 15:24:31 -0400 (EDT) Message-Id: <5.1.0.14.2.20010904151748.00a9a0d0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 15:18:40 -0400 To: "Christian Huitema" From: RJ Atkinson Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 15:16 04/09/01, Christian Huitema wrote: >Game stations, and PC running video-games, obtain >incoming connectivity by registering their address in a game lobby. Christian, A few special cases != generally. Ran rja@inet.org From owner-multi6@ops.ietf.org Tue Sep 4 15:44:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25606 for ; Tue, 4 Sep 2001 15:44:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eM8Y-000N2D-00 for multi6-data@psg.com; Tue, 04 Sep 2001 12:45:30 -0700 Received: from mail4.microsoft.com ([131.107.3.122] helo=inet-vrs-04.redmond.corp.microsoft.com) by psg.com with smtp (Exim 3.33 #1) id 15eM8Y-000N27-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 12:45:30 -0700 Received: from 157.54.9.100 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Sep 2001 12:45:29 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Sep 2001 12:45:29 -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(5.0.2195.2966); Tue, 4 Sep 2001 12:45:29 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Sep 2001 12:45:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Tue, 4 Sep 2001 12:45:00 -0700 Message-ID: Thread-Topic: Multihoming by IP Layer Address Rewriting (MILAR) Thread-Index: AcE1dzARoGAOHCVCQV26+CfR6AFiiQAAGC+A From: "Christian Huitema" To: "RJ Atkinson" Cc: X-OriginalArrivalTime: 04 Sep 2001 19:45:01.0253 (UTC) FILETIME=[15E27750:01C1357A] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA25606 > From: RJ Atkinson [mailto:rja@inet.org] > At 15:16 04/09/01, Christian Huitema wrote: > >Game stations, and PC running video-games, obtain > >incoming connectivity by registering their address in a game lobby. > > Christian, > > A few special cases != generally. We are not speaking of a few special cases here. Game players are in the tens of millions, at least. Last time I looked at the IM market, there were at least 150 million users. Many of us hope to see Internet telephony grow to the size of the existing telephone network. Napster had at one point 70 million users... I will grant you that the vast majority of web servers can be reached on the DNS. But that is definitely not a reason to build a dependency between IP and the DNS. I want to support game users, I want to let then multi-home between DSL and Cable. There is also a practicality issue. The current DNS practice would hit any DNS based scheme in multiple ways: many reverse (PTR) entries, and in fact many direct (A, AAAA) entries are "pro-forma", such as "64-5-6-7.example.net"; many server entries use multiple A records for load balancing, with addresses pointing at different servers. You will get maximum confusion if you try to use the existing data for multi-homing. Then, there is a performance issue. Last time I checked, about 25% of DNS queries took more than 3 seconds to complete. In fact, if you look at http://www.netsizer.com/daily/quality_today.html, you observe that at least 5% of queries for the addresses of large servers don't complete in less than 3 seconds, and that 5% of queries for the addresses of small servers don't complete in less than 6 seconds! I don't believe that adding more load to the DNS is a good idea, when the infrastructure is so obviously strained. There is an obvious alternative to DNS discovery of peer addresses, which is, have the peer tell you. We obviously have to wrestle with the security implications, but there have to be solutions -- nonce, s-key, self signed certificates, etc. We don't need to throw a server in the mix. -- Christian Huitema From owner-multi6@ops.ietf.org Tue Sep 4 15:47:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25660 for ; Tue, 4 Sep 2001 15:47:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eMBD-000N6X-00 for multi6-data@psg.com; Tue, 04 Sep 2001 12:48:15 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15eMBC-000N6Q-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 12:48:14 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f84JnGG14333; Tue, 4 Sep 2001 21:49:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 4 Sep 2001 21:49:16 +0200 (CEST) From: Iljitsch van Beijnum To: Christian Huitema cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: <20010904214747.M5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Christian Huitema wrote: > There is no dependency between connectivity and the DNS, and there > should not be. A multi-homing solution that depends on the DNS is a non > starter. Are you saying that if there is a good way to implement multihoming that requires a globally distributed hierarchical database system, we should create a new one? Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Sep 4 15:59:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26136 for ; Tue, 4 Sep 2001 15:59:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eMMw-000NRd-00 for multi6-data@psg.com; Tue, 04 Sep 2001 13:00:22 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15eMMv-000NRW-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 13:00:21 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f84K1OZ14374; Tue, 4 Sep 2001 22:01:25 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 4 Sep 2001 22:01:24 +0200 (CEST) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <5.1.0.14.2.20010904115721.00a2e4c0@10.30.15.2> Message-ID: <20010904214256.T5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, RJ Atkinson wrote: > >Apart from being a regional/international exchange, the AMS-IX also > >functions as a national exchange. > ISPs are indifferent to national exchanges. It is the regional/ > international exchanges that make economic sense to ISPs today. A bit of economic sense. Many years ago, I did some traffic analysis. I concluded that for an average dial-up ISP 45% of the traffic was transatlantic, 10% to the rest of Europe and 45% to destinations within The Netherlands. I haven't repeated the full analysis, but as far as I've seen, this pattern has stayed very much the same. Now, considering that: - there are no other exchanges to speak of (yet) in NL - relatively few other Dutch networks connect to other European exchanges, and those that do to relatively few of them would you agree that it makes economic sense for a Dutch network to connect to the AMS-IX? I've seen it time and time again (and I've had a hand in it a few times too): as soon as a Dutch network that provides transit services, be it dial-up, leased lines or colo, starts to use more than one or two E1s it connects to the AMS-IX. > However, lets take this offline unless it gets tied firmly > back to multi6 topics in the interest of good list S/N ratio. :-) I've made all my points on the subject, I think. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Sep 4 16:00:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26155 for ; Tue, 4 Sep 2001 16:00:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eMMp-000NRU-00 for multi6-data@psg.com; Tue, 04 Sep 2001 13:00:15 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15eMMo-000NRO-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 13:00:14 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id NAA11187; Tue, 4 Sep 2001 13:00:11 -0700 (PDT) Date: Tue, 4 Sep 2001 13:00:09 -0700 (PDT) From: Ramakrishna Gummadi To: RJ Atkinson cc: Christian Huitema , Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <5.1.0.14.2.20010904151748.00a9a0d0@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk An article (http://www.menandmice.com/6000/61_recent_survey.html) says 78.5% of .com zones are misconfigured, with problems ranging from lame delegations to non-responding authoritative name servers to incorrect match between delegation data and zone data. I don't think that we should create a dependency between routing (even if it is for multihoming) and DNS that can be hurt by these kinds of misconfigurations, even if we assume that every internet device is required (which I think is impossible to do for various reasons, including non-technical) to be hosted in DNS. -ramki On Tue, 4 Sep 2001, RJ Atkinson wrote: > At 15:16 04/09/01, Christian Huitema wrote: > >Game stations, and PC running video-games, obtain > >incoming connectivity by registering their address in a game lobby. > > Christian, > > A few special cases != generally. > > Ran > rja@inet.org > > > From owner-multi6@ops.ietf.org Tue Sep 4 16:07:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26386 for ; Tue, 4 Sep 2001 16:07:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eMUk-000NeA-00 for multi6-data@psg.com; Tue, 04 Sep 2001 13:08:26 -0700 Received: from mail1.microsoft.com ([131.107.3.125] helo=inet-vrs-01.redmond.corp.microsoft.com) by psg.com with smtp (Exim 3.33 #1) id 15eMUj-000Ne3-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 13:08:25 -0700 Received: from 157.54.9.100 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Sep 2001 13:08:14 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Sep 2001 13:08:16 -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(5.0.2195.2966); Tue, 4 Sep 2001 13:08:16 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Sep 2001 13:07:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Tue, 4 Sep 2001 13:07:47 -0700 Message-ID: Thread-Topic: Multihoming by IP Layer Address Rewriting (MILAR) Thread-Index: AcE1enwUudblq6MBQ4erPR1Z1msBJwAASP/w From: "Christian Huitema" To: "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 04 Sep 2001 20:07:48.0331 (UTC) FILETIME=[44BA03B0:01C1357D] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA26386 > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > > On Tue, 4 Sep 2001, Christian Huitema wrote: > > > There is no dependency between connectivity and the DNS, and there > > should not be. A multi-homing solution that depends on the DNS is a > non > > starter. > > Are you saying that if there is a good way to implement multihoming > that requires a globally distributed hierarchical database system, we > should create a new one? Well, you should first prove that we actually need a globally distributed hierarchical database. I don't think so. We start with the assumption that hosts have multiple addresses, but that the corresponding host only knows one of them. The obvious solution is to have the peers use the address they know to learn the addresses they don't. Using a third party as a server is a tortuous way to solve the problem. There are indeed security issues, and we need to address them. So far, I see at least two security issues: 1) Spoofing. Alice speaks to Bob at address B; Eve somehow convinces Alice to send packets at address E. 2) DoS. Eve speaks to Bob, then convinces Bob to send packets to Carroll, an unsuspecting third party. Carroll receives a DoS attack that cannot be traced to Eve. Note that the server approach may solve spoofing, but does not solve the DoS attack -- Eve could just as well put Carroll's address in her server entry. Also note that there are many ways to solve spoofing. -- Christian Huitema From owner-multi6@ops.ietf.org Tue Sep 4 16:11:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26453 for ; Tue, 4 Sep 2001 16:11:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eMYN-000NkA-00 for multi6-data@psg.com; Tue, 04 Sep 2001 13:12:11 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15eMYM-000Nk4-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 13:12:10 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 462FA8266E; Tue, 4 Sep 2001 16:12:07 -0400 (EDT) Message-Id: <5.1.0.14.2.20010904160402.00a37470@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 16:06:16 -0400 To: "Christian Huitema" From: RJ Atkinson Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 15:45 04/09/01, Christian Huitema wrote: >There is also a practicality issue. Good point. >Then, there is a performance issue. Last time I checked, about 25% of >DNS queries took more than 3 seconds to complete. In fact, if you look >at http://www.netsizer.com/daily/quality_today.html, you observe that at >least 5% of queries for the addresses of large servers don't complete in >less than 3 seconds, and that 5% of queries for the addresses of small >servers don't complete in less than 6 seconds! I don't believe that >adding more load to the DNS is a good idea, when the infrastructure is >so obviously strained. If DNS is about to collapse, that's a pretty urgent problem to fix, because it is the primary way folks find the peer in the first place these days. >There is an obvious alternative to DNS discovery of peer addresses, >which is, have the peer tell you. One must find the peer somehow before the peer can give you their other addresses. Or are you suggesting that just using IP addresses in host files is user-friendly and scales to the current Internet ? Ran From owner-multi6@ops.ietf.org Tue Sep 4 16:21:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26749 for ; Tue, 4 Sep 2001 16:21:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eMiS-000O1p-00 for multi6-data@psg.com; Tue, 04 Sep 2001 13:22:36 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15eMiR-000O1c-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 13:22:35 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f84KNcF14422; Tue, 4 Sep 2001 22:23:38 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 4 Sep 2001 22:23:38 +0200 (CEST) From: Iljitsch van Beijnum To: Christian Huitema cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: <20010904221321.D5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Christian Huitema wrote: > > Are you saying that if there is a good way to implement multihoming > > that requires a globally distributed hierarchical database system, we > > should create a new one? > Well, you should first prove that we actually need a globally > distributed hierarchical database. I don't think so. The problem is that there is no clear "best" way to do multihoming in IPv6. So router people want the hosts to solve it, layer 4 people want layer 3 to solve it, and so on. Who will be the tiebreaker? Someone people are bound to be unhappy, whatever we end up implementing. > We start with the > assumption that hosts have multiple addresses, but that the > corresponding host only knows one of them. For multi-address multihoming to work, we need to know more than one address the time of session establishment. Preferably before setting up a session, but certainly well before the setup times out. However, traditional multiple A/AAAA records should suffice for this purpose. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Sep 4 16:23:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26795 for ; Tue, 4 Sep 2001 16:23:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eMkL-000O5n-00 for multi6-data@psg.com; Tue, 04 Sep 2001 13:24:33 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15eMkK-000O5d-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 13:24:32 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 4BA768266E; Tue, 4 Sep 2001 16:24:25 -0400 (EDT) Message-Id: <5.1.0.14.2.20010904161704.01de82f0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 16:18:34 -0400 To: Ramakrishna Gummadi From: RJ Atkinson Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Cc: In-Reply-To: References: <5.1.0.14.2.20010904151748.00a9a0d0@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 16:00 04/09/01, Ramakrishna Gummadi wrote: >I don't think that we should create a dependency between routing (even if >it is for multihoming) and DNS that can be hurt by these kinds of >misconfigurations, even if we assume that every internet device is >required (which I think is impossible to do for various reasons, >including non-technical) to be hosted in DNS. We've already got that dependency. Folks depend on www.cnn.com resolving to the right load-balancer's IP address so that routing goes to the right place. If DNS is really so broken that it is a crisis right now, then we should defer multi6 work to fix that first, IMHO. Ran From owner-multi6@ops.ietf.org Tue Sep 4 16:25:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26852 for ; Tue, 4 Sep 2001 16:25:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eMmL-000OA5-00 for multi6-data@psg.com; Tue, 04 Sep 2001 13:26:37 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15eMmK-000O9r-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 13:26:36 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id NAA11996; Tue, 4 Sep 2001 13:26:35 -0700 (PDT) Date: Tue, 4 Sep 2001 13:26:34 -0700 (PDT) From: Ramakrishna Gummadi To: Christian Huitema cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk I first started writing a solution based on hip (host identity payload) because hip addresses spoofing, hijacking, and DoS issues cleanly, especially for "anonymous" connections, with a minimal external overhead. But the main problem with this approach (as with any other host-based approach) is that multicast becomes painfully difficult, both in terms of performance and security. This is why I went back to a router-only solution that preserves today's semantics for multihoming (draft available at www.cs.berkeley.edu/~ramki/draft-ramki-multi6-nlmp-00.txt). I am going to resurrect the host-only draft to see folks' response. thanks, ramki On Tue, 4 Sep 2001, Christian Huitema wrote: > > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > > > > On Tue, 4 Sep 2001, Christian Huitema wrote: > > > > > There is no dependency between connectivity and the DNS, and there > > > should not be. A multi-homing solution that depends on the DNS is a > > non > > > starter. > > > > Are you saying that if there is a good way to implement multihoming > > that requires a globally distributed hierarchical database system, we > > should create a new one? > > Well, you should first prove that we actually need a globally > distributed hierarchical database. I don't think so. We start with the > assumption that hosts have multiple addresses, but that the > corresponding host only knows one of them. The obvious solution is to > have the peers use the address they know to learn the addresses they > don't. Using a third party as a server is a tortuous way to solve the > problem. There are indeed security issues, and we need to address them. > So far, I see at least two security issues: > > 1) Spoofing. Alice speaks to Bob at address B; Eve somehow convinces > Alice to send packets at address E. > > 2) DoS. Eve speaks to Bob, then convinces Bob to send packets to > Carroll, an unsuspecting third party. Carroll receives a DoS attack that > cannot be traced to Eve. > > Note that the server approach may solve spoofing, but does not solve the > DoS attack -- Eve could just as well put Carroll's address in her server > entry. Also note that there are many ways to solve spoofing. > > -- Christian Huitema > > > From owner-multi6@ops.ietf.org Tue Sep 4 16:25:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26867 for ; Tue, 4 Sep 2001 16:25:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eMmz-000OB7-00 for multi6-data@psg.com; Tue, 04 Sep 2001 13:27:17 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15eMmy-000OB0-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 13:27:17 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 10D5C8266E; Tue, 4 Sep 2001 16:27:15 -0400 (EDT) Message-Id: <5.1.0.14.2.20010904161850.01e323e0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 16:21:24 -0400 To: Iljitsch van Beijnum From: RJ Atkinson Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Cc: In-Reply-To: <20010904214256.T5044-100000@sequoia.muada.com> References: <5.1.0.14.2.20010904115721.00a2e4c0@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 16:01 04/09/01, Iljitsch van Beijnum wrote: >would you agree that it makes economic sense for a Dutch network to >connect to the AMS-IX? I've already agreed that any European network ought to be at AMS-IX, regardless of that network's location, simply because its at a place where lots of long-haul fibres terminate. Where we disagree is the relative utility of connecting at each national/metropolitan exchange. I think most lack a good business case (from an ISP perspective), so we ought not use metro-oriented addressing as the basis for multi6 solutions in the near-term. Ran rja@inet.org From owner-multi6@ops.ietf.org Tue Sep 4 16:47:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27567 for ; Tue, 4 Sep 2001 16:47:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eN79-000OmQ-00 for multi6-data@psg.com; Tue, 04 Sep 2001 13:48:07 -0700 Received: from [216.243.33.138] (helo=roxanne.org) by psg.com with esmtp (Exim 3.33 #1) id 15eN78-000OmH-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 13:48:06 -0700 Received: (from eric@localhost) by roxanne.org (8.11.0/8.11.0) id f84Klgf27532; Tue, 4 Sep 2001 16:47:42 -0400 Date: Tue, 4 Sep 2001 16:47:42 -0400 From: Eric Gauthier To: RJ Atkinson Cc: Ramakrishna Gummadi , multi6@ops.ietf.org Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) Message-ID: <20010904164742.A27281@roxanne.org> References: <5.1.0.14.2.20010904151748.00a9a0d0@10.30.15.2> <5.1.0.14.2.20010904161704.01de82f0@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.2.20010904161704.01de82f0@10.30.15.2>; from rja@inet.org on Tue, Sep 04, 2001 at 04:18:34PM -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Folks depend on www.cnn.com resolving to the right > load-balancer's IP address so that routing goes to the right place. > If DNS is really so broken that it is a crisis right now, then > we should defer multi6 work to fix that first, IMHO. I might be a bit confused here, but it seems that people are talking about two different things. First, when a person (layer 8 application) or application wants to do something, they try to attach to that resource. Somehow, those upper layer applications need to ask the lower layers to get a resource (ie - please connect to IP x.x.x.x on port z). This seems to be the DNS side of things where you are determining what that layer 3 address should be. Second, there is a pure layer 3 issue of how do various layer 3 devices build their routing tables. So, is the debate right now : do we want the multihoming functionality to be handled by the upper layer -> layer 3 translation mechanism or do we want it handled within the routing tables themselves (or a conbination of the two). If I've got this right, it seems like this is more of a debate on what direction we should take rather than about a specific technology. Should we focus on the translations like, for example, the way Mail service was implemented by using multiple MX records to handle failover of a service to a different IP. Or, should we handle this solely within layer 3 like, for example, how site multihoming is done using BGP? Am I close on this? Thanks! Eric :) From owner-multi6@ops.ietf.org Tue Sep 4 16:47:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27585 for ; Tue, 4 Sep 2001 16:47:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eN7i-000Oo7-00 for multi6-data@psg.com; Tue, 04 Sep 2001 13:48:42 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15eN7i-000Oo1-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 13:48:42 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id NAA12747; Tue, 4 Sep 2001 13:48:40 -0700 (PDT) Date: Tue, 4 Sep 2001 13:48:39 -0700 (PDT) From: Ramakrishna Gummadi To: RJ Atkinson cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <5.1.0.14.2.20010904161704.01de82f0@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, RJ Atkinson wrote: > At 16:00 04/09/01, Ramakrishna Gummadi wrote: > >I don't think that we should create a dependency between routing (even if > >it is for multihoming) and DNS that can be hurt by these kinds of > >misconfigurations, even if we assume that every internet device is > >required (which I think is impossible to do for various reasons, > >including non-technical) to be hosted in DNS. > > We've already got that dependency. > > Folks depend on www.cnn.com resolving to the right > load-balancer's IP address so that routing goes to the right place. I think it is important to distinguish between performance and correctness; the load-balancer should just "work", it need not (and, sometimes, is not) be "optimum". > If DNS is really so broken that it is a crisis right now, then > we should defer multi6 work to fix that first, IMHO. While all indications are that the quality of DNS today is bad, it "works", so people aren't too concerned about it: http://www.psg.com/~randy/960303.iepg I think it is the job another working group (dnsop) to make sure it does not break (this means that it is a good idea to bounce any DNS-based ideas on the dnsop mailing list). regards, -ramki From owner-multi6@ops.ietf.org Tue Sep 4 16:51:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27666 for ; Tue, 4 Sep 2001 16:51:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eNBV-000OuO-00 for multi6-data@psg.com; Tue, 04 Sep 2001 13:52:37 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15eNBU-000Ou6-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 13:52:36 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id NAA12873; Tue, 4 Sep 2001 13:52:15 -0700 (PDT) Date: Tue, 4 Sep 2001 13:52:15 -0700 (PDT) From: Ramakrishna Gummadi To: Iljitsch van Beijnum cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <20010904221321.D5044-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > For multi-address multihoming to work, we need to know more than one > address the time of session establishment. Preferably before setting up a > session, but certainly well before the setup times out. However, > traditional multiple A/AAAA records should suffice for this purpose. I disagree. It is possible to build a layer 3 solution using multiple addresses that provides high availability semantics to each address, even if that address is not directly reachable. My draft says how. From owner-multi6@ops.ietf.org Tue Sep 4 16:51:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27677 for ; Tue, 4 Sep 2001 16:51:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eNBX-000Ouh-00 for multi6-data@psg.com; Tue, 04 Sep 2001 13:52:39 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15eNBW-000OuM-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 13:52:38 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f84Krbg14514; Tue, 4 Sep 2001 22:53:37 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 4 Sep 2001 22:53:37 +0200 (CEST) From: Iljitsch van Beijnum To: Ramakrishna Gummadi cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: <20010904225128.P5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Ramakrishna Gummadi wrote: > I first started writing a solution based on hip (host identity payload) > because hip addresses spoofing, hijacking, and DoS issues cleanly, > especially for "anonymous" connections, with a minimal external overhead. > But the main problem with this approach (as with any other host-based > approach) is that multicast becomes painfully difficult, both in terms of > performance and security. You've mentioned multicast problems before. Maybe I'm uninformed on the subject, not having done any real multicasting, but I don't see the problem. Isn't multicast addressing and routing pretty much independent from unicast addressing and routing? What are the problem areas? From owner-multi6@ops.ietf.org Tue Sep 4 17:00:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27853 for ; Tue, 4 Sep 2001 17:00:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eNJq-000PAi-00 for multi6-data@psg.com; Tue, 04 Sep 2001 14:01:14 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15eNJp-000PAc-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 14:01:13 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id OAA13176; Tue, 4 Sep 2001 14:01:09 -0700 (PDT) Date: Tue, 4 Sep 2001 14:01:06 -0700 (PDT) From: Ramakrishna Gummadi To: Iljitsch van Beijnum cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <20010904225128.P5044-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > You've mentioned multicast problems before. Maybe I'm uninformed on the > subject, not having done any real multicasting, but I don't see the > problem. > > Isn't multicast addressing and routing pretty much independent from > unicast addressing and routing? What are the problem areas? No, multicast trees are typically (PIM, etc.) built from corresponding underlying unicast routing entries, which means that, for example, in source-specific multicast, a client cannot connect to a multicast tree using a different unicast source address than the one the multihomed multicasting source is using. Another problem is that, due to danger of "ack-implosion", it is typically not possible to generate any path management messages (like what SCTP does), and discovering source failures can take a long time. Finally, multicast security (spoofing, DoS, etc.) is still very immature. regards, ramki From owner-multi6@ops.ietf.org Tue Sep 4 17:01:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27889 for ; Tue, 4 Sep 2001 17:01:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eNL8-000PD2-00 for multi6-data@psg.com; Tue, 04 Sep 2001 14:02:34 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15eNL7-000PCv-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 14:02:33 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 743A98266E; Tue, 4 Sep 2001 17:02:31 -0400 (EDT) Message-Id: <5.1.0.14.2.20010904165459.009ee890@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 16:56:40 -0400 To: Ramakrishna Gummadi From: RJ Atkinson Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Cc: In-Reply-To: References: <5.1.0.14.2.20010904161704.01de82f0@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 16:48 04/09/01, Ramakrishna Gummadi wrote: >While all indications are that the quality of DNS today is bad, it >"works", so people aren't too concerned about it: >http://www.psg.com/~randy/960303.iepg > >I think it is the job another working group (dnsop) to make sure it does >not break (this means that it is a good idea to bounce any DNS-based ideas >on the dnsop mailing list). OK, so we can go back to assuming the DNS works well enough and not use the DNS anxieties as the basis for ruling out DNS as a component of a possible solution. Please note well that I'm not advocating a DNS-only kind of solution. I'm trying to keep this WG from closing doors prematurely on *any* technical approach that might be shown to work... Ran From owner-multi6@ops.ietf.org Tue Sep 4 17:14:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28126 for ; Tue, 4 Sep 2001 17:14:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eNXk-000PfN-00 for multi6-data@psg.com; Tue, 04 Sep 2001 14:15:36 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15eNXj-000PfH-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 14:15:35 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id OAA13654; Tue, 4 Sep 2001 14:15:33 -0700 (PDT) Date: Tue, 4 Sep 2001 14:15:33 -0700 (PDT) From: Ramakrishna Gummadi To: RJ Atkinson cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <5.1.0.14.2.20010904165459.009ee890@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > OK, so we can go back to assuming the DNS works well enough > and not use the DNS anxieties as the basis for ruling out DNS > as a component of a possible solution. As far as it does not require every IPv6 device to have DNS entries. In this regard, I fully agree with Christian that we must be prepared to let those game boxes, IM services, etc. get the benefit of multihoming even if they don't appear in DNS. regards, ramki From owner-multi6@ops.ietf.org Tue Sep 4 17:23:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28381 for ; Tue, 4 Sep 2001 17:23:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eNgH-000Pvj-00 for multi6-data@psg.com; Tue, 04 Sep 2001 14:24:25 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15eNgG-000Pvc-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 14:24:24 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 770448266E; Tue, 4 Sep 2001 17:24:17 -0400 (EDT) Message-Id: <5.1.0.14.2.20010904171444.01dab290@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 17:18:25 -0400 To: Ramakrishna Gummadi From: RJ Atkinson Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Cc: multi6@ops.ietf.org In-Reply-To: References: <5.1.0.14.2.20010904165459.009ee890@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 17:15 04/09/01, you wrote: >As far as it does not require every IPv6 device to have DNS entries. >In this regard, I fully agree with Christian that we must be prepared >to let those game boxes, IM services, etc. get the benefit of >multihoming even if they don't appear in DNS. I wouldn't be bothered if requiring at least one AAAA/A6 record to exist was a precondition to multihoming working. I might even be comfortable with requiring more than one in DNS, if explained as part of a detailed proposal (not sure, but open minded). Clearly you and Christian would be bothered and that has been noted. Even the game boxes or toasters connected via cable modem have DNS records -- the cable network operators and dialup operators and DSL operators normally assign both forward and reverse DNS records to all their users' IP addresses (just to preserve the sanity of the ISP in troubleshooting things, not because of any more complex motive). So it isn't something residential users even need to think about these days. Ran From owner-multi6@ops.ietf.org Tue Sep 4 18:16:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29606 for ; Tue, 4 Sep 2001 18:16:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eOTj-0001Hy-00 for multi6-data@psg.com; Tue, 04 Sep 2001 15:15:31 -0700 Received: from mail1.microsoft.com ([131.107.3.125] helo=inet-vrs-01.redmond.corp.microsoft.com) by psg.com with smtp (Exim 3.33 #1) id 15eOTi-0001Hr-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 15:15:30 -0700 Received: from 157.54.9.108 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Sep 2001 15:15:14 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Sep 2001 15:15:16 -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(5.0.2195.2966); Tue, 4 Sep 2001 15:15:16 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Sep 2001 15:14:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Tue, 4 Sep 2001 15:14:47 -0700 Message-ID: Thread-Topic: Multihoming by IP Layer Address Rewriting (MILAR) Thread-Index: AcE1f0eLZKoGnCglTUiawHa46LQ8HgADKrTQ From: "Christian Huitema" To: "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 04 Sep 2001 22:14:47.0846 (UTC) FILETIME=[024FBC60:01C1358F] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA29606 > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > > On Tue, 4 Sep 2001, Christian Huitema wrote: > > > > Are you saying that if there is a good way to implement > multihoming > > > that requires a globally distributed hierarchical database system, > we > > > should create a new one? > > > Well, you should first prove that we actually need a globally > > distributed hierarchical database. I don't think so. > > The problem is that there is no clear "best" way to do multihoming in > IPv6. So router people want the hosts to solve it, layer 4 people want > layer 3 to solve it, and so on. Who will be the tiebreaker? Someone > people are bound to be unhappy, whatever we end up implementing. Uh, I don't know of any such thing as layer 3 or layer 4 in the TCP-IP model, I would rather speak of transport and Internet. Anyway, I am a bit puzzled by your comment about layered implementations. There is a rhetorical question about whether multi-homing could be entirely hidden by the network so that hosts don't have anything to do, but the truth is that we have multi-homed hosts to manage, which means the question is very much settled. Then, there is the layer issue. In my own small boutique, there is not all that much distance between the implementers of TCP and those of IP, or IPv6; I think that the same is true for most host implementations. It is then more a question of practicality, e.g. using ICMP messages or IPv6 end to end options versus using TCP options and doing it again for UDP. > > > We start with the > > assumption that hosts have multiple addresses, but that the > > corresponding host only knows one of them. > > For multi-address multihoming to work, we need to know more than one > address the time of session establishment. Preferably before setting > up a session, but certainly well before the setup times out. However, > traditional multiple A/AAAA records should suffice for this purpose. Yes, but what the host will do here is select one of a set of DNS provided addresses to send the initial SYN. It certainly does not follow that the host can use all the addresses in the set to balance traffic or reroute the connection: in many cases, the addresses belong to different "boxes." Also, we could just as well use alternatives to DNS for getting the initial address. -- Christian Huitema From owner-multi6@ops.ietf.org Tue Sep 4 18:22:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29745 for ; Tue, 4 Sep 2001 18:22:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eOZW-0001SS-00 for multi6-data@psg.com; Tue, 04 Sep 2001 15:21:30 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15eOZV-0001SK-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 15:21:29 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f84MMSE14733; Wed, 5 Sep 2001 00:22:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 5 Sep 2001 00:22:28 +0200 (CEST) From: Iljitsch van Beijnum To: Eric Gauthier cc: Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <20010904164742.A27281@roxanne.org> Message-ID: <20010904234725.L5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Eric Gauthier wrote: > I might be a bit confused here, but it seems that people are talking > about two different things. Just two? We're making progress. :-) > (ie - please connect to IP x.x.x.x on port z). This seems to be > the DNS side of things where you are determining what that layer > 3 address should be. Second, there is a pure layer 3 issue of how > do various layer 3 devices build their routing tables. I think I'm the one who inadvertently opened this can of worms, so let me explain where it all came from. My proposal is to let layer 3 rewrite destination addresses in some cases, so that both higher layers and other layer 3 entities can go about their business as usual and there is still scalable multihoming. There is one caveat, though: you need to know what the new destination address should be. Obviously, this information can't come from the routing table, since keeping the routing table small is exactly the problem we're trying to solve. Also, receiving alternate addresses from the remote host is problematic if all you have is a primary address that is unreachable. So using the DNS seemed like logical choice. PTR records would get a neighbor, something like AP (alternative prefix). That way, a host can find out the way the address should be rewritten without too much trouble. Earlier I said the regular way of using multiple AAAA records would suffice to enable a host to connect to another host when a path is broken, but this is problematic. A host could do this, since it can decide to break off TCP session establishment if it's getting nowhere and try to start one to another address without seeming to break off the session to the application. But a router would not be able to do that on behalf of a host without a full NAT implementation, and I think we should avoid introducing that much state in routers. Finding a AP record and rewriting the destination addresses for all packets to the original address (prefix) is much cleaner. > If I've got this right, it seems like this is more of a debate on what > direction we should take rather than about a specific technology. Should > we focus on the translations like, for example, the way Mail service was > implemented by using multiple MX records to handle failover of a service > to a different IP. Or, should we handle this solely within layer 3 > like, for example, how site multihoming is done using BGP? Any consensus on BGP changes is a long way off (or has been carefully hidden) so I guess we have to solve the problem, or at least lessen the impact, elsewhere. There are basically three choices: - application - transport - IP Changing applications is next to impossible: there are too many of them. (Unfortunately, the socket API doesn't hide the layer 3 addresses so applications need to be changed for IPv6 as well. We can all see how fast this is happening.) Changing transport protocols is hard: there are many of them and changing them imposes changes on the applications as well and repeating the same steps for each session is somewhat wasteful of resources. And not all transport protocol lend themselves equally well for this. Changing IP processing seems doable, at least compared to the alternatives. So: what do we change in IP? There are several drafts and not-so-drafty proposals. They all have stronger and weaker points, and most of them seem to gravitate towards some kind of address rewriting scheme. Maybe we should come up with some more specific requirements for multiple addresses / address rewriting solutions. Or we can just wait and see who is the first to produce code. :-) Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Sep 4 20:00:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00863 for ; Tue, 4 Sep 2001 20:00:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eQ7j-0004AT-00 for multi6-data@psg.com; Tue, 04 Sep 2001 17:00:55 -0700 Received: from ampere.iie.edu.uy ([164.73.224.40]) by psg.com with esmtp (Exim 3.33 #1) id 15eQ7i-0004AN-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 17:00:54 -0700 Received: from 6b8j40j (r200-40-179-249.adinet.com.uy [200.40.179.249]) (authenticated) by ampere.iie.edu.uy (8.11.0/8.11.0) with ESMTP id f85005L38105; Tue, 4 Sep 2001 21:00:06 -0300 (UYT) From: "marcelo bagnulo" To: "Iljitsch van Beijnum" , "Peter Tattam" Cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Wed, 5 Sep 2001 02:00:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010904131044.Q5044-100000@sequoia.muada.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > > It doesn't tell the other end what addresses you might be coming from though. > > > Good point. But this information could easily be carried in an IP option. > > surprise surprise - that's what I'm proposing :) > But you are proposing this in both directions, which is somewhat more > problematic: you can only send an IP option if you can send period... But > you could try each of the different addresses, of course. If I understand it correctly this could be a good trade-off solution. In a large portion of cases, a DNS query is performed before connection is established, so this could be a place where to include all the addresses of the target host, because no extra query is usually requiered. However if we want to use DNS to obtain source host address set, this would requiere an extra DNS query which may not be desirable, so source address set can be carried in the IP prefix option. In addition, the IP prefixes option could include a flag which indicates whether the source host has a target address host available (it got it from DNS) or not, so that the target host can include or not a IP prefix option in the SYN-ACK packet. This option could be included anyway to override the existent address set. Regards, marcelo From owner-multi6@ops.ietf.org Tue Sep 4 20:07:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00927 for ; Tue, 4 Sep 2001 20:07:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eQEG-0004Mu-00 for multi6-data@psg.com; Tue, 04 Sep 2001 17:07:40 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15eQEE-0004MW-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 17:07:38 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id RAA19181; Tue, 4 Sep 2001 17:07:36 -0700 (PDT) Date: Tue, 4 Sep 2001 17:07:36 -0700 (PDT) From: Ramakrishna Gummadi To: Christian Huitema cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi Christian, > bit puzzled by your comment about layered implementations. There is a > rhetorical question about whether multi-homing could be entirely hidden > by the network so that hosts don't have anything to do, but the truth is > that we have multi-homed hosts to manage, which means the question is > very much settled. As I am saying all along, network (Internet) *can* handle multihoming completely even if only multi-homed hosts, and not sites are to be managed. I submitted a draft to ietf yesterday that says how this can be done, and it is available at: http://www.cs.berkeley.edu/~ramki/draft-ramki-multi6-nlmp-00.txt regards, ramki From owner-multi6@ops.ietf.org Tue Sep 4 20:36:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01239 for ; Tue, 4 Sep 2001 20:36:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eQfE-000591-00 for multi6-data@psg.com; Tue, 04 Sep 2001 17:35:32 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15eQfD-00058v-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 17:35:31 -0700 Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Tue, 4 Sep 2001 17:35:29 -0700 Message-ID: <2B81403386729140A3A899A8B39B046403ADB0@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C135A2.AA2CD000" X-MS-TNEF-Correlator: <2B81403386729140A3A899A8B39B046403ADB0@server2000.arneill-py.sacramento.ca.us> Thread-Topic: Multihoming by IP Layer Address Rewriting (MILAR) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Index: AcE1T32A0PxQVIyISDy/xBBjg+JxVQAJfB9wAAsKM44= content-class: urn:content-classes:message From: "Michel Py" To: "Christian Huitema" , "RJ Atkinson" , "Ramakrishna Gummadi" Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C135A2.AA2CD000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIHRoYXQuIFJvdXRpbmcgc2hvdWxkIG5vdCByZWx5IG9uIEROUyBiZWNhdXNl IEROUyBuZWVkcw0Kcm91dGluZy4NCg0KDQpDaHJpc3RpYW4gSHVpdGVtYSB3cm90ZToNCj4+IFRo ZXJlIGlzIG5vIGRlcGVuZGVuY3kgYmV0d2VlbiBjb25uZWN0aXZpdHkgYW5kIHRoZSBETlMsIGFu ZCB0aGVyZQ0KPj4gc2hvdWxkIG5vdCBiZS4gQSBtdWx0aS1ob21pbmcgc29sdXRpb24gdGhhdCBk ZXBlbmRzIG9uIHRoZSBETlMgaXMgYQ0KPj4gbm9uIHN0YXJ0ZXIuDQoNCg0K ------_=_NextPart_001_01C135A2.AA2CD000 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiAAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD AA4AAADRBwkABAARACMAHQACADgBASCAAwAOAAAA0QcJAAQAEQAjAB4AAgA5AQEJgAEAIQAAAEQw RkEwQjE3RjUxMUQwNDQ4QjAxNDYxRTQyQjhDNDZBABcHAQOQBgB8DQAAOQAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAAGwAAABSAEUAOgAgAE0AdQBsAHQA aQBoAG8AbQBpAG4AZwAgAGIAeQAgAEkAUAAgAEwAYQB5AGUAcgAgAEEAZABkAHIAZQBzAHMAIABS AGUAdwByAGkAdABpAG4AZwAgACgATQBJAEwAQQBSACkAAABAADkAANAsqqI1wQEfAD0AAQAAAAoA AABSAEUAOgAgAAAAAAACAUcAAQAAADQAAABjPXVzO2E9IDtwPWFybmVpbGwtcHk7bD1TRVJWRVIy MDAwLTAxMDkwNTAwMzUyOVotMTMAHwBJAAEAAABsAAAAUgBFADoAIABNAHUAbAB0AGkAaABvAG0A aQBuAGcAIABiAHkAIABJAFAAIABMAGEAeQBlAHIAIABBAGQAZAByAGUAcwBzACAAUgBlAHcAcgBp AHQAaQBuAGcAIAAoAE0ASQBMAEEAUgApAAAAQABOAADc2x92NcEBHwBaAAEAAAAkAAAAQwBoAHIA aQBzAHQAaQBhAG4AIABIAHUAaQB0AGUAbQBhAAAAAgFbAAEAAABNAAAAAAAAAIErH6S+oxAZnW4A 3QEPVAIAAAAAQ2hyaXN0aWFuIEh1aXRlbWEAU01UUABodWl0ZW1hQHdpbmRvd3MubWljcm9zb2Z0 LmNvbQAAAAACAVwAAQAAACMAAABTTVRQOkhVSVRFTUFAV0lORE9XUy5NSUNST1NPRlQuQ09NAAAf AF0AAQAAACQAAABDAGgAcgBpAHMAdABpAGEAbgAgAEgAdQBpAHQAZQBtAGEAAAACAV4AAQAAAE0A AAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABDaHJpc3RpYW4gSHVpdGVtYQBTTVRQAGh1aXRlbWFA d2luZG93cy5taWNyb3NvZnQuY29tAAAAAAIBXwABAAAAIwAAAFNNVFA6SFVJVEVNQUBXSU5ET1dT Lk1JQ1JPU09GVC5DT00AAB8AZgABAAAACgAAAFMATQBUAFAAAAAAAB8AZwABAAAAPAAAAGgAdQBp AHQAZQBtAGEAQAB3AGkAbgBkAG8AdwBzAC4AbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQAAAB8A aAABAAAACgAAAFMATQBUAFAAAAAAAB8AaQABAAAAPAAAAGgAdQBpAHQAZQBtAGEAQAB3AGkAbgBk AG8AdwBzAC4AbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQAAAB8AcAABAAAAZAAAAE0AdQBsAHQA aQBoAG8AbQBpAG4AZwAgAGIAeQAgAEkAUAAgAEwAYQB5AGUAcgAgAEEAZABkAHIAZQBzAHMAIABS AGUAdwByAGkAdABpAG4AZwAgACgATQBJAEwAQQBSACkAAAACAXEAAQAAACAAAAABwTVPfYDQ/FBU jIhIPL/EEGOD4nFVAAl8H3AACwozjh8AcwABAAAAKAAAAG0AdQBsAHQAaQA2AEAAbwBwAHMALgBp AGUAdABmAC4AbwByAGcAAAAfAHQAAQAAAEIAAABSAEoAIABBAHQAawBpAG4AcwBvAG4AOwAgAFIA YQBtAGEAawByAGkAcwBoAG4AYQAgAEcAdQBtAG0AYQBkAGkAAAAAAB8AGgwBAAAAFAAAAE0AaQBj AGgAZQBsACAAUAB5AAAAHwAdDgEAAABkAAAATQB1AGwAdABpAGgAbwBtAGkAbgBnACAAYgB5ACAA SQBQACAATABhAHkAZQByACAAQQBkAGQAcgBlAHMAcwAgAFIAZQB3AHIAaQB0AGkAbgBnACAAKABN AEkATABBAFIAKQAAAAIBCRABAAAAWwMAAFcDAAAmCAAATFpGdabIJwgDAAoAcmNwZzEyNYIyA0No dG1sMQMw/wEDAfcKgAKkA+QHEwKAEAP/AFAEVghVB7IRNQ5RAwECAIRjaArAc2V0MgYA2wbDETUz BEYTxzASPBFD2wjvCfc7GC8OMDURMgxgzmMAUAsJAWQzNhZgC6VkNCAQAipcDrIBkGcvFFAKoxFD HUg0FFA8IQBET0NUWVBFIABIVE1MIFBVQgBMSUMgIi0vL4hXM0Mg4ERURB/0CDMuMiDgRU4iPuce TR3vIyExOB9QIAIibxsjfyXwMxzgJNBFQURfJS0O8SZPKM8kVDYO8DxQTUVUQQewQSvAPUwiRwnw BJBhdAWwItESME9OVCIwVCxQBeFERXgT4W5nZQZSdg8SkS6hAJACICA2LjDgLjQ0MTcvcCJeKi8J JGM3Nx9QVElUTE5FJS4vsAfwRToF0HUZJdBpaANwC4BnIGIAeSBJUCBMYXmxEpFBZGQYMAQRUgfQ BwUQNJA08ShNSUxB1FIpI841H1AvMq8w378lpTPxOJAnryX/PGQ1FmAAPEJPRFkgZGn0cj08gHI7 0DxDACEDMDk+4WRvAOA+4QqxXHH/GBA+4RPgAzA/RRZgO/scUek8/2c2J3FQPxkAAEFXrEkgPKAJ 0SAD8HRBIKtGUCzALgfxdTazczSwYTRwZCBubwVAGDBsUzUwLzFETgXwYgWQYX51FCBIgzp8QsUs kAmAc7cj3CtwPjFSPxsLgGUKgfdBVwNgRwMuPzYKoj8nCnL/P0cKsU16O/sBwDiBREFB7z9C/0QP US9Lr0y/VnVDaE0FEHM0kAORSHU2oGXvAMBGIANgWrA6Vu9X/01cxTv7OBzgJmd0AoA/N44+Xc9e 31/vIFRoBJDPLlAEAEfBPpBlcAnwAQDMbmM1MEjQdHcJ4UmPq1QTBaBuLJBjNJB2NqDfNTAAcEew RlBJMyxnlhgw/1tvXH9dj2EvYj9rz2zfYtqvR2lI0EbAK/BtNHItNLX7ZY9UInMG8EcBLzFGgmRF 7wQgdMNJNGPxYWkPah9rL/9uz2/feX96j2LaR9Blb3QF9wGQACAEkC52v3fPTVxOv/9Pz1DfUe9S /1QPiQ89tSSx/i8+Ujvfip+NITJxO4Ak8wJ9j1AAHwA1EAEAAACgAAAAPAAyAEIAOAAxADQAMAAz ADMAOAA2ADcAMgA5ADEANAAwAEEAMwBBADgAOQA5AEEAOABCADMAOQBCADAANAA2ADQAMAAzAEEA RABCADAAQABzAGUAcgB2AGUAcgAyADAAMAAwAC4AYQByAG4AZQBpAGwAbAAtAHAAeQAuAHMAYQBj AHIAYQBtAGUAbgB0AG8ALgBjAGEALgB1AHMAPgAAAB8ARxABAAAAHgAAAG0AZQBzAHMAYQBnAGUA LwByAGYAYwA4ADIAMgAAAAAACwDyEAEAAAAfAPMQAQAAAHgAAABSAEUAJQAzAEEAIABNAHUAbAB0 AGkAaABvAG0AaQBuAGcAIABiAHkAIABJAFAAIABMAGEAeQBlAHIAIABBAGQAZAByAGUAcwBzACAA UgBlAHcAcgBpAHQAaQBuAGcAIAAoAE0ASQBMAEEAUgApAC4ARQBNAEwAAAALAPYQAAAAAEAABzBg RMWWoTXBAUAACDDQoXSqojXBAQMA3j/p/QAAAwDxPwkEAAAfAPg/AQAAABQAAABNAGkAYwBoAGUA bAAgAFAAeQAAAAIB+T8BAAAAYAAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1BUk5F SUxMLVBZL09VPUZJUlNUIEFETUlOSVNUUkFUSVZFIEdST1VQL0NOPVJFQ0lQSUVOVFMvQ049TUlD SEVMAB8A+j8BAAAAKgAAAFMAeQBzAHQAZQBtACAAQQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8AcgAA AAAAAgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMA GUAAAAAAAwAaQAAAAAADAB1AAAAAAAMAHkAAAAAAHwAwQAEAAAAOAAAATQBJAEMASABFAEwAAAAA AB8AMUABAAAADgAAAE0ASQBDAEgARQBMAAAAAAAfADJAAQAAADwAAABoAHUAaQB0AGUAbQBhAEAA dwBpAG4AZABvAHcAcwAuAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0AAAAfADNAAQAAADwAAABo AHUAaQB0AGUAbQBhAEAAdwBpAG4AZABvAHcAcwAuAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0A AAAfADhAAQAAAA4AAABNAEkAQwBIAEUATAAAAAAAHwA5QAEAAAAEAAAALgAAAAsAKQAAAAAACwAj AAAAAAADAAYQMdoDhwMABxDLAAAAAwAQEAAAAAADABEQAQAAAB4ACBABAAAAZQAAAElBR1JFRVdJ VEhUSEFUUk9VVElOR1NIT1VMRE5PVFJFTFlPTkROU0JFQ0FVU0VETlNORUVEU1JPVVRJTkdDSFJJ U1RJQU5IVUlURU1BV1JPVEU6VEhFUkVJU05PREVQRU5ERU4AAAAAAgF/AAEAAABQAAAAPDJCODE0 MDMzODY3MjkxNDBBM0E4OTlBOEIzOUIwNDY0MDNBREIwQHNlcnZlcjIwMDAuYXJuZWlsbC1weS5z YWNyYW1lbnRvLmNhLnVzPgAb8g== ------_=_NextPart_001_01C135A2.AA2CD000-- From owner-multi6@ops.ietf.org Tue Sep 4 20:38:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01311 for ; Tue, 4 Sep 2001 20:38:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eQjA-0005H3-00 for multi6-data@psg.com; Tue, 04 Sep 2001 17:39:36 -0700 Received: from ampere.iie.edu.uy ([164.73.224.40]) by psg.com with esmtp (Exim 3.33 #1) id 15eQj9-0005Gv-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 17:39:36 -0700 Received: from 6b8j40j (r200-40-74-40.adinet.com.uy [200.40.74.40]) (authenticated) by ampere.iie.edu.uy (8.11.0/8.11.0) with ESMTP id f850cnL43087; Tue, 4 Sep 2001 21:38:50 -0300 (UYT) From: "marcelo bagnulo" To: "Iljitsch van Beijnum" , Cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Wed, 5 Sep 2001 02:39:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010904234725.L5044-100000@sequoia.muada.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So: what do we change in IP? There are several drafts and not-so-drafty > proposals. They all have stronger and weaker points, and most of them seem > to gravitate towards some kind of address rewriting scheme. Perhaps we can try to collect strong points from different proposals :-) IMO Preserving Active TCP sessions on Multi-homed IPv6 Networks (PATS from now on) and LIN6 are both very interesting proposals. However, PATS is not transparent to TCP layer and above what introduces the transport address concept and brings some problems (IPsec, TCP pseudo header calculation and others as mentioned in the draft). This issue is solved in LIN6 making address translation at IP level and making it transparent for TCP, so that for TCP (and IPSec) only one address is used. In the other hand, LIN6 uses a complex mechanism (designed for mobile environement) for mapping different addresses (for defining the address set), while PATS provide a simpler solution (IP prefixes option and perhaps DNS info) to define the address set. Wouldn?t be posible to merge them into one and obtain the best of the two worlds? Regards, marcelo From owner-multi6@ops.ietf.org Tue Sep 4 20:57:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01496 for ; Tue, 4 Sep 2001 20:57:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eR1n-0005t1-00 for multi6-data@psg.com; Tue, 04 Sep 2001 17:58:51 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15eR1n-0005sv-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 17:58:51 -0700 Subject: O/T: Mime Date: Tue, 4 Sep 2001 17:58:49 -0700 Message-ID: <2B81403386729140A3A899A8B39B046403ADB1@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: O/T: Mime content-class: urn:content-classes:message Thread-Index: AcE1pevAmcesgDAIRfOCdk2jtoHRnw== From: "Michel Py" To: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA01496 multi6 folks: Can someone help me with this: I am in the middle of nowhere (literally). When I can get a dialtone, 14400 is good speed. The VPN connection will not stay up so here goes my regular mail client and all I have left is the Web interface to the Exchange server. It sends MIME messages for plain text and some people here can not read them. Any ideas? Thanks Michel. From owner-multi6@ops.ietf.org Tue Sep 4 21:37:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02824 for ; Tue, 4 Sep 2001 21:37:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eRdt-0007D4-00 for multi6-data@psg.com; Tue, 04 Sep 2001 18:38:13 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15eRds-0007Cy-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 18:38:12 -0700 Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Tue, 4 Sep 2001 18:38:11 -0700 Message-ID: <2B81403386729140A3A899A8B39B046403ADB7@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: Multihoming by IP Layer Address Rewriting (MILAR) content-class: urn:content-classes:message Thread-Index: AcE1ir+RjQr8H1rfTQu98UC+2dIKgQAH9Q8b From: "Michel Py" To: "RJ Atkinson" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA02824 IMHO, DNS servers would be prime canditates to be multihomed by a layer3 (OSI, also called the network layer or the Internet layer) solution. Part of the current DNS problems is that lots of them are not multihomed. RJ Atkinson wrote: >> I wouldn't be bothered if requiring at least one AAAA/A6 record >> to exist was a precondition to multihoming working. I might even >> be comfortable with requiring more than one in DNS, if explained >> as part of a detailed proposal (not sure, but open minded). Clearly >> you and Christian would be bothered and that has been noted. From owner-multi6@ops.ietf.org Tue Sep 4 22:05:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03162 for ; Tue, 4 Sep 2001 22:05:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eS5e-00082d-00 for multi6-data@psg.com; Tue, 04 Sep 2001 19:06:54 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15eS5d-00082V-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 19:06:53 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA23941; Wed, 5 Sep 2001 12:06:39 +1000 (EST) Date: Wed, 5 Sep 2001 12:06:39 +1000 (EST) From: Peter Tattam To: marcelo bagnulo cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 5 Sep 2001, marcelo bagnulo wrote: > > > > > > It doesn't tell the other end what addresses you might be coming > from though. > > > > > Good point. But this information could easily be carried in an IP > option. > > > > surprise surprise - that's what I'm proposing :) > > > But you are proposing this in both directions, which is somewhat more > > problematic: you can only send an IP option if you can send period... But > > you could try each of the different addresses, of course. > > If I understand it correctly this could be a good trade-off solution. > > In a large portion of cases, a DNS query is performed before connection is > established, so this could be a place where to include all the addresses of > the target host, because no extra query is usually requiered. > > However if we want to use DNS to obtain source host address set, this would > requiere an extra DNS query which may not be desirable, so source address > set can be carried in the IP prefix option. > > In addition, the IP prefixes option could include a flag which indicates > whether the source host has a target address host available (it got it from > DNS) or not, so that the target host can include or not a IP prefix option > in the SYN-ACK packet. This option could be included anyway to override the > existent address set. > > Regards, marcelo > > > For the case where you only have a single starting address but there exists several alternative addresses and there is no way to find the alternatives (no DNS entries), you can only rely on routing infrastructure to tell you the rest of the addresses if the peer can't tell you. This case would force routers to get involved which I hoped one could avoid. It doesn't have to be a router that tells you this, just some third party service like DNS or a reachability cache or somehing. I agree with the comments mad by Christian about DNS not being the best vehicle for this kind of information. Is it worth pursuing the reachability cache idea? Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Tue Sep 4 22:41:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04477 for ; Tue, 4 Sep 2001 22:41:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eSbU-00097Y-00 for multi6-data@psg.com; Tue, 04 Sep 2001 19:39:48 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15eSbS-00096a-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 19:39:46 -0700 Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Tue, 4 Sep 2001 19:39:41 -0700 Message-ID: <2B81403386729140A3A899A8B39B046403ADB8@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C135B4.037E7E40" X-MS-TNEF-Correlator: <2B81403386729140A3A899A8B39B046403ADB8@server2000.arneill-py.sacramento.ca.us> Thread-Topic: Multihoming by IP Layer Address Rewriting (MILAR) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Index: AcE1IMRyRNR4DT4xQ72W/NC+T2rTmwAiwgFE content-class: urn:content-classes:message From: "Michel Py" To: "Iljitsch van Beijnum" Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C135B4.037E7E40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWxqaXRzY2gsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCg0KDQpJbGppdHNjaCB2YW4g QmVpam51bSB3cm90ZToNCj4+Pj4gVW50aWwgc29tZW9uZSBmaW5kcyBhIG1lY2hhbmlzbSB0aGF0 IGNhbiBkbyBpdC4NCj4+IE9rLCB5b3UncmUgcmlnaHQsIG90aGVyIHdheXMsIHN1Y2ggYXMgb24t ZGVtYW5kIGNyZWF0ZWQgcm91dGVzLCBhcmUNCj4+IHBvc3NpYmxlLCBidXQgSSBkb24ndCBzZWUg aXQgaGFwcGVuaW5nLg0KDQpNZSBuZWl0aGVyLCB0aGF0J3Mgd2h5IEkgZGVzaWduZWQgTUhUUC4N Cg0KDQo+PiBJJ20gbm90IGFzIHBlc3NpbWlzdGljIGFzIHNvbWUgb3RoZXJzOiBJIHRoaW5rIHRo ZSBjdXJyZW50DQptdWx0aWhvbWluZw0KPj4gcHJhY3RpY2VzIGNvdWxkIGNvbnRpbnVlIHRvIHdv cmsgZm9yIHRoZSBmb3Jlc2VlYWJsZSBmdXR1cmUgaWYgQkdQDQo+PiBpbXBsZW1lbnRhdGlvbnMg Y2FuIGJlIG9wdGltaXplZC4NCg0KU28gZG8gSSwgYW5kIHRoaXMgaXMgaG93IEkgY29uc2lkZXIg TUhUUDogYW4gb3B0aW1pemF0aW9uIG9mIHRoZQ0KZXhpc3RpbmcNCm1vZGVsLCBhIHdhaXRpbmcg c29sdXRpb24sIGFuZCBzb21ldGhpbmcgdGhhdCB3b3VsZCBwcm92aWRlIGEgd29ya2luZw0KYmFz ZSBmb3IgdHdvIHRoaW5ncyB0aGF0IGFyZSBsaWtlbHkgdG8gYmUgdXNlZCBhbnl3YXk6DQotIEEg cHJlZml4IHJlc2VydmVkIGZvciBtdWx0aWhvbWVkIGFkZHJlc3Nlcy4NCi0gVGhlIGNvbmNlcHQg b2YgbXVsdGlwbGUgYWRkcmVzc2VzIHBlciBob3N0Lg0KDQoNCj4+IFN0aWxsLCBpZiB3ZSBjYW4g Y3JlYXRlIGEgZ29vZCBob3N0LWJhc2VkIG11bHRpaG9taW5nIHNvbHV0aW9uLCB0aGlzDQp3aWxs DQo+PiBkcmFpbiBhd2F5IG11Y2ggb2YgdGhlIGdyb3d0aCBvZiBjdXJyZW50IG11bHRpaG9taW5n IHByYWN0aWNlcywNCmdpdmluZyB1cw0KPj4gYWxsIG1vcmUgYnJlYXRoaW5nIHJvb20uIEFsc28s IGl0IG1ha2VzIG11bHRpaG9taW5nIHJlYWNoYWJsZSBmb3INCj4+IGV2ZXJ5b25lLiBXaXRoIElQ djYgd2UncmUgaW4gdGhlIHVuaXF1ZSBwb3NpdGlvbiB0aGF0IHRoZQ0KaW1wbGVtZW50YXRpb25z DQo+PiBhcmUgc3RpbGwgdmVyeSBmbHVpZCwgc28gd2Ugc2hvdWxkIHRha2UgYWR2YW50YWdlIG9m IHRoYXQuDQoNClllcywgYnV0IEkgc3RpbGwgaGF2ZSB0byBzZWUgdGhhdCBzb2x1dGlvbi4gQWdh aW4sIE1IVFAgZG9lcyBub3QgcHJldGVuZA0KdG8gYmUgIlRIRSIgbXVsdGlob21pbmcgc29sdXRp b24uDQoNCg0KPj4gSG93ZXZlciwgeW91ciBwcm9wb3NhbCBkZXBlbmRzIG9uIGNoYW5naW5nIHRo ZSBJbnRlcm5ldCBjb3JlIHJvdXRpbmcsDQoNCkkgZG8gbm90IGFncmVlIHdpdGggdGhhdC4gVGhl IGNvcmUgb2YgdGhlIHJvdXRpbmcgd291bGQgc3RpbGwgYmUNCnRoZSBleGlzdGluZywgc3Ryb25n bHkgc3VtbWFyaXplZCBCR1A0KyBERlogdGhhdCB3ZSB3YW50IHRvIGtlZXAuDQpXaGF0IEkgcHJv cG9zZSB0byBjaGFuZ2UgaW4gbm90IEhPVyB0aGUgdHJhZmZpYyBpcyByb3V0ZWQgYnV0IFdIQVQg aXMNCmJlaW5nIHJvdXRlZCAoYmVjYXVzZSBpdCBoYXMgYmVlbiB0cmFuc2xhdGVkKS4NCg0KDQo+ PiBUaGUgbWFpbiBhZHZhbnRhZ2Ugb2YgeW91ciBwcm9wb3NhbCBpcyB0aGF0IHlvdSBzb2x2ZSB0 aGUNCiJhbHRlcm5hdGl2ZQ0KPj4gYWRkcmVzcyBkaXNjb3ZlcnkiIHByb2JsZW0uDQoNCkJ5IHVz aW5nIHRoZSBzYW1lLCBwcm92ZW4gbWVjaGFuaXNtIHRoYXQgd29ya3MgdG9kYXk6IGEgQkdQIHJv dXRpbmcNCnRhYmxlLg0KDQoNCj4+IE5vdGUgdGhhdCBhIG5ldHdvcmsgdGhhdCBpcyBwYXJ0IG9m IHRoZSBERlogZG9lcyBub3QgaGF2ZSAiYW4gSVNQIi4NCg0KQW4gaW50ZXJlc3Rpbmcgc2VtYW50 aWNzIGlzc3VlLiBUbyBtZSwgYW4gSVNQIGlzIHdobyBwcm92aWRlcw0KY29ubmVjdGl2aXR5DQp0 byB0aGUgSW50ZXJuZXQuIEluIHRoZSBVUywgaXQgaXMgZmFpcmx5IGNvbW1vbiB0byBidXkgYSBE UzMgb3IgYmlnZ2VyDQpwaXBlIHdpdGggZnVsbCBCR1AgZmVlZCBmcm9tIG9uZSBvciBtb3JlIElT UChzKSAodGhhdCB3b3VsZCBiZSBmb3INCmNvbXBhbmllcw0KdGhhdCBoYXZlIGFuIEFTTiBhbmQg YSBDSURSIGJsb2NrKS4NCg0KPj4geW91IHBheSBhbiBJU1AgdG8gcm91dGUgdHJhZmZpYyB0byBh bGwgZGVzdGluYXRpb25zIGNvbm5lY3RlZCB0byB0aGUNCk5ldA0KDQpJIGRvbid0IHRoaW5rIHNv LiBJIHBheSBteSBJU1AgdG8gcHJvdmlkZSBtZSBhIGNvbm5lY3Rpb24gdG8gdGhlDQpiYWNrYm9u ZQ0Kd2l0aG91dCB0aGUgaGFzc2xlIG9mIGdldHRpbmcgaW50byBhIGNvbG8gd2hlcmUgSSBkbyBu b3Qgd2FudCB0byBtb3ZlDQphbmQNCndpdGhvdXQgdGhlIGhhc3NsZSBvZiBiZWluZyBwYXJ0IG9m IGFuIGV4Y2hhbmdlIHdoaWNoIGlzIG5vdCBteSBjb3JlDQpidXNpbmVzcy4NCg0KDQo+PiBpbiBv dGhlciB3b3JkczogeW91IHBheSBmb3IgYSBkZWZhdWx0Lg0KTm8sIEknbSBnZXR0aW5nIGEgZnVs bCBCR1AgZmVlZC4NCg0KDQo+PiBJbiB0aGUgZGVmYXVsdC1mcmVlIHpvbmUgdGhlcmUgYXJlIG5v IGRlZmF1bHRzDQoNCkxldCdzIHNheSB0aGVyZSBTSE9VTEQgYmUgbm8gZGVmYXVsdHMsIHJlbGF0 ZWQgdG8gdGhlIGZhY3QgdGhhdA0KMTAuMC4wLjAvOCBTSE9VTEQgTk9UIGJlZW4gYWR2ZXJ0aXNl ZCBpbiB0aGUgREZaIGVpdGhlci4uLi4NCg0KDQo+PiAoYnV0IHRoZSByZXZlcnNlIGlzIG5vdCBh bHdheXMgdHJ1ZTogYSBuZXR3b3JrIHJ1bm5pbmcgd2l0aG91dCBhDQo+PiBkZWZhdWx0IGlzIG5v dCBuZWNlc3NhcmlseSBwYXJ0IG9mIHRoZSBERlopDQoNCkFncmVlLiBBIG5ldHdvcmsgaXMgcGFy dCBvZiB0aGUgREZaIGJlY2F1c2UgaXQgaGFzIGl0cyBvd24gYmxvY2ssIHRoZQ0Kc2FtZQ0KYW5p bWFsIHRoYXQgY2xvZ3MgdGhlIERGWidzIHJvdXRpbmcgdGFibGUuDQoNCg0KPj4gU28gdXNpbmcg dGhlIEROUyBzZWVtZWQgbGlrZSBsb2dpY2FsIGNob2ljZS4NCg0KVGhlcmUgYXJlIHdheSB0b28g bWFueSBwZW9wbGUgdGhhdCBjb25zaWRlciBhIEROUy1iYXNlZCBzb2x1dGlvbiBhbg0KYWJzb2x1 dGUNCm5vLW5vIHRvIGF0dGVtcHQgYW55IEROUyBzb2x1dGlvbiwgSU1ITy4NCg0KDQo+PiBBbnkg Y29uc2Vuc3VzIG9uIEJHUCBjaGFuZ2VzIGlzIGEgbG9uZyB3YXkgb2ZmDQoNCkRlZmluaXRlbHku IEkgZ3Vlc3MgSSBoYXZlIG5vdCBtYWRlIG15c2VsZiBjbGVhciBhYm91dCB0aGUgcmVsYXRpb24N CmJldHdlZW4NCk1IVFAgYW5kIEJHUC4gV2hhdCBzaG91bGQgSSBjaGFuZ2UgaW4gNi4yLjkgb2YN Cmh0dHA6Ly9hcm5laWxsLXB5LnNhY3JhbWVudG8uY2EudXMvZHJhZnQtcHktbXVsdGk2LW1odHAt MDEudHh0ID8NCg0KDQo+PiBNYXliZSB3ZSBzaG91bGQgY29tZSB1cCB3aXRoIHNvbWUgbW9yZSBz cGVjaWZpYyByZXF1aXJlbWVudHMgZm9yDQptdWx0aXBsZQ0KPj4gYWRkcmVzc2VzIC8gYWRkcmVz cyByZXdyaXRpbmcgc29sdXRpb25zLiBPciB3ZSBjYW4ganVzdCB3YWl0IGFuZCBzZWUNCndobw0K Pj4gaXMgdGhlIGZpcnN0IHRvIHByb2R1Y2UgY29kZS4gIDotKQ0KDQpUaGlzIG1pZ2h0IG5vIGJl IHRoZSBmYXN0ZXN0IGNvdXJzZSBvZiBhY3Rpb24uIFdoYXQgaWYgdGhlIHBlb3BsZSB0aGF0DQp3 cml0ZQ0KdGhlIGNvZGUgYXJlIHdhaXRpbmcgZm9yIHVzIHRvIGRlY2lkZSBzb21ldGhpbmcgOy0p DQoNCk1pY2hlbA0KDQoNCg== ------_=_NextPart_001_01C135B4.037E7E40 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IisCAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD AA4AAADRBwkABAATACcAKQACAEoBASCAAwAOAAAA0QcJAAQAEwAnACoAAgBLAQEJgAEAIQAAADQ3 RTJGRTlBOUJENzgzNEI4RDM4OEREODUzQzM2ODgwAFEHAQOQBgC4GQAAOQAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAAGwAAABSAEUAOgAgAE0AdQBsAHQA aQBoAG8AbQBpAG4AZwAgAGIAeQAgAEkAUAAgAEwAYQB5AGUAcgAgAEEAZABkAHIAZQBzAHMAIABS AGUAdwByAGkAdABpAG4AZwAgACgATQBJAEwAQQBSACkAAABAADkAQH5+A7Q1wQEfAD0AAQAAAAoA AABSAEUAOgAgAAAAAAACAUcAAQAAADQAAABjPXVzO2E9IDtwPWFybmVpbGwtcHk7bD1TRVJWRVIy MDAwLTAxMDkwNTAyMzk0MVotMTgAHwBJAAEAAABsAAAAUgBFADoAIABNAHUAbAB0AGkAaABvAG0A aQBuAGcAIABiAHkAIABJAFAAIABMAGEAeQBlAHIAIABBAGQAZAByAGUAcwBzACAAUgBlAHcAcgBp AHQAaQBuAGcAIAAoAE0ASQBMAEEAUgApAAAAQABOAIB/br8gNcEBHwBaAAEAAAAqAAAASQBsAGoA aQB0AHMAYwBoACAAdgBhAG4AIABCAGUAaQBqAG4AdQBtAAAAAAACAVsAAQAAAEUAAAAAAAAAgSsf pL6jEBmdbgDdAQ9UAgAAAABJbGppdHNjaCB2YW4gQmVpam51bQBTTVRQAGlsaml0c2NoQG11YWRh LmNvbQAAAAACAVwAAQAAABgAAABTTVRQOklMSklUU0NIQE1VQURBLkNPTQAfAF0AAQAAACoAAABJ AGwAagBpAHQAcwBjAGgAIAB2AGEAbgAgAEIAZQBpAGoAbgB1AG0AAAAAAAIBXgABAAAARQAAAAAA AACBKx+kvqMQGZ1uAN0BD1QCAAAAAElsaml0c2NoIHZhbiBCZWlqbnVtAFNNVFAAaWxqaXRzY2hA bXVhZGEuY29tAAAAAAIBXwABAAAAGAAAAFNNVFA6SUxKSVRTQ0hATVVBREEuQ09NAB8AZgABAAAA CgAAAFMATQBUAFAAAAAAAB8AZwABAAAAJgAAAGkAbABqAGkAdABzAGMAaABAAG0AdQBhAGQAYQAu AGMAbwBtAAAAAAAfAGgAAQAAAAoAAABTAE0AVABQAAAAAAAfAGkAAQAAACYAAABpAGwAagBpAHQA cwBjAGgAQABtAHUAYQBkAGEALgBjAG8AbQAAAAAAHwBwAAEAAABkAAAATQB1AGwAdABpAGgAbwBt AGkAbgBnACAAYgB5ACAASQBQACAATABhAHkAZQByACAAQQBkAGQAcgBlAHMAcwAgAFIAZQB3AHIA aQB0AGkAbgBnACAAKABNAEkATABBAFIAKQAAAAIBcQABAAAAGwAAAAHBNSDEckTUeA0+MUO9lvzQ vk9q05sAIsIBRAAfAHMAAQAAACgAAABtAHUAbAB0AGkANgBAAG8AcABzAC4AaQBlAHQAZgAuAG8A cgBnAAAAHwB0AAEAAAAUAAAATQBpAGMAaABlAGwAIABQAHkAAAAfABoMAQAAABQAAABNAGkAYwBo AGUAbAAgAFAAeQAAAB8AHQ4BAAAAZAAAAE0AdQBsAHQAaQBoAG8AbQBpAG4AZwAgAGIAeQAgAEkA UAAgAEwAYQB5AGUAcgAgAEEAZABkAHIAZQBzAHMAIABSAGUAdwByAGkAdABpAG4AZwAgACgATQBJ AEwAQQBSACkAAAACAQkQAQAAADQQAAAwEAAANTUAAExaRnX6st2MAwAKAHJjcGcxMjWCMgNDaHRt bDEDMD8BAwH3CoACpAPjAgBjaMEKwHNldDAgBxMCgP8QAwBQBFYIVQeyEdUOUQMB3RDXMgYABsMR 1TMERhDZbxLrEeMI7wn3OxjPDjA1OxHSDGBjAFALCQFkMzaTEWALpTQgEAIqXA6yvQGQZxTwCqMR 4x3oNBTwADwhRE9DVFlQAEUgSFRNTCBQAFVCTElDICItIC8vVzNDIYBEVCJEIJQzLjIhgEVOnCI+ Hu0ejyPBMTgf8G8goiMPJB8mkDMdgCVwRXxBRCXNDvEm7ylvJPQ2QQ7wPE1FVEEHsEExLGA9IkcJ 8ASQYXRFBbAiEtBPTlQi0FQTLPAF4UV4EPFuZ2U9BlJ2EzEvQQCQAiAgNoAuMC40NDE3MBAnIv4q zyUDNzcf8FRJOFRMRSXOMFAH8EU6ZQXQdSZwaWgDcAuAZwAgYnkgSVAgTMRheRMxQWRkGNAEER5S B9AFEDUwNZEoTUlQTEFSKSRuNR/wL/8zTzF/JkU0kTkwKE8mnz0EAjURYDxCT0RZINBkaXI9PSBy PHA84+cAIQMwP4FkbwDgP4EKsfxccRiwP4EQ8AMwP+URYKc8mxzxPZ9nNigRUD+5YwAAQfdJbGo3 QATwaP4sP9YKoj/HCnI/5wqxSEj/Qm0BwDkhROFCj0OfRK9JWLpULrFrBCACEAXAeQhhmiAFoG0H gAIwcy5G7/9H/0kPSh9LL0w/TU9FmiR82ywQPtFSP7sLgGVS+kZWAy9wA5FCZWlqbnWEbSA3IG90 ZTpY3xdZ71r8PJs4HYAmZ3T7AoA/1z5f72D/Yg9jH2QvZ2U/Zk9nXCBVAjADEXOtA3BlAiAu8GYL gGQEIP5hHZwdgFX0B4AuogQAXQC2dBEABUBjA5FAoCA3QP4uXY9en1+vaG9pf3Hfcu9RahpPayxP sicY0CBdBRBnDrB3YF1AaBMxd7U2MHN3YHMbgEHAYQQgt2w/VhICIC0BAAOBZFAA/xjQLWAJgHfg CGBdUHjxCsD/WwFvP3BPcV90/3YPf6+Av6lqOHBvBBBpAmBld2DOYnwwNeBuoW4nBUARMJ8u8DdA eZ9WAxEAcHAJ8P81gVCfUa9Sv1PPVN9V71b//UWLTS7wLTA3QHiBd2BuIvInBCB3aDXRPzAHkHgA 6y0we3BNIKBQiK+Jv4rP/4vfjO+N/48PWA99D34fmu+fgs+D356Pn59qVkknXQC+bl1AeWKIQIUR NXBzNTDuY3liazJ4VHM04IXQbiDtC4BrbhEu8GMIcBjQAjD/hr9tNDUYm4+cn52voU+iX++sL60/ hDstUGOk4QeRBaB/NRB7cQIhC4AKUG4QbsB3/wWwpoBPgqaiT4EHkAngAaD3hVCnX5izZnwwCHCG cUBA+EJHUKlvqn+rj68vsD//uc+632oaB3ALUHswUFEtYHcvwbIRA5FipYEFMKShev8JgJNPlF+V b5Z/l4+Yn5mv7UWLU27AbrFJfHF7YaZB/wQgymE1UAfghdCykQCQBIH/kvM04AORwKW/w3hQQECm ovO078ayZXikwqlPt/9a3v0EYmx8cXixN0RrMApAv9L/yeRrMqZCNaBuI7NQslKxkPxvdsthbA/G hbNSzy/QP33RT2J5cLQDbhCzUKYzZ9cEIG4jfJEgWtBr0oA10LuzIcBxdREwe3AAcHl4wXddf9j/ Wu0tEXCxgQEQaf541i/Go7RCLzF7cE+CqLb/3bI2lAeQbw/fX+BvTxCmwf8CILHwBTHNEaizv1Hk yKRR/wXA4g+H04UAbvDBT8Jfw2//xH/Fj8afx6+az+XP5t/0P9+9H7uf99/472plU2rx0pE9tqF3 psEDkXuU1gFnb/cEcMqxpNAt2vJ7cKi501n/6v/yAspDA/D9IPTP9d/27//6j/ufBZ8Gr2oaNqAc MdYA/3jB5BFBsc0VGSDK0G4gzQI/pub/mgD/8gKxl3dgZ2n/1cA1kd2QAt8D7wT/CJ8Jr3cTrxS/ ahph/SDSQXfBYq97otSTXTClYC42cGxrMPv9QQ1xYdzgeY+oX3fge7D/LqG0ouPhEO8R/xMPFq8X v/chPyJPahplL0F3gC0wGoD2V5ExNeF2H2D9kHeyCzH1pqJ1iGBxsvEbnw9jhQD/N0Ev0W4jpqK/ PR5/H48gn/8kPyVPL08wXxhbd8Gk0Rkh/yayT3AAcNXQeQGzMTTRHTD/slIpLwIDG0HkwVxh8ZGl gf/NIm5A7I/tn+6v77/wz/Hf+/LvRYtZfFKFlDT03EAmsN+zEoZSbiPTZhqBZwshd2D/kwLJkbIB o/I27w9k1HCIUB5kLI8tn1r83TQiVEj8RSL/j0QzOa86vzvPPN//Pe8+/0AP9A9H/0kPVF8yn+8x H1f/WQ9qZUjK0Caid2P/5ADVkYTxGRCSYYhBa+HM4e9tohBQ1LPV8Elq4KXQ2hC/blEZYkXv4xN8 IR1hLEy//03PTt9P71D/Ug9TH5AqhdL/o+QMcIZhApAMsTlT6IV3wf/NFWI11SU09MBwVO9V/0nN 981fzm15AXR8ENfQ3QF5IB5te0B38MEBtsI0KyD4REZa1NVrsTixsxI4UO9ekOVvb+9W/VfcQoXQ XfQ/cg8B5WsQXzMoI0WiSE/mV6aTdCBhZuHApQDKkYdtgpLRhZJXSEFUyoG/d094X9odkSAaE37j KMBw/8Aw3ZF7L2gTGwHcQMAQwHCXiFB+AstAbP4xZClMr/9jv2TPZd9m72f/aQ9UH4Av/4E/jq9a 71v/kk+TXxiW6JL/dNALMjiaXazKkUOjXaHTUvdDAnH/jFUiGRBgIr/BJrD/j0+QX5FvlQ+WH5/v oP8YW//qJMmQzvCyMCayS0DVkbSh/xpwhx+IL4k/ik+LX4xvjX/9yLpCNYDdkF+GXkDUYF2A39WS hiHUYF8yzvBt1NazcP/cEf6w3iHWAbbRbXebHzf0/x4Bpv+oD6kfqi+rP6xPrV//jn+db55/vL+j L6Q/wF/Bb/0Ylk5FsEOF1hBgUdeCQ5T/ypG6gekzDDJ1skVXQuOcYIdfELN/upJJU1AitR9/ti+3 P7hPuV+6b7t/QQtB/18Qv2BgIUVwbbPbEHTQDWDffmClsHOQdKAnEVRrELAi9/3RyrHHAncdMLBT NdAbb5/QRejR2hAP0RBwdHm9Xz++b0nPX8oagGAADCNVU+sa48cRZgsgcnRxpgB0wBsq0kqxdTWA spBEUzPHDNDq39BUYmlnOPAeb9vaL79tcOnAa7VmbiA1MO2ysmZDcP7AZm2AsVAm8cff4hlTyrEo cymDoLF1/24iStEeQeAf2BUroLERRXA/4d/i73EOQ8FC4/3RQVMOTtWR/sCykENJRFLhQhBsb2Nr hv/L/80P/84fzy/QP9FPvH/DH8Qv+A//+R8YWpoy9XDfcdW0fIF+w/9+B3yBGRLW0W2xLCRggdiD 738B3CXpD/WCTsZQ8B/xLz/yP/NP9F/1b/Z/ai5uJ78rMr9gxqBD8N0R/aNtNYD//iXWhbDBsoHY Zt70AY/g9/kdwGtiJvHq7+v/ggzlIr9tkStDhcGGkDkDOPB0bbP/02H/gWCB77DWMdORath2dv8P jxyjphHu4hFfEm8TfxSP/wUwguTHRskxc3B8tdZAfmD/bADHEUWiDPEYb9gkpYAaP/8bT4INr2Kl kfAPBE8FXwZv/wd/CI8Jn/d/Iw8kHy3v+0///F8xjzKf/PaX0UWwFwGxsv9e0LJw/XbowrKQXoDe QEtxn3c/L48wncWAXYBJJ7FQ/xW2spDlcyE/K8LlxiZPJ1//KG8pfyqPK58sry2/OV86b/9G/zSP NZ9Kn0uv/PbdNTiV9i3mUGuheuaiNvLuYWCx+31QOIZzP29Af0GPQp9Dr9dEv0XPRtpMxlAnpbBe QIsM0FFUU32QVUxE6IL/Uflz8KWAhqMPBt5ADrB140dHn0ivggwxMC5h0y/OOD1/WANb1U5Pf6CG A/+YAaYwbnDUIG5Al9HHxoLw/TbyLmaBUq9Tv1TPVd9W7/9X/1kPRt9fH2Avbm9Nr0wv/3IPcx/9 BYOwHYWlgKYhhBHXIJWZgBfgeZnBctTwsnJ/xkZ5INiAgwIdNmJ/bDJh/27/cA9xH3S/dc9/P4BP /LrfOJUghgDhpZFo8GnegcdN/ilmz2ffaO9p/2sPbB9tL+3Se2dQwQxwQcY3xx/IIP3okGM4wHgC yLLUoV0Ax4D+dx+A76PdwA9PtEawAnx/v32PJOzqkdRA5aCxc2PvsP5nsgHH1FsBsva0z4gPiR// ii+LP4xPjV+Ob27vln9+j9+CL4M/pf+nD/yrU98wr2h4RE5T1BHUMOYhJMBr3+5gmUH/QJixIGBv /0Ca/3+cD50fni+fP6BPoV+ibFQ/UWd4wd8R1UHu8IYxZW9+cBVRmOQAcdbBOFKsQS33ENBlMgxQ bJpR3vHJP3v2vmK545VvpE+lXXhgLVHx9/9yFdDUMHDGAbehrEO59f08MU1j0K4vrz+wT7Ffsm// s3+0j6J/vL+9z8mPqU+qX/fNL84//PZBt6G4kmSQ1OD/ktEfgOXCH8SSkd4g7zDvsP96Yv3BhqDC YMIPwx/EL8U/78ZPx1/Ib8l5RISwNrDlMPVdUHkMcmd5MCYgF0HuM38gw2TADfF44F1QzuCZMGX/ 2qGawB12XUMO0rqvEJN5od9kgcovyz8k7MGwVD7w7vKrPtEMcFeY8nMdYWwBMAcXUB/FNrE2LjIu Od+GkeNv5H/MT8/rPI/w2oMiaHewZj0i0RB0cDg6Ly/XYCTghhBsLXZw3fCVMGP/AA4QFkEu5ZHg LiXQL2T/AVCQ7xBkLW040Wk28NDREHAALTAxLnR4dCLX3Av/MF1QZOHCZufQNrABAAB7SFlQRVJM 8ElOSyDuH+8v8D/xSzx9ffLB59B38BjwXGP4ZjFcPUDrIOu39K/1v3/2z/FZ0QfV+Pm3/srZmznd 2SJB6oDhn9qTP9U/1k//11/Yb9l/2o/bn8lv6Z/qr78LL9A/zr8Ozw/fhDVNOAC/XEHjIOeG0pCs sKuQcHqDL7nRFQEZsFuhc7fQY2nF8uBjXTFxdWl3sPvS/9QAODICLwjy/SO4AQu/DM//Dd8RfxKP HI8dn4PqZMD8kNsmEdPxLyHmXTF3hgA8w/O55iYwIE83IVGQkeA2wP5qq6B6/wjU1MCSQeayrIH/ FVCt0BnPGt8b7x+PIJ8qj38rnzX7mXTy4Hfw4LFcgHD5mjBkdYWwFNHfcDkMLiIKbrwAcC6JXCdh MPmD+Toth08EjwWfBq8Hv48IzwnftZ2QkW1pZy6wv1xiXEFd9PPA0/C4cnV38v+GoV5BwVHnJRaQ k5O32iV//yaDI2EZvyjPKd2TojFytrX/I3QXstMBXcHfcBaA33EVsvuToJpyOzTPNd827zf/OQ+3 Oh87LwrcTa1wd4BsQy//RD++nElfSm9Lf0yPTZ9OrxtZ/5RUNWJQWPBCT0TeWVktWNBbj14RN1jh 5nAUTUxTIH1gQB8ANRABAAAAoAAAADwAMgBCADgAMQA0ADAAMwAzADgANgA3ADIAOQAxADQAMABB ADMAQQA4ADkAOQBBADgAQgAzADkAQgAwADQANgA0ADAAMwBBAEQAQgA4AEAAcwBlAHIAdgBlAHIA MgAwADAAMAAuAGEAcgBuAGUAaQBsAGwALQBwAHkALgBzAGEAYwByAGEAbQBlAG4AdABvAC4AYwBh AC4AdQBzAD4AAAAfAEcQAQAAAB4AAABtAGUAcwBzAGEAZwBlAC8AcgBmAGMAOAAyADIAAAAAAAsA 8hABAAAAHwDzEAEAAAB4AAAAUgBFACUAMwBBACAATQB1AGwAdABpAGgAbwBtAGkAbgBnACAAYgB5 ACAASQBQACAATABhAHkAZQByACAAQQBkAGQAcgBlAHMAcwAgAFIAZQB3AHIAaQB0AGkAbgBnACAA KABNAEkATABBAFIAKQAuAEUATQBMAAAACwD2EAAAAABAAAcw8MV0zKs1wQFAAAgwQL34A7Q1wQED AN4/6f0AAAMA8T8JBAAAHwD4PwEAAAAUAAAATQBpAGMAaABlAGwAIABQAHkAAAACAfk/AQAAAGAA AAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089QVJORUlMTC1QWS9PVT1GSVJTVCBBRE1J TklTVFJBVElWRSBHUk9VUC9DTj1SRUNJUElFTlRTL0NOPU1JQ0hFTAAfAPo/AQAAACoAAABTAHkA cwB0AGUAbQAgAEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAAAAAAAIB+z8BAAAAHgAAAAAAAADc p0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAAAAMAGkAAAAAAAwAdQAAA AAADAB5AAAAAAB8AMEABAAAADgAAAE0ASQBDAEgARQBMAAAAAAAfADFAAQAAAA4AAABNAEkAQwBI AEUATAAAAAAAHwAyQAEAAAAmAAAAaQBsAGoAaQB0AHMAYwBoAEAAbQB1AGEAZABhAC4AYwBvAG0A AAAAAB8AM0ABAAAAJgAAAGkAbABqAGkAdABzAGMAaABAAG0AdQBhAGQAYQAuAGMAbwBtAAAAAAAf ADhAAQAAAA4AAABNAEkAQwBIAEUATAAAAAAAHwA5QAEAAAAEAAAALgAAAAsAKQAAAAAACwAjAAAA AAADAAYQHctGTgMABxD4CgAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAElMSklUU0NILFRI QU5LU0ZPUllPVVJDT01NRU5UU0lMSklUU0NIVkFOQkVJSk5VTVdST1RFOlVOVElMU09NRU9ORUZJ TkRTQU1FQ0hBTklTTVRIQVRDQU5ET0lUT0ssWU9VUkUAAAAAAgF/AAEAAABQAAAAPDJCODE0MDMz ODY3MjkxNDBBM0E4OTlBOEIzOUIwNDY0MDNBREI4QHNlcnZlcjIwMDAuYXJuZWlsbC1weS5zYWNy YW1lbnRvLmNhLnVzPgDkMw== ------_=_NextPart_001_01C135B4.037E7E40-- From owner-multi6@ops.ietf.org Tue Sep 4 23:46:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05342 for ; Tue, 4 Sep 2001 23:46:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eTdl-000B7M-00 for multi6-data@psg.com; Tue, 04 Sep 2001 20:46:13 -0700 Received: from ampere.iie.edu.uy ([164.73.224.40]) by psg.com with esmtp (Exim 3.33 #1) id 15eTdk-000B7G-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 20:46:12 -0700 Received: from 6b8j40j (r200-40-179-111.adinet.com.uy [200.40.179.111]) (authenticated) by ampere.iie.edu.uy (8.11.0/8.11.0) with ESMTP id f853jWL56914; Wed, 5 Sep 2001 00:45:32 -0300 (UYT) From: "marcelo bagnulo" To: "Peter Tattam" Cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Wed, 5 Sep 2001 05:45:45 +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.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > De: Peter Tattam [mailto:peter@jazz-1.trumpet.com.au] > Enviado el: miercoles, 05 de septiembre de 2001 4:07 > On Wed, 5 Sep 2001, marcelo bagnulo wrote: > > > For the case where you only have a single starting address but > there exists > severtal alternative addresses and there is no way to find the > alternatives (no > DNS entries), you can only rely on routing infrastructure to tell > you the rest > of the addresses if the peer can't tell you. This case would Sorry, I think I do not understand, but doesn?t always the host knows which addresses have been asigned to their own interfaces? Perhaps not all of them are reachable but this issue could be addressed with Router Renumbering and Router Advertisement mechanisms, deprecating unreachable addresses. > force routers to > get involved which I hoped one could avoid. > > It doesn't have to be a router that tells you this, just some third party > service like DNS or a reachability cache or somehing. > > I agree with the comments mad by Christian about DNS not being > the best vehicle > for this kind of information. > I am not saying that the DNS is the best option, I am just saying that for almost the same price of the usual AAAA query, the DNS can provide an initial address set, that can be overwritten in case that the other end consider it necesary. > Is it worth pursuing the reachability cache idea? I find it interesting. I think that bragg draft proposed something related, and reachability information was comunicated through redundant information on the routing protocol. A similar mechanism could be used to inform a host about which of their own addresses are reachable from the outside. > > Peter > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > Regards, marcelo From owner-multi6@ops.ietf.org Wed Sep 5 00:09:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05454 for ; Wed, 5 Sep 2001 00:09:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eU18-000Br2-00 for multi6-data@psg.com; Tue, 04 Sep 2001 21:10:22 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15eU16-000Bqr-00 for multi6@ops.ietf.org; Tue, 04 Sep 2001 21:10:21 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id OAA21292; Wed, 5 Sep 2001 14:10:12 +1000 (EST) Date: Wed, 5 Sep 2001 14:10:12 +1000 (EST) From: Peter Tattam To: marcelo bagnulo cc: multi6@ops.ietf.org Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 5 Sep 2001, marcelo bagnulo wrote: > > > > De: Peter Tattam [mailto:peter@jazz-1.trumpet.com.au] > > Enviado el: miercoles, 05 de septiembre de 2001 4:07 > > On Wed, 5 Sep 2001, marcelo bagnulo wrote: > > > > > > For the case where you only have a single starting address but > > there exists > > severtal alternative addresses and there is no way to find the > > alternatives (no > > DNS entries), you can only rely on routing infrastructure to tell > > you the rest > > of the addresses if the peer can't tell you. This case would > > Sorry, I think I do not understand, but doesn?t always the host knows which > addresses have been asigned to their own interfaces? Perhaps not all of them > are reachable but this issue could be addressed with Router Renumbering and > Router Advertisement mechanisms, deprecating unreachable addresses. I'm talking about addresses of the peer. If we have only one address for the peer there's no way to find out it's alternative addresses if we rule out DNS. > > > force routers to > > get involved which I hoped one could avoid. > > > > It doesn't have to be a router that tells you this, just some third party > > service like DNS or a reachability cache or somehing. > > > > I agree with the comments mad by Christian about DNS not being > > the best vehicle > > for this kind of information. > > > > I am not saying that the DNS is the best option, I am just saying that for > almost the same price of the usual AAAA query, the DNS can provide an > initial address set, that can be overwritten in case that the other end > consider it necesary. > > > Is it worth pursuing the reachability cache idea? > > I find it interesting. I think that bragg draft proposed something related, > and reachability information was comunicated through redundant information > on the routing protocol. A similar mechanism could be used to inform a host > about which of their own addresses are reachable from the outside. The information could be considered advisory and would eventually be confirmed either way by the syn handshake. The risks of spoofing do however increase if such a cache we contaminated. This risk would be roughly equivalent to that of bogus DNS entries. We have grown accustomed to some degree of trust level with the DNS. It all boils down to what level of security you are trying to achieve. A level of security based on a DNS lookup of the address could be achievable with such caches. Anything more would require you to enter the IPSec arena to establish authenticity of each end. Not all applications need this level of security though. It's clear that there's not going to be a one size fits all solution. MH solutions that require high availability and security will take lots of resources to authenticate in comparison to quick & dirty schemes that rely on DNS or something similar to seed the MH process. If you can't contact directly any of the addresses you know to be authentic, the authenticity of the connection can't be guaranteed and should be reported as such to higher layers. However once you get connected to an address you know to be valid additional addresses can be immediately exchanged. A man in the middle attack can still take place, but this is no different to a single - single address connection. Only IPSec can prevent that from happening, but not all connections need IPsec. Hijacking could take place but only by a man in the middle controllign traffic both ways. A man in the middle can do plenty of other nasty things so it's probably academic whether a connection could get hijacked in this manner. Peter > Regards, marcelo > > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Wed Sep 5 03:11:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20987 for ; Wed, 5 Sep 2001 03:11:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eWqQ-000FV8-00 for multi6-data@psg.com; Wed, 05 Sep 2001 00:11:30 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15eWqO-000FV1-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 00:11:29 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f857CQk15758; Wed, 5 Sep 2001 09:12:27 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 5 Sep 2001 09:12:26 +0200 (CEST) From: Iljitsch van Beijnum To: Peter Tattam cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: <20010905090318.R5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 5 Sep 2001, Peter Tattam wrote: > For the case where you only have a single starting address but there exists > several alternative addresses and there is no way to find the alternatives (no > DNS entries), you can only rely on routing infrastructure to tell you the rest > of the addresses if the peer can't tell you. This case would force routers to > get involved which I hoped one could avoid. We can't use the routers for this, since this information can't be aggregated so we'd lose the "small DFZ" we're trying to work towards. > It doesn't have to be a router that tells you this, just some third party > service like DNS or a reachability cache or somehing. > I agree with the comments mad by Christian about DNS not being the best vehicle > for this kind of information. > Is it worth pursuing the reachability cache idea? I love the idea of a reachability cache where a group of hosts and routers shares reachability information. However, I don't see how this could be used to find out alternative addresses for a site for which there is not yet any information in the cache. Also, it is much more important to protect the cache against falsified alternative addresses than to falsified (un)reachability information, since the former can lead to data interception and DDoS attacks, and the latter only to a slight performance degradation while the host discovers the cached information is incorrect. The alternative would be some sort of address registration server, but this would have to be both redundant and safe. From owner-multi6@ops.ietf.org Wed Sep 5 03:25:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21088 for ; Wed, 5 Sep 2001 03:25:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eX4c-000Fov-00 for multi6-data@psg.com; Wed, 05 Sep 2001 00:26:10 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15eX4b-000Foo-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 00:26:10 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id RAA06562; Wed, 5 Sep 2001 17:26:03 +1000 (EST) Date: Wed, 5 Sep 2001 17:26:02 +1000 (EST) From: Peter Tattam To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <20010905090318.R5044-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 5 Sep 2001, Iljitsch van Beijnum wrote: > On Wed, 5 Sep 2001, Peter Tattam wrote: > > > For the case where you only have a single starting address but there exists > > several alternative addresses and there is no way to find the alternatives (no > > DNS entries), you can only rely on routing infrastructure to tell you the rest > > of the addresses if the peer can't tell you. This case would force routers to > > get involved which I hoped one could avoid. > > We can't use the routers for this, since this information can't be > aggregated so we'd lose the "small DFZ" we're trying to work towards. > > > It doesn't have to be a router that tells you this, just some third party > > service like DNS or a reachability cache or somehing. > > > I agree with the comments mad by Christian about DNS not being the best vehicle > > for this kind of information. > > > Is it worth pursuing the reachability cache idea? > > I love the idea of a reachability cache where a group of hosts and routers > shares reachability information. However, I don't see how this could be > used to find out alternative addresses for a site for which there is not > yet any information in the cache. Also, it is much more important to > protect the cache against falsified alternative addresses than to > falsified (un)reachability information, since the former can lead to data > interception and DDoS attacks, and the latter only to a slight performance > degradation while the host discovers the cached information is incorrect. > > The alternative would be some sort of address registration server, but > this would have to be both redundant and safe. > > Something else to consider. We are generally trying to work out alternative prefixes for entire sites, not micro managing every single address on the planet. This is assuming of course that the lower 64 bits is the same across all prefixes. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Wed Sep 5 06:06:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22375 for ; Wed, 5 Sep 2001 06:06:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eZVF-000IUG-00 for multi6-data@psg.com; Wed, 05 Sep 2001 03:01:49 -0700 Received: from znsgs0ja.nortelnetworks.com ([47.165.25.40] helo=znsgs0ja.europe.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15eZVE-000ITG-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 03:01:48 -0700 Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f85A1fg20761 for ; Wed, 5 Sep 2001 11:01:41 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Wed, 5 Sep 2001 11:01:16 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Sep 2001 11:01:13 +0100 Message-ID: From: "Nigel Bragg" To: "'marcelo bagnulo'" , Peter Tattam Cc: multi6 Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Wed, 5 Sep 2001 11:01:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C135F1.B13D2750" 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_01C135F1.B13D2750 Content-Type: text/plain Hi, > -----Original Message----- > From: marcelo bagnulo [SMTP:marcelo@it.uc3m.es] > Sent: Wednesday, September 05, 2001 4:46 AM > To: Peter Tattam > Cc: multi6 > Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) > ----------------------- >8 ----------------------- > > Is it worth pursuing the reachability cache idea? > > I find it interesting. I think that bragg draft proposed something > related, > and reachability information was comunicated through redundant information > on the routing protocol. A similar mechanism could be used to inform a > host > about which of their own addresses are reachable from the outside. > It did. Design intent was to use Routing and Host Renumbering mechanisms to allow the Host initiating a communication to select a reachable Source Address. The selection of a reachable Destination Address was left to the normal mechanisms (assuming a DNS lookup, return of multiple AAAA / A6 records, and retry with another address on lack of response). The proposal assumed strict hierarchical addressing; I recall that at about the same time we were informed that we should consider Provider Addressing to be dead within the Service Provider community. So, while this proposal and others have the potential to address multi-homed enterprises, they do not help the problem of route proliferation in a highly meshed internet. Regards, Nigel ------_=_NextPart_001_01C135F1.B13D2750 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Multihoming by IP Layer Address Rewriting (MILAR)

Hi,

    -----Original = Message-----
    From:   = marcelo bagnulo = [SMTP:marcelo@it.uc3m.es]
    Sent:   = Wednesday, September 05, 2001 4:46 = AM
    To:     Peter Tattam
    Cc:     multi6
    Subject:        = RE: Multihoming by IP Layer Address = Rewriting (MILAR)

 ----------------------- >8 -----------------------

    > Is it worth pursuing the = reachability cache idea?

    I find it interesting. I think = that bragg draft proposed something related,
    and reachability information = was comunicated through redundant information
    on the routing protocol. A = similar mechanism  could be used to inform a host
    about which of their own = addresses are reachable from the outside.

It did.  = Design intent was to use Routing and Host Renumbering mechanisms
to allow the = Host initiating a communication to select a reachable Source
Address.  The selection of a reachable Destination Address = was left to
the normal = mechanisms (assuming a DNS lookup, return of multiple AAAA / A6
records, and = retry with another address on lack of response).

The proposal = assumed strict hierarchical addressing;  I recall that at = about
the same time = we were informed that we should consider Provider Addressing
to be dead = within the Service Provider community.  So, while this = proposal
and others = have the potential to address multi-homed enterprises, they do
not help the = problem of route proliferation in a highly meshed internet.

Regards,

     Nigel

------_=_NextPart_001_01C135F1.B13D2750-- From owner-multi6@ops.ietf.org Wed Sep 5 06:46:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23019 for ; Wed, 5 Sep 2001 06:46:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eaCm-000JGL-00 for multi6-data@psg.com; Wed, 05 Sep 2001 03:46:48 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 15eaCl-000JFy-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 03:46:47 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22764; Wed, 5 Sep 2001 06:45:19 -0400 (EDT) Message-Id: <200109051045.GAA22764@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com, multi6@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ramki-multi6-nlmp-00.txt Date: Wed, 05 Sep 2001 06:45:19 -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A proposal for scalable network-level multihoming Author(s) : R. Gummadi Filename : draft-ramki-multi6-nlmp-00.txt Pages : Date : 04-Sep-01 This document proposes two extensions to BGP4+ to provide scalable multihoming in IPv6. The first is a new well-known and mandatory 'TunneL (TL)' BGP path attribute that allows a multihomed enterprise to maintain global connectivity in the presence of network outages within a direct provider Autonomous System (AS) without adding any global forwarding overhead. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ramki-multi6-nlmp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ramki-multi6-nlmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ramki-multi6-nlmp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010904141225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ramki-multi6-nlmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ramki-multi6-nlmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010904141225.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Wed Sep 5 12:53:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10839 for ; Wed, 5 Sep 2001 12:53:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15efvm-000102-00 for multi6-data@psg.com; Wed, 05 Sep 2001 09:53:38 -0700 Received: from web13509.mail.yahoo.com ([216.136.173.13]) by psg.com with smtp (Exim 3.33 #1) id 15efvl-0000zv-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 09:53:37 -0700 Message-ID: <20010905165337.3277.qmail@web13509.mail.yahoo.com> Received: from [63.101.96.1] by web13509.mail.yahoo.com via HTTP; Wed, 05 Sep 2001 09:53:37 PDT Date: Wed, 5 Sep 2001 09:53:37 -0700 (PDT) From: Michel Py Subject: A new spin on multihoming: multihoming classes. To: multi6@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk multi6 folks, I think that one of the problems we are having is that we are trying to design a universal solution for a too broad topic. Let's divide multihoming into two classes: - Entreprise class. - user class. - Entreprise class is for companies that receive a BGP feed from two different TLAs and have been allocated a centrally managed multihomed block of IPv6 addresses. These entreprises run mission-critical web servers with large pipes to the Net and want 99.999% availability and global load sharing among their different connections. The multihoming solution for entreprise class must be contained at the network or internet layer. My personal submission to entreprise class is: http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt - User class is for home/soho setups that dual home both to DSL and cable (example). These users might be given dynamically assigned IPv6 addresses or prefixes and are in potentially very large numbers. These users mailnly use their connections for surfing and eventually run minimal/personal servers over a slow uplink. The potentially very large number of user class multihomed sites and high volatility of IP addresses makes it very difficult to centrally administer. The multihoming solution for user class could be based on transport or higher levels. Survivability and availability are nice to have but second to the ease of a large scale deployment. Any comments? Michel. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Wed Sep 5 14:00:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13060 for ; Wed, 5 Sep 2001 14:00:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15egyk-0002ER-00 for multi6-data@psg.com; Wed, 05 Sep 2001 11:00:46 -0700 Received: from sean.ebone.net ([195.158.227.211]) by psg.com with esmtp (Exim 3.33 #1) id 15egyj-0002EL-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 11:00:45 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 114FA84A; Wed, 5 Sep 2001 20:00:39 +0200 (CEST) To: multi6@ops.ietf.org, py_michel@yahoo.com Subject: Re: A new spin on multihoming: multihoming classes. Message-Id: <20010905180039.114FA84A@sean.ebone.net> Date: Wed, 5 Sep 2001 20:00:39 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk I think we would like to solve the problems for ANY site that is trying to multihome with IPv6, although there may be several different and possibly co-existing solutions available at the end of the day, just as there is with IPv4. Trying to restrict our scope to just some types of sites will lead into quasi-legalistic arguing about what a site is and whether a small server farm or a soho is really a site in the sense of e.g. 2.5.4 of draft-ietf-ipngwg-addr-arch-v3-06.txt. In other words, feel free to propose solutions which are optimized for certain types of sites, as long as such solutions do not exclude (or refuse to interoperate with) either a more general (set of) solution(s) or different specific solutions for different types of multihomed sites. Personally, I prefer more general solutions since assumptions about the traffic profiles and even protocols that any given entity (particularly ones that are not huge aggregators of traffic) tend to be surprisingly short lived. | - Entreprise class is for companies that receive a BGP | feed from two different TLAs and have been allocated a | centrally managed multihomed block of IPv6 addresses. Incidentally, I also (personally) prefer solutions which DO NOT require the use of BGP. Operational complexity aside, lots of sites means lots of ASes, which do not aggregate away even as nicely as the prefixes they originate (and we do not want to juggle private-use ASes). If all sites are to have some sort of site-identifier, these should be directly associated with the topological location part of an address, rather than indirectly as an indication of originator and a reannouncement-loop-prevention device in the rather crusty exterior routing protocol in use today. One method for doing this more directly would be to have the RoutingGoop in an 8+8 like system be an encoding of higher-order routing objects (abstracted collections of sites, which in turn are abstracted collections of links&nodes) into the top 8-or-so bytes of an address. However, as people have been discussing here, this does require either that the hosts be much more aware of their exact topological location(s) or that they be much more agnostic about them than they are with current IPv6 host implementations. Ran Atkinson, for example, has done a little bit of list-making about what would have to change for a host implementation to generally not care about what its own top 8 bytes are, and this includes some obvious things like header & pseudo-header checksumming, and some less obvious things as well. Other folks here have proposed something along the lines of "pushing down" SCTP ideas into the stack, for the benefit of all applications, or alternatively having hosts adapt to addressing changes that the other hosts they communicate with undergo. Few of these proposals are specialized to site types per se, and few of them propose having hosts partcipate directly in the global routing system to the extent of being fully aware of non-local (and not immediately relevant) topology changes nearly as they occur. In my (personal) opinion, these are strengths, although I do agree with you that there are "cheaper" ways of attacking specific site types. Sean. p.s.: thank you for the pointer to your draft; i'm sure that if it makes a convincing case for attacking your enterprise site type specifically, that some way will be found to carry the work forward towards the standards track (and more importantly, real world implementation) From owner-multi6@ops.ietf.org Wed Sep 5 14:29:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14990 for ; Wed, 5 Sep 2001 14:29:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ehOn-0002ln-00 for multi6-data@psg.com; Wed, 05 Sep 2001 11:27:41 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.33 #1) id 15ehOl-0002lh-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 11:27:40 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f85IRXA24896; Wed, 5 Sep 2001 21:27:33 +0300 Date: Wed, 5 Sep 2001 21:27:33 +0300 (EEST) From: Pekka Savola To: Christian Huitema cc: Iljitsch van Beijnum , Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Christian Huitema wrote: > Well, you should first prove that we actually need a globally > distributed hierarchical database. I don't think so. We start with the > assumption that hosts have multiple addresses, but that the > corresponding host only knows one of them. The obvious solution is to > have the peers use the address they know to learn the addresses they > don't. Using a third party as a server is a tortuous way to solve the > problem. There are indeed security issues, and we need to address them. > So far, I see at least two security issues: > > 1) Spoofing. Alice speaks to Bob at address B; Eve somehow convinces > Alice to send packets at address E. > > 2) DoS. Eve speaks to Bob, then convinces Bob to send packets to > Carroll, an unsuspecting third party. Carroll receives a DoS attack that > cannot be traced to Eve. 2) is a very difficult problem to solve at all. As are many DoS problems. Only way I can see this happening is that Bob here would have some security checks in the implementation. At the moment I see a couple of different approaches: - checking the correlation of the last 80 bits of the IPv6 addresses. This would limits the usability pretty much though, and still wouldn't be foolproof. - checking in the DNS/... that the new address "Carroll", _in turn_ also mentions "Eve" as its secondary address; you have to keep the data in some _external_ database, to avoid the DoS. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-multi6@ops.ietf.org Wed Sep 5 14:51:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17199 for ; Wed, 5 Sep 2001 14:51:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ehkq-0003IH-00 for multi6-data@psg.com; Wed, 05 Sep 2001 11:50:28 -0700 Received: from lox.sandelman.ottawa.on.ca ([192.139.46.2]) by psg.com with esmtp (Exim 3.33 #1) id 15ehkp-0003IB-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 11:50:27 -0700 Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id OAA21643 for ; Wed, 5 Sep 2001 14:50:23 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca ([3ffe:1ce1:0:fe50:204:76ff:fe2d:8c]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f85IofG05150 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 5 Sep 2001 14:50:42 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f85IWba27993 for ; Wed, 5 Sep 2001 14:32:37 -0400 (EDT) Message-Id: <200109051832.f85IWba27993@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. In-reply-to: Your message of "Wed, 05 Sep 2001 09:53:37 PDT." <20010905165337.3277.qmail@web13509.mail.yahoo.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 05 Sep 2001 14:32:37 -0400 From: Michael Richardson Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Michel" == Michel Py writes: Michel> Let's divide multihoming into two classes: Michel> - Entreprise class. Michel> - user class. Let's be more precise here: - Ruling lords (aka "servers") - serfs (no, not "surfs") (aka "clients") This is not peer to peer/end-to-end. It totally fails to provide for the very large number of organizations that in the IPv4 world do not do BGP with anyone because the barrier to entry is too high for IPv4. They would like not to be held hostage by the ISPs. Michel> - User class is for home/soho setups that dual home Michel> both to DSL and cable (example). These users might be Michel> given dynamically assigned IPv6 addresses or prefixes Michel> and are in potentially very large numbers. These users These users are right now given two IPv4 addresses (one from each). Typical usage is now to have two web proxies talking ICP to each other, each running on a gateway that has its default route pointing at the appropriate network. NAT for the real network, and screw IPsec, VoIP, and anything else that is really peer-peer. Given a bit of competition on the DSL market, one can usually find at least one static IP, often two if you realize that cable operators just use DHCP for configuration (until very recently). Thus, 2x IPv6 /48s via 6to4 are immediately available to these organizations (including my "soho"). We are not yet at 1 computer per household member, but in middle class families, we are getting close. Add in PDAs and gameboys via household bluetooth or 802.11, and I do not see how the "client/server" scenario you propose makes any sense. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO5ZvxIqHRg3pndX9AQEdRgQA5JT8gRd5jM5n1oAaBzFVNATku/17j0EJ FvhhqGODlgwDasi+pPhhtxwf/xelGmaWwKI8tJFfwpEcrL/beJM7hpqINPv8ZLqE CE6pOjM8vpmUqDrG2tYgmiqix7P/LJRBWqx7X0gsQBlMu30IuN6nBpS+NB0/Hhq6 TiFFqNyMdvE= =b5um -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Sep 5 15:27:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19247 for ; Wed, 5 Sep 2001 15:27:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15eiLJ-00044R-00 for multi6-data@psg.com; Wed, 05 Sep 2001 12:28:09 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15eiLI-00044L-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 12:28:08 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id MAA05730; Wed, 5 Sep 2001 12:28:04 -0700 (PDT) Date: Wed, 5 Sep 2001 12:28:04 -0700 (PDT) From: Ramakrishna Gummadi To: Sean Doran cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <20010905180039.114FA84A@sean.ebone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Sean, > Incidentally, I also (personally) prefer solutions which DO NOT require the > use of BGP. Operational complexity aside, lots of sites means > lots of ASes, which do not aggregate away even as nicely as > the prefixes they originate (and we do not want to juggle private-use ASes). I don't think every site needs an AS number even though we use BGP. For example, in my draft (http://www.ietf.org/internet-drafts/draft-ramki-multi6-nlmp-00.txt), we *don't* need a multihomed site to have an AS number. Only (multihomed) ISPs are required to have an AS number. > If all sites are to have some sort of site-identifier, these > should be directly associated with the topological location > part of an address, rather than indirectly as an indication > of originator and a reannouncement-loop-prevention device in the > rather crusty exterior routing protocol in use today. In my draft, loop-prevention, etc., is detected by bgp routing attributes associated with route withdrawals and not by AS numbers or other site-specific identifiers. thanks, ramki From owner-multi6@ops.ietf.org Wed Sep 5 17:00:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22262 for ; Wed, 5 Sep 2001 17:00:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ejmY-0005pP-00 for multi6-data@psg.com; Wed, 05 Sep 2001 14:00:22 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15ejmX-0005pJ-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 14:00:21 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f85L1Pd16666 for ; Wed, 5 Sep 2001 23:01:25 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 5 Sep 2001 23:01:25 +0200 (CEST) From: Iljitsch van Beijnum To: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <2B81403386729140A3A899A8B39B046403ADB8@server2000.arneill-py.sacramento.ca.us> Message-ID: <20010905223614.M5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 4 Sep 2001, Michel Py wrote: > >> Note that a network that is part of the DFZ does not have "an ISP". > An interesting semantics issue. To me, an ISP is who provides > connectivity to the Internet. Can't argue with you there. Now let's define "default-free zone". I would say: "the subset of routers that do not receive a full routing table from a single peer or a default route". > In the US, it is fairly common to buy a DS3 or bigger > pipe with full BGP feed from one or more ISP(s) (that would be for > companies that have an ASN and a CIDR block). Having an AS number and a PI or even PA block don't make a network part of the DFZ: as long as it pays another network to carry packets to any destination, the network in question may use a default to the other network and if there is a default filtering is possible without hurting connectivity. The problem with the DFZ is that defaults are not possible, so filtering always hurts connectivity. > >> you pay an ISP to route traffic to all destinations connected to the > >> Net > I don't think so. I pay my ISP to provide me a connection to the > backbone "backbone" is a word without meaning in interdomain routing. > without the hassle of getting into a colo Why would your location have anything to do with it? > >> in other words: you pay for a default. > No, I'm getting a full BGP feed. A full feed is pretty much a more verbose default. > >> (but the reverse is not always true: a network running without a > >> default is not necessarily part of the DFZ) > Agree. A network is part of the DFZ because it has its own block, the > same animal that clogs the DFZ's routing table. No, that's my point: that has still nothing to do with it. Having your own block means you are visible in the DFZ, being part of the DFZ means you can't dump packets for which you don't have a route in someone else's lap. In other words: the DFZ is the top of the tree. On all other levels, you route the packet to a known destination or to the higher level. At the top, there is no higher level so all destinations have to be known destinations to be reachable. > >> Any consensus on BGP changes is a long way off > Definitely. I guess I have not made myself clear about the relation > between > MHTP and BGP. What should I change in 6.2.9 of > http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt ? Nameserver problem, can't get at the document right now. Maybe you should multihome... Iljitsch From owner-multi6@ops.ietf.org Wed Sep 5 18:28:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23749 for ; Wed, 5 Sep 2001 18:28:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15el9I-00079a-00 for multi6-data@psg.com; Wed, 05 Sep 2001 15:27:56 -0700 Received: from kahuna.telstra.net ([139.130.204.11]) by psg.com with esmtp (Exim 3.33 #1) id 15el9G-000799-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 15:27:55 -0700 Received: from tecra.telstra.net (gorp.telstra.net [203.50.0.66]) by kahuna.telstra.net (8.11.3/8.11.3) with ESMTP id f85MR8w87522; Thu, 6 Sep 2001 08:27:09 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20010906062345.00acb820@kahuna.telstra.net> X-Sender: gih@139.130.204.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Sep 2001 08:06:33 +1000 To: smd@ebone.net (Sean Doran) From: Geoff Huston Subject: Re: A new spin on multihoming: multihoming classes. Cc: multi6@ops.ietf.org In-Reply-To: <20010905180039.114FA84A@sean.ebone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 9/6/01 04:00 AM, Sean Doran wrote: >I think we would like to solve the problems for ANY site >that is trying to multihome with IPv6, although there may >be several different and possibly co-existing solutions >available at the end of the day, just as there is with IPv4. I'm reminded of the parable in Marshall Rose's "The Open Book" (ok - yes, it was some years back) about the toaster, where the king wants a toaster and the Standard's response goes along the lines of "Ahh, but you are forgetting that toast is but one class of breakfast foods!". To me there is some value in restricting and dividing the problem space, rather than generalizing it to the point where standards-based solutions start to loose traction. There is some merit, in my humble view, of looking at the stub (non-transit) routing domain that is multi-homed, and looking at the interaction between the stub's exterior gateways and the interior hosts to see if a) the exterior gateways can conform to the address hierarchies that are derived from the external connection, and b) these address prefixes can be used by the interior host (in some fashion) so that the stub network and the hosts do not rely on the current (v4) technique of punching small address prefixes into the global routing soup. There is also some value is looking at a discrete problem set where a single host, or a non-routed enterprise LAN is dual homed into two or more provider networks, and the communication with the edge devices of the providers' networks is, perhaps, more restricted. The more general issue of multi-homed networks when you include both transit and stub domains may require somewhat different approaches to solve. Geoff From owner-multi6@ops.ietf.org Wed Sep 5 18:30:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23815 for ; Wed, 5 Sep 2001 18:30:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15elAk-0007AW-00 for multi6-data@psg.com; Wed, 05 Sep 2001 15:29:26 -0700 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.33 #1) id 15elAj-0007AQ-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 15:29:25 -0700 Received: from CLASSIC.viagenie.qc.ca (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f85MTIQ81068; Wed, 5 Sep 2001 18:29:18 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010905133940.02191060@127.0.0.1> X-Sender: blanchet@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Sep 2001 13:41:17 -0400 To: Michel Py , multi6@ops.ietf.org From: Marc Blanchet Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <20010905165337.3277.qmail@web13509.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At/Ŕ 09:53 2001-09-05 -0700, Michel Py you wrote/vous écriviez: >multi6 folks, > >I think that one of the problems we are having is that >we are trying to design a universal solution for a too >broad topic. > >Let's divide multihoming into two classes: >- Entreprise class. >- user class. good classification >- Entreprise class is for companies that receive a BGP >feed from two different TLAs and have been allocated a >centrally managed multihomed block of IPv6 addresses. >These entreprises run mission-critical web servers >with large pipes to the Net and want 99.999% >availability and global load sharing among their >different connections. >The multihoming solution for entreprise class must be >contained at the network or internet layer. My >personal submission to entreprise class is: >http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt > >- User class is for home/soho setups that dual home >both to DSL and cable (example). These users might be >given dynamically assigned IPv6 addresses or prefixes >and are in potentially very large numbers. These users >mailnly use their connections for surfing and >eventually run minimal/personal servers over a slow >uplink. However, I would include in this class the "fiber-to-the home" and wireless 802.11 community networks. Still a user class, but the "slow uplink" might not be right for those users. Marc. >The potentially very large number of user >class multihomed sites and high volatility of IP >addresses makes it very difficult to centrally >administer. >The multihoming solution for user class could be based >on transport or higher levels. Survivability and >availability are nice to have but second to the ease >of a large scale deployment. > >Any comments? >Michel. > > >__________________________________________________ >Do You Yahoo!? >Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger >http://im.yahoo.com From owner-multi6@ops.ietf.org Wed Sep 5 19:11:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24630 for ; Wed, 5 Sep 2001 19:11:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15elp3-0007hn-00 for multi6-data@psg.com; Wed, 05 Sep 2001 16:11:05 -0700 Received: from sean.ebone.net ([195.158.227.211]) by psg.com with esmtp (Exim 3.33 #1) id 15elp2-0007hh-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 16:11:04 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 893DB81D; Thu, 6 Sep 2001 01:11:03 +0200 (CEST) To: gih@telstra.net, smd@ebone.net Subject: Re: A new spin on multihoming: multihoming classes. Cc: multi6@ops.ietf.org Message-Id: <20010905231103.893DB81D@sean.ebone.net> Date: Thu, 6 Sep 2001 01:11:03 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Geoff - | At 9/6/01 04:00 AM, Sean Doran wrote: | >I think we would like to solve the problems for ANY site | | The more general issue of multi-homed networks when you include both | transit and stub domains may require somewhat different approaches to solve. Well, I think you are just agreeing with me, of course. :-) I did specifically say "site" and not network. For clarity, this means we are in apparent agreement, as "site" != [transit] "provider" / "network". Multi6 is chartered to solve site multihoming, not all multihoming. If what is produced solves all multihoming, I don't think anybody would complain. On the other hand, we should not get bogged down into refusing various approaches to site multihoming just because we (maybe) don't know how to make "the stuff in the middle" deal well/properly/adequately/at all (choose one) with "its own" topological complexity. That said, I don't think it is impossible to predict that a given approach to site multihoming will operate with a vast array of possible solutions to THAT problem, and I think most of the options being discussed on the list are pretty open to lots of "weird core stuff". Please yelp if you disagree. Sean. From owner-multi6@ops.ietf.org Wed Sep 5 20:58:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25835 for ; Wed, 5 Sep 2001 20:58:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15enTo-00097R-00 for multi6-data@psg.com; Wed, 05 Sep 2001 17:57:16 -0700 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 15enTn-00097L-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 17:57:15 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 05 Sep 2001 17:56:54 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 54F826D817AA4152ACC71A718EC19CDA for plus 2 more; Wed, 05 Sep 2001 17:56:53 -0700 Reply-To: From: "Tony Hain" To: "Iljitsch van Beijnum" , "Eric Gauthier" Cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) Date: Wed, 5 Sep 2001 17:56:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010904234725.L5044-100000@sequoia.muada.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: EAE87FC6-C6674F40-9FC3AD69-7FCA906E Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA25835 Iljitsch van Beijnum wrote: > My proposal is to let layer 3 rewrite destination addresses > in some cases, > so that both higher layers and other layer 3 entities can go > about their > business as usual and there is still scalable multihoming. Question, how does the receiver know it is supposed to replace the dst, and which of its possible dst addresses to replace it with? In other words, how can it tell the difference between a rewritten packet to address B vs. a second connection from that src that happened to be load-balanced to address B? If it doesn't put back the original layer 3 will know. Tony From owner-multi6@ops.ietf.org Wed Sep 5 21:03:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25906 for ; Wed, 5 Sep 2001 21:03:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15enab-0009Cy-00 for multi6-data@psg.com; Wed, 05 Sep 2001 18:04:17 -0700 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 15enaa-0009Cs-00 for multi6@ops.ietf.org; Wed, 05 Sep 2001 18:04:16 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 05 Sep 2001 18:03:53 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 3716E8F2AFE4464585D122BD69FFE5A8 for plus 2 more; Wed, 05 Sep 2001 18:03:53 -0700 Reply-To: From: "Tony Hain" To: "Geoff Huston" , "Sean Doran" Cc: Subject: RE: A new spin on multihoming: multihoming classes. Date: Wed, 5 Sep 2001 18:03:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20010906062345.00acb820@kahuna.telstra.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 28468506-D4FF42E1-B5AA74ED-118460D9 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA25906 Geoff Huston wrote: > There is also some value is looking at a discrete problem set where a > single host, or a non-routed enterprise LAN is dual homed > into two or more > provider networks, and the communication with the edge devices of the > providers' networks is, perhaps, more restricted. What is the point? Odds are very high that the small site will grow in complexity over the lifetime of the mechanism we define here. If we don't build a mechanism that ignores the size of the multi-homed site, we will simply create an operational problem down the road in transitioning all the sites from one mechanism to another as they grow. Tony From owner-multi6@ops.ietf.org Thu Sep 6 03:14:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16758 for ; Thu, 6 Sep 2001 03:14:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15etKx-000EQp-00 for multi6-data@psg.com; Thu, 06 Sep 2001 00:12:31 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15etKv-000EQe-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 00:12:30 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f867DRX17728; Thu, 6 Sep 2001 09:13:28 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 6 Sep 2001 09:13:27 +0200 (CEST) From: Iljitsch van Beijnum To: Tony Hain cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: Message-ID: <20010906085849.H5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 5 Sep 2001, Tony Hain wrote: > Question, how does the receiver know it is supposed to replace > the dst, and which of its possible dst addresses to replace it > with? In other words, how can it tell the difference between > a rewritten packet to address B vs. a second connection from > that src that happened to be load-balanced to address B? That is a problem. A host could sort through the list of transport layer connections to see if the source address and ports match any of those and see which destination address is expected for that connection. However, a "proxy address rewriting device" would not be able to do this without keeping track of all transport layer connections of all the hosts it's rewriting for, which is something I think should be avoided. So the solution I propose is to have specific alternative addresses for each regular address. The alternative addresses would be known to the rest of the world and to the host as such, and not be used for regular communication. Suppose a host has two interfaces that connect to two different address ranges. It would then have four addresses: A::1 ; real address in address block A A::2 ; alternative address for B::2 B::1 ; alternative address for A::1 B::2 ; real address in address block B If we're going to use the DNS to discover the alternative addresses, this would be the forward zone: host IN AAAA A::1 host IN AAAA B::2 The reversed zone for A: 1 IN PTR host.domain. IN AP B::1 2 IN PTR host.domain. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Thu Sep 6 04:34:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17610 for ; Thu, 6 Sep 2001 04:34:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15euby-000FdX-00 for multi6-data@psg.com; Thu, 06 Sep 2001 01:34:10 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.33 #1) id 15eubw-000FdQ-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 01:34:08 -0700 Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id f868Y7G11154 for ; Thu, 6 Sep 2001 10:34:07 +0200 Received: (from shane@localhost) by x17.ripe.net (8.11.6/8.11.6) id f868Y7M13103 for multi6@ops.ietf.org; Thu, 6 Sep 2001 10:34:07 +0200 Date: Thu, 6 Sep 2001 10:34:07 +0200 From: Shane Kerr To: multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. Message-ID: <20010906103406.B13093@x17.ripe.net> References: <20010905165337.3277.qmail@web13509.mail.yahoo.com> <200109051832.f85IWba27993@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109051832.f85IWba27993@marajade.sandelman.ottawa.on.ca>; from mcr@sandelman.ottawa.on.ca at 2001-09-05 14:32:37 -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk On 2001-09-05 14:32:37 -0400, Michael Richardson wrote: > > >>>>> "Michel" == Michel Py writes: > Michel> Let's divide multihoming into two classes: > Michel> - Entreprise class. > Michel> - user class. > > Let's be more precise here: > - Ruling lords (aka "servers") > - serfs (no, not "surfs") (aka "clients") > > This is not peer to peer/end-to-end. > > It totally fails to provide for the very large number of organizations > that in the IPv4 world do not do BGP with anyone because the barrier > to entry is too high for IPv4. They would like not to be held hostage > by the ISPs. While I'm not sure I agree with the politically-charged nature of this post, I agree that there shouldn't be any difference between "big honkin' server" end-to-end connectivity and "mom's recipe box server". End-to-end is end-to-end, and I think that the multiple-IP solution is the right tactic. However, there is a need for network multihoming, which will probably need to be solved as well. But given that most of the growth of the routing table seems to be end users desiring reliability and speed, I think the network multihoming problem can wait. -- Shane Carpe Diem From owner-multi6@ops.ietf.org Thu Sep 6 05:54:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18690 for ; Thu, 6 Sep 2001 05:54:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15evqD-000Gkn-00 for multi6-data@psg.com; Thu, 06 Sep 2001 02:52:57 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15evqC-000Gkh-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 02:52:56 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f869rsw17872; Thu, 6 Sep 2001 11:53:54 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 6 Sep 2001 11:53:54 +0200 (CEST) From: Iljitsch van Beijnum To: Shane Kerr cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <20010906103406.B13093@x17.ripe.net> Message-ID: <20010906110815.T5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Sep 2001, Shane Kerr wrote: > However, there is a need for network multihoming, which will probably > need to be solved as well. But given that most of the growth of the > routing table seems to be end users desiring reliability and speed, I > think the network multihoming problem can wait. It never hurts to give the subject some thought. Many of the large networks would really like an 8k global routing table in IPv6. That means: no more than 8192 ISPs with a PA block of their own. (I'll be using IPv4 terminology.) I think this is a reasonable number if we can enforce strict requirements on holding PA blocks. Avoiding renumbering can't be a reason for having a PA block any more, even if this requires millions of hosts to renumber when there is some change in connectivity. People will feel they're held hostage by their existing ISP unless renumbering becomes completely painless. I think the tools for the actual renumbering are there, but changing DNS entries for all these hosts might be a problem. Then there are the enterprises that want to multihome at the network level. Obviously, giving those PI space would be impossible. So they would have to announce a /48 out of one ISP's PA block to other ISPs. The other ISPs will allow this, because it brings in cash. Small ISPs will be happy to receive the /48s at exchange points, because that saves them cash. However, we can expect some of the larger ISPs to filter the /48s because they have no incentive for carrying the more specific routes. Still, as long as all of its other ISPs peer with the "primary" ISP (the one the enterprise got its addresses from), the enterprise will be reachable when the link to its primary ISP fails or that ISP's POP fails. Only when the entire primary ISP is wiped off the network, they'll be unreachable from networks that filter the /48s. But in that case, they can still fall back to multi-address / host level multihoming. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Thu Sep 6 06:32:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19152 for ; Thu, 6 Sep 2001 06:32:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ewRX-000HJh-00 for multi6-data@psg.com; Thu, 06 Sep 2001 03:31:31 -0700 Received: from kahuna.telstra.net ([139.130.204.11]) by psg.com with esmtp (Exim 3.33 #1) id 15ewRV-000HJa-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 03:31:30 -0700 Received: from tecra.telstra.net (gorp.telstra.net [203.50.0.66]) by kahuna.telstra.net (8.11.3/8.11.3) with ESMTP id f86AUnw24882; Thu, 6 Sep 2001 20:30:49 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20010906203008.00acba70@139.130.204.11> X-Sender: gih@139.130.204.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Sep 2001 20:30:40 +1000 To: smd@ebone.net (Sean Doran) From: Geoff Huston Subject: Re: A new spin on multihoming: multihoming classes. Cc: multi6@ops.ietf.org In-Reply-To: <20010905231103.893DB81D@sean.ebone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 9/6/01 09:11 AM, Sean Doran wrote: >Geoff - > >| At 9/6/01 04:00 AM, Sean Doran wrote: >| >I think we would like to solve the problems for ANY site >| >| The more general issue of multi-homed networks when you include both >| transit and stub domains may require somewhat different approaches to solve. > >Well, I think you are just agreeing with me, of course. :-) I'll yelp agreement with you! Geoff From owner-multi6@ops.ietf.org Thu Sep 6 06:53:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19786 for ; Thu, 6 Sep 2001 06:53:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ewms-000HcF-00 for multi6-data@psg.com; Thu, 06 Sep 2001 03:53:34 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15ewmq-000Hc7-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 03:53:33 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id UAA28575; Thu, 6 Sep 2001 20:53:21 +1000 (EST) Date: Thu, 6 Sep 2001 20:53:21 +1000 (EST) From: Peter Tattam To: Iljitsch van Beijnum cc: Shane Kerr , multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <20010906110815.T5044-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Sep 2001, Iljitsch van Beijnum wrote: > On Thu, 6 Sep 2001, Shane Kerr wrote: > > > However, there is a need for network multihoming, which will probably > > need to be solved as well. But given that most of the growth of the > > routing table seems to be end users desiring reliability and speed, I > > think the network multihoming problem can wait. > > It never hurts to give the subject some thought. > > Many of the large networks would really like an 8k global routing table > in IPv6. That means: no more than 8192 ISPs with a PA block of their own. > (I'll be using IPv4 terminology.) > > I think this is a reasonable number if we can enforce strict requirements > on holding PA blocks. Avoiding renumbering can't be a reason for having a > PA block any more, even if this requires millions of hosts to renumber > when there is some change in connectivity. People will feel they're held > hostage by their existing ISP unless renumbering becomes completely > painless. I think the tools for the actual renumbering are there, but > changing DNS entries for all these hosts might be a problem. A6 is supposed to deal with this quickly and painlessly. > > Then there are the enterprises that want to multihome at the network > level. Obviously, giving those PI space would be impossible. So they would > have to announce a /48 out of one ISP's PA block to other ISPs. The other > ISPs will allow this, because it brings in cash. Small ISPs will be happy > to receive the /48s at exchange points, because that saves them cash. > However, we can expect some of the larger ISPs to filter the /48s because > they have no incentive for carrying the more specific routes. > > Still, as long as all of its other ISPs peer with the "primary" ISP (the > one the enterprise got its addresses from), the enterprise will be > reachable when the link to its primary ISP fails or that ISP's POP fails. > Only when the entire primary ISP is wiped off the network, they'll be > unreachable from networks that filter the /48s. > > But in that case, they can still fall back to multi-address / host level > multihoming. > > Iljitsch van Beijnum > > > Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Thu Sep 6 10:02:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27754 for ; Thu, 6 Sep 2001 10:02:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ezip-000JmN-00 for multi6-data@psg.com; Thu, 06 Sep 2001 07:01:35 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([194.237.142.116]) by psg.com with esmtp (Exim 3.33 #1) id 15ezio-000JmG-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 07:01:34 -0700 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f86E1MK08003; Thu, 6 Sep 2001 16:01:26 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA11635; Thu, 6 Sep 2001 16:01:22 +0200 Message-ID: <3B978102.4638A4A6@era.ericsson.se> Date: Thu, 06 Sep 2001 15:58:26 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: marcelo bagnulo CC: Iljitsch van Beijnum , peter@jazz-1.trumpet.com.au, multi6@ops.ietf.org Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > > > So: what do we change in IP? There are several drafts and not-so-drafty > > proposals. They all have stronger and weaker points, and most of them seem > > to gravitate towards some kind of address rewriting scheme. > > Perhaps we can try to collect strong points from different proposals :-) > > IMO Preserving Active TCP sessions on Multi-homed IPv6 Networks (PATS from > now on) and LIN6 are both very interesting proposals. > > However, PATS is not transparent to TCP layer and above what introduces the > transport address concept and brings some problems (IPsec, TCP pseudo header > calculation and others as mentioned in the draft). This issue is solved in > LIN6 making address translation at IP level and making it transparent for > TCP, so that for TCP (and IPSec) only one address is used. > > In the other hand, LIN6 uses a complex mechanism (designed for mobile > environement) for mapping different addresses (for defining the address > set), while PATS provide a simpler solution (IP prefixes option and perhaps > DNS info) to define the address set. > > Wouldn?t be posible to merge them into one and obtain the best of the two > worlds? > > Regards, marcelo I would like you to consider Homeless Mobile IPv6 as well. It tries to solve mobility and multihoming in one attempt somewhere around layer 3.5. /Mattias From owner-multi6@ops.ietf.org Thu Sep 6 10:25:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28496 for ; Thu, 6 Sep 2001 10:25:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f06c-000K43-00 for multi6-data@psg.com; Thu, 06 Sep 2001 07:26:10 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15f06c-000K3x-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 07:26:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15f06c-00089z-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 07:26:10 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15ezms-000Jp7-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 07:05:46 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15ezmh-0007Zg-00; Thu, 06 Sep 2001 07:05:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Iljitsch van Beijnum Cc: Subject: Re: A new spin on multihoming: multihoming classes. References: <20010906103406.B13093@x17.ripe.net> <20010906110815.T5044-100000@sequoia.muada.com> Message-Id: Date: Thu, 06 Sep 2001 07:05:35 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Many of the large networks would really like an 8k global routing table > in IPv6. That means: no more than 8192 ISPs with a PA block of their own. really? as it forms the base of your argument, i must ask if there is a basis for this assertion? my impression is that large (and small) providers would like fairly stable routing which converges predictably in reasonable time. if that can be done with ten, 100k, or 5,000,000 routes is not so important. but, as i said, that is merely my impression. randy From owner-multi6@ops.ietf.org Thu Sep 6 10:37:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28935 for ; Thu, 6 Sep 2001 10:37:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f0J0-000KIv-00 for multi6-data@psg.com; Thu, 06 Sep 2001 07:38:58 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15f0Iy-000KIn-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 07:38:57 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id AAA08730; Fri, 7 Sep 2001 00:38:39 +1000 (EST) Date: Fri, 7 Sep 2001 00:38:39 +1000 (EST) From: Peter Tattam To: Mattias Pettersson cc: marcelo bagnulo , Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <3B978102.4638A4A6@era.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > I would like you to consider Homeless Mobile IPv6 Complete with soup kitchen? :) Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Thu Sep 6 11:08:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29835 for ; Thu, 6 Sep 2001 11:08:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f0lh-000KmE-00 for multi6-data@psg.com; Thu, 06 Sep 2001 08:08:37 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15f0lh-000Km7-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 08:08:37 -0700 Received: from mosquito.inet.org (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id 696F38266E; Thu, 6 Sep 2001 11:08:26 -0400 (EDT) Message-Id: <5.1.0.14.2.20010906105948.00a3e510@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Sep 2001 11:02:31 -0400 To: Randy Bush From: RJ Atkinson Subject: Re: A new spin on multihoming: multihoming classes. Cc: Iljitsch van Beijnum , In-Reply-To: References: <20010906103406.B13093@x17.ripe.net> <20010906110815.T5044-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 10:05 06/09/01, Randy Bush wrote: >> Many of the large networks would really like an 8k global routing table >> in IPv6. That means: no more than 8192 ISPs with a PA block of their own. > >really? as it forms the base of your argument, i must ask if there is a >basis for this assertion? I'd be comfortable with more than 8192 provided the routing system still met the criterion Randy outlines below. >my impression is that large (and small) providers would like fairly stable >routing which converges predictably in reasonable time. Yep. >if that can be done with ten, 100k, or 5,000,000 routes is >not so important. but, as i said, that is merely my impression. Some few folk think that somewhere between 100K and 300K prefixes it isn't stable to have "fairly stable routing which converges predictably in reasonable time" when using current BGP and current BGP algorithms. Those folk are credible, but I haven't seen any equations yet myself. From owner-multi6@ops.ietf.org Thu Sep 6 14:07:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04605 for ; Thu, 6 Sep 2001 14:07:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f3Z7-000Mq2-00 for multi6-data@psg.com; Thu, 06 Sep 2001 11:07:49 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15f3Z6-000Mpw-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 11:07:48 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f86I8ns18373; Thu, 6 Sep 2001 20:08:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 6 Sep 2001 20:08:49 +0200 (CEST) From: Iljitsch van Beijnum To: Mattias Pettersson cc: Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <3B978102.4638A4A6@era.ericsson.se> Message-ID: <20010906200346.O5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Sep 2001, Mattias Pettersson wrote: > I would like you to consider Homeless Mobile IPv6 > as well. It tries to solve > mobility and multihoming in one attempt somewhere around layer 3.5. Looks good. A few questions: - what happens when an address suddenly fails and is no longer reachable? - what happens if TCP tries to set up a connection but the address it chooses doesn't respond (and there is another address that works available)? - would it be possible to offload homeless mobile ipv6 processing on some kind of "mobile proxy" so hosts that do not support the protocol can use it anyway? From owner-multi6@ops.ietf.org Thu Sep 6 14:45:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05738 for ; Thu, 6 Sep 2001 14:45:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f4AV-000NLU-00 for multi6-data@psg.com; Thu, 06 Sep 2001 11:46:27 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15f4AU-000NLM-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 11:46:27 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f86IlRT18416; Thu, 6 Sep 2001 20:47:27 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 6 Sep 2001 20:47:27 +0200 (CEST) From: Iljitsch van Beijnum To: Randy Bush cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: Message-ID: <20010906200938.Q5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Sep 2001, Randy Bush wrote: > > Many of the large networks would really like an 8k global routing table > > in IPv6. That means: no more than 8192 ISPs with a PA block of their own. > really? as it forms the base of your argument, i must ask if there is a > basis for this assertion? I've read words to that effect on this list, and I may have read the same thing in a document (draft, RFC, RIR document), but I'm not absolutely sure on the latter. > my impression is that large (and small) providers would like fairly stable > routing which converges predictably in reasonable time. if that can be done > with ten, 100k, or 5,000,000 routes is not so important. but, as i said, > that is merely my impression. What are you saying? That there is no problem? That BGP implementations need to get better and stop muliplying flaps? Or something else? If we want an 8k routing table, we can't give ISPs more than a hand full of PA blocks and we have to make sure only real ISPs get them. Not limiting the number of PA blocks per ISP probably won't hurt much: with the larger blocks they get with IPv6 they won't burn through them as fast as in IPv4. If we relax the "real" ISP rule, there will be some more growth, since many enterprises will become "ISPs" to be able to multihome without problems. But this is pretty expensive, so the growth of the global routing table should still be fairly reasonable. if we allow PI and/or /48s out of PA space in the DFZ without any restrictions, the routing table will grow as we've never seen before, and it is very likely that many of the new networks will have less stable connections than current networks and the new, large routing table will also be less stable. From owner-multi6@ops.ietf.org Thu Sep 6 16:30:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08002 for ; Thu, 6 Sep 2001 16:30:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f5oC-000OZc-00 for multi6-data@psg.com; Thu, 06 Sep 2001 13:31:32 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15f5oB-000OZW-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 13:31:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15f5o8-000ITR-00; Thu, 06 Sep 2001 13:31:28 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Iljitsch van Beijnum Cc: Subject: Re: A new spin on multihoming: multihoming classes. References: <20010906200938.Q5044-100000@sequoia.muada.com> Message-Id: Date: Thu, 06 Sep 2001 13:31:28 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> my impression is that large (and small) providers would like fairly >> stable routing which converges predictably in reasonable time. if that >> can be done with ten, 100k, or 5,000,000 routes is not so important. >> but, as i said, that is merely my impression. > What are you saying? That there is no problem? i don't see how my words could be interpreted that way. > That BGP implementations need to get better and stop muliplying flaps? if indeed bgp does that, and it is detrimental to stability, convergence, etc., then i would think that fixing this would be one (possibly small) tactical action to progress toward the goals i thought i was outlining. > If we want an 8k routing table maybe i need to be more explicit. it is not clear to me that this is a useful criterion. but, to indulge in your tactical view > if we allow PI and/or /48s out of PA space in the DFZ without any > restrictions i am not aware of this being seriously proposed. the discussions i am hearing imply /[23..36] in the inter-provider dfz. /48s are for sites, and i for one, am not inclined to recommend listening to /48s from peers. randy From owner-multi6@ops.ietf.org Thu Sep 6 16:44:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08614 for ; Thu, 6 Sep 2001 16:44:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f627-000Ols-00 for multi6-data@psg.com; Thu, 06 Sep 2001 13:45:55 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.33 #1) id 15f626-000Oll-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 13:45:54 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id QAA27327; Thu, 6 Sep 2001 16:45:52 -0400 Date: Thu, 6 Sep 2001 16:45:52 -0400 From: "J. Noel Chiappa" Message-Id: <200109062045.QAA27327@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: RJ Atkinson >> my impression is that large (and small) providers would like fairly >> stable routing which converges predictably in reasonable time. if that >> can be done with ten, 100k, or 5,000,000 routes is not so important. As has been discussed considerably, the likelihood of getting the predicate ("converges predictably in reasonable time") gets smaller as the number gets larger. > Some few folk think that somewhere between 100K and 300K prefixes it > isn't stable .. when using current BGP and current BGP algorithms. > ... I haven't seen any equations yet myself. I doubt you will; the problem is too complex to analyze in closed form (it will vary depending on the exact topology), and it's much easier to either simply gather empirical data, or (for the really ambitious) do simulations. Noel From owner-multi6@ops.ietf.org Thu Sep 6 17:04:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09062 for ; Thu, 6 Sep 2001 17:04:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f6LQ-000P2z-00 for multi6-data@psg.com; Thu, 06 Sep 2001 14:05:52 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15f6LP-000P2t-00; Thu, 06 Sep 2001 14:05:52 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f86L6tV18558; Thu, 6 Sep 2001 23:06:55 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 6 Sep 2001 23:06:55 +0200 (CEST) From: Iljitsch van Beijnum To: Randy Bush cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: Message-ID: <20010906225509.B5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Sep 2001, Randy Bush wrote: > > That BGP implementations need to get better and stop muliplying flaps? > if indeed bgp does that, and it is detrimental to stability, convergence, > etc., then i would think that fixing this would be one (possibly small) > tactical action to progress toward the goals i thought i was outlining. Have a look at RIPE document 210, section 3.1: http://www.ripe.net/ripe/docs/ripe-210.html > > If we want an 8k routing table > maybe i need to be more explicit. it is not clear to me that this is a > useful criterion. Hence the "if". Just looking at the implications. > > if we allow PI and/or /48s out of PA space in the DFZ without any > > restrictions > i am not aware of this being seriously proposed. the discussions i am > hearing imply /[23..36] in the inter-provider dfz. /48s are for sites, > and i for one, am not inclined to recommend listening to /48s from peers. I think the large networks won't (although they will announce them to peers if customers pay them for that), but I think the small networks will listen to them at exchange points. It's cheaper for them to buy some extra memory for their router and route traffic to as many /48s as possible over the exchange rather than to the networks the /48s belong to, since that connection will very likely be transit and cost them money. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Thu Sep 6 17:47:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09714 for ; Thu, 6 Sep 2001 17:47:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f70l-000Pfn-00 for multi6-data@psg.com; Thu, 06 Sep 2001 14:48:35 -0700 Received: from web13501.mail.yahoo.com ([216.136.175.80]) by psg.com with smtp (Exim 3.33 #1) id 15f70k-000Pfh-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 14:48:34 -0700 Message-ID: <20010906214830.5508.qmail@web13501.mail.yahoo.com> Received: from [63.101.96.1] by web13501.mail.yahoo.com via HTTP; Thu, 06 Sep 2001 14:48:30 PDT Date: Thu, 6 Sep 2001 14:48:30 -0700 (PDT) From: Michel Py Subject: Re: A new spin on multihoming: multihoming classes. To: Michael Richardson , multi6@ops.ietf.org In-Reply-To: <200109051832.f85IWba27993@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Michael Richardson wrote: > Let's be more precise here: > - Ruling lords (aka "servers") > - serfs (no, not "surfs") (aka "clients") First, serfs are not limited to be clients, second I don't have a problem with being a serf at home. I run a personal web site out of a mighty Pentium 133 server and a residential Pacific Bell aDSL (128kbps upstream). If I can multihome it for $30 a month more, I will give it a thought. And yes, I am also a ruling lord at the office, we have multiple OC48s, a robot to change backup tapes, a multi- terabyte SAN array, and a 24/7 staff and NOC. > It totally fails to provide for the very large > number of organizations that in the IPv4 world do > not do BGP with anyone because the barrier to entry > is too high for IPv4. They would like not to be held > hostage by the ISPs. I don't agree with that, at least not in the US. If you can't afford a BGP feed is because you don't really need it. Yes, it would be nice to have my home network connected with two DS3s to two ISPs, I could actually configure it myself, I just don't make enough money to justify it. A company that connects to the Net with a T1 does not need BGP > We are not yet at 1 computer per household member, I actually have 7 IP connected computers in my two- person household not to mention those that are too old to be connected with IP. > Add in PDAs and gameboys via household bluetooth > or 802.11, and I do not see how the "client/server" > scenario you propose makes any sense. I do not see where the client/server part is in what I propose, could you devellop that part? Michel. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Thu Sep 6 18:29:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10350 for ; Thu, 6 Sep 2001 18:29:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f7d4-0000Gr-00 for multi6-data@psg.com; Thu, 06 Sep 2001 15:28:10 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15f7d4-0000Gl-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 15:28:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15f7d4-0008mW-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 15:28:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: from web13501.mail.yahoo.com ([216.136.175.80]) by psg.com with smtp (Exim 3.33 #1) id 15f7bX-0000FK-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 15:26:35 -0700 Message-ID: <20010906222635.8932.qmail@web13501.mail.yahoo.com> Received: from [63.101.96.1] by web13501.mail.yahoo.com via HTTP; Thu, 06 Sep 2001 15:26:35 PDT Date: Thu, 6 Sep 2001 15:26:35 -0700 (PDT) From: Michel Py Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) To: Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: <20010905223614.M5044-100000@sequoia.muada.com> Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum >>>> An interesting semantics issue. To me, an ISP is who provides >>>> connectivity to the Internet. >> Can't argue with you there. Now let's define "default-free zone". I would >> say: "the subset of routers that do not receive a full routing table from >> a single peer or a default route". Or: "The subset of routers that do not use a default route, and peer with two or more other ASNs." >>>> In the US, it is fairly common to buy a DS3 or bigger >>>> pipe with full BGP feed from one or more ISP(s) (that would be for >>>> companies that have an ASN and a CIDR block). >> Having an AS number and a PI or even PA block don't make a network part of >> the DFZ: as long as it pays another network to carry packets to any >> destination, the network in question may use a default to the other >> network and if there is a default filtering is possible without hurting >> connectivity. The problem with the DFZ is that defaults are not possible, >> so filtering always hurts connectivity. I think I see your point here. My ISPs are major ones, I have the assurance that the routers that I peer with are part of the DFZ and do not use a default route. >> No, that's my point: that has still nothing to do with it. Having your own >> block means you are visible in the DFZ, being part of the DFZ means you >> can't dump packets for which you don't have a route in someone else's lap. >> In other words: the DFZ is the top of the tree. On all other levels, you >> route the packet to a known destination or to the higher level. At the >> top, there is no higher level so all destinations have to be known >> destinations to be reachable. If I have two BGP feeds from two major ISPs, why should I use a default route? With a 200,000 route feed, if the route is unreachable to me it is probably unreachable to my ISPs as well and I'd rather dump the traffic into the bit bucket at my site instead of wasting bandwidth on the link. >>>> Definitely. I guess I have not made myself clear about the relation >>>> between MHTP and BGP. What should I change in 6.2.9 of >>>> http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt >> Nameserver problem, can't get at the document right now. Maybe you should >> multihome... This is my home^H^H^H^H serf setup. I use "The Public DNS" for name resolution, they have two different name servers connected to two different networks, and I regularly have DNS failures. Besides the fact that I got what I paid for (none), that makes my point about multihoming DNS servers I guess. Michel. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Thu Sep 6 18:36:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10463 for ; Thu, 6 Sep 2001 18:36:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f7jT-0000M0-00 for multi6-data@psg.com; Thu, 06 Sep 2001 15:34:47 -0700 Received: from web13508.mail.yahoo.com ([216.136.175.87]) by psg.com with smtp (Exim 3.33 #1) id 15f7jS-0000Lt-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 15:34:46 -0700 Message-ID: <20010906223446.19670.qmail@web13508.mail.yahoo.com> Received: from [63.101.96.1] by web13508.mail.yahoo.com via HTTP; Thu, 06 Sep 2001 15:34:46 PDT Date: Thu, 6 Sep 2001 15:34:46 -0700 (PDT) From: Michel Py Subject: Re: A new spin on multihoming: multihoming classes. To: Marc Blanchet , multi6@ops.ietf.org In-Reply-To: <5.1.0.14.1.20010905133940.02191060@127.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Marc Blanchet wrote: > However, I would include in this class the > "fiber-to-the home" and wireless > 802.11 community networks. > Still a user class, but the "slow uplink" might not > be right for those users. I have rarely seen these 802.11 networks reaching even half of their rated 11 mbps speed. Besides, lots of them connect to a T1... Lets define "slow uplink": - Anything less than a full T1 ? (other proposals welcome) __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Thu Sep 6 20:09:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12604 for ; Thu, 6 Sep 2001 20:09:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f9D5-0001iB-00 for multi6-data@psg.com; Thu, 06 Sep 2001 17:09:27 -0700 Received: from web13506.mail.yahoo.com ([216.136.175.85]) by psg.com with smtp (Exim 3.33 #1) id 15f9D4-0001i5-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 17:09:26 -0700 Message-ID: <20010907000925.79028.qmail@web13506.mail.yahoo.com> Received: from [63.101.96.1] by web13506.mail.yahoo.com via HTTP; Thu, 06 Sep 2001 17:09:25 PDT Date: Thu, 6 Sep 2001 17:09:25 -0700 (PDT) From: Michel Py Subject: Re: A new spin on multihoming: multihoming classes. To: Sean Doran , multi6@ops.ietf.org In-Reply-To: <20010905180039.114FA84A@sean.ebone.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Sean, Sean Doran wrote: >> Trying to restrict our scope to just some types of sites >> will lead into quasi-legalistic arguing about what a site >> is and whether a small server farm or a soho is really >> a site in the sense of e.g. 2.5.4 of >> draft-ietf-ipngwg-addr-arch-v3-06.txt. I was not trying to restrict the scope of the workgroup but try to describe the problem so everyone has the same reading on it. For what I have read here for the last three days, the two cans of worms that Ilsitch and I have opened did not leave people indifferent. >> In other words, feel free to propose solutions which are >> optimized for certain types of sites, as long as such >> solutions do not exclude (or refuse to interoperate with) >> either a more general (set of) solution(s) or different >> specific solutions for different types of multihomed sites. That makes my point: Until the perfect and universal multihoming solution is invented, this workgroup is the best place to ensure that all classes of multihoming not only can coexist but are aware of each other. I think that everyone would benefit from guidelines in the requirements draft such as: - There are roughly 3 classes of multihoming: entreprise, user and mobile (with some flexible definitions). If your draft is geared to only one or two of these, please make it clear in the text. BTW, when do we see a requirement draft? >> Personally, I prefer more general solutions since assumptions >> about the traffic profiles and even protocols that any given >> entity (particularly ones that are not huge aggregators of traffic) >> tend to be surprisingly short lived. So do I, when they exist. >> Incidentally, I also (personally) prefer solutions which DO NOT >> require the use of BGP. I have heard many times that the only multihoming solution some people would accept is BGP-based and preferably a slow evolution over the IPv4 deal. >> Operational complexity aside, lots of sites means >> lots of ASes, which do not aggregate away even as nicely as >> the prefixes they originate >> (and we do not want to juggle private-use ASes). My IPv6 home network is kinda-multihomed (I have two blocks but no multihoming solution, sigh) to two different 6bone pTLAs using a private ASN and I don't see anything wrong with that as long as the pTLAs do not advertise my ASN but theirs. In the case of MHTP, that would not be a problem at all. >> If all sites are to have some sort of site-identifier, We don't all wear the same shoes because we don't all have the same feet and I think that there is nothing wrong with some sites using their ASN as the site-identifier and some other sites using some other mechanism, because their multihoming requirements are not the same. Michel. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Thu Sep 6 20:28:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12805 for ; Thu, 6 Sep 2001 20:28:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f9VZ-0001vq-00 for multi6-data@psg.com; Thu, 06 Sep 2001 17:28:33 -0700 Received: from web13502.mail.yahoo.com ([216.136.175.81]) by psg.com with smtp (Exim 3.33 #1) id 15f9VZ-0001vk-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 17:28:33 -0700 Message-ID: <20010907002832.82075.qmail@web13502.mail.yahoo.com> Received: from [63.101.96.1] by web13502.mail.yahoo.com via HTTP; Thu, 06 Sep 2001 17:28:32 PDT Date: Thu, 6 Sep 2001 17:28:32 -0700 (PDT) From: Michel Py Subject: RE: A new spin on multihoming: multihoming classes. To: alh-ietf@tndh.net Cc: multi6@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony- > If we don't build a mechanism that ignores the size of > the multi-homed site, we will simply create an operational > problem down the road in transitioning all the sites from one > mechanism to another as they grow. This is true, but keep in mind that a bad solution is better than no solution. There are people that don't want to adopt IPv6 today because there is no multihoming solution. Michel. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Thu Sep 6 20:44:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12969 for ; Thu, 6 Sep 2001 20:44:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15f9kN-00028k-00 for multi6-data@psg.com; Thu, 06 Sep 2001 17:43:51 -0700 Received: from smtp5.andrew.cmu.edu ([128.2.10.85]) by psg.com with esmtp (Exim 3.33 #1) id 15f9kL-00028a-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 17:43:50 -0700 Received: from [192.168.1.100] (pa-monroeville1a-240.pit.adelphia.net [24.50.128.240]) (user=lambert mech=KERBEROS_V4 (0 bits)) by smtp5.andrew.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f870hL7k000921 for ; Thu, 6 Sep 2001 20:43:24 -0400 Date: Thu, 06 Sep 2001 20:43:15 -0400 From: "Michael H. Lambert" To: multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. Message-ID: <519837.3208797795@[192.168.1.100]> In-Reply-To: <20010905165337.3277.qmail@web13509.mail.yahoo.com> X-Mailer: Mulberry/2.0.8 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Wednesday, September 5, 2001 9:53 -0700 Michel Py wrote: > - Entreprise class is for companies that receive a BGP > feed from two different TLAs and have been allocated a > centrally managed multihomed block of IPv6 addresses. > These entreprises run mission-critical web servers > with large pipes to the Net and want 99.999% > availability and global load sharing among their > different connections. > The multihoming solution for entreprise class must be > contained at the network or internet layer. My > personal submission to entreprise class is: > http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt There is a class of sites for which all addresses are likely not created equal: those with connectivity to both the commodity Internet and high-performance research and education networks. For these sites, DNS-based solutions might not prove adequate because applications or even pairs of hosts expect to talk only over the high-performance networks; falling back to the commodity network isn't an option; it indicates failure of the connection. Michael +-----------------------------------------------------------------------+ | Michael H. Lambert, Network Engineer Phone: +1 412 268-4960 | | Pittsburgh Supercomputing Center FAX: +1 412 268-8200 | | 4400 Fifth Avenue, Pittsburgh, PA 15213 lambert@psc.edu | +-----------------------------------------------------------------------+ From owner-multi6@ops.ietf.org Fri Sep 7 00:19:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16818 for ; Fri, 7 Sep 2001 00:19:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fCHi-000472-00 for multi6-data@psg.com; Thu, 06 Sep 2001 20:26:26 -0700 Received: from web13509.mail.yahoo.com ([216.136.173.13]) by psg.com with smtp (Exim 3.33 #1) id 15fCHh-00046w-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 20:26:25 -0700 Message-ID: <20010907032624.50366.qmail@web13509.mail.yahoo.com> Received: from [63.101.96.1] by web13509.mail.yahoo.com via HTTP; Thu, 06 Sep 2001 20:26:24 PDT Date: Thu, 6 Sep 2001 20:26:24 -0700 (PDT) From: Michel Py Subject: RE: A new spin on multihoming: multihoming classes. To: alh-ietf@tndh.net Cc: multi6@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony - Tony Hain wrote: > Actually for the most part they are the same people > that insisted that the only IPv6 addressing/routing > mechanism be a clone of IPv4/CIDR. Yep. > The other point is that many of them simply don't > want to implement IPv6, Right again. > and the lack of a solution to the multi-homing problem > is a sufficient justification for now. Until there is customer demand or senior management reads something about it in a fashion magazine and decide they need it yesterday. > Once that problem is solved > I am sure there will be another reason. No doubt about that either. > The point I was trying to make initially is that > the reasons sites multi-home has absolutely > nothing to do with their size, or the size of the > pipe they connect with. It is simply a function of > their desire to be independent of the provider. > This could be for the ability to change providers, > or simply to be immune to problems any one may have. Today, provider independence exits in IPv4. Its name is NAT. Even for small setups, and even if (in the US) they can get a PA block, most choose to get only a handful of public IPv4 addresses and use RFC1918 private addresses for all their hosts. Switching ISPs? simple, just change the outside address of the router and a few DNS entries. Lots of people have a PI block these days: 192.168.0.0/16. I did not want to open that can of worms before, but there are good possibilities that the provider independance you mention will be provided for IPv6 in a very similar way it is provided in IPv4: NAT to a link-local or a site-local address, with the nice addition that IPv6 would provide a 1host-to-1host NAT translation making it a lot easier on peer to peer applications. (as related to multihoming, a 1-to-many NAT). By hosting the DNS server on the inside and NATting DNS replies (this already works for IPv4), this could provide a reasonably redundant setup. Given, load balancing would be problematic if not impossible and open sessions would die on link failure but for a home/soho setup it's probably a reasonable annoyance. Don't like the idea? me neither, but it has had most of its growing pains already, and you can't beat the price. Michel. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Fri Sep 7 02:23:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02283 for ; Fri, 7 Sep 2001 02:23:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fF34-0005tG-00 for multi6-data@psg.com; Thu, 06 Sep 2001 23:23:30 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.33 #1) id 15fF33-0005tA-00 for multi6@ops.ietf.org; Thu, 06 Sep 2001 23:23:29 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f876NHm04738; Fri, 7 Sep 2001 09:23:17 +0300 Date: Fri, 7 Sep 2001 09:23:16 +0300 (EEST) From: Pekka Savola To: Michel Py cc: , Subject: RE: A new spin on multihoming: multihoming classes. In-Reply-To: <20010907002832.82075.qmail@web13502.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Sep 2001, Michel Py wrote: > This is true, but keep in mind that a bad solution is better than no > solution. There are people that don't want to adopt IPv6 today because > there is no multihoming solution. I'd like to disagree. I think, for most people, this is just a _good excuse_ not to adopt IPv6; they really don't want to yet, as there is little incentive other than being on the cutting edge, and preparing for the days when clients start to enable IPv6. There are ways if people _really_ wanted to get to IPv6. For example, get multihomed IPv4 connectivity and run tunnels over each of them. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-multi6@ops.ietf.org Fri Sep 7 04:00:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03724 for ; Fri, 7 Sep 2001 04:00:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fGYw-0006iV-00 for multi6-data@psg.com; Fri, 07 Sep 2001 01:00:30 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15fGYv-0006iP-00 for multi6@ops.ietf.org; Fri, 07 Sep 2001 01:00:29 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f8781UE19647; Fri, 7 Sep 2001 10:01:30 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 7 Sep 2001 10:01:30 +0200 (CEST) From: Iljitsch van Beijnum To: Michel Py cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <20010906222635.8932.qmail@web13501.mail.yahoo.com> Message-ID: <20010907092149.P5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Sep 2001, Michel Py wrote: > >> "the subset of routers that do not receive a full routing table from > >> a single peer or a default route". > Or: "The subset of routers that do not use a default > route, and peer with two or more other ASNs." I want to exclude the routers that run defaultless by choice, rather than out of necessity. You want to include those. > If I have two BGP feeds from two major ISPs, why > should I use a default route? I can only tell you why I do it: the routers for "my" network don't have enough memory to carry a full table. For two customers I have installed filters to keep the routing table small(er) as well. They have Cisco 7500 routers with more than enough memory on the RSP, but only 32 MB on one of the VIP cards. Those cards need a copy of the forwarding table and 32 MB leaves to little room for error. But if you can, it's better to take full routing from multiple connections, because that way BGP can always find the shortest path. > >>>> Definitely. I guess I have not made myself clear about the relation > >>>> between MHTP and BGP. What should I change in 6.2.9 of > >>>> http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt The problem is that it is hard to find specific information I'm looking for. MHTP rendevous points keep the mapping between multihomed addresses and single homed addresses, right? But is this a static mapping or a dynamic one? I guess I'm used to the "inverted pyramid" writing style, which makes it easier to glance at something and get the most important facts right away. Back to the problem at hand. If we are going to translate addresses, we need to know to things: what are possible valid addresses to translate to, and which of the possible addresses are actually valid/reachable. Unless I'm reading the draft wrong, you try to solve both in one go. I think that's not the best solution, since this way a continuous stream of reachability information flows around the globe, whether this information is of use at a certain point at a certain moment or not. The mapping between MH and SH addresses could easily be quite static if we employ separate means to validate the SH addresses. Also, using MH addresses that are reachable without translation makes sense. That way, there is instant compatibility with non-MH-capable hosts and it saves some processing and address space. > >> Nameserver problem, can't get at the document right now. Maybe you should > >> multihome... [...] > that makes my point about multihoming DNS servers I guess. Disagree: the DNS system has its own redundancy features, which are even better than multihoming. But many people still don't get it and put primary and secondary nameservers in places with shared fate. I remember one time that the entire berkeley.edu domain vanished. They had four nameservers, but all on campus. It seems they have learned from this, though. Iljitsch From owner-multi6@ops.ietf.org Fri Sep 7 04:15:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04044 for ; Fri, 7 Sep 2001 04:15:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fGoL-0006p5-00 for multi6-data@psg.com; Fri, 07 Sep 2001 01:16:25 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15fGoK-0006oz-00 for multi6@ops.ietf.org; Fri, 07 Sep 2001 01:16:24 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f878HQl19668; Fri, 7 Sep 2001 10:17:26 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 7 Sep 2001 10:17:26 +0200 (CEST) From: Iljitsch van Beijnum To: "Michael H. Lambert" cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <519837.3208797795@[192.168.1.100]> Message-ID: <20010907101609.X5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Sep 2001, Michael H. Lambert wrote: > There is a class of sites for which all addresses are likely not created > equal: those with connectivity to both the commodity Internet and > high-performance research and education networks. For these sites, > DNS-based solutions might not prove adequate Do these networks use two address ranges, one for the high performance network and one for the regular network? If so, how is this handled in the DNS today? From owner-multi6@ops.ietf.org Fri Sep 7 08:03:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08377 for ; Fri, 7 Sep 2001 08:03:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fKJQ-0008De-00 for multi6-data@psg.com; Fri, 07 Sep 2001 05:00:44 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.33 #1) id 15fKJP-0008DY-00; Fri, 07 Sep 2001 05:00:43 -0700 Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id IAA15121; Fri, 7 Sep 2001 08:00:34 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id HAA11361; Fri, 7 Sep 2001 07:59:48 -0400 (EDT) Date: Fri, 7 Sep 2001 07:59:48 -0400 (EDT) From: Greg Maxwell To: Randy Bush cc: Iljitsch van Beijnum , Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 6 Sep 2001, Randy Bush wrote: > > If we want an 8k routing table > > maybe i need to be more explicit. it is not clear to me that this is a > useful criterion. I think a more useful criterion is that we want a networks routing table to grow O(n) with the number of peers and customers that they have (i.e. ports) rather then O(x^2) or O(x log x) in the case of a meshed Internet which is not highly aggregated, where x is the number of user networks on the Internet not just the ones connected to you. From owner-multi6@ops.ietf.org Fri Sep 7 09:07:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11474 for ; Fri, 7 Sep 2001 09:07:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fLLo-0008iP-00 for multi6-data@psg.com; Fri, 07 Sep 2001 06:07:16 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15fLLn-0008iC-00 for multi6@ops.ietf.org; Fri, 07 Sep 2001 06:07:15 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f87D8GI20122; Fri, 7 Sep 2001 15:08:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 7 Sep 2001 15:08:16 +0200 (CEST) From: Iljitsch van Beijnum To: Greg Maxwell cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: Message-ID: <20010907142841.S5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 7 Sep 2001, Greg Maxwell wrote: > > > If we want an 8k routing table > > maybe i need to be more explicit. it is not clear to me that this is a > > useful criterion. > I think a more useful criterion is that we want a networks routing table > to grow O(n) with the number of peers and customers that they have (i.e. > ports) rather then O(x^2) or O(x log x) in the case of a meshed Internet > which is not highly aggregated, where x is the number of user networks on > the Internet not just the ones connected to you. None of these represent the current size of a BGP table. I don't think it's possible to remove the x completely from the equation, but O(log x) (which I think more or less represents a table with just the TLAs) is pretty good too. However, the current size of the routing table is not nearly as bad as you say. It's something like O((pz + 1) * x) where p is the number of eBGP peers for a router, x the total global number of routes and z the fraction of the global routing table received from each peer. By decreasing the number of routers, it is possible keep the number of entries in a router's BGP table fairly close to 2x. Unfortunately, larger numbers of routers mean increased processing. A small routing table has disadvantages too: the routing process has to do its job based on less information, so paths will be longer. We shouldn't try to limit the actual size of routing tables in networks, but only make sure the _minimum_ routing table necessary for connectivity is kept as small as possible, however scenic the routes may get using this table. It would also help if we could find a way to keep regional traffic regional without announcing every single /48 individually. Here in Europe we have some experience in transatlantic routing for regional traffic (this was quite common five or six years ago) and I don't think many people want it back. From owner-multi6@ops.ietf.org Fri Sep 7 11:27:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17167 for ; Fri, 7 Sep 2001 11:27:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fNXg-0009wm-00 for multi6-data@psg.com; Fri, 07 Sep 2001 08:27:40 -0700 Received: from mail4.microsoft.com ([131.107.3.122] helo=inet-vrs-04.redmond.corp.microsoft.com) by psg.com with smtp (Exim 3.33 #1) id 15fNXf-0009we-00 for multi6@ops.ietf.org; Fri, 07 Sep 2001 08:27:39 -0700 Received: from 157.54.9.104 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Sep 2001 08:27:26 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 08:27:25 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 08:27:18 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 08:26:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: A new spin on multihoming: multihoming classes. Date: Fri, 7 Sep 2001 08:26:47 -0700 Message-ID: Thread-Topic: A new spin on multihoming: multihoming classes. Thread-Index: AcE3TrjSmNRA/QvvSCyqmAm9VVayMQAYFs/g From: "Christian Huitema" To: "Michel Py" , Cc: X-OriginalArrivalTime: 07 Sep 2001 15:26:48.0246 (UTC) FILETIME=[82927560:01C137B1] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA17167 > Today, provider independence exits in IPv4. Its name > is NAT. Even for small setups, and even if (in the US) they > can get a PA block, most choose to get only a handful of > public IPv4 addresses and use RFC1918 private addresses for > all their hosts. Switching ISPs? simple, just change the > outside address of the router and a few DNS entries. > Lots of people have a PI block these days: > 192.168.0.0/16. This is an extremely naďve view of renumbering. If all it took was "change a few DNS entry", then we should not have any concern with switching IPv6 providers: just switch a few DNS entries and let automatic address configuration take care of the rest. The hard part of renumbering is keeping track of all occurrences of "your address" outside of the DNS, and maintaining existing connections. The address of a host is typically copied in all kinds of configuration files, both inside and outside the local domains. These can be for example access control lists in firewalls and servers, or start-up lists in applications; we know it is a poor practice, but it is also a frequent practice, for all kinds of reasons. The NAT stuff only helps the internal configuration, i.e. the listing of local addresses inside a local domain; IPv6 "site local" addresses provide an equivalent service. But the RFC1918 addresses, or the IPv6 site local addresses, cannot be used outside of the local site; if you want to program a remote firewall or a remote server to accept incoming traffic from the "Example" corporation, you have to program in the "global" address of that network, i.e. the address assigned by a provider. This programming will have to be updated if the provider changes. The TCP connection, IPSEC association, RTP streams, are identified by a pair of IP addresses, plus ports or other end-to-end identifier. In-site connections using the RFC1918 or IPv6 site local addresses will survive renumbering. External connection, on the other hand, will appear to the "other" side as being identified by the global address, as a result of the address translation in the NAT; changing providers will change the mappings, and the connections will be lost. A similar problem occurs in the case of "multi-homing through a NAT": if a flow is directed to an alternate provider as a consequence of load balancing or routing changes, then the mapping changes, and the connections could be lost. This problem is in fact addressed in IPv6 with two mechanisms, the notion of "preferred" and "deprecated" prefix that allows hosts to keep using the old prefix for some time and maintain the connections, and the "binding update" that allows hosts to notify corresponding hosts of a change in their address. Let's please actually solve the problem, not evade in fantasy-land. -- Christian Huitema From owner-multi6@ops.ietf.org Fri Sep 7 15:47:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26070 for ; Fri, 7 Sep 2001 15:47:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fRai-000CYC-00 for multi6-data@psg.com; Fri, 07 Sep 2001 12:47:04 -0700 Received: from smtp7.andrew.cmu.edu ([128.2.10.87]) by psg.com with esmtp (Exim 3.33 #1) id 15fRae-000CY4-00 for multi6@ops.ietf.org; Fri, 07 Sep 2001 12:47:03 -0700 Received: from ebola.psc.edu (ebola.psc.edu [128.182.61.124]) (user=lambert mech=KERBEROS_V4 (0 bits)) by smtp7.andrew.cmu.edu (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id f87JkoUh016297 for ; Fri, 7 Sep 2001 15:46:51 -0400 Date: Fri, 07 Sep 2001 15:46:37 -0400 From: "Michael H. Lambert" To: multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. Message-ID: <2560052.3208866397@ebola.psc.edu> In-Reply-To: <20010907101609.X5044-100000@sequoia.muada.com> X-Mailer: Mulberry/2.0.8 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Friday, September 7, 2001 10:17 +0200 Iljitsch van Beijnum wrote: > Do these networks use two address ranges, one for the high performance > network and one for the regular network? If so, how is this handled in the > DNS today? Historically (in the era of isolated, expensive supercomputers), it was common to put the high-performance interface (called foo-hippi, for example) on a separate /24 in a site /16. This subnet was often routed statically within the site and announced separately (for topological reasons) to the research network. At the time that mechanism worked fine. The current trend is toward highly distributed systems (eg, Grids) and a user community which probably has less of a grasp of the system as a whole than did the previous generation of users. I think that under v6 it will be necessary to keep the Grid machines within the aggregates, although one could probably make a case for high-performance providers to send to (or accept from) peer providers aggregate-breaking announcements. Michael From owner-multi6@ops.ietf.org Fri Sep 7 17:29:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29122 for ; Fri, 7 Sep 2001 17:29:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fTAP-000DVe-00 for multi6-data@psg.com; Fri, 07 Sep 2001 14:28:01 -0700 Received: from lox.sandelman.ottawa.on.ca ([192.139.46.2]) by psg.com with esmtp (Exim 3.33 #1) id 15fTAO-000DVY-00 for multi6@ops.ietf.org; Fri, 07 Sep 2001 14:28:00 -0700 Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id RAA07087 for ; Fri, 7 Sep 2001 17:27:59 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca ([2002:c08b:2e21:2:204:76ff:fe2d:8c]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f87GYBG07567 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 7 Sep 2001 12:34:12 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f87GXbq29146 for ; Fri, 7 Sep 2001 12:33:37 -0400 (EDT) Message-Id: <200109071633.f87GXbq29146@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. In-reply-to: Your message of "Fri, 07 Sep 2001 09:23:16 +0300." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 Sep 2001 12:33:37 -0400 From: Michael Richardson Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pekka" == Pekka Savola writes: Pekka> On Thu, 6 Sep 2001, Michel Py wrote: >> This is true, but keep in mind that a bad solution is better than no >> solution. There are people that don't want to adopt IPv6 today because >> there is no multihoming solution. Pekka> I'd like to disagree. I think, for most people, this is just a _good Pekka> excuse_ not to adopt IPv6; they really don't want to yet, as there is Pekka> little incentive other than being on the cutting edge, and preparing for Pekka> the days when clients start to enable IPv6. Pekka> There are ways if people _really_ wanted to get to IPv6. For example, get Pekka> multihomed IPv4 connectivity and run tunnels over each of them. Ah, that's the rub. Getting multihomed IPv4 connectivity is a lot harder than getting IPv6. (Believe me. I've been involved in getting the groundwork layed in place at multiple mid-sized regional ISPs in order to convince the powers-that-be to allocate an AS#) In my talking with these ISPs, they see essentially no reason for them to risk any of their network to deploy IPv6. Particularly since 6to4 lets their customers do it whenever the customer wants. The customers mostly do not care about IPv6 either, but they wish they could multihome themselves easier. Most have multiple xDSL and 10Mb ATM VCs, but have all sorts of hacks to permit them to make the most use of the bandwidth and redundancy. This is why I object to any solution that has different classes. Nearly every single one of these ISPs went from stack of {SCO,Solaris,Xylogics,BSDi} and modems plus T1 to OC-3+,etc. The customers went from "soho" operations with a single high-end Sparc 2 or 486 to racks and racks of equipment. I think that this is the story of the rest of the Internet as well. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO5j24IqHRg3pndX9AQFYhgP+Mni5ZPBcLR87hPLdIuEqebLPigBOF7Q9 aAJU5NxnYzxBPyD3W0NOYMayT8oj0xNOWYGrsJw3Stt+5/kZkgdR07XjPUi6jLVK 3xag1gJ6DrZuNW0apQlGwymG7Ndq1v4XEXDYnaR5IvWIgsfcH3bE4xqg8pxbmezR I+/n1a1Ia6A= =Logp -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Fri Sep 7 18:42:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00538 for ; Fri, 7 Sep 2001 18:42:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fUIe-000EBu-00 for multi6-data@psg.com; Fri, 07 Sep 2001 15:40:36 -0700 Received: from [139.130.204.11] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 3.33 #1) id 15fUIc-000EBo-00 for multi6@ops.ietf.org; Fri, 07 Sep 2001 15:40:35 -0700 Received: from tecra.telstra.net (gunk.telstra.net [203.10.60.2]) by kahuna.telstra.net (8.11.3/8.11.3) with ESMTP id f87MeNw36750 for ; Sat, 8 Sep 2001 08:40:24 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20010907194104.00aabee0@139.130.204.11> X-Sender: gih@139.130.204.11 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Sep 2001 19:52:23 +1000 To: multi6@ops.ietf.org From: Geoff Huston Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <5.1.0.14.2.20010906105948.00a3e510@10.30.15.2> References: <20010906103406.B13093@x17.ripe.net> <20010906110815.T5044-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 9/7/01 01:02 AM, RJ Atkinson wrote: > Some few folk think that somewhere between 100K and 300K prefixes >it isn't stable to have "fairly stable routing which converges >predictably in reasonable time" when using current BGP and current >BGP algorithms. Those folk are credible, but I haven't seen any >equations yet myself. Again, we appear to be wandering off topic, but right now its not obvious where the scaling issues drive us into instability. While the precise number of prefixes is in an of itself not the major issue with scaling the routing system, its the 'density' of the topology over which BGP is attempting to operate, and the rate of dynamic change of the prefix set and associated AS path vector and related prefix attributes which are a concern. The suspicion is that these concerns are in some way related to the number of prefixes, and that a greater number of prefixes in the routing table may infer a greater density of interconnectivity, and an increase in the rate of dynamic change that in turn may cause BGP. as currently used to take longer to propagate changes and explore more 'infeasible' routes on its path to convergence. But as to the assertion that 8,192 is some magical preferred number of 'root prefixes', then I'm not sure that I can agree. The leverage which appears to offer some promise still appears to be the delineation in the V6 address space of 'identity' and 'routing goop' (GSE-styled approach) so that the routing goop can reflect, to the extent possible, implicit hierarchies in the inter-provider connectivity space. (However it is still unclear to me, at any rate, that address hierarchies in the routing goop are going to provide 'natural' hierarchical aggregation of routing identifiers, but such a discussion is probably still off in the weeds with respect to the charter of this working group.) Geoff From owner-multi6@ops.ietf.org Fri Sep 7 19:57:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01787 for ; Fri, 7 Sep 2001 19:57:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fVVI-000F3V-00 for multi6-data@psg.com; Fri, 07 Sep 2001 16:57:44 -0700 Received: from web13507.mail.yahoo.com ([216.136.175.86]) by psg.com with smtp (Exim 3.33 #1) id 15fVVH-000F3P-00 for multi6@ops.ietf.org; Fri, 07 Sep 2001 16:57:43 -0700 Message-ID: <20010907235743.31600.qmail@web13507.mail.yahoo.com> Received: from [63.101.96.1] by web13507.mail.yahoo.com via HTTP; Fri, 07 Sep 2001 16:57:43 PDT Date: Fri, 7 Sep 2001 16:57:43 -0700 (PDT) From: Michel Py Subject: RE: A new spin on multihoming: multihoming classes. To: Christian Huitema Cc: multi6@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Christian - --- Christian Huitema wrote: >> Let's please actually solve the problem, not evade >> in fantasy-land. Nobody is going to buy that one either. Darn, here goes my dream of Provider-Independant multihoming for serfs that multihome with DSL and Cable. Sigh. Fortunately, my draft is based on BGP.... Michel. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Fri Sep 7 20:13:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01991 for ; Fri, 7 Sep 2001 20:13:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fVlE-000FG7-00 for multi6-data@psg.com; Fri, 07 Sep 2001 17:14:12 -0700 Received: from web13506.mail.yahoo.com ([216.136.175.85]) by psg.com with smtp (Exim 3.33 #1) id 15fVlD-000FG0-00 for multi6@ops.ietf.org; Fri, 07 Sep 2001 17:14:11 -0700 Message-ID: <20010908001410.57233.qmail@web13506.mail.yahoo.com> Received: from [63.101.96.1] by web13506.mail.yahoo.com via HTTP; Fri, 07 Sep 2001 17:14:10 PDT Date: Fri, 7 Sep 2001 17:14:10 -0700 (PDT) From: Michel Py Subject: RE: A new spin on multihoming: multihoming classes. To: Pekka Savola Cc: multi6@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk --- Pekka Savola wrote: >>>> On Thu, 6 Sep 2001, Michel Py wrote: >>>> This is true, but keep in mind that a bad solution >>>> is better than no >>>> solution. There are people that don't want to >>>> adopt IPv6 today because >>>> there is no multihoming solution. >> I'd like to disagree. I think, for most people, >> this is just a _good excuse_ not to adopt IPv6; >> they really don't want to yet, as there is >> little incentive other than being on the cutting >> edge, and preparing for >> the days when clients start to enable IPv6. I agree with that, but the fact that the lack of a multihoming solution is used as an excuse does not change the outcome. >> There are ways if people _really_ wanted to get to >> IPv6. For example, get multihomed IPv4 connectivity >> and run tunnels over each of them. Yep, using 6to4 tunnels. Which makes the problem worse, because if they can multihome IPv4 most will find plenty of excuses to delay IPv6 deployment. Michel. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Fri Sep 7 20:44:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02602 for ; Fri, 7 Sep 2001 20:44:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fWEf-000FaU-00 for multi6-data@psg.com; Fri, 07 Sep 2001 17:44:37 -0700 Received: from web13507.mail.yahoo.com ([216.136.175.86]) by psg.com with smtp (Exim 3.33 #1) id 15fWEe-000FaO-00 for multi6@ops.ietf.org; Fri, 07 Sep 2001 17:44:36 -0700 Message-ID: <20010908004436.34616.qmail@web13507.mail.yahoo.com> Received: from [63.101.96.1] by web13507.mail.yahoo.com via HTTP; Fri, 07 Sep 2001 17:44:36 PDT Date: Fri, 7 Sep 2001 17:44:36 -0700 (PDT) From: Michel Py Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org In-Reply-To: <20010907092149.P5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch - --- Iljitsch van Beijnum wrote: >>>>>> "the subset of routers that do not receive a >>>>>> full routing table from a single peer or a >>>>>> default route". >>>> Or: "The subset of routers that do not use a >>>> default route, and peer with two or more other ASNs." >> I want to exclude the routers that run defaultless >> by choice, rather than out of necessity. You want >> to include those. That is where I don't follow you. In defining the semantics of what is the DFZ, why would you exclude the routers that run defaultless by choice? I thought that the definition if the DFZ should match WHAT the routers actually do and not WHY. >> but only 32 MB on one of the VIP cards. Those cards need >> a copy of the forwarding table and 32 MB >> leaves to little room for error. Selling the customer Cisco 12416s would solve the problem ;-) Then you can scrounge the 7500 for your CCIE lab :-) >>>> What should I change in 6.2.9 of >>>> http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt >> The problem is that it is hard to find specific >> information I'm looking for. MHTP rendevous points >> keep the mapping between multihomed addresses >> and single homed addresses, right? But is this a >> static mapping or a dynamic one? The MHTP routing table is a standard BGP routing table, dynamic naturally. However, the rendezvous point is used in the bootstrap phase only, then the client and the endpoint >> Back to the problem at hand. If we are going to >> translate addresses, we need to know two things: >> what are possible valid addresses to translate to, >> and which of the possible addresses are actually >> valid/reachable. Unless I'm reading the draft wrong, >> you try to solve both in one go. Correct. >> I think that's not the best solution, since this way a >> continuous stream of reachability information flows >> around the globe, whether this information is of use >> at a certain point at a certain moment or not. I am unsure of what you are refering to here. If you are talking about the MHTP routing table, The way I understand BGP is that routes are not exchanged if they do not change so there is no reachability information floating around the globe unless a change occurs. If you are referring to MHTP keepalives, these are sent only when there is active traffic between an MHTP client and an MHTP prefix, the the reachability information that flows flows only from/to there is current traffic and times out quickly. >> The mapping between MH and SH addresses could easily be >> quite static if we employ separate means to validate >> the SH addresses. The mapping between MH and DH addresses is actually static (router's configuration if you prefer) in MHTP endpoints. In MHTP rendezvous points, it will change only if a link goes down or that kind of event. >> Also, using MH addresses that are reachable without >> translation makes sense. That way, there is instant >> compatibility with non-MH-capable hosts >> and it saves some processing and address space. That way the implementation can be gradual, and there are tools (control of proxying rate) that could help enforce the migration, if desired or required. >> Disagree: the DNS system has its own redundancy >> features, which are even better than multihoming. >> But many people still don't get it and put >> primary and secondary nameservers in places with We are actually saying the same thing: The design of DNS redundancy is better than multihoming. How do we get people to actually use it? Michel. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Fri Sep 7 21:06:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02873 for ; Fri, 7 Sep 2001 21:05:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fWa0-000FqD-00 for multi6-data@psg.com; Fri, 07 Sep 2001 18:06:40 -0700 Received: from sean.ebone.net ([195.158.227.211]) by psg.com with esmtp (Exim 3.33 #1) id 15fWa0-000Fq6-00 for multi6@ops.ietf.org; Fri, 07 Sep 2001 18:06:40 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 756C981D; Sat, 8 Sep 2001 03:06:35 +0200 (CEST) To: multi6@ops.ietf.org Subject: administrivia Message-Id: <20010908010635.756C981D@sean.ebone.net> Date: Sat, 8 Sep 2001 03:06:35 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk All - Please, this really is not the place for speculation about whether or not IPv6 will be deployed, when or why it will or will not be deployed, and so forth. Discussions about why this WG exists and what the motivations of the many participants are do not belong here. May I humbly suggest the IESG, IAB and IETF mailing lists for some of these topics? Here, please focus on how to do site multihoming for v6, and in particular discussion geared towards fulfilling our milestones. There are several drafts which have been put forward, which would benefit from more positive energy spent on comments/improvements, or even the submission of completely different drafts. Officially yours, Sean. (your friendly co-chair) From owner-multi6@ops.ietf.org Sat Sep 8 00:03:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07227 for ; Sat, 8 Sep 2001 00:03:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fZKq-000HSM-00 for multi6-data@psg.com; Fri, 07 Sep 2001 21:03:12 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15fZKp-000HSF-00 for multi6@ops.ietf.org; Fri, 07 Sep 2001 21:03:11 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id OAA29801; Sat, 8 Sep 2001 14:03:08 +1000 (EST) Date: Sat, 8 Sep 2001 14:03:07 +1000 (EST) From: Peter Tattam To: Geoff Huston cc: multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <4.3.2.7.2.20010907194104.00aabee0@139.130.204.11> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 7 Sep 2001, Geoff Huston wrote: > At 9/7/01 01:02 AM, RJ Atkinson wrote: > > But as to the assertion that 8,192 is some magical preferred number of > 'root prefixes', then I'm not sure that I can agree. > Geoff, I am concerned that the whole multihoming issue hinges on the answer to whether BGP can be made to work with larger DFZ than we anticipated. I'm not sure where 8K comes from. 8K = 2^13. Maybe it relates to the size of a practical switching table in very fast routers built using ASICs. Maybe it's just a figure which was plucked out of the air in relation to the BGP table size at the time of the IPv6 standards being formed. Maybe it's a figure designed to stabilize the core given the high bandwidths we're likely to experience in the future. We have probably gotten to the point where we finally have enough capacity on inter site links and now RTT delays will be governed My impression however is that it has been generally agreed (amongst Ipv6 people at least) that BGP in its current form isn't going to scale. If I asked you the question "how big is too big" what would you answer, and how would base your measure? My understanding wasn't that it was hardware size limitations that we critical, but more that the amount of information grows faster than O(n) resulting in exchange of that information causing instability of the DFZ. In my opinion some of the measures that prevent route flapping may actually cause more damage than good because they introduce stepping functions into the differential equation that would model the DFZ. They work now because the paramters have been determined empirically - I'm uncertain that they will scale indefinitely. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Sat Sep 8 09:06:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25574 for ; Sat, 8 Sep 2001 09:06:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fhm5-000N58-00 for multi6-data@psg.com; Sat, 08 Sep 2001 06:03:53 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15fhm4-000N52-00 for multi6@ops.ietf.org; Sat, 08 Sep 2001 06:03:53 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f88D4ju24182; Sat, 8 Sep 2001 15:04:45 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 8 Sep 2001 15:04:45 +0200 (CEST) From: Iljitsch van Beijnum To: Michael Richardson cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <200109071633.f87GXbq29146@marajade.sandelman.ottawa.on.ca> Message-ID: <20010908145708.V5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 7 Sep 2001, Michael Richardson wrote: > Getting multihomed IPv4 connectivity is a lot harder than getting IPv6. > (Believe me. I've been involved in getting the groundwork layed in place at > multiple mid-sized regional ISPs in order to convince the powers-that-be to > allocate an AS#) Strange, I've never had much trouble getting an AS# from RIPE. > customers do it whenever the customer wants. The customers mostly do not care > about IPv6 either, but they wish they could multihome themselves easier. Most > have multiple xDSL and 10Mb ATM VCs, but have all sorts of hacks to permit > them to make the most use of the bandwidth and redundancy. So then if we can come up with a good multiple addresses / host multihoming scheme, it might be worth the trouble to see if we can get it to work on IPv4 too. Or why stop there. Let's make something that runs over both IPv6 and IPv4 at the same time. From owner-multi6@ops.ietf.org Sat Sep 8 10:00:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25991 for ; Sat, 8 Sep 2001 10:00:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fifa-000Ndk-00 for multi6-data@psg.com; Sat, 08 Sep 2001 07:01:14 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15fifZ-000Nde-00 for multi6@ops.ietf.org; Sat, 08 Sep 2001 07:01:13 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f88E2FF24231; Sat, 8 Sep 2001 16:02:15 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 8 Sep 2001 16:02:15 +0200 (CEST) From: Iljitsch van Beijnum To: Michel Py cc: Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <20010908004436.34616.qmail@web13507.mail.yahoo.com> Message-ID: <20010908151229.I5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 7 Sep 2001, Michel Py wrote: > >> I want to exclude the routers that run defaultless > >> by choice, rather than out of necessity. You want > >> to include those. > That is where I don't follow you. In defining the semantics > of what is the DFZ, why would you exclude the routers that > run defaultless by choice? I thought that the definition > if the DFZ should match WHAT the routers actually do and not WHY. The "tier 1" networks need to run defaultless, even if this becomes very expensive. People who do it by choice can always stop if it becomes too expensive for them. So if it's only the latter who complain, I don't see why we should listen. > >> but only 32 MB on one of the VIP cards. Those cards need > >> a copy of the forwarding table and 32 MB > >> leaves to little room for error. > Selling the customer Cisco 12416s would solve the problem ;-) > Then you can scrounge the 7500 for your CCIE lab :-) Ah, should have thought of that... > >> I think that's not the best solution, since this way a > >> continuous stream of reachability information flows > >> around the globe, whether this information is of use > >> at a certain point at a certain moment or not. > I am unsure of what you are refering to here. If you are > talking about the MHTP routing table, The way I understand > BGP is that routes are not exchanged if they do not change > so there is no reachability information floating around the > globe unless a change occurs. Of course. But with 100k+ multihomers that means many changes per minute (even if we assume just a few flaps a month on average), and if multihoming becomes easier the number will grow rapidly. I think any solution where many systems around the world must be kept up to date on the status of the connections of all multihomers world wide won't scale: both the amount of information and the number of changes increase with the number of multihomers, creating a growth curve in processing requirements of O(x^2) or maybe O(x log x) with a good implementation. What we want is at least O(x), but preferably O(log x). And it's not necessary: as soon as you start communicating, it's not too hard to find out which addresses are valid and which aren't. Finding out all available potentially usable addresses is harder. > >> Also, using MH addresses that are reachable without > >> translation makes sense. That way, there is instant > >> compatibility with non-MH-capable hosts > >> and it saves some processing and address space. > That way the implementation can be gradual, and there > are tools (control of proxying rate) that could help > enforce the migration, if desired or required. So you agree that using separate MH addresses that aren't reachable through existing SH means, is not the best solution? > >> Disagree: the DNS system has its own redundancy > >> features, which are even better than multihoming. > We are actually saying the same thing: The design of > DNS redundancy is better than multihoming. How do we > get people to actually use it? Why should we? If they misconfigure their DNS they have to live with the consequences. If we can make everything work when both sides of the session have their stuff in working order and there is a possible path, that should be enough. Userfriendliness is good for implementations, but not so much for protocols, IMO. From owner-multi6@ops.ietf.org Sat Sep 8 13:48:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27959 for ; Sat, 8 Sep 2001 13:48:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fmDg-000Pgz-00 for multi6-data@psg.com; Sat, 08 Sep 2001 10:48:40 -0700 Received: from lox.sandelman.ottawa.on.ca ([192.139.46.2]) by psg.com with esmtp (Exim 3.33 #1) id 15fmDf-000Pgt-00 for multi6@ops.ietf.org; Sat, 08 Sep 2001 10:48:39 -0700 Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id NAA22043 for ; Sat, 8 Sep 2001 13:48:39 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca ([3ffe:1ce1:0:fe50:204:76ff:fe2d:8c]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f88HnCG08919 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sat, 8 Sep 2001 13:49:13 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f88HmT416566 for ; Sat, 8 Sep 2001 13:48:29 -0400 (EDT) Message-Id: <200109081748.f88HmT416566@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. In-reply-to: Your message of "Sat, 08 Sep 2001 14:03:07 +1000." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 08 Sep 2001 13:48:28 -0400 From: Michael Richardson Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Peter" == Peter Tattam writes: Peter> On Fri, 7 Sep 2001, Geoff Huston wrote: >> But as to the assertion that 8,192 is some magical preferred number of >> 'root prefixes', then I'm not sure that I can agree. Peter> I am concerned that the whole multihoming issue hinges on the Peter> answer to whether Peter> BGP can be made to work with larger DFZ than we anticipated. Peter> I'm not sure where 8K comes from. 8K = 2^13. Peter> Maybe it relates to the size of a practical switching table in very fast Peter> routers built using ASICs. No. Currently shipping OC-48 capable ASICs do 100K+ easily (for IPv4). Announced OC-192 ASICs do the same or more, and most designs have roadmaps to OC-768, assuming that the OIF/NPF people finish defining appropriate electrical interfaces to get packets between ASICs at that rate :-) Some solutions scale as the number of bits that matter. I.e. a single /128 entry simply takes twice as much space as two /64s, while other solutions must store as many bits as the worst case length. The pathological situation (highest price, highest power dissipation) is ternary CAMs which seem to do 72 bits or 144 bits only as options. I too would like to know about this 8K DFZ. I can see that there are BGP convergence reasons why one might want to attempt to keep the size small, but this number scares me. Peter> In my opinion some of the measures that prevent route flapping may actually Peter> cause more damage than good because they introduce stepping functions into the Peter> differential equation that would model the DFZ. They work now because the Peter> paramters have been determined empirically - I'm uncertain that Peter> they will scale Peter> indefinitely. That's an interesting observation. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (NetBSD) Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard iQCVAwUBO5pZ64qHRg3pndX9AQG1zwP+LRjVAvPvg+Yihh//T+6qkX1fRa+7hHZr oFF/cZDj+FiAG/6UG4uPeZSK/8KLaLzslGazJzzi0ywitQkLXYjOxFVZNmMlU7xb GdpxN6DtYHCcaQ9zg41T+9LfWktP0UoNnw9HlZGDB1PV9oasea8TUh/+n8KdrUQE nnhR7W5CVzQ= =4lid -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sat Sep 8 14:13:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28185 for ; Sat, 8 Sep 2001 14:13:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fmcH-000Pxn-00 for multi6-data@psg.com; Sat, 08 Sep 2001 11:14:05 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15fmcG-000Pxh-00 for multi6@ops.ietf.org; Sat, 08 Sep 2001 11:14:04 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f88IF8H24451 for ; Sat, 8 Sep 2001 20:15:08 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 8 Sep 2001 20:15:08 +0200 (CEST) From: Iljitsch van Beijnum To: Subject: Distributed reachability information Message-ID: <20010908193134.O5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Thinking about a good way to turn my MILAR proposal into a draft, it occurred to me that the following should probably be something separate. In a multi-address multihoming environment, it helps a lot to have good reachability information for the different addresses of a remote host. Sending traffic immediately to the "best" address has many advantages over choosing one more or less randomly and detect failures later. Being able to pick a working address out of a set of addresses prior to session establishment can even be considered a very basic form of multihoming support. This could be accomplished by using some kind of reachability cache, storing information about whether an address or prefix is reachable (or even how well, using RTT, bandwidth and packet loss statistics). As the session is initiated, the possible addresses for the remote host are checked against the reachability cache and the "best" address is selected. Obviously the choice is limited when just one address is available: then the system should try to connect to this address, whatever the cached status. The data for the cache can come from ICMP unreachables and protocols or even applications that gather their own statistics. Sharing this information with other hosts and routers (as Peter Tattam and myself discussed earlier this week) makes a lot of sense. If one host discovers an address is unreachable, other local hosts can benefit from this and immediately contact one of the other addresses for this destination host if they want to connect to it shortly after that. The question is: how do we implement this? One way would be to create a protocol from scratch. Another would be to abuse RIP for this. I haven't really looked in to this, but RIP does a lot of the same things in a somewhat different manner, so it could be a good starting point. Then there is the most dangerous way: integrate some or all of this into the DNS. Name servers already gather a lot of statistics that could be useful. Also, hosts continuously query the DNS, adding reachability information to the answers seems like a logical extension. Or the DNS could even hold back addresses it thinks are unreachable when replying to queries. Tell me what you think. It would probably help to get some input from a DNS guru. That is, if they didn't all faint upon reading this. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Sat Sep 8 15:31:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28820 for ; Sat, 8 Sep 2001 15:31:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fnpZ-0000hh-00 for multi6-data@psg.com; Sat, 08 Sep 2001 12:31:53 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15fnpY-0000hb-00 for multi6@ops.ietf.org; Sat, 08 Sep 2001 12:31:52 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id MAA09102; Sat, 8 Sep 2001 12:31:48 -0700 (PDT) Date: Sat, 8 Sep 2001 12:31:47 -0700 (PDT) From: Ramakrishna Gummadi To: Michael Richardson cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <200109081748.f88HmT416566@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > I too would like to know about this 8K DFZ. > I can see that there are BGP convergence reasons why one might want to > attempt to keep the size small, but this number scares me. I may be wrong, but isn't this number from rfc2374? To quote from section 4.0: The size of the Top-Level Aggregation Identifier is 13 bits. This allows for 8,192 TLA ID's. This size was chosen to insure that the default-free routing table in top level routers in the Internet is kept within the limits, with a reasonable margin, of the current routing technology. The margin is important because default-free routers will also carry a significant number of longer (i.e., more- specific) prefixes for optimizing paths internal to a TLA and between TLAs. -ramki From owner-multi6@ops.ietf.org Sat Sep 8 19:43:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00990 for ; Sat, 8 Sep 2001 19:43:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15frk6-00032V-00 for multi6-data@psg.com; Sat, 08 Sep 2001 16:42:30 -0700 Received: from web13501.mail.yahoo.com ([216.136.175.80]) by psg.com with smtp (Exim 3.33 #1) id 15frk5-00032P-00 for multi6@ops.ietf.org; Sat, 08 Sep 2001 16:42:29 -0700 Message-ID: <20010908234228.28425.qmail@web13501.mail.yahoo.com> Received: from [63.101.96.1] by web13501.mail.yahoo.com via HTTP; Sat, 08 Sep 2001 16:42:28 PDT Date: Sat, 8 Sep 2001 16:42:28 -0700 (PDT) From: Michel Py Subject: Re: A new spin on multihoming: multihoming classes. To: Ramakrishna Gummadi Cc: multi6@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Ramki- --- Ramakrishna Gummadi wrote: >> I may be wrong, but isn't this number from rfc2374? >> To quote from section 4.0: >> The size of the Top-Level Aggregation Identifier >> is 13 bits. This allows for 8,192 TLA ID's. This >> size was chosen to insure that the default-free >> routing table in top level routers in the Internet >> is kept within the limits, with a reasonable margin >> of the current routing technology. The margin is >> important because default-free routers will also >> carry a significant number of longer (i.e., more- >> specific) prefixes for optimizing paths internal >> to a TLA and between TLAs. This is pretty much what I say in section 5.5.2 of the -01 draft of MHTP: ( http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt ) 5.5.2. Simplified routing on high-bandwidth routers: Since backbone routers would no longer need to handle multihomed traffic, the IPv6 DFZ could be summarized in the spirit that has guided its inception. To take the summarization to an unrealistically absurd level, the IPv6 backbone could be summarized at the /16 boundary, and the 6bone could be summarized at the /28 boundary without compromising the multihoming capabilities of MHTP. I other words: Although the IPv6 DFZ could THEORATICALLY be summarized to the /16 boundary (which effectively be a 8k routig table when all 8192 TLAs have been assigned) the reality is that more specific prefixes are more than likely to be seen there. Michel. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Sun Sep 9 00:03:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05229 for ; Sun, 9 Sep 2001 00:03:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fvpL-0005Ny-00 for multi6-data@psg.com; Sat, 08 Sep 2001 21:04:11 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15fvpK-0005Nr-00 for multi6@ops.ietf.org; Sat, 08 Sep 2001 21:04:10 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id OAA03138; Sun, 9 Sep 2001 14:04:00 +1000 (EST) Date: Sun, 9 Sep 2001 14:04:00 +1000 (EST) From: Peter Tattam To: Michael Richardson cc: multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <200109081748.f88HmT416566@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 8 Sep 2001, Michael Richardson wrote: > > >>>>> "Peter" == Peter Tattam writes: > Peter> On Fri, 7 Sep 2001, Geoff Huston wrote: > >> But as to the assertion that 8,192 is some magical preferred number of > >> 'root prefixes', then I'm not sure that I can agree. > > Peter> I am concerned that the whole multihoming issue hinges on the > Peter> answer to whether > Peter> BGP can be made to work with larger DFZ than we anticipated. > > Peter> I'm not sure where 8K comes from. 8K = 2^13. > > Peter> Maybe it relates to the size of a practical switching table in very fast > Peter> routers built using ASICs. > > No. > Currently shipping OC-48 capable ASICs do 100K+ easily (for IPv4). > Announced OC-192 ASICs do the same or more, and most designs have roadmaps > to OC-768, assuming that the OIF/NPF people finish defining appropriate > electrical interfaces to get packets between ASICs at that rate :-) > > Some solutions scale as the number of bits that matter. I.e. a single /128 > entry simply takes twice as much space as two /64s, while other solutions > must store as many bits as the worst case length. The pathological situation > (highest price, highest power dissipation) is ternary CAMs which seem to do > 72 bits or 144 bits only as options. > Ok. Point taken. Flies in the face of the RFC recommendations mentioned in other docs. So we have the technology to make large routing crossbars. I guess the issue is what's feeding that crossbars. Am I right in guessing that a lot of the BGP stuff happens as a background process in the routers, and it's managing that BGP mesh in a stable manner that's at issues. Can one assume that technology will keep track of the expansion of the internet necessary? At issue is a big question as to whether BGP will scale *across the whole network* . I haven't seen a clear informed answer to this yet. Many of the studies I've seen refer only to empirical studies and analysis of the current v4 network and predictions of what is likely in the next year or so. One problem that I see (correct me if I'm wrong) with the current v4 BGP system is that *IF* there is a BGP storm it affects *everyone* whether they are multihomed or not. In other words, those sites which aren't multihomed are penalized. Stability of the core is then threatened merely by the act of allowing multihoming via long prefixes. It would be a very worthy post grad thesis to do a realistic simulation of the BGP system to see exactly what happens when it is scaled up in size - there must be one around I'm sure, but it might need a supercomputer to do it. I guess it comes down to fundamentals. For a router based solution, you need to fill the DFZ with all the possible MH information for every MH site in the world and intuitively we think this can't possibly scale. To date the ratio of MH sites to non-MH sites has been low - kept that way because of availability & cost. However with the advent of widespread always on connectivity and bandwidth (e.g. Cable, DSL, 802.11) the potential availablility of MH is likely to increase that ratio faster than would have been initially predicted. The concern is that even if a core router could switch fast enough & with what seems a reasoanble number of routing table entries, the overengineering required for a given router lifetime is difficult to predict with the current BGP based MH solution. The suggested IPv6 solution is to limit the choices that the DFZ routers need to make and push the MH decision making to the edges. By doing so, you throw away the MH information visible at the core and you have to regain it another way (which I've said before). Once thing we do know scales reasonably well is that of DNS. It has the job of providing name to address mapping for almost every address on the planet and it does it by virtue of localization of information & caching. It has a few bottle necks I suspect where there are heavily loaded domain names (e.g. .com) but it survives because it can be managed with technology which is cheaper han routers and where memory cost integral is reducing at a much faster rate I suspect than router memory and ASICs. So I can only think that to achieve the scalability we want, we still need to work on decentralizing the MH decision making no matter how confident we think that core routers are going to cope. Finally I might add that I have to concede there is one fundamental flaw in the host based or DNS based solutions to MH and that was eloquently pointed out by someone else. DNS needs routing so routing can't depend on DNS which means we can't use it as it is currently implemented, primarily because DNS is agnostic towards routing conditions. This implies that you need a globally reachable sub system that is independent of MH conditions which will then supply the MH information for any site based or transport based MH solutions to function. Very likely it could borrow heavily from DSN, but it would need to be redesigned to be resilient to MH conditions which I believe DNS is not. My final conclusion is that we need a reachability caching system somewhat like DNS but which is reachability aware. Traditionally BGP has met this target but this places the burden on routers to manage it. An idea springs to mind - why not have an alternative system based on BGP *independent* of the routing system from which reachability information can be gathered. Such a BGP system would need to be extended so that whole DFZ would not need to be kept in the BGP server, but rather the localized routing needs of the site instead, much in the same way that a DNS server only keeps the localized name mapping that it requires for the sites current connections. Such a system would meet the needs of keeping the *DFZ of core routers* small, provide information for load balancing, retain a strong aggregation structure, reduce instability of the core by forbidding advertising long prefixes. I believe it could be executed on hardware comparable to that which DNS uses. Such a service could be referenced by node based multihoming solutions to provide an accurate and timely source of information for such solutions. If this has been thought of before I completely apologize to the original proposer. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Sun Sep 9 01:36:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07764 for ; Sun, 9 Sep 2001 01:36:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fxGc-0006Fy-00 for multi6-data@psg.com; Sat, 08 Sep 2001 22:36:26 -0700 Received: from cheops.cs.berkeley.edu ([128.32.33.73]) by psg.com with esmtp (Exim 3.33 #1) id 15fxGc-0006Fs-00 for multi6@ops.ietf.org; Sat, 08 Sep 2001 22:36:26 -0700 Received: from localhost (ramki@localhost) by cheops.cs.berkeley.edu (8.11.2/8.11.2) with ESMTP id f895VeP01967; Sat, 8 Sep 2001 22:31:40 -0700 Date: Sat, 8 Sep 2001 22:31:39 -0700 (PDT) From: Ramakrishna Gummadi To: Peter Tattam cc: Michael Richardson , Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi Peter, > An idea springs to mind - why not have an alternative system based on BGP > *independent* of the routing system from which reachability information can be > gathered. Such a BGP system would need to be extended so that whole DFZ would > not need to be kept in the BGP server, but rather the localized routing needs > of the site instead, much in the same way that a DNS server only keeps the > localized name mapping that it requires for the sites current connections. My draft (http://www.ietf.org/internet-drafts/draft-ramki-multi6-nlmp-00.txt), together with rfc2660, takes a somewhat similar approach by marking unusable prefixes with a special BGP attribute and both localizing and aggregating this unreachability information in BGP. It would be great if you can tell me what you think of it. thanks, ramki From owner-multi6@ops.ietf.org Sun Sep 9 02:36:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19140 for ; Sun, 9 Sep 2001 02:36:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15fyDW-0006m5-00 for multi6-data@psg.com; Sat, 08 Sep 2001 23:37:18 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15fyDU-0006lz-00 for multi6@ops.ietf.org; Sat, 08 Sep 2001 23:37:17 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id QAA01536; Sun, 9 Sep 2001 16:37:09 +1000 (EST) Date: Sun, 9 Sep 2001 16:37:09 +1000 (EST) From: Peter Tattam To: Ramakrishna Gummadi cc: Michael Richardson , multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk I have no desire to change existing BGP system - it will be needed to keep the aggregated direct routing framework in place. The key point I was trying to make was decoupling of an alternative BGP cache from the routing infrastructure. From my reading of http://www.telstra.net/gih/papers/ietf50-bgp.pdf it becomes clear that multihoming is already a major degradation issue for the Ipv4 network based on current BGP models. I especially note the growth in the longer prefixes (/24). On Sat, 8 Sep 2001, Ramakrishna Gummadi wrote: > Hi Peter, > > > An idea springs to mind - why not have an alternative system based on BGP > > *independent* of the routing system from which reachability information can be > > gathered. Such a BGP system would need to be extended so that whole DFZ would > > not need to be kept in the BGP server, but rather the localized routing needs > > of the site instead, much in the same way that a DNS server only keeps the > > localized name mapping that it requires for the sites current connections. > > My draft > (http://www.ietf.org/internet-drafts/draft-ramki-multi6-nlmp-00.txt), > together with rfc2660, takes a somewhat similar approach by marking unusable > prefixes with a special BGP attribute and both localizing and > aggregating this unreachability information in BGP. It would be great if > you can tell me what you think of it. > > thanks, > ramki > > > > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Sun Sep 9 05:25:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07931 for ; Sun, 9 Sep 2001 05:25:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15g0ok-0008Oy-00 for multi6-data@psg.com; Sun, 09 Sep 2001 02:23:54 -0700 Received: from cheops.cs.berkeley.edu ([128.32.33.73]) by psg.com with esmtp (Exim 3.33 #1) id 15g0oj-0008Os-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 02:23:53 -0700 Received: from localhost (ramki@localhost) by cheops.cs.berkeley.edu (8.11.2/8.11.2) with ESMTP id f899JAW03876; Sun, 9 Sep 2001 02:19:10 -0700 Date: Sun, 9 Sep 2001 02:19:09 -0700 (PDT) From: Ramakrishna Gummadi To: Peter Tattam cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > >From my reading of > > http://www.telstra.net/gih/papers/ietf50-bgp.pdf > > it becomes clear that multihoming is already a major degradation issue for the > Ipv4 network based on current BGP models. My claim is that current BGP can be modified to both eliminate separate multihoming entries and include the same information that would be provided by a separate reachability cache. -ramki From owner-multi6@ops.ietf.org Sun Sep 9 07:28:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08666 for ; Sun, 9 Sep 2001 07:28:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15g2kY-0009ZG-00 for multi6-data@psg.com; Sun, 09 Sep 2001 04:27:42 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15g2kX-0009ZA-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 04:27:41 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f89BSis01475; Sun, 9 Sep 2001 13:28:44 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 9 Sep 2001 13:28:44 +0200 (CEST) From: Iljitsch van Beijnum To: Peter Tattam cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: Message-ID: <20010909094516.Q1293-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 9 Sep 2001, Peter Tattam wrote: > At issue is a big question as to whether BGP will scale *across the whole > network* . I haven't seen a clear informed answer to this yet. Many of the > studies I've seen refer only to empirical studies and analysis of the current > v4 network and predictions of what is likely in the next year or so. Even if we assume the stability of new multihomers is the same of that of current networks, the load on the BGP route processing system will increase faster than the number of routes because each update needs to be done on a larger table. This means order O(x^2) if doing an update scales in a linear way or O(x log x) if it scales logarithmically. > Finally I might add that I have to concede there is one fundamental flaw in the > host based or DNS based solutions to MH and that was eloquently pointed out by > someone else. DNS needs routing so routing can't depend on DNS which means we > can't use it as it is currently implemented, primarily because DNS is agnostic > towards routing conditions. Eloquent, but wrong. In the multi-address multihoming (MAMH) proposals we've seen lately, there are never changes to single homed routing. So as long as the domain name system only depends on single homed routing, there is no problem. Also, no actual forwarding decisions depend on DNS information, it is only used to find out addresses associated with a hostname (or possibly with another address). This is hardly a new thing for the DNS. If we're going to do MAMH, we need three things: 1. initial address discovery: DNS already does this 2. address negotiation: mobile IP already does this 3. failover: this we don't have Not a strict requirement, but it would be very helpful to have a choice whether the end hosts or a proxy/router/NAT-like box does the necessary multi-address multihoming processing. > This implies that you need a globally reachable sub system that is independent > of MH conditions which will then supply the MH information for any site based > or transport based MH solutions to function. Very likely it could borrow > heavily from DSN, but it would need to be redesigned to be resilient to MH > conditions which I believe DNS is not. In the DNS, the information for each zone is replicated over two or more servers. Rather than making sure you can always get at a certain server, the DNS makes sure you can always get at the information by trying servers until a live one is found. If all TCP/IP applications (well, the DNS is not really an "application") did this, there would be no need for multihoming support. > An idea springs to mind - why not have an alternative system based on BGP > *independent* of the routing system from which reachability information can be > gathered. Such a BGP system would need to be extended so that whole DFZ would > not need to be kept in the BGP server, but rather the localized routing needs > of the site instead, much in the same way that a DNS server only keeps the > localized name mapping that it requires for the sites current connections. In BGP, all the routers in the path need to know a route. Since that can't be a requirement here (back to BGP scaling) we're limited to multi-address multihoming or tunneling/rewriting schemes. So I would send a query along the lines of "what are all of the addresses for a:b:c:d::1/128 and how reachable are they" to a root reachability server. That one would probably return "a:b::1:2:3 is authorative for a:b::/32" and assuming no more recursion a:b::1:2:3 would answer: "alternative prefixes for a:b:c:d::/64 are: a:b:c:d:: min RTT: 1700 us, bandwidth 1544 kbps, reliability 100% d:e:f:9:: min RTT: 520 ms, bandwidth 44736 kbps, reliability 99% 5:6:7:8:: min RTT: 20 ms, bandwidth 128 kbps, reliability 93% additional information: d:e:f:9::1/128 reliability 0%" meaning the site is connected over a T1, a satellite DS3 and ISDN dial-up, and the host in question not being able to use the ISDN line at the moment. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Sun Sep 9 07:35:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08778 for ; Sun, 9 Sep 2001 07:35:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15g2st-0009eu-00 for multi6-data@psg.com; Sun, 09 Sep 2001 04:36:19 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15g2ss-0009eo-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 04:36:18 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f89BbX601485; Sun, 9 Sep 2001 13:37:33 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 9 Sep 2001 13:37:33 +0200 (CEST) From: Iljitsch van Beijnum To: Ramakrishna Gummadi cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: Message-ID: <20010909132846.N1293-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 9 Sep 2001, Ramakrishna Gummadi wrote: > My claim is that current BGP can be modified to both eliminate > separate multihoming entries and include the same > information that would be provided by a separate reachability cache. BGP can of course tell you that a certain prefix is _not_ reachable, but it can not tell you that a specific address within that prefix _is_ reachable. Better BGP multihoming doesn't mean there is no place for multi-address multihoming. From owner-multi6@ops.ietf.org Sun Sep 9 08:05:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09091 for ; Sun, 9 Sep 2001 08:05:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15g3LY-0009xr-00 for multi6-data@psg.com; Sun, 09 Sep 2001 05:05:56 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.33 #1) id 15g3LX-0009xk-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 05:05:55 -0700 Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id f89C5mC07084 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Sun, 9 Sep 2001 08:05:49 -0400 Message-Id: <5.1.0.14.2.20010909075158.00acb670@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 09 Sep 2001 08:05:48 -0400 To: multi6@ops.ietf.org From: Daniel Senie Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <20010909094516.Q1293-100000@sequoia.muada.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 07:28 AM 9/9/01, Iljitsch van Beijnum wrote: >On Sun, 9 Sep 2001, Peter Tattam wrote: > > > At issue is a big question as to whether BGP will scale *across the whole > > network* . I haven't seen a clear informed answer to this yet. Many > of the > > studies I've seen refer only to empirical studies and analysis of the > current > > v4 network and predictions of what is likely in the next year or so. > >Even if we assume the stability of new multihomers is the same of that of >current networks, the load on the BGP route processing system will >increase faster than the number of routes because each update needs to be >done on a larger table. This means order O(x^2) if doing an update scales >in a linear way or O(x log x) if it scales logarithmically. > > > Finally I might add that I have to concede there is one fundamental > flaw in the > > host based or DNS based solutions to MH and that was eloquently pointed > out by > > someone else. DNS needs routing so routing can't depend on DNS which > means we > > can't use it as it is currently implemented, primarily because DNS is > agnostic > > towards routing conditions. > >Eloquent, but wrong. In the multi-address multihoming (MAMH) proposals >we've seen lately, there are never changes to single homed routing. So as >long as the domain name system only depends on single homed routing, there >is no problem. Also, no actual forwarding decisions depend on DNS >information, it is only used to find out addresses associated with a >hostname (or possibly with another address). This is hardly a new thing >for the DNS. > >If we're going to do MAMH, we need three things: > >1. initial address discovery: DNS already does this >2. address negotiation: mobile IP already does this >3. failover: this we don't have 4. a separate IP address prefix for each pipe from a site to the Internet, all of equal size. This point seems to be missing from the discussion. While with IPv6 we like to think of sizing as infinite, we are busy dividing that space by 2 or 3 to account for a large percentage of sites multihoming. That might be OK, or it might not. This issue also raises some concerns in terms of whether the RIRs are willing to play along. Clearly in an IPv4 world, assigning additional prefixes of equal size to a site is not going to go over well, and yet it's already an option, see below. >Not a strict requirement, but it would be very helpful to have a choice >whether the end hosts or a proxy/router/NAT-like box does the necessary >multi-address multihoming processing. There are multi-ported NAT Boxes on the market today which provide a flavor of multihoming with IPv4. This approach, with one-to-one NAT, can provide some level of service today to make a site "multihomed" in an IPv4 world. Note, however, the consumption of address space. So let's keep in mind that when we make the routing table in the DFZ small using host-based multihoming, we're having a significant effect on the amount of IP address space we're causing to be allocated. This may be a tradeoff we're willing to make. I have not seen anyone mention it in the arguments made here, which concerns me. As a community and standards body, we have not always done a good job of considering future impacts of standards promoted. > > This implies that you need a globally reachable sub system that is > independent > > of MH conditions which will then supply the MH information for any site > based > > or transport based MH solutions to function. Very likely it could borrow > > heavily from DSN, but it would need to be redesigned to be resilient to MH > > conditions which I believe DNS is not. > >In the DNS, the information for each zone is replicated over two or more >servers. Rather than making sure you can always get at a certain server, >the DNS makes sure you can always get at the information by trying servers >until a live one is found. If all TCP/IP applications (well, the DNS is >not really an "application") did this, there would be no need for >multihoming support. And it would potentially take a LONG time to get connected to a web server, mail server, etc., if there were one or more dead machines on a list. Since it takes a while to get DNS changes propagated, that could continue for some time. > > An idea springs to mind - why not have an alternative system based on BGP > > *independent* of the routing system from which reachability information > can be > > gathered. Such a BGP system would need to be extended so that whole > DFZ would > > not need to be kept in the BGP server, but rather the localized routing > needs > > of the site instead, much in the same way that a DNS server only keeps the > > localized name mapping that it requires for the sites current connections. > >In BGP, all the routers in the path need to know a route. Since that can't >be a requirement here (back to BGP scaling) we're limited to multi-address >multihoming or tunneling/rewriting schemes. > >So I would send a query along the lines of "what are all of the addresses >for a:b:c:d::1/128 and how reachable are they" to a root reachability >server. That one would probably return "a:b::1:2:3 is authorative for >a:b::/32" and assuming no more recursion a:b::1:2:3 would answer: > >"alternative prefixes for a:b:c:d::/64 are: >a:b:c:d:: min RTT: 1700 us, bandwidth 1544 kbps, reliability 100% >d:e:f:9:: min RTT: 520 ms, bandwidth 44736 kbps, reliability 99% >5:6:7:8:: min RTT: 20 ms, bandwidth 128 kbps, reliability 93% >additional information: >d:e:f:9::1/128 reliability 0%" > >meaning the site is connected over a T1, a satellite DS3 and ISDN dial-up, >and the host in question not being able to use the ISDN line at the >moment. Are the DNS servers magically in a place where THEY are better connected? Arguably with this multi-connected site, the DNS servers could appear to be on separate networks, thus well protected. However, the time to find a responsive DNS server would have to be added to the other access times. Further the TTLs on the DNS data would need to be short, to reflect the changing nature of the data that you want to present. This can and is done today for load balancing, but the downside is excess DNS traffic and latency. Again, this may be a tradeoff we're willing to make. Let's just be sure we understand its effects on the whole. >Iljitsch van Beijnum ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Sun Sep 9 08:18:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09226 for ; Sun, 9 Sep 2001 08:18:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15g3Z3-000A7i-00 for multi6-data@psg.com; Sun, 09 Sep 2001 05:19:53 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15g3Z2-000A7b-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 05:19:52 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id WAA05599; Sun, 9 Sep 2001 22:19:44 +1000 (EST) Date: Sun, 9 Sep 2001 22:19:44 +1000 (EST) From: Peter Tattam To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <20010909094516.Q1293-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 9 Sep 2001, Iljitsch van Beijnum wrote: > On Sun, 9 Sep 2001, Peter Tattam wrote: > > > Finally I might add that I have to concede there is one fundamental flaw in the > > host based or DNS based solutions to MH and that was eloquently pointed out by > > someone else. DNS needs routing so routing can't depend on DNS which means we > > can't use it as it is currently implemented, primarily because DNS is agnostic > > towards routing conditions. > > Eloquent, but wrong. In the multi-address multihoming (MAMH) proposals > we've seen lately, there are never changes to single homed routing. So as > long as the domain name system only depends on single homed routing, there > is no problem. Also, no actual forwarding decisions depend on DNS > information, it is only used to find out addresses associated with a > hostname (or possibly with another address). This is hardly a new thing > for the DNS. Umm.. There is a pathological situation where a DNS server within the site may not be accessible if that DNS server were only visible from a single address prefix. A secondary DNS might be visible at another address range but may not be for similar reasons as the primary netowrk fault. You could multi home the SOA & NS entries but it might complicate lookups - however you are implying this is not done. The site could be black holed from the DNS system if it were relying on a single homing their DNS servers, even if it were visible via other prefixes. It can be avoided by strategic placement of secondary servers, but in practice it might prove difficult. What I'm saying is that the DNS needs multihoming to work for it to be fully reliable. Do you still disagree? Show me what I'm missing here. I'll respond to the rest of your message when I've digested it. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Sun Sep 9 08:31:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09330 for ; Sun, 9 Sep 2001 08:31:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15g3l6-000AGj-00 for multi6-data@psg.com; Sun, 09 Sep 2001 05:32:20 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.33 #1) id 15g3l5-000AGb-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 05:32:19 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id WAA08227; Sun, 9 Sep 2001 22:32:13 +1000 (EST) Date: Sun, 9 Sep 2001 22:32:12 +1000 (EST) From: Peter Tattam To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <20010909094516.Q1293-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 9 Sep 2001, Iljitsch van Beijnum wrote: > In the DNS, the information for each zone is replicated over two or more > servers. Rather than making sure you can always get at a certain server, > the DNS makes sure you can always get at the information by trying servers > until a live one is found. If all TCP/IP applications (well, the DNS is > not really an "application") did this, there would be no need for > multihoming support. > My other message addresses this. I'd like to add that I'm not sure I agree with you that this is adequate. Also, because I believe that DNS is agnostic towards routing, in practice if I assume you would MH SOA & NS entries, you might find DNS lookups slow down if random NS entries were used to locate DNS information if one MH path was less optimal than another. You might not get black holed, but DNS resolution for the site would end up being degraded in the presence of multihoming. Can you see my reasoning? For DNS to be efficient or even work at all, it has to be MH aware to do its job. It's circular and hence I believe there is a problem. There is a circular issue in the current DNS system, but we resolve it through the use of geographically distinct secondary servers and gluing in the delegation via a fixed IP address. This works because the routing system always provides a path to the backup server in the instance that the primary DNS is down. I'm not so sure it will be so simple in a multi prefix environment. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Sun Sep 9 10:03:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10546 for ; Sun, 9 Sep 2001 10:03:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15g5Aa-000BBZ-00 for multi6-data@psg.com; Sun, 09 Sep 2001 07:02:44 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15g5AZ-000BBT-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 07:02:43 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f89E3sG01659; Sun, 9 Sep 2001 16:03:54 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 9 Sep 2001 16:03:54 +0200 (CEST) From: Iljitsch van Beijnum To: Peter Tattam cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: Message-ID: <20010909154227.L1293-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 9 Sep 2001, Peter Tattam wrote: > Umm.. There is a pathological situation where a DNS server within the site may > not be accessible if that DNS server were only visible from a single address > prefix. A secondary DNS might be visible at another address range but may not > be for similar reasons as the primary netowrk fault. This happens without multihoming too. The primary and secondary servers should not both go down when there is a network problem. > You could multi home the > SOA & NS entries but it might complicate lookups - however you are implying > this is not done. I would just give the name server in a MAMH network two addresses, and list both addresses in the delegating zone. That way, name service for a dual-homed network with two name servers would be available from four addresses. When an address is unreachable queries to that address will time out and have to be tried again at another address. This adds a delay to the process, which is not good but not so big a problem that we have to attach any consequences to it, IMO. > The site could be black holed from the DNS system if it were > relying on a single homing their DNS servers, even if it were visible via other > prefixes. It can be avoided by strategic placement of secondary servers, but > in practice it might prove difficult. Today, it is possible to multihome a server without any changes to any protocol. This means giving the server addresses from ISP A and from ISP B. This works. The problem is: what happens when one of them is down? This problem can be fixed by trying different addresses until you find one that works. Telnet does this, BIND does this. Another problem is: when something goes down in the middle of a session, what do you do? This is not a problem for the DNS, since it mostly uses single request/reply transactions over UDP without keeping sessions active and it retries everything so even with TCP it works out in the end. What we're trying to do is not make multiple-address multihoming as such possible: it already is. What we want is mechanisms to hide IP and lower layer failures from the transport layer. Iljitsch From owner-multi6@ops.ietf.org Sun Sep 9 10:14:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10629 for ; Sun, 9 Sep 2001 10:14:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15g5MK-000BJK-00 for multi6-data@psg.com; Sun, 09 Sep 2001 07:14:52 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15g5MJ-000BJE-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 07:14:51 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f89EG1a01676; Sun, 9 Sep 2001 16:16:01 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 9 Sep 2001 16:16:01 +0200 (CEST) From: Iljitsch van Beijnum To: Peter Tattam cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: Message-ID: <20010909160426.O1293-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 9 Sep 2001, Peter Tattam wrote: > Also, because I believe that DNS is agnostic > towards routing, in practice if I assume you would MH SOA & NS entries, you > might find DNS lookups slow down if random NS entries were used to locate DNS > information if one MH path was less optimal than another. You might not get > black holed, but DNS resolution for the site would end up being degraded in the > presence of multihoming. For a single query this might be a problem. But unless I'm mistaken, BIND takes note of the round trip times it sees and (mostly) prefers the faster address over the slower one on subsequent queries. From owner-multi6@ops.ietf.org Sun Sep 9 10:36:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10881 for ; Sun, 9 Sep 2001 10:36:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15g5iE-000Ba5-00 for multi6-data@psg.com; Sun, 09 Sep 2001 07:37:30 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.33 #1) id 15g5iD-000BZz-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 07:37:30 -0700 Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id f89EbSC10395 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Sun, 9 Sep 2001 10:37:28 -0400 Message-Id: <5.1.0.14.2.20010909103341.04550060@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 09 Sep 2001 10:37:28 -0400 To: multi6@ops.ietf.org From: Daniel Senie Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <20010909160426.O1293-100000@sequoia.muada.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 10:16 AM 9/9/01, Iljitsch van Beijnum wrote: >On Sun, 9 Sep 2001, Peter Tattam wrote: > > > Also, because I believe that DNS is agnostic > > towards routing, in practice if I assume you would MH SOA & NS entries, you > > might find DNS lookups slow down if random NS entries were used to > locate DNS > > information if one MH path was less optimal than another. You might > not get > > black holed, but DNS resolution for the site would end up being > degraded in the > > presence of multihoming. > >For a single query this might be a problem. But unless I'm mistaken, BIND >takes note of the round trip times it sees and (mostly) prefers the faster >address over the slower one on subsequent queries. Be a bit careful here, or you fall into a trap that some of the DNS load balancer vendors fall into. You care about the distance/latency between the RESOLVER and the target machine, NOT between the RESOLVER's Name Server and the target's name server. Several load balancer products ensure the latter case is not a problem, however, they do not address the issue of proximity of the name server doing the lookup on behalf of the user/service/whatever. The recursive name servers used when making requests are NOT required to be topologically close to the machine requesting the lookup. I bring this up just so we don't go down any paths that could lead to bad assumptions about DNS resolution as a cure-all. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Sun Sep 9 10:39:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10901 for ; Sun, 9 Sep 2001 10:39:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15g5kz-000BcF-00 for multi6-data@psg.com; Sun, 09 Sep 2001 07:40:21 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15g5ky-000Bc7-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 07:40:20 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f89EfXk01716; Sun, 9 Sep 2001 16:41:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 9 Sep 2001 16:41:33 +0200 (CEST) From: Iljitsch van Beijnum To: Daniel Senie cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <5.1.0.14.2.20010909075158.00acb670@mail.amaranth.net> Message-ID: <20010909161605.E1293-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 9 Sep 2001, Daniel Senie wrote: > >If we're going to do MAMH, we need three things: > >1. initial address discovery: DNS already does this > >2. address negotiation: mobile IP already does this > >3. failover: this we don't have Hm, I might have another one: sending traffic with a source address from ISP A over a link to ISP B can be a problem. > 4. a separate IP address prefix for each pipe from a site to the Internet, > all of equal size. > This point seems to be missing from the discussion. While with IPv6 we like > to think of sizing as infinite, we are busy dividing that space by 2 or 3 > to account for a large percentage of sites multihoming. That might be OK, > or it might not. That's one or two bits out of 128. Considering that 16 bits are wasted in the IEEE -> EUI-64 conversion, I don't see the problem in IPv6. In IPv4, things are different, of course. Still, a single host could have several addresses if this serves an important function, I think. > This issue also raises some concerns in terms of whether the RIRs are > willing to play along. They might not like all of this, but for the opposite reason: when just a hand full of ISPs need address space and AS numbers, that means less work for them. > Clearly in an IPv4 world, assigning additional prefixes of equal size to a > site is not going to go over well, Agree. > >Not a strict requirement, but it would be very helpful to have a choice > >whether the end hosts or a proxy/router/NAT-like box does the necessary > >multi-address multihoming processing. > There are multi-ported NAT Boxes on the market today which provide a flavor > of multihoming with IPv4. This approach, with one-to-one NAT, can provide > some level of service today to make a site "multihomed" in an IPv4 world. > Note, however, the consumption of address space. Aren't current sessions still lost with current NAT? > This may be a tradeoff we're willing to make. I have not seen anyone > mention it in the arguments made here, which concerns me. As a community > and standards body, we have not always done a good job of considering > future impacts of standards promoted. You are right, we should pay attention to this. Michel Py talks about this in section 6.2.4 of his draft. > Are the DNS servers magically in a place where THEY are better connected? > Arguably with this multi-connected site, the DNS servers could appear to be > on separate networks, thus well protected. However, the time to find a > responsive DNS server would have to be added to the other access times. That would be a good reason to incorporate this in the current DNS, since we already have to wait for the name to address translation. If the other information is then returned as well, this would save time. > Further the TTLs on the DNS data would need to be short, to reflect the > changing nature of the data that you want to present. I do not propose to store data that needs to be changed often in the DNS. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Sun Sep 9 10:56:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10995 for ; Sun, 9 Sep 2001 10:56:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15g61I-000BoM-00 for multi6-data@psg.com; Sun, 09 Sep 2001 07:57:12 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.33 #1) id 15g61I-000BoG-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 07:57:12 -0700 Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id f89EvAC10880 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Sun, 9 Sep 2001 10:57:10 -0400 Message-Id: <5.1.0.14.2.20010909104343.0394f330@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 09 Sep 2001 10:57:10 -0400 To: multi6@ops.ietf.org From: Daniel Senie Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <20010909161605.E1293-100000@sequoia.muada.com> References: <5.1.0.14.2.20010909075158.00acb670@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 10:41 AM 9/9/01, Iljitsch van Beijnum wrote: >On Sun, 9 Sep 2001, Daniel Senie wrote: > > > >If we're going to do MAMH, we need three things: > > > >1. initial address discovery: DNS already does this > > >2. address negotiation: mobile IP already does this > > >3. failover: this we don't have > >Hm, I might have another one: sending traffic with a source address from >ISP A over a link to ISP B can be a problem. Especially if folks are doing ingress filtering. Proper address selection (and figuring out how to decide) is the hardest part of this to do in hosts, unless the hosts have a lot of information pushed to them. > > 4. a separate IP address prefix for each pipe from a site to the Internet, > > all of equal size. > > > This point seems to be missing from the discussion. While with IPv6 we like > > to think of sizing as infinite, we are busy dividing that space by 2 or 3 > > to account for a large percentage of sites multihoming. That might be OK, > > or it might not. > >That's one or two bits out of 128. Considering that 16 bits are wasted in >the IEEE -> EUI-64 conversion, I don't see the problem in IPv6. Though the use of MAC address is now an optional thing, due to privacy concerns. Yes, there's a large block of addresses. The concern is that we not give away too many bits for one thing or another. We also have the issue that all providers to a site will need to supply prefixes that essentially match (i.e. same sizes from each, so that things overlay cleanly). The RIRs would need to adjust their policies to permit this. >In IPv4, things are different, of course. Still, a single host could have >several addresses if this serves an important function, I think. It does, but would 2 or 3 different upstreams each provide a block of addresses large enough for a web server farm? At what point is the consumption of addresses considered more expensive than handing the site an AS number, and allowing them to advertise their blocks? > > This issue also raises some concerns in terms of whether the RIRs are > > willing to play along. > >They might not like all of this, but for the opposite reason: when just a >hand full of ISPs need address space and AS numbers, that means less work >for them. > > > Clearly in an IPv4 world, assigning additional prefixes of equal size to a > > site is not going to go over well, > >Agree. > > > >Not a strict requirement, but it would be very helpful to have a choice > > >whether the end hosts or a proxy/router/NAT-like box does the necessary > > >multi-address multihoming processing. > > > There are multi-ported NAT Boxes on the market today which provide a flavor > > of multihoming with IPv4. This approach, with one-to-one NAT, can provide > > some level of service today to make a site "multihomed" in an IPv4 world. > > Note, however, the consumption of address space. > >Aren't current sessions still lost with current NAT? With a Multi-homed NAT solution, it's possible to have sessions load balanced, as the box doing the NAT is a router connected to all possible exits. The box can decide which link to connect out on, and thus outbound connections are cleanly load balanced (and the returning packets for those links will follow the same path back in). For inbound traffic to a site, load balancers (e.g. DNS tricks and such) permit balancing between the various links. The two functions can be handled by the same equipment, so that line utilization can be managed for each link. One of my concerns is that these boxes (available today) will look more attractive to many people than a migration to IPv6. Indeed, if a site can get multiple providers to supply enough address space, then for many cases this is an efficient and cost-effective way to get into multihoming. Certainly such boxes could be made to play in the IPv6 space as well, or do 6to4 in the course of their work. > > This may be a tradeoff we're willing to make. I have not seen anyone > > mention it in the arguments made here, which concerns me. As a community > > and standards body, we have not always done a good job of considering > > future impacts of standards promoted. > >You are right, we should pay attention to this. Michel Py talks about this >in section 6.2.4 of his draft. > > > Are the DNS servers magically in a place where THEY are better connected? > > Arguably with this multi-connected site, the DNS servers could appear to be > > on separate networks, thus well protected. However, the time to find a > > responsive DNS server would have to be added to the other access times. > >That would be a good reason to incorporate this in the current DNS, since >we already have to wait for the name to address translation. If the other >information is then returned as well, this would save time. Other than packet size limitations with DNS over UDP, or overhead if everything spills over to TCP. > > Further the TTLs on the DNS data would need to be short, to reflect the > > changing nature of the data that you want to present. > >I do not propose to store data that needs to be changed often in the DNS. Unfortunately, one of the things this type of multihoming lends itself to is load balancing manipulation. By altering the order of the addresses in responses (i.e. doing something other than round robin) is a pretty effective way of altering balancing. Setting TTLs very low makes this possible. If we go down this path, people WILL be setting their TTLs very low. Some will argue for ignoring the TTLs and caching longer, but that'll create significant problems for many applications, and likely increase support costs in the long run. >Iljitsch van Beijnum ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Sun Sep 9 13:09:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11765 for ; Sun, 9 Sep 2001 13:09:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15g85f-000DCK-00 for multi6-data@psg.com; Sun, 09 Sep 2001 10:09:51 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15g85e-000DCE-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 10:09:50 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f89HB4r01847; Sun, 9 Sep 2001 19:11:04 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 9 Sep 2001 19:11:04 +0200 (CEST) From: Iljitsch van Beijnum To: Daniel Senie cc: Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <5.1.0.14.2.20010909104343.0394f330@mail.amaranth.net> Message-ID: <20010909182856.O1293-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 9 Sep 2001, Daniel Senie wrote: > >That's one or two bits out of 128. Considering that 16 bits are wasted in > >the IEEE -> EUI-64 conversion, I don't see the problem in IPv6. > Though the use of MAC address is now an optional thing, due to privacy > concerns. Yes, there's a large block of addresses. The concern is that we > not give away too many bits for one thing or another. We also have the > issue that all providers to a site will need to supply prefixes that > essentially match (i.e. same sizes from each, so that things overlay > cleanly). The RIRs would need to adjust their policies to permit this. I haven't followed the latest developments, but I think the plan is to give each organization its own /48 and each network, however small (even a dial-up user) its own /64. So the blocks are always the same size, that helps. Don't underestimate the huge address space of IPv6: even if you're multihoming within each TLA (costing 16 bits) with a /48 there is room for 4 billion multihomers. > >In IPv4, things are different, of course. Still, a single host could have > >several addresses if this serves an important function, I think. > It does, but would 2 or 3 different upstreams each provide a block of > addresses large enough for a web server farm? At what point is the > consumption of addresses considered more expensive than handing the site an > AS number, and allowing them to advertise their blocks? As it is now, you can only be sure that you won't be filtered with a /20. That means 1300 triple-homed web servers... [Load balancing with NAT] > One of my concerns is that these boxes (available today) will look more > attractive to many people than a migration to IPv6. Indeed, if a site can > get multiple providers to supply enough address space, then for many cases > this is an efficient and cost-effective way to get into multihoming. > Certainly such boxes could be made to play in the IPv6 space as well, or do > 6to4 in the course of their work. Essentially you're just making renumbering easier with these boxes: they don't help much when a line goes down. I wouldn't call this multihoming. I'm certainly not a big fan of NAT, but it does help preserve address space in IPv4. Load balancing using NAT is an even bigger hack that regular NAT and has little to do with multihoming: you're trying to balance the load over the servers, not over the lines. > >I do not propose to store data that needs to be changed often in the DNS. > Unfortunately, one of the things this type of multihoming lends itself to > is load balancing manipulation. By altering the order of the addresses in > responses (i.e. doing something other than round robin) is a pretty > effective way of altering balancing. Setting TTLs very low makes this > possible. If we go down this path, people WILL be setting their TTLs very > low. If we depend on the DNS to only deliver the "best" address. What I propose is that we use the DNS to deliver all addresses and find out which ones work and which don't separately. This way, there is no harm in keeping a broken address in the DNS and the TTL doesn't have to be especially low. But even if people use low TTLs for things like load balancing, that's not necessarily evil. Only the A records for the server in question need to have a low TTL, the rest of DNS tree can have a regular TTL. This means the resolving name server can directly contact the destination name server, so only the endpoints experience the higher load. Presumably, the resources needed for a single DNS query/reply will be dwarfed by the subsequent "real" communication that takes place. > Some will argue for ignoring the TTLs and caching longer, but that'll > create significant problems for many applications, and likely increase > support costs in the long run. I don't see the problem... Why would a low TTL for "leaf" records be such a big problem that people will want to break protocols? Obviously we want high TTLs for NS records and such. From another message: > Be a bit careful here, or you fall into a trap that some of the DNS load > balancer vendors fall into. You care about the distance/latency between > the RESOLVER and the target machine, NOT between the RESOLVER's Name Server > and the target's name server. Several load balancer products ensure the > latter case is not a problem, however, they do not address the issue of > proximity of the name server doing the lookup on behalf of the > user/service/whatever. By resolver you mean the resolver library on the host that wants to set up a session? The latency between a host and the caching name server it uses must be as small as possible, since applications such as WWW need to get at the caching name server a lot, and usually the user is waiting during that time. Also, in many cases this information is not cached locally, so the same information may be requested many times. > The recursive name servers used when making requests are NOT required to > be topologically close to the machine requesting the lookup. They are in my book. :-) > I bring this up just so we don't go down any paths that could lead to > bad assumptions about DNS resolution as a cure-all. Yes, we should be careful with the domain name system. On the other hand, we don't want to prematurely close off paths that could lead to the multihoming walhalla... Iljitsch From owner-multi6@ops.ietf.org Sun Sep 9 14:50:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12419 for ; Sun, 9 Sep 2001 14:50:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15g9ey-000EDw-00 for multi6-data@psg.com; Sun, 09 Sep 2001 11:50:24 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.33 #1) id 15g9ey-000EDp-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 11:50:24 -0700 Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id f89IoMC17141 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Sun, 9 Sep 2001 14:50:22 -0400 Message-Id: <5.1.0.14.2.20010909143605.0452d180@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 09 Sep 2001 14:50:21 -0400 To: multi6@ops.ietf.org From: Daniel Senie Subject: Re: A new spin on multihoming: multihoming classes. In-Reply-To: <20010909182856.O1293-100000@sequoia.muada.com> References: <5.1.0.14.2.20010909104343.0394f330@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 01:11 PM 9/9/01, Iljitsch van Beijnum wrote: >On Sun, 9 Sep 2001, Daniel Senie wrote: > > > >That's one or two bits out of 128. Considering that 16 bits are wasted in > > >the IEEE -> EUI-64 conversion, I don't see the problem in IPv6. > > > Though the use of MAC address is now an optional thing, due to privacy > > concerns. Yes, there's a large block of addresses. The concern is that we > > not give away too many bits for one thing or another. We also have the > > issue that all providers to a site will need to supply prefixes that > > essentially match (i.e. same sizes from each, so that things overlay > > cleanly). The RIRs would need to adjust their policies to permit this. > >I haven't followed the latest developments, but I think the plan is to >give each organization its own /48 and each network, however small (even a >dial-up user) its own /64. So the blocks are always the same size, that >helps. Don't underestimate the huge address space of IPv6: even if you're >multihoming within each TLA (costing 16 bits) with a /48 there is room for >4 billion multihomers. > > > >In IPv4, things are different, of course. Still, a single host could have > > >several addresses if this serves an important function, I think. > > > It does, but would 2 or 3 different upstreams each provide a block of > > addresses large enough for a web server farm? At what point is the > > consumption of addresses considered more expensive than handing the site an > > AS number, and allowing them to advertise their blocks? > >As it is now, you can only be sure that you won't be filtered with a /20. >That means 1300 triple-homed web servers... No, you misunderstand. With a multi-port NAT setup, you use ISP-provided space from each provider. There's no BGP, no ASN, no advertisements, and no filtering, 'cause you're within someone's large block on each of the links. >[Load balancing with NAT] > > > One of my concerns is that these boxes (available today) will look more > > attractive to many people than a migration to IPv6. Indeed, if a site can > > get multiple providers to supply enough address space, then for many cases > > this is an efficient and cost-effective way to get into multihoming. > > Certainly such boxes could be made to play in the IPv6 space as well, or do > > 6to4 in the course of their work. > >Essentially you're just making renumbering easier with these boxes: they >don't help much when a line goes down. I wouldn't call this multihoming. Wrong. These boxes work QUITE WELL in the event of a line outage. Outbound connections from the site which were in progress over the dead link obviously die, but new connections will go only over the functioning links. With reasonable DNS-based load balancing and short TTLs, the inbound connectivity will be relatively unaffected as well. >I'm certainly not a big fan of NAT, but it does help preserve address >space in IPv4. Load balancing using NAT is an even bigger hack that >regular NAT and has little to do with multihoming: you're trying to >balance the load over the servers, not over the lines. I'm not a big fan of NAT either, despite having implemented it and done a fair bit of writing about it, but it CAN be useful, and this "multihoming" approach using NAT is fairly workable. Products are on the market which do this already. > > >I do not propose to store data that needs to be changed often in the DNS. > > > Unfortunately, one of the things this type of multihoming lends itself to > > is load balancing manipulation. By altering the order of the addresses in > > responses (i.e. doing something other than round robin) is a pretty > > effective way of altering balancing. Setting TTLs very low makes this > > possible. If we go down this path, people WILL be setting their TTLs very > > low. > >If we depend on the DNS to only deliver the "best" address. What I propose >is that we use the DNS to deliver all addresses and find out which ones >work and which don't separately. This way, there is no harm in keeping a >broken address in the DNS and the TTL doesn't have to be especially low. Ah, but if you give out more than one address, but specifically manipulate the order of the entries given out, and keep the TTLs low, it's possible to get a degree of load balancing at the same time. >But even if people use low TTLs for things like load balancing, that's not >necessarily evil. Only the A records for the server in question need to >have a low TTL, the rest of DNS tree can have a regular TTL. This means >the resolving name server can directly contact the destination name >server, so only the endpoints experience the higher load. Presumably, the >resources needed for a single DNS query/reply will be dwarfed by the >subsequent "real" communication that takes place. Assuming the DNS and the actual traffic are going in the same neighborhood, which admittedly is the most common case. > > Some will argue for ignoring the TTLs and caching longer, but that'll > > create significant problems for many applications, and likely increase > > support costs in the long run. > >I don't see the problem... Why would a low TTL for "leaf" records be such >a big problem that people will want to break protocols? Obviously we want >high TTLs for NS records and such. Agree, people shouldn't do these things, but some appear to. Some applications cache DNS data, for example, which is a concern. Such caching should be limited to the timeouts specified, but will applications bother? A better resolver API would probably be a good thing. > >From another message: > > > Be a bit careful here, or you fall into a trap that some of the DNS load > > balancer vendors fall into. You care about the distance/latency between > > the RESOLVER and the target machine, NOT between the RESOLVER's Name Server > > and the target's name server. Several load balancer products ensure the > > latter case is not a problem, however, they do not address the issue of > > proximity of the name server doing the lookup on behalf of the > > user/service/whatever. > >By resolver you mean the resolver library on the host that wants to set up >a session? Yes. >The latency between a host and the caching name server it uses must be as >small as possible, since applications such as WWW need to get at the >caching name server a lot, and usually the user is waiting during that >time. Also, in many cases this information is not cached locally, so the >same information may be requested many times. Web browsers cache DNS info for at least short periods. If they didn't browsing over a dialup would probably be painfully slow. There are instances where they'll be far away. While having the name server close speeds things up for the user or server making the request, having that topological closeness ALSO be used to try to determine best site for load balancing and other such games is a concern. > > The recursive name servers used when making requests are NOT required to > > be topologically close to the machine requesting the lookup. > >They are in my book. :-) Hope you don't have to use VPNs much. That's one of several cases where the name servers can wind up being VERY far away. > > I bring this up just so we don't go down any paths that could lead to > > bad assumptions about DNS resolution as a cure-all. > >Yes, we should be careful with the domain name system. On the other hand, >we don't want to prematurely close off paths that could lead to the >multihoming walhalla... My concern is that we don't choose paths prematurely that may result in other troubles. DNS has been our kitchen sink for a long time, and while it's done well, some of the ways it's being used are problematic, and the situation could get worse. Let's consider these approaches but be careful. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Sun Sep 9 15:58:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13005 for ; Sun, 9 Sep 2001 15:58:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15gAit-000EsT-00 for multi6-data@psg.com; Sun, 09 Sep 2001 12:58:31 -0700 Received: from web13502.mail.yahoo.com ([216.136.175.81]) by psg.com with smtp (Exim 3.33 #1) id 15gAis-000EsN-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 12:58:30 -0700 Message-ID: <20010909195830.54388.qmail@web13502.mail.yahoo.com> Received: from [63.101.96.1] by web13502.mail.yahoo.com via HTTP; Sun, 09 Sep 2001 12:58:30 PDT Date: Sun, 9 Sep 2001 12:58:30 -0700 (PDT) From: Michel Py Subject: If IPv6 multihomed sites were cars To: multi6@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk As the author of the original post (was: A new spin on multihoming: multihoming classes), and given what I have read here recently, I thought I neeeded to post this: If IPv6 multihomed sites were cars: Some people have posted drafts describing a a 3-ton truck. They have been told "this design is not good, we need a sports car". Some people have posted drafts describing a sports car. They have been told "this design is not good, we need a truck". Some poeple have said "It is pointless designing a Mercedes, I can't afford it". Some other people have said "Don't buy a Yugo, it's a piece of junk". A few facts of life: A small truck and a sports car cost about the same, $50,000. They both have an engine, 4 wheels and a steering wheel. They are very different though, because they are not used for the same thing. A $2,000 Yugo is inexpensive, but a $200,000 Mercedes is a lot nicer and more reliable. On the same road, you can see trucks, sports cars, Mercedes', and Yugos. This specialization applies to almost technology item. Let's look at airplanes: A Boeing 737 and an F-15 Eagle cost about the same ($35M). They both have wings, 2 jet engines and a retractable landing gear. They are very different though, because they are not used for the same thing. A $100,000 Cessna is inexpensive, but a $10M Learjet is a lot nicer and faster. In the same airspace, you can spot jetliners, combat aircraft, single prop airplanes, and personal jets. Computers: A nice color PDA and a standard desktop PC cost about the same, $600. They both have a screen, an operating system, and a USB interface. They are very different though, because they are not used for the same thing. A $400 stripped-down Celeron with IDE, 64 megs and Win Me is inexpensive, but a $5,000, dual P4, 15KRPM SCSI drives raid array, 21" screen is a lot nicer and it makes a hell of a game machine, too. On the Internet, you can find any kind of computer there is. More facts of life: - Some people don't have a car. Some drive a truck. Some drive a sports car, some drive a Mercedes. - Some people have never flown in an airplaine. In the same jetliner, you find the pilot, who gets paid to fly, and the guy in first that paid twice as much as the one in coach for a few more inches of leg space. - Some don't have a computer, some have a basic one, and some have a big honkin' setup. - Some people won't have a multihomed IPv6 setup, some people will have a $49.95/mo multihomed IPv6 setup, and some people will have a $50K/mo setup. I don't think the $49.95/mo will be as nice as the $50k/mo. - The car that can carry 3 tons of cargo, accelerates like a Ferrari, is luxurious like a Mercedes, gives you 40 miles/gallon, can fit in a standard garage and costs $5,000 does not exist. - The airplane that can carry 400 passengers for 10,000 miles at mach 2.3, can land on 1,500 ft of runway and costs $100,000 does not exist. - The computer that has 1 gig of ram, 1 terabyte of hot-swap raid storage, quad 2ghz processors, fits in a shirt pocket and cost $500 does not exist. - The IPv6 multihoming solution that can host amazon.com, work over a 64k dialback ISDN, does not care about BGP nor the DFZ, can be configured by grandma and costs $49.95 a month does not exist. Michel. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Sun Sep 9 19:59:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15324 for ; Sun, 9 Sep 2001 19:59:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15gESI-000HNg-00 for multi6-data@psg.com; Sun, 09 Sep 2001 16:57:38 -0700 Received: from web13507.mail.yahoo.com ([216.136.175.86]) by psg.com with smtp (Exim 3.33 #1) id 15gESH-000HNa-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 16:57:37 -0700 Message-ID: <20010909235737.77254.qmail@web13507.mail.yahoo.com> Received: from [63.101.96.1] by web13507.mail.yahoo.com via HTTP; Sun, 09 Sep 2001 16:57:37 PDT Date: Sun, 9 Sep 2001 16:57:37 -0700 (PDT) From: Michel Py Subject: Re: A new spin on multihoming: multihoming classes. To: Daniel Senie , multi6@ops.ietf.org In-Reply-To: <5.1.0.14.2.20010909104343.0394f330@mail.amaranth.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Daniel - >> Hm, I might have another one: sending traffic with >> a source address from ISP A over a link to ISP B >> can be a problem. There is a MAMH version of MHTP that is exactly what you and Ilsitch are talking about (NAT based, initial resolution based on DNS and it does have failover, too). I discarded it for two reasons: it uses DNS and what you mention just above. The idea is technically workable as long as you accept that the system is far from being perfect, but it has not a single chance of political acceptance. >> There are multi-ported NAT Boxes on the market >> today which provide a flavor of multihoming with >> IPv4. This approach, with one-to-one NAT, can >> provide some level of service today to make a site >> "multihomed" in an IPv4 world. You can configure it with a Cisco router using reflexive access-lists, but the load balancing implies a hack on the DNS server. >> One of my concerns is that these boxes (available >> today) will look more attractive to many people >> than a migration to IPv6. This is not the place to discuss it, and it remains to be seen. I can tell you quite frankly that I am familiar with that configuration and that it would easily integrate with MHTP and I have decided not to make a fool of myself by waiting to see if it pumps up speed in the IPv4 world first. If it does, I'll publish it. Michel From owner-multi6@ops.ietf.org Sun Sep 9 20:05:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15427 for ; Sun, 9 Sep 2001 20:05:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15gEb1-000HTe-00 for multi6-data@psg.com; Sun, 09 Sep 2001 17:06:39 -0700 Received: from web13501.mail.yahoo.com ([216.136.175.80]) by psg.com with smtp (Exim 3.33 #1) id 15gEb0-000HTX-00 for multi6@ops.ietf.org; Sun, 09 Sep 2001 17:06:38 -0700 Message-ID: <20010910000638.39141.qmail@web13501.mail.yahoo.com> Received: from [63.101.96.1] by web13501.mail.yahoo.com via HTTP; Sun, 09 Sep 2001 17:06:38 PDT Date: Sun, 9 Sep 2001 17:06:38 -0700 (PDT) From: Michel Py Subject: Re: Distributed reachability information To: Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: <20010908193134.O5044-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Ilsitch - >> Another would be to abuse RIP for this. I haven't >> really looked in to this, but RIP does a lot of >> the same things in a somewhat different manner, >> so it could be a good starting point. [view in courier font] This is what RIP is about. _____ _____ < `/ | > ( | _ _ | | |_) | |_) | | | \ | | | | | ______.______%_| |__________ _____ _/ \| | | Ilsitch's multihomed setup < |_____.-._________ ____/|___________| | | | | | | | | | _ < |__/ | / `--. | %| |% |/.%%| -< @%%% `\%`@| v |@@%@%% - mfj .%%%@@@|% | % @@@%%@%%%% _.%%%%%%@@@@@@%%_/%\_%@@%%@@@@@@@%%%%%% Michel. __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Mon Sep 10 08:27:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12183 for ; Mon, 10 Sep 2001 08:27:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15gQ9W-0001Dg-00 for multi6-data@psg.com; Mon, 10 Sep 2001 05:27:02 -0700 Received: from [194.78.143.90] (helo=hrtades9.atea.be) by psg.com with esmtp (Exim 3.33 #1) id 15gQ9U-0001DG-00 for multi6@ops.ietf.org; Mon, 10 Sep 2001 05:27:02 -0700 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SF8JYP93; Mon, 10 Sep 2001 14:27:06 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Sep 2001 14:26:37 +0200 Message-ID: From: Coene Lode To: "'tsvwg@ietf.org'" , "'multi6@ops.ietf.org'" Subject: multihoming issues via SCTP Date: Mon, 10 Sep 2001 14:26:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-multi6@ops.ietf.org Precedence: bulk Folks, Recently, the following draft was released: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multihoming issues in the Stream Control Transmission Protocol Author(s) : L. Coene et al. Filename : draft-coene-sctp-multihome-00.txt Pages : Date : 31-Aug-01 This document describes issues of the Stream Control Transmission Protocol (SCTP)[RFC2960] in regard to multihoming on the Internet. It explores cases where through situations in the internet, single points-of-failure can occur even when using multihoming and what the impact is of multihoming on the host routing tables. A URL for this Internet-Draft is: We ar not quite sure where the home of this draft is(which WG it belongs to) but the ultimate goal for this draft is to identify and find solution(s) for the issues described in the draft. Once that is done, then this draft will expire. I would much apperciate if you have suggestions concerning: - does it belong in these WG's(presently I have send it to the TSV WG(=home of SCTP now) and to the multi6 WG) or in another WG. - Are there errors in it? - Are there things omitted that should be in. - should some stuff be taken out. - any other suggestion. You can send them to me(Lode.coene@siemens.atea.be) or can be discussed on the mailing list. yours sincerly, Lode Coene Siemens atea ICN D CS D Software development Atealaan 34 B-2200 Herentals Belgium Tel: +32-14-2-52081 Fax: +32-14-2-53212 E-mail: lode.coene@siemens.atea.be From owner-multi6@ops.ietf.org Mon Sep 10 11:18:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18018 for ; Mon, 10 Sep 2001 11:18:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15gSnN-0003GG-00 for multi6-data@psg.com; Mon, 10 Sep 2001 08:16:21 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15gSnL-0003G7-00 for multi6@ops.ietf.org; Mon, 10 Sep 2001 08:16:20 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f8AFHCk03626; Mon, 10 Sep 2001 17:17:12 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 10 Sep 2001 17:17:12 +0200 (CEST) From: Iljitsch van Beijnum To: Coene Lode cc: "'tsvwg@ietf.org'" , "'multi6@ops.ietf.org'" Subject: Re: multihoming issues via SCTP In-Reply-To: Message-ID: <20010910164526.F3400-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 10 Sep 2001, Coene Lode wrote: > This document describes issues of the Stream Control Transmission > Protocol (SCTP)[RFC2960] in regard to multihoming on the Internet. It > explores cases where through situations in the internet, single > points-of-failure can occur even when using multihoming and what the > impact is of multihoming on the host routing tables. The main problem is the idea of paths from an interface on one host to an interface on another host. This could work if the hosts are both connected to two networks that are not interconnected, but not on anything resembling the Internet. For instance, consider host A having interface 1 connected to ISP X and interface 2 to ISP Y. By coincidence host B it is communicating with, is connected to the same ISPs, but the other way around: interface 1 to Y and interface 2 to X. So now host A tries to connect to host B over interface 1, ISP X, ISP Y and interface 1 of host B (A1->X->Y-B1) and also A2->Y->X->B2. This should work just fine, although two ISPs instead of one in each path may not give the best possible performance. But now there are three ways in which the connection can fail: either of the ISPs may fail, or the connection between them. This means there have to be more paths: A1->X->Y->B1 A1->X->B2 A2->Y->B1 A2->Y->X->B2 However, this assumes both that the output interface stays the same over the life time of a connection and that the end host is the one making the decision how packets are routed to the outside. Both are unlikely. If an output interface fails, hosts may simply reroute outgoing packets over the other interface. And in most cases, routers will reroute packets over another path if a connection to an ISP fails. So the other side will often still see incoming traffic from a remote address that is no longer reachable for outgoing packets. Also, I don't like the idea of a protocol sending keepalives over a path it is otherwise not using. This is a waste of resources and can trigger inefficient use of different kinds of caches. Also, it won't do much good unless there are three or more paths of which at least two fail, a situation that is not likely to be very common. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Sep 10 15:20:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27831 for ; Mon, 10 Sep 2001 15:20:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15gWZS-0006hc-00 for multi6-data@psg.com; Mon, 10 Sep 2001 12:18:14 -0700 Received: from lox.sandelman.ottawa.on.ca ([192.139.46.2]) by psg.com with esmtp (Exim 3.33 #1) id 15gWZR-0006hW-00 for multi6@ops.ietf.org; Mon, 10 Sep 2001 12:18:13 -0700 Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id PAA24961 for ; Mon, 10 Sep 2001 15:18:12 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca ([3ffe:1ce1:0:fe50:204:76ff:fe2d:8c]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f8AJItG11358 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 10 Sep 2001 15:18:57 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f8AJHtL04818 for ; Mon, 10 Sep 2001 15:17:55 -0400 (EDT) Message-Id: <200109101917.f8AJHtL04818@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: If IPv6 multihomed sites were cars In-reply-to: Your message of "Sun, 09 Sep 2001 12:58:30 PDT." <20010909195830.54388.qmail@web13502.mail.yahoo.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 10 Sep 2001 15:17:54 -0400 From: Michael Richardson Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Michel" == Michel Py writes: Michel> A few facts of life: A small truck and a sports car Michel> cost about the same, $50,000. They both have an Michel> engine, 4 wheels and a steering wheel. They are very Michel> different though, because they are not used for the Michel> same thing. A $2,000 Yugo is inexpensive, but a Michel> $200,000 Mercedes is a lot nicer and more reliable. On Michel> the same road, you can see trucks, sports cars, Michel> Mercedes', and Yugos. Michel> This specialization applies to almost technology item. I guess I fail to see what your point is. You seem to be saying that different people will get different results using the same mechanisms. If this is your point, then we agree. But, you have argued for different mechanisms before. In each category you describe several variations on the same theme which result in differing qualities in the return on investment. But, in each category there are some essential principles which are the same. airplanes have wings and means of propulsion, cars and trucks have wheels, brakes, steering and propulsion, and PDAs and Celerons have I/O, CPU and storage. You are suggesting that part of the population should use PDAs to drive on roads and the other part should use F-15s. Yet that was your proposal before about having different mechanisms for different classes of multihoming. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO50R4IqHRg3pndX9AQEYOAQA2wFKB1Yxr4xvbjIpS2u/IhZogeLK2KVc 5A54yT0CueJkEbRi510+5IuV2QFpkz/8pkRIUmTqr6ooLI7DGRWYgRXV30f+WqxT tVCQXXBwPpY8WCov0Z6e/PFxNGxoYlEQ6l7G13fZfPZnQ06N4BXI6bBzH4lV6BLF AtpjZCO6ns4= =yzpA -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Sep 10 16:03:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29431 for ; Mon, 10 Sep 2001 16:02:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15gXHe-0007Ml-00 for multi6-data@psg.com; Mon, 10 Sep 2001 13:03:54 -0700 Received: from lox.sandelman.ottawa.on.ca ([192.139.46.2]) by psg.com with esmtp (Exim 3.33 #1) id 15gXHd-0007Me-00 for multi6@ops.ietf.org; Mon, 10 Sep 2001 13:03:53 -0700 Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id QAA25661 for ; Mon, 10 Sep 2001 16:03:53 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca ([3ffe:1ce1:0:fe50:204:76ff:fe2d:8c]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f8AK4aG11396 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 10 Sep 2001 16:04:37 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f8AK3an06454 for ; Mon, 10 Sep 2001 16:03:36 -0400 (EDT) Message-Id: <200109102003.f8AK3an06454@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: A new spin on multihoming: multihoming classes. In-reply-to: Your message of "Sun, 09 Sep 2001 14:04:00 +1000." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 10 Sep 2001 16:03:35 -0400 From: Michael Richardson Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Peter" == Peter Tattam writes: Peter> The suggested IPv6 solution is to limit the choices that the DFZ routers need Peter> to make and push the MH decision making to the edges. By doing so, you throw Peter> away the MH information visible at the core and you have to regain it another Peter> way (which I've said before). Let me reword this: push the MH decision away from the DFZ The thing about IX based solutions with geographically significant addressing is that it pushes the problem down to the IX and municipal area network. My preferred solution is to use geographically significant addresses as the PI address format, but to then use some kind of address exchange mechanism inband (a la what you have described). I am not clear why this "inband" system is any different than MobileIP, nor why it should be secure when MobileIP is not. My preference is therefore to use either Binding Updates or a minor variation of them to do this. Geographically significant addresses may never get optimal routing. It may even be necessary to configure tunnels to geographical address concentrators to get the first packet through. (This is easily done with IKE and IPsec and scales rather well as the relationship with the address concentrator must be pre-existing. I would further suggest that it is entirely appropriate that these system be a municipally governed service, but that is a local jurisdiction issue) If I wanted to put a web server up in this scenario, I'd give www.example.com a geographically significant address in DNS. I'd could then have references to the rest of the site be www-ispA.example.com or some such with a PA address that leads to the appropriate place, or just depend upon each host having some kind of PI->PA cache. [This can wreck havoc with long term bookmarks, but many of these web sites are entirely generated anyway, and bookmarks fail here anyway. Putting a URL in that is appropriate for "bookmark"ing is probably a todo for W3C anyway] Peter> Finally I might add that I have to concede there is one Peter> fundamental flaw in the Peter> host based or DNS based solutions to MH and that was eloquently pointed out by Peter> someone else. DNS needs routing so routing can't depend on DNS which means we Peter> can't use it as it is currently implemented, primarily because DNS is agnostic Peter> towards routing conditions. While I would agree that we would like to have the root, and TLD servers multihomed (and in particular, we'd like to have a stable set of addresses to put into named.ca), DNS has some rather nice features for discovering the entire list of addresses of nameservers already. The first thing that one usually does when a DNS server starts is to ask the root servers for a list of root servers. They could easily return all of their PA. So, while I would agree that having a *routing* system that depends upon DNS is a deadlock, having a *multihoming* system that depends upon DNS may not be a loss. I would prefer that we did not rely on DNS however. Peter> An idea springs to mind - why not have an alternative system based on BGP Peter> *independent* of the routing system from which reachability information can be Peter> gathered. Such a BGP system would need to be extended so that whole DFZ would Peter> not need to be kept in the BGP server, but rather the localized routing needs Peter> of the site instead, much in the same way that a DNS server only keeps the Peter> localized name mapping that it requires for the sites current connections. Like a geographical IX system? Peter> If this has been thought of before I completely apologize to the original Peter> proposer. I think it is in one draft. Hmm. Now I don't know which one! We need a better list of drafts under consideration. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO50clYqHRg3pndX9AQFCtwQA7phFAakYQ4KtkHq9M4dSgKN1kfRWU7Hr iR7IJsRfATdAkUWqK1Xn+ArMd8wQjFa4R6txULRxs10ViY6Ii+OgWJ79W7Qs8phw hka/oUSa/1zxh8XnLlzQjgikQ0UYh8PFQvgABt5MMdmrsr+kxu5Qp/qTs9dKe4lj PazDX42/pYo= =3P/x -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Sep 11 05:09:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01008 for ; Tue, 11 Sep 2001 05:09:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15gjW8-000KGm-00 for multi6-data@psg.com; Tue, 11 Sep 2001 02:07:40 -0700 Received: from viap090.atea.be ([194.78.143.90] helo=hrtades9.atea.be) by psg.com with esmtp (Exim 3.33 #1) id 15gjW7-000KGg-00 for multi6@ops.ietf.org; Tue, 11 Sep 2001 02:07:40 -0700 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SF8JYTWL; Tue, 11 Sep 2001 11:07:44 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Sep 2001 11:07:15 +0200 Message-ID: From: Coene Lode To: "'Iljitsch van Beijnum'" Cc: "'tsvwg@ietf.org'" , "'multi6@ops.ietf.org'" Subject: RE: multihoming issues via SCTP Date: Tue, 11 Sep 2001 11:07:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-multi6@ops.ietf.org Precedence: bulk Some comments below. > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: maandag 10 september 2001 17:17 > To: Coene Lode > Cc: 'tsvwg@ietf.org'; 'multi6@ops.ietf.org' > Subject: Re: multihoming issues via SCTP > > > On Mon, 10 Sep 2001, Coene Lode wrote: > > > This document describes issues of the Stream Control Transmission > > Protocol (SCTP)[RFC2960] in regard to multihoming on the > Internet. It > > explores cases where through situations in the internet, single > > points-of-failure can occur even when using multihoming and what the > > impact is of multihoming on the host routing tables. > > The main problem is the idea of paths from an interface on > one host to an > interface on another host. This could work if the hosts are > both connected > to two networks that are not interconnected, but not on anything > resembling the Internet. > > For instance, consider host A having interface 1 connected to > ISP X and > interface 2 to ISP Y. By coincidence host B it is > communicating with, is > connected to the same ISPs, but the other way around: > interface 1 to Y and > interface 2 to X. So now host A tries to connect to host B > over interface > 1, ISP X, ISP Y and interface 1 of host B (A1->X->Y-B1) and also > A2->Y->X->B2. This should work just fine, although two ISPs > instead of one > in each path may not give the best possible performance. > > But now there are three ways in which the connection can > fail: either of > the ISPs may fail, or the connection between them. > > This means there have to be more paths: > > A1->X->Y->B1 > A1->X->B2 > A2->Y->B1 > A2->Y->X->B2 yes, but does routing allow them to be used? We got the impression that at a certain time you can have only one path through the network for a certain destination address. > > However, this assumes both that the output interface stays > the same over > the life time of a connection and that the end host is the > one making the > decision how packets are routed to the outside. Both are > unlikely. Well, but that is how it is done with SCTP. SCTP specifies the destination address and IP should try to route based on that IP address to B. If B1 is taken as destination address then the source address should be the corresponding A1(and that is something done by IP in host A). Host A has to make a routing decision based on the destination address whether it likes it or not. > If an > output interface fails, hosts may simply reroute outgoing > packets over the > other interface. That is a possibility, but that depends on who finds it first. If SCTP detects that the interface has gone(via the heartbeats that aren't acknowledge), then it will changeover to another destination address(thus taking the other interface) If on the other hand routing finds this, then routing will reroute everything over the other interface(but with the same destination address as before(and giving SCTP the impression that the path presently used is still up: so SCTP has been fooled into believing that both paths are still up) The question for me is: Does it happen that the host changes it routing tables? > And in most cases, routers will reroute packets over > another path if a connection to an ISP fails. So the other > side will often > still see incoming traffic from a remote address that is no longer > reachable for outgoing packets. Uhh, doesn't that mean that then the alternate address should be used instead of the original addresses? And as far as I understand something from routing and routing protocols, doesn't that take time? The fact is that I come from a background where rerouting(around failures) is immediate and we don't wait for routing protocol till they found some route around. In such a configuration, using the concept of paths through the network is indeed a stupid concept, as there are in theory a infinite number of paths through the network(every router has 2 or more routes towards a certain destination at any time). But that is not what we have been told what routing does in IP networks. Changing routes in IP networks seem to involve first searching for them and waiting for it till the routing protocol converges. And it is during that convergence faze that the packets will be routed to probably the middle of nowhere(or better said: they are dropped) If I happen to be wrong in this assesment, then let me know. That would mean that we could sleep better, put our trust in routing and that all the work in SCTP concerning multihoming wasn't really necessary. > > Also, I don't like the idea of a protocol sending keepalives > over a path > it is otherwise not using. This is a waste of resources and > can trigger > inefficient use of different kinds of caches. Well the alternate routes are not only used for heartbeats, but if the SACK don't get back, then the alternative routes are used for the SACK, so they are not really idle in the strictest sense of the word. What about caches: well caches (in my very humble opinion) shouldn't be there in the first place, especially the implicit ones, as you point out, they will contain irrelevant info. Well good, if they contain irrelevant info, what the hell are they doing anyway in may path apart from having absolutely no idea what is going on. The same is applicable for NAT's, that is also for SCTP not such a nice sight, especially if the SCTP multihoming is involved. > Also, it won't > do much good > unless there are three or more paths of which at least two fail, a > situation that is not likely to be very common. Murphy law: Failures of links, interfaces and routers will happen.(once upon a time, we believed this tale that failures wouldn't happen, but then reality and a lot of users thought us otherwise) > > Iljitsch van Beijnum > Yours sincerly, Lode From owner-multi6@ops.ietf.org Tue Sep 11 05:20:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01197 for ; Tue, 11 Sep 2001 05:20:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15gjiM-000KV3-00 for multi6-data@psg.com; Tue, 11 Sep 2001 02:20:18 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15gjiL-000KUx-00 for multi6@ops.ietf.org; Tue, 11 Sep 2001 02:20:18 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f8B9LQv05108; Tue, 11 Sep 2001 11:21:30 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 11 Sep 2001 11:21:26 +0200 (CEST) From: Iljitsch van Beijnum To: Michael Richardson cc: Subject: Re: If IPv6 multihomed sites were cars In-Reply-To: <200109101917.f8AJHtL04818@marajade.sandelman.ottawa.on.ca> Message-ID: <20010911095608.I3400-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 10 Sep 2001, Michael Richardson wrote: > >>>>> "Michel" == Michel Py writes: > Michel> On the same road, you can see trucks, sports cars, > Michel> Mercedes', and Yugos. > Michel> This specialization applies to almost technology item. > You seem to be saying that different people will get different > results using the same mechanisms. If this is your point, then we agree. > But, you have argued for different mechanisms before. > In each category you describe several variations on the same theme which > result in differing qualities in the return on investment. > But, in each category there are some essential principles which are > the same. airplanes have wings and means of propulsion, cars and trucks have > wheels, brakes, steering and propulsion, and PDAs and Celerons have I/O, CPU > and storage. I think what we're doing here compares to building roads in the car analogy. Unfortunately, the differences in IP are somewhat bigger than an order of magnitude in size or the quality of the seats. The slowest devices on the network are five orders of magnitude slower than the fastest. If we compare DS3 to the Mercedes and an ADSL user to a pedestrian, there are also snails (cell phone modem) and vehicles going mach 4 (Gigabit Ethernet) on the road. I feel we shouldn't spend too much time figuring out the perfect multihoming solution for a certain group of users, when each form of multihoming we've discussed so far has serious drawbacks and none of them is likely to be perfect anyway. And users have the annoying habit to use the technology in the way it best suits them, rather than in the way the designers intended. That being said, there are already multihoming solutions on the table that cater to the needs of four groups. ISPs can still do what they do now by getting a TLA address block and using BGP. Enterprises and smaller ISPs can take an address block from an upstream ISP and announce it to several ISPs over BGP. Since these announcements will very likely be filtered in the DFZ, there is no guaranteed network-wide redundancy, but when done carefully this could still work very well. Small to medium sized organizations or departments of larger organizations can use proxy address rewriting boxes to do multi-address multihoming processing for a large number of hosts and/or servers, if we create a protocol that allows this. Individual hosts can do their own MAMH processing, similar to mobile IP or SCTP. So there is really no problem, as long as we can make something good for multi-address multihoming and this is implemented widely enough to be useful. From owner-multi6@ops.ietf.org Tue Sep 11 05:52:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01589 for ; Tue, 11 Sep 2001 05:52:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15gkDH-000L7K-00 for multi6-data@psg.com; Tue, 11 Sep 2001 02:52:15 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15gkDG-000L6m-00 for multi6@ops.ietf.org; Tue, 11 Sep 2001 02:52:14 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f8B9rPt05147; Tue, 11 Sep 2001 11:53:25 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 11 Sep 2001 11:53:25 +0200 (CEST) From: Iljitsch van Beijnum To: Coene Lode cc: "'tsvwg@ietf.org'" , "'multi6@ops.ietf.org'" Subject: RE: multihoming issues via SCTP In-Reply-To: Message-ID: <20010911112132.I3400-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 11 Sep 2001, Coene Lode wrote: > > This means there have to be more paths: > > A1->X->Y->B1 > > A1->X->B2 > > A2->Y->B1 > > A2->Y->X->B2 > yes, but does routing allow them to be used? We got the impression that at > a certain time you can have only one path through the network for a certain > destination address. If we define a path as being from a source interface to a destination interface, then the number of paths is only limited by the product of the number of interfaces on both sides. Obviously, many of those paths will share a lot of infrastructure, but they won't be identical. I think the main problem is that in most cases a default route will be used, which is tied to one interface. That means the paths originating at the different interfaces are effectively identical. > > However, this assumes both that the output interface stays > > the same over > > the life time of a connection and that the end host is the > > one making the > > decision how packets are routed to the outside. Both are > > unlikely. > Well, but that is how it is done with SCTP. SCTP specifies the destination > address and IP should try to route based on that IP address to B. Right. So the decision about the output path is done in IP and SCTP probably can't control this. > If B1 is taken as destination address then the source address should be the > corresponding A1(and that is something done by IP in host A). I suppose it is possible to do this, although TCP doesn't. > > If an > > output interface fails, hosts may simply reroute outgoing > > packets over the > > other interface. > That is a possibility, but that depends on who finds it first. If SCTP > detects that the interface has gone(via the heartbeats that aren't > acknowledge), then it will changeover to another destination address(thus > taking the other interface) The fact that host B is suddenly sending packets to interface 2 instead of 1 of host A, doesn't influence outgoing packets on host A. Assuming B1 and B2 are both routed over the same interface (which is likely unless the host has a full routing table, something that never happens today) host A will have to detect the failure of interface 1 and reroute over interface 2. > The question for me is: Does it happen that the host changes it routing > tables? Depends on the host. I think most will do this, but it never hurts to experiment. If this doesn't happen automatically when using defaults, it is always possible to run RIP. > > And in most cases, routers will reroute packets over > > another path if a connection to an ISP fails. So the other > > side will often > > still see incoming traffic from a remote address that is no longer > > reachable for outgoing packets. > Uhh, doesn't that mean that then the alternate address should be used > instead of the original addresses? If the router does this, how would SCTP know a different source address has to be used? > And as far as I understand something from routing and routing protocols, > doesn't that take time? Of course. Depends on the interface, though: some can detect failures very fast (less than a second) while others won't see failures at all and there has to be a timeout in the routing protocol. This takes 30 to 180 seconds. The former is likely in point-to-point links, the latter in switched environments (Ethernet, ATM). > Changing routes in IP networks > seem to involve first searching for them and waiting for it till the routing > protocol converges. And it is during that convergence faze that the packets > will be routed to probably the middle of nowhere(or better said: they are > dropped) There are many different routing protocols, all with different properties. For instance, RIP waits for minutes to decide that a destination is unreachable and then removes it from the routing table. OSPF and IS-IS on the other hand, will detect all failures in 30 seconds, and interfaces that go down immediately. Then the update is flooded through the network and all routers recompute the topology. In BGP the detection process is much the same but each router recomputes the routing changes individually. So in BGP it may take a few moments for routing to stabilize. Routers do not necessarily drop packets while updating routing information, but they may route them to unreachable destinations or in loops for a while. > > Also, I don't like the idea of a protocol sending keepalives > > over a path > > it is otherwise not using. This is a waste of resources and > > can trigger > > inefficient use of different kinds of caches. > Well the alternate routes are not only used for heartbeats, but if the SACK > don't get back, then the alternative routes are used for the SACK, so they > are not really idle in the strictest sense of the word. Well if everything is working, then the other paths aren't used, right? > What about caches: well caches (in my very humble opinion) shouldn't be > there in the first place, Some routers use a "route cache" where the most recently used routing information is stored. ARP or neighbor discovery are also a form of cacheing. Why should processing all of this be triggered just to see if a path is available if you don't intend to use it? > > Also, it won't do much good > > unless there are three or more paths of which at least two fail, a > > situation that is not likely to be very common. > Murphy law: Failures of links, interfaces and routers will happen.(once upon > a time, we believed this tale that failures wouldn't happen, but then > reality and a lot of users thought us otherwise) I'm not saying failures won't happen, just that in most cases the heartbeats won't help you. If there are only two paths, you'll have to use the second one when the first one fails. So why bother to see if the second path is alive? You'll find out soon enough. If you have three paths and one fails, then each of the others still work so no need to use heartbeats again. Only when two paths fail at the same time, it helps to know which secondary path has also failed so you know to avoid that one and pick the other. If doing something and doing nothing yield the same results, the latter is preferable. Iljitsch From owner-multi6@ops.ietf.org Tue Sep 11 07:45:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03673 for ; Tue, 11 Sep 2001 07:45:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15glxt-000N1o-00 for multi6-data@psg.com; Tue, 11 Sep 2001 04:44:29 -0700 Received: from viap090.atea.be ([194.78.143.90] helo=hrtades9.atea.be) by psg.com with esmtp (Exim 3.33 #1) id 15glxq-000N1i-00 for multi6@ops.ietf.org; Tue, 11 Sep 2001 04:44:27 -0700 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SF8JY40Q; Tue, 11 Sep 2001 13:44:34 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Sep 2001 13:44:05 +0200 Message-ID: From: Coene Lode To: "'Iljitsch van Beijnum'" , Coene Lode Cc: "'tsvwg@ietf.org'" , "'multi6@ops.ietf.org'" Subject: RE: multihoming issues via SCTP Date: Tue, 11 Sep 2001 13:43:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-multi6@ops.ietf.org Precedence: bulk a few commments below. > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: dinsdag 11 september 2001 11:53 > To: Coene Lode > Cc: 'tsvwg@ietf.org'; 'multi6@ops.ietf.org' > Subject: RE: multihoming issues via SCTP > > > On Tue, 11 Sep 2001, Coene Lode wrote: > > > > This means there have to be more paths: > > > > A1->X->Y->B1 > > > A1->X->B2 > > > A2->Y->B1 > > > A2->Y->X->B2 > > > yes, but does routing allow them to be used? We got the > impression that at > > a certain time you can have only one path through the > network for a certain > > destination address. > > If we define a path as being from a source interface to a destination > interface, then the number of paths is only limited by the > product of the > number of interfaces on both sides. Obviously, many of those > paths will > share a lot of infrastructure, but they won't be identical. > > I think the main problem is that in most cases a default route will be > used, which is tied to one interface. That means the paths > originating at > the different interfaces are effectively identical. Hmm, not exactly the effect we are looking for. > > > > However, this assumes both that the output interface stays > > > the same over > > > the life time of a connection and that the end host is the > > > one making the > > > decision how packets are routed to the outside. Both are > > > unlikely. > > > Well, but that is how it is done with SCTP. SCTP specifies > the destination > > address and IP should try to route based on that IP address to B. > > Right. So the decision about the output path is done in IP and SCTP > probably can't control this. > > > If B1 is taken as destination address then the source > address should be the > > corresponding A1(and that is something done by IP in host A). > > I suppose it is possible to do this, although TCP doesn't. It is not TCP nor SCTP that have to do selection of the source address, They cannot do this, it is the IP layer who has to do this. > > > > If an > > > output interface fails, hosts may simply reroute outgoing > > > packets over the > > > other interface. > > > That is a possibility, but that depends on who finds it > first. If SCTP > > detects that the interface has gone(via the heartbeats that aren't > > acknowledge), then it will changeover to another > destination address(thus > > taking the other interface) > > The fact that host B is suddenly sending packets to interface > 2 instead of > 1 of host A, doesn't influence outgoing packets on host A. > Assuming B1 and > B2 are both routed over the same interface (which is likely unless the > host has a full routing table, something that never happens > today) host A > will have to detect the failure of interface 1 and reroute > over interface > 2. > > > The question for me is: Does it happen that the host > changes it routing > > tables? > > Depends on the host. I think most will do this, but it never hurts to > experiment. If this doesn't happen automatically when using > defaults, it > is always possible to run RIP. Well, something to test during a SCTP bakeoff maybe. > > > > And in most cases, routers will reroute packets over > > > another path if a connection to an ISP fails. So the other > > > side will often > > > still see incoming traffic from a remote address that is no longer > > > reachable for outgoing packets. > > > Uhh, doesn't that mean that then the alternate address > should be used > > instead of the original addresses? > > If the router does this, how would SCTP know a different > source address > has to be used? It never knows, SCTP only supplies the destination address, the network layer has to fill in the source address. > > > And as far as I understand something from routing and > routing protocols, > > doesn't that take time? > > Of course. Depends on the interface, though: some can detect > failures very > fast (less than a second) while others won't see failures at > all and there > has to be a timeout in the routing protocol. This takes 30 to > 180 seconds. > > The former is likely in point-to-point links, the latter in switched > environments (Ethernet, ATM). > > > Changing routes in IP networks > > seem to involve first searching for them and waiting for it > till the routing > > protocol converges. And it is during that convergence faze > that the packets > > will be routed to probably the middle of nowhere(or better > said: they are > > dropped) > > There are many different routing protocols, all with > different properties. > For instance, RIP waits for minutes to decide that a destination is > unreachable and then removes it from the routing table. OSPF > and IS-IS on > the other hand, will detect all failures in 30 seconds, and interfaces > that go down immediately. Then the update is flooded through > the network > and all routers recompute the topology. In BGP the detection > process is > much the same but each router recomputes the routing changes > individually. > So in BGP it may take a few moments for routing to stabilize. > > Routers do not necessarily drop packets while updating routing > information, but they may route them to unreachable destinations or in > loops for a while. > > > > Also, I don't like the idea of a protocol sending keepalives > > > over a path > > > it is otherwise not using. This is a waste of resources and > > > can trigger > > > inefficient use of different kinds of caches. > > > Well the alternate routes are not only used for heartbeats, > but if the SACK > > don't get back, then the alternative routes are used for > the SACK, so they > > are not really idle in the strictest sense of the word. > > Well if everything is working, then the other paths aren't > used, right? Yes, that is right > > > What about caches: well caches (in my very humble opinion) > shouldn't be > > there in the first place, > > Some routers use a "route cache" where the most recently used routing > information is stored. ARP or neighbor discovery are also a form of > cacheing. Why should processing all of this be triggered just > to see if a > path is available if you don't intend to use it? You can turn it off(see also Michel's mail) > > > > Also, it won't do much good > > > unless there are three or more paths of which at least two fail, a > > > situation that is not likely to be very common. > > > Murphy law: Failures of links, interfaces and routers will > happen.(once upon > > a time, we believed this tale that failures wouldn't > happen, but then > > reality and a lot of users thought us otherwise) > > I'm not saying failures won't happen, just that in most cases the > heartbeats won't help you. If there are only two paths, > you'll have to use > the second one when the first one fails. So why bother to see if the > second path is alive? You'll find out soon enough. In my view, if the second path is not alive then everything is allready lost and the net result is that I gain a lot of very, very angry customers. That is my view and , agreed, for some/many/most/all?(make your choice) applications that need not to be the case. > If you > have three paths > and one fails, then each of the others still work so no need to use > heartbeats again. Only when two paths fail at the same time, > it helps to > know which secondary path has also failed so you know to > avoid that one > and pick the other. > > If doing something and doing nothing yield the same results, > the latter is > preferable. Depends on the view taken. If you are happy which the situation as you described then OK, then it is better to do nothing(that is why the heartbeat is optional). But you will find people(like me) doing heartbeats(and yes, there are not many of us) > > Iljitsch > Seems like we are in between a rock and a hard place. Maybe I'll try to come up with something. Thanks anyway for the comments. They cleared some things for me. Yours sincerly, Lode From owner-multi6@ops.ietf.org Tue Sep 11 23:48:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26834 for ; Tue, 11 Sep 2001 23:48:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15h0xD-000F1o-00 for multi6-data@psg.com; Tue, 11 Sep 2001 20:44:47 -0700 Received: from web13507.mail.yahoo.com ([216.136.175.86]) by psg.com with smtp (Exim 3.33 #1) id 15h0xD-000F1i-00 for multi6@ops.ietf.org; Tue, 11 Sep 2001 20:44:47 -0700 Message-ID: <20010912034446.22956.qmail@web13507.mail.yahoo.com> Received: from [63.101.96.1] by web13507.mail.yahoo.com via HTTP; Tue, 11 Sep 2001 20:44:46 PDT Date: Tue, 11 Sep 2001 20:44:46 -0700 (PDT) From: Michel Py Subject: Re: If IPv6 multihomed sites were cars To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org In-Reply-To: <20010911095608.I3400-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch - --- Iljitsch van Beijnum wrote: >> Unfortunately, the differences in IP are >> somewhat bigger than an order of magnitude in >> size or the quality of the seats. The slowest >> devices on the network are five orders of magnitude >> slower than the fastest. If we compare DS3 to the >> Mercedes and an ADSL user to a pedestrian, there >> are also snails (cell phone modem) and vehicles >> going mach 4 (Gigabit Ethernet) on the road. Good point. > ISPs can still do what they do now by getting a TLA > address block and > using BGP. There is some danger here. As of today, there can be only 8K TLAs and there are more ASNs allocated already. I fear a rush to get a TLA "just in case" by people that don't really need one. To be honest, it has crossed my mind. With several thousand modems and multiple DS3s OC48s I would probably qualify for it. With such scarce numbers, it might even be a sound business decision. If I could get an IPv4 class A today for a few thousand dollars, I certainly would. Just in case. >> So there is really no problem, as long as we can >> make something good for multi-address multihoming >> and this is implemented widely enough to be useful. There needs to be some mutual awareness between all the different solutions. As of today, there are still people that say that we should design a mach 4 Yugo... Michel __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From owner-multi6@ops.ietf.org Wed Sep 12 10:40:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23319 for ; Wed, 12 Sep 2001 10:40:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15hB78-0001Z4-00 for multi6-data@psg.com; Wed, 12 Sep 2001 07:35:42 -0700 Received: from viap090.atea.be ([194.78.143.90] helo=hrtades9.atea.be) by psg.com with esmtp (Exim 3.33 #1) id 15hB77-0001Yo-00 for multi6@ops.ietf.org; Wed, 12 Sep 2001 07:35:42 -0700 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SF8JY7CS; Wed, 12 Sep 2001 16:35:52 +0200 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Sep 2001 16:35:23 +0200 Message-ID: From: Coene Lode To: "'Ivan.Arias-Rodriguez@nokia.com'" , Coene Lode , iljitsch@muada.com Cc: tsvwg@ietf.org, multi6@ops.ietf.org Subject: RE: [Tsvwg] RE: multihoming issues via SCTP Date: Wed, 12 Sep 2001 16:35:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA23319 alot of stuff deleted <>snip<> > > > By the way Lode, wouldn't it be interesting including something > about the use of IPsec in the draft and the problems with it regarding > multiple addresses? There is a mention of it in the applicability statement(that Ipsec is looking into the matter). And it should normally be mentioned also in the specific IPsec and SCTP draft in the IPsec WG(forgot the draft name) Oh got it: draft-ietf-ipsec-sctp-01.txt Oh boy, another one to read. > > BR Iván Arias Rodríguez > But no problem, if you sent something I'll be more than happy to include it. Yours sincerly, Lode From owner-multi6@ops.ietf.org Wed Sep 12 11:10:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24200 for ; Wed, 12 Sep 2001 11:10:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15hBcF-0002BK-00 for multi6-data@psg.com; Wed, 12 Sep 2001 08:07:51 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.33 #1) id 15hBcF-0002BD-00 for multi6@ops.ietf.org; Wed, 12 Sep 2001 08:07:51 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27255; Wed, 12 Sep 2001 09:07:45 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8CF7lN05937; Wed, 12 Sep 2001 17:07:47 +0200 (MET DST) Date: Wed, 12 Sep 2001 17:03:50 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Distributed reachability information To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <20010908193134.O5044-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > This could be accomplished by using some kind of reachability cache, > storing information about whether an address or prefix is reachable (or > even how well, using RTT, bandwidth and packet loss statistics). As the > session is initiated, the possible addresses for the remote host are > checked against the reachability cache and the "best" address is selected. > Obviously the choice is limited when just one address is available: then > the system should try to connect to this address, whatever the cached > status. > > The data for the cache can come from ICMP unreachables and protocols or > even applications that gather their own statistics. Sharing this > information with other hosts and routers (as Peter Tattam and myself > discussed earlier this week) makes a lot of sense. If one host discovers > an address is unreachable, other local hosts can benefit from this and > immediately contact one of the other addresses for this destination host > if they want to connect to it shortly after that. > > The question is: how do we implement this? Before you go there I have a more basic question: What is the trust model associated with the notion of a reachability cache? Would you trust one shared in the IETF terminal room or any other public or semi-public 802.11 infrastructure? Would you trust one shared by all the customers of one of your ISPs? If you can't trust "random" hosts in a fairly large network (larger or a lot larger than a single home or personal area network) to contribute unverified information to the cache then the idea doesn't seem to be that useful since the probability of finding recent information in the cache about a particular destination is likely to be rather small. And if you take the path to verify the information I suspect (but it makes sense to verify this) that many aspects of the solution space start looking more like trusted route servers in the domain (that perhaps somehow interact with the site border routers). Erik From owner-multi6@ops.ietf.org Wed Sep 12 11:54:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25765 for ; Wed, 12 Sep 2001 11:54:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15hCK5-0003GB-00 for multi6-data@psg.com; Wed, 12 Sep 2001 08:53:09 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15hCK3-0003G0-00 for multi6@ops.ietf.org; Wed, 12 Sep 2001 08:53:07 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f8CFrne08579; Wed, 12 Sep 2001 17:53:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 12 Sep 2001 17:53:49 +0200 (CEST) From: Iljitsch van Beijnum To: Coene Lode cc: "'tsvwg@ietf.org'" , "'multi6@ops.ietf.org'" Subject: RE: multihoming issues via SCTP In-Reply-To: Message-ID: <20010912152721.C3400-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 11 Sep 2001, Coene Lode wrote: > > I think the main problem is that in most cases a default route will be > > used, which is tied to one interface. That means the paths > > originating at > > the different interfaces are effectively identical. > Hmm, not exactly the effect we are looking for. I believe SCTP was originally conceived as a protocol to transport telephony signalling. In such a context, it is possible to create a network where this is not a problem. However, I gather that there are people who want to do a lot more with SCTP and the Internet as a whole is not likely to be reengineerd to eliminate this problem. > > > If B1 is taken as destination address then the source address should be the > > > corresponding A1(and that is something done by IP in host A). > > I suppose it is possible to do this, although TCP doesn't. > It is not TCP nor SCTP that have to do selection of the source address, They > cannot do this, it is the IP layer who has to do this. Please keep in mind that selection of the source address and of the source interface are not related. In TCP, the system will select the source address matching the output interface for the first packet of an outgoing session. Since the remote TCP expects this address to stay the same, subsequent packets within a session all have the same source address, regardless of the output interface. Since it is possible in TCP to find a source address based on the output interface for the first packet, it stands to reason that SCTP could do this for every packet. [heatbeats] > You can turn it off(see also Michel's mail) I suggest that for implementations that are deployed in regular hosts that are expected to communicate over the Internet, heartbeats are disabled by default. > > I'm not saying failures won't happen, just that in most cases the > > heartbeats won't help you. If there are only two paths, > > you'll have to use > > the second one when the first one fails. So why bother to see if the > > second path is alive? You'll find out soon enough. > In my view, if the second path is not alive then everything is allready lost > and the net result is that I gain a lot of very, very angry customers. > That is my view and , agreed, for some/many/most/all?(make your choice) > applications that need not to be the case. I don't understand. Either the line is down or it is up. Heartbeating will not change this: we're not talking about quantum physics, where looking at something changes its state. I suppose that in telephony signalling, where there the number of sessions is very small and they stay up for very long and the data is very important, it can make sense to immediately see when a path goes down. But now consider a web server. It has dozens of simultaneous sessions, and each only lives for a few moments. Is it then sensible to send heartbeats over dozens of alternative paths? I hardly think so: having each session discover the same situation individually doesn't make any sense. This should be done at a lower level, if this functionality is required. But I that goes for all the multihoming features of SCTP, IMHO. > > If doing something and doing nothing yield the same results, > > the latter is preferable. > Depends on the view taken. If you are happy which the situation as you > described then OK, then it is better to do nothing(that is why the heartbeat > is optional). But you will find people(like me) doing heartbeats(and yes, > there are not many of us) Please read what I'm saying. If not asking for anything will get yo a cup of tea. And if asking for a cup of coffee will get you a cup of tea also. Is it then worth the trouble asking for coffee? > Seems like we are in between a rock and a hard place. Maybe I'll try to come > up with something. Not really. Have a look at http://www.muada.com/sctp.gif [1st drawing] It describes a situation where host A communicates with host B and both networks have to routers and connect to two ISPs. As you can see, the default makes all the output traffic go over one connection: Red: A1 -> ISP W -> ISP Y -> B3 Orange: B3 -> ISP Y -> ISP W -> A1 Blue: A1 -> ISP W -> ISP Z -> B4 Cyan: B3 -> ISP Y -> ISP X -> A2 [2nd drawing] Then, if the 1 interface on A fails, it will detect this (hopefully) and point the default route to the other router over the other interface. Now the orange path from B to A fails, but the red and blue paths from A to B both still work and the cyan path from B to A as well. [3rd drawing] Another type of failure would be where ISP W and ISP Y (if they are the same ISP or share something) both fail. Then, two paths fail and the remaining paths get somewhat longer than necessary, but there is still a path in each direction. [4th drawing] In an environment where both ends of the connections can be controlled or coordinated, it is very easy to add static routes from A to B over A1/B3 and A2/B4 so the paths are more diverse and have to depend less on reliability/redundancy measures elsewhere in the network. If the network interfaces of A and B are in the same subnet, this even happens automatically without static routes. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Wed Sep 12 12:16:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26473 for ; Wed, 12 Sep 2001 12:16:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15hCf3-0003sH-00 for multi6-data@psg.com; Wed, 12 Sep 2001 09:14:49 -0700 Received: from mail3.microsoft.com ([131.107.3.123] helo=inet-vrs-03.redmond.corp.microsoft.com) by psg.com with smtp (Exim 3.33 #1) id 15hCf2-0003sB-00 for multi6@ops.ietf.org; Wed, 12 Sep 2001 09:14:48 -0700 Received: from 157.54.9.100 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Sep 2001 09:13:15 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Sep 2001 09:13:05 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Sep 2001 09:13:06 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Sep 2001 09:12:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: multihoming issues via SCTP Date: Wed, 12 Sep 2001 09:12:30 -0700 Message-ID: Thread-Topic: multihoming issues via SCTP Thread-Index: AcE7o6q+5FCdFa37S/6LDJjdMqRsyAAAaneQ From: "Christian Huitema" To: "Iljitsch van Beijnum" , "Coene Lode" Cc: , X-OriginalArrivalTime: 12 Sep 2001 16:12:30.0631 (UTC) FILETIME=[B939F370:01C13BA5] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA26473 > Please keep in mind that selection of the source address and of the > source > interface are not related. In TCP, the system will select the source > address matching the output interface for the first packet of an > outgoing > session. Since the remote TCP expects this address to stay the same, > subsequent packets within a session all have the same source address, > regardless of the output interface. > > Since it is possible in TCP to find a source address based on the > output > interface for the first packet, it stands to reason that SCTP could do > this for every packet. There are issues with this if the ISP enforces verification of the source address. The issues are discussed in draft-draves-ipngwg-ingress-filtering-00.txt These issues should be addressed by any multihoming solution. -- Christian Huitema From owner-multi6@ops.ietf.org Wed Sep 12 12:20:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26652 for ; Wed, 12 Sep 2001 12:20:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15hCi9-0003xJ-00 for multi6-data@psg.com; Wed, 12 Sep 2001 09:18:01 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15hCi8-0003x3-00 for multi6@ops.ietf.org; Wed, 12 Sep 2001 09:18:01 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f8CGJDa08626; Wed, 12 Sep 2001 18:19:13 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 12 Sep 2001 18:19:13 +0200 (CEST) From: Iljitsch van Beijnum To: Erik Nordmark cc: Subject: Re: Distributed reachability information In-Reply-To: Message-ID: <20010912175352.D3400-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 12 Sep 2001, Erik Nordmark wrote: > > This could be accomplished by using some kind of reachability cache, > > storing information about whether an address or prefix is reachable (or > > even how well, using RTT, bandwidth and packet loss statistics). As the > > session is initiated, the possible addresses for the remote host are > > checked against the reachability cache and the "best" address is selected. > What is the trust model associated with the notion of a reachability cache? > Would you trust one shared in the IETF terminal room or any other > public or semi-public 802.11 infrastructure? For yes/no reachability information: sure, why not. Either the information is correct, and I benefit, or the information is wrong and I'm no worse off then if I had picked the wrong address to try first myself. Obvioulsy, when the cache says something is not reachable, we only take this to mean we should try other addresses first, not that we shouldn't try to contact the "unreachable" address at all. The address might have become reachable again in the mean time. For the more detailed RTT, bandwidth and packet loss information this could be more of a problem: skillful manipulation of this information might do more damage. And I'm not sure I'm willing to trust all implementations to calculate these values correctly. So this part is problematic. > Would you trust one shared by all the customers of one of your ISPs? If we make sure one single host can't flood the network with unlimited amounts of false messages, the number of "good" messages will outnumber the "bad" ones so there should still be some benefit. > If you can't trust "random" hosts in a fairly large network > (larger or a lot larger than a single home or personal area network) to > contribute unverified information to the cache then the idea doesn't seem > to be that useful since the probability of finding recent information > in the cache about a particular destination is likely to be rather small. I think even in relatively small networks the correlation between remote hosts accessed is large enough to be helpful. Especially if the DNS is in on it, since in many situations prior to communication the local name server will have to contact a remote name server that is close to the destination host. Iljitsch From owner-multi6@ops.ietf.org Wed Sep 12 12:25:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26840 for ; Wed, 12 Sep 2001 12:25:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15hCny-00049N-00 for multi6-data@psg.com; Wed, 12 Sep 2001 09:24:02 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.33 #1) id 15hCnx-00049F-00 for multi6@ops.ietf.org; Wed, 12 Sep 2001 09:24:01 -0700 Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id MAA20184; Wed, 12 Sep 2001 12:23:51 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id MAA08709; Wed, 12 Sep 2001 12:23:52 -0400 (EDT) Date: Wed, 12 Sep 2001 12:23:51 -0400 (EDT) From: Greg Maxwell To: Christian Huitema cc: Iljitsch van Beijnum , Coene Lode , , Subject: RE: multihoming issues via SCTP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 12 Sep 2001, Christian Huitema wrote: > There are issues with this if the ISP enforces verification of the > source address. The issues are discussed in > draft-draves-ipngwg-ingress-filtering-00.txt > These issues should be addressed by any multihoming solution. My suggestion with respect to multihoming in the transport protocol (i.e. via SCTP) is to use source address routing for egress at the edges. It solves the filtering issue nicely, and lets the multihoming host have full path control. From owner-multi6@ops.ietf.org Wed Sep 12 12:41:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27280 for ; Wed, 12 Sep 2001 12:41:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15hD41-0004cC-00 for multi6-data@psg.com; Wed, 12 Sep 2001 09:40:37 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.33 #1) id 15hD40-0004c6-00 for multi6@ops.ietf.org; Wed, 12 Sep 2001 09:40:36 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18615; Wed, 12 Sep 2001 10:40:31 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8CGeWN12549; Wed, 12 Sep 2001 18:40:32 +0200 (MET DST) Date: Wed, 12 Sep 2001 18:36:36 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Distributed reachability information To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <20010912175352.D3400-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > For yes/no reachability information: sure, why not. Either the information > is correct, and I benefit, or the information is wrong and I'm no worse > off then if I had picked the wrong address to try first myself. If you can choose between addresses A and B and B is in fact unreachable but somebody has entered information into the cache to the opposite (i.e. that B is good and A is unreachable) then you end up trying B before A, which seems worse than a random pick. > Obvioulsy, when the cache says something is not reachable, we only take > this to mean we should try other addresses first, not that we shouldn't > try to contact the "unreachable" address at all. The address might have > become reachable again in the mean time. > > For the more detailed RTT, bandwidth and packet loss information this > could be more of a problem: skillful manipulation of this information > might do more damage. And I'm not sure I'm willing to trust all > implementations to calculate these values correctly. So this part is > problematic. Some of those metrics might also become stale in about one RTT (packet loss depending on congestion and congestion control per connection reacting in one RTT approx.) so the utility of caching them might be limited. > > > Would you trust one shared by all the customers of one of your ISPs? > > If we make sure one single host can't flood the network with unlimited > amounts of false messages, the number of "good" messages will outnumber > the "bad" ones so there should still be some benefit. And how could you make sure? > I think even in relatively small networks the correlation between remote > hosts accessed is large enough to be helpful. Even for a single household? The household members are not very likely to share interests i.e. communication patters. I wish there was real data on IP address usage e.g. for households so we'd have to data to talk about. > Especially if the DNS is in > on it, since in many situations prior to communication the local name > server will have to contact a remote name server that is close to the > destination host. Often the host would communicate with a DNS resolver (a server which does recursion) and not with the actual DNS servers for the target domain. And then the DNS does private caching so the resolver (or host if there is no resolver) might not talk to the authoritative server. Finally, the location of the authoritative server might not have much to do with the location of hosts in that domain. For instance, example.com might run their own authoritative server at the site (with secondaries at example.net), but www.example.com is outsourced to some completely different entity and location. Again it would be useful to have data indicating whether or not the DNS lookup could provide useful hints to the communication following the lookup. Erik I wonder about the correlation of DNS servers and From owner-multi6@ops.ietf.org Wed Sep 12 13:07:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27916 for ; Wed, 12 Sep 2001 13:07:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15hDTG-0005Hf-00 for multi6-data@psg.com; Wed, 12 Sep 2001 10:06:42 -0700 Received: from mail3.microsoft.com ([131.107.3.123] helo=inet-vrs-03.redmond.corp.microsoft.com) by psg.com with smtp (Exim 3.33 #1) id 15hDTF-0005HZ-00 for multi6@ops.ietf.org; Wed, 12 Sep 2001 10:06:41 -0700 Received: from 157.54.9.108 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Sep 2001 10:05:28 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Sep 2001 10:05:25 -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(5.0.2195.2966); Wed, 12 Sep 2001 10:05:23 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Sep 2001 10:04:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: multihoming issues via SCTP Date: Wed, 12 Sep 2001 10:04:48 -0700 Message-ID: Thread-Topic: multihoming issues via SCTP Thread-Index: AcE7qAuaYTDbNsg1S1u/2kta4K776gAAzLpg From: "Christian Huitema" To: "Greg Maxwell" Cc: X-OriginalArrivalTime: 12 Sep 2001 17:04:48.0796 (UTC) FILETIME=[07B7EDC0:01C13BAD] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA27916 > > There are issues with this if the ISP enforces verification of the > > source address. The issues are discussed in > > draft-draves-ipngwg-ingress-filtering-00.txt > > These issues should be addressed by any multihoming solution. > > My suggestion with respect to multihoming in the transport protocol > (i.e. > via SCTP) is to use source address routing for egress at the edges. > > It solves the filtering issue nicely, and lets the multihoming host > have full path control. Are you suggesting that we modify all IPv6 routers to implement source based routing? And that we modify all the hosts? The cost appears important: we would need to maintain in each router of the site a separate routing table for of the valid prefixes; we would need to define routing protocols that are prefix aware; we would need to modify the "neighbor cache" management in hosts to include a qualifier per source address. Estimated development time should probably be counted in years. I would rather look for a solution to ingress filtering that only involves the site exit routers and the hosts. An example may be a mesh of tunnels established between the exit routers, so that packets can be redirected to the right exit. Another example would be an ICMP error message warning that the packet cannot be delivered because the source address is incompatible with the path; we would indeed need a hint of what a valid source address prefix would be; the host could then retry the transmission with an appropriate source address, as well as possibly a binding update. Yet another example may be tunneling from the host to an appropriate exit point; but then, we would need a way to find the exit point or the anycast address associated with a specific prefix. -- Christian Huitema From owner-multi6@ops.ietf.org Wed Sep 12 14:37:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00012 for ; Wed, 12 Sep 2001 14:37:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15hEsJ-0007cS-00 for multi6-data@psg.com; Wed, 12 Sep 2001 11:36:39 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15hEsH-0007bv-00 for multi6@ops.ietf.org; Wed, 12 Sep 2001 11:36:38 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f8CIbm508857; Wed, 12 Sep 2001 20:37:48 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 12 Sep 2001 20:37:48 +0200 (CEST) From: Iljitsch van Beijnum To: Christian Huitema cc: Subject: RE: multihoming issues via SCTP In-Reply-To: Message-ID: <20010912203130.P3400-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 12 Sep 2001, Christian Huitema wrote: > I would rather look for a solution to ingress filtering that only > involves the site exit routers and the hosts. An example may be a mesh > of tunnels established between the exit routers, so that packets can be > redirected to the right exit. And what if this exit happens to be down? Wouldn't it be easier to just allow all addresses in all filters at all exits? Source address filtering is a means to an end, not an end in itself. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Wed Sep 12 15:28:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01127 for ; Wed, 12 Sep 2001 15:28:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15hFfQ-0008vQ-00 for multi6-data@psg.com; Wed, 12 Sep 2001 12:27:24 -0700 Received: from mail5.microsoft.com ([131.107.3.121] helo=inet-vrs-05.redmond.corp.microsoft.com) by psg.com with smtp (Exim 3.33 #1) id 15hFfO-0008vJ-00 for multi6@ops.ietf.org; Wed, 12 Sep 2001 12:27:22 -0700 Received: from 157.54.7.67 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Sep 2001 12:26:45 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Sep 2001 12:26:45 -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(5.0.2195.2966); Wed, 12 Sep 2001 12:26:40 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Sep 2001 12:26:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: multihoming issues via SCTP Date: Wed, 12 Sep 2001 12:26:03 -0700 Message-ID: Thread-Topic: multihoming issues via SCTP Thread-Index: AcE7ucWh16vIhAlKRzCd8YVykIzbFAABtkLw From: "Christian Huitema" To: "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 12 Sep 2001 19:26:04.0296 (UTC) FILETIME=[C3829880:01C13BC0] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA01127 > > I would rather look for a solution to ingress filtering that only > > involves the site exit routers and the hosts. An example may be a > mesh > > of tunnels established between the exit routers, so that packets can > be > > redirected to the right exit. > > And what if this exit happens to be down? > > Wouldn't it be easier to just allow all addresses in all filters at > all > exits? Source address filtering is a means to an end, not an end in > itself. Yes, that is also a very good option. But you have to understand the ramification, e.g. if source address filtering was to be performed further up in the network. -- Christian Huitema From owner-multi6@ops.ietf.org Thu Sep 13 04:14:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28961 for ; Thu, 13 Sep 2001 04:14:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15hRZc-0005ep-00 for multi6-data@psg.com; Thu, 13 Sep 2001 01:10:12 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15hRZb-0005eh-00 for multi6@ops.ietf.org; Thu, 13 Sep 2001 01:10:11 -0700 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8D89ap06342 for ; Thu, 13 Sep 2001 04:09:36 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Thu, 13 Sep 2001 04:10:02 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id S3346YNG; Thu, 13 Sep 2001 04:10:02 -0400 Received: from americasm06.nt.com (DEATHVALLEY [141.251.192.167]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87R97T; Thu, 13 Sep 2001 04:10:00 -0400 Message-ID: <3BA069D6.939315F5@americasm06.nt.com> Date: Thu, 13 Sep 2001 04:09:58 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: Greg Maxwell , multi6@ops.ietf.org Subject: Re: multihoming issues via SCTP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian, Christian Huitema wrote: > Are you suggesting that we modify all IPv6 routers to implement source > based routing? I should point out that the use of non-global scoped addresses will utilize a form of source-based routing already. Right now, the restriction is in place for two reasons: 1. To ensure the correct scope zone ID is used in route lookups 2. To prevent source addresses of lesser scope from "leaking" out of a scope zone boundary This is all documented in the scoped addressing architecture document draft-ietf-ipngwg-scoping-arch-02.txt. Regards, Brian From owner-multi6@ops.ietf.org Thu Sep 13 11:47:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06255 for ; Thu, 13 Sep 2001 11:47:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15hYfM-000DCg-00 for multi6-data@psg.com; Thu, 13 Sep 2001 08:44:36 -0700 Received: from mail5.microsoft.com ([131.107.3.121] helo=inet-vrs-05.redmond.corp.microsoft.com) by psg.com with smtp (Exim 3.33 #1) id 15hYfL-000DCa-00 for multi6@ops.ietf.org; Thu, 13 Sep 2001 08:44:35 -0700 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Sep 2001 08:44:11 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 08:44:11 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 08:44:09 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 08:43:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: multihoming issues via SCTP Date: Thu, 13 Sep 2001 08:43:33 -0700 Message-ID: Thread-Topic: multihoming issues via SCTP Thread-Index: AcE8K2v4N5gXbQChRVWJQgyqjkt1+wAOgsVg From: "Christian Huitema" To: "Brian Haberman" Cc: "Greg Maxwell" , X-OriginalArrivalTime: 13 Sep 2001 15:43:33.0421 (UTC) FILETIME=[D82E7DD0:01C13C6A] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA06255 > > Are you suggesting that we modify all IPv6 routers to implement > source > > based routing? > > I should point out that the use of non-global scoped addresses will > utilize a form of source-based routing already... > > This is all documented in the scoped addressing architecture document > draft-ietf-ipngwg-scoping-arch-02.txt. Enforcing scope boundaries is not the same as source based routing; it is source based access control. There is still only one routing table; packets going to a given prefix follow a route that is independent of the source address; they are just dropped somewhere in the middle of that route if they are not authorized to cross a boundary. -- Christian Huitema From owner-multi6@ops.ietf.org Mon Sep 17 10:17:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12886 for ; Mon, 17 Sep 2001 10:17:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15iz8D-000O9d-00 for multi6-data@psg.com; Mon, 17 Sep 2001 07:12:17 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([194.237.142.110]) by psg.com with esmtp (Exim 3.33 #1) id 15iz8C-000O9X-00 for multi6@ops.ietf.org; Mon, 17 Sep 2001 07:12:16 -0700 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f8HECEv14268; Mon, 17 Sep 2001 16:12:14 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA13024; Mon, 17 Sep 2001 16:12:13 +0200 Message-ID: <3BA60439.35D98F1@era.ericsson.se> Date: Mon, 17 Sep 2001 16:10:01 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) References: <20010906200346.O5044-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Late reply... Iljitsch van Beijnum wrote: > > On Thu, 6 Sep 2001, Mattias Pettersson wrote: > > > I would like you to consider Homeless Mobile IPv6 > > as well. It tries to solve > > mobility and multihoming in one attempt somewhere around layer 3.5. > > Looks good. A few questions: > > - what happens when an address suddenly fails and is no longer reachable? > > - what happens if TCP tries to set up a connection but the address it > chooses doesn't respond (and there is another address that works > available)? As long as there are multiple addresses available the sending node is free to select any of them as destination address. I guess an ICMP error message or an upper layer lack of progress signal would cause a bad address to either be removed or lowered in priority. Similar ideas are used in Mobile IPv6 today. That would apply to both of your questions. In addition, in the first case, the peer can send packets to the node in question and the source address of those packets would indicate a new better destination address to use. > > - would it be possible to offload homeless mobile ipv6 processing on some > kind of "mobile proxy" so hosts that do not support the protocol can use > it anyway? That's an alternative to look at. Otherwise, the Homeless protocol is backwards compatible wrt Mobile IPv6, so that all that is required is standard correspondent node behaviour, which is mandatory for all IPv6 nodes anyway. /Mattias From owner-multi6@ops.ietf.org Mon Sep 17 14:01:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17416 for ; Mon, 17 Sep 2001 14:01:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15j2f7-0000s2-00 for multi6-data@psg.com; Mon, 17 Sep 2001 10:58:29 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15j2f5-0000rw-00 for multi6@ops.ietf.org; Mon, 17 Sep 2001 10:58:28 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f8HHxbB21874; Mon, 17 Sep 2001 19:59:37 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 17 Sep 2001 19:59:37 +0200 (CEST) From: Iljitsch van Beijnum To: Mattias Pettersson cc: Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <3BA60439.35D98F1@era.ericsson.se> Message-ID: <20010917195522.K21860-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 17 Sep 2001, Mattias Pettersson wrote: > > - what happens when an address suddenly fails and is no longer reachable? > > - what happens if TCP tries to set up a connection but the address it > > chooses doesn't respond (and there is another address that works > > available)? > As long as there are multiple addresses available the sending node is > free to select any of them as destination address. > I guess an ICMP error message or an upper layer lack of progress signal > would cause a bad address to either be removed or lowered in priority. > Similar ideas are used in Mobile IPv6 today. That would apply to both of > your questions. Yes, but what does the user experience? I can do round robin DNS for two IP numbers for a website and since you can still connect 50% of the time when one address fails, this could be considered a solution. Users won't like it, though. Having a connection setup attempt fail so it has to be retried at the application level is not good enough. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Sep 18 05:37:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17113 for ; Tue, 18 Sep 2001 05:37:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15jHGo-000Boo-00 for multi6-data@psg.com; Tue, 18 Sep 2001 02:34:22 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([194.237.142.116]) by psg.com with esmtp (Exim 3.33 #1) id 15jHGn-000Bog-00 for multi6@ops.ietf.org; Tue, 18 Sep 2001 02:34:21 -0700 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f8I9YEK04917; Tue, 18 Sep 2001 11:34:15 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA09691; Tue, 18 Sep 2001 11:34:14 +0200 Message-ID: <3BA71492.A0B7B6A9@era.ericsson.se> Date: Tue, 18 Sep 2001 11:32:02 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) References: <20010917195522.K21860-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On Mon, 17 Sep 2001, Mattias Pettersson wrote: > > > > - what happens when an address suddenly fails and is no longer reachable? > > > > - what happens if TCP tries to set up a connection but the address it > > > chooses doesn't respond (and there is another address that works > > > available)? > > > As long as there are multiple addresses available the sending node is > > free to select any of them as destination address. > > > I guess an ICMP error message or an upper layer lack of progress signal > > would cause a bad address to either be removed or lowered in priority. > > Similar ideas are used in Mobile IPv6 today. That would apply to both of > > your questions. > > Yes, but what does the user experience? I can do round robin DNS for two > IP numbers for a website and since you can still connect 50% of the time > when one address fails, this could be considered a solution. Users > won't like it, though. > > Having a connection setup attempt fail so it has to be retried at the > application level is not good enough. I agree that the user can't accept that. But what do other proposals do (we are talking about connection setup)? Send TCP SYN to multiple peer addresses? The peer would ignore multiple attempts. I think that was mentioned before. We need mechanisms that will provide the first address of the peer that has a high probability of being reachable. I don't know if DNS can reflect that fast enough. The draft mentions SIP, and such mechanisms that are based on registering are good if the peer knows which of its addresses are reachable and which are not. The draft assumes that we can't read too much stability into the IP addresses of a node. Addresses come and go. As long as you have a session established between two nodes then they can inform each other of address changes. On the other hand, when trying to establish a connection to a node we need fast location management, and that may be something new but not within the scope of this draft. /Mattias From owner-multi6@ops.ietf.org Thu Sep 27 11:37:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04053 for ; Thu, 27 Sep 2001 11:37:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15mdBs-000B0O-00 for multi6-data@psg.com; Thu, 27 Sep 2001 08:35:08 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 15mdBr-000B0H-00 for multi6@ops.ietf.org; Thu, 27 Sep 2001 08:35:07 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id f8RFac802041; Thu, 27 Sep 2001 17:36:38 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 27 Sep 2001 17:36:37 +0200 (CEST) From: Iljitsch van Beijnum To: Mattias Pettersson cc: Subject: Re: Multihoming by IP Layer Address Rewriting (MILAR) In-Reply-To: <3BA71492.A0B7B6A9@era.ericsson.se> Message-ID: <20010927172941.M376-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 18 Sep 2001, Mattias Pettersson wrote: > > Having a connection setup attempt fail so it has to be retried at the > > application level is not good enough. > I agree that the user can't accept that. But what do other proposals do > (we are talking about connection setup)? > Send TCP SYN to multiple peer addresses? The peer would ignore multiple > attempts. I think that was mentioned before. > We need mechanisms that will provide the first address of the peer that > has a high probability of being reachable. Since replicating this information regardless of whether it will be used or not (such as is current practice with BGP) does not scale, the only solution to this is to have the host try. Optionally, the information gathered this way could be stored/shared for further use. > I don't know if DNS can reflect that fast enough. > The draft mentions SIP, and such mechanisms > that are based on registering are good if the peer knows which of its > addresses are reachable and which are not. Which is certainly not something we can rely on... So this means either pinging the host to find a working address before the TCP setup, or just trying the TCP setup and retry it transparently if it fails or takes too long. > The draft assumes that we can't read too much stability into the IP > addresses of a node. Addresses come and go. As long as you have a > session established between two nodes then they can inform each other of > address changes. But I'm not sure if mobile IP does in a way that is robust enough for our purposes. Iljitsch van Beijnum