From owner-multi6@ops.ietf.org Wed Oct 9 15:43:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01289 for ; Wed, 9 Oct 2002 15:43:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zMkR-000L8U-00 for multi6-data@psg.com; Wed, 09 Oct 2002 12:43:59 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17zMkQ-000L88-00 for multi6@ops.ietf.org; Wed, 09 Oct 2002 12:43:58 -0700 Received: from kenawang.windriver.com ([147.11.233.40]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA00648; Wed, 9 Oct 2002 12:42:36 -0700 (PDT) Message-Id: <5.1.0.14.2.20021009154140.04f9dec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 09 Oct 2002 15:42:47 -0400 To: Yoshihiro Ohba From: Margaret Wasserman Subject: Re: multihomed host Cc: ipng@sunroof.eng.sun.com, multi6@ops.ietf.org In-Reply-To: <20021009192841.GI2310@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > >Is there any definition for multihomed "host"? I don't know if there is an official definition, but I have usually heard the term "multihomed host" used to refer to multi-interface systems that do not function as routers (i.e. they don't forward packets). Margaret From owner-multi6@ops.ietf.org Wed Oct 9 18:19:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06383 for ; Wed, 9 Oct 2002 18:19:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zPCF-00001s-00 for multi6-data@psg.com; Wed, 09 Oct 2002 15:20: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.36 #1) id 17zPCE-000Q0n-00 for multi6@ops.ietf.org; Wed, 09 Oct 2002 15:20:50 -0700 content-class: urn:content-classes:message Subject: RE: multihomed host MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 9 Oct 2002 15:21:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B046405E365@server2000> Thread-Topic: multihomed host Thread-Index: AcJv03CVWgQrBF9MSVe0fEonzBlzQAAC4vzw From: "Michel Py" To: , "Margaret Wasserman" Cc: "Yoshihiro Ohba" , , X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA06383 > Yoshihiro Ohba wrote: > I don't know if there is an official definition, but I > have usually heard the term "multihomed host" used to > refer to multi-interface systems that do not function > as routers (i.e. they don't forward packets). Here is my reading of this: 1. Multi-interface host: > Margaret Wasserman wrote: > I don't know if there is an official definition, but I > have usually heard the term "multihomed host" used to > refer to multi-interface systems that do not function > as routers (i.e. they don't forward packets). I agree with Margaret. A host that has multiple interfaces connected to multiple subnets *is* a multihomed host, but... 2. A host that has multiple interfaces with addresses in the same subnet (either to increase throughput or to provide redundancy) is *not* a multihomed host. 3. Single interface, multiple address host: > Bill Sommerfeld wrote: > For what it's worth, I've occasionally heard the > term used in an application-layer context to refer > to hosts having multiple IP addresses rather than/in > addition to multiple interfaces. For v4, I agree with Bill *if* the multiple addresses belong to different subnets. For v6, this is blurry. Would you call multihomed a host that has both a link-local and a regular unicast address on the same interface? I don't think so. On the other hand, > Yoshihiro Ohba wrote: > There may be some scenario in which a single-interface > host is connected to multiple ISPs on the same link, which > seems to be not covered in the usual definition for > "multihomed host". I don't know what to call the model, > but is such a model already common? Or is there any > ongoing work on this model? This is possible as of today; a host that has multiple PA addresses is certainly considered a multihomed host. However, this alone is not a multihoming solution. 4. A host that has a single address but is part of a multihomed site: This would be the case for hosts belonging to a multihomed LIR, or the case of hosts connecting to a MHAP network. I do not call these hosts multihomed. In other words: semantically speaking, the fact that the host is connected to a multihomed router does not make the host itself multihomed, IMHO. Michel. From owner-multi6@ops.ietf.org Wed Oct 9 18:53:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07020 for ; Wed, 9 Oct 2002 18:53:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zPjV-00014B-00 for multi6-data@psg.com; Wed, 09 Oct 2002 15:55: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.36 #1) id 17zPjS-000135-00 for multi6@ops.ietf.org; Wed, 09 Oct 2002 15:55:11 -0700 content-class: urn:content-classes:message Subject: RE: multihomed host MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 9 Oct 2002 15:55:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B04640BD192@server2000> Thread-Topic: multihomed host Thread-Index: AcJv5i+GBJC2QX20Qf+uo/e21ejqigAAGxoA From: "Michel Py" To: Cc: "Margaret Wasserman" , "Yoshihiro Ohba" , , X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA07020 > Bill Sommerfeld wrote: > From the point of view of what applications need to do, > it's safest to assume that all V6 hosts are multiaddressed. Strongly agree. Although multiaddressed does not necessarily mean multihomed, it is likely that part of the multihoming solution is multiadressed hosts. Michel. From owner-multi6@ops.ietf.org Wed Oct 9 21:46:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10144 for ; Wed, 9 Oct 2002 21:46:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zSPD-0005yg-00 for multi6-data@psg.com; Wed, 09 Oct 2002 18:46:27 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6]) by psg.com with esmtp (Exim 3.36 #1) id 17zSPC-0005yU-00 for multi6@ops.ietf.org; Wed, 09 Oct 2002 18:46:26 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id KAA10324 for ; Thu, 10 Oct 2002 10:46:24 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Thu, 10 Oct 2002 10:47:37 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zSP8-0000db-00 for multi6@ops.ietf.org; Thu, 10 Oct 2002 10:46:22 +0900 Message-ID: <20021009192841.GI2310@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline Date: Wed, 9 Oct 2002 15:28:41 -0400 To: ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: multihomed host From: Yoshihiro Ohba X-Spam-Status: No, hits=-1.2 required=5.0 tests=RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, I have one question about multihomed host. In the multi6 WG charter, there is the following definition for multihomed "site": A multihomed site is a site that has more than one connection to the public internet with those connections through either the same or different ISPs. Sites choose to multihome for several reasons, especially to improve fault tolerence, perform load balancing, etc. Is there any definition for multihomed "host"? Of cource, a definition would be quickly made by just replacing a word "site" in the above definition with "host", but please let me know if there is other definition. Regards, Yoshihiro Ohba From owner-multi6@ops.ietf.org Wed Oct 9 21:47:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10184 for ; Wed, 9 Oct 2002 21:47:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zSS4-000635-00 for multi6-data@psg.com; Wed, 09 Oct 2002 18:49:24 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6]) by psg.com with esmtp (Exim 3.36 #1) id 17zSS3-00062t-00 for multi6@ops.ietf.org; Wed, 09 Oct 2002 18:49:23 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id KAA10389 for ; Thu, 10 Oct 2002 10:49:21 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Thu, 10 Oct 2002 10:50:35 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zSS0-0000dq-00 for multi6@ops.ietf.org; Thu, 10 Oct 2002 10:49:20 +0900 Message-ID: <20021009200920.GK2310@catfish> References: <20021009192841.GI2310@catfish> <5.1.0.14.2.20021009154140.04f9dec0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20021009154140.04f9dec0@mail.windriver.com> Date: Wed, 9 Oct 2002 16:09:20 -0400 To: Margaret Wasserman Cc: Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host From: Yoshihiro Ohba X-Spam-Status: No, hits=-7.8 required=5.0 tests=IN_REP_TO,REFERENCES,RESENT_TO,SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Thanks for your quick response. There may be some scenario in which a single-interface host is connected to multiple ISPs on the same link, which seems to be not covered in the usual definition for "multihomed host". I don't know what to call the model, but is such a model already common? Or is there any ongoing work on this model? On Wed, Oct 09, 2002 at 03:42:47PM -0400, Margaret Wasserman wrote: > > > > > > >Is there any definition for multihomed "host"? > > I don't know if there is an official definition, but I > have usually heard the term "multihomed host" used to > refer to multi-interface systems that do not function > as routers (i.e. they don't forward packets). > > Margaret > Thanks, Yoshihiro Ohba From owner-multi6@ops.ietf.org Wed Oct 9 21:48:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10207 for ; Wed, 9 Oct 2002 21:48:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zSSw-00065c-00 for multi6-data@psg.com; Wed, 09 Oct 2002 18:50:18 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6]) by psg.com with esmtp (Exim 3.36 #1) id 17zSSv-00065P-00 for multi6@ops.ietf.org; Wed, 09 Oct 2002 18:50:17 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id KAA10418 for ; Thu, 10 Oct 2002 10:50:16 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Thu, 10 Oct 2002 10:51:28 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zSSr-0000e6-00 for multi6@ops.ietf.org; Thu, 10 Oct 2002 10:50:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200210092031.g99KVSgu023997@thunk.east.sun.com> In-Reply-To: Your message of "Wed, 09 Oct 2002 15:42:47 EDT." <5.1.0.14.2.20021009154140.04f9dec0@mail.windriver.com> From: Bill Sommerfeld To: Margaret Wasserman cc: Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host Date: Wed, 09 Oct 2002 16:31:28 -0400 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > I don't know if there is an official definition, but I > have usually heard the term "multihomed host" used to > refer to multi-interface systems that do not function > as routers (i.e. they don't forward packets). For what it's worth, I've occasionally heard the term used in an application-layer context to refer to hosts having multiple IP addresses rather than/in addition to multiple interfaces. - Bill From owner-multi6@ops.ietf.org Wed Oct 9 22:05:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10399 for ; Wed, 9 Oct 2002 22:05:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zSjE-0006Sm-00 for multi6-data@psg.com; Wed, 09 Oct 2002 19:07:08 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6]) by psg.com with esmtp (Exim 3.36 #1) id 17zSjC-0006ST-00 for multi6@ops.ietf.org; Wed, 09 Oct 2002 19:07:06 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id LAA11035 for ; Thu, 10 Oct 2002 11:07:05 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Thu, 10 Oct 2002 11:08:17 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zSj9-0000fX-00 for multi6@ops.ietf.org; Thu, 10 Oct 2002 11:07:03 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200210092248.g99MmWgu025186@thunk.east.sun.com> In-Reply-To: Your message of "Wed, 09 Oct 2002 15:21:34 PDT." <2B81403386729140A3A899A8B39B046405E365@server2000> From: Bill Sommerfeld To: "Michel Py" cc: sommerfeld@east.sun.com, "Margaret Wasserman" , "Yoshihiro Ohba" , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host Date: Wed, 09 Oct 2002 18:48:32 -0400 X-Spam-Status: No, hits=-7.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > For v4, I agree with Bill *if* the multiple addresses belong to > different subnets. > > For v6, this is blurry. Would you call multihomed a host that has both a > link-local and a regular unicast address on the same interface? I don't > think so. >From the point of view of what applications need to do, it's safest to assume that all V6 hosts are multiaddressed. - Bill From owner-multi6@ops.ietf.org Wed Oct 9 22:14:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10628 for ; Wed, 9 Oct 2002 22:14:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zSsU-0006hd-00 for multi6-data@psg.com; Wed, 09 Oct 2002 19:16:42 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6]) by psg.com with esmtp (Exim 3.36 #1) id 17zSsT-0006hQ-00 for multi6@ops.ietf.org; Wed, 09 Oct 2002 19:16:41 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id LAA11282 for ; Thu, 10 Oct 2002 11:16:40 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Thu, 10 Oct 2002 11:17:54 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zSsR-0000gD-00 for multi6@ops.ietf.org; Thu, 10 Oct 2002 11:16:39 +0900 Message-ID: <20021009232056.GN2310@catfish> References: <2B81403386729140A3A899A8B39B046405E365@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046405E365@server2000> Date: Wed, 9 Oct 2002 19:20:56 -0400 To: Michel Py Cc: sommerfeld@East.sun.com, Margaret Wasserman , Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host From: Yoshihiro Ohba X-Spam-Status: No, hits=-10.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Thank you all for helping me understand. I have additional question below. On Wed, Oct 09, 2002 at 03:21:34PM -0700, Michel Py wrote: > On the other hand, > > Yoshihiro Ohba wrote: > > There may be some scenario in which a single-interface > > host is connected to multiple ISPs on the same link, which > > seems to be not covered in the usual definition for > > "multihomed host". I don't know what to call the model, > > but is such a model already common? Or is there any > > ongoing work on this model? > > This is possible as of today; a host that has multiple PA addresses is > certainly considered a multihomed host. However, this alone is not a > multihoming solution. > What additional things need to be considered for this usage to become a multihoming solution? Yoshihiro Ohba From owner-multi6@ops.ietf.org Wed Oct 9 22:40:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11584 for ; Wed, 9 Oct 2002 22:40:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zTHC-0007IY-00 for multi6-data@psg.com; Wed, 09 Oct 2002 19:42:14 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6]) by psg.com with esmtp (Exim 3.36 #1) id 17zTHB-0007IH-00 for multi6@ops.ietf.org; Wed, 09 Oct 2002 19:42:13 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id LAA12173 for ; Thu, 10 Oct 2002 11:42:12 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Thu, 10 Oct 2002 11:43:26 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zTH9-0000iq-00 for multi6@ops.ietf.org; Thu, 10 Oct 2002 11:42:11 +0900 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: Thread-Topic: multihomed host Thread-Index: AcJwBkorD+WRLQRvSxikDZwFKxpMbw== Subject: RE: multihomed host Date: Wed, 9 Oct 2002 21:39:44 -0500 From: "Ragib, Husain B (UMKC-Student)" To: X-Spam-Status: No, hits=-1.2 required=5.0 tests=RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA11584 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Multi-Homed Hosts: These are any machines which has more than one interface to connect to multiple networks. There are lots of complication involved when thinking in terms of Multi-homed hosts, such as routing tables entrys and local hosts IP address translations to name a few. An interesting point to note in Multi-Homed hosts is that it can be visaulised as a normal computer with two NIC and two IP address of two diffrent networks. Here it could just be sitting and recieving traffic from both network and rarely if anytime be involved in routing functions.(Or else it would become a Router..Though there is a distinction between those two..] hope this helps.. Husain -----Original Message----- From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On Behalf Of Bill Sommerfeld Sent: Wednesday, October 09, 2002 3:31 PM To: Margaret Wasserman Cc: Yoshihiro Ohba; ipng@sunroof.eng.sun.com; multi6@ops.ietf.org Subject: Re: multihomed host [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > I don't know if there is an official definition, but I > have usually heard the term "multihomed host" used to > refer to multi-interface systems that do not function > as routers (i.e. they don't forward packets). For what it's worth, I've occasionally heard the term used in an application-layer context to refer to hosts having multiple IP addresses rather than/in addition to multiple interfaces. - Bill From owner-multi6@ops.ietf.org Thu Oct 10 02:10:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23398 for ; Thu, 10 Oct 2002 02:10:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zWWe-000BKw-00 for multi6-data@psg.com; Wed, 09 Oct 2002 23:10:24 -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.36 #1) id 17zWWc-000BKk-00 for multi6@ops.ietf.org; Wed, 09 Oct 2002 23:10:22 -0700 content-class: urn:content-classes:message Subject: RE: multihomed host MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 9 Oct 2002 23:11:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B046405E369@server2000> Thread-Topic: multihomed host Thread-Index: AcJv6s3SpmocDFsoSuG9IRHUzk8BuwAN8WZA From: "Michel Py" To: "Yoshihiro Ohba" Cc: , "Margaret Wasserman" , , X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA23398 >>> Yoshihiro Ohba wrote: >>> There may be some scenario in which a single-interface >>> host is connected to multiple ISPs on the same link, which >>> seems to be not covered in the usual definition for >>> "multihomed host". I don't know what to call the model, >>> but is such a model already common? Or is there any >>> ongoing work on this model? >> Michel Py wrote: >> This is possible as of today; a host that has multiple PA >> addresses is certainly considered a multihomed host. >> However, this alone is not a multihoming solution. > What additional things need to be considered for this > usage to become a multihoming solution? There is no simple answer to this question. Here is one approach: http://arneill-py.sacramento.ca.us/ipv6mh/draft-bagnulo-mhExtHdr-00.txt Michel. From owner-multi6@ops.ietf.org Thu Oct 10 03:02:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24112 for ; Thu, 10 Oct 2002 03:02:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zXMw-000Cj2-00 for multi6-data@psg.com; Thu, 10 Oct 2002 00:04:26 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 17zXMt-000Ciq-00 for multi6@ops.ietf.org; Thu, 10 Oct 2002 00:04:24 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9A72YS88790; Thu, 10 Oct 2002 09:02:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 10 Oct 2002 09:02:34 +0200 (CEST) From: Iljitsch van Beijnum To: Yoshihiro Ohba cc: , Subject: Re: multihomed host In-Reply-To: <20021009232056.GN2310@catfish> Message-ID: <20021010084219.O85622-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 9 Oct 2002, Yoshihiro Ohba wrote: > > This is possible as of today; a host that has multiple PA addresses is > > certainly considered a multihomed host. However, this alone is not a > > multihoming solution. > What additional things need to be considered for this usage to become > a multihoming solution? A good multihoming solution keeps working if there are failures. So the applications must be smart enough to try all the addresses rather than just one. Telnet and FTP do this, WWW clients typically don't. Unfortunately, this must be done at the remote end and not on the multi(homed|addressed) host itself. When there is a session, and the path over one ISP becomes unavailable, the multihomed host must switch to the path over the other ISP. There are many problems with this. First of all, the failure must be detected. Then the host can reroute outgoing packets. But if the host still uses the same source address (from the address space from the failed ISP), it is likely the packets won't be accepted by the alternate ISP because the source addresses are "spoofed". And even if they are, the communications partner keeps sending packets back to th source address tied to the first ISP, which isn't reachable any more. One solution for the address problem would be the adoption of new or improved transport protocols that can handle this. There have been experiments with modifications to TCP to support this, and the new SCTP protocol can also handle this. However, modifying all transport protocols might be problematic. Another solution is tunnelling/aliasing the packet to hide the original address while the packet is rerouted over the alternative path. The destination host or a box very close to the destination host strips of the tunnel header or replaces the original address so TCP and other transport protocols don't see the change in address. Some of us are working on this stuff on a non-IETF mailinglist. The latest idea is to come up with a common tunnelling/aliasing framework so different solutions in this area may interoperate. From owner-multi6@ops.ietf.org Thu Oct 10 14:45:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19392 for ; Thu, 10 Oct 2002 14:45:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17ziJO-0001vX-00 for multi6-data@psg.com; Thu, 10 Oct 2002 11:45:30 -0700 Received: from styx.org ([205.189.139.145]) by psg.com with esmtp (Exim 3.36 #2) id 17ziJM-0001s0-00 for multi6@ops.ietf.org; Thu, 10 Oct 2002 11:45:28 -0700 Received: by STYX.ORG (Postfix, from userid 1001) id F38984CF3; Thu, 10 Oct 2002 14:44:54 -0400 (EDT) To: Bill Sommerfeld Cc: Margaret Wasserman , Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: Re: multihomed host References: <200210092031.g99KVSgu023997@thunk.east.sun.com> Organization: Idiosyntactix Research Laboratories From: William Waites Date: 10 Oct 2002 14:44:54 -0400 In-Reply-To: <200210092031.g99KVSgu023997@thunk.east.sun.com> Message-ID: <86smzecevt.fsf@styx.org> Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-11.2 required=5.0 tests=IN_REP_TO,NOSPAM_INC,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk >>> "Bill" == Bill Sommerfeld writes: Bill> For what it's worth, I've occasionally heard the term used Bill> in an application-layer context to refer to hosts having Bill> multiple IP addresses rather than/in addition to multiple Bill> interfaces. This just looks like the degenerate case -- multiple addresses, multiple interfaces, except that each of the multiple interfaces happen to be the same. It seems to me that the network layer code should treat both cases identically. Does this make sense? -w -- William Waites Idiosyntactix Research Laboratories Any sufficiently advanced technology http://www.irl.styx.org is indistinguishable from a rigged demo. From owner-multi6@ops.ietf.org Thu Oct 10 15:26:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20694 for ; Thu, 10 Oct 2002 15:26:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17ziz6-0003Jq-00 for multi6-data@psg.com; Thu, 10 Oct 2002 12:28:36 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 17ziz4-0003Jd-00 for multi6@ops.ietf.org; Thu, 10 Oct 2002 12:28:34 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9AJQxW89772; Thu, 10 Oct 2002 21:26:59 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 10 Oct 2002 21:26:59 +0200 (CEST) From: Iljitsch van Beijnum To: William Waites cc: , Subject: Re: multihomed host In-Reply-To: <86smzecevt.fsf@styx.org> Message-ID: <20021010212526.X85622-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On 10 Oct 2002, William Waites wrote: > Bill> For what it's worth, I've occasionally heard the term used > Bill> in an application-layer context to refer to hosts having > Bill> multiple IP addresses rather than/in addition to multiple > Bill> interfaces. > This just looks like the degenerate case -- multiple addresses, > multiple interfaces, except that each of the multiple interfaces > happen to be the same. It seems to me that the network layer code > should treat both cases identically. Does this make sense? There is one difference that may be important sometimes, but inconsequential at other times: a host can detect that an interface is down. It can't necessarily detect the link to an ISP is down. From owner-multi6@ops.ietf.org Thu Oct 10 16:05:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22121 for ; Thu, 10 Oct 2002 16:05:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zjYg-0004Ro-00 for multi6-data@psg.com; Thu, 10 Oct 2002 13:05:22 -0700 Received: from styx.org ([205.189.139.145]) by psg.com with esmtp (Exim 3.36 #2) id 17zjYe-0004Pv-00 for multi6@ops.ietf.org; Thu, 10 Oct 2002 13:05:20 -0700 Received: by STYX.ORG (Postfix, from userid 1001) id 3B1BB4CF3; Thu, 10 Oct 2002 16:04:49 -0400 (EDT) To: Iljitsch van Beijnum Cc: , Subject: Re: multihomed host References: <20021010212526.X85622-100000@sequoia.muada.com> Organization: Idiosyntactix Research Laboratories From: William Waites Date: 10 Oct 2002 16:04:48 -0400 In-Reply-To: <20021010212526.X85622-100000@sequoia.muada.com> Message-ID: <86it0acb6n.fsf@styx.org> Lines: 28 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-15.4 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk >>> "Iljitsch" == Iljitsch van Beijnum writes: Iljitsch> There is one difference that may be important sometimes, Iljitsch> but inconsequential at other times: a host can detect Iljitsch> that an interface is down. It can't necessarily detect Iljitsch> the link to an ISP is down. But the "physical interface is down" failure mode is relatively rare -- as soon as an ethernet switch, or ethernet to atm or mpls bridge is thrown into the mix, the "physical interface is up but link layer is down" failure mode becomes much more common. In fact it subsumes the first case since if there's no physical interface, there's no link layer. Is the correct place to implement detection of these types of failures in the link layer? But then the providers have to play nicely, and it says nothing about problems more than one hop out in the ISP's network. Or beyond the ISP's AS even... I guess I am not sure where in the stack the failure detection belongs, or which types of failures are to be addressed here... -w -- William Waites Any sufficiently advanced Idiosyntactix Research Laboratories technology is indistinguishable http://www.irl.styx.org from a rigged demo. From owner-multi6@ops.ietf.org Thu Oct 10 16:19:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22447 for ; Thu, 10 Oct 2002 16:19:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zjmh-0004zZ-00 for multi6-data@psg.com; Thu, 10 Oct 2002 13:19:51 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 17zjme-0004zL-00 for multi6@ops.ietf.org; Thu, 10 Oct 2002 13:19:48 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9AKFbp89879; Thu, 10 Oct 2002 22:15:37 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 10 Oct 2002 22:15:37 +0200 (CEST) From: Iljitsch van Beijnum To: William Waites cc: , Subject: Re: multihomed host In-Reply-To: <86it0acb6n.fsf@styx.org> Message-ID: <20021010220846.P85622-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On 10 Oct 2002, William Waites wrote: > Iljitsch> There is one difference that may be important sometimes, > Iljitsch> but inconsequential at other times: a host can detect > Iljitsch> that an interface is down. It can't necessarily detect > Iljitsch> the link to an ISP is down. > But the "physical interface is down" failure mode is relatively rare > -- as soon as an ethernet switch, or ethernet to atm or mpls bridge > is thrown into the mix, the "physical interface is up but link layer > is down" That's the whole problem with switched networks: you can't detect failures at layer 2, so you have to do it at layer 3. (The problem could have been in layer 3 in the first place, so you have to detect layer 3 problems anyway.) I wouldn't discount the usefulness of being able to detect failures at layer 1: this is much, much faster than anything else. > Is the correct place to implement detection of these types of failures > in the link layer? But then the providers have to play nicely, and it > says nothing about problems more than one hop out in the ISP's > network. Or beyond the ISP's AS even... > I guess I am not sure where in the stack the failure detection > belongs, or which types of failures are to be addressed here... Failure detection is one of the major challenges in multihoming solutions that aren't router-based. My thinking is that TCP should signal the IP layer that there _may_ be a problem and the IP layer should either act as if there is, or make sure first. In any event, it has to be end-to-end. Unfortunately, this doesn't mean you can leave it out at the lower layers, since failure detection at layer 4 is very slow (TCP timeout...) and you don't want to have to do this time and time again when going back to the same destination. From owner-multi6@ops.ietf.org Thu Oct 10 18:39:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26201 for ; Thu, 10 Oct 2002 18:39:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zly2-0009jN-00 for multi6-data@psg.com; Thu, 10 Oct 2002 15:39:42 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 17zly0-0009iz-00 for multi6@ops.ietf.org; Thu, 10 Oct 2002 15:39:40 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9AMdFKV012071; Fri, 11 Oct 2002 00:39:15 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <44LQ3NKS>; Fri, 11 Oct 2002 00:39:15 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0B2D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'William Waites'" , Bill Sommerfeld Cc: Margaret Wasserman , Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org Subject: RE: multihomed host Date: Fri, 11 Oct 2002 00:39:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-1.2 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > >>> "Bill" == Bill Sommerfeld writes: > > Bill> For what it's worth, I've occasionally heard > the term used > Bill> in an application-layer context to refer to > hosts having > Bill> multiple IP addresses rather than/in addition > to multiple > Bill> interfaces. > > This just looks like the degenerate case -- multiple > addresses, > multiple interfaces, except that each of the multiple > interfaces > happen to be the same. It seems to me that the network > layer code > should treat both cases identically. Does this make sense? => I don't think so. There is a difference in existing standards (2461) and implementations between the 2 cases. A multiaddressed node with a single interface assumes that any address can be used as a source address with any default router. This is clearly not a good assumption for multi-interfaced (multihomed) nodes Hesham From owner-multi6@ops.ietf.org Thu Oct 10 20:35:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27649 for ; Thu, 10 Oct 2002 20:35:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17znlz-000Dgk-00 for multi6-data@psg.com; Thu, 10 Oct 2002 17:35:23 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17znly-000DgD-00 for multi6@ops.ietf.org; Thu, 10 Oct 2002 17:35:22 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id JAA05871 for ; Fri, 11 Oct 2002 09:35:20 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Fri, 11 Oct 2002 09:36:35 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17znlv-000Gbu-00 for multi6@ops.ietf.org; Fri, 11 Oct 2002 09:35:19 +0900 Message-ID: <20021010152035.GB682@catfish> References: <2B81403386729140A3A899A8B39B046405E369@server2000> <20021009232056.GN2310@catfish> <20021010084219.O85622-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046405E369@server2000> <20021010084219.O85622-100000@sequoia.muada.com> Date: Thu, 10 Oct 2002 11:20:35 -0400 To: Iljitsch van Beijnum , Michel Py Cc: Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org, sommerfeld@East.sun.com, Margaret Wasserman Subject: Re: multihomed host From: Yoshihiro Ohba X-Spam-Status: No, hits=-10.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Thanks Iljitsch for detailed answer and Michel for the pointer. Actually, I'm working in the PANA WG and viewing this kind of multihomed host scenario from network access authentication perspective, and wondering whether the PANA WG needs to consider this scenario for now. (My impression is that there is a lot of work to consider before considering network access authentication) Yoshihiro Ohba On Thu, Oct 10, 2002 at 09:02:34AM +0200, Iljitsch van Beijnum wrote: > On Wed, 9 Oct 2002, Yoshihiro Ohba wrote: > > > > This is possible as of today; a host that has multiple PA addresses is > > > certainly considered a multihomed host. However, this alone is not a > > > multihoming solution. > > > What additional things need to be considered for this usage to become > > a multihoming solution? > > A good multihoming solution keeps working if there are failures. So the > applications must be smart enough to try all the addresses rather than > just one. Telnet and FTP do this, WWW clients typically don't. > Unfortunately, this must be done at the remote end and not on the > multi(homed|addressed) host itself. > > When there is a session, and the path over one ISP becomes unavailable, > the multihomed host must switch to the path over the other ISP. There are > many problems with this. First of all, the failure must be detected. Then > the host can reroute outgoing packets. But if the host still uses the same > source address (from the address space from the failed ISP), it is likely > the packets won't be accepted by the alternate ISP because the source > addresses are "spoofed". And even if they are, the communications partner > keeps sending packets back to th source address tied to the first ISP, > which isn't reachable any more. > > One solution for the address problem would be the adoption of new or > improved transport protocols that can handle this. There have been > experiments with modifications to TCP to support this, and the new SCTP > protocol can also handle this. However, modifying all transport protocols > might be problematic. > > Another solution is tunnelling/aliasing the packet to hide the original > address while the packet is rerouted over the alternative path. The > destination host or a box very close to the destination host strips of the > tunnel header or replaces the original address so TCP and other transport > protocols don't see the change in address. > > Some of us are working on this stuff on a non-IETF mailinglist. The latest > idea is to come up with a common tunnelling/aliasing framework so > different solutions in this area may interoperate. > > On Wed, Oct 09, 2002 at 11:11:09PM -0700, Michel Py wrote: > >>> Yoshihiro Ohba wrote: > >>> There may be some scenario in which a single-interface > >>> host is connected to multiple ISPs on the same link, which > >>> seems to be not covered in the usual definition for > >>> "multihomed host". I don't know what to call the model, > >>> but is such a model already common? Or is there any > >>> ongoing work on this model? > > >> Michel Py wrote: > >> This is possible as of today; a host that has multiple PA > >> addresses is certainly considered a multihomed host. > >> However, this alone is not a multihoming solution. > > > What additional things need to be considered for this > > usage to become a multihoming solution? > > There is no simple answer to this question. Here is one approach: > http://arneill-py.sacramento.ca.us/ipv6mh/draft-bagnulo-mhExtHdr-00.txt > > Michel. > > From owner-multi6@ops.ietf.org Fri Oct 11 11:11:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25012 for ; Fri, 11 Oct 2002 11:11:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1801S6-000GUJ-00 for multi6-data@psg.com; Fri, 11 Oct 2002 08:11:46 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #2) id 1801S4-000GTd-00 for multi6@ops.ietf.org; Fri, 11 Oct 2002 08:11:44 -0700 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20803; Fri, 11 Oct 2002 08:11:14 -0700 (PDT) Received: from localhost (lillen.France.Sun.COM [129.157.212.23]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with SMTP id g9BFBBQl732575; Fri, 11 Oct 2002 08:11:12 -0700 (PDT) Date: Fri, 11 Oct 2002 15:15:30 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: multihomed host To: William Waites Cc: Bill Sommerfeld , Margaret Wasserman , Yoshihiro Ohba , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org In-Reply-To: "Your message with ID" <86smzecevt.fsf@styx.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > This just looks like the degenerate case -- multiple addresses, > multiple interfaces, except that each of the multiple interfaces > happen to be the same. It seems to me that the network layer code > should treat both cases identically. Does this make sense? There are some important differences when it comes to the relationship between IP source address and routes that are used. draft-ietf-ipv6-default-addr-select-09.txt specifies that the candidate source address are related to the interface on which a packet is sent. Hence there is a difference between case 1: Host with one interface, two routers, two global addresses with different prefixes (whether one router advertises each addrconf prefix or both routers advertise both prefixes). In this case the candidate source address will be both global addresses, and the other rules in the source address selection will determine which source address is used. Note that there is no relationship between the source address selected and which (default) router is used for sending packets. case 2: Host with two interface, one router on each interface, one global address being configured on each interface with different prefixes (each router advertises a single addrconf prefix) In this case the candidate source address set will be coupled to the (default) route used to send the packet, since there are two interfaces. In both cases there are issues of what happens when e.g. one of the routers fail, which have to do with not only how the host behaves but also how routing works beyond the first hop routers. Erik From owner-multi6@ops.ietf.org Thu Oct 17 07:11:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05956 for ; Thu, 17 Oct 2002 07:11:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1828Yo-000Dz1-00 for multi6-data@psg.com; Thu, 17 Oct 2002 04:11:26 -0700 Received: from smtp03.uc3m.es ([163.117.136.123] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #2) id 1828Yl-000Dyp-00 for multi6@ops.ietf.org; Thu, 17 Oct 2002 04:11:23 -0700 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id CFBF7431E5 for ; Thu, 17 Oct 2002 13:11:15 +0200 (CEST) Received: from it.uc3m.es (mira.it.uc3m.es [163.117.140.166]) by smtp03.uc3m.es (Postfix) with ESMTP id AB5F399E10 for ; Thu, 17 Oct 2002 13:11:15 +0200 (CEST) Message-ID: <3DAE9AD3.4DB9F384@it.uc3m.es> Date: Thu, 17 Oct 2002 13:11:15 +0200 From: Juan Francisco Rodriguez Hervella X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.5-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: (ipv6mh) about MHAP draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.4 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi: I'm trying to understand this draft, but there are a lot of terminology and definitions at the beginning and I don't see the main idea clearly. How does it work ? I think it's worth to underline the features and try to explain how this works *briefly*, maybe in another paper ? (I've got on my table over 50 pages !!). PS: If someday someone wants to apply this solution, likely he will fed up of reading this paper. Don't get angry with me, I'm making a positive review :) Regards. -- JFRH. From owner-multi6@ops.ietf.org Thu Oct 17 13:04:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17869 for ; Thu, 17 Oct 2002 13:04:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182E5g-000OSE-00 for multi6-data@psg.com; Thu, 17 Oct 2002 10:05:44 -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.36 #2) id 182E5e-000ORz-00 for multi6@ops.ietf.org; Thu, 17 Oct 2002 10:05:42 -0700 content-class: urn:content-classes:message Subject: RE: (ipv6mh) about MHAP draft Date: Thu, 17 Oct 2002 10:05:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B04640BD1EA@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: (ipv6mh) about MHAP draft Thread-Index: AcJ1z7n+348JpnzARDmQ5M/YYrEGgQAL5iiw From: "Michel Py" To: "Juan Francisco Rodriguez Hervella" , Cc: "ipv6mh" X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA17869 > Juan Francisco Rodriguez Hervella wrote: > I'm trying to understand this draft, but there are a > lot of terminology and definitions at the beginning and > I don't see the main idea clearly. How does it work ? > I think it's worth to underline the features and try to > explain how this works *briefly*, maybe in another paper ? Here is the main idea: 6.1.24. The general principle of address aliasing is as follows: - Multihomed traffic is to be aliased and carried over the Internet as singlehomed traffic. - When the IPv6 packet or datagram is processed by the first aliasing- capable router along its path (an MHAP client in most situations) the multihomed destination IPv6 address is replaced with one of the possible singlehomed PA addresses. - When this aliased packet reaches the destination site's MHAP endpoint, the singlehomed destination PA address is replaced (unaliased) with the original multihomed destination address. - Contrary to most NATs, MHAP replaces the destination address, not the source. Here is the sales pitch: MHAP Features: -------------- - Zero impact on the DFZ's routing table. The DFZ's routing table stays strongly aggregated. - Provides multihomed, provider-independent, /48 address space for any site. - Very large organizations that require more can get a /47 or bigger. - Scalable (4 billion multihomed sites, initial allocation). - Addresses are aggregated at geographic areas boundaries. - There is no need for Internet eXchanges at aggregation boundaries. - MHAP is transparent to hosts. No modification of existing stacks is required and end-to-end traffic is unchanged. - More than 90% of routers would not require modification. - Provides global load balancing. - Provides survivability of open sessions. - There is no MTU reduction. - Can be run on hardware available today. - Gradual migration, no "flag day". - IPv6 only protocol. - MHAP provides site multihoming. ISP multihoming is unchanged. MHAP Concepts: -------------- - Multihomed address space exists only at the edge. The end-to-end multihomed traffic is carried over aggregated PA address space in the core. - A site gets PA addresses from ISPs and multihomed provider-independent space from a registry. - The process of transforming multihomed traffic to PA and back is called aliasing and relies on the presence of rendezvous points and aggregators. - Rendezvous points and aggregators answer topology requests. They do not carry traffic. - There is a separation between the DFZ's routing table and the multihomed space routing tables. The entire multihomed space is represented by two aggregates in the DFZ's routing table. - The only multihomed traffic on backbones is topology requests and routing updates. - There are two types of multihomed addresses: o Centralized, portable, for large multinational organizations. o Geographical, portable only within a geographic area. - There is no centralized table for geographic addresses. - The routing table for centralized prefixes remains contained to rendezvous points. - No multihomed site receives full multihomed tables. All a multihomed site needs is the small DFZ's routing table. > If someday someone wants to apply this solution, likely > he will fed up of reading this paper. Don't get angry > with me, I'm making a positive review :) I know this, the draft is due for a complete rewrite for Atlanta.... Michel. From owner-multi6@ops.ietf.org Thu Oct 17 13:53:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19813 for ; Thu, 17 Oct 2002 13:53:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182Epn-0000Jk-00 for multi6-data@psg.com; Thu, 17 Oct 2002 10:53:23 -0700 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #2) id 182Epm-0000JU-00 for multi6@ops.ietf.org; Thu, 17 Oct 2002 10:53:22 -0700 Received: (qmail 26344 invoked by uid 0); 17 Oct 2002 17:53:20 -0000 Received: from localhost.automagic.org (HELO automagic.org) (127.0.0.1) by localhost.automagic.org with SMTP; 17 Oct 2002 17:53:20 -0000 Date: Thu, 17 Oct 2002 13:53:18 -0400 Subject: Re: (ipv6mh) about MHAP draft Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Juan Francisco Rodriguez Hervella" , , "ipv6mh" To: "Michel Py" From: Joe Abley In-Reply-To: <2B81403386729140A3A899A8B39B04640BD1EA@server2000> Message-Id: <51D450B0-E1F9-11D6-8641-00039312C852@automagic.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Michael, Sorry to say, I haven't read your draft, so excuse me if the following question is stupid. On Thursday, Oct 17, 2002, at 13:05 Canada/Eastern, Michel Py wrote: > Here is the main idea: ... > - When the IPv6 packet or datagram is processed by the first aliasing- > capable router along its path (an MHAP client in most situations) the > multihomed destination IPv6 address is replaced with one of the > possible singlehomed PA addresses. So, your proposal is, in effect, a coordinated deployment of NAT at ISP or site borders? > Here is the sales pitch: ... > - MHAP provides site multihoming. ISP multihoming is unchanged. What is the difference between a site and an ISP? Does your proposal introduce different end-to-end behaviour according to whether two communicating hosts are behind the same NAT, or whether there is one more NAT between them? > MHAP Concepts: ... > - Rendezvous points and aggregators answer topology requests. They do > not carry traffic. What are the failure modes for control-plane devices which do not participate in traffic flow? Joe From owner-multi6@ops.ietf.org Mon Oct 21 17:25:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16107 for ; Mon, 21 Oct 2002 17:25:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183k3Y-0000W3-00 for multi6-data@psg.com; Mon, 21 Oct 2002 14:25:48 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 183k3V-0000Vo-00 for multi6@ops.ietf.org; Mon, 21 Oct 2002 14:25:45 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9LLOBL15151 for ; Mon, 21 Oct 2002 23:24:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 21 Oct 2002 23:24:10 +0200 (CEST) From: Iljitsch van Beijnum To: Subject: The state of IPv6 multihoming development Message-ID: <20021018220452.R2978-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk In order to kickstart some activity in this wg, here is my view on the current state of multihoming in IPv6 development. I hope this will start a discussion on this here mailinglist, and also elsewhere, because I don't think we can solve the entire problem right here, right now. Since waiting for "someone else" to completely solve the problem hasn't been very productive so far, I think everyone should assume responsibility for that part of the solution space he or she has any control over. There are things that can be done to help multihoming in operations, address allocation policy and application, host stack and router development. Lack of cooperation from even one of those will hurt the multihoming in IPv6 effort. The problem ----------- The user problem: the internet is unreliable. Parts of it fail from time to time. The only way to really protect yourself against this is having several connections to the internet over different ISPs (multihome). The IETF problem: multihoming by announcing a globally visible address block (as is current practice in IPv4) doesn't scale to a large enough number of multihomed sites. A number of new drafts and revised versions of existing drafts will be out in time for Atlanta. 1. Application solutions ------------------------ One way to solve this would be by taking provider aggregatable addresses (that don't polute the global routing table and thus scale well) from two (or more) ISPs and give all systems addresses from both ranges. Then applications simply try all addresses. This has many drawbacks. For instance, sessions still break if there is a problem, and source address selection is problematic, especially in the presence of anti-spoofing filtering by ISPs. But the good part is it actually works today, to some degree. For instance, I can list several IP addresses for an FTP server, and when the first one is down the FTP program simply tries the next. Unfortunatley, the applications must support this, and most of the newer ones (especially web browsers) don't. 2. Transport protocol solutions ------------------------------- It is also possible to solve the problem at the transport layer. This has most of the drawbacks of solving the problem at the application layer, such as the source address selection/filtering issue. But also the fact that applications have to be changed: unfortunately, the IPv6 API as described in RFC 2292 centers around a single IPv6 address. Therefore, an application wishing to use an address-agile transport protocol must be changed in order to provide the extra address or addresses to the transport layer. Alternatively, the transport layer could incorporate a mechanism to discover alternate addresses, but this leads to security problems as applications would be unaware of the addresses they use. Transport-layer solutions only solve the multihoming problem for applications using the specific transport protocol so they only provide a partial solution. 3. Routing implementation solutions ----------------------------------- Current routers easily need upto a kilobyte or even more memory for each individual prefix that is visible in the global routing table. In theory, it should be possible to reduce this by one or two orders of magnitude by removing information that doesn't directly lead to better routing decisions. However, this requires major changes to the internals of routers and the potential gain is relatively limited. 4. Geographical aggregation --------------------------- By confining the reachability information for multihomed prefixes to the geographical region where the multihomed network is connected, it is possible to keep the size of the routing tables in individual routers small while the global routing table gets bigger. The downside is that all aggregation implies loss of information, which means less optimal routing. Also, aggregation across network boundaries is complex. Geographical aggregation can only work in the presence of a compatible address allocation policy. 5. Tunnelling or aliasing solutions ----------------------------------- As a rule, current transport protocols do not have the capability to switch soure/destination addresses when the addresses that are used no longer provide connectivity, even if other addresses that are tied to another physical or logical path that doesn't share the problem are available. Such an alternate path can still be used by tunnelling the original packets with the broken addresses. An optimization to tunnelling is to simply rewrite the original addresses with the alternate ones at (or close to) the source, and write back the original addresses at (or close to) the destination. This is called aliasing and has the advantage the size of the packet remains the same. Aliasing has superficial similarities to NAT, but it is fundamentally different as the destination sees the same addresses as the source. Note the resemblance to mobility. A major problem with tunnelling/aliasing solutions is the discovery of the alternate addresses, and the security of these discovery mechanisms. What have we learned -------------------- In discussions on this mailinglist and elsewhere, I've come to the following conlusions: * The operations people really want/need multihoming. Current 6bone guidelines (which are treated as law in many circles) forbid announcing non-pTLA blocks with the result not even internet exchanges or regional internet registries can be provider independent. * There is a lot of overlap between mobility and some of the multihoming solution space. It is likely that mobility can be extended to support host multihoming. * GSE is interesting, but it doesn't provide much multihoming support. * Applications behaving in a multi-address aware manner could very easily support some bare-bones host multihoming. * Hosts having multiple addresses from different ISP PA blocks doesn't currently work in practice. This could be solved by having systems (mainly hosts, but possibly also routers) taking the source address into account when making routing decisions. * Larg(er) organizations will do just about anything to avoid renumbering, this is NOT "free" or even particularly easy in IPv6. * Very few organizations want or need to connect to the internet at geographical locations that are very far apart and provide "internal transit" for non-backup purposes. * Some organizations that have a relatively large block of address space de-aggregate to avoid having to use their internal network for transit. What we should do ----------------- This is what I think this wg should do: 0. Move past the requirements. There is consensus--sort of. It's not going to get much better than this. 1. Make recommendations to developers and other wgs about what they can do to better support multihoming. 2. Several tunnelling/aliasing solutions have been proposed. It would be good if those could interoperate. This would make it possible for a multihomed host with (for instance) modified mobility support, to interact in a multihomed-meaningful way with a host sitting behind a cluster of big aliasing boxes. This would greatly relieve the chicken/egg problem for this type of solution and make experimentation with the really hard part (discovery and its security) easier. So we should come up with a protocol that makes this interoperation possible. 3. Open the lines of communication with people working on mobility. 4. Work on geographical aggregation, especially by getting an address allocation mechanism that supports this off the ground. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Oct 21 21:52:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21703 for ; Mon, 21 Oct 2002 21:52:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183oAf-0005FH-00 for multi6-data@psg.com; Mon, 21 Oct 2002 18:49:25 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 183oAP-0005Ed-00 for multi6@ops.ietf.org; Mon, 21 Oct 2002 18:49:09 -0700 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 21 Oct 2002 18:48:38 -0700 Reply-To: From: "Tony Hain" To: "'Iljitsch van Beijnum'" , Subject: RE: The state of IPv6 multihoming development Date: Mon, 21 Oct 2002 18:48:24 -0700 Message-ID: <00dd01c2796d$1c0c00a0$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021018220452.R2978-100000@sequoia.muada.com> X-Spam-Status: No, hits=-4.3 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > ... > 4. Work on geographical aggregation, especially by getting an address > allocation mechanism that supports this off the ground. To which I submit: http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-03.txt http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt Comments welcome... Tony From owner-multi6@ops.ietf.org Tue Oct 22 03:51:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08014 for ; Tue, 22 Oct 2002 03:51:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183tpx-000Az6-00 for multi6-data@psg.com; Tue, 22 Oct 2002 00:52:25 -0700 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 183tpv-000Ayb-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 00:52:23 -0700 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9M7phxF009278; Tue, 22 Oct 2002 00:51:43 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9M7pj4Q028308; Tue, 22 Oct 2002 00:51:45 -0700 (PDT) Received: from cisco.com (sjc-vpn3-8.cisco.com [10.21.64.8]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id AAA26490; Tue, 22 Oct 2002 00:51:41 -0700 (PDT) Message-ID: <3DB5038E.5000305@cisco.com> Date: Tue, 22 Oct 2002 00:51:42 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development References: <20021018220452.R2978-100000@sequoia.muada.com> In-Reply-To: <20021018220452.R2978-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, I submit that there are several reasons that this group has been (too) quiet. The first is that the requirements document has not progressed. I suspect the authors cannot agree on how to proceed, but I haven't actually discussed the matter with them. More importantly, however, I believe the document is actually an impediment to moving forward. One can view the document in two ways, and neither is positive. Either the points made in the document are so obvious as to not be worth writing down, or they are so constraining as to make the resulting solution not worth implementing. Here is an example of both: 3.2.5 Operations and Management It MUST be posssible for staff responsible for the operation of a site to monitor and configure the site's multihoming system. I could envision a system where an upstream actually does the configuration. Building a system that cannot be monitored is foolish (and therefore the requirement is obvious). Who does that monitoring is at worst a matter of device authorization. Similarly, I would want people to be able to reconsider the address format as well as the relationship between the EGP and the IGP. The question then turns to this: should we revisit the requirements document, or simply discard it and place effort more along the lines of the note sent by Iljitsch van Beijnum? It's not that the document is completely wrong. I just don't want architects to be so bound by it that we end up with something less lasting or useful. Let's have the engineering tradeoffs on the table. Those can develop *after* solutions are proposed. Eliot Iljitsch van Beijnum wrote: > In order to kickstart some activity in this wg, here is my view on the > current state of multihoming in IPv6 development. I hope this will start a > discussion on this here mailinglist, and also elsewhere, because I don't > think we can solve the entire problem right here, right now. > > Since waiting for "someone else" to completely solve the problem hasn't > been very productive so far, I think everyone should assume responsibility > for that part of the solution space he or she has any control over. There > are things that can be done to help multihoming in operations, address > allocation policy and application, host stack and router development. Lack > of cooperation from even one of those will hurt the multihoming in IPv6 > effort. > > The problem > ----------- > > The user problem: the internet is unreliable. Parts of it fail from time > to time. The only way to really protect yourself against this is having > several connections to the internet over different ISPs (multihome). > > The IETF problem: multihoming by announcing a globally visible address > block (as is current practice in IPv4) doesn't scale to a large enough > number of multihomed sites. > > A number of new drafts and revised versions of existing drafts will be out > in time for Atlanta. > > 1. Application solutions > ------------------------ > > One way to solve this would be by taking provider aggregatable addresses > (that don't polute the global routing table and thus scale well) from two > (or more) ISPs and give all systems addresses from both ranges. Then > applications simply try all addresses. > > This has many drawbacks. For instance, sessions still break if there is a > problem, and source address selection is problematic, especially in the > presence of anti-spoofing filtering by ISPs. But the good part is it > actually works today, to some degree. For instance, I can list several IP > addresses for an FTP server, and when the first one is down the FTP > program simply tries the next. Unfortunatley, the applications must > support this, and most of the newer ones (especially web browsers) don't. > > 2. Transport protocol solutions > ------------------------------- > > It is also possible to solve the problem at the transport layer. This has > most of the drawbacks of solving the problem at the application layer, > such as the source address selection/filtering issue. But also the fact > that applications have to be changed: unfortunately, the IPv6 API as > described in RFC 2292 centers around a single IPv6 address. Therefore, an > application wishing to use an address-agile transport protocol must be > changed in order to provide the extra address or addresses to the > transport layer. Alternatively, the transport layer could incorporate a > mechanism to discover alternate addresses, but this leads to security > problems as applications would be unaware of the addresses they use. > > Transport-layer solutions only solve the multihoming problem for > applications using the specific transport protocol so they only provide a > partial solution. > > 3. Routing implementation solutions > ----------------------------------- > > Current routers easily need upto a kilobyte or even more memory for each > individual prefix that is visible in the global routing table. In theory, > it should be possible to reduce this by one or two orders of magnitude by > removing information that doesn't directly lead to better routing > decisions. > > However, this requires major changes to the internals of routers and the > potential gain is relatively limited. > > 4. Geographical aggregation > --------------------------- > > By confining the reachability information for multihomed prefixes to the > geographical region where the multihomed network is connected, it is > possible to keep the size of the routing tables in individual routers > small while the global routing table gets bigger. > > The downside is that all aggregation implies loss of information, which > means less optimal routing. Also, aggregation across network boundaries is > complex. Geographical aggregation can only work in the presence of a > compatible address allocation policy. > > 5. Tunnelling or aliasing solutions > ----------------------------------- > > As a rule, current transport protocols do not have the capability to > switch soure/destination addresses when the addresses that are used no > longer provide connectivity, even if other addresses that are tied to > another physical or logical path that doesn't share the problem are > available. Such an alternate path can still be used by tunnelling the > original packets with the broken addresses. > > An optimization to tunnelling is to simply rewrite the original addresses > with the alternate ones at (or close to) the source, and write back the > original addresses at (or close to) the destination. This is called > aliasing and has the advantage the size of the packet remains the same. > Aliasing has superficial similarities to NAT, but it is fundamentally > different as the destination sees the same addresses as the source. Note > the resemblance to mobility. > > A major problem with tunnelling/aliasing solutions is the discovery of the > alternate addresses, and the security of these discovery mechanisms. > > What have we learned > -------------------- > > In discussions on this mailinglist and elsewhere, I've come to the > following conlusions: > > * The operations people really want/need multihoming. Current 6bone > guidelines (which are treated as law in many circles) forbid announcing > non-pTLA blocks with the result not even internet exchanges or regional > internet registries can be provider independent. > * There is a lot of overlap between mobility and some of the multihoming > solution space. It is likely that mobility can be extended to support > host multihoming. > * GSE is interesting, but it doesn't provide much multihoming support. > * Applications behaving in a multi-address aware manner could very > easily support some bare-bones host multihoming. > * Hosts having multiple addresses from different ISP PA blocks doesn't > currently work in practice. This could be solved by having systems > (mainly hosts, but possibly also routers) taking the source address into > account when making routing decisions. > * Larg(er) organizations will do just about anything to avoid renumbering, > this is NOT "free" or even particularly easy in IPv6. > * Very few organizations want or need to connect to the internet at > geographical locations that are very far apart and provide "internal > transit" for non-backup purposes. > * Some organizations that have a relatively large block of address space > de-aggregate to avoid having to use their internal network for transit. > > What we should do > ----------------- > > This is what I think this wg should do: > > 0. Move past the requirements. There is consensus--sort of. It's not going > to get much better than this. > > 1. Make recommendations to developers and other wgs about what > they can do to better support multihoming. > > 2. Several tunnelling/aliasing solutions have been proposed. It would be > good if those could interoperate. This would make it possible for a > multihomed host with (for instance) modified mobility support, to > interact in a multihomed-meaningful way with a host sitting behind a > cluster of big aliasing boxes. This would greatly relieve the > chicken/egg problem for this type of solution and make experimentation > with the really hard part (discovery and its security) easier. So we > should come up with a protocol that makes this interoperation possible. > > 3. Open the lines of communication with people working on mobility. > > 4. Work on geographical aggregation, especially by getting an address > allocation mechanism that supports this off the ground. > > Iljitsch van Beijnum > > > > From owner-multi6@ops.ietf.org Tue Oct 22 03:59:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08172 for ; Tue, 22 Oct 2002 03:59:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183tzI-000B7p-00 for multi6-data@psg.com; Tue, 22 Oct 2002 01:02:04 -0700 Received: from smtp1.extremenetworks.com ([216.52.8.6]) by psg.com with esmtp (Exim 3.36 #2) id 183tzH-000B7I-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 01:02:03 -0700 Received: from extremenetworks.com (unknown [10.120.24.129]) by smtp1.extremenetworks.com (Postfix) with ESMTP id C71A37A0A; Tue, 22 Oct 2002 01:01:29 -0700 (PDT) Date: Tue, 22 Oct 2002 04:01:30 -0400 Subject: Re: The state of IPv6 multihoming development Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20021018220452.R2978-100000@sequoia.muada.com> Message-Id: <792AAC82-E594-11D6-B646-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Oct 21, 2002, at 17:24 America/Montreal, Iljitsch van Beijnum wrote: > 4. Work on geographical aggregation, especially by getting an address > allocation mechanism that supports this off the ground. At best, a different term needs to be found other than "geographical aggregation". At worst, this is a bad idea. The problem is that just because I am in city X, that still does not mean that any of the ISPs that I connect to will interconnect inside X. In all cases so far, I am on a tail circuit that goes to a *different* geographical location (outside X in each case) for each provider that I have. In short, the IP routing topology is NOT closely congruent with the world's geographical topology. If we assign addresses not congruent with the actual IP routing topology, this tends to increase the number of prefixes in the default-free-zone (which is generally understood to be a bad property). Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Tue Oct 22 06:01:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10427 for ; Tue, 22 Oct 2002 06:01:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183vsC-000Ccs-00 for multi6-data@psg.com; Tue, 22 Oct 2002 03:02:52 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 183vsA-000Ccg-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 03:02:51 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9MA1ED16498; Tue, 22 Oct 2002 12:01:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 22 Oct 2002 12:01:13 +0200 (CEST) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: <792AAC82-E594-11D6-B646-00039357A82A@extremenetworks.com> Message-ID: <20021022114355.C14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, RJ Atkinson wrote: > > 4. Work on geographical aggregation, especially by getting an address > > allocation mechanism that supports this off the ground. > At best, a different term needs to be found other than "geographical > aggregation". At worst, this is a bad idea. Why a different term? > The problem is that just because I am in city X, that still does not > mean that any of the ISPs that I connect to will interconnect inside X. Currently interconnection isn't a game played on the city level. In Europe, there is usually a good interconnect for each country. In the US, it's more difficult, but it should be possible to divide the country roughly into three or four parts and have two interconnects between all the major players in each of those parts. Also, this isn't a binary thing: if you can't interconnect with a peer in the target region, you simply don't aggregate routes learned from this peer. Finally, it doesn't matter where the interconnect location is, as long as you can limit the presence of more specifics to a subset of all routers. So a US-only network could very well have all the routes towards Asian destinations inside routers on the west coast and routes towards European inside routers on the east coast. This is a very long way from the target region, but it still makes sense: routers in Chicago get to forward packets in the right direction until they reach a router that has more specific information. As the routing tables grow, it might even be necessary to have several routers in one interconnect location that each handle a different target region. For instance, a network could have two routers at Palo Alto: one that has domestic west coast routes and one that has Asia/Pacific routes. I'll have a draft on this ready within a few days. > In short, the IP routing topology is NOT closely congruent with the > world's geographical topology. If we assign addresses not congruent > with > the actual IP routing topology, this tends to increase the number > of prefixes in the default-free-zone (which is generally understood > to be a bad property). Are you saying the IPv6 routing table should only contain PA routes (this is current 6bone policy)? I don't think this is a sustainable position in the long run. And if we are going to do PI, doing it in a way that at least potentially supports aggregation would be good. Iljitsch From owner-multi6@ops.ietf.org Tue Oct 22 08:35:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13986 for ; Tue, 22 Oct 2002 08:35:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183yFi-000Eon-00 for multi6-data@psg.com; Tue, 22 Oct 2002 05:35:18 -0700 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #2) id 183yFe-000EnP-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 05:35:14 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9MCYWtt020014; Tue, 22 Oct 2002 14:34:32 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9MCYVUZ067308; Tue, 22 Oct 2002 14:34:32 +0200 Received: from [9.29.3.172] by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54060 from ; Tue, 22 Oct 2002 14:34:23 +0200 Message-Id: <3DB545C4.2EA17D0B@hursley.ibm.com> Date: Tue, 22 Oct 2002 14:34:12 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: RJ Atkinson , multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development References: <20021022114355.C14896-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On Tue, 22 Oct 2002, RJ Atkinson wrote: ... > > > In short, the IP routing topology is NOT closely congruent with the > > world's geographical topology. If we assign addresses not congruent > > with > > the actual IP routing topology, this tends to increase the number > > of prefixes in the default-free-zone (which is generally understood > > to be a bad property). > > Are you saying the IPv6 routing table should only contain PA routes (this > is current 6bone policy)? I don't think this is a sustainable position in > the long run. And if we are going to do PI, doing it in a way that at > least potentially supports aggregation would be good. The last sentence is clearly true, but you are making assumptions that multihoming will be solved in a particular way in the second sentence. That presupposes a result from the multi6 debate, before that debate has even started. So for now, yes the BGP4+ table should only contain PA routes, until we have a better solution to aggregation than that. Brian From owner-multi6@ops.ietf.org Tue Oct 22 08:38:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14106 for ; Tue, 22 Oct 2002 08:37:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183yKM-000EtK-00 for multi6-data@psg.com; Tue, 22 Oct 2002 05:40:06 -0700 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #2) id 183yKK-000EsK-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 05:40:05 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9MCdDTX068302; Tue, 22 Oct 2002 14:39:13 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9MCdCUZ043352; Tue, 22 Oct 2002 14:39:12 +0200 Received: from [9.29.3.172] by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA72788 from ; Tue, 22 Oct 2002 14:39:10 +0200 Message-Id: <3DB546E3.8BD70B46@hursley.ibm.com> Date: Tue, 22 Oct 2002 14:38:59 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Eliot Lear Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development References: <20021018220452.R2978-100000@sequoia.muada.com> <3DB5038E.5000305@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear wrote: > > Dear all, > > I submit that there are several reasons that this group has been (too) > quiet. The first is that the requirements document has not progressed. > I suspect the authors cannot agree on how to proceed, but I haven't > actually discussed the matter with them. > > More importantly, however, I believe the document is actually an > impediment to moving forward. One can view the document in two ways, > and neither is positive. Either the points made in the document are so > obvious as to not be worth writing down, or they are so constraining as > to make the resulting solution not worth implementing. I think we need the document, but since it does indeed contain conflicting requirements that will need tradeoffs, it clearly SHOULD NOT contain pseudo-normative language. I would suggest that all the upper case normative words should be replaced by shoulds and should nots in lower case, and then just ship the thing as Informational. Brian From owner-multi6@ops.ietf.org Tue Oct 22 08:52:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14601 for ; Tue, 22 Oct 2002 08:52:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183yXr-000F9H-00 for multi6-data@psg.com; Tue, 22 Oct 2002 05:54:03 -0700 Received: from elle.sprintlink.net ([199.0.234.34] helo=iscserv1.res.sprintlink.net) by psg.com with esmtp (Exim 3.36 #2) id 183yXn-000F93-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 05:53:59 -0700 Received: from localhost (rrockell@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id IAA11819; Tue, 22 Oct 2002 08:55:36 -0400 (EDT) X-Authentication-Warning: iscserv1.res.sprintlink.net: rrockell owned process doing -bs Date: Tue, 22 Oct 2002 08:55:36 -0400 (EDT) From: "Robert J. Rockell" X-X-Sender: To: Iljitsch van Beijnum cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021018220452.R2978-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk -> ->What we should do ->----------------- -> ->This is what I think this wg should do: -> ->0. Move past the requirements. There is consensus--sort of. It's not going -> to get much better than this. This 'sort of' could serve as a good indicator that the current solution space is not well-received. I think it is important that requirements get documented, blessed, and put through the system in this working group. There is already enough 'bad blood' in the IETF about IPv6. If one were to develop a solution to the multi-homing problem, without first having the requriements document solidified, this just furthers the problem (ex. "the solution stinks, it doesn't take into account X,Y, and Z"). Summary: Define the problem before you solve it. This has gotten us into trouble with this nasty little protocol before. We should learn from mistakes in the past. -> ->1. Make recommendations to developers and other wgs about what -> they can do to better support multihoming. -> ->2. Several tunnelling/aliasing solutions have been proposed. It would be -> good if those could interoperate. This would make it possible for a -> multihomed host with (for instance) modified mobility support, to -> interact in a multihomed-meaningful way with a host sitting behind a -> cluster of big aliasing boxes. This would greatly relieve the -> chicken/egg problem for this type of solution and make experimentation -> with the really hard part (discovery and its security) easier. So we -> should come up with a protocol that makes this interoperation possible. Good for 6bone, bad for 'real' networks. inter-provider SLA's are a long way off... and this is requirement #1 for most of the tunneling stuff to work. ->3. Open the lines of communication with people working on mobility. ...but they scale the same as this problem does... not sure. Perhaps safer to circle back frequently, then try to develop some consistency between the groups for the sake of similarity. -> ->4. Work on geographical aggregation, especially by getting an address -> allocation mechanism that supports this off the ground. I'm with RJA on this one. that dog won't hunt. You're making assumptions about how interconnection occurs, and implementing a protocol BCP, that has dependancies on what a network engineer can do/afford/justify/etc... a dangerous game. It is probably an ok assumption to say that every geographic provider is not connected to each of it's 'peers' (in the they-do-the-same-business sense of the word) in region. Will the world get better or worse? Are we REALLY assuming filtering in iBGP? Really? It would seem that is a tertiary requirement out of every thread I see in this solution. I would like to see more operators weigh in on the feasibility of these solutions. rjr -> ->Iljitsch van Beijnum -> -> From owner-multi6@ops.ietf.org Tue Oct 22 08:56:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14835 for ; Tue, 22 Oct 2002 08:56:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183yc8-000FDy-00 for multi6-data@psg.com; Tue, 22 Oct 2002 05:58:28 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 183yc6-000FDl-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 05:58:26 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9MCupJ16791; Tue, 22 Oct 2002 14:56:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 22 Oct 2002 14:56:51 +0200 (CEST) From: Iljitsch van Beijnum To: Brian E Carpenter cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: <3DB545C4.2EA17D0B@hursley.ibm.com> Message-ID: <20021022144630.N14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Brian E Carpenter wrote: > > Are you saying the IPv6 routing table should only contain PA routes (this > > is current 6bone policy)? I don't think this is a sustainable position in > > the long run. And if we are going to do PI, doing it in a way that at > > least potentially supports aggregation would be good. > The last sentence is clearly true, but you are making assumptions > that multihoming will be solved in a particular way in the second sentence. > That presupposes a result from the multi6 debate, before that debate > has even started. I think the debate has started some two years ago, when this wg was formed. Unfortunately, the debate hasn't finished yet. The way I see it is that we really need some level of working multihoming in IPv6 to get it deployed, and probably in a way that doesn't require much renumbering, preferably none, for large organizations. Guess what? PI does that, and nothing else is even on the horizon. So either IPv6 remains a playpen for several more years, or we get some form of PI. > So for now, yes the BGP4+ table should only contain PA routes, until we > have a better solution to aggregation than that. So far, the people with the deep pockets haven't entered the v6 arena. If and when they do, they'll get their routes in the DFZ, whether we like it or not. If there was another solution that could be deployed in (say) two years, that would make things different... From owner-multi6@ops.ietf.org Tue Oct 22 09:10:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15481 for ; Tue, 22 Oct 2002 09:10:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183ypf-000FVW-00 for multi6-data@psg.com; Tue, 22 Oct 2002 06:12:27 -0700 Received: from pa-monroeville1b-61.pit.adelphia.net ([24.53.182.61] helo=localhost) by psg.com with esmtp (Exim 3.36 #2) id 183ypc-000FUm-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 06:12:24 -0700 Received: from [192.168.1.100] (localhost [127.0.0.1]) by localhost (8.12.2/8.12.2) with ESMTP id g9MDBl2O006008; Tue, 22 Oct 2002 09:11:48 -0400 (EDT) Date: Tue, 22 Oct 2002 09:11:44 -0400 From: "Michael H. Lambert" To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development Message-ID: <19880208.1035277903@[192.168.1.100]> In-Reply-To: <20021018220452.R2978-100000@sequoia.muada.com> References: <20021018220452.R2978-100000@sequoia.muada.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-8.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This has many drawbacks. For instance, sessions still break if there is a > problem, and source address selection is problematic, especially in the > presence of anti-spoofing filtering by ISPs. But the good part is it > actually works today, to some degree. For instance, I can list several IP > addresses for an FTP server, and when the first one is down the FTP > program simply tries the next. Unfortunatley, the applications must > support this, and most of the newer ones (especially web browsers) don't. As a (perhaps) extreme case in this scenario, consider the situation of two sites which can communicate over either the commodity Internet or a Research and Education network (most likely high bandwidth and/or low latency). If viewed only from a reachability standpoint, either path would work, but there are applications which demand the latter. Simply returning a list of IP addresses to be tried in order is probably not sufficient in this case (in fact, both of these sites might have addresses, which, because of conditions of use on the network [ie, routing policy], cannot be reached from an arbitrary third site). What is the validity of this statement: All PA addresses (at least at RIR allocation boundaries) MUST appear in the DFZ. 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 Tue Oct 22 09:36:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16538 for ; Tue, 22 Oct 2002 09:36:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 183zEv-000G0f-00 for multi6-data@psg.com; Tue, 22 Oct 2002 06:38:33 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 183zEt-000G0O-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 06:38:31 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9MDZdM16852; Tue, 22 Oct 2002 15:35:40 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 22 Oct 2002 15:35:39 +0200 (CEST) From: Iljitsch van Beijnum To: "Michael H. Lambert" cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: <19880208.1035277903@[192.168.1.100]> Message-ID: <20021022152717.X14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Michael H. Lambert wrote: [Listing several addresses for a server and the application trying them all in order to achieve a low degree of multihoming functionality] > As a (perhaps) extreme case in this scenario, consider the situation of two > sites which can communicate over either the commodity Internet or a > Research and Education network (most likely high bandwidth and/or low > latency). If viewed only from a reachability standpoint, either path would > work, but there are applications which demand the latter. Simply returning > a list of IP addresses to be tried in order is probably not sufficient in > this case (in fact, both of these sites might have addresses, which, > because of conditions of use on the network [ie, routing policy], cannot be > reached from an arbitrary third site). This assumes a network/server/service has several addresses with each address tied to a certain service quality. Is this the best way to go? Obviously, at some point somewhere, the decision has to be made to select the higher quality path. What would be the best place to do this? The simple solution is to use the same addresses over both links and simply route all traffic over the higher quality link. A more advanced solution would be that the application or some kind of classifyin device sets a diffserv code point that then makes sure the appropriate path is chosen. The solution where there are different addresses with "hidden meanings" doesn't appeal much to me. > What is the validity of this statement: All PA addresses (at least at RIR > allocation boundaries) MUST appear in the DFZ. In the good old days many people requested routable (but not PA) space with no intention to connect to the net. Having unique space is helpful when interconnecting privately with others. There is even an RFC "RFC 1597 space considered harmful" or words to the same effect. Also, what are you going to do with people that break this rule? Disconnect them from the net? :-) Iljitsch From owner-multi6@ops.ietf.org Tue Oct 22 11:32:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22272 for ; Tue, 22 Oct 2002 11:32:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18412E-000ILZ-00 for multi6-data@psg.com; Tue, 22 Oct 2002 08:33:34 -0700 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 18412D-000IKJ-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 08:33:33 -0700 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MFWpxF003896; Tue, 22 Oct 2002 08:32:51 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9MFWqV4007909; Tue, 22 Oct 2002 08:32:53 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA20889; Tue, 22 Oct 2002 08:32:51 -0700 (PDT) Date: Tue, 22 Oct 2002 10:32:52 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Brian E Carpenter cc: Iljitsch van Beijnum , RJ Atkinson , Subject: Re: The state of IPv6 multihoming development In-Reply-To: <3DB545C4.2EA17D0B@hursley.ibm.com> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.7 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Brian E Carpenter wrote: > > Are you saying the IPv6 routing table should only contain PA routes (this > > is current 6bone policy)? I don't think this is a sustainable position in > > the long run. And if we are going to do PI, doing it in a way that at > > least potentially supports aggregation would be good. > > So for now, yes the BGP4+ table should only contain PA routes, until we > have a better solution to aggregation than that. I have to disagree here. Adoption of IPv6 in enterprises REQUIRES multihoming. It's not a "nice-to-have". Without it, IPv6 in enterprises is limited to the labs. If this means we have to accept some type of PI addressing in the near-term, then so be it, with the condition that those using it are given time frame to migrate to the Ultimate Multihoming Solution in the future. As for the original multi-PA multihoming solution, it doesn't fly in an enterprise. The selection of source and destination addresses by the originating host keeps enterprises from managing bandwidth on circuits, because the routing infrastructure has no idea of possible alternate paths for the packet. BGP isn't perfect either, but it's much better than how many bits a particular address has in common with another. Managing n+1 prefixes per subnet where n is number of providers serving a site is a nightmare. The list of problems goes on... If the goal was to design a theoretical protocol without end-user operational considerations that can keep DFZ routing tables under 16k prefixes, then we're doing a good job at designing multi-homing. If the goal is to gain adoption by and reliability for the end users of the IPv6 internet, we're failing. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Tue Oct 22 11:54:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23475 for ; Tue, 22 Oct 2002 11:54:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1841OH-000Ixs-00 for multi6-data@psg.com; Tue, 22 Oct 2002 08:56:21 -0700 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #2) id 1841OF-000Ix2-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 08:56:19 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9MFtFCG038608; Tue, 22 Oct 2002 17:55:15 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9MFt99X034718; Tue, 22 Oct 2002 17:55:09 +0200 Received: from [9.29.3.174] by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA37830 from ; Tue, 22 Oct 2002 17:55:06 +0200 Message-Id: <3DB574D0.4475E5D0@hursley.ibm.com> Date: Tue, 22 Oct 2002 17:54:56 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Craig A. Huegen" Cc: Iljitsch van Beijnum , RJ Atkinson , multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.4 required=5.0 tests=GAPPY_TEXT,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Craig, I would love to be able to agree with you. Of course I do agree that multi-homing is a must-have. But we just can't put the BGP4+ table on the exponential path. It's very unfortunate that this WG has made no progress on resolving that dilemma. New thinking is needed here if we are not to reproduce the old problems. Brian "Craig A. Huegen" wrote: > > On Tue, 22 Oct 2002, Brian E Carpenter wrote: > > > > Are you saying the IPv6 routing table should only contain PA routes (this > > > is current 6bone policy)? I don't think this is a sustainable position in > > > the long run. And if we are going to do PI, doing it in a way that at > > > least potentially supports aggregation would be good. > > > > So for now, yes the BGP4+ table should only contain PA routes, until we > > have a better solution to aggregation than that. > > I have to disagree here. Adoption of IPv6 in enterprises REQUIRES > multihoming. It's not a "nice-to-have". Without it, IPv6 in enterprises > is limited to the labs. If this means we have to accept some type of PI > addressing in the near-term, then so be it, with the condition that those > using it are given time frame to migrate to the Ultimate Multihoming > Solution in the future. > > As for the original multi-PA multihoming solution, it doesn't fly in an > enterprise. The selection of source and destination addresses by the > originating host keeps enterprises from managing bandwidth on circuits, > because the routing infrastructure has no idea of possible alternate paths > for the packet. BGP isn't perfect either, but it's much better than how > many bits a particular address has in common with another. Managing n+1 > prefixes per subnet where n is number of providers serving a site is a > nightmare. The list of problems goes on... > > If the goal was to design a theoretical protocol without end-user > operational considerations that can keep DFZ routing tables under 16k > prefixes, then we're doing a good job at designing multi-homing. If the > goal is to gain adoption by and reliability for the end users of the IPv6 > internet, we're failing. > > /cah > > --- > Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s > IT Transport, Network Technology & Design || || > Cisco Systems, Inc., 400 East Tasman Drive || || > San Jose, CA 95134, (408) 526-8104 |||| |||| > email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Tue Oct 22 11:56:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23582 for ; Tue, 22 Oct 2002 11:56:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1841Qx-000J2v-00 for multi6-data@psg.com; Tue, 22 Oct 2002 08:59:07 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 1841Qv-000J2d-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 08:59:05 -0700 Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g9MFwknZ023512; Tue, 22 Oct 2002 17:58:46 +0200 Received: (from shane@localhost) by x17.ripe.net (8.11.6/8.11.6) id g9MFwkV24468; Tue, 22 Oct 2002 17:58:46 +0200 Date: Tue, 22 Oct 2002 17:58:46 +0200 From: Shane Kerr To: "Craig A. Huegen" Cc: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development Message-ID: <20021022155846.GA24266@x17.ripe.net> References: <3DB545C4.2EA17D0B@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-RIPE-Spam-Status: NONE ; -1027 X-Spam-Status: No, hits=-16.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On 2002-10-22 10:32:52 -0500, Craig A. Huegen wrote: > > As for the original multi-PA multihoming solution, it doesn't fly in > an enterprise. The selection of source and destination addresses by > the originating host keeps enterprises from managing bandwidth on > circuits, because the routing infrastructure has no idea of possible > alternate paths for the packet. A multi-PA multihoming solution can use several techniques to allow the destination host to determine the addresses used, especially if it is layer 4 or higher. It seems like a lot of of end-sites would be happy with redundancy first, speed second, and least-cost routing as icing on the cake. Do you think enterprises would you reject out of hand a solution that uses DNS-style RTT optimisation for destination address selection? > BGP isn't perfect either, but it's much better than how many bits a > particular address has in common with another. Managing n+1 > prefixes per subnet where n is number of providers serving a site is > a nightmare. The list of problems goes on... Maybe you can point me to a URL of the specific draft you're addressing here (I only see the hoary requirements document at the IETF site). -- Shane Kerr RIPE NCC From owner-multi6@ops.ietf.org Tue Oct 22 12:23:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24780 for ; Tue, 22 Oct 2002 12:23:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1841qM-000JyO-00 for multi6-data@psg.com; Tue, 22 Oct 2002 09:25:22 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1841qC-000Jxc-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 09:25:12 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9MGNbg17141; Tue, 22 Oct 2002 18:23:37 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 22 Oct 2002 18:23:37 +0200 (CEST) From: Iljitsch van Beijnum To: Brian E Carpenter cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: <3DB574D0.4475E5D0@hursley.ibm.com> Message-ID: <20021022181323.S14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Brian E Carpenter wrote: > Craig, > I would love to be able to agree with you. Of course I do agree > that multi-homing is a must-have. But we just can't put the BGP4+ > table on the exponential path. It's very unfortunate that this WG > has made no progress on resolving that dilemma. I figured the whole geographical aggregation thing was a step in the right direction... I'll be sending the draft to the IETF later today or tomorrow (just waiting for some last minute feedback) but I guess it's ready: http://www.muada.com/drafts/draft-van-beijnum-multi6-geo-aggr-00.txt (The title is now "Geographical Aggregation to Support Multihoming in IPv6", this used to be "Geo For Now" (GFN).) > New thinking is needed here if we are not to reproduce the old > problems. Some face-to-face discussion would also be good. How do we get multi6 stuff on the agenda for Atlanta? Iljitsch From owner-multi6@ops.ietf.org Tue Oct 22 12:43:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25553 for ; Tue, 22 Oct 2002 12:43:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18429T-000Kh4-00 for multi6-data@psg.com; Tue, 22 Oct 2002 09:45:07 -0700 Received: from sj-msg-core-2.cisco.com ([171.70.145.30]) by psg.com with esmtp (Exim 3.36 #2) id 18429R-000Kep-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 09:45:05 -0700 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9MGiOcl020112; Tue, 22 Oct 2002 09:44:24 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MGiPlO028536; Tue, 22 Oct 2002 09:44:25 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA03806; Tue, 22 Oct 2002 09:44:24 -0700 (PDT) Date: Tue, 22 Oct 2002 11:44:24 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Brian E Carpenter cc: Iljitsch van Beijnum , RJ Atkinson , Subject: Re: The state of IPv6 multihoming development In-Reply-To: <3DB574D0.4475E5D0@hursley.ibm.com> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Brian E Carpenter wrote: > I would love to be able to agree with you. Of course I do agree > that multi-homing is a must-have. But we just can't put the BGP4+ > table on the exponential path. It's very unfortunate that this WG > has made no progress on resolving that dilemma. I wouldn't suggest PI as the long-term fix. Rather, I would suggest that we use it for adoption and support PI space for the short term, on condition that it is returned in timeframe when whatever solutions we come up with are filled out. > New thinking is needed here if we are not to reproduce the old > problems. I agree that new thinking is needed. At the same time, if any of the new thinking requires router changes, or even worse, host stack changes, the protocol continues to stagnate because there are few end-users beyond research, and single-homed home use. I'm not proposing that we just say IPv4 multihoming is the solution and be done with it. However, it does give us a few years of breathing room to come up with a real solution. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Tue Oct 22 12:44:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25639 for ; Tue, 22 Oct 2002 12:44:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1842BQ-000Kl5-00 for multi6-data@psg.com; Tue, 22 Oct 2002 09:47:08 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 1842BO-000Kkt-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 09:47:06 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id MAA29456; Tue, 22 Oct 2002 12:47:05 -0400 Date: Tue, 22 Oct 2002 12:47:05 -0400 From: "J. Noel Chiappa" Message-Id: <200210221647.MAA29456@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Hain" > Iljitsch van Beijnum wrote: >> 4. Work on geographical aggregation > To which I submit Let's try this one more time. An "address", as used in the IPv4/v6 architectures, is a name that (among other functions) specifies *where* that entity is in the network: i.e. where it is attached to the network's connectivity topology. In other words: "geographical address" -> "geographical topological-location-name" -> "connectivity-independent topological-location-name" -> "topological-location-independent topological-location-name". The latter is, rather obviously, a paradox. Q.E.D. While I'm at it, I rather admire the skilful political spin displayed in naming them "provider-dependent" and "provider-independent" addresses, thereby completely obscuring the underlying technical issues, and making it seem like it's purely a policy issue, one in which the large providers are out to screw the customers. Maybe y'all should introduce terminology of "RIAA-addresses" and "Microsoft-addresses", as alternatives for "provider-dependent addresses", for extra PR bang. If you want technically accurate terminology, as opposed to politically accurate, call them "connectivity-dependent" and "connectivity-independent". Noel From owner-multi6@ops.ietf.org Tue Oct 22 12:46:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25709 for ; Tue, 22 Oct 2002 12:46:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1842CV-000KoQ-00 for multi6-data@psg.com; Tue, 22 Oct 2002 09:48:15 -0700 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 1842CT-000Kmb-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 09:48:13 -0700 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MGlbxF000551; Tue, 22 Oct 2002 09:47:37 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MGlcVQ001446; Tue, 22 Oct 2002 09:47:39 -0700 (PDT) Received: from cisco.com (sjc-vpn2-800.cisco.com [10.21.115.32]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA07391; Tue, 22 Oct 2002 09:47:36 -0700 (PDT) Message-ID: <3DB58128.6020604@cisco.com> Date: Tue, 22 Oct 2002 09:47:36 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development References: <20021018220452.R2978-100000@sequoia.muada.com> <3DB5038E.5000305@cisco.com> <3DB546E3.8BD70B46@hursley.ibm.com> In-Reply-To: <20021018220452.R2978-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > I think we need the document Why? Eliot From owner-multi6@ops.ietf.org Tue Oct 22 12:55:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26137 for ; Tue, 22 Oct 2002 12:55:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1842Lg-000LEe-00 for multi6-data@psg.com; Tue, 22 Oct 2002 09:57:44 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 1842Le-000LES-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 09:57:42 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id MAA29488; Tue, 22 Oct 2002 12:57:41 -0400 Date: Tue, 22 Oct 2002 12:57:41 -0400 From: "J. Noel Chiappa" Message-Id: <200210221657.MAA29488@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum > The way I see it is that we really need some level of working > multihoming in IPv6 to get it deployed, and probably in a way that > doesn't require much renumbering, preferably none, for large > organizations. Guess what? PI does that, and nothing else is even on > the horizon. So either IPv6 remains a playpen for several more years, > or we get some form of PI. Hunh. Why don't you write a spec that says that IPv6 negates the Second Law of Thermodynamics? (Hey, that makes as much sense as a design which offers "topological-location-independent topological-location-names".) That way, IPv6 could solve the energy crisis *and* fix global warming, all in one fell swoop. That ought to drive IPv6 deployment. Let's try this one more time. Multi-homing is an additional "service" (if you will) of the network, a service that provides additional benefits. You don't get additional benefits without a price. (The old "There Ain't No Such Thing As A Free Lunch" principle.) The benefit of multi-homing has a price - the only question is, who's going to pay the price? Simple fairness demands that it *ought* to be the entity which directly benefits. Multiple connectivity-based addresses do this; the end-site has to pay the bulk of the cost (in complexity, etc). Connectivity-independent addresses (such as Provider-Independent addresses) don't have this characteristic. CI-addresses make everyone *else* pay for that site's privilege in being multi-homed. (That is, unless we have a system of charging for route advertisements, where the charge is directly related to the scope over which the advertisement is seen, which seems rather unlikely to happen.) It's all very simple, really. Who's going to pay for the benefits of multi-homing? That's the real question. Noel From owner-multi6@ops.ietf.org Tue Oct 22 13:01:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26249 for ; Tue, 22 Oct 2002 13:01:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1842RI-000LQ2-00 for multi6-data@psg.com; Tue, 22 Oct 2002 10:03:32 -0700 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 1842RG-000LOF-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 10:03:30 -0700 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MH2rxF013763; Tue, 22 Oct 2002 10:02:53 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9MH2t5s000593; Tue, 22 Oct 2002 10:02:55 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA27362; Tue, 22 Oct 2002 10:02:54 -0700 (PDT) Date: Tue, 22 Oct 2002 12:02:54 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Shane Kerr cc: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021022155846.GA24266@x17.ripe.net> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Shane Kerr wrote: > A multi-PA multihoming solution can use several techniques to allow > the destination host to determine the addresses used, especially if it > is layer 4 or higher. It seems like a lot of of end-sites would be > happy with redundancy first, speed second, and least-cost routing as > icing on the cake. Enterprise end-sites want equivalent functionality to IPv4. It also has to be manageable, such that the cost of managing the multi-homing solution is equal or less than that of managing multi-homing in IPv4 today. They need to be able to trust the infrastructure enough to make their AAAA RR part of the records for www..com. Given the business environment of the IPv4 Internet, I don't think you can trade off speed for redundancy. Multi-homing in IPv4 today delivers both. We need to deliver both. > Do you think enterprises would you reject out of hand a solution that > uses DNS-style RTT optimisation for destination address selection? When the host selects the path by virtue of address selection, such that the routing infrastructure can see no alternate paths to the destination, then enterprise network operations teams have no capability to manage traffic policy. I believe the majority of enterprise network operations teams would have an issue with that. We should keep traffic routing within the network layer, IMO, or at least give visibility to the network layer of alternate paths that can be taken for a variety of policy reasons. > > BGP isn't perfect either, but it's much better than how many bits a > > particular address has in common with another. Managing n+1 > > prefixes per subnet where n is number of providers serving a site is > > a nightmare. The list of problems goes on... > > Maybe you can point me to a URL of the specific draft you're > addressing here (I only see the hoary requirements document at the > IETF site). draft-ietf-ipngwg-default-addr-select-06.txt specifies the use of the pair of addresses with most common bits (left-most) in a set of source and destination address pairs. The IPv6 specifications for aggregatable address architecture offer that for multihoming, each segment could have multiple IP subnets from different PA-assigned /48's for an end-user. The host then uses the selection mechanism in default-addr-select to select the source and destination addresses to use. An enterprise would have to assign, per segment, a /64 from PA space from each provider plus perhaps a site-local /64 as well, and manage that list of prefixes across the entire enterprise network. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Tue Oct 22 13:04:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26387 for ; Tue, 22 Oct 2002 13:04:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1842UE-000LXl-00 for multi6-data@psg.com; Tue, 22 Oct 2002 10:06:34 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1842UC-000LXU-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 10:06:32 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9MH4uL17242; Tue, 22 Oct 2002 19:04:56 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 22 Oct 2002 19:04:56 +0200 (CEST) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <200210221647.MAA29456@ginger.lcs.mit.edu> Message-ID: <20021022185723.L14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, J. Noel Chiappa wrote: > Let's try this one more time. Do you think one more time is all it will take...? > An "address", as used in the IPv4/v6 architectures, is a name that (among > other functions) specifies *where* that entity is in the network: i.e. where > it is attached to the network's connectivity topology. I wouldn't call an address a name, but who cares. The real problem is that you tie addresses to the topology. Why? Obviously there is some hierarchy so the two can't be completely seperated, but when looking at the AS level there is absolutely no relationship between an AS, the addresses it uses and its place in the network topology. > In other words: > "geographical address" -> > "geographical topological-location-name" -> > "connectivity-independent topological-location-name" -> > "topological-location-independent topological-location-name". > The latter is, rather obviously, a paradox. Q.E.D. Ok, now I have to say I don't quite follow your permutations, but if this is such a paradox, how come it has worked for years for E.164 addresses? Iljitsch From owner-multi6@ops.ietf.org Tue Oct 22 13:19:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26913 for ; Tue, 22 Oct 2002 13:19:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1842hx-000M6Q-00 for multi6-data@psg.com; Tue, 22 Oct 2002 10:20:45 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1842hv-000M6E-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 10:20:43 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9MHJ8q17264; Tue, 22 Oct 2002 19:19:08 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 22 Oct 2002 19:19:08 +0200 (CEST) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: <200210221657.MAA29488@ginger.lcs.mit.edu> Message-ID: <20021022190631.D14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, J. Noel Chiappa wrote: > Multi-homing is an additional "service" (if you will) of the network, a > service that provides additional benefits. You don't get additional benefits > without a price. (The old "There Ain't No Such Thing As A Free Lunch" > principle.) I'm not convinced this is an "extra" service. > The benefit of multi-homing has a price - the only question is, who's going > to pay the price? Simple fairness demands that it *ought* to be the entity > which directly benefits. Multiple connectivity-based addresses do this; the > end-site has to pay the bulk of the cost (in complexity, etc). So who benefits if Google is multihomed? The user or the server? Or both? > Connectivity-independent addresses (such as Provider-Independent addresses) > don't have this characteristic. CI-addresses make everyone *else* pay for > that site's privilege in being multi-homed. For straight PI (or "CI") it is true that many organizations other than the multihomed one have to bear costs. However, this is far from "everyone else": only people who are default-free _need_ to pay for the extra memory and CPU power for their routers. In a multiple address solution this is much, much worse: in that case, all IPv6 hosts may have to implement extra functionality to be able to talk to multihomed destinations. But we're not debating straight PI, but geographically aggregatable PI (GAPI). GAPI aggregation is essentially free after the initial implementation efforts, as long as the routing tables within a region ("zone" in the draft) with interconnection within the region remain small enough to fit in a single router. Only when the routing tables grow beyond that, networks in the affected region need to install more memory in existing routers or more routers. This is of course not a good thing for networks that are active in the region but don't have multihomed customers themselves (also, these networks will experience less optimal traffic flow). > It's all very simple, really. Who's going to pay for the benefits of > multi-homing? That's the real question. No, the real question is whether multihoming in IPv6 will be good enough to get people who multihome "for free" to move to v6. Iljitsch From owner-multi6@ops.ietf.org Tue Oct 22 13:51:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28203 for ; Tue, 22 Oct 2002 13:51:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1843DA-000NFk-00 for multi6-data@psg.com; Tue, 22 Oct 2002 10:53:00 -0700 Received: from c2bapps5.btconnect.com ([193.113.209.26]) by psg.com with smtp (Exim 3.36 #2) id 1843D6-000NE6-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 10:52:56 -0700 Received: from ati (actually host host213-123-11-169.in-addr.btopenworld.com) by c2bapps5 with SMTP-CUST (XT-PP) with ESMTP; Tue, 22 Oct 2002 18:52:19 +0100 Reply-To: From: "Christian de Larrinaga" To: "J. Noel Chiappa" , Subject: RE: The state of IPv6 multihoming development Date: Tue, 22 Oct 2002 18:52:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 V6.00.2600.0000 In-Reply-To: <200210221657.MAA29488@ginger.lcs.mit.edu> Importance: Normal X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_03_05,USER_AGENT_OUTLOOK version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It's all very simple, really. Who's going to pay for the benefits of > multi-homing? That's the real question. > > Noel > up to a point. The benefits really depend on where you are and what you are doing so I don't know that there are any hard and fast rules to multi-homing in terms of a generalised cost benefit analysis that we can apply here that will make our job any easier/complicated. I think the observation is that multi homing makes for a more robust network environment and user experience and I guess that means we should ultimately think of a resolution which allows most points on the Internet becoming multi-homed is safer than thinking of multihoming as the exception. To that end we should make it so it can be cheap and simple to implement so it can be ubiquitous. Christian Christian de Larrinaga From owner-multi6@ops.ietf.org Tue Oct 22 13:52:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28232 for ; Tue, 22 Oct 2002 13:52:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1843Eg-000NKf-00 for multi6-data@psg.com; Tue, 22 Oct 2002 10:54:34 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1843Ef-000NKS-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 10:54:33 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9MHqxe17301 for ; Tue, 22 Oct 2002 19:52:59 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 22 Oct 2002 19:52:59 +0200 (CEST) From: Iljitsch van Beijnum To: Subject: Requirements Message-ID: <20021022195156.K14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Here are some good requirements: http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-groupa-00.txt They include everything we want and even more. From owner-multi6@ops.ietf.org Tue Oct 22 13:53:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28256 for ; Tue, 22 Oct 2002 13:53:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1843FP-000NML-00 for multi6-data@psg.com; Tue, 22 Oct 2002 10:55:19 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 1843FM-000NM6-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 10:55:16 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9MHt4KV020018; Tue, 22 Oct 2002 19:55:04 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 22 Oct 2002 19:55:04 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0BBE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Iljitsch van Beijnum'" , "J. Noel Chiappa" Cc: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Date: Tue, 22 Oct 2002 19:55:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-1.2 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > The benefit of multi-homing has a price - the only > question is, who's going > > to pay the price? Simple fairness demands that it *ought* > to be the entity > > which directly benefits. Multiple connectivity-based > addresses do this; the > > end-site has to pay the bulk of the cost (in complexity, etc). > > So who benefits if Google is multihomed? The user or the server? Or > both? => Why would Google want to be multihomed? Perhaps to ensure that they're online 24/7? And why do they want to do that? Perhaps so that they can maintain/increase their customer base/profits. If that's why they do it then it would make sense to make them pay for it. Hesham From owner-multi6@ops.ietf.org Tue Oct 22 14:51:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00314 for ; Tue, 22 Oct 2002 14:51:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18449Y-000PRb-00 for multi6-data@psg.com; Tue, 22 Oct 2002 11:53:20 -0700 Received: from sj-msg-core-2.cisco.com ([171.70.145.30]) by psg.com with esmtp (Exim 3.36 #2) id 18449X-000PQi-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 11:53:19 -0700 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9MIqfcl010357; Tue, 22 Oct 2002 11:52:41 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MIqgOI028141; Tue, 22 Oct 2002 11:52:42 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA05676; Tue, 22 Oct 2002 11:52:41 -0700 (PDT) Date: Tue, 22 Oct 2002 13:52:42 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: "J. Noel Chiappa" cc: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development In-Reply-To: <200210221657.MAA29488@ginger.lcs.mit.edu> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, J. Noel Chiappa wrote: > Multi-homing is an additional "service" (if you will) of the network, a > service that provides additional benefits. You don't get additional benefits > without a price. (The old "There Ain't No Such Thing As A Free Lunch" > principle.) Without multi-homing, demand for the network will be severely reduced because end-users will not see the IPv6 as a reliable network to do business on. > The benefit of multi-homing has a price - the only question is, who's going > to pay the price? Simple fairness demands that it *ought* to be the entity > which directly benefits. Multiple connectivity-based addresses do this; the > end-site has to pay the bulk of the cost (in complexity, etc). Content consumers benefit from the content providers being multi-homed, just as content providers benefit from the content consumers being multi-homed. You can't make the argument that benefit is solely or even primarily with the end-user that multihomes. The cost of multiple PA/CA/whateveryouwanttocallthem addresses is far too much compared with the return. The complexity of multiple PA prefixes across an infrastructure that has tens of thousands of subnets is phenomenal from an operations perspective. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Tue Oct 22 16:27:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03300 for ; Tue, 22 Oct 2002 16:27:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1845dX-0003pQ-00 for multi6-data@psg.com; Tue, 22 Oct 2002 13:28:23 -0700 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #2) id 1845dV-0003oG-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 13:28:21 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9MKRhjU021270; Tue, 22 Oct 2002 22:27:43 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9MKRgUZ100826; Tue, 22 Oct 2002 22:27:43 +0200 Received: from [9.29.3.173] by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA74970 from ; Tue, 22 Oct 2002 22:27:40 +0200 Message-Id: <3DB5B4B2.4F4C9208@hursley.ibm.com> Date: Tue, 22 Oct 2002 22:27:30 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development References: <20021022181323.S14896-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: ... > Some face-to-face discussion would also be good. How do we get multi6 > stuff on the agenda for Atlanta? Persuade the chairs to schedule a meeting. Brian From owner-multi6@ops.ietf.org Tue Oct 22 16:46:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03945 for ; Tue, 22 Oct 2002 16:46:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1845wu-0004n5-00 for multi6-data@psg.com; Tue, 22 Oct 2002 13:48:24 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 1845wt-0004mr-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 13:48:23 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9MKmI322386; Tue, 22 Oct 2002 23:48:18 +0300 Date: Tue, 22 Oct 2002 23:48:17 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: Iljitsch van Beijnum , Subject: Re: The state of IPv6 multihoming development In-Reply-To: <3DB5B4B2.4F4C9208@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Brian E Carpenter wrote: > Iljitsch van Beijnum wrote: > ... > > Some face-to-face discussion would also be good. How do we get multi6 > > stuff on the agenda for Atlanta? > > Persuade the chairs to schedule a meeting. Discuss what? Solutions? Forget about it... I think we need some concrete proposals on how to proceed with the requirements (it's a nice piece of work IMO but will probably be a bit useless: no solution is likely to satisfy all the criteria..) or what. There has been some discussion on that already, good. -- 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 Tue Oct 22 16:55:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04156 for ; Tue, 22 Oct 2002 16:55:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18466E-0005G9-00 for multi6-data@psg.com; Tue, 22 Oct 2002 13:58:02 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18466C-0005Fp-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 13:58:00 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id QAA00731; Tue, 22 Oct 2002 16:57:59 -0400 Date: Tue, 22 Oct 2002 16:57:59 -0400 From: "J. Noel Chiappa" Message-Id: <200210222057.QAA00731@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum > Do you think one more time is all it will take...? Given that we've been working on getting people to understand this since well into the previous millenium, I have no hopes that we'll be there anytime soon. >> An "address", as used in the IPv4/v6 architectures, is a name that >> (among other functions) specifies *where* that entity is in the network >> it is attached to the network's connectivity topology. > I wouldn't call an address a name It's a "name" in the general computer-science sense of the term "name". >> "geographical address" -> >> "geographical topological-location-name" -> >> "connectivity-independent topological-location-name" -> >> "topological-location-independent topological-location-name". > I have to say I don't quite follow your permutations Perhaps you should go over it again. It's an important point, and I believe it's been laid out in a fairly clearly. > if this is such a paradox, how come it has worked for years for E.164 > addresses? Well, for one, the international telephone system doesn't use dynamic routing. Because of the close connections between topology, addresses, and routing, one basically has the choice of either forcing the addressing to follow the connectivity topology, or forcing the connectivity topology to follow the addressing. The international telephone connectivity is pretty heavily regulated (indeed, in many countries around the world, it's still a government monopoly). Those parts of the system that do have some number portability do it through a mechanism which is basically identical to IPv6 Mobility - your "phone number" is now a virtual 'name', and it gets translated into a different phone number which is your actual phone 'address'. This corresponds exactly to the "home address", etc of IPv6 Mobility. So there's another possible solution for people who really want to multi-home: use IPv6 Mobility. That's already supported in all hosts, right? Noel From owner-multi6@ops.ietf.org Tue Oct 22 17:13:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04789 for ; Tue, 22 Oct 2002 17:13:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1846MY-00063m-00 for multi6-data@psg.com; Tue, 22 Oct 2002 14:14:54 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 1846MW-00063a-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 14:14:52 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id RAA00836; Tue, 22 Oct 2002 17:14:51 -0400 Date: Tue, 22 Oct 2002 17:14:51 -0400 From: "J. Noel Chiappa" Message-Id: <200210222114.RAA00836@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-0.7 required=5.0 tests=SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum >> The benefit of multi-homing has a price - the only question is, who's >> going to pay the price? Simple fairness demands that it *ought* to be >> the entity which directly benefits. > So who benefits if Google is multihomed? The user or the server? Or > both? If we only had to support multi-homing for Google, CNN and the N other top sites (for a reasonably small N, say 1K or so) we'd be done. The problem comes when you want to multi-home many, many small sites, all of whom (by definition) will be conversing with only a limited subset of the network. Forcing the rest of the network to help pay for the benefit they receive from multi-homing is patently unfair. I do agree completely with the basic idea behind one observation in Tony's draft: "the overriding assumption that the Internet will have to be built using one or the other rather than leveraging the strengths of each in context." There's probably no single mechanism which is "the" answer to multi-homing; you probably need several, each with its own optimal applicability domain. > In a multiple address solution this is much, much worse: in that case, > all IPv6 hosts may have to implement extra functionality to be able to > talk to multihomed destinations. How much extra code is it, really? It can't be as much code as IPv6 Mobility, or Authrntication, each of which is already mandated. In any event, if you think it's too much extra complexity, use IPv6 Mobility instead. That way you'll also get connection failover if you have to switch addresses dynamically because one of your incoming links went down. > But we're not debating straight PI, but geographically aggregatable PI > (GAPI). All forms of PI have the same basic problem, laid out in the previous messages, which is that they are ""topological-location-independent topological-location-names". So which particular flavor of PI it is really isn't of any interest. > Only when the routing tables grow beyond that, networks in the affected > region need to install more memory in existing routers or more routers. You have a static view of a dynamic reality. There are a lot more factors than just memory size. > the real question is whether multihoming in IPv6 will be good enough to > get people who multihome "for free" to move to v6. Hmm. If the current multi-homing "solution" (where the load of supporting multi-homing is borne entirely by the routing) "works" (and I don't think it does, but let me play advocatus diaboli here for a second), why not adopt it "as is" for IPv6? Contrariwise, if it doesn't work, why are you trying to adopt a variant of it, a variant which is so little different in its underlying technical implications that it amounts to the classic "re-arranging the deck-chairs on the Titanic"? Noel From owner-multi6@ops.ietf.org Tue Oct 22 17:21:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05108 for ; Tue, 22 Oct 2002 17:21:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1846Uh-0006Th-00 for multi6-data@psg.com; Tue, 22 Oct 2002 14:23:19 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 1846Uf-0006TM-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 14:23:17 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id RAA00886; Tue, 22 Oct 2002 17:23:15 -0400 Date: Tue, 22 Oct 2002 17:23:15 -0400 From: "J. Noel Chiappa" Message-Id: <200210222123.RAA00886@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-0.7 required=5.0 tests=SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Craig A. Huegen" > The cost of multiple PA/CA/whateveryouwanttocallthem addresses is far > too much compared with the return. The complexity of multiple PA > prefixes across an infrastructure that has tens of thousands of subnets > is phenomenal from an operations perspective. Well, there are a number of basically feasible paths you can take to support *widescale* multi-homing. (Supporting it for just Google and a "few" other sites is not too hard.) First, you can use multiple connectivity-based addresses. You're saying this is infeasible. Second, you can re-use a mobility mechanism. Third, you could use a radical addressing architecture that assigns addresses automatically, based on actual connectivity topology. I don't know of any others. Do you? If not, since you don't like multiple connectivity-based addresses, which of the other two do you prefer? Noel From owner-multi6@ops.ietf.org Tue Oct 22 17:22:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05141 for ; Tue, 22 Oct 2002 17:22:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1846WD-0006ZC-00 for multi6-data@psg.com; Tue, 22 Oct 2002 14:24:53 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 1846WB-0006Ys-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 14:24:51 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id IAA14124 for ; Wed, 23 Oct 2002 08:24:49 +1100 (EST) Date: Wed, 23 Oct 2002 08:24:48 +1100 (EST) From: Peter Tattam To: Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: <200210222057.QAA00731@ginger.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk I have not weighed in on this discussion yet as I wanted to see what the general consensus was. All I can say is that I believe the transport based solution I developed a couple of years back will work, and could easily be extended to cover non-TCP protocols. However, I did find that the level of support for my ideas were rather wanting which sadly made it difficult for me to devote time & effort to rounding them off. One other difficulty is that IPv6 deployment of hardware/software is now a fait accomplit and it's unlikely that my ideas would be implementable. I too agree that the requirements document places an insurmountable hurdle as there are mutually exclusive requirements that must be met. I have recently wondered whether the multihoming problem could be solved by isolating the requirement for global uniqueness of IP addresses from the more fluid nature of routing. Such proposals have been raised before, but rejected as being too radical in my opinion. One thing still remains clear though - multihoming is the thorn in the side for IPv6. Until it is finalized, IPv6 will be going nowhere. 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 Oct 22 17:32:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05346 for ; Tue, 22 Oct 2002 17:32:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1846eO-0006z9-00 for multi6-data@psg.com; Tue, 22 Oct 2002 14:33:20 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1846eM-0006yo-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 14:33:18 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9MLURj17577; Tue, 22 Oct 2002 23:30:28 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 22 Oct 2002 23:30:27 +0200 (CEST) From: Iljitsch van Beijnum To: Pekka Savola cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: Message-ID: <20021022232151.W14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Pekka Savola wrote: > > > Some face-to-face discussion would also be good. How do we get multi6 > > > stuff on the agenda for Atlanta? > Discuss what? Solutions? Forget about it... Why not? Ultimately, what people need is solutions, not requirements. > I think we need some concrete proposals on how to proceed with the > requirements (it's a nice piece of work IMO but will probably be a bit > useless: no solution is likely to satisfy all the criteria..) or what. > There has been some discussion on that already, good. Allow me to repeat myself: the current requirements are as good as they are going to get. We can officially adopt them and live with their inherit problems, or reject them and live without requirements. Either is a valid option. But spending more time on refining them will not provide additional benefits. These requirements are all reasonably obvious, and it is just as obvious that we're not going to arrive at solutions that fullfill all of these requirements completely. At some point, they'll have to be applied to parts of the solution space to decide whether a certain type of solution is acceptable or not. We might as well start with that part now. So: - Does geographical aggregation meet the requirements to such a level it would be worth our while to develop it further? - Do address agile transport protocols meet the requirements to such a level it would be worth our while to develop them further? - Does application-based multihoming meet the requirements to such a level it would be worth our while to develop it further? - Does dynamic aliasing/tunnelling meet the requirements to such a level it would be worth our while to develop it further? From owner-multi6@ops.ietf.org Tue Oct 22 17:34:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05466 for ; Tue, 22 Oct 2002 17:34:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1846h5-000794-00 for multi6-data@psg.com; Tue, 22 Oct 2002 14:36:07 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 1846h4-00078h-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 14:36:06 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9MLa2L22806; Wed, 23 Oct 2002 00:36:02 +0300 Date: Wed, 23 Oct 2002 00:36:02 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021022232151.W14896-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Iljitsch van Beijnum wrote: > On Tue, 22 Oct 2002, Pekka Savola wrote: > > > > > Some face-to-face discussion would also be good. How do we get multi6 > > > > stuff on the agenda for Atlanta? > > > Discuss what? Solutions? Forget about it... > > Why not? Ultimately, what people need is solutions, not requirements. [...] Chairs didn't see this as necessary before, I doubt they see it now.. I agree on most of your points. -- 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 Tue Oct 22 17:39:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05593 for ; Tue, 22 Oct 2002 17:39:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1846m7-0007R4-00 for multi6-data@psg.com; Tue, 22 Oct 2002 14:41:19 -0700 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.36 #2) id 1846m5-0007Q7-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 14:41:17 -0700 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9MLejIm028916; Tue, 22 Oct 2002 14:40:45 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9MLeiEY029050; Tue, 22 Oct 2002 14:40:44 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA18126; Tue, 22 Oct 2002 14:40:43 -0700 (PDT) Date: Tue, 22 Oct 2002 16:40:44 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: "J. Noel Chiappa" cc: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development In-Reply-To: <200210222114.RAA00836@ginger.lcs.mit.edu> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.7 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, J. Noel Chiappa wrote: > context." There's probably no single mechanism which is "the" answer to > multi-homing; you probably need several, each with its own optimal > applicability domain. So why not support PI for a limited subset of multihomers that have vast networks while supporting multi-PA for the small networks that have a minimal number of segments? > How much extra code is it, really? It can't be as much code as IPv6 Mobility, > or Authrntication, each of which is already mandated. The issue isn't code, IMO -- it's adoption. How long will it take to get global implementation of a new multihoming capability into IPv6? I think it's time to take advantage of the surge in popularity of IPv6 and get it into enterprise networks, before the steam is lost. > In any event, if you think it's too much extra complexity, use IPv6 Mobility > instead. That way you'll also get connection failover if you have to switch > addresses dynamically because one of your incoming links went down. End-user operators want SIMPLICITY, just like the provider operators like simplicity. Mobile IP / IPv6 mobility is certainly not simplicity. > > the real question is whether multihoming in IPv6 will be good enough to > > get people who multihome "for free" to move to v6. > > Hmm. If the current multi-homing "solution" (where the load of supporting > multi-homing is borne entirely by the routing) "works" (and I don't think it > does, but let me play advocatus diaboli here for a second), why not adopt it > "as is" for IPv6? You're looking at it in black-and-white (works vs. not works) when the real issue is gray -- a matter of scale, both near-term and long-term. It's pretty obvious to me that we need a simple way to multi-home such that enterprises can treat an IPv6 Internet as business-critical, that gives the routing infrastructure the ability to select alternate paths based on policy (whether manual, infrastructure characteristics, etc.) It's pretty obvious to me that multi-PA does not work for an end-user that has more than several hundred segments throughout its infrastructure, due to the configuration and maintenance load, the inability to failover or automatically deprecate addressing when delivery of traffic to a particular multi-PA prefix dies, and the inability of the enterprise network operator to implement network-based policy for path preference. It's pretty obvious to me that, for the time being, PI addressing could be leveraged to support those organizations for which multi-PA is a significant trouble, and therefore encourage those organizations to adopt IPv6 instead of ignore it. These organizations can migrate to the Ultimate Multihoming Solution (UMS) as soon as feasible. It's pretty obvious to me that aggregation is a Good Thing, and therefore, anything that would be helpful for PI aggregation in the future may be a good idea. I'm offering that existing PI be adopted "as is" for the time being for adoption purposes, coupled with a promise/demand that it be retired as soon as the better mousetrap comes along. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Tue Oct 22 17:49:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05774 for ; Tue, 22 Oct 2002 17:49:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1846vb-0007wd-00 for multi6-data@psg.com; Tue, 22 Oct 2002 14:51:07 -0700 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 1846vZ-0007vo-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 14:51:05 -0700 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MLoSxF024020; Tue, 22 Oct 2002 14:50:28 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9MLoT1o008278; Tue, 22 Oct 2002 14:50:30 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA27481; Tue, 22 Oct 2002 14:50:28 -0700 (PDT) Date: Tue, 22 Oct 2002 16:50:29 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: "J. Noel Chiappa" cc: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development In-Reply-To: <200210222123.RAA00886@ginger.lcs.mit.edu> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.3 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, J. Noel Chiappa wrote: > First, you can use multiple connectivity-based addresses. You're saying this > is infeasible. Second, you can re-use a mobility mechanism. Third, you could > use a radical addressing architecture that assigns addresses automatically, > based on actual connectivity topology. > > I don't know of any others. Do you? If not, since you don't like multiple > connectivity-based addresses, which of the other two do you prefer? Given those three and those three only (which is akin to asking whether you'd be happier with a stoning, a clubbing, or being hit by a truck), the third sounds most feasible to me. It, however, does not align with the idea that IPv6 addresses were intended to be globally unique and visible to the host, so several applications would be broken. It would require significantly complicated machinery to be created to support, both from a routing and infrastructure service (DNS, etc.) perspective which would delay adoption for years. It would most likely not address the capability of the enterprise network operator to choose a path among the set of possible paths, as the host would still be responsible for choosing the destination IP address, thereby hiding the other possible paths from the infrastructure. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Tue Oct 22 17:55:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05845 for ; Tue, 22 Oct 2002 17:55:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18471L-0008E3-00 for multi6-data@psg.com; Tue, 22 Oct 2002 14:57:03 -0700 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.36 #2) id 18471I-0008D5-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 14:57:00 -0700 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9MLuPIm009221; Tue, 22 Oct 2002 14:56:25 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9MLuOHo001192; Tue, 22 Oct 2002 14:56:24 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA02961; Tue, 22 Oct 2002 14:56:11 -0700 (PDT) Date: Tue, 22 Oct 2002 16:56:06 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Tony Li cc: "J. Noel Chiappa" , Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Tony Li wrote: > Because we've done nothing to eliminate the "tragedy of the commons". > > Under this scheme, which alternative is easier for users? I would > guess PI space. And everyone would choose that and then tell us that > they are sufficiently "special" to get PI space and then we end up > back where we are today. > > A workable architecture has to constrain the users into doing The > Right Thing automatically. Because otherwise, users will optimize for > their own benefit, at the cost of the network. I agree that it's not something I would propose for all multi-homers. I agree there would be some folks who would want PI space when perhaps multi-PA is indeed workable for them. So it's all-or-nothing? I don't buy that. The complexity and management of assigning multiple-PA prefixes to my home network of 6 segments, or my mother's accounting firm with 20 segments, or even a previous employer's network of 100 segments, is vastly different than assigning multiple-PA prefixes to a network of tens of thousands of segments worldwide, with multiple Internet igress/egress points. I don't think it's just me who believes that IPv6 adoption isn't automatic in large enterprises today, and is in fact hindered severely at this point for lack of a multi-homing solution. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Tue Oct 22 18:02:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06022 for ; Tue, 22 Oct 2002 18:02:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18478r-0008e1-00 for multi6-data@psg.com; Tue, 22 Oct 2002 15:04:49 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18478p-0008dk-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 15:04:47 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9MM3BB17658; Wed, 23 Oct 2002 00:03:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Oct 2002 00:03:11 +0200 (CEST) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <200210222057.QAA00731@ginger.lcs.mit.edu> Message-ID: <20021022234102.G14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, J. Noel Chiappa wrote: > > if this is such a paradox, how come it has worked for years for E.164 > > addresses? > Well, for one, the international telephone system doesn't use dynamic > routing. Hm, hardly a good point. If you can train monkeys with a fax machine to execute your routing algorithm, it must be simple enough to implement on a router, I'd think... > Because of the close connections between topology, addresses, and > routing, one basically has the choice of either forcing the addressing to > follow the connectivity topology, or forcing the connectivity topology to > follow the addressing. I think the last place where addressing follows topology is in old electro-mechanical telephone exchanges, where the digit you dial is translated to an actual crossconnect location. In IP, there is only a slight overlap between the addressing and topology hierarchies. Unfortunately, hierarchy -> tree structure -> no loops -> no redundancy. Trying as hard as I can to think "out of the box" it seems reasonable to me to see how far we can get by tying addresses to location. I know this is an "ugly" solution as in theory, the network topology has nothing to do with geography. And as we know, in theory there is no difference between theory and practice, but in practice there is. Despite the fact that I run a website under the domain "bgpexpert.com" I have no delusion I'm the world's greatest routing expert, but on the other hand I'm not a complete novice and I feel confident that this geographical aggregation will work in practice. And the really good part is it's all completely optional: you don't _have_ to geographically aggregate. If people don't like the fact that addresses are geographically significant, they can simply treat them as straight PI addresses and buy big routers. > Those parts of the system that do have some number portability do it through > a mechanism which is basically identical to IPv6 Mobility - your "phone > number" is now a virtual 'name', and it gets translated into a different > phone number which is your actual phone 'address'. This corresponds exactly > to the "home address", etc of IPv6 Mobility. It's a bit more complicated than that. Some networks use the "intelligent network" for everything, but first you have to reach the "home" network for a "prefix". There is a three level hierarchy here: country, city (state in the US?), operator. In IPv4, it's just "operator". So does this mean we're smarter or stupider than the bell-heads? > So there's another possible solution for people who really want to > multi-home: use IPv6 Mobility. That's already supported in all hosts, right? Mobility has useful mechanisms, but unfortunately it will not do anything useful in the presence of outages. From owner-multi6@ops.ietf.org Tue Oct 22 18:15:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06181 for ; Tue, 22 Oct 2002 18:15:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1847KX-000FO6-00 for multi6-data@psg.com; Tue, 22 Oct 2002 15:16:53 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 1847KU-000FLr-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 15:16:50 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id SAA01231; Tue, 22 Oct 2002 18:16:48 -0400 Date: Tue, 22 Oct 2002 18:16:48 -0400 From: "J. Noel Chiappa" Message-Id: <200210222216.SAA01231@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Craig A. Huegen" >> there are a number of basically feasible paths you can take to support >> *widescale* multi-homing. >> First, you can use multiple connectivity-based addresses. .. Second, >> you can re-use a mobility mechanism. Third, you could use a radical >> addressing architecture that assigns addresses automatically, based >> on actual connectivity topology. >> I don't know of any others. Do you? > Given those three and those three only Hey, I did ask if you know of any others. I'd be very interested in any additional alternatives you can outline. (Excluding schemes of the form "let the routing do it", like the existing IPv4 solution, and PI addresses.) Noel From owner-multi6@ops.ietf.org Tue Oct 22 18:18:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06269 for ; Tue, 22 Oct 2002 18:18:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1847OT-000GO8-00 for multi6-data@psg.com; Tue, 22 Oct 2002 15:20:57 -0700 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net ident=4919-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-take-this-and-log-it!) by psg.com with esmtp (Exim 3.36 #2) id 1847OR-000GNm-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 15:20:56 -0700 Received: by ab.use.net (Postfix, from userid 3005) id A65A1AE4; Tue, 22 Oct 2002 22:20:53 +0000 (GMT) To: brian@hursley.ibm.com, iljitsch@muada.com Subject: Re: The state of IPv6 multihoming development Cc: multi6@ops.ietf.org Message-Id: <20021022222053.A65A1AE4@ab.use.net> Date: Tue, 22 Oct 2002 22:20:53 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=1.9 required=5.0 tests=SHORT_RECEIVED_LINE,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk | Some face-to-face discussion would also be good. How do we get multi6 | stuff on the agenda for Atlanta? If you have something concrete for the agenda, and can fudge some wording so that it's relevant to the existing charter, then Thomas & I will write to the secretariat (& ADs) and ask for a meeting slot. Sean. From owner-multi6@ops.ietf.org Tue Oct 22 18:21:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06308 for ; Tue, 22 Oct 2002 18:21:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1847Qu-000GZM-00 for multi6-data@psg.com; Tue, 22 Oct 2002 15:23:28 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1847Qs-000GZ2-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 15:23:27 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9MMLcC17709; Wed, 23 Oct 2002 00:21:38 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Oct 2002 00:21:38 +0200 (CEST) From: Iljitsch van Beijnum To: "Craig A. Huegen" cc: Tony Li , "J. Noel Chiappa" , Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: <20021023000439.K14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Craig A. Huegen wrote: > The complexity and management of assigning multiple-PA prefixes to my home > network of 6 segments, or my mother's accounting firm with 20 segments, or > even a previous employer's network of 100 segments, is vastly different > than assigning multiple-PA prefixes to a network of tens of thousands of > segments worldwide, with multiple Internet igress/egress points. In my original message, which has stirred up a lot of discussion I'm happy to see, I also mentioned working on a unified tunnelling/aliasing mechanism. If we look at a huge enterprise as one example of someone who needs multihoming, and at a single host with two interfaces or one interface with two addresses as another, it seems unlikely they could use the same multihoming mechanisms. However, they could both use a multi address solution. For the enterprise, this could be something along the lines of Michel Py's MHAP where the entire enterprise or good size chunks of it sit behind clusters of aliasing/tunneling devices that provide the multihoming functionality by rewriting (or tunnelling) traffic that can't reach its destination otherwise over a backup address. For the host, this could be something like Marcelo Bagnulo's extension header, modified mobility, Peter Tattam's modified TCP or my own "BALTS" idea. These all boil down to a host having several addresses and being able to receive packets on a secondary address and trick the transport layer into thinking it's still using the primary address. Just recently it occurred to me that these solutions could very well work together. There are just so many ways you can tunnel or aliaze a packet, and it's fairly trivial to implement them all for sending. That means everyone can implement whatever is most convenient for receiving. For instance, if a multihomed host sends a packet to a multihomed enterprise its server while the primary address is unreachable, the host could replace the enterprise's primary prefix with a secondary (PA) one which is received at a big de-multihoming box which replaces the original prefix. When the target host (which doesn't have to know about all of this) sends a packet back, the multihoming box can add a mobility header and send the packet to the secondary address for the multihomed host. I think standardizing the interaction between different multi address multihoming solutions will make this type of solution much more viable. It would be great if we could have a discussion about this in Atlanta. From owner-multi6@ops.ietf.org Tue Oct 22 18:58:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07012 for ; Tue, 22 Oct 2002 18:58:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18480N-000IPl-00 for multi6-data@psg.com; Tue, 22 Oct 2002 16:00:07 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18480M-000IPZ-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 16:00:06 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18480L-0009Wj-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 16:00:06 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ6FBRO734EMeYQQ6GTSxoJlhTtkgAAH+lg Subject: RE: The state of IPv6 multihoming development Date: Tue, 22 Oct 2002 14:49:29 -0700 From: "Tony Li" To: "Craig A. Huegen" , "J. Noel Chiappa" Cc: X-Spam-Status: No, hits=-1.2 required=5.0 tests=RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA07012 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] | > context." There's probably no single mechanism which is | "the" answer to | > multi-homing; you probably need several, each with its own optimal | > applicability domain. | | So why not support PI for a limited subset of multihomers | that have vast | networks while supporting multi-PA for the small networks | that have a | minimal number of segments? Because we've done nothing to eliminate the "tragedy of the commons". Under this scheme, which alternative is easier for users? I would guess PI space. And everyone would choose that and then tell us that they are sufficiently "special" to get PI space and then we end up back where we are today. A workable architecture has to constrain the users into doing The Right Thing automatically. Because otherwise, users will optimize for their own benefit, at the cost of the network. Tony From owner-multi6@ops.ietf.org Tue Oct 22 19:02:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07109 for ; Tue, 22 Oct 2002 19:02:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18484w-000IcQ-00 for multi6-data@psg.com; Tue, 22 Oct 2002 16:04:50 -0700 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #2) id 18484u-000IcA-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 16:04:48 -0700 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id AAA26467; Wed, 23 Oct 2002 00:04:36 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:z82DbNQgRybxgMK929T0BtiQ0IMKuUQn@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g9MN4SWX022896; Wed, 23 Oct 2002 00:04:28 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id g9MN4SU03717; Wed, 23 Oct 2002 00:04:28 +0100 Date: Wed, 23 Oct 2002 00:04:28 +0100 From: Tim Chown To: Peter Tattam Cc: Multi6 Working Group Subject: Re: The state of IPv6 multihoming development Message-ID: <20021022230427.GE2891@login.ecs.soton.ac.uk> References: <200210222057.QAA00731@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-7.0 required=5.0 tests=HOME_EMPLOYMENT,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Oct 23, 2002 at 08:24:48AM +1100, Peter Tattam wrote: > > One thing still remains clear though - multihoming is the thorn in the side for > IPv6. Until it is finalized, IPv6 will be going nowhere. Is it really that big a thorn? To play devil's advocate... What proportion of Internet sites are multihomed? Academia generally isn't, not to the universities, although the NRENs will have multiple peerings. What proportion of Internet enterprise sites are mission critical? My home or small business DSL/cable network certainly isn't multihomed, in the access network at least. Itojun is a rare example with four home /48's, I think :) How frequently are multihomed sites calling on their resilient links? Of course ISPs like to sell additional connectivity. How much of the IPv4 DFZ clutter is due to multihomed sites? Are 3GPP systems using IPv6 in Release 5 multihomed? I don't see lack of multihoming stopping deployment to academic networks (many 10's of millions of users), or to broadband home networks. There's a potentially big IPv6 market in the latter. Multihoming is important, but is it that important? Tim From owner-multi6@ops.ietf.org Tue Oct 22 19:11:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07204 for ; Tue, 22 Oct 2002 19:11:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1848Dg-000J7V-00 for multi6-data@psg.com; Tue, 22 Oct 2002 16:13:52 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 1848De-000J7J-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 16:13:50 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 1848De-0009tc-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 16:13:50 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ6H6P+xMMnij27QeqlgqCSwtINrwAABr4Q Subject: RE: The state of IPv6 multihoming development Date: Tue, 22 Oct 2002 16:08:56 -0700 From: "Tony Li" To: "Tim Chown" , "Peter Tattam" Cc: "Multi6 Working Group" X-Spam-Status: No, hits=-1.2 required=5.0 tests=RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA07204 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] It's vitally important in the sense that if we deploy the wrong solution (or no solution), then we end up back on the exponential curve and it will be that much harder to change later because we would then have an installed base. In other words, the sequence should not be: ready, fire, aim. ;-) Tony | -----Original Message----- | From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] | Sent: Tuesday, October 22, 2002 4:04 PM | To: Peter Tattam | Cc: Multi6 Working Group | Subject: Re: The state of IPv6 multihoming development | | | On Wed, Oct 23, 2002 at 08:24:48AM +1100, Peter Tattam wrote: | > | > One thing still remains clear though - multihoming is the | thorn in the side for | > IPv6. Until it is finalized, IPv6 will be going nowhere. | | Is it really that big a thorn? | | To play devil's advocate... | | What proportion of Internet sites are multihomed? Academia | generally isn't, | not to the universities, although the NRENs will have | multiple peerings. | | What proportion of Internet enterprise sites are mission | critical? My home | or small business DSL/cable network certainly isn't | multihomed, in the | access network at least. Itojun is a rare example with | four home /48's, | I think :) | | How frequently are multihomed sites calling on their | resilient links? Of | course ISPs like to sell additional connectivity. | | How much of the IPv4 DFZ clutter is due to multihomed sites? | | Are 3GPP systems using IPv6 in Release 5 multihomed? | | I don't see lack of multihoming stopping deployment to | academic networks | (many 10's of millions of users), or to broadband home | networks. There's | a potentially big IPv6 market in the latter. | | Multihoming is important, but is it that important? | | Tim | | From owner-multi6@ops.ietf.org Tue Oct 22 19:25:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07330 for ; Tue, 22 Oct 2002 19:25:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1848Qd-000JnD-00 for multi6-data@psg.com; Tue, 22 Oct 2002 16:27:15 -0700 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #2) id 1848Qb-000Jn0-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 16:27:13 -0700 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id AAA26863; Wed, 23 Oct 2002 00:27:10 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:i0TvahvmXOzogwUXp7qyrkcwAwuOnzaC@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g9MNR2WX025579; Wed, 23 Oct 2002 00:27:02 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id g9MNR2d03845; Wed, 23 Oct 2002 00:27:02 +0100 Date: Wed, 23 Oct 2002 00:27:02 +0100 From: Tim Chown To: Tony Li Cc: Multi6 Working Group Subject: Re: The state of IPv6 multihoming development Message-ID: <20021022232702.GF2891@login.ecs.soton.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, Oct 22, 2002 at 04:08:56PM -0700, Tony Li wrote: > > It's vitally important in the sense that if we deploy > the wrong solution (or no solution), then we end up back > on the exponential curve and it will be that much harder > to change later because we would then have an installed > base. > > In other words, the sequence should not be: ready, fire, > aim. > > ;-) OK, containment (of the DFZ table size) is certainly a good goal. But who is actually going to be multihoming with IPv6, and to what extent? Perhaps there are now 50,000 large enterprises doing so with IPv4. Is the number of such enterprises going to rise? What's the change in terms of the types of sites multihoming that's pushing the DFZ size up so much? Small ISPs? Smaller enterprises? I'm just curious as to who the multihomers are, and best guesstimates of future growth. Do we foresee home users multihoming to multiple ISPs? I don't pay for resilience now with two telephone lines, or having DSL and cable lines; paying double isn't economic for Joe User. The same I assume would be true for mobile handsets. Academia + home users + mobile (3G) users is (or will be) a large chunk of the Internet; all three can benefit from IPv6 now, or in the near future. The crux seems to be projected top limits on who will demand multihoming, and what clas of users those people/sites are? Of course, predicting 10 years ahead is a tad tricky :) Any pointers to research/stats on this would be interesting. Tim From owner-multi6@ops.ietf.org Tue Oct 22 19:27:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07404 for ; Tue, 22 Oct 2002 19:27:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1848T0-000Juz-00 for multi6-data@psg.com; Tue, 22 Oct 2002 16:29:42 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 1848Sw-000Jul-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 16:29:38 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id KAA27469; Wed, 23 Oct 2002 10:29:31 +1100 (EST) Date: Wed, 23 Oct 2002 10:29:31 +1100 (EST) From: Peter Tattam To: Tim Chown cc: Multi6 Working Group Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021022230427.GE2891@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk While I agree that it may not be entirely necessary for the real deployment of IPv6, it is IPv6 opponents that continually use it to denigrate IPv6. So that's why I said "thorn in the side" instead of a "gaping wound" :) These people are the kinds of people who have strong influence in teh spheres of power. Until they are silenced once and for all, they whittle away trying to reduce any progress that IPv6 would make. Peter On Wed, 23 Oct 2002, Tim Chown wrote: > On Wed, Oct 23, 2002 at 08:24:48AM +1100, Peter Tattam wrote: > > > > One thing still remains clear though - multihoming is the thorn in the side for > > IPv6. Until it is finalized, IPv6 will be going nowhere. > > Is it really that big a thorn? > > To play devil's advocate... > > What proportion of Internet sites are multihomed? Academia generally isn't, > not to the universities, although the NRENs will have multiple peerings. > > What proportion of Internet enterprise sites are mission critical? My home > or small business DSL/cable network certainly isn't multihomed, in the > access network at least. Itojun is a rare example with four home /48's, > I think :) > > How frequently are multihomed sites calling on their resilient links? Of > course ISPs like to sell additional connectivity. > > How much of the IPv4 DFZ clutter is due to multihomed sites? > > Are 3GPP systems using IPv6 in Release 5 multihomed? > > I don't see lack of multihoming stopping deployment to academic networks > (many 10's of millions of users), or to broadband home networks. There's > a potentially big IPv6 market in the latter. > > Multihoming is important, but is it that important? > > Tim > > -- 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 Oct 22 19:38:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07608 for ; Tue, 22 Oct 2002 19:38:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1848d2-000KWr-00 for multi6-data@psg.com; Tue, 22 Oct 2002 16:40:04 -0700 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net ident=1564-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-take-this-and-log-it!) by psg.com with esmtp (Exim 3.36 #2) id 1848d0-000KWO-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 16:40:03 -0700 Received: by ab.use.net (Postfix, from userid 3005) id 63676AE4; Tue, 22 Oct 2002 23:40:01 +0000 (GMT) To: jnc@ginger.lcs.mit.edu, multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development Message-Id: <20021022234001.63676AE4@ab.use.net> Date: Tue, 22 Oct 2002 23:40:01 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=1.9 required=5.0 tests=SHORT_RECEIVED_LINE,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk | >> First, you can use multiple connectivity-based addresses. .. Second, | >> you can re-use a mobility mechanism. Third, you could use a radical | >> addressing architecture that assigns addresses automatically, based | >> on actual connectivity topology. | | >> I don't know of any others. Do you? | | > Given those three and those three only | | Hey, I did ask if you know of any others. I'd be very interested Well, you could automatically adjust the topology to match a relatively static layout of addresses (so we would call this address-based connectivity). Although I imagine this would be done at a layer below that of IP, I accept that one could see this as a form of mobility mechanism, or as a means for achieving geographical IP addressing. Whether moving the mechanisms handling the work of dynamic change to the topology to a lower layer is as practical as dealing with it at a higher layer (as in your option one), I could not say. Sean. From owner-multi6@ops.ietf.org Tue Oct 22 20:05:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08320 for ; Tue, 22 Oct 2002 20:05:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18493c-000M0S-00 for multi6-data@psg.com; Tue, 22 Oct 2002 17:07:32 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18493b-000M09-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 17:07:31 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18493b-000BPH-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 17:07:31 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ6Io+TsIaFrs6PSeWKG3VtocpnAAAAyxhw Subject: RE: The state of IPv6 multihoming development Date: Tue, 22 Oct 2002 17:00:29 -0700 From: "Tony Li" To: "Tim Chown" Cc: "Multi6 Working Group" X-Spam-Status: No, hits=-1.2 required=5.0 tests=RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA08320 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Back when we were doing the CIDR work, we asked a bunch of ISPs and they came back with about 10% of their customer base being multihomed. And typically, the second provider wasn't part of the sample, so that we felt that about 10% of all enterprises were multihomed. During the bubble, it looked like that number was increasing, but post-bubble, I'd make the educated guess that it's back to 10%. This may well increase as more enterprises find that the net is mission critical to them. A side point: another result that we got from CIDR is that even at 10% of the enterprises being multihomed, that their contribution to the DFZ tables would come to dominate the size of the table and push us back into exponential growth extremely quickly. Or, another way of looking at it is that when you have exponential growth, dividing the problem by 10 only gets you about one growth cycle of relief. It doesn't solve the issue entirely. Will homes, academia and non-enterprises multihome? Some academic sites already are. I know of some sick netgeeks who are already multihomed. All of it hangs in the balance between the economic cost and the perception of mission critical importance. Bottom line: we need a multihoming solution that allows the DFZ table to scale reasonably even if everyone is multihomed. Because that might happen and the net must continue to work. Tony p.s. In the past I have certainly been an opponent to IPv6. However, my position has changed somewhat. I can see the pressure to go down the IPv6 path and I would like to see some good come out of the exercise. If v6 turns out to be simply v4 with a bigger address space but it still collapses due to the poor routing architecture, then we will have failed miserably. So I am pushing for scalability for the routing layer and hoping that we don't make the same mistakes again. -- t | -----Original Message----- | From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] | Sent: Tuesday, October 22, 2002 4:27 PM | To: Tony Li | Cc: Multi6 Working Group | Subject: Re: The state of IPv6 multihoming development | | | On Tue, Oct 22, 2002 at 04:08:56PM -0700, Tony Li wrote: | > | > It's vitally important in the sense that if we deploy | > the wrong solution (or no solution), then we end up back | > on the exponential curve and it will be that much harder | > to change later because we would then have an installed | > base. | > | > In other words, the sequence should not be: ready, fire, | > aim. | > | > ;-) | | OK, containment (of the DFZ table size) is certainly a good goal. | | But who is actually going to be multihoming with IPv6, and | to what extent? | Perhaps there are now 50,000 large enterprises doing so | with IPv4. Is the | number of such enterprises going to rise? What's the | change in terms of | the types of sites multihoming that's pushing the DFZ size | up so much? | Small ISPs? Smaller enterprises? | | I'm just curious as to who the multihomers are, and best | guesstimates of | future growth. Do we foresee home users multihoming to | multiple ISPs? | I don't pay for resilience now with two telephone lines, or | having DSL and | cable lines; paying double isn't economic for Joe User. | The same I assume | would be true for mobile handsets. Academia + home users | + mobile (3G) users | is (or will be) a large chunk of the Internet; all three | can benefit from | IPv6 now, or in the near future. | | The crux seems to be projected top limits on who will | demand multihoming, | and what clas of users those people/sites are? Of course, | predicting 10 | years ahead is a tad tricky :) | | Any pointers to research/stats on this would be interesting. | | Tim | From owner-multi6@ops.ietf.org Tue Oct 22 20:18:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08580 for ; Tue, 22 Oct 2002 20:18:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1849G4-000MiF-00 for multi6-data@psg.com; Tue, 22 Oct 2002 17:20:24 -0700 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net ident=6901-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-take-this-and-log-it!) by psg.com with esmtp (Exim 3.36 #2) id 1849G2-000Mi3-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 17:20:22 -0700 Received: by ab.use.net (Postfix, from userid 3005) id D871B986; Wed, 23 Oct 2002 00:20:20 +0000 (GMT) To: peter@jazz-1.trumpet.com.au, tjc@ecs.soton.ac.uk Subject: Re: The state of IPv6 multihoming development Cc: multi6@ops.ietf.org Message-Id: <20021023002020.D871B986@ab.use.net> Date: Wed, 23 Oct 2002 00:20:20 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=2.0 required=5.0 tests=SHORT_RECEIVED_LINE,SPAM_PHRASE_05_08 version=2.41 X-Spam-Level: ** Sender: owner-multi6@ops.ietf.org Precedence: bulk | While I agree that it may not be entirely necessary for the real deployment of | IPv6, it is IPv6 opponents that continually use it to denigrate IPv6. So | that's why I said "thorn in the side" instead of a "gaping wound" :) These | people are the kinds of people who have strong influence in teh spheres of | power. Until they are silenced once and for all, they whittle away trying to | reduce any progress that IPv6 would make. Please, let's not have comments with a tone like this (from anyone, of this or contrary opinion) here, whether this was intended as a serious comment, or as a joke. Discussion of people's individual or collective motives is unlikely to be appropriate for this list. That is not to say that you should not express the opinion here, (which I hope I am summarizing reasonably), namely, that the work of multi6 is not critical to the deployment success of IPv6, but that there is unfortunate P.R. because our work here is not done. Many people on this list would agree. That said, I think it would be more productive to try to move forward on the item in front of us per the charter, namely submitting a requirements draft to the IESG for review. If you think the existing draft is ready, great. If there is consensus, we will last call it. If you think that the existing draft can use some improvements, please post those improvements here and alert the draft editor that you have done so. If you think that you can write a better draft from scratch, then please do so, and submit it in the usual manner. Finally, if you want an official forum analogous to the "-interest" 2ndary/non-work lists enjoyed by other WGs, we can probably do something about that, so that all sorts of issues related to multi6 but not specifically advancing a requirements draft, can be discussed somewhere obvious to everyone, including newcomers. Note though that even an "-interest" list would not be alt.flame, alt.conspiracy or alt.satire. Sean. (oh and please don't newgroup alt.flame.multi6. thanks.) From owner-multi6@ops.ietf.org Tue Oct 22 20:26:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08920 for ; Tue, 22 Oct 2002 20:26:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1849O0-000NB5-00 for multi6-data@psg.com; Tue, 22 Oct 2002 17:28:36 -0700 Received: from pa-monroeville1b-61.pit.adelphia.net ([24.53.182.61] helo=localhost) by psg.com with esmtp (Exim 3.36 #2) id 1849Ny-000N8R-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 17:28:34 -0700 Received: from [192.168.1.100] (localhost [127.0.0.1]) by localhost (8.12.2/8.12.2) with ESMTP id g9N0RS2O006426; Tue, 22 Oct 2002 20:27:29 -0400 (EDT) Date: Tue, 22 Oct 2002 20:27:27 -0400 From: "Michael H. Lambert" To: Tim Chown cc: Multi6 Working Group Subject: Re: The state of IPv6 multihoming development Message-ID: <21084977.1035318447@[192.168.1.100]> In-Reply-To: <20021022230427.GE2891@login.ecs.soton.ac.uk> References: <200210222057.QAA00731@ginger.lcs.mit.edu> <20021022230427.GE2891@login.ecs.soton.ac.uk> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-8.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim, > What proportion of Internet sites are multihomed? Academia generally > isn't, not to the universities, although the NRENs will have multiple > peerings. In the US, all Internet2 member universities are multihomed (or at least the GigaPoPs to which they connect are, which helps with scaling but not the underlying problem). This is true now for IPv4 and will be soon for IPv6. Eventually the NRENs will impose the same Conditions of Use on IPv6 as are currently in place for IPv4. The end result is PA + multihoming + CoU = multiple addresses, some of which have special semantics. 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 Tue Oct 22 20:28:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08959 for ; Tue, 22 Oct 2002 20:28:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1849PY-000NGV-00 for multi6-data@psg.com; Tue, 22 Oct 2002 17:30:12 -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.36 #2) id 1849PW-000NGJ-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 17:30:11 -0700 Subject: RE: The state of IPv6 multihoming development Date: Tue, 22 Oct 2002 17:30:13 -0700 Message-ID: <2B81403386729140A3A899A8B39B04640BD216@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: The state of IPv6 multihoming development X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Index: AcJ6Kq3tFtNNHGy9RzWhJ+JHSemzfAAAFrDg From: "Michel Py" To: "Sean Doran" , , "Tim Chown" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA08959 > Sean Doran wrote: > If there is consensus, we will last call it. We heard that song a year ago in this highly productive meeting we had in Salt Lake. What is the excuse for being one MORE year late than we were a year ago, this time? Michel. From owner-multi6@ops.ietf.org Tue Oct 22 20:33:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09225 for ; Tue, 22 Oct 2002 20:33:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1849UI-000NYK-00 for multi6-data@psg.com; Tue, 22 Oct 2002 17:35:06 -0700 Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by psg.com with esmtp (Exim 3.36 #2) id 1849UH-000NWl-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 17:35:05 -0700 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9N0Xxot029976; Tue, 22 Oct 2002 17:33:59 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9N0Xo2L026082; Tue, 22 Oct 2002 17:33:50 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA16694; Tue, 22 Oct 2002 17:33:48 -0700 (PDT) Date: Tue, 22 Oct 2002 19:33:49 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Tony Li cc: Tim Chown , Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Tony Li wrote: > p.s. In the past I have certainly been an opponent to IPv6. > However, my position has changed somewhat. I can see the > pressure to go down the IPv6 path and I would like to see > some good come out of the exercise. If v6 turns out to be > simply v4 with a bigger address space but it still collapses > due to the poor routing architecture, then we will have > failed miserably. So I am pushing for scalability for the > routing layer and hoping that we don't make the same mistakes > again. -- t On the other hand, it can also be argued that we have failed miserably if we don't end up with demand for this network because it cannot address baseline requirements for business. That's the path we head down with multi-PA. Noel asked if I could suggest any other mechanisms. So far, all of the multi-homing solutions I can think of that are implementable with current code do not address the requirements that enterprises have: * simple to implement and operate for the enterprise * network infrastructure visibility into alternative paths such that policy decisions may be made on paths by the infrastructure, not the host * unique, host-aware end-to-end addresses so poorly-written applications (in use in IPv4 today) will work Given that, the only solutions I can think of require changes to code, whether router or host, network or transport or application layer. This code change will require time. This time delays adoption and makes IPv6 continue to stagnate. I believe we need to come up with something now, with the current amount of energy behind IPv6, in order to bring these large enterprises on board. Otherwise, we will continue to build a great experimental network with little business value to anyone except the academic community. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Tue Oct 22 20:38:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09345 for ; Tue, 22 Oct 2002 20:38:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1849Zn-000NtM-00 for multi6-data@psg.com; Tue, 22 Oct 2002 17:40:47 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 1849Zl-000NtA-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 17:40:46 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id LAA05646; Wed, 23 Oct 2002 11:40:30 +1100 (EST) Date: Wed, 23 Oct 2002 11:40:30 +1100 (EST) From: Peter Tattam To: Sean Doran cc: tjc@ecs.soton.ac.uk, multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021023002020.D871B986@ab.use.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk I sincerly apologize - the negative tone was not intended, but rather I wanted to express the frustration which I personally have experienced when trying to promote IPv6 to groups of IT specialists who have been reluctant to see the benefits of IPv6. I am drawing from my own personal experience where I have been attacked on this very topic. 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 Oct 22 20:43:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09427 for ; Tue, 22 Oct 2002 20:43:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1849eg-000ODS-00 for multi6-data@psg.com; Tue, 22 Oct 2002 17:45:50 -0700 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net ident=6907-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-take-this-and-log-it!) by psg.com with esmtp (Exim 3.36 #2) id 1849ee-000OD5-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 17:45:48 -0700 Received: by ab.use.net (Postfix, from userid 3005) id 395BD986; Wed, 23 Oct 2002 00:45:46 +0000 (GMT) To: michel@arneill-py.sacramento.ca.us, peter@jazz-1.trumpet.com.au, smd@ab.use.net, tjc@ecs.soton.ac.uk Subject: Advancement: ready to test consensus? (was: Re: The state of ...) Cc: multi6@ops.ietf.org Message-Id: <20021023004546.395BD986@ab.use.net> Date: Wed, 23 Oct 2002 00:45:46 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=1.9 required=5.0 tests=SHORT_RECEIVED_LINE,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk Re: the advancement of the chartered/milestoned requirements draft, draft-ietf-multi6-multihoming-requirements-03.txt | We heard that song a year ago in this highly productive meeting we had | in Salt Lake. What is the excuse for being one MORE year late than we | were a year ago, this time? An insufficient number of people expressed their views on the mailing list to be able to claim that there was a clear consensus on advancing the draft as it is now & was then. If there looks like there could be a consensus on advancing the draft as it exists now, the chairs would be happy to ask for it to be demonstrated. The usual mechanism for this would be to ask for some reasonable number of "yes, advance it now" comments and few or no "no, not yet" comments (*ideally* with alternative suggestions, such as "examine and incorporate these edits I have written" or "because I have written what I think is a superior draft, which I have submitted in the usual way", which will trigger actual work in the working group, per the charter). Those of you participating in the current conversation might usefully indicate your feelings on this issue at the beginning of the next message you write, and yes, I realize this is less fun than discussing architecture and implementation. :-) Sean. From owner-multi6@ops.ietf.org Tue Oct 22 20:46:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09477 for ; Tue, 22 Oct 2002 20:46:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1849gu-000OMN-00 for multi6-data@psg.com; Tue, 22 Oct 2002 17:48:08 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 1849gs-000OMB-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 17:48:06 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 1849gr-000CU5-00; Tue, 22 Oct 2002 17:48:05 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Craig A. Huegen" Cc: Tony Li , Tim Chown , Multi6 Working Group Subject: RE: The state of IPv6 multihoming development References: Message-Id: Date: Tue, 22 Oct 2002 17:48:05 -0700 X-Spam-Status: No, hits=-5.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > On the other hand, it can also be argued that we have failed miserably if > we don't end up with demand for this network because it cannot address > baseline requirements for business. That's the path we head down with > multi-PA. > > Noel asked if I could suggest any other mechanisms. So far, all of the > multi-homing solutions I can think of that are implementable with current > code do not address the requirements that enterprises have: > > * simple to implement and operate for the enterprise > * network infrastructure visibility into alternative paths such that > policy decisions may be made on paths by the infrastructure, not the > host > * unique, host-aware end-to-end addresses so poorly-written applications > (in use in IPv4 today) will work > > Given that, the only solutions I can think of require changes to code, > whether router or host, network or transport or application layer. This > code change will require time. This time delays adoption and makes IPv6 > continue to stagnate. > > I believe we need to come up with something now, with the current amount > of energy behind IPv6, in order to bring these large enterprises on board. > Otherwise, we will continue to build a great experimental network with > little business value to anyone except the academic community. this group is chartered to refine and explore solutions to the problems of large-scale multihoming in ipv6. it is not chartered to do ipv6 marketing. and, while it would be nice to use existing code, that is not a constraint (and i suspect that, if it were, this group would likely fail). randy From owner-multi6@ops.ietf.org Tue Oct 22 20:46:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09491 for ; Tue, 22 Oct 2002 20:46:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1849hL-000OPj-00 for multi6-data@psg.com; Tue, 22 Oct 2002 17:48:35 -0700 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net ident=5264-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-take-this-and-log-it!) by psg.com with esmtp (Exim 3.36 #2) id 1849hK-000OPI-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 17:48:34 -0700 Received: by ab.use.net (Postfix, from userid 3005) id 70904986; Wed, 23 Oct 2002 00:48:32 +0000 (GMT) To: peter@jazz-1.trumpet.com.au, smd@ab.use.net Subject: Re: The state of IPv6 multihoming development Cc: multi6@ops.ietf.org, tjc@ecs.soton.ac.uk Message-Id: <20021023004832.70904986@ab.use.net> Date: Wed, 23 Oct 2002 00:48:32 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=1.9 required=5.0 tests=SHORT_RECEIVED_LINE,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk | I sincerly apologize - the negative tone was not intended, but rather I wanted | to express the frustration which I personally have experienced when trying to | promote IPv6 to groups of IT specialists who have been reluctant to see the | benefits of IPv6. I am drawing from my own personal experience where I have | been attacked on this very topic. I understand. We all have our moments of frustration and catharsis. Unfortunately, they tend to be contagious on WG mailing lists, thus the vaccination shot from me and Dr. Randy. :-) Sean. From owner-multi6@ops.ietf.org Tue Oct 22 20:55:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09723 for ; Tue, 22 Oct 2002 20:55:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1849px-000OxV-00 for multi6-data@psg.com; Tue, 22 Oct 2002 17:57:29 -0700 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net ident=9161-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-take-this-and-log-it!) by psg.com with esmtp (Exim 3.36 #2) id 1849pv-000OxG-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 17:57:28 -0700 Received: by ab.use.net (Postfix, from userid 3005) id 260A0AE3; Wed, 23 Oct 2002 00:57:25 +0000 (GMT) To: chuegen@cisco.com, Tony.Li@procket.com Subject: RE: The state of IPv6 multihoming development Cc: multi6@ops.ietf.org, tjc@ecs.soton.ac.uk Message-Id: <20021023005725.260A0AE3@ab.use.net> Date: Wed, 23 Oct 2002 00:57:25 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=1.9 required=5.0 tests=SHORT_RECEIVED_LINE,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk [broken record alert] Craig: | * simple to implement and operate for the enterprise | * network infrastructure visibility into alternative paths such that | policy decisions may be made on paths by the infrastructure, not the | host | * unique, host-aware end-to-end addresses so poorly-written applications | (in use in IPv4 today) will work Great. Perhaps you can suggest some text that could be incorporated into the requirements draft, if you think these points are not already there? Even a paragraph or two elaborating each point would be useful. The WG is here to discuss any text you come up with. Sean. From owner-multi6@ops.ietf.org Tue Oct 22 21:17:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10485 for ; Tue, 22 Oct 2002 21:17:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184ABC-0000Cy-00 for multi6-data@psg.com; Tue, 22 Oct 2002 18:19:26 -0700 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net ident=6212-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-take-this-and-log-it!) by psg.com with esmtp (Exim 3.36 #2) id 184ABB-0000Cm-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 18:19:25 -0700 Received: by ab.use.net (Postfix, from userid 3005) id 9C051AE3; Wed, 23 Oct 2002 01:19:23 +0000 (GMT) To: multi6@ops.ietf.org Subject: draft-ietf-multi6-multihoming-requirements-03.txt Message-Id: <20021023011923.9C051AE3@ab.use.net> Date: Wed, 23 Oct 2002 01:19:23 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=1.9 required=5.0 tests=SHORT_RECEIVED_LINE,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk This draft expires in one week on 30 October 2002. Have you read it? Do you think it's ready? Do you think it's not ready? Do you have an idea you think should be incorporated into the draft? Comments, please. Incidentally, three other important dates are coming in the near future: the pre-IETF draft cutoffs for initial and final submissions and the cut-off for scheduling a WG meeting (October 29), should we have wg business to discuss in Atlanta. Sean. From owner-multi6@ops.ietf.org Tue Oct 22 22:12:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12161 for ; Tue, 22 Oct 2002 22:12:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184B2a-0003Yq-00 for multi6-data@psg.com; Tue, 22 Oct 2002 19:14:36 -0700 Received: from 53.cust2.nsw.dsl.ozemail.com.au ([203.103.157.53] helo=mail.nosense.org) by psg.com with esmtp (Exim 3.36 #2) id 184B2Y-0003XW-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 19:14:34 -0700 Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 36B453B370; Wed, 23 Oct 2002 12:14:23 +1000 (EST) Subject: RE: The state of IPv6 multihoming development From: Mark Smith To: Tony Li Cc: Tim Chown , Multi6 Working Group In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 23 Oct 2002 12:14:23 +1000 Message-Id: <1035339272.8284.9.camel@dupy> Mime-Version: 1.0 X-Spam-Status: No, hits=-5.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2002-10-23 at 10:00, Tony Li wrote: > > Will homes, academia and non-enterprises multihome? Some > academic sites already are. I know of some sick netgeeks > who are already multihomed. All of it hangs in the balance > between the economic cost and the perception of mission > critical importance. I agree. My house is already multi-homed for electricity supply - my conventional phone has an independent power supply from my house. I'm already multi-homed with my voice service itself - I have both a sepearate fixed line and a mobile services. While I'm not a netgeek yet with a multi-homed Internet connections, when my Internet connection becomes as critical as my phone during emergency situations, I'd all of a sudden become very interested in multi-homing, likely via both land line and wireless. As the critical infrastructure converges onto the Internet, I think multi-homing is going to become far more common than what exists today, to the point where the majority of connections may be multi-homed. Mark. From owner-multi6@ops.ietf.org Wed Oct 23 00:20:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14547 for ; Wed, 23 Oct 2002 00:20:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184D1N-000B8U-00 for multi6-data@psg.com; Tue, 22 Oct 2002 21:21:29 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 184D1K-000B8A-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 21:21:26 -0700 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 22 Oct 2002 21:21:14 -0700 Reply-To: From: "Tony Hain" To: "'Iljitsch van Beijnum'" , "'Brian E Carpenter'" Cc: Subject: RE: The state of IPv6 multihoming development Date: Tue, 22 Oct 2002 21:20:58 -0700 Message-ID: <016101c27a4b$9aad26d0$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021022144630.N14896-100000@sequoia.muada.com> X-Spam-Status: No, hits=-4.3 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA14547 Iljitsch van Beijnum wrote: > ... > So far, the people with the deep pockets haven't entered the > v6 arena. If and when they do, they'll get their routes in > the DFZ, whether we like it or not. This is the bottom line to: http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt To a first order I don't care what PI mechanism we end up with, but it is very clear that one will happen. If we do nothing it will simply be random holes punched in the PA space. I have continued working on the particular proposal because even the minimal implementation decouples the 120 degree regions that would cover EMEA/AsiaPac/Americas. This has value and does not require a deployment to cover the problem of an individual connection terminating outside its natural geo region. At the same time, it is conceivable that the 200+ existing exchange points and private peering connections would allow the scaling to be much better than the simple 3. Tony From owner-multi6@ops.ietf.org Wed Oct 23 01:42:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15766 for ; Wed, 23 Oct 2002 01:42:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184EIt-000GAf-00 for multi6-data@psg.com; Tue, 22 Oct 2002 22:43:39 -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.36 #2) id 184EIr-000G90-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 22:43:37 -0700 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Tue, 22 Oct 2002 22:43:33 -0700 Message-ID: <2B81403386729140A3A899A8B39B04640BD218@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ5olk1cJB1SYB9Sg2Y+Ch6cNiYAgAtIt4Q From: "Michel Py" To: "RJ Atkinson" , "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA15766 Ran, >> Iljitsch van Beijnum wrote: >> 4. Work on geographical aggregation, especially by getting >> an address allocation mechanism that supports this off the >> ground. > RJ Atkinson wrote: > At best, a different term needs to be found other than > "geographical aggregation". At worst, this is a bad idea. How could you voice an opinion about a solution without seing it? Michel. From owner-multi6@ops.ietf.org Wed Oct 23 01:48:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15819 for ; Wed, 23 Oct 2002 01:48:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184EPS-000GZJ-00 for multi6-data@psg.com; Tue, 22 Oct 2002 22:50:26 -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.36 #2) id 184EPR-000GZ6-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 22:50:25 -0700 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Tue, 22 Oct 2002 22:50:24 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E39C@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ5ocBOPjyFVP4QQ5KRIZyb9RWnsQAtPZHw From: "Michel Py" To: "Eliot Lear" , "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=-4.6 required=5.0 tests=DEAR_SOMEBODY,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA15819 Eliot, > Eliot Lear wrote: > More importantly, however, I believe the document is actually > an impediment to moving forward. One can view the document in > two ways, and neither is positive. Either the points made in > the document are so obvious as to not be worth writing down, > or they are so constraining as to make the resulting solution > not worth implementing. I strongly agree. > The question then turns to this: should we revisit the > requirements document, or simply discard it and place effort > more along the lines of the note sent by Iljitsch van > Beijnum? It's not that the document is completely wrong. > I just don't want architects to be so bound by it that we > end up with something less lasting or useful. If it was called "recommendations" instead of "requirements" it would then be design guidelines instead of making it impossible to deliver. This requirements doc is like a letter to Santa Claus. Dear Santa, This is what I want for my IPv6 multihoming solution. [..] it needs to be perfect. > Let's have the engineering tradeoffs on the table. It appears that the chairs and some other politically powerful members prefer the status quo (do I need to post quotes from this very mailing list)? Please please say yes. It also appears that the charter says that's what we should have been doing 18 months ago: > APR 01 Begin consideration of approaches and proposals that could > be pursued. Apparently, some people have trouble reading charters in here. Michel. From owner-multi6@ops.ietf.org Wed Oct 23 01:57:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15967 for ; Wed, 23 Oct 2002 01:57:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184EXo-000H8v-00 for multi6-data@psg.com; Tue, 22 Oct 2002 22:59:04 -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.36 #2) id 184EXm-000H8j-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 22:59:02 -0700 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Tue, 22 Oct 2002 22:59:01 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E39D@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ6BE4x2hCbyJWeTq2JGv2cCEUsGQAU+4aQ From: "Michel Py" To: "Craig A. Huegen" , "Brian E Carpenter" Cc: "Iljitsch van Beijnum" , "RJ Atkinson" , X-Spam-Status: No, hits=-3.6 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA15967 Craig, > Craig A. Huegen wrote: > Adoption of IPv6 in enterprises REQUIRES multihoming. It's not a > "nice-to-have". Without it, IPv6 in enterprises is limited to > the labs. If this means we have to accept some type of PI > addressing in the near-term, then so be it, with the condition > that those using it are given time frame to migrate to the > Ultimate Multihoming Solution in the future. I have come to agree with this compromise. Reality check: IPv6 does not exist. It does not exist because I can't get over v6 to www.etrade.com. I can't get to www.cnn.com. I can't get to www.yahoo.com. And yes, I can get over v6 to Cisco because I have 6bone tunnels, that's why I use IPv4. > As for the original multi-PA multihoming solution, it doesn't > fly in an enterprise. > [sniped the reasons] I agree too. > If the goal was to design a theoretical protocol without > end-user operational considerations that can keep DFZ routing > tables under 16k prefixes, then we're doing a good job at > designing multi-homing. If the goal is to gain adoption by and > reliability for the end users of the IPv6 internet, we're > failing. Ditto. Michel. From owner-multi6@ops.ietf.org Wed Oct 23 02:00:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16535 for ; Wed, 23 Oct 2002 02:00:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184EbV-000HOR-00 for multi6-data@psg.com; Tue, 22 Oct 2002 23:02:53 -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.36 #2) id 184EbT-000HO7-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 23:02:51 -0700 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Tue, 22 Oct 2002 23:02:50 -0700 Message-ID: <2B81403386729140A3A899A8B39B04640BD21B@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ6BFC9Lwzl8Yq3Rda7C2qdeZ6yjwAVVwmw From: "Michel Py" To: "Brian E Carpenter" , "Eliot Lear" Cc: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=-3.6 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA16535 Brian, > Brian E Carpenter wrote: > I think we need the document, but since it does indeed contain > conflicting requirements that will need tradeoffs, it clearly > SHOULD NOT contain pseudo-normative language. I would suggest > that all the upper case normative words should be replaced by > shoulds and should nots in lower case, and then just ship the > thing as Informational. Replace "requirements" with "recommendations" and I'm with you. Michel. From owner-multi6@ops.ietf.org Wed Oct 23 02:04:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18909 for ; Wed, 23 Oct 2002 02:04:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184EeL-000HcK-00 for multi6-data@psg.com; Tue, 22 Oct 2002 23:05:49 -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.36 #2) id 184EeJ-000Hc6-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 23:05:47 -0700 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Tue, 22 Oct 2002 23:05:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B04640BD21C@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ6DpSlQGD89vjeSayc9dY7iEElbQAS4IOg From: "Michel Py" To: "J. Noel Chiappa" , X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA18909 From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] > So there's another possible solution for people who really > want to multi-home: use IPv6 Mobility. This does not address enterprise concerns at all. Michel. From owner-multi6@ops.ietf.org Wed Oct 23 02:35:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09703 for ; Wed, 23 Oct 2002 02:35:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184F87-000JXj-00 for multi6-data@psg.com; Tue, 22 Oct 2002 23:36:35 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 184F85-000JXJ-00 for multi6@ops.ietf.org; Tue, 22 Oct 2002 23:36:33 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9N6Yph26496; Wed, 23 Oct 2002 09:34:51 +0300 Date: Wed, 23 Oct 2002 09:34:51 +0300 (EEST) From: Pekka Savola To: "Michael H. Lambert" cc: Tim Chown , Multi6 Working Group Subject: The term multihoming [Re: The state of IPv6 multihoming development In-Reply-To: <21084977.1035318447@[192.168.1.100]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Michael H. Lambert wrote: > > What proportion of Internet sites are multihomed? Academia generally > > isn't, not to the universities, although the NRENs will have multiple > > peerings. > > In the US, all Internet2 member universities are multihomed (or at least > the GigaPoPs to which they connect are, which helps with scaling but not > the underlying problem). This is true now for IPv4 and will be soon for > IPv6. Eventually the NRENs will impose the same Conditions of Use on IPv6 > as are currently in place for IPv4. The end result is PA + multihoming + > CoU = multiple addresses, some of which have special semantics. Careful with the terminology... In multihoming, two or more network connections to the same connectivity provider is a trivial case we don't have to worry about. I believe this is what most academia do (we too). Now, if a university would want to advertise it's /48 using commodity Internet as a backup too.. that would be the problem we're solving. -- 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 Oct 23 05:10:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11857 for ; Wed, 23 Oct 2002 05:10:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184HXz-0000gm-00 for multi6-data@psg.com; Wed, 23 Oct 2002 02:11:27 -0700 Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by psg.com with esmtp (Exim 3.36 #2) id 184HXx-0000g2-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 02:11:25 -0700 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9N9Akot007149; Wed, 23 Oct 2002 02:10:46 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9N9Af1t023591; Wed, 23 Oct 2002 02:10:41 -0700 (PDT) Received: from cisco.com (rtp-vpn2-253.cisco.com [10.82.240.253]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id CAA00322; Wed, 23 Oct 2002 02:10:42 -0700 (PDT) Message-ID: <3DB66792.2010903@cisco.com> Date: Wed, 23 Oct 2002 02:10:42 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: "J. Noel Chiappa" , multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development References: <20021022190631.D14896-100000@sequoia.muada.com> In-Reply-To: <20021022190631.D14896-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Nothing like 60 messages in one day after nothing in 6 months ;-) Iljitsch van Beijnum wrote: > I'm not convinced this is an "extra" service. As Tony Li knows well I've never been one for artificial shortages and markets (which is what I think we have in v4). On the other hand, you yourself later wrote the precise contradiction to this statement: > Unfortunately, hierarchy -> tree structure -> no loops -> no redundancy. Now, you could argue that the additional mechanism required should be at the transport or in a tunnel, or whatever. But that's additional infrastructure as well. By the way, Michel, when we use the term tunnel, in any form, we really ought to revisit existing technology to see if it can be adopted. Thus Noel's allusion to MIPv6. I'm not convinced. I think we have to consider Craig's complexity question, but at the same time ask him what he's willing to pay for redundancy for his service, and what sort of redundancy he needs. > So who benefits if Google is multihomed? The user or the server? Or > both? Google, or they wouldn't pay to be multihomed. If their users experience a better service, in the end that is to Google's advantage. But let's also separate web services from Craig's case. It's easy to do a service that knows about topology and delivers a single "close" address to a client name server or redirect to a client. Been there done that. In fact the actual physical hosts may not even be multihomed into the Internet, nor might their upstreams be. Craig's problem is a lot more difficult. Choosing the right source address in a large enterprise network is difficult. Getting both the physics and economics correct here is important. > For straight PI (or "CI") it is true that many organizations other than > the multihomed one have to bear costs. However, this is far from > "everyone else": only people who are default-free _need_ to pay for the > extra memory and CPU power for their routers. In a multiple address > solution this is much, much worse: in that case, all IPv6 hosts may have > to implement extra functionality to be able to talk to multihomed > destinations. This is only because there isn't a viable alternative in v6 yet. When there is you can impose a cost model in v4 and let the market do its thing. And that cost model would include things like "maintenance of legacy v4 infrastructure, route sourcing charges, etc." The IETF actually has heard from game theory researchers on this topic. Not new. The *real* cost I want to understand is how much someone is willing to pay to have fine grain control over their policy as they do today with BGP, padding, etc. Eliot From owner-multi6@ops.ietf.org Wed Oct 23 06:04:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12635 for ; Wed, 23 Oct 2002 06:04:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184IOj-0002yL-00 for multi6-data@psg.com; Wed, 23 Oct 2002 03:05:57 -0700 Received: from c2bapps5.btconnect.com ([193.113.209.26]) by psg.com with smtp (Exim 3.36 #2) id 184IOZ-0002vV-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 03:05:47 -0700 Received: from ati (actually host host62-7-22-91.in-addr.btopenworld.com) by c2bapps5 with SMTP-CUST (XT-PP) with ESMTP; Wed, 23 Oct 2002 11:05:15 +0100 Reply-To: From: "Christian de Larrinaga" To: "Tim Chown" , "Tony Li" Cc: "Multi6 Working Group" Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 11:05:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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: <20021022232702.GF2891@login.ecs.soton.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=-6.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_OUTLOOK version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim > > OK, containment (of the DFZ table size) is certainly a good goal. > > But who is actually going to be multihoming with IPv6, and to what extent? > Perhaps there are now 50,000 large enterprises doing so with IPv4. Is the > number of such enterprises going to rise? What's the change in terms of > the types of sites multihoming that's pushing the DFZ size up so much? > Small ISPs? Smaller enterprises? > this is a guess... ok;-) the size of the ipv6 address space itself is likely to open up multihoming demand. for instance if we deploy trillions of embedded networked devices its a fair assumption that a few hundred million will be considered sufficiently mission critical as to warrant a redundant IP path even if they have a very light data load. now you say 50,000 in ip4 and on very expensive communications links and limited business applications. What's the proportion of this number multihoming to the address space in ip4 and would it be valid to apply that proportion to ipv6? well it might give us something to think about at least. Also consider that 64k line costs of $20,000 per annum and today dsl of $300 and FTTH potentially of $50 (perhaps without service) what impact then on demand for multi homing? We can only guess but my guess is that it would be a mistake to think multi homing in ipv6 only applies to a few big boys because that's the lesson from the history of big iron computing. Christian Christian de Larrinaga From owner-multi6@ops.ietf.org Wed Oct 23 06:05:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12649 for ; Wed, 23 Oct 2002 06:05:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184IOa-0002xf-00 for multi6-data@psg.com; Wed, 23 Oct 2002 03:05:48 -0700 Received: from c2bapps5.btconnect.com ([193.113.209.26]) by psg.com with smtp (Exim 3.36 #2) id 184IOY-0002vV-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 03:05:46 -0700 Received: from ati (actually host host62-7-22-91.in-addr.btopenworld.com) by c2bapps5 with SMTP-CUST (XT-PP) with ESMTP; Wed, 23 Oct 2002 11:05:12 +0100 Reply-To: From: "Christian de Larrinaga" To: "Craig A. Huegen" , "Tony Li" Cc: "Tim Chown" , "Multi6 Working Group" Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 11:05:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=-6.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_OUTLOOK version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Behalf Of Craig A. Huegen > Noel asked if I could suggest any other mechanisms. So far, all of the > multi-homing solutions I can think of that are implementable with current > code do not address the requirements that enterprises have: > > * simple to implement and operate for the enterprise > * network infrastructure visibility into alternative paths such that > policy decisions may be made on paths by the infrastructure, not the > host > * unique, host-aware end-to-end addresses so poorly-written applications > (in use in IPv4 today) will work true for all users (not just *enterprises*) Christian From owner-multi6@ops.ietf.org Wed Oct 23 07:47:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14497 for ; Wed, 23 Oct 2002 07:47:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Jzd-0007rD-00 for multi6-data@psg.com; Wed, 23 Oct 2002 04:48:09 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184Jza-0007qs-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 04:48:07 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9NBkUL19316; Wed, 23 Oct 2002 13:46:30 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Oct 2002 13:46:30 +0200 (CEST) From: Iljitsch van Beijnum To: Brian E Carpenter cc: Subject: Re: Requirements draft In-Reply-To: <3DB546E3.8BD70B46@hursley.ibm.com> Message-ID: <20021023131949.T14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Brian E Carpenter wrote: > I think we need the document, but since it does indeed contain conflicting > requirements that will need tradeoffs, it clearly SHOULD NOT contain > pseudo-normative language. I would suggest that all the upper case normative > words should be replaced by shoulds and should nots in lower case, and then > just ship the thing as Informational. I second that commotion. After reading http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-requirements-03.txt again it seems to me that the problem isn't so much that the requirements are unreasonable or clash (well, at least not all that badly), but that many of the requirements aren't quantifiable. For instance, a solution should be simple. Coulnd't agree more. But what is simple? To me, configuring a router for BGP is much simpler than driving a car, as I do the former on a weekly basis and don't have a driver's license. For other people, this may very well be different. In any event, the requirements as they are now should provide a basis to prefer one solution over the other, if one solution consistently meets the requirements to a larger degree than another. So that would be: YES to the current requirements, but without the normative language: Brian E Carpenter Iljitsch van Beijnum NO to the current requirements: From owner-multi6@ops.ietf.org Wed Oct 23 08:20:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15286 for ; Wed, 23 Oct 2002 08:20:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184KWE-0009Qi-00 for multi6-data@psg.com; Wed, 23 Oct 2002 05:21:50 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184KWC-0009QW-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 05:21:48 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9NCKEL19367 for ; Wed, 23 Oct 2002 14:20:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Oct 2002 14:20:13 +0200 (CEST) From: Iljitsch van Beijnum To: Subject: Agenda for Atlanta Message-ID: <20021023134838.V14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk There is one thing I'm not entirely clear on about the IETF meetings. Are the wg sessions usually only/mostly populated by the same people that are on the wg mailinglist, or do these sessions draw a wider public? I'm not sure doing what we are doing on this mailinglist in person for a couple of hours will achieve all that much. (A good bar brawl might help, though.) However, if we can get some routing, transport protocol and mobility people together, we may actually come up with some new insights or even a broad consensus. What I have in mind is more or less a "present our findings" session. As having a wg session requires some consensus, please let me know if you find this useful, and whether you like some other agenda item in addition to this or as a replacement. Iljitsch From owner-multi6@ops.ietf.org Wed Oct 23 08:56:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16803 for ; Wed, 23 Oct 2002 08:56:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184L47-000AeV-00 for multi6-data@psg.com; Wed, 23 Oct 2002 05:56:51 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184L44-000AeC-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 05:56:48 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9NCtDK19412; Wed, 23 Oct 2002 14:55:13 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Oct 2002 14:55:13 +0200 (CEST) From: Iljitsch van Beijnum To: Tim Chown cc: Multi6 Working Group Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021022230427.GE2891@login.ecs.soton.ac.uk> Message-ID: <20021023144442.G14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Tim Chown wrote: > > One thing still remains clear though - multihoming is the thorn in the side for > > IPv6. Until it is finalized, IPv6 will be going nowhere. > What proportion of Internet sites are multihomed? Academia generally isn't, > not to the universities, although the NRENs will have multiple peerings. But they do often have PI space. How would universities like it if they had to renumber every time their transit ISP changes? This could be called "serial multihoming": an organization doesn't actually multihome, but changes ISPs relatively frequently. > What proportion of Internet enterprise sites are mission critical? Business still send out bills through regular mail. At some point in the future, they're going to realize this costs a lot of money and is very inconvenient. When they start sending out bills over the net, suddenly their connectivity becomes mission ciritical. I'm not sure our billion multihomers is very realistic, but expecting we can do IPv4-style multihoming and not run into trouble is a very big risk. Don't forget that in IPv4, lots of organizations can't effectively multihome, because they can't get a large enough block of addresses and small blocks are filtered. In IPv6, everyone gets a /48 so filtering on prefix length doesn't work anymore and it's all or nothing. > How frequently are multihomed sites calling on their resilient links? When you have extra links, you usually load balance/traffic engineer your traffic over them. See http://www.oreilly.com/catalog/bgp/chapter/ch06.html on how to do this. :-) > How much of the IPv4 DFZ clutter is due to multihomed sites? Actually not that much. There are less than 30k ASes, and around half of them are visible in the global routing table. Of those, a fair number must be ISPs. Iljitsch From owner-multi6@ops.ietf.org Wed Oct 23 09:26:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22476 for ; Wed, 23 Oct 2002 09:26:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184LXo-000BkO-00 for multi6-data@psg.com; Wed, 23 Oct 2002 06:27:32 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184LXl-000BkC-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 06:27:30 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9NDPqB19458; Wed, 23 Oct 2002 15:25:52 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Oct 2002 15:25:52 +0200 (CEST) From: Iljitsch van Beijnum To: Tony Hain cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <016101c27a4b$9aad26d0$4b194104@eagleswings> Message-ID: <20021023151736.S14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 22 Oct 2002, Tony Hain wrote: > > So far, the people with the deep pockets haven't entered the > > v6 arena. If and when they do, they'll get their routes in > > the DFZ, whether we like it or not. > This is the bottom line to: > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt > To a first order I don't care what PI mechanism we end up with, but it > is very clear that one will happen. If we do nothing it will simply be > random holes punched in the PA space. Actually holes in PA space is perfectly fine for the network, as you can filter the more specifics and still have connectivity. However, it is not so great for the organization using the addresses since this doesn't address all failure modes. > I have continued working on the particular proposal because even the > minimal implementation decouples the 120 degree regions that would cover > EMEA/AsiaPac/Americas. This has value and does not require a deployment > to cover the problem of an individual connection terminating outside its > natural geo region. At the same time, it is conceivable that the 200+ > existing exchange points and private peering connections would allow the > scaling to be much better than the simple 3. We did discuss this proposal at length on a different mailinglist. My view was that it needs to address the problem of address density at the poles and the fact that the aggregation boundaries don't fit either topology or geography. This could be done by having several instances of this address space and have two places that would otherwise be aggregated together sit in a different instance. By rotating the axes and limiting everything to (say) from -60 to +60 degrees you eliminate the pole problem. Still, there is one unanswered question: what problem is solved by having such a close relationship between geography and address space? From owner-multi6@ops.ietf.org Wed Oct 23 10:07:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00501 for ; Wed, 23 Oct 2002 10:07:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184MAG-000DEY-00 for multi6-data@psg.com; Wed, 23 Oct 2002 07:07:16 -0700 Received: from ebola.psc.edu ([128.182.61.124] helo=localhost) by psg.com with esmtp (Exim 3.36 #2) id 184MAE-000DE6-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 07:07:14 -0700 Received: from ebola.psc.edu (localhost [127.0.0.1]) by localhost (8.12.2/8.12.2) with ESMTP id g9NE6N2O006780; Wed, 23 Oct 2002 10:06:25 -0400 (EDT) Date: Wed, 23 Oct 2002 10:06:23 -0400 From: "Michael H. Lambert" To: Pekka Savola cc: Tim Chown , Multi6 Working Group Subject: Re: The term multihoming Message-ID: <22131352.1035367583@ebola.psc.edu> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-8.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Careful with the terminology... > > In multihoming, two or more network connections to the same connectivity > provider is a trivial case we don't have to worry about. I believe this > is what most academia do (we too). Understood. On one side we have four universities and a few other entities. On the other, three commodity providers and two R&E networks. I'd call that multihoming. We currently have a PA allocation from one of the R&E networks; if we were to ask, we could receive addresses from the other R&E network and, probably, one of the commodity providers. We haven't asked, because multiple PA addresses on an interface would be problematic in our environment. 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 Wed Oct 23 10:45:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07947 for ; Wed, 23 Oct 2002 10:45:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Mmo-000ErS-00 for multi6-data@psg.com; Wed, 23 Oct 2002 07:47:06 -0700 Received: from nic-ks.greatplains.net ([164.113.238.2]) by psg.com with esmtp (Exim 3.36 #2) id 184MmI-000EpF-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 07:46:34 -0700 Received: from nic-ks.greatplains.net (localhost.greatplains.net [127.0.0.1]) by nic-ks.greatplains.net (8.12.5/8.12.5) with ESMTP id g9NEjIl7020710; Wed, 23 Oct 2002 09:45:18 -0500 (CDT) (envelope-from rrsum@greatplains.net) Received: from localhost (rrsum@localhost) by nic-ks.greatplains.net (8.12.5/8.12.5/Submit) with ESMTP id g9NEjIp9020707; Wed, 23 Oct 2002 09:45:18 -0500 (CDT) X-Authentication-Warning: nic-ks.ip6.greatplains.net: rrsum owned process doing -bs Date: Wed, 23 Oct 2002 09:45:18 -0500 (CDT) From: Rick Summerhill To: "Michael H. Lambert" cc: Multi6 Working Group Subject: Re: The term multihoming In-Reply-To: <22131352.1035367583@ebola.psc.edu> Message-ID: <20021023094208.P20694-100000@nic-ks.greatplains.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,X_AUTH_WARNING version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Michael H. Lambert wrote: > > Careful with the terminology... > > > > In multihoming, two or more network connections to the same connectivity > > provider is a trivial case we don't have to worry about. I believe this > > is what most academia do (we too). > > Understood. On one side we have four universities and a few other > entities. On the other, three commodity providers and two R&E networks. > I'd call that multihoming. > > We currently have a PA allocation from one of the R&E networks; if we were > to ask, we could receive addresses from the other R&E network and, > probably, one of the commodity providers. We haven't asked, because > multiple PA addresses on an interface would be problematic in our > environment. Let me chime in with an example from academia that is going to hit is very soon if v6 is to take off. Like Michael, I run a gigapop connected to research backbones and multiple commodity providers. Call my network A, and include in that network a potential for 5 (PA) prefixes. Below me, sits several state networks. They connect to me, would get our prefixes and they might also have their own commodity connections, almost always multiple in number. Call that network B, and add another 2 prefixes. Below that state network, sits a university. They may have only one connection to the state network, but they may have to deal with the above prefixes. They may also feel the necessity to have their own commodity connection, or they may indeed connect to a specialized research network, taking in another set of prefixes. Call that network C. Below C, sits an extension office D out in a remote county that connects to the university for research purposes, but they also has as part of their mission serving the rural community. They may want to have redundancy in their connectivity, to simply serve their county needs. This simple site has multiple computers and other research gathering devices in their offices and field equipment, and therefore will most likely utilize a /48. Finally, this is not way off in the future. As Michael indicates, we run a native v6 connection to a research backbone at this time and want to connect to our commodity providers via v6 also. If v6 is to propagate, this issue must be dealt with. --Rick -- Rick Summerhill Executive Director, GPN 5008 Canyon Road rrsum@greatplains.net Manhattan, KS 66503 Cell: 785-341-7878 Voice: 785-587-4642 Fax: 785-587-4642 From owner-multi6@ops.ietf.org Wed Oct 23 11:24:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14948 for ; Wed, 23 Oct 2002 11:24:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184NNz-000Gb5-00 for multi6-data@psg.com; Wed, 23 Oct 2002 08:25:31 -0700 Received: from nic-ks.greatplains.net ([164.113.238.2]) by psg.com with esmtp (Exim 3.36 #2) id 184NNx-000Gas-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 08:25:29 -0700 Received: from nic-ks.greatplains.net (localhost.greatplains.net [127.0.0.1]) by nic-ks.greatplains.net (8.12.5/8.12.5) with ESMTP id g9NFO8l7020847; Wed, 23 Oct 2002 10:24:08 -0500 (CDT) (envelope-from rrsum@greatplains.net) Received: from localhost (rrsum@localhost) by nic-ks.greatplains.net (8.12.5/8.12.5/Submit) with ESMTP id g9NFO89Y020844; Wed, 23 Oct 2002 10:24:08 -0500 (CDT) X-Authentication-Warning: nic-ks.ip6.greatplains.net: rrsum owned process doing -bs Date: Wed, 23 Oct 2002 10:24:08 -0500 (CDT) From: Rick Summerhill To: Jim Fleming cc: "Michael H. Lambert" , Multi6 Working Group Subject: Re: The term multihoming In-Reply-To: <02f201c27aa6$b2a2aac0$0100a8c0@repligate> Message-ID: <20021023102024.B20827-100000@nic-ks.greatplains.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,X_AUTH_WARNING version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Jim Fleming wrote: > ----- Original Message ----- > From: "Rick Summerhill" > > we run a native v6 connection to a research backbone at this time and > > want to connect to our commodity providers via v6 also. If v6 is to > > propagate, this issue must be dealt with. > > > > Rather than describing a hierarchy of networks, you might want to consider > the end-to-end Architecture of the Internet, and first start by describing how > your nodes are numbered (addressed) in the 128-bit address field. > > Do you have the Persistent Part of the address in the Right 64 bits or the Left 64 bits ? In the case of the extension office, with multiple /48's obtained from above, the right 80 bits would remain the same. If they had a /64, then the right 64 bits would remain the same (by right here, I mean the host portion of the address). --Rick -- Rick Summerhill Executive Director, GPN 5008 Canyon Road rrsum@greatplains.net Manhattan, KS 66503 Cell: 785-341-7878 Voice: 785-587-4642 Fax: 785-587-4642 From owner-multi6@ops.ietf.org Wed Oct 23 11:51:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20550 for ; Wed, 23 Oct 2002 11:51:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Nor-000HwQ-00 for multi6-data@psg.com; Wed, 23 Oct 2002 08:53:17 -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.36 #2) id 184Noq-000HwD-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 08:53:16 -0700 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 08:53:11 -0700 MIME-Version: 1.0 Message-ID: <2B81403386729140A3A899A8B39B046405E3A0@server2000> Content-Type: text/plain; charset="us-ascii" X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ6dT4+94mNI2gOSoKHKVFIw0tg1gALxuqQ From: "Michel Py" To: "Eliot Lear" , "Iljitsch van Beijnum" Cc: "J. Noel Chiappa" , X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA20550 Eliot, > Eliot Lear wrote: > Nothing like 60 messages in one day after nothing > in 6 months ;-) On the ipv6mh list we averaged 140 posts a month over 8 months, nothing new to us. This list has been asleep for too long, you just forgot what is was. > By the way, Michel, when we use the term tunnel, in any form, > we really ought to revisit existing technology to see if it > can be adopted. Thus Noel's allusion to MIPv6. In that context, I'm all for it. When you look at MHAP, one of the base mechanisms is MIPv6-like anyway (the rendezvous points). > I'm not convinced. I think we have to consider Craig's > complexity question, but at the same time ask him what > he's willing to pay for redundancy for his service, and > what sort of redundancy he needs. I don't think this is a fair question to Craig, because he is between the rock and the hard place. Cisco MUST have an IPv6 internal network just to save the face. That being said, what we hear from large companies whose business in not to sell routers is that they already got the (IPv4) multihoming solution they want, so why bother with an inferior (IPv6) solution, especially when almost nobody's asking for it? > The *real* cost I want to understand is how much someone is > willing to pay to have fine grain control over their policy > as they do today with BGP, padding, etc. We have raised this question before and the answer is that large customers would be willing to pay large RIR fees for it *if* there was customer demand (the RIRs would then give a break to operators that have to support the infrastructure). Michel. From owner-multi6@ops.ietf.org Wed Oct 23 11:52:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20666 for ; Wed, 23 Oct 2002 11:52:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Nq3-000Hzn-00 for multi6-data@psg.com; Wed, 23 Oct 2002 08:54:31 -0700 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #2) id 184Nq0-000HzP-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 08:54:28 -0700 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g9NFrAG00445 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 23 Oct 2002 11:53:12 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g9NFr9sL027812 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 23 Oct 2002 11:53:10 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g9NFr7Sn027808 for ; Wed, 23 Oct 2002 11:53:08 -0400 Message-Id: <200210231553.g9NFr7Sn027808@marajade.sandelman.ottawa.on.ca> To: "Multi6 Working Group" Subject: Re: The state of IPv6 multihoming development In-reply-to: Your message of "Tue, 22 Oct 2002 17:00:29 PDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 23 Oct 2002 11:53:07 -0400 From: Michael Richardson X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tony" == Tony Li writes: Tony> A side point: another result that we got from CIDR is that even at Tony> 10% of the enterprises being multihomed, that their contribution to Tony> the DFZ tables would come to dominate the size of the table and Tony> push us back into exponential growth extremely quickly. Or, Tony> another way of looking at it is that when you have exponential Tony> growth, dividing the problem by 10 only gets you about one growth Tony> cycle of relief. It doesn't solve the issue entirely. This is a useful thing to understand. Tony> Will homes, academia and non-enterprises multihome? Some academic Tony> sites already are. I know of some sick netgeeks who are already Tony> multihomed. All of it hangs in the balance between the economic Tony> cost and the perception of mission critical importance. I know multiple homes and small business who have multiple network connections because they don't want to be offline. They do not show up as multihomed because they manage with a combination of NAT, source address routing, use of explicit web proxies and educated guessing. We have been down this road before. I though we were in agreement on two things: 1) that multihoming would increase, 2) and that we can't do it like IPv4. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPbbF34qHRg3pndX9AQF5WwQAm9P5ZfYvusfZh++gcxhtM/Sf1M4631sW VnpkMTjWCw7pwbtS8YDdSY4YlMTnbhwEJ4wDXDL0lMLXxzDV2uyRhVucGw+NIHyo me/kWfAj74qaOT6lz9aAxpsKlTWJjdvO29d1uhdElaNuBQi0s10LD+64Ek++Ut20 2Xk5udLUbEk= =V7kp -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Oct 23 12:16:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24009 for ; Wed, 23 Oct 2002 12:16:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184OCX-000J8o-00 for multi6-data@psg.com; Wed, 23 Oct 2002 09:17:45 -0700 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #2) id 184OCV-000J85-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 09:17:43 -0700 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g9NGGLG00556 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 23 Oct 2002 12:16:27 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g9NGGKsL028014 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 23 Oct 2002 12:16:20 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g9NGGJJ1028010 for ; Wed, 23 Oct 2002 12:16:19 -0400 Message-Id: <200210231616.g9NGGJJ1028010@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development In-reply-to: Your message of "Tue, 22 Oct 2002 00:51:42 PDT." <3DB5038E.5000305@cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 23 Oct 2002 12:16:18 -0400 From: Michael Richardson X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> "Eliot" == Eliot Lear writes: Eliot> I suspect the authors cannot agree on how to proceed, Eliot> but I haven't actually discussed the matter with them. I think that there is other stuff occuring as well. I know that some of the authors have changed jobs vastly. Sean, can you put us back on track? Eliot> The question then turns to this: should we revisit the Eliot> requirements document, or simply discard it and place effort more Eliot> along the lines of the note sent by Iljitsch van Beijnum? It's Eliot> not that the document is completely wrong. I just don't want Eliot> architects to be so bound by it that we end up with something less Eliot> lasting or useful. I would like to see things divided up into three categories: 1) agreed to requirements. These are EXPLICITELY in scope. 2) agreed to non-requirements. These are EXPLICITELY OUT OF SCOPE. 3) requirements which to be controversial. These will be debated, and likely it is based upon whether we ultimately rule it in scope or out of scope that will determine the nature of the solution. Iljitsch has listed the possible solutions. The problem is that we don't know how we are going to decide on which is best. I think that I know the best solution, but I have learnt that not every agrees, and some run away screaming. I would like to walk through the proposals, and get a better understanding of the objections to them. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-multi6@ops.ietf.org Wed Oct 23 12:19:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24057 for ; Wed, 23 Oct 2002 12:19:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184OFs-000JJI-00 for multi6-data@psg.com; Wed, 23 Oct 2002 09:21:12 -0700 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #2) id 184OFq-000JJ6-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 09:21:10 -0700 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g9NGJmG00561 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 23 Oct 2002 12:19:54 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g9NGJlsL028029 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 23 Oct 2002 12:19:48 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g9NGJkLa028026 for ; Wed, 23 Oct 2002 12:19:47 -0400 Message-Id: <200210231619.g9NGJkLa028026@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development In-reply-to: Your message of "Tue, 22 Oct 2002 04:01:30 EDT." <792AAC82-E594-11D6-B646-00039357A82A@extremenetworks.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 23 Oct 2002 12:19:46 -0400 From: Michael Richardson X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "RJ" == RJ Atkinson writes: RJ> On Monday, Oct 21, 2002, at 17:24 America/Montreal, Iljitsch van RJ> Beijnum wrote: >> 4. Work on geographical aggregation, especially by getting an address >> allocation mechanism that supports this off the ground. RJ> At best, a different term needs to be found other than "geographical RJ> aggregation". At worst, this is a bad idea. RJ> The problem is that just because I am in city X, that still does not RJ> mean that any of the ISPs that I connect to will interconnect inside RJ> X. In all cases so far, I am on a tail circuit that goes to a Perhaps this is a problem! 1) Maybe we can never solve the aggregation problem until we change this statement. RJ> In short, the IP routing topology is NOT closely congruent with the RJ> world's geographical topology. If we assign addresses not congruent 2) maybe geographical based addresses are always tunnelled. They are not intended to be efficiently routed, just efficiently aggregated. So, Ran, you are perfectly correct that geographical addresses are useless in an IPv4 model 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPbbMIIqHRg3pndX9AQH2NgQAjZxqwBGmieBXDxVPAxSpN/id8pTHo7po toLVDBvYiO8bE3EZ3/q6Is/OSzLEPS5SoZToitmY12TddZrtQ3P8du8CCUngpTFw KLmlkaYb2dbWcPRFbcgyFD4baTFo/WrawtAG1wzULeZgfxqEFRe0syBvn2jyKvZ6 15ZZNqzmbIE= =V1Y2 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Oct 23 13:12:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25887 for ; Wed, 23 Oct 2002 13:12:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184P4L-000LiN-00 for multi6-data@psg.com; Wed, 23 Oct 2002 10:13:21 -0700 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #2) id 184P4J-000LiB-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 10:13:19 -0700 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g9NHC2G00699 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 23 Oct 2002 13:12:03 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g9NHC0sL028350 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 23 Oct 2002 13:12:01 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g9NHBxHu028347 for ; Wed, 23 Oct 2002 13:11:59 -0400 Message-Id: <200210231711.g9NHBxHu028347@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03.txt In-reply-to: Your message of "Wed, 23 Oct 2002 01:19:23 -0000." <20021023011923.9C051AE3@ab.use.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 23 Oct 2002 13:11:59 -0400 From: Michael Richardson X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Sean" == Sean Doran writes: Sean> This draft expires in one week on 30 October 2002. I guess that the draft has expired once already in June. My scripts picked up the new copy from June 11th again, but didn't sort it properly for me, so it looked like it was still expired. Sean> Have you read it? Do you think it's ready? Do you think it's not I have just re-read it from top to bottom, and I think that it is ready. I partially agree with Brian Carpenter - perhaps MUST should be removed. I am do not feel strongly about this. There are a number of sections with significant outs - 3.2.3 - impact on hosts in particular. I am concerned about this topic - I believe that the degree of impact to end hosts is where we will decide upon a good vs bad solution. I don't think that the wording of the requirements should change here, just that this is where the contention will be. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPbbYXYqHRg3pndX9AQHSJQQAwIuO5/OnjcXV9GL8FbNl0VPqNNehlCDi AJrw/VXRz1+fb2BxUWEfAe4FARHoTFS3c+Q0sG+vXdOFZmsGup7fglRE6OiSYnOL sh7b6Vk07YKVs9ZgEjYzXt4yIXoy63ctKzJdwWPuU7JqGsYCH0yA9Y7u89pO+Krp AKT2eOgPj44= =QNqV -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Oct 23 13:21:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26116 for ; Wed, 23 Oct 2002 13:21:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184PDt-000MID-00 for multi6-data@psg.com; Wed, 23 Oct 2002 10:23:13 -0700 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #2) id 184PDq-000MEn-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 10:23:10 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9NHMWCG039708; Wed, 23 Oct 2002 19:22:33 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9NHMV0c036436; Wed, 23 Oct 2002 19:22:31 +0200 Received: from lig32-230-41-229.ca.lig-dial.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32914 from ; Wed, 23 Oct 2002 19:22:26 +0200 Message-Id: <3DB69DB4.CE268BEA@hursley.ibm.com> Date: Wed, 23 Oct 2002 15:01:40 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Sean Doran Cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03.txt References: <20021023011923.9C051AE3@ab.use.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.9 required=5.0 tests=DATE_IN_PAST_03_06,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As I suggested on the other thread, remove the MUST/SHOULD normative language - make everything lower case should/should not - and ship it as Informational. Use it as guidance for further work. Brian Sean Doran wrote: > > This draft expires in one week on 30 October 2002. > > Have you read it? Do you think it's ready? > Do you think it's not ready? Do you have an > idea you think should be incorporated into > the draft? > > Comments, please. > > Incidentally, three other important dates are coming in the near future: > the pre-IETF draft cutoffs for initial and final submissions and the > cut-off for scheduling a WG meeting (October 29), should we have wg business > to discuss in Atlanta. > > Sean. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-multi6@ops.ietf.org Wed Oct 23 13:22:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26151 for ; Wed, 23 Oct 2002 13:22:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184PER-000MJG-00 for multi6-data@psg.com; Wed, 23 Oct 2002 10:23:47 -0700 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #2) id 184PEP-000MIG-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 10:23:45 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9NHMwjU016954; Wed, 23 Oct 2002 19:22:59 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9NHMvfc058856; Wed, 23 Oct 2002 19:22:58 +0200 Received: from lig32-230-41-229.ca.lig-dial.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32926 from ; Wed, 23 Oct 2002 19:22:53 +0200 Message-Id: <3DB6A17F.9274FFA8@hursley.ibm.com> Date: Wed, 23 Oct 2002 15:17:51 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Sean Doran Cc: multi6@ops.ietf.org Subject: Agenda [Re: The state of IPv6 multihoming development References: <20021022222053.A65A1AE4@ab.use.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.3 required=5.0 tests=DATE_IN_PAST_03_06,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sean Doran wrote: > > | Some face-to-face discussion would also be good. How do we get multi6 > | stuff on the agenda for Atlanta? > > If you have something concrete for the agenda, and > can fudge some wording so that it's relevant to the > existing charter, then Thomas & I will write to the > secretariat (& ADs) and ask for a meeting slot. I'd suggest inviting 10 minute presentations on proposed solutions. Your agenda will fill up quickly. OK, it would be more like a BOF than a WG but that's where we are. Brian P.S. and forbid discussion on the requirements/recommendations draft. From owner-multi6@ops.ietf.org Wed Oct 23 13:33:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26632 for ; Wed, 23 Oct 2002 13:33:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184POu-000Mw0-00 for multi6-data@psg.com; Wed, 23 Oct 2002 10:34:36 -0700 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #2) id 184POr-000MtE-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 10:34:33 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9NHMijk012892; Wed, 23 Oct 2002 19:22:44 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9NHMh0c081186; Wed, 23 Oct 2002 19:22:43 +0200 Received: from lig32-230-41-229.ca.lig-dial.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA75732 from ; Wed, 23 Oct 2002 19:22:33 +0200 Message-Id: <3DB6A0D9.44A5209@hursley.ibm.com> Date: Wed, 23 Oct 2002 15:15:05 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: Eliot Lear , Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Recommendation v Requirements [Re: The state of IPv6 multihoming development References: <2B81403386729140A3A899A8B39B04640BD21B@server2000> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.6 required=5.0 tests=DATE_IN_PAST_03_06,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sure. And in answer to Eliot, its usefulness is to provide a frame in which to think about proposed solutions. Brian Michel Py wrote: > > Brian, > > > Brian E Carpenter wrote: > > I think we need the document, but since it does indeed contain > > conflicting requirements that will need tradeoffs, it clearly > > SHOULD NOT contain pseudo-normative language. I would suggest > > that all the upper case normative words should be replaced by > > shoulds and should nots in lower case, and then just ship the > > thing as Informational. > > Replace "requirements" with "recommendations" and I'm with you. > > Michel. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-multi6@ops.ietf.org Wed Oct 23 13:41:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26890 for ; Wed, 23 Oct 2002 13:41:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184PX4-000NR9-00 for multi6-data@psg.com; Wed, 23 Oct 2002 10:43:02 -0700 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 184PWZ-000NNl-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 10:42:31 -0700 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 7FC5B23C3D; Tue, 22 Oct 2002 13:48:51 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9NHfsiI011846; Wed, 23 Oct 2002 10:41:54 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 10:41:54 -0700 Message-ID: Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ6rLgbM9OA0f7+QiCMV4UWgaUyIAADqERA From: "Tony Li" To: "Michael Richardson" , "Multi6 Working Group" X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA26890 | We have been down this road before. I though we were in | agreement on | two things: | 1) that multihoming would increase, | 2) and that we can't do it like IPv4. Yes, we agree. Now we're onto something harder: 3) we need to fix it now Tony From owner-multi6@ops.ietf.org Wed Oct 23 13:50:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27123 for ; Wed, 23 Oct 2002 13:50:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Pfn-000NvP-00 for multi6-data@psg.com; Wed, 23 Oct 2002 10:52:03 -0700 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 184Pfg-000NsB-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 10:51:56 -0700 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9NHp5xF001027; Wed, 23 Oct 2002 10:51:05 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9NHp7fc019631; Wed, 23 Oct 2002 10:51:08 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA27974; Wed, 23 Oct 2002 10:51:07 -0700 (PDT) Date: Wed, 23 Oct 2002 12:51:07 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Sean Doran cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03.txt In-Reply-To: <20021023011923.9C051AE3@ab.use.net> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Sean Doran wrote: > Have you read it? Do you think it's ready? > Do you think it's not ready? Do you have an > idea you think should be incorporated into > the draft? Two changes I recommend: Insert between 3.1.4 and 3.1.5 (alternative is placing it into the "3.1.6 transport-layer survivability" section, although that doesn't completely address the issue: --- 3.1.x Alternate path visibility Multihoming solutions must not constrain alternate path visibility to the originating host only. Multihoming solutions should allow alternate path visibility to reside within the network infrastructure, such that the multihomed site's operator may easily configure policy to prefer a given set of paths. This may include host and network-infrastructure interaction to determine the best path. --- Discussion: See previous threads. The goal is to allow network infrastructure to have visibility into alternate paths for IP traffic, and not constrain them to the originating host. An addition to 3.2.6: --- A multihoming solution must not require cooperation between the multi-homed site and other transit providers not providing service to said multi-homed site. --- Discussion: A requirement or possibility for a multihomed site to establish a business relationship with many, or every, transit provider is unreasonable. Multihoming solutions should work and provide reachability to an end-site provided the guidelines are adhered to, without the need for a site to establish settlement with a significant number of transit providers to carry any routing information. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Wed Oct 23 13:50:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27138 for ; Wed, 23 Oct 2002 13:50:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184PfJ-000NsT-00 for multi6-data@psg.com; Wed, 23 Oct 2002 10:51:33 -0700 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #2) id 184PfG-000NsF-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 10:51:31 -0700 Received: (qmail 918 invoked by uid 0); 23 Oct 2002 17:51:29 -0000 Received: from localhost.automagic.org (HELO automagic.org) (127.0.0.1) by localhost.automagic.org with SMTP; 23 Oct 2002 17:51:29 -0000 Date: Wed, 23 Oct 2002 10:51:30 -0700 Subject: Re: draft-ietf-multi6-multihoming-requirements-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Sean Doran , multi6@ops.ietf.org To: Brian E Carpenter From: Joe Abley In-Reply-To: <3DB69DB4.CE268BEA@hursley.ibm.com> Message-Id: <0F69DFBA-E6B0-11D6-86BD-00039312C852@automagic.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Oct 23, 2002, at 06:01 US/Pacific, Brian E Carpenter wrote: > As I suggested on the other thread, remove the MUST/SHOULD normative > language - make everything lower case should/should not - and ship it > as Informational. > > Use it as guidance for further work. I like this plan. I seem to think that recommendation-flavoured must/shoulds were what was in the document to start with anyway, and that the MUST/SHOULDs were added later following comments from this list, but I could be mistaken. Joe From owner-multi6@ops.ietf.org Wed Oct 23 13:53:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27270 for ; Wed, 23 Oct 2002 13:53:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Pix-000O7h-00 for multi6-data@psg.com; Wed, 23 Oct 2002 10:55:19 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.36 #2) id 184Piv-000O5U-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 10:55:17 -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 NAA05189; Wed, 23 Oct 2002 13:54:50 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id NAA00433; Wed, 23 Oct 2002 13:54:41 -0400 (EDT) Date: Wed, 23 Oct 2002 13:54:40 -0400 (EDT) From: Greg Maxwell To: Tony Li cc: Michael Richardson , Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Tony Li wrote: > | We have been down this road before. I though we were in > | agreement on > | two things: > | 1) that multihoming would increase, > | 2) and that we can't do it like IPv4. > > > Yes, we agree. Now we're onto something harder: > > 3) we need to fix it now I've still yet to see an idea here that provided complete multihoming (i.e. ones that won't get filtered to uselessness) without either breaking aggregation and exploding the DFZ or making transport level changes.. In other news.. SCTP is included now in the Linux 2.5.xx development chain. From owner-multi6@ops.ietf.org Wed Oct 23 14:07:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27728 for ; Wed, 23 Oct 2002 14:07:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Pw6-000OvX-00 for multi6-data@psg.com; Wed, 23 Oct 2002 11:08:54 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 184Pw5-000OvL-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 11:08:53 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 184Pw4-000FnP-00; Wed, 23 Oct 2002 11:08:52 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Greg Maxwell Cc: Tony Li , Michael Richardson , Multi6 Working Group Subject: RE: The state of IPv6 multihoming development References: Message-Id: Date: Wed, 23 Oct 2002 11:08:52 -0700 X-Spam-Status: No, hits=-5.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I've still yet to see an idea here that provided complete multihoming > (i.e. ones that won't get filtered to uselessness) as i am not aware of anyone filtering v6 announcements at the moment (well, other than maybe at /48 or something), perhaps this wg should work on solutions to the routing problems presented and assume that, if reasonable aggregation is one of those goals and is met, that the isps will act rationally. randy From owner-multi6@ops.ietf.org Wed Oct 23 14:18:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28148 for ; Wed, 23 Oct 2002 14:18:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Q6j-000PWF-00 for multi6-data@psg.com; Wed, 23 Oct 2002 11:19:53 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 184Q6h-000PVO-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 11:19:51 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id OAA06153; Wed, 23 Oct 2002 14:19:49 -0400 Date: Wed, 23 Oct 2002 14:19:49 -0400 From: "J. Noel Chiappa" Message-Id: <200210231819.OAA06153@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Randy Bush > perhaps this wg should work on solutions to the routing problems > presented Let me make sure I understand you. You're saying: "let's see if we can find a working design where multi-homing is supported entirely in the routing"? I.e. distant host S emits packets with destination address D, and they can come in to D through a number of different paths? That would cover what some people call "site multi-homing"; i.e. all the hosts have a single interface, but the group of hosts has multiple paths to the network. What about "host multi-homing", where a host has several different interfaces - would you like to see the same thing there? I.e. the packets automatically go in which ever interface to D is working? Noel From owner-multi6@ops.ietf.org Wed Oct 23 14:26:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28609 for ; Wed, 23 Oct 2002 14:26:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184QEd-000PzG-00 for multi6-data@psg.com; Wed, 23 Oct 2002 11:28:03 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.36 #2) id 184QES-000Pw2-00; Wed, 23 Oct 2002 11:27:52 -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 OAA06150; Wed, 23 Oct 2002 14:27:25 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id OAA03786; Wed, 23 Oct 2002 14:27:16 -0400 (EDT) Date: Wed, 23 Oct 2002 14:27:16 -0400 (EDT) From: Greg Maxwell To: Randy Bush cc: Tony Li , Michael Richardson , Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Randy Bush wrote: > > I've still yet to see an idea here that provided complete multihoming > > (i.e. ones that won't get filtered to uselessness) > > as i am not aware of anyone filtering v6 announcements at the moment > (well, other than maybe at /48 or something), perhaps this wg should > work on solutions to the routing problems presented and assume that, > if reasonable aggregation is one of those goals and is met, that the > isps will act rationally. Lets say that everyone who mutihomes will take their provider based address and announce it to other providers.. This would work.. But it would also explode the DFZ.. Okay, so people could filter the smaller routes... effectively de-multihoming the multihomer.. so filtering is not a reasonable solution to multihoming caused DFZ inflation. So, here is the point of the problem: Do we care about inflating the DFZ? Keep in mind that DFZ inflation is more costly in v6 due to the larger amount of data involved and the expected growth of multihomed networks.. and that it's price carried by everyone, even people without business relationships with the multihomers If we don't care (which I think would be an example of extremely poor foresight..) then multihomers should just announce more-specifics of their other providers address blocks and act just like it is in the v4 world. Problem solved. If we do care about preserving aggregation (one of the stated goals of IPv6), then we can NOT permit *any* multihoming aggregation busting and multihoming must be provided either by transport layer enhancements (my favor, see archives) or via tunnel hacks. I got tired of discussing the matter because of the group's unwillingness to seriously consider transport layer modifications (wah wah outside of the scope blah.. I thought my argument for prefix flowthrough and SCTP was compelling.. No DFZ busting, the only catch was that legacy apps wouldn't be multihomed: a good reason to upgrade them).. If you simply can not do anything but break aggregation then fine, stop waffling and declare it already. The problem isn't just going to go away. The only thing worse then making a bad decision is wasting a lot of time making a bad decision. From owner-multi6@ops.ietf.org Wed Oct 23 14:27:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28673 for ; Wed, 23 Oct 2002 14:27:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184QGM-000089-00 for multi6-data@psg.com; Wed, 23 Oct 2002 11:29:50 -0700 Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by psg.com with esmtp (Exim 3.36 #2) id 184QGK-00003g-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 11:29:48 -0700 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9NITAot016395; Wed, 23 Oct 2002 11:29:10 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9NIT8me024521; Wed, 23 Oct 2002 11:29:09 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA11163; Wed, 23 Oct 2002 11:29:07 -0700 (PDT) Date: Wed, 23 Oct 2002 13:29:08 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Randy Bush cc: Greg Maxwell , Tony Li , Michael Richardson , Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Randy Bush wrote: > > I've still yet to see an idea here that provided complete multihoming > > (i.e. ones that won't get filtered to uselessness) > > as i am not aware of anyone filtering v6 announcements at the moment > (well, other than maybe at /48 or something), perhaps this wg should > work on solutions to the routing problems presented and assume that, > if reasonable aggregation is one of those goals and is met, that the > isps will act rationally. We had been announcing a /40 for a short period of time. A month or two ago, we experienced unreachability to www.kame.net and found that filters were put in place to filter anything longer than /35 in one of the Japanese ISP's, such that 2001:420::/40 was no longer accepted. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Wed Oct 23 14:35:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29066 for ; Wed, 23 Oct 2002 14:35:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184QNe-0000bG-00 for multi6-data@psg.com; Wed, 23 Oct 2002 11:37:22 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 184QN8-0000Yt-00; Wed, 23 Oct 2002 11:36:51 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9NIaZ402854; Wed, 23 Oct 2002 21:36:35 +0300 Date: Wed, 23 Oct 2002 21:36:35 +0300 (EEST) From: Pekka Savola To: "Craig A. Huegen" cc: Randy Bush , Greg Maxwell , Tony Li , Michael Richardson , Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Craig A. Huegen wrote: > On Wed, 23 Oct 2002, Randy Bush wrote: > > > > I've still yet to see an idea here that provided complete multihoming > > > (i.e. ones that won't get filtered to uselessness) > > > > as i am not aware of anyone filtering v6 announcements at the moment > > (well, other than maybe at /48 or something), perhaps this wg should > > work on solutions to the routing problems presented and assume that, > > if reasonable aggregation is one of those goals and is met, that the > > isps will act rationally. > > We had been announcing a /40 for a short period of time. A month or two > ago, we experienced unreachability to www.kame.net and found that filters > were put in place to filter anything longer than /35 in one of the > Japanese ISP's, such that 2001:420::/40 was no longer accepted. And you think advertising it was rational? Nope... I want to announce my 6to4 /48 too but my neighbors won't let me :-( -- 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 Oct 23 14:56:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29833 for ; Wed, 23 Oct 2002 14:56:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184QhZ-0001v2-00 for multi6-data@psg.com; Wed, 23 Oct 2002 11:57:57 -0700 Received: from sj-msg-core-2.cisco.com ([171.70.145.30]) by psg.com with esmtp (Exim 3.36 #2) id 184QhX-0001rj-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 11:57:55 -0700 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NIv3cl011711; Wed, 23 Oct 2002 11:57:03 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9NIv4RV008238; Wed, 23 Oct 2002 11:57:04 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA09698; Wed, 23 Oct 2002 11:57:01 -0700 (PDT) Date: Wed, 23 Oct 2002 13:56:56 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Pekka Savola cc: Randy Bush , Greg Maxwell , Tony Li , Michael Richardson , Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Pekka Savola wrote: > And you think advertising it was rational? > > Nope... > > I want to announce my 6to4 /48 too but my neighbors won't let me :-( *shrug* I was pointing out to Randy that some providers are indeed filtering. Do I think it's rational to advertise that /40? Given the circumstances, yes. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Wed Oct 23 15:04:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00326 for ; Wed, 23 Oct 2002 15:04:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184QpP-0002QK-00 for multi6-data@psg.com; Wed, 23 Oct 2002 12:06:03 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184QpJ-0002Q6-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 12:05:57 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9NJ4KT20080; Wed, 23 Oct 2002 21:04:20 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Oct 2002 21:04:19 +0200 (CEST) From: Iljitsch van Beijnum To: Greg Maxwell cc: Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: <20021023205837.O14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Greg Maxwell wrote: > I've still yet to see an idea here that provided complete multihoming > (i.e. ones that won't get filtered to uselessness) without either breaking > aggregation and exploding the DFZ or making transport level changes.. I think http://www.muada.com/drafts/draft-van-beijnum-multi6-geo-aggr-00.txt (name may change as I submit the draft) or "Geographical Aggregation to Support Multihoming in IPv6" fits the bill. Sure, there are many reasons not to like this, but so far I haven't heard any reasons why it wouldn't _work_. As it provides relief almost immediately without any pain (that comes later...), I can't see why this (or rather, an address allocation mechanism supporting it) shouldn't be implemented, unless someone can present _very_ convincing arguments why all of this is evil. Iljitsch From owner-multi6@ops.ietf.org Wed Oct 23 15:18:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01522 for ; Wed, 23 Oct 2002 15:18:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184R2s-0003Kx-00 for multi6-data@psg.com; Wed, 23 Oct 2002 12:19:58 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.36 #2) id 184R2l-0003HA-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 12:19:51 -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 PAA07521; Wed, 23 Oct 2002 15:19:29 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id PAA09145; Wed, 23 Oct 2002 15:19:20 -0400 (EDT) Date: Wed, 23 Oct 2002 15:19:20 -0400 (EDT) From: Greg Maxwell To: Iljitsch van Beijnum cc: Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: <20021023205837.O14896-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Iljitsch van Beijnum wrote: > On Wed, 23 Oct 2002, Greg Maxwell wrote: > > > I've still yet to see an idea here that provided complete multihoming > > (i.e. ones that won't get filtered to uselessness) without either breaking > > aggregation and exploding the DFZ or making transport level changes.. > > I think http://www.muada.com/drafts/draft-van-beijnum-multi6-geo-aggr-00.txt > (name may change as I submit the draft) or "Geographical Aggregation to > Support Multihoming in IPv6" fits the bill. Sure, there are many reasons > not to like this, but so far I haven't heard any reasons why it wouldn't > _work_. As it provides relief almost immediately without any pain (that > comes later...), I can't see why this (or rather, an address allocation > mechanism supporting it) shouldn't be implemented, unless someone can > present _very_ convincing arguments why all of this is evil. We're still in the game of having a cost set onto the outsiders.. sure, now we've flattened the nonlinearity of price (hardware to contain a million routes is more complex then a group of 100k routers with a similar totally routing ability). Is this really about the limits of top end scaling? I always considered it to be about making routing more O(1)ish with respect to multihomed networks you don't have a bussiness relationship then O(n*mumble).. The multinational geospacial distribution is a non-issue imho.. there is too much clustering.. In places where multihoming load will matter.. thats where the majority of the networks are.... I think it's reasonable to say that if a router can handle X routes (i.e. all of the US, all of asia, or all of europe) that asking it to handle 4X routes is not a big deal. I don't believe that it is reasonable to ask providers to zone their networks any smaller then continents. From owner-multi6@ops.ietf.org Wed Oct 23 15:27:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01917 for ; Wed, 23 Oct 2002 15:27:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184RBu-0003v5-00 for multi6-data@psg.com; Wed, 23 Oct 2002 12:29:18 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 184RBs-0003un-00; Wed, 23 Oct 2002 12:29:16 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9NJSuh04322; Wed, 23 Oct 2002 22:28:56 +0300 Date: Wed, 23 Oct 2002 22:28:55 +0300 (EEST) From: Pekka Savola To: "Craig A. Huegen" cc: Randy Bush , Greg Maxwell , Tony Li , Michael Richardson , Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Craig A. Huegen wrote: > On Wed, 23 Oct 2002, Pekka Savola wrote: > > > And you think advertising it was rational? > > > > Nope... > > > > I want to announce my 6to4 /48 too but my neighbors won't let me :-( > > *shrug* I was pointing out to Randy that some providers are indeed > filtering. > > Do I think it's rational to advertise that /40? Given the circumstances, > yes. Maybe, but is it rational to expect it to not to be filtered? No. -- 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 Oct 23 15:27:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01952 for ; Wed, 23 Oct 2002 15:27:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184RCc-0003xE-00 for multi6-data@psg.com; Wed, 23 Oct 2002 12:30:02 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 184RCY-0003wb-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 12:29:58 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id PAA06829; Wed, 23 Oct 2002 15:29:54 -0400 Date: Wed, 23 Oct 2002 15:29:54 -0400 From: "J. Noel Chiappa" Message-Id: <200210231929.PAA06829@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Craig A. Huegen" > Noel asked if I could suggest any other mechanisms. So far, all of the > multi-homing solutions I can think of that are implementable with > current code I'd rather not get into the swamp of "current code only". Either way, I think it's very useful to know what the technical alternatives are, and then you can assess the entire cost/benefit balance of each (and yes, changing code is a cost). So, I'll ask again: there are a number of basically feasible paths you can take to support *widescale* multi-homing. .. First, you can use multiple connectivity-based addresses. .. Second, you can re-use a mobility mechanism. Third, you could use a radical addressing architecture that assigns addresses automatically, based on actual connectivity topology. I've since remembered another, one that Dave Clark came up with in the early 80's (IIRC), which was "route fragments" - i.e. when you look someone up in the DNS, you don't get back just an address, but also some partial source routes which lead from something major (e.g. a large ISP which everyone will have in their routing table) to the destination. There's an equivalent for Map-Distribution based routing architectures. Can you suggest any others (not including "let the routing do it")? Noel From owner-multi6@ops.ietf.org Wed Oct 23 15:29:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02103 for ; Wed, 23 Oct 2002 15:29:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184REF-00044y-00 for multi6-data@psg.com; Wed, 23 Oct 2002 12:31:43 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184RED-00044R-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 12:31:41 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9NJTuc20158; Wed, 23 Oct 2002 21:29:56 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Oct 2002 21:29:56 +0200 (CEST) From: Iljitsch van Beijnum To: Greg Maxwell cc: Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: <20021023210648.G14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Greg Maxwell wrote: > Lets say that everyone who mutihomes will take their provider based > address and announce it to other providers.. This would work.. > But it would also explode the DFZ.. > Okay, so people could filter the smaller routes... effectively > de-multihoming the multihomer.. so filtering is not a reasonable solution > to multihoming caused DFZ inflation. If nothing changes, this is exactly what will happen. This is also quite common in v4 today: it is very close to impossible to get a small PI block, so many multihomers take addresses from one ISP and announce them over both. This provides a reasonable degree of multihoming if the ISP they take addresses from accepts the announcement from the alternate ISP. Then, if the multihomer's connection to the primary ISP goes down and their more specific is filtered, the traffic ends up at the primary ISP thanks to the aggregate, and the primary ISP sends it to the secondary ISP who in turn delivers it to the multihomer. This doesn't protect the multihomer from all failure modes for the primary ISP, but it sure beats single homing. > If we do care about preserving aggregation (one of the stated goals of > IPv6), then we can NOT permit *any* multihoming aggregation busting and > multihoming must be provided either by transport layer enhancements (my > favor, see archives) or via tunnel hacks. > I got tired of discussing the matter because of the group's unwillingness > to seriously consider transport layer modifications (wah wah outside of > the scope blah.. I thought my argument for prefix flowthrough and SCTP > was compelling.. No DFZ busting, the only catch was that legacy apps > wouldn't be multihomed: a good reason to upgrade them).. If you simply can > not do anything but break aggregation then fine, stop waffling and > declare it already. The problem isn't just going to go away. Personally, I feel this is a network issue so it should be dealt with at the network layer. However, I'll take a good solution at any other layer over a bad one at the network layer any day of the week. A more compelling reason to do it at the network layer is that we have many boxes that can do stuff at the network layer, while all the transport layer decisions are (should be) made by the end hosts. See Craig's problem with host solutions. Also, keeping a single address for the transport layer (essentially promoting this one to an identifier) and a possibly large set of alternate addresses that are hidden from it (these would be locators) keeps the transport protocols simple (= the same as they are now). But in order to make it all work efficiently, there must be tight integration between TCP and the multi-address engine, because TCP knows when sessions start and end, and when there are (potential) reachability problems. Do you have a pointer to your transport layer ideas, BTW? > The only thing worse then making a bad decision is wasting a lot of time > making a bad decision. The ship has sailed on making a good decision fast, so let's focus on making a good decision period. Iljitsch From owner-multi6@ops.ietf.org Wed Oct 23 15:45:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02889 for ; Wed, 23 Oct 2002 15:45:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184RTC-0005Aq-00 for multi6-data@psg.com; Wed, 23 Oct 2002 12:47:10 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.36 #2) id 184RT9-00058k-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 12:47:07 -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 PAA08269; Wed, 23 Oct 2002 15:46:45 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id PAA12037; Wed, 23 Oct 2002 15:46:36 -0400 (EDT) Date: Wed, 23 Oct 2002 15:46:36 -0400 (EDT) From: Greg Maxwell To: Iljitsch van Beijnum cc: Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: <20021023210648.G14896-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Iljitsch van Beijnum wrote: > On Wed, 23 Oct 2002, Greg Maxwell wrote: > > > Lets say that everyone who mutihomes will take their provider based > > address and announce it to other providers.. This would work.. > > But it would also explode the DFZ.. > > > Okay, so people could filter the smaller routes... effectively > > de-multihoming the multihomer.. so filtering is not a reasonable solution > > to multihoming caused DFZ inflation. > > If nothing changes, this is exactly what will happen. This is also quite > common in v4 today: it is very close to impossible to get a small PI > block, so many multihomers take addresses from one ISP and announce them > over both. This provides a reasonable degree of multihoming if the ISP > they take addresses from accepts the announcement from the alternate > ISP. Then, if the multihomer's connection to the primary ISP goes down > and their more specific is filtered, the traffic ends up at the primary > ISP thanks to the aggregate, and the primary ISP sends it to the > secondary ISP who in turn delivers it to the multihomer. This doesn't > protect the multihomer from all failure modes for the primary ISP, but > it sure beats single homing. Well perhaps this specific filtered, cross announce approach could be combined with my transport layer ideas as a transitional method. > Personally, I feel this is a network issue so it should be dealt with at > the network layer. However, I'll take a good solution at any other layer > over a bad one at the network layer any day of the week. I'm not so sure it's a network layer issue.. The network moves packets to a network location.. when their is a failure and multihoming comes into play, you are effectivly moving onto a NEW network location.. > A more compelling reason to do it at the network layer is that we have > many boxes that can do stuff at the network layer, while all the > transport layer decisions are (should be) made by the end hosts. See > Craig's problem with host solutions. [snip] > Do you have a pointer to your transport layer ideas, BTW? I made some long posts to this list a while back, search based on my email address. Ascii graphs and such.. I started working on a draft, but it seemed like the consensus was that "transport layer solutions are outside of the scope of this working group".. The irony is that everyone with anything to do with transport protocols said IPv6 and multihoming arn't our bussiness. > > The only thing worse then making a bad decision is wasting a lot of time > > making a bad decision. > > The ship has sailed on making a good decision fast, so let's focus on > making a good decision period. My concern is that we should make a decision that doesn't tie us in.. If we decided on an DFZ exploding solution, there will be no going back.. I really don't believe that weak DFZ exploding solutions like I said might work above (like, announce specifics and filter, and if you want better then upgrade to transport layer multihoming) are sufficent because of the current practice of flooding the DFZ with IPv4 (i.e. the filtering won't happen/people will cry and get it removed when it first annoys them.. which will work early in IPv6's production deployment becuase it won't yet be many networks).. Am I off? Can we really get away with saying 'well, the technoligy allows you to flood the DFZ like in v4, but policy says you should play nice and not do so' and actually have that happen? or must we make a strong stand: aggregate and solve your multihoming via this non-DFZ exploding method or cope with being singly homed! From owner-multi6@ops.ietf.org Wed Oct 23 15:47:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03049 for ; Wed, 23 Oct 2002 15:47:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184RW1-0005QX-00 for multi6-data@psg.com; Wed, 23 Oct 2002 12:50:05 -0700 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 184RVz-0005ME-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 12:50:03 -0700 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 0D35A3442D; Wed, 23 Oct 2002 12:58:16 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9NJnRiI020567; Wed, 23 Oct 2002 12:49:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 12:49:26 -0700 Message-ID: Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ6vWXVGwolgkPjSAet3Oj8IS69DQADuFhw From: "Tony Li" To: "Greg Maxwell" Cc: "Michael Richardson" , "Multi6 Working Group" X-Spam-Status: No, hits=0.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA03049 | I've still yet to see an idea here that provided complete | multihoming | (i.e. ones that won't get filtered to uselessness) without | either breaking | aggregation and exploding the DFZ or making transport level | changes.. And you're not likely to see one soon either. Look at the problem that we're trying to solve: - Not exploding the DFZ requires hierarchical addressing. - Being multihomed implies that there is a cycle in the graph, which implies that a node appears multiple places in the hierarchy. - No changes in the transport implies that once you start using an address, you MUST continue using it, thereby binding yourself to one path through the hierarchy. Tunnelling tries to address this by maintaining the hierarchy and virtualizing the topology. Geographic addressing declares the top of the graph to be hierarchical, but makes the lower layers non-hierarchical and thereby pushes the explosion down, simply moving the problem. Something has to give, and IMHO, it had better be the transport. Tony From owner-multi6@ops.ietf.org Wed Oct 23 15:51:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03213 for ; Wed, 23 Oct 2002 15:51:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184RZR-0005XA-00 for multi6-data@psg.com; Wed, 23 Oct 2002 12:53:37 -0700 Received: from sj-msg-core-2.cisco.com ([171.70.145.30]) by psg.com with esmtp (Exim 3.36 #2) id 184RZP-0005WB-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 12:53:36 -0700 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NJqjcl011415; Wed, 23 Oct 2002 12:52:45 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9NJqkt8026340; Wed, 23 Oct 2002 12:52:46 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA29153; Wed, 23 Oct 2002 12:52:45 -0700 (PDT) Date: Wed, 23 Oct 2002 14:52:46 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Pekka Savola cc: Randy Bush , Greg Maxwell , Tony Li , Michael Richardson , Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Pekka Savola wrote: > Maybe, but is it rational to expect it to not to be filtered? No. Given today's possible multihoming solution set for large enterprises with tens of thousands of segments, and given the requirement for multi-homing as per the draft + my comments, and given the rather small routing table currently used for research, yes; it is rational for me to expect it not to be filtered. This is partially in line with the discussion a bit earlier about providers not filtering all that much today because it isn't too great of a concern. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Wed Oct 23 16:07:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03618 for ; Wed, 23 Oct 2002 16:07:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184RoW-0006jo-00 for multi6-data@psg.com; Wed, 23 Oct 2002 13:09:12 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 184RoU-0006jb-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 13:09:10 -0700 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Oct 2002 13:08:59 -0700 Reply-To: From: "Tony Hain" To: "'Iljitsch van Beijnum'" Cc: Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 13:08:35 -0700 Message-ID: <027101c27ad0$059f7e00$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021023151736.S14896-100000@sequoia.muada.com> X-Spam-Status: No, hits=-4.3 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA03618 Iljitsch van Beijnum wrote: > ... > Actually holes in PA space is perfectly fine for the network, as you > can filter the more specifics and still have connectivity. This statement is self contradictory. > However, it is not so great for the > organization using the addresses since this doesn't address > all failure modes. The point I was making about punching holes in PA is that the more influential organizations will get the full prefix routed globally. > > We did discuss this proposal at length on a different mailinglist. My > view was that it needs to address the problem of address density at > the poles Over-engineering the approach doesn't accomplish the goal. > and the fact that the > aggregation boundaries don't fit either topology or > geography. By geography, I assume you mean geo-political agreements. It clearly matches the global coordinate system those agreements are based on. > This could be done by having several instances of > this address space and have two places that would otherwise > be aggregated together sit in a different instance. By > rotating the axes and limiting everything to (say) from -60 > to +60 degrees you eliminate the pole problem. I played with rotating the axis, but the only thing that made Europe contiguous was to put the origin on a 22.5 degree mark. This would unnecessarily complicate the rest of the world, for the simple gain of reducing the London prefix set from 2 to 1. If it were 20 to 1 I would reconsider, but I don't see how a single prefix makes it worthwhile. Also, setting the boundaries at +/-60 does nothing useful in terms of available address resolution. You would have to restrict it to +/-45 to get a bit back, and that is clearly not a wide enough band. > > Still, there is one unanswered question: what problem is solved by > having such a close relationship between geography and address space? I was not trying to force any particular alignment. The goals were: Uses current BGP protocol. Aggregate the basement-multi-homer, while recognizing the CNN's of the world will always get a full prefix announced. Decouple the scale of aggregation, so it becomes a regional decision. Make it simple to derive by basing it on a globally consistent reference. The use of WGS84 was based on the fact that handheld receivers are cheap and available, so the L1 installer can easily identify the reference point. Bit-interleaving the result decoupled the aggregation scale decision when using current BGP prefix exchanges. Is it the most efficient use of address space? No, and the document recognizes there is a clear trade-off being made between simplicity and efficiency. Are there other ways to achieve the listed goals? Probably, and when I see something that looks more operationally viable I will back off. Tony From owner-multi6@ops.ietf.org Wed Oct 23 16:07:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03635 for ; Wed, 23 Oct 2002 16:07:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184RoQ-0006jX-00 for multi6-data@psg.com; Wed, 23 Oct 2002 13:09:06 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 184RoG-0006j4-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 13:08:56 -0700 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Oct 2002 13:08:51 -0700 Reply-To: From: "Tony Hain" To: "'J. Noel Chiappa'" , Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 13:08:35 -0700 Message-ID: <026901c27acf$fa35e450$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200210221657.MAA29488@ginger.lcs.mit.edu> X-Spam-Status: No, hits=-0.8 required=5.0 tests=INVALID_MSGID,IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA03635 J. Noel Chiappa wrote: > ... > It's all very simple, really. Who's going to pay for the > benefits of multi-homing? That's the real question. That is a direct function of the architecture and business models. If we take the current state, the service provider ends up eating the cost in terms of routing table maintenance because it is the only defense against receiving undesired traffic. If we look at a different model, the end sites could end up paying for the capability by subscribing to an aggregation exchange point. This model would introduce a new player into the mix between the ISP and the customer, so it is naturally undesirable to the business side of the house. The real question is, is that the necessary evil that makes it possible to scale? Tony From owner-multi6@ops.ietf.org Wed Oct 23 16:08:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03651 for ; Wed, 23 Oct 2002 16:08:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184RoH-0006jB-00 for multi6-data@psg.com; Wed, 23 Oct 2002 13:08:57 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 184RoE-0006il-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 13:08:54 -0700 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Oct 2002 13:08:57 -0700 Reply-To: From: "Tony Hain" To: "'J. Noel Chiappa'" , Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 13:08:35 -0700 Message-ID: <026e01c27acf$fbe1bf90$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200210221647.MAA29456@ginger.lcs.mit.edu> X-Spam-Status: No, hits=-5.0 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA03651 J. Noel Chiappa wrote: > ... > Let's try this one more time. > > An "address", as used in the IPv4/v6 architectures, is a name > that (among other functions) specifies *where* that entity is > in the network: i.e. where it is attached to the network's > connectivity topology. In other words: > > "geographical address" -> > "geographical topological-location-name" -> > "connectivity-independent topological-location-name" -> > "topological-location-independent topological-location-name". > > The latter is, rather obviously, a paradox. Q.E.D. > The missing link of the chain is that the provider-independent name ends up being connectivity-dependent by aligning the scale of abstraction such that the connection falls within its boundary. > > While I'm at it, I rather admire the skilful political spin > displayed in naming them "provider-dependent" and > "provider-independent" addresses, thereby completely > obscuring the underlying technical issues, and making it seem > like it's purely a policy issue, one in which the large > providers are out to screw the customers. Maybe y'all should > introduce terminology of "RIAA-addresses" and > "Microsoft-addresses", as alternatives for > "provider-dependent addresses", for extra PR bang. > > If you want technically accurate terminology, as opposed to > politically accurate, call them "connectivity-dependent" and > "connectivity-independent". There was no attempt to make this a political argument, in fact it is more accurate than connectivity-*. The current policy says customers get their prefix from their provider so that it aggregates, therefore it is provider-dependent. End sites are looking for a mechanism that allows them to decouple their prefix from any specific provider, therefore it is provider-independent. You are correct that when the bits hit the wire, connectivity is the thing that matters, but that is what the prefix exchanges in BGP tape back together. If a connection falls outside the scope of an available aggregate, it will flatten routing up to the next available level of aggregation. There is no magic here, as I am sure you are well aware. Tony > > Noel > From owner-multi6@ops.ietf.org Wed Oct 23 16:09:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03665 for ; Wed, 23 Oct 2002 16:09:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184RqZ-0006tQ-00 for multi6-data@psg.com; Wed, 23 Oct 2002 13:11:19 -0700 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 184RqX-0006qa-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 13:11:17 -0700 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9NKAZxF016019; Wed, 23 Oct 2002 13:10:35 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9NKAbVj012042; Wed, 23 Oct 2002 13:10:37 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA17026; Wed, 23 Oct 2002 13:10:35 -0700 (PDT) Date: Wed, 23 Oct 2002 15:10:36 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Michel Py cc: Eliot Lear , Iljitsch van Beijnum , "J. Noel Chiappa" , Subject: RE: The state of IPv6 multihoming development In-Reply-To: <2B81403386729140A3A899A8B39B046405E3A0@server2000> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Michel Py wrote: > I don't think this is a fair question to Craig, because he is between > the rock and the hard place. Cisco MUST have an IPv6 internal network > just to save the face. Actually, I'd disagree with that -- I don't need an internal IPv6 network to save face. I have business requirements for a reliable, available, scalable IPv6-Internet-connected intranet for a global, multi-national corporation. My requirements may come a bit sooner than most other enterprises due to the nature of the business, but that's relatively minor. However, at this time I cannot justify to our operations teams the cost or load of implementing a multi-PA IPv6 network across tens of thousands of subnets (currently the only accepted multi-homing technique). It's not realistically feasible. Many other enterprise networks are in the same position or are considering their position at this time. Until a solution set is not only developed, but IMPLEMENTED, adoption of IPv6 is severely hindered. To me, that's the real goal. Randy may claim that we're not a marketing organization, but if we're not considering the requirements or opportunities behind this protocol and network, then we've failed already. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Wed Oct 23 16:42:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04750 for ; Wed, 23 Oct 2002 16:42:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184SMJ-0009Ib-00 for multi6-data@psg.com; Wed, 23 Oct 2002 13:44:07 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184SMD-0009I3-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 13:44:01 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9NKgNh20343; Wed, 23 Oct 2002 22:42:23 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Oct 2002 22:42:23 +0200 (CEST) From: Iljitsch van Beijnum To: Greg Maxwell cc: Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: <20021023223146.P14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Greg Maxwell wrote: > We're still in the game of having a cost set onto the outsiders.. sure, > now we've flattened the nonlinearity of price (hardware to contain a > million routes is more complex then a group of 100k routers with a similar > totally routing ability). > Is this really about the limits of top end scaling? > I always considered it to be about making routing more O(1)ish with > respect to multihomed networks you don't have a bussiness relationship > then O(n*mumble).. O(1)? :-) Well, maybe there is such a beast. When I studied software engineering I was told there were no sorting algorithms that could do better than O(n*log(n)). However, some digging produced radix sort, which was used in the good old days of the Hollerith machines and scales O(n). So just because people think it can't be done doesn't mean it can't be done. > The multinational geospacial distribution is a non-issue imho.. there is > too much clustering.. In places where multihoming load will matter.. Why is that a bad thing? > thats > where the majority of the networks are.... I think it's reasonable to say > that if a router can handle X routes (i.e. all of the US, all of asia, or > all of europe) that asking it to handle 4X routes is not a big deal. Agree. That's why flat routing within a continent isn't worth the hassle, while flat routing within a country/state/province or a metro area (+ aggregating away everything on the outside) would be. > I don't believe that it is reasonable to ask providers to zone their > networks any smaller then continents. Is it reasonable to ask people to not multihome? Is it reasonable to ask providers to buy bigger routers because the routing table explodes? If we give people the tools, they can decide on how to use them. That's why we need geographically aggregatable PI address space. On the other hand, we could just throw the towel in the ring, accept a large DFZ and start optimizing for that. 1 KB per prefix is way to much. If we can get this down to 10 bytes on average (in theory it could be one bit per path: reachable or unreachable) and double our memory and slightly more than double our CPU power every two years, we're at 2^4 * 1024 / 10 * 114k = ~200M routes in 2010's equivalent of a 7200. Not too shabby. From owner-multi6@ops.ietf.org Wed Oct 23 16:50:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04882 for ; Wed, 23 Oct 2002 16:50:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184STf-0009qC-00 for multi6-data@psg.com; Wed, 23 Oct 2002 13:51:43 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 184STd-0009pt-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 13:51:41 -0700 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Oct 2002 13:51:45 -0700 Reply-To: From: "Tony Hain" To: "'Tony Li'" , "'Greg Maxwell'" Cc: "'Michael Richardson'" , "'Multi6 Working Group'" Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 13:51:28 -0700 Message-ID: <028401c27ad5$f5f08ac0$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Spam-Status: No, hits=-0.8 required=5.0 tests=INVALID_MSGID,IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Li wrote: > ... > Geographic addressing declares the top of the graph to be > hierarchical, but makes the lower layers non-hierarchical > and thereby pushes the explosion down, simply moving > the problem. > The important missing point is that it not only moves the problem, it segments it at the same time. This reduces the scaling issues at any given point, but you are correct it does not eliminate them. Tony From owner-multi6@ops.ietf.org Wed Oct 23 16:53:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04967 for ; Wed, 23 Oct 2002 16:53:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184SXm-000A93-00 for multi6-data@psg.com; Wed, 23 Oct 2002 13:55:58 -0700 Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by psg.com with esmtp (Exim 3.36 #2) id 184SXl-000A7l-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 13:55:57 -0700 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9NKtHot029614; Wed, 23 Oct 2002 13:55:17 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9NKtCvx016665; Wed, 23 Oct 2002 13:55:12 -0700 (PDT) Received: from cisco.com (sjc-vpn1-533.cisco.com [10.21.98.21]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA29422; Wed, 23 Oct 2002 13:55:13 -0700 (PDT) Message-ID: <3DB70CB1.9010208@cisco.com> Date: Wed, 23 Oct 2002 13:55:13 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Michel Py , Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Recommendation v Requirements [Re: The state of IPv6 multihoming development References: <2B81403386729140A3A899A8B39B04640BD21B@server2000> <3DB6A0D9.44A5209@hursley.ibm.com> In-Reply-To: <2B81403386729140A3A899A8B39B04640BD21B@server2000> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Sure. And in answer to Eliot, its usefulness is to provide > a frame in which to think about proposed solutions. Given the document will have no force, I suppose I don't care all too much. My point, however, is that the frame appears currently more like an overly constraining box. Eliot From owner-multi6@ops.ietf.org Wed Oct 23 16:57:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05086 for ; Wed, 23 Oct 2002 16:57:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184SaR-000AMk-00 for multi6-data@psg.com; Wed, 23 Oct 2002 13:58:43 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.36 #2) id 184SaP-000ALn-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 13:58:41 -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 QAA10226; Wed, 23 Oct 2002 16:58:14 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id QAA18662; Wed, 23 Oct 2002 16:58:05 -0400 (EDT) Date: Wed, 23 Oct 2002 16:58:05 -0400 (EDT) From: Greg Maxwell To: Tony Li cc: Michael Richardson , Multi6 Working Group Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_03_05, USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Tony Li wrote: > And you're not likely to see one soon either. Look at the > problem that we're trying to solve: > > - Not exploding the DFZ requires hierarchical addressing. > - Being multihomed implies that there is a cycle in the > graph, which implies that a node appears multiple > places in the hierarchy. > - No changes in the transport implies that once you start > using an address, you MUST continue using it, thereby > binding yourself to one path through the hierarchy. > > Tunnelling tries to address this by maintaining the > hierarchy and virtualizing the topology. Geographic > addressing declares the top of the graph to be > hierarchical, but makes the lower layers non-hierarchical > and thereby pushes the explosion down, simply moving > the problem. > > Something has to give, and IMHO, it had better be the > transport. I believe that any tunnling purposal would be an incomplete solution and something of a hack. I really don't think that anyone is arguing that such a solution is realistic due to it's inelegance. (anyone feel free to correct me) I condend that the requirements of no-transport-layer-mods and aggregation are mutually exclusive and we need to drop one of them.. as soon as we do: The answer becomes trivial. From owner-multi6@ops.ietf.org Wed Oct 23 16:57:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05120 for ; Wed, 23 Oct 2002 16:57:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184SbS-000ASQ-00 for multi6-data@psg.com; Wed, 23 Oct 2002 13:59:46 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 184SbQ-000ARs-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 13:59:44 -0700 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Oct 2002 13:59:48 -0700 Reply-To: From: "Tony Hain" To: "'Iljitsch van Beijnum'" , "'Greg Maxwell'" Cc: "'Multi6 Working Group'" Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 13:59:31 -0700 Message-ID: <028501c27ad7$15e60a70$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021023223146.P14896-100000@sequoia.muada.com> X-Spam-Status: No, hits=-4.3 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA05120 Iljitsch van Beijnum wrote: > ... If we give people the tools, they can > decide on how to use them. That's why we need geographically > aggregatable PI address space. > More correctly, that is why we need an aggregatable PI address space. The fact that people generally put up abstraction barriers that align with geography is orthogonal and an artifact of human nature. Since they will tend to want to do that anyway, we can leverage that with geo-PI allocations, as long as they fit the fundemental requirement of being aggregatable. Tony From owner-multi6@ops.ietf.org Wed Oct 23 17:27:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05975 for ; Wed, 23 Oct 2002 17:27:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184T3D-000Cl5-00 for multi6-data@psg.com; Wed, 23 Oct 2002 14:28:27 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184T3A-000Ckt-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 14:28:25 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9NLQmL20438; Wed, 23 Oct 2002 23:26:48 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Oct 2002 23:26:48 +0200 (CEST) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: <200210231929.PAA06829@ginger.lcs.mit.edu> Message-ID: <20021023231051.G14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, J. Noel Chiappa wrote: > So, I'll ask again: > there are a number of basically feasible paths you can take to support > *widescale* multi-homing. .. > First, you can use multiple connectivity-based addresses. .. Interesting choice of words... Currently, you can _have_ several addresses, but it is extremely hard to actually _use_ them as the host must essentially make routing decisions and IP hosts are not designed to do this. Obviously, this can be fixed, and it must be, in order for any "a host has more than one address" solution to work. Making a host choose good source and destination addresses at the start of a session should be relatively easy (although not trivial), the trouble begins when these have to be changed in mid-session. > Second, you can re-use a mobility mechanism. This is nothing more than one variation on the above. Also note that current mobility will not support multihoming in any way, it would just be a starting point and we can borrow the header. There are also other tunnelling or aliasing proposals that accomplish the same thing in ways that may be more suitable for different types of networks. (i.e. the host wouldn't do the tunnelling/aliasing itself but a box sitting between the host and the routers takes care of this.) > Third, you could use a radical addressing > architecture that assigns addresses automatically, based on actual > connectivity topology. This is also a variation on the multi-address family of solutions. And don't forget four, address agile transport protocols. Some other ideas: 5. geographical aggregation 6. encoding two prefixes in one address and steal a bit somewhere in the header to indicate which should be used for forwarding 7. source routing 8. identifier/locator seperation (like GSE) From owner-multi6@ops.ietf.org Wed Oct 23 17:40:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06218 for ; Wed, 23 Oct 2002 17:40:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184TFH-000Dru-00 for multi6-data@psg.com; Wed, 23 Oct 2002 14:40:55 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 184TFF-000DqI-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 14:40:53 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9NLeiKV028216; Wed, 23 Oct 2002 23:40:44 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 23 Oct 2002 23:40:44 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0BCE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Iljitsch van Beijnum'" , "J. Noel Chiappa" Cc: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 23:40:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-1.9 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > Second, you can re-use a mobility mechanism. > > This is nothing more than one variation on the above. Also note that > current mobility will not support multihoming in any way, > it would just > be a starting point and we can borrow the header. => Current MIPv6 mechanisms _will_ support a multihomed/ multiaddressed hosts. However, they will not give you a seamless switch from one path to another when one of the paths fail. The host will somehow need to be explicitly notified that it should choose a new CoA. So this will interrupt (but need not break) ongoing connections. Note that the _only_ reason for this is security. The MIPv6 mechanisms can easily be reused or extended to allow for a near-seamless (very small packet loss due to link failures) interface/address switching. How much interruption is acceptable? The interruption I'm talking about is the time it takes to send an ICMP error message (from the edge of the enterprise network) to a host. Not much. Hesham There are also > other tunnelling or aliasing proposals that accomplish the > same thing in > ways that may be more suitable for different types of > networks. (i.e. > the host wouldn't do the tunnelling/aliasing itself but a > box sitting > between the host and the routers takes care of this.) > > > Third, you could use a radical addressing > > architecture that assigns addresses automatically, > based on actual > > connectivity topology. > > This is also a variation on the multi-address family of solutions. > > And don't forget four, address agile transport protocols. > > Some other ideas: > > 5. geographical aggregation > 6. encoding two prefixes in one address and steal a bit > somewhere in the > header to indicate which should be used for forwarding > 7. source routing > 8. identifier/locator seperation (like GSE) > > From owner-multi6@ops.ietf.org Wed Oct 23 17:40:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06236 for ; Wed, 23 Oct 2002 17:40:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184THG-000Dxy-00 for multi6-data@psg.com; Wed, 23 Oct 2002 14:42:58 -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.36 #2) id 184THE-000Dxd-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 14:42:56 -0700 content-class: urn:content-classes:message Subject: RE: Recommendation v Requirements [Re: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 14:42:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3A4@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Recommendation v Requirements [Re: The state of IPv6 multihoming development Thread-Index: AcJ6uumdWmvQT8J2QvOLxF/OXeaJ5QAH39OA From: "Michel Py" To: "Brian E Carpenter" Cc: "Eliot Lear" , "Iljitsch van Beijnum" , X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA06236 Brian / Eliot, > Eliot Lear wrote: > I submit that there are several reasons that this > group has been (too) quiet. By comparing to another group (ipv6mh) that functions like an IETF WG, with for the most part the same people as this one, deals with the same topic, and that has not been quiet at all over the past 8 months, I can identify two things that make the difference between success and stagnation: charter and leadership. >> Michel Py wrote: >> Replace "requirements" with "recommendations" and I'm >> with you. > Brian E Carpenter wrote: > Sure. And in answer to Eliot, its usefulness is to > provide a frame in which to think about proposed > solutions. This would require a re-charter. As you mentioned in another post, we might as well go over the BOF process again. Michel. From owner-multi6@ops.ietf.org Wed Oct 23 18:44:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07330 for ; Wed, 23 Oct 2002 18:44:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184UFi-000JGC-00 for multi6-data@psg.com; Wed, 23 Oct 2002 15:45:26 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.36 #2) id 184UFg-000JE6-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 15:45:24 -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 SAA11567; Wed, 23 Oct 2002 18:45:01 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id SAA24382; Wed, 23 Oct 2002 18:44:52 -0400 (EDT) Date: Wed, 23 Oct 2002 18:44:52 -0400 (EDT) From: Greg Maxwell To: Tony Hain cc: "'Iljitsch van Beijnum'" , "'Multi6 Working Group'" Subject: RE: The state of IPv6 multihoming development In-Reply-To: <028501c27ad7$15e60a70$4b194104@eagleswings> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Tony Hain wrote: > Iljitsch van Beijnum wrote: > > ... If we give people the tools, they can > > decide on how to use them. That's why we need geographically > > aggregatable PI address space. > > > > More correctly, that is why we need an aggregatable PI address space. > The fact that people generally put up abstraction barriers that align > with geography is orthogonal and an artifact of human nature. Since they > will tend to want to do that anyway, we can leverage that with geo-PI > allocations, as long as they fit the fundemental requirement of being > aggregatable. Contentential boundries are the only ones that make sence.. Any tighter and there is too much movement and interconnection. Contentential bounderies also make sence because they could be aligned with the addressing authorties. But.. They don't buy us much.. At best they would reduce the routing table by a factor of 4 or so, probably less.. Heres the thing.. If a simple linear reduction like that will suffice, then lets just flood the DFZ and let hardware improvments take care of it. If we do not believe it will suffice, then we must have a solution that does not increase the routing tables for networks who do not have a direct relationship with the multihomed network. Lets work on answering these questions: Is it approiate for network operators to have to carry the burden created by other peoples multihoming? and Can we expect routers handle the future growth of the IPv6 internet without aggregation? I thought that was already answered by the heavily aggregation centric approach of IPv6. Perhaps not.. If we decide yes, they can, then simple.. lets just declare that the IPv4 way is the way to go.. If not, then we should not waste time talking about aggregation break schemes. My thought on scaling: I don't think that it's unreasonable to say that simple enhanced versions of todays routing hardware/software could handle a million routes.. But what happens when we want links that move many 10s or hundreds of gigabits a second... and we're forced into using optical packet-level switching.. In the stuff I offered up using pure transport-level multihoming, the number of routes a network had would be a pure linear relationship to the sum of (customers+peers+transit providers). A unpeered lower tier networks routing table would be close to 1:1 with the number of customers they have. I can easily see this making or breaking the possiblity of 'optical routing' until there are major advances in photonic computing devices. From owner-multi6@ops.ietf.org Wed Oct 23 19:16:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07704 for ; Wed, 23 Oct 2002 19:16:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Um6-000M3Q-00 for multi6-data@psg.com; Wed, 23 Oct 2002 16:18:54 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 184Um3-000M2Q-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 16:18:51 -0700 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Oct 2002 16:18:54 -0700 Reply-To: From: "Tony Hain" To: "'Greg Maxwell'" Cc: "'Iljitsch van Beijnum'" , "'Multi6 Working Group'" Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 16:18:37 -0700 Message-ID: <02b801c27aea$853b09d0$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Spam-Status: No, hits=-4.3 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA07704 Greg Maxwell wrote: > ... > Contentential boundries are the only ones that make sence.. > Any tighter and there is too much movement and interconnection. > > Contentential bounderies also make sence because they could > be aligned with the addressing authorties. > > But.. They don't buy us much.. At best they would reduce the > routing table by a factor of 4 or so, probably less.. > > Heres the thing.. If a simple linear reduction like that will > suffice, then lets just flood the DFZ and let hardware > improvments take care of it. If we do not believe it will > suffice, then we must have a solution that does not increase > the routing tables for networks who do not have a direct > relationship with the multihomed network. > > Lets work on answering these questions: Is it approiate for > network operators to have to carry the burden created by > other peoples multihoming? and Can we expect routers handle > the future growth of the IPv6 internet without aggregation? > > I thought that was already answered by the heavily > aggregation centric approach of IPv6. Perhaps not.. If we > decide yes, they can, then simple.. lets just declare that > the IPv4 way is the way to go.. If not, then we should not > waste time talking about aggregation break schemes. The current provider-aggregate approach is very focused on the needs of the service provider at the expense of the needs of the enterprise. While this does create a very scalable system, it also creates one that doesn't solve the real problems (more correctly it only solves a subset of them). I will agree that to a large degree the only thing that makes sense today is contential aggregation, but I don't think that gets us very far. It is a great first step, so we should take it, but we need a plan that goes further. Those are the kinds of issues I was talking about in my USE draft. > > My thought on scaling: I don't think that it's unreasonable > to say that simple enhanced versions of todays routing > hardware/software could handle a million routes.. But what > happens when we want links that move many 10s or hundreds of > gigabits a second... and we're forced into using optical > packet-level switching.. > > In the stuff I offered up using pure transport-level > multihoming, the number of routes a network had would be a > pure linear relationship to the sum of > (customers+peers+transit providers). A unpeered lower tier > networks routing table would be close to 1:1 with the number > of customers they have. I can easily see this making or > breaking the possiblity of 'optical routing' until there are > major advances in photonic computing devices. Changing the model to make the transport deal with the multi-homing is a very long term problem. It is not that it is a particularly difficult task, but that human nature plays here so it just takes a substantial amount of time. When SCTP is well published, taught in every University course as the proper way to create connections, and those who have been taught to do so are finally in charge of software development projects, then we might start to see a shift. Basically you have to promote/retire out the entrenched development community that is under pressure to deliver and will always fall back on what they were taught and know works. Tony From owner-multi6@ops.ietf.org Wed Oct 23 19:49:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08091 for ; Wed, 23 Oct 2002 19:49:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184VHY-000P0v-00 for multi6-data@psg.com; Wed, 23 Oct 2002 16:51:24 -0700 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #2) id 184VHV-000Oxw-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 16:51:22 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9NNoBJf018754; Thu, 24 Oct 2002 01:50:11 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9NNoBfc019916; Thu, 24 Oct 2002 01:50:11 +0200 Received: from [9.29.3.174] by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA18596 from ; Thu, 24 Oct 2002 01:50:08 +0200 Message-Id: <3DB735A4.B98DC92E@hursley.ibm.com> Date: Thu, 24 Oct 2002 01:49:57 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Eliot Lear Cc: Michel Py , Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Recommendation v Requirements [Re: The state of IPv6 multihomingdevelopment References: <2B81403386729140A3A899A8B39B04640BD21B@server2000> <3DB6A0D9.44A5209@hursley.ibm.com> <3DB70CB1.9010208@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear wrote: > > Brian E Carpenter wrote: > > > Sure. And in answer to Eliot, its usefulness is to provide > > a frame in which to think about proposed solutions. > > Given the document will have no force, I suppose I don't care all too > much. My point, however, is that the frame appears currently more like > an overly constraining box. We're engineers and should be used to designing in overconstrained spaces. I just like to know what the constraints are. I'm sure we don't need a recharter to downgrade the requirements deliverable to an Informational. Brian From owner-multi6@ops.ietf.org Wed Oct 23 21:50:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11889 for ; Wed, 23 Oct 2002 21:50:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184XAb-0009nu-00 for multi6-data@psg.com; Wed, 23 Oct 2002 18:52:21 -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.36 #2) id 184XAa-0009ni-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 18:52:20 -0700 content-class: urn:content-classes:message Subject: RE: Recommendation v Requirements [Re: The state of IPv6 multihomingdevelopment Date: Wed, 23 Oct 2002 18:52:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3A5@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Recommendation v Requirements [Re: The state of IPv6 multihomingdevelopment Thread-Index: AcJ67xcywccbnFCuQ3KU8it8G1VUMwAD1E3g From: "Michel Py" To: "Brian E Carpenter" , "Eliot Lear" Cc: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA11889 Brian, > Brian E Carpenter wrote: > I'm sure we don't need a recharter to downgrade the > requirements deliverable to an Informational. I must be missing something. This is what the charter says: > SEP 01 Submit requirements ID to IESG for publication as > Informational RFC. And it has been used as an excuse for over a year to do nothing. What is the difference with what you are proposing? What I am talking about is removing the word "requirements". If requirements are optional, they are not requirements. Removing pseudo-normative language is a step in the right direction, but is not enough, as people will endlessly argue that if there is a requirement document that says "we must not do this" it will be almost as good as "we MUST NOT do this" and be enough to block any solution. Call it "recommendations", "guidelines", "framework" or come up with a better term but not "requirements". Michel. From owner-multi6@ops.ietf.org Wed Oct 23 23:08:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15021 for ; Wed, 23 Oct 2002 23:08:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184YN0-000FPD-00 for multi6-data@psg.com; Wed, 23 Oct 2002 20:09:14 -0700 Received: from smtp1.extremenetworks.com ([216.52.8.6]) by psg.com with esmtp (Exim 3.36 #2) id 184YMz-000FL7-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 20:09:13 -0700 Received: from extremenetworks.com (ssh.extremenetworks.com [10.0.1.139]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 671197A0F; Wed, 23 Oct 2002 20:08:40 -0700 (PDT) Date: Wed, 23 Oct 2002 23:08:43 -0400 Subject: Re: draft-ietf-multi6-multihoming-requirements-03.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: multi6@ops.ietf.org To: smd@ab.use.net (Sean Doran) From: RJ Atkinson In-Reply-To: <20021023011923.9C051AE3@ab.use.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I propose that the chairs schedule a meeting in Atlanta to discuss the above draft and try to see whether or not it is ready for advancement. Even if not ready for advancement, a meeting to discuss the draft might highlight which areas lack consensus and thus help focus future discussions. I'd ask that the author resubmit the draft if necessary in order to ensure that the I-D not expire before/during IETF Atlanta. I believe the above to be within charter for this WG. Ran From owner-multi6@ops.ietf.org Wed Oct 23 23:10:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15064 for ; Wed, 23 Oct 2002 23:10:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184YQ6-000Fev-00 for multi6-data@psg.com; Wed, 23 Oct 2002 20:12:26 -0700 Received: from smtp1.extremenetworks.com ([216.52.8.6]) by psg.com with esmtp (Exim 3.36 #2) id 184YQ4-000Fd8-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 20:12:24 -0700 Received: from extremenetworks.com (ssh.extremenetworks.com [10.0.1.139]) by smtp1.extremenetworks.com (Postfix) with ESMTP id BFC6F7A0F; Wed, 23 Oct 2002 20:11:51 -0700 (PDT) Date: Wed, 23 Oct 2002 23:11:54 -0400 Subject: Re: Agenda for Atlanta Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20021023134838.V14896-100000@sequoia.muada.com> Message-Id: <59104458-E6FE-11D6-85DC-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Oct 23, 2002, at 08:20 America/Montreal, Iljitsch van Beijnum wrote: > There is one thing I'm not entirely clear on about the IETF meetings. > Are the wg sessions usually only/mostly populated by the same people > that are on the wg mailinglist, or do these sessions draw a wider > public? Generally a subset of the mailing list attends a given WG meeting, for reasons of cost and calendar complexity. They generally do not draw a wider audience. > However, if we can get some routing, transport protocol and mobility > people together, we may actually come up with some new insights or even > a broad consensus. The routing people who have showed up here are not slouches, yet seem to be ignored by some of the vocal multihoming advocates. Sigh. And I don't think we lack for transport or architectural clue here either. Ran From owner-multi6@ops.ietf.org Thu Oct 24 00:01:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16261 for ; Thu, 24 Oct 2002 00:01:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184ZDC-000JfD-00 for multi6-data@psg.com; Wed, 23 Oct 2002 21:03:10 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 184ZDA-000JeP-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 21:03:08 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id AAA09256; Thu, 24 Oct 2002 00:03:06 -0400 Date: Thu, 24 Oct 2002 00:03:06 -0400 From: "J. Noel Chiappa" Message-Id: <200210240403.AAA09256@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum > If we look at a huge enterprise as one example of someone who needs > multihoming, and at a single host with two interfaces or one interface > with two addresses as another .. they could both use a multi address > solution. This is an excellent point, part of one I was about to make myself, actually, as a result of my previous message mentioning the difference between "site multi-homing" and "host multi-homing". If you have a host which is multi-homed to widely spaced points in the topology, there's unlikely to be a routing-based solution, i.e. one where that host has only one address. > For the host, this could be something like Marcelo Bagnulo's extension > header, modified mobility, Peter Tattam's modified TCP or my own > "BALTS" idea. These all boil down to a host having several addresses > and being able to receive packets on a secondary address and trick the > transport layer into thinking it's still using the primary address. Two points. First, Craig Huegen seems to think that any solution involving multiple addresses is infeasible for a large organization. What's your reply to him? Second, I seem to recall some people objecting to multiple addresses because it's too much code/complexity. It would seem to me that once you have multiple addresses, the details on exactly how they are used are somewhat in the noise; whether one tricks the transport layer, or gets it to understand the possibility of multiple addresses, there's a certain amount of code involved. About the only way I could see it making a difference is if you can figure out some way to do all on the multi-homed end. Some multiple-address schemes involve both ends, which is obviously more perturbing. The downside, of course, is that then there are probably things you can't do it you only involve the multi-homed end. (Too tired to figure them all out right at the moment - although I suppose you could use the "aliasing/tunneling devices" at the non-multi-homed end to get around this.) Of couse, then it starts to get ugly pretty quickly... lots of different hacks and kludges. Noel From owner-multi6@ops.ietf.org Thu Oct 24 01:51:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18039 for ; Thu, 24 Oct 2002 01:51:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184avc-00028U-00 for multi6-data@psg.com; Wed, 23 Oct 2002 22:53:08 -0700 Received: from [209.233.126.65] (helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #2) id 184ava-00023Y-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 22:53:06 -0700 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 22:52:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3A8@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ7E10pSRvJ5EslSL2fq9ql5lbu/AACEvWg From: "Michel Py" To: "J. Noel Chiappa" , X-Spam-Status: No, hits=-3.6 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA18039 Noel, > J. Noel Chiappa wrote: > If you have a host which is multi-homed to widely spaced > points in the topology, there's unlikely to be a routing-based > solution, i.e. one where that host has only one address. I totally disagree, and this sounds rather surprising to me considering what you have written in the past about identity/location separation. Would you be more specific about why you find this unlikely, and what you call "widely spaced" (which I read as "from different PA blocks). > First, Craig Huegen seems to think that any solution > involving multiple addresses is infeasible for a large > organization. What's your reply to him? There is a difference between the solution itself using multiple addresses and each host using multiple addresses. If each host has to use multiple addresses, I regret to report that Craig's statement is not an opinion, but a fact. Any people that disagree with this and that actually have renumbered a 1000+ subnet enterprise network, please speak up; otherwise, don't. However, a solution that involves multiple addresses at the edge of the organization but single addresses on the internal network and hosts does not look unfeasible to me (Craig, please comment). > Second, I seem to recall some people objecting to multiple > addresses because it's too much code/complexity. It would > seem to me that once you have multiple addresses, the details > on exactly how they are used are somewhat in the noise; whether > one tricks the transport layer, or gets it to understand the > possibility of multiple addresses, there's a certain amount of > code involved. No disagreement here. That being said, we are not pursuing the UMS without new code, are we? > About the only way I could see it making a difference is if > you can figure out some way to do all on the multi-homed end. All on the multihomed end seems unrealistic, but there are ways to avoid impact on the source single-homed end. Michel. From owner-multi6@ops.ietf.org Thu Oct 24 02:25:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27646 for ; Thu, 24 Oct 2002 02:25:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184bTF-0004d1-00 for multi6-data@psg.com; Wed, 23 Oct 2002 23:27:53 -0700 Received: from [209.233.126.65] (helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #2) id 184bTD-0004cS-00 for multi6@ops.ietf.org; Wed, 23 Oct 2002 23:27:51 -0700 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Wed, 23 Oct 2002 23:27:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3AB@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ65xRKzEC4jqqmR5OhtyDpmjoF3gAPX31A From: "Michel Py" To: "Greg Maxwell" Cc: "Multi6 Working Group" X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA27646 Greg, > Greg Maxwell wrote: > Contentential boundries are the only ones that make sence.. > Any tighter and there is too much movement and interconnection. > Contentential bounderies also make sence because they could be > aligned with the addressing authorties. You are not the first one to make this argument. > But.. They don't buy us much.. At best they would reduce > the routing table by a factor of 4 or so, probably less.. Something of that order. That being said, a factor 4 is 4 years of extra time developing a better solution. If the better solution does use the same addressing scheme, it does make sense. > I believe that any tunnling purposal would be an incomplete > solution and something of a hack. I really don't think that > anyone is arguing that such a solution is realistic due to > it's inelegance. (anyone feel free to correct me) $100 cash to find a flaw in this one: http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt (please read the open issues too) Michel. From owner-multi6@ops.ietf.org Thu Oct 24 04:03:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28782 for ; Thu, 24 Oct 2002 04:03:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184cyd-0009wz-00 for multi6-data@psg.com; Thu, 24 Oct 2002 01:04:23 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 184cyb-0009wm-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 01:04:21 -0700 Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g9O84InZ009352; Thu, 24 Oct 2002 10:04:18 +0200 Received: (from shane@localhost) by x17.ripe.net (8.11.6/8.11.6) id g9O84In29819; Thu, 24 Oct 2002 10:04:18 +0200 Date: Thu, 24 Oct 2002 10:04:18 +0200 From: Shane Kerr To: "J. Noel Chiappa" Cc: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development Message-ID: <20021024080418.GB29728@x17.ripe.net> References: <200210240403.AAA09256@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210240403.AAA09256@ginger.lcs.mit.edu> User-Agent: Mutt/1.3.25i X-RIPE-Spam-Status: NONE ; -1027 X-Spam-Status: No, hits=-16.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On 2002-10-24 00:03:06 -0400, J. Noel Chiappa wrote: > > Two points. First, Craig Huegen seems to think that any solution > involving multiple addresses is infeasible for a large organization. > What's your reply to him? Even if he's right, I think he's wrong to argue against end-point solutions based on multiple addresses. Given the current understanding of the problem and the approaches that have been outlined, doesn't it seem like wishful thinking to want One True Multihoming strategy? For small sites, binding multiple PA addresses into a single end-point seems like a straightforward, cheap, and effective solution. I'm not even 100% sure he's correct that multihoming needs to be in the network in order to do traffic engineering. At least, I can envision end-site solutions that solve some (simple) classes of traffic engineering requirements. :) -- Shane Kerr RIPE NCC From owner-multi6@ops.ietf.org Thu Oct 24 04:06:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28814 for ; Thu, 24 Oct 2002 04:06:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184d2J-000A8u-00 for multi6-data@psg.com; Thu, 24 Oct 2002 01:08:11 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184d2G-000A8i-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 01:08:08 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9O86VI21699; Thu, 24 Oct 2002 10:06:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Oct 2002 10:06:31 +0200 (CEST) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <200210240403.AAA09256@ginger.lcs.mit.edu> Message-ID: <20021024092051.D14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 24 Oct 2002, J. Noel Chiappa wrote: > > If we look at a huge enterprise as one example of someone who needs > > multihoming, and at a single host with two interfaces or one interface > > with two addresses as another .. they could both use a multi address > > solution. > This is an excellent point, part of one I was about to make myself, actually, > as a result of my previous message mentioning the difference between "site > multi-homing" and "host multi-homing". > If you have a host which is multi-homed to widely spaced points in the > topology, there's unlikely to be a routing-based solution, i.e. one where that > host has only one address. Disagree with you there, but I think that's nothing new by now. Maybe we should have a look at source routing? > > For the host, this could be something like Marcelo Bagnulo's extension > > header, modified mobility, Peter Tattam's modified TCP or my own > > "BALTS" idea. These all boil down to a host having several addresses > > and being able to receive packets on a secondary address and trick the > > transport layer into thinking it's still using the primary address. > Two points. First, Craig Huegen seems to think that any solution involving > multiple addresses is infeasible for a large organization. What's your reply > to him? I was talking specifically about a multihomed host in the above. Looking at a large multihomed organization as simply a collection of individual hosts that are all multihomed is unmanagable. So remove the multihoming processing to the edges where you can control it. I think that could work well. > Second, I seem to recall some people objecting to multiple addresses because > it's too much code/complexity. My objection is that it will take too long to develop to simply wait for it, we must have something in the mean time. But other than that I don't think the complexity is too bad. > It would seem to me that once you have > multiple addresses, the details on exactly how they are used are somewhat in > the noise; whether one tricks the transport layer, or gets it to understand > the possibility of multiple addresses, there's a certain amount of code > involved. Well, yes, sort of. > About the only way I could see it making a difference is if you can figure out > some way to do all on the multi-homed end. I don't see this happening. If the destination is multihomed using several addresses, and the source is single homed, the best we can do is move the necessary processing from the source to a box a little upstream. This could be a router/firewall or maybe ISPs can do this for their customers. But if the destination has several addresses and the one used becomes unreachable, someone somewhere will have to switch to a secondary address. > Some multiple-address schemes > involve both ends, which is obviously more perturbing. The downside, of > course, is that then there are probably things you can't do it you only > involve the multi-homed end. (Too tired to figure them all out right at the > moment - although I suppose you could use the "aliasing/tunneling devices" > at the non-multi-homed end to get around this.) > Of couse, then it starts to get ugly pretty quickly... lots of different hacks > and kludges. It's no worse than mobility. And have a look at the v4 routing table, that's not exactly a thing of beauty either. From owner-multi6@ops.ietf.org Thu Oct 24 05:08:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29985 for ; Thu, 24 Oct 2002 05:08:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184e0f-000Da3-00 for multi6-data@psg.com; Thu, 24 Oct 2002 02:10:33 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184e0c-000DZr-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 02:10:30 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9O98nI21774; Thu, 24 Oct 2002 11:08:53 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Oct 2002 11:08:49 +0200 (CEST) From: Iljitsch van Beijnum To: Tony Hain cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <027101c27ad0$059f7e00$4b194104@eagleswings> Message-ID: <20021024105714.N14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Tony Hain wrote: > > Actually holes in PA space is perfectly fine for the network, as you > > can filter the more specifics and still have connectivity. > This statement is self contradictory. How so? > > However, it is not so great for the > > organization using the addresses since this doesn't address > > all failure modes. > The point I was making about punching holes in PA is that the more > influential organizations will get the full prefix routed globally. So then the question becomes: how do we limit the growth in organizational influentialness? :-) This is bad for operators as they have to make complex filters. Also, this "solution" still requires renumbering. > > This could be done by having several instances of > > this address space and have two places that would otherwise > > be aggregated together sit in a different instance. By > > rotating the axes and limiting everything to (say) from -60 > > to +60 degrees you eliminate the pole problem. > I played with rotating the axis, but the only thing that made Europe > contiguous was to put the origin on a 22.5 degree mark. That would be shifting. What I mean is have at least three instances, one with the poles at 90 north/south, one with the "poles" at the equator at the 0 and 180 meridians and one with the poles at the equator at the 90 and 270 meridians. Then you only need to go upto 45 degrees and still every part of the world would be covered by two instances. This means 1.5 times more address space used, but 2 times as much usable in the non-polar regions. > > Still, there is one unanswered question: what problem is solved by > > having such a close relationship between geography and address space? > I was not trying to force any particular alignment. The goals were: > Uses current BGP protocol. > Aggregate the basement-multi-homer, while recognizing the CNN's of the > world will always get a full prefix announced. > Decouple the scale of aggregation, so it becomes a regional decision. > Make it simple to derive by basing it on a globally consistent > reference. You fail to address my question. This scheme uses an incredible amount of address space, but still manages to come up short in very densely populated areas. The aggregation properties are relatively poor. So what is it that makes all these downsides worth it? Basing a geographical address allocation scheme on population (x addresses per person) rather than geography (x addresses per square kilometer) makes more sense, as long as you're not going to use IP addresses to aim your microwave antenna or something like that. From owner-multi6@ops.ietf.org Thu Oct 24 05:30:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00253 for ; Thu, 24 Oct 2002 05:30:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184eLj-000EnW-00 for multi6-data@psg.com; Thu, 24 Oct 2002 02:32:19 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184eLg-000EnH-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 02:32:17 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9O9Ubh21808; Thu, 24 Oct 2002 11:30:37 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Oct 2002 11:30:37 +0200 (CEST) From: Iljitsch van Beijnum To: "Hesham Soliman (EAB)" cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0BCE@Esealnt861.al.sw.ericsson.se> Message-ID: <20021024112834.V14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Hesham Soliman (EAB) wrote: > > Also note that > > current mobility will not support multihoming in any way, > > it would just > > be a starting point and we can borrow the header. > => Current MIPv6 mechanisms _will_ support a multihomed/ > multiaddressed hosts. However, they will not give you a > seamless switch from one path to another when one of the > paths fail. So what's the use then? We don't multihome because we like having many addresses, but to survive failures. > The host will somehow need to be explicitly > notified that it should choose a new CoA. So this will > interrupt (but need not break) ongoing connections. How does a mobile host survive the home agent becoming unreachable? From owner-multi6@ops.ietf.org Thu Oct 24 06:07:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00940 for ; Thu, 24 Oct 2002 06:07:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184euW-000GsX-00 for multi6-data@psg.com; Thu, 24 Oct 2002 03:08:16 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184etT-000Grr-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 03:07:11 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9OA5UI21859; Thu, 24 Oct 2002 12:05:30 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Oct 2002 12:05:30 +0200 (CEST) From: Iljitsch van Beijnum To: Greg Maxwell cc: "'Multi6 Working Group'" Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: <20021024113132.T14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Greg Maxwell wrote: > Contentential boundries are the only ones that make sence.. Any tighter > and there is too much movement and interconnection. That's too bad for the movee. If someone wants to move from Nova Scotia to Costa Rica, they'll just have to renumber. I can live with that. > But.. They don't buy us much.. At best they would reduce the routing > table by a factor of 4 or so, probably less.. 50% for the US because that's where most of the crap is today. But in the long run it will be better as other regions start to do more multihoming. > Heres the thing.. If a simple linear reduction like that will suffice, > then lets just flood the DFZ and let hardware improvments take care of it. Three or so rounds of a factor 10 improvement should be able to take care of it for a good long time. We hear "exponential growth" but of course the growth will only be exponential for so long: in the end, it will be an S curve. So a good solution would be to go for continental aggregation in a couple of years, country/state/province aggregation in five years and metropolitan aggregation in ten years or so. But then we have to start assigning addresses based on metro *now* if we want to avoid renumbering later. > If we do not believe it will suffice, then we must have a solution that > does not increase the routing tables for networks who do not have a > direct relationship with the multihomed network. The only way you need to see all routes is if you are a "tier 1" ISP and don't pay anyone for transit. If having all these routes in your tables is too expensive you can simply pay someone for transit and use a default. It's not like we're forcing innocent bystanders to upgrade their routers, only those who do routing as their core business. > Lets work on answering these questions: Is it approiate for network > operators to have to carry the burden created by other peoples > multihoming? Yes. The alternative is becoming telcos and spend a cent a minute to charge someone for a service that costs only a tenth of a cent to provide in the first place. All ISPs share the costs of multihoming, but they also all have multihomed customers so who cares. > and Can we expect routers handle the future growth of the > IPv6 internet without aggregation? Maybe it will turn out that they can, but counting on it is too dangerous. > My thought on scaling: I don't think that it's unreasonable to say that > simple enhanced versions of todays routing hardware/software could handle > a million routes.. But what happens when we want links that move many 10s > or hundreds of gigabits a second... and we're forced into using optical > packet-level switching.. Switching isn't the problem as routing table lookups scale at O(log(n)). However, processing the updates scales at O(n*log(n)), assuming longer prefixes are as stable as short ones, which they aren't. So routing table lookups should use about 17% more processing for a factor 8 increase (~1M routes) while processing routing updates requires 9.4 times more CPU power. On the other hand, routing table lookups have timing constraints (at least if you want to forward at line rate) while routing updates can be delayed. From owner-multi6@ops.ietf.org Thu Oct 24 06:54:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01556 for ; Thu, 24 Oct 2002 06:54:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184ff7-000Jgg-00 for multi6-data@psg.com; Thu, 24 Oct 2002 03:56:25 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184ff4-000JgT-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 03:56:23 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9OAsjO21957; Thu, 24 Oct 2002 12:54:46 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Oct 2002 12:54:45 +0200 (CEST) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: What happens next? was: Re: Agenda for Atlanta In-Reply-To: <59104458-E6FE-11D6-85DC-00039357A82A@extremenetworks.com> Message-ID: <20021024120807.I14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, RJ Atkinson wrote: > Generally a subset of the mailing list attends a given WG meeting, > for reasons of cost and calendar complexity. They generally do not > draw a wider audience. Ok. I assume more people will show if we tell them we may be straying onto their turf. Although nobody bothered to answer directly, it seems there is consensus that the requirements can be accepted with some small changes. Good. So what happens next? As I see it, we are ready to start working on (relatively) short term routing-only, no changes to code solutions. Some people feel these solutions are inherently inadequate. I don't think that's sufficient reason to not work on this. It may be sufficient reason to not implement it later, but let's see what we can come up with first. We are NOT ready to start working on solutions that use multiple addresses, as there are no good routing <-> source address selection <-> filtering/failing <-> session rehoming mechanisms. I think it would be good to come up with a multi address requirements document. (Or maybe there already is one and I missed it?) When the multi address thing is clear, work can start on address agile transport protocols. However, I don't think this wg is the right place for developing individual transport protocols. There are already several proposals for tunnelling/aliasing solutions. However, having several of those that don't interoperate would be a Bad Thing so I think when we've sorted out the multi address thing, this wg should focus on making different solutions in this area interoperate, or maybe come up with a single solution that is so good others aren't needed. In the mean time, the IRTF can brood on IPv7 and perfect routing. The right answer too late is just as wrong as the wrong answer immediately. There is one thing I want to stress: we all have opinions on which type of solution is better. However, at some point input along the lines of "this solution type simply doesn't cut it" stops being productive. The IETF has produced many protocols that aren't perfect, or even very good. Some of them are in wide use. The best way to stop a bad solution is not to try and stop a bad solution, but to create a good solution of your own. > > However, if we can get some routing, transport protocol and mobility > > people together, we may actually come up with some new insights or even > > a broad consensus. > The routing people who have showed up here are not slouches, > yet seem to be ignored by some of the vocal multihoming advocates. > Sigh. And I don't think we lack for transport or architectural clue > here either. I wasn't commenting on the cluefulness of the multi6 participants. The problem here is that so little happens. Some fresh input might be just the thing to get things moving. Iljitsch From owner-multi6@ops.ietf.org Thu Oct 24 07:23:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01880 for ; Thu, 24 Oct 2002 07:23:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184g6u-000LOK-00 for multi6-data@psg.com; Thu, 24 Oct 2002 04:25:08 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 184g6s-000LO6-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 04:25:07 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9OBOxx14460; Thu, 24 Oct 2002 14:25:00 +0300 Date: Thu, 24 Oct 2002 14:24:59 +0300 (EEST) From: Pekka Savola To: RJ Atkinson cc: Iljitsch van Beijnum , Subject: Re: Agenda for Atlanta In-Reply-To: <59104458-E6FE-11D6-85DC-00039357A82A@extremenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, RJ Atkinson wrote: > On Wednesday, Oct 23, 2002, at 08:20 America/Montreal, Iljitsch van > Beijnum wrote: > > > There is one thing I'm not entirely clear on about the IETF meetings. > > Are the wg sessions usually only/mostly populated by the same people > > that are on the wg mailinglist, or do these sessions draw a wider > > public? > > Generally a subset of the mailing list attends a given WG meeting, > for reasons of cost and calendar complexity. They generally do not > draw a wider audience. Disagree: a wider audience stumbles in just because there was nothing else interesting going on. People interested and fiddling with IPv6 stumble in because, well, they've dealt with IPv6 and want to see what's going on, etc.etc. As for those people active on the list or active doing the work, fewer attend, yes. -- 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 Thu Oct 24 08:12:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03582 for ; Thu, 24 Oct 2002 08:12:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184gr5-000OBs-00 for multi6-data@psg.com; Thu, 24 Oct 2002 05:12:51 -0700 Received: from [24.53.182.61] (helo=localhost) by psg.com with esmtp (Exim 3.36 #2) id 184gr3-000OAo-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 05:12:50 -0700 Received: from [192.168.1.100] (localhost [127.0.0.1]) by localhost (8.12.2/8.12.2) with ESMTP id g9OCBc2O007089; Thu, 24 Oct 2002 08:11:41 -0400 (EDT) Date: Thu, 24 Oct 2002 08:11:37 -0400 From: "Michael H. Lambert" To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Message-ID: <23809037.1035447097@[192.168.1.100]> In-Reply-To: <20021024092051.D14896-100000@sequoia.muada.com> References: <20021024092051.D14896-100000@sequoia.muada.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-8.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 24 October 2002 10:06 +0200 Iljitsch van Beijnum wrote: [...] > I was talking specifically about a multihomed host in the above. Looking > at a large multihomed organization as simply a collection of individual > hosts that are all multihomed is unmanagable. So remove the multihoming > processing to the edges where you can control it. I think that could > work well. >From S's perspective, I can see that this scenario would make it easy to use the right path (from N1, N2, ...) to reach D. However, wouldn't it require the edge to maintain state for each flow which crosses it? 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 Thu Oct 24 08:21:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03755 for ; Thu, 24 Oct 2002 08:21:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184h0t-000Oto-00 for multi6-data@psg.com; Thu, 24 Oct 2002 05:22:59 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184h0p-000OsR-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 05:22:55 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9OCK3h22142; Thu, 24 Oct 2002 14:20:03 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Oct 2002 14:20:03 +0200 (CEST) From: Iljitsch van Beijnum To: "Michael H. Lambert" cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <23809037.1035447097@[192.168.1.100]> Message-ID: <20021024141340.I14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 24 Oct 2002, Michael H. Lambert wrote: > > Looking > > at a large multihomed organization as simply a collection of individual > > hosts that are all multihomed is unmanagable. So remove the multihoming > > processing to the edges where you can control it. I think that could > > work well. > >From S's perspective, I can see that this scenario would make it easy to > use the right path (from N1, N2, ...) to reach D. However, wouldn't it > require the edge to maintain state for each flow which crosses it? It shouldn't if these boxes just replace prefixes. In current NAT setups much more is changed: the entire address, not just a prefix, for starters, and also a port number and the TCP/UDP checksum. In the setup I'm talking about just the prefix (presumably, the 48 most significant bits) change and everything else remains the same, so no need to keep state. From owner-multi6@ops.ietf.org Thu Oct 24 08:31:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04108 for ; Thu, 24 Oct 2002 08:31:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184hAA-000PVP-00 for multi6-data@psg.com; Thu, 24 Oct 2002 05:32:34 -0700 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #2) id 184hA7-000PUB-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 05:32:32 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9OCUMkU027888; Thu, 24 Oct 2002 14:30:22 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9OCULlg076282; Thu, 24 Oct 2002 14:30:22 +0200 Received: from [9.29.3.171] by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA64038 from ; Thu, 24 Oct 2002 14:30:14 +0200 Message-Id: <3DB7E7CB.C0ACDAB8@hursley.ibm.com> Date: Thu, 24 Oct 2002 14:30:03 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: Eliot Lear , Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Recommendation v Requirements [Re: The state of IPv6 multihomingdevelopment References: <2B81403386729140A3A899A8B39B046405E3A5@server2000> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-10.4 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Charters are not algorithms, and Area Directors are normally willing to exercise common sense when a WG diverges in a rational way from its charter. Please don't use the words in the charter as yet another excuse for delaying output from this WG. I have no problem with calling it 'recommendations', 'thoughts' or 'vague ideas'. The value is in the contents, not the title. Brian Michel Py wrote: > > Brian, > > > Brian E Carpenter wrote: > > I'm sure we don't need a recharter to downgrade the > > requirements deliverable to an Informational. > > I must be missing something. This is what the charter says: > > > SEP 01 Submit requirements ID to IESG for publication as > > Informational RFC. > > And it has been used as an excuse for over a year to do nothing. What is > the difference with what you are proposing? > > What I am talking about is removing the word "requirements". If > requirements are optional, they are not requirements. Removing > pseudo-normative language is a step in the right direction, but is not > enough, as people will endlessly argue that if there is a requirement > document that says "we must not do this" it will be almost as good as > "we MUST NOT do this" and be enough to block any solution. > > Call it "recommendations", "guidelines", "framework" or come up with a > better term but not "requirements". > > Michel. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-multi6@ops.ietf.org Thu Oct 24 08:39:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04332 for ; Thu, 24 Oct 2002 08:39:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184hIW-000PzF-00 for multi6-data@psg.com; Thu, 24 Oct 2002 05:41:12 -0700 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #2) id 184hIU-000Pz1-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 05:41:10 -0700 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA15839; Thu, 24 Oct 2002 13:32:27 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:7UvI6IxTiQ+Db+bhhSut4IbbqCaIQvq5@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g9OCWNWX024758; Thu, 24 Oct 2002 13:32:23 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id g9OCWNf25588; Thu, 24 Oct 2002 13:32:23 +0100 Date: Thu, 24 Oct 2002 13:32:23 +0100 From: Tim Chown To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development Message-ID: <20021024123223.GI22346@login.ecs.soton.ac.uk> References: <23809037.1035447097@[192.168.1.100]> <20021024141340.I14896-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021024141340.I14896-100000@sequoia.muada.com> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-13.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, Oct 24, 2002 at 02:20:03PM +0200, Iljitsch van Beijnum wrote: > > It shouldn't if these boxes just replace prefixes. In current NAT setups > much more is changed: the entire address, not just a prefix, for > starters, and also a port number and the TCP/UDP checksum. In the setup > I'm talking about just the prefix (presumably, the 48 most significant > bits) change and everything else remains the same, so no need to keep > state. Well, that has been punted around as an idea for some time (8+8 or 6+2+8). e.g. from 1995/6: http://www.wcug.wwu.edu/lists/ipng/199612/msg00116.html Tim From owner-multi6@ops.ietf.org Thu Oct 24 08:57:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05103 for ; Thu, 24 Oct 2002 08:57:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184hZz-0001HA-00 for multi6-data@psg.com; Thu, 24 Oct 2002 05:59:15 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184hZw-0001Gs-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 05:59:12 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9OCvaI22233; Thu, 24 Oct 2002 14:57:36 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Oct 2002 14:57:36 +0200 (CEST) From: Iljitsch van Beijnum To: Tim Chown cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021024123223.GI22346@login.ecs.soton.ac.uk> Message-ID: <20021024144445.Y14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 24 Oct 2002, Tim Chown wrote: > > I'm talking about just the prefix (presumably, the 48 most significant > > bits) change and everything else remains the same, so no need to keep > > state. > Well, that has been punted around as an idea for some time (8+8 or 6+2+8). I'm not claiming to have come up with this, let alone that I'd be the first one. What I have in mind is Michel Py's MHAP draft, although the part where a multi-addressed host interacts with the MHAP infrastructure isn't in there, you can blame me for that part. > e.g. from 1995/6: > http://www.wcug.wwu.edu/lists/ipng/199612/msg00116.html On the ipv6mh list we've pretty much disected GSE, which is along the same lines. While this would certainly make for an interesting new direction for further development of the IP family, it doesn't actually solve multihoming while at the same time being so radical it will be hard to get off the ground. If we want to move into the direction of separating identifiers and locators it's probably easier to keep a globally unique and (potentially) routable IPv6 address as the identifier since that way we don't need changes to transport protocols and no "flag day". From owner-multi6@ops.ietf.org Thu Oct 24 08:59:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05137 for ; Thu, 24 Oct 2002 08:59:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184hbz-0001Qk-00 for multi6-data@psg.com; Thu, 24 Oct 2002 06:01:19 -0700 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #2) id 184hbx-0001Me-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 06:01:17 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9OD06Jf014456; Thu, 24 Oct 2002 15:00:07 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9OD06gr071662; Thu, 24 Oct 2002 15:00:06 +0200 Received: from [9.29.3.171] by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38306 from ; Thu, 24 Oct 2002 15:00:04 +0200 Message-Id: <3DB7EEC9.C48E82E@hursley.ibm.com> Date: Thu, 24 Oct 2002 14:59:53 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Tim Chown Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development References: <23809037.1035447097@[192.168.1.100]> <20021024141340.I14896-100000@sequoia.muada.com> <20021024123223.GI22346@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: > > On Thu, Oct 24, 2002 at 02:20:03PM +0200, Iljitsch van Beijnum wrote: > > > > It shouldn't if these boxes just replace prefixes. In current NAT setups > > much more is changed: the entire address, not just a prefix, for > > starters, and also a port number and the TCP/UDP checksum. In the setup > > I'm talking about just the prefix (presumably, the 48 most significant > > bits) change and everything else remains the same, so no need to keep > > state. > > Well, that has been punted around as an idea for some time (8+8 or 6+2+8). > > e.g. from 1995/6: > http://www.wcug.wwu.edu/lists/ipng/199612/msg00116.html And it is not part of the IPv6 that is being rolled out today, so I don't think rehashing the debate is relevant to multihoming that IPv6. Brian From owner-multi6@ops.ietf.org Thu Oct 24 10:08:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08746 for ; Thu, 24 Oct 2002 10:08:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184if5-0005rR-00 for multi6-data@psg.com; Thu, 24 Oct 2002 07:08:35 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 184if2-0005rF-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 07:08:32 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9OE8TKV015055; Thu, 24 Oct 2002 16:08:30 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 24 Oct 2002 16:08:29 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0BD2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Iljitsch van Beijnum'" Cc: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Date: Thu, 24 Oct 2002 16:08:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Status: No, hits=-1.1 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_05_08 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > > Also note that > > > current mobility will not support multihoming in any way, > > > it would just > > > be a starting point and we can borrow the header. > > > => Current MIPv6 mechanisms _will_ support a multihomed/ > > multiaddressed hosts. However, they will not give you a > > seamless switch from one path to another when one of the > > paths fail. > > So what's the use then? We don't multihome because we like > having many > addresses, but to survive failures. => That's why I asked: "How much interruption is acceptable?" What do you mean by survive failure? Is it ok to lose 150 ms of traffic? Or are you asking for a seamless survival failures (i.e. zero interruption). Frankly I don't think that a 100 - 200 ms interruption is a big deal, considering that this failure is not something that will happen once a minute. > > > The host will somehow need to be explicitly > > notified that it should choose a new CoA. So this will > > interrupt (but need not break) ongoing connections. > > How does a mobile host survive the home agent becoming unreachable? => I'm confused. Why would a home Agent become unreachable?? You seem to assume that the HA must be located in the upstream provider's network (that's the only interpretation I can think of for your statement above). The HA can be located in the mutlihomed enterprise. Hesham > From owner-multi6@ops.ietf.org Thu Oct 24 10:42:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10113 for ; Thu, 24 Oct 2002 10:42:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184jCN-0008FN-00 for multi6-data@psg.com; Thu, 24 Oct 2002 07:42:59 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184jCK-0008EP-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 07:42:56 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9OEfKI22769; Thu, 24 Oct 2002 16:41:20 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Oct 2002 16:41:20 +0200 (CEST) From: Iljitsch van Beijnum To: "Hesham Soliman (EAB)" cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0BD2@Esealnt861.al.sw.ericsson.se> Message-ID: <20021024163617.A14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 24 Oct 2002, Hesham Soliman (EAB) wrote: > > So what's the use then? We don't multihome because we like > > having many addresses, but to survive failures. > => That's why I asked: "How much interruption is acceptable?" > What do you mean by survive failure? Is it ok to lose 150 ms > of traffic? Or are you asking for a seamless survival failures > (i.e. zero interruption). Frankly I don't think that a 100 - 200 ms > interruption is a big deal, considering that this failure is not > something that will happen once a minute. The shorter the better, but anything under 15 seconds is good enough, IMO. > > How does a mobile host survive the home agent becoming unreachable? > => I'm confused. Why would a home Agent become unreachable?? > You seem to assume that the HA must be located in the > upstream provider's network (that's the only interpretation > I can think of for your statement above). The HA can be located > in the mutlihomed enterprise. Ah, I see now. I'm not sure where exactly I envisioned the home agent, but I didn't consider moving it to a place that is multihomed through separate means. Still, we'd need a good solution for all the home agents (at least this will lessen the problem a good deal) and having a single point of failure somewhere isn't optimal. From owner-multi6@ops.ietf.org Thu Oct 24 11:08:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11152 for ; Thu, 24 Oct 2002 11:08:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184jcK-000AC2-00 for multi6-data@psg.com; Thu, 24 Oct 2002 08:09:48 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 184jcI-000ABg-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 08:09:46 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9OF9iKV001049; Thu, 24 Oct 2002 17:09:44 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 24 Oct 2002 17:09:44 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0BD6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Iljitsch van Beijnum'" Cc: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Date: Thu, 24 Oct 2002 17:09:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Status: No, hits=-1.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > > So what's the use then? We don't multihome because we like > > > having many addresses, but to survive failures. > > > => That's why I asked: "How much interruption is acceptable?" > > What do you mean by survive failure? Is it ok to lose 150 ms > > of traffic? Or are you asking for a seamless survival failures > > (i.e. zero interruption). Frankly I don't think that a > 100 - 200 ms > > interruption is a big deal, considering that this failure is not > > something that will happen once a minute. > > The shorter the better, but anything under 15 seconds is > good enough, > IMO. => ok, thanks. 15 seconds is eternity for MIPv6, I don't think meeting this time restriction is an issue. > > => I'm confused. Why would a home Agent become unreachable?? > > You seem to assume that the HA must be located in the > > upstream provider's network (that's the only interpretation > > I can think of for your statement above). The HA can be located > > in the mutlihomed enterprise. > > Ah, I see now. I'm not sure where exactly I envisioned the > home agent, > but I didn't consider moving it to a place that is > multihomed through > separate means. Still, we'd need a good solution for all > the home agents > (at least this will lessen the problem a good deal) and > having a single > point of failure somewhere isn't optimal. => Sure, but corporate networks are full of them :). This is an important problem to solve IMHO, whether it should be done in this WG is a different discussion. Hesham From owner-multi6@ops.ietf.org Thu Oct 24 11:14:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11401 for ; Thu, 24 Oct 2002 11:14:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184jhu-000AeL-00 for multi6-data@psg.com; Thu, 24 Oct 2002 08:15:34 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 184jhs-000AdQ-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 08:15:32 -0700 From: Masataka Ohta Message-Id: <200210241509.AAA02747@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA02747; Fri, 25 Oct 2002 00:08:46 +0859 Subject: Re: The state of IPv6 multihoming development In-Reply-To: from "Craig A. Huegen" at "Oct 22, 2002 10:32:52 am" To: "Craig A. Huegen" Date: Fri, 25 Oct 2002 00:08:45 +0859 () CC: Brian E Carpenter , Iljitsch van Beijnum , RJ Atkinson , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Huegen; > As for the original multi-PA multihoming solution, it doesn't fly in an > enterprise. The selection of source and destination addresses by the > originating host keeps enterprises from managing bandwidth on circuits, > because the routing infrastructure has no idea of possible alternate paths > for the packet. According to your theory, the Internet today is not working, because bandwidth of TCP is managed by individual hosts and the routing infrastructure has no idea on it. The reality is that L2/3 traffic engineering is a fallacy. It was invented by people insisting on MPLS, even after they must admit an obvious fact that MPLS routers are more expensive but no faster than plain routers. The real traffic engineering is that, if there is not enough link capacity, add more fiber. > BGP isn't perfect either, but it's much better than how > many bits a particular address has in common with another. Managing n+1 > prefixes per subnet where n is number of providers serving a site is a > nightmare. The list of problems goes on... The nightmare is to manage n ASes where n is the number of multihomed sites in the world. Masataka Ohta From owner-multi6@ops.ietf.org Thu Oct 24 11:44:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12865 for ; Thu, 24 Oct 2002 11:44:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184kB4-000CmQ-00 for multi6-data@psg.com; Thu, 24 Oct 2002 08:45:42 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 184kB3-000Cls-00; Thu, 24 Oct 2002 08:45:41 -0700 From: Masataka Ohta Message-Id: <200210241534.AAA03190@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA03190; Fri, 25 Oct 2002 00:34:39 +0900 Subject: Re: The state of IPv6 multihoming development In-Reply-To: from Randy Bush at "Oct 22, 2002 05:48:05 pm" To: Randy Bush Date: Fri, 25 Oct 2002 00:34:38 +0859 () CC: "Craig A. Huegen" , Tony Li , Tim Chown , Multi6 Working Group X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Randy; > this group is chartered to refine and explore solutions to the > problems of large-scale multihoming in ipv6. it is not chartered > to do ipv6 marketing. and, while it would be nice to use existing > code, that is not a constraint (and i suspect that, if it were, > this group would likely fail). Just FYI, their is existing code running for end to end multihoming. With 8+8 addressing, modification to TCP code was trivially easy. Masataka Ohta From owner-multi6@ops.ietf.org Thu Oct 24 11:44:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12880 for ; Thu, 24 Oct 2002 11:44:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184kAw-000Cm5-00 for multi6-data@psg.com; Thu, 24 Oct 2002 08:45:34 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 184kAu-000Cls-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 08:45:32 -0700 From: Masataka Ohta Message-Id: <200210241533.AAA03186@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA03186; Fri, 25 Oct 2002 00:32:58 +0859 Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021022181323.S14896-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Oct 22, 2002 06:23:37 pm" To: Iljitsch van Beijnum Date: Fri, 25 Oct 2002 00:32:57 +0859 () CC: Brian E Carpenter , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > > I would love to be able to agree with you. Of course I do agree > > that multi-homing is a must-have. But we just can't put the BGP4+ > > table on the exponential path. It's very unfortunate that this WG > > has made no progress on resolving that dilemma. > > I figured the whole geographical aggregation thing was a step in the > right direction... A problem is that such geographical aggregation can not properly handle multiple links between regions maintained by multiple entities. Another problem is that it is helpless for a partitioned geographical area. Masataka Ohta From owner-multi6@ops.ietf.org Thu Oct 24 12:02:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13644 for ; Thu, 24 Oct 2002 12:02:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184kT7-000E5f-00 for multi6-data@psg.com; Thu, 24 Oct 2002 09:04:21 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 184kT5-000E5R-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 09:04:19 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 184kT5-000O9y-00; Thu, 24 Oct 2002 09:04:19 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian E Carpenter Cc: multi6@ops.ietf.org Subject: Re: Recommendation v Requirements [Re: The state of IPv6 multihomingdevelopment References: <2B81403386729140A3A899A8B39B046405E3A5@server2000> <3DB7E7CB.C0ACDAB8@hursley.ibm.com> Message-Id: Date: Thu, 24 Oct 2002 09:04:19 -0700 X-Spam-Status: No, hits=-5.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I have no problem with calling it 'recommendations', 'thoughts' > or 'vague ideas'. The value is in the contents, not the title. i recommend worrying about the content and the progress far more than about the title. randy, with ad hat on From owner-multi6@ops.ietf.org Thu Oct 24 12:03:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13684 for ; Thu, 24 Oct 2002 12:03:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184kUC-000E7j-00 for multi6-data@psg.com; Thu, 24 Oct 2002 09:05:28 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 184kU9-000E77-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 09:05:25 -0700 From: Masataka Ohta Message-Id: <200210241557.AAA03593@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA03593; Fri, 25 Oct 2002 00:57:38 +0900 Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021023223146.P14896-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Oct 23, 2002 10:42:23 pm" To: Iljitsch van Beijnum Date: Fri, 25 Oct 2002 00:57:37 +0859 () CC: Greg Maxwell , Multi6 Working Group X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > > Is this really about the limits of top end scaling? > > I always considered it to be about making routing more O(1)ish with > > respect to multihomed networks you don't have a bussiness relationship > > then O(n*mumble).. > > O(1)? :-) > > Well, maybe there is such a beast. When I studied software engineering I > was told there were no sorting algorithms that could do better than > O(n*log(n)). However, some digging produced radix sort, which was used > in the good old days of the Hollerith machines and scales O(n). So just > because people think it can't be done doesn't mean it can't be done. Radix sort uses address arithmetic complexity of which is silently assumed to be O(1). However, speed of real memory is O(log(size of the memory)). That's one of the reason why reduction of DFZ is important for the high speed Internet with quick routing table look up. Masataka Ohta From owner-multi6@ops.ietf.org Thu Oct 24 12:19:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14331 for ; Thu, 24 Oct 2002 12:19:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184kjL-000FMj-00 for multi6-data@psg.com; Thu, 24 Oct 2002 09:21:07 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184kjI-000FMJ-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 09:21:04 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9OGJJj23143; Thu, 24 Oct 2002 18:19:19 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Oct 2002 18:19:19 +0200 (CEST) From: Iljitsch van Beijnum To: Masataka Ohta cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: <200210241533.AAA03186@necom830.hpcl.titech.ac.jp> Message-ID: <20021024180913.Y14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 25 Oct 2002, Masataka Ohta wrote: > > I figured the whole geographical aggregation thing was a step in the > > right direction... > A problem is that such geographical aggregation can not properly > handle multiple links between regions maintained by multiple entities. Regions aren't "maintained" by "entities". You simply route traffic for a region to a router inside your own network that has more specific routing information for the region. Obvioulsy, it makes sense to put that router inside that region, but you don't have to. > Another problem is that it is helpless for a partitioned geographical > area. You can deaggregate. But automatic deaggregation is dangerous, so yes, partitioning is bad. This means you must define your regions in such a way that it is very unlikely that they will be partitioned internally, from the rest of the network or from peers in the region. This makes it hard to arrive at very small regions which in turn sets a practical limit on the scalability of geographical aggregation. In theory, it can scale to 1G multihomers. In practice, it won't be much fun anymore beyond 25 - 100M. From owner-multi6@ops.ietf.org Thu Oct 24 12:20:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14371 for ; Thu, 24 Oct 2002 12:20:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184kj5-000FM1-00 for multi6-data@psg.com; Thu, 24 Oct 2002 09:20:51 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 184kj3-000FLp-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 09:20:49 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id MAA12189; Thu, 24 Oct 2002 12:20:47 -0400 Date: Thu, 24 Oct 2002 12:20:47 -0400 From: "J. Noel Chiappa" Message-Id: <200210241620.MAA12189@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Hain" >> naming them "provider-dependent" and "provider-independent" >> addresses, thereby completely obscuring the underlying technical >> issues, and making it seem like it's purely a policy issue .. If >> you want technically accurate terminology .. call them >> "connectivity-dependent" and "connectivity-independent". > There was no attempt to make this a political argument, in fact it > is more accurate than connectivity-*. The current policy says > customers get their prefix from their provider so that it > aggregates, therefore it is provider-dependent. End sites are > looking for a mechanism that allows them to decouple their prefix > from any specific provider, therefore it is provider-independent. Look, there are network designs which allow connectivity-dependent addressing schemes which are *not* provider-dependent. E.g. if a (large enough) bunch of customers band together and create an exchange, which buys service from multiple ISP's, and which is given an address which is visible over the same scope as those ISP's, and the customers are addressed as part of that exchange, you meet the policy goal (being able to change providers) *without* so-called "PI" addresses. But the addresses are still connectivity-based. So there's one really good reason to discard this bogus "provider-dependent" and "provider-independent" terminology - because there are cases in which it *doesn't* align with the underlying technical issue. Perhaps if people understood the underlying technical issues better this discussion would be more fruitful. Using terminology which *accurately* conveys the underlying fundamental technical limitations, rather than their policy goals, is a good place to start. Noel From owner-multi6@ops.ietf.org Thu Oct 24 12:23:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14533 for ; Thu, 24 Oct 2002 12:23:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184knN-000FnV-00 for multi6-data@psg.com; Thu, 24 Oct 2002 09:25:17 -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.36 #2) id 184knL-000Fmi-01 for multi6@ops.ietf.org; Thu, 24 Oct 2002 09:25:15 -0700 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Thu, 24 Oct 2002 09:15:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3B0@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ6wAq7v0gnxJdmTS2of7zjKbY9zQAt3hYA From: "Michel Py" To: "Randy Bush" , "Greg Maxwell" Cc: "Tony Li" , "Michael Richardson" , "Multi6 Working Group" X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14533 > Randy Bush wrote: > as i am not aware of anyone filtering v6 announcements > at the moment (well, other than maybe at /48 or something), > perhaps this wg should work on solutions to the routing > problems presented and assume that, if reasonable aggregation > is one of those goals and is met, that the isps will act > rationally. I and lots of other people filter at /35, soon to be /32 for the 2001:: space and at /24 or /32 (depending on the range) for the 3ffe:: space. Which is perfectly in line with the whole idea of aggregation. Michel. From owner-multi6@ops.ietf.org Thu Oct 24 12:23:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14548 for ; Thu, 24 Oct 2002 12:23:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184knc-000Foe-00 for multi6-data@psg.com; Thu, 24 Oct 2002 09:25: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.36 #2) id 184knL-000Fmi-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 09:25:15 -0700 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Thu, 24 Oct 2002 08:38:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3AE@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ60MiiXTFSvpZLTx+wx9943VJ73gAoNugw From: "Michel Py" To: , "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=-4.2 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14548 Tony, > Tony Hain wrote: > Is it the most efficient use of address space? No, and the > document recognizes there is a clear trade-off being made > between simplicity and efficiency. Are there other ways to > achieve the listed goals? Probably, and when I see something > that looks more operationally viable I will back off. I agree with your ideas, and they were a major contributor to this: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt I suggest you accept the fact that the chances of getting the /4 you need are zero. As I said before, I would be the strongest supporter of your scheme if it stood a chance. Michel. From owner-multi6@ops.ietf.org Thu Oct 24 12:23:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14582 for ; Thu, 24 Oct 2002 12:23:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184knM-000FnP-00 for multi6-data@psg.com; Thu, 24 Oct 2002 09:25:16 -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.36 #2) id 184knK-000Fmi-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 09:25:14 -0700 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Thu, 24 Oct 2002 08:03:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3AC@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ7NSdtkbCVypmwQvidasQu6OYbdwAN0fPw From: "Michel Py" To: "Shane Kerr" , "J. Noel Chiappa" Cc: X-Spam-Status: No, hits=-0.7 required=5.0 tests=SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14582 Shane, >> J. Noel Chiappa wrote: >> Two points. First, Craig Huegen seems to think that >> any solution involving multiple addresses is infeasible >> for a large organization. What's your reply to him? > Shane Kerr wrote: > Even if he's right, I think he's wrong to argue against > end-point solutions based on multiple addresses. Given > the current understanding of the problem and the approaches > that have been outlined, doesn't it seem like wishful > thinking to want One True Multihoming strategy? For small > sites, binding multiple PA addresses into a single > end-point seems like a straightforward, cheap, and > effective solution. Absolutely. It is clear that there is a place for both, and this WG has been denying host-based solution in the misguided hunt for The Universal Multihoming Solution. A PI solution is not the answer to everybody nor is a host solution. My message to Peter Tattam and other people that have designed host solutions is this: There is a place for what you are doing, but also understand that it's not what everyone needs, and accept the fact that your solution will have to coexist with something else. > I'm not even 100% sure he's correct that multihoming > needs to be in the network in order to do traffic > engineering. At least, I can envision end-site > solutions that solve some (simple) classes of > traffic engineering requirements. :) He is. It's not a matter of feasibility, but a matter of complexity. Introducing transport-layer features would be the equivalent of NAT: It's fine at home with your Linksys connected to a cable modem, but it's a nightmare in the enterprise. Michel. From owner-multi6@ops.ietf.org Thu Oct 24 12:23:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14602 for ; Thu, 24 Oct 2002 12:23:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184knU-000Fo9-00 for multi6-data@psg.com; Thu, 24 Oct 2002 09:25:24 -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.36 #2) id 184knK-000Fmi-01 for multi6@ops.ietf.org; Thu, 24 Oct 2002 09:25:14 -0700 content-class: urn:content-classes:message Subject: RE: Recommendation v Requirements [Re: The state of IPv6 multihoming development Date: Thu, 24 Oct 2002 08:20:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3AD@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Recommendation v Requirements [Re: The state of IPv6 multihoming development Thread-Index: AcJ7TYUq1gE/AHEBQq64YjuKbaQuogAIi0vQ From: "Michel Py" To: "Iljitsch van Beijnum" , "RJ Atkinson" Cc: X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14602 > Iljitsch van Beijnum wrote: > Although nobody bothered to answer directly, it seems there > is consensus that the requirements can be accepted with some > small changes. Good. I am opposed to it as-is. The small changes are not going to change the outcome, and I am sure that I am not the only protocol developer that does not want his work to be cancelled because it does not meet the requirements. Peter, Itojun, and others: this is valid for you as well. Michel. From owner-multi6@ops.ietf.org Thu Oct 24 12:29:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14819 for ; Thu, 24 Oct 2002 12:29:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184kt2-000GM4-00 for multi6-data@psg.com; Thu, 24 Oct 2002 09:31:08 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 184kt0-000GLJ-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 09:31:06 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id MAA12288; Thu, 24 Oct 2002 12:31:02 -0400 Date: Thu, 24 Oct 2002 12:31:02 -0400 From: "J. Noel Chiappa" Message-Id: <200210241631.MAA12288@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Michel Py" >> If you have a host which is multi-homed to widely spaced >> points in the topology, there's unlikely to be a routing-based >> solution, i.e. one where that host has only one address. > I totally disagree I'd be interested to hear what your reason is for thinking that this statement is incorrect. > Would you be more specific about why you find this unlikely, and > what you call "widely spaced" (which I read as "from different PA > blocks). Addresses are a symptom of the problem, not the cause. By "widely spaced ... in the [connectivity] topology", I mean just that: the host H is connected to the Internet in two places, which are far apart in the connectivity graph. I.e. the shortest path between the two connection points (not through the host) is long. E.g. suppose this host is connectes to two local ISP's L1 and L2. Further suppose these are connected to upstream larger ISP's U1 and U2 (respectively). Further suppose that U1 and U2 don't peer near the points where the local ISP's connect to them. All hardly unlikely, but you've probably got at a 15-hop path, or something. No matter *what* kind of address you give the host (be it connectivity-based, or "provider-independent"), if one of the interfaces is down, the routing table at the midpoint of the path (i.e. where incoming traffic is going to have to decide which way to go, "left" or "right") is going to have to have a currently correct entry *for this specific host* if the traffic is going to get there. In other words, you have to have host routes, propogated over a wide scope (back to a major top-level ISP peering point, in the example above). This is not feasible. That's why I say "addresses are a symptom of the problem, not the cause", because the problem is the same no matter what kind of addressing scheme you are using. > There is a difference between the solution itself using multiple > addresses and each host using multiple addresses. If each host has to > use multiple addresses, I regret to report that Craig's statement is > not an opinion, but a fact. Any people that disagree with this and that > actually have renumbered a 1000+ subnet enterprise network, please > speak up Who's talking about (manually, I assume) renumbering a 1000+ subnet network? IPv6 hosts get the high bits of the globally-unique addresses from their routers, right? Why is it so hard/insecure to get two (or more) instead of one? Noel From owner-multi6@ops.ietf.org Thu Oct 24 12:49:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15370 for ; Thu, 24 Oct 2002 12:49:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184lCW-000HoE-00 for multi6-data@psg.com; Thu, 24 Oct 2002 09:51:16 -0700 Received: from ebola.psc.edu ([128.182.61.124] helo=localhost) by psg.com with esmtp (Exim 3.36 #2) id 184lCU-000HnZ-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 09:51:14 -0700 Received: from ebola.psc.edu (localhost [127.0.0.1]) by localhost (8.12.2/8.12.2) with ESMTP id g9OGor2O007278; Thu, 24 Oct 2002 12:50:55 -0400 (EDT) Date: Thu, 24 Oct 2002 12:50:53 -0400 From: "Michael H. Lambert" To: Michel Py cc: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Message-ID: <24522892.1035463851@ebola.psc.edu> In-Reply-To: <2B81403386729140A3A899A8B39B046405E3AC@server2000> References: <2B81403386729140A3A899A8B39B046405E3AC@server2000> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-8.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 24 October 2002 08:03 -0700 Michel Py wrote: [...] > Absolutely. It is clear that there is a place for both, and this WG has > been denying host-based solution in the misguided hunt for The Universal > Multihoming Solution. A PI solution is not the answer to everybody nor > is a host solution. My message to Peter Tattam and other people that > have designed host solutions is this: There is a place for what you are > doing, but also understand that it's not what everyone needs, and accept > the fact that your solution will have to coexist with something else. [...] Is this a fair assessment? There are three classes of multihomed leaf sites: 1) Entities, generally smaller ones, which can exist quite happily with multiple PA addresses (implying some degree of interchangeability among their providers), 2) Enterprises which require PI addresses either because they extend across multiple geographic areas (such as large corporations) or they connect to networks which are not interchangeable (such as universities with commodity and R&E connections) and 3) Regions which have the local topology to take advantage of geographically-based PI addresses. It seems as though most discussion has tried to shoehorn both 2) and 3) into the same category. I'm wondering if overall aggregation might be improved by giving these two classes separate PI space. 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 Thu Oct 24 13:21:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16555 for ; Thu, 24 Oct 2002 13:21:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184lgT-000K6P-00 for multi6-data@psg.com; Thu, 24 Oct 2002 10:22:13 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 184lgP-000K68-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 10:22:09 -0700 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 24 Oct 2002 10:22:09 -0700 Reply-To: From: "Tony Hain" To: "'Iljitsch van Beijnum'" Cc: Subject: RE: The state of IPv6 multihoming development Date: Thu, 24 Oct 2002 10:22:02 -0700 Message-ID: <034901c27b81$de9b42f0$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021024105714.N14896-100000@sequoia.muada.com> X-Spam-Status: No, hits=-5.0 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA16555 Iljitsch van Beijnum wrote: > > > Actually holes in PA space is perfectly fine for the > network, as you > > > can filter the more specifics and still have connectivity. > > > This statement is self contradictory. > > How so? By definition, when there is filtering, connectivity is being intentionally broken. > > > > However, it is not so great for the > > > organization using the addresses since this doesn't address all > > > failure modes. > > > The point I was making about punching holes in PA is that the more > > influential organizations will get the full prefix routed globally. > > So then the question becomes: how do we limit the growth in > organizational influentialness? :-) You can't, so it becomes how do we scale to deal with them? > > This is bad for operators as they have to make complex > filters. Also, this "solution" still requires renumbering. This depends on the mechanism that is selected. > > > > This could be done by having several instances of > > > this address space and have two places that would otherwise be > > > aggregated together sit in a different instance. By rotating the > > > axes and limiting everything to (say) from -60 to +60 degrees you > > > eliminate the pole problem. > > > I played with rotating the axis, but the only thing that > made Europe > > contiguous was to put the origin on a 22.5 degree mark. > > That would be shifting. What I mean is have at least three > instances, one with the poles at 90 north/south, one with the > "poles" at the equator at the 0 and 180 meridians and one > with the poles at the equator at the 90 and 270 meridians. > Then you only need to go upto 45 degrees and still every part > of the world would be covered by two instances. This means > 1.5 times more address space used, but 2 times as much usable > in the non-polar regions. What is the real gain?? If it is only 2x, the size of the grid shrinks from 10x10m to 7x7m. > > > > Still, there is one unanswered question: what problem is > solved by > > > having such a close relationship between geography and address > > > space? > > > I was not trying to force any particular alignment. The goals were: > > Uses current BGP protocol. Aggregate the > basement-multi-homer, while > > recognizing the CNN's of the world will always get a full prefix > > announced. Decouple the scale of aggregation, so it becomes > a regional > > decision. Make it simple to derive by basing it on a globally > > consistent reference. > > You fail to address my question. This scheme uses an > incredible amount of address space, But you were arguing for using 1.5x the space??? > but still manages to come > up short in very densely populated areas. This is BS... Show me a space where 128 /64's per vertical meter is insufficient. > The aggregation > properties are relatively poor. Based on what criterion? For the 200+ existing exchanges it would appear to reduce the scope of the flat routed parts of the table. Also, the bit interleave allows for varying aggregation scale based on local need. > So what is it that makes all > these downsides worth it? Show me a plan that works better and is simple enough to really deploy. > > Basing a geographical address allocation scheme on population > (x addresses per person) rather than geography (x addresses per square > kilometer) makes more sense, as long as you're not going to > use IP addresses to aim your microwave antenna or something like that. > PA is an appropriate technology for X addr/person. What we are discussing here is how we deal with multi-homed entities. What that requires is a defined way to abstract without loss of utility. Tony From owner-multi6@ops.ietf.org Thu Oct 24 13:25:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16706 for ; Thu, 24 Oct 2002 13:25:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184ll8-000KRe-00 for multi6-data@psg.com; Thu, 24 Oct 2002 10:27:02 -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.36 #2) id 184ll6-000KQN-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 10:27:01 -0700 content-class: urn:content-classes:message Subject: RE: Recommendation v Requirements [Re: The state of IPv6 multihomingdevelopment Date: Thu, 24 Oct 2002 10:27:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B04640BD233@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Recommendation v Requirements [Re: The state of IPv6 multihomingdevelopment Thread-Index: AcJ7f/GqqyQPKl6qQpWSXKTt2ibmfwAAo2GQ From: "Michel Py" To: "Randy Bush" , "Brian E Carpenter" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA16706 > Randy Bush wrote: > i recommend worrying about the content and the > progress far more than about the title. Tried that, a year ago. Progress since then: zero. Michel. From owner-multi6@ops.ietf.org Thu Oct 24 13:52:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17424 for ; Thu, 24 Oct 2002 13:52:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184mAV-000MMR-00 for multi6-data@psg.com; Thu, 24 Oct 2002 10:53:15 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 184mAT-000MME-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 10:53:13 -0700 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 24 Oct 2002 10:53:19 -0700 Reply-To: From: "Tony Hain" To: "'J. Noel Chiappa'" , Subject: RE: The state of IPv6 multihoming development Date: Thu, 24 Oct 2002 10:53:12 -0700 Message-ID: <034e01c27b86$38c872d0$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200210241620.MAA12189@ginger.lcs.mit.edu> X-Spam-Status: No, hits=-4.3 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA17424 J. Noel Chiappa wrote: > ... > Look, there are network designs which allow > connectivity-dependent addressing schemes which are *not* > provider-dependent. > > E.g. if a (large enough) bunch of customers band together and > create an exchange, which buys service from multiple ISP's, > and which is given an address which is visible over the same > scope as those ISP's, and the customers are addressed as part > of that exchange, you meet the policy goal (being able to > change providers) *without* so-called "PI" addresses. But the > addresses are still connectivity-based. > So we are arguing the same point, so this is simple semantics. I was simply using a global algorithmic mapping to allocate the prefix for the exchange. > So there's one really good reason to discard this bogus > "provider-dependent" and "provider-independent" terminology - > because there are cases in which it > *doesn't* align with the underlying technical issue. > Fine, we need to come up with a paragraph that clearly gets the point across. > > Perhaps if people understood the underlying technical issues > better this discussion would be more fruitful. Using > terminology which *accurately* conveys the underlying > fundamental technical limitations, rather than their policy > goals, is a good place to start. Both apply, so we just need to be very clear. Tony > > Noel > From owner-multi6@ops.ietf.org Thu Oct 24 14:28:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18692 for ; Thu, 24 Oct 2002 14:28:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184mjg-000P46-00 for multi6-data@psg.com; Thu, 24 Oct 2002 11:29:36 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184mje-000P3t-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 11:29:34 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9OIRuX23543; Thu, 24 Oct 2002 20:27:57 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Oct 2002 20:27:56 +0200 (CEST) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <200210241620.MAA12189@ginger.lcs.mit.edu> Message-ID: <20021024202432.I14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 24 Oct 2002, J. Noel Chiappa wrote: > E.g. if a (large enough) bunch of customers band together and create an > exchange, which buys service from multiple ISP's, and which is given an > address which is visible over the same scope as those ISP's, and the > customers are addressed as part of that exchange, you meet the policy goal > (being able to change providers) *without* so-called "PI" addresses. But the > addresses are still connectivity-based. Semantics. The exchange would be the "provider" here. BTW, this looks an awful lot like geographical addressing and aggregating. Now if we virtualize the exchange that saves a lot of iron. From owner-multi6@ops.ietf.org Thu Oct 24 14:31:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18878 for ; Thu, 24 Oct 2002 14:31:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184mmv-000PCV-00 for multi6-data@psg.com; Thu, 24 Oct 2002 11:32:57 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184mmt-000PC4-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 11:32:55 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9OIVHl23550; Thu, 24 Oct 2002 20:31:17 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Oct 2002 20:31:17 +0200 (CEST) From: Iljitsch van Beijnum To: Masataka Ohta cc: Multi6 Working Group Subject: Re: The state of IPv6 multihoming development In-Reply-To: <200210241557.AAA03593@necom830.hpcl.titech.ac.jp> Message-ID: <20021024202819.T14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 25 Oct 2002, Masataka Ohta wrote: > That's one of the reason why reduction of DFZ is important for > the high speed Internet with quick routing table look up. The IRTF doesn't agree: http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-groupa-00.txt 4.1 Forwarding Table Optimization We believe that it is not necessary for the architecture to minimize the size of the forwarding tables (FIBS). Current memory sizes, speeds, and prices, along with processor and ASIC capabilities allow forwarding tables to be very large, O(E6), and fast (100M lookups/second) tables to be built with little difficulty. From owner-multi6@ops.ietf.org Thu Oct 24 15:15:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20284 for ; Thu, 24 Oct 2002 15:15:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184nT2-0002a1-00 for multi6-data@psg.com; Thu, 24 Oct 2002 12:16:28 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184nT0-0002Zk-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 12:16:26 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9OJEph23608 for ; Thu, 24 Oct 2002 21:14:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Oct 2002 21:14:51 +0200 (CEST) From: Iljitsch van Beijnum To: Subject: Transport multihoming Message-ID: <20021024210103.E14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Greg, Peter, As I see it, the reason to have the multihoming functionality inside one or more transport protocols is that the transport layer has end-to-end knowledge that makes it possible to make better multihoming decisions. Would it be possible to have a modified TCP talk to a non-modified TCP through some kind of "mudem" (multihomer/demultihomer), without loss of the core multihoming functionality, and without the "mudem" having to keep long-term state? This would create a much more attractive deployment path as people can choose to either upgrade hosts or put them behind a box to provide the multihoming functionality. It also makes it possible to move the multihoming decision making to a place where it can be better controlled if this is desired. Iljitsch (or just call me dr. Frankenstein) From owner-multi6@ops.ietf.org Thu Oct 24 15:24:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20541 for ; Thu, 24 Oct 2002 15:24:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184ncP-0003LG-00 for multi6-data@psg.com; Thu, 24 Oct 2002 12:26:09 -0700 Received: from elle.sprintlink.net ([199.0.234.34] helo=iscserv1.res.sprintlink.net) by psg.com with esmtp (Exim 3.36 #2) id 184ncN-0003KV-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 12:26:07 -0700 Received: from localhost (rrockell@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id PAA18798; Thu, 24 Oct 2002 15:27:42 -0400 (EDT) X-Authentication-Warning: iscserv1.res.sprintlink.net: rrockell owned process doing -bs Date: Thu, 24 Oct 2002 15:27:42 -0400 (EDT) From: "Robert J. Rockell" X-X-Sender: To: Iljitsch van Beijnum cc: Masataka Ohta , Multi6 Working Group Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021024202819.T14896-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_00_01, USER_AGENT_PINE,X_AUTH_WARNING version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Please allow me to possibly mis-use other portions of this draft. If you (all) will allow me to counterpoint based on the same draft: [...] 1. The computational power and memory sizes required to execute the routing protocol software and to contain the tables must be less than the growth in hardware capabilities described by Moore's Law, which has hardware capabilities doubling every 18 months or so. Other observations indicate that memory sizes double every 2 years or so. 3. The speeds of high-speed RAMS (SRAMs, used for caches and the like) are growing, though slowly. Because of their use in caches and other very specific applications, these RAMs tend to be small, a few megabits, and the size of these RAMs is not increasing very rapidly. On the other hand, the speed of "large" memories (DRAMs) is increasing even slower than that for the high speed RAMS. This is because the development of these RAMs is driven by the PC market, where size is very important, and low speed can be made up for by better caches. Not necessarily affecting "geo for now", but not proven either way. Definitely a hint against CIDR-izing IPv6. 3.5: [...] Some have proposed that a geographic addressing scheme be used, requiring exchange points to be situated within each geographic 'region'. There are many reasons why we believe this to be a bad approach, but those arguments are irrelevant. The main issue is that the routing architecture should not presume a specific network structure. I didn't write it. Send flames to IRTF :) Another useful quote that is not necessarily germane to this thread, but indeed a consideration is: 3.17 Simplicity The architecture MUST be simple enough so that Radia Perlman can explain all the important concepts in less than an hour. The requirement is that the routing architecture be kept as simple as possible. This requires careful evaluation of possible features and functions with a merciless weeding out of those that "might be nice". Possibly germane to some proposals: 3.20 Stand-alone The routing architecture and protocols MUST NOT rely on other components of the Internet (such as DNS) for their correct operation. Routing is the fundamental process by which data [...] so 8+8 is probably out too... So we are back to square one, based on this document... ? Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- On Thu, 24 Oct 2002, Iljitsch van Beijnum wrote: ->On Fri, 25 Oct 2002, Masataka Ohta wrote: -> ->> That's one of the reason why reduction of DFZ is important for ->> the high speed Internet with quick routing table look up. -> ->The IRTF doesn't agree: -> ->http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-groupa-00.txt -> ->4.1 Forwarding Table Optimization -> -> We believe that it is not necessary for the architecture to -> minimize the size of the forwarding tables (FIBS). Current -> memory sizes, speeds, and prices, along with processor and ASIC -> capabilities allow forwarding tables to be very large, O(E6), -> and fast (100M lookups/second) tables to be built with little -> difficulty. -> -> From owner-multi6@ops.ietf.org Thu Oct 24 15:32:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20749 for ; Thu, 24 Oct 2002 15:32:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184nkI-0003zG-00 for multi6-data@psg.com; Thu, 24 Oct 2002 12:34:18 -0700 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 184nkG-0003un-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 12:34:16 -0700 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9OJXaxF008028; Thu, 24 Oct 2002 12:33:36 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9OJXcd8020442; Thu, 24 Oct 2002 12:33:38 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA03275; Thu, 24 Oct 2002 12:33:37 -0700 (PDT) Date: Thu, 24 Oct 2002 14:33:37 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Michel Py cc: "J. Noel Chiappa" , Subject: RE: The state of IPv6 multihoming development In-Reply-To: <2B81403386729140A3A899A8B39B046405E3A8@server2000> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 23 Oct 2002, Michel Py wrote: > However, a solution that involves multiple addresses at the edge of the > organization but single addresses on the internal network and hosts does > not look unfeasible to me (Craig, please comment). From a routing perspective, this doesn't look unfeasible. Care must be given to those applications which currently embed end-to-end addresses in the upper-layer payload (H.323); this type of solution would imply a knowledge base in the routing infrastructure to perform embedded translation or an acceptance that these applications do not work. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Thu Oct 24 15:34:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20824 for ; Thu, 24 Oct 2002 15:34:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184nmO-0004D1-00 for multi6-data@psg.com; Thu, 24 Oct 2002 12:36:28 -0700 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.36 #2) id 184nmM-00046t-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 12:36:26 -0700 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9OJZoIm022727; Thu, 24 Oct 2002 12:35:50 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9OJZo15022445; Thu, 24 Oct 2002 12:35:50 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA05476; Thu, 24 Oct 2002 12:35:49 -0700 (PDT) Date: Thu, 24 Oct 2002 14:35:49 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Shane Kerr cc: "J. Noel Chiappa" , Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021024080418.GB29728@x17.ripe.net> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 24 Oct 2002, Shane Kerr wrote: > Even if he's right, I think he's wrong to argue against end-point > solutions based on multiple addresses. Given the current > understanding of the problem and the approaches that have been > outlined, doesn't it seem like wishful thinking to want One True > Multihoming strategy? For small sites, binding multiple PA addresses > into a single end-point seems like a straightforward, cheap, and > effective solution. I'm not arguing against multi-PA for small organizations. I can anticipate it working for the small sites with less than 100 segments or so (actual number may vary). Some limitations still exist -- for example, the deprecation of all of the subnets within a prefix when the link serving that prefix goes away (or using a NAT function). I do know, however, that it isn't reasonable in a network with tens of thousands of segments. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Thu Oct 24 15:49:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21110 for ; Thu, 24 Oct 2002 15:49:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184o0X-0005Lx-00 for multi6-data@psg.com; Thu, 24 Oct 2002 12:51:05 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184o0V-0005L8-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 12:51:03 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9OJnDO23672; Thu, 24 Oct 2002 21:49:13 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 24 Oct 2002 21:49:13 +0200 (CEST) From: Iljitsch van Beijnum To: "Craig A. Huegen" cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: <20021024214521.P14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 24 Oct 2002, Craig A. Huegen wrote: > > However, a solution that involves multiple addresses at the edge of the > > organization but single addresses on the internal network and hosts does > > not look unfeasible to me (Craig, please comment). > >From a routing perspective, this doesn't look unfeasible. Care must be > given to those applications which currently embed end-to-end addresses in > the upper-layer payload (H.323); this type of solution would imply a > knowledge base in the routing infrastructure to perform embedded > translation or an acceptance that these applications do not work. If there is a "primary" address known as such by all (the apps, transport layers at both ends and the onimous boxes in the middle) this shouldn't be a problem. As an enterprise, you'd want a good set of primary addresses anyway, because those would be the provider/connectivity independent ones. From owner-multi6@ops.ietf.org Thu Oct 24 16:11:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21710 for ; Thu, 24 Oct 2002 16:11:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184oMU-00074d-00 for multi6-data@psg.com; Thu, 24 Oct 2002 13:13:46 -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.36 #2) id 184oMQ-00074Q-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 13:13:42 -0700 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Thu, 24 Oct 2002 13:13:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B04640BD234@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ7lFTTDi80K6nCQ4Syg/rTXxHR9wABTi4g From: "Michel Py" To: "Robert J. Rockell" , "Iljitsch van Beijnum" Cc: "Masataka Ohta" , "Multi6 Working Group" X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA21710 > Rob Rockell wrote: > So we are back to square one, based on this > document...? I don't think so. This document is for routing. There is nothing that says that multihoming should be limited to routing, although it is clear that part of the solution will more than likely be a routing solution. Michel. From owner-multi6@ops.ietf.org Thu Oct 24 16:12:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21745 for ; Thu, 24 Oct 2002 16:12:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184oNN-00079K-00 for multi6-data@psg.com; Thu, 24 Oct 2002 13:14:41 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 184oNL-000794-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 13:14:39 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id HAA13208; Fri, 25 Oct 2002 07:14:32 +1100 (EST) Date: Fri, 25 Oct 2002 07:14:32 +1100 (EST) From: Peter Tattam To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: Transport multihoming In-Reply-To: <20021024210103.E14896-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 24 Oct 2002, Iljitsch van Beijnum wrote: > Greg, Peter, > > As I see it, the reason to have the multihoming functionality inside one > or more transport protocols is that the transport layer has end-to-end > knowledge that makes it possible to make better multihoming decisions. My recent thoughts are that it need not be tied directly to the TCP protocol, but can instead be done at the IP layer of the host stack. However the TCP and IP layers should be aware of each other in much the same way that PMTU is facilitated. If done that way, there would be benefits from caching the multihoming information and sharing it over several connections. Also because of the strong aggregation, the cached information would be able to build a multihoming hint tree more efficiently than would a flat list of IP addresses. For example, if a major link from one aggregator showed a problem, it would take provide a hint that all aggregations from that provider would be inaccessible and the stack could use this intelligence in advance. > > Would it be possible to have a modified TCP talk to a non-modified TCP > through some kind of "mudem" (multihomer/demultihomer), without loss of > the core multihoming functionality, and without the "mudem" having to > keep long-term state? Depends what you mean by long term. Please clarify. This is perhaps close to what I alluded to by a decoupling process. What is fundamental to a reliable working solution using my concepts is that if the prefix replacement is decoupled, it must still be done in a secure way so that protocols like TCP which might depend on address immutability can have an iron clad guarantee that the address selection is valid. It is clear that moving the process out of the host kernel enviromnent into an ancilliary processor environment would imply using some kind of secure control protocol to ensure that addresses are dealt with correctly, and this adds a degree of complication which I believe to be excessive. It is my conclusion then that it should be done on the host. This also has the advantage of distributing the processing and memory requirements for such a protocol away from the core of the internet which fit the requirement for being scalable. Careful thought needs to be given to huge servers which are likely to be servicing tens of thousands of connections though as the multihoming process could add some burden to servers of that calibre. It is perhaps sites like these that could benefit from decoupling the multihoming process in a controlled manner. I strong suggest that such multihoming be restricted to prefix replacement only, and not arbitrary address replacement, as there will be significant advantage in exploiting the implied tree structure imposed by the strong aggregation. > > This would create a much more attractive deployment path as people can > choose to either upgrade hosts or put them behind a box to provide the > multihoming functionality. > > It also makes it possible to move the multihoming decision making to a > place where it can be better controlled if this is desired. Yes, I see your reasoning, but only if the immutability of end point addressing and the prevention of connection hijacking can be guaranteed. > > Iljitsch (or just call me dr. Frankenstein) > > > 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 Oct 24 16:21:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22036 for ; Thu, 24 Oct 2002 16:21:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184oVc-0007oi-00 for multi6-data@psg.com; Thu, 24 Oct 2002 13:23:12 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 184oVa-0007oU-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 13:23:11 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id HAA13711; Fri, 25 Oct 2002 07:20:31 +1100 (EST) Date: Fri, 25 Oct 2002 07:20:31 +1100 (EST) From: Peter Tattam To: "Craig A. Huegen" cc: Michel Py , "J. Noel Chiappa" , multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 24 Oct 2002, Craig A. Huegen wrote: > On Wed, 23 Oct 2002, Michel Py wrote: > > > However, a solution that involves multiple addresses at the edge of the > > organization but single addresses on the internal network and hosts does > > not look unfeasible to me (Craig, please comment). > > >From a routing perspective, this doesn't look unfeasible. Care must be > given to those applications which currently embed end-to-end addresses in > the upper-layer payload (H.323); this type of solution would imply a > knowledge base in the routing infrastructure to perform embedded > translation or an acceptance that these applications do not work. This is fine if one can accept the level of insecurity within a site. WHat about sites that don't necessarily look like an edge router but rather a cloud with multiple entry points. You then have the possibility of a host not knowing which source address to select. Source address selection has been a much overlooked issue in the debate since most of the descussion seems to me to be focused on delivery. > > /cah > > --- > Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s > IT Transport, Network Technology & Design || || > Cisco Systems, Inc., 400 East Tasman Drive || || > San Jose, CA 95134, (408) 526-8104 |||| |||| > email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. > > > -- 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 Oct 24 19:35:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27019 for ; Thu, 24 Oct 2002 19:35:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184rVZ-000O5j-00 for multi6-data@psg.com; Thu, 24 Oct 2002 16:35:21 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 184rVU-000O3u-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 16:35:16 -0700 From: Masataka Ohta Message-Id: <200210242331.IAA06361@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA06361; Fri, 25 Oct 2002 08:30:50 +0859 Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021024180913.Y14896-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Oct 24, 2002 06:19:19 pm" To: Iljitsch van Beijnum Date: Fri, 25 Oct 2002 08:30:50 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > > > I figured the whole geographical aggregation thing was a step in the > > > right direction... > > > A problem is that such geographical aggregation can not properly > > handle multiple links between regions maintained by multiple entities. > > Regions aren't "maintained" by "entities". Oops, I mean links are maintained by entities. But, regions not maintained by a entity will naturally be partitioned into smaller regions, which makes the routing table explode. > > Another problem is that it is helpless for a partitioned geographical > > area. > > You can deaggregate. But automatic deaggregation is dangerous, so yes, > partitioning is bad. This means you must define your regions in such a > way that it is very unlikely that they will be partitioned internally, > from the rest of the network or from peers in the region. This makes it > hard to arrive at very small regions which in turn sets a practical > limit on the scalability of geographical aggregation. In theory, it can > scale to 1G multihomers. In practice, it won't be much fun anymore > beyond 25 - 100M. In theory and practice, it can scale to 100K. Masataka Ohta From owner-multi6@ops.ietf.org Thu Oct 24 19:43:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27177 for ; Thu, 24 Oct 2002 19:43:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184rfA-000Ouo-00 for multi6-data@psg.com; Thu, 24 Oct 2002 16:45:16 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 184rf8-000Ouc-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 16:45:14 -0700 From: Masataka Ohta Message-Id: <200210242334.IAA06440@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA06440; Fri, 25 Oct 2002 08:34:37 +0900 Subject: Re: Transport multihoming In-Reply-To: <20021024210103.E14896-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Oct 24, 2002 09:14:51 pm" To: Iljitsch van Beijnum Date: Fri, 25 Oct 2002 08:34:36 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; "Transport multihoming" is a wrong terminology. As long as multihoming is solved on end systems, it is irrelevent whether it is solved by transport or application layer. The separation between the transport and application layers is an end system local issue and invisible from the network. See my expired draft (available in ML log) for further explanation. Masataka Ohta From owner-multi6@ops.ietf.org Thu Oct 24 19:53:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27390 for ; Thu, 24 Oct 2002 19:53:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184rp7-000Prp-00 for multi6-data@psg.com; Thu, 24 Oct 2002 16:55:33 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 184rp4-000PrT-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 16:55:31 -0700 From: Masataka Ohta Message-Id: <200210242351.IAA06554@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA06554; Fri, 25 Oct 2002 08:51:34 +0900 Subject: Re: The state of IPv6 multihoming development In-Reply-To: from "Craig A. Huegen" at "Oct 24, 2002 02:33:37 pm" To: "Craig A. Huegen" Date: Fri, 25 Oct 2002 08:51:33 +0859 () CC: Michel Py , "J. Noel Chiappa" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Huegen; > > However, a solution that involves multiple addresses at the edge of the > > organization but single addresses on the internal network and hosts does > > not look unfeasible to me (Craig, please comment). > > >From a routing perspective, this doesn't look unfeasible. Care must be > given to those applications which currently embed end-to-end addresses in > the upper-layer payload (H.323); this type of solution would imply a > knowledge base in the routing infrastructure to perform embedded > translation or an acceptance that these applications do not work. According to the end to end principle, routing infrastructure MUST be dumb that there is no room for perspective. If an address of an end system is known, reverse and forward DNS look up gives all the addresses of the end system. It is an end system local issue having nothing to do with the routing infrastructure. People are free not to register the information to DNS, though they can not enjoy robust internet connectivity with multihoming. Masataka Ohta From owner-multi6@ops.ietf.org Thu Oct 24 19:54:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27406 for ; Thu, 24 Oct 2002 19:54:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184roy-000PrO-00 for multi6-data@psg.com; Thu, 24 Oct 2002 16:55:24 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 184row-000PrC-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 16:55:22 -0700 From: Masataka Ohta Message-Id: <200210242345.IAA06532@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA06532; Fri, 25 Oct 2002 08:45:06 +0900 Subject: Re: The state of IPv6 multihoming development In-Reply-To: from "Robert J. Rockell" at "Oct 24, 2002 03:27:42 pm" To: "Robert J. Rockell" Date: Fri, 25 Oct 2002 08:45:05 +0859 () CC: Iljitsch van Beijnum , Multi6 Working Group X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Rob Rockell; > Possibly germane to some proposals: > > 3.20 Stand-alone > > > The routing architecture and protocols MUST NOT rely on other > components of the Internet (such as DNS) for their correct > operation. Routing is the fundamental process by which data [...] > > so 8+8 is probably out too... Could you elaborate? Maybe, GSE uses DNS internally in the network. But, GSE is a poor example of 8+8 and hopeless. 8+8 with end to end multihoming resolves DNS purely inside end systems, of course. Masataka Ohta From owner-multi6@ops.ietf.org Thu Oct 24 20:22:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27893 for ; Thu, 24 Oct 2002 20:22:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184sGH-0001sU-00 for multi6-data@psg.com; Thu, 24 Oct 2002 17:23:37 -0700 Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by psg.com with esmtp (Exim 3.36 #2) id 184sGG-0001r8-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 17:23:36 -0700 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g9P0Mxot008157; Thu, 24 Oct 2002 17:22:59 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9P0MxWn009936; Thu, 24 Oct 2002 17:22:59 -0700 (PDT) Received: from dhcp-171-71-17-203.cisco.com (dhcp-171-71-17-203.cisco.com [171.71.17.203]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA22338; Thu, 24 Oct 2002 17:22:57 -0700 (PDT) Date: Thu, 24 Oct 2002 19:22:58 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Masataka Ohta cc: Michel Py , "J. Noel Chiappa" , Subject: Re: The state of IPv6 multihoming development In-Reply-To: <200210242351.IAA06554@necom830.hpcl.titech.ac.jp> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 25 Oct 2002, Masataka Ohta wrote: > If an address of an end system is known, reverse and forward DNS look > up gives all the addresses of the end system. As an enterprise network operator I do not have reasonable policy controls when path selection is performed by the originating host's selection of source and destination addresses from the system's set of source addresses and the destination's set of DNS-registered addresses. DNS as a routing policy specification language seems inappropriate to me. I can accept some interaction between the host and network infrastructure in order to determine the best path to use to a multi-address destination host; however, we still run into the support issues associated with applying and maintaining several, multi-PA prefixes to tens of thousands of subnets. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Thu Oct 24 20:23:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27924 for ; Thu, 24 Oct 2002 20:23:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184sHz-000216-00 for multi6-data@psg.com; Thu, 24 Oct 2002 17:25:23 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 184sHx-00020u-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 17:25:21 -0700 From: Masataka Ohta Message-Id: <200210250015.JAA07075@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA07075; Fri, 25 Oct 2002 09:15:18 +0900 Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021024202819.T14896-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Oct 24, 2002 08:31:17 pm" To: Iljitsch van Beijnum Date: Fri, 25 Oct 2002 09:15:13 +0859 () CC: Multi6 Working Group X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > > That's one of the reason why reduction of DFZ is important for > > the high speed Internet with quick routing table look up. > > The IRTF doesn't agree: > > http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-groupa-00.txt > > 4.1 Forwarding Table Optimization > > We believe that it is not necessary for the architecture to > minimize the size of the forwarding tables (FIBS). Current > memory sizes, speeds, and prices, along with processor and ASIC > capabilities allow forwarding tables to be very large, O(E6), > and fast (100M lookups/second) tables to be built with little > difficulty. 1M entry with 100M lookup per second may be possible someday, if the 1M entry memory and core logic of routers be put into a single chip. However, the statement is politically distorted. The reality is that, if we don't solve multihoming issue, 1M is small. Moverover, 100M lookups/second is slow for terabit networking. If we use multiple chips, we must accept that inter-chip communication has large overhead, which means it is slow and costs a lot. High performance routing is still possible with parallelism, which means a lot of wiring and, thus, a lot more cost. Masataka Ohta From owner-multi6@ops.ietf.org Thu Oct 24 20:42:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28425 for ; Thu, 24 Oct 2002 20:42:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184sa7-0003H2-00 for multi6-data@psg.com; Thu, 24 Oct 2002 17:44:07 -0700 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net ident=1525-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-take-this-and-log-it!) by psg.com with esmtp (Exim 3.36 #2) id 184sa5-0003Go-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 17:44:05 -0700 Received: by ab.use.net (Postfix, from userid 3005) id 0D1C0AA6; Fri, 25 Oct 2002 00:44:03 +0000 (GMT) To: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development Message-Id: <20021025004403.0D1C0AA6@ab.use.net> Date: Fri, 25 Oct 2002 00:44:03 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=0.6 required=5.0 tests=SHORT_RECEIVED_LINE,SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > The IRTF doesn't agree: > > http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-groupa-00.txt Requirements Group A no more represents the formal position of the IRTF than multi6 represents the formal position of the IETF. The former is roughly analogous to a working group within the Routing Research Group, which is very roughly analogous to an IETF area. I am very glad that you are reading the documents, and the editor is planning an update of this particular draft, and certainly would appreciate comments on that (or even on the one whose URL is above), should you choose to make them. However, there is a draft here in this wg which could use some comments too (hint, hint, hint). Sean. From owner-multi6@ops.ietf.org Thu Oct 24 20:43:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28441 for ; Thu, 24 Oct 2002 20:43:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184sbU-0003Pb-00 for multi6-data@psg.com; Thu, 24 Oct 2002 17:45:32 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 184sbS-0003PO-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 17:45:30 -0700 From: Masataka Ohta Message-Id: <200210250042.JAA07359@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA07359; Fri, 25 Oct 2002 09:41:50 +0859 Subject: Re: The state of IPv6 multihoming development In-Reply-To: from "Craig A. Huegen" at "Oct 24, 2002 07:22:58 pm" To: "Craig A. Huegen" Date: Fri, 25 Oct 2002 09:41:49 +0859 () CC: Michel Py , "J. Noel Chiappa" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Huegen; > > If an address of an end system is known, reverse and forward DNS look > > up gives all the addresses of the end system. > > As an enterprise network operator I do not have reasonable policy controls > when path selection is performed by the originating host's selection of > source and destination addresses from the system's set of source addresses > and the destination's set of DNS-registered addresses. > > DNS as a routing policy specification language seems inappropriate to me. Your assumption that the originating host source and destination for path selection is self contradictory. Originating host can control forward path with proper selection of destination. There is no such issue of source address selection. > I can accept some interaction between the host and network infrastructure > in order to determine the best path to use to a multi-address destination > host; however, we still run into the support issues associated with > applying and maintaining several, multi-PA prefixes to tens of thousands > of subnets. In draft-ohta-e2e-multihoming-02.txt, I wrote: Once a full routing table is available on all the end systems, it is easy for the end systems try all the destination addresses, from the most and to the least favorable ones, based on the routing metric. Note that end to end multihoming works with the separation between inter domain BGP and intra domain routing protocols, if BGP routers, based on domain policy, assign external routes preference values (metric) of intra domain routing protocols. All we need is a RIP-like mechanism to distribute global routing table with proper metric to all the hosts, to let the hosts control forward pathes with proper selection of destinations. Note that dumb hosts relying on intelligent default routers are the first step for intelligent networking and is a major design flaw of IPv6. Masataka Ohta From owner-multi6@ops.ietf.org Fri Oct 25 02:48:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14228 for ; Fri, 25 Oct 2002 02:48:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184yHf-0006AV-00 for multi6-data@psg.com; Thu, 24 Oct 2002 23:49:27 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184yHd-0006AJ-00 for multi6@ops.ietf.org; Thu, 24 Oct 2002 23:49:25 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9P6lhP25075; Fri, 25 Oct 2002 08:47:43 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 25 Oct 2002 08:47:43 +0200 (CEST) From: Iljitsch van Beijnum To: Masataka Ohta cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: <200210242331.IAA06361@necom830.hpcl.titech.ac.jp> Message-ID: <20021025084630.B14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 25 Oct 2002, Masataka Ohta wrote: > > In theory, it can > > scale to 1G multihomers. In practice, it won't be much fun anymore > > beyond 25 - 100M. > In theory and practice, it can scale to 100K. What am I, stupid? I don't need to take this crap. Go irritate someone else. From owner-multi6@ops.ietf.org Fri Oct 25 03:06:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14467 for ; Fri, 25 Oct 2002 03:06:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184yZQ-0007wV-00 for multi6-data@psg.com; Fri, 25 Oct 2002 00:07:48 -0700 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 184yZM-0007vo-00 for multi6@ops.ietf.org; Fri, 25 Oct 2002 00:07:44 -0700 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id E20EB23C3A; Thu, 24 Oct 2002 03:14:05 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9P77DiI028465; Fri, 25 Oct 2002 00:07:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: The state of IPv6 multihoming development Date: Fri, 25 Oct 2002 00:07:12 -0700 Message-ID: Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ7vUJdknKMqX0hSqSaOKc88kKZeQAN5rBQ From: "Tony Li" To: "Craig A. Huegen" , "Masataka Ohta" Cc: "Michel Py" , "J. Noel Chiappa" , X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA14467 | > If an address of an end system is known, reverse and | forward DNS look | > up gives all the addresses of the end system. | | As an enterprise network operator I do not have reasonable | policy controls | when path selection is performed by the originating host's | selection of | source and destination addresses from the system's set of | source addresses | and the destination's set of DNS-registered addresses. | | DNS as a routing policy specification language seems | inappropriate to me. A fine way of architecting this would be to have the host request routing preferences from the enterprise's border gateway. Of course, if the enterprise DNS server was colocated with the gateway, it could massage this as part of the response. | I can accept some interaction between the host and network | infrastructure | in order to determine the best path to use to a | multi-address destination | host; however, we still run into the support issues associated with | applying and maintaining several, multi-PA prefixes to tens | of thousands | of subnets. Would you feel this way if you could simply maintain the prefixes in the border gateway? Tony From owner-multi6@ops.ietf.org Fri Oct 25 03:18:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14715 for ; Fri, 25 Oct 2002 03:18:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184yl6-0008t3-00 for multi6-data@psg.com; Fri, 25 Oct 2002 00:19:52 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 184yl4-0008sr-00 for multi6@ops.ietf.org; Fri, 25 Oct 2002 00:19:51 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9P7I9T25141; Fri, 25 Oct 2002 09:18:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 25 Oct 2002 09:18:09 +0200 (CEST) From: Iljitsch van Beijnum To: Sean Doran cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: <20021025004403.0D1C0AA6@ab.use.net> Message-ID: <20021025090122.Y14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_05_08 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 25 Oct 2002, Sean Doran wrote: > > The IRTF doesn't agree: > > http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-groupa-00.txt > Requirements Group A no more represents the formal position > of the IRTF than multi6 represents the formal position > of the IETF. Aaarghh, you're not going to let me get away with _any_ hyperbole, are you? > I am very glad that you are reading the documents, and > the editor is planning an update of this particular > draft, and certainly would appreciate comments on > that (or even on the one whose URL is above), > should you choose to make them. I don't know if I could forget about real-world concerns long enough to make useful suggestions... For instance, in theory I agree with the point that we shouldn't assume a network topology (so geography is out) but how much are we willing to pay for not assuming this? In the real there are interconnection points within 2000 km or so from well-connected locations for good reasons: it helps robustness, keeps speed of light delays in check and it's usually cheaper. So why not optimize for this, at least in the absense of something that is better in al regards? PS. Sorry about my last email but I really found that comment to be insulting, especially as it seems he didn't read the soon-to-be-draft that explains how it works. Iljitsch From owner-multi6@ops.ietf.org Fri Oct 25 08:35:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22658 for ; Fri, 25 Oct 2002 08:35:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1853hf-000BXV-00 for multi6-data@psg.com; Fri, 25 Oct 2002 05:36:39 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1853hc-000BWb-00 for multi6@ops.ietf.org; Fri, 25 Oct 2002 05:36:36 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9PCZ1f25647 for ; Fri, 25 Oct 2002 14:35:01 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 25 Oct 2002 14:35:00 +0200 (CEST) From: Iljitsch van Beijnum To: Subject: draft-ietf-multi6-multihoming-requirements-04.txt Message-ID: <20021025140820.X14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.7 required=5.0 tests=SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Ok, I've taken the 03 requirements and made some changes: 3.2.7 "within the IESG" removed (Tony Hain) 2 Normativity removed (Brian E Carpenter) "3.1.7 Alternate path visibility" added (Craig A. Huegen) 3.2.6 Added no cooperation with non-transit ISPs text (Craig A. Huegen) It is available for your perusal at http://www.muada.com/drafts/draft-ietf-multi6-multihoming-requirements-04.txt The most important difference with 03 is: The use of the words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may" and "optional" is not meant to be interpreted as described in RFC 2119 [4]. The words "should" and "must" and "required" should be interpreted to indicate the described functionality is very important, and should be included if at all possible. However, lacking the indicated functionality doesn't automatically remove a potential solution from consideration as it may be impossible to create a solution that completely satisfies all requirements. I think this is enough to make sure no solution will be killed over technicalities. Does this mean everyone is inagreement now? I assume the chairs will know what to do next? Iljitsch From owner-multi6@ops.ietf.org Fri Oct 25 13:56:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04625 for ; Fri, 25 Oct 2002 13:55:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1858hU-000PIR-00 for multi6-data@psg.com; Fri, 25 Oct 2002 10:56:48 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1858hS-000PIF-00 for multi6@ops.ietf.org; Fri, 25 Oct 2002 10:56:46 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9PHtAB26171 for ; Fri, 25 Oct 2002 19:55:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 25 Oct 2002 19:55:10 +0200 (CEST) From: Iljitsch van Beijnum To: Subject: Agenda for Atlanta Message-ID: <20021025193554.O14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk I've talked about putting things on the agenda for Atlanta before, and didn't receive much feedback. Here is what I propose: 1. Discussion of the requirements draft to see if there is consensus on it 2. Formalities that are necessary and/or possible to move the requirements along 3. Life after requirements: disussion of several parts of the solution space: a. transport protocol solutions b. tunnelling/aliasing solutions c. (new) routing protocol solutions (are there any?) d. "no changes" solutions 4. Life after the requirements: who is going to do what where, do we recharter? Sean, can you take care of this if you observe the necessary consensus? My main reason for wanting to discuss this in Atlanta is because it will give us the opportunity to get feedback from people that aren't on this list. Note that I didn't include in-depth discussions of proposed solutions. I think that's something best done in a smaller, less formal setting, preferably before the wg meeting itself, and hopefully after Atlanta we're done with the requirements so we can get some work done on this list. Iljitsch From owner-multi6@ops.ietf.org Fri Oct 25 16:22:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10186 for ; Fri, 25 Oct 2002 16:22:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185Azx-000Ji1-00 for multi6-data@psg.com; Fri, 25 Oct 2002 13:24:01 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 185Azt-000JhW-00 for multi6@ops.ietf.org; Fri, 25 Oct 2002 13:23:58 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9PKNTY26354; Fri, 25 Oct 2002 22:23:30 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 25 Oct 2002 22:23:28 +0200 (CEST) From: Iljitsch van Beijnum To: Peter Tattam cc: Subject: Re: Transport multihoming In-Reply-To: Message-ID: <20021025214554.A14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 25 Oct 2002, Peter Tattam wrote: > > As I see it, the reason to have the multihoming functionality inside one > > or more transport protocols is that the transport layer has end-to-end > > knowledge that makes it possible to make better multihoming decisions. > My recent thoughts are that it need not be tied directly to the TCP protocol, > but can instead be done at the IP layer of the host stack. However the TCP and > IP layers should be aware of each other in much the same way that PMTU is > facilitated. If done that way, there would be benefits from caching the > multihoming information and sharing it over several connections. This may or may not be desireable; the best way to handle this is probably some capabilities negotiation where each end tells the other: I can do this and this and that and it applies to: 1. All hosts living in this prefix: ... 2. This host 3. This protocol (TCP, UDP, ...) 4. This session > Also because > of the strong aggregation, the cached information would be able to build a > multihoming hint tree more efficiently than would a flat list of IP addresses. > For example, if a major link from one aggregator showed a problem, it would > take provide a hint that all aggregations from that provider would be > inaccessible and the stack could use this intelligence in advance. Hm, not sure if this would work very well as many different networks are behind a single PA block, some of which may be down, some of which may be operational. Also, I don't think many hosts will be donning a full routing table. However, it would be nice to have. I've been thinking about a protocol to share such information between hosts a while back, maybe this would be a nice addition later on. > > Would it be possible to have a modified TCP talk to a non-modified TCP > > through some kind of "mudem" (multihomer/demultihomer), without loss of > > the core multihoming functionality, and without the "mudem" having to > > keep long-term state? > Depends what you mean by long term. Please clarify. If a host sets up a connection that passes through a "mudem" this box may intercept the setup packet and do some capability negotiation with the other end. During this negotiation, there must be state in the mudem box. That would be acceptable. But when the session is established, it should be possible for the mudem to go down and come back up, or for another to take over, without breaking the session. So for running sessions, there must not be any state that can't be recovered by looking at the session = state that would last as long as the session = long time. > This is perhaps close to what I alluded to by a decoupling process. What is > fundamental to a reliable working solution using my concepts is that if the > prefix replacement is decoupled, it must still be done in a secure way so that > protocols like TCP which might depend on address immutability can have an iron > clad guarantee that the address selection is valid. I'm not sure what kind of bad things you want to protect against. If someone has full access to the TCP packets, there is nothing you can do anyway. (Other than SSL/IPSec, that is, but then they can still break the session.) > It is clear that moving the process out of the host kernel enviromnent into an > ancilliary processor environment would imply using some kind of secure control > protocol to ensure that addresses are dealt with correctly, and this adds a > degree of complication which I believe to be excessive. Hm, there is one thing that would be bad: a host thinks it talks with host X, while in fact it talks to host Y. But that could happen with NAT or some other man-in-the-middle thingy anyway, so is it worth the trouble protecting against this? We could build something into the protocol but obviously a corrupted multihoming processing box wouldn't necessarily implement this and the fact that you _don't_ see such a box doesn't mean anything. > I strong suggest that such multihoming be restricted to prefix replacement > only, and not arbitrary address replacement, as there will be significant > advantage in exploiting the implied tree structure imposed by the strong > aggregation. I think it would be good to be able to replace the full address, that way everyone can use it, no matter how limited their connectivity. What I envision is an IP option that makes it possible to negotiate capabilities at the start of a / the first session. This option can either be added: 1. by the transport protocol without involvement from the IP layer 2. by the IP layer without involvement from the transport protocol 3. by the IP layer at the request of the transport protocol (= we need to extend the interface) 4. by some external entity Which of 1 - 3 would you say is best? Don't forget this will probably have to be implemented for several transport protocols. It would of course also be possible to do this in a TCP option, but that complicates things like the TCP checksum in the case of 4 and doesn't address non-TCP protocols. Iljitsch From owner-multi6@ops.ietf.org Fri Oct 25 16:38:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10862 for ; Fri, 25 Oct 2002 16:38:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185BFn-000KaS-00 for multi6-data@psg.com; Fri, 25 Oct 2002 13:40:23 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.36 #2) id 185BFk-000KZY-00 for multi6@ops.ietf.org; Fri, 25 Oct 2002 13:40:21 -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 QAA22807; Fri, 25 Oct 2002 16:39:57 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id QAA11446; Fri, 25 Oct 2002 16:39:49 -0400 (EDT) Date: Fri, 25 Oct 2002 16:39:48 -0400 (EDT) From: Greg Maxwell To: Iljitsch van Beijnum cc: Subject: Re: Transport multihoming In-Reply-To: <20021024210103.E14896-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 24 Oct 2002, Iljitsch van Beijnum wrote: > Greg, Peter, > > As I see it, the reason to have the multihoming functionality inside one > or more transport protocols is that the transport layer has end-to-end > knowledge that makes it possible to make better multihoming decisions. > > Would it be possible to have a modified TCP talk to a non-modified TCP > through some kind of "mudem" (multihomer/demultihomer), without loss of > the core multihoming functionality, and without the "mudem" having to > keep long-term state? > > This would create a much more attractive deployment path as people can > choose to either upgrade hosts or put them behind a box to provide the > multihoming functionality. > > It also makes it possible to move the multihoming decision making to a > place where it can be better controlled if this is desired. I could imagine a TCP extension that could interoperate with a translation device that could handle adding the functionality of the extension to all the non-supported hosts behind it. /[network]\ /[old host] [enhanced host] - [router] [router] - [magic] - [old host] [magic]/ \[network]/ [old host] - / The magic host would have to see all the traffic (no wraparound paths), and I'd have to put a lot of thought into figuring out if it could be done without tracking state in the magic host (initial though is, no, not without an unreasonable amount of overhead). This would represent a layering violation, but no worse then nat. There are a few complications.. If one link was down, and the locator service (DNS) was not TLM (transport layer multihoming) aware, there would be complications in forming an initial connection. From owner-multi6@ops.ietf.org Fri Oct 25 18:04:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13518 for ; Fri, 25 Oct 2002 18:04:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185CaX-000P2l-00 for multi6-data@psg.com; Fri, 25 Oct 2002 15:05:53 -0700 Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by psg.com with esmtp (Exim 3.36 #2) id 185CaV-000P2F-00 for multi6@ops.ietf.org; Fri, 25 Oct 2002 15:05:51 -0700 Received: from chuegen-sun.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9PM5CLb029146; Fri, 25 Oct 2002 18:05:12 -0400 (EDT) Received: from localhost (chuegen@localhost) by chuegen-sun.cisco.com (8.11.6+Sun/8.11.6) with ESMTP id g9PM4wA06935; Fri, 25 Oct 2002 15:04:58 -0700 (PDT) X-Authentication-Warning: chuegen-sun.cisco.com: chuegen owned process doing -bs Date: Fri, 25 Oct 2002 15:04:58 -0700 (PDT) From: "Craig A. Huegen" To: Tony Li cc: Masataka Ohta , Michel Py , "J. Noel Chiappa" , Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.9 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 25 Oct 2002, Tony Li wrote: > | host; however, we still run into the support issues associated with > | applying and maintaining several, multi-PA prefixes to tens > | of thousands > | of subnets. > > Would you feel this way if you could simply maintain the prefixes > in the border gateway? No. The open concern then becomes that of applications that carry addresses in the payload -- would border routers require a knowledge base of applications to translate a la IPv4 NAT? /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Fri Oct 25 19:09:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15082 for ; Fri, 25 Oct 2002 19:09:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185DaY-0002IJ-00 for multi6-data@psg.com; Fri, 25 Oct 2002 16:09:58 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 185DaV-0002I5-00 for multi6@ops.ietf.org; Fri, 25 Oct 2002 16:09:56 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9PN9Wj26580; Sat, 26 Oct 2002 01:09:32 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 26 Oct 2002 01:09:31 +0200 (CEST) From: Iljitsch van Beijnum To: Greg Maxwell cc: Subject: Re: Transport multihoming In-Reply-To: Message-ID: <20021026004205.A14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 25 Oct 2002, Greg Maxwell wrote: > The magic host would have to see all the traffic (no wraparound paths), > and I'd have to put a lot of thought into figuring out if it could be done > without tracking state in the magic host (initial though is, no, not > without an unreasonable amount of overhead). Restoring the destination address should be simple, if we require that a secondary destination address is recognizable as such: this would be a simple prefix replacement. However, it becomes more complicated when the source address changes. A translation box can't be configured with this information. So either we require the source to always include the original source address (so now we're tunnelling) or the magic box has to keep source remapping state. However, it should be possible to rebuild this state if the source includes the primary source address whenever it feels this is appropriate, for instance, in retransmissions, or when the magic box asks for this information because it isn't in the cache. > This would represent a layering violation, but no worse then nat. I'm not sure it would... If we define this functionality to be in IP and provide suitable new interfaces for TCP and other transport protocols to interact with it, we should be fine. If those darn implementers then decide it's easier to implement the whole thing in one go in TCP, well, that's not our fault. I think being able to take advantage of the end-to-end information that TCP has is worth a few minor infractions. > There are a few complications.. If one link was down, and the > locator service (DNS) was not TLM (transport layer multihoming) aware, > there would be complications in forming an initial connection. True. The simple solution would be to require the application to try alternate addresses. (Note that a host would then have four addresses: 1. primary address in prefix A, listed in DNS 2. secondary address in prefix B, dynamically discovered 3. primary address in prefix B, listed in DNS 4. secondary address in prefix A, dynamically discovered With just two addresses it would be impossible to easily determine when addresses should be translated. The client must be smart enough to try all addresses listed in the DNS, the magic box can't do this on behalf of the client unless the translation state is already cached. The other solution is that discovery of the alternate addresses happens out of band. This is what Michel's MHAP does. This has the advantage the primary address doesn't have to be reachable which in turn makes these addresses portable. Unfortunately, this out of band discovery is a tough nut to crack. From owner-multi6@ops.ietf.org Fri Oct 25 19:11:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15126 for ; Fri, 25 Oct 2002 19:11:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185Ddt-0002VJ-00 for multi6-data@psg.com; Fri, 25 Oct 2002 16:13:25 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 185Ddq-0002Uf-00 for multi6@ops.ietf.org; Fri, 25 Oct 2002 16:13:22 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id KAA08995; Sat, 26 Oct 2002 10:13:06 +1100 (EST) Date: Sat, 26 Oct 2002 10:13:06 +1100 (EST) From: Peter Tattam To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: Transport multihoming In-Reply-To: <20021025214554.A14896-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 25 Oct 2002, Iljitsch van Beijnum wrote: > On Fri, 25 Oct 2002, Peter Tattam wrote: > > > > As I see it, the reason to have the multihoming functionality inside one > > > or more transport protocols is that the transport layer has end-to-end > > > knowledge that makes it possible to make better multihoming decisions. > > > My recent thoughts are that it need not be tied directly to the TCP protocol, > > but can instead be done at the IP layer of the host stack. However the TCP and > > IP layers should be aware of each other in much the same way that PMTU is > > facilitated. If done that way, there would be benefits from caching the > > multihoming information and sharing it over several connections. > > This may or may not be desireable; the best way to handle this is > probably some capabilities negotiation where each end tells the other: I > can do this and this and that and it applies to: > > 1. All hosts living in this prefix: ... > 2. This host > 3. This protocol (TCP, UDP, ...) > 4. This session > > > Also because > > of the strong aggregation, the cached information would be able to build a > > multihoming hint tree more efficiently than would a flat list of IP addresses. > > For example, if a major link from one aggregator showed a problem, it would > > take provide a hint that all aggregations from that provider would be > > inaccessible and the stack could use this intelligence in advance. > > Hm, not sure if this would work very well as many different networks are > behind a single PA block, some of which may be down, some of which may > be operational. Also, I don't think many hosts will be donning a full > routing table. However, it would be nice to have. I've been thinking > about a protocol to share such information between hosts a while back, > maybe this would be a nice addition later on. > > > > Would it be possible to have a modified TCP talk to a non-modified TCP > > > through some kind of "mudem" (multihomer/demultihomer), without loss of > > > the core multihoming functionality, and without the "mudem" having to > > > keep long-term state? > > > Depends what you mean by long term. Please clarify. > > If a host sets up a connection that passes through a "mudem" this box > may intercept the setup packet and do some capability negotiation with > the other end. During this negotiation, there must be state in the mudem > box. That would be acceptable. But when the session is established, it > should be possible for the mudem to go down and come back up, or for > another to take over, without breaking the session. So for running > sessions, there must not be any state that can't be recovered by looking > at the session = state that would last as long as the session = long > time. > > > This is perhaps close to what I alluded to by a decoupling process. What is > > fundamental to a reliable working solution using my concepts is that if the > > prefix replacement is decoupled, it must still be done in a secure way so that > > protocols like TCP which might depend on address immutability can have an iron > > clad guarantee that the address selection is valid. > > I'm not sure what kind of bad things you want to protect against. If > someone has full access to the TCP packets, there is nothing you can do > anyway. (Other than SSL/IPSec, that is, but then they can still break > the session.) > > > It is clear that moving the process out of the host kernel enviromnent into an > > ancilliary processor environment would imply using some kind of secure control > > protocol to ensure that addresses are dealt with correctly, and this adds a > > degree of complication which I believe to be excessive. > > Hm, there is one thing that would be bad: a host thinks it talks with > host X, while in fact it talks to host Y. But that could happen with NAT > or some other man-in-the-middle thingy anyway, so is it worth the > trouble protecting against this? We could build something into the > protocol but obviously a corrupted multihoming processing box wouldn't > necessarily implement this and the fact that you _don't_ see such a box > doesn't mean anything. The real danger in all this is connection hijacking. The set of addresses negotiated must be kept immutable and also free from contamination during the negotiation process. Having a network in between the host and the mudem would increase the risk of this contamination. > > > I strong suggest that such multihoming be restricted to prefix replacement > > only, and not arbitrary address replacement, as there will be significant > > advantage in exploiting the implied tree structure imposed by the strong > > aggregation. > > I think it would be good to be able to replace the full address, that > way everyone can use it, no matter how limited their connectivity. > > What I envision is an IP option that makes it possible to negotiate > capabilities at the start of a / the first session. This option can > either be added: > > 1. by the transport protocol without involvement from the IP layer > 2. by the IP layer without involvement from the transport protocol > 3. by the IP layer at the request of the transport protocol > (= we need to extend the interface) > 4. by some external entity > > Which of 1 - 3 would you say is best? Don't forget this will probably > have to be implemented for several transport protocols. I think 2. Then it is available to all transport protocols. Maybe 4 if the issues I outlined before can be adequately dealt with. As I said in another thread selection of source address is also something that has been largely overlooked. The host based MH possibly has the advantage of getting this right better than an external entity. > > It would of course also be possible to do this in a TCP option, but that > complicates things like the TCP checksum in the case of 4 and doesn't > address non-TCP protocols. As discussed at the Tokyo meeting, there are limitations in the TCP header size which may preclude this being done there. Having it at the IP layer kind of makes sense, and having the gleaned information cached beyond the life of connections not only benefits multiple connections to the same host but should also aid connectionless protocols as well. At Tokyo, I think Steve Deering made a suggestion that we make this an IP layer feature available to all protocols but it was so fresh in my mind that I had not thought through all the possibilities. So my latest thought would be that we could do it at the IP layer in a similar way to that described in my preliminary draft. For TCP connections, the prefix/address set negotiation be done at syn/ack time, and for any other protocols that have the same syn/ack semantics. For connectionless protocols, the IP layer would need to rely on cached state to do its thing. In such a scenario, it may be important to set an upper time limit on the cached information being valid, the information being updated by incoming traffic. A nonce for the negotiation would have to be supplied by both ends in this case. If a nonce were to be added to the IP MH options, this could be made larger than the TCP sequence number thereby increasing the security from seq number attacks. Another possibility is that we define a MH connection protocol which establishes the MH characteristics of the connection between the two hosts. It would be analogous to a TCP session and would have the same degree of security as a TCP session. It could be done directly at the IP layer or be an ancilliary protocol on top of IP. It would imply that there would be host-host state information kept somewhere in the IP stack, but it is possible that this could distributed amongst the control blocks associated with each connection. My logic is that if this type of multihoming is done, state information has to be kept, and that this state information is likely to be rather fine grained and would very likely be a bad idea to place in a single box being used for a whole organization whether that be a router or mudem or whatever. The connection states are on the hosts - these would closely map those states and could best be managed on the hosts. What we don't want is this thing looking like one humungous NAT box - in the long term, that just won't scale, and it introduces another point of failure to consider in the traffic flow. > > 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 Sat Oct 26 03:04:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02341 for ; Sat, 26 Oct 2002 03:04:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185L04-000Jyv-00 for multi6-data@psg.com; Sat, 26 Oct 2002 00:04:48 -0700 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 185Kzz-000Jwx-00 for multi6@ops.ietf.org; Sat, 26 Oct 2002 00:04:43 -0700 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 10EE134422; Sat, 26 Oct 2002 00:13:05 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9Q746iI022495; Sat, 26 Oct 2002 00:04:06 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: The state of IPv6 multihoming development Date: Sat, 26 Oct 2002 00:04:06 -0700 Message-ID: Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ8criEf2bgXm80SDGUmfblXVg64wASt7/w From: "Tony Li" To: "Craig A. Huegen" Cc: "Masataka Ohta" , "Michel Py" , "J. Noel Chiappa" , X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA02341 | > Would you feel this way if you could simply maintain the prefixes | > in the border gateway? | | No. The open concern then becomes that of applications that carry | addresses in the payload -- would border routers require a | knowledge base | of applications to translate a la IPv4 NAT? So we're going to institutionalize support for layering violations? This doesn't seem right. Tony From owner-multi6@ops.ietf.org Sat Oct 26 03:17:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02458 for ; Sat, 26 Oct 2002 03:17:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185LDQ-000KOL-00 for multi6-data@psg.com; Sat, 26 Oct 2002 00:18:36 -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.36 #2) id 185LDO-000KO6-00 for multi6@ops.ietf.org; Sat, 26 Oct 2002 00:18:34 -0700 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Sat, 26 Oct 2002 00:18:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3BD@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ8cr08eE965z/eTummIFMvUNsw+wAShugA From: "Michel Py" To: "Craig A. Huegen" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA02458 > No. The open concern then becomes that of applications > that carry addresses in the payload -- would border > routers require a knowledge base of applications to > translate a la IPv4 NAT? Yuck. I am totally opposed to ALGs. Although higher layer apps that embed port numbers or other info in the payload are not elegant, they do exist. Any solution that requires an ALG is a non-starter. IPv6 was designed with the implicit promise that we could restore end-to-end connectivity that was lost with NAT. NAT is not bad; it simply is a necessary evil. There are no regrets to have invented NAT, as it was necessary. However, it would be a terrible mistake to reproduce with IPv6. Should we go that road, I already have The Perfect IPv6 Multihoming Solution: - We already have RFC 1918 for IPv6: Site local. - We keep the multihomed IPv4 backbone as is, and use 6to4. - Behind the 6to4 address, we put an IPv6 NAT (TM)(c) - This solves all the problems in the world: terrorism, hunger, and even IPv6 multihoming. You don't like it? Don't invent IPv6 NAT. Michel. From owner-multi6@ops.ietf.org Sat Oct 26 03:54:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02941 for ; Sat, 26 Oct 2002 03:54:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185Lny-000MBZ-00 for multi6-data@psg.com; Sat, 26 Oct 2002 00:56:22 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 185Lnv-000MBN-00 for multi6@ops.ietf.org; Sat, 26 Oct 2002 00:56:20 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9Q7tq029806; Sat, 26 Oct 2002 09:55:54 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 26 Oct 2002 09:55:52 +0200 (CEST) From: Iljitsch van Beijnum To: Tony Li cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: <20021026095013.G14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 26 Oct 2002, Tony Li wrote: > | No. The open concern then becomes that of applications that carry > | addresses in the payload -- would border routers require a > | knowledge base > | of applications to translate a la IPv4 NAT? > So we're going to institutionalize support for layering violations? > This doesn't seem right. Unless I'm mistaken nobody here has proposed a solution that has this problem. If/when addresses are changed somewhere, they are either changed back later, or the destination is aware of the relationship between the old and new address. In other words: any address that an application communicates to the other end remains valid. Reachable is another question... Apps should consider using more than one address. From owner-multi6@ops.ietf.org Sat Oct 26 04:14:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03168 for ; Sat, 26 Oct 2002 04:14:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185M6J-000Mlb-00 for multi6-data@psg.com; Sat, 26 Oct 2002 01:15:19 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 185M6H-000MlG-00 for multi6@ops.ietf.org; Sat, 26 Oct 2002 01:15:18 -0700 From: Masataka Ohta Message-Id: <200210260812.RAA06800@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA06800; Sat, 26 Oct 2002 17:12:04 +0900 Subject: Re: The state of IPv6 multihoming development In-Reply-To: <2B81403386729140A3A899A8B39B046405E3BD@server2000> from Michel Py at "Oct 26, 2002 00:18:33 am" To: Michel Py Date: Sat, 26 Oct 2002 17:12:03 +0859 () CC: "Craig A. Huegen" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Michel. > > No. The open concern then becomes that of applications > > that carry addresses in the payload -- would border > > routers require a knowledge base of applications to > > translate a la IPv4 NAT? > > Yuck. I am totally opposed to ALGs. Although higher layer apps that > embed port numbers or other info in the payload are not elegant, they do > exist. Any solution that requires an ALG is a non-starter. > > IPv6 was designed with the implicit promise that we could restore > end-to-end connectivity that was lost with NAT. NAT is not bad; it > simply is a necessary evil. There are no regrets to have invented NAT, > as it was necessary. However, it would be a terrible mistake to > reproduce with IPv6. NAT is unnecessary. IPv6 people, trying to promoto IPv6 transition, loudly warned IPv4 space exhaustion, perhaps with overestimation. The result was suppression of IPv4 address allocation, which promoted people to use NAT. As a result, IPv4 space won't exhaust very soon that no one really needs the IPv6 transtion, yet. Considering that IPv6 still have several flaws, including, but not limited to that for multihoming, we are lucky thant NAT suppressed IPv6 deployment. The remaining problem is that some IPv6 people are opposing to fix fatal flaws, as the fix will delay the magical IPv6 deployment to occur within several months, for these seven years. Masataka Ohta From owner-multi6@ops.ietf.org Sat Oct 26 20:44:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15733 for ; Sat, 26 Oct 2002 20:44:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185bXE-000D8Q-00 for multi6-data@psg.com; Sat, 26 Oct 2002 17:44:08 -0700 Received: from server.pasta.cs.uit.no ([129.242.16.119]) by psg.com with esmtp (Exim 3.36 #2) id 185bXB-000D8D-00 for multi6@ops.ietf.org; Sat, 26 Oct 2002 17:44:05 -0700 Received: from pasta.cs.uit.no (yltra.pasta.cs.uit.no [2001:700:400:600:250:4ff:fef9:301]) by server.pasta.cs.uit.no (8.11.6/8.11.6) with ESMTP id g9R0i0I26470; Sun, 27 Oct 2002 02:44:00 +0200 (CEST) Received: (from dillema@localhost) by pasta.cs.uit.no (8.11.6/8.11.6) id g9R0h3T12667; Sun, 27 Oct 2002 02:43:03 +0200 (CEST) Date: Sun, 27 Oct 2002 02:43:03 +0200 From: Feico Dillema To: Peter Tattam Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Transport multihoming Message-ID: <20021027004303.GK3253@pasta.cs.uit.no> References: <20021024210103.E14896-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: NetBSD yltra.pasta.cs.uit.no 1.6_RC2 NetBSD 1.6_RC2 (YLTRA) X-URL: http://www.dillema.net/ X-Spam-Status: No, hits=-13.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Oct 25, 2002 at 07:14:32AM +1100, Peter Tattam wrote: > On Thu, 24 Oct 2002, Iljitsch van Beijnum wrote: > > > Greg, Peter, > > > > As I see it, the reason to have the multihoming functionality inside one > > or more transport protocols is that the transport layer has end-to-end > > knowledge that makes it possible to make better multihoming decisions. > > My recent thoughts are that it need not be tied directly to the TCP protocol, > but can instead be done at the IP layer of the host stack. However the TCP and > IP layers should be aware of each other in much the same way that PMTU is > facilitated. If done that way, there would be benefits from caching the > multihoming information and sharing it over several connections. Also because > of the strong aggregation, the cached information would be able to build a > multihoming hint tree more efficiently than would a flat list of IP addresses. > For example, if a major link from one aggregator showed a problem, it would > take provide a hint that all aggregations from that provider would be > inaccessible and the stack could use this intelligence in advance. Instead of letting hosts negotiate the prefixes why not augment/generalize PMTU into a ``Path Capability (or MTU and Prefix) Discovery'' (or do something traceroute-like) that collects the information from all nodes along the path. This might allow for some nice aggregation and double-checking of information (assuming routers are typically more trustworthy or better maintainedi than most hosts). Feico. From owner-multi6@ops.ietf.org Sat Oct 26 21:11:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16153 for ; Sat, 26 Oct 2002 21:11:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185c00-000EuN-00 for multi6-data@psg.com; Sat, 26 Oct 2002 18:13:52 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #2) id 185bzy-000Eu9-00 for multi6@ops.ietf.org; Sat, 26 Oct 2002 18:13:50 -0700 Received: from penguin.ripe.net (penguin.ripe.net [193.0.1.232]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g9R1DdnZ003862; Sun, 27 Oct 2002 02:13:39 +0100 Received: (from shane@localhost) by penguin.ripe.net (8.11.6/8.11.6) id g9R1Ddf31695; Sun, 27 Oct 2002 02:13:39 +0100 Date: Sun, 27 Oct 2002 02:13:39 +0100 From: Shane Kerr To: Michel Py Cc: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development Message-ID: <20021027011339.GB28565@penguin.ripe.net> References: <2B81403386729140A3A899A8B39B046405E3BD@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046405E3BD@server2000> User-Agent: Mutt/1.3.25i X-RIPE-Spam-Status: NONE ; -1027 X-Spam-Status: No, hits=-16.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On 2002-10-26 00:18:33 -0700, Michel Py wrote: > > IPv6 was designed with the implicit promise that we could restore > end-to-end connectivity that was lost with NAT. NAT is not bad; it > simply is a necessary evil. There are no regrets to have invented > NAT, as it was necessary. However, it would be a terrible mistake to > reproduce with IPv6. Here's a question: does the end-to-end principle imply the endpoint is the application or the network stack on the hosts? The reason I ask is that I think the mudem idea has merit, even if it involves a NAT-like transformation from the application point of view. While eventually building applications that use SCTP might solve the multihoming needs of many end-users, building a layer that allows all existing applications to work with a set of addresses can offer enough benefit now so that the IPv6 folks should hold their noses and consider the idea. -- Shane Kerr RIPE NCC From owner-multi6@ops.ietf.org Sat Oct 26 23:46:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18278 for ; Sat, 26 Oct 2002 23:46:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185ePI-000NqA-00 for multi6-data@psg.com; Sat, 26 Oct 2002 20:48:08 -0700 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 185ePE-000NnJ-00 for multi6@ops.ietf.org; Sat, 26 Oct 2002 20:48:04 -0700 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id AC45934438; Sat, 26 Oct 2002 20:56:27 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9R3lXiI018459; Sat, 26 Oct 2002 20:47:33 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: The state of IPv6 multihoming development Date: Sat, 26 Oct 2002 20:47:33 -0700 Message-ID: Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ8xS3FsnDZcKfhSGKuUX0uPWHCGwApdoXQ From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA18278 | > | No. The open concern then becomes that of | applications that carry | > | addresses in the payload -- would border routers require a | > | knowledge base | > | of applications to translate a la IPv4 NAT? | | > So we're going to institutionalize support for layering | violations? | > This doesn't seem right. | | Unless I'm mistaken nobody here has proposed a solution | that has this | problem. Unless I'm the one that's mistaken, the original complaint was that changing bits (and specifically -- the locator) at the border router would break applications that carry full addresses around in them. | If/when addresses are changed somewhere, they are either | changed back later, or the destination is aware of the relationship | between the old and new address. In other words: any address that an | application communicates to the other end remains valid. | Reachable is | another question... Apps should consider using more than | one address. Ok, if apps (or the underlying transport) can use more than one address, then that implies that the host has to make a decision about WHICH address to use, which is what Craig was objecting to in the first place. If the host has to decide, then it's making a routing decision and it certainly shouldn't have enough information to make that decision. Thus, the suggestion is to push the decision to the border router and move the policy information there. The host still specifies the end system identifier, but the border router then determines the locator. Tony From owner-multi6@ops.ietf.org Sun Oct 27 00:17:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18532 for ; Sun, 27 Oct 2002 00:17:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185eu7-000Pl1-00 for multi6-data@psg.com; Sat, 26 Oct 2002 21:19:59 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 185eu5-000Pkp-00 for multi6@ops.ietf.org; Sat, 26 Oct 2002 21:19:57 -0700 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Sat, 26 Oct 2002 21:19:56 -0700 Reply-To: From: "Tony Hain" To: "'Tony Li'" , "'Iljitsch van Beijnum'" Cc: Subject: RE: The state of IPv6 multihoming development Date: Sat, 26 Oct 2002 21:19:41 -0700 Message-ID: <048301c27d70$1477cd40$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Spam-Status: No, hits=-5.6 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA18532 Tony Li wrote: > ... > Ok, if apps (or the underlying transport) can use more than > one address, > then that implies that the host has to make a decision about > WHICH address to use, which is what Craig was objecting to in > the first place. If the host has to decide, then it's making > a routing decision and it certainly shouldn't have enough > information to make that decision. I know Craig said the host is making a routing decision, but it isn't. Even if it tried it could be overruled by the routers for the outbound packets. The only thing the host can decide that might even come close to a routing decision is the address that the remote node will use to talk back toward it. This is not a routing decision, but for those who are into fine-grained TE, it might be considered a policy decision. Even if the origin node chooses an address that is overwritten by a border router, there is absolutely nothing the origin AS can do to enforce/influence the routing policy of the foreign network manager. As the packet gets closer, there might be an opportunity to create a localized gravity well, but only if there is no filtering going on between the providers. Since the origin network can't enforce reverse path routing decisions, the idea that the origin host is making any kind of routing decision is completely bogus. Tony From owner-multi6@ops.ietf.org Sun Oct 27 00:21:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18552 for ; Sun, 27 Oct 2002 00:21:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185exl-000Q0g-00 for multi6-data@psg.com; Sat, 26 Oct 2002 21:23:45 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 185exj-000Q0U-00 for multi6@ops.ietf.org; Sat, 26 Oct 2002 21:23:43 -0700 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Sat, 26 Oct 2002 21:23:50 -0700 Reply-To: From: "Tony Hain" To: "'Iljitsch van Beijnum'" , "'Tony Li'" Cc: Subject: RE: The state of IPv6 multihoming development Date: Sat, 26 Oct 2002 21:23:35 -0700 Message-ID: <048401c27d70$9ee0d8a0$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021026095013.G14896-100000@sequoia.muada.com> X-Spam-Status: No, hits=-4.3 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > ... > Unless I'm mistaken nobody here has proposed a solution that > has this problem. If/when addresses are changed somewhere, > they are either changed back later, Through a complex mechanism that scales worse than inter-domain multicast. Since that has proven to be a real deployment challenge, why do we think magic translator protocols are going to be any better? Tony > or the destination is > aware of the relationship between the old and new address. In > other words: any address that an application communicates to > the other end remains valid. Reachable is another question... > Apps should consider using more than one address. > > From owner-multi6@ops.ietf.org Sun Oct 27 03:50:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00088 for ; Sun, 27 Oct 2002 03:50:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185j8M-000EYR-00 for multi6-data@psg.com; Sun, 27 Oct 2002 01:50:58 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 185j8J-000EYF-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 01:50:55 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9R8oPI31755; Sun, 27 Oct 2002 09:50:27 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 27 Oct 2002 09:50:25 +0100 (CET) From: Iljitsch van Beijnum To: Tony Li cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: <20021027092247.P14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 26 Oct 2002, Tony Li wrote: > Unless I'm the one that's mistaken, the original complaint was that > changing bits (and specifically -- the locator) at the border router > would break applications that carry full addresses around in them. How can this be a problem if the bits are changed back later? > Ok, if apps (or the underlying transport) can use more than one address, > then that implies that the host has to make a decision about WHICH address > to use, which is what Craig was objecting to in the first place. If the > host has to decide, then it's making a routing decision and it certainly > shouldn't have enough information to make that decision. That's why it would be good if this functionality can be moved outside the end host to a place where this information is available. If this is done on the host, this host must select two addresses: the source address and the destination address. If we assume the source address must match the outgoing ISP, there are two ways to handle this: 1. The host selects a source address, and the routers choose the right ISP to match the source address. 2. The host selects a source address, and the routers don't care and route as per the destination address so the packet is filtered if the host selected the "wrong" source address. 1. would seem to provide better functionality. However, if the ISP the host implicitly selects by its choice of source address is unable to deliver the packet, the host must jump to another source address, just like it should if it selects the wrong source address in the case of 2. So for the host, the solutions are really equivalent and the choice should depend on the needs of the routers rather than the needs of the host. Then there is the destination address. If all destination addresses are routed/routable over the same ISP (which would alway be the case in source address handling mechanism 1. and a good percentage of the time in mechanism 2.) the host has no reason to prefer one over the other, so if the other end requests the use of another destination address, there is no reason to deny this request. Note that in the presence of source address mechanism 1. you'd have four rather than two functional paths in the following topology: A---C / \ / \ src + dst \ / \ / B---D src -> A -> C -> dst src -> A -> D -> dst src -> B -> C -> dst src -> B -> D -> dst can all be used. > Thus, the suggestion is to push the decision to the border router and > move the policy information there. The host still specifies the end > system identifier, but the border router then determines the locator. That would be one way to do it. The (border) router could also communicate its preferences back to the host. Either by dropping enough packets to force a rehoming event, or by sending back a message or some such. The host could set the router alert option for the negotation packets and the router could inspect these and let its preferences be known. From owner-multi6@ops.ietf.org Sun Oct 27 03:59:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00166 for ; Sun, 27 Oct 2002 03:59:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185jIp-000F1q-00 for multi6-data@psg.com; Sun, 27 Oct 2002 01:01:47 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 185jIn-000F1d-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 01:01:45 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9R91Lp31772; Sun, 27 Oct 2002 10:01:21 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 27 Oct 2002 10:01:21 +0100 (CET) From: Iljitsch van Beijnum To: Tony Hain cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <048401c27d70$9ee0d8a0$4b194104@eagleswings> Message-ID: <20021027095147.K14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 26 Oct 2002, Tony Hain wrote: > > Unless I'm mistaken nobody here has proposed a solution that > > has this problem. If/when addresses are changed somewhere, > > they are either changed back later, > Through a complex mechanism that scales worse than inter-domain > multicast. Since that has proven to be a real deployment challenge, why > do we think magic translator protocols are going to be any better? I don't see any relationship with interdomain multicast, so the fact that this has been hard to deploy in the past (and unless I'm mistaken the scalability problems have now been largely solved) doesn't say anything about translation mechanisms. Anything that happens in end-hosts should scale well. Moving the functionality to a different box outside, but still close to, the end-hosts should also scale as long as it's possible to deploy an arbitrary number of those boxes = no hard state. Content delivery systems often use complex NAT setups to balance the load and provide redundancy. Since what we're proposing here is simpler than NAT, I see no reason why it wouldn't work or scale. And if for the truly huge networks this solution isn't viable, they can always use IPv4-style multihoming. (But they'd still need to implement all of this in order to be able to talk to others who use multi-address multihoming.) Iljitsch From owner-multi6@ops.ietf.org Sun Oct 27 04:04:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00263 for ; Sun, 27 Oct 2002 04:04:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185jNs-000FHJ-00 for multi6-data@psg.com; Sun, 27 Oct 2002 01:07:00 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 185jNn-000FFv-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 01:06:55 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 8949334438; Sun, 27 Oct 2002 01:15:18 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9R96OiI002666; Sun, 27 Oct 2002 01:06:24 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: The state of IPv6 multihoming development Date: Sun, 27 Oct 2002 01:06:24 -0800 Message-ID: Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ9lfiV+NsvtRWZTAmY9qIUGBdAmAAAbg9A From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA00263 | On Sat, 26 Oct 2002, Tony Li wrote: | | > Unless I'm the one that's mistaken, the original | complaint was that | > changing bits (and specifically -- the locator) at the | border router | > would break applications that carry full addresses around in them. | | How can this be a problem if the bits are changed back later? Why would they get changed back? | > Ok, if apps (or the underlying transport) can use more | than one address, | > then that implies that the host has to make a decision | about WHICH address | > to use, which is what Craig was objecting to in the first | place. If the | > host has to decide, then it's making a routing decision | and it certainly | > shouldn't have enough information to make that decision. | | That's why it would be good if this functionality can be | moved outside | the end host to a place where this information is available. | | If this is done on the host, this host must select two | addresses: the | source address and the destination address. If we assume the source | address must match the outgoing ISP, there are two ways to | handle this: | | 1. The host selects a source address, and the routers | choose the right | ISP to match the source address. | 2. The host selects a source address, and the routers don't care and | route as per the destination address so the packet is | filtered if the | host selected the "wrong" source address. The host should select the identifier, both for itself and for the destination. The border router selects the locators for both the source and the destination. This allows the border router to implement policy in a reasonable way. | > Thus, the suggestion is to push the decision to the | border router and | > move the policy information there. The host still | specifies the end | > system identifier, but the border router then determines | the locator. | | That would be one way to do it. The (border) router could also | communicate its preferences back to the host. Either by | dropping enough | packets to force a rehoming event, or by sending back a message or | some such. The host could set the router alert option for | the negotation | packets and the router could inspect these and let its | preferences be | known. Agreed. One thing that we can do to speed the conversation is to first have the discussion at the architectural level. Then we can worry about the mechanisms. Tony From owner-multi6@ops.ietf.org Sun Oct 27 04:53:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00803 for ; Sun, 27 Oct 2002 04:53:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185k8i-000HVZ-00 for multi6-data@psg.com; Sun, 27 Oct 2002 01:55:24 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 185k8g-000HVC-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 01:55:22 -0800 From: Masataka Ohta Message-Id: <200210270951.SAA24189@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA24189; Sun, 27 Oct 2002 18:51:22 +0900 Subject: Re: The state of IPv6 multihoming development In-Reply-To: from Tony Li at "Oct 26, 2002 08:47:33 pm" To: Tony Li Date: Sun, 27 Oct 2002 18:51:22 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony; > Thus, the suggestion is to push the decision to the border router and > move the policy information there. The host still specifies the end > system identifier, but the border router then determines the locator. What a stupid suggestion. It makes the border router the single point of failure totally destroying the benefit of multihoming. If you try to have multiple border routers with complex redundancy protocol, there always is simple failure mode of the protocol. > If the > host has to decide, then it's making a routing decision and it certainly > shouldn't have enough information to make that decision. Hosts, of course, are the only intelligent entities of the Internet, must make as much decision as possible and should have all the information. Never say IPv6 global routing table is to large. Masataka Ohta From owner-multi6@ops.ietf.org Sun Oct 27 07:04:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02324 for ; Sun, 27 Oct 2002 07:04:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185mBE-000Nqg-00 for multi6-data@psg.com; Sun, 27 Oct 2002 04:06:08 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 185mBC-000NqU-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 04:06:06 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9RC5eL31950; Sun, 27 Oct 2002 13:05:43 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 27 Oct 2002 13:05:40 +0100 (CET) From: Iljitsch van Beijnum To: Tony Li cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: <20021027103332.V14896-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 27 Oct 2002, Tony Li wrote: > | > Unless I'm the one that's mistaken, the original > | > complaint was that > | > changing bits (and specifically -- the locator) at the > | > border router > | > would break applications that carry full addresses around in them. > | How can this be a problem if the bits are changed back later? > Why would they get changed back? To avoid the above problem. :-) If the multihoming processing is done outside the host, then packets all packets must be presented to the host with the identifiers as the source and destinations addresses. If this is done inside the host then this isn't strictly required, but it is likely the transport layer will want to see just the identifiers so the IP layer will have to reconstitute those. > | 1. The host selects a source address, and the routers > | choose the right > | ISP to match the source address. > | 2. The host selects a source address, and the routers don't care and > | route as per the destination address so the packet is > | filtered if the > | host selected the "wrong" source address. > The host should select the identifier, both for itself and for the > destination. The border router selects the locators for both the > source and the destination. This allows the border router to implement > policy in a reasonable way. Agree. However, do we want to involve a border router in the locator discovery process? > One thing that we can do to speed the conversation is to > first have the discussion at the architectural level. Then we can > worry about the mechanisms. Ok, that should work as long as we don't run into any "that can't work" "yes it can" arguments. The basic idea is simple: the IP addresses the transport layer uses become the identifiers of a session. In transit, these identifiers may/must be replaced by locators, but they identifiers are restored before the packet reaches the transport layer at the other end. The idea is that identifiers are also valid "regular" IP addresses that can be used whenever multi-address multihoming isn't supported by both ends or otherwise not desired. I think there is some rough consensus that this should be done at the IP layer, but it's probably advantagious to include some way for transport protocols to provide hints that a rehoming might be in order. Making this functionality "portable" so it can be located either inside the host, or at a border router or some intermediate device would greatly help in easy deployment and makes it possible to better address the needs to implement multihoming or traffic engineering policies and address management in large networks. Then there is the issue of locator discovery or negotion. Negotiation is much simpler to do, but has the disadvantage the it can't occur a priori so it doesn't protect against an unreachable identifier. However, this could be solved by having several potential identifiers located at different places in the topology. This does NOT imply the alternative identifiers are also alternative locators. It may be necessary to have some mechanism for IP to learn from the transport protocol whether the negotiation data pertains to a valid session if negotiation is done at the network layer. Discovery is hard to do, but if we can solve the associated problems it provides a much stronger mechanism because then a host can have a single, portable identifier. It would be good if we could provide an upgrade path from negotiation to discovery. An interesting consequence of all this multi-address stuff is that a range of addresses becoming unreachable is no longer a huge problem that must be fixed immediately, but rather an inconvience that can be tolerated for some time. This means routing protocols can become much less dynamic. For instance, the mapping from address prefixes to AS numbers can become very static. It could even be done out of band, and the mapping could be stored on semi-permanent storage. This makes it possible to include much stronger security mechanisms. Changes in inter-AS connectivity can then be propagated throughout the network much faster than they are now, and there is room to exchange much more information that can be used to optimize inter-AS routing, such as link-state mechanisms. Iljitsch From owner-multi6@ops.ietf.org Sun Oct 27 08:47:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03601 for ; Sun, 27 Oct 2002 08:47:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185nly-0002pk-00 for multi6-data@psg.com; Sun, 27 Oct 2002 05:48:10 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 185nlw-0002pQ-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 05:48:09 -0800 Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by n97.nomadiclab.com (Postfix) with ESMTP id CBC001C; Sun, 27 Oct 2002 15:54:14 +0200 (EET) Message-ID: <3DBBE066.2030603@nomadiclab.com> Date: Sun, 27 Oct 2002 15:47:34 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021024 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: Tony Li , multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development References: <20021027103332.V14896-100000@sequoia.muada.com> In-Reply-To: <20021027103332.V14896-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > The basic idea is simple: the IP addresses the transport layer uses > become the identifiers of a session. In transit, these identifiers > may/must be replaced by locators, but they identifiers are restored > before the packet reaches the transport layer at the other end. > > The idea is that identifiers are also valid "regular" IP addresses that > can be used whenever multi-address multihoming isn't supported by both > ends or otherwise not desired. Why does this so much sound like Mobile IPv6 to me? > ... > > Making this functionality "portable" so it can be located either inside > the host, or at a border router or some intermediate device would > greatly help in easy deployment and makes it possible to better address > the needs to implement multihoming or traffic engineering policies and > address management in large networks. And why does this statement make me think that the lessons we learned during the Mobile IPv6 security process might be good to remember here? I am probably biased here, but IMHO once you start to really ponder the security consequences, you pretty much come to the idea that maybe, after all, it might be better to introduce a new cryptographic name space instead of once more overloading the IP name space with some IP addresses that are end-point identifiers (and locators) and some that are (just) locators. The resulting aliasing problems are nasty, security wise. The NSRG report still makes a good reading. If you are going to require changes to the end-host and the introduction of a mudem box anyway, the HIP design might be a good place to start with. The more recent variants of HIP already support end-host multi-homing, and they contain a "mudem" which is able to perform prefix translation, function as a mobility home agent, and as a mobility anchor point. Probably the LIN6/LINA design can do most of what HIP does as well, but I haven't followed their recent changes, and I don't know if they have already solved the scalability problems in their security design. --Pekka Nikander From owner-multi6@ops.ietf.org Sun Oct 27 12:28:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07247 for ; Sun, 27 Oct 2002 12:28:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185rEU-000EIv-00 for multi6-data@psg.com; Sun, 27 Oct 2002 09:29:50 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 185rER-000EIj-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 09:29:47 -0800 Received: from localhost (metamorph.gamepoint.net [195.193.163.32]) by sequoia.muada.com (8.11.3/8.9.3) with SMTP id g9RHStH32251; Sun, 27 Oct 2002 18:28:56 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 27 Oct 2002 18:28:56 +0100 (CET) Message-Id: <200210271728.g9RHStH32251@sequoia.muada.com> From: Iljitsch van Beijnum To: Cc: Subject: Re: The state of IPv6 multihoming development X-Mailer: HandMail 2.1 Mime-Version: 1.0 Content-Type: text/plain; Charset="iso-8859-1" X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA07247 >> The basic idea is simple: the IP addresses the transport layer uses >> become the identifiers of a session. In transit, these identifiers >> may/must be replaced by locators, but they identifiers are restored >> before the packet reaches the transport layer at the other end. >Why does this so much sound like Mobile IPv6 to me? There are many similarities. That's why it would be good to talk with the mobility people. >I am probably biased here, but IMHO once you start to really >ponder the security consequences, you pretty much come to the >idea that maybe, after all, it might be better to introduce >a new cryptographic name space instead of once more overloading >the IP name space with some IP addresses that are end-point >identifiers (and locators) and some that are (just) locators. >The resulting aliasing problems are nasty, security wise. What would this cryptographic name space look like? Remember that we have to maintain backward compatibility with a lot of stuff. >The NSRG report still makes a good reading. Do you have a pointer? >If you are going to require changes to the end-host and the >introduction of a mudem box anyway, the HIP design might >be a good place to start with. The more recent variants of >HIP already support end-host multi-homing, and they contain >a "mudem" which is able to perform prefix translation, function >as a mobility home agent, and as a mobility anchor point. That sounds good. Another pointer, please? However, mobility as I understand it assumes things, especially the home agent, are reachable. In multihoming, this definately isn't an assumption we can make. From owner-multi6@ops.ietf.org Sun Oct 27 13:38:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08184 for ; Sun, 27 Oct 2002 13:38:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185sKb-000INm-00 for multi6-data@psg.com; Sun, 27 Oct 2002 10:40:13 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 185sKY-000IN4-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 10:40:10 -0800 Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id 7E1E01C; Sun, 27 Oct 2002 20:46:16 +0200 (EET) Message-ID: <3DBC32EB.7000607@nomadiclab.com> Date: Sun, 27 Oct 2002 20:39:39 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development References: <200210271728.g9RHStH32251@sequoia.muada.com> In-Reply-To: <200210271728.g9RHStH32251@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: >>> The basic idea is simple: the IP addresses the transport layer uses >>> become the identifiers of a session. In transit, these identifiers >>> may/must be replaced by locators, but they identifiers are restored >>> before the packet reaches the transport layer at the other end. >> I am probably biased here, but IMHO once you start to really >> ponder the security consequences, you pretty much come to the >> idea that maybe, after all, it might be better to introduce >> a new cryptographic name space instead of once more overloading >> the IP name space with some IP addresses that are end-point >> identifiers (and locators) and some that are (just) locators. >> The resulting aliasing problems are nasty, security wise. > What would this cryptographic name space look like? The basic idea is simple: Introduce a new name space for end-points. Architecturally, the name space would be located between the IP addresses and the TCP/UDP/SCTP ports. The scope of the transport layer ports would be changed from IP addresses to end-point names. The end-points names would then be bound to IP addresses. For mobility, this binding would be dynamic. For end-host multi-homing, this binding would be one-to-many. For virtual hosts, the binding would be many-to-one. If the new name space was cryptographic, the primary end-point identifiers would be public keys (or equivalents). However, since public keys are so large, it would be more convenient to use digests of the keys in most data structures. Thus, instead of trying to make a TCP connection to e.g. your-ip:25 I would create a TCP connection to hash(your-key):25. Security would be trivial, since you would know the public key of your peer. The details are in the HIP drafts. > Remember that we have to maintain backward compatibility > with a lot of stuff. There are lots of details to be worked out, but the basic idea in HIP is to represent the end-point ID as a 127 bit hash of the public key. This hash would then be encoded so that it looks like an IPv6 address with the first two bits being either 01 or 10. Both of these code points are currently unassigned. The host stack would then, underneath TCP or UDP, look at these two bits. If the bits indicate a normal IPv6 address, nothing would happen and the host would work just like today. On the other hand, if the bits indicate HIP, the host would select an IP address from the addresses currently available for the given host, and replace the key hash with the address. The recipient would then make the reverse, thereby preserving transport layer checksums. This is somewhat hackish, I agree, but it would preserve backward compatibility. A new API would be a better alternative, but would break backward compatibility. In the wire, IP addresses are always used as today. Thus, no changes are required to routing. >> The NSRG report still makes a good reading. > > Do you have a pointer? http://www.ietf.org/internet-drafts/draft-irtf-nsrg-report-06.txt >> If you are going to require changes to the end-host and the >> introduction of a mudem box anyway, the HIP design might >> be a good place to start with. The more recent variants of >> HIP already support end-host multi-homing, and they contain >> a "mudem" which is able to perform prefix translation, function >> as a mobility home agent, and as a mobility anchor point. > > That sounds good. Another pointer, please? The basic design is perhaps best explained in our forthcoming NDSS paper. I'm happy to send preprints upon request; I'm afraid I can't put it on my web site yet. (NDSS will be held in February in San Diego, see http://www.isoc.org) Other sources of information are the following: http://homebase.htt-consult.com/HIP.html http://hip4inter.net > However, mobility as I understand it assumes things, > especially the home agent, are reachable. In multihoming, > this definately isn't an assumption we can make. According to my understanding, mobility requires reachability for the following two reasons: a) Initial reachability. You need some initial IP address to reach the host in the first place. If multi-homing is supported in addition to mobility, the set of initial addresses can contain more than one address. b) Resolving simultaneous movements (double jump). If both ends of a connection are mobile and move at the same time, they must somehow be able to reach each other after the movements. Both of these, in fact, are easier to solve with end-host multi-homing. (It is a completely different thing that Mobile IPv6 is designed as it is designed, with home agents and lots of complexity. It carries much history from Mobile IPv4 design...) --Pekka Nikander From owner-multi6@ops.ietf.org Sun Oct 27 15:27:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09370 for ; Sun, 27 Oct 2002 15:27:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185u1i-000OXs-00 for multi6-data@psg.com; Sun, 27 Oct 2002 12:28:50 -0800 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 185u1g-000OXg-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 12:28:48 -0800 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9RKSkQ1008758; Sun, 27 Oct 2002 21:28:46 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sun, 27 Oct 2002 21:28:46 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0BF6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Iljitsch van Beijnum'" Cc: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Date: Sun, 27 Oct 2002 21:28:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-1.9 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > However, mobility as I understand it assumes things, > especially the home agent, are reachable. In multihoming, > this definately isn't an assumption we can make. > => This is not an issue. It depends on where your HA is located. I can write something if there is enough interest, but end host approaches don't seem to be interesting to most people on this list. Hesham From owner-multi6@ops.ietf.org Sun Oct 27 15:49:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09565 for ; Sun, 27 Oct 2002 15:49:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185uNN-00005e-00 for multi6-data@psg.com; Sun, 27 Oct 2002 12:51:13 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 185uNK-000053-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 12:51:11 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id HAA23456; Mon, 28 Oct 2002 07:50:57 +1100 (EST) Date: Mon, 28 Oct 2002 07:50:57 +1100 (EST) From: Peter Tattam To: Iljitsch van Beijnum cc: Pekka.Nikander@nomadiclab.com, multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development In-Reply-To: <200210271728.g9RHStH32251@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 27 Oct 2002, Iljitsch van Beijnum wrote: > >> The basic idea is simple: the IP addresses the transport layer uses > >> become the identifiers of a session. In transit, these identifiers > >> may/must be replaced by locators, but they identifiers are restored > >> before the packet reaches the transport layer at the other end. > > >Why does this so much sound like Mobile IPv6 to me? > > There are many similarities. That's why it would be good to talk with the mobility people. > > >I am probably biased here, but IMHO once you start to really > >ponder the security consequences, you pretty much come to the > >idea that maybe, after all, it might be better to introduce > >a new cryptographic name space instead of once more overloading > >the IP name space with some IP addresses that are end-point > >identifiers (and locators) and some that are (just) locators. > >The resulting aliasing problems are nasty, security wise. > > What would this cryptographic name space look like? Remember that we have to maintain backward compatibility with a lot of stuff. I strongly believe that any solution which depends on crypto won't fly, mainly on the grounds that it is my understanding that good crypto relies on PKI and also requires significant cpu resources that may not be applicable to monster servers or miniscule devices. Generally the nature of mobility is that crypto is mandatory because of the dangerous environment that it operates within. The only security requirement that a MH solution needs to conform to would be equivalent to what we have in IPv4. I believe this requirement is fully met by a syn/ack exchange of addresses on the primary addresses between the hosts. While this does not preclude a man in the middle attack steal the connection, neither does the BGP model preclude a man in the middle attack also in such a scenario. I believe it could withstand a man on the side attack though. > > >The NSRG report still makes a good reading. > > Do you have a pointer? > > >If you are going to require changes to the end-host and the > >introduction of a mudem box anyway, the HIP design might > >be a good place to start with. The more recent variants of > >HIP already support end-host multi-homing, and they contain > >a "mudem" which is able to perform prefix translation, function > >as a mobility home agent, and as a mobility anchor point. > > That sounds good. Another pointer, please? > > However, mobility as I understand it assumes things, especially the home agent, are reachable. In multihoming, this definately isn't an assumption we can make. > > -- 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 Oct 27 17:53:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11076 for ; Sun, 27 Oct 2002 17:53:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185wHy-0007ij-00 for multi6-data@psg.com; Sun, 27 Oct 2002 14:53:46 -0800 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.36 #2) id 185wHw-0007iX-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 14:53:44 -0800 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Sun, 27 Oct 2002 14:53:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3C1@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ9cNO0PtrchIhLR3Wa+bgpZ5iQUwAmcktg From: "Michel Py" To: , "Tony Li" , "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA11076 > Tony Hain wrote: > Even if the origin node chooses an address that is > overwritten by a border router, there is absolutely nothing > he origin AS can do to enforce/influence the routing policy > of the foreign network manager. As the packet gets closer, > there might be an opportunity to create a localized gravity > well, but only if there is no filtering going on between > the providers. Since the origin network can't enforce reverse > path routing decisions, the idea that the origin host is > making any kind of routing decision is completely bogus. That being said, Craig has some legitimate traffic shaping concerns. Even though the host might not make direct routing decisions, by choosing either which of its own addresses it's going to use or which of the destination's addresses it's going to use, the host itself takes a traffic shaping decision, which is not something that Craig wants and I support him on that. Add to this the extra overhead and headaches associated with maintaining several addresses per host, it makes the task impossible. In short: a large organization needs to be able to engineer traffic, which I don't realistically see happening when individual hosts can take decisions that can affect traffic engineering. Michel. From owner-multi6@ops.ietf.org Sun Oct 27 17:53:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11091 for ; Sun, 27 Oct 2002 17:53:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185wI5-0007j1-00 for multi6-data@psg.com; Sun, 27 Oct 2002 14:53:53 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 185wI3-0007ip-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 14:53:51 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9RMrS532645; Sun, 27 Oct 2002 23:53:28 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 27 Oct 2002 23:53:28 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Nikander cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: <3DBC32EB.7000607@nomadiclab.com> Message-ID: <20021027233419.J32506-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 27 Oct 2002, Pekka Nikander wrote: > If the new name space was cryptographic, the primary end-point > identifiers would be public keys (or equivalents). However, > since public keys are so large, it would be more convenient to > use digests of the keys in most data structures. > Thus, instead of trying to make a TCP connection to e.g. > your-ip:25 I would create a TCP connection to hash(your-key):25. > Security would be trivial, since you would know the public > key of your peer. The details are in the HIP drafts. Hm, what problem exactly does this solve that isn't solved by (for instance) SSL? Also, how does the hash to IP address mapping work in the absence of a hierarchy? > > Remember that we have to maintain backward compatibility > > with a lot of stuff. > There are lots of details to be worked out, but the basic > idea in HIP is to represent the end-point ID as a 127 bit > hash of the public key. This hash would then be encoded > so that it looks like an IPv6 address with the first two > bits being either 01 or 10. Both of these code points > are currently unassigned. I'm not sure if I've said so clearly on this list, but over the last month or so I've come to realize that it's probably too soon to create a definitive multihoming solution. So it would be good to come up with meta-solutions that enable different solutions to work together, or provide a growth path from one solution to the other. I share Peter's scepticism towards crypto-based solutions, so I don't think we should crate a solution that only works with crypto. But a first step solution could very well have the right hooks to enable the use of cryptography where desired. More specifically: if we can make some sort of identifier/locator seperation solution where the identifiers are simply routable addresses, most of the ground work to move to crypto hash identifiers is in place, and the only thing necessary is a good locator discovery mechanism. > > That sounds good. Another pointer, please? > The basic design is perhaps best explained in our forthcoming > NDSS paper. I'm happy to send preprints upon request; Condiser it requested. > According to my understanding, mobility requires reachability > for the following two reasons: > a) Initial reachability. You need some initial IP address > to reach the host in the first place. If multi-homing > is supported in addition to mobility, the set of initial > addresses can contain more than one address. I'm afraid we have to push this into the application (trying multiple addresses) as long as we don't have a good locator discovery service. > b) Resolving simultaneous movements (double jump). If both > ends of a connection are mobile and move at the same time, > they must somehow be able to reach each other after the > movements. But what if the home agent becomes unreachable? Requiring the home agent to be reachable just moves the problem to the place where the home agent is located. This may have some benefits as the number of home agent locations can be smaller than the number of multihomed hosts, but it still requires some other means of multihoming to protect the home agent. I read about a homeless mobility proposal somewhere a while ago, but I haven't been able to find it again afterwards... Iljitsch From owner-multi6@ops.ietf.org Sun Oct 27 17:54:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11108 for ; Sun, 27 Oct 2002 17:54:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185wKF-0007pS-00 for multi6-data@psg.com; Sun, 27 Oct 2002 14:56:07 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 185wKD-0007pD-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 14:56:05 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9RMtan32652; Sun, 27 Oct 2002 23:55:37 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 27 Oct 2002 23:55:36 +0100 (CET) From: Iljitsch van Beijnum To: Peter Tattam cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: Message-ID: <20021027235353.A32506-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 28 Oct 2002, Peter Tattam wrote: > The > only security requirement that a MH solution needs to conform to would be > equivalent to what we have in IPv4. I believe this requirement is fully met by > a syn/ack exchange of addresses on the primary addresses between the hosts. > While this does not preclude a man in the middle attack steal the connection, > neither does the BGP model preclude a man in the middle attack also in such a > scenario. I believe it could withstand a man on the side attack though. This is a good point. Sometimes the security people get carried away... From owner-multi6@ops.ietf.org Sun Oct 27 18:11:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11385 for ; Sun, 27 Oct 2002 18:11:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185waV-0008fm-00 for multi6-data@psg.com; Sun, 27 Oct 2002 15:12:55 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.36 #2) id 185waT-0008bf-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 15:12:53 -0800 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9RNCDPP012302; Sun, 27 Oct 2002 15:12:13 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9RNC7Wx018694; Sun, 27 Oct 2002 15:12:07 -0800 (PST) Received: from dhcp1205.nanog26.merit.net (sjc-vpn1-565.cisco.com [10.21.98.53]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA29062; Sun, 27 Oct 2002 15:12:00 -0800 (PST) Date: Sun, 27 Oct 2002 17:12:01 -0600 (Central Standard Time) From: "Craig A. Huegen" To: Tony Li cc: Masataka Ohta , Michel Py , "J. Noel Chiappa" , Subject: RE: The state of IPv6 multihoming development In-Reply-To: Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 26 Oct 2002, Tony Li wrote: > So we're going to institutionalize support for layering violations? > This doesn't seem right. I would like for the answer to be "no". At the same time, there is the question of existing applications. Will H.323 be completely re-written? /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Sun Oct 27 19:36:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12526 for ; Sun, 27 Oct 2002 19:36:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185xvU-000DpI-00 for multi6-data@psg.com; Sun, 27 Oct 2002 16:38:40 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 185xvS-000DmY-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 16:38:38 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 3C6B834434; Sun, 27 Oct 2002 16:46:59 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9S0c0iI013061; Sun, 27 Oct 2002 16:38:00 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: The state of IPv6 multihoming development Date: Sun, 27 Oct 2002 16:37:59 -0800 Message-ID: Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ+DmjcPt1hefDBQb+NI8DlWUzXAAAC6FXA From: "Tony Li" To: "Craig A. Huegen" Cc: "Masataka Ohta" , "Michel Py" , "J. Noel Chiappa" , X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA12526 | On Sat, 26 Oct 2002, Tony Li wrote: | | > So we're going to institutionalize support for layering | violations? | > This doesn't seem right. | | I would like for the answer to be "no". At the same time, | there is the | question of existing applications. Will H.323 be | completely re-written? I have no idea. If folks decide not to do some kind of modification to support IPv6, they're going to have problems as soon as they try to put 128 bits in a 32 bit entry. ;-) In my mind, the correct thing to do is to change it so that the host identifier can go there, but keep the locator out of the upper layers. Tony From owner-multi6@ops.ietf.org Sun Oct 27 21:23:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13807 for ; Sun, 27 Oct 2002 21:23:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185zYj-000KH9-00 for multi6-data@psg.com; Sun, 27 Oct 2002 18:23:17 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 185zYg-000KGm-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 18:23:14 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Sun, 27 Oct 2002 18:23:09 -0800 Reply-To: From: "Tony Hain" To: "'Iljitsch van Beijnum'" Cc: Subject: RE: The state of IPv6 multihoming development Date: Sun, 27 Oct 2002 18:22:49 -0800 Message-ID: <048e01c27e28$eb1a82d0$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021027095147.K14896-100000@sequoia.muada.com> X-Spam-Status: No, hits=-4.3 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > I don't see any relationship with interdomain multicast, so > the fact that this has been hard to deploy in the past (and > unless I'm mistaken the scalability problems have now been > largely solved) doesn't say anything about translation mechanisms. Passing around state between administrative entities is always a trust problem. > > Anything that happens in end-hosts should scale well. Moving > the functionality to a different box outside, but still close > to, the end-hosts should also scale as long as it's possible > to deploy an arbitrary number of those boxes = no hard state. As long as all participants are the same adminstrative entity, scaling is not a serious problem. > Content delivery systems often use complex NAT setups to > balance the load and provide redundancy. Since what we're > proposing here is simpler than NAT, I see no reason why it > wouldn't work or scale. But those content systems are run by a single entity. When multiple parties are involved, the translation is done at a higher layer. > > And if for the truly huge networks this solution isn't > viable, they can always use IPv4-style multihoming. (But > they'd still need to implement all of this in order to be > able to talk to others who use multi-address > multihoming.) We will end up with a system that looks like IPv4 muti-homing to the sites that want that, but scales better for the service providers. Anything less on either front is a non-starter. Tony From owner-multi6@ops.ietf.org Sun Oct 27 21:48:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14446 for ; Sun, 27 Oct 2002 21:48:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185zzN-000Lyp-00 for multi6-data@psg.com; Sun, 27 Oct 2002 18:50:49 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 185zzK-000LyX-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 18:50:46 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Sun, 27 Oct 2002 18:50:47 -0800 Reply-To: From: "Tony Hain" To: "'Michel Py'" , "'Tony Li'" , "'Iljitsch van Beijnum'" Cc: Subject: RE: The state of IPv6 multihoming development Date: Sun, 27 Oct 2002 18:50:29 -0800 Message-ID: <04ac01c27e2c$c6bc5f90$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <2B81403386729140A3A899A8B39B046405E3C1@server2000> X-Spam-Status: No, hits=-4.3 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA14446 Michel Py wrote: > ... > In short: a large organization needs to be able to engineer > traffic, which I don't realistically see happening when > individual hosts can take decisions that can affect traffic > engineering. A host decision does not affect traffic shaping for the outbound direction. The only choice it is making in that space is the dst addr, and it has that responsibility today, even though it has no deterministic means of making that choice. The IPv6 address selection rules add structure to that process. For the inbound direction, the remote and intermediate network managers have more impact on the actual path the bits will take than the origin choice of source addr. All we have today is the illusion that a network manager can direct traffic toward his network. Having 1 or N addresses doesn't change the granularity of traffic engineering, so the argument is bogus. What it really boils down to is that nodes outside the network manager's direct control are making a decision (any decision). This is about trust, not traffic engineering. Tony From owner-multi6@ops.ietf.org Sun Oct 27 22:04:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14621 for ; Sun, 27 Oct 2002 22:04:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1860EP-000MwK-00 for multi6-data@psg.com; Sun, 27 Oct 2002 19:06:21 -0800 Received: from ns1.arch.bellsouth.net ([205.152.173.2]) by psg.com with esmtp (Exim 3.36 #2) id 1860EN-000MvQ-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 19:06:19 -0800 Received: (from ck@localhost) by ns1.arch.bellsouth.net (goaway/goaway) id g9S35f116061; Sun, 27 Oct 2002 22:05:41 -0500 (EST) Date: Sun, 27 Oct 2002 22:05:40 -0500 From: Christian Kuhtz To: Tony Hain Cc: "'Michel Py'" , "'Tony Li'" , "'Iljitsch van Beijnum'" , multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development Message-ID: <20021027220540.B15478@ns1.arch.bellsouth.net> References: <2B81403386729140A3A899A8B39B046405E3C1@server2000> <04ac01c27e2c$c6bc5f90$4b194104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <04ac01c27e2c$c6bc5f90$4b194104@eagleswings>; from Tony Hain on Sun, Oct 27, 2002 at 06:50:29PM -0800 X-message-flag: Department of Redundancy Department X-Spam-Status: No, hits=-8.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, Oct 27, 2002 at 06:50:29PM -0800, Tony Hain wrote: > Michel Py wrote: > > ... > > In short: a large organization needs to be able to engineer > > traffic, which I don't realistically see happening when > > individual hosts can take decisions that can affect traffic > > engineering. > > A host decision does not affect traffic shaping for the outbound > direction. The only choice it is making in that space is the dst addr, > and it has that responsibility today, even though it has no > deterministic means of making that choice. The IPv6 address selection > rules add structure to that process. maybe i got this all wrong, but... if this means that a host is expected to make a decision which path to chose, i'm sorry, i don't see that happening and consider it an absurd notion. the last thing i want is for an oracle server, or webserver, or whatever to make a routing decision as to which addr or iface to use. seems the trend is exactly the opposite.. to get that decision _away_ from the host and have the backbone of a given org take care of traffic management. any type of te will have to aggregated at a higher level than hosts. some of this is a technology and architectural decision, some of this is also real world organizational skills. i do not want to create a rqmt that says that systems operations folks have to be omnipotent systems & network wizards to configuration, manage and troubleshoot their hosts. and i think that's exactly what you do when you push te capabilities down to the host level. > For the inbound direction, the remote and intermediate network managers > have more impact on the actual path the bits will take than the origin > choice of source addr. All we have today is the illusion that a network > manager can direct traffic toward his network. Having 1 or N addresses > doesn't change the granularity of traffic engineering, so the argument > is bogus. What it really boils down to is that nodes outside the network > manager's direct control are making a decision (any decision). This is > about trust, not traffic engineering. nevermind that there are various bgp knobs today which allow you to do exactly that (regulate inbound traffic) by changing what prefixes are advertised where and how. there is a gating factor here in today's ipv4 world in terms of the smallest chunk of addresses which can be pulled out of a given aggregate. thanks, christian From owner-multi6@ops.ietf.org Sun Oct 27 22:44:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15529 for ; Sun, 27 Oct 2002 22:44:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1860qb-000PU2-00 for multi6-data@psg.com; Sun, 27 Oct 2002 19:45:49 -0800 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.36 #2) id 1860qZ-000PTq-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 19:45:47 -0800 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Sun, 27 Oct 2002 19:45:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3C3@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ+LwXtuDf86nN0RP2lbLwLBUUDfwAA7sCQ From: "Michel Py" To: "Christian Kuhtz" , "Tony Hain" Cc: "Tony Li" , "Iljitsch van Beijnum" , X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA15529 Christian, > Christian Kuhtz wrote: > maybe i got this all wrong, but... You got it right. Let's keep something in mind: the kind of traffic engineering we are talking about is egress: you have a big honkin' server farm serving a boatload of customers wherever. The bulk of the traffic is return traffic, let's say http traffic. Here's the scenario: the home/soho host that is multihomed with cable and dsl makes a choice on which of its own addresses (the cable one, or the dsl one) to use. This choice will dictate on which pipe the return traffic from the web server to the requesting host goes. This is what we really are talking about here: Joe-six-pack's PC thinks the ping to the cable default gateway is better than the ping to the dsl default gateway and chooses its own source address to be the cable's one. And this, gentlemen, is *not* what I call traffic engineering. Michel. From owner-multi6@ops.ietf.org Sun Oct 27 23:18:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16021 for ; Sun, 27 Oct 2002 23:18:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1861O9-0001er-00 for multi6-data@psg.com; Sun, 27 Oct 2002 20:20:29 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 1861O6-0001ef-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 20:20:27 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id PAA13968; Mon, 28 Oct 2002 15:19:42 +1100 (EST) Date: Mon, 28 Oct 2002 15:19:42 +1100 (EST) From: Peter Tattam To: Michel Py cc: Christian Kuhtz , Tony Hain , Tony Li , Iljitsch van Beijnum , multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development In-Reply-To: <2B81403386729140A3A899A8B39B046405E3C3@server2000> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 27 Oct 2002, Michel Py wrote: > Christian, > > > Christian Kuhtz wrote: > > maybe i got this all wrong, but... > > You got it right. Let's keep something in mind: the kind of traffic > engineering we are talking about is egress: you have a big honkin' > server farm serving a boatload of customers wherever. The bulk of the > traffic is return traffic, let's say http traffic. > > Here's the scenario: the home/soho host that is multihomed with cable > and dsl makes a choice on which of its own addresses (the cable one, or > the dsl one) to use. This choice will dictate on which pipe the return > traffic from the web server to the requesting host goes. > > This is what we really are talking about here: Joe-six-pack's PC thinks > the ping to the cable default gateway is better than the ping to the dsl > default gateway and chooses its own source address to be the cable's > one. > > And this, gentlemen, is *not* what I call traffic engineering. And precisely the reason why I am thinking of using the flow label to collect RTT information for each path. The traffic engineering decisions should be based on something a little more reaslistic thatn the size fo the various liks or local routing policies. Frankly I have experienced some very serious traffic engineering problems using regular BGP with a mix of different media and suppliers. Try as I might I just could not direct incoming traffic the way I wanted it. There is not going to be any easy solution as to who controls traffic flow policies. There will always be conflicts between the sender, the receiver and the people in between. > > Michel. > > > 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 Oct 28 00:24:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17332 for ; Mon, 28 Oct 2002 00:24:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1862Q4-0005qe-00 for multi6-data@psg.com; Sun, 27 Oct 2002 21:26:32 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 1862Q1-0005q2-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 21:26:30 -0800 Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id D1CE11C; Mon, 28 Oct 2002 07:32:35 +0200 (EET) Message-ID: <3DBCCA65.7050507@nomadiclab.com> Date: Mon, 28 Oct 2002 07:25:57 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Tattam Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-10.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [I changed the subject line to reflect the contents of discussion.] Peter Tattam wrote: > I strongly believe that any solution which depends on crypto won't fly, mainly > on the grounds that it is my understanding that good crypto relies on PKI and > also requires significant cpu resources that may not be applicable to monster > servers or miniscule devices. Generally the nature of mobility is that crypto > is mandatory because of the dangerous environment that it operates within. The > only security requirement that a MH solution needs to conform to would be > equivalent to what we have in IPv4. I believe this requirement is fully met by > a syn/ack exchange of addresses on the primary addresses between the hosts. > While this does not preclude a man in the middle attack steal the connection, > neither does the BGP model preclude a man in the middle attack also in such a > scenario. I believe it could withstand a man on the side attack though. Well, I fully agree that there are problems with crypto. However, part of your worry is ungrounded, IMHO. The kind of crypto we are now taking about does *not* depend on PKI. It may even be possible to base it on symmetric crypto instead of public key crypto, thus alleviating some of the performance worries. OTOH, using public key crypto is so much easier that AFAIK nobody has yet seriously considered the symmetric alternatives. Why do I believe that crypto is probably needed? Well, *if* the goal of end-host multi-homing is to keep transport sessions flowing, it becomes equivalent with mobility, at least from security point of view. Let's consider the following scenario: 1. Alice contacts Bob from 10.0.0.1 2. Alice tells Bob that she is also reachable at 10.1.1.2 3. Alice stops answering to 10.0.0.1 4. Bob assumes that the path to 10.0.0.1 has failed and starts using 10.1.1.2 instead This is equivalent, from the security point of view, to 1. Alice contacts Bob from 10.0.0.1 2. Alice tells Bob that she has moved to 10.1.1.2 3. Bob starts using 10.1.1.2 instead of 10.0.0.1 Ergo, if someone can launch an attack against a mobility mechanism, she is also able to launch a similar attack against an equivalent end-host multi-homing mechanism. The level of protection needed is basically similar, and the same basic security solutions are applicable. Well, the multi-homing case (as well as the so called smooth handover case) is slightly easier to solve, since we can assume that the multi-homed host is (at least briefly) reachable through both addresses. However, the difference is quite small in practise. The resulting security protocols are fairly similar in both end-host mobility and end-host multihoming. The details differ more based on the exact nature of the mobility resp. multi-homing solution, not whether it is a question of end-host mobility or end-host multi-homing. If we forget about keeping the transport sessions flowing, or rely completely on mechanisms on the routing infrastructure, the story is different, of course. I am only referring to the case where multi-homing is visible to the end-hosts. Anyway, that's my current humble understanding, after having played with the ideas for some 2-3 years now. Maybe I am completely flawed in my analysis, and most probably I haven't layed out the underlying assumptions well enough in this message. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Oct 28 00:58:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18209 for ; Mon, 28 Oct 2002 00:58:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1862xQ-0008Dl-00 for multi6-data@psg.com; Sun, 27 Oct 2002 22:01:00 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 1862xN-00089p-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 22:00:58 -0800 Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id 2D8E41C; Mon, 28 Oct 2002 08:07:04 +0200 (EET) Message-ID: <3DBCD279.3050704@nomadiclab.com> Date: Mon, 28 Oct 2002 08:00:25 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org, hipsec Subject: Re: The state of IPv6 multihoming development References: <20021027233419.J32506-100000@sequoia.muada.com> In-Reply-To: <20021027233419.J32506-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [CC:in to hipsec from multi6] Iljitsch van Beijnum wrote: >> Thus, instead of trying to make a TCP connection to e.g. >> your-ip:25 I would create a TCP connection to hash(your-key):25. > >> Security would be trivial, since you would know the public >> key of your peer. The details are in the HIP drafts. > > Hm, what problem exactly does this solve that isn't solved by (for > instance) SSL? That is a subtle question, thanks for asking that. That is also exactly the question which has prevented HIP from becoming a WG a long time ago. I think that the multi6 list is perhaps not the right place to discuss that question, the answer is too long. If you are interested, let's move this point off-line, to the HIP mailing list, or some other better suited mailing list. And please read the NSRG report before we start to dive into this. > Also, how does the hash to IP address mapping work in the absence of a > hierarchy? How does a name to IP address mapping work today? Using DNS, for example. Or some other name resolution service. There are pure hash based name resolution services, dubbed "distributed hash tables" (DHT). I'm not an expert there, but I can dig up a couple of references if you are interested. > I'm not sure if I've said so clearly on this list, but over the last > month or so I've come to realize that it's probably too soon to create a > definitive multihoming solution. So it would be good to come up with > meta-solutions that enable different solutions to work together, or > provide a growth path from one solution to the other. I agree. Basically I wanted to point of the following: 1. Once we start to discuss solutions that require changes to the end host (and perhaps these "mudem"s), there is also the option of introducing a new name space, cryptographic or not. 2. End-host based multi-homing solutions *seem* to have the same security problems as (some) end-host mobility solutions. > ... More specifically: if we can make some sort of > identifier/locator seperation solution where the identifiers are simply > routable addresses, most of the ground work to move to crypto hash > identifiers is in place, and the only thing necessary is a good locator > discovery mechanism. If you create a solution where identifiers are simply routable addresses, you are, from my point of view, basically re-inventing Mobile IPv6. And since there are so many problems with Mobile IPv6, I am quite sceptical about such a design. Well, Mobile IPv6 works (probably) and the security problems have been solved, but the result is, well, large and complex. But perhaps I'm short sighted here, and you have something else in your mind. >> b) Resolving simultaneous movements (double jump). If both >> ends of a connection are mobile and move at the same time, >> they must somehow be able to reach each other after the >> movements. > > But what if the home agent becomes unreachable? If the end-host is multi-homed, either in reality or conceptually, there is no problem. You can consider the home agent as one multi-homed interface. You can have multiple home agents if you need to. Or none, temporarily. See the paper. > I read about a homeless mobility proposal somewhere a while ago, but I > haven't been able to find it again afterwards... That was our draft. Since then we moved our work to HIP, mainly due to security constraints. Maybe it would be the time to have a look at cheaper-than-PK crypto solutions for HIP. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Oct 28 01:50:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19222 for ; Mon, 28 Oct 2002 01:50:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1863kx-000BcR-00 for multi6-data@psg.com; Sun, 27 Oct 2002 22:52:11 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 1863ku-000Bc6-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 22:52:08 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id RAA00892; Mon, 28 Oct 2002 17:51:58 +1100 (EST) Date: Mon, 28 Oct 2002 17:51:58 +1100 (EST) From: Peter Tattam To: Pekka Nikander cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development) In-Reply-To: <3DBCCA65.7050507@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 28 Oct 2002, Pekka Nikander wrote: > [I changed the subject line to reflect the contents of discussion.] > > Peter Tattam wrote: > > > I strongly believe that any solution which depends on crypto won't fly, mainly > > on the grounds that it is my understanding that good crypto relies on PKI and > > also requires significant cpu resources that may not be applicable to monster > > servers or miniscule devices. Generally the nature of mobility is that crypto > > is mandatory because of the dangerous environment that it operates within. The > > only security requirement that a MH solution needs to conform to would be > > equivalent to what we have in IPv4. I believe this requirement is fully met by > > a syn/ack exchange of addresses on the primary addresses between the hosts. > > While this does not preclude a man in the middle attack steal the connection, > > neither does the BGP model preclude a man in the middle attack also in such a > > scenario. I believe it could withstand a man on the side attack though. > > Well, I fully agree that there are problems with crypto. However, > part of your worry is ungrounded, IMHO. The kind of crypto we are > now taking about does *not* depend on PKI. It may even be possible > to base it on symmetric crypto instead of public key crypto, thus > alleviating some of the performance worries. OTOH, using public > key crypto is so much easier that AFAIK nobody has yet seriously > considered the symmetric alternatives. > > Why do I believe that crypto is probably needed? Well, *if* the > goal of end-host multi-homing is to keep transport sessions > flowing, it becomes equivalent with mobility, at least from > security point of view. > > Let's consider the following scenario: > > 1. Alice contacts Bob from 10.0.0.1 > 2. Alice tells Bob that she is also reachable at 10.1.1.2 > 3. Alice stops answering to 10.0.0.1 > 4. Bob assumes that the path to 10.0.0.1 has failed and > starts using 10.1.1.2 instead This should be... 1. Alice at primary address 10.0.0.1 contacts Bob at primary address 10.10.0.1 and at the same time says that she is reachable also at 10.1.1.2 2. Bob responds by saying, ok you tell me that you are at 10.0.0.1 and 10.1.1.2, and I'm at 10.10.0.1 and also at 10.12.0.1 3. Alice says ok, that agrees with what I sent you and I'm responding back to you to say you're telling me you're at 10.10.0.1 and at 10.12.0.1. I'm still awaiting final confirmation. 4. Bob sends his final response saying yes, your response agrees with what I sent you. We both trust each other to send data on these addresses, but we agree now that no other addresses can be used from this point on. time passes... 5. Alice stops answering to 10.0.0.1 6. Bob knows already that alice might be listening at 10.1.1.2 and tries that address also. (Steps 1 to 4 *MUST* be done on the primary addresses. If that fails a new primary address should be chosen and the whole process starts again.) Been through this issue many times before. Both sides exchange the set of reachable addresses with a three way syn/ack handshake before any addresses are allowed to be switched. The strength of this is governed by the size of the ISS/IRS in TCP, which in recent times has been encouraged to have much more cryptographically strong properties. It is plausible to have a much larger nonce for this purpose included in the IPv6 option that is cryptographically strong enough to prevent any kind of guessing that is common in syn/ack hijacking. If the session doesn't reach an established state, nothing goes ahead. For the really paranoid, the only solution is signing the packets, but that implies there are either shared secrets or some kind of public key crypto. The difference between a MH solution and a mobility solution is that in the MH solution, both ends negotiate in advance all possible addresses because each end knows in advance all the possible addresses which can be used, and only the primary address pair is used for negotation. In mobility, the alternative addresses are generally not known in advance and hence crypto is required to establish trust that the change of address is authorized. Don't also forget that DNS provides MH information which can also be used to add some extra checking at least for destination addresses. It is unrealistic for the listening host to consult DNS for every incoming connection, although many sites do this as a matter of good practice anyway. > > This is equivalent, from the security point of view, to > > 1. Alice contacts Bob from 10.0.0.1 > 2. Alice tells Bob that she has moved to 10.1.1.2 > 3. Bob starts using 10.1.1.2 instead of 10.0.0.1 > > Ergo, if someone can launch an attack against a mobility > mechanism, she is also able to launch a similar attack against > an equivalent end-host multi-homing mechanism. The level of > protection needed is basically similar, and the same basic > security solutions are applicable. They are not the same for reasons mentioned above. The attack can be launched only during the exchange, but no other time. With mobility, the attack could be launched any time. I challenge the security people to work out an attack strategy which is not a man in the middle one, and then I will be perfectly happy to concede defeat. > > Well, the multi-homing case (as well as the so called smooth > handover case) is slightly easier to solve, since we can assume > that the multi-homed host is (at least briefly) reachable > through both addresses. However, the difference is quite small > in practise. The resulting security protocols are fairly similar > in both end-host mobility and end-host multihoming. The details > differ more based on the exact nature of the mobility resp. > multi-homing solution, not whether it is a question of end-host > mobility or end-host multi-homing. > > If we forget about keeping the transport sessions flowing, or > rely completely on mechanisms on the routing infrastructure, > the story is different, of course. I am only referring to the > case where multi-homing is visible to the end-hosts. > > Anyway, that's my current humble understanding, after having > played with the ideas for some 2-3 years now. Maybe I am > completely flawed in my analysis, and most probably I haven't > layed out the underlying assumptions well enough in this message. No problem. I would really like a definitive answer from the security heavyweights to finally put the matter to rest if possible. > > --Pekka Nikander > > > > -- 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 Oct 28 02:16:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28975 for ; Mon, 28 Oct 2002 02:16:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1864AO-000DMu-00 for multi6-data@psg.com; Sun, 27 Oct 2002 23:18:28 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #2) id 1864AL-000DMb-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 23:18:25 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9S7HoRa032216; Mon, 28 Oct 2002 08:17:50 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9S7Hf7V013458; Mon, 28 Oct 2002 08:17:41 +0100 Received: from dhcp22-101.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34014 from ; Mon, 28 Oct 2002 08:17:41 +0100 Message-Id: <3DB951C2.15958764@hursley.ibm.com> Date: Fri, 25 Oct 2002 16:14:26 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: Transport multihoming References: <20021024210103.E14896-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.6 required=5.0 tests=DATE_IN_PAST_48_96,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Why would we do that rather than rolling out SCTP? I can imagine an API trick to make SCTP look like TCP to a legacy app. The notion that we can solve it without host stack mods is pretty unlikely. Brian Iljitsch van Beijnum wrote: > > Greg, Peter, > > As I see it, the reason to have the multihoming functionality inside one > or more transport protocols is that the transport layer has end-to-end > knowledge that makes it possible to make better multihoming decisions. > > Would it be possible to have a modified TCP talk to a non-modified TCP > through some kind of "mudem" (multihomer/demultihomer), without loss of > the core multihoming functionality, and without the "mudem" having to > keep long-term state? > > This would create a much more attractive deployment path as people can > choose to either upgrade hosts or put them behind a box to provide the > multihoming functionality. > > It also makes it possible to move the multihoming decision making to a > place where it can be better controlled if this is desired. > > Iljitsch (or just call me dr. Frankenstein) -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-multi6@ops.ietf.org Mon Oct 28 02:16:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28989 for ; Mon, 28 Oct 2002 02:16:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1864AY-000DNR-00 for multi6-data@psg.com; Sun, 27 Oct 2002 23:18:38 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #2) id 1864AV-000DMf-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 23:18:35 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9S7HkRP020480; Mon, 28 Oct 2002 08:17:51 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9S7Hgrc120156; Mon, 28 Oct 2002 08:17:42 +0100 Received: from dhcp22-101.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA20212 from ; Mon, 28 Oct 2002 08:17:41 +0100 Message-Id: <3DB95775.17B8ECD9@hursley.ibm.com> Date: Fri, 25 Oct 2002 16:38:45 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: "J. Noel Chiappa" , multi6@ops.ietf.org Subject: PI/metro/geo [Re: The state of IPv6 multihoming development] References: <20021024202432.I14896-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.3 required=5.0 tests=DATE_IN_PAST_48_96,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On Thu, 24 Oct 2002, J. Noel Chiappa wrote: > > > E.g. if a (large enough) bunch of customers band together and create an > > exchange, which buys service from multiple ISP's, and which is given an > > address which is visible over the same scope as those ISP's, and the > > customers are addressed as part of that exchange, you meet the policy goal > > (being able to change providers) *without* so-called "PI" addresses. But the > > addresses are still connectivity-based. > > Semantics. The exchange would be the "provider" here. The problem with this (and the reason I have serious doubts about Tony's PI proposal, and all geographical proposals going back at least to Bill Simpson's metro proposal years ago), is There is no economic reason to create such an exchange. If we could get past that, of course it works. And there isn't much the IETF can do about it. We could perfectly well make the case to get the PI block from IANA, but that doesn't get it deployed. As Noel notes, you don't even need PI space to create an exchange-based addressing scheme. You don't even need PA space - you could build a metro exchange using 6to4 space if you were desparate. > BTW, this looks an awful lot like geographical addressing and > aggregating. Of course. > Now if we virtualize the exchange that saves a lot of iron. Pls explain. Brian From owner-multi6@ops.ietf.org Mon Oct 28 02:17:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29005 for ; Mon, 28 Oct 2002 02:17:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1864AX-000DNH-00 for multi6-data@psg.com; Sun, 27 Oct 2002 23:18:37 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #2) id 1864AU-000DMe-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 23:18:34 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9S7HkRa035120; Mon, 28 Oct 2002 08:17:51 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9S7He7V042296; Mon, 28 Oct 2002 08:17:41 +0100 Received: from dhcp22-101.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23500 from ; Mon, 28 Oct 2002 08:17:35 +0100 Message-Id: <3DB9508A.EA30C303@hursley.ibm.com> Date: Fri, 25 Oct 2002 16:09:14 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: Iljitsch van Beijnum , RJ Atkinson , multi6@ops.ietf.org Subject: Re: Recommendation v Requirements [Re: The state of IPv6 multihoming development References: <2B81403386729140A3A899A8B39B046405E3AD@server2000> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.3 required=5.0 tests=DATE_IN_PAST_48_96,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel Py wrote: > > > Iljitsch van Beijnum wrote: > > Although nobody bothered to answer directly, it seems there > > is consensus that the requirements can be accepted with some > > small changes. Good. > > I am opposed to it as-is. The small changes are not going to change the > outcome, and I am sure that I am not the only protocol developer that > does not want his work to be cancelled because it does not meet the > requirements. > > Peter, Itojun, and others: this is valid for you as well. Please see the subject field. The proposal is to remove the word "requirements" and normative language. This solves your perceived problem. Can't we just get past this and publish it? Brian From owner-multi6@ops.ietf.org Mon Oct 28 02:24:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29090 for ; Mon, 28 Oct 2002 02:24:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1864ID-000E01-00 for multi6-data@psg.com; Sun, 27 Oct 2002 23:26:33 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 1864IA-000Dyb-00 for multi6@ops.ietf.org; Sun, 27 Oct 2002 23:26:30 -0800 Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by n97.nomadiclab.com (Postfix) with ESMTP id 120A51C; Mon, 28 Oct 2002 09:32:37 +0200 (EET) Message-ID: <3DBCD878.1080406@nomadiclab.com> Date: Mon, 28 Oct 2002 09:26:00 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021024 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Tattam Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Peter Tattam wrote: >> Why do I believe that crypto is probably needed? Well, *if* the >> goal of end-host multi-homing is to keep transport sessions >> flowing, it becomes equivalent with mobility, at least from >> security point of view. > > 1. Alice at primary address 10.0.0.1 contacts Bob at primary > address 10.10.0.1 and at the same time says > that she is reachable also at 10.1.1.2 > > 2. Bob responds by saying, ok you tell me that you are at 10.0.0.1 and > 10.1.1.2, and I'm at 10.10.0.1 and also at 10.12.0.1 > > 3. Alice says ok, that agrees with what I sent you and I'm responding back > to you to say you're telling me you're at 10.10.0.1 and at 10.12.0.1. I'm > still awaiting final confirmation. > > 4. Bob sends his final response saying yes, your response agrees with what > I sent you. We both trust each other to send data on these addresses, but we > agree now that no other addresses can be used from this point on. > > time passes... > > 5. Alice stops answering to 10.0.0.1 > 6. Bob knows already that alice might be listening at 10.1.1.2 and tries > that address also. I'm quite happy with your extended description instead of my more compact one, no problem with that. However, there is a potential flooding DoS problem with the scenario: 1. Alice the attacker contacts 20000 hosts, tells them that her primary address is 10.0.0.1 and she is also reachable at 10.1.1.2 She may make the contacts one at time if she has herself only limited network capability, leaving the connections dormant. She also performs the three way handshake as outlined above. 2. Alice orders a large data stream from each of the 20000 hosts, perhaps once at a time, and *immediately* stops answering at 10.0.0.1 for that particular host. Preferably she uses a service where the data stream will start with a delay, e.g. streaming video which will start only somewhat later. 3. The 20000 hosts notice, one by one, that Alice is not answering any more at 10.0.0.1, and divert the large data stream to 10.1.1.2. To make the situation worse, Alice may try to send faked canned acknowledgements that look like they were coming from 10.1.1.2. Notice that there does not have to be any hosts at 10.1.1.2, and therefore the 20000 hosts are not receiving ICMP replies or TCP RSTs. The real target might be the network 10.1.1.0/24. 4. As a result, the 10.1.1.0/24 network is flooded with unwanted traffic. The fix is simple, but needed: Either a) during the initial negotiation the hosts check the reachability of the secondary addresses, and make sure, through some simple and cheap crypto, that it is the same host answering at all of the given addresses, or b) once the primary address becomes unreachable, the hosts check, using some simple and cheap crypto, that it is the same host answering at the secondary address, *before* sending any larger amounts of data to that secondary address. If you look at the current MIPv6 security solution, it is essentially a variation combined a) and b); a) since a MIPv6 host is multihomed at its home address and care-of-address and b) since the care-of-address changes in an unpredictable way during a handoff. The essense: You *have* to check that it is the *same* host that is answering in the secondary address *before* you send any larger amounts of data to that address. For what I've been following SCTP etc, it looks like the possibility of such a flooding attack has been neglected. Using that "simple and cheap" crypto is not very secure, of course. PK makes it more secure. But people seemed to agree that it is good enough for MIPv6; maybe it would be good enough for end-host multi-homing as well. Hence also my call for non-PK crypto for HIP, since HIP is more than just security. [In principle I agree with your "strengthening TCP ISS/IRS" view.] > The difference between a MH solution and a mobility solution is that in the MH > solution, both ends negotiate in advance all possible addresses because each > end knows in advance all the possible addresses which can be used, and only the > primary address pair is used for negotation. In mobility, the alternative > addresses are generally not known in advance and hence crypto is required to > establish trust that the change of address is authorized. IMHO, that is quite a black&white view. I think that the majority of end-host multihoming cases will be shades of gray there in between, e.g. mobile devices with multiple alternative network interfaces. >> Ergo, if someone can launch an attack against a mobility >> mechanism, she is also able to launch a similar attack against >> an equivalent end-host multi-homing mechanism. The level of >> protection needed is basically similar, and the same basic >> security solutions are applicable. > > They are not the same for reasons mentioned above. The attack can be launched > only during the exchange, but no other time. With mobility, the attack could > be launched any time. I slightly disagree for two reasons: Firstly, I don't believe in the black&white multi-homing vs. mobility distinction, but I see the shades of gray. Secondly, IMHO the flooding attacks look very much the same, even though the details differ. The expired draft-aura-mipv6-bu-attacks-01.txt had pretty good text about the flooding attacks. It is still available at Google cache. > I challenge the security people to work out an attack strategy which is not a > man in the middle one, and then I will be perfectly happy to concede defeat. Maybe the flooding above qualifies as one? :-) > No problem. I would really like a definitive answer from the security > heavyweights to finally put the matter to rest if possible. Well, the security people think that I'm a mobility person, knowing nuthin about security, and the mobility people think that I'm a security Steve, knowing nuthing about mobility. So take your grain of salt. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Oct 28 03:01:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00009 for ; Mon, 28 Oct 2002 03:01:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1864ru-000Gvl-00 for multi6-data@psg.com; Mon, 28 Oct 2002 00:03:26 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 1864ro-000GvA-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 00:03:20 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id TAA08519; Mon, 28 Oct 2002 19:03:09 +1100 (EST) Date: Mon, 28 Oct 2002 19:03:09 +1100 (EST) From: Peter Tattam To: Pekka Nikander cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development) In-Reply-To: <3DBCD878.1080406@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 28 Oct 2002, Pekka Nikander wrote: > Peter Tattam wrote: > >> Why do I believe that crypto is probably needed? Well, *if* the > >> goal of end-host multi-homing is to keep transport sessions > >> flowing, it becomes equivalent with mobility, at least from > >> security point of view. > > > > > 1. Alice at primary address 10.0.0.1 contacts Bob at primary > > address 10.10.0.1 and at the same time says > > that she is reachable also at 10.1.1.2 > > > > 2. Bob responds by saying, ok you tell me that you are at 10.0.0.1 and > > 10.1.1.2, and I'm at 10.10.0.1 and also at 10.12.0.1 > > > > 3. Alice says ok, that agrees with what I sent you and I'm responding back > > to you to say you're telling me you're at 10.10.0.1 and at 10.12.0.1. I'm > > still awaiting final confirmation. > > > > 4. Bob sends his final response saying yes, your response agrees with what > > I sent you. We both trust each other to send data on these addresses, but we > > agree now that no other addresses can be used from this point on. > > > > time passes... > > > > 5. Alice stops answering to 10.0.0.1 > > 6. Bob knows already that alice might be listening at 10.1.1.2 and tries > > that address also. > > I'm quite happy with your extended description instead of my > more compact one, no problem with that. > > However, there is a potential flooding DoS problem with the scenario: > > 1. Alice the attacker contacts 20000 hosts, tells them that her > primary address is 10.0.0.1 and she is also reachable at 10.1.1.2 > She may make the contacts one at time if she has herself only > limited network capability, leaving the connections dormant. > She also performs the three way handshake as outlined above. > > 2. Alice orders a large data stream from each of the 20000 hosts, > perhaps once at a time, and *immediately* stops answering > at 10.0.0.1 for that particular host. Preferably she uses > a service where the data stream will start with a delay, e.g. > streaming video which will start only somewhat later. > > 3. The 20000 hosts notice, one by one, that Alice is not answering > any more at 10.0.0.1, and divert the large data stream to 10.1.1.2. > To make the situation worse, Alice may try to send faked canned > acknowledgements that look like they were coming from 10.1.1.2. > Notice that there does not have to be any hosts at 10.1.1.2, and > therefore the 20000 hosts are not receiving ICMP replies or > TCP RSTs. The real target might be the network 10.1.1.0/24. > > 4. As a result, the 10.1.1.0/24 network is flooded with unwanted traffic. > > The fix is simple, but needed: Either > > a) during the initial negotiation the hosts check the reachability > of the secondary addresses, and make sure, through some simple > and cheap crypto, that it is the same host answering at all of > the given addresses, or > > b) once the primary address becomes unreachable, the hosts check, > using some simple and cheap crypto, that it is the same host > answering at the secondary address, *before* sending any larger > amounts of data to that secondary address. How about a variation on both of these... c) only the primary address remains in an established state. Secondary addresses remain in a syn-received state until required to be used in which case the syn-ack and ack packets have to also be sent on the secondary addresses using the same nonce. If it doesn't arrive on the same host, the flood storm will be immediately quenched. (the decision to send a RST might be a policy decision on the host). > > If you look at the current MIPv6 security solution, it is essentially > a variation combined a) and b); a) since a MIPv6 host is multihomed > at its home address and care-of-address and b) since the care-of-address > changes in an unpredictable way during a handoff. > > The essense: You *have* to check that it is the *same* host that > is answering in the secondary address *before* you send any larger > amounts of data to that address. > > For what I've been following SCTP etc, it looks like the possibility > of such a flooding attack has been neglected. > > Using that "simple and cheap" crypto is not very secure, of course. > PK makes it more secure. But people seemed to agree that it is > good enough for MIPv6; maybe it would be good enough for end-host > multi-homing as well. Hence also my call for non-PK crypto for HIP, > since HIP is more than just security. > > [In principle I agree with your "strengthening TCP ISS/IRS" view.] > > > The difference between a MH solution and a mobility solution is that in the MH > > solution, both ends negotiate in advance all possible addresses because each > > end knows in advance all the possible addresses which can be used, and only the > > primary address pair is used for negotation. In mobility, the alternative > > addresses are generally not known in advance and hence crypto is required to > > establish trust that the change of address is authorized. > > IMHO, that is quite a black&white view. I think that the majority > of end-host multihoming cases will be shades of gray there in between, > e.g. mobile devices with multiple alternative network interfaces. > > > >> Ergo, if someone can launch an attack against a mobility > >> mechanism, she is also able to launch a similar attack against > >> an equivalent end-host multi-homing mechanism. The level of > >> protection needed is basically similar, and the same basic > >> security solutions are applicable. > > > > They are not the same for reasons mentioned above. The attack can be launched > > only during the exchange, but no other time. With mobility, the attack could > > be launched any time. > > I slightly disagree for two reasons: Firstly, I don't believe > in the black&white multi-homing vs. mobility distinction, but I > see the shades of gray. Secondly, IMHO the flooding attacks > look very much the same, even though the details differ. > > The expired draft-aura-mipv6-bu-attacks-01.txt had pretty good > text about the flooding attacks. It is still available at > Google cache. > > > I challenge the security people to work out an attack strategy which is not a > > man in the middle one, and then I will be perfectly happy to concede defeat. > > Maybe the flooding above qualifies as one? :-) > > > No problem. I would really like a definitive answer from the security > > heavyweights to finally put the matter to rest if possible. > > Well, the security people think that I'm a mobility person, knowing > nuthin about security, and the mobility people think that I'm a > security Steve, knowing nuthing about mobility. So take your > grain of salt. > > --Pekka Nikander > > > -- 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 Oct 28 03:03:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00064 for ; Mon, 28 Oct 2002 03:03:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1864uT-000HFm-00 for multi6-data@psg.com; Mon, 28 Oct 2002 00:06:05 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 1864uS-000HCw-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 00:06:04 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 3F36334437; Mon, 28 Oct 2002 00:14:24 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9S85TiI006123; Mon, 28 Oct 2002 00:05:29 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: The state of IPv6 multihoming development Date: Mon, 28 Oct 2002 00:05:28 -0800 Message-ID: Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ9nvmY5RQNrGTTQTmWPz+UDAalwwAuWCmQ From: "Tony Li" To: "Masataka Ohta" Cc: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=0.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA00064 | What a stupid suggestion. Thank you for your opinion. | It makes the border router the single point of failure totally | destroying the benefit of multihoming. Or.... you could use multiple border routers. | If you try to have multiple border routers with complex redundancy | protocol, there always is simple failure mode of the protocol. Yes, but you don't NEED a complex redundancy protocol. You only need the group of border routers to make a consistent decision about the optimal exit route. We have a tool that does this already. ;-) Tony From owner-multi6@ops.ietf.org Mon Oct 28 03:12:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00249 for ; Mon, 28 Oct 2002 03:12:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18653A-000Hjr-00 for multi6-data@psg.com; Mon, 28 Oct 2002 00:15:04 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 186537-000HgX-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 00:15:01 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id DD9BD34437; Mon, 28 Oct 2002 00:23:24 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9S8EUiI006478; Mon, 28 Oct 2002 00:14:30 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: The state of IPv6 multihoming development Date: Mon, 28 Oct 2002 00:14:30 -0800 Message-ID: Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ9sT1KKA0+Q5StT3q62Oy9+hvBigAp8j6g From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA00249 | If the multihoming processing is done outside the host, | then packets all | packets must be presented to the host with the identifiers | as the source | and destinations addresses. If this is done inside the host | then this | isn't strictly required, but it is likely the transport | layer will want | to see just the identifiers so the IP layer will have to | reconstitute | those. Fair enough, but if we go down the GSE direction, the packet has the identifier in it already when it arrives at the host and the identifier is never modified in flight. In my book, that gives us the desired end-to-end connectivity. | > The host should select the identifier, both for itself and for the | > destination. The border router selects the locators for both the | > source and the destination. This allows the border | router to implement | > policy in a reasonable way. | | Agree. However, do we want to involve a border router in the locator | discovery process? If you want to address Craig's concern about being able to affect locator policy for the entire enterprise in a scalable way, you kinda have to. | The basic idea is simple: the IP addresses the transport layer uses | become the identifiers of a session. In transit, these identifiers | may/must be replaced by locators, but they identifiers are restored | before the packet reaches the transport layer at the other end. Yes, but if you do wholesale identifier replacement, then you get into trouble with protocols carrying identifiers around above the network layer. A nice way of fixing this is to establish the principle that locators are never carried around above the network layer, only the identifier. | Discovery is hard to do, but if we can solve the associated | problems it | provides a much stronger mechanism because then a host can have a | single, portable identifier. It would be good if we could provide an | upgrade path from negotiation to discovery. I have to agree. I prefer discovery as well. Tony From owner-multi6@ops.ietf.org Mon Oct 28 03:21:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00442 for ; Mon, 28 Oct 2002 03:21:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1865By-000ID2-00 for multi6-data@psg.com; Mon, 28 Oct 2002 00:24:10 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 1865Bw-000I86-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 00:24:08 -0800 Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by n97.nomadiclab.com (Postfix) with ESMTP id 1F2941C; Mon, 28 Oct 2002 10:30:15 +0200 (EET) Message-ID: <3DBCE5F9.7030301@nomadiclab.com> Date: Mon, 28 Oct 2002 10:23:37 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021024 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Tattam Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Peter Tattam wrote: >>The fix is simple, but needed: Either >> >> a) during the initial negotiation the hosts check the reachability >> of the secondary addresses, and make sure, through some simple >> and cheap crypto, that it is the same host answering at all of >> the given addresses, or >> >> b) once the primary address becomes unreachable, the hosts check, >> using some simple and cheap crypto, that it is the same host >> answering at the secondary address, *before* sending any larger >> amounts of data to that secondary address. > > > How about a variation on both of these... > > c) only the primary address remains in an established state. Secondary > addresses remain in a syn-received state until required to be used in which > case the syn-ack and ack packets have to also be sent on the secondary > addresses using the same nonce. If it doesn't arrive on the same host, the > flood storm will be immediately quenched. (the decision to send a RST might be > a policy decision on the host). I think that approach could be developed as well. However, maybe you should pay attention to the possibility of faked acks. That is, if Alice is the attacker, she knows the nonce. Thus, she might be able to anticipate the forthcoming syn-ack containing the nonce, and be able to ack that even if she doesn't see the syn-ack. Thus, we must combine a) the nonce used on the primary connection, and b) a fresh nonce generated for the syn-ack on the secondary address. If you hash these together, you, again, have a solution very similar to that of Mobile IPv6. --Pekka From owner-multi6@ops.ietf.org Mon Oct 28 03:43:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00644 for ; Mon, 28 Oct 2002 03:43:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1865WX-000JEm-00 for multi6-data@psg.com; Mon, 28 Oct 2002 00:45:25 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 1865WV-000JEa-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 00:45:23 -0800 From: Masataka Ohta Message-Id: <200210280835.RAA10387@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA10387; Mon, 28 Oct 2002 17:35:17 +0900 Subject: Re: The state of IPv6 multihoming development In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0BF6@Esealnt861.al.sw.ericsson.se> from "Hesham Soliman (EAB)" at "Oct 27, 2002 09:28:46 pm" To: "Hesham Soliman (EAB)" Date: Mon, 28 Oct 2002 17:35:16 +0859 () CC: "'Iljitsch van Beijnum'" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hesham; > > However, mobility as I understand it assumes things, > > especially the home agent, are reachable. In multihoming, > > this definately isn't an assumption we can make. > => This is not an issue. It depends on where your > HA is located. I can write something if there is > enough interest, but end host approaches don't > seem to be interesting to most people on this list. Multihoming and mobility are related, because, if we are to support multihoming, we should also support multiple home agents for the same degree of robustness. Note that, for security at this level, cookie is just enough. Masataka Ohta PS Our multihoming code, of course, supports such mobility with cookie based security. From owner-multi6@ops.ietf.org Mon Oct 28 04:00:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00962 for ; Mon, 28 Oct 2002 04:00:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1865mE-000K2x-00 for multi6-data@psg.com; Mon, 28 Oct 2002 01:01:38 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 1865mB-000K2a-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 01:01:36 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id UAA14567; Mon, 28 Oct 2002 20:01:22 +1100 (EST) Date: Mon, 28 Oct 2002 20:01:22 +1100 (EST) From: Peter Tattam To: Pekka Nikander cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development) In-Reply-To: <3DBCE5F9.7030301@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 28 Oct 2002, Pekka Nikander wrote: > Peter Tattam wrote: > > > > How about a variation on both of these... > > > > c) only the primary address remains in an established state. Secondary > > addresses remain in a syn-received state until required to be used in which > > case the syn-ack and ack packets have to also be sent on the secondary > > addresses using the same nonce. If it doesn't arrive on the same host, the > > flood storm will be immediately quenched. (the decision to send a RST might be > > a policy decision on the host). > > I think that approach could be developed as well. However, > maybe you should pay attention to the possibility of faked > acks. That is, if Alice is the attacker, she knows the > nonce. Thus, she might be able to anticipate the forthcoming > syn-ack containing the nonce, and be able to ack that even > if she doesn't see the syn-ack. Thus, we must combine > a) the nonce used on the primary connection, and > b) a fresh nonce generated for the syn-ack on the secondary > address. Hmm.. good point. What about if we turn the process around backward. The site which decides the other end is unreachable starts a fresh exchange on the new address pair (although it is still a secondary address and no new addresses may be introduced) with a separate nonce for each unused destination address (as seen by the host originating packets). The new nonce has to be cryptographically strong enough to be unguessable. i.e. 5. Bob sees Alice is not responding to the primary address and sends a new MH SYN-Secondary to the secondary address, but with new originating nonce. 6. Alice responds with a MH SYN-Secondary ACK-Secondary (with same addresses as before). (original nonce or new nonce???) 7. Bob sends MH ACK-Secondary as with MH ACK-primary. We add some extra signals... for Primary MH address establishment we use as before.. SYN-primary and ACK-primary control signals (like SYN and ACK bits in TCP). for each Secondary MH address establishment we use two new signals.. SYN-secondary and ACK-secondary control signals A SYN secondary must be ignored if there is no MH state with the primary address in the ESTABLISHED state. Also, I think the address list should match exactly the same as the primary address. Would that solve the problems? > > If you hash these together, you, again, have a solution very > similar to that of Mobile IPv6. I am not sure if that is totally necessary if we exchange the same addresses as before along with a new originating nonce (so the packet looks almost identical to a primary MH SYN address packet except for nonce and control bits) > > --Pekka > > > -- 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 Oct 28 04:03:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01009 for ; Mon, 28 Oct 2002 04:03:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1865ps-000KHE-00 for multi6-data@psg.com; Mon, 28 Oct 2002 01:05:24 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 1865pq-000KH2-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 01:05:22 -0800 From: Masataka Ohta Message-Id: <200210280856.RAA10663@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA10663; Mon, 28 Oct 2002 17:56:44 +0900 Subject: Re: The state of IPv6 multihoming development In-Reply-To: from Tony Li at "Oct 28, 2002 00:05:28 am" To: Tony Li Date: Mon, 28 Oct 2002 17:56:42 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-4.9 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_05_08 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony; > | It makes the border router the single point of failure totally > | destroying the benefit of multihoming. > Or.... you could use multiple border routers. By doing everything on hosts, yes, we can. > | If you try to have multiple border routers with complex redundancy > | protocol, there always is simple failure mode of the protocol. > > > Yes, but you don't NEED a complex redundancy protocol. You only need > the group of border routers to make a consistent decision about the > optimal exit route. We have a tool that does this already. ;-) You don't. You need secure transport (MPLS?) between border routers to prohibits hosts select the optimal exit routes by themselves. At the same time, you need extended ICMP redirect for route optimization to let border routers teach the hosts locators to the optimal exit routes to be selected for latter communication. It, of course, is obvious that above two mutually contradict that you should make your protocol even more complex to obscure the contradiction. I, instead, simply make all the selection on the hosts. Masataka Ohta From owner-multi6@ops.ietf.org Mon Oct 28 04:57:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01883 for ; Mon, 28 Oct 2002 04:57:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1866gD-000N2d-00 for multi6-data@psg.com; Mon, 28 Oct 2002 01:59:29 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1866gA-000N2Q-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 01:59:27 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9S9x1o33937; Mon, 28 Oct 2002 10:59:02 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 28 Oct 2002 10:59:01 +0100 (CET) From: Iljitsch van Beijnum To: Michel Py cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <2B81403386729140A3A899A8B39B046405E3C1@server2000> Message-ID: <20021028104850.Y32506-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk [Can everyone please clean up those CC lists once in a while? I get two copies of each message which really doesn't bring me twice the joy.] On Sun, 27 Oct 2002, Michel Py wrote: > That being said, Craig has some legitimate traffic shaping concerns. > Even though the host might not make direct routing decisions, by > choosing either which of its own addresses it's going to use or which of > the destination's addresses it's going to use, the host itself takes a > traffic shaping decision, which is not something that Craig wants and I > support him on that. There are two cases: 1. The multihoming functionality it implemented in a separate box. In this case, you have all the traffic engineering knobs you'll ever need in this box. (Which will provide much better traffic engineering functionality than current BGP mechanisms, although at the expense of more work for thix box.) 2. The multihoming functionality is implemented in individual hosts. Without additional mechanisms, you have to revert to rather crude methods to do traffic engineering: simply drop enough packets to make the host switch to another IP address. Alternatively, we can come up with a mechanism for routers to inform hosts which exit they should use. As I explained in an earlier message, if the routing decisions are also based on the source address in the packets, it should be possible to control both the outgoing and incoming path for each flow. That's pretty much the holy grail of traffic engineering. > In short: a large organization needs to be able to engineer traffic, > which I don't realistically see happening when individual hosts can take > decisions that can affect traffic engineering. The host controls the traffic, but that doesn't mean the host gets to decide. The same way the driver gets to control the car, but he had better not drive the wrong way in a one way street. From owner-multi6@ops.ietf.org Mon Oct 28 05:10:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02027 for ; Mon, 28 Oct 2002 05:10:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1866sL-000Nin-00 for multi6-data@psg.com; Mon, 28 Oct 2002 02:12:01 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1866sJ-000NiZ-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 02:11:59 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9SABWV33957; Mon, 28 Oct 2002 11:11:35 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 28 Oct 2002 11:11:32 +0100 (CET) From: Iljitsch van Beijnum To: Tony Hain cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <048e01c27e28$eb1a82d0$4b194104@eagleswings> Message-ID: <20021028110302.C32506-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 27 Oct 2002, Tony Hain wrote: > > I don't see any relationship with interdomain multicast, so > > the fact that this has been hard to deploy in the past (and > > unless I'm mistaken the scalability problems have now been > > largely solved) doesn't say anything about translation mechanisms. > Passing around state between administrative entities is always a trust > problem. I don't think we are doing that here, unless you count the fact that the administrative domains where each endpoint is located contain state that must match that in the other, but this is normal TCP behavior. Compare to NAT: usually, both the NAT box and the host sitting behind it are part of the same administrative domain, or there is another reason there is implicit trust. (For instance, the NAT box is located at a service provider and you pay your service provider to be trustworthy to some degree.) Obviously, having the multihoming functionality in a potentially hostile box isn't going to fly. > > And if for the truly huge networks this solution isn't > > viable, they can always use IPv4-style multihoming. (But > > they'd still need to implement all of this in order to be > > able to talk to others who use multi-address > > multihoming.) > We will end up with a system that looks like IPv4 muti-homing to the > sites that want that, but scales better for the service providers. > Anything less on either front is a non-starter. Truly huge in this context would be fortune 500 or something like that. For smaller, but still reasonably large sites, having the multihoming functionality in each host is still too much headache, that's why I think it's important to be able to offload the necessary processing to a relatively small number of boxes at the edges of the network. To the internal network this will look like traditional IPv4-style multihoming, to the service providers it looks like single homing. The only downside is that the other end has to implement something similar. That's why we also need to have it in the host stacks, even for hosts that don't multihome themselves. From owner-multi6@ops.ietf.org Mon Oct 28 05:31:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02376 for ; Mon, 28 Oct 2002 05:31:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1867Cj-000Oy5-00 for multi6-data@psg.com; Mon, 28 Oct 2002 02:33:05 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1867Ch-000Oxo-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 02:33:03 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9SAWdU33978; Mon, 28 Oct 2002 11:32:39 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 28 Oct 2002 11:32:39 +0100 (CET) From: Iljitsch van Beijnum To: Michel Py cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <2B81403386729140A3A899A8B39B046405E3C3@server2000> Message-ID: <20021028111324.B32506-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 27 Oct 2002, Michel Py wrote: > Here's the scenario: the home/soho host that is multihomed with cable > and dsl makes a choice on which of its own addresses (the cable one, or > the dsl one) to use. This choice will dictate on which pipe the return > traffic from the web server to the requesting host goes. Actually it doesn't, twice. First of all, in order to really be multihomed, both addresses must be viable. So if the HTTP farm decides to direct its traffic to the other address, Joe can't really stop them, other than not advertise this address in the first place. Also, presumably, both of Joe's addresses are reachable over both of the HTTP farm's uplinks. If the HTTP farm is smart enough to be able to direct outgoing traffic depening on the traffic engineering needs rather than simply the destination address, they can route each of Joe's addresses over either of their uplinks as desired. And even if they don't have this capability, it's still 50% chance that both of Joe's addresses are routed over the same uplink so which address they use to reach Joe doesn't matter for traffic engineering purposes. > This is what we really are talking about here: Joe-six-pack's PC thinks > the ping to the cable default gateway is better than the ping to the dsl > default gateway and chooses its own source address to be the cable's > one. > And this, gentlemen, is *not* what I call traffic engineering. So what's your definition? The Right Thing for Joe's PC would be to measure the end-to-end delay, packet loss and bandwidth over both links and use the one that best suits his application. However, this is complex enough to NOT solve this at this stage. We may want to provide some hooks so people can do this later, though. From owner-multi6@ops.ietf.org Mon Oct 28 06:29:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03519 for ; Mon, 28 Oct 2002 06:29:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18686m-0002CB-00 for multi6-data@psg.com; Mon, 28 Oct 2002 03:31:00 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18686b-0002BK-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 03:30:50 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03395; Mon, 28 Oct 2002 06:28:26 -0500 (EST) Message-Id: <200210281128.GAA03395@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-van-beijnum-multi6-isp-int-aggr-00.txt Date: Mon, 28 Oct 2002 06:28:25 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Provider-Internal Aggregation based on Geography to Support Multihoming in IPv6 Author(s) : I. van Beijnum Filename : draft-van-beijnum-multi6-isp-int-aggr-00.txt Pages : 10 Date : 2002-10-25 Current 6bone backbone routing guidelines prohibit traditional multihoming in IPv6, because current IPv4-style multihoming doesn't scale. This stands in the way of successful adoption of IPv6. The solution outlined in this memo proposes aggregating the routing information for multihomed destinations inside service provider networks based on geography to accomplish scalable multihoming in IPv6 using current protocols and implementations. This solution does not require network operators to increase the density of interconnection; nor does it require significant cooperation or simultaneous adoption. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-isp-int-aggr-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-van-beijnum-multi6-isp-int-aggr-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-van-beijnum-multi6-isp-int-aggr-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: <2002-10-25110443.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-van-beijnum-multi6-isp-int-aggr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-van-beijnum-multi6-isp-int-aggr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-25110443.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Mon Oct 28 08:30:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08192 for ; Mon, 28 Oct 2002 08:30:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1869yy-0008ro-00 for multi6-data@psg.com; Mon, 28 Oct 2002 05:31:04 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 1869yv-0008qf-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 05:31:01 -0800 Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by n97.nomadiclab.com (Postfix) with ESMTP id 8C8DE1C; Mon, 28 Oct 2002 15:37:07 +0200 (EET) Message-ID: <3DBD2DE7.5040806@nomadiclab.com> Date: Mon, 28 Oct 2002 15:30:31 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021024 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Tattam Cc: multi6@ops.ietf.org Subject: Re: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Peter Tattam wrote: > What about if we turn the process around backward. The site which decides the > other end is unreachable starts a fresh exchange on the new address pair > (although it is still a secondary address and no new addresses may be > introduced) with a separate nonce for each unused destination address (as seen > by the host originating packets). The new nonce has to be cryptographically > strong enough to be unguessable. > > i.e. > > 5. Bob sees Alice is not responding to the primary address and sends a new MH > SYN-Secondary to the secondary address, but with new originating nonce. > > 6. Alice responds with a MH SYN-Secondary ACK-Secondary (with same addresses > as before). (original nonce or new nonce???) > > 7. Bob sends MH ACK-Secondary as with MH ACK-primary. > > We add some extra signals... > > for Primary MH address establishment we use as before.. > > SYN-primary and ACK-primary control signals (like SYN and ACK bits in TCP). > > for each Secondary MH address establishment we use two new signals.. > > SYN-secondary and ACK-secondary control signals > > > A SYN secondary must be ignored if there is no MH state with the primary > address in the ESTABLISHED state. Also, I think the address list should match > exactly the same as the primary address. > > Would that solve the problems? Maybe. I'd have to see a much more specific description before I could analyze it for possible holes. But as a quick evaluation, maybe the address list + the existense of a higher layer context would work well enough. But, IMHO, we are now going too far into a transport specific solution space. There are other problems with transport-only solutions, like consistency between different parallal transport connections, the amount of signalling when changing from primary to secondary etc. I fully support Iljitsch in the call for an architectural discussion. That was the reason why I chimed in: instead of trying to hack end-host multi-homing support into TCP or IP, maybe it would be the right time to consider a new name space. And if not, taking a good look at SCTP, as Brian suggested, might be the right road. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Oct 28 09:03:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09726 for ; Mon, 28 Oct 2002 09:03:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186AWP-000Atd-00 for multi6-data@psg.com; Mon, 28 Oct 2002 06:05:37 -0800 Received: from pa-monroeville1b-61.pit.adelphia.net ([24.53.182.61] helo=localhost) by psg.com with esmtp (Exim 3.36 #2) id 186AWM-000Ary-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 06:05:34 -0800 Received: from [192.168.1.100] (localhost [127.0.0.1]) by localhost (8.12.2/8.12.2) with ESMTP id g9SE182O008159; Mon, 28 Oct 2002 09:01:10 -0500 (EST) Date: Mon, 28 Oct 2002 09:01:07 -0500 From: "Michael H. Lambert" To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Message-ID: <32152351.1035795667@[192.168.1.100]> In-Reply-To: <20021028110302.C32506-100000@sequoia.muada.com> References: <20021028110302.C32506-100000@sequoia.muada.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-8.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, 28 October 2002 11:11 +0100 Iljitsch van Beijnum wrote: [...] > For smaller, but still reasonably large sites, having the multihoming > functionality in each host is still too much headache, that's why I > think it's important to be able to offload the necessary processing to a > relatively small number of boxes at the edges of the network. To the > internal network this will look like traditional IPv4-style multihoming, > to the service providers it looks like single homing. The only downside > is that the other end has to implement something similar. That's why we > also need to have it in the host stacks, even for hosts that don't > multihome themselves. Can these boxes (which in essence are multihoming policy servers) exist only at the edge of the enterprise network, or do they have to live at each level of the internal routing hierarchy? A host with interfaces on multiple subnets has to make the same decisions about address selection when reaching an internal destination as when reaching an external one. I guess the implication is that a solution which is routing-protocol agnostic is more scalable than one which isn't. 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 Mon Oct 28 10:59:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15714 for ; Mon, 28 Oct 2002 10:59:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186CKu-000HuA-00 for multi6-data@psg.com; Mon, 28 Oct 2002 08:01:52 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 186CKs-000Htx-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 08:01:50 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id LAA10374; Mon, 28 Oct 2002 11:01:48 -0500 Date: Mon, 28 Oct 2002 11:01:48 -0500 From: "J. Noel Chiappa" Message-Id: <200210281601.LAA10374@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Brian E Carpenter >>> E.g. if a (large enough) bunch of customers band together and create >>> an exchange, which buys service from multiple ISP's, and which is >>> given an address which is visible over the same scope as those ISP's, >>> and the customers are addressed as part of that exchange, you meet >>> the policy goal (being able to change providers) *without* so-called >>> "PI" addresses. But the addresses are still connectivity-based. > The problem with this (and the reason I have serious doubts about > Tony's PI proposal, and all geographical proposals going back at least > to Bill Simpson's metro proposal years ago) Well, you usefully point out that all geographical proposals basically amount to the proposal to create exchanges! :-) At least, if the routing is to remain functional!! :-) :-) > is > There is no economic reason to create such an exchange. > If we could get past that, of course it works. Ah. You misunderstood the point of my comment, which was not to advocate the creation of exchanges, but solely to point out that the terminology of "provider-independent" is not technical terminology, but rather economic/policy terminology. In other words, there are addressing scheme which are "provider-independent" but which differ in extremely important technical ways from the PI addresses proposed by various people. The important division in addressing schemes is between "connectivity-based" and "non-connectivity-based", and it occupies the same place in networking discussions as the division between "second-law-machines" and "perpetual-motion-machines" does in engine discussion. There are many useful finer subdivisions of the "connectivity-based" class (e.g. hierarchical, provider-dependent, exchange-dependent, etc - some orthagonal to each other), just as there are many useful finer divisions of the "second-law-machines" class. However, at least in discussion of engine designs one normally doesn't have to spend a lot of time discussing perpetual-motion machines; everyone involves understands that although that is the most fundamental division, the second class isn't worth discussing, and not a lot of time gets spent discussing things in that division. One day the networking world will get there too, and the only discussion of routing-names (i.e. those names/identifiers/whatever which the routing calculations use - addresses, in the IPv4/6 architecture) which people will bother with are the "connectivity-based". I'm not holding my breath. If people don't like some of the properties that being connectivity-based induces in routing-names, then the answer is simple: define another namespace which has characteristics you like better, and map back and forth between the two. If the price of that is too high, then you just have to deal with the hassles of connectivity-based names, just like we have do live with the hassles of friction, entropy, etc. Noel From owner-multi6@ops.ietf.org Mon Oct 28 11:00:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15759 for ; Mon, 28 Oct 2002 11:00:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186CK3-000HrK-00 for multi6-data@psg.com; Mon, 28 Oct 2002 08:00:59 -0800 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.36 #2) id 186CK1-000Hr7-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 08:00:57 -0800 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Mon, 28 Oct 2002 08:00:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3C4@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ+bYGl5XeOORIhSVaKl+hETCsyygALJIwg From: "Michel Py" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA15759 > Michel Py wrote: > Here's the scenario: the home/soho host that is multihomed > with cable and dsl makes a choice on which of its own addresses > (the cable one, or the dsl one) to use. This choice will dictate > on which pipe the return traffic from the web server to the > requesting host goes. > Iljitsch van Beijnum wrote: > Actually it doesn't, twice. > First of all, in order to really be multihomed, both addresses > must be viable. So if the HTTP farm decides to direct its traffic > to the other address, Joe can't really stop them, other than not > advertise this address in the first place. How could this possibly work? If Joe opens an HTTP connection to the web server using a source address of PA2, there is no way the web server can send the return traffic to Joe using PA1 as of today. So, if it happens that from the web server's network, PA1 is preferred over pipe P1, and PA2 is preferred over pipe P2, indeed we have Joe choosing over which pipe the traffic will come out of the server farm. Michel. From owner-multi6@ops.ietf.org Mon Oct 28 11:10:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16222 for ; Mon, 28 Oct 2002 11:10:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186CUx-000IWl-00 for multi6-data@psg.com; Mon, 28 Oct 2002 08:12:15 -0800 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.36 #2) id 186CUv-000IWY-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 08:12:13 -0800 content-class: urn:content-classes:message Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Oct 2002 08:12:14 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD258@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcJ+nG1k0UqUKkkhQxy19/uzqGeJqwAAD0Lw From: "Michel Py" To: "J. Noel Chiappa" , X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA16222 > J. Noel Chiappa wrote: > Well, you usefully point out that all geographical proposals > basically amount to the proposal to create exchanges! :-) Absolutely not. Michel. From owner-multi6@ops.ietf.org Mon Oct 28 11:14:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16446 for ; Mon, 28 Oct 2002 11:14:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186CZA-000IpT-00 for multi6-data@psg.com; Mon, 28 Oct 2002 08:16:36 -0800 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.36 #2) id 186CZ8-000IpH-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 08:16:34 -0800 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development Date: Mon, 28 Oct 2002 08:16:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3C5@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcJ+jBBP78EXK6+gS1u1ci6jjjIMaQAEL8cQ From: "Michel Py" To: "Michael Lambert" , "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA16446 > Michael Lambert wrote: > Can these boxes (which in essence are multihoming policy > servers) exist only at the edge of the enterprise network, Yes. > or do they have to live at each level of the internal > routing hierarchy? No. > A host with interfaces on multiple subnets has to make the > same decisions about address selection when reaching an > internal destination as when reaching an external one. That's the point, precisely: These boxes would enable hosts on the internal network to have only one address. > I guess the implication is that a solution which is > routing-protocol agnostic is more scalable than one > which isn't. At the host level, definitely. At the router level, there is a fine line between agnosticism and awareness, as there are tremendous advantages for the box that makes the multihoming decisions to know the network topology. Michel. From owner-multi6@ops.ietf.org Mon Oct 28 11:20:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16818 for ; Mon, 28 Oct 2002 11:20:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186CeX-000J5K-00 for multi6-data@psg.com; Mon, 28 Oct 2002 08:22:09 -0800 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.36 #2) id 186CeV-000J57-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 08:22:07 -0800 content-class: urn:content-classes:message Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Mon, 28 Oct 2002 08:22:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B04640BD25A@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcJ+UvTrzvJV5bFXS/eGKura3gwqjgAStNag From: "Michel Py" To: "Brian E Carpenter" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA16818 > Brian E Carpenter > The problem with this (and the reason I have serious > doubts about Tony's PI proposal, and all geographical > proposals going back at least to Bill Simpson's metro > proposal years ago), is there is no economic reason to > create such an exchange. No disagreement here. We are talking about geo PI that does not require exchanges. Michel. From owner-multi6@ops.ietf.org Mon Oct 28 11:41:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17871 for ; Mon, 28 Oct 2002 11:41:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186CyO-000K3o-00 for multi6-data@psg.com; Mon, 28 Oct 2002 08:42:40 -0800 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.36 #2) id 186CyN-000K3c-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 08:42:39 -0800 content-class: urn:content-classes:message Subject: RE: Recommendation v Requirements [Re: The state of IPv6 multihoming development Date: Mon, 28 Oct 2002 08:42:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3C6@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Recommendation v Requirements [Re: The state of IPv6 multihoming development Thread-Index: AcJ+UkI0rrMv9ZTHReer+ZJxn0fHxQATAdqw From: "Michel Py" To: "Brian E Carpenter" Cc: X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA17871 Brian, > Brian E Carpenter wrote: > Please see the subject field. The proposal is to > remove the word "requirements" and normative language. > This solves your perceived problem. Can't we just get > past this and publish it? If you remember what happened in Salt Lake a year ago, I was one of the strong supporters of sending to last call and you opposed this. I am happy you since then realized that it was time to finally begin to look at solutions. That being said, the reason we have not been looking at solutions since then is *not* because the requirements doc has not been shipped. The multi6 charter says that's what we should have started doing 18 months ago and finished doing a year ago. > [quote from the multi6 charter] > APR 01 Begin consideration of approaches and proposals > that could be pursued. > AUG 01 Evaluate approaches and select those to be worked on. > SEP 01 Submit requirements ID to IESG for publication as > Informational RFC. You will also note that looking at solutions is chronologically *before* submitting the requirements drafts in the charter, a point I already made a year ago. Read the charter again, and give me a reason why we should ship the document before looking at solutions. And while you are at it, please also give me just one reason to believe that shipping that doc is going to change something in here. Michel. From owner-multi6@ops.ietf.org Mon Oct 28 12:01:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18847 for ; Mon, 28 Oct 2002 12:01:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186DI0-000Kw8-00 for multi6-data@psg.com; Mon, 28 Oct 2002 09:02:56 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.36 #2) id 186DHy-000Kue-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 09:02:54 -0800 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9SH28PP027296; Mon, 28 Oct 2002 09:02:13 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9SH1wqL006952; Mon, 28 Oct 2002 09:01:58 -0800 (PST) Received: from dhcp1205.nanog26.merit.net (sjc-vpn1-633.cisco.com [10.21.98.121]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA04549; Mon, 28 Oct 2002 09:02:01 -0800 (PST) Date: Mon, 28 Oct 2002 11:01:48 -0600 (Central Standard Time) From: "Craig A. Huegen" To: Tony Hain cc: "'Tony Li'" , "'Iljitsch van Beijnum'" , Subject: RE: The state of IPv6 multihoming development In-Reply-To: <048301c27d70$1477cd40$4b194104@eagleswings> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.7 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 26 Oct 2002, Tony Hain wrote: > I know Craig said the host is making a routing decision, but it isn't. > Even if it tried it could be overruled by the routers for the outbound > packets. The only thing the host can decide that might even come close > to a routing decision is the address that the remote node will use to > talk back toward it. This is not a routing decision, but for those who > are into fine-grained TE, it might be considered a policy decision. There's a significant difference between being able to override normal path selection via significant manual policy configuration and performing path selection as a normal path of course. As an example, www.cisco.com may have addresses of 2001:420:9c3b:1::2 and 2003:602:b1cd:1::2. client.example.com selects 2001:420:9c3b:1::2. example.com's routing infrastructure doesn't know of the alternate path (if 2003:602:b1cd:1::2 were used as the destination IP address). Sure, example.com *could* put in a policy to look for packets to 2001:420:9c3b::/48 and force it down a different path, but it's completely manual and example.com's border has absolutely no visibility of this. Instead, example.com is most likely to hand the packets for 2001:420:9c3b::/48 to its best path to 2001:420::/32, the provider aggregate, unless manually overridden. The infrastructure has no way to evaluate an alternate path. What's most important here is that the routing infrastructure has absolutely no visibility that the destination 2001:420:9c3b:1::2 has an alternate path, to the address 2003:602:b1cd:1::2. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Mon Oct 28 12:47:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20602 for ; Mon, 28 Oct 2002 12:47:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186E0j-000NTG-00 for multi6-data@psg.com; Mon, 28 Oct 2002 09:49:09 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 186E0h-000NSz-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 09:49:07 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 28 Oct 2002 09:49:07 -0800 Reply-To: From: "Tony Hain" To: "'J. Noel Chiappa'" , Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Mon, 28 Oct 2002 09:48:48 -0800 Message-ID: <056f01c27eaa$454009c0$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200210281601.LAA10374@ginger.lcs.mit.edu> X-Spam-Status: No, hits=-5.0 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA20602 J. Noel Chiappa wrote: > > From: Brian E Carpenter > > >>> E.g. if a (large enough) bunch of customers band > together and create > >>> an exchange, which buys service from multiple ISP's, > and which is > >>> given an address which is visible over the same scope > as those ISP's, > >>> and the customers are addressed as part of that > exchange, you meet > >>> the policy goal (being able to change providers) > *without* so-called > >>> "PI" addresses. But the addresses are still > connectivity-based. > > > The problem with this (and the reason I have serious > doubts about > > Tony's PI proposal, and all geographical proposals > going back at least > > to Bill Simpson's metro proposal years ago) > > Well, you usefully point out that all geographical proposals > basically amount to the proposal to create exchanges! :-) At > least, if the routing is to remain functional!! :-) :-) > > > > is > > There is no economic reason to create such an exchange. > > If we could get past that, of course it works. > > Ah. You misunderstood the point of my comment, which was not > to advocate the creation of exchanges, but solely to point > out that the terminology of "provider-independent" is not > technical terminology, but rather economic/policy terminology. We don't need to create exchanges, there are already over 200 located in the global population centers. The economic incentive that is missing is the motivation for providers to connect to them. Routing table growth might become enough of an economic burden to cause that. Unfortunately we are paralyzed by the fear that it will, while refusing to pay what it will take to avoid it. Tony > > In other words, there are addressing scheme which are > "provider-independent" but which differ in extremely > important technical ways from the PI addresses proposed by > various people. > > > The important division in addressing schemes is between > "connectivity-based" and "non-connectivity-based", and it > occupies the same place in networking discussions as the > division between "second-law-machines" and > "perpetual-motion-machines" does in engine discussion. > > There are many useful finer subdivisions of the > "connectivity-based" class (e.g. hierarchical, > provider-dependent, exchange-dependent, etc - some orthagonal > to each other), just as there are many useful finer divisions > of the "second-law-machines" class. However, at least in > discussion of engine designs one normally doesn't have to > spend a lot of time discussing perpetual-motion machines; > everyone involves understands that although that is the most > fundamental division, the second class isn't worth > discussing, and not a lot of time gets spent discussing > things in that division. > > One day the networking world will get there too, and the only > discussion of routing-names (i.e. those > names/identifiers/whatever which the routing calculations use > - addresses, in the IPv4/6 architecture) which people will > bother with are the "connectivity-based". I'm not holding my breath. > > If people don't like some of the properties that being > connectivity-based induces in routing-names, then the answer > is simple: define another namespace which has characteristics > you like better, and map back and forth between the two. > > If the price of that is too high, then you just have to deal > with the hassles of connectivity-based names, just like we > have do live with the hassles of friction, entropy, etc. > > Noel > From owner-multi6@ops.ietf.org Mon Oct 28 13:43:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24019 for ; Mon, 28 Oct 2002 13:43:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186Esg-0000T1-00 for multi6-data@psg.com; Mon, 28 Oct 2002 10:44:54 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186Esd-0000SR-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 10:44:52 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9SIiPg34890; Mon, 28 Oct 2002 19:44:26 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 28 Oct 2002 19:44:25 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Nikander cc: , hipsec Subject: Re: The state of IPv6 multihoming development In-Reply-To: <3DBCD279.3050704@nomadiclab.com> Message-ID: <20021028192118.B34794-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 28 Oct 2002, Pekka Nikander wrote: > > Hm, what problem exactly does this solve that isn't solved by (for > > instance) SSL? > That is a subtle question, thanks for asking that. That is also > exactly the question which has prevented HIP from becoming a WG > a long time ago. I think that the multi6 list is perhaps not the > right place to discuss that question, the answer is too long. If the answer is so long, how do you expect to convince people they need it...? > If you are interested, let's move this point off-line, to > the HIP mailing list, or some other better suited mailing list. > And please read the NSRG report before we start to dive into this. Ok. > > Also, how does the hash to IP address mapping work in the absence of a > > hierarchy? > How does a name to IP address mapping work today? Using DNS, > for example. Or some other name resolution service. The DNS is strictly hierarchical. If address/number/hash 1234::5678 belongs to organization A, 1234::5679 to B, 1234::567A to C and so on, it is impossible to delegate authority so the whole thing must be administered at some central place. This is bad. This problem is one of the reasons why GSE didn't make it. > I agree. Basically I wanted to point of the following: > 1. Once we start to discuss solutions that require changes to the > end host (and perhaps these "mudem"s), there is also the option > of introducing a new name space, cryptographic or not. I don't completely agree (or disagree). Yes, the best time to do this would be when making changes anyway, but since this means changing more than what's needed to get multi-address multihoming going, doing it at the same time isn't "free". > 2. End-host based multi-homing solutions *seem* to have the > same security problems as (some) end-host mobility solutions. That's what everyone has been saying the last few days. However, I see some fundamental differences. First of all, in multihoming all the addresses are known beforehand. This gives us more options to implement security mechanisms. Second, mobile hosts are likely to travel to a place where the network is less secure than at their home location. For multihomed hosts, the security of their network connections doesn't really change. > If you create a solution where identifiers are simply > routable addresses, you are, from my point of view, basically > re-inventing Mobile IPv6. And since there are so many > problems with Mobile IPv6, I am quite sceptical about such > a design. Well, Mobile IPv6 works (probably) and the security > problems have been solved, but the result is, well, large > and complex. But perhaps I'm short sighted here, and you > have something else in your mind. As you say, MIPv6 is complex. I haven't fully digested how this works, so it's hard for me to say much about it. I realize that there is a lot of overlap in what needs to happen, but the functionality is fundamentally different so I don't think we are reinventing the same thing. Iljitsch From owner-multi6@ops.ietf.org Mon Oct 28 13:54:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24495 for ; Mon, 28 Oct 2002 13:54:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186F4K-0001C2-00 for multi6-data@psg.com; Mon, 28 Oct 2002 10:56:56 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186F4I-0001BI-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 10:56:54 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9SIuT334908; Mon, 28 Oct 2002 19:56:29 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 28 Oct 2002 19:56:29 +0100 (CET) From: Iljitsch van Beijnum To: Brian E Carpenter cc: "J. Noel Chiappa" , Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: <3DB95775.17B8ECD9@hursley.ibm.com> Message-ID: <20021028194625.G34794-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk You asked why not roll out SCTP? I seem to remember more problems with SCTP than just the obvious ones, but those are: * not every application uses a TCP-like transport mechanism * no backward compatibility * multiple addresses per host is a management nightmare in large networks On Fri, 25 Oct 2002, Brian E Carpenter wrote: > > Now if we virtualize the exchange that saves a lot of iron. > Pls explain. If you have an exchange in region X, you can have some kind of exchange-based adressing. So now remove the exchange and keep the addresses. Now you need to find the shortest path between each combination of networks to exchange traffic towards destinations in region X. There are potentially at least, many ways to do this: * tunnels * layer 2 "tunnels" using stuff like ATM or MPLS * more specific routes * separate routers for region X in region Y From owner-multi6@ops.ietf.org Mon Oct 28 14:10:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25234 for ; Mon, 28 Oct 2002 14:10:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186FJb-00026w-00 for multi6-data@psg.com; Mon, 28 Oct 2002 11:12:43 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186FJY-00026j-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 11:12:41 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9SJCHo34938; Mon, 28 Oct 2002 20:12:17 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 28 Oct 2002 20:12:17 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Nikander cc: Subject: Re: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development) In-Reply-To: <3DBCD878.1080406@nomadiclab.com> Message-ID: <20021028195706.C34794-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 28 Oct 2002, Pekka Nikander wrote: [...] > 4. As a result, the 10.1.1.0/24 network is flooded with unwanted traffic. > The fix is simple, but needed: Either > a) during the initial negotiation the hosts check the reachability > of the secondary addresses, and make sure, through some simple > and cheap crypto, that it is the same host answering at all of > the given addresses, or This isn't the preferred option as the secondary address may be down at the time of connection/association establishment. If there is no way around it, we can adopt a solution where you can only use the addresses that were up at the start of the negotiation, but that isn't the best way to handle it. > b) once the primary address becomes unreachable, the hosts check, > using some simple and cheap crypto, that it is the same host > answering at the secondary address, *before* sending any larger > amounts of data to that secondary address. Why do all this checking? Just assume the host is interested in the traffic until it tells you otherwise. For TCP apps, you're pretty much guaranteed to be in slow start anyway, so there wouldn't be much flooding. However, some way to throttle back streaming applications until we know the other end is happy would be good. It would be appropriate to redo the path characteristics discovery at this point in time for any streaming media applications as it is likely these characteristics are different now. (Note that using current multihoming a minute or more of unreachability when rehoming isn't out of the ordinary.) If the host at the new address doesn't want the traffic, there should be a way for it to make the sender stop without relying on transport mechanisms such as TCP RSTs. It would be good if the host at the new address receives the IP address from which all of this was initiated so an attacker can be traced easily. > The essense: You *have* to check that it is the *same* host that > is answering in the secondary address *before* you send any larger > amounts of data to that address. Why? If this address was presented as a valid secondary address (assuming this is done in a way that is reasonably secure) AND the host at the new address accepts the traffic, what's the problem? From owner-multi6@ops.ietf.org Mon Oct 28 14:38:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26220 for ; Mon, 28 Oct 2002 14:38:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186Fkr-0003nv-00 for multi6-data@psg.com; Mon, 28 Oct 2002 11:40:53 -0800 Received: from sj-msg-core-2.cisco.com ([171.70.145.30]) by psg.com with esmtp (Exim 3.36 #2) id 186Fkg-0003le-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 11:40:42 -0800 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9SJdogM025656; Mon, 28 Oct 2002 11:39:53 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g9SJdpcL024870; Mon, 28 Oct 2002 11:39:51 -0800 (PST) Received: from dhcp1205.nanog26.merit.net (sjc-vpn1-633.cisco.com [10.21.98.121]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA00846; Mon, 28 Oct 2002 11:39:49 -0800 (PST) Date: Mon, 28 Oct 2002 13:39:39 -0600 (Central Standard Time) From: "Craig A. Huegen" To: Tony Hain cc: "'Tony Li'" , "'Iljitsch van Beijnum'" , Subject: RE: The state of IPv6 multihoming development In-Reply-To: <048301c27d70$1477cd40$4b194104@eagleswings> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.3 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 26 Oct 2002, Tony Hain wrote: > I know Craig said the host is making a routing decision, but it isn't. > Even if it tried it could be overruled by the routers for the outbound > packets. The only thing the host can decide that might even come close > [...] > between the providers. Since the origin network can't enforce reverse > path routing decisions, the idea that the origin host is making any kind > of routing decision is completely bogus. Remember that simplicity is key for both providers and enterprises. The more exceptions that you need to configure in the routers, the higher the cost. What you're suggesting is that it's operationally feasible to overrule many individual /48's for each end-user to push it down a different path, which requires significant research and configuration for each given end-user. The IPv4 BGP model is much better at this because policy can be applied to paths, not individual /48's for end-users. This can range from a specific end-user to aggregated paths from a specific end-provider to a large group of paths from multiple providers -- it's not limited to overrides for specific end-users. Here's an example: P1--- | \ | \ CC1-----P2-----CP1 \ | / \ | / SP1--P3--- CC1 = content consumer CP1 = content provider P1,P2,P3 = tier 1 provider SP1 = sub-tier-1 (resale) provider P1 allocated 2001:42c::/32 P2 allocated 2001:445::/32 P3 allocated 2001:49c::/32 SP1 allocated 2001:49c:100::/40 CC1 allocated 2001:445:b1c::/48 (P2), 2001:49c:18f::/48 (SP1/P3) CP1 allocated 2001:42c:91cb::/48 (P1), 2001:445:8cb1::/48 (P2), 2001:49c:10c::/48 (P3) host1.CC1 has addresses: 2001:0445:0b1c:005a::1f 2001:049c:018f:005a::1f host1.CC1 sends DNS lookup for www.cp1, gets back: 2001:042c:91cb:0001::5 2001:0445:8cb1:0001::5 2001:049c:010c:0001::5 Using address selection rules proposed, host1.CC1 selects SA of 2001:049c:018f:005a::1f. host1.CC1 selects DA of 2001:049c:010c:0001::5. Assuming default routing (remember, keep it simple and keep exceptions to an absolute minimum), traffic from host1.CC1 to www.CP1 will go via SP1 to P3 to CP1 (destination address follows P3's /32 aggregate). Traffic from www.CP1 to host1.CC1 will go via P3 to SP1 to CC1. This is more likely to be a suboptimal path, given more organizational hops. The host's selection of source and destination addresses has selected the paths, and the network infrastructure has no visibility whatsoever that packets to host www.CP1 has an alternate path via P2. The only way that the network operator of network CC1 can send this traffic down a better path (P2) is to perform research on paths to CP1, identify a better path, configure a manual entry to hijack traffic going to 2001:049c:010c::/48 and send it down P2. Now imagine doing this for thousands of destination AS's. A previous suggestion has been to withhold the 2001:049c:018f:005a prefix from being a valid source address for host1.CC1; however, this isn't reasonable as there may be many best paths from host1.CC1 to other networks via SP1. I'll admit that BGP isn't a perfect solution - but it at least allows the network operator to have better, easier control over sets of paths (say, generally preferring P2, or de-preferring SP1/P3) as opposed to making individual, per-end-user policy specifications. --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Mon Oct 28 14:46:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26515 for ; Mon, 28 Oct 2002 14:46:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186Fs1-0004E1-00 for multi6-data@psg.com; Mon, 28 Oct 2002 11:48:17 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 186Fry-0004Cb-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 11:48:14 -0800 Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id 284DC1C; Mon, 28 Oct 2002 21:54:20 +0200 (EET) Message-ID: <3DBD945D.1030303@nomadiclab.com> Date: Mon, 28 Oct 2002 21:47:41 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org, hipsec Subject: End-host multi-homing (was Re: The state of IPv6 multihoming development) References: <20021028192118.B34794-100000@sequoia.muada.com> In-Reply-To: <20021028192118.B34794-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [I changed the subject to match content. Besides, this starts to go off-topic. But a part of this discussion is already moving elsewhere.] >>> Hm, what problem exactly does this solve that isn't solved by (for >>> instance) SSL? > >> That is a subtle question, thanks for asking that. That is also >> exactly the question which has prevented HIP from becoming a WG >> a long time ago. I think that the multi6 list is perhaps not the >> right place to discuss that question, the answer is too long. > > If the answer is so long, how do you expect to convince people they need > it...? Well, to give a short answer, HIP doesn't fit in to the way people are used to work at the IETF: take one problem, and solve it. And that's the reason why there is no HIP WG, at least as far as I understand the situation. I didn't have the discussions with the IESG, so I don't know. Anyway, I'll write a longer one to the hipsec list, explaining the details, but here is the condensed answer: HIP does not solve any new problems (except perhaps IPv6 end-host multi-homing). Instead, it solves a number of problems that have already been solved individually, but in an integrated and architecturally "better" way. (If you don't want to subscribe to the hipsec list, the archive is at http://lists.freeswan.org/pipermail/hipsec/) >> 2. End-host based multi-homing solutions *seem* to have the >> same security problems as (some) end-host mobility solutions. > > That's what everyone has been saying the last few days. However, I see > some fundamental differences. First of all, in multihoming all the > addresses are known beforehand. This gives us more options to implement > security mechanisms. Second, mobile hosts are likely to travel to a > place where the network is less secure than at their home location. For > multihomed hosts, the security of their network connections doesn't > really change. I agree and disagree. As I already wrote in my answer to Peter, if you take the view that end-host multi-homing is only for large servers, I can't but agree with you. However, I'm personally more interested in multi-homed end-user devices, i.e. the future mobile devices and home appliances with multiple simultaneous network connections. There are already now PCMCIA NICs available that are able to switch from WLAN to GPRS to something else, and the next generation NICs will be able to maintain a WLAN and a GPRS/EDGE connection at the same time. I have both an old ISDN line and an ADSL line to my home server, and if I had a good end-host multi-homing solution I could use the ISDN line as a good backup. My current practise of manually changing the routing tables and re-establishing TCP connections is not very transparent. With a better multi-homing solution, maybe I could replace the ISDN with a second ADSL or Cable. Under the current arrangment that doesn't make much sense. Now, if we speak about this kind of end-host multi-homing, then I don't think that the difference is so great. Either you have multiple IP addresses at the same time, or you have multiple IP addresses one after another, or some combination of both. So what? Maybe we need not just different multi-homing solutions for large sites and small sites, but also for large stationary servers, home servers, and mobile multi-access end-hosts. I just don't know. But so many solutions sure sounds quite complex. I'm just making an observation that to *me* the *security* problems look pretty similar. Maybe I'm wrong, I'm still learning about multi-homing. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Oct 28 14:47:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26584 for ; Mon, 28 Oct 2002 14:47:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186Ftr-0004Lk-00 for multi6-data@psg.com; Mon, 28 Oct 2002 11:50:11 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186Ftp-0004L6-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 11:50:09 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9SJniR34993; Mon, 28 Oct 2002 20:49:44 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 28 Oct 2002 20:49:44 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Nikander cc: Subject: Re: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development) In-Reply-To: <3DBD2DE7.5040806@nomadiclab.com> Message-ID: <20021028204424.T34794-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 28 Oct 2002, Pekka Nikander wrote: > I fully support Iljitsch in the call for an architectural discussion. Actually it was Tony. > That was the reason why I chimed in: instead of trying to hack > end-host multi-homing support into TCP or IP, maybe it would be > the right time to consider a new name space. Then the first order of business would be to solve the discovery problem. Is someone brave (or foolish?) enough to stand up to the DNS people and suggest using the domain name system for this? Or have a look at the MHAP draft for an example of one that doesn't use the DNS: http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt I think something completely new, designed specially for this purpose, would be best, but that will take a good deal of time. From owner-multi6@ops.ietf.org Mon Oct 28 15:22:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28088 for ; Mon, 28 Oct 2002 15:22:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186GQR-00060a-00 for multi6-data@psg.com; Mon, 28 Oct 2002 12:23:51 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 186GQP-0005xz-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 12:23:49 -0800 Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id 9D0931C; Mon, 28 Oct 2002 22:29:55 +0200 (EET) Message-ID: <3DBD9CB4.50806@nomadiclab.com> Date: Mon, 28 Oct 2002 22:23:16 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development) References: <20021028195706.C34794-100000@sequoia.muada.com> In-Reply-To: <20021028195706.C34794-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> b) once the primary address becomes unreachable, the hosts check, >> using some simple and cheap crypto, that it is the same host >> answering at the secondary address, *before* sending any larger >> amounts of data to that secondary address. > > Why do all this checking? Just assume the host is interested in the > traffic until it tells you otherwise. Remember that maybe there is no host there. Maybe the target is to flood a network. In IPv6 it is fairly easy to select an empty address, in fact probably easier than to pick an existing host. > For TCP apps, you're pretty much > guaranteed to be in slow start anyway, so there wouldn't be much > flooding. In TCP the attacker can anticipate what you send and send you faked acks, probably even trick you to send data on much faster rate than what you otherwise would do. The checking just takes on round trip, and you can even piggypack your regular data. > If the host at the new address doesn't want the traffic, there should be > a way for it to make the sender stop without relying on transport > mechanisms such as TCP RSTs. It would be good if the host at the new > address receives the IP address from which all of this was initiated so > an attacker can be traced easily. I agree with the value of sending the initial address. However, we must remember that maybe there is no host in the first place, and at the time when the local router knows this for sure, it may be already too late: the router may be completely flooded with all those extra streams, maybe even targetted to different address each. >>The essense: You *have* to check that it is the *same* host that >>is answering in the secondary address *before* you send any larger >>amounts of data to that address. > > Why? If this address was presented as a valid secondary address > (assuming this is done in a way that is reasonably secure) AND the host > at the new address accepts the traffic, what's the problem? Once more: The attacker selects an address that has no host on it, with the goal of flooding the network. It will take some time for the end-router to notice (through ND) that there is no host in that address. The attacker can send acks to the TCP segments, since it knows the sequence numbers and most probably can anticipate the traffic pattern. When the end-router is ready to send ICMP host unreachable, it is already too late since it will be flooded. Paying the price of delaying some packets and calculating one hash (or something equivalent) isn't that high. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Oct 28 16:01:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29835 for ; Mon, 28 Oct 2002 16:01:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186H1j-0007os-00 for multi6-data@psg.com; Mon, 28 Oct 2002 13:02:23 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 186H1g-0007od-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 13:02:20 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id IAA28979; Tue, 29 Oct 2002 08:01:57 +1100 (EST) Date: Tue, 29 Oct 2002 08:01:57 +1100 (EST) From: Peter Tattam To: Pekka Nikander cc: multi6@ops.ietf.org Subject: Re: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development) In-Reply-To: <3DBD2DE7.5040806@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 28 Oct 2002, Pekka Nikander wrote: > Peter Tattam wrote: > > What about if we turn the process around backward. The site which decides the > > other end is unreachable starts a fresh exchange on the new address pair > > (although it is still a secondary address and no new addresses may be > > introduced) with a separate nonce for each unused destination address (as seen > > by the host originating packets). The new nonce has to be cryptographically > > strong enough to be unguessable. > > > > i.e. > > > > 5. Bob sees Alice is not responding to the primary address and sends a new MH > > SYN-Secondary to the secondary address, but with new originating nonce. > > > > 6. Alice responds with a MH SYN-Secondary ACK-Secondary (with same addresses > > as before). (original nonce or new nonce???) > > > > 7. Bob sends MH ACK-Secondary as with MH ACK-primary. > > > > We add some extra signals... > > > > for Primary MH address establishment we use as before.. > > > > SYN-primary and ACK-primary control signals (like SYN and ACK bits in TCP). > > > > for each Secondary MH address establishment we use two new signals.. > > > > SYN-secondary and ACK-secondary control signals > > > > > > A SYN secondary must be ignored if there is no MH state with the primary > > address in the ESTABLISHED state. Also, I think the address list should match > > exactly the same as the primary address. > > > > Would that solve the problems? > > Maybe. I'd have to see a much more specific description before > I could analyze it for possible holes. But as a quick evaluation, > maybe the address list + the existense of a higher layer context > would work well enough. Doesn't bother me - I'm just thinking on my feet. > > But, IMHO, we are now going too far into a transport specific > solution space. There are other problems with transport-only > solutions, like consistency between different parallal transport > connections, the amount of signalling when changing from primary > to secondary etc. I don't want to rule out crypto altogether (e.g. I would insist on crypto for the nonce selection. My latest TCP stack [Trumpet Winsock and PetrOS TCP] uses crypto [MD5 hashed sequence] to select ISS for all tcp sessions now. It seems to be fast enough for the purpose of building lots of TCP connection.) You must however be very carefully aware of the types of crypto being selected from a CPU time perspective. PK encryption is very CPU intensive and could easily result in DoS attacks at the kernel layer. > > I fully support Iljitsch in the call for an architectural discussion. > That was the reason why I chimed in: instead of trying to hack > end-host multi-homing support into TCP or IP, maybe it would be > the right time to consider a new name space. And if not, taking > a good look at SCTP, as Brian suggested, might be the right road. I looked at SCTP a while back. While it has some similarities, I agree with others that it will not solve the legacy problem of apps that are built for TCP. > > --Pekka Nikander > > I have gotten to the point where I am agnostic about whether this particular solution should be deployed or not. It would be nice if it solved a large part of the MH problem, but if it never gets accepted, I'm not going to lose any sleep over it. I don't have a great deal of time at my disposal, and IETF meetings are out of the question because of my limited financial resources. Maybe mobility is the way to go. Why not apply it to realistic scenarios and see how well it fits. 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 Oct 28 17:19:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02268 for ; Mon, 28 Oct 2002 17:19:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186IFr-000BSM-00 for multi6-data@psg.com; Mon, 28 Oct 2002 14:21:03 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186IFp-000BRB-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 14:21:01 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9SMKZ535185; Mon, 28 Oct 2002 23:20:35 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 28 Oct 2002 23:20:35 +0100 (CET) From: Iljitsch van Beijnum To: Michel Py cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <2B81403386729140A3A899A8B39B046405E3C4@server2000> Message-ID: <20021028231311.X34794-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 28 Oct 2002, Michel Py wrote: > > First of all, in order to really be multihomed, both addresses > > must be viable. So if the HTTP farm decides to direct its traffic > > to the other address, Joe can't really stop them, other than not > > advertise this address in the first place. > How could this possibly work? If Joe opens an HTTP connection to the web > server using a source address of PA2, there is no way the web server can > send the return traffic to Joe using PA1 as of today. That's why we're working on better stuff for tomorrow. If the web server knows Joe's addresses, it can simply direct its packets at any of those addresses. This is an essential capability; without it the server wouldn't be able to get traffic flowing again if the address it was sending the data to stops working. > So, if it happens that from the web server's network, PA1 is preferred > over pipe P1, and PA2 is preferred over pipe P2, indeed we have Joe > choosing over which pipe the traffic will come out of the server farm. If we forget the fine grained stuff we were talking about earlier, the web serving network can the same thing we do today with BGP: prefer more prefixes over the connection that has the most available bandwidth. The difference with today's practices would be rather small, although in theory it would be possible for two networks to try to optimize in different directions so the traffic flow starts to oscillate. From owner-multi6@ops.ietf.org Mon Oct 28 18:06:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03142 for ; Mon, 28 Oct 2002 18:06:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186IzU-000DlY-00 for multi6-data@psg.com; Mon, 28 Oct 2002 15:08:12 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186IzR-000DlI-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 15:08:10 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9SN7kN35242; Tue, 29 Oct 2002 00:07:46 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 29 Oct 2002 00:07:45 +0100 (CET) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: <200210281601.LAA10374@ginger.lcs.mit.edu> Message-ID: <20021028232112.I34794-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 28 Oct 2002, J. Noel Chiappa wrote: > If people don't like some of the properties that being connectivity-based > induces in routing-names, then the answer is simple: define another > namespace which has characteristics you like better, and map back and forth > between the two. > If the price of that is too high, then you just have to deal with the > hassles of connectivity-based names, just like we have do live with the > hassles of friction, entropy, etc. So what is it that makes "connectivity-based" names so good and everything else so bad? Unless I'm much more mistaken than I thought possible, the relationship between a connection and a name/address is purely contingent. Things would be different if routing were hierarchical, which it isn't. Let me draw an ASCII picture: G / \ / \ E F / \ / \ A B C D If the only way to get from A to D is A -> E -> G -> F -> D everything gets very simple and very scalable. However, not only does this not match the way things work--it doesn't even come close. There is absolutely no way to make real-world interdomain routing fit inside a hierarchy. In reality, each AS occupies a place at the top of the hierarchy. Some ASes have many lower layers inside, some don't. But if an AS could be hidden completely behind another AS, the AS wouldn't qualify for an AS number and not exist in the BGP view of the world to begin with. This means we have to live with a very large number of prefixes in our routing tables. Fortunately, a single big thing can usually be split into a larger number of small things to make it more manageable. Four smaller routers that handle 2000::/5, 2800::/5, 3000::/5 and 3800::/5 respectively, are probably cheaper than one big one that handles 2000::/3. Now if a multihomed customer of two ISPs with address range 3333:abc:def::/48 were somehow to connect to routers that handle the 3000::/5 portion of the routing tables at both her ISPs, that would certainly make things easier. And if the 3000::/5 routers of those ISPs could talk to each other, that too. It wouldn't be necessary per se, just easier. Iljitsch From owner-multi6@ops.ietf.org Mon Oct 28 19:48:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05607 for ; Mon, 28 Oct 2002 19:48:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186KaT-000Ijd-00 for multi6-data@psg.com; Mon, 28 Oct 2002 16:50:29 -0800 Received: from dhcp3217.nanog26.merit.net ([192.35.167.217] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 186KaR-000IjQ-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 16:50:27 -0800 Received: from laptop2.kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id g9T0nOFY003688; Tue, 29 Oct 2002 01:49:24 +0100 (CET) Date: Tue, 29 Oct 2002 01:49:23 +0100 Subject: Re: Advancement: ready to test consensus? (was: Re: The state of ...) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: michel@arneill-py.sacramento.ca.us, peter@jazz-1.trumpet.com.au, tjc@ecs.soton.ac.uk, multi6@ops.ietf.org To: smd@ab.use.net (Sean Doran) From: Kurt Erik Lindqvist In-Reply-To: <20021023004546.395BD986@ab.use.net> Message-Id: <44847D94-EAD8-11D6-BCCD-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > ask for it to be demonstrated. The usual mechanism for > this would be to ask for some reasonable number of "yes, > advance it now" comments and few or no "no, not yet" > comments (*ideally* with alternative suggestions, such > as "examine and incorporate these edits I have written" > or "because I have written what I think is a superior > draft, which I have submitted in the usual way", which > will trigger actual work in the working group, per the > charter). > Being late in the discussion (and new to the discussion), I would like to second Brians comment - if the draft is to move on, change MUST/SHOULD etc to must/should. Appart from that, I don't see a better starting point at the moment. - kurtis - From owner-multi6@ops.ietf.org Mon Oct 28 20:33:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06358 for ; Mon, 28 Oct 2002 20:33:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186LHT-000KwE-00 for multi6-data@psg.com; Mon, 28 Oct 2002 17:34:55 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 186LHR-000Kum-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 17:34:53 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id UAA13019; Mon, 28 Oct 2002 20:34:51 -0500 Date: Mon, 28 Oct 2002 20:34:51 -0500 From: "J. Noel Chiappa" Message-Id: <200210290134.UAA13019@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum > So what is it that makes "connectivity-based" names so good and > everything else so bad? Because the only way to make the routing scale to extremely large sizes (and the Internet has to be up to way over 1M "nodes" by now, where "nodes" only include routers and networks, not hosts, since hosts don't generally create any load on the routing algorithm) is to use connectivity-based routing-names; i.e. routing-names which express *where* you are in the network. > Unless I'm much more mistaken than I thought possible I will exercise great restraint and not touch this straight line... :-) > the relationship between a connection and a name/address is purely > contingent. Things would be different if routing were hierarchical, > which it isn't. You're making a common mistake, and confusing the connection graph (which *is* an arbitrary graph) with the "abstraction hierarchy", which is a tree (i.e. a hierarchy). The "abstraction hierarchy" just shows the relationship between larger and larger "abstractions"; i.e. named areas of the network connectivity graph. This is probably easier to grasp with a picture; check out: http://users.exis.net/~jnc/tech/routing_slides.html#abshier which should help make it clear. Anyway, if the routing is to scale, the actual connectivity relationships between the abstractions *have* to be embodied, to a certain degree (long side-dissertation suppressed) in the routing-names. This is generally done by having the routing-names have a hierarchical structure which generally (same long side-dissertation suppressed) mimics the abstraction hierarchy. In fact, one generally simply creates those hierarchical names by stringing together the names of the branches of the abstraction hierarchy tree leading from the root to the thing you want to name. E.g. on the example page above, the node X.A.1 is named that by concatenating (with dots) the names of the branches X, A and 1. > If the only way to get from A to D is A -> E -> G -> F -> D everything > gets very simple and very scalable. However, not only does this not > match the way things work--it doesn't even come close. There is > absolutely no way to make real-world interdomain routing fit inside a > hierarchy. Nobody said it should. Just like the connectivity doesn't have to be a tree (or hierarchy), the routes don't follow a tree (or hierarchy) either. However, the *naming* has to follow a hierarchy. If you do that, you get scalable routing; i.e. routing where the overhead grows as something like ln(N), where N is the number of "nodes" (as defined above) in the network. Please read this seminal paper: Leonard Kleinrock and Farouk Kamoun, "Hierarchical Routing for Large Networks: Performance Evaluation and Optimization", Computer Networks 1 (1977), North-Holland Publishing Co., pp. 155-174. which explains this all, and includes a number of key proofs. And it does *not* have to be hierarchical routing (as in the K-K paper), either, if information about the internal structure of an abstraction is allowed to leak out a *limited* distance beyond the naming boundary of that abstraction - as opposed to suppressing it at the naming boundary, which is the most common case. Again, an example makes this easier to see. Going back to the example in the page above, add a second connection between A.3 and B.3. If information about the internal structure of A is allowed to leak out a *limited* distance beyond A, say as far as B.2, then when packets for A.2 and A.3 arrive at B.2, the latter can forward them to the appropriate next hop (B.1 and B.3 respectively) which leads to the optimal entry point into A for their actual ultimate destinations. More later, this is enough for now. Noel From owner-multi6@ops.ietf.org Tue Oct 29 02:22:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23451 for ; Tue, 29 Oct 2002 02:22:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186QhH-000D4v-00 for multi6-data@psg.com; Mon, 28 Oct 2002 23:21:55 -0800 Received: from dhcp3253.nanog26.merit.net ([192.35.167.253] helo=roam.psg.com ident=exim) by psg.com with esmtp (Exim 3.36 #2) id 186QhF-000D4L-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 23:21:53 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 186QhF-000OKY-00 for multi6@ops.ietf.org; Mon, 28 Oct 2002 23:21:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15806.10733.350645.350630@harjus.eng.song.fi> In-Reply-To: <3DBD945D.1030303@nomadiclab.com> References: <20021028192118.B34794-100000@sequoia.muada.com> <3DBD945D.1030303@nomadiclab.com> Date: Tue, 29 Oct 2002 08:25:49 +0200 To: hipsec@lists.freeswan.org Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: [Hipsec] End-host multi-homing (was Re: The state of IPv6 multihoming development) From: jh@lohi.eng.song.fi X-Spam-Status: No, hits=-7.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME,REFERENCES, RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Pekka Nikander writes: > So what? Maybe we need not just different multi-homing > solutions for large sites and small sites, but also for > large stationary servers, home servers, and mobile multi-access > end-hosts. I just don't know. But so many solutions sure > sounds quite complex. we should have only one multihoming solution and that should definitely also cover the mobile hosts that are simultaneously attached to several mobile network (wlan, gprs, umts) and whose attachments can come and go dynamically. ietf should not approve any limited solution that would only apply to stationary multihomed sites. -- juha From owner-multi6@ops.ietf.org Tue Oct 29 04:32:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26014 for ; Tue, 29 Oct 2002 04:32:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186Sk4-000I5z-00 for multi6-data@psg.com; Tue, 29 Oct 2002 01:32:56 -0800 Received: from babar.switch.ch ([130.59.4.2]) by psg.com with esmtp (Exim 3.36 #2) id 186Sk1-000I5O-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 01:32:54 -0800 Received: from babar.switch.ch (localhost [IPv6:::1]) by babar.switch.ch (8.12.2+Sun/8.12.2) with ESMTP id g9T9WcGU001001; Tue, 29 Oct 2002 10:32:38 +0100 (MET) Received: (from leinen@localhost) by babar.switch.ch (8.12.2+Sun/8.12.2/Submit) id g9T9Wb28000998; Tue, 29 Oct 2002 10:32:37 +0100 (MET) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: "Craig A. Huegen" Cc: Shane Kerr , multi6@ops.ietf.org Subject: Path selection by hosts, shudder [was: Re: The state of...] References: X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: Date: 29 Oct 2002 10:32:36 +0100 Message-ID: Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-12.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, X_AUTH_WARNING version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Craig, I absolutely agree with Ohta-san's response to yours - I see this issue as fundamentally similar to the bandwidth management issue. Bandwidth is obviously something that IT people want to manage, but yet this is done on the end systems on the Internet (in TCP). Of course some may argue that this has failed, because there sometimes congestion somewhere on the Internet, and IT people are forced to buy rate shapers and other middleboxes to gain the control back from end systems, and lots of other people have spent a lot of effort to devise various ways to improve the QoS of the network, most of them involving making the network handle "less-important" traffic less well. But the fact is that for many (most?) people the Internet works or would work well even without all these things. I think there are good ("end-to-end") arguments for considering to leave the path selection decision to end systems too. For instance, applications run on end systems, and are in a good position to choose a path that fits their requirement best (cheapest/quickest response/highest bulk throughput...). On Tue, 22 Oct 2002 12:02:54 -0500 (Central Daylight Time), "Craig A. Huegen" said: > When the host selects the path by virtue of address selection, such > that the routing infrastructure can see no alternate paths to the > destination, then enterprise network operations teams have no > capability to manage traffic policy. I believe the majority of > enterprise network operations teams would have an issue with that. Yes, but the question is how much we should care about that. It's true that IT people are the ones who have to buy our stuff, but in the end our requirements are driven by business (in the large sense) needs of "end users". And you can rest assured that someone will sell those IT people boxes that give them back some control over their vict^H^H^H^Hcustomers' machines' path selection decisions, just like rate shapers "fix" TCP's rate computation in many enterprises today. > We should keep traffic routing within the network layer, IMO, or at > least give visibility to the network layer of alternate paths that > can be taken for a variety of policy reasons. Or we push the policy information out to the edge, so that end systems can select paths accordingly. -- Simon. From owner-multi6@ops.ietf.org Tue Oct 29 04:54:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26325 for ; Tue, 29 Oct 2002 04:54:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186T6h-000Iv9-00 for multi6-data@psg.com; Tue, 29 Oct 2002 01:56:19 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #2) id 186T6f-000ItO-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 01:56:17 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9T9tbjk008038; Tue, 29 Oct 2002 10:55:37 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9T9taeD074602; Tue, 29 Oct 2002 10:55:37 +0100 Received: from dhcp222-5.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA75462 from ; Tue, 29 Oct 2002 10:55:32 +0100 Message-Id: <3DBE5B09.D0F8FE62@hursley.ibm.com> Date: Tue, 29 Oct 2002 10:55:21 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: multi6@ops.ietf.org Subject: Re: Recommendation v Requirements [Re: The state of IPv6 multihoming development References: <2B81403386729140A3A899A8B39B046405E3C6@server2000> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-10.4 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel Py wrote: > > Brian, > > > Brian E Carpenter wrote: > > Please see the subject field. The proposal is to > > remove the word "requirements" and normative language. > > This solves your perceived problem. Can't we just get > > past this and publish it? > > If you remember what happened in Salt Lake a year ago, I was one of the > strong supporters of sending to last call and you opposed this. That was the -02 version. I've been happy with the -03 version. Brian > I am > happy you since then realized that it was time to finally begin to look > at solutions. > > That being said, the reason we have not been looking at solutions since > then is *not* because the requirements doc has not been shipped. The > multi6 charter says that's what we should have started doing 18 months > ago and finished doing a year ago. > > > [quote from the multi6 charter] > > APR 01 Begin consideration of approaches and proposals > > that could be pursued. > > AUG 01 Evaluate approaches and select those to be worked on. > > SEP 01 Submit requirements ID to IESG for publication as > > Informational RFC. > > You will also note that looking at solutions is chronologically *before* > submitting the requirements drafts in the charter, a point I already > made a year ago. > > Read the charter again, and give me a reason why we should ship the > document before looking at solutions. > > And while you are at it, please also give me just one reason to believe > that shipping that doc is going to change something in here. > > Michel. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-multi6@ops.ietf.org Tue Oct 29 10:30:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08775 for ; Tue, 29 Oct 2002 10:30:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186YKU-0005gN-00 for multi6-data@psg.com; Tue, 29 Oct 2002 07:30:54 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #2) id 186YKR-0005eT-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 07:30:51 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9TFU5Ra023314; Tue, 29 Oct 2002 16:30:10 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9TFU5eD044140; Tue, 29 Oct 2002 16:30:05 +0100 Received: from dhcp22-101.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA71448 from ; Tue, 29 Oct 2002 16:30:03 +0100 Message-Id: <3DBEA970.74465B9C@hursley.ibm.com> Date: Tue, 29 Oct 2002 16:29:52 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] References: <20021028232112.I34794-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch, Noel has already answered, but I would like to add that we know the routing structure will be flat at some level. However, to get to the ten billion node Internet we need to plan for, we need aggregation of addresses much deeper in the topology than we have it today - let's think in terms of 10000 subnets represented by one route, for example. Brian Iljitsch van Beijnum wrote: > > On Mon, 28 Oct 2002, J. Noel Chiappa wrote: > > > If people don't like some of the properties that being connectivity-based > > induces in routing-names, then the answer is simple: define another > > namespace which has characteristics you like better, and map back and forth > > between the two. > > > If the price of that is too high, then you just have to deal with the > > hassles of connectivity-based names, just like we have do live with the > > hassles of friction, entropy, etc. > > So what is it that makes "connectivity-based" names so good and > everything else so bad? Unless I'm much more mistaken than I thought > possible, the relationship between a connection and a name/address is > purely contingent. Things would be different if routing were > hierarchical, which it isn't. Let me draw an ASCII picture: > > G > / \ > / \ > E F > / \ / \ > A B C D > > If the only way to get from A to D is A -> E -> G -> F -> D everything > gets very simple and very scalable. However, not only does this not > match the way things work--it doesn't even come close. There is > absolutely no way to make real-world interdomain routing fit inside a > hierarchy. > > In reality, each AS occupies a place at the top of the hierarchy. Some > ASes have many lower layers inside, some don't. But if an AS could be > hidden completely behind another AS, the AS wouldn't qualify for an AS > number and not exist in the BGP view of the world to begin with. > > This means we have to live with a very large number of prefixes in our > routing tables. Fortunately, a single big thing can usually be split > into a larger number of small things to make it more manageable. Four > smaller routers that handle 2000::/5, 2800::/5, 3000::/5 and 3800::/5 > respectively, are probably cheaper than one big one that handles > 2000::/3. Now if a multihomed customer of two ISPs with address range > 3333:abc:def::/48 were somehow to connect to routers that handle the > 3000::/5 portion of the routing tables at both her ISPs, that would > certainly make things easier. And if the 3000::/5 routers of those ISPs > could talk to each other, that too. It wouldn't be necessary per se, > just easier. > > Iljitsch From owner-multi6@ops.ietf.org Tue Oct 29 11:06:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10878 for ; Tue, 29 Oct 2002 11:06:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186YuN-0007Lg-00 for multi6-data@psg.com; Tue, 29 Oct 2002 08:07:59 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186YuI-0007L2-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 08:07:55 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9TG7Vt36868; Tue, 29 Oct 2002 17:07:31 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 29 Oct 2002 17:07:31 +0100 (CET) From: Iljitsch van Beijnum To: Brian E Carpenter cc: Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: <3DBEA970.74465B9C@hursley.ibm.com> Message-ID: <20021029163826.W36604-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 29 Oct 2002, Brian E Carpenter wrote: > Noel has already answered, but I would like to add that we know the > routing structure will be flat at some level. However, to get to the > ten billion node Internet we need to plan for, we need aggregation > of addresses much deeper in the topology than we have it today - > let's think in terms of 10000 subnets represented by one route, > for example. Any particular reason for the 10 billion figure? My provider-internal solution (see draft) doesn't scale to quite this level, but I believe it will buy us more than enough time to work out all the kinks in one or more multi-address solutions. I would very much appreciate some feedback that isn't just geo-allergy. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Oct 29 11:08:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10982 for ; Tue, 29 Oct 2002 11:08:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186YxM-0007Ud-00 for multi6-data@psg.com; Tue, 29 Oct 2002 08:11:04 -0800 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.36 #2) id 186YxK-0007UP-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 08:11:02 -0800 content-class: urn:content-classes:message Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Tue, 29 Oct 2002 08:11:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E3D2@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcJ/Ye+Vo6C6vy0VQAGdGQfKxkyTDwAAjmCg From: "Michel Py" To: "Brian E Carpenter" , "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA10982 Brian, > Brian E Carpenter wrote: > Noel has already answered, but I would like to add that we > know the routing structure will be flat at some level. > However, to get to the ten billion node Internet we need to > plan for, we need aggregation of addresses much deeper in > the topology than we have it today - let's think in terms > of 10000 subnets represented by one route, for example. What you describe above is almost exactly the GAPI draft used by MHAP. The flat level involves 64k areas (an area is a /32), which of them contains 64k sites. The draft: http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt Does not have an allocation example, but we have one here: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt (there will be some cosmetic changes to make the addressing plan compliant with the 25% clause in 5.2 in the draft, but good enough for a first look). Michel. From owner-multi6@ops.ietf.org Tue Oct 29 11:12:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11179 for ; Tue, 29 Oct 2002 11:12:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186Z0O-0007dS-00 for multi6-data@psg.com; Tue, 29 Oct 2002 08:14:12 -0800 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.36 #2) id 186Z0M-0007d5-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 08:14:10 -0800 content-class: urn:content-classes:message Subject: RE: Recommendation v Requirements [Re: The state of IPv6 multihoming development Date: Tue, 29 Oct 2002 08:14:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B04640BD273@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Recommendation v Requirements [Re: The state of IPv6 multihoming development Thread-Index: AcJ/MXd0XdRHgP2MSQupGM+TbKTD3wANLO8g From: "Michel Py" To: "Brian E Carpenter" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA11179 Brian, >> If you remember what happened in Salt Lake a year ago, >> I was one of the strong supporters of sending to last >> call and you opposed this. > That was the -02 version. I've been happy with the -03 > version. I'm happy to hear this, as the changes for -02 to -03 were my initiative and my work for a large part. Why do you think the -03 has not made it to WG last call? Michel. From owner-multi6@ops.ietf.org Tue Oct 29 11:33:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12009 for ; Tue, 29 Oct 2002 11:33:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186ZK0-0008aK-00 for multi6-data@psg.com; Tue, 29 Oct 2002 08:34:28 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #2) id 186ZJy-0008Xo-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 08:34:26 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9TGXcJf038408; Tue, 29 Oct 2002 17:33:44 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9TGXXeD069182; Tue, 29 Oct 2002 17:33:34 +0100 Received: from dhcp22-101.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA69436 from ; Tue, 29 Oct 2002 17:33:33 +0100 Message-Id: <3DBEB852.89F832B1@hursley.ibm.com> Date: Tue, 29 Oct 2002 17:33:22 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] References: <2B81403386729140A3A899A8B39B046405E3D2@server2000> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-10.4 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel Py wrote: > > Brian, > > > Brian E Carpenter wrote: > > Noel has already answered, but I would like to add that we > > know the routing structure will be flat at some level. > > However, to get to the ten billion node Internet we need to > > plan for, we need aggregation of addresses much deeper in > > the topology than we have it today - let's think in terms > > of 10000 subnets represented by one route, for example. > > What you describe above is almost exactly the GAPI draft used by MHAP. > The flat level involves 64k areas (an area is a /32), which of them > contains 64k sites. An addressing scheme doesn't magically cause aggregation to occur, but the scale is about right. In answer to Iljitsch, 10 billion is the approximate world population predicted for the year 2050. One node per human seems a modest target. Brian > > The draft: > http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt > Does not have an allocation example, but we have one here: > http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt > (there will be some cosmetic changes to make the addressing plan > compliant with the 25% clause in 5.2 in the draft, but good enough for a > first look). > > Michel. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-multi6@ops.ietf.org Tue Oct 29 11:33:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12040 for ; Tue, 29 Oct 2002 11:33:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186ZL4-0008cF-00 for multi6-data@psg.com; Tue, 29 Oct 2002 08:35:34 -0800 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #2) id 186ZL2-0008bG-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 08:35:32 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9TGYwSD048664 for ; Tue, 29 Oct 2002 17:34:59 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9TGYveD076590 for ; Tue, 29 Oct 2002 17:34:57 +0100 Received: from dhcp22-101.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA46882 from ; Tue, 29 Oct 2002 17:34:56 +0100 Message-Id: <3DBEB8A5.D5E563ED@hursley.ibm.com> Date: Tue, 29 Oct 2002 17:34:45 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Recommendation v Requirements [Re: The state of IPv6 multihoming development References: <2B81403386729140A3A899A8B39B04640BD273@server2000> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel Py wrote: > > Brian, > > >> If you remember what happened in Salt Lake a year ago, > >> I was one of the strong supporters of sending to last > >> call and you opposed this. > > > That was the -02 version. I've been happy with the -03 > > version. > > I'm happy to hear this, as the changes for -02 to -03 were my initiative > and my work for a large part. Why do you think the -03 has not made it > to WG last call? Probably because of the normative language. Brian From owner-multi6@ops.ietf.org Tue Oct 29 12:21:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14849 for ; Tue, 29 Oct 2002 12:20:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186a4m-000AxB-00 for multi6-data@psg.com; Tue, 29 Oct 2002 09:22:48 -0800 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #2) id 186a4j-000AwK-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 09:22:45 -0800 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 0BD4843155; Tue, 29 Oct 2002 18:22:13 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp02.uc3m.es (Postfix) with SMTP id DC68D99F33; Tue, 29 Oct 2002 18:22:12 +0100 (CET) From: "marcelo bagnulo" To: "Hesham Soliman (EAB)" Cc: Subject: RE: The state of IPv6 multihoming development Date: Tue, 29 Oct 2002 18:23:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0BF6@Esealnt861.al.sw.ericsson.se> Importance: Normal X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02,USER_AGENT_OUTLOOK version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Hesham, > => This is not an issue. It depends on where your > HA is located. I can write something if there is > enough interest, but end host approaches don't > seem to be interesting to most people on this list. FWIW i consider that this would be really interesting, and I am really interested in reading this. Have you read Dupont (very long time expired) draft about this? Thanks, marcelo > > Hesham > From owner-multi6@ops.ietf.org Tue Oct 29 16:24:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26074 for ; Tue, 29 Oct 2002 16:24:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186dqj-000Of7-00 for multi6-data@psg.com; Tue, 29 Oct 2002 13:24:33 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186dqg-000Oev-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 13:24:30 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9TLO5W37443; Tue, 29 Oct 2002 22:24:05 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 29 Oct 2002 22:24:05 +0100 (CET) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: <200210290134.UAA13019@ginger.lcs.mit.edu> Message-ID: <20021029154945.I36604-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 28 Oct 2002, J. Noel Chiappa wrote: > > So what is it that makes "connectivity-based" names so good and > > everything else so bad? > Because the only way to make the routing scale to extremely large sizes (and > the Internet has to be up to way over 1M "nodes" by now, Well the IPv4 routing table is only a little over 100k and there should be a one time gain when moving to IPv6, so I'm not sure about the "now" part, but soon, yes. I think we're all in agreement about that and the fact that 1M is just a starting point. > > Unless I'm much more mistaken than I thought possible > I will exercise great restraint and not touch this straight line... :-) I appreciate it. > Anyway, if the routing is to scale, the actual connectivity relationships > between the abstractions *have* to be embodied, to a certain degree (long > side-dissertation suppressed) in the routing-names. This is generally done by > having the routing-names have a hierarchical structure which generally (same > long side-dissertation suppressed) mimics the abstraction hierarchy. I'm wondering whether the solution isn't worse that the original problem. And so are you (at least to some degree) as you dismiss geographical aggregation, despite the fact that geography is much structured much more hierarchical than any aspect of IP and the routing thereof. See draft-py-multi6-gapi-00.txt, which was posted earlier today. > > There is > > absolutely no way to make real-world interdomain routing fit inside a > > hierarchy. > Nobody said it should. Just like the connectivity doesn't have to be a tree > (or hierarchy), the routes don't follow a tree (or hierarchy) either. However, > the *naming* has to follow a hierarchy. If you do that, you get scalable > routing; i.e. routing where the overhead grows as something like ln(N), where > N is the number of "nodes" (as defined above) in the network. It seems to me that in order to have simple routing, you have to live with simple forwarding, which has many undesireable properties, such as a longer path and less redundancy. > Please read this seminal paper: > Leonard Kleinrock and Farouk Kamoun, "Hierarchical Routing for Large > Networks: Performance Evaluation and Optimization", > Computer Networks 1 (1977), > North-Holland Publishing Co., pp. 155-174. That's going to take a while as it seems noone ever bothered to put it online, not even Kleinrock himself who isn't otherwise very modest about his accomplishments. From what I gather from other stuff that refers to this, the down side is a longer path. > And it does *not* have to be hierarchical routing (as in the K-K paper), > either, if information about the internal structure of an abstraction is > allowed to leak out a *limited* distance beyond the naming boundary of that > abstraction - as opposed to suppressing it at the naming boundary, which is > the most common case. Yes, being able to control how far the more specific information leaks out is a very useful property. If we can make sure a multihomed network connects to two places that are close together in the hierarchy, the problems with the number of multihomed routes would be solved. However, this means we can no longer aggregate based on ownership of the routers (as it is done today) but rather routers from different networks that connect the same customers must be close together in the hierarchy. From owner-multi6@ops.ietf.org Tue Oct 29 16:50:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27278 for ; Tue, 29 Oct 2002 16:50:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186eH8-0000Qp-00 for multi6-data@psg.com; Tue, 29 Oct 2002 13:51:50 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 186eH5-0000QX-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 13:51:48 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id QAA19572; Tue, 29 Oct 2002 16:51:46 -0500 Date: Tue, 29 Oct 2002 16:51:46 -0500 From: "J. Noel Chiappa" Message-Id: <200210292151.QAA19572@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-0.7 required=5.0 tests=SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum >> the Internet has to be up to way over 1M "nodes" by now, where "nodes" >> only include[s] routers and networks > Well the IPv4 routing table is only a little over 100k Perhaps I should have said "physical routers and networks". In other words, I'm counting all the routers and subnets in the entire Internet. That's the actual problem the routing has to deal with. You see *only* 100K destinations in DFZ routing tables because some large percentage of the informaion has *already* been hidden (through use of hierarchical information hiding, e.g. subnets, etc). >> if the routing is to scale, the actual connectivity relationships >> between the abstractions *have* to be embodied, to a certain degree .. >> in the routing-names. This is generally done by having the >> routing-names have a hierarchical structure which generally .. mimics >> the abstraction hierarchy. > I'm wondering whether the solution isn't worse that the original > problem. See comments below about the tradeoff between routing efficiency (i.e. path length) and routing overhead (i.e. storage/computation/messages). > And so are you (at least to some degree) as you dismiss geographical > aggregation, despite the fact that geography is much structured much > more hierarchical than any aspect of IP and the routing thereof. Look, when getting packets from host A to host B - which *inevitably* means finding a path to get packets from host A to host B - it's *completely* irrelevant if host A is only 3mm from host B, iff the shortest path between them *through the actual network* is 117 hops. Addresses (in the sense of routing-names, and IPv4/6 addresses are routing-names) are nothing more than the data that routing uses, and the routing won't scale unless the routing-names are properly aligned with the actual topology (see previous message). *** For path selection, *actual network connectivity* is the *only* thing that *** matters. Therefore, FOR ADDRESSES, *ACTUAL NETWORK CONNECTIVITY* IS THE *** *ONLY* THING THAT MATTERS. Yeah, I dismiss "geographical aggregation" of routing-names for extremely large networks. Competent mechanical engineers dismiss perpetual motion machines without examining them closely too. There's a very good reason in both cases. >> Just like the connectivity doesn't have to be a tree (or hierarchy), >> the routes don't follow a tree (or hierarchy) either. However, the >> *naming* has to follow a hierarchy. If you do that, you get scalable >> routing; i.e. routing where the overhead grows as something like ln(N), >> where N is the number of "nodes" (as defined above) in the network. > It seems to me that in order to have simple routing, you have to live > with simple forwarding, which has many undesireable properties, such as > a longer path and less redundancy. What is "simple" forwarding, or "simple" routing, for that matter? These are not terms with any clear meaning that I am aware of. I was talking about "scalable" routing, which I carefully defined. >> Please read this seminal paper: > From what I gather from other stuff that refers to this, the down side > is a longer path. The tradeoff between routing efficiency (i.e. path length) and routing overhead (i.e. storage/computation/messages) is central to large-scale routing. To really cover this topic is a PhD thesis (and that's for the mono-metric case), but in general if you want to be absolutely sure of getting optimal routes, you have to get rid of information hiding; i.e. flat route the entire network. Needles to say, this doesn't scale well. The whole art in large-scale routing is managing that tradeoff between routing efficiency and overhead. The K/K paper does show that, given certain reasonable assumptions about topology, that the increase in path length due to their information hiding scheme grows very small as the network gets larger, although of course their whole paper is about mono-metric systems. Noel From owner-multi6@ops.ietf.org Tue Oct 29 17:41:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00025 for ; Tue, 29 Oct 2002 17:41:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186f4X-0003oO-00 for multi6-data@psg.com; Tue, 29 Oct 2002 14:42:53 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186f4U-0003oB-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 14:42:50 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9TMgQv37556; Tue, 29 Oct 2002 23:42:26 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 29 Oct 2002 23:42:25 +0100 (CET) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: <200210292151.QAA19572@ginger.lcs.mit.edu> Message-ID: <20021029232148.Q36604-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 29 Oct 2002, J. Noel Chiappa wrote: > >> the Internet has to be up to way over 1M "nodes" by now, where "nodes" > >> only include[s] routers and networks > > Well the IPv4 routing table is only a little over 100k > Perhaps I should have said "physical routers and networks". In other words, > I'm counting all the routers and subnets in the entire Internet. That's the > actual problem the routing has to deal with. Any particular reason for this? > > And so are you (at least to some degree) as you dismiss geographical > > aggregation, despite the fact that geography is much structured much > > more hierarchical than any aspect of IP and the routing thereof. > Look, when getting packets from host A to host B - which *inevitably* means > finding a path to get packets from host A to host B - it's *completely* > irrelevant if host A is only 3mm from host B, iff the shortest path between > them *through the actual network* is 117 hops. Absolutely true. However, if we can build a naming hierarchy in which most multihomed networks connect to two places that are very close in the hierarchy, this buys us aggregatability. Obviously, this is never going to be a long term solution, but it makes for a very good short term solution as it can work pretty much immediately by just adopting a new address allocation scheme and some creative BGP filtering. > Yeah, I dismiss "geographical aggregation" of routing-names for extremely > large networks. Competent mechanical engineers dismiss perpetual motion > machines without examining them closely too. There's a very good reason in > both cases. It's hardly the same thing, as perpetual motion is something that doesn't work in theory or practice, no matter which way you slice it. (Obviously I'm not saying something can't move "forever", but rather that you can't derive energy from something forever.) You can make routing work in any way you want, it's just that some ways are cheaper or faster than others. That's one of the problems with networking: even if done wrong it can work so people don't even see they're doing it wrong. But then sometimes this is an advantage as you can still get things to work even if there is a reason why it can't be done right. > > It seems to me that in order to have simple routing, you have to live > > with simple forwarding, which has many undesireable properties, such as > > a longer path and less redundancy. > What is "simple" forwarding, or "simple" routing, for that matter? These are > not terms with any clear meaning that I am aware of. I was talking about > "scalable" routing, which I carefully defined. Simple = using little information. Flat routing gives you all the information you need. Depening on aggregates leads to less optimal forwarding decisions. > To really cover this topic is a PhD thesis (and that's for the mono-metric > case), but in general if you want to be absolutely sure of getting optimal > routes, you have to get rid of information hiding; i.e. flat route the entire > network. Needles to say, this doesn't scale well. The whole art in large-scale > routing is managing that tradeoff between routing efficiency and overhead. > The K/K paper does show that, given certain reasonable assumptions about > topology, that the increase in path length due to their information hiding > scheme grows very small as the network gets larger, although of course their > whole paper is about mono-metric systems. It seems to me you have some very clear opinions on how this should work. Can we expect a draft? From owner-multi6@ops.ietf.org Tue Oct 29 18:26:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01348 for ; Tue, 29 Oct 2002 18:26:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186fmQ-0006rV-00 for multi6-data@psg.com; Tue, 29 Oct 2002 15:28:14 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 186fmM-0006nj-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 15:28:10 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id A6E1B3443C; Tue, 29 Oct 2002 15:36:37 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9TNRYiI029427; Tue, 29 Oct 2002 15:27:39 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Tue, 29 Oct 2002 15:27:34 -0800 Message-ID: Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcJ/nPZyyI8bCTr8SNGk97O84Nbc+gABFXRw From: "Tony Li" To: "Iljitsch van Beijnum" , "J. Noel Chiappa" Cc: X-Spam-Status: No, hits=0.7 required=5.0 tests=SPAM_PHRASE_05_08 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA01348 | However, if we can build a naming | hierarchy in which | most multihomed networks connect to two places that are | very close in | the hierarchy, this buys us aggregatability. Obviously, | this is never | going to be a long term solution, but it makes for a very good short | term solution as it can work pretty much immediately by | just adopting a | new address allocation scheme and some creative BGP filtering. Unfortunately, that's not going to be so simple. What happens when some organization that spans geographic areas decides that they want to multihome through providers on either sides of their particular continent? Or even different continents? | It's hardly the same thing, as perpetual motion is something that | doesn't work in theory or practice, no matter which way you | slice it. | (Obviously I'm not saying something can't move "forever", but rather | that you can't derive energy from something forever.) You can make | routing work in any way you want, it's just that some ways | are cheaper | or faster than others. That's one of the problems with | networking: even | if done wrong it can work so people don't even see they're doing it | wrong. But then sometimes this is an advantage as you can still get | things to work even if there is a reason why it can't be done right. Exactly. What we want to build is a routing architecture that is never going to have to be replaced. It's too difficult to reach in and change it, so you'd like it to be done right the first time. Since scalability is key and the way to scale is to keep the overhead low, a solution that has higher overhead is sub-optimal and to be avoided. Geographic aggregation is fine if the topology does indeed provide a convenient aggregation boundary. But in many cases, there will be no such convenient boundary. What do you do? You cannot make an exception and flat route any enterprise that has such links, because then their overhead dominates the cost of all routing and you're not sufficiently scalable. Now I admit that you can warp the virtual topology by tunneling in such a way that any two points on the graph are adjacent. But by doing this, you are abstracting routing away from the physical topology and you're insuring that routing never makes a correct decision with respect to that physical topology. | Simple = using little information. Flat routing gives you all the | information you need. Depening on aggregates leads to less optimal | forwarding decisions. Routing Theorem #1. ;-) | > The K/K paper does show that, given certain reasonable | assumptions about | > topology, that the increase in path length due to their | information hiding | > scheme grows very small as the network gets larger, | although of course their | > whole paper is about mono-metric systems. | | It seems to me you have some very clear opinions on how this should | work. Can we expect a draft? You might surf around for "Nimrod" and "Chiappa". There's about an entire book's worth of material around about this. As has been remarked elsewhere, we've been around and around and around on this topic for the last decade. We have no new answers, only the bitter pill of reality that we cannot all seem to swallow at the same time. Tony From owner-multi6@ops.ietf.org Tue Oct 29 19:24:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02795 for ; Tue, 29 Oct 2002 19:24:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186gfy-000AaP-00 for multi6-data@psg.com; Tue, 29 Oct 2002 16:25:38 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 186gfw-000AaD-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 16:25:36 -0800 From: Masataka Ohta Message-Id: <200210300021.JAA22212@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA22212; Wed, 30 Oct 2002 09:20:59 +0859 Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: from Tony Li at "Oct 29, 2002 03:27:34 pm" To: Tony Li Date: Wed, 30 Oct 2002 09:20:58 +0859 () CC: Iljitsch van Beijnum , "J. Noel Chiappa" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony; > Exactly. What we want to build is a routing architecture that is > never going to have to be replaced. It's too difficult to reach in and > change it, so you'd like it to be done right the first time. Since > scalability is key Exactly. However, routing architecture intelligent enough to support multihoming does not scale. The basic problem is that intelligent network does not scale. The basic principle against the problem is end to end. > and the way to scale is to keep the overhead low, > a solution that has higher overhead is sub-optimal and to be avoided. Low overhead is nothing more than a constant factor of improvement and is useless for real large network. Masataka Ohta From owner-multi6@ops.ietf.org Tue Oct 29 19:43:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03275 for ; Tue, 29 Oct 2002 19:43:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186gzF-000Bte-00 for multi6-data@psg.com; Tue, 29 Oct 2002 16:45:33 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 186gzD-000BtR-00 for multi6@ops.ietf.org; Tue, 29 Oct 2002 16:45:31 -0800 From: Masataka Ohta Message-Id: <200210300039.JAA22410@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA22410; Wed, 30 Oct 2002 09:39:41 +0900 Subject: Re: [Hipsec] End-host multi-homing (was Re: The state of IPv6 multihoming development) In-Reply-To: <15806.10733.350645.350630@harjus.eng.song.fi> from "jh@lohi.eng.song.fi" at "Oct 29, 2002 08:25:49 am" To: jh@lohi.eng.song.fi Date: Wed, 30 Oct 2002 09:39:40 +0859 () CC: hipsec@lists.freeswan.org, Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Juha; > > So what? Maybe we need not just different multi-homing > > solutions for large sites and small sites, but also for > > large stationary servers, home servers, and mobile multi-access > > end-hosts. I just don't know. But so many solutions sure > > sounds quite complex. > > we should have only one multihoming solution and that should definitely > also cover the mobile hosts that are simultaneously attached to several > mobile network (wlan, gprs, umts) and whose attachments can come and go > dynamically. ietf should not approve any limited solution that would > only apply to stationary multihomed sites. Unfortunately, your requirement for mobility is limited. Morevoer, it is partially satisfied already as mobile host implementation matter. A mobile host with multiple attachments is free to try all the attachment, if, through some attachment, communication with a home agent fails. We already have running IPv4 mobile host implementation with PHS and WLAN attachment. Note that it is a variant of end to end multihoming, though a property of moblity that care of addresses are variable and variable and that WLAN is always better than PHS makes the implementation easier. The basic reuirement for robust mobility, equivalent to the robustness of multihoming, is to have multiple mobility agents (such as home agents). Masataka Ohta From owner-multi6@ops.ietf.org Wed Oct 30 03:46:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05826 for ; Wed, 30 Oct 2002 03:46:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186oVj-000F2R-00 for multi6-data@psg.com; Wed, 30 Oct 2002 00:47:35 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 186oVh-000F0R-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 00:47:33 -0800 Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id EB87367103; Wed, 30 Oct 2002 00:06:27 -0500 (EST) Date: Wed, 30 Oct 2002 03:47:00 -0500 Subject: Re: The state of IPv6 multihoming development Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20021025090122.Y14896-100000@sequoia.muada.com> Message-Id: <2781E674-EBE4-11D6-927D-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Oct 25, 2002, at 03:18 America/Montreal, Iljitsch van Beijnum wrote: > In the real there are interconnection points within 2000 km or so from > well-connected locations for good reasons: it helps robustness, keeps > speed of light delays in check and it's usually cheaper. So why not > optimize for this, at least in the absense of something that is better > in al regards? That is not universal reality with North American networks at least. I also have found it not to be the case with some commercial networks in Europe and Asia/Pacific. My main objection to so-called "geographic addressing" is that it is often not congruent with the actual network topology. Ran From owner-multi6@ops.ietf.org Wed Oct 30 03:46:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05840 for ; Wed, 30 Oct 2002 03:46:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186oX6-000F4i-00 for multi6-data@psg.com; Wed, 30 Oct 2002 00:49:00 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 186oX4-000F45-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 00:48:58 -0800 Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 3910667103; Wed, 30 Oct 2002 00:07:54 -0500 (EST) Date: Wed, 30 Oct 2002 03:48:26 -0500 Subject: Re: draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20021025140820.X14896-100000@sequoia.muada.com> Message-Id: <5AF35C01-EBE4-11D6-927D-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Oct 25, 2002, at 08:35 America/Montreal, Iljitsch van Beijnum wrote: > 2 Normativity removed (Brian E Carpenter) I actually object to this change. It is *desirable* that approaches which substantially don't meet the requirements get disallowed. That is in fact the main reason for doing requirements in the first place. Ran From owner-multi6@ops.ietf.org Wed Oct 30 04:25:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06512 for ; Wed, 30 Oct 2002 04:25:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186p7B-000GNJ-00 for multi6-data@psg.com; Wed, 30 Oct 2002 01:26:17 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186p79-000GN7-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 01:26:15 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9U9PmG38676; Wed, 30 Oct 2002 10:25:49 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 30 Oct 2002 10:25:48 +0100 (CET) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: Re: draft-ietf-multi6-multihoming-requirements-04.txt In-Reply-To: <5AF35C01-EBE4-11D6-927D-00039357A82A@extremenetworks.com> Message-ID: <20021030095758.A36604-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 30 Oct 2002, RJ Atkinson wrote: > > 2 Normativity removed (Brian E Carpenter) > I actually object to this change. It is *desirable* that approaches > which substantially don't meet the requirements get disallowed. The IETF doesn't get to disallow things. > That is in fact the main reason for doing requirements in the first > place. I'm missing the part where you say what should be in the requirements instead. I'm also missing the part where the chairs help move all of this along, one way or another. From owner-multi6@ops.ietf.org Wed Oct 30 05:13:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07013 for ; Wed, 30 Oct 2002 05:13:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186psS-000I2P-00 for multi6-data@psg.com; Wed, 30 Oct 2002 02:15:08 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 186psR-000I1W-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 02:15:07 -0800 Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 653C167103; Wed, 30 Oct 2002 01:34:03 -0500 (EST) Date: Wed, 30 Oct 2002 05:14:34 -0500 Subject: Re: draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20021030095758.A36604-100000@sequoia.muada.com> Message-Id: <639B353A-EBF0-11D6-927D-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Oct 30, 2002, at 04:25 America/Montreal, Iljitsch van Beijnum wrote: > On Wed, 30 Oct 2002, RJ Atkinson wrote: > >>> 2 Normativity removed (Brian E Carpenter) > >> I actually object to this change. It is *desirable* that approaches >> which substantially don't meet the requirements get disallowed. > > The IETF doesn't get to disallow things. IETF WGs have used requirements documents to disallow proposals for years, not sure why you have concluded otherwise. >> That is in fact the main reason for doing requirements in the first >> place. > > I'm missing the part where you say what should be in the requirements > instead. I've made numerous comments on the requirements draft over the life of this WG, as the archives clearly show. Not sure how you missed all of them, but checking the WG archives should reveal them all. Ran From owner-multi6@ops.ietf.org Wed Oct 30 05:17:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07064 for ; Wed, 30 Oct 2002 05:17:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186pxG-000IEq-00 for multi6-data@psg.com; Wed, 30 Oct 2002 02:20:06 -0800 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net ident=4591-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-take-this-and-log-it!) by psg.com with esmtp (Exim 3.36 #2) id 186pxD-000IEB-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 02:20:04 -0800 Received: by ab.use.net (Postfix, from userid 3005) id 3C354AE9; Wed, 30 Oct 2002 10:20:00 +0000 (GMT) To: iljitsch@muada.com, rja@extremenetworks.com Subject: status update (was Re: draft-ietf-multi6-multihoming-requirements-04.txt) Cc: multi6@ops.ietf.org Message-Id: <20021030102000.3C354AE9@ab.use.net> Date: Wed, 30 Oct 2002 10:20:00 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=1.9 required=5.0 tests=SHORT_RECEIVED_LINE,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk | I'm also missing the part where the chairs help move all of this along, | one way or another. The chairs are in unavoidable travel/transit/other_obligations but have agreed an approach we hope moves all of this along (one way or another), and will within the next two or three days post our ideas formally for digestion and review by the wg mailing list. Sean. From owner-multi6@ops.ietf.org Wed Oct 30 05:46:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07735 for ; Wed, 30 Oct 2002 05:46:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186qOY-000JIc-00 for multi6-data@psg.com; Wed, 30 Oct 2002 02:48:18 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186qOU-000JHq-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 02:48:14 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9UAlo038763; Wed, 30 Oct 2002 11:47:50 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 30 Oct 2002 11:47:50 +0100 (CET) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: Re: draft-ietf-multi6-multihoming-requirements-04.txt In-Reply-To: <639B353A-EBF0-11D6-927D-00039357A82A@extremenetworks.com> Message-ID: <20021030114200.I36604-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 30 Oct 2002, RJ Atkinson wrote: > > The IETF doesn't get to disallow things. > IETF WGs have used requirements documents to disallow proposals for > years, not sure why you have concluded otherwise. Yes, the IETF has jurisdiction over its wgs, but not over much of anything else. People ignore IETF wisdom all the time. That's why the IETF is under the obligation to come up with solutions that are so good people really want them, rather than adopt them because they're told to. > > I'm missing the part where you say what should be in the requirements > > instead. > I've made numerous comments on the requirements draft over the life of > this WG, > as the archives clearly show. Not sure how you missed all of them, > but checking the WG archives should reveal them all. Without going back and reading everything, I think it's safe to say it would be impossible to include all the comments everyone made over the life time of this wg into the requirements. So if you could state in which way you'd want the requirements to change, based on the current situation, that would be good. From owner-multi6@ops.ietf.org Wed Oct 30 05:46:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07755 for ; Wed, 30 Oct 2002 05:46:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186qOu-000JJL-00 for multi6-data@psg.com; Wed, 30 Oct 2002 02:48:40 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186qOs-000JJ9-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 02:48:38 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9UAm5O38767; Wed, 30 Oct 2002 11:48:05 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 30 Oct 2002 11:48:05 +0100 (CET) From: Iljitsch van Beijnum To: Sean Doran cc: , Subject: Re: status update (was Re: draft-ietf-multi6-multihoming-requirements-04.txt) In-Reply-To: <20021030102000.3C354AE9@ab.use.net> Message-ID: <20021030114753.Q36604-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 30 Oct 2002, Sean Doran wrote: > The chairs are in unavoidable travel/transit/other_obligations but > have agreed an approach we hope moves all of this along (one way or another), > and will within the next two or three days post our ideas formally > for digestion and review by the wg mailing list. Excellent. From owner-multi6@ops.ietf.org Wed Oct 30 05:58:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07973 for ; Wed, 30 Oct 2002 05:58:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186qZi-000Jps-00 for multi6-data@psg.com; Wed, 30 Oct 2002 02:59:50 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186qZf-000Jpe-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 02:59:48 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9UAxNh38785; Wed, 30 Oct 2002 11:59:24 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 30 Oct 2002 11:59:23 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Nikander cc: Subject: Re: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development) In-Reply-To: <3DBD9CB4.50806@nomadiclab.com> Message-ID: <20021030115200.J36604-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 28 Oct 2002, Pekka Nikander wrote: > > Why do all this checking? Just assume the host is interested in the > > traffic until it tells you otherwise. > Remember that maybe there is no host there. Maybe the target is > to flood a network. In IPv6 it is fairly easy to select an empty > address, in fact probably easier than to pick an existing host. But unlike with v4, there is a good chance you'll get a host unreachable back. > > For TCP apps, you're pretty much > > guaranteed to be in slow start anyway, so there wouldn't be much > > flooding. > In TCP the attacker can anticipate what you send and send > you faked acks, probably even trick you to send data on > much faster rate than what you otherwise would do. Good point. We need something to protect against that. > The checking just takes on round trip, and you can even > piggypack your regular data. Yes, that would be a good way to handle it. Do you agree that doing this at the time the first choice address becomes unavailable makes more sense than doing it at the time of initialization? > > If the host at the new address doesn't want the traffic, there should be > > a way for it to make the sender stop without relying on transport > > mechanisms such as TCP RSTs. It would be good if the host at the new > > address receives the IP address from which all of this was initiated so > > an attacker can be traced easily. > I agree with the value of sending the initial address. However, > we must remember that maybe there is no host in the first place, > and at the time when the local router knows this for sure, it > may be already too late: the router may be completely flooded > with all those extra streams, maybe even targetted to different > address each. I didn't think this was a very likely attack scenario because it is so expensive for the attacker, but now that I think about it: it would be a viable attack because the attacker gets to bypass any filters the attacked network may have in place. I don't really see any way around this, though, except make this attack as expensive as possible for the attacker. From owner-multi6@ops.ietf.org Wed Oct 30 06:56:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10568 for ; Wed, 30 Oct 2002 06:56:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186rUK-000MQX-00 for multi6-data@psg.com; Wed, 30 Oct 2002 03:58:20 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186rUG-000MQG-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 03:58:17 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9UBvgr38873; Wed, 30 Oct 2002 12:57:45 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 30 Oct 2002 12:57:42 +0100 (CET) From: Iljitsch van Beijnum To: Tony Li cc: "J. Noel Chiappa" , Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: Message-ID: <20021030120513.A36604-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 29 Oct 2002, Tony Li wrote: > | However, if we can build a naming hierarchy in which > | most multihomed networks connect to two places that are > | very close in the hierarchy, this buys us aggregatability. > Unfortunately, that's not going to be so simple. What happens > when some organization that spans geographic areas decides > that they want to multihome through providers on either sides > of their particular continent? Or even different continents? Very few non-ISP organizations do this, as it requires them to move traffic over their internal network which costs money, while receiving the traffic where it eventually needs to be usually doesn't cost more than receiving it at any other location. In fact, large organizations with a large address block of their own often announce more specifics in different locations. There is usually no technical reason for having a large block rather than several smaller ones. If we can solve the problem for all other multihomers except the ones that connect to the net in locations very far apart and _need_ to do "internal transit", I think that would be good enough. Don't forget that at this time, NOBODY other than ISPs gets to multihome in IPv6. > | That's one of the problems with networking: even > | if done wrong it can work so people don't even see they're doing it > | wrong. But then sometimes this is an advantage as you can still get > | things to work even if there is a reason why it can't be done right. > Exactly. What we want to build is a routing architecture that is > never going to have to be replaced. I don't think that's in the charter for this wg, but I agree this is a worthy goal. However, we should also recognize that _some_ form of multihoming in IPv6 is necessary _soon_ (at a recent AMS-IX technical meeting the fact that the exchange couldn't get provider independent IPv6 address space was debated at length, RIPE has similar problems and that's just what I know first hand). That's the reason I came up with my provider-internal draft, which I originally named "geo for now" because it only provides a short-term solution. Unfortunately, it looks like the RIRs aren't going to implement a new address allocation mechanism as long as this doesn't get the IETF stamp of approval, despite the fact that the draft only proposes new operational practices and not a new protocol. > It's too difficult to reach in and > change it, so you'd like it to be done right the first time. I don't think "this" is the first time. :-) > Geographic aggregation is fine if the topology does indeed provide > a convenient aggregation boundary. Geography in itself is useless, as it isn't visible to the network. However, aggregation makes the logical path longer. If we can use geography to map long logical paths to short physical ones, that isn't an issue and we can aggregate as aggressively as possible. In other words: if I have to route a packet to a place where more specific information is known, it helps if this place is in the direction the packet has to travel anyway. > But in many cases, there will be no > such convenient boundary. What do you do? You cannot make an exception > and flat route any enterprise that has such links, because then their > overhead dominates the cost of all routing and you're not sufficiently > scalable. If we require a solution (even a short-term one) to address this fully, then yes, this is a problem. However, I think we can leave this problem unsolved for now as there doesn't seem to be a good reason for an organization to do this other than cost saving and we're not in the business of making the internet a more expensive place for all to accomodate savings for some. > As has been remarked elsewhere, we've been around and around and > around on this topic for the last decade. We have no new answers, > only the bitter pill of reality that we cannot all seem to swallow > at the same time. I think we're getting closer as we've been mostly discussing multi-address solutions the past week and these are compatible with the reality pill. There are many concerns with this type of solution, but I haven't seen any show stoppers yet. The only question is whether we can agree on a temporary fix to give us more time to develop one or more of these solutions. Iljitsch From owner-multi6@ops.ietf.org Wed Oct 30 08:45:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14541 for ; Wed, 30 Oct 2002 08:45:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186t9u-0001B4-00 for multi6-data@psg.com; Wed, 30 Oct 2002 05:45:22 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 186t9q-0001Ar-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 05:45:18 -0800 From: Masataka Ohta Message-Id: <200210301336.WAA26277@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA26277; Wed, 30 Oct 2002 22:35:45 +0859 Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: <200210292151.QAA19572@ginger.lcs.mit.edu> from "J. Noel Chiappa" at "Oct 29, 2002 04:51:46 pm" To: "J. Noel Chiappa" Date: Wed, 30 Oct 2002 22:35:44 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Noel; > You see *only* 100K destinations in DFZ routing tables because some large > percentage of the informaion has *already* been hidden (through use of > hierarchical information hiding, e.g. subnets, etc). Agreed, strongly. > > From what I gather from other stuff that refers to this, the down side > > is a longer path. > > The tradeoff between routing efficiency (i.e. path length) and routing > overhead (i.e. storage/computation/messages) is central to large-scale routing. Considering geographically large, such as intercontinental, subnets, host route is, technically, the only way to minimize the shortest path. However, practically, the minimization for inter-ISP traffic is impossible, as we can not expect all ISPs use consistent routing metric, not because there is no consistent metric (e.g. geographycal distance is an internationally consistent metric) but because there is no metric to be compatible with all the business models of various ISPs, which is why BGP does not use any metric. Many, if not all, ISPs are assuming ASes are local with mostly same diameter and untimately relies on AS-path length, down side of which is, of course, a longer path. Masataka Ohta From owner-multi6@ops.ietf.org Wed Oct 30 09:36:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16532 for ; Wed, 30 Oct 2002 09:36:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186tyi-0003ka-00 for multi6-data@psg.com; Wed, 30 Oct 2002 06:37:52 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #2) id 186tyg-0003j7-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 06:37:50 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9UEbGSC051490; Wed, 30 Oct 2002 15:37:16 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9UEbFdH054118; Wed, 30 Oct 2002 15:37:15 +0100 Received: from dhcp22-101.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA71616 from ; Wed, 30 Oct 2002 15:37:13 +0100 Message-Id: <3DBFEE8D.4F0CE3BE@hursley.ibm.com> Date: Wed, 30 Oct 2002 15:37:01 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: RJ Atkinson Cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-04.txt References: <5AF35C01-EBE4-11D6-927D-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ran, RJ Atkinson wrote: > > On Friday, Oct 25, 2002, at 08:35 America/Montreal, Iljitsch van > Beijnum wrote: > > 2 Normativity removed (Brian E Carpenter) > > I actually object to this change. It is *desirable* that approaches > which substantially don't meet the requirements get disallowed. > That is in fact the main reason for doing requirements in the first > place. In some kind of free space, I'd agree with you. But given that this WG has been manifestly hung up on this point since Salt Lake City, I think we need to move on, and this is the only way I can see to do so. The perceived requirements overconstrain the solution space, and the only exit from that box is pragmatism. Brian From owner-multi6@ops.ietf.org Wed Oct 30 11:38:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23890 for ; Wed, 30 Oct 2002 11:38:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186vsR-000AIn-00 for multi6-data@psg.com; Wed, 30 Oct 2002 08:39:31 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 186vs9-000AFp-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 08:39:13 -0800 Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id CE58667103; Wed, 30 Oct 2002 07:57:56 -0500 (EST) Date: Wed, 30 Oct 2002 11:38:21 -0500 Subject: Re: draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20021030114200.I36604-100000@sequoia.muada.com> Message-Id: <005F7490-EC26-11D6-900F-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Oct 30, 2002, at 05:47 America/Montreal, Iljitsch van Beijnum wrote: > So if you could state in > which way you'd want the requirements to change, based on the current > situation, that would be good. Restore the normative nature of the requirements document -- including changing "may/should/must" back to "MAY/SHOULD/MUST". Ran From owner-multi6@ops.ietf.org Wed Oct 30 11:50:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24739 for ; Wed, 30 Oct 2002 11:50:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186w51-000B6U-00 for multi6-data@psg.com; Wed, 30 Oct 2002 08:52:31 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 186w4y-000B6I-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 08:52:29 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9UGqM812575; Wed, 30 Oct 2002 18:52:22 +0200 Date: Wed, 30 Oct 2002 18:52:22 +0200 (EET) From: Pekka Savola To: RJ Atkinson cc: Iljitsch van Beijnum , Subject: Re: draft-ietf-multi6-multihoming-requirements-04.txt In-Reply-To: <005F7490-EC26-11D6-900F-00039357A82A@extremenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-11.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 30 Oct 2002, RJ Atkinson wrote: > On Wednesday, Oct 30, 2002, at 05:47 America/Montreal, Iljitsch van > Beijnum wrote: > > So if you could state in > > which way you'd want the requirements to change, based on the current > > situation, that would be good. > > Restore the normative nature of the requirements document > -- including changing "may/should/must" back to "MAY/SHOULD/MUST". What do you suggest _when_ (not if) we run into the situation that we can't think of any solution which would satisfy all MUST's? -- 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 Oct 30 13:29:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02092 for ; Wed, 30 Oct 2002 13:28:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186xbu-000Gq4-00 for multi6-data@psg.com; Wed, 30 Oct 2002 10:30:34 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 186xbs-000GoD-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 10:30:32 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 9E4DF23C44; Tue, 29 Oct 2002 13:36:41 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9UITwiI002478; Wed, 30 Oct 2002 10:29:58 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft-ietf-multi6-multihoming-requirements-04.txt Date: Wed, 30 Oct 2002 10:29:58 -0800 Message-ID: Thread-Topic: draft-ietf-multi6-multihoming-requirements-04.txt Thread-Index: AcKANRhv3DzQtZtyRwKjojjPPBDLowADP3Mg From: "Tony Li" To: "Pekka Savola" , "RJ Atkinson" Cc: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=-0.7 required=5.0 tests=SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA02092 May I suggest that this discussion is moot. We will only gain rough consensus if we have a proposal that does what we want, regardless of whether some words are capitalized. Our time is best spent dealing with the weighty technical issues, of which there is no shortage. Tony | -----Original Message----- | From: Pekka Savola [mailto:pekkas@netcore.fi] | Sent: Wednesday, October 30, 2002 8:52 AM | To: RJ Atkinson | Cc: Iljitsch van Beijnum; multi6@ops.ietf.org | Subject: Re: draft-ietf-multi6-multihoming-requirements-04.txt | | | On Wed, 30 Oct 2002, RJ Atkinson wrote: | > On Wednesday, Oct 30, 2002, at 05:47 America/Montreal, | Iljitsch van | > Beijnum wrote: | > > So if you could state in | > > which way you'd want the requirements to change, based | on the current | > > situation, that would be good. | > | > Restore the normative nature of the requirements document | > -- including changing "may/should/must" back to "MAY/SHOULD/MUST". | | What do you suggest _when_ (not if) we run into the | situation that we | can't think of any solution which would satisfy all MUST's? | | -- | 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 Oct 30 14:17:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05158 for ; Wed, 30 Oct 2002 14:17:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186yNR-000JXA-00 for multi6-data@psg.com; Wed, 30 Oct 2002 11:19:41 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 186yNP-000JVn-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 11:19:39 -0800 Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 4883467103; Wed, 30 Oct 2002 10:38:40 -0500 (EST) Date: Wed, 30 Oct 2002 14:19:07 -0500 Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20021030120513.A36604-100000@sequoia.muada.com> Message-Id: <75C46026-EC3C-11D6-8FC5-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Oct 30, 2002, at 06:57 America/Montreal, Iljitsch van Beijnum wrote: > On Tue, 29 Oct 2002, Tony Li wrote: >> Unfortunately, that's not going to be so simple. What happens >> when some organization that spans geographic areas decides >> that they want to multihome through providers on either sides >> of their particular continent? Or even different continents? > > Very few non-ISP organizations do this, as it requires them to move > traffic over their internal network which costs money, while receiving > the traffic where it eventually needs to be usually doesn't cost more > than receiving it at any other location. Our samples spaces must be different. I think that many non-ISP organisations multi-home via different providers on either sides of North America. The examples tend to be larger organisations rather than a mom-and-pop, but there seem to be very many examples of such organisations that do this today. Ran From owner-multi6@ops.ietf.org Wed Oct 30 14:44:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06479 for ; Wed, 30 Oct 2002 14:44:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186ymi-000L3w-00 for multi6-data@psg.com; Wed, 30 Oct 2002 11:45:48 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 186yme-000Kyn-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 11:45:44 -0800 Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id 7E7CF1C; Wed, 30 Oct 2002 21:51:49 +0200 (EET) Message-ID: <3DC036CA.1020809@nomadiclab.com> Date: Wed, 30 Oct 2002 21:45:14 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development) References: <20021030115200.J36604-100000@sequoia.muada.com> In-Reply-To: <20021030115200.J36604-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_05_08, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> In TCP the attacker can anticipate what you send and send >> you faked acks, probably even trick you to send data on >> much faster rate than what you otherwise would do. > > Good point. We need something to protect against that. > >> The checking just takes on round trip, and you can even >> piggypack your regular data. > > > Yes, that would be a good way to handle it. Do you agree that doing this > at the time the first choice address becomes unavailable makes more > sense than doing it at the time of initialization? From the security point of view it doesn't make much difference whether you make the check in the beginning or when the first choice address becomes unavailable. What is important is that you can strongly bind the existing connection between the first address pair to the secodary addresses, and that you check the validity of the secondary address before sending any larger amounts of data. --Pekka From owner-multi6@ops.ietf.org Wed Oct 30 15:06:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07942 for ; Wed, 30 Oct 2002 15:06:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186z8m-000MQo-00 for multi6-data@psg.com; Wed, 30 Oct 2002 12:08:36 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 186z8k-000MQc-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 12:08:34 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 12:08:33 -0800 Reply-To: From: "Tony Hain" To: "'Christian Kuhtz'" Cc: "'Michel Py'" , "'Tony Li'" , "'Iljitsch van Beijnum'" , Subject: RE: The state of IPv6 multihoming development Date: Wed, 30 Oct 2002 12:08:10 -0800 Message-ID: <07e801c28050$11f8eb20$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021027220540.B15478@ns1.arch.bellsouth.net> X-Spam-Status: No, hits=-4.3 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA07942 Christian Kuhtz wrote: > > A host decision does not affect traffic shaping for the outbound > > direction. The only choice it is making in that space is > the dst addr, > > and it has that responsibility today, even though it has no > > deterministic means of making that choice. The IPv6 address > selection > > rules add structure to that process. > > maybe i got this all wrong, but... > > if this means that a host is expected to make a decision > which path to > chose, i'm sorry, i don't see that happening and consider it > an absurd > notion. You did miss my point which was that the routers will always decide the path. The only thing the host decides is which entry in a dns response it will use for the dst, and which of its addresses it will use. > > the last thing i want is for an oracle server, or webserver, > or whatever to make a routing decision as to which addr or > iface to use. seems the trend is exactly the opposite.. to > get that decision _away_ from the host and have the backbone > of a given org take care of traffic management. > > any type of te will have to aggregated at a higher level than hosts. Yes, and the reality is that this will happen no matter what the host decides to use for addresses. This whole discussion is a bogon caused by the fear that the host might make any kind of decision. REALITY CHECK: it already does sort through the list of addresses in a DNS response, and if it has multiple interfaces it already has to decide which of those to use. Once the packet is in flight, the routers decide the path because that is their job. > > some of this is a technology and architectural decision, some > of this is also real world organizational skills. i do not > want to create a rqmt > that says that systems operations folks have to be omnipotent > systems & network wizards to configuration, manage and > troubleshoot their hosts. > > and i think that's exactly what you do when you push te > capabilities down to the host level. Nobody is pushing TE to the host level, there is simply a fear that will happen when a host chooses which of its addresses it will use as a source. > > > For the inbound direction, the remote and intermediate network > > managers have more impact on the actual path the bits will > take than > > the origin choice of source addr. All we have today is the illusion > > that a network manager can direct traffic toward his > network. Having 1 > > or N addresses doesn't change the granularity of traffic > engineering, > > so the argument is bogus. What it really boils down to is > that nodes > > outside the network manager's direct control are making a decision > > (any decision). This is about trust, not traffic engineering. > > nevermind that there are various bgp knobs today which allow > you to do exactly that (regulate inbound traffic) by changing > what prefixes are advertised where and how. Over a diminishing scope of influence. Yes you affect immediate neighbors, and depending on their filtering policy, you may influence their direct peers, but the strength of your ability to manage inbound traffic diminishes at every policy boundary. Tony > there is a > gating factor here in today's ipv4 world in terms of the > smallest chunk of addresses which can be pulled out of a > given aggregate. > > thanks, > christian > From owner-multi6@ops.ietf.org Wed Oct 30 15:11:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08227 for ; Wed, 30 Oct 2002 15:11:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186zEE-000Mu6-00 for multi6-data@psg.com; Wed, 30 Oct 2002 12:14:14 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 186zEC-000Mtu-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 12:14:12 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 12:14:17 -0800 Reply-To: From: "Tony Hain" To: "'Iljitsch van Beijnum'" Cc: Subject: RE: The state of IPv6 multihoming development Date: Wed, 30 Oct 2002 12:13:54 -0800 Message-ID: <07f301c28050$ded78340$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021028110302.C32506-100000@sequoia.muada.com> X-Spam-Status: No, hits=-1.5 required=5.0 tests=INVALID_MSGID,IN_REP_TO,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > ... The only > downside is that the other end has to implement something > similar. And you need a protocol to pass around the translation mappings to the other end so they can undo it. When the other end is a foreign network, why should they trust or accept the origin site? Tony From owner-multi6@ops.ietf.org Wed Oct 30 15:34:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09555 for ; Wed, 30 Oct 2002 15:34:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186zZV-000OBH-00 for multi6-data@psg.com; Wed, 30 Oct 2002 12:36:13 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 186zZT-000OAz-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 12:36:11 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 12:36:16 -0800 Reply-To: From: "Tony Hain" To: "'RJ Atkinson'" , "'Iljitsch van Beijnum'" Cc: Subject: RE: The state of IPv6 multihoming development Date: Wed, 30 Oct 2002 12:35:53 -0800 Message-ID: <07ff01c28053$f1514030$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <2781E674-EBE4-11D6-927D-00039357A82A@extremenetworks.com> X-Spam-Status: No, hits=-4.3 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA09555 RJ Atkinson wrote: > On Friday, Oct 25, 2002, at 03:18 America/Montreal, Iljitsch van > Beijnum wrote: > > In the real there are interconnection points within 2000 km > or so from > > well-connected locations for good reasons: it helps > robustness, keeps > > speed of light delays in check and it's usually cheaper. So why not > > optimize for this, at least in the absense of something > that is better > > in al regards? > > That is not universal reality with North American networks at > least. So expand the scope of the statement to 3000 km, and it holds for the densely populated parts of North America. > I also have found it not to be the case with some > commercial networks in Europe and Asia/Pacific. We can always find a exception, the question is can we find an approach that minimizes the number and impact of those exceptions? If we insist on finding the grand solution that will work for all cases, we will never do anything. > > My main objection to so-called "geographic addressing" is that it is > often > not congruent with the actual network topology. Over an arbitrary scope, you are correct. If we take a large enough scope, it becomes less clear. After all, there are only so many physical fiber runs under the oceans, and the places where they terminate is an even smaller number. Granted the logical circuit topology is not limited to that, but again, how many real exceptions will exist, and how many of those will exist despite every attempt to prevent them? I content that particularly in the case where someone has gone to the expense to pull a direct circuit out of their region, they will insist on and get flat routing in the remote region. The question is can we abstract that away in other regions? Tony > > Ran > > From owner-multi6@ops.ietf.org Wed Oct 30 15:36:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09725 for ; Wed, 30 Oct 2002 15:36:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186zbh-000OLC-00 for multi6-data@psg.com; Wed, 30 Oct 2002 12:38:29 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 186zbf-000OKx-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 12:38:28 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9UKc2g39901; Wed, 30 Oct 2002 21:38:02 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 30 Oct 2002 21:38:02 +0100 (CET) From: Iljitsch van Beijnum To: Tony Hain cc: Subject: RE: The state of IPv6 multihoming development In-Reply-To: <07f301c28050$ded78340$4b194104@eagleswings> Message-ID: <20021030213453.J39291-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 30 Oct 2002, Tony Hain wrote: > And you need a protocol to pass around the translation mappings to the > other end so they can undo it. When the other end is a foreign network, > why should they trust or accept the origin site? If the level of trust is zero to begin with, there should be no problem extending this "trust" so a third party. However, there may be some unexpected cases. For instance, an untrusted host tries to bind a trusted address to the connection and then inherits the higher level of trust. I'm sure we can work all of this out when there is something concrete on the table. From owner-multi6@ops.ietf.org Wed Oct 30 15:51:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10744 for ; Wed, 30 Oct 2002 15:51:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186zpu-000PEG-00 for multi6-data@psg.com; Wed, 30 Oct 2002 12:53:10 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 186zps-000PE4-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 12:53:08 -0800 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9UKr6KV024569; Wed, 30 Oct 2002 21:53:06 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Oct 2002 21:53:06 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C47@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Iljitsch van Beijnum'" , Tony Hain Cc: multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Date: Wed, 30 Oct 2002 21:53:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-1.9 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > And you need a protocol to pass around the translation > mappings to the > > other end so they can undo it. When the other end is a > foreign network, > > why should they trust or accept the origin site? > > If the level of trust is zero to begin with, there should > be no problem > extending this "trust" so a third party. => Is this an argument for global PKI? Presumably this protocol would work between arbitray sites? > > However, there may be some unexpected cases. For instance, > an untrusted > host tries to bind a trusted address to the connection and > then inherits > the higher level of trust. I'm sure we can work all of this out when > there is something concrete on the table. => I don't think this will be a trivial task. Especially when you're aggregating the updates to handle large prefixes (instead of updating each address at a time). Hesham > > From owner-multi6@ops.ietf.org Wed Oct 30 15:55:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11065 for ; Wed, 30 Oct 2002 15:55:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186zuG-000PXW-00 for multi6-data@psg.com; Wed, 30 Oct 2002 12:57:40 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 186zuC-000PWo-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 12:57:36 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 30 Oct 2002 12:57:41 -0800 Reply-To: From: "Tony Hain" To: Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Wed, 30 Oct 2002 12:57:18 -0800 Message-ID: <080c01c28056$ef302d90$4b194104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Spam-Status: No, hits=-4.2 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA11065 Tony Li wrote: > ... > Exactly. What we want to build is a routing architecture that is > never going to have to be replaced. It's too difficult to > reach in and change it, so you'd like it to be done right the > first time. Unfortunately 'never' is a very long time, and we will continue to do nothing while we wait for the answer. > Since scalability is key and the way to scale is > to keep the overhead low, a solution that has higher overhead > is sub-optimal and to be avoided. > > Geographic aggregation is fine if the topology does indeed > provide a convenient aggregation boundary. But in many > cases, there will be no > such convenient boundary. What do you do? You cannot make > an exception and flat route any enterprise that has such > links, because then their overhead dominates the cost of all > routing and you're not sufficiently scalable. This point is arguable, because it is making a blanket statement about a process with multiple causes. For the truly global enterprise with multiple exposure points and global internal network that could handle a route shift, why not? There are fewer than 11,000 toady as evidenced by the number of AS's injecting prefixes into BGP. (I suspect the real number is less than 2,000 that could deal with taking a full traffic load at multiple points) The real problem is that there is no clear way to say one organization can while another can't. For the case where an enterprise is simply looking for better/cheaper service in a remote region, we are into economic rather than technical arguments. These organizations aren't concerned about their impact on routing, so the only way to deal with them is to give them the level of service they need while making it cheaper to constrain the topology than it is to blow out the tables. Tony From owner-multi6@ops.ietf.org Wed Oct 30 16:14:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12159 for ; Wed, 30 Oct 2002 16:14:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1870CM-0000lN-00 for multi6-data@psg.com; Wed, 30 Oct 2002 13:16:22 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 1870CK-0000ib-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 13:16:20 -0800 Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id B9C3367103 for ; Wed, 30 Oct 2002 12:35:21 -0500 (EST) Date: Wed, 30 Oct 2002 16:15:49 -0500 Subject: Re: The state of IPv6 multihoming development Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: RJ Atkinson To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <07ff01c28053$f1514030$4b194104@eagleswings> Message-Id: X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Oct 30, 2002, at 15:35 America/Montreal, Tony Hain wrote: > We can always find a exception, the question is can we find an approach > that minimizes the number and impact of those exceptions? If we insist > on finding the grand solution that will work for all cases, we will > never do anything. I think it is important to understand what the deployed reality is today. That impacts how widely useful some solutions might be, particularly in the case of so-called "geographic addressing". I also think it is important to understand when a given solution will not work with some/all deployed networks. Financial realities mean that an IETF document standardising a solution that requires more interconnection probably will not lead to firms changing their topologies anytime soon to meet such a requirement. > Over an arbitrary scope, you are correct. If we take a large enough > scope, it becomes less clear. After all, there are only so many > physical > fiber runs under the oceans, and the places where they terminate is an > even smaller number. Granted the logical circuit topology is not > limited > to that, but again, how many real exceptions will exist, and how many > of > those will exist despite every attempt to prevent them? A fair number of exceptions exist today. And as the scope gets larger, the aggregation potential appears to decline -- a kind of catch-22. Ran From owner-multi6@ops.ietf.org Wed Oct 30 16:47:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14163 for ; Wed, 30 Oct 2002 16:47:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1870i3-0002lh-00 for multi6-data@psg.com; Wed, 30 Oct 2002 13:49:07 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1870i1-0002lT-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 13:49:05 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9ULmdT40037; Wed, 30 Oct 2002 22:48:40 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 30 Oct 2002 22:48:39 +0100 (CET) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: Message-ID: <20021030223459.X39291-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 30 Oct 2002, RJ Atkinson wrote: > I think it is important to understand what the deployed reality is > today. > That impacts how widely useful some solutions might be, particularly > in the case of so-called "geographic addressing". I also think it > is important to understand when a given solution will not work with > some/all deployed networks. Financial realities mean that an IETF > document standardising a solution that requires more interconnection > probably will not lead to firms changing their topologies anytime soon > to meet such a requirement. Nobody is proposing a solution that needs more exchanges in order to be useful. Just to be safe I've included a statement to this effect in the abstract of draft-van-beijnum-multi6-isp-int-aggr-00.txt. New exchanges would only be necessary if this solution were to be used much longer than intended, but as we approach one multihomer in 10 people even flat routing for a single city such as New York, Tokio or Mexico City will be problematic. > > Granted the logical circuit topology is not limited > > to that, but again, how many real exceptions will exist, and how many > > of those will exist despite every attempt to prevent them? > A fair number of exceptions exist today. But then what's common today may be tomorrow's exception and the other way around. For instance, someone with ADSL doing BGP routing with IPv6 and a "real" AS number is very rare today, while the number of organizations connecting to the internet in far apart locations is something that regularly happens (although I suspect the actual number isn't all that high). In the future, this will very likely be different. It could even be argued that existing cases are of no importance to routing scalability and it's enough to make new cases scalable. Also note that as of today, NO end-user networks are multihomed in IPv6. Iljitsch From owner-multi6@ops.ietf.org Wed Oct 30 16:50:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14342 for ; Wed, 30 Oct 2002 16:50:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1870ls-000323-00 for multi6-data@psg.com; Wed, 30 Oct 2002 13:53:04 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1870lq-00031r-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 13:53:02 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9ULqcc40044; Wed, 30 Oct 2002 22:52:38 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 30 Oct 2002 22:52:38 +0100 (CET) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: <75C46026-EC3C-11D6-8FC5-00039357A82A@extremenetworks.com> Message-ID: <20021030224927.X39291-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 30 Oct 2002, RJ Atkinson wrote: > > Very few non-ISP organizations do this, as it requires them to move > > traffic over their internal network which costs money, while receiving > > the traffic where it eventually needs to be usually doesn't cost more > > than receiving it at any other location. > Our samples spaces must be different. I think that many non-ISP > organisations > multi-home via different providers on either sides of North America. It is certainly possible we're seeing different things from the places we're sitting. But the real question isn't whether they _connect_ on opposite ends of a continent or ocean, but whether they need to announce a globally visible route in both locations. This is only absolutely necessary if they prefer traffic to flow over their internal network rather than over an ISP network. It is also desireable for backup purposes but I feel this isn't an important enough reason to allow it. From owner-multi6@ops.ietf.org Wed Oct 30 16:57:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14841 for ; Wed, 30 Oct 2002 16:57:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1870sA-0003P7-00 for multi6-data@psg.com; Wed, 30 Oct 2002 13:59:34 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1870s8-0003Ot-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 13:59:32 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9ULwwV40059; Wed, 30 Oct 2002 22:58:58 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 30 Oct 2002 22:58:57 +0100 (CET) From: Iljitsch van Beijnum To: "Hesham Soliman (EAB)" cc: Tony Hain , Subject: RE: The state of IPv6 multihoming development In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C47@Esealnt861.al.sw.ericsson.se> Message-ID: <20021030225326.O39291-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 30 Oct 2002, Hesham Soliman (EAB) wrote: > > If the level of trust is zero to begin with, there should > > be no problem extending this "trust" so a third party. > => Is this an argument for global PKI? Presumably > this protocol would work between arbitray sites? No, this is an argument for not building elaborate security mechanisms when there is nothing to secure. If someone who I don't know visits my web site or connects to my mail server, and then halfway through the session the connection is transferred to another IP addres, why would I care? The only time this is dangerous would be when I communicate with a trusted host but if this trusted host tells me it has another address then presumably, I should trust this information as well. Obviously things are different when someone at an address I don't know tells me she is a trusted host. Then she has to present credentials. > > I'm sure we can work all of this out when > > there is something concrete on the table. > => I don't think this will be a trivial task. No, but that doesn't mean we have to start with this part. :-) Iljitsch From owner-multi6@ops.ietf.org Wed Oct 30 17:05:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15203 for ; Wed, 30 Oct 2002 17:05:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18710C-000419-00 for multi6-data@psg.com; Wed, 30 Oct 2002 14:07:52 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 18710A-00040x-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 14:07:50 -0800 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9UM7mKV000993; Wed, 30 Oct 2002 23:07:48 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 30 Oct 2002 23:07:48 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C4C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Iljitsch van Beijnum'" , "Hesham Soliman (EAB)" Cc: Tony Hain , multi6@ops.ietf.org Subject: RE: The state of IPv6 multihoming development Date: Wed, 30 Oct 2002 23:07:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-1.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > > If the level of trust is zero to begin with, there should > > > be no problem extending this "trust" so a third party. > > > => Is this an argument for global PKI? Presumably > > this protocol would work between arbitray sites? > > No, this is an argument for not building elaborate security > mechanisms > when there is nothing to secure. => Hmm, see below, now I have a _lot_ of questions :) If someone who I don't > know visits my > web site => Why do you assume you don't know this someone? or connects to my mail server, and then halfway through the > session the connection is transferred to another IP addres, > why would I > care? => Because: - The new source address (that you'll reply to) could be someone else that will accuse you of bombing them - Your server might be offering secure internet banking and suddenly it's not so secure - You might be a popular server and all of a sudden people can't reach you because their traffic is diverted to a victim. Maybe the victim will become popular :) I'm pretty sure there are more reasons. The only time this is dangerous would be when I > communicate with a > trusted host but if this trusted host tells me it has > another address > then presumably, I should trust this information as well. => Yes but how did you establish that trust? The identifier used is the key problem here. Hesham@ericsson.com tells you nothing about whether I can divert traffic from 3ffe::1 to ABCD::1. This is the exact problem we had in MIPv6. Obviously > things are different when someone at an address I don't > know tells me > she is a trusted host. Then she has to present credentials. => Careful how you pick "credentials". > No, but that doesn't mean we have to start with this part. :-) > => oh no, it's MIPv6 all over again :) trust me if you don't start thinking about this early on it won't be fun later ! Hesham From owner-multi6@ops.ietf.org Wed Oct 30 17:37:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16562 for ; Wed, 30 Oct 2002 17:37:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1871UJ-0005wk-00 for multi6-data@psg.com; Wed, 30 Oct 2002 14:38:59 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 1871UI-0005vj-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 14:38:58 -0800 Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 1D3CC67103; Wed, 30 Oct 2002 13:58:00 -0500 (EST) Date: Wed, 30 Oct 2002 17:38:26 -0500 Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20021030224927.X39291-100000@sequoia.muada.com> Message-Id: <4E0160CB-EC58-11D6-8FC5-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Oct 30, 2002, at 16:52 America/Montreal, Iljitsch van Beijnum wrote: > It is also desireable for backup > purposes but I feel this isn't an important enough reason to allow it. Backup is a big driver for current multihomed customers. Disallowing that really reduces the applicability of an approach. Ran From owner-multi6@ops.ietf.org Wed Oct 30 17:41:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16765 for ; Wed, 30 Oct 2002 17:41:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1871Yd-0006Hj-00 for multi6-data@psg.com; Wed, 30 Oct 2002 14:43:27 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1871Yb-0006HI-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 14:43:26 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9UMh1e40138; Wed, 30 Oct 2002 23:43:01 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 30 Oct 2002 23:43:01 +0100 (CET) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: <4E0160CB-EC58-11D6-8FC5-00039357A82A@extremenetworks.com> Message-ID: <20021030233841.T39291-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 30 Oct 2002, RJ Atkinson wrote: > > It is also desireable for backup > > purposes but I feel this isn't an important enough reason to allow it. > Backup is a big driver for current multihomed customers. > Disallowing that really reduces the applicability of an approach. I don't mean that these people shouldn't have backups. What I mean is that injecting a globally visible route into the infrastructure 100% of the time to avoid sub-optimal, but otherwise functional routing 1% of the time isn't a good use of scarce resources. From owner-multi6@ops.ietf.org Wed Oct 30 19:54:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20594 for ; Wed, 30 Oct 2002 19:54:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1873cN-000Diw-00 for multi6-data@psg.com; Wed, 30 Oct 2002 16:55:27 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 1873cL-000DiK-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 16:55:25 -0800 From: Masataka Ohta Message-Id: <200210310047.JAA01627@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA01627; Thu, 31 Oct 2002 09:47:10 +0900 Subject: Re: draft-ietf-multi6-multihoming-requirements-04.txt In-Reply-To: <005F7490-EC26-11D6-900F-00039357A82A@extremenetworks.com> from RJ Atkinson at "Oct 30, 2002 11:38:21 am" To: RJ Atkinson Date: Thu, 31 Oct 2002 09:47:09 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Ran; > > So if you could state in > > which way you'd want the requirements to change, based on the current > > situation, that would be good. > > Restore the normative nature of the requirements document > -- including changing "may/should/must" back to "MAY/SHOULD/MUST". The problem is that the draft already contains mutually exclusive requirements. Requiring a requirement document is to suppress discussion. It is a political way to autoritate an existing proposal, by a list of requirements biased for the proposal. Technically, it is harmful and, for problems related to multiple areas of expertise, hopeless. Masataka Ohta From owner-multi6@ops.ietf.org Wed Oct 30 21:15:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22482 for ; Wed, 30 Oct 2002 21:15:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1874sd-000IBJ-00 for multi6-data@psg.com; Wed, 30 Oct 2002 18:16:19 -0800 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.36 #2) id 1874sb-000IB7-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 18:16:17 -0800 content-class: urn:content-classes:message Subject: RE: draft-ietf-multi6-multihoming-requirements-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 2002 18:16:17 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD28C@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: draft-ietf-multi6-multihoming-requirements-04.txt Thread-Index: AcKAeq7xXhsgrjmER12Q4fm1s9WLtgACKhJw From: "Michel Py" To: "Masataka Ohta" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA22482 > Masataka Ohta wrote: > It is a political way to autoritate an existing > proposal, by a list of requirements biased for > the proposal. Which one? I was not aware that we had any. Michel. From owner-multi6@ops.ietf.org Wed Oct 30 21:19:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22532 for ; Wed, 30 Oct 2002 21:19:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1874xk-000IYL-00 for multi6-data@psg.com; Wed, 30 Oct 2002 18:21:36 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 1874xi-000IV1-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 18:21:35 -0800 Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 1793C67103; Wed, 30 Oct 2002 17:40:34 -0500 (EST) Date: Wed, 30 Oct 2002 21:20:59 -0500 Subject: Re: draft-ietf-multi6-multihoming-requirements-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: multi6@ops.ietf.org To: Masataka Ohta From: RJ Atkinson In-Reply-To: <200210310047.JAA01627@necom830.hpcl.titech.ac.jp> Message-Id: <64FC98B6-EC77-11D6-A53C-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_02_03,USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Oct 30, 2002, at 19:48 America/Montreal, Masataka Ohta wrote: > The problem is that the draft already contains mutually > exclusive requirements. It would be helpful if you would list any that you find so any that exist can be resolved. Details help. Cheers, Ran From owner-multi6@ops.ietf.org Wed Oct 30 21:50:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23492 for ; Wed, 30 Oct 2002 21:50:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1875R9-000KHP-00 for multi6-data@psg.com; Wed, 30 Oct 2002 18:51:59 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 1875R6-000KBD-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 18:51:56 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id DC68334431; Wed, 30 Oct 2002 19:00:18 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9V2pKiI005155; Wed, 30 Oct 2002 18:51:20 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Wed, 30 Oct 2002 18:51:20 -0800 Message-ID: Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcKAZjdpBrIVmreyQnG0/SJj/wS9iwAIcX8Q From: "Tony Li" To: "Iljitsch van Beijnum" , "RJ Atkinson" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA23492 | > > It is also desireable for backup | > > purposes but I feel this isn't an important enough | reason to allow it. | | > Backup is a big driver for current multihomed customers. | > Disallowing that really reduces the applicability of an approach. | | I don't mean that these people shouldn't have backups. What | I mean is | that injecting a globally visible route into the | infrastructure 100% of | the time to avoid sub-optimal, but otherwise functional | routing 1% of | the time isn't a good use of scarce resources. We might well be in violent agreement. Are you suggesting that we disallow the globally visible route? Or that we disallow them from making multiple connections? Tony From owner-multi6@ops.ietf.org Wed Oct 30 22:03:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23859 for ; Wed, 30 Oct 2002 22:03:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1875e9-000L5G-00 for multi6-data@psg.com; Wed, 30 Oct 2002 19:05:25 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 1875e8-000L45-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 19:05:24 -0800 From: Masataka Ohta Message-Id: <200210310256.LAA02794@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA02794; Thu, 31 Oct 2002 11:56:16 +0900 Subject: Re: draft-ietf-multi6-multihoming-requirements-04.txt In-Reply-To: <2B81403386729140A3A899A8B39B04640BD28C@server2000> from Michel Py at "Oct 30, 2002 06:16:17 pm" To: Michel Py Date: Thu, 31 Oct 2002 11:56:15 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Michel; > > Masataka Ohta wrote: > > It is a political way to autoritate an existing > > proposal, by a list of requirements biased for > > the proposal. > > Which one? I was not aware that we had any. It is a generic statement and is not the case of multi6 WG. Masataka Ohta From owner-multi6@ops.ietf.org Wed Oct 30 22:13:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23984 for ; Wed, 30 Oct 2002 22:13:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1875nt-000Lh4-00 for multi6-data@psg.com; Wed, 30 Oct 2002 19:15:29 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 1875nr-000Lgm-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 19:15:28 -0800 From: Masataka Ohta Message-Id: <200210310304.MAA02913@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA02913; Thu, 31 Oct 2002 12:04:27 +0900 Subject: Re: draft-ietf-multi6-multihoming-requirements-04.txt In-Reply-To: <64FC98B6-EC77-11D6-A53C-00039357A82A@extremenetworks.com> from RJ Atkinson at "Oct 30, 2002 09:20:59 pm" To: RJ Atkinson Date: Thu, 31 Oct 2002 12:04:26 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-2.8 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Ran; > > The problem is that the draft already contains mutually > > exclusive requirements. > > It would be helpful if you would list any that you find > so any that exist can be resolved. Details help. Search ML log. Masataka Ohta From owner-multi6@ops.ietf.org Thu Oct 31 00:52:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27933 for ; Thu, 31 Oct 2002 00:52:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1878Gq-0005Do-00 for multi6-data@psg.com; Wed, 30 Oct 2002 21:53:32 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1878Gl-0005Cu-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 21:53:28 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g9V5r2041098; Thu, 31 Oct 2002 06:53:02 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 31 Oct 2002 06:53:01 +0100 (CET) From: Iljitsch van Beijnum To: Tony Li cc: Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: Message-ID: <20021031064405.L39291-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 30 Oct 2002, Tony Li wrote: > | I don't mean that these people shouldn't have backups. What > | I mean is that injecting a globally visible route into the > | infrastructure 100% of > | the time to avoid sub-optimal, but otherwise functional > | routing 1% of the time isn't a good use of scarce resources. > We might well be in violent agreement. Hey, violence never solves anything. > Are you suggesting that we disallow the globally visible route? In short: yes, that is what my provider-internal aggregation draft suggests. However, since aggregation happens within individual ISP networks they all get to choose whether they want to aggregate or not. This uses regular BGP. A longer-term solution may be able to improve on this, although I doubt having a few hundred million globally visible routes will work well even with much smarter protocols. > Or that we disallow them from making multiple connections? No, that way it would be hard to multihome... But in essence I'm saying that if they have multiple connections in far apart locations they can only use the connection in location B to back up location A and vice versa, and not load balance incoming traffic to A over both A and B. For that, they'll have to have two connections close to location A and two connections close to location B. From owner-multi6@ops.ietf.org Thu Oct 31 02:49:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09725 for ; Thu, 31 Oct 2002 02:49:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187A62-000COO-00 for multi6-data@psg.com; Wed, 30 Oct 2002 23:50:30 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 187A61-000CKA-00 for multi6@ops.ietf.org; Wed, 30 Oct 2002 23:50:29 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 07DF134431; Wed, 30 Oct 2002 23:58:57 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9V7nviI023688; Wed, 30 Oct 2002 23:49:57 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Wed, 30 Oct 2002 23:49:57 -0800 Message-ID: Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcKAodf7jINQtkHGR3i7ZPAs1/T3RwAEAwjw From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA09725 | > Are you suggesting that we disallow the globally visible route? | | In short: yes, that is what my provider-internal aggregation draft | suggests. However, since aggregation happens within individual ISP | networks they all get to choose whether they want to | aggregate or not. | This uses regular BGP. A longer-term solution may be able | to improve on | this, although I doubt having a few hundred million globally visible | routes will work well even with much smarter protocols. Excellent, thank you this is the first step towards scalability. Now we only differ on the mechanisms. Tony From owner-multi6@ops.ietf.org Thu Oct 31 03:05:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09988 for ; Thu, 31 Oct 2002 03:05:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187AMl-000DZl-00 for multi6-data@psg.com; Thu, 31 Oct 2002 00:07:47 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 187AMj-000DXL-00 for multi6@ops.ietf.org; Thu, 31 Oct 2002 00:07:45 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id CCE0E3442A; Thu, 31 Oct 2002 00:16:10 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9V87CiI024555; Thu, 31 Oct 2002 00:07:12 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Thu, 31 Oct 2002 00:07:12 -0800 Message-ID: Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcKAV4q7y7IimvAdQey8z1UpF3iyxAAWs5xg From: "Tony Li" To: , X-Spam-Status: No, hits=0.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA09988 | Tony Li wrote: | > ... | > Exactly. What we want to build is a routing architecture that is | > never going to have to be replaced. It's too difficult to | > reach in and change it, so you'd like it to be done right the | > first time. | | Unfortunately 'never' is a very long time, and we will | continue to do | nothing while we wait for the answer. Tony, No one is proposing that we wait for the perfect answer. The only question is how long it will be before we can reach consensus. We need to decide which is more important: the scalability and durability of the routing subsystem or the convenience of non-connection based addressing. When we have consensus on this point, then all else will follow. | > Since scalability is key and the way to scale is | > to keep the overhead low, a solution that has higher overhead | > is sub-optimal and to be avoided. | > | > Geographic aggregation is fine if the topology does indeed | > provide a convenient aggregation boundary. But in many | > cases, there will be no | > such convenient boundary. What do you do? You cannot make | > an exception and flat route any enterprise that has such | > links, because then their overhead dominates the cost of all | > routing and you're not sufficiently scalable. | | This point is arguable, because it is making a blanket | statement about a | process with multiple causes. For the truly global enterprise with | multiple exposure points and global internal network that | could handle a | route shift, why not? There are fewer than 11,000 toady as | evidenced by | the number of AS's injecting prefixes into BGP. (I suspect the real | number is less than 2,000 that could deal with taking a full traffic | load at multiple points) The real problem is that there is | no clear way | to say one organization can while another can't. For the | case where an | enterprise is simply looking for better/cheaper service in a remote | region, we are into economic rather than technical arguments. These | organizations aren't concerned about their impact on routing, so the | only way to deal with them is to give them the level of service they | need while making it cheaper to constrain the topology than it is to | blow out the tables. The fact that there are already 11,000 today should concern us greatly. If the rate of such sites continues to grow proportionally to the size of the network, we'd be looking at unsustainable exponential growth in the DFZ. If it helps, you might recall that the DFZ about 10 years ago was only about 5K routes. Multiplying by 20X has been painful. For organizations that are looking for better/cheaper or (more likely) diverse service, I think that you'll agree that we do want to find a way to provide them service. If we simply try to constrain the topology, then we will simply be ignored. People will use the technology in the way that is to their benefit, not necessarily to the benefit of the whole. Game theory 101. What we must do is to give them a technological mechanism that provides their needs, meets their cost goals and simultaneously allows us to have a lasting routing architecture. I believe that we have that option staring us in the face in the form of GSE (possibly with some tweaks), but we need to get past our ideological differences and move forward to a true engineering solution. Will you help? Tony From owner-multi6@ops.ietf.org Thu Oct 31 03:08:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10022 for ; Thu, 31 Oct 2002 03:08:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187APL-000DhO-00 for multi6-data@psg.com; Thu, 31 Oct 2002 00:10:27 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 187APK-000DfG-00 for multi6@ops.ietf.org; Thu, 31 Oct 2002 00:10:26 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id A637F23C3A; Wed, 30 Oct 2002 03:16:35 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g9V89tiI024635; Thu, 31 Oct 2002 00:09:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Thu, 31 Oct 2002 00:09:54 -0800 Message-ID: Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcKAC6Xlc7ypi65hSzW+Y1DX7y262AAqQVZg From: "Tony Li" To: "Iljitsch van Beijnum" Cc: "J. Noel Chiappa" , X-Spam-Status: No, hits=0.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA10022 | > But in many cases, there will be no | > such convenient boundary. What do you do? You cannot | make an exception | > and flat route any enterprise that has such links, | because then their | > overhead dominates the cost of all routing and you're not | sufficiently | > scalable. | | If we require a solution (even a short-term one) to address | this fully, | then yes, this is a problem. However, I think we can leave | this problem | unsolved for now as there doesn't seem to be a good reason for an | organization to do this other than cost saving and we're not in the | business of making the internet a more expensive place for all to | accomodate savings for some. News flash: we left this problem unsolved when we did CIDR for IPv4. It's now an issue. It needs to be addressed if IPv6 is to succceed. Tony From owner-multi6@ops.ietf.org Thu Oct 31 19:59:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22207 for ; Thu, 31 Oct 2002 19:59:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187QAM-000Mfe-00 for multi6-data@psg.com; Thu, 31 Oct 2002 17:00:02 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 187QAI-000MfK-00 for multi6@ops.ietf.org; Thu, 31 Oct 2002 16:59:58 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 17:00:02 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Thu, 31 Oct 2002 16:59:52 -0800 Message-ID: <013b01c28141$fe3838f0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-4.8 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA22207 Tony Li wrote: > ... > We need to decide which is more important: the scalability > and durability > of the routing subsystem or the convenience of non-connection based > addressing. When we have consensus on this point, then all else will > follow. > The answer to the question depends on which side of the table you are sitting on. > ... > The fact that there are already 11,000 today should concern > us greatly. > If the rate of such sites continues to grow proportionally to the size > of the network, we'd be looking at unsustainable exponential growth in > the DFZ. If it helps, you might recall that the DFZ about 10 > years ago > was only about 5K routes. Multiplying by 20X has been painful. Yes, but much of that is self inflicted for TE. Of the ~11,000, ~7,000 inject a single prefix, while the next ~3,000 inject 2-4. In other words, 4/5 of the growth can be directly traced to 1/10 of the participants. > > For organizations that are looking for better/cheaper or (more likely) > diverse service, I think that you'll agree that we do want to find > a way to provide them service. If we simply try to constrain the > topology, then we will simply be ignored. People will use > the technology > in the way that is to their benefit, not necessarily to the benefit of > the whole. Game theory 101. > > What we must do is to give them a technological mechanism > that provides > their needs, meets their cost goals and simultaneously allows > us to have > a lasting routing architecture. I believe that we have that option > staring us in the face in the form of GSE (possibly with some > tweaks), but > we need to get past our ideological differences and move > forward to a true > engineering solution. > > Will you help? I have not been opposed to GSE, but I think the time has passed for it to be adopted without coupling it with something like MIPv6 to provide a stable identifier to the psuedo-header calculation and multi-party apps that insist on refering addresses rather than name strings. We also need PI address space for edge network operators that are looking for something that can be configured into local policy databases and be imune to changes in provider. It has been quite awhile since I looked at the details of GSE, but if we can find a way to map a PI based HA through the GSE context of the base header, I would be glad to help. Tony > > Tony >