From owner-multi6@ops.ietf.org Thu Aug 2 22:13:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10569 for ; Thu, 2 Aug 2001 22:13:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SUQC-0004Fy-00 for multi6-data@psg.com; Thu, 02 Aug 2001 19:10:40 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.31 #1) id 15SUQB-0004Fr-00 for multi6@ops.ietf.org; Thu, 02 Aug 2001 19:10:39 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 9B34A4B21; Fri, 3 Aug 2001 11:10:35 +0900 (JST) To: "Craig A. Huegen" Cc: Pekka Savola , Thomas Narten , multi6@ops.ietf.org, Sean Doran In-reply-to: chuegen's message of Mon, 30 Jul 2001 08:57:33 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Pseudo "last call" for draft-ietf-ipngwg-ipv6-2260-02.txt From: itojun@iijlab.net Date: Fri, 03 Aug 2001 11:10:35 +0900 Message-ID: <23425.996804635@itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk >>From an enterprise end-user point of view, this approach adds more >confusion to a solution that already has major concerns. The number 1 >concern that we have to deal with in this multihoming scheme is the path >selection by the originating TCP stack through its selection of source and >destination addresses. draft-ietf-ipngwg-ipv6-2260 does not add more confusion, but protects you from unreachability of certain prefix in multiple-prefix-assigned- to-site style of multihoming. without draft-ietf-ipngwg-ipv6-2260, source address selection problem is a critical task since if you pick P::a (from P::a and Q::b) while P::/48 is unreachable, you are dead. with draft-ietf-ipngwg-ipv6-2260, you can pick either P::a or Q::b, regardless from the external link status (tunnels will always ensure that P::/48 and Q::/48 are reachable, assuming that the upstream ISP is reachable). itojun From owner-multi6@ops.ietf.org Fri Aug 3 09:37:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15783 for ; Fri, 3 Aug 2001 09:37:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Sf82-0003cZ-00 for multi6-data@psg.com; Fri, 03 Aug 2001 06:36:38 -0700 Received: from hare.ics.keio.ac.jp ([131.113.126.200] helo=tera.ics.keio.ac.jp) by psg.com with smtp (Exim 3.31 #1) id 15Sf81-0003Xt-00 for multi6@ops.ietf.org; Fri, 03 Aug 2001 06:36:37 -0700 Received: (qmail 30281 invoked from network); 3 Aug 2001 13:26:57 -0000 Received: from pdf7d0d.kngwnt01.ap.so-net.ne.jp (HELO AQUILA.csl.sony.co.jp) (202.223.125.13) by hare.ics.keio.ac.jp with SMTP; 3 Aug 2001 13:26:57 -0000 Message-Id: <4.3.2-J.20010803222513.029d2088@aphelion.csl.sony.co.jp> X-Sender: tera@aphelion.csl.sony.co.jp X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Fri, 03 Aug 2001 22:27:02 +0900 To: multi6@ops.ietf.org From: Fumio Teraoka Subject: Re: Multi6 London Agenda In-Reply-To: <200107311607.MAA11925@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 01/07/31 12:07 -0400, Thomas Narten wrote: >Fumio Teraoka (5 min) > draft-teraoka-ipng-lin6-01.txt The title of our talk is "LIN6: A Solution to Multi-Homing and Mobility in IPv6." The i-d is available at http://www.lin6.net/draft-teraoka-ipng-lin6-01.txt (We missed the i-d deadline for a few hours..) Fumio Teraoka From owner-multi6@ops.ietf.org Fri Aug 3 20:15:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01465 for ; Fri, 3 Aug 2001 20:15:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Sp6B-000PEc-00 for multi6-data@psg.com; Fri, 03 Aug 2001 17:15:23 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15Sp6A-000PEV-00 for multi6@ops.ietf.org; Fri, 03 Aug 2001 17:15:22 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id KAA21740 for ; Sat, 4 Aug 2001 10:15:20 +1000 (EST) Date: Sat, 4 Aug 2001 10:15:20 +1000 (EST) From: Peter Tattam To: multi6@ops.ietf.org Subject: intro Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi all, Some of you know me, some maybe not. I'd like to get up to speed with multi6 and perhaps get involved in the debate. Could someone send me a brief summary of the current work to date. I have read draft-ietf-multi6-multihoming-requirements-01 and draft-ietf-multi6-v4-multihoming-00 What else should I read? 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 Fri Aug 3 21:41:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03136 for ; Fri, 3 Aug 2001 21:41:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SqRd-0001jl-00 for multi6-data@psg.com; Fri, 03 Aug 2001 18:41:37 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15SqRc-0001cM-00 for multi6@ops.ietf.org; Fri, 03 Aug 2001 18:41:36 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id LAA04733 for ; Sat, 4 Aug 2001 11:33:40 +1000 (EST) Date: Sat, 4 Aug 2001 11:33:40 +1000 (EST) From: Peter Tattam To: Multi6 Working Group Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk It has been on my mind for some time to elevate this proposal (and the subsequent discussions in Tokyo) to I-D level, but getting it to the right printing format is beyond me. Can someone point me to some tools that might help me translate this into IETF acceptable format? My apologies for not getting to it sooner. I have had an incredibily full schedule with the release of our new operating system over the past year or so. My analysis of multihoming and the widespread criticism of Ipv6 "outside the Ipv6 fold", indicated that host-based multihoming was probably the only thing that was going to fly. I put the idea together after much discussion on the ipng mailing list. The preconditions were that strong aggregation and multi numbering were an inherent part of the multihoming brief for Ipv6, and that it was not possible to change the rules to suit my needs (e.g. GSE). Also part of my brief was to consider that the routing infrastructure was made up of a number of entities in a mutal love/hate relationship implying that they would be unwilling to do much more than forward packets to each other (ruling out any kind of friendly tunneling proposals). If there is sufficient interest, I believe the proposal (at the suggestion of Steve durin the Tokyo meeting) can be extended outside the initial TCP scope for which it was intended. I have since determined the fundamental principles of the proposal so that they can be applied to a more general proposal. Peter On Wed, 4 Apr 2001, Steve Deering wrote: > If this group is to pursue host-based or transport-layer multihoming, > you might want to look at some of the material presented at the Tokyo > interim meeting of the IPng working group in Sept/Oct 1999, fetchable > from . For example, > my "Overview of IP(v6) Multihoming Issues" is one attempt to > characterize the problem space and list a range of (increasingly > ambitious) goals one could set for host-based multihoming, and the > presentation from Peter Tattam entitled "Preserving Active TCP > Sessions" was one stab at enhancing TCP for multihoming. > > Steve > > -- 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 Aug 4 03:10:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23043 for ; Sat, 4 Aug 2001 03:10:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SvZ3-000Adr-00 for multi6-data@psg.com; Sat, 04 Aug 2001 00:09:37 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.31 #1) id 15SvZ2-000Adj-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 00:09:36 -0700 From: Masataka Ohta Message-Id: <200108040702.QAA02064@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA02064; Sat, 4 Aug 2001 16:02:11 +0900 Subject: Re: Transport level multihoming In-Reply-To: from Peter Tattam at "Aug 4, 2001 11:33:40 am" To: Peter Tattam Date: Sat, 4 Aug 2001 16:02:10 +0859 () CC: Multi6 Working Group X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Peter; > It has been on my mind for some time to elevate this proposal (and the > subsequent discussions in Tokyo) to I-D level, That is not a useful thing to do. Transport layer is not the last layer to solve the problem. > If there is sufficient interest, I believe the proposal (at the suggestion of > Steve durin the Tokyo meeting) can be extended outside the initial TCP scope > for which it was intended. I have since determined the fundamental principles > of the proposal so that they can be applied to a more general proposal. > I have read > > draft-ietf-multi6-multihoming-requirements-01 > and > draft-ietf-multi6-v4-multihoming-00 > > What else should I read? draft-ohta-e2e-multihoming-01.txt Masataka Ohta From owner-multi6@ops.ietf.org Sat Aug 4 03:26:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23225 for ; Sat, 4 Aug 2001 03:26:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SvqG-000B8j-00 for multi6-data@psg.com; Sat, 04 Aug 2001 00:27:24 -0700 Received: from soggy131.drizzle.com ([216.162.199.131] helo=tristero.cryptocourier.com) by psg.com with smtp (Exim 3.31 #1) id 15SvqF-000B8d-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 00:27:23 -0700 Received: (qmail 20032 invoked from network); 4 Aug 2001 07:36:35 -0000 Received: from unknown (HELO ae) (192.168.70.50) by 192.168.70.2 with SMTP; 4 Aug 2001 07:36:35 -0000 From: "Ben Black" To: "Masataka Ohta" , "Peter Tattam" Cc: "Multi6 Working Group" Subject: RE: Transport level multihoming Date: Sat, 4 Aug 2001 00:27:20 -0700 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.2911.0) In-Reply-To: <200108040702.QAA02064@necom830.hpcl.titech.ac.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> It has been on my mind for some time to elevate this proposal (and the >> subsequent discussions in Tokyo) to I-D level, > >That is not a useful thing to do. Peter, The working group would welcome your contributions. Ben From owner-multi6@ops.ietf.org Sat Aug 4 03:42:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23344 for ; Sat, 4 Aug 2001 03:42:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Sw5v-000CDg-00 for multi6-data@psg.com; Sat, 04 Aug 2001 00:43:35 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15Sw5u-000CDS-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 00:43:34 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id RAA09510; Sat, 4 Aug 2001 17:43:23 +1000 (EST) Date: Sat, 4 Aug 2001 17:43:22 +1000 (EST) From: Peter Tattam To: Ben Black cc: Masataka Ohta , Multi6 Working Group Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk ok. I'm getting a mixed signal here. I've reformatted my draft to be IETF compatible and added some more recent thoughts and discussion of implications. Until I get it published via the I-D editor, here's a URL to it. http://jazz-1.trumpet.com.au/ipv6-draft/preserve-tcp.txt Peter On Sat, 4 Aug 2001, Ben Black wrote: > >> It has been on my mind for some time to elevate this proposal (and the > >> subsequent discussions in Tokyo) to I-D level, > > > >That is not a useful thing to do. > > Peter, > > The working group would welcome your contributions. > > > Ben > > > -- 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 Aug 4 04:14:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23605 for ; Sat, 4 Aug 2001 04:14:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Swap-000D9N-00 for multi6-data@psg.com; Sat, 04 Aug 2001 01:15:31 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Swap-000D9G-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 01:15:31 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id DAA95589; Sat, 4 Aug 2001 03:15:18 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Sat, 4 Aug 2001 03:15:18 -0500 (CDT) From: "Jon (Taz) Mischo" To: Peter Tattam cc: Ben Black , Masataka Ohta , Multi6 Working Group Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Ignore the mixed signals, Peter. We are always open to at least hearing new ideas. While some parties may or may not agree with your standpoint, the IETF's motto is rough consensus and running code. Our many viewpoints are our strength. -Jon On Sat, 4 Aug 2001, Peter Tattam wrote: > Date: Sat, 4 Aug 2001 17:43:22 +1000 (EST) > From: Peter Tattam > To: Ben Black > Cc: Masataka Ohta , > Multi6 Working Group > Subject: RE: Transport level multihoming > > ok. I'm getting a mixed signal here. > > I've reformatted my draft to be IETF compatible and added some more recent > thoughts and discussion of implications. > > Until I get it published via the I-D editor, here's a URL to it. > > http://jazz-1.trumpet.com.au/ipv6-draft/preserve-tcp.txt > > Peter > > On Sat, 4 Aug 2001, Ben Black wrote: > > > >> It has been on my mind for some time to elevate this proposal (and the > > >> subsequent discussions in Tokyo) to I-D level, > > > > > >That is not a useful thing to do. > > > > Peter, > > > > The working group would welcome your contributions. > > > > > > Ben > > > > > > > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Sat Aug 4 04:39:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23796 for ; Sat, 4 Aug 2001 04:39:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Swyr-000Dye-00 for multi6-data@psg.com; Sat, 04 Aug 2001 01:40:21 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.31 #1) id 15Swyq-000DyX-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 01:40:20 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id E3D8B86D; Sat, 4 Aug 2001 10:40:17 +0200 (CEST) To: ben@layer8.net, peter@jazz-1.trumpet.com.au Subject: RE: Transport level multihoming Cc: mohta@necom830.hpcl.titech.ac.jp, multi6@ops.ietf.org Message-Id: <20010804084017.E3D8B86D@sean.ebone.net> Date: Sat, 4 Aug 2001 10:40:17 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Yes, we welcome proposals and drafts, but the present focus is on bringing to last call (i.e., please shout now) two main documents: #1 - how multihoming is done today in the Internet #2 - requirements for multihoming in an IPv6 Internet (which probably should say "AT LEAST #1 and some more things") After those two are agreed to, we can start examining individual proposals against #2. Until then, while the specific proposals for protocols are an interesting way of converging on a reasonable architecture in which to develop various specific protocols, the freight train is a little before the foal... So, while it's good to see interesting ideas from a number of authors being put forward as drafts, I'd like to suggest that the authors take a close look at the various present inputs to numbers one and two above. Since it's hard to forsee us recommending a standard which does not fully meet the requirements document, everyone should be asking: is what is developing now too strict, too loose? Are there pieces missing? Are there pieces that should be missing? Are we so on the wrong track that you are motivated to write a counter-proposal to numbers one or two above? And so on. Yours in wondrous TechniProcess, Sean. From owner-multi6@ops.ietf.org Sat Aug 4 04:48:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23886 for ; Sat, 4 Aug 2001 04:48:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Sx6V-000EFR-00 for multi6-data@psg.com; Sat, 04 Aug 2001 01:48:15 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Sx6U-000EFL-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 01:48:14 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id DAA97768 for ; Sat, 4 Aug 2001 03:48:12 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Sat, 4 Aug 2001 03:48:12 -0500 (CDT) From: "Jon (Taz) Mischo" To: multi6@ops.ietf.org Subject: RE: Transport level multihoming (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Please ignore the mixed signals, Peter. We are always open to at least hearing new ideas. While some parties may or may not agree with your standpoint, the IETF's motto is rough consensus and running code. Our many viewpoints are our strength. -Jon On Sat, 4 Aug 2001, Peter Tattam wrote: > Date: Sat, 4 Aug 2001 17:43:22 +1000 (EST) > From: Peter Tattam > To: Ben Black > Cc: Masataka Ohta , > Multi6 Working Group > Subject: RE: Transport level multihoming > > ok. I'm getting a mixed signal here. > > I've reformatted my draft to be IETF compatible and added some more recent > thoughts and discussion of implications. > > Until I get it published via the I-D editor, here's a URL to it. > > http://jazz-1.trumpet.com.au/ipv6-draft/preserve-tcp.txt > > Peter > > On Sat, 4 Aug 2001, Ben Black wrote: > > > >> It has been on my mind for some time to elevate this proposal (and the > > >> subsequent discussions in Tokyo) to I-D level, > > > > > >That is not a useful thing to do. > > > > Peter, > > > > The working group would welcome your contributions. > > > > > > Ben > > > > > > > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Sat Aug 4 04:51:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23918 for ; Sat, 4 Aug 2001 04:51:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SxA1-000ENn-00 for multi6-data@psg.com; Sat, 04 Aug 2001 01:51:53 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.31 #1) id 15SxA0-000ENf-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 01:51:52 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f748pfi17710; Sat, 4 Aug 2001 11:51:41 +0300 Date: Sat, 4 Aug 2001 11:51:41 +0300 (EEST) From: Pekka Savola To: Masataka Ohta cc: Subject: Re: WG Docs & Call for Agenda Items In-Reply-To: <200107291132.UAA07933@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 29 Jul 2001, Masataka Ohta wrote: > Thomas and Sean; > > > Multi6 has been assigned a 1-hour slot in London, tentatively > > scheduled for the first Tuesday afternoon slot. If you wish to have > > some agenda time, please let Sean and I know. > > I wish to have some agenda time for discussions on: > > draft-ohta-e2e-multihoming-02.txt > > The Architecture of End to End Multihoming Is this really a multi6 issue? I don't feel multi6 is the right place to suggest that establishing a TCP connection should not work unless reverse DNS queries are working (among other things..). My imagination is a little limited wrt. which would be a better place, though. -- 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 Sat Aug 4 04:51:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23929 for ; Sat, 4 Aug 2001 04:51:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SxAH-000EP3-00 for multi6-data@psg.com; Sat, 04 Aug 2001 01:52:09 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15SxAG-000EOv-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 01:52:09 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id DAA97777; Sat, 4 Aug 2001 03:51:58 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Sat, 4 Aug 2001 03:51:58 -0500 (CDT) From: "Jon (Taz) Mischo" To: Peter Tattam cc: Ben Black , Masataka Ohta , Multi6 Working Group Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Well, okay...Sean hath laid the smack down :) So listen to him :) Just ignore the man behind the curtain. -Jon On Sat, 4 Aug 2001, Jon (Taz) Mischo wrote: > Date: Sat, 4 Aug 2001 03:15:18 -0500 (CDT) > From: "Jon (Taz) Mischo" > To: Peter Tattam > Cc: Ben Black , > Masataka Ohta , > Multi6 Working Group > Subject: RE: Transport level multihoming > > Ignore the mixed signals, Peter. We are always open to at least hearing > new ideas. While some parties may or may not agree with your standpoint, > the IETF's motto is rough consensus and running code. Our many viewpoints > are our strength. > > -Jon > > On Sat, 4 Aug 2001, Peter Tattam wrote: > > > Date: Sat, 4 Aug 2001 17:43:22 +1000 (EST) > > From: Peter Tattam > > To: Ben Black > > Cc: Masataka Ohta , > > Multi6 Working Group > > Subject: RE: Transport level multihoming > > > > ok. I'm getting a mixed signal here. > > > > I've reformatted my draft to be IETF compatible and added some more recent > > thoughts and discussion of implications. > > > > Until I get it published via the I-D editor, here's a URL to it. > > > > http://jazz-1.trumpet.com.au/ipv6-draft/preserve-tcp.txt > > > > Peter > > > > On Sat, 4 Aug 2001, Ben Black wrote: > > > > > >> It has been on my mind for some time to elevate this proposal (and the > > > >> subsequent discussions in Tokyo) to I-D level, > > > > > > > >That is not a useful thing to do. > > > > > > Peter, > > > > > > The working group would welcome your contributions. > > > > > > > > > Ben > > > > > > > > > > > > > -- > > Peter R. Tattam peter@trumpet.com > > Managing Director, Trumpet Software International Pty Ltd > > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > > > > > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Sat Aug 4 04:53:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23946 for ; Sat, 4 Aug 2001 04:53:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SxCf-000EUl-00 for multi6-data@psg.com; Sat, 04 Aug 2001 01:54:37 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15SxCd-000EUf-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 01:54:36 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id SAA21055; Sat, 4 Aug 2001 18:54:19 +1000 (EST) Date: Sat, 4 Aug 2001 18:54:19 +1000 (EST) From: Peter Tattam To: Sean Doran cc: ben@layer8.net, mohta@necom830.hpcl.titech.ac.jp, multi6@ops.ietf.org Subject: RE: Transport level multihoming In-Reply-To: <20010804084017.E3D8B86D@sean.ebone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 4 Aug 2001, Sean Doran wrote: > Yes, we welcome proposals and drafts, but the present focus > is on bringing to last call (i.e., please shout now) two > main documents: > > #1 - how multihoming is done today in the Internet > #2 - requirements for multihoming in an IPv6 Internet > (which probably should say "AT LEAST #1 and some more things") I pretty much agree with the two I-D's being presented at the IETF meeting which I believe cover these two points. > > After those two are agreed to, we can start examining individual > proposals against #2. Until then, while the specific proposals > for protocols are an interesting way of converging on a reasonable > architecture in which to develop various specific protocols, > the freight train is a little before the foal... > > So, while it's good to see interesting ideas from a number > of authors being put forward as drafts, I'd like to suggest > that the authors take a close look at the various present inputs > to numbers one and two above. > > Since it's hard to forsee us recommending a standard which > does not fully meet the requirements document, everyone > should be asking: is what is developing now too strict, too loose? > Are there pieces missing? Are there pieces that should be missing? > Are we so on the wrong track that you are motivated to write a > counter-proposal to numbers one or two above? And so on. My apologies. I was picking up from where I was involved in IPng discussions a couple of years back and was present at the interim meeting in Tokyo. It had gotten quite involved then and I presumed things were more advanced since then. > > Yours in wondrous TechniProcess, > > Sean. > Can I gently say that IPv6 is getting beaten up quite a bit by the technical community, and it all centres on the issue of multihoming and strong aggregation. It's stalling deployment by major infrastructure, and a lot of people are not buying the line that "we'll fix that bit later". I'm a strong supporter of IPv6 but its very difficult to defend IPv6 on this particular issue when I can't point to specific ways of how IPv6 solves the multhoming issue. I will suitably back off - I'd forgotten how carefully one needs to tread in the working group environment. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Sat Aug 4 05:05:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24039 for ; Sat, 4 Aug 2001 05:05:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SxNo-000Es1-00 for multi6-data@psg.com; Sat, 04 Aug 2001 02:06:08 -0700 Received: from [217.33.136.18] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15SxNn-000Eru-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 02:06:07 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15SxNj-0001ku-00; Sat, 04 Aug 2001 10:06:03 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: smd@ebone.net (Sean Doran) Cc: multi6@ops.ietf.org Subject: RE: Transport level multihoming References: <20010804084017.E3D8B86D@sean.ebone.net> Message-Id: Date: Sat, 04 Aug 2001 10:06:03 +0100 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > #1 - how multihoming is done today in the Internet > #2 - requirements for multihoming in an IPv6 Internet > (which probably should say "AT LEAST #1 and some more things") just to make trouble, and not because i have a position on the question, is the parenthetical above *really* a desirable/necessary condition? i.e. if, by magic, we come up with a really sexy v6 solution, must it also support current v4-style multihoming. randy From owner-multi6@ops.ietf.org Sat Aug 4 05:07:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24066 for ; Sat, 4 Aug 2001 05:07:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SxQ1-000EvC-00 for multi6-data@psg.com; Sat, 04 Aug 2001 02:08:25 -0700 Received: from flowpoint.procket.com ([209.140.237.1] helo=alpha-tli.procket.com) by psg.com with esmtp (Exim 3.31 #1) id 15SxQ0-000Ev6-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 02:08:24 -0700 Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id CAA10344; Sat, 4 Aug 2001 02:07:40 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15211.47964.547431.337850@alpha-tli.procket.com> Date: Sat, 4 Aug 2001 02:07:40 -0700 To: Peter Tattam Cc: Sean Doran , ben@layer8.net, mohta@necom830.hpcl.titech.ac.jp, multi6@ops.ietf.org Subject: RE: Transport level multihoming In-Reply-To: References: <20010804084017.E3D8B86D@sean.ebone.net> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | It's stalling deployment by major infrastructure, and a lot of | people are not buying the line that "we'll fix that bit later". Peter, I hope you understand the rationale behind this. Without a scalable routing architecture that supports multihoming, it would be foolish to do massive address assignments. Been there, done that, got the IPv4 swamp to show for it. Regards, Tony From owner-multi6@ops.ietf.org Sat Aug 4 05:18:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24223 for ; Sat, 4 Aug 2001 05:18:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Sxad-000FG6-00 for multi6-data@psg.com; Sat, 04 Aug 2001 02:19:23 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.31 #1) id 15Sxac-000FFz-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 02:19:22 -0700 From: Masataka Ohta Message-Id: <200108040903.SAA03332@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA03332; Sat, 4 Aug 2001 18:03:27 +0900 Subject: Re: WG Docs & Call for Agenda Items In-Reply-To: from Pekka Savola at "Aug 4, 2001 11:51:41 am" To: Pekka Savola Date: Sat, 4 Aug 2001 18:03:26 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > > I wish to have some agenda time for discussions on: > > > > draft-ohta-e2e-multihoming-02.txt > > > > The Architecture of End to End Multihoming > > Is this really a multi6 issue? I don't feel multi6 is the right place to > suggest that establishing a TCP connection should not work unless reverse > DNS queries are working (among other things..). The draft never suggests such a thing at all. TCP works with multiple addresses or, less robustly, a single address. > My imagination is a little limited wrt. which would be a better place, though. You have successfully demonstrated unlimited power of your imagination. Masataka Ohta From owner-multi6@ops.ietf.org Sat Aug 4 05:29:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24337 for ; Sat, 4 Aug 2001 05:29:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SxlB-000FYn-00 for multi6-data@psg.com; Sat, 04 Aug 2001 02:30:17 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15Sxl9-000FYh-00; Sat, 04 Aug 2001 02:30:16 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id TAA27046; Sat, 4 Aug 2001 19:30:13 +1000 (EST) Date: Sat, 4 Aug 2001 19:30:12 +1000 (EST) From: Peter Tattam To: Randy Bush cc: Sean Doran , multi6@ops.ietf.org Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 4 Aug 2001, Randy Bush wrote: > > #1 - how multihoming is done today in the Internet > > #2 - requirements for multihoming in an IPv6 Internet > > (which probably should say "AT LEAST #1 and some more things") > > just to make trouble, and not because i have a position on the question, is > the parenthetical above *really* a desirable/necessary condition? i.e. if, > by magic, we come up with a really sexy v6 solution, must it also support > current v4-style multihoming. Sorry, I missed something very important there. Is it planned to support multihoming exactly as Ipv4 does now? The policy a couple of years back was very firm. IPv6 = Strong aggregation, small DFZ. Current v4 style multihoming can't fit that requirement. Trying to shoehorn Ipv4 BGP practices into Ipv6 has very serious problems for scalability and long term stability of the core. Has there been a backdown or crucial change in policy that I have somehow missed because I had my head down on other work? > > randy > > 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 Aug 4 05:38:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24391 for ; Sat, 4 Aug 2001 05:38:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Sxte-000FpG-00 for multi6-data@psg.com; Sat, 04 Aug 2001 02:39:02 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15Sxtd-000FpA-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 02:39:01 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id TAA26139; Sat, 4 Aug 2001 19:22:24 +1000 (EST) Date: Sat, 4 Aug 2001 19:22:24 +1000 (EST) From: Peter Tattam To: Tony Li cc: Sean Doran , ben@layer8.net, mohta@necom830.hpcl.titech.ac.jp, multi6@ops.ietf.org Subject: RE: Transport level multihoming In-Reply-To: <15211.47964.547431.337850@alpha-tli.procket.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 4 Aug 2001, Tony Li wrote: > > | It's stalling deployment by major infrastructure, and a lot of > | people are not buying the line that "we'll fix that bit later". > > > Peter, > > I hope you understand the rationale behind this. Without a scalable > routing architecture that supports multihoming, it would be foolish to do > massive address assignments. Been there, done that, got the IPv4 swamp to > show for it. I do understand and it demonstrates the clear lack of confidence by the IPv6 community that the protocol will deliver what it promises. That's all very well, but unfortunately the techies are digging their heels in and implementing NAT based solutions to make things continue (sort of). What you are saying could (and sometimes is) being interpreted as "well, we've got Ipv6 to solve all your address space problems, but we haven't figured out how to properly route it yet. Come back in (X) months/years when we've figured it out and then we'll tell you how to deploy it.". > > Regards, > Tony > I challenge any of you to get on slashdot and successfully defend IPv6 against its opponents - especially the issue of strong aggregation, core router bloat and multi homing. Sorry to be off topic, but I'm trying to express the sense urgency to see a solution and frustration of what's happeing in the real world. Now I'll get off my soapbox. :) Regards. 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 Aug 4 05:39:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24404 for ; Sat, 4 Aug 2001 05:38:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SxuX-000FrR-00 for multi6-data@psg.com; Sat, 04 Aug 2001 02:39:57 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.31 #1) id 15SxuW-000FrK-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 02:39:56 -0700 From: Masataka Ohta Message-Id: <200108040931.SAA03481@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA03481; Sat, 4 Aug 2001 18:31:08 +0900 Subject: Re: Transport level multihoming In-Reply-To: from Peter Tattam at "Aug 4, 2001 07:22:24 pm" To: Peter Tattam Date: Sat, 4 Aug 2001 18:31:07 +0859 () CC: Tony Li , Sean Doran , ben@layer8.net, multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Peter; > What you are saying could (and sometimes is) being interpreted as "well, we've > got Ipv6 to solve all your address space problems, but we haven't figured out > how to properly route it yet. Come back in (X) months/years when we've figured > it out and then we'll tell you how to deploy it.". Months? According to the chairs, we shouldn't figure out how to properly route it yet, until we finish our requirement draft. While 3 multi6 meeting are being spent on it, discussions on specific proposals are discouraged to make the requirement draft abstract and separated from the real world. But, it is still an improvement as 5 years are wasted waiting IPv6 deployed, insisting on keeping the specification as is (changes will delay deployment of the perfect specification) and ignoring real world requirements for changes. Masataka Ohta From owner-multi6@ops.ietf.org Sat Aug 4 06:00:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24550 for ; Sat, 4 Aug 2001 06:00:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SyEh-000GSd-00 for multi6-data@psg.com; Sat, 04 Aug 2001 03:00:47 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.31 #1) id 15SyEg-000GSX-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 03:00:47 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 6DAC286D; Sat, 4 Aug 2001 12:00:45 +0200 (CEST) To: mohta@necom830.hpcl.titech.ac.jp, peter@jazz-1.trumpet.com.au Subject: Re: Transport level multihoming Cc: ben@layer8.net, multi6@ops.ietf.org, smd@ebone.net, tli@Procket.com Message-Id: <20010804100045.6DAC286D@sean.ebone.net> Date: Sat, 4 Aug 2001 12:00:45 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk I think that if a draft comes forward which is explicit in how it meets the present requirements work, or is explicit in WHY it obviates the present requirements work (a la Randy's question), that not even I am too stubborn to insist that we ignore it. Put another way - the obvious next step after we have the reqs out the door is to do a detailed comparison of the various individual proposals that are on the table now (and the ones that aren't yet), and try to come up with a rough consensus on which one(s) we propose. It's rather hard to validate one's belief in a given architecture without understanding what it is you're trying to accomplish, and frankly from my perspective as a netwok operator, that lack of understanding is commonplace. Ignorance is neither shameful nor incurable - what we're trying to do with the first two drafts is to demonstrate that the elephant is not a kite, a snake, or a tree. I realize that this is slower than some people would like, but frankly, if anything, I regret to say that *every* proposal may obviously "need more work" when compared to the reqs draft. Please do not take that as a cheap shot at the authors and potential authors. This is not a trivial problem to solve and it is beyond the ability of any single writer to draw up a complete solution. That's hopefully why we're trying to engineer in committee anyway, and while we're here we can make it easier on authors by pushing them into treating the reqs document as a series of FAQs that ultimately need to be answered. Obvious valid answers are "we do X", "we don't do X but...". On the other hand "we think X is stupid" is something that should really be dealt with in advance (i.e., NOW) so that we don't have to keep rewriting the reqs when we discover they're wrong in some way. :-) Sean. From owner-multi6@ops.ietf.org Sat Aug 4 06:05:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24640 for ; Sat, 4 Aug 2001 06:05:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SyK8-000GdD-00 for multi6-data@psg.com; Sat, 04 Aug 2001 03:06:24 -0700 Received: from [217.33.136.18] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15SyK8-000Gd6-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 03:06:24 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15SyJx-0001ns-00; Sat, 04 Aug 2001 11:06:13 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Peter Tattam Cc: multi6@ops.ietf.org Subject: RE: Transport level multihoming References: Message-Id: Date: Sat, 04 Aug 2001 11:06:13 +0100 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Sorry, I missed something very important there. Is it planned to support > multihoming exactly as Ipv4 does now? The policy a couple of years back > was very firm. IPv6 = Strong aggregation, small DFZ. yes indeed. unfortunately, to date, that rather idealistic policy has lacked clear technical mechanisms with which to implement it. and note that, as this wg is in the ops area, folk here tend to be rather pragmatic about utility and implementability. so, from that, you may be able to infer what this wg is about. randy From owner-multi6@ops.ietf.org Sat Aug 4 06:09:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24661 for ; Sat, 4 Aug 2001 06:09:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SyNY-000Gk2-00 for multi6-data@psg.com; Sat, 04 Aug 2001 03:09:56 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.31 #1) id 15SyNX-000Gjp-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 03:09:55 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id EFB6886D; Sat, 4 Aug 2001 12:09:53 +0200 (CEST) To: mohta@necom830.hpcl.titech.ac.jp, peter@jazz-1.trumpet.com.au Subject: Re: Transport level multihoming Cc: ben@layer8.net, multi6@ops.ietf.org, smd@ebone.net, tli@Procket.com Message-Id: <20010804100953.EFB6886D@sean.ebone.net> Date: Sat, 4 Aug 2001 12:09:53 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk | According to the chairs, we shouldn't figure out how to properly route | it yet, until we finish our requirement draft. I (personally) would really love some answers to the questions I posed to you when I wrote up the analysis of your draft here on the mailing list some months ago. Certainly, I can be persuaded that your solution is both a complete and a routing one, but it will take some work. I also hope to have some time to write up some detailed questions/comments about the other specific proposals, but was hoping other folks in the WG could do some of that for me. :-) | While 3 multi6 meeting are being spent on it, discussions on specific | proposals are discouraged to make the requirement draft abstract | and separated from the real world. The reqs draft should be based on the draft which explains what the real world is today. Anything else would be foolish. Therefore, I think we are in agreement. What I would like to have is a toolset so that you and your "competition" (i.e., other authors) have some hints about the criteria which must be met before anything like rough consensus happens in the WG. The reqs doc based on today's practises, cleaned up a bit and so on, is the best thing I can think of. I am open to suggestions. However, I think we are using too much time in meta-standardizing. The reqs document is not really that hard to complete and move forward. If you think the reqs are separating from the real world, please shout out now with specific objections, rather than waiting for the formal last call. I know that people are listening... Sean. From owner-multi6@ops.ietf.org Sat Aug 4 06:29:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24831 for ; Sat, 4 Aug 2001 06:29:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Sygm-000HJW-00 for multi6-data@psg.com; Sat, 04 Aug 2001 03:29:48 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15Sygl-000HJM-00; Sat, 04 Aug 2001 03:29:47 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id UAA07885; Sat, 4 Aug 2001 20:29:44 +1000 (EST) Date: Sat, 4 Aug 2001 20:29:44 +1000 (EST) From: Peter Tattam To: Randy Bush cc: multi6@ops.ietf.org Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 4 Aug 2001, Randy Bush wrote: > > Sorry, I missed something very important there. Is it planned to support > > multihoming exactly as Ipv4 does now? The policy a couple of years back > > was very firm. IPv6 = Strong aggregation, small DFZ. > > yes indeed. unfortunately, to date, that rather idealistic policy has > lacked clear technical mechanisms with which to implement it. and note > that, as this wg is in the ops area, folk here tend to be rather pragmatic > about utility and implementability. > > so, from that, you may be able to infer what this wg is about. I am beginning to infer that we are talking BGP style solutions much like current IPv4 practice. > > randy > Could the chair please confirm this significant policy turnaround regarding relaxation on indiscriminate advertising in the DFZ for IPv6? If so, I question the credibility of what is being done and can only infer that the BGP lobby has finally gotten their way. I will politely leave because my proposal is very likely no longer valid for the suggested direction. It will not be able to fit all the requirements that have been laid down. Thanks I will lay down a wreath or two for IPv6. 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 Aug 4 06:35:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24893 for ; Sat, 4 Aug 2001 06:35:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SymE-000HUP-00 for multi6-data@psg.com; Sat, 04 Aug 2001 03:35:26 -0700 Received: from [217.33.136.18] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15SymE-000HUJ-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 03:35:26 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Sym7-0002Ad-00; Sat, 04 Aug 2001 11:35:19 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Peter Tattam Cc: multi6@ops.ietf.org Subject: RE: Transport level multihoming References: Message-Id: Date: Sat, 04 Aug 2001 11:35:19 +0100 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit you may find a bit helpful randy From owner-multi6@ops.ietf.org Sat Aug 4 06:45:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24972 for ; Sat, 4 Aug 2001 06:45:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SyvW-000Hn8-00 for multi6-data@psg.com; Sat, 04 Aug 2001 03:45:02 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15SyvV-000Hmt-00; Sat, 04 Aug 2001 03:45:01 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id UAA10827; Sat, 4 Aug 2001 20:44:59 +1000 (EST) Date: Sat, 4 Aug 2001 20:44:58 +1000 (EST) From: Peter Tattam To: Randy Bush cc: multi6@ops.ietf.org Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Read it already. My initial understanding of it was that it supported the preexisting policy of small DFZ. The only way this can be done is to enforce strong aggregation policy. If open the gate even slightly the traditional BGP thinking will just push things back to what they were with IPv4. I was on the side of weak aggregation policy until I "saw the light". Then when I applied my lateral thinking skills, I stumbled onto a possible solution that didn't involve complicated routing exchange protocols. Any solution that shifts the decision making towards the edges of the network is going to scale a whole lot better than one at the core. Peter On Sat, 4 Aug 2001, Randy Bush wrote: > you may find > a bit helpful > > randy > -- 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 Aug 4 07:01:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25088 for ; Sat, 4 Aug 2001 07:01:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SzC2-000IKV-00 for multi6-data@psg.com; Sat, 04 Aug 2001 04:02:06 -0700 Received: from [217.33.136.18] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15SzC2-000IKP-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 04:02:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15SzBw-0002CV-00; Sat, 04 Aug 2001 12:02:00 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Peter Tattam Cc: multi6@ops.ietf.org Subject: RE: Transport level multihoming References: Message-Id: Date: Sat, 04 Aug 2001 12:02:00 +0100 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I was on the side of weak aggregation policy until I "saw the light". great! send code. randy From owner-multi6@ops.ietf.org Sat Aug 4 07:15:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25201 for ; Sat, 4 Aug 2001 07:15:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SzQG-000In7-00 for multi6-data@psg.com; Sat, 04 Aug 2001 04:16:48 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.31 #1) id 15SzQG-000Imy-00 for multi6@ops.ietf.org; Sat, 04 Aug 2001 04:16:48 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 8243B86D; Sat, 4 Aug 2001 13:16:46 +0200 (CEST) To: peter@jazz-1.trumpet.com.au, randy@psg.com Subject: RE: Transport level multihoming Cc: multi6@ops.ietf.org Message-Id: <20010804111646.8243B86D@sean.ebone.net> Date: Sat, 4 Aug 2001 13:16:46 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Peter - It would be interesting to see you put together a quick attempt at a formal registry allocation policy (with or without RIRs) for the small-DFZ aproach. I am not sure how I* would publish such a policy, but I think it would help crystallize the argument about the viability of the small-DFZ proposal. Certainly, if you and others (e.g. Christian Huitema) can put together some framework for actually operating the small-DFZ, then I'm sure that if multi6 is not the correct WG, something can be spun up in the Ops area. However, here's a good place to test how multihoming will actually work for sites of various sizes, for various approaches, independent of what biases people have. Sean. From owner-multi6@ops.ietf.org Sat Aug 4 07:16:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25212 for ; Sat, 4 Aug 2001 07:16:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SzQI-000InF-00 for multi6-data@psg.com; Sat, 04 Aug 2001 04:16:50 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15SzQH-000In0-00; Sat, 04 Aug 2001 04:16:49 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id VAA16419; Sat, 4 Aug 2001 21:16:46 +1000 (EST) Date: Sat, 4 Aug 2001 21:16:46 +1000 (EST) From: Peter Tattam To: Randy Bush cc: multi6@ops.ietf.org Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 4 Aug 2001, Randy Bush wrote: > > I was on the side of weak aggregation policy until I "saw the light". > > great! send code. > > randy > Is that a challenge for me to implement my protocol on our stack and distribute it as standard with the next operating system release without peer review :) That's sure to make friends for me within the IETF and the rest of the industry !!! The doc I sent the reference to was enough for someone to flesh out the details and make it work - I believe there is a BSD implementation out before I even got a chance to try it myself. What I've presented is a concept paper. Once people are comfortable with the concepts, I'll put together a technical paper with specifics. But my time is too precious to spend on something that isn't going to be used. I need a strong green light before I take it any further. 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 Aug 4 07:31:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25339 for ; Sat, 4 Aug 2001 07:31:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SzeM-000JFK-00 for multi6-data@psg.com; Sat, 04 Aug 2001 04:31:22 -0700 Received: from server.pasta.cs.uit.no ([129.242.16.119] helo=dillema.net) by psg.com with esmtp (Exim 3.31 #1) id 15SzeL-000JFB-00; Sat, 04 Aug 2001 04:31:21 -0700 Received: (from dillema@localhost) by dillema.net (8.11.4/8.11.3) id f74BUrx04146; Sat, 4 Aug 2001 13:30:53 +0200 (CEST) Date: Sat, 4 Aug 2001 13:30:53 +0200 From: Feico Dillema To: Peter Tattam Cc: Randy Bush , multi6@ops.ietf.org Subject: Re: Transport level multihoming Message-ID: <20010804133051.A1355@pasta.cs.uit.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from peter@jazz-1.trumpet.com.au on Sat, Aug 04, 2001 at 09:16:46PM +1000 X-Operating-System: NetBSD drifter.dillema.net 1.5W NetBSD 1.5W (DRIFTER) X-URL: http://www.dillema.net/ Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, Aug 04, 2001 at 09:16:46PM +1000, Peter Tattam wrote: > On Sat, 4 Aug 2001, Randy Bush wrote: > > > great! send code. > > Is that a challenge for me to implement my protocol on our stack and distribute > it as standard with the next operating system release without peer review :) > That's sure to make friends for me within the IETF and the rest of the > industry !!! > > The doc I sent the reference to was enough for someone to flesh out the details > and make it work - I believe there is a BSD implementation out before I even > got a chance to try it myself. What I've presented is a concept paper. Once One of our students implemented it for FreeBSD-3.2 with Kame IPv6 stack of 12-1999. His thesis and all source code can be found on-line here: http://www.vermicelli.pasta.cs.uit.no/ipv6/students/troels/index.html Feico. From owner-multi6@ops.ietf.org Sat Aug 4 07:46:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25422 for ; Sat, 4 Aug 2001 07:46:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Sztb-000JiT-00 for multi6-data@psg.com; Sat, 04 Aug 2001 04:47:07 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15Szta-000JiN-00; Sat, 04 Aug 2001 04:47:06 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id VAA21603; Sat, 4 Aug 2001 21:46:54 +1000 (EST) Date: Sat, 4 Aug 2001 21:46:54 +1000 (EST) From: Peter Tattam To: Sean Doran cc: randy@psg.com, multi6@ops.ietf.org Subject: RE: Transport level multihoming In-Reply-To: <20010804111646.8243B86D@sean.ebone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 4 Aug 2001, Sean Doran wrote: > Peter - > > It would be interesting to see you put together a quick attempt > at a formal registry allocation policy (with or without RIRs) for > the small-DFZ aproach. > > I am not sure how I* would publish such a policy, but I think > it would help crystallize the argument about the viability of > the small-DFZ proposal. > I will respond to this later. > Certainly, if you and others (e.g. Christian Huitema) can > put together some framework for actually operating the small-DFZ, > then I'm sure that if multi6 is not the correct WG, something can > be spun up in the Ops area. > > However, here's a good place to test how multihoming will > actually work for sites of various sizes, for various approaches, > independent of what biases people have. > > Sean. > One of the difficulties that makes "testing" difficult is that you can only simulate the ideas and draw inferences from the results. Most every other protocol on the internet today has been put together by incremental design with lessons being learned from real life over considerable amounts of time. One lesson we are learning is that EGPs aren't scaling too well, and thumb nail simulations would indicate that it mightn't scale for Ipv6 because of the huge address space. The best we can do is build up a test network using the 6bone and configure it for strong aggregation multi homing with decision making at the edges. I don't think this task is too difficult. I can code up the protocol fairly quickly & I believe there is BSD implementation in existence but I'm not sure about availablility. At the root of the whole debate is that we only get one chance to get it right. It's like trying to land a guy on the moon. If you screw up, there's a lot at stake. 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 Aug 4 07:49:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25449 for ; Sat, 4 Aug 2001 07:49:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Szwb-000JqA-00 for multi6-data@psg.com; Sat, 04 Aug 2001 04:50:13 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15Szwa-000Jq1-00; Sat, 04 Aug 2001 04:50:12 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id VAA21982; Sat, 4 Aug 2001 21:49:59 +1000 (EST) Date: Sat, 4 Aug 2001 21:49:59 +1000 (EST) From: Peter Tattam To: Feico Dillema cc: Randy Bush , multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: <20010804133051.A1355@pasta.cs.uit.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 4 Aug 2001, Feico Dillema wrote: > On Sat, Aug 04, 2001 at 09:16:46PM +1000, Peter Tattam wrote: > > On Sat, 4 Aug 2001, Randy Bush wrote: > > > > > great! send code. > > > > Is that a challenge for me to implement my protocol on our stack and distribute > > it as standard with the next operating system release without peer review :) > > That's sure to make friends for me within the IETF and the rest of the > > industry !!! > > > > The doc I sent the reference to was enough for someone to flesh out the details > > and make it work - I believe there is a BSD implementation out before I even > > got a chance to try it myself. What I've presented is a concept paper. Once > > One of our students implemented it for FreeBSD-3.2 with Kame IPv6 > stack of 12-1999. His thesis and all source code can be found on-line > here: > > http://www.vermicelli.pasta.cs.uit.no/ipv6/students/troels/index.html Thanks, I will take a close look. > > Feico. > > Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Sun Aug 5 04:52:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10533 for ; Sun, 5 Aug 2001 04:52:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15TJc6-0000pA-00 for multi6-data@psg.com; Sun, 05 Aug 2001 01:50:22 -0700 Received: from sommerfeld.ne.mediaone.net ([24.218.160.210] helo=stack.hamachi.org) by psg.com with esmtp (Exim 3.31 #1) id 15TJc5-0000ou-00 for multi6@ops.ietf.org; Sun, 05 Aug 2001 01:50:21 -0700 Received: from syn.hamachi.org (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id 50D1B2712; Sun, 5 Aug 2001 04:50:15 -0400 (EDT) Received: from syn (localhost [[UNIX: localhost]]) by syn.hamachi.org (8.11.0/8.8.8) with ESMTP id f74C0ar00424; Sat, 4 Aug 2001 08:00:36 -0400 (EDT) Message-Id: <200108041200.f74C0ar00424@syn.hamachi.org> From: Bill Sommerfeld To: Randy Bush Cc: smd@ebone.net (Sean Doran), multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: Message from Randy Bush of "Sat, 04 Aug 2001 10:06:03 BST." Reply-To: sommerfeld@orchard.arlington.ma.us Date: Sat, 04 Aug 2001 08:00:36 -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > #1 - how multihoming is done today in the Internet > > #2 - requirements for multihoming in an IPv6 Internet > > (which probably should say "AT LEAST #1 and some more things") > > just to make trouble, and not because i have a position on the question, is > the parenthetical above *really* a desirable/necessary condition? i.e. if, > by magic, we come up with a really sexy v6 solution, must it also support > current v4-style multihoming. I really hope Sean meant: problem #1: multihoming v4 in today's internet problem #2: multihoming v6 in a future IPv6 Internet - requirements for #2 are a subset of the requirements to #1 - possible solutions to #2 are a superset of the solutions to #1 - Bill From owner-multi6@ops.ietf.org Mon Aug 6 08:12:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21847 for ; Mon, 6 Aug 2001 08:12:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15TjCk-000Cbo-00 for multi6-data@psg.com; Mon, 06 Aug 2001 05:09:54 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.31 #1) id 15TjCj-000Cbi-00; Mon, 06 Aug 2001 05:09:53 -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 IAA13956; Mon, 6 Aug 2001 08:09:39 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id IAA06816; Mon, 6 Aug 2001 08:09:39 -0400 (EDT) Date: Mon, 6 Aug 2001 08:09:39 -0400 (EDT) From: Greg Maxwell To: Randy Bush cc: Peter Tattam , Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 4 Aug 2001, Randy Bush wrote: [snip] > > was very firm. IPv6 = Strong aggregation, small DFZ. > > yes indeed. unfortunately, to date, that rather idealistic policy has > lacked clear technical mechanisms with which to implement it. and note > that, as this wg is in the ops area, folk here tend to be rather pragmatic > about utility and implementability. > > so, from that, you may be able to infer what this wg is about. Yes, it's about excluding new ideas which have strong technical merit because some people believe that IPv6 has significant implementation momentum and that the future cost of restructuring the IPv6 Internet to make it scalable once it falls down is greater then the cost of potentially slowing this supposedly huge IPv6 momentum. From owner-multi6@ops.ietf.org Mon Aug 6 08:19:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21937 for ; Mon, 6 Aug 2001 08:19:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15TjLG-000Cq8-00 for multi6-data@psg.com; Mon, 06 Aug 2001 05:18:42 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.31 #1) id 15TjLF-000Cq2-00; Mon, 06 Aug 2001 05:18:42 -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 IAA14126; Mon, 6 Aug 2001 08:18:29 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id IAA07450; Mon, 6 Aug 2001 08:18:28 -0400 (EDT) Date: Mon, 6 Aug 2001 08:18:28 -0400 (EDT) From: Greg Maxwell To: Randy Bush cc: Peter Tattam , Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 4 Aug 2001, Randy Bush wrote: > > I was on the side of weak aggregation policy until I "saw the light". > > great! send code. What code to you want? I've collected a few differnt transport hacks that serve the purpose (such as SCTP) but they require minor (i.e. search and replace) application level changes. This working group has pretty much painted themselves into a corner by concluding that application level changes for multihoming support are not acceptable. Because of this, the majority of the transport level multihoming discussion has been about ugly hacks on TCP involving DNS kludges and other things that are never going to work. IPv6 itself requires application level changes of a simmlar extent then moving to SCTP in TCP-like mode, multihoming *could* be left to apps which have made the transition, and I've already posted what I believe to be a fairly good high level set of ideas on how 'total aggregation' can by maintained (via prefix flow-throughs). From owner-multi6@ops.ietf.org Mon Aug 6 08:22:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21976 for ; Mon, 6 Aug 2001 08:22:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15TjOW-000CyJ-00 for multi6-data@psg.com; Mon, 06 Aug 2001 05:22:04 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.31 #1) id 15TjOV-000CyA-00; Mon, 06 Aug 2001 05:22:03 -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 IAA14186; Mon, 6 Aug 2001 08:21:50 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id IAA07632; Mon, 6 Aug 2001 08:21:50 -0400 (EDT) Date: Mon, 6 Aug 2001 08:21:50 -0400 (EDT) From: Greg Maxwell To: Peter Tattam cc: Sean Doran , , Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 4 Aug 2001, Peter Tattam wrote: [snip] > At the root of the whole debate is that we only get one chance to get it right. > It's like trying to land a guy on the moon. If you screw up, there's a lot at > stake. Poor analogy. If we kill the guy going to the moon, it's a single event. If we grow the production IPv6 Internet without strong aggregation and node/IP independence we might be crushed under the mess for some time to come. From owner-multi6@ops.ietf.org Mon Aug 6 09:40:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23198 for ; Mon, 6 Aug 2001 09:40:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Tkco-000F6F-00 for multi6-data@psg.com; Mon, 06 Aug 2001 06:40:54 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.31 #1) id 15Tkcn-000F5j-00 for multi6@ops.ietf.org; Mon, 06 Aug 2001 06:40:53 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id E034A86D; Mon, 6 Aug 2001 15:40:50 +0200 (CEST) To: sommerfeld@orchard.arlington.ma.us Cc: Randy Bush , multi6@ops.ietf.org Subject: Re: Transport level multihoming References: <200108041200.f74C0ar00424@syn.hamachi.org> From: Sean Doran Date: Mon, 06 Aug 2001 15:40:50 +0200 In-Reply-To: <200108041200.f74C0ar00424@syn.hamachi.org> (Bill Sommerfeld's message of "Sat, 04 Aug 2001 08:00:36 -0400") Message-ID: <52u1zlux0d.fsf@sean.ebone.net> Lines: 14 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-multi6@ops.ietf.org Precedence: bulk Bill Sommerfeld writes: > I really hope Sean meant: > > problem #1: multihoming v4 in today's internet > problem #2: multihoming v6 in a future IPv6 Internet > - requirements for #2 are a subset of the requirements to #1 > - possible solutions to #2 are a superset of the solutions to #1 Yes. Thank you for the improved wording. (Although to quibble, requirements for #2 are a set containing a subset of the requirements to #1). Sean. From owner-multi6@ops.ietf.org Mon Aug 6 12:54:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27497 for ; Mon, 6 Aug 2001 12:54:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Tndo-000KtU-00 for multi6-data@psg.com; Mon, 06 Aug 2001 09:54:08 -0700 Received: from soggy131.drizzle.com ([216.162.199.131] helo=tristero.cryptocourier.com) by psg.com with smtp (Exim 3.31 #1) id 15Tndn-000KtO-00 for multi6@ops.ietf.org; Mon, 06 Aug 2001 09:54:07 -0700 Received: (qmail 22941 invoked from network); 6 Aug 2001 17:03:19 -0000 Received: from unknown (HELO ae) (192.168.70.50) by 192.168.70.2 with SMTP; 6 Aug 2001 17:03:19 -0000 From: "Ben Black" To: "Greg Maxwell" , "Randy Bush" Cc: "Peter Tattam" , Subject: RE: Transport level multihoming Date: Mon, 6 Aug 2001 09:54:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > This working group has pretty much painted themselves into a corner by > concluding that application level changes for multihoming support are not > acceptable. > I am part of this working group and I have definitely not concluded this. I have concluded the exact opposite, and I believe rather strongly that the reason this situation exists is layer violation (why does the application need to know the network and transport addresses?). Ben From owner-multi6@ops.ietf.org Mon Aug 6 16:39:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01330 for ; Mon, 6 Aug 2001 16:39:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Tr9Y-00018u-00 for multi6-data@psg.com; Mon, 06 Aug 2001 13:39:08 -0700 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by psg.com with esmtp (Exim 3.31 #1) id 15Tr9X-00017t-00 for multi6@ops.ietf.org; Mon, 06 Aug 2001 13:39:07 -0700 Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f76Kck305662; Mon, 6 Aug 2001 13:38:46 -0700 (PDT) Received: from [144.254.46.238] (ams-vpdn-client-237.cisco.com [144.254.46.238]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ABB09911; Mon, 6 Aug 2001 13:38:29 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: Date: Mon, 6 Aug 2001 13:27:59 -0700 To: "Ben Black" , Vijay Gill , Joe Abley From: Steve Deering Subject: comments on requirements draft Cc: multi6@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk Here are some comments on the -01 version of the multi6 requirements draft. > Requirements for IP Multihoming Architectures Shouldn't this say "Site Multihoming" or "Enterprise Multihoming" or something like that, to distinguish it from the other common uses of the term "multihoming", such as host multihoming (i.e., having more than one address or more than one interface on a host)? >Abstract > > Multihoming is an essential component of service for enterprises [3] > which are part of the Internet. Existing IPv4 multi-homing... "Multihoming" is used before it is defined. How about something like the following: Multihoming, that is, connecting to more than one IP service provider, is an essential component for enterprises... > Migration to IPv6, which will allow unprecedented scaling of the > number of potentially multihomed sites, will seriously exacerbate > this stress unless a substantially different approach to multihoming > is adopted. It's not the move to IPv6 that will exacerbate the stress -- it's the growth of the Internet and of multihoming, regardless of which version of IP will be used. It is often claimed that IPv6's larger address will make the problem worse, as if the shorter length of IPv4 addresses were acting as some sort of defense, which is just not true. The 32-bit space already accommodates "unprecedented scaling of the number of potentially multihomed sites" way beyond what can be handled with the current multihoming approach, as we we move more and more towards giving sites only one or a small number of public IPv4 addresses and expecting them to use NAT. I.e., the current direction is intractable; IPv6 doesn't make it "more intractable". > An "enterprise" is an entity autonomously operating a network using > TCP/IP and, in particular, determining the addressing plan and > address assignments within that network. This is the definition of > "enterprise" used in [3]. I wonder why "TCP/IP" and not just "IP"? Must an enterprise use TCP? >3.1.1 Redundancy > > By multihoming, an enterprise should be able to insulate itself from > certain failure modes within one or more transit providers, as well > as failures in the network providing interconnecting with one or more > transit providers. "providing interconnecting with" is awkward. How about "providing interconnection among"? > The multihoming architecture must accommodate (in the general case, > issues of shared-fate notwithstanding) the following failure modes: s/accommodate/survive/ > o Physical link failure, such as a fiber cut or router failure, A router failure is not an example of a physical link failure. >3.1.2 Load Sharing > > By multihoming, an enterprise should be able to distribute both > inbound and outbound traffic between multiple transit providers. s/between/across/ Also, change or add wording to make it clear that the requirement is for potentially *concurrent* usage of the multiple connections, not just the usage of one provider over one interval of time and another provider over a different interval. >3.1.3 Performance > > By multihoming, an enterprise should be able to protect itself from > performance difficulties between transit providers. > > For example, suppose enterprise E obtains transit from transit > providers T1 and T2, and there is long-term congestion between T1 and > T2. The multihoming architecture should allow E to ensure that in > normal operation none of its traffic is carried over the congested > interconnection T1-T2. How is the capability offered in the current multihoming approach, given that BGP is not sensitive to congestion, short-term or long-term? > A multi-homed enterprise must also be able to distribute inbound > traffic particular multiple transit providers according to the ^ from > particular network within their enterprise which is sourcing or > sinking the traffic. How can a network within the enterprise source inbound traffic to that enterprise via a particular transit provider? This Performance section needs more elaboration and clarification. >3.1.4 Policy > > A customer may choose to multihome for a variety of policy reasons > outside technical scope (e.g. cost, acceptable use conditions, etc.) ^ the? > For example, customer C homed to ISP A may wish to shift traffic of a > certain class or application, NNTP, for example, to ISP B as matter > of policy. A new IPv6 multihoming proposal must provide support for > multihoming for external policy reasons. Inbound only? Outbound only? Both? This requirement seems excessive to me, e.g., if end systems ESP encrypt their traffic, how can the network recognize NNTP traffic? >3.1.5 Simplicity > > As any proposed multihoming solution must be deployed in real > networks with real customers, simplicity is paramount. The current > multihoming solution is quite straightforward to deploy and maintain. > A new IPv6 multihoming proposal must not be substantially more > complex to deploy and operate than current IPv4 multihoming > practices. Complexity is in the eye of the beholder. Also, the acceptability of complexity may well depend upon whom the complexity is being imposed, and on what benefits one gets in return for that complexity. BGP and OSPF are more complex than RIP, but their advantages are apparently deemed worth their extra complexity. So while simplicity is a very important goal, and we each believe we know complexity when we see it (even when others disagree), it's not feasible in this context to measure complexity or agree on how much is too much, so it cannot reasonably be made a "requirement". >3.2.1 Scalability > > Current IPV4 multihoming practices contribute to the significant > growth currently observed in the state held in the global inter- ^ and information exchanged? > provider routing system; this is a concern both because of the > hardware requirements it imposes and also because of the impact on > the stability of the routing system. This issue is discussed in > great detail in [9]. > > A new IPv6 multihoming architecture should scale to accommodate > orders of magnitude more multi-homed enterprises without imposing > unreasonable requirements on the routing system. How many orders of magnitude? >3.2.2 Impact on Routers > > The solution may require changes to IPv6 router implementations, but > these changes must be either minor, or in the form of logically > separate functions added to existing functions. This is a surprising requirement -- can you elaborate? Also, the nature and degree of acceptable change would presumably depend on whether or not the change was required in the data plane (already being cast in hardware for IPv6 on some routers) or the control plane (still in software), and perhaps also on how many routers would have to change, e.g., all routers vs. backbone routers vs. edge routers vs. enterprise routers. >3.2.3 Impact on Hosts > > The solution must not destroy IPv6 connectivity for a legacy host > implementing RFC 2373 [5], RFC 2460 [7], RFC 2553 [8] and other basic > IPv6 specifications current in June 2001. That is to say, if a host > can work in a single-homed site, it must still be able to work in a > multihomed site, even if it cannot benefit from multihoming. > > It would be compatible with this requirement for such a host to lose > connectivity if the site's primary ISP connection failed. Is the assumption that there's a "primary" ISP always valid? What about newly-established sessions? > If the solution requires changes to the host stack, these changes > must be either minor, or in the form of logically separate functions > added to existing functions. This needs more elaboration. > The multi-homing solution should allow host or application changes to > enhance session survivability. s/to enhance/if that would enhance/ >3.2.5 Operations and Management > > It must be posssible to monitor and configure the multihoming system. Possible for whom? >4. Security Considerations > > Multihoming no doubt offers some attractive opportunites for denial > of service and spoofing attacks. Multihomed sites must be protected > against such attacks at least as well as single-homed sites. I.e., not at all? - Steve From owner-multi6@ops.ietf.org Mon Aug 6 17:42:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02625 for ; Mon, 6 Aug 2001 17:42:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ts91-0002TQ-00 for multi6-data@psg.com; Mon, 06 Aug 2001 14:42:39 -0700 Received: from [209.233.126.65] (helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.31 #1) id 15Ts91-0002RE-00 for multi6@ops.ietf.org; Mon, 06 Aug 2001 14:42:39 -0700 Subject: New proposal for Network Layer IPv6 multihoming: MHTP Date: Mon, 6 Aug 2001 14:41:22 -0700 MIME-Version: 1.0 Message-ID: <2B81403386729140A3A899A8B39B046403ACE4@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset="UTF-8" X-Mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: New proposal for Network Layer IPv6 multihoming: MHTP Thread-Index: AcEewIj2OGIs3WaMTIC1+7NfXNwc2A== From: "Michel Py" To: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id RAA02625 Dear multi6 members, I would greatly appreciate the group's feedback on the following text I just submitted. http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-00.txt Regards, Michel. From owner-multi6@ops.ietf.org Mon Aug 6 19:44:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04300 for ; Mon, 6 Aug 2001 19:44:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Tu2P-000599-00 for multi6-data@psg.com; Mon, 06 Aug 2001 16:43:57 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15Tu2O-000593-00; Mon, 06 Aug 2001 16:43:56 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id JAA20821; Tue, 7 Aug 2001 09:43:48 +1000 (EST) Date: Tue, 7 Aug 2001 09:43:47 +1000 (EST) From: Peter Tattam To: Greg Maxwell cc: Randy Bush , multi6@ops.ietf.org Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 6 Aug 2001, Greg Maxwell wrote: > On Sat, 4 Aug 2001, Randy Bush wrote: > > [snip] > > > was very firm. IPv6 = Strong aggregation, small DFZ. > > > > yes indeed. unfortunately, to date, that rather idealistic policy has > > lacked clear technical mechanisms with which to implement it. and note > > that, as this wg is in the ops area, folk here tend to be rather pragmatic > > about utility and implementability. > > > > so, from that, you may be able to infer what this wg is about. > > Yes, it's about excluding new ideas which have strong technical merit > because some people believe that IPv6 has significant implementation > momentum and that the future cost of restructuring the IPv6 Internet to > make it scalable once it falls down is greater then the cost of > potentially slowing this supposedly huge IPv6 momentum. > > > I don't quite know which way to read this :) 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 Aug 6 19:47:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04322 for ; Mon, 6 Aug 2001 19:47:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Tu6X-0005FU-00 for multi6-data@psg.com; Mon, 06 Aug 2001 16:48:13 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15Tu6W-0005FN-00; Mon, 06 Aug 2001 16:48:12 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id JAA21493; Tue, 7 Aug 2001 09:48:06 +1000 (EST) Date: Tue, 7 Aug 2001 09:48:05 +1000 (EST) From: Peter Tattam To: Greg Maxwell cc: Randy Bush , multi6@ops.ietf.org Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk The problem with application methods is that they're prone to application coding errors. There's already a big hit ofr app developers to convert to IPv6 anyway. Making it even harder can be seen to be counterproductive. Peter On Mon, 6 Aug 2001, Greg Maxwell wrote: > On Sat, 4 Aug 2001, Randy Bush wrote: > > > > I was on the side of weak aggregation policy until I "saw the light". > > > > great! send code. > > What code to you want? I've collected a few differnt transport hacks that > serve the purpose (such as SCTP) but they require minor (i.e. search and > replace) application level changes. > > This working group has pretty much painted themselves into a corner by > concluding that application level changes for multihoming support are not > acceptable. > > Because of this, the majority of the transport level multihoming > discussion has been about ugly hacks on TCP involving DNS kludges and > other things that are never going to work. > > IPv6 itself requires application level changes of a simmlar extent then > moving to SCTP in TCP-like mode, multihoming *could* be left to apps which > have made the transition, and I've already posted what I believe to be a > fairly good high level set of ideas on how 'total aggregation' can by > maintained (via prefix flow-throughs). > > > > -- 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 Aug 6 19:54:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04413 for ; Mon, 6 Aug 2001 19:54:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15TuDT-0005Qe-00 for multi6-data@psg.com; Mon, 06 Aug 2001 16:55:23 -0700 Received: from mailhub1.almaden.ibm.com ([198.4.83.44]) by psg.com with esmtp (Exim 3.31 #1) id 15TuC1-0005N5-00 for multi6@ops.ietf.org; Mon, 06 Aug 2001 16:55:22 -0700 Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id QAA223074; Mon, 6 Aug 2001 16:47:56 -0700 Received: from hursley.ibm.com (lig32-227-10-250.us.lig-dial.ibm.com [32.227.10.250]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id NAA20100; Mon, 6 Aug 2001 13:17:39 -0700 Message-ID: <3B6EFA26.C1EBB986@hursley.ibm.com> Date: Mon, 06 Aug 2001 15:12:22 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Thomas Narten CC: multi6@ops.ietf.org, Sean Doran Subject: Re: Pseudo "last call" for draft-ietf-ipngwg-ipv6-2260-02.txt References: <200107272055.QAA01999@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I see no harm in publishing this as Informational. My most urgent concern is still to see the multi6 requirements published, so that we can start to evaluate all proposed solutions somewhat objectively. Brian Thomas Narten wrote: > > The document "IPv6 multihoming support at site exit routers" > came out of the IPng WG, which > has requested that it be published as an informational RFC. Given that > the subject of the draft overlaps with the main focus of this group, > we'd be interested in getting WG feedback on the contents of the > document. Namely: > > - is the document reasonable to publish as an informational RFC as > is, or are some specific changes appropriate? > > - How feasible do the techniques described in the document appear to > be from the perspective of an operator? > > - What are the main (if any) limitations to using the described > techniques from an operational perspective? Are these limitations, > if any, adequately described in the document? > > Explicit feedback (including "looks fine to me") from all those who > read it would be helpful. > > Sean & Thomas > Multi6 WG Chairs From owner-multi6@ops.ietf.org Mon Aug 6 20:25:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04678 for ; Mon, 6 Aug 2001 20:25:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Tugr-00068n-00 for multi6-data@psg.com; Mon, 06 Aug 2001 17:25:45 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15Tugq-00068h-00; Mon, 06 Aug 2001 17:25:44 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id KAA00763; Tue, 7 Aug 2001 10:25:31 +1000 (EST) Date: Tue, 7 Aug 2001 10:25:30 +1000 (EST) From: Peter Tattam To: Greg Maxwell cc: Sean Doran , randy@psg.com, multi6@ops.ietf.org Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk But don't forget the run up to the moon took 10+ years of work - at stake wasn't just the man's life, but rather the national pride of USA. This is kind of the same, a lot of poeple have invested blood, sweat & tears into IPv6 and don't want it to fall on its head. On the other hand they don't want to see it still born because of delays in getting key components together. Peter On Mon, 6 Aug 2001, Greg Maxwell wrote: > On Sat, 4 Aug 2001, Peter Tattam wrote: > > [snip] > > At the root of the whole debate is that we only get one chance to get it right. > > It's like trying to land a guy on the moon. If you screw up, there's a lot at > > stake. > > Poor analogy. If we kill the guy going to the moon, it's a single event. > > If we grow the production IPv6 Internet without strong aggregation and > node/IP independence we might be crushed under the mess for some time to > come. > > -- 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 Aug 7 07:43:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01369 for ; Tue, 7 Aug 2001 07:43:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U5Fb-000MQL-00 for multi6-data@psg.com; Tue, 07 Aug 2001 04:42:19 -0700 Received: from kahuna.telstra.net ([139.130.204.11]) by psg.com with esmtp (Exim 3.31 #1) id 15U5FZ-000MQF-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 04:42:18 -0700 Received: from tecra.telstra.net (jumble.telstra.net [139.130.204.15]) by kahuna.telstra.net (8.11.3/8.11.3) with ESMTP id f77BcU871780; Tue, 7 Aug 2001 21:38:31 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20010807213442.00bff300@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 21:37:28 +1000 To: Steve Deering From: Geoff Huston Subject: Re: comments on requirements draft Cc: "Ben Black" , Vijay Gill , Joe Abley , multi6@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk nit upon nit... >Here are some comments on the -01 version of the multi6 requirements >draft. > > > >Abstract > > > > Multihoming is an essential component of service for enterprises [3] > > which are part of the Internet. Existing IPv4 multi-homing... > >"Multihoming" is used before it is defined. How about something like >the following: > > Multihoming, that is, connecting to more than one IP service > provider, is an essential component for enterprises... "essential"? Not necessarily essential, but sometimes desirable. How about: "Multihoming, that is, connecting to more than one IP service provider for IP access and transit services is used by enterprises ..... Geoff From owner-multi6@ops.ietf.org Tue Aug 7 07:46:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01396 for ; Tue, 7 Aug 2001 07:46:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U5J4-000MUW-00 for multi6-data@psg.com; Tue, 07 Aug 2001 04:45:54 -0700 Received: from kahuna.telstra.net ([139.130.204.11]) by psg.com with esmtp (Exim 3.31 #1) id 15U5J3-000MUO-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 04:45:54 -0700 Received: from tecra.telstra.net (jumble.telstra.net [139.130.204.15]) by kahuna.telstra.net (8.11.3/8.11.3) with ESMTP id f77Bhc871793; Tue, 7 Aug 2001 21:43:38 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20010807213754.00ca1ab0@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 21:42:38 +1000 To: Steve Deering From: Geoff Huston Subject: Re: comments on requirements draft Cc: "Ben Black" , Vijay Gill , Joe Abley , multi6@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk one point at a time: > > Migration to IPv6, which will allow unprecedented scaling of the > > number of potentially multihomed sites, will seriously exacerbate > > this stress unless a substantially different approach to multihoming > > is adopted. > >It's not the move to IPv6 that will exacerbate the stress -- it's >the growth of the Internet and of multihoming, regardless of which >version of IP will be used. I would tend to suggest that growth in multi-homing is a cost and perception issue. If the cost of multi-homing is considered to be sufficiently low and the perception of service reliability is also sufficiently low then you will see increased activity in multi-homing. Increase the perception of reliability, or make multi-homing more difficult (cost, technology required, or anything else) and you reduce the incidence of multi-homing. To ascribe growth to multi-homing to IPv6 is a rash statement without adequate foundation. Geoff From owner-multi6@ops.ietf.org Tue Aug 7 08:38:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02320 for ; Tue, 7 Aug 2001 08:38:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U66l-000NxR-00 for multi6-data@psg.com; Tue, 07 Aug 2001 05:37:15 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.31 #1) id 15U66k-000NxB-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 05:37:14 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id B7D2B86D; Tue, 7 Aug 2001 14:37:12 +0200 (CEST) To: deering@cisco.com, gih@telstra.net Subject: Re: comments on requirements draft Cc: ben@layer8.net, jabley-ietf@automagic.org, multi6@ops.ietf.org, vijay@umbc.edu Message-Id: <20010807123712.B7D2B86D@sean.ebone.net> Date: Tue, 7 Aug 2001 14:37:12 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Thanks, Geoff, for your realtime comments. The scheduling is tight, so it's good to know the list (and possibly other media (IRC, anyone?)) can save on microphone time during Q&A. Sean. From owner-multi6@ops.ietf.org Tue Aug 7 10:22:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04706 for ; Tue, 7 Aug 2001 10:22:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U7kP-0001N1-00 for multi6-data@psg.com; Tue, 07 Aug 2001 07:22:17 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15U7kO-0001M7-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 07:22:16 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id AAA06251; Wed, 8 Aug 2001 00:21:29 +1000 (EST) Date: Wed, 8 Aug 2001 00:21:28 +1000 (EST) From: Peter Tattam To: Geoff Huston cc: Steve Deering , Ben Black , Vijay Gill , Joe Abley , multi6@ops.ietf.org Subject: Re: comments on requirements draft In-Reply-To: <4.3.2.7.2.20010807213754.00ca1ab0@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 7 Aug 2001, Geoff Huston wrote: > one point at a time: > > > > > Migration to IPv6, which will allow unprecedented scaling of the > > > number of potentially multihomed sites, will seriously exacerbate > > > this stress unless a substantially different approach to multihoming > > > is adopted. > > > >It's not the move to IPv6 that will exacerbate the stress -- it's > >the growth of the Internet and of multihoming, regardless of which > >version of IP will be used. > > > I would tend to suggest that growth in multi-homing is a cost and > perception issue. > If the cost of multi-homing is considered to be sufficiently low and the > perception > of service reliability is also sufficiently low then you will see increased > activity > in multi-homing. Increase the perception of reliability, or make > multi-homing more > difficult (cost, technology required, or anything else) and you reduce the > incidence of multi-homing. To ascribe growth to multi-homing to IPv6 is a rash > statement without adequate foundation. > > Geoff > > > I was at a recent conference in Aus and the issue of Service Level Agreements was being discussed in a forum panel. Each of three very large telco's/provider's (by Aus standards anyway) representatives were all highly confident that they could promise extremely high levels of redundancy and there was no need to have more than one provider. However by the end of the panel discussion and after several war stories were shared by members of the audience and even one member on the panel, it was eventually conceded that for an effective SLA, redundancy was crucial, and in particular to multiple providers. The forum concluded with an independent consultant's reflection that they always recommended complete redundancy to their clients especially at the last mile. I also find that the further you are away from the core of the internet in your region, the higher is the risk of things going bang. We are multply homed to 3 providers even though we are a small ISP, and I have had occusion to depend on each of them for large outages over the past year. Some outages were configuration problems in networks, while others were meltdowns in the providers infrastructure including major cable breaks, and even one international fibre break. Had it not been for our multihoming, our service would have been out for a minimum of several hours, and in one worst case scenario we suffered, 2-3 days. This risk of things going wrong being higher at the edge is a curious observation as it flies in the face of the conventional wisdom that says that the smaller you are, and further from the core, the less need one should have for multihoming. I would suggest the converse may actually be true. The smaller or perhaps more remote a site or network is, the higher is the risk that the quality of their service is going to be degraded in one way or another. I guess my point is that to maintain any kind of quality of service, a small provider has to go that extra mile (pardon the pun) and provide a better service to differentiate their brand from the big providers. One method of differentiation is redundancy by multihoming, even if the perceived cost may be high. 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 Aug 7 13:38:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09060 for ; Tue, 7 Aug 2001 13:38:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UAnX-0006uL-00 for multi6-data@psg.com; Tue, 07 Aug 2001 10:37:43 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=goose.home.automagic.org) by psg.com with esmtp (Exim 3.31 #1) id 15UAnW-0006uB-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 10:37:42 -0700 Received: (from jabley@localhost) by goose.home.automagic.org (8.11.3/8.11.3) id f77Hakp05932; Tue, 7 Aug 2001 13:36:46 -0400 (EDT) Date: Tue, 7 Aug 2001 13:36:46 -0400 From: Joe Abley To: Steve Deering Cc: Ben Black , Vijay Gill , multi6@ops.ietf.org Subject: Re: comments on requirements draft Message-ID: <20010807133645.V1607@goose.home.automagic.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi Steve, Thanks for your comments! A couple of small comments on a couple of them to start off with: On Mon, Aug 06, 2001 at 01:27:59PM -0700, Steve Deering wrote: > > An "enterprise" is an entity autonomously operating a network using > > TCP/IP and, in particular, determining the addressing plan and > > address assignments within that network. This is the definition of > > "enterprise" used in [3]. > > I wonder why "TCP/IP" and not just "IP"? Must an enterprise use TCP? The origin of this (surprisingly contentious!) paragraph is an idea that was put forward in response to -00, which was that since "enterprise" was already defined in an existing document (RFC1918), it might be nice to re-use the definition. The definiton as shown is that included in RFC1918, and that is where the reference to "TCP" comes from. I agree with the point you are making, particularly as people will be reading this draft with transport-layer solutions in mind; I just wanted to explain why "TCP" featured in that paragraph. > >3.1.3 Performance > > > > By multihoming, an enterprise should be able to protect itself from > > performance difficulties between transit providers. > > > > For example, suppose enterprise E obtains transit from transit > > providers T1 and T2, and there is long-term congestion between T1 and > > T2. The multihoming architecture should allow E to ensure that in > > normal operation none of its traffic is carried over the congested > > interconnection T1-T2. > > How is the capability offered in the current multihoming approach, > given that BGP is not sensitive to congestion, short-term or long-term? That capability is provided by the fact that T[i] will apply a higher local preference to the prefixes operated by E that they learn directly from E, rather than those they learn from T[3-i]. That means in normal operation, traffic from T[i] destined for E will never be routed towards T[3-i]. > > A multi-homed enterprise must also be able to distribute inbound > > traffic particular multiple transit providers according to the > ^ > from > > > particular network within their enterprise which is sourcing or > > sinking the traffic. > > How can a network within the enterprise source inbound traffic to that > enterprise via a particular transit provider? "network" here refers to a prefix; an enterprise may advertise more than one prefix to its transit providers. By advertising a particular prefix in different ways to different transit providers (e.g. path prepending, setting provider-specific community strings), the enterprise and change the way in which inbound traffic to that prefix is handled. We were trying to avoid terms with routing connotations in the reqs draft, and unfortunately that has introduced some ambiguity. We certainly need to make sure we define our terms rigourously. > This Performance section needs more elaboration and clarification. > >3.1.4 Policy > > > > A customer may choose to multihome for a variety of policy reasons > > outside technical scope (e.g. cost, acceptable use conditions, etc.) > ^ > the? Mmm. I don't think so -- perhaps s/outside/beyond/ ? > > For example, customer C homed to ISP A may wish to shift traffic of a > > certain class or application, NNTP, for example, to ISP B as matter > > of policy. A new IPv6 multihoming proposal must provide support for > > multihoming for external policy reasons. > > Inbound only? Sure. > Outbound only? Sure. > Both? Sure. > This requirement seems excessive > to me, e.g., if end systems ESP encrypt their traffic, how can the > network recognize NNTP traffic? In current practice, this can be achieved so long as the traffic shifting is accommodated at the IP layer -- i.e. stick all your news servers on one subnet, and advertise that subnet in different ways. This is done in the real world, horrible though it may seem. A common example is in far-flung networks where under-sea cable is expensive, rare and low-latency, and satellite circuits are cheaper, more readily available and high-latency. Shifting non-interactive traffic such as mail and news onto satellite circuits is good for business. If we can't accommodate this kind of thing, there are lots of operators in (apparently) the fastest-growing parts of the network who will not be very happy. > >3.2.2 Impact on Routers > > > > The solution may require changes to IPv6 router implementations, but > > these changes must be either minor, or in the form of logically > > separate functions added to existing functions. > > This is a surprising requirement -- can you elaborate? That's Brian's paragraph -- perhaps he can comment on it? > > The multi-homing solution should allow host or application changes to > > enhance session survivability. > > s/to enhance/if that would enhance/ s/if // :) > >3.2.5 Operations and Management > > > > It must be posssible to monitor and configure the multihoming system. > > Possible for whom? Possible for the operator of the multi-homed enterprise. I think I'm not seeing the ambiguity -- who else could that be read as referring to? > >4. Security Considerations > > > > Multihoming no doubt offers some attractive opportunites for denial > > of service and spoofing attacks. Multihomed sites must be protected > > against such attacks at least as well as single-homed sites. > > I.e., not at all? I have also been harbouring some doubts about that paragraph. I'm glad I'm not alone :) Joe From owner-multi6@ops.ietf.org Tue Aug 7 14:56:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11041 for ; Tue, 7 Aug 2001 14:56:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UC1F-0008q1-00 for multi6-data@psg.com; Tue, 07 Aug 2001 11:55:57 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15UC1E-0008pv-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 11:55:56 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id LAA27987; Tue, 7 Aug 2001 11:55:50 -0700 (PDT) Date: Tue, 7 Aug 2001 11:55:50 -0700 (PDT) From: Ramakrishna Gummadi To: Michel Py cc: Subject: Re: New proposal for Network Layer IPv6 multihoming: MHTP In-Reply-To: <2B81403386729140A3A899A8B39B046403ACE4@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, I read this draft, and my main complaint is that it does not seem to solve the main (and only?) problem with IPv4 multihoming, which is scalability---this document proposes to maintain the MHTP prefixes of *all* multihomed sites, and this means that the same scalability problem arises, whether these prefixes are of fixed or variable length as in IPv4. Imagine the scenario where every home is multihomed---/48 MHTP prefixes are certainly sufficient, but I don't think any router can maintain translation tables for these billions of multi-homed sites (or homes in this case). Other potential problems: 1) As far as I can tell, connection survivability probably becomes worse in this case than with IPv4 because of the way the the source MHTP client tries to discover failed MHTP endpoints--by constant pro-active pings. Apart from the increased traffic due to constant pinging between the source MHTP client and the destination MHTP endpoint, this exposes faiures that would not have been noticed in some cases---for example, currently, an ssh session would survive a transient failure in a router if the connection is idle during the failure, but would not probably survive in MHTP because the multihomed destination router (or MHTP endpoint) would become unavailable to the pings. What happens in these cases is not specified by the draft. 2) How are rendezvous points provisioned and discovered? The draft says a TLA would run them, but questions about scalability, availability and discovery of rendezvous points still remain. 3) Problems acknowledged in the draft itself, which include sub-optimal paths for messages, first-packet latencies, etc. In any case, I see the scalability problem still persisting, and that is my main objection... thanks, ramki From owner-multi6@ops.ietf.org Tue Aug 7 15:49:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11789 for ; Tue, 7 Aug 2001 15:49:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UCqo-000AAo-00 for multi6-data@psg.com; Tue, 07 Aug 2001 12:49:14 -0700 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.31 #1) id 15UCqn-000AA8-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 12:49:13 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA20538; Tue, 7 Aug 2001 20:48:35 +0100 Received: from hursley.ibm.com ([9.29.3.172]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA24580; Tue, 7 Aug 2001 20:48:35 +0100 Message-ID: <3B70472D.266FDF9C@hursley.ibm.com> Date: Tue, 07 Aug 2001 14:53:17 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Steve Deering CC: Ben Black , Vijay Gill , Joe Abley , multi6@ops.ietf.org Subject: Re: comments on requirements draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Steve, Cherry-picking among your comments: ... > >3.1.4 Policy > > > > A customer may choose to multihome for a variety of policy reasons > > outside technical scope (e.g. cost, acceptable use conditions, etc.) > ^ > the? > > > For example, customer C homed to ISP A may wish to shift traffic of a > > certain class or application, NNTP, for example, to ISP B as matter > > of policy. A new IPv6 multihoming proposal must provide support for > > multihoming for external policy reasons. > > Inbound only? Outbound only? Both? This requirement seems excessive > to me, e.g., if end systems ESP encrypt their traffic, how can the > network recognize NNTP traffic? Joe Abley already responded and I agree with him. Like any traffic classification policy, this one would have restricted applicability in the case of ESP traffic. In fact the issues are essentially if not totally identical to those for diffserv classification. If you can't classify for diffserv reasons, you can't classify for multi6 reasons either and default policy will apply. There is nothing special here - multi6 is simply added to the list of modules that look at policy (i.e. a local config table) as part of their decision process. ... > > >3.2.2 Impact on Routers > > > > The solution may require changes to IPv6 router implementations, but > > these changes must be either minor, or in the form of logically > > separate functions added to existing functions. > > This is a surprising requirement -- can you elaborate? You work for a router company so you tell us :-) The intention is to *require* a solution that does not cause router vendors to need to throw away their IPv6 routing engines and start again. IMHO such a solution would have no chance of getting implemented across all routers, and therefore is not something the IETF can endorse. > Also, the > nature and degree of acceptable change would presumably depend on > whether or not the change was required in the data plane (already being > cast in hardware for IPv6 on some routers) or the control plane > (still in software), and perhaps also on how many routers would have > to change, e.g., all routers vs. backbone routers vs. edge routers vs. > enterprise routers. Indeed. Of course not all hardware architectures are so rigid that the data plane is carved in the silicon. > > >3.2.3 Impact on Hosts > > > > The solution must not destroy IPv6 connectivity for a legacy host > > implementing RFC 2373 [5], RFC 2460 [7], RFC 2553 [8] and other basic > > IPv6 specifications current in June 2001. That is to say, if a host > > can work in a single-homed site, it must still be able to work in a > > multihomed site, even if it cannot benefit from multihoming. > > > > It would be compatible with this requirement for such a host to lose > > connectivity if the site's primary ISP connection failed. > > Is the assumption that there's a "primary" ISP always valid? In the sense of providing backwards compatibility, for pre-multi6 hosts, I think it is (even if it is an arbitrary choice among the site's ISPs). > > What about newly-established sessions? You mean can a pre-multi6 host switch to a backup ISP for new sessions? I intended *not* to require that, since that would require today's (BGP-expensive) solution still to be in place. Thus in this respect the pre-multi6 host gets *worse* service from multi6, and there's the incentive to upgrade it. > > > If the solution requires changes to the host stack, these changes > > must be either minor, or in the form of logically separate functions > > added to existing functions. > > This needs more elaboration. As for routers, the intention is to *not* require stack rewrites, which I can tell you are very unlikely to happen. Multi6 needs to be an add-on. I don't know how to say it more clearly. ... > >4. Security Considerations > > > > Multihoming no doubt offers some attractive opportunites for denial > > of service and spoofing attacks. Multihomed sites must be protected > > against such attacks at least as well as single-homed sites. > > I.e., not at all? :-) Well, you write a better security section! Brian From owner-multi6@ops.ietf.org Tue Aug 7 15:57:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11916 for ; Tue, 7 Aug 2001 15:57:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UCzQ-000AQ1-00 for multi6-data@psg.com; Tue, 07 Aug 2001 12:58:08 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15UCzP-000APu-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 12:58:07 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id MAA29101; Tue, 7 Aug 2001 12:58:01 -0700 (PDT) Date: Tue, 7 Aug 2001 12:58:01 -0700 (PDT) From: Ramakrishna Gummadi To: Michel Py cc: Subject: Re: New proposal for Network Layer IPv6 multihoming: MHTP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk I would just like to add that if one is looking into NAT-based solutions, Paul Francis and I have a paper at this year's SIGCOMM conference about such a protocol for dealing with address renumbering and multihoming issues using NATs. It has some elements common with MHTP, and shows how one can do away with out-of-band pings, rendezvous points, etc. The protocol is called IPNL, and the paper is available from: http://www.acm.org/sigcomm/sigcomm2001/p6.html thanks, ramki From owner-multi6@ops.ietf.org Tue Aug 7 16:06:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12018 for ; Tue, 7 Aug 2001 16:06:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UD8W-000Ahl-00 for multi6-data@psg.com; Tue, 07 Aug 2001 13:07:32 -0700 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.31 #1) id 15UD8V-000AgB-00; Tue, 07 Aug 2001 13:07:32 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA13106; Tue, 7 Aug 2001 21:06:57 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA17372; Tue, 7 Aug 2001 21:06:58 +0100 Message-ID: <3B704B57.880A8569@hursley.ibm.com> Date: Tue, 07 Aug 2001 15:11:03 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ben Black CC: Greg Maxwell , Randy Bush , Peter Tattam , multi6@ops.ietf.org Subject: Re: Transport level multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ben Black wrote: > > > > > This working group has pretty much painted themselves into a corner by > > concluding that application level changes for multihoming support are not > > acceptable. > > > > I am part of this working group and I have definitely not concluded this. > I have concluded the exact opposite, and I believe rather strongly that > the reason this situation exists is layer violation (why does the > application > need to know the network and transport addresses?). There is certainly a lot of evidence building up that the multi6 solution will require work at the transport layer; once we have agreed requirements we can be more precise about that conclusion. On the other hand we know that major restructuring of applications isn't going to happen - that's the real world. So if we have to do work in the transport layer, the transport layer is going to have to hide most of it below some sort of socket API. I can't see any reason in principle why that API would have to expose a bunch of addresses, even if it turns out that multi6 requires more than one. A "primary" address per host would be enough to expose to the middleware. Brian From owner-multi6@ops.ietf.org Tue Aug 7 16:22:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12148 for ; Tue, 7 Aug 2001 16:22:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UDN2-000B5v-00 for multi6-data@psg.com; Tue, 07 Aug 2001 13:22:32 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.31 #1) id 15UDN1-000B5o-00; Tue, 07 Aug 2001 13:22:31 -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 QAA06655; Tue, 7 Aug 2001 16:22:16 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id QAA06373; Tue, 7 Aug 2001 16:22:16 -0400 (EDT) Date: Tue, 7 Aug 2001 16:22:15 -0400 (EDT) From: Greg Maxwell To: Brian E Carpenter cc: Ben Black , Randy Bush , Peter Tattam , Subject: Re: Transport level multihoming In-Reply-To: <3B704B57.880A8569@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 7 Aug 2001, Brian E Carpenter wrote: [snip] > On the other hand we know that major restructuring of applications isn't going > to happen - that's the real world. So if we have to do work in the transport > layer, the transport layer is going to have to hide most of it below some > sort of socket API. I can't see any reason in principle why that API > would have to expose a bunch of addresses, even if it turns out that > multi6 requires more than one. A "primary" address per host would be enough > to expose to the middleware. If the primary address is functional at connection setup time, then, yes it could learn the other transports from the remote end. However, what do you do if the primary is down? The only solutions I can think of either require the applications to rotate the address passed to the API, or require the transport to consult DNS (what an ugly kludge and layering violation THAT would be!). From owner-multi6@ops.ietf.org Tue Aug 7 17:29:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12774 for ; Tue, 7 Aug 2001 17:29:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UEPw-000Csa-00 for multi6-data@psg.com; Tue, 07 Aug 2001 14:29: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.31 #1) id 15UEPv-000CrK-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 14:29:35 -0700 Subject: RE: New proposal for Network Layer IPv6 multihoming: MHTP Date: Tue, 7 Aug 2001 14:29:11 -0700 Message-ID: <2B81403386729140A3A899A8B39B046403ACF5@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Thread-Topic: New proposal for Network Layer IPv6 multihoming: MHTP X-Mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Index: AcEfcq1kngGtOl4KTxa5uu1qdNK12AADnHD6 From: "Michel Py" To: "Ramakrishna Gummadi" Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id RAA12774 >> Imagine the scenario where every home is multihomed---/48 >> MHTP prefixes are certainly sufficient, but I don't think any router can >> maintain translation tables for these billions of multi-homed sites (or >> homes in this case). Valid point; three remarks about that: a) The scalability would be improved indeed because the rendezvous points would not process a lot of traffic, so the problem, instead of being size of the routing table aggravated by high traffic, would be size of the routing table only. b) the scalability would be further improved because the routing table would be smaller (it would not contain the single-homed prefixes). c) It might be a few years before we need billions of multihomed prefixes. Current hardware could accomodate a million MHTP prefixes. A million IPv6 multihomed sites? In a while. Maybe only one home out of two is going to be multihomed to two different TLAs, maybe a neighborhood would get a /48 instead of a home, who knows. And by then, wrist watches would have a Gigabyte of ram. >> 1) As far as I can tell, connection survivability probably becomes worse >> in this case than with IPv4 because of the way the >> the source MHTP client tries to discover failed MHTP endpoints--by >> constant pro-active pings. Apart from the increased traffic due to >> constant pinging between the source MHTP client and the destination MHTP >> endpoint,this exposes faiures that would not have been noticed in some >> cases---for example, currently, an ssh session would survive a transient >> failure in a router if the connection is idle during the failure, but >> would not probably survive in MHTP because the multihomed >> destination router (or MHTP endpoint) would become unavailable to the >> pings. What happens in these cases is not specified by the draft. The MHTP endpoint would not become unavailable. - If one of the MHTP translation prefixes fails, the traffic would be switched to another translation block. - If all the translation prefixes fails at the same time, there is not much that any protocol can do. Besides, idle connections would survive because, if any path has become available again during idle time, the first packet in either direction would trigger a new query and be proxied to the rendezvous point. - It would make sense to have two routers with a mechanism such as HSRP to dodge router failures. >> 2) How are rendezvous points provisioned and discovered? The draft says a >> TLA would run them, but questions about scalability, availability and >> discovery of rendezvous points still remain. The discovery part is easy: rendezvous points advertise aggregates to the multihomed space. Multihomed traffic will naturally flow to the one deemed as the closest by the routing protocol. >> In any case, I see the scalability problem still persisting, and that is >> my main objection... Postponing it for 5 or 10 years would be good enough for me. Michel. From owner-multi6@ops.ietf.org Tue Aug 7 18:02:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13163 for ; Tue, 7 Aug 2001 18:02:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UEvb-000Dg2-00 for multi6-data@psg.com; Tue, 07 Aug 2001 15:02:19 -0700 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.31 #1) id 15UEva-000DfX-00; Tue, 07 Aug 2001 15:02:18 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA35182; Tue, 7 Aug 2001 23:01:44 +0100 Received: from hursley.ibm.com ([9.29.3.172]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA40920; Tue, 7 Aug 2001 23:01:41 +0100 Message-ID: <3B70654F.99FA39AC@hursley.ibm.com> Date: Tue, 07 Aug 2001 17:01:51 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Greg Maxwell CC: Ben Black , Randy Bush , Peter Tattam , multi6@ops.ietf.org Subject: Re: Transport level multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greg Maxwell wrote: > > On Tue, 7 Aug 2001, Brian E Carpenter wrote: > > [snip] > > On the other hand we know that major restructuring of applications isn't going > > to happen - that's the real world. So if we have to do work in the transport > > layer, the transport layer is going to have to hide most of it below some > > sort of socket API. I can't see any reason in principle why that API > > would have to expose a bunch of addresses, even if it turns out that > > multi6 requires more than one. A "primary" address per host would be enough > > to expose to the middleware. > > If the primary address is functional at connection setup time, then, yes > it could learn the other transports from the remote end. However, what do > you do if the primary is down? The only solutions I can think of either > require the applications to rotate the address passed to the API, or > require the transport to consult DNS (what an ugly kludge and layering > violation THAT would be!). There is *always* an abstraction layer above which a single handle identifies the other party in a session (and probably no handle at all identifies "this" end of the session). So whatever layer is the highest layer to be aware of N addresses, there is always a layer above that (conceptually at least) that has a single handle for that set of N addresses. All I am saying is that this abstraction layer may just as well be a socket API, and that single handle may just as well be one of the N addresses - and if you do it that way, you minimise the impact on existing apps layer logic. It's probably sloppy to write as I did of a "primary" address being the handle; it's just an arbitrary choice among the N addresses available. It's the one that gethostbyname (equivalent) chooses to return to you; it might conceal a bunch of others from you below the socket API, and use them as needed for multihoming or whatever other cookery it needs to do. Brian From owner-multi6@ops.ietf.org Tue Aug 7 18:22:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13358 for ; Tue, 7 Aug 2001 18:22:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UFFl-000EJy-00 for multi6-data@psg.com; Tue, 07 Aug 2001 15:23:09 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.31 #1) id 15UFFk-000EJq-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 15:23:08 -0700 Received: from yarrow-wls.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f77MMQC00761 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Tue, 7 Aug 2001 18:22:27 -0400 Message-Id: <5.1.0.14.2.20010807181055.03ef2230@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 07 Aug 2001 18:22:26 -0400 To: Brian E Carpenter From: Daniel Senie Subject: Re: Transport level multihoming Cc: multi6@ops.ietf.org In-Reply-To: <3B70654F.99FA39AC@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 06:01 PM 8/7/01, Brian E Carpenter wrote: >Greg Maxwell wrote: > > > > On Tue, 7 Aug 2001, Brian E Carpenter wrote: > > > > [snip] > > > On the other hand we know that major restructuring of applications > isn't going > > > to happen - that's the real world. So if we have to do work in the > transport > > > layer, the transport layer is going to have to hide most of it below some > > > sort of socket API. I can't see any reason in principle why that API > > > would have to expose a bunch of addresses, even if it turns out that > > > multi6 requires more than one. A "primary" address per host would be > enough > > > to expose to the middleware. > > > > If the primary address is functional at connection setup time, then, yes > > it could learn the other transports from the remote end. However, what do > > you do if the primary is down? The only solutions I can think of either > > require the applications to rotate the address passed to the API, or > > require the transport to consult DNS (what an ugly kludge and layering > > violation THAT would be!). > >There is *always* an abstraction layer above which a single handle identifies >the other party in a session (and probably no handle at all identifies >"this" end of the session). So whatever layer is the highest layer to >be aware of N addresses, there is always a layer above that (conceptually >at least) that has a single handle for that set of N addresses. > >All I am saying is that this abstraction layer may just as well be a socket >API, and that single handle may just as well be one of the N addresses - and >if you do it that way, you minimise the impact on existing apps layer logic. > >It's probably sloppy to write as I did of a "primary" address being the >handle; it's just an arbitrary choice among the N addresses available. >It's the one that gethostbyname (equivalent) chooses to return to you; >it might conceal a bunch of others from you below the socket API, >and use them as needed for multihoming or whatever other cookery it >needs to do. What you suggest could work, though the management of that new abstraction layer brings with it some level of trouble. Assuming some clean, fast and reliable mechanism is in place for that, and all applications use the API that automagically uses this capability, the application writers will be blissfully unaware. Diagnostic utilities could bypass that facility and learn what's actually going on. Interesting complications await for firewall vendors, as a single application may wind up with connections going out multiple links from a site if that's what the underlying multihoming stuff decides to do, but that's probably OK. Failover could be a bit messier, but I think the app writers are getting used to having to do reconnects on occasion. Somehow, though all of this I get the same icky feeling I got with the design of IBM's source routing for 802.5 Token Ring. Seems like the answer then was the end stations had more processing power, so pushing all the info out to them was the way to go. Bridges were going to be hopelessly overworked, and so could handle nothing more than reading a few bits on the way by (man, this is starting to sound like MPLS). Well, along came intelligent Ethernet bridges which learned, and Token Ring Source Routing looked pretty bad. It was difficult for people to support and debug, made a total mess of the code in the end stations, and really didn't scale well. I get nervous when folks call for Transport-level multihoming, it comes across as either: "The routers in the core will never be able to handle the problem." (Refer to arguments for MPLS to save the core from overload, since they won't be able to forward at gigabit speeds, and look at present day hardware. Every time we claim hardware won't ever scale to do a thing, we appear to get it wrong). or "We can't come up with a good way to work out this problem, so let's push it up a level and it'll be someone else's problem". I'm not ready to rule out transport-level as a bad idea, nor rule it in as a good idea, but it does give me a bad feeling of deja-vu. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Tue Aug 7 18:48:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13750 for ; Tue, 7 Aug 2001 18:48:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UFeH-000FAC-00 for multi6-data@psg.com; Tue, 07 Aug 2001 15:48:29 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.31 #1) id 15UFeG-000FA6-00; Tue, 07 Aug 2001 15:48:28 -0700 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20526; Tue, 7 Aug 2001 16:48:20 -0600 (MDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id PAA15901; Tue, 7 Aug 2001 15:50:27 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.5) with SMTP id f77MmLs611108; Tue, 7 Aug 2001 15:48:21 -0700 (PDT) Message-Id: <200108072248.f77MmLs611108@jurassic.eng.sun.com> Date: Tue, 7 Aug 2001 15:46:54 -0700 (PDT) From: Mohan Parthasarathy Reply-To: Mohan Parthasarathy Subject: Re: Transport level multihoming To: gmaxwell@martin.fl.us, brian@hursley.ibm.com Cc: ben@layer8.net, randy@psg.com, peter@jazz-1.trumpet.com.au, multi6@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: rUjUTYdCm5xCOHHGG3/Llg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-multi6@ops.ietf.org Precedence: bulk Sometime back there was some discussion on multi-level multihoming scenario while GxSE was being discussed i.e what if your upstream ISP is multi-homed, how does GxSE work in this case ? Doesn't similar constraints apply to any transport level solution ? I am not sure how a transport solution works when one of the upstream ISP's link fails. Isn't this one of the requirements ? thanks -mohan > Date: Tue, 07 Aug 2001 17:01:51 -0500 > From: Brian E Carpenter > X-Accept-Language: en,fr > MIME-Version: 1.0 > To: Greg Maxwell > CC: Ben Black , Randy Bush , Peter Tattam , multi6@ops.ietf.org > Subject: Re: Transport level multihoming > Content-Transfer-Encoding: 7bit > > Greg Maxwell wrote: > > > > On Tue, 7 Aug 2001, Brian E Carpenter wrote: > > > > [snip] > > > On the other hand we know that major restructuring of applications isn't going > > > to happen - that's the real world. So if we have to do work in the transport > > > layer, the transport layer is going to have to hide most of it below some > > > sort of socket API. I can't see any reason in principle why that API > > > would have to expose a bunch of addresses, even if it turns out that > > > multi6 requires more than one. A "primary" address per host would be enough > > > to expose to the middleware. > > > > If the primary address is functional at connection setup time, then, yes > > it could learn the other transports from the remote end. However, what do > > you do if the primary is down? The only solutions I can think of either > > require the applications to rotate the address passed to the API, or > > require the transport to consult DNS (what an ugly kludge and layering > > violation THAT would be!). > > There is *always* an abstraction layer above which a single handle identifies > the other party in a session (and probably no handle at all identifies > "this" end of the session). So whatever layer is the highest layer to > be aware of N addresses, there is always a layer above that (conceptually > at least) that has a single handle for that set of N addresses. > > All I am saying is that this abstraction layer may just as well be a socket > API, and that single handle may just as well be one of the N addresses - and > if you do it that way, you minimise the impact on existing apps layer logic. > > It's probably sloppy to write as I did of a "primary" address being the > handle; it's just an arbitrary choice among the N addresses available. > It's the one that gethostbyname (equivalent) chooses to return to you; > it might conceal a bunch of others from you below the socket API, > and use them as needed for multihoming or whatever other cookery it > needs to do. > > Brian > From owner-multi6@ops.ietf.org Tue Aug 7 20:57:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15182 for ; Tue, 7 Aug 2001 20:57:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UHfC-000IW5-00 for multi6-data@psg.com; Tue, 07 Aug 2001 17:57:34 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15UHfB-000IVz-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 17:57:33 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id RAA05667 for ; Tue, 7 Aug 2001 17:57:32 -0700 (PDT) Date: Tue, 7 Aug 2001 17:57:32 -0700 (PDT) From: Ramakrishna Gummadi To: Subject: Re: Transport level multihoming Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > Doesn't similar constraints apply to any transport level solution ? > I am not sure how a transport solution works when one of the > upstream ISP's link fails. Isn't this one of the requirements ? I don't think that an end-host level solution without address translation can work effectively in a decentralized multi-tier multihoming scenario because the end-hosts' addresses have to be added/deleted/modified whenever a provider adds/deletes/changes its providers. Address translation has to be used, but this will be rendered less effective in the transport level multihoming case because end-hosts will now have to be aware of the final routable addresses so that they can advertise them in the payload, assuming we don't want to change every app at the other end-point to make it aware of multiple addresses. A tunneling (or any network-layer)+translation based solution would not have this problem. Another problem with the transport-level multihoming is that the number of failure modes that can be tolerated in a multi-tier multihoming are decreased. For example, consider the scenario where a site is dually-multihomed, while each of the providers are triply multihomed to three different providers each. The question is---how many addresses do the hosts in the site have? If it is two, then it means that the site can not tolerate failures in four of the providers twice removed from it. If it is six, then it means we are exposing the site to addressing issues not related to it. A tunneling+translation solution solves this problem cleanly by using only two (or as many addresses as there are providers) provider-independent addresses to the site. The site's immediate providers would independently translate the addresses to meet their own load-balancing needs without leaking the site's prefixes. When a failure between the provider and its higher-up is detected, by creating two tunnels between itself and the higher up via the two working ISPs, a provider can ensure connection survivability and can even load-balance failed traffic among the working providers. The tunnels are only one "level" deep, and are transparent to all others, including the original site. thanks, ramki > > thanks > -mohan > > > Date: Tue, 07 Aug 2001 17:01:51 -0500 > > From: Brian E Carpenter > > X-Accept-Language: en,fr > > MIME-Version: 1.0 > > To: Greg Maxwell > > CC: Ben Black , Randy Bush , Peter Tattam > , multi6@ops.ietf.org > > Subject: Re: Transport level multihoming > > Content-Transfer-Encoding: 7bit > > > > Greg Maxwell wrote: > > > > > > On Tue, 7 Aug 2001, Brian E Carpenter wrote: > > > > > > [snip] > > > > On the other hand we know that major restructuring of applications isn't > going > > > > to happen - that's the real world. So if we have to do work in the > transport > > > > layer, the transport layer is going to have to hide most of it below some > > > > sort of socket API. I can't see any reason in principle why that API > > > > would have to expose a bunch of addresses, even if it turns out that > > > > multi6 requires more than one. A "primary" address per host would be > enough > > > > to expose to the middleware. > > > > > > If the primary address is functional at connection setup time, then, yes > > > it could learn the other transports from the remote end. However, what do > > > you do if the primary is down? The only solutions I can think of either > > > require the applications to rotate the address passed to the API, or > > > require the transport to consult DNS (what an ugly kludge and layering > > > violation THAT would be!). > > > > There is *always* an abstraction layer above which a single handle identifies > > the other party in a session (and probably no handle at all identifies > > "this" end of the session). So whatever layer is the highest layer to > > be aware of N addresses, there is always a layer above that (conceptually > > at least) that has a single handle for that set of N addresses. > > > > All I am saying is that this abstraction layer may just as well be a socket > > API, and that single handle may just as well be one of the N addresses - and > > if you do it that way, you minimise the impact on existing apps layer logic. > > > > It's probably sloppy to write as I did of a "primary" address being the > > handle; it's just an arbitrary choice among the N addresses available. > > It's the one that gethostbyname (equivalent) chooses to return to you; > > it might conceal a bunch of others from you below the socket API, > > and use them as needed for multihoming or whatever other cookery it > > needs to do. > > > > Brian > > > > > From owner-multi6@ops.ietf.org Tue Aug 7 21:13:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15295 for ; Tue, 7 Aug 2001 21:13:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UHvJ-000IxQ-00 for multi6-data@psg.com; Tue, 07 Aug 2001 18:14:13 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15UHvH-000IxJ-00; Tue, 07 Aug 2001 18:14:12 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id LAA11792; Wed, 8 Aug 2001 11:13:42 +1000 (EST) Date: Wed, 8 Aug 2001 11:13:41 +1000 (EST) From: Peter Tattam To: Ramakrishna Gummadi cc: Mohan Parthasarathy , gmaxwell@martin.fl.us, brian@hursley.ibm.com, ben@layer8.net, randy@psg.com, multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 7 Aug 2001, Ramakrishna Gummadi wrote: > > Doesn't similar constraints apply to any transport level solution ? > > I am not sure how a transport solution works when one of the > > upstream ISP's link fails. Isn't this one of the requirements ? > > I don't think that an end-host level solution without address > translation can work effectively > in a decentralized multi-tier multihoming scenario because the end-hosts' > addresses have to be added/deleted/modified whenever a provider > adds/deletes/changes its providers. Address translation has to be used, > but this will be rendered less effective in the > transport level multihoming case because end-hosts will now have to be > aware of the final routable addresses so that they can advertise them in > the payload, assuming we don't want to change every app at the other > end-point to make it aware of multiple addresses. > I thought that site renumbering was supposed to deal with this? Bob Hinden had a lot to say on the issue. > A tunneling (or any network-layer)+translation based solution would not > have this problem. > > Another problem with the transport-level multihoming is that > the number of failure modes in multi-tier multihoming are decreased. For > example, consider the scenario where a site is dually-multihomed, while > each of the providers are triply multihomed to three different providers > each. The question how many addresses do the hosts in the site have? If it > is two, then it means that the site can not tolerate failures in four of > the providers twice removed from it. If it is six, then it means we are > exposing the site to addressing issues not related to it. > > A tunneling+translation solution solves this problem cleanly by using only > two (or > as many addresses as there are providers) provider-independent addresses > to the site. The site's immediate providers would independently translate > the addresses to meet their own load-balancing needs without leaking the > site's prefixes. When a failure between the provider and its higher-up > is detected, by creating two tunnels between itself and the higher up via > the two working ISPs, a provider can ensure connection survivability and > can even load-balance failed traffic among the working providers. The > tunnels are only one "leve" deep, and are transparent to all others, > including the original site. > > > thanks, > ramki > Won't a translation solution have the risk of translator box meltdown? i.e. may not scale? 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 Aug 7 21:38:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16411 for ; Tue, 7 Aug 2001 21:38:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UIIw-000Jbe-00 for multi6-data@psg.com; Tue, 07 Aug 2001 18:38:38 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15UIIv-000JbY-00; Tue, 07 Aug 2001 18:38:38 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id LAA19566; Wed, 8 Aug 2001 11:38:13 +1000 (EST) Date: Wed, 8 Aug 2001 11:38:13 +1000 (EST) From: Peter Tattam To: Ramakrishna Gummadi cc: Mohan Parthasarathy , gmaxwell@martin.fl.us, brian@hursley.ibm.com, ben@layer8.net, randy@psg.com, multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 8 Aug 2001, Peter Tattam wrote: > On Tue, 7 Aug 2001, Ramakrishna Gummadi wrote: > > > > Doesn't similar constraints apply to any transport level solution ? > > > I am not sure how a transport solution works when one of the > > > upstream ISP's link fails. Isn't this one of the requirements ? > > > > I don't think that an end-host level solution without address > > translation can work effectively > > in a decentralized multi-tier multihoming scenario because the end-hosts' > > addresses have to be added/deleted/modified whenever a provider > > adds/deletes/changes its providers. Address translation has to be used, > > but this will be rendered less effective in the > > transport level multihoming case because end-hosts will now have to be > > aware of the final routable addresses so that they can advertise them in > > the payload, assuming we don't want to change every app at the other > > end-point to make it aware of multiple addresses. > > > > I thought that site renumbering was supposed to deal with this? Bob Hinden had > a lot to say on the issue. Disregard this comment in this context. I think it relates to another message I was reading. Apologies. ........ > > Peter > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Tue Aug 7 21:58:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16576 for ; Tue, 7 Aug 2001 21:58:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UIdC-000KBb-00 for multi6-data@psg.com; Tue, 07 Aug 2001 18:59:34 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15UIdB-000KBU-00; Tue, 07 Aug 2001 18:59:33 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id SAA06204; Tue, 7 Aug 2001 18:58:35 -0700 (PDT) Date: Tue, 7 Aug 2001 18:58:35 -0700 (PDT) From: Ramakrishna Gummadi To: Peter Tattam cc: Ramakrishna Gummadi , Mohan Parthasarathy , , , , , Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 8 Aug 2001, Peter Tattam wrote: > On Tue, 7 Aug 2001, Ramakrishna Gummadi wrote: > > > > Doesn't similar constraints apply to any transport level solution ? > > > I am not sure how a transport solution works when one of the > > > upstream ISP's link fails. Isn't this one of the requirements ? > > > > I don't think that an end-host level solution without address > > translation can work effectively > > in a decentralized multi-tier multihoming scenario because the end-hosts' > > addresses have to be added/deleted/modified whenever a provider > > adds/deletes/changes its providers. Address translation has to be used, > > but this will be rendered less effective in the > > transport level multihoming case because end-hosts will now have to be > > aware of the final routable addresses so that they can advertise them in > > the payload, assuming we don't want to change every app at the other > > end-point to make it aware of multiple addresses. > > > > I thought that site renumbering was supposed to deal with this? Bob Hinden had > a lot to say on the issue. I think the mechanisms in IPv6 are adequate for sites/hosts that use one address per connection. I don't think they would be adequate if we consider multi-tier multi-homed scenarios that carry all possible addresses in packets. I may be wrong, but this clearly seems to be the case in any transport-level multihoming solution... > > > A tunneling (or any network-layer)+translation based solution would not > > have this problem. > > > > Another problem with the transport-level multihoming is that > > the number of failure modes in multi-tier multihoming are decreased. For > > example, consider the scenario where a site is dually-multihomed, while > > each of the providers are triply multihomed to three different providers > > each. The question how many addresses do the hosts in the site have? If it > > is two, then it means that the site can not tolerate failures in four of > > the providers twice removed from it. If it is six, then it means we are > > exposing the site to addressing issues not related to it. > > > > A tunneling+translation solution solves this problem cleanly by using only > > two (or > > as many addresses as there are providers) provider-independent addresses > > to the site. The site's immediate providers would independently translate > > the addresses to meet their own load-balancing needs without leaking the > > site's prefixes. When a failure between the provider and its higher-up > > is detected, by creating two tunnels between itself and the higher up via > > the two working ISPs, a provider can ensure connection survivability and > > can even load-balance failed traffic among the working providers. The > > tunnels are only one "leve" deep, and are transparent to all others, > > including the original site. > > > > > > thanks, > > ramki > > > > Won't a translation solution have the risk of translator box meltdown? i.e. > may not scale? It is only for the customer's prefixes that a provider has to make translation. The translation can reside in the customer's border router, and needs to contain only entry per site. Secondly, translation is entirely optional. Finally, I think stateless (with regard to packets) translation is not very expensive---already, web switches provide hardware layer-7 (looking at cookies and urls) "virtual ip" services for load-balancing and failover, so a layer 3 translation certainly looks certainaly possible to me. thanks, ramki > > > 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 Aug 7 22:07:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16662 for ; Tue, 7 Aug 2001 22:07:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UIkX-000KOT-00 for multi6-data@psg.com; Tue, 07 Aug 2001 19:07:09 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15UIkW-000KOL-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 19:07:08 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA28578; Wed, 8 Aug 2001 12:07:02 +1000 (EST) Date: Wed, 8 Aug 2001 12:07:02 +1000 (EST) From: Peter Tattam To: Ramakrishna Gummadi cc: multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 7 Aug 2001, Ramakrishna Gummadi wrote: > > Doesn't similar constraints apply to any transport level solution ? > > I am not sure how a transport solution works when one of the > > upstream ISP's link fails. Isn't this one of the requirements ? > > I don't think that an end-host level solution without address > translation can work effectively > in a decentralized multi-tier multihoming scenario because the end-hosts' > addresses have to be added/deleted/modified whenever a provider > adds/deletes/changes its providers. I think I was trying to say was that this seens to me to be the site renumbering scenario. At the Tokyo meeting, this was discussed and the following recommendations considered. 1) renumbering would be infrequent and usually highly coordinated. 2) when renumbering occured there would be considerable overlap where both sets of addresses would be in use at the same time. This is simply an extended multihoming scenario with certain prefixes being deprecated. The overlap should be long enough to allow deprecated addresses to disappear from the network. The issue of management of site renumbering in a multi tier environment does leave open many management questions. One throny issue is that higher tiers would have to inform lower tiers of their intentions and lower tiers would have no choice in the matter in reality. How this is perceived by the wider community is a public relations excercise. The public has grown accustomed to the fallacy that once they get some address space, they sort of own it or at least lease it. The concept of the address space being fluid is going to take a lot of reeducation. I believe a successful solution to multihoming in Ipv6 is to make the address space fluid enough to facilitate renumbering and transport (site) level multihoming but sticky enough that it doesn't all fall apart. The BGP approach takes the address space as a fluid mass and tries to mold it to the current routable topology. The site level approach considers the address space as a skeleton upon which you can apply the flesh of routing. No matter how you shake it, the skeleton is rigid as it is based on relatively static allocation policies. 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 Aug 7 22:18:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16731 for ; Tue, 7 Aug 2001 22:18:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UIw5-000Kj7-00 for multi6-data@psg.com; Tue, 07 Aug 2001 19:19:05 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15UIw3-000Kj1-00; Tue, 07 Aug 2001 19:19:03 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA01085; Wed, 8 Aug 2001 12:17:05 +1000 (EST) Date: Wed, 8 Aug 2001 12:17:05 +1000 (EST) From: Peter Tattam To: Ramakrishna Gummadi cc: Ramakrishna Gummadi , Mohan Parthasarathy , gmaxwell@martin.fl.us, brian@hursley.ibm.com, ben@layer8.net, randy@psg.com, multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 7 Aug 2001, Ramakrishna Gummadi wrote: > > > On Wed, 8 Aug 2001, Peter Tattam wrote: > > > On Tue, 7 Aug 2001, Ramakrishna Gummadi wrote: > > > > > > > > Another problem with the transport-level multihoming is that > > > the number of failure modes in multi-tier multihoming are decreased. For > > > example, consider the scenario where a site is dually-multihomed, while > > > each of the providers are triply multihomed to three different providers > > > each. The question how many addresses do the hosts in the site have? If it > > > is two, then it means that the site can not tolerate failures in four of > > > the providers twice removed from it. If it is six, then it means we are > > > exposing the site to addressing issues not related to it. > > > > > > A tunneling+translation solution solves this problem cleanly by using only > > > two (or > > > as many addresses as there are providers) provider-independent addresses > > > to the site. The site's immediate providers would independently translate > > > the addresses to meet their own load-balancing needs without leaking the > > > site's prefixes. When a failure between the provider and its higher-up > > > is detected, by creating two tunnels between itself and the higher up via > > > the two working ISPs, a provider can ensure connection survivability and > > > can even load-balance failed traffic among the working providers. The > > > tunnels are only one "leve" deep, and are transparent to all others, > > > including the original site. > > > > > > > > > thanks, > > > ramki > > > > > > > Won't a translation solution have the risk of translator box meltdown? i.e. > > may not scale? > > It is only for the customer's prefixes that a provider has to make > translation. The translation can reside in the customer's border router, > and needs to contain only entry per site. Secondly, translation is > entirely optional. Finally, I think stateless (with regard to > packets) translation is not very expensive---already, web switches provide > hardware layer-7 (looking at cookies and urls) "virtual ip" services for > load-balancing and failover, so a layer 3 translation certainly looks > certainaly possible to me. > But it's still another single point of failure. In my experience, such a service unless delivered in a router style high reliability platform is going to be a high risk point of failure. Also the suggestion that it be another box separate from the router means that it adds significant cost to the provider's infrastructure. It will be a specialized piece of equipment and likely to be expensive. Routers are good - they have high utility/cost, manage redundacy well, are general purpose and you normally have more than one of them. 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 Aug 7 22:31:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17334 for ; Tue, 7 Aug 2001 22:31:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UJ8X-000L6I-00 for multi6-data@psg.com; Tue, 07 Aug 2001 19:31:57 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15UJ8W-000L68-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 19:31:56 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id TAA06425; Tue, 7 Aug 2001 19:31:52 -0700 (PDT) Date: Tue, 7 Aug 2001 19:31:52 -0700 (PDT) From: Ramakrishna Gummadi To: Peter Tattam cc: Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > But it's still another single point of failure. In my experience, such a > service unless delivered in a router style high reliability platform is going > to be a high risk point of failure. Also the suggestion that it be another box > separate from the router means that it adds significant cost to the provider's > infrastructure. It will be a specialized piece of equipment and likely to be > expensive. > > Routers are good - they have high utility/cost, manage redundacy well, are > general purpose and you normally have more than one of them. I was suggesting that border routers implement this functionality as part of the multihoming modification. If I am not mistaken, most access routers, cable and dsl boxes already provide this (and more complex stateful translation) functionality for IPv4, although for different reasons ... thanks, ramki > > 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 Aug 7 22:42:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17896 for ; Tue, 7 Aug 2001 22:42:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UJJK-000LQM-00 for multi6-data@psg.com; Tue, 07 Aug 2001 19:43:06 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15UJJK-000LQG-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 19:43:06 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id TAA06484; Tue, 7 Aug 2001 19:43:01 -0700 (PDT) Date: Tue, 7 Aug 2001 19:43:00 -0700 (PDT) From: Ramakrishna Gummadi To: Peter Tattam cc: Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > I think I was trying to say was that this seens to me to be the site > renumbering scenario. At the Tokyo meeting, this was discussed and the > following recommendations considered. > > 1) renumbering would be infrequent and usually highly coordinated. > > 2) when renumbering occured there would be considerable overlap where both sets > of addresses would be in use at the same time. This is simply an extended > multihoming scenario with certain prefixes being deprecated. The overlap > should be long enough to allow deprecated addresses to disappear from the > network. > > The issue of management of site renumbering in a multi tier environment does > leave open many management questions. One throny issue is that higher tiers > would have to inform lower tiers of their intentions and lower tiers would have > no choice in the matter in reality. How this is perceived by the wider > community is a public relations excercise. The public has grown accustomed to > the fallacy that once they get some address space, they sort of own it or at > least lease it. The concept of the address space being fluid is going to take > a lot of reeducation. While I think that renumbering is a technical issue that is non-trivial to remove because it has wide management implications, I am willing to ignore this in this context. But, like I said, it certainly has a great role to play in the amount of redundancy and availability it provides (if an ISP multihomes to three providers while it uses one provider's prefixes for its sites, then I think multihoming is not being used to its fullest potential). The ISP may also be using its connectivity bandwidth suboptimally, which I consider another strong potential problem because the full potential of packet switching is not being realized. > I believe a successful solution to multihoming in Ipv6 is to make the address > space fluid enough to facilitate renumbering and transport (site) level > multihoming but sticky enough that it doesn't all fall apart. > > The BGP approach takes the address space as a fluid mass and tries to mold it > to the current routable topology. > > The site level approach considers the address space as a skeleton upon which > you can apply the flesh of routing. No matter how you shake it, the skeleton > is rigid as it is based on relatively static allocation policies. I am not saying that we should abandon the existing routing architecture. In fact, we would be exploiting its excellent scaling and routing properties. All translated addresses would be providing is a sticky point of reference for a flow around which fault-tolerance through routing, and scalability through aggregation will be achieved. thanks, ramki > 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 Aug 7 23:27:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18139 for ; Tue, 7 Aug 2001 23:27:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UK0D-000MfD-00 for multi6-data@psg.com; Tue, 07 Aug 2001 20:27:25 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15UK0C-000Mew-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 20:27:24 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id UAA06703 for ; Tue, 7 Aug 2001 20:27:23 -0700 (PDT) Date: Tue, 7 Aug 2001 20:27:23 -0700 (PDT) From: Ramakrishna Gummadi To: Subject: Re: comments on requirements draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Peter, Just a thought on the amount of addressing overhead this would involve with transport-level multihoming: assuming each of your customers dual homes with any provider that is triply redundant, this means their network-level header overhead would be 16*3*2=96 bytes. This is not at all a pleasant thought if we consider the fact that the average packet size is about 500 bytes... thanks, ramki > I was at a recent conference in Aus and the issue of Service Level Agreements > was being discussed in a forum panel. Each of three very large > telco's/provider's (by Aus standards anyway) representatives were all highly > confident that they could promise extremely high levels of redundancy and there > was no need to have more than one provider. > > However by the end of the panel discussion and after several war stories were > shared by members of the audience and even one member on the panel, it > was eventually conceded that for an effective SLA, redundancy was crucial, and > in particular to multiple providers. The forum concluded with an independent > consultant's reflection that they always recommended complete redundancy to > their clients especially at the last mile. > > I also find that the further you are away from the core of the internet in your > region, the higher is the risk of things going bang. We are multply homed to 3 > providers even though we are a small ISP, and I have had occusion to depend on > each of them for large outages over the past year. Some outages were > configuration problems in networks, while others were meltdowns in the > providers infrastructure including major cable breaks, and even one > international fibre break. Had it not been for our multihoming, our service > would have been out for a minimum of several hours, and in one worst case > scenario we suffered, 2-3 days. > > This risk of things going wrong being higher at the edge is a curious > observation as it flies in the face of the conventional wisdom that says that > the smaller you are, and further from the core, the less need one should have > for multihoming. I would suggest the converse may actually be true. The > smaller or perhaps more remote a site or network is, the higher is the risk > that the quality of their service is going to be degraded in one way or > another. > > I guess my point is that to maintain any kind of quality of service, a small > provider has to go that extra mile (pardon the pun) and provide a better > service to differentiate their brand from the big providers. One method of > differentiation is redundancy by multihoming, even if the perceived cost may be > high. > > 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 Aug 7 23:30:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18231 for ; Tue, 7 Aug 2001 23:30:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UK3s-000MlG-00 for multi6-data@psg.com; Tue, 07 Aug 2001 20:31:12 -0700 Received: from lox.sandelman.ottawa.on.ca ([192.139.46.2] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UK3r-000MlA-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 20:31:11 -0700 Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id XAA18024 for ; Tue, 7 Aug 2001 23:31:13 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (port-14.ottawa4.achilles.net [209.151.2.113]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f783WAF17843 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 7 Aug 2001 23:32:14 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f783MJS05436 for ; Tue, 7 Aug 2001 23:22:19 -0400 (EDT) Message-Id: <200108080322.f783MJS05436@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: comments on requirements draft In-reply-to: Your message of "Tue, 07 Aug 2001 21:42:38 +1000." <4.3.2.7.2.20010807213754.00ca1ab0@localhost> From: Michael Richardson Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 07 Aug 2001 23:22:19 -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Geoff" == Geoff Huston writes: Geoff> I would tend to suggest that growth in multi-homing is a cost and Geoff> perception issue. If the cost of multi-homing is considered to be Geoff> sufficiently low and the perception of service reliability is also Geoff> sufficiently low then you will see increased activity in Geoff> multi-homing. Increase the perception of reliability, or make As a consumer of multihoming... Small (100 person and less) organizations have it very difficult. The current service reliabilities are just far too low. We can easily consume more than 1 unit of bandwidth (whether that was a 56K, a T1 or now a 10Mb ATM VC), so it makes a lot of sense to buy a second unit from another provider. But, as a small organization we did not get provider independant space when we started (likely private network space, but not always), and ISPs willing to deal with us are either: 1) too small to have the multiple connections 2) too big to care Almost every 100 person organization that I know of with these kinds of needs finds that multihoming is too expensive, but no amount of money gets us good service. We go for ad-hoc solutions: e.g. a pair of web caches with different default routes with ICP between them. The assumption that everything is HTTP often bites here as well... ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO3CwaoqHRg3pndX9AQFJswP+JE7aBwTKjxzMoIXAmVIpDYAKR+MvmqkR zRsycaf0Tl+Ond6wlLxunx5HgQyv4mUiOsS8kxanMO1qZr6EWKu09OAvQjAQ/OWj Sl2GKQFZhcMyKoaY8oVpyQ19t6Ood7qXro1KsJholSwY9i5ZMfwC0MFUpGLvArJf BPWqLVbWmNQ= =Y4cm -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Aug 7 23:36:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18657 for ; Tue, 7 Aug 2001 23:36:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UK9j-000MxD-00 for multi6-data@psg.com; Tue, 07 Aug 2001 20:37:15 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15UK9h-000Mx4-00 for multi6@ops.ietf.org; Tue, 07 Aug 2001 20:37:14 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id NAA20053; Wed, 8 Aug 2001 13:37:08 +1000 (EST) Date: Wed, 8 Aug 2001 13:37:07 +1000 (EST) From: Peter Tattam To: Ramakrishna Gummadi cc: Multi6 Working Group Subject: Re: comments on requirements draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Presuming you are referrring to my preliminary draft. The network level overhead is only require at setup and is cached at either end. Also the set of prefixes is quite compressible as it is actually more like a tree. If one strengthens the distinction between an full address and a routing gook component, some of the concepts start to full into place. I am currently working on an accompanying document which explores the characteristics of transport level multihoming as it relates to my suggested idea. I'm concerned also that the nomenclature (transport level multihoming) doesn't properly convey the nature of the process. I merely used the title that Steve Deering used in his email probe to the list. Peter On Tue, 7 Aug 2001, Ramakrishna Gummadi wrote: > Peter, > Just a thought on the amount of addressing overhead this would > involve with transport-level multihoming: assuming each of your customers > dual homes with any provider that is triply redundant, this means their > network-level header overhead would be 16*3*2=96 bytes. This is not at all > a pleasant thought if we consider the fact that the average packet size is > about 500 bytes... > > thanks, > ramki > > > I was at a recent conference in Aus and the issue of Service Level Agreements > > was being discussed in a forum panel. Each of three very large > > telco's/provider's (by Aus standards anyway) representatives were all highly > > confident that they could promise extremely high levels of redundancy and there > > was no need to have more than one provider. > > > > However by the end of the panel discussion and after several war stories were > > shared by members of the audience and even one member on the panel, it > > was eventually conceded that for an effective SLA, redundancy was crucial, and > > in particular to multiple providers. The forum concluded with an independent > > consultant's reflection that they always recommended complete redundancy to > > their clients especially at the last mile. > > > > I also find that the further you are away from the core of the internet in your > > region, the higher is the risk of things going bang. We are multply homed to 3 > > providers even though we are a small ISP, and I have had occusion to depend on > > each of them for large outages over the past year. Some outages were > > configuration problems in networks, while others were meltdowns in the > > providers infrastructure including major cable breaks, and even one > > international fibre break. Had it not been for our multihoming, our service > > would have been out for a minimum of several hours, and in one worst case > > scenario we suffered, 2-3 days. > > > > This risk of things going wrong being higher at the edge is a curious > > observation as it flies in the face of the conventional wisdom that says that > > the smaller you are, and further from the core, the less need one should have > > for multihoming. I would suggest the converse may actually be true. The > > smaller or perhaps more remote a site or network is, the higher is the risk > > that the quality of their service is going to be degraded in one way or > > another. > > > > I guess my point is that to maintain any kind of quality of service, a small > > provider has to go that extra mile (pardon the pun) and provide a better > > service to differentiate their brand from the big providers. One method of > > differentiation is redundancy by multihoming, even if the perceived cost may be > > high. > > > > Peter > > > > -- > > Peter R. Tattam peter@trumpet.com > > Managing Director, Trumpet Software International Pty Ltd > > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > > > > > > > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Wed Aug 8 11:07:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14467 for ; Wed, 8 Aug 2001 11:07:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UUrg-000HUm-00 for multi6-data@psg.com; Wed, 08 Aug 2001 08:03:20 -0700 Received: from [194.196.110.15] (helo=mail-gw1.hursley.ibm.com) by psg.com with esmtp (Exim 3.31 #1) id 15UUrf-000HUL-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 08:03:19 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA25032; Wed, 8 Aug 2001 16:02:46 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA50432; Wed, 8 Aug 2001 16:02:46 +0100 Message-ID: <3B715566.50772F94@hursley.ibm.com> Date: Wed, 08 Aug 2001 10:06:14 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ramakrishna Gummadi CC: Peter Tattam , multi6@ops.ietf.org Subject: Re: Transport level multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ramakrishna Gummadi wrote: > ... > > > > The site level approach considers the address space as a skeleton upon which > > you can apply the flesh of routing. No matter how you shake it, the skeleton > > is rigid as it is based on relatively static allocation policies. > > I am not saying that we should abandon the existing routing architecture. > In fact, we would be exploiting its excellent scaling and > routing properties. Its what?? Haven't you read draft-iab-bgparch-01.txt? We don't have any scaling left to play with. That's why we are here. > All translated addresses would be providing is a > sticky point of reference for a flow around which fault-tolerance through > routing, and scalability through aggregation will be achieved. We invented IPv6 to avoid the need for address translation and all its attendant problems. The argument for a multi6 solution at transport level is to *deal with* the existence of multiple addresses and precisely to avoid translation. There is an alternative, which is the type of architected address translation implied by 8+8, GSE etc but please let's avoid painting ourselves into a corner that requires both transport layer gymnastics and NAT; that would be a catastrophe. Brian From owner-multi6@ops.ietf.org Wed Aug 8 11:08:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14498 for ; Wed, 8 Aug 2001 11:08:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UUvF-000His-00 for multi6-data@psg.com; Wed, 08 Aug 2001 08:07:01 -0700 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.31 #1) id 15UUvD-000Hex-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 08:07:00 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA25066; Wed, 8 Aug 2001 16:06:26 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA29720; Wed, 8 Aug 2001 16:06:28 +0100 Message-ID: <3B71563E.D0CAB2B3@hursley.ibm.com> Date: Wed, 08 Aug 2001 10:09:50 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Daniel Senie CC: multi6@ops.ietf.org Subject: Re: Transport level multihoming References: <5.1.0.14.2.20010807181055.03ef2230@mail.amaranth.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Daniel, If I could avoid the conclusion that we are forced into transport level gymnastics, I would be delighted. But remember that the scaling arguments are several orders of magnitude worse than in the 802.5 case (potentially many millions of entries in a flat routing table, as opposed to a few thousand for LAN bridging tables.) Brian Daniel Senie wrote: > > At 06:01 PM 8/7/01, Brian E Carpenter wrote: > >Greg Maxwell wrote: > > > > > > On Tue, 7 Aug 2001, Brian E Carpenter wrote: > > > > > > [snip] > > > > On the other hand we know that major restructuring of applications > > isn't going > > > > to happen - that's the real world. So if we have to do work in the > > transport > > > > layer, the transport layer is going to have to hide most of it below some > > > > sort of socket API. I can't see any reason in principle why that API > > > > would have to expose a bunch of addresses, even if it turns out that > > > > multi6 requires more than one. A "primary" address per host would be > > enough > > > > to expose to the middleware. > > > > > > If the primary address is functional at connection setup time, then, yes > > > it could learn the other transports from the remote end. However, what do > > > you do if the primary is down? The only solutions I can think of either > > > require the applications to rotate the address passed to the API, or > > > require the transport to consult DNS (what an ugly kludge and layering > > > violation THAT would be!). > > > >There is *always* an abstraction layer above which a single handle identifies > >the other party in a session (and probably no handle at all identifies > >"this" end of the session). So whatever layer is the highest layer to > >be aware of N addresses, there is always a layer above that (conceptually > >at least) that has a single handle for that set of N addresses. > > > >All I am saying is that this abstraction layer may just as well be a socket > >API, and that single handle may just as well be one of the N addresses - and > >if you do it that way, you minimise the impact on existing apps layer logic. > > > >It's probably sloppy to write as I did of a "primary" address being the > >handle; it's just an arbitrary choice among the N addresses available. > >It's the one that gethostbyname (equivalent) chooses to return to you; > >it might conceal a bunch of others from you below the socket API, > >and use them as needed for multihoming or whatever other cookery it > >needs to do. > > What you suggest could work, though the management of that new abstraction > layer brings with it some level of trouble. Assuming some clean, fast and > reliable mechanism is in place for that, and all applications use the API > that automagically uses this capability, the application writers will be > blissfully unaware. Diagnostic utilities could bypass that facility and > learn what's actually going on. Interesting complications await for > firewall vendors, as a single application may wind up with connections > going out multiple links from a site if that's what the underlying > multihoming stuff decides to do, but that's probably OK. Failover could be > a bit messier, but I think the app writers are getting used to having to do > reconnects on occasion. > > Somehow, though all of this I get the same icky feeling I got with the > design of IBM's source routing for 802.5 Token Ring. Seems like the answer > then was the end stations had more processing power, so pushing all the > info out to them was the way to go. Bridges were going to be hopelessly > overworked, and so could handle nothing more than reading a few bits on the > way by (man, this is starting to sound like MPLS). Well, along came > intelligent Ethernet bridges which learned, and Token Ring Source Routing > looked pretty bad. It was difficult for people to support and debug, made a > total mess of the code in the end stations, and really didn't scale well. > > I get nervous when folks call for Transport-level multihoming, it comes > across as either: > > "The routers in the core will never be able to handle the problem." (Refer > to arguments for MPLS to save the core from overload, since they won't be > able to forward at gigabit speeds, and look at present day hardware. Every > time we claim hardware won't ever scale to do a thing, we appear to get it > wrong). > > or > > "We can't come up with a good way to work out this problem, so let's push > it up a level and it'll be someone else's problem". > > I'm not ready to rule out transport-level as a bad idea, nor rule it in as > a good idea, but it does give me a bad feeling of deja-vu. > ----------------------------------------------------------------- > Daniel Senie dts@senie.com > Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Wed Aug 8 11:35:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15141 for ; Wed, 8 Aug 2001 11:35:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UVLV-000J1K-00 for multi6-data@psg.com; Wed, 08 Aug 2001 08:34:09 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.31 #1) id 15UVLU-000J1E-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 08:34:09 -0700 Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id LAA15612; Wed, 8 Aug 2001 11:33:55 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id LAA24324; Wed, 8 Aug 2001 11:33:53 -0400 (EDT) Date: Wed, 8 Aug 2001 11:33:53 -0400 (EDT) From: Greg Maxwell To: Brian E Carpenter cc: Daniel Senie , Subject: Re: Transport level multihoming In-Reply-To: <3B71563E.D0CAB2B3@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 8 Aug 2001, Brian E Carpenter wrote: > Daniel, > > If I could avoid the conclusion that we are forced into transport level > gymnastics, I would be delighted. But remember that the scaling arguments > are several orders of magnitude worse than in the 802.5 case (potentially > many millions of entries in a flat routing table, as opposed to a few thousand > for LAN bridging tables.) For transport level multi-homing, you'll need a higher level distributed database to keep track of all the address->host mappings. Fortunately, we already have one designed for just that purpose: DNS. Since we don't want to make any application changes (i.e. make it gather multiple addresses from DNS and pass them to the socket API), how about this: We make the existing API a userspace wrapper on an improved API that takes multiple addresses. The resolver will return a bogus IP address which is specific to that boot-session of the host, the socket API wrapper will reconize the bogus address (because they will all be scoped out of a special allocated area), and query the resolver again to retrieve all of the real addresses then call the real API. This would allow us to achieve application compatibility. I don't see why anything more is needed. I'll code up an example of this implementation for a GNU/Linux system once the SCTP TCP-like api support is finished in the Linux kernel SCTP implementation. From owner-multi6@ops.ietf.org Wed Aug 8 12:00:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15865 for ; Wed, 8 Aug 2001 12:00:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UVkr-000KC2-00 for multi6-data@psg.com; Wed, 08 Aug 2001 09:00:21 -0700 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.31 #1) id 15UVkq-000KBt-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 09:00:20 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 08 Aug 2001 09:00:03 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id A541C5F3FEF44FAEA5B12D6E8EF72642 for plus 3 more; Wed, 08 Aug 2001 09:00:02 -0700 Reply-To: From: "Tony Hain" To: "Peter Tattam" , "Ben Black" Cc: "Masataka Ohta" , "Multi6 Working Group" Subject: RE: Transport level multihoming Date: Wed, 8 Aug 2001 17:00:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: 08062515-C9F1489C-AC9E2BEA-16624201 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA15865 Peter Tattam wrote: > Until I get it published via the I-D editor, here's a URL to it. > > http://jazz-1.trumpet.com.au/ipv6-draft/preserve-tcp.txt Maybe I missed something, I have no problem with the address exchange, but how is a host supposed to know which of its addresses the correspondent will be able to reply to? If the prefix required for the SYN/ACK drops after connection establishment, won't the host need to be snooping the routing system to know which of its addresses to use as the source of the next packet? If both hosts are snooping, wouldn't they be in a position to try and bias the end-to-end path by switching the destination address to one on the list provided in the SYN/ACK? Tony From owner-multi6@ops.ietf.org Wed Aug 8 12:15:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16098 for ; Wed, 8 Aug 2001 12:15:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UVyV-000KnF-00 for multi6-data@psg.com; Wed, 08 Aug 2001 09:14:27 -0700 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.31 #1) id 15UVyT-000KmZ-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 09:14:26 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA31754; Wed, 8 Aug 2001 17:13:52 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA30478; Wed, 8 Aug 2001 17:13:53 +0100 Message-ID: <3B71659D.BC72D392@hursley.ibm.com> Date: Wed, 08 Aug 2001 11:15:25 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Greg Maxwell CC: Daniel Senie , multi6@ops.ietf.org Subject: Re: Transport level multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greg Maxwell wrote: > > On Wed, 8 Aug 2001, Brian E Carpenter wrote: > > > Daniel, > > > > If I could avoid the conclusion that we are forced into transport level > > gymnastics, I would be delighted. But remember that the scaling arguments > > are several orders of magnitude worse than in the 802.5 case (potentially > > many millions of entries in a flat routing table, as opposed to a few thousand > > for LAN bridging tables.) > > For transport level multi-homing, you'll need a higher level distributed > database to keep track of all the address->host mappings. Fortunately, we > already have one designed for just that purpose: DNS. > > Since we don't want to make any application changes (i.e. make it gather > multiple addresses from DNS and pass them to the socket API), how about > this: > > We make the existing API a userspace wrapper on an improved API that takes > multiple addresses. The resolver will return a bogus IP address which is > specific to that boot-session of the host, the socket API wrapper will > reconize the bogus address (because they will all be scoped out of a > special allocated area), and query the resolver again to retrieve all of > the real addresses then call the real API. > > This would allow us to achieve application compatibility. > > I don't see why anything more is needed. I'll code up an example of this > implementation for a GNU/Linux system once the SCTP TCP-like api support > is finished in the Linux kernel SCTP implementation. Yes, this is one way to do it (almost identical to the "bump in the API" approach to v4/v6 interworking). I don't see any reason why the IP address returned by the resolver needs to be bogus; surely it can simply be any one of the real IP addresses, which might have some advantages. Brian From owner-multi6@ops.ietf.org Wed Aug 8 12:30:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16453 for ; Wed, 8 Aug 2001 12:30:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UWEb-000La2-00 for multi6-data@psg.com; Wed, 08 Aug 2001 09:31:05 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.31 #1) id 15UWEa-000LZw-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 09:31:04 -0700 Received: from yarrow-wls.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f78GUxC16854 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Wed, 8 Aug 2001 12:30:59 -0400 Message-Id: <5.1.0.14.2.20010808122108.03fb6380@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 08 Aug 2001 12:30:58 -0400 To: Brian E Carpenter From: Daniel Senie Subject: Re: Transport level multihoming Cc: multi6@ops.ietf.org In-Reply-To: <3B71563E.D0CAB2B3@hursley.ibm.com> References: <5.1.0.14.2.20010807181055.03ef2230@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 11:09 AM 8/8/01, Brian E Carpenter wrote: >Daniel, > >If I could avoid the conclusion that we are forced into transport level >gymnastics, I would be delighted. But remember that the scaling arguments >are several orders of magnitude worse than in the 802.5 case (potentially >many millions of entries in a flat routing table, as opposed to a few thousand >for LAN bridging tables.) As I said, I remain open to transport level involvement if there's no other way. The arguments REALLY do remind me of the 802.5 ones. While I agree we are orders of magnitude larger in scope here, we also have significantly improved technology to work with. The reliance on "sky is falling" arguments to justify standards development which at best will take years is what I'm questioning. MPLS was started because of a belief we could never build routers that could handle the massive loads, yet routers CAN handle the loads. Yes, MPLS has other uses now. A good test of the justification for undertaking a standardization effort would be to look back at the point at which a technology is ready for deployment, and see if the initial reasons are still valid. We will not know for some years whether the decisions we make now are the correct ones. I do hope we can find ways to justify ourselves that stand the test of time. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Wed Aug 8 12:42:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16818 for ; Wed, 8 Aug 2001 12:42:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UWPA-000M3q-00 for multi6-data@psg.com; Wed, 08 Aug 2001 09:42:00 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.31 #1) id 15UWP9-000M3j-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 09:41:59 -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 MAA16673; Wed, 8 Aug 2001 12:41:45 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id MAA27893; Wed, 8 Aug 2001 12:41:43 -0400 (EDT) Date: Wed, 8 Aug 2001 12:41:43 -0400 (EDT) From: Greg Maxwell To: Brian E Carpenter cc: Daniel Senie , Subject: Re: Transport level multihoming In-Reply-To: <3B71659D.BC72D392@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 8 Aug 2001, Brian E Carpenter wrote: > Yes, this is one way to do it (almost identical to the "bump in the API" > approach to v4/v6 interworking). I don't see any reason why the IP address > returned by the resolver needs to be bogus; surely it can simply be any one > of the real IP addresses, which might have some advantages. My only reasoning for not using one of the actual IP addresses is that some hosts may advertise a different set of addresses based on application: Consider a single host with two DNS names: ftp.host.company.com = A,B,C,D (where the letters are addresses in different prefixes) www.host.company.com = A,B Why? C,D are high latency satellite links. The host is smart enough to not include the high-latency links in any assotiation binding in it's transport protocol for port 80. However, we don't want remote systems to attempt to initiate across those slow links either. Of course, we could just declare that those kinds of smarts belong to applications that are aware of the transport-level multihoming (in that they pass all the addresses themselves) and go ahead and use one of it's correct IP addresses. This was my reasoning for using bogus identifyers. From owner-multi6@ops.ietf.org Wed Aug 8 12:57:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17151 for ; Wed, 8 Aug 2001 12:57:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UWel-000MrD-00 for multi6-data@psg.com; Wed, 08 Aug 2001 09:58:07 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.31 #1) id 15UWej-000Mqi-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 09:58:06 -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 MAA16919; Wed, 8 Aug 2001 12:57:49 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id MAA28681; Wed, 8 Aug 2001 12:57:46 -0400 (EDT) Date: Wed, 8 Aug 2001 12:57:46 -0400 (EDT) From: Greg Maxwell To: Daniel Senie cc: Brian E Carpenter , Subject: Re: Transport level multihoming In-Reply-To: <5.1.0.14.2.20010808122108.03fb6380@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 8 Aug 2001, Daniel Senie wrote: > As I said, I remain open to transport level involvement if there's no other > way. The arguments REALLY do remind me of the 802.5 ones. While I agree we > are orders of magnitude larger in scope here, we also have significantly > improved technology to work with. The reliance on "sky is falling" > arguments to justify standards development which at best will take years is > what I'm questioning. MPLS was started because of a belief we could never > build routers that could handle the massive loads, yet routers CAN handle > the loads. Yes, MPLS has other uses now. What would be useful is a metric for defining the global computational and storage complexity for transport-level and network-level multihoming. Then we can make a comparison: Only if the global complexity of network-level solution is much less then the transport-level solution could it be an acceptable solution. For example, if we accepted that people could only be multihomed to a single multi-provider (i.e. a provider maintains multiple separate but interconnected networks) so that we could maintain aggregation, this solution would be preferable on a global routing complexity basis to transport-level multihoming. From owner-multi6@ops.ietf.org Wed Aug 8 14:13:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18611 for ; Wed, 8 Aug 2001 14:13:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UXpr-00013t-00 for multi6-data@psg.com; Wed, 08 Aug 2001 11:13:39 -0700 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.31 #1) id 15UXpq-0000ze-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 11:13:39 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA17940; Wed, 8 Aug 2001 19:13:06 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA32536; Wed, 8 Aug 2001 19:13:03 +0100 Message-ID: <3B718097.F2D8CE50@hursley.ibm.com> Date: Wed, 08 Aug 2001 13:10:31 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Greg Maxwell CC: Daniel Senie , multi6@ops.ietf.org Subject: Re: Transport level multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greg Maxwell wrote: > > On Wed, 8 Aug 2001, Brian E Carpenter wrote: > > > Yes, this is one way to do it (almost identical to the "bump in the API" > > approach to v4/v6 interworking). I don't see any reason why the IP address > > returned by the resolver needs to be bogus; surely it can simply be any one > > of the real IP addresses, which might have some advantages. > > My only reasoning for not using one of the actual IP addresses is that > some hosts may advertise a different set of addresses based on application: > > Consider a single host with two DNS names: > > ftp.host.company.com = A,B,C,D (where the letters are addresses in > different prefixes) > www.host.company.com = A,B > > Why? C,D are high latency satellite links. > > The host is smart enough to not include the high-latency links in any > assotiation binding in it's transport protocol for port 80. However, we > don't want remote systems to attempt to initiate across those slow links > either. > > Of course, we could just declare that those kinds of smarts belong to > applications that are aware of the transport-level multihoming (in that > they pass all the addresses themselves) and go ahead and use one of it's > correct IP addresses. Indeed. It's only a binary number after all. > > This was my reasoning for using bogus identifyers. I have a feeling that for diagnosis, using one of the actual values to be found in DNS is probably better - a bogus (locally synthesised) value has no diagnostic value. In any case it's a detail. Brian From owner-multi6@ops.ietf.org Wed Aug 8 18:06:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22399 for ; Wed, 8 Aug 2001 18:06:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UbT5-000CNy-00 for multi6-data@psg.com; Wed, 08 Aug 2001 15:06:23 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.31 #1) id 15UbT4-000CNr-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 15:06:22 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id 310C5870; Thu, 9 Aug 2001 00:06:21 +0200 (CEST) To: multi6@ops.ietf.org Subject: note from the iesg plenary Cc: ahuja@umich.edu, randy@psg.com Message-Id: <20010808220621.310C5870@sean.ebone.net> Date: Thu, 9 Aug 2001 00:06:21 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk it was noted that there has been little attention payed in the ietf to scoped addresses of various types in the ipv6 standard (e.g., link or anycast addresses). for our wg (from me, not from the floor): can these different address varities, when a host uses them, be considered as a form of multiple-address multihoming? likewise, those approaches which change the routing system in some fashion: how can/do they deal with such addressing types? Sean. ps - several questions are coming up and unfortunately i am too slow a typist: how does one choose and forward addresses for anycast objects, how does one deal with sites which are not convex, how does one scope addresses beyond a site boundary. there were others. if someone can identify the questioner from the floor, i would like to invite her to ask the same questions here. as noted, with my other hat, irtf-rr is a reasonable place to ask (not necessarily ipv6-specific) similar questions, but note well that the irtf is *NOT* the ietf, whereas this is. From owner-multi6@ops.ietf.org Wed Aug 8 18:08:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22470 for ; Wed, 8 Aug 2001 18:08:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UbW8-000CXV-00 for multi6-data@psg.com; Wed, 08 Aug 2001 15:09:32 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UbW8-000CXO-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 15:09:32 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UbW5-0001a5-00; Wed, 08 Aug 2001 23:09:29 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: smd@ebone.net (Sean Doran) Cc: multi6@ops.ietf.org Subject: Re: note from the iesg plenary References: <20010808220621.310C5870@sean.ebone.net> Message-Id: Date: Wed, 08 Aug 2001 23:09:29 +0100 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > it was noted that there has been little attention payed in the ietf > to scoped addresses of various types in the ipv6 standard (e.g., link > or anycast addresses). > > for our wg (from me, not from the floor): can these different address > varities, when a host uses them, be considered as a form of > multiple-address multihoming? likewise, those approaches which change the > routing system in some fashion: how can/do they deal with such addressing > types? routing as we know it, does not have sufficient scoping / reachability constraint mechanisms to handle the seeming semantics. randy From owner-multi6@ops.ietf.org Wed Aug 8 18:24:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22811 for ; Wed, 8 Aug 2001 18:24:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ublq-000DNa-00 for multi6-data@psg.com; Wed, 08 Aug 2001 15:25:46 -0700 Received: from sean.ebone.net ([195.158.227.211] ident=postfix) by psg.com with esmtp (Exim 3.31 #1) id 15Ublp-000DN8-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 15:25:45 -0700 Received: by sean.ebone.net (Postfix, from userid 1113) id BFB3986D; Thu, 9 Aug 2001 00:25:43 +0200 (CEST) To: randy@psg.com, smd@ebone.net Subject: Re: note from the iesg plenary Cc: multi6@ops.ietf.org Message-Id: <20010808222543.BFB3986D@sean.ebone.net> Date: Thu, 9 Aug 2001 00:25:43 +0200 (CEST) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Randy - sorry about being administrivial -:) | routing as we know it, does not have sufficient scoping / reachability | constraint mechanisms to handle the seeming semantics. Does that translate to, "this does not need to be in the requirements doc required of the wg", or something stricter? (for example, if a mechanism that we do not know were to arise which allows for both site multihoming AND these semantics, should we give no additional weight to those proposals which specifically incorporate those mechanisms?) speaking for myself ONLY, i think that this needs to be dealt with in the iEtf even though i think the iRtf RRG would accomodate an I* suggestion (however informal) to study these things for ipv6 specifically. my note was intended only to pass along provocative questions which may be interesting and possibly relevant to the folks here, not necessarily to incur extra work for the multi6 wg or ops area. :-) Sean. From owner-multi6@ops.ietf.org Wed Aug 8 18:59:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23299 for ; Wed, 8 Aug 2001 18:59:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UcJ9-000EuB-00 for multi6-data@psg.com; Wed, 08 Aug 2001 16:00:11 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15UcJ9-000Eu0-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 16:00:11 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id PAA21695; Wed, 8 Aug 2001 15:59:25 -0700 (PDT) Date: Wed, 8 Aug 2001 15:59:25 -0700 (PDT) From: Ramakrishna Gummadi To: Brian E Carpenter cc: Subject: Re: Transport level multihoming In-Reply-To: <3B715566.50772F94@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > We invented IPv6 to avoid the need for address translation and all its > attendant problems. The argument for a multi6 solution at transport level > is to *deal with* the existence of multiple addresses and precisely to avoid > translation. There is an alternative, which is the type of architected > address translation implied by 8+8, GSE etc but please let's avoid painting > ourselves into a corner that requires both transport layer gymnastics and NAT; > that would be a catastrophe. I think the question is: should multi6 also deal with provider multihoming? If it should, then address translation like 8+8 would be required because the multi6 requirements draft says that the architecture should provide for policy-based multihoming---if untranslated addresses are used directly by the provider's sites (single- or multi-homed), the site is pretty much dictating the routing, and load-sharing policies. If 8+8 or GSE or some such is used, this would preclude a transport-level or app-level solution because we don't want routers to modify addresses in the payload as well. That leaves us only with network-level solutions. Is there anything wrong in the argument? thanks, ramki From owner-multi6@ops.ietf.org Wed Aug 8 20:38:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24349 for ; Wed, 8 Aug 2001 20:37:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UdqM-000JjM-00 for multi6-data@psg.com; Wed, 08 Aug 2001 17:38:34 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15UdqK-000JjF-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 17:38:33 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id KAA04908; Thu, 9 Aug 2001 10:38:16 +1000 (EST) Date: Thu, 9 Aug 2001 10:38:15 +1000 (EST) From: Peter Tattam To: Tony Hain cc: Ben Black , Masataka Ohta , Multi6 Working Group Subject: RE: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 8 Aug 2001, Tony Hain wrote: > Peter Tattam wrote: > > > Until I get it published via the I-D editor, here's a URL to it. > > > > http://jazz-1.trumpet.com.au/ipv6-draft/preserve-tcp.txt > > Maybe I missed something, I have no problem with the address exchange, but > how is a host supposed to know which of its addresses the correspondent will > be able to reply to? If the prefix required for the SYN/ACK drops after > connection establishment, won't the host need to be snooping the routing > system to know which of its addresses to use as the source of the next > packet? If both hosts are snooping, wouldn't they be in a position to try and > bias the end-to-end path by switching the destination address to one on the > list provided in the SYN/ACK? This is the difficult bit alluded to in the draft. In the BSD implementation, the address switch is based on the TCP retry mechanism (I think after so many retries). It cycles sequentially thorugh the list supplied. This is the tricky bit in the whole idea. Making the first quess (for the SYN exchange) is the hardest. Switching to change addresses is not quite as difficult as the list returned by the peer can be ordered to make the subsequent guesses more accurate. The thesis that accompanies the BSD implementation has an analysis of these aspects. It is worth reading. My next step is to suggest ways that nodes can cache important information regarding the state of forward routing so that it can make the appropriate decisions. It need not be tied to the routing system, just learnt as it goes. > > Tony > > I'm sorry it looks like hand waving. This is new for us all. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Wed Aug 8 20:41:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24412 for ; Wed, 8 Aug 2001 20:40:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Udte-000JvP-00 for multi6-data@psg.com; Wed, 08 Aug 2001 17:41:58 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15Udtd-000JvH-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 17:41:57 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id KAA05674; Thu, 9 Aug 2001 10:41:45 +1000 (EST) Date: Thu, 9 Aug 2001 10:41:45 +1000 (EST) From: Peter Tattam To: Daniel Senie cc: Brian E Carpenter , multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: <5.1.0.14.2.20010808122108.03fb6380@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 8 Aug 2001, Daniel Senie wrote: > At 11:09 AM 8/8/01, Brian E Carpenter wrote: > >Daniel, > > > >If I could avoid the conclusion that we are forced into transport level > >gymnastics, I would be delighted. But remember that the scaling arguments > >are several orders of magnitude worse than in the 802.5 case (potentially > >many millions of entries in a flat routing table, as opposed to a few thousand > >for LAN bridging tables.) > > As I said, I remain open to transport level involvement if there's no other > way. The arguments REALLY do remind me of the 802.5 ones. While I agree we > are orders of magnitude larger in scope here, we also have significantly > improved technology to work with. The reliance on "sky is falling" > arguments to justify standards development which at best will take years is > what I'm questioning. MPLS was started because of a belief we could never > build routers that could handle the massive loads, yet routers CAN handle > the loads. Yes, MPLS has other uses now. > > A good test of the justification for undertaking a standardization effort > would be to look back at the point at which a technology is ready for > deployment, and see if the initial reasons are still valid. That should not invalidate any research done on transport level solution in the mean time. There may be other important spin offs. > > We will not know for some years whether the decisions we make now are the > correct ones. I do hope we can find ways to justify ourselves that stand > the test of time. > ----------------------------------------------------------------- > Daniel Senie dts@senie.com > Amaranth Networks Inc. http://www.amaranth.com > > > Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Wed Aug 8 20:46:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24470 for ; Wed, 8 Aug 2001 20:46:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Udys-000KAJ-00 for multi6-data@psg.com; Wed, 08 Aug 2001 17:47:22 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15Udyq-000KAB-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 17:47:21 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id KAA06864; Thu, 9 Aug 2001 10:47:07 +1000 (EST) Date: Thu, 9 Aug 2001 10:47:07 +1000 (EST) From: Peter Tattam To: Greg Maxwell cc: Daniel Senie , Brian E Carpenter , multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 8 Aug 2001, Greg Maxwell wrote: > On Wed, 8 Aug 2001, Daniel Senie wrote: > > > As I said, I remain open to transport level involvement if there's no other > > way. The arguments REALLY do remind me of the 802.5 ones. While I agree we > > are orders of magnitude larger in scope here, we also have significantly > > improved technology to work with. The reliance on "sky is falling" > > arguments to justify standards development which at best will take years is > > what I'm questioning. MPLS was started because of a belief we could never > > build routers that could handle the massive loads, yet routers CAN handle > > the loads. Yes, MPLS has other uses now. > > What would be useful is a metric for defining the global computational and > storage complexity for transport-level and network-level multihoming. > > Then we can make a comparison: Only if the global complexity of > network-level solution is much less then the transport-level solution > could it be an acceptable solution. > > For example, if we accepted that people could only be multihomed to a > single multi-provider (i.e. a provider maintains multiple separate but > interconnected networks) so that we could maintain aggregation, this > solution would be preferable on a global routing complexity basis to > transport-level multihoming. > It depends if the provider is supplying multiple completely independent paths to the core or not. If what you are implying is that a MH site can only have multiple paths to its parent branch, or only partly up the tree to the core, this may be unnecessarily restrictive, and possibly defeat the purpose of multihoming. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Wed Aug 8 20:58:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24587 for ; Wed, 8 Aug 2001 20:58:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UeAA-000KeK-00 for multi6-data@psg.com; Wed, 08 Aug 2001 17:59:02 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15UeA9-000KeB-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 17:59:01 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id KAA09572; Thu, 9 Aug 2001 10:58:48 +1000 (EST) Date: Thu, 9 Aug 2001 10:58:48 +1000 (EST) From: Peter Tattam To: Greg Maxwell cc: Brian E Carpenter , Daniel Senie , multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 8 Aug 2001, Greg Maxwell wrote: > On Wed, 8 Aug 2001, Brian E Carpenter wrote: > > > Daniel, > > > > If I could avoid the conclusion that we are forced into transport level > > gymnastics, I would be delighted. But remember that the scaling arguments > > are several orders of magnitude worse than in the 802.5 case (potentially > > many millions of entries in a flat routing table, as opposed to a few thousand > > for LAN bridging tables.) > > For transport level multi-homing, you'll need a higher level distributed > database to keep track of all the address->host mappings. Fortunately, we > already have one designed for just that purpose: DNS. Not necessarily. You just need enough address information to hook into the peer. With my idea, any additional addresses can be exchanged at SYN/ACK time. 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 Aug 9 01:24:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02043 for ; Thu, 9 Aug 2001 01:24:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UiJi-0008mz-00 for multi6-data@psg.com; Wed, 08 Aug 2001 22:25:10 -0700 Received: from www.bit-net.com ([208.146.132.4] helo=mail.users.bit-net.com) by psg.com with smtp (Exim 3.31 #1) id 15UiJh-0008mt-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 22:25:09 -0700 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA28257; Thu, 9 Aug 2001 01:24:56 -0400 Date: Thu, 9 Aug 2001 01:24:55 -0400 (EDT) From: Jim Bound To: Brian E Carpenter Cc: Ramakrishna Gummadi , Peter Tattam , multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: <3B715566.50772F94@hursley.ibm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Brian, I am convinced that we can help alleviate the TL issue with SCTP for IPv6. And get it deployed in 2 years (some of us have started shipping it now as product not prototype). Also it is being used for SMS for test UMTS environments now. Also I believe SCTP can be used by small memory footprint devices too for IPv6. Some of us will go look at a shim for AF_SCTP esp for IPv6 so app that does ftp (example app only) can use SCTP without a change in source code. But part of that work is to see the cost and effect to a vendor library and sys call code if it can be done in production manner and not break binary compatibility with IPv4/IPv6 app. Don't know till we try. But I think so. /jim On Wed, 8 Aug 2001, Brian E Carpenter wrote: > Ramakrishna Gummadi wrote: > > > ... > > > > > > The site level approach considers the address space as a skeleton upon which > > > you can apply the flesh of routing. No matter how you shake it, the skeleton > > > is rigid as it is based on relatively static allocation policies. > > > > I am not saying that we should abandon the existing routing architecture. > > In fact, we would be exploiting its excellent scaling and > > routing properties. > > Its what?? Haven't you read draft-iab-bgparch-01.txt? We don't have any > scaling left to play with. That's why we are here. > > > All translated addresses would be providing is a > > sticky point of reference for a flow around which fault-tolerance through > > routing, and scalability through aggregation will be achieved. > > We invented IPv6 to avoid the need for address translation and all its > attendant problems. The argument for a multi6 solution at transport level > is to *deal with* the existence of multiple addresses and precisely to avoid > translation. There is an alternative, which is the type of architected > address translation implied by 8+8, GSE etc but please let's avoid painting > ourselves into a corner that requires both transport layer gymnastics and NAT; > that would be a catastrophe. > > Brian > From owner-multi6@ops.ietf.org Thu Aug 9 01:39:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04282 for ; Thu, 9 Aug 2001 01:39:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UiXx-0009bK-00 for multi6-data@psg.com; Wed, 08 Aug 2001 22:39:53 -0700 Received: from www.bit-net.com ([208.146.132.4] helo=mail.users.bit-net.com) by psg.com with smtp (Exim 3.31 #1) id 15UiXx-0009bE-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 22:39:53 -0700 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA22939; Thu, 9 Aug 2001 01:39:46 -0400 Date: Thu, 9 Aug 2001 01:39:46 -0400 (EDT) From: Jim Bound To: Sean Doran Cc: multi6@ops.ietf.org, ahuja@umich.edu, randy@psg.com Subject: Re: note from the iesg plenary In-Reply-To: <20010808220621.310C5870@sean.ebone.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Sean, If the node knows that the target is onl the link, the site, and global then yes. But a node knowing that is not known except by the interface the packet goes or enters and most do not believe we should try to parse that type of a priori knowledge today because its complex. But if I knew my ISP was global and part of my site and had DNS recs for each address type then if one address was down the other could be used if also true for ISP #2. But if we specify SCTP for example and IPv6 default address selection if this is implemented the end result is the scoping should work for the multihome case. I think one piece of work for someone who knows the ICMPv6 protocol implementation well and router renumbering would be to see if we can define a mechanism to inform an end node that an ISP interface is down would be a good exercise. We would get this with SCTP for free (no response or heartbeat probe) but if the ISP routers were proactive the convergence time for the end node to use another SCTP connection would be useful if lets say 20 times faster than SCTP failover convergence. regards, /jim On Thu, 9 Aug 2001, Sean Doran wrote: > > it was noted that there has been little attention payed in the ietf > to scoped addresses of various types in the ipv6 standard (e.g., link > or anycast addresses). > > for our wg (from me, not from the floor): can these different address > varities, when a host uses them, be considered as a form of multiple-address > multihoming? likewise, those approaches which change the routing system > in some fashion: how can/do they deal with such addressing types? > > Sean. > > ps - several questions are coming up and unfortunately i am too slow a typist: > how does one choose and forward addresses for anycast objects, how does > one deal with sites which are not convex, how does one scope addresses > beyond a site boundary. there were others. if someone can identify > the questioner from the floor, i would like to invite her to ask the > same questions here. as noted, with my other hat, irtf-rr is a reasonable > place to ask (not necessarily ipv6-specific) similar questions, but > note well that the irtf is *NOT* the ietf, whereas this is. > From owner-multi6@ops.ietf.org Thu Aug 9 01:46:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05090 for ; Thu, 9 Aug 2001 01:46:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Uif2-0009va-00 for multi6-data@psg.com; Wed, 08 Aug 2001 22:47:12 -0700 Received: from www.bit-net.com ([208.146.132.4] helo=mail.users.bit-net.com) by psg.com with smtp (Exim 3.31 #1) id 15Uif1-0009vS-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 22:47:11 -0700 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA28380; Thu, 9 Aug 2001 01:47:07 -0400 Date: Thu, 9 Aug 2001 01:47:07 -0400 (EDT) From: Jim Bound To: Randy Bush Cc: Sean Doran , multi6@ops.ietf.org Subject: Re: note from the iesg plenary In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Routing does not but the end node could. Routing would be transparent to the solution. I think the best multi6 proposal would be one that can start alleviating the pain of multihoming in v6 while we work the routing issues in general in the IETF. Also this will help as IPv6 deployment is eminant and will not wait for us to finish. By defining a mechanism like SCTP and use of proper scoping with address selection much of the multihome problem can be solved using the ideas from ohta-san, peter tatam et al and we can get this in our IPv6 production code bases by late 2002 or early 2003. Possbily earlier with code patches with a shim I suggested to Brian on other mail thread. Do not assume the market will wait or can be held up at least in Asia and Europe, and now even certain target markets will begin early adoption in the U.S. and have already although in test phase now. /jim On Wed, 8 Aug 2001, Randy Bush wrote: > > it was noted that there has been little attention payed in the ietf > > to scoped addresses of various types in the ipv6 standard (e.g., link > > or anycast addresses). > > > > for our wg (from me, not from the floor): can these different address > > varities, when a host uses them, be considered as a form of > > multiple-address multihoming? likewise, those approaches which change the > > routing system in some fashion: how can/do they deal with such addressing > > types? > > routing as we know it, does not have sufficient scoping / reachability > constraint mechanisms to handle the seeming semantics. > > randy > From owner-multi6@ops.ietf.org Thu Aug 9 02:21:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15790 for ; Thu, 9 Aug 2001 02:21:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UjCf-000B7v-00 for multi6-data@psg.com; Wed, 08 Aug 2001 23:21:57 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15UjCd-000B7i-00; Wed, 08 Aug 2001 23:21:56 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id QAA26882; Thu, 9 Aug 2001 16:21:45 +1000 (EST) Date: Thu, 9 Aug 2001 16:21:45 +1000 (EST) From: Peter Tattam To: Jim Bound cc: Randy Bush , Sean Doran , multi6@ops.ietf.org Subject: Re: note from the iesg plenary In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 9 Aug 2001, Jim Bound wrote: > Routing does not but the end node could. Routing would be transparent to > the solution. > > I think the best multi6 proposal would be one that can start alleviating > the pain of multihoming in v6 while we work the routing issues in general > in the IETF. Also this will help as IPv6 deployment is eminant and will > not wait for us to finish. By defining a mechanism like SCTP and use of > proper scoping with address selection much of the multihome problem can be > solved using the ideas from ohta-san, peter tatam et al and we can get > this in our IPv6 production code bases by late 2002 or early 2003. > Possbily earlier with code patches with a shim I suggested to Brian on > other mail thread. Do not assume the market will wait or can be held up > at least in Asia and Europe, and now even certain target markets will > begin early adoption in the U.S. and have already although in test phase > now. Are multihoming issues likely to bite any current rollout taking place? If so, there will need to be a temporary workaround in the contingency plan, with a strict stipulation that such a workaround has a limited lifetime. If not, no need to worry. 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 Aug 9 02:55:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16120 for ; Thu, 9 Aug 2001 02:55:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UjjQ-000CRE-00 for multi6-data@psg.com; Wed, 08 Aug 2001 23:55:48 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15UjjN-000CQH-00 for multi6@ops.ietf.org; Wed, 08 Aug 2001 23:55:46 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id QAA05601; Thu, 9 Aug 2001 16:55:36 +1000 (EST) Date: Thu, 9 Aug 2001 16:55:36 +1000 (EST) From: Peter Tattam To: Jim Bound cc: Multi6 Working Group Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk One question. In a transport level multihoming scenario, should two addresses that differ in the lower 64 bits (node address part) be considered independent nodes and handled in the traditional manner with regard to multiple addresses? Why I ask is that the upper 64 bits of all possible full addresses for a particular node that is multihomed have particular properties that would be useful to exploit in transport level multihoming. If the lower 64 bits is not identical between multiple addresses, it could lead to inefficiencies in a compressed representation of the list of IPv6 addresses. It may also be important to some layers of any multihoming protocol to consider that addresses which differ in the lower 64 bits would not being equivalent for the purposes of multihoming. This probably smacks of 8+8 or GSD but I'm just seeking a clarification of what the current accepted wisdom might be. 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 Aug 9 03:09:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16353 for ; Thu, 9 Aug 2001 03:09:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ujx8-000DRe-00 for multi6-data@psg.com; Thu, 09 Aug 2001 00:09:58 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.31 #1) id 15Ujx7-000DRH-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 00:09:57 -0700 From: Masataka Ohta Message-Id: <200108090657.PAA08938@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA08938; Thu, 9 Aug 2001 15:57:24 +0900 Subject: Re: Transport level multihoming In-Reply-To: from Ramakrishna Gummadi at "Aug 8, 2001 03:59:25 pm" To: Ramakrishna Gummadi Date: Thu, 9 Aug 2001 15:57:23 +0859 () CC: Brian E Carpenter , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk ramki; > If 8+8 or GSE or some such is used, this would preclude a transport-level > or app-level > solution because we don't want routers to modify addresses in the payload > as well. That leaves us only with network-level solutions. > > Is there anything wrong in the argument? First, you are confusing 8+8 and GSE. GSE is certainly a variation of 8+8 but is a poor proposal violating the end to end priciple at leastin two ways. Secondly, 8+8 (even including GSE) is a proposal that applicaion/transport identify hosts by lower 8 bytes only. So, its OK for upper layers if some intermediate entity modify upper 8 bytes of source and/or destination address. While modification by routers of GSE is not a good idea, modification of upper 8 bytes of destination addresss can remove tunelling of some protocol. Masataka Ohta From owner-multi6@ops.ietf.org Thu Aug 9 03:33:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16560 for ; Thu, 9 Aug 2001 03:33:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UkKu-000EUL-00 for multi6-data@psg.com; Thu, 09 Aug 2001 00:34:32 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=goose.home.automagic.org) by psg.com with esmtp (Exim 3.31 #1) id 15UkKt-000EUF-00; Thu, 09 Aug 2001 00:34:31 -0700 Received: (from jabley@localhost) by goose.home.automagic.org (8.11.3/8.11.3) id f797XjZ10685; Thu, 9 Aug 2001 03:33:45 -0400 (EDT) Date: Thu, 9 Aug 2001 03:33:45 -0400 From: Joe Abley To: Peter Tattam Cc: Jim Bound , Randy Bush , Sean Doran , multi6@ops.ietf.org Subject: Re: note from the iesg plenary Message-ID: <20010809033345.C9767@goose.home.automagic.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi Peter, On Thu, Aug 09, 2001 at 04:21:45PM +1000, Peter Tattam wrote: > Are multihoming issues likely to bite any current rollout taking place? If so, > there will need to be a temporary workaround in the contingency plan, with a > strict stipulation that such a workaround has a limited lifetime. If not, no > need to worry. There is a requirement that any host that is modified to facilitate multihoming interoperates with other hosts that have not received such modifications (see 3.2.3 in requirements-01). I think that covers both the cases of stack rollout and network rollout (not sure which you were referring to). I believe the former is of greater concern amongst people here than the latter, based on what I have heard so far. Joe From owner-multi6@ops.ietf.org Thu Aug 9 03:37:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16588 for ; Thu, 9 Aug 2001 03:37:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UkOZ-000EaH-00 for multi6-data@psg.com; Thu, 09 Aug 2001 00:38:19 -0700 Received: from soggy131.drizzle.com ([216.162.199.131] helo=tristero.cryptocourier.com) by psg.com with smtp (Exim 3.31 #1) id 15UkOY-000Ea6-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 00:38:18 -0700 Received: (qmail 4653 invoked from network); 9 Aug 2001 07:47:28 -0000 Received: from unknown (HELO ae) (192.168.70.50) by 192.168.70.2 with SMTP; 9 Aug 2001 07:47:28 -0000 From: "Ben Black" To: "Masataka Ohta" , "Ramakrishna Gummadi" Cc: "Brian E Carpenter" , Subject: RE: Transport level multihoming Date: Thu, 9 Aug 2001 00:38:11 -0700 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.2911.0) In-Reply-To: <200108090657.PAA08938@necom830.hpcl.titech.ac.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > GSE is certainly a variation of 8+8 but is a poor proposal > violating the end to end priciple at leastin two ways. > And the currently deployed architecture violates layers by allowing (forcing?) applications to be aware of network and transport addresses. If you eliminate those violations, through whatever method of indirection, the end to end principle can be maintained while allowing a wide variety of solutions to the problem of multihoming. Religious advocacy of a certain world view results in paralysis when faced with problems which challenge that world view. Ben From owner-multi6@ops.ietf.org Thu Aug 9 04:19:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17133 for ; Thu, 9 Aug 2001 04:19:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ul2e-000FxK-00 for multi6-data@psg.com; Thu, 09 Aug 2001 01:19:44 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Ul2e-000FxE-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 01:19:44 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Ul2Q-0001o6-00; Thu, 09 Aug 2001 09:19:30 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Peter Tattam Cc: Jim Bound , Multi6 Working Group Subject: Re: Transport level multihoming References: Message-Id: Date: Thu, 09 Aug 2001 09:19:30 +0100 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In a transport level multihoming scenario, should two addresses that differ > in the lower 64 bits (node address part) be considered independent nodes and > handled in the traditional manner with regard to multiple addresses? > > Why I ask is that the upper 64 bits of all possible full addresses for a > particular node that is multihomed have particular properties that would be > useful to exploit in transport level multihoming. If the lower 64 bits is > not identical between multiple addresses, it could lead to inefficiencies in > a compressed representation of the list of IPv6 addresses. It may also be > important to some layers of any multihoming protocol to consider that > addresses which differ in the lower 64 bits would not being equivalent for > the purposes of multihoming. are you asking if the forwarding look-up is longest match on 64 or 128 bits? i think the latter is mandatory. we do allow allocation of /128s. randy From owner-multi6@ops.ietf.org Thu Aug 9 08:00:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21455 for ; Thu, 9 Aug 2001 08:00:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UoRo-000P0B-00 for multi6-data@psg.com; Thu, 09 Aug 2001 04:57:56 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.31 #1) id 15UoRn-000Oza-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 04:57:55 -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 HAA26824; Thu, 9 Aug 2001 07:57:20 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id HAA06704; Thu, 9 Aug 2001 07:57:17 -0400 (EDT) Date: Thu, 9 Aug 2001 07:57:17 -0400 (EDT) From: Greg Maxwell To: Peter Tattam cc: Brian E Carpenter , Daniel Senie , Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 9 Aug 2001, Peter Tattam wrote: > Not necessarily. You just need enough address information to hook into the > peer. With my idea, any additional addresses can be exchanged at SYN/ACK > time. If you only know one path to reach the other system, what happens if that path goes down before you tack up a connection? From owner-multi6@ops.ietf.org Thu Aug 9 08:22:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21738 for ; Thu, 9 Aug 2001 08:22:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Uoni-0000C7-00 for multi6-data@psg.com; Thu, 09 Aug 2001 05:20:34 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.31 #1) id 15Uoni-0000C1-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 05:20:34 -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 IAA27277; Thu, 9 Aug 2001 08:20:22 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id IAA08376; Thu, 9 Aug 2001 08:20:16 -0400 (EDT) Date: Thu, 9 Aug 2001 08:20:16 -0400 (EDT) From: Greg Maxwell To: Peter Tattam cc: Jim Bound , Multi6 Working Group Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 9 Aug 2001, Peter Tattam wrote: > One question. > > In a transport level multihoming scenario, should two addresses that differ in > the lower 64 bits (node address part) be considered independent nodes and > handled in the traditional manner with regard to multiple addresses? My opinion is that: Hosts should consult DNS to get a list of addresses associated with a name and pass these addresses to the transport API. This set of addresses MAY or MAY NOT be for a single host. The transport protocol will then attempt to connect, most likely by trying to tack up a connection with the first host on the list. The transport level will communicate the rest of the valid addresses for the hosts. This allows DNS to continue to round robin separate hosts, as well as initiating link. > Why I ask is that the upper 64 bits of all possible full addresses for a > particular node that is multihomed have particular properties that would be > useful to exploit in transport level multihoming. If the lower 64 bits is not > identical between multiple addresses, it could lead to inefficiencies in a > compressed representation of the list of IPv6 addresses. It may also be > important to some layers of any multihoming protocol to consider that addresses > which differ in the lower 64 bits would not being equivalent for the purposes > of multihoming. I don't believe using the lower 64 bits to identify the host is the correct solution. For example, what happens when I want to use the 16bits of site networking to perform future-internet-like multihoming inside my own AS (I probably wouldn't do this because of address proliferation and because I wouldn't have scaling problems with traditional multihoming on a local scale)? Or a more obvious example: The 8+8 limits the minimum network that can separately multihome to /64. On the IPv4 internet, people complain that some providers filter their deaggregated /24 announcements! I would have to see some pretty compelling optimizations for a change which would effectively exclude all small institutions from multihoming. From owner-multi6@ops.ietf.org Thu Aug 9 08:40:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21971 for ; Thu, 9 Aug 2001 08:40:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Up7L-0001AV-00 for multi6-data@psg.com; Thu, 09 Aug 2001 05:40:51 -0700 Received: from www.bit-net.com ([208.146.132.4] helo=mail.users.bit-net.com) by psg.com with smtp (Exim 3.31 #1) id 15Up7K-0001AO-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 05:40:51 -0700 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA21778; Thu, 9 Aug 2001 08:40:40 -0400 Date: Thu, 9 Aug 2001 08:40:40 -0400 (EDT) From: Jim Bound To: Peter Tattam Cc: Randy Bush , Sean Doran , multi6@ops.ietf.org Subject: Re: note from the iesg plenary In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi Peter, > On Thu, 9 Aug 2001, Jim Bound wrote: > > > Routing does not but the end node could. Routing would be transparent to > > the solution. > > > > I think the best multi6 proposal would be one that can start alleviating > > the pain of multihoming in v6 while we work the routing issues in general > > in the IETF. Also this will help as IPv6 deployment is eminant and will > > not wait for us to finish. By defining a mechanism like SCTP and use of > > proper scoping with address selection much of the multihome problem can be > > solved using the ideas from ohta-san, peter tatam et al and we can get > > this in our IPv6 production code bases by late 2002 or early 2003. > > Possbily earlier with code patches with a shim I suggested to Brian on > > other mail thread. Do not assume the market will wait or can be held up > > at least in Asia and Europe, and now even certain target markets will > > begin early adoption in the U.S. and have already although in test phase > > now. > > Are multihoming issues likely to bite any current rollout taking place? If so, > there will need to be a temporary workaround in the contingency plan, with a > strict stipulation that such a workaround has a limited lifetime. If not, no > need to worry. > Not for current IPv6 deployment which is for others: 1. Core IPv6 Specs (Base, ND, ICMP, PMTUD, Base API, et al) 2. Core Trans Mech (Base Trans Mech, init 6to4, et al) 3. Core Internet Apps (telnet and friends, netutilities, send-mail, nfs, et al). So what we see are first IPv6/IPv4 nodes are deployed in departments/labs/et al. THen tunnels are used to connect across IPv4 ocean. To keep it short initial deployment will not be seen by ISPs et al hence no IPv6 routing table issues which is why deployment has started and continue and because it will start in Intranets to the Edge and tunnel across the core we have time. Two variable where IPv6 could show up at the core are 802.11b and 3G wireless. But in these cases it will probably not use the traditional Internet still as this will be done by the telco providers not the standard ISPs. It will take them time to see any IPv6 routing pain as they will use the Internet also as IPv4 ocean to tunnel across. Now if someone causes a market of 3 billion IPv6 handhelds well then everything breaks clearly. I don't see that happening at least for two years but it could. Sorry for the diatribe but I wanted to be clear by what I mean IPv6 deployment. I am not speaking of native IPv6 packets across the core backbone of the Internet. I guess it could happen in Asia and Europe and if that happens I fear they will build their own Internet and bypass the U.S. issues I guess ??? As far as product rollout if sctp as one example was used it would adhere to the current multi6 reqs and work with non Ipv6 multihomed nodes or non ipv4 multihomed nodes for transition. My vision of shim to support AF_SCTP (for V6) also would adhere to multi6 req above. Plus once we see this is something we want to experiment with we add that specific test to UNH, ETSI, and Kame Test Suites for IPv6. Most all IPv6 is tested at interop events before we move to production mode. So I think we are OK but the code always is the final truth. /jim From owner-multi6@ops.ietf.org Thu Aug 9 08:50:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22197 for ; Thu, 9 Aug 2001 08:50:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UpDu-0001TT-00 for multi6-data@psg.com; Thu, 09 Aug 2001 05:47:38 -0700 Received: from www.bit-net.com ([208.146.132.4] helo=mail.users.bit-net.com) by psg.com with smtp (Exim 3.31 #1) id 15UpDt-0001TM-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 05:47:37 -0700 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA01731; Thu, 9 Aug 2001 08:47:33 -0400 Date: Thu, 9 Aug 2001 08:47:32 -0400 (EDT) From: Jim Bound To: Peter Tattam Cc: Multi6 Working Group Subject: Re: Transport level multihoming In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi Peter, > One question. > > In a transport level multihoming scenario, should two addresses that differ in > the lower 64 bits (node address part) be considered independent nodes and > handled in the traditional manner with regard to multiple addresses? Good question. I would say yes but SCTP would permit one to treat them as the same node yet different links (interfaces). But I think we need to think hard about the question and all the matrix of answers. > > Why I ask is that the upper 64 bits of all possible full addresses for a > particular node that is multihomed have particular properties that would be > useful to exploit in transport level multihoming. If the lower 64 bits is not > identical between multiple addresses, it could lead to inefficiencies in a > compressed representation of the list of IPv6 addresses. It may also be > important to some layers of any multihoming protocol to consider that addresses > which differ in the lower 64 bits would not being equivalent for the purposes > of multihoming. Hmmmm... I am not sure we can assume this on the lower 64 bits...I need to dream on that...Excellent question. /jim From owner-multi6@ops.ietf.org Thu Aug 9 09:19:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22846 for ; Thu, 9 Aug 2001 09:19:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UpjH-0002wI-00 for multi6-data@psg.com; Thu, 09 Aug 2001 06:20:03 -0700 Received: from melimelo.enst-bretagne.fr ([192.108.115.36]) by psg.com with esmtp (Exim 3.31 #1) id 15UpjG-0002s8-00; Thu, 09 Aug 2001 06:20:02 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f79DIw826095; Thu, 9 Aug 2001 15:18:58 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA08405; Thu, 9 Aug 2001 15:18:57 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f79DIvu77238; Thu, 9 Aug 2001 15:18:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108091318.f79DIvu77238@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: Randy Bush , Sean Doran , multi6@ops.ietf.org Subject: Re: note from the iesg plenary In-reply-to: Your message of Thu, 09 Aug 2001 01:47:07 EDT. Date: Thu, 09 Aug 2001 15:18:57 +0200 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: Possbily earlier with code patches with a shim I suggested to Brian on other mail thread. Do not assume the market will wait or can be held up at least in Asia and Europe, and now even certain target markets will begin early adoption in the U.S. and have already although in test phase now. => I disagree: we know we have no good solution in the current code base. I believe the solution will be in hosts and compatible with the current IPv6, but nodes which will be to used it will get extra functionalities (so we'll like to switch to them). But I agree we have to search and *find* a workable solution ASAP. Something like HIP seems to be promising (I was at the HIP meeting so I should be still biaised :-). Regards Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Thu Aug 9 09:35:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23284 for ; Thu, 9 Aug 2001 09:35:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Upyv-0003aU-00 for multi6-data@psg.com; Thu, 09 Aug 2001 06:36:13 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.31 #1) id 15Upyu-0003Xh-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 06:36:12 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id CB19082671 for ; Thu, 9 Aug 2001 09:35:37 -0400 (EDT) Message-Id: <5.1.0.14.2.20010809092609.009f8e10@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 Aug 2001 09:30:32 -0400 To: multi6@ops.ietf.org From: RJ Atkinson Subject: 64-bit identifiers In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 08:20 09/08/01, Greg Maxwell wrote: >I don't believe using the lower 64 bits to identify the host is the >correct solution. The existence of the Privacy Address Configuration specification for IPv6 means that the low-order 64-bits CAN NOT uniquely identify a host. Prior to then, using the low-order 64-bits (as proposed by original 8+8/GSE) might have worked. That approach cannot work given the current state of specs. Note well that the "privacy extension" spec (sic) is being widely implemented and deployed in end-systems (e.g. Windows XP). Now one could postulate a different identifer that could be used in things like Protocol Control Blocks to bind session state and identity (in lieu of using IP addresses as at present). There would need to be some ability to map to/from that identifier to other kinds of identifiers (perhaps IP Addresses, FQDNs) for this to be deployable, as near as I can tell. There is some work within the IRTF NSRG examining the possibility of adding such identifiers to the Internet Architecture, but that's research not engineering for now. Ran rja@inet.org From owner-multi6@ops.ietf.org Thu Aug 9 11:23:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27000 for ; Thu, 9 Aug 2001 11:23:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Urdy-0008hu-00 for multi6-data@psg.com; Thu, 09 Aug 2001 08:22:42 -0700 Received: from melimelo.enst-bretagne.fr ([192.108.115.36]) by psg.com with esmtp (Exim 3.31 #1) id 15Urdx-0008hf-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 08:22:42 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f79FM7819265; Thu, 9 Aug 2001 17:22:07 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA11191; Thu, 9 Aug 2001 17:22:07 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f79FM6u77678; Thu, 9 Aug 2001 17:22:06 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108091522.f79FM6u77678@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: RJ Atkinson cc: multi6@ops.ietf.org Subject: Re: 64-bit identifiers In-reply-to: Your message of Thu, 09 Aug 2001 09:30:32 EDT. <5.1.0.14.2.20010809092609.009f8e10@10.30.15.2> Date: Thu, 09 Aug 2001 17:22:06 +0200 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: Now one could postulate a different identifer that could be used in things like Protocol Control Blocks to bind session state and identity (in lieu of using IP addresses as at present). There would need to be some ability to map to/from that identifier to other kinds of identifiers (perhaps IP Addresses, FQDNs) for this to be deployable, as near as I can tell. There is some work within the IRTF NSRG examining the possibility of adding such identifiers to the Internet Architecture, but that's research not engineering for now. => this is not fully true: HIP escaped from IRTF and just proposes this kind of new namespace. Regards Francis.Dupont@enst-bretagne.fr PS: the five bullets in the HIP TODO list are: - key exchange - mobility - NAT traversal - home multihoming - site multihoming So HIP is something we have to look at! From owner-multi6@ops.ietf.org Thu Aug 9 11:24:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27046 for ; Thu, 9 Aug 2001 11:24:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UrgJ-0008sq-00 for multi6-data@psg.com; Thu, 09 Aug 2001 08:25:07 -0700 Received: from [194.196.110.15] (helo=mail-gw1.hursley.ibm.com) by psg.com with esmtp (Exim 3.31 #1) id 15UrgI-0008q2-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 08:25:06 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA28766; Thu, 9 Aug 2001 16:24:26 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA27250; Thu, 9 Aug 2001 16:24:25 +0100 Message-ID: <3B72ABDC.F55044AC@hursley.ibm.com> Date: Thu, 09 Aug 2001 10:27:24 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jim Bound CC: Peter Tattam , Multi6 Working Group Subject: Re: Transport level multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Given that privacy considerations will force us to accept pseudo-random lower 64 bits, I don't think we can assume much of anything about those bits from the viewpoint of host identity. Brian Jim Bound wrote: > > Hi Peter, > > > One question. > > > > In a transport level multihoming scenario, should two addresses that differ in > > the lower 64 bits (node address part) be considered independent nodes and > > handled in the traditional manner with regard to multiple addresses? > > Good question. I would say yes but SCTP would permit one to treat them as > the same node yet different links (interfaces). But I think we need to > think hard about the question and all the matrix of answers. > > > > > Why I ask is that the upper 64 bits of all possible full addresses for a > > particular node that is multihomed have particular properties that would be > > useful to exploit in transport level multihoming. If the lower 64 bits is not > > identical between multiple addresses, it could lead to inefficiencies in a > > compressed representation of the list of IPv6 addresses. It may also be > > important to some layers of any multihoming protocol to consider that addresses > > which differ in the lower 64 bits would not being equivalent for the purposes > > of multihoming. > > Hmmmm... I am not sure we can assume this on the lower 64 bits...I need to > dream on that...Excellent question. > > /jim From owner-multi6@ops.ietf.org Thu Aug 9 11:33:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27504 for ; Thu, 9 Aug 2001 11:33:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Urpc-0009LV-00 for multi6-data@psg.com; Thu, 09 Aug 2001 08:34:44 -0700 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.31 #1) id 15Urpb-0009Ko-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 08:34:43 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA20964; Thu, 9 Aug 2001 16:33:29 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA22552; Thu, 9 Aug 2001 16:32:49 +0100 Message-ID: <3B72ADC3.FD779AD8@hursley.ibm.com> Date: Thu, 09 Aug 2001 10:35:31 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ramakrishna Gummadi CC: multi6@ops.ietf.org Subject: Re: Transport level multihoming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ramakrishna Gummadi wrote: > > > We invented IPv6 to avoid the need for address translation and all its > > attendant problems. The argument for a multi6 solution at transport level > > is to *deal with* the existence of multiple addresses and precisely to avoid > > translation. There is an alternative, which is the type of architected > > address translation implied by 8+8, GSE etc but please let's avoid painting > > ourselves into a corner that requires both transport layer gymnastics and NAT; > > that would be a catastrophe. > > I think the question is: should multi6 also deal with provider > multihoming? If it should, then address translation like 8+8 would be > required because the multi6 requirements draft says that the architecture > should provide for policy-based multihoming---if untranslated addresses > are used directly by the provider's sites (single- or multi-homed), the > site is pretty much dictating the routing, and load-sharing policies. I think that's a complete non sequitur. The fact that the multihoming needs to be under policy control doesn't imply anything of the kind. It simply implies that the multihoming decision point must be configurable by some policy management system. It's quite orthogonal to the rest of the solution; the range of possible policies will be determined by the solution. > If 8+8 or GSE or some such is used, this would preclude a transport-level > or app-level > solution because we don't want routers to modify addresses in the payload > as well. That leaves us only with network-level solutions. Yes, I think the 8+8/GSE class of solutions do indeed hide the multihoming decision point from transport and applications, although there might still be some indirect influence via address selection. For example if DNS returns two AAAA records, one of which is a provider-based address like today and the other is a GSEbis address, which one the transport layer chooses to use would have significant effect on multihoming. Brian From owner-multi6@ops.ietf.org Thu Aug 9 11:37:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27685 for ; Thu, 9 Aug 2001 11:37:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Urru-0009S4-00 for multi6-data@psg.com; Thu, 09 Aug 2001 08:37:06 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.31 #1) id 15Urru-0009Pi-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 08:37:06 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA14128; Thu, 9 Aug 2001 08:36:35 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f79FaUW22538; Thu, 9 Aug 2001 08:36:30 -0700 X-mProtect: Thu, 9 Aug 2001 08:36:30 -0700 Nokia Silicon Valley Messaging Protection Received: from host217-33-140-17.ietf.ignite.net (217.33.140.17, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdJ9SpMc; Thu, 09 Aug 2001 08:36:27 PDT Message-Id: <4.3.2.7.2.20010809081326.021d6978@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Aug 2001 08:29:23 -0700 To: RJ Atkinson From: Bob Hinden Subject: Re: 64-bit identifiers Cc: multi6@ops.ietf.org In-Reply-To: <5.1.0.14.2.20010809092609.009f8e10@10.30.15.2> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk Ran, >The existence of the Privacy Address Configuration specification >for IPv6 means that the low-order 64-bits CAN NOT uniquely identify >a host. Prior to then, using the low-order 64-bits (as proposed >by original 8+8/GSE) might have worked. That approach cannot work >given the current state of specs. Note well that the "privacy >extension" spec (sic) is being widely implemented and deployed in >end-systems (e.g. Windows XP). IPv6 nodes can have long lived 64 bit interface identifiers (usually created from hardware tokens) and temporary interface identifiers per RFC3041. Most implementations will support both types as they serve different purposes. There is a bit in the interface identifier that indicates whether it is a global or local identifier. As you point out the global identifiers could be used with an 8+8/GSE type scheme, while the temporary addresses would be harder to use. >Now one could postulate a different identifer that could be used >in things like Protocol Control Blocks to bind session state >and identity (in lieu of using IP addresses as at present). There >would need to be some ability to map to/from that identifier to >other kinds of identifiers (perhaps IP Addresses, FQDNs) for >this to be deployable, as near as I can tell. There is some work >within the IRTF NSRG examining the possibility of adding such >identifiers to the Internet Architecture, but that's research >not engineering for now. Based on our experience with global IPv6 interface identifiers, I suspect that any new scheme using global identifiers will have to deal with privacy issues to allow for anonymous communication. Bob From owner-multi6@ops.ietf.org Thu Aug 9 12:15:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29078 for ; Thu, 9 Aug 2001 12:15:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UsPk-000BOq-00 for multi6-data@psg.com; Thu, 09 Aug 2001 09:12:04 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.31 #1) id 15UsPj-000BOg-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 09:12:03 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id MAA03910; Thu, 9 Aug 2001 12:11:56 -0400 Date: Thu, 9 Aug 2001 12:11:56 -0400 From: "J. Noel Chiappa" Message-Id: <200108091611.MAA03910@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: 64-bit identifiers Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Bob Hinden > I suspect that any new scheme using global identifiers will have to > deal with privacy issues to allow for anonymous communication. If you look at things like HIP, they provide identifiers that are both completely anonymous as well as long-lived and globally unique. It's now understood that the abiltity to provide anonymity is a requirement. Of course, for the really paranoid, they don't like long-lived unique identifiers of any kind, because they allow correlation of activity, which may allow identification through out-of-channel means. So for them, there's *no* identifier scheme that will keep them happy. Kind of hard to work around that requirement.... On the other hand, I have it on good authority that various commercial activities are now tracking people on dialins without use of any kind of identifier (e.g. HTML cookies) - they do it by some sort of activity analysis. So the cost/benefit analysis (pro, utility of long-lived global name, con, security issues) may still tip toward providing them (with a tip of the hat toward the anonymity issue, which is relatively easy to provide, of course). And of course, for the really paranoid, they can just keep creating new ones for every transaction.... :-) Noel From owner-multi6@ops.ietf.org Thu Aug 9 13:30:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00967 for ; Thu, 9 Aug 2001 13:30:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Utdn-000FJt-00 for multi6-data@psg.com; Thu, 09 Aug 2001 10:30:39 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.31 #1) id 15Utdn-000FHQ-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 10:30:39 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id BD32A82671 for ; Thu, 9 Aug 2001 13:30:14 -0400 (EDT) Message-Id: <5.1.0.14.2.20010809132409.01df57e0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 Aug 2001 13:25:08 -0400 To: multi6@ops.ietf.org From: RJ Atkinson Subject: Re: Transport level multihoming In-Reply-To: <3B72ABDC.F55044AC@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 11:27 09/08/01, Brian E Carpenter wrote: >Given that privacy considerations will force us to accept >pseudo-random lower 64 bits, I don't think we can assume >much of anything about those bits from the viewpoint of host identity. Precisely so. And they aren't merely pseudo-random, but instead pseudo-random with *high probability* of many duplicates, at least with the current specifications. Ran From owner-multi6@ops.ietf.org Thu Aug 9 13:34:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01095 for ; Thu, 9 Aug 2001 13:34:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UtiY-000FeX-00 for multi6-data@psg.com; Thu, 09 Aug 2001 10:35:34 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.31 #1) id 15UtiX-000FeE-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 10:35:33 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 3D5AF82671 for ; Thu, 9 Aug 2001 13:35:09 -0400 (EDT) Message-Id: <5.1.0.14.2.20010809132518.01df4860@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 Aug 2001 13:30:02 -0400 To: multi6@ops.ietf.org From: RJ Atkinson Subject: Re: 64-bit identifiers In-Reply-To: <4.3.2.7.2.20010809081326.021d6978@mailhost.iprg.nokia.com> References: <5.1.0.14.2.20010809092609.009f8e10@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 11:29 09/08/01, Bob Hinden wrote: >IPv6 nodes can have long lived 64 bit interface identifiers (usually created from hardware tokens) and temporary interface identifiers per RFC3041. Most implementations will support both types as they serve different purposes. There is a bit in the interface identifier that indicates whether it is a global or local identifier. As you point out the global identifiers could be used with an 8+8/GSE type scheme, while the temporary addresses would be harder to use. Given that WindowsXP is shipping with the local identifier and with a change in the local identifier with every Nth new IP session (for single digit value of N), the majority of the end systems will be using duplicative local-use-only 64-bit identifiers. I'm told that this is controlled only by a registry knob, meaning few will know how to disable the default and fewer will actually make that change. For an 8+8/GSE-like schema, all systems need to have probabilistically unique identifiers. The current privacy spec guarantees that requirement won't be met with the low-order bits of the IPv6 unicast address. This isn't good or bad, just reality. So folks looking into 8+8/GSE-like schemas need to find/create an alternate identity space for things like PCBs. This necessarily adds to the complexity of such approaches versus the prior world order. >>Now one could postulate a different identifer that could be used >>in things like Protocol Control Blocks to bind session state >>and identity (in lieu of using IP addresses as at present). There >>would need to be some ability to map to/from that identifier to >>other kinds of identifiers (perhaps IP Addresses, FQDNs) for >>this to be deployable, as near as I can tell. There is some work >>within the IRTF NSRG examining the possibility of adding such >>identifiers to the Internet Architecture, but that's research >>not engineering for now. > >Based on our experience with global IPv6 interface identifiers, I suspect that any new scheme using global identifiers will have to deal with privacy issues to allow for anonymous communication. As near as I can tell, there is no conflict between a requirement for a probabilistically unique ID and anonymous communication -- it simply needs to be accounted for during design of the identifier to be used. Ran From owner-multi6@ops.ietf.org Thu Aug 9 13:39:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01183 for ; Thu, 9 Aug 2001 13:39:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Utmf-000FmT-00 for multi6-data@psg.com; Thu, 09 Aug 2001 10:39:49 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.31 #1) id 15Utme-000FlC-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 10:39:48 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id BE92A82671 for ; Thu, 9 Aug 2001 13:39:17 -0400 (EDT) Message-Id: <5.1.0.14.2.20010809133053.01df3a20@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 Aug 2001 13:34:11 -0400 To: multi6@ops.ietf.org From: RJ Atkinson Subject: Re: 64-bit identifiers & traffic analysis In-Reply-To: <200108091611.MAA03910@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 12:11 09/08/01, J. Noel Chiappa wrote: >On the other hand, I have it on good authority that various >commercial activities are now tracking people on dialins without >use of any kind of identifier (e.g. HTML cookies) - they do it >by some sort of activity analysis. So the cost/benefit analysis >(pro, utility of long-lived global name, con, security issues) >may still tip toward providing them (with a tip of the hat >toward the anonymity issue, which is relatively easy to provide, >of course). Quite so. A number of commercial web firms have hired folks who really understand traffic analysis techniques. These are now reasonably widely deployed to track web users/uses from at least 2 commercial firms that I'm aware of. Many of the "privacy advocates" don't seem to grasp that the original IPv6 use of the MAC in the low-order bits wasn't the big privacy threat -- traffic analysis has always been the bigger threat and the IPv6 spec change (though needed to pacify those "advocates") can't actually resolve that privacy issue. The world seems like a complicated place these days...(sigh). Ran rja@inet.org From owner-multi6@ops.ietf.org Thu Aug 9 19:12:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07173 for ; Thu, 9 Aug 2001 19:12:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Uyxf-0007rK-00 for multi6-data@psg.com; Thu, 09 Aug 2001 16:11:31 -0700 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by psg.com with esmtp (Exim 3.31 #1) id 15Uyxf-0007qL-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 16:11:31 -0700 Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f79NBBJ16651; Thu, 9 Aug 2001 16:11:11 -0700 (PDT) Received: from [144.254.46.241] (ams-vpdn-client-240.cisco.com [144.254.46.241]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ABC72307; Thu, 9 Aug 2001 16:10:50 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <5.1.0.14.2.20010809132518.01df4860@10.30.15.2> References: <5.1.0.14.2.20010809092609.009f8e10@10.30.15.2> <5.1.0.14.2.20010809132518.01df4860@10.30.15.2> Date: Thu, 9 Aug 2001 16:10:40 -0700 To: RJ Atkinson From: Steve Deering Subject: Re: 64-bit identifiers Cc: multi6@ops.ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 1:30 PM -0400 8/9/01, RJ Atkinson wrote: >For an 8+8/GSE-like schema, all systems need to have probabilistically >unique identifiers. The current privacy spec guarantees that requirement >won't be met with the low-order bits of the IPv6 unicast address. The low-order 64 bits of an IPv6 "privacy" address *is* probabilistically unique, given that it's a pseudo-randomly-generated 64-bit number. How low does the probability of collision have to be for your purposes? >This isn't good or bad, just reality. So folks looking into >8+8/GSE-like schemas need to find/create an alternate identity space >for things like PCBs. Or find/create an alternate locator space (e.g., in an encapsulating IPv6 or other kind of header), and treat the 128-bit end-to-end IPv6 address as the globally-unique identifier. Steve From owner-multi6@ops.ietf.org Thu Aug 9 19:37:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07581 for ; Thu, 9 Aug 2001 19:37:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UzNR-0009Vw-00 for multi6-data@psg.com; Thu, 09 Aug 2001 16:38:09 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.31 #1) id 15UzNQ-0009UF-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 16:38:09 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 8BEB182671 for ; Thu, 9 Aug 2001 19:37:35 -0400 (EDT) Message-Id: <5.1.0.14.2.20010809192231.00a3b1a0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 Aug 2001 19:32:27 -0400 To: multi6@ops.ietf.org From: RJ Atkinson Subject: Re: 64-bit identifiers In-Reply-To: References: <5.1.0.14.2.20010809132518.01df4860@10.30.15.2> <5.1.0.14.2.20010809092609.009f8e10@10.30.15.2> <5.1.0.14.2.20010809132518.01df4860@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 19:10 09/08/01, you wrote: >The low-order 64 bits of an IPv6 "privacy" address *is* probabilistically >unique, given that it's a pseudo-randomly-generated 64-bit number. We disagree on the math here. My analysis, based in part on discussions with some folks who have running code for hosts, is that the low-order bits in the "privacy" case will probably collide frequently. In particular, approaches that use the MAC of the NIC card as seed will usually generate visibly more collisions than those that start with an appropriate number of Heisenberg-quality random bits (RFC-1750). The former appears to be a common approach, the latter very uncommon. Along similar lines, a common issue with IPsec implementations is that most folks don't understand randomness issues and how to implement them properly (despite RFC-1750's specific advice). As I noted earlier, this isn't a criticism or anything necessarily bad, it is merely the reality of the situation we have on the ground. Folks need to design accordingly. >How low does the probability of collision have to be for your purposes? Very low. Not zero. For example, one could live with collisions with the same frequency that one would happen to get two different NIC cards with the same burned-in MAC address (e.g. due to factory error). Ran rja@inet.org From owner-multi6@ops.ietf.org Thu Aug 9 22:06:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09814 for ; Thu, 9 Aug 2001 22:06:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V1gx-000H7b-00 for multi6-data@psg.com; Thu, 09 Aug 2001 19:06:27 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15V1gw-000H7V-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 19:06:26 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA20530; Fri, 10 Aug 2001 12:06:12 +1000 (EST) Date: Fri, 10 Aug 2001 12:06:11 +1000 (EST) From: Peter Tattam To: Greg Maxwell cc: Jim Bound , Multi6 Working Group Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 9 Aug 2001, Greg Maxwell wrote: > On Thu, 9 Aug 2001, Peter Tattam wrote: > > > One question. > > > > In a transport level multihoming scenario, should two addresses that differ in > > the lower 64 bits (node address part) be considered independent nodes and > > handled in the traditional manner with regard to multiple addresses? > > My opinion is that: > > Hosts should consult DNS to get a list of addresses associated with a name > and pass these addresses to the transport API. This set of addresses MAY > or MAY NOT be for a single host. > > The transport protocol will then attempt to connect, most likely by trying > to tack up a connection with the first host on the list. The transport > level will communicate the rest of the valid addresses for the hosts. > > This allows DNS to continue to round robin separate hosts, as well as > initiating link. > > > Why I ask is that the upper 64 bits of all possible full addresses for a > > particular node that is multihomed have particular properties that would be > > useful to exploit in transport level multihoming. If the lower 64 bits is not > > identical between multiple addresses, it could lead to inefficiencies in a > > compressed representation of the list of IPv6 addresses. It may also be > > important to some layers of any multihoming protocol to consider that addresses > > which differ in the lower 64 bits would not being equivalent for the purposes > > of multihoming. > > I don't believe using the lower 64 bits to identify the host is the > correct solution. For example, what happens when I want to use the > 16bits of site networking to perform future-internet-like multihoming > inside my own AS (I probably wouldn't do this because of address > proliferation and because I wouldn't have scaling problems with > traditional multihoming on a local scale)? > > Or a more obvious example: The 8+8 limits the minimum network that can > separately multihome to /64. On the IPv4 internet, people complain that > some providers filter their deaggregated /24 announcements! > > I would have to see some pretty compelling optimizations for a change > which would effectively exclude all small institutions from multihoming. > > > I am not precluding this. Perhaps I should expand the argument to relax the restriction on the 64 bit boundary and say that if a site is multihomed with N upper bits, can we consider that if the lower 128-N bits are the same, they can be considered the same node address. Anything else is another address. 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 Aug 9 22:09:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09877 for ; Thu, 9 Aug 2001 22:09:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V1ke-000HJd-00 for multi6-data@psg.com; Thu, 09 Aug 2001 19:10:16 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15V1kd-000HJX-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 19:10:15 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA20793; Fri, 10 Aug 2001 12:09:57 +1000 (EST) Date: Fri, 10 Aug 2001 12:09:57 +1000 (EST) From: Peter Tattam To: RJ Atkinson cc: multi6@ops.ietf.org Subject: Re: 64-bit identifiers In-Reply-To: <5.1.0.14.2.20010809092609.009f8e10@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk I am not talking about identifiying hosts. A host may have more than one address per interface and be chosen arbitrarily. I am merely referring to the identity properties of the lower 128-N bits (where N is typically 64) for the lifetime of a connection. Peter On Thu, 9 Aug 2001, RJ Atkinson wrote: > At 08:20 09/08/01, Greg Maxwell wrote: > >I don't believe using the lower 64 bits to identify the host is the > >correct solution. > > The existence of the Privacy Address Configuration specification > for IPv6 means that the low-order 64-bits CAN NOT uniquely identify > a host. Prior to then, using the low-order 64-bits (as proposed > by original 8+8/GSE) might have worked. That approach cannot work > given the current state of specs. Note well that the "privacy > extension" spec (sic) is being widely implemented and deployed in > end-systems (e.g. Windows XP). > > Now one could postulate a different identifer that could be used > in things like Protocol Control Blocks to bind session state > and identity (in lieu of using IP addresses as at present). There > would need to be some ability to map to/from that identifier to > other kinds of identifiers (perhaps IP Addresses, FQDNs) for > this to be deployable, as near as I can tell. There is some work > within the IRTF NSRG examining the possibility of adding such > identifiers to the Internet Architecture, but that's research > not engineering for now. > > Ran > rja@inet.org > > > > -- 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 Aug 9 22:15:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09924 for ; Thu, 9 Aug 2001 22:15:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V1r0-000HfR-00 for multi6-data@psg.com; Thu, 09 Aug 2001 19:16:50 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15V1qy-000HfK-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 19:16:49 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA22864; Fri, 10 Aug 2001 12:16:39 +1000 (EST) Date: Fri, 10 Aug 2001 12:16:38 +1000 (EST) From: Peter Tattam To: Bob Hinden cc: RJ Atkinson , multi6@ops.ietf.org Subject: Re: 64-bit identifiers In-Reply-To: <4.3.2.7.2.20010809081326.021d6978@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk I was attempting to only referr to the short lived identity properties of such identifiers for the purposes of multihoming over the lifetime of a connection. The privacy debate, while important, should not necessarily be relevant to the discussion I was attempting to promote. Peter On Thu, 9 Aug 2001, Bob Hinden wrote: > Ran, > > >The existence of the Privacy Address Configuration specification > >for IPv6 means that the low-order 64-bits CAN NOT uniquely identify > >a host. Prior to then, using the low-order 64-bits (as proposed > >by original 8+8/GSE) might have worked. That approach cannot work > >given the current state of specs. Note well that the "privacy > >extension" spec (sic) is being widely implemented and deployed in > >end-systems (e.g. Windows XP). > > IPv6 nodes can have long lived 64 bit interface identifiers (usually > created from hardware tokens) and temporary interface identifiers per > RFC3041. Most implementations will support both types as they serve > different purposes. There is a bit in the interface identifier that > indicates whether it is a global or local identifier. As you point out the > global identifiers could be used with an 8+8/GSE type scheme, while the > temporary addresses would be harder to use. > > >Now one could postulate a different identifer that could be used > >in things like Protocol Control Blocks to bind session state > >and identity (in lieu of using IP addresses as at present). There > >would need to be some ability to map to/from that identifier to > >other kinds of identifiers (perhaps IP Addresses, FQDNs) for > >this to be deployable, as near as I can tell. There is some work > >within the IRTF NSRG examining the possibility of adding such > >identifiers to the Internet Architecture, but that's research > >not engineering for now. > > Based on our experience with global IPv6 interface identifiers, I suspect > that any new scheme using global identifiers will have to deal with privacy > issues to allow for anonymous communication. > > Bob > > > > -- 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 Aug 9 22:17:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09944 for ; Thu, 9 Aug 2001 22:17:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V1sF-000Hnf-00 for multi6-data@psg.com; Thu, 09 Aug 2001 19:18:07 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15V1sD-000HnM-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 19:18:06 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA22990; Fri, 10 Aug 2001 12:17:59 +1000 (EST) Date: Fri, 10 Aug 2001 12:17:59 +1000 (EST) From: Peter Tattam To: RJ Atkinson cc: multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: <5.1.0.14.2.20010809132409.01df57e0@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 9 Aug 2001, RJ Atkinson wrote: > At 11:27 09/08/01, Brian E Carpenter wrote: > >Given that privacy considerations will force us to accept > >pseudo-random lower 64 bits, I don't think we can assume > >much of anything about those bits from the viewpoint of host identity. > > Precisely so. And they aren't merely pseudo-random, but > instead pseudo-random with *high probability* of many duplicates, > at least with the current specifications. > > Ran > > > Let us hope that duplicate discovery works properly then :) 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 Aug 9 22:43:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11090 for ; Thu, 9 Aug 2001 22:43:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V2HD-000JBX-00 for multi6-data@psg.com; Thu, 09 Aug 2001 19:43:55 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15V2HB-000JAk-00; Thu, 09 Aug 2001 19:43:54 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA29169; Fri, 10 Aug 2001 12:43:50 +1000 (EST) Date: Fri, 10 Aug 2001 12:43:50 +1000 (EST) From: Peter Tattam To: Randy Bush cc: Jim Bound , Multi6 Working Group Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 9 Aug 2001, Randy Bush wrote: > > In a transport level multihoming scenario, should two addresses that differ > > in the lower 64 bits (node address part) be considered independent nodes and > > handled in the traditional manner with regard to multiple addresses? > > > > Why I ask is that the upper 64 bits of all possible full addresses for a > > particular node that is multihomed have particular properties that would be > > useful to exploit in transport level multihoming. If the lower 64 bits is > > not identical between multiple addresses, it could lead to inefficiencies in > > a compressed representation of the list of IPv6 addresses. It may also be > > important to some layers of any multihoming protocol to consider that > > addresses which differ in the lower 64 bits would not being equivalent for > > the purposes of multihoming. > > are you asking if the forwarding look-up is longest match on 64 or 128 bits? > i think the latter is mandatory. we do allow allocation of /128s. No, I'm not. See other references. The main relevance is towards efficient representation of lists of multihomed addresses. Having the last 128-N bits of address identical between items in that list may be important. > > randy > > 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 Aug 9 22:45:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11113 for ; Thu, 9 Aug 2001 22:45:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V2JY-000JKZ-00 for multi6-data@psg.com; Thu, 09 Aug 2001 19:46:20 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15V2JW-000JJf-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 19:46:19 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA29668; Fri, 10 Aug 2001 12:45:49 +1000 (EST) Date: Fri, 10 Aug 2001 12:45:48 +1000 (EST) From: Peter Tattam To: Greg Maxwell cc: Brian E Carpenter , Daniel Senie , multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 9 Aug 2001, Greg Maxwell wrote: > On Thu, 9 Aug 2001, Peter Tattam wrote: > > > Not necessarily. You just need enough address information to hook into the > > peer. With my idea, any additional addresses can be exchanged at SYN/ACK > > time. > > If you only know one path to reach the other system, what happens if that > path goes down before you tack up a connection? > > > It would be foolhardy to expect that such a scenario work well. I would suggest "sufficient" information for a connection to be visible at the time of the exchange. The lists need not be identical, but in practice may be. 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 Aug 9 22:48:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11139 for ; Thu, 9 Aug 2001 22:48:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V2N1-000JUe-00 for multi6-data@psg.com; Thu, 09 Aug 2001 19:49:55 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15V2N0-000JU6-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 19:49:54 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA29986; Fri, 10 Aug 2001 12:49:47 +1000 (EST) Date: Fri, 10 Aug 2001 12:49:47 +1000 (EST) From: Peter Tattam To: RJ Atkinson cc: multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 10 Aug 2001, Peter Tattam wrote: > On Thu, 9 Aug 2001, RJ Atkinson wrote: > > > At 11:27 09/08/01, Brian E Carpenter wrote: > > >Given that privacy considerations will force us to accept > > >pseudo-random lower 64 bits, I don't think we can assume > > >much of anything about those bits from the viewpoint of host identity. > > > > Precisely so. And they aren't merely pseudo-random, but > > instead pseudo-random with *high probability* of many duplicates, > > at least with the current specifications. > > > > Ran > > > > > > > > Let us hope that duplicate discovery works properly then :) > > Peter The issue of duplicates rings an alarm bell with me. Duplicate detection is likely to be complicated by a transport layer solution to multihoming as each multihomed address will require DAD. Should a unique site level address guarantee no duplicates on all other prefixes? Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Thu Aug 9 23:18:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11368 for ; Thu, 9 Aug 2001 23:18:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V2p5-000L8M-00 for multi6-data@psg.com; Thu, 09 Aug 2001 20:18:55 -0700 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.31 #1) id 15V2p4-000L7c-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 20:18:54 -0700 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id NAA06866 for ; Fri, 10 Aug 2001 13:18:51 +1000 (EST) Date: Fri, 10 Aug 2001 13:18:51 +1000 (EST) From: Peter Tattam To: Multi6 Working Group Subject: ICMP Unreachable messages. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk I know this has probably come up many times before. How much can one depend on the reliability of unreachable network messages. Some issues. 1) lost packets (bad guy in the middle, router misconfiguration, inappropriate adminstration) 2) modified packets (bad guy in middle) 3) injected packets (bad guy anywhere) 4) excessive packets (overload situation, bad guy anywhere) Since we already have a stipulation that ICMP MTU size exceeded packets need to be forwarded for MTU discovery to work, I believe a precedent is already in place that mandates that important ICMP messages should be forwarded ruling out (1). Questions arising... Can such information be authenticated in a reasonable manner? Can such information be anycast to other networks rather than being sent to individual hosts? If so, should it? Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Fri Aug 10 01:30:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16535 for ; Fri, 10 Aug 2001 01:30:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V4rW-0002S3-00 for multi6-data@psg.com; Thu, 09 Aug 2001 22:29:34 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.31 #1) id 15V4rV-0002Rx-00; Thu, 09 Aug 2001 22:29:33 -0700 From: Masataka Ohta Message-Id: <200108100521.OAA13490@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA13490; Fri, 10 Aug 2001 14:21:29 +0900 Subject: OT: prefix length used by backbone routers In-Reply-To: from Randy Bush at "Aug 9, 2001 09:19:30 am" To: Randy Bush Date: Fri, 10 Aug 2001 14:21:29 +0859 () CC: Peter Tattam , Jim Bound , Multi6 Working Group X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Randy; > are you asking if the forwarding look-up is longest match on 64 or 128 bits? > i think the latter is mandatory. we do allow allocation of /128s. Can't backbone routers assume 48 bit look-up for best effort unicast forwarding? Though who want to sell value-added (such as MPLS) routers may disagree, it is important for low-cost high-speed Internet. Masataka Ohta From owner-multi6@ops.ietf.org Fri Aug 10 01:48:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19370 for ; Fri, 10 Aug 2001 01:48:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V5B4-0003WZ-00 for multi6-data@psg.com; Thu, 09 Aug 2001 22:49:46 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.31 #1) id 15V5B3-0003WT-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 22:49:46 -0700 From: Masataka Ohta Message-Id: <200108100542.OAA13715@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA13715; Fri, 10 Aug 2001 14:42:05 +0900 Subject: Re: Transport level multihoming In-Reply-To: from Ben Black at "Aug 9, 2001 00:38:11 am" To: Ben Black Date: Fri, 10 Aug 2001 14:42:05 +0859 () CC: Ramakrishna Gummadi , Brian E Carpenter , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Ben; > > GSE is certainly a variation of 8+8 but is a poor proposal > > violating the end to end priciple at leastin two ways. > > > > And the currently deployed architecture violates layers by > allowing (forcing?) applications to be aware of network and > transport addresses. That's no layer violation. Or, are you saying TCP violates layer, because it is aware of not only port numbers but also internetworking layer addresses? Then, please tell me how to fix it. > If you eliminate those violations, through > whatever method of indirection, the end to end principle can The modification is to let applications handle (often merely pass them to TCP) multiple addresses, which some applications are already doing. Masaaka Ohta From owner-multi6@ops.ietf.org Fri Aug 10 02:38:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29718 for ; Fri, 10 Aug 2001 02:38:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V5x5-00063Z-00 for multi6-data@psg.com; Thu, 09 Aug 2001 23:39:23 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.31 #1) id 15V5x5-00063J-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 23:39:23 -0700 From: Masataka Ohta Message-Id: <200108100625.PAA14282@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA14282; Fri, 10 Aug 2001 15:25:39 +0900 Subject: Re: New proposal for Network Layer IPv6 multihoming: MHTP In-Reply-To: <2B81403386729140A3A899A8B39B046403ACE4@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Aug 6, 2001 02:41:22 pm" To: Michel Py Date: Fri, 10 Aug 2001 15:25:39 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Michael Py; My mailer says: [Charset UTF-8 unsupported, skipping...] Use ASCII. Masataka Ohta From owner-multi6@ops.ietf.org Fri Aug 10 02:54:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29944 for ; Fri, 10 Aug 2001 02:54:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V6CN-0006tj-00 for multi6-data@psg.com; Thu, 09 Aug 2001 23:55:11 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15V6CM-0006tQ-00 for multi6@ops.ietf.org; Thu, 09 Aug 2001 23:55:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15V6CH-0002aQ-00; Fri, 10 Aug 2001 07:55:05 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Masataka Ohta Cc: Multi6 Working Group Subject: Re: OT: prefix length used by backbone routers References: <200108100521.OAA13490@necom830.hpcl.titech.ac.jp> Message-Id: Date: Fri, 10 Aug 2001 07:55:05 +0100 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> are you asking if the forwarding look-up is longest match on 64 or 128 >> bits? i think the latter is mandatory. we do allow allocation of /128s. > Can't backbone routers assume 48 bit look-up for best effort unicast > forwarding? given the current addressing and routing model, i don't think so > Though who want to sell value-added (such as MPLS) routers may > disagree, it is important for low-cost high-speed Internet. i suspect the days of forwarding lookup speed problems are past us randy From owner-multi6@ops.ietf.org Fri Aug 10 03:39:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00600 for ; Fri, 10 Aug 2001 03:39:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V6tB-0009aA-00 for multi6-data@psg.com; Fri, 10 Aug 2001 00:39:25 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.31 #1) id 15V6tA-0009a3-00; Fri, 10 Aug 2001 00:39:25 -0700 From: Masataka Ohta Message-Id: <200108100731.QAA14709@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA14709; Fri, 10 Aug 2001 16:31:14 +0900 Subject: Re: OT: prefix length used by backbone routers In-Reply-To: from Randy Bush at "Aug 10, 2001 07:55:05 am" To: Randy Bush Date: Fri, 10 Aug 2001 16:31:13 +0859 () CC: Multi6 Working Group X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Randy; > >> are you asking if the forwarding look-up is longest match on 64 or 128 > >> bits? i think the latter is mandatory. we do allow allocation of /128s. > > Can't backbone routers assume 48 bit look-up for best effort unicast > > forwarding? > > given the current addressing and routing model, i don't think so Are you saying there is no fixed boundary at /48 even in the backbone? Then, it may affect multi6 proposals. > > Though who want to sell value-added (such as MPLS) routers may > > disagree, it is important for low-cost high-speed Internet. > > i suspect the days of forwarding lookup speed problems are past us I'm afraind you are assuming maximum router speed as slow as 10Gps. Masataka Ohta From owner-multi6@ops.ietf.org Fri Aug 10 03:43:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00651 for ; Fri, 10 Aug 2001 03:43:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V6xO-0009m8-00 for multi6-data@psg.com; Fri, 10 Aug 2001 00:43:46 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15V6xN-0009m0-00 for multi6@ops.ietf.org; Fri, 10 Aug 2001 00:43:45 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15V6xJ-0002f9-00; Fri, 10 Aug 2001 08:43:41 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Masataka Ohta Cc: Multi6 Working Group Subject: Re: OT: prefix length used by backbone routers References: <200108100731.QAA14709@necom830.hpcl.titech.ac.jp> Message-Id: Date: Fri, 10 Aug 2001 08:43:41 +0100 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> Can't backbone routers assume 48 bit look-up for best effort unicast >>> forwarding? >> given the current addressing and routing model, i don't think so > Are you saying there is no fixed boundary at /48 even in the > backbone? yes, that is what i am saying. the /48 boundary is soft, and is only for fp=001. we should not hard code the equivalent of A/B/C in routers again. >>> Though who want to sell value-added (such as MPLS) routers may >>> disagree, it is important for low-cost high-speed Internet. >> i suspect the days of forwarding lookup speed problems are past us > I'm afraind you are assuming maximum router speed as slow as 10Gps. no i am not. i am presuming that the forwarding lookup will continue to keep up with line speeds. randy From owner-multi6@ops.ietf.org Fri Aug 10 03:46:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00717 for ; Fri, 10 Aug 2001 03:46:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V70c-0009wu-00 for multi6-data@psg.com; Fri, 10 Aug 2001 00:47:06 -0700 Received: from [65.194.140.146] (helo=uniwest2.it.west.unispherenetworks.com) by psg.com with esmtp (Exim 3.31 #1) id 15V70b-0009tZ-00 for multi6@ops.ietf.org; Fri, 10 Aug 2001 00:47:05 -0700 Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 03:45:00 -0400 Received: from fkastenholzpc.unispherenetworks.com (FKASTENHOLZPC [10.10.248.60]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P5AJKHQH; Fri, 10 Aug 2001 03:46:26 -0400 From: "Kastenholz, Frank" To: Masataka Ohta , Randy Bush Cc: Peter Tattam , Jim Bound , Multi6 Working Group Message-Id: <5.0.2.1.2.20010810033203.01fc57b0@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 10 Aug 2001 03:40:23 -0400 Subject: Re: OT: prefix length used by backbone routers In-Reply-To: <200108100521.OAA13490@necom830.hpcl.titech.ac.jp> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 02:21 PM 8/10/01 +0859, Masataka Ohta wrote: >Randy; > >> are you asking if the forwarding look-up is longest match on 64 or 128 bits? >> i think the latter is mandatory. we do allow allocation of /128s. > >Can't backbone routers assume 48 bit look-up for best effort unicast >forwarding? no >Though who want to sell value-added (such as MPLS) routers may >disagree, it is important for low-cost high-speed Internet. that would be nice. but the cost of being able to do long (/32 and /128) lookups is in the noise compared to the costs of all the other stuff, such as the somewhat shorter lookups (eg /24 or /48), high speed optics (lasers etc), buffer memories, internal switch fabrics, boards, and so on. Frank Kastenholz From owner-multi6@ops.ietf.org Fri Aug 10 04:02:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01033 for ; Fri, 10 Aug 2001 04:02:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V7Gm-000Al6-00 for multi6-data@psg.com; Fri, 10 Aug 2001 01:03:48 -0700 Received: from [65.194.140.146] (helo=uniwest2.it.west.unispherenetworks.com) by psg.com with esmtp (Exim 3.31 #1) id 15V7Gl-000Akn-00 for multi6@ops.ietf.org; Fri, 10 Aug 2001 01:03:47 -0700 Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 04:01:46 -0400 Received: from fkastenholzpc.unispherenetworks.com (FKASTENHOLZPC [10.10.248.60]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P5AJKHQQ; Fri, 10 Aug 2001 04:03:15 -0400 From: "Kastenholz, Frank" To: Masataka Ohta , Randy Bush Cc: Multi6 Working Group Message-Id: <5.0.2.1.2.20010810040348.01f60ba0@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 10 Aug 2001 04:05:39 -0400 Subject: Re: OT: prefix length used by backbone routers In-Reply-To: <200108100731.QAA14709@necom830.hpcl.titech.ac.jp> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 04:31 PM 8/10/01 +0859, Masataka Ohta wrote: >Randy; > >> >> are you asking if the forwarding look-up is longest match on 64 or 128 >> >> bits? i think the latter is mandatory. we do allow allocation of /128s. >> > Can't backbone routers assume 48 bit look-up for best effort unicast >> > forwarding? >> >> given the current addressing and routing model, i don't think so > >Are you saying there is no fixed boundary at /48 even in the >backbone? > >Then, it may affect multi6 proposals. There may be a fixed /48 boundary. But a router vendor can not assume that there is one -- it could change next week... And given that the edit-compile-debug loop of ASICs is measured in months, not minutes, we need to assume the worst case. Frank Kastenholz From owner-multi6@ops.ietf.org Fri Aug 10 05:38:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01977 for ; Fri, 10 Aug 2001 05:38:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V8kY-000FDm-00 for multi6-data@psg.com; Fri, 10 Aug 2001 02:38:38 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([194.237.142.110]) by psg.com with esmtp (Exim 3.31 #1) id 15V8kQ-000FDU-00 for multi6@ops.ietf.org; Fri, 10 Aug 2001 02:38:34 -0700 Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f7A9c5O28411 for ; Fri, 10 Aug 2001 11:38:05 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA17810; Fri, 10 Aug 2001 11:38:04 +0200 Message-ID: <3B73AB13.47147DF1@era.ericsson.se> Date: Fri, 10 Aug 2001 11:36:19 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: 64-bit identifiers References: <200108091522.f79FM6u77678@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: > PS: the five bullets in the HIP TODO list are: > - key exchange > - mobility > - NAT traversal > - home multihoming > - site multihoming > So HIP is something we have to look at! Francis, I agree. What is the consensus on supporting large progressive steps like HIP? /Mattias From owner-multi6@ops.ietf.org Fri Aug 10 06:06:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02414 for ; Fri, 10 Aug 2001 06:06:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V9Cn-000Gem-00 for multi6-data@psg.com; Fri, 10 Aug 2001 03:07:49 -0700 Received: from www.bit-net.com ([208.146.132.4] helo=mail.users.bit-net.com) by psg.com with smtp (Exim 3.31 #1) id 15V9Cn-000Geg-00 for multi6@ops.ietf.org; Fri, 10 Aug 2001 03:07:49 -0700 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA12945; Fri, 10 Aug 2001 06:07:34 -0400 Date: Fri, 10 Aug 2001 06:07:34 -0400 (EDT) From: Jim Bound To: Brian E Carpenter Cc: Peter Tattam , Multi6 Working Group Subject: Re: Transport level multihoming In-Reply-To: <3B72ABDC.F55044AC@hursley.ibm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Brian/Ran, I agree. Forgot about the privacy exts... thx /jim On Thu, 9 Aug 2001, Brian E Carpenter wrote: > Given that privacy considerations will force us to accept pseudo-random lower > 64 bits, I don't think we can assume much of anything about those bits from > the viewpoint of host identity. > > Brian > > Jim Bound wrote: > > > > Hi Peter, > > > > > One question. > > > > > > In a transport level multihoming scenario, should two addresses that differ in > > > the lower 64 bits (node address part) be considered independent nodes and > > > handled in the traditional manner with regard to multiple addresses? > > > > Good question. I would say yes but SCTP would permit one to treat them as > > the same node yet different links (interfaces). But I think we need to > > think hard about the question and all the matrix of answers. > > > > > > > > Why I ask is that the upper 64 bits of all possible full addresses for a > > > particular node that is multihomed have particular properties that would be > > > useful to exploit in transport level multihoming. If the lower 64 bits is not > > > identical between multiple addresses, it could lead to inefficiencies in a > > > compressed representation of the list of IPv6 addresses. It may also be > > > important to some layers of any multihoming protocol to consider that addresses > > > which differ in the lower 64 bits would not being equivalent for the purposes > > > of multihoming. > > > > Hmmmm... I am not sure we can assume this on the lower 64 bits...I need to > > dream on that...Excellent question. > > > > /jim > From owner-multi6@ops.ietf.org Fri Aug 10 06:06:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02430 for ; Fri, 10 Aug 2001 06:06:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V9As-000GXC-00 for multi6-data@psg.com; Fri, 10 Aug 2001 03:05:50 -0700 Received: from www.bit-net.com ([208.146.132.4] helo=mail.users.bit-net.com) by psg.com with smtp (Exim 3.31 #1) id 15V9As-000GX6-00 for multi6@ops.ietf.org; Fri, 10 Aug 2001 03:05:50 -0700 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA19509; Fri, 10 Aug 2001 06:05:38 -0400 Date: Fri, 10 Aug 2001 06:05:37 -0400 (EDT) From: Jim Bound To: Francis Dupont Cc: Randy Bush , Sean Doran , multi6@ops.ietf.org Subject: Re: note from the iesg plenary In-Reply-To: <200108091318.f79DIvu77238@givry.rennes.enst-bretagne.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk I was speaking of future code base. What has the shim to do with HIP? /jim On Thu, 9 Aug 2001, Francis Dupont wrote: > In your previous mail you wrote: > > Possbily earlier with code patches with a shim I suggested to Brian on > other mail thread. Do not assume the market will wait or can be held up > at least in Asia and Europe, and now even certain target markets will > begin early adoption in the U.S. and have already although in test phase > now. > > => I disagree: we know we have no good solution in the current code base. > I believe the solution will be in hosts and compatible with the current > IPv6, but nodes which will be to used it will get extra functionalities > (so we'll like to switch to them). But I agree we have to search and *find* > a workable solution ASAP. Something like HIP seems to be promising (I was > at the HIP meeting so I should be still biaised :-). > > Regards > > Francis.Dupont@enst-bretagne.fr > From owner-multi6@ops.ietf.org Fri Aug 10 06:09:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02471 for ; Fri, 10 Aug 2001 06:09:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V9FS-000GoB-00 for multi6-data@psg.com; Fri, 10 Aug 2001 03:10:34 -0700 Received: from www.bit-net.com ([208.146.132.4] helo=mail.users.bit-net.com) by psg.com with smtp (Exim 3.31 #1) id 15V9FR-000Go5-00 for multi6@ops.ietf.org; Fri, 10 Aug 2001 03:10:33 -0700 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA01624; Fri, 10 Aug 2001 06:10:28 -0400 Date: Fri, 10 Aug 2001 06:10:28 -0400 (EDT) From: Jim Bound To: Bob Hinden Cc: RJ Atkinson , multi6@ops.ietf.org Subject: Re: 64-bit identifiers In-Reply-To: <4.3.2.7.2.20010809081326.021d6978@mailhost.iprg.nokia.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Bob, I thought about where your coming from after Ran/Brian's mail. But I don't think we can say this works if public EUIs are used but not with Temp addrs. I don't think that will fly with the operators as that is yet more to manage with yet another "if case". /jim On Thu, 9 Aug 2001, Bob Hinden wrote: > Ran, > > >The existence of the Privacy Address Configuration specification > >for IPv6 means that the low-order 64-bits CAN NOT uniquely identify > >a host. Prior to then, using the low-order 64-bits (as proposed > >by original 8+8/GSE) might have worked. That approach cannot work > >given the current state of specs. Note well that the "privacy > >extension" spec (sic) is being widely implemented and deployed in > >end-systems (e.g. Windows XP). > > IPv6 nodes can have long lived 64 bit interface identifiers (usually > created from hardware tokens) and temporary interface identifiers per > RFC3041. Most implementations will support both types as they serve > different purposes. There is a bit in the interface identifier that > indicates whether it is a global or local identifier. As you point out the > global identifiers could be used with an 8+8/GSE type scheme, while the > temporary addresses would be harder to use. > > >Now one could postulate a different identifer that could be used > >in things like Protocol Control Blocks to bind session state > >and identity (in lieu of using IP addresses as at present). There > >would need to be some ability to map to/from that identifier to > >other kinds of identifiers (perhaps IP Addresses, FQDNs) for > >this to be deployable, as near as I can tell. There is some work > >within the IRTF NSRG examining the possibility of adding such > >identifiers to the Internet Architecture, but that's research > >not engineering for now. > > Based on our experience with global IPv6 interface identifiers, I suspect > that any new scheme using global identifiers will have to deal with privacy > issues to allow for anonymous communication. > > Bob > > > From owner-multi6@ops.ietf.org Fri Aug 10 06:30:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02849 for ; Fri, 10 Aug 2001 06:30:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V9Zw-000Hrx-00 for multi6-data@psg.com; Fri, 10 Aug 2001 03:31:44 -0700 Received: from melimelo.enst-bretagne.fr ([192.108.115.36]) by psg.com with esmtp (Exim 3.31 #1) id 15V9Zv-000HqI-00; Fri, 10 Aug 2001 03:31:43 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f7AAUd817297; Fri, 10 Aug 2001 12:30:40 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA19000; Fri, 10 Aug 2001 12:30:39 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f7AAUcu80693; Fri, 10 Aug 2001 12:30:38 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108101030.f7AAUcu80693@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: Randy Bush , Sean Doran , multi6@ops.ietf.org Subject: Re: note from the iesg plenary In-reply-to: Your message of Fri, 10 Aug 2001 06:05:37 EDT. Date: Fri, 10 Aug 2001 12:30:38 +0200 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: I was speaking of future code base. => what I have (mis?)understood is that we can't adopt very new things like HIP because the code was frozen and will be delivered to customers ASAP. This implies (that was the introducing statement of your mail I have lost in editing after a connection reset (the only one, BT seems stronger than Code Red :-)) that the solution has to be implemented in routers and not in hosts (modulo the shim stuff). What has the shim to do with HIP? => nothing... A shim should not be enough to add HIP. Regards Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Fri Aug 10 11:50:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06793 for ; Fri, 10 Aug 2001 11:50:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15VEUG-0007jF-00 for multi6-data@psg.com; Fri, 10 Aug 2001 08:46:12 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.31 #1) id 15VEUF-0007ii-00; Fri, 10 Aug 2001 08:46:12 -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 LAA13380; Fri, 10 Aug 2001 11:45:58 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id LAA14747; Fri, 10 Aug 2001 11:45:52 -0400 (EDT) Date: Fri, 10 Aug 2001 11:45:52 -0400 (EDT) From: Greg Maxwell To: Randy Bush cc: Masataka Ohta , Multi6 Working Group Subject: Re: OT: prefix length used by backbone routers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 10 Aug 2001, Randy Bush wrote: > >>> disagree, it is important for low-cost high-speed Internet. > >> i suspect the days of forwarding lookup speed problems are past us > > I'm afraind you are assuming maximum router speed as slow as 10Gps. > > no i am not. i am presuming that the forwarding lookup will continue to > keep up with line speeds. Whatever cases there are that can be made about strange fast optical switching technology, comparing 128 bits is within the same order of magnitude as comparing 48 bits, so it's unlikely to be an issue. Back on topic: The way multihoming is done will have a much more profound impact on how much work routers have to do. From owner-multi6@ops.ietf.org Fri Aug 10 12:38:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07825 for ; Fri, 10 Aug 2001 12:38:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15VFI6-000AP0-00 for multi6-data@psg.com; Fri, 10 Aug 2001 09:37:42 -0700 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.31 #1) id 15VFI5-000AOt-00 for multi6@ops.ietf.org; Fri, 10 Aug 2001 09:37:42 -0700 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id MAA05949; Fri, 10 Aug 2001 12:37:40 -0400 Date: Fri, 10 Aug 2001 12:37:40 -0400 From: "J. Noel Chiappa" Message-Id: <200108101637.MAA05949@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: OT: prefix length used by backbone routers Cc: jnc@ginger.lcs.mit.edu Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Greg Maxwell > Back on topic: The way multihoming is done will have a much more > profound impact on how much work routers have to do. Please distinguish between "work in forwarding" and "work in the control plane, e.g. route selection computations" when you speak of work for routers - different schemes have important differences there. Noel From owner-multi6@ops.ietf.org Fri Aug 10 13:14:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08479 for ; Fri, 10 Aug 2001 13:14:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15VFs7-000CJr-00 for multi6-data@psg.com; Fri, 10 Aug 2001 10:14:55 -0700 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.31 #1) id 15VFs6-000CJl-00 for multi6@ops.ietf.org; Fri, 10 Aug 2001 10:14:54 -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 NAA14459; Fri, 10 Aug 2001 13:14:42 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id NAA20709; Fri, 10 Aug 2001 13:14:35 -0400 (EDT) Date: Fri, 10 Aug 2001 13:14:35 -0400 (EDT) From: Greg Maxwell To: "J. Noel Chiappa" cc: Subject: Re: OT: prefix length used by backbone routers In-Reply-To: <200108101637.MAA05949@ginger.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 10 Aug 2001, J. Noel Chiappa wrote: > > From: Greg Maxwell > > > Back on topic: The way multihoming is done will have a much more > > profound impact on how much work routers have to do. > > Please distinguish between "work in forwarding" and "work in the control > plane, e.g. route selection computations" when you speak of work for routers - > different schemes have important differences there. The difference in control plain is a function of how many routes you place in the table, not the depth of your lookup. The type of transport level multihoming I've been calling for here would make the size of your route table grow linearly (or better) with the number of customers and peers you have, so your load is purely a local issue. From a global perspective, there is no reason to believe that the routing table size would be related to the depth of the lookups. Why? Because there are already more possible /64 networks then we could tolerate in any control plane, so going deeper doesn't make a difference. From owner-multi6@ops.ietf.org Fri Aug 10 14:40:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09579 for ; Fri, 10 Aug 2001 14:40:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15VHDM-000GEy-00 for multi6-data@psg.com; Fri, 10 Aug 2001 11:40:56 -0700 Received: from flowpoint.procket.com ([209.140.237.1] helo=alpha-tli.procket.com) by psg.com with esmtp (Exim 3.31 #1) id 15VHDL-000GEi-00 for multi6@ops.ietf.org; Fri, 10 Aug 2001 11:40:55 -0700 Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id LAA03047; Fri, 10 Aug 2001 11:34:42 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15220.10562.277676.852364@alpha-tli.procket.com> Date: Fri, 10 Aug 2001 11:34:42 -0700 To: Masataka Ohta Cc: Ben Black , Ramakrishna Gummadi , Brian E Carpenter , multi6@ops.ietf.org Subject: Re: Transport level multihoming In-Reply-To: <200108100542.OAA13715@necom830.hpcl.titech.ac.jp> References: <200108100542.OAA13715@necom830.hpcl.titech.ac.jp> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | Then, please tell me how to fix it. The way to fix it is to add another layer of indirection. Almost all applications do not care about the address of the other end of the connection. They start out with a hostname and actually have to work quite hard to resolve the hostname, get an address and then make a connection to that address. The hostname serves as a unique identifier which carries the semantics that the application cares about and does not carry more specific semantics that the application does not and should not care about. This would allow lower layers to change addresses on a connection in a manner that is transparent to the application. Tony p.s. I've always wanted to ask the BSD architects how they would change the sockets API if they had it to do over again. From owner-multi6@ops.ietf.org Fri Aug 10 22:35:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16042 for ; Fri, 10 Aug 2001 22:35:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15VOcc-000CQO-00 for multi6-data@psg.com; Fri, 10 Aug 2001 19:35:30 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.31 #1) id 15VOcb-000COE-00 for multi6@ops.ietf.org; Fri, 10 Aug 2001 19:35:29 -0700 Received: from kenawang ([192.168.1.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA25353 for ; Fri, 10 Aug 2001 19:34:53 -0700 (PDT) Message-Id: <4.2.2.20010810223354.00a87100@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 10 Aug 2001 22:40:43 -0400 To: multi6@ops.ietf.org From: Margaret Wasserman Subject: Fwd: Re: note from the iesg plenary Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi All, Sean Doran and Thomas Narten asked that I send a summary of my routing issues to the multi6 list. This is not a very well-developed list. I'm working on a draft for the IPv6 group that will answer these questions as well as I can, and hopefully serve as a discussion tool for closing the other questions. In the meantime, please let me know if you have any of the answers. I don't think that any of these particular issues related directly to multi-homing, but I could be wrong -- everything seems to related to multi-homing these days. :-). Thanks, Margaret >>Basically, I have four issues: >> >> (1) Boundaries for regular route lookups. >> (2) Site-local routing. >> (3) Anycast routing. >> (4) Routing table MIBs. >> >>(1) The current addressing architecture defines all routable >>unicast addresses to include a 64-bit identifier. Does that mean >>that it is reasonable for a router to only look at the first 64 >>bits when making a routing decision? Or should routers still treat >>these addresses as CIDR-like? >> >>(2) Site-local routing is particularly confusing on a site-border router. >>I don't know if anyone has really implemented one, but it seems likely >>that it will need to have multiple routing tables (one global table >>and one per attached site). Even an intra-site router may need two >>conceptual routing tables (one global, one site). >> >>Also, some of the scoped addressing architecture assumptions only work >>if sites are "convex" (Steve's word). Unfortunately, that assumption >>is not yet documented and the word "convex" has no currently defined >>meaning in terms of routing -- even though we understand what it means. >>Also, topologies change. So, what happens if a site becomes >>"concave"? >> >>There is wording in a variety of IPv6 specs talking about how >>routers should (and shouldn't) pass site-local information, but I haven't >>looked to see if the current IPv6 routing protocols reflect this >>information (or even know that they may pass site-local routes). >> >>Since there doesn't have to be a one-to-one mapping between sites >>and ASes, I need to figure out if there are any problems with propagating >>site information when a site contains two (or more) ASes or when two >>(or more, or parts of multiple) sites are contained in a single OSPF >>AS. I have no clue how this would work yet... >> >>(3) IPv6 anycast is substantially different from the anycast hacks >>currently used in IPv4. One big difference: a global IPv6 anycast >>address would (probably?) not appear to be inside of anyone's AS. >>I don't know if this causes problems, as I haven't had time to look >>at how OSPF would handle a host route injection for a router outside >>the AS. >> >>And, despite the fact that we are specifying the use of site-local >>anycast addresses in documents (like Dave Thaler's DNS stuff), we >>don't actually know what a site-local anycast would look like. The >>latest verbal possibilities from Steve seem to indicate that we might >>artificially reserve one of the subnet numbers (all zeros or all >>ones?) as an area to assign site-local anycast addresses. If so, >>the routing might be okay...? >> >>However, the IPv4 stuff has only been tried with BGP. Do we know for >>sure that the OSPF tree will converge if it thinks that one host is >>actually located at two different places in the topology? Maybe this >>would just work -- I don't know OSPF well enough to know for sure >>without closely reviewing the spec (or maybe trying it). >> >>Also, since a site doesn't actually map to an AS, and may not be >>handled by a single routing protocol (i.e. it may be running OSPF >>between some RIP networks, or something?), then it isn't clear >>exactly where and how you would "inject" a route into the routing >>system (or whatever loose wording we're using) and be sure that >>it would propogated to the entire site... >> >>(4) The current IPv6 routing table MIBs are based on the IPv4 >>routing MIBs. It isn't clear if they will be able to properly >>handle IPv6 routing tables, as they may be different. Once we >>figure out the architecture and conceptual datastructures, I will >>closely review the MIBs to see if they match. >> >>So, those are basically my issues. Some of these may be non-issues, >>but I won't know for sure until I investigate (much) further. I had >>been hoping that some actual routing person was looking at these >>issues, but alas...I guess that I will be forced to play a routing >>person on TV (or on the mbone, anyway). I will try to write something >>up in the next several weeks for the IPv6 WG. >> >>Sean, I doubt that this answers any of your questions. But, feel >>free to let me know if you have specific issues or questions. I'll >>also try to read the multi6 list next week. >> >>I'm glad that someone was listening... :-). >> >>Margaret >> >> >> >> >>At 06:28 AM 8/10/01 , Thomas Narten wrote: >>>Hi Sean. >>> >>>Margaret Wasserman was the person who raised the issues from the >>>floor during the plenary.. >>> >>>Margaret, are you on the multi6 list? >>> >>>Thomas >>> >>>smd@ebone.net (Sean Doran) writes: >>> >>> > it was noted that there has been little attention payed in the ietf >>> > to scoped addresses of various types in the ipv6 standard (e.g., link >>> > or anycast addresses). >>> >>> > for our wg (from me, not from the floor): can these different address >>> > varities, when a host uses them, be considered as a form of multiple-address >>> > multihoming? likewise, those approaches which change the routing system >>> > in some fashion: how can/do they deal with such addressing types? >>> >>> > Sean. >>> >>> > ps - several questions are coming up and unfortunately i am too slow a typist: >>> > how does one choose and forward addresses for anycast objects, how does >>> > one deal with sites which are not convex, how does one scope addresses >>> > beyond a site boundary. there were others. if someone can identify >>> > the questioner from the floor, i would like to invite her to ask the >>> > same questions here. as noted, with my other hat, irtf-rr is a reasonable >>> > place to ask (not necessarily ipv6-specific) similar questions, but >>> > note well that the irtf is *NOT* the ietf, whereas this is. From owner-multi6@ops.ietf.org Sat Aug 11 05:14:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05045 for ; Sat, 11 Aug 2001 05:14:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15VUr0-000NE6-00 for multi6-data@psg.com; Sat, 11 Aug 2001 02:14:46 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.31 #1) id 15VUqz-000NE0-00 for multi6@ops.ietf.org; Sat, 11 Aug 2001 02:14:45 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f7B9Eao12101; Sat, 11 Aug 2001 12:14:36 +0300 Date: Sat, 11 Aug 2001 12:14:36 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: , Subject: Re: Fwd: Re: note from the iesg plenary In-Reply-To: <4.2.2.20010810223354.00a87100@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk I've added ipng to Cc: list as this has never been discussed there, and is IMO mostly ipng-stuff. On Fri, 10 Aug 2001, Margaret Wasserman wrote: > >>Basically, I have four issues: > >> > >> (1) Boundaries for regular route lookups. > >> (2) Site-local routing. > >> (3) Anycast routing. > >> (4) Routing table MIBs. > >> > >>(1) The current addressing architecture defines all routable > >>unicast addresses to include a 64-bit identifier. Does that mean > >>that it is reasonable for a router to only look at the first 64 > >>bits when making a routing decision? Or should routers still treat > >>these addresses as CIDR-like? I think this was discussed very recently in 'prefix length used by backbone routers' thread in multi6. I'm not sure if all issues raised here were brought up there. > >>(2) Site-local routing is particularly confusing on a site-border router. > >>I don't know if anyone has really implemented one, but it seems likely > >>that it will need to have multiple routing tables (one global table > >>and one per attached site). Even an intra-site router may need two > >>conceptual routing tables (one global, one site). [snip] Why would there be a need for two routing tables? It might help, but I don't see it as strictly necessary. Wouldn't "practically" some equivalent of an IPv6 access list, blocking site-local addresses from spreading outside of the site and in the site be sufficient? Also, all routing EGP protocols should have route-map's or equivalent to eliminate the possible spread of site-local, and link-local, address announcements. It's legal to use different AS numbers inside the site (e.g. one or two primary ones and some from private space), the default behaviour perhaps should be: 1) in eBGP (or anything between two AS numbers), filter site-local announcements by default 2) if extra keyword "same-site" is used even with different AS's, this would not be done. > >>(3) IPv6 anycast is substantially different from the anycast hacks > >>currently used in IPv4. One big difference: a global IPv6 anycast > >>address would (probably?) not appear to be inside of anyone's AS. > >>I don't know if this causes problems, as I haven't had time to look > >>at how OSPF would handle a host route injection for a router outside > >>the AS. Another huge difference (from usage point of view): IPv6 anycast address MUST not be used as a source address. I doubt host route injection will work due to "martian" filtering of /128's, or other such routes. What will work, is the similar thing as it is done with IPv4 anycast: Consider: 6to4 IPv4 anycast prefix is 192.88.99.0/24. 6to4 IPv4 anycast address is 192.88.99.1. If someone injected 192.88.99.1, that would surely be filtered. But as IPv6 anycast is defined the same as IPv4 anycast, you can just inject routes to to some /48, /64, etc. networks -- no different than current route injections. (btw, nobody is advertising 6to4 anycast prefix in DFZ yet. Shows the current ipv4 anycast deployment rate mentioned in ngtrans at IETF51 wrt. isatap discovery IMO.. :-) > >>However, the IPv4 stuff has only been tried with BGP. Do we know for > >>sure that the OSPF tree will converge if it thinks that one host is > >>actually located at two different places in the topology? Maybe this > >>would just work -- I don't know OSPF well enough to know for sure > >>without closely reviewing the spec (or maybe trying it). We cannot be sure. That is, if OSPF costs (or other protocols' metrics) to different anycast advertisements are equal, there will be load-balancing. But then again, this might be designed behaviour (for unicast, probably not for anycast) too. By designing the site topology properly, and adjusting the last-hop (ie. router to host providing anycast service; this might not always be doable if routers themselves act as anycast servers) OSPF costs by adding big values there, e.g. "500" or "1000" so there would be no overlap no matter what, this should converge quite nicely. This is a policy issue. One might want to (in intra-site policy) either (or some others): - select the closest anycast server (ospf cost should not be adjusted, loadbalancing would be considered a feature) - select always the default anycast server if it's responding, if not, select a different one (preferring the service with ospf cost) > >>(4) The current IPv6 routing table MIBs are based on the IPv4 > >>routing MIBs. It isn't clear if they will be able to properly > >>handle IPv6 routing tables, as they may be different. Once we > >>figure out the architecture and conceptual datastructures, I will > >>closely review the MIBs to see if they match. As you know, Bill Fenner is revising these. Now's the time... -- 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 Sun Aug 12 17:48:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19165 for ; Sun, 12 Aug 2001 17:48:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15W33I-0009Oh-00 for multi6-data@psg.com; Sun, 12 Aug 2001 14:45:44 -0700 Received: from kahuna.telstra.net ([139.130.204.11]) by psg.com with esmtp (Exim 3.31 #1) id 15W33G-0009OX-00 for multi6@ops.ietf.org; Sun, 12 Aug 2001 14:45:43 -0700 Received: from tecra.telstra.net (jumble.telstra.net [139.130.204.15]) by kahuna.telstra.net (8.11.3/8.11.3) with ESMTP id f7CLjJ834328; Mon, 13 Aug 2001 07:45:20 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20010813073613.00aa14b0@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Aug 2001 07:44:13 +1000 To: Mattias Pettersson From: Geoff Huston Subject: Re: 64-bit identifiers Cc: multi6@ops.ietf.org In-Reply-To: <3B73AB13.47147DF1@era.ericsson.se> References: <200108091522.f79FM6u77678@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk > > So HIP is something we have to look at! > >Francis, I agree. What is the consensus on supporting large progressive >steps like HIP? Obviously it depends nf the architecture you want to follow - As I understand it HIP is a persistent identity algorithm at the application layer. It you want to following the architectural model that multi-homing at the end point implies a change of address _that the application is aware of_ then either you need some part of the address to remain constant (low order n bits) or you need some other exchanged token to denote identity. Its not obvious to me that you need both mechanisms simultaneously. Geoff From owner-multi6@ops.ietf.org Mon Aug 13 04:25:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12180 for ; Mon, 13 Aug 2001 04:25:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WD26-000L0p-00 for multi6-data@psg.com; Mon, 13 Aug 2001 01:25:10 -0700 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.31 #1) id 15WD26-000L0j-00 for multi6@ops.ietf.org; Mon, 13 Aug 2001 01:25:10 -0700 Received: from bebop.France.Sun.COM ([129.157.179.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA03108; Mon, 13 Aug 2001 01:25:07 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7D8P1219444; Mon, 13 Aug 2001 10:25:01 +0200 (MET DST) Date: Mon, 13 Aug 2001 10:22:23 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Transport level multihoming To: Greg Maxwell Cc: Brian E Carpenter , Daniel Senie , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > We make the existing API a userspace wrapper on an improved API that takes > multiple addresses. The resolver will return a bogus IP address which is > specific to that boot-session of the host, the socket API wrapper will > reconize the bogus address (because they will all be scoped out of a > special allocated area), and query the resolver again to retrieve all of > the real addresses then call the real API. > > This would allow us to achieve application compatibility. If you are using bogus identifiers then the system, from the applications perspective, looks very much like a NAT. Thus multiparty applications which pass IP addresses to peer application instances will completely fail. It isn't clear to me that even the ftp port command can be made to work. (Having implemented Bump-in-the-API with IPv4 applications on an IPv6 stack by making the applications believe they connect to addresses in 0.0.0.0/8 I have a long list of things that can break. Doing this for IPv6 "over" IPv6 has the same issues as far as I can tell.) I don't yet fully understand the properties of using one of the real IP addresses. It can cause some unexpected aliasing between IP address sets as you pointed out in subsequent emails. Erik From owner-multi6@ops.ietf.org Mon Aug 13 04:44:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12341 for ; Mon, 13 Aug 2001 04:44:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WDKc-000LHJ-00 for multi6-data@psg.com; Mon, 13 Aug 2001 01:44:18 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.31 #1) id 15WDKc-000LHD-00 for multi6@ops.ietf.org; Mon, 13 Aug 2001 01:44:18 -0700 Received: from bebop.France.Sun.COM ([129.157.179.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03124; Mon, 13 Aug 2001 02:44:14 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7D8iA221028; Mon, 13 Aug 2001 10:44:10 +0200 (MET DST) Date: Mon, 13 Aug 2001 10:41:32 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 64-bit identifiers To: "J. Noel Chiappa" Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <200108091611.MAA03910@ginger.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > Of course, for the really paranoid, they don't like long-lived unique > identifiers of any kind, because they allow correlation of activity, which > may allow identification through out-of-channel means. So for them, there's > *no* identifier scheme that will keep them happy. Kind of hard to work around > that requirement.... If a node can have multiple such indentifiers, new identifiers can be created autonomously by the node, and it isn't too expensive to create new ones, then it wouldn't be infeasible for the truly paranoid to use a different identifier every hour or for every connection. Thus I think the ability to autonomously create new identifiers is a requirement. Erik From owner-multi6@ops.ietf.org Mon Aug 13 04:47:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12370 for ; Mon, 13 Aug 2001 04:47:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WDOS-000LL5-00 for multi6-data@psg.com; Mon, 13 Aug 2001 01:48:16 -0700 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.31 #1) id 15WDOS-000LKz-00 for multi6@ops.ietf.org; Mon, 13 Aug 2001 01:48:16 -0700 Received: from bebop.France.Sun.COM ([129.157.179.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA09046; Mon, 13 Aug 2001 01:48:12 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7D8m6221471; Mon, 13 Aug 2001 10:48:07 +0200 (MET DST) Date: Mon, 13 Aug 2001 10:45:29 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Transport level multihoming To: Peter Tattam Cc: Greg Maxwell , Jim Bound , Multi6 Working Group In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > I am not precluding this. Perhaps I should expand the argument to relax the > restriction on the 64 bit boundary and say that if a site is multihomed with > N upper bits, can we consider that if the lower 128-N bits are the same, > they can be considered the same node address. Anything else is another > address. Peter, what benefits can we derive from such a restriction? Is it just implementation ease? (being able to compress the memory representation of the list of addresses and being able to make more efficient lookups against the list?) Erik From owner-multi6@ops.ietf.org Mon Aug 13 05:29:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12665 for ; Mon, 13 Aug 2001 05:29:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WE3B-000Lvz-00 for multi6-data@psg.com; Mon, 13 Aug 2001 02:30:21 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.31 #1) id 15WE3A-000Lvt-00 for multi6@ops.ietf.org; Mon, 13 Aug 2001 02:30:20 -0700 Received: from bebop.France.Sun.COM ([129.157.179.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00228; Mon, 13 Aug 2001 02:38:17 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7D8cE220498; Mon, 13 Aug 2001 10:38:14 +0200 (MET DST) Date: Mon, 13 Aug 2001 10:35:36 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 64-bit identifiers To: RJ Atkinson Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <5.1.0.14.2.20010809092609.009f8e10@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > The existence of the Privacy Address Configuration specification > for IPv6 means that the low-order 64-bits CAN NOT uniquely identify > a host. Prior to then, using the low-order 64-bits (as proposed > by original 8+8/GSE) might have worked. That approach cannot work > given the current state of specs. Note well that the "privacy > extension" spec (sic) is being widely implemented and deployed in > end-systems (e.g. Windows XP). ... and others are contemplating using the low-order 64 bits to solve authorization issues for "redirect" (as in mobile ip binding updates) as in the SUCV draft. However, this doesn't make things any worse than with the "privacy extensions" RFC. But it is more of a technical argument than a perception argument for using the low-order 64 bits. > Now one could postulate a different identifer that could be used > in things like Protocol Control Blocks to bind session state > and identity (in lieu of using IP addresses as at present). The transport multihoming, SCTP, and GxSE seem to all be based on the identifier being a *set of* IP addresses, where the set is determined when the communcation is initiated. I think this is a very interesting space to continue to explore to understand the differences between the ideas/proposals. Such approaches would need a separate mechanism for handling renumbering of long-lived connections since that would require securely changing the set. (But my gut feel is that whatever secure solution we are confortable for Mobile IPv6 binding updates effectively "redirecting" traffic, can be applied to changes in the set of addresses identifying the connection.) Has the NSRG explored using sets of IP addresses as the indentifiers? Or are they focused on the issues of inventing a new name space? Erik From owner-multi6@ops.ietf.org Mon Aug 13 07:05:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13627 for ; Mon, 13 Aug 2001 07:05:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WFXo-000NG8-00 for multi6-data@psg.com; Mon, 13 Aug 2001 04:06:04 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.31 #1) id 15WFXn-000NG1-00 for multi6@ops.ietf.org; Mon, 13 Aug 2001 04:06:03 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13504; Mon, 13 Aug 2001 07:04:50 -0400 (EDT) Message-Id: <200108131104.HAA13504@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-py-multi6-mhtp-00.txt Date: Mon, 13 Aug 2001 07:04:50 -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi Homing Translation Protocol (MHTP) Author(s) : M. Py Filename : draft-py-multi6-mhtp-00.txt Pages : 24 Date : 08-Aug-01 This document describes a protocol for IPv6 Network Layer multihoming (MHTP) that does not affect the size of the routing table in the IPv6 DFZ and does not use tunnels. MHTP provides fault tolerance, very good application compatibility, and simple configuration. It can be described as a semi-symmetric, end-to-end, NAT protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-py-multi6-mhtp-00.txt 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-py-multi6-mhtp-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-py-multi6-mhtp-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: <20010809113529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-py-multi6-mhtp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-py-multi6-mhtp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010809113529.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Mon Aug 13 09:11:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18895 for ; Mon, 13 Aug 2001 09:11:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WHVi-000P13-00 for multi6-data@psg.com; Mon, 13 Aug 2001 06:12:02 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.31 #1) id 15WHVh-000P0H-00 for multi6@ops.ietf.org; Mon, 13 Aug 2001 06:12:01 -0700 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7DDAvp17713 for ; Mon, 13 Aug 2001 09:11:00 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Mon, 13 Aug 2001 09:10:49 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q5XKF6RX; Mon, 13 Aug 2001 09:10:39 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5NAGX; Mon, 13 Aug 2001 09:10:41 -0400 Message-ID: <3B77D1CD.39A66815@americasm06.nt.com> Date: Mon, 13 Aug 2001 09:10:37 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman CC: multi6@ops.ietf.org Subject: Re: Fwd: Re: note from the iesg plenary References: <4.2.2.20010810223354.00a87100@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Margaret, Let me take a crack at answering some of these. Margaret Wasserman wrote: > >>(1) The current addressing architecture defines all routable > >>unicast addresses to include a 64-bit identifier. Does that mean > >>that it is reasonable for a router to only look at the first 64 > >>bits when making a routing decision? Or should routers still treat > >>these addresses as CIDR-like? They still need to be treated as CIDR-like. A longest prefix match lookup may find a 16-bit or 48-bit entry, especially if the address being looked up is outside that router's domain. > >> > >>(2) Site-local routing is particularly confusing on a site-border router. > >>I don't know if anyone has really implemented one, but it seems likely > >>that it will need to have multiple routing tables (one global table > >>and one per attached site). Even an intra-site router may need two > >>conceptual routing tables (one global, one site). I have begun implementing one. And it does require having multiple "conceptual" routing tables. The reason for this is that on a site boundary router, the zone IDs per interface determine which interfaces are in each zone. Since the site-local addresses do not contain any of this information, the routing table needs to enforce the separation. For example, a router that is a border between site A and site B may find that it has entries for FEC0:0:0:ABCD:: in both sites. If that is the case, they can only be distinguished via the zone IDs assigned to sites A and B. This can be implemented as either separate route tables per site or by including the zone ID in the route table lookup. > >> > >>Also, some of the scoped addressing architecture assumptions only work > >>if sites are "convex" (Steve's word). Unfortunately, that assumption > >>is not yet documented and the word "convex" has no currently defined > >>meaning in terms of routing -- even though we understand what it means. > >>Also, topologies change. So, what happens if a site becomes > >>"concave"? So, I am partly at fault for not getting that text into the architecture draft. My working definition for a convex site is that for any two points within the site, the shortest path between the points never leaves the site. As for topology changes, an event that turns a site from convex to concave can be treated in the same manner as an event that fragments a network. > >> > >>There is wording in a variety of IPv6 specs talking about how > >>routers should (and shouldn't) pass site-local information, but I haven't > >>looked to see if the current IPv6 routing protocols reflect this > >>information (or even know that they may pass site-local routes). To my knowledge, none of the v6 routing protocol specs have been updated to reflect the information in the scoped address architecture. I think that once the architecture is solidified, we can go and look to see what needs to be done in the routing specs. > >> > >>Since there doesn't have to be a one-to-one mapping between sites > >>and ASes, I need to figure out if there are any problems with propagating > >>site information when a site contains two (or more) ASes or when two > >>(or more, or parts of multiple) sites are contained in a single OSPF > >>AS. I have no clue how this would work yet... > >> > >>(3) IPv6 anycast is substantially different from the anycast hacks > >>currently used in IPv4. One big difference: a global IPv6 anycast > >>address would (probably?) not appear to be inside of anyone's AS. > >>I don't know if this causes problems, as I haven't had time to look > >>at how OSPF would handle a host route injection for a router outside > >>the AS. From discussions I have had, I don't think there is much interest in global anycast. The proposals I have heard have been for using anycast within domains, so that the anycast address gets aggregated into the global prefix for that domain. > >> > >>And, despite the fact that we are specifying the use of site-local > >>anycast addresses in documents (like Dave Thaler's DNS stuff), we > >>don't actually know what a site-local anycast would look like. The > >>latest verbal possibilities from Steve seem to indicate that we might > >>artificially reserve one of the subnet numbers (all zeros or all > >>ones?) as an area to assign site-local anycast addresses. If so, > >>the routing might be okay...? > >> > >>However, the IPv4 stuff has only been tried with BGP. Do we know for > >>sure that the OSPF tree will converge if it thinks that one host is > >>actually located at two different places in the topology? Maybe this > >>would just work -- I don't know OSPF well enough to know for sure > >>without closely reviewing the spec (or maybe trying it). > >> > >>Also, since a site doesn't actually map to an AS, and may not be > >>handled by a single routing protocol (i.e. it may be running OSPF > >>between some RIP networks, or something?), then it isn't clear > >>exactly where and how you would "inject" a route into the routing > >>system (or whatever loose wording we're using) and be sure that > >>it would propogated to the entire site... > >> > >>(4) The current IPv6 routing table MIBs are based on the IPv4 > >>routing MIBs. It isn't clear if they will be able to properly > >>handle IPv6 routing tables, as they may be different. Once we > >>figure out the architecture and conceptual datastructures, I will > >>closely review the MIBs to see if they match. There are updates in the works on the v6 MIBs. One of the topics being discussed is the structure of the routing table MIB. Take a look at http://www.aciri.org/fenner/mibs/v6/ Brian From owner-multi6@ops.ietf.org Mon Aug 13 11:16:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21878 for ; Mon, 13 Aug 2001 11:16:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WJSe-00019Q-00 for multi6-data@psg.com; Mon, 13 Aug 2001 08:17:00 -0700 Received: from arpa.it.uc3m.es ([163.117.139.120]) by psg.com with esmtp (Exim 3.31 #1) id 15WJSd-00019D-00 for multi6@ops.ietf.org; Mon, 13 Aug 2001 08:16:59 -0700 Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by arpa.it.uc3m.es (8.9.3/8.9.3) with SMTP id RAA07780; Mon, 13 Aug 2001 17:15:31 +0200 From: "marcelo" To: "Steve Deering" , "Ben Black" , "Vijay Gill" , "Joe Abley" Cc: Subject: RE: comments on requirements draft Date: Mon, 13 Aug 2001 17:14:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >3.1.4 Policy > > > > A customer may choose to multihome for a variety of policy reasons > > outside technical scope (e.g. cost, acceptable use conditions, etc.) > ^ > the? > > > For example, customer C homed to ISP A may wish to shift traffic of a > > certain class or application, NNTP, for example, to ISP B as matter > > of policy. A new IPv6 multihoming proposal must provide support for > > multihoming for external policy reasons. > > Inbound only? Outbound only? Both? This requirement seems excessive > to me, e.g., if end systems ESP encrypt their traffic, how can the > network recognize NNTP traffic? Perhaps it may be interesting to distinguish between internally initiated comunications (comunications iniiated by a host from the MH site) and externally initiated comunication (comunications initated by a host not belonging to the MH site) marcelo From owner-multi6@ops.ietf.org Mon Aug 13 11:34:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22245 for ; Mon, 13 Aug 2001 11:34:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WJkO-0001WH-00 for multi6-data@psg.com; Mon, 13 Aug 2001 08:35:20 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.31 #1) id 15WJkO-0001Vl-00 for multi6@ops.ietf.org; Mon, 13 Aug 2001 08:35:20 -0700 Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.11.4/8.11.4) with ESMTP id f7DFYmH08522; Mon, 13 Aug 2001 17:34:48 +0200 Received: (from shane@localhost) by x17.ripe.net (8.10.2/8.10.2) id f7DFYmW03544; Mon, 13 Aug 2001 17:34:48 +0200 Date: Mon, 13 Aug 2001 17:34:48 +0200 From: Shane Kerr To: mpy@ieee.org Cc: multi6@ops.ietf.org Subject: MHTP draft (draft-py-multi6-mhtp-00.txt) Message-ID: <20010813173448.G3106@x17.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-multi6@ops.ietf.org Precedence: bulk Nit-picks: - I assume that DFZ is the "Default-Free Zone". Perhaps you should define it in the document, so I don't have to guess which of the 9 documents referenced contains it? Basic Questions: - How is it possible for a router to know when it is an "end router"? Is it necessary? Can a router act as an end router for some hosts but not others? - It appears every multihomed site must carry the entire (single-homed) DFZ, the same as in current BGP multihoming. While hopefully the DFZ will be much smaller, is this indeed the case? - Is the keepalive mechanism intended to avoid the problem of losing a connection when the single-home connection goes down? Since the multi-home to single-home mapping occurs only once, certain kinds of transport failure will kill active sessions (whether they be TCP or UDP "sessions"), correct? Won't the extra traffic be a problem with this? Fundamental Questions: - It seems like this protocol won't scale. I may not understand it fully, but while creating a second routing table with fixed length prefixes is an optimization, it still won't solve the problem when every home on earth wants to multihome, because you'll need millions (or billions!) of entries in the MHTP route table. I presume that this is what the "rendezvous point" model is intended to deal with, but won't the rendezvous points themselves be overloaded then? - Since this is fundamentally a translation, why not get further benefit of distribution and do the mapping at the hosts rather than on a router? The problems with NAT (state in the network) are definately present here, and I don't know if 6.2.[12] fully address this. For instance, what happens if my router bounces? What happens if my closest router changes? -- Shane From owner-multi6@ops.ietf.org Mon Aug 13 14:26:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26622 for ; Mon, 13 Aug 2001 14:26:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WMMp-0003Y3-00 for multi6-data@psg.com; Mon, 13 Aug 2001 11:23:11 -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.31 #1) id 15WMMo-0003Xh-00 for multi6@ops.ietf.org; Mon, 13 Aug 2001 11:23:10 -0700 Subject: RE: MHTP draft (draft-py-multi6-mhtp-00.txt) Date: Mon, 13 Aug 2001 11:22:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046403D2B1@server2000.arneill-py.sacramento.ca.us> X-Mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: MHTP draft (draft-py-multi6-mhtp-00.txt) Thread-Index: AcEkDwklOpAQqNSeQ+iosrLwLGS/rQAFYu5w From: "Michel Py" To: "Shane Kerr" Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA26622 Shane, Some of your questions have been adressed in the not-yet-published -01 available here: http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt I encourage everyone to refer to the -01 text instead of the -00. >> I assume that DFZ is the "Default-Free Zone". Perhaps you should >> define it in the document, so I don't have to guess which of the 9 >> documents referenced contains it? Thanks for the suggestion. I also acknowledge that I need to polish the references in the text. >> How is it possible for a router to know when it is an "end router"? By static configuration, no more than a very few lines. >> Is it necessary? Not every router needs to be an MHTP client. As a matter of fact, small customers with stub networks should not do anything regarding MHTP and send untranslated multihomed traffic to their ISP. >> Can a router act as an end router for some hosts but not others? There is no specific provision for that, could you give me an example of why it would be nice to have? >> It appears every multihomed site must carry the entire (single-homed) >> DFZ, the same as in current BGP multihoming. While hopefully the DFZ >> will be much smaller, is this indeed the case? This is indeed the case, and will produce signinficant gains if the IPv6 DFZ stays strongly summarized, which is the way it was designed. >> Is the keepalive mechanism intended to avoid the problem of losing a >> connection when the single-home connection goes down? Yes. >> Since the multi-home to single-home mapping occurs only once It happens each time traffic to an a prefix is unknown in the translation table for a specific router and is refreshed periodically. >> certain kinds of transport failure will kill active sessions (whether they be TCP or >> UDP "sessions"), correct? Depending on the duration of the failure, yes. However, this is currently the case with BGP, and I expect MHTP to be much more survivable for open sessions than a BGP reconvergence as it happens today. >> Won't the extra traffic be a problem with this? There is a balance to find between increasing the frequency of keepalives and the amount of extra traffic caused by active sessions that died trying to reconnect. Let's say that if the keepalives are set to twice a second, hardly any session would die, but it will nail the endpoints. >> It seems like this protocol won't scale. I may not understand it >> fully, but while creating a second routing table with fixed length >> prefixes is an optimization, it still won't solve the problem when >> every home on earth wants to multihome, because you'll need millions >> (or billions!) of entries in the MHTP route table. I presume that >> this is what the "rendezvous point" model is intended to deal with, >> but won't the rendezvous points themselves be overloaded then? Let's say it will scale better, and you are completely correct here. As mentionned in the -01, this is part of the design. The idea is double: 1. Keep the IPv6 DFZ cleanly summarized. 2. Give time to someone to invent the perfect IPv6 multihoming solution. >> Since this is fundamentally a translation, why not get further benefit >> of distribution and do the mapping at the hosts rather than on a >> router? The problems with NAT (state in the network) are definately >> present here, and I don't know if 6.2.[12] fully address this. For >> instance, what happens if my router bounces? What happens if my >> closest router changes? In either case the host should see only increased latency for the very first packets immediatly after the topology change. Thanks, Michel. From owner-multi6@ops.ietf.org Tue Aug 14 13:22:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11018 for ; Tue, 14 Aug 2001 13:22:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WhsZ-000OiR-00 for multi6-data@psg.com; Tue, 14 Aug 2001 10:21:23 -0700 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.31 #1) id 15WhsY-000OiK-00 for multi6@ops.ietf.org; Tue, 14 Aug 2001 10:21:22 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f7EHLBd09453; Tue, 14 Aug 2001 20:21:13 +0300 Date: Tue, 14 Aug 2001 20:21:10 +0300 (EEST) From: Pekka Savola To: Michel Py cc: Subject: RE: MHTP draft (draft-py-multi6-mhtp-00.txt) In-Reply-To: <2B81403386729140A3A899A8B39B046403D2B1@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 13 Aug 2001, Michel Py wrote: > Some of your questions have been adressed in the not-yet-published -01 > available here: > > http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt Isn't this what we wanted to avoid with IPv6? :-) I believe Steve Deering would be tearing his hair by now :-) Does this work properly if a router between to MHTP points notices hop count has reached zero, and emits ICMP TTL expired to the source? (if the TTL failure is delivered to the end node properly, the headers in ICMP payload would have to be translated too. ICMP by intermediate nodes is not the only issue with NAT techniques like this. I fear this might have unforeseen consequences. I'm also a bit unsure whether this just moves the multihoming problem to a separate table, where it would be contained until some new mechanisms are developed. Some improvements are naturally made, but I fear the all the effects couldn't be properly analyzed and planned beforehand. I have think _some_ multihoming methods will be developed before the number of "multihomed prefixes", were there not filtering, would reach critical bounds (perhaps 5 years, who knows). If this kind of scenario ("race against time") is sought, perhaps just a separate prefix, allocated to multihomed sites (and they would also have a primary prefix), would be sufficient. The prefix wouldn't be aggregated as strictly. I believe the thought has already been mentioned. This way, "99.5%" or the like would always be reachable through strictly aggregated DFZ, and people who care about multihoming could play around with the other prefix until it "explodes" or better ways are made up. -- 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 Aug 14 16:43:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14747 for ; Tue, 14 Aug 2001 16:43:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Wl1z-0001We-00 for multi6-data@psg.com; Tue, 14 Aug 2001 13:43:19 -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.31 #1) id 15Wl1y-0001WV-00 for multi6@ops.ietf.org; Tue, 14 Aug 2001 13:43:18 -0700 Subject: RE: MHTP draft (draft-py-multi6-mhtp-00.txt) Date: Tue, 14 Aug 2001 13:43:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AD15@server2000.arneill-py.sacramento.ca.us> X-Mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: RE: MHTP draft (draft-py-multi6-mhtp-00.txt) Thread-Index: AcElAbsbzRxlqtrbQgm9/PC9pih+6A== From: "Michel Py" To: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA14747 Pekka, Thank you for your contribution. Refers to: http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt >> If this kind of scenario >> ("race against time") is sought, perhaps just a separate prefix, allocated >> to multihomed sites (and they would also have a primary prefix), would be >> sufficient. The prefix wouldn't be aggregated as strictly. I believe the >> thought has already been mentioned. This way, "99.5%" or the like would >> always be reachable through strictly aggregated DFZ, and people who care >> about multihoming could play around with the other prefix until it >> "explodes" or better ways are made up. A separate prefix for multihomed sites would be a good step to matter what. MHTP goes one step further by moving that separate prefix out of the routers that needs to process large amounts of data to MHTP rendezvouspoints that are limited proxies. >> Isn't this what we wanted to avoid with IPv6? :-) I believe Steve Deering >> would be tearing his hair by now :-) I, for sure, would be interested in reading Dr. Deering's comments. I am a strong supporter of a strictly aggregated DFZ, and it is one of MHTP's goals: keep the DFZ strictly aggregated by moving the multihomed prefixes that do not belong there somewhere else. In the case of a reserved prefix for multihomed sites, these prefixes would still be in the DFZ's routing table. >> Does this work properly if a router between to MHTP points notices hop >> count has reached zero, and emits ICMP TTL expired to the source? (if the >> TTL failure is delivered to the end node properly, the headers in ICMP >> payload would have to be translated too. I don't see any issues here. If the source prefix is singlehomed, the TTL failure would naturally go back to the source node. If the source prefix is multihomed, it will at some point hit an MHTP enabled router. Thanks for bringing that point, it makes me think that ICMP error packets might not be subject to proxying limits on MHTP rendezvouspoints. >> ICMP by intermediate nodes is not the only issue with NAT techniques like >> this. I fear this might have unforeseen consequences. As far as I know, MHTP is the first protocol that reverses the NAT at the end and leaves end-to-end traffic unchanged, and that will take care of most of the NAT-related issues. >> I'm also a bit unsure whether this just moves the multihoming problem to a >> separate table, where it would be contained until some new mechanisms are >> developed. Some improvements are naturally made, but I fear the all the >> effects couldn't be properly analyzed and planned beforehand. Agreed, and I think that now is a better time to find out the unforeseen consequences and not in 5 years when the race over time might have been lost. >> I have think _some_ multihoming methods will be developed before the >> number of "multihomed prefixes", were there not filtering, would reach >> critical bounds (perhaps 5 years, who knows). You are making my point here. Everyone assumes that a good solution will be available when we need it. In the meantime, some people are or will be reluctant to implement IPv6 until a good solution is found. MHTP is not a good solution for IPv6 multihoming, but I think it is a good contingency plan. What is wrong in developping a contingency plan before it is needed? Michel. From owner-multi6@ops.ietf.org Tue Aug 14 17:25:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15442 for ; Tue, 14 Aug 2001 17:25:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Wlhk-0002EF-00 for multi6-data@psg.com; Tue, 14 Aug 2001 14:26:28 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.31 #1) id 15Wlhj-0002E8-00 for multi6@ops.ietf.org; Tue, 14 Aug 2001 14:26:27 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f7ELQGm10785; Wed, 15 Aug 2001 00:26:16 +0300 Date: Wed, 15 Aug 2001 00:26:15 +0300 (EEST) From: Pekka Savola To: Michel Py cc: Subject: RE: MHTP draft (draft-py-multi6-mhtp-00.txt) In-Reply-To: <2B81403386729140A3A899A8B39B046403D2BB@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 14 Aug 2001, Michel Py wrote: > >> Does this work properly if a router between to MHTP points notices > hop > >> count has reached zero, and emits ICMP TTL expired to the source? > (if the > >> TTL failure is delivered to the end node properly, the headers in > ICMP > >> payload would have to be translated too. > > I don't see any issues here. If the source prefix is singlehomed, the > TTL failure would naturally go back to the source node. > > If the source prefix is multihomed, it will at some point hit an MHTP > enabled router. Thanks for bringing that point, it > > makes me think that ICMP error packets might not be subject to proxying > limits on MHTP rendezvouspoints. To clarify (and elaborate a bit), Well, basically you'd have to analyze all the possible packets routers between two MHTP points could send. For some of these, there might have to be payload address translation. You might not always know the format of the data there (though, e.g. for ICMP, this should be rather straightforward ... but what if you're using e.g. additional headers (e.g. routing) where more are stored, ...). > the end and leaves end-to-end traffic unchanged, and > that will take care of most of the NAT-related issues. Of end-to-end traffic, yes. But as noted, ICMP and friends are not necessarily end-to-end, rather end-to-some_router (if one assumes that ICMP generated by a MHTP router should be transmitted and translated all the way back to the originating node), there might be some similar "evilness". > You are making my point here. Everyone assumes that a good solution will > be available when we need it. In the meantime, some > > people are or will be reluctant to implement IPv6 until a good solution > is found. MHTP is not a good solution for IPv6 > > multihoming, but I think it is a good contingency plan. What is wrong in > developping a contingency plan before it is needed? Yes, especially business people might be reluctant (or, some might say, this might give them a good excuse for not considering IPv6 yet!) -- one might not take IPv6 seriously if multihoming is not possible. I'm pretty certain some contingency plans will be made, whether sanctioned by IETF/IESG or not; this is a tough problem and can't be solved overnight. But one you're proposing makes fundamental changes to the way people regard IP routing (one might consider it as a kind of lightweight "MPLS over IP" I suppose), and it may not be thought as a "clean enough" contingency plan. And there is also an issue of opening a can of worms, so to speak. If this was taken to use, you would need very strong applicability statements and whatever, so that people wouldn't think IETF is advocating a certain kind of network design, protocol layering hacks, etc. This might be a start of a landslide in IPv6 world. (I wasn't around when NAT was introduced to IETF the first time. I wonder how people felt what was coming then.) If there is more interest in this, I think it might be useful to briefly study the tunneling mechanism too. That is viewed generally as a more acceptable approach, and it's (mis)features have been more widely experienced already. -- 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 Aug 14 18:51:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16574 for ; Tue, 14 Aug 2001 18:51:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Wn2L-0003ZV-00 for multi6-data@psg.com; Tue, 14 Aug 2001 15:51:49 -0700 Received: from [194.196.110.15] (helo=mail-gw1.hursley.ibm.com) by psg.com with esmtp (Exim 3.31 #1) id 15Wn2J-0003Y8-00 for multi6@ops.ietf.org; Tue, 14 Aug 2001 15:51:48 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA30732; Tue, 14 Aug 2001 23:51:14 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA26360; Tue, 14 Aug 2001 23:51:14 +0100 Message-ID: <3B79ABD3.D6039F12@hursley.ibm.com> Date: Tue, 14 Aug 2001 17:53:07 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Pekka Savola CC: Michel Py , multi6@ops.ietf.org Subject: Re: MHTP draft (draft-py-multi6-mhtp-00.txt) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: ... > (I wasn't around when NAT was introduced to IETF the first time. I wonder > how people felt what was coming then.) Very scared, and we were right. Brian From owner-multi6@ops.ietf.org Tue Aug 14 19:23:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17015 for ; Tue, 14 Aug 2001 19:23:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WnY4-00046S-00 for multi6-data@psg.com; Tue, 14 Aug 2001 16:24:36 -0700 Received: from [209.233.126.65] (helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.31 #1) id 15WnY3-00045G-00 for multi6@ops.ietf.org; Tue, 14 Aug 2001 16:24:35 -0700 Subject: RE: MHTP draft (draft-py-multi6-mhtp-00.txt) Date: Tue, 14 Aug 2001 16:23:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AD19@server2000.arneill-py.sacramento.ca.us> X-Mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: RE: MHTP draft (draft-py-multi6-mhtp-00.txt) Thread-Index: AcElGBfvXXOYk7HSTAieszB7huF7bg== From: "Michel Py" To: Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA17015 I split the thread into two parts, technical and political. Also, if the WG thinks this is annoying and Pekka and I should discuss the matter privately, please say so. Technical: ---------- Pekka Savola wrote: >> Well, basically you'd have to analyze all the possible packets >> routers between two MHTP points could send. For some of these >> there might have to be payload address translation. You might >> not always know the format of the data there (though, e.g. for >> ICMP, this should be rather straightforward ... but what if >> you're using e.g. additional headers (e.g. routing) where more >> are stored, ...). For most packets, instead of translating something inside the payload, it would be a lot simpler to translate the header back to the way it was when it was sent and MHTP takes care of that. Let's say a TCP packet expires its TTL. It does not make much of a difference if the router sends the "time expired" ICMP message to the multihomed or the corresponding singlehomed source address, either one would reach the host. Could you bring up a specific situation where a router in the middle would have to inspect/translate the payload? >> Of end-to-end traffic, yes. But as noted, ICMP and friends >> are not necessarily end-to-end, rather end-to-some_router or "some_router-to-end" as well >> (if one assumes that ICMP generated by a MHTP router should be >> transmitted and translated all the way back to the originating node) This is the way it works now. The host that sent the traffic is the one that gets back the "Time expired" or "unreachable". >> If there is more interest in this, I think it might be useful to briefly >> study the tunneling mechanism too. That is viewed generally as a more >> acceptable approach, and it's (mis)features have been more widely >> experienced already. My original design was based on tunnels; I detailed in the draft why I moved to NAT. Back to the ICMP TTL expired scenario, a tunnelled solution would not notify the host that originally sent the offending traffic but the router that tunnelled it (unless the router specifically decapsulates the tunnel, a lot of work). Political: ---------- >> there might be some similar "evilness". There will be. Most network protocols have experienced some "evilness" during their development. >> But one you're proposing makes fundamental changes to the >> way people regard IP routing I would not qualify MHTP as "fundamental" as related to IP routing. BGP4 could be optimized for MHTP but does not need to be modified and will still be the one that routes packets over the cloud. >> (one might consider it as a kind of lightweight "MPLS over IP" >> I suppose), and it may not be thought as a "clean enough" >> contingency plan. I am not sure such a comparison could be made. There is a similarity in the sense that the path taken by the traffic is going to be altered at the edge, but MHTP does not add a label to the data. My reading of MPLS is that it is mostly about VPNs and QOS. Packets translated by MHTP have nothing special and could be labelled by MPLS. >> I'm pretty certain some contingency plans will be made, >> whether sanctioned by IETF/IESG or not; this is a tough problem >> and can't be solved overnight. Candid question: Does this workgroup generally think that a contingency plan is a good idea, and should it be sanctionned by the IETF/IESG ? Michel. From owner-multi6@ops.ietf.org Wed Aug 15 10:08:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21424 for ; Wed, 15 Aug 2001 10:08:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1J4-000J64-00 for multi6-data@psg.com; Wed, 15 Aug 2001 07:06:02 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.31 #1) id 15X1J3-000J5x-00 for multi6@ops.ietf.org; Wed, 15 Aug 2001 07:06:01 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f7FE5xW16704 for ; Wed, 15 Aug 2001 17:05:59 +0300 Date: Wed, 15 Aug 2001 17:05:59 +0300 (EEST) From: Pekka Savola To: Subject: RE: MHTP draft (draft-py-multi6-mhtp-00.txt) In-Reply-To: <2B81403386729140A3A899A8B39B046403AD19@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk [strip off Michel Py as the MX isn't reachable from here] On Tue, 14 Aug 2001, Michel Py wrote: > >> Well, basically you'd have to analyze all the possible packets > >> routers between two MHTP points could send. For some of these > >> there might have to be payload address translation. You might > >> not always know the format of the data there (though, e.g. for > >> ICMP, this should be rather straightforward ... but what if > >> you're using e.g. additional headers (e.g. routing) where more > >> are stored, ...). > > For most packets, instead of translating something inside the payload, > it would be a lot simpler to translate the header back to the way it was > when it was sent and MHTP takes care of that. This way all the routers between MHTP endpoints would have to support MHTP, right? I'm not sure if that's an acceptable approach (there are always some plain ipv6 routers that don't..). I thought, perhaps I didn't read carefully enough, that the translation process, "the intelligence", would only be needed at the edges. > Let's say a TCP packet expires its TTL. It does not make much of a > difference if the router sends the "time expired" ICMP message to the > multihomed or the corresponding singlehomed source address, either one > would reach the host. > > Could you bring up a specific situation where a router in the middle > would have to inspect/translate the payload? Perhaps I didn't say this clearly (or maybe didn't understand the workings of MHTP..). What I meant, was something like: multihomed node sends TCP packet [with some additional headers, like routing header] the destination address gets converted by MHTP, the packet is passed on Hop count expires while in transit, the router does not know about MHTP. The router sends back ICMP message to the source address, _but_ the original headers have been added to the ICMP payload as is normal to make the original sender recognize the packet ICMP was generated for. However, the payload address has been translated by MHTP, so the original sender does not recognize the ICMP unless it's de-translated too. You would have to go through all of the ICMP message, looking for things to alter, change addresses and recalculate the checksum. Additional headers, like routing header, might make this even more complicated. This is handled by NATv4, at least to some extent (I'm not sure whether anyone has analyzed how ipv6 extension headers might affect this if there was NATv6), but then the MHTP would have to be fully bidirectional, or..? "Political" side: >>> (one might consider it as a kind of lightweight "MPLS over IP" >>> I suppose), and it may not be thought as a "clean enough" >>> contingency plan. > > I am not sure such a comparison could be made. There is a similarity in > the sense that the path taken by the traffic is going to be altered at > the edge, but MHTP does not add a label to the data. My reading of MPLS > is that it is mostly about VPNs and QOS. Packets translated by MHTP have > nothing special and could be labelled by MPLS. You could think MHTP addressing as MPLS tags (added and removed at the edge), and MHTP routing tables as MPLS LDP. Sure, I didn't say it _is_ MPLS, but there are some resemblances :-) -- 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 Aug 15 11:18:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23426 for ; Wed, 15 Aug 2001 11:18:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X2R6-0000vQ-00 for multi6-data@psg.com; Wed, 15 Aug 2001 08:18:24 -0700 Received: from melimelo.enst-bretagne.fr ([192.108.115.36]) by psg.com with esmtp (Exim 3.31 #1) id 15X2R5-0000u8-00 for multi6@ops.ietf.org; Wed, 15 Aug 2001 08:18:24 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f7FFHe819415; Wed, 15 Aug 2001 17:17:40 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA19431; Wed, 15 Aug 2001 17:17:39 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f7FFHcl04334; Wed, 15 Aug 2001 17:17:38 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108151517.f7FFHcl04334@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: RJ Atkinson , multi6@ops.ietf.org Subject: Re: 64-bit identifiers In-reply-to: Your message of Mon, 13 Aug 2001 10:35:36 +0200. Date: Wed, 15 Aug 2001 17:17:38 +0200 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: The transport multihoming, SCTP, and GxSE seem to all be based on the identifier being a *set of* IP addresses, where the set is determined when the communcation is initiated. I think this is a very interesting space to continue to explore to understand the differences between the ideas/proposals. Such approaches would need a separate mechanism for handling renumbering of long-lived connections since that would require securely changing the set. (But my gut feel is that whatever secure solution we are confortable for Mobile IPv6 binding updates effectively "redirecting" traffic, can be applied to changes in the set of addresses identifying the connection.) => low overhead (i.e. BAKE, SUCV) proposals won't apply (no home agent), higher overhead (i.e. IKE, HIP) proposals provide the required security level but rely on a global PKI... I really don't know what is the worst: to accept MITM attacks or to wait for DNSSEC? Has the NSRG explored using sets of IP addresses as the indentifiers? Or are they focused on the issues of inventing a new name space? => obviously HIP & co follows the second (a new name space with crypto properties which give opportunistic modes for security). Regards Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Wed Aug 15 11:33:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23824 for ; Wed, 15 Aug 2001 11:33:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X2fH-0001DF-00 for multi6-data@psg.com; Wed, 15 Aug 2001 08:33:03 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.31 #1) id 15X2fG-0001D1-00 for multi6@ops.ietf.org; Wed, 15 Aug 2001 08:33:02 -0700 Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.11.4/8.11.4) with ESMTP id f7FFWUH11776; Wed, 15 Aug 2001 17:32:30 +0200 Received: (from shane@localhost) by x17.ripe.net (8.10.2/8.10.2) id f7FFWUq10931; Wed, 15 Aug 2001 17:32:30 +0200 Date: Wed, 15 Aug 2001 17:32:30 +0200 From: Shane Kerr To: Francis Dupont Cc: multi6@ops.ietf.org Subject: Re: 64-bit identifiers Message-ID: <20010815173230.A10927@x17.ripe.net> References: <200108151517.f7FFHcl04334@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108151517.f7FFHcl04334@givry.rennes.enst-bretagne.fr>; from Francis.Dupont@enst-bretagne.fr at 2001-08-15 17:17:38 +0200 Sender: owner-multi6@ops.ietf.org Precedence: bulk On 2001-08-15 17:17:38 +0200, Francis Dupont wrote: > > => low overhead (i.e. BAKE, SUCV) proposals won't apply (no home > agent), higher overhead (i.e. IKE, HIP) proposals provide the required > security level but rely on a global PKI... I really don't know what is > the worst: to accept MITM attacks or to wait for DNSSEC? MITM seems like a problem that multi6 doesn't have to solve. If a "gang-of-IP's" protocol is used, as long as it doesn't preclude host authentication for users/admins/hosts/protocols that care about it, then solving the problems of redundacy and load sharing seem like the thing to worry about. I think most businesses today would be happy with an anonymous end-to-end connection since they rely on web certs for their only authentication in the current Internet. I'm not saying this is a good thing, but again, not one that multi6 needs to address. -- Shane From owner-multi6@ops.ietf.org Wed Aug 15 13:18:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26776 for ; Wed, 15 Aug 2001 13:18:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X4Jf-0003wo-00 for multi6-data@psg.com; Wed, 15 Aug 2001 10:18:51 -0700 Received: from melimelo.enst-bretagne.fr ([192.108.115.36]) by psg.com with esmtp (Exim 3.31 #1) id 15X4Je-0003wG-00 for multi6@ops.ietf.org; Wed, 15 Aug 2001 10:18:50 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f7FHII815705; Wed, 15 Aug 2001 19:18:18 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA20040; Wed, 15 Aug 2001 19:18:17 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f7FHIHl05041; Wed, 15 Aug 2001 19:18:17 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108151718.f7FHIHl05041@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Shane Kerr cc: multi6@ops.ietf.org Subject: Re: 64-bit identifiers In-reply-to: Your message of Wed, 15 Aug 2001 17:32:30 +0200. <20010815173230.A10927@x17.ripe.net> Date: Wed, 15 Aug 2001 19:18:17 +0200 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: On 2001-08-15 17:17:38 +0200, Francis Dupont wrote: > > => low overhead (i.e. BAKE, SUCV) proposals won't apply (no home > agent), higher overhead (i.e. IKE, HIP) proposals provide the required > security level but rely on a global PKI... I really don't know what is > the worst: to accept MITM attacks or to wait for DNSSEC? MITM seems like a problem that multi6 doesn't have to solve. => yes and no, look at below. If a "gang-of-IP's" protocol is used, as long as it doesn't preclude host authentication for users/admins/hosts/protocols that care about it, then solving the problems of redundacy and load sharing seem like the thing to worry about. => this is the point and this is not so easy. Today IPsec (i.e. security in the network layer) and any "gang-of-IP's" protocol (as we can see with address based mobility protocols like MIPv6) are fighting together with very bad consequences: - a lot of crypto stuff already done for IPsec will be redone (a real concern if we'd like to get correct crypto) - people will make bad assumptions about security level - IPsec will remain "orthogonal" and it use expensive Summary: people won't pay the extra cost for IPsec when a high security level will be needed. What we need is integration of some IPsec basic mechanisms into the "gang-of-IP's" protocol in order to provide reliable security with for a minimal extra cost (i.e. in the key management only) the optional & high security level given by IPsec. I think most businesses today would be happy with an anonymous end-to-end connection => this will be the job of "opportunistic" modes. since they rely on web certs for their only authentication in the current Internet. I'm not saying this is a good thing, but again, not one that multi6 needs to address. => I'd like to get both some flexibility for multi6/mipv6/... and security levels required by policies. I don't want to get only one or to do things (like tunneling) twice. It seemed there were many conflicts between multihoming/mobility and security areas but HIP has shown the things are changing! Regards Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Thu Aug 16 05:00:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26552 for ; Thu, 16 Aug 2001 05:00:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15XJ04-000Pmr-00 for multi6-data@psg.com; Thu, 16 Aug 2001 01:59:36 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.31 #1) id 15XJ03-000Pml-00; Thu, 16 Aug 2001 01:59:35 -0700 From: Masataka Ohta Message-Id: <200108160849.RAA09833@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA09833; Thu, 16 Aug 2001 17:49:19 +0900 Subject: Re: OT: prefix length used by backbone routers In-Reply-To: from Randy Bush at "Aug 10, 2001 08:43:41 am" To: Randy Bush Date: Thu, 16 Aug 2001 17:49:18 +0859 () CC: Multi6 Working Group X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Randy; > > Are you saying there is no fixed boundary at /48 even in the > > backbone? > > yes, that is what i am saying. the /48 boundary is soft, and is only for > fp=001. we should not hard code the equivalent of A/B/C in routers again. Then, is multihoming proposal using a particular addressing structure acceptable? I guess an idea initiaed multi6 BoF was, though broken, the case. > >>> Though who want to sell value-added (such as MPLS) routers may > >>> disagree, it is important for low-cost high-speed Internet. > >> i suspect the days of forwarding lookup speed problems are past us > > I'm afraind you are assuming maximum router speed as slow as 10Gps. > > no i am not. i am presuming that the forwarding lookup will continue to > keep up with line speeds. The problem is that, due to the difficulties of high bandwidth low latency inter-chip communication, routing engine core will be on a single chip, capacity of which is, for the time being, limited. Masataka Ohta From owner-multi6@ops.ietf.org Thu Aug 16 11:11:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11813 for ; Thu, 16 Aug 2001 11:11:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15XOo0-0008Ra-00 for multi6-data@psg.com; Thu, 16 Aug 2001 08:11:32 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.31 #1) id 15XOo0-0008RU-00 for multi6@ops.ietf.org; Thu, 16 Aug 2001 08:11:32 -0700 Received: from bebop.France.Sun.COM ([129.157.179.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28585; Thu, 16 Aug 2001 09:11:22 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7GFBI206115; Thu, 16 Aug 2001 17:11:18 +0200 (MET DST) Date: Thu, 16 Aug 2001 17:08:29 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Fwd: Re: note from the iesg plenary To: Brian Haberman Cc: Margaret Wasserman , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <3B77D1CD.39A66815@americasm06.nt.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > So, I am partly at fault for not getting that text into the architecture > draft. My working definition for a convex site is that for any two > points within the site, the shortest path between the points never > leaves the site. Brian, I can see odd cases where using global addresses the traffic would indeed leave the site, whereas using site-local address it might not. So shouldn't the definition be related to the addresses used? Or is there a concern related to a global destination (routed on a path that goes outside) and a site-local source, which would cause the packet to be dropped at the border? Erik From owner-multi6@ops.ietf.org Thu Aug 16 11:18:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12271 for ; Thu, 16 Aug 2001 11:18:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15XOub-0008fA-00 for multi6-data@psg.com; Thu, 16 Aug 2001 08:18:21 -0700 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.31 #1) id 15XOub-0008ez-00 for multi6@ops.ietf.org; Thu, 16 Aug 2001 08:18:21 -0700 Received: from bebop.France.Sun.COM ([129.157.179.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06691; Thu, 16 Aug 2001 08:18:19 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7GFIA206537; Thu, 16 Aug 2001 17:18:10 +0200 (MET DST) Date: Thu, 16 Aug 2001 17:15:21 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 64-bit identifiers To: Francis Dupont Cc: Erik Nordmark , RJ Atkinson , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <200108151517.f7FFHcl04334@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > => low overhead (i.e. BAKE, SUCV) proposals won't apply (no home agent), While there is not an agent per se, there is a notion of a home which is the previous set of prefixes. In a sense each node is its own home agent. Thus the ability to use return routability as an authorization check for e.g. BAKE can be used to handle attacks from attackers that are not on the path. Erik From owner-multi6@ops.ietf.org Thu Aug 16 13:35:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16922 for ; Thu, 16 Aug 2001 13:35:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15XR3v-000Co7-00 for multi6-data@psg.com; Thu, 16 Aug 2001 10:36:07 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.31 #1) id 15XR3t-000Clf-00 for multi6@ops.ietf.org; Thu, 16 Aug 2001 10:36:06 -0700 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7GHZ9p20274 for ; Thu, 16 Aug 2001 13:35:10 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 16 Aug 2001 13:35:08 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q5Y45P75; Thu, 16 Aug 2001 13:35:07 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5NB8J; Thu, 16 Aug 2001 13:35:08 -0400 Message-ID: <3B7C0445.5748EDB7@americasm06.nt.com> Date: Thu, 16 Aug 2001 13:35:01 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Margaret Wasserman , multi6@ops.ietf.org Subject: Re: Fwd: Re: note from the iesg plenary References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Erik Nordmark wrote: > > > So, I am partly at fault for not getting that text into the architecture > > draft. My working definition for a convex site is that for any two > > points within the site, the shortest path between the points never > > leaves the site. > > Brian, > > I can see odd cases where using global addresses the traffic would > indeed leave the site, whereas using site-local address it might not. > So shouldn't the definition be related to the addresses used? Correct, it should be in terms of the scope of the addresses being used. > > Or is there a concern related to a global destination (routed on > a path that goes outside) and a site-local source, which would cause the > packet to be dropped at the border? I know that this subject has been discussed several times. I believe the scenario that Margaret is concerned about is based on this diagram she posted to IPNG several months ago (correct me if I am wrong, Margaret): ========================================================== SITEA Host1 Host2 | | ______._|_________ ___.______._|_____________ Link1 | | | Link2 | (down) | | | | |+-----------------+ | || | ============R1========================R3=================== SITEB | | | | _____|_________________________|________________ Link3 =========================================================== If Host1 is using site-locals, then Host2 can't be reached and R1 cannot return any info that is very useful to Host1 other than a Destination Unreachable message. If Host1 uses a global destination address and a site-local source address, R1 returns a Scope Exceeded message even though Host2 is in the same site as Host1. Brian From owner-multi6@ops.ietf.org Fri Aug 17 02:21:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20199 for ; Fri, 17 Aug 2001 02:21:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Xczj-0007dc-00 for multi6-data@psg.com; Thu, 16 Aug 2001 23:20:35 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15Xczi-0007dV-00 for multi6@ops.ietf.org; Thu, 16 Aug 2001 23:20:34 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id XAA24167 for ; Thu, 16 Aug 2001 23:20:30 -0700 (PDT) Date: Thu, 16 Aug 2001 23:20:30 -0700 (PDT) From: Ramakrishna Gummadi To: Subject: Requirements draft status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, I have two questions: 1) Can someone tell me what the current status of the multi6 requirements draft is? Was any consensus reached during the ietf meeting? (It would be great if someone could send out the minutes.) 2) Is there any requirement on multicast with respect to multihoming? I think a host-level solution will make achieving scalable multihoming very hard... thanks, ramki From owner-multi6@ops.ietf.org Fri Aug 17 12:21:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07199 for ; Fri, 17 Aug 2001 12:21:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15XmLW-000OE0-00 for multi6-data@psg.com; Fri, 17 Aug 2001 09:19:42 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.31 #1) id 15XmLV-000OBo-00 for multi6@ops.ietf.org; Fri, 17 Aug 2001 09:19:42 -0700 Subject: RE: MHTP draft (draft-py-multi6-mhtp-00.txt) Date: Fri, 17 Aug 2001 09:18:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046403AD2A@server2000.arneill-py.sacramento.ca.us> X-Mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: MHTP draft (draft-py-multi6-mhtp-00.txt) Thread-Index: AcEm4cWXSDo6iZFbREmxmvHXPj1dLAARc45w From: "Michel Py" To: "Pekka Savola" Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA07199 Pekka Savola wrote: >> [strip off Michel Py >> as the MX isn't reachable from here] Tell me about it. 48-hour DNS nightmare. I apologize for the inconvenience (although none of my doing). It appears to be back and I will soon have THREE DNS servers.... >> This way all the routers between MHTP endpoints would have to support >> MHTP, right? I'm not sure if that's an acceptable approach (there are >> always some plain ipv6 routers that don't..). No they would not, see below. >> I thought, perhaps I didn't read carefully enough, that the translation >> process, "the intelligence", would only be needed at the edges. Yes. If a router in the middle is not MHTP-aware and has to deal with multihomed traffic, it will send it wherever the aggregates to the multihomed space point to, which is the closest MHTP rendezvous point. Note that this is sub-optimal path, and hitting the MHTP rendezvous point is acceptable in some situations only. (initial deployment and ICMP error messages and some other). >> multihomed node sends TCP packet [with some additional headers, >> like routing header] It does not matter if the node that sends the packet is multihomed or not. What matters is if the destination address is multihomed, because this is what is translated by MHTP. >> the destination address gets converted by MHTP, the packet is >> passed on. Hop count expires while in transit, the router does >> not know about MHTP. Even if it does, it does not know about the translation table in the router that originally sent the traffic, so it does not know the original source address (before it was translated) and it would not be able to translate the payload no matter what. THis issue is similar as IPv4 NAT, not all routers in the path need to support it. >> The router sends back ICMP message to the source address, _but_ the >> original headers have been added to the ICMP payload as is normal to >> make the original sender recognize the packet ICMP was generated for. >> However, the payload address has been translated by MHTP, so the >> original sender does not recognize the ICMP unless it's de-translated >> too. Correct. >> You would have to go through all of the ICMP message, looking for things >> to alter, change addresses and recalculate the checksum. Correct again, and the place to do that is definitely the MHTP client that made the original translation. I am grateful that you brought the issue, because there needs to be special handling of ICMP messages that hit an MHTP client, and I have not reached that point in the draft. >> Additional headers, like routing header, might make this even more >> complicated. Evilness. >> This is handled by NATv4, at least to some extent (I'm not sure whether >> anyone has analyzed how ipv6 extension headers might affect this if there >> was NATv6), but then the MHTP would have to be fully bidirectional, or..? In that situation, MHTP is definitely a one-way NAT, and it does need to be handled. I do not intend to re-invent the wheel and I think the best approach here is to follow what the folks that design IPv6 NAT do. Thanks Michel. From owner-multi6@ops.ietf.org Fri Aug 17 12:24:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07309 for ; Fri, 17 Aug 2001 12:24:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15XmQc-000OME-00 for multi6-data@psg.com; Fri, 17 Aug 2001 09:24:58 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.31 #1) id 15XmQb-000OM8-00 for multi6@ops.ietf.org; Fri, 17 Aug 2001 09:24:57 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f7HGOmx14495; Fri, 17 Aug 2001 19:24:48 +0300 Date: Fri, 17 Aug 2001 19:24:48 +0300 (EEST) From: Pekka Savola To: Michel Py cc: Subject: RE: MHTP draft (draft-py-multi6-mhtp-00.txt) In-Reply-To: <2B81403386729140A3A899A8B39B046403AD2A@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 17 Aug 2001, Michel Py wrote: > >> This is handled by NATv4, at least to some extent (I'm not sure > whether > >> anyone has analyzed how ipv6 extension headers might affect this if > there > >> was NATv6), but then the MHTP would have to be fully bidirectional, > or..? > > In that situation, MHTP is definitely a one-way NAT, and it does need to > be handled. I do not intend to re-invent the wheel and I think the best > approach here is to follow what the folks that design IPv6 NAT do. I really hope "folks that design IPv6 NAT" was a typo or a joke.. :-) ("NATv6? We don't need no stinkin' NATv6!" :) -- 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 Sat Aug 18 00:44:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21870 for ; Sat, 18 Aug 2001 00:44:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Xxwp-0009Ot-00 for multi6-data@psg.com; Fri, 17 Aug 2001 21:42:59 -0700 Received: from mercury.sun.com ([192.9.25.1]) by psg.com with esmtp (Exim 3.31 #1) id 15Xxwo-0009Om-00 for multi6@ops.ietf.org; Fri, 17 Aug 2001 21:42:59 -0700 Received: from bebop.France.Sun.COM ([129.157.179.15]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA05169; Fri, 17 Aug 2001 01:33:00 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7H8WH228579; Fri, 17 Aug 2001 10:32:17 +0200 (MET DST) Date: Fri, 17 Aug 2001 10:29:26 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Fwd: Re: note from the iesg plenary To: Brian Haberman Cc: Erik Nordmark , Margaret Wasserman , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <3B7C0445.5748EDB7@americasm06.nt.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > I know that this subject has been discussed several times. I believe > the scenario that Margaret is concerned about is based on this > diagram she posted to IPNG several months ago (correct me if I am > wrong, Margaret): > > ========================================================== > SITEA > Host1 Host2 > | | > ______._|_________ ___.______._|_____________ > Link1 | | | Link2 > | (down) | > | | | > |+-----------------+ | > || | > ============R1========================R3=================== > SITEB | | > | | > _____|_________________________|________________ > Link3 > > > =========================================================== But I think there is another issue even when the path isn't down. Suppose the metric/preferences on the routes are such that when sending to the global address of H2 from H1 that the packets pass through site B. Then it is even worse since H1 and H2 have both a path inside the site and one outside, but if H1 doesn't have a global source address they will fail to communicate. Thus I think this needs to be captured in the notion of convex - packets sent to a global address in the site can not leave the site. Erik From owner-multi6@ops.ietf.org Sat Aug 18 04:26:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09592 for ; Sat, 18 Aug 2001 04:26:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Y1R2-000CEk-00 for multi6-data@psg.com; Sat, 18 Aug 2001 01:26:24 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.31 #1) id 15Y1R1-000CEZ-00 for multi6@ops.ietf.org; Sat, 18 Aug 2001 01:26:23 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f7I8QLQ19161 for ; Sat, 18 Aug 2001 11:26:21 +0300 Date: Sat, 18 Aug 2001 11:26:20 +0300 (EEST) From: Pekka Savola To: Subject: LIN6 and multihoming (+sec) In-Reply-To: <200108171103.HAA23318@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk [http://www.ietf.org/internet-drafts/draft-teraoka-ipng-lin6-01.txt] As LIN6 was presented at multi6, and I don't know of a better place to comment on this, I guess I'll just post these here.. The fact is that the multihoming support of LIN6 is only limited to single nodes, clearly made cellular mobiles in mind: 3.9. Multi-Homing Support Figure 6 shows multi-homing support in LIN6. In the figure, Node-B is a multi-homing host which has two network interfaces. Node-A and Node-B have the LIN6 generalized ID, "LIN6_P+ID_A" and "LIN6_P+ID_B", respectively, where "LIN6_P" is the LIN6 Prefix, and "ID_A" and "ID_B" are the identifiers of Node-A and Node-B, respectively. Node-A has the LIN6 address, "P_A+ID_A", where "P_A" is the network prefix of Node-A. Node-B has two LIN6 addresses, "P_B1+ID_B" and "P_B2+ID_B", where "P_B1" and "P_B2" are the network prefixes of Node-B corresponding to the two network interfaces. [...] I don't think people generally want to multihome every node, rather multihome a router and provide multihomed connection that way. ID's based on EUI64 aren't possible with this mechanism if there is only one interface on end-nodes (you could just make up the other ID, I suppose, but that would be .. dirty, and no effective means of tracking them unless using some mapping function to generate them). The fact remains that this mechanism does not seem to be fit for real multihoming. Also: [...] 2. Assume that Path_A crashes due to some reason, and ICMP Unreach is returned to Node-A. 3. Node-A knows that Path_A is unavailable and selects "P_B2" as the network prefix of Node-B. Does ICMP Unreachable trigger you to retry connection using a different destination address? IIRC ICMP unreaches are soft errors, and affect nothing. I don't comment on non-multihoming issues, except for the fact that there are no "Security Considerations" in the text. It appears to me that if you use generalized network prefix as e.g. TCP/UDP endpoints, capturing traffic, hijacking connections etc. are bound to be at least potentially easier (as the generalized LIN6 namespace is flat); this puts even more responsibility for the security of DNS and mapping agent functions. -- 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 Sat Aug 18 08:58:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11843 for ; Sat, 18 Aug 2001 08:58:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Y5gc-000Frw-00 for multi6-data@psg.com; Sat, 18 Aug 2001 05:58:46 -0700 Received: from ren-5.cais.net ([205.252.14.80]) by psg.com with esmtp (Exim 3.31 #1) id 15Y5gb-000Frq-00 for multi6@ops.ietf.org; Sat, 18 Aug 2001 05:58:45 -0700 Received: from [63.216.127.98] (63-216-127-98.sdsl.cais.net [63.216.127.98]) by ren-5.cais.net (8.11.1/8.11.1) with ESMTP id f7ICwhx52624; Sat, 18 Aug 2001 08:58:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: hcb@pop3.clark.net Message-Id: In-Reply-To: References: Date: Sat, 18 Aug 2001 08:58:02 -0400 To: From: "Howard C. Berkowitz" Subject: Re: LIN6 and multihoming (+sec) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-multi6@ops.ietf.org Precedence: bulk I'd like to use this comment as a springboard to what might be called a meta-discussion of multihoming requirments. At 11:26 AM +0300 8/18/01, Pekka Savola wrote: >[http://www.ietf.org/internet-drafts/draft-teraoka-ipng-lin6-01.txt] > >As LIN6 was presented at multi6, and I don't know of a better place to >comment on this, I guess I'll just post these here.. > >The fact is that the multihoming support of LIN6 is only limited to single >nodes, clearly made cellular mobiles in mind: > >[snip] > > >I don't think people generally want to multihome every node, rather >multihome a router and provide multihomed connection that way. This is where I partially disagree. Yes, I can understand that it is generally not required to multihome cellular mobile hosts. I hope I may be forgiven for loose terminology if I call them "clients." "Server" hosts, in contrast, very reasonably will be multihomed to routers. Indeed, there may be complex relationships of multiple servers and multiple routers. The mechanism of server to router multihoming will vary with the application. When the multiple routers are on the same subnet as the server, a mechanism as simple as VRRP may suffice, perhaps with multiple VRRP groups for a degree of load-sharing. As the servers and routers become more distributed, some NAT or transport based mechanism may be needed, or the servers may need some awareness of routing. Howard Berkowitz Nortel Networks From owner-multi6@ops.ietf.org Sat Aug 18 09:42:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12713 for ; Sat, 18 Aug 2001 09:42:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Y6O4-000GJk-00 for multi6-data@psg.com; Sat, 18 Aug 2001 06:43:40 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.31 #1) id 15Y6O3-000GJe-00 for multi6@ops.ietf.org; Sat, 18 Aug 2001 06:43:40 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f7IDhZG20625; Sat, 18 Aug 2001 16:43:35 +0300 Date: Sat, 18 Aug 2001 16:43:35 +0300 (EEST) From: Pekka Savola To: "Howard C. Berkowitz" cc: Subject: Re: LIN6 and multihoming (+sec) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 18 Aug 2001, Howard C. Berkowitz wrote: > >I don't think people generally want to multihome every node, rather > >multihome a router and provide multihomed connection that way. > > This is where I partially disagree. Yes, I can understand that it is > generally not required to multihome cellular mobile hosts. I hope I > may be forgiven for loose terminology if I call them "clients." This isn't a point, but there might be some justification for it so... Multihoming cellular clients might be feasible if the underlaying structure is made so that the address would change if they changed their radio base station. Then, when you move to some direction, it might be prudent to start to "prepare way for the handoff" by multihoming with current and the next cell you're moving towards when you're close enough to the edge. > "Server" hosts, in contrast, very reasonably will be multihomed to > routers. Indeed, there may be complex relationships of multiple > servers and multiple routers. > > The mechanism of server to router multihoming will vary with the > application. When the multiple routers are on the same subnet as the > server, a mechanism as simple as VRRP may suffice, perhaps with > multiple VRRP groups for a degree of load-sharing. As the servers > and routers become more distributed, some NAT or transport based > mechanism may be needed, or the servers may need some awareness of > routing. (I'm assuming here that multihoming is done to ensure redundancy. There are other reasons too, of course, but I'll skip them here.) I agree. This depends heavily on how important and costly multihoming is (ie. do you want to also multihome systems that strictly speaking might not need it so much, e.g. workstations vs. critical web-servers). If we can't find a good way to multihome entire sites, it just _might_ (for an intermediate approach, if not else) be sufficient to be able to multihome certain critical systems. The amount of critical systems and how they're located in the site's network topology defines whether "server-based" or "network-based" multihoming is a better alternative (if you actually could do it either way). -- 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 Sat Aug 18 10:35:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13216 for ; Sat, 18 Aug 2001 10:35:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Y7DI-000Gqw-00 for multi6-data@psg.com; Sat, 18 Aug 2001 07:36:36 -0700 Received: from ren-10.cais.net ([205.252.14.85]) by psg.com with esmtp (Exim 3.31 #1) id 15Y7DI-000Gqp-00 for multi6@ops.ietf.org; Sat, 18 Aug 2001 07:36:36 -0700 Received: from [63.216.127.98] (63-216-127-98.sdsl.cais.net [63.216.127.98]) by ren-10.cais.net (8.11.1/8.11.1) with ESMTP id f7IEaYT80068 for ; Sat, 18 Aug 2001 10:36:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: hcb@pop3.clark.net Message-Id: In-Reply-To: References: Date: Sat, 18 Aug 2001 10:36:15 -0400 To: multi6@ops.ietf.org From: "Howard C. Berkowitz" Subject: Re: LIN6 and multihoming (+sec) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-multi6@ops.ietf.org Precedence: bulk >On Sat, 18 Aug 2001, Howard C. Berkowitz wrote: >> >I don't think people generally want to multihome every node, rather >> >multihome a router and provide multihomed connection that way. >> >> This is where I partially disagree. Yes, I can understand that it is >> generally not required to multihome cellular mobile hosts. I hope I >> may be forgiven for loose terminology if I call them "clients." And just to disagree with myself, there might be unusual and critical applications where a mobile "end user" might need high availability, such as a telepresence application in field emergency medicine. In such cases, the question becomes, is "multihomed routing" enough? Certainly multihomed routing protects against certain failures. It wouldn't protect against a failure of the base station for a cell, if both "homings" are to it. It wouldn't protect against a hardware or system software failure of the host. I feel it's important that the requirements make very clear that multihomed routing only protects against certain failure modes. http://www.ietf.org/internet-drafts/draft-berkowitz-multireq-02.txt, which I wrote with Dima Krioukov, and hope to merge with current multi6 requirements, provides pointers to "multihoming" at other layers. > >This isn't a point, but there might be some justification for it so... > >Multihoming cellular clients might be feasible if the underlaying >structure is made so that the address would change if they changed their >radio base station. Then, when you move to some direction, it might be >prudent to start to "prepare way for the handoff" by multihoming with >current and the next cell you're moving towards when you're close enough >to the edge. Especially if the client has GPS and knows its direction, it might be interesting (although annoying to the cellular protocol folk) to introduce a query message that asks "hey, current base station...what cell(s) is northwest of you?" > >> "Server" hosts, in contrast, very reasonably will be multihomed to >> routers. Indeed, there may be complex relationships of multiple >> servers and multiple routers. >> >> The mechanism of server to router multihoming will vary with the >> application. When the multiple routers are on the same subnet as the >> server, a mechanism as simple as VRRP may suffice, perhaps with >> multiple VRRP groups for a degree of load-sharing. As the servers >> and routers become more distributed, some NAT or transport based >> mechanism may be needed, or the servers may need some awareness of >> routing. > >(I'm assuming here that multihoming is done to ensure redundancy. There >are other reasons too, of course, but I'll skip them here.) > >I agree. This depends heavily on how important and costly multihoming is >(ie. do you want to also multihome systems that strictly speaking might >not need it so much, e.g. workstations vs. critical web-servers). Depends on the industry and application. There's no question that a CT or MRI scanner workstation is critical, but if the scanner/server itself fails, workstation redundancy doesn't help much. As a matter of fact, I was in an MRI scanner at a research hospital last year, and the UNIX server kept crashing. I kept volunteering to help debug, but that merely resulted in red faces on the part of the staff. I think we need to distinguish, in the non-mobile space, between workstations and multiple interface workstations. Someone like a money trader has a critical application, and, while they might not have a wholly separate workstation, it's quite common for their stations to have an active and a backup NIC, connected to separate LANs going to high-availability server clusters. > >If we can't find a good way to multihome entire sites, it just _might_ >(for an intermediate approach, if not else) be sufficient to be able to >multihome certain critical systems. > >The amount of critical systems and how they're located in the site's >network topology defines whether "server-based" or "network-based" >multihoming is a better alternative (if you actually could do it either >way). > >-- >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 Sat Aug 18 15:59:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15211 for ; Sat, 18 Aug 2001 15:59:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15YCDy-000KEh-00 for multi6-data@psg.com; Sat, 18 Aug 2001 12:57:38 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.31 #1) id 15YCDx-000KEA-00 for multi6@ops.ietf.org; Sat, 18 Aug 2001 12:57:37 -0700 Received: from kenawang ([192.168.1.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA14060; Sat, 18 Aug 2001 12:56:53 -0700 (PDT) Message-Id: <4.2.2.20010818154138.00a8dd90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 18 Aug 2001 16:03:19 -0400 To: "Brian Haberman" From: Margaret Wasserman Subject: Re: Fwd: Re: note from the iesg plenary Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: <3B7C0445.5748EDB7@americasm06.nt.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi Brian, >I know that this subject has been discussed several times. I believe >the scenario that Margaret is concerned about is based on this >diagram she posted to IPNG several months ago (correct me if I am >wrong, Margaret): This is one case that I am concerned about, yes. You and Steve resolved this case by stating that a site must be "convex", and I am sure that the text explaining this will be in the next version of the document -- I do understand what it means, and I agree that it will solve the problem. However, this does place several constraints on the concept of a site. For example, consider two office of the same company, both connected to the Internet, that are connected by a high-cost link (higher cost than traversing the Internet between the two locations). These two locations could not be configured as a single site, although they would probably cross-pollinate their global addresses (for redundancy) and might be treated as a single routing AS. This adds some complexity for routing purposes, as it clearly decouples the concept of sites (which must be convex) and routing ASes (which do not have that restriction). Also it is possible that all of the subnets of a single global address allocation may not be in the same site, right? So, it would probably not be acceptable for renumbering to be constrained by site boundaries. Some other issues have been raised in my previous mail, but I forgot to raise two additional issues: Default Routes: Will multi-interface-hosts and non-default-free site border routers potentially have several different default routes (one for global traffic, one for each site, etc.)? And in general, will we allow multi-site hosts? Or, can only a router have interfaces in more than one site? Just for the record, I think that I know the answers to many of the questions that I have posed. I'm sure that several of you know the answers as well. But, do we know the same answers? And, how can we standardize this behaviour well-enough for people to implement site-border, anycast-compatible, IPv6 hosts and routers without investing years of effort to understand IPv6? One of the most disturbing issues (to me) is the widespread misconception that it should be possible to route IPv6 packets by looking at only the first 64-bits. This may be true for the small number of addresses that we've already defined, but the IESG has been quite clear that we shouldn't rely on any hard internal boundaries in the addresses. And this certainly wouldn't work for host routes. Also, site-local addressing and anycast addressing are the biggest changes in IPv6 from IPv4. Basically, addressing == routing. And, I think that it would be worth the investment of our time to make sure that we understand all of the routing implications of site-local and anycast addressing. Also, we need to make sure that the appropriate semantics are included in the current IPv6 routing protocols (OSPFv3, BGP-4+, RIPv6, ??) to handle site-local addressing and the injection of anycast host routes (as we are suggesting in some drafts). I am not actually disagreeing with any of the work in this area, to date. It just isn't complete. Margaret From owner-multi6@ops.ietf.org Mon Aug 20 09:29:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19256 for ; Mon, 20 Aug 2001 09:29:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Yp1I-000JYq-00 for multi6-data@psg.com; Mon, 20 Aug 2001 06:23:08 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15Yp1H-000JYj-00 for multi6@ops.ietf.org; Mon, 20 Aug 2001 06:23:07 -0700 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7KDMXp15334 for ; Mon, 20 Aug 2001 09:22:33 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Mon, 20 Aug 2001 09:22:46 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id R21R5300; Mon, 20 Aug 2001 09:22:45 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5NCX9; Mon, 20 Aug 2001 09:22:44 -0400 Message-ID: <3B810F1F.55D9E13A@americasm06.nt.com> Date: Mon, 20 Aug 2001 09:22:39 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman CC: Erik Nordmark , multi6@ops.ietf.org Subject: Re: Fwd: Re: note from the iesg plenary References: <4.2.2.20010818154138.00a8dd90@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Margaret, Margaret Wasserman wrote: > > Hi Brian, > > >I know that this subject has been discussed several times. I believe > >the scenario that Margaret is concerned about is based on this > >diagram she posted to IPNG several months ago (correct me if I am > >wrong, Margaret): > > This is one case that I am concerned about, yes. > > You and Steve resolved this case by stating that a site must be > "convex", and I am sure that the text explaining this will be in the next > version of the document -- I do understand what it means, and I agree > that it will solve the problem. Good. Now if I could get some cycles to actually edit the doc... > > However, this does place several constraints on the concept of a site. > For example, consider two office of the same company, both connected to > the Internet, that are connected by a high-cost link (higher cost than > traversing the Internet between the two locations). These two > locations could not be configured as a single site, although they > would probably cross-pollinate their global addresses (for redundancy) > and might be treated as a single routing AS. This adds some complexity > for routing purposes, as it clearly decouples the concept of sites > (which must be convex) and routing ASes (which do not have that > restriction). This is true and I would state that it is a "good thing" to have the routing ASes and the sites decoupled. In your scenario, if the sites had a cheaper connection via the Internet, I would not even consider putting them in one site. If it was necessary to have both locations in the same site, it would still be possible with the use of IPSec tunnels and some tweaked routing parameters. > > Also it is possible that all of the subnets of a single global address > allocation may not be in the same site, right? So, it would probably > not be acceptable for renumbering to be constrained by site boundaries. I agree. Renumbering is not constrained by site boundaries, it is constrained by delegation of the prefix being renumbered. > > Some other issues have been raised in my previous mail, but I forgot to > raise two additional issues: > > Default Routes: Will multi-interface-hosts and non-default-free site border > routers potentially have several different default routes (one for global > traffic, one for each site, etc.)? Sure. I have that today in my v6 lab network. There is a default route per scope (global, site, etc.). Works fine. There may be an issue of having multiple default routes per zone ID. > > And in general, will we allow multi-site hosts? Or, can only a router have > interfaces in more than one site? I would not make that restriction. > > Just for the record, I think that I know the answers to many of the > questions that I have posed. I'm sure that several of you know the answers > as well. But, do we know the same answers? Don't know. What are your answers to these questions? > > And, how can we standardize this behaviour well-enough for people to implement > site-border, anycast-compatible, IPv6 hosts and routers without investing > years of effort to understand IPv6? I hope so. > > One of the most disturbing issues (to me) is the widespread misconception > that it should be possible to route IPv6 packets by looking at only the > first 64-bits. This may be true for the small number of addresses that > we've already defined, but the IESG has been quite clear that we shouldn't > rely on any hard internal boundaries in the addresses. And this certainly > wouldn't work for host routes. That is correct. I hope people start forgetting that misconception. > > Also, site-local addressing and anycast addressing are the biggest changes in > IPv6 from IPv4. Basically, addressing == routing. And, I think that it > would be worth the investment of our time to make sure that we understand > all of the routing implications of site-local and anycast addressing. Also, > we need to make sure that the appropriate semantics are included in the > current IPv6 routing protocols (OSPFv3, BGP-4+, RIPv6, ??) to handle site-local > addressing and the injection of anycast host routes (as we are suggesting in > some drafts). Agreed. I happen to be working on both of these areas. I am hoping that once we get the scoped addressing architecture done, we can go and look at making necessary changes to the routing docs. The anycast will take a little longer, but may not affect the routing RFCs. > > I am not actually disagreeing with any of the work in this area, to date. > It just isn't complete. Agreed. Brian From owner-multi6@ops.ietf.org Tue Aug 21 15:46:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29559 for ; Tue, 21 Aug 2001 15:46:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZHSx-000C60-00 for multi6-data@psg.com; Tue, 21 Aug 2001 12:45:35 -0700 Received: from cichlid.adsl.duke.edu ([152.16.64.203] helo=hygro.adsl.duke.edu) by psg.com with esmtp (Exim 3.33 #1) id 15ZHSu-000C5t-00 for multi6@ops.ietf.org; Tue, 21 Aug 2001 12:45:33 -0700 Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f7LJhm902110 for ; Tue, 21 Aug 2001 15:43:48 -0400 Message-Id: <200108211943.f7LJhm902110@hygro.adsl.duke.edu> To: multi6@ops.ietf.org Subject: draft minutes from London multi6 session Date: Tue, 21 Aug 2001 15:43:48 -0400 From: Thomas Narten Sender: owner-multi6@ops.ietf.org Precedence: bulk These minutes are mostly from Geoff Huston , augmented slightly with notes taken by Jun-ichiro itojun Hagino . Please send corrections/clarifications to myself (if minor) or to the list. Thomas Multi 6 Working Group Meeting Tuesday 1300 - 1400 Vijay Gill: Drafts Update draft-ietf-multi6-multihoming-requirements-01.txt draft-ietf-multi6-v4-multihoming-00.txt Drafts were written up as strawman proposals to encapsulate the scope of the issues to be addressed. The documents are intended to document Best Current Requirements. i.e. Given what we know and observe, this is what we believe are the requirements. Any solution we come up is to support the current functionality we have today. This includes resiliency, traffic engineering and similar. The WG is soliciting input on these requirements documents. Any solution should support these current requirements as a minimium. Going forward includes sending comments, alternative proposals and requirements and practices. Howard Berkowitz draft-berkowitz-multireq-02.txt The draft is not intended as an alternative proposal, but could be merged with the multi6 requirements document. This document deals with more than level 3 multi-homing, and addresses a number of issues at the datalink level as well as at the IP level. The draft addresses some of the customer motivations for multihoming and points to specific technologies to support these requirements. It was suggested to the WG that a possible approach is to merge the wg req document with this draft. It was proposed that a services/requiments document and an architecture/framework and limitations document would be generated, and noted that both documents do not restrict themselves to multi-homing at the network layer. Discussion: Vijay Gill - that the multi6 document concentrated on network layer was a reflection of input and observation of current multihoming practices. Geoff Huston - this broadens the scope of the working group and could defocus the working group and stall its progress Perry Metzger - why Multi6? This is a more general operational requirement document. Howard - there is a level of fit with the Multi6 scope Steve Deering - this proposal depends on the charter of the WG. While there is some scope to explore more general issues, its up to the chairs and the ADs to see if this is in scope. Joe Touch - we've been working on updates to the architecture documents of multi-homing requirements for hosts and routers. One of the problems of this group is one of understanding the terminology of multi-homing as defined in this document. This architectural principle of multi-homing could be undertaken in a chartered WG to look at these issues. Atsushi Shionozaki - Lin6 http://www.lin6.net/draft-teraoka-ipng-lin6-01.txt Overview of lin6 - Location independant networking for v6. Based on a 64 bit node identifier and a "mapping agent". The constant node identifier part is used to base security associations which can be maintained over network prefix changes. The prefix change is not passed back to the end hosts. The source code has been released at www.lin6.org Discussion: Paul Francis: What are the security modifications? Shio - there are no modifications to IPSEC as the input to the security association is unaltered. Perry Metzger: performance issues with the use of DNS in this model? Tony Hain draft-hain-ipv6-pi-addr-00.txt draft-hain-ipv6-pi-addr-use-00.txt. The agenda item is the applicability of this PI address format and the use of it. The intent was to step back from the issues of multi-homing and examine the basic issues. Multi-homing in general is a subset of the general concept of 'provider independance' - this broader provider independance includes provider transition without renumbering for example. This provider independance is that the full prefix is in the DFZ. Comments were received that the proposal is suboptimal to some extent - it was noted that this is a tradeoff with simplicity and routeability. Is this intended to replace PA? Not as such. The open questions in the draft include the match of the current format and the network topology to this proposed address format. The document also focuses on a multi-homed site, not a multi-homed ISP. How to keep the full knowledge of prefixes in a region over time. Discussion: Itojun - the issues of aggregation potential are not well understood Christian Huitema - I think it does not work. The registration system cannot be avoided, and one is required. Tony Hain - the inclusion of a registration system is not precluded by this proposal Christian Huitema - a lot of address space is wasted on ocean surfaces. Tall buildings are problems too. Christian - comparison of this proposal with the older Metro addressing scheme Tony Hain- this is intended to address the issue of complete provider independance within and beyond the metro Steve Deering - metro stuff is completely provide-independent (Tony may have misread). Tom Narten - If we go in this direction how can we ensure that addresses will in fact be aggregated? There are always temptations not to. Tony - worst case of no aggregatability is no different from today. Tom Narten draft-ietf-ipngwg-ipv6-2260-02.txt Question to group for additonal comments on this document. No comments and no strong objection seen so far. Further comments to the mailing list. Masataka Ohta draft-ohta-e2e-multihoming-02.txt Overview of the approach documented in the draft. The approach is to provide end hosts with multiple addresses and the aplpication or transport tries all destination addresses. The question is when to try alternative addresses, and the approach adopted is the either use directives in the applications or transport or a TCP default timeout. The advantages claimed for this approach is no change to router functionality, but a change to the API. Comments: Tom Narten - we are seeing two extremes of a spectrum where there is a push to the routing system to support multi-homing and a push to the host to support multi-homing. Each approach is not without considerable cost. vijay: DNS reverse lookup in 8+8? no hierarchy, how to constract tree? ohta: optional. vijay: remove it if it is not necessary Harald Alvestrand - the proposed host identifier space is non-hierarchical and as such is a large DNS flat space. Randy Bush - this is illustrative of the issues of host-based multi-homing Joe Touch - multi-homing is necessarily a combination of host and router functionality to be robust. Multihoming tunnelling (XBONE) experience showed that, endpoint should have some control over intermediate paths. Erik Nordmark: how you recover from failure, scaling issue. scaling issue comparison with routing solutions. ohta: more udp apps due to internet phone. From owner-multi6@ops.ietf.org Wed Aug 22 07:39:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00382 for ; Wed, 22 Aug 2001 07:39:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZWIA-000EH5-00 for multi6-data@psg.com; Wed, 22 Aug 2001 04:35:26 -0700 Received: from sh.wide.ad.jp ([203.178.137.85]) by psg.com with esmtp (Exim 3.33 #1) id 15ZWI9-000EGv-00 for multi6@ops.ietf.org; Wed, 22 Aug 2001 04:35:25 -0700 Received: from localhost (localhost [127.0.0.1]) by sh.wide.ad.jp (8.11.1+3.4W/8.11.0) with ESMTP id f7MBZHc05789 for ; Wed, 22 Aug 2001 20:35:17 +0900 (JST) Date: Wed, 22 Aug 2001 20:34:06 +0900 Message-ID: From: Masahiro Ishiyama To: multi6@ops.ietf.org Subject: Re: LIN6 and multihoming (+sec) In-Reply-To: References: <200108171103.HAA23318@ietf.org> User-Agent: Wanderlust/2.7.1 (Too Funky) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (powerpc-apple-darwin1.3.7) MULE/4.0 (HANANOEN) Organization: WIDE Project./Toshiba Corp. R&D Center. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 41 Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> On Sat, 18 Aug 2001 11:26:20 +0300 (EEST), Pekka Savola said: > I don't think people generally want to multihome every node, rather > multihome a router and provide multihomed connection that way. ID's based > on EUI64 aren't possible with this mechanism if there is only one > interface on end-nodes (you could just make up the other ID, I suppose, > but that would be .. dirty, and no effective means of tracking them unless > using some mapping function to generate them). The fact remains that this > mechanism does not seem to be fit for real multihoming. I don't think I understand what you mean by "ID's based on EUI64 aren't possible with this mechanism if there is only one interface on end-nodes", can you clarify? > Does ICMP Unreachable trigger you to retry connection using a different > destination address? IIRC ICMP unreaches are soft errors, and affect > nothing. Our implementation has a hook to handle ICMP unreach messages. With this hook, the LIN6 node can refresh the opponent's mapping, so strictly speaking the ICMP message does not trigger a direct change of the destination address. When a node does become unreachable due to a temporary routing error and its mapping does not change, its destination address will not change. > I don't comment on non-multihoming issues, except for the fact that there > are no "Security Considerations" in the text. It appears to me that if > you use generalized network prefix as e.g. TCP/UDP endpoints, capturing > traffic, hijacking connections etc. are bound to be at least potentially > easier (as the generalized LIN6 namespace is flat); this puts even more > responsibility for the security of DNS and mapping agent functions. You present some good points and we plan to address these issues in future drafts. For now, we would like more people to test our implementation to get feedback so that we can effectively integrate our proposal with DNS and mapping agents. If you have any interest at all in LIN6 please try our prototype implementation. masahiro From owner-multi6@ops.ietf.org Wed Aug 22 08:36:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03124 for ; Wed, 22 Aug 2001 08:36:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZXFi-000I2Y-00 for multi6-data@psg.com; Wed, 22 Aug 2001 05:36:58 -0700 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.33 #1) id 15ZXFh-000I2S-00 for multi6@ops.ietf.org; Wed, 22 Aug 2001 05:36:57 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA03814; Wed, 22 Aug 2001 13:36:54 +0100 Received: from hursley.ibm.com ([9.29.3.172]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA49046; Wed, 22 Aug 2001 13:36:54 +0100 Message-ID: <3B82FDDC.29ACA5A0@hursley.ibm.com> Date: Tue, 21 Aug 2001 19:33:32 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Thomas Narten CC: multi6@ops.ietf.org Subject: Re: draft minutes from London multi6 session References: <200108211943.f7LJhm902110@hygro.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't quite understand from the minutes whether there was decision to merge the multi6 requirements darft with Howard's. Could someone clarify? Brian From owner-multi6@ops.ietf.org Wed Aug 22 09:18:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05891 for ; Wed, 22 Aug 2001 09:18:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZXuP-000Kdy-00 for multi6-data@psg.com; Wed, 22 Aug 2001 06:19:01 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.33 #1) id 15ZXuO-000Kdr-00 for multi6@ops.ietf.org; Wed, 22 Aug 2001 06:19:00 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f7MDInq23160; Wed, 22 Aug 2001 16:18:49 +0300 Date: Wed, 22 Aug 2001 16:18:49 +0300 (EEST) From: Pekka Savola To: Masahiro =Rhythm Drive= Ishiyama cc: Subject: Re: LIN6 and multihoming (+sec) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 22 Aug 2001, Masahiro =Rhythm Drive= Ishiyama wrote: > >>>>> On Sat, 18 Aug 2001 11:26:20 +0300 (EEST), Pekka Savola said: > > > I don't think people generally want to multihome every node, rather > > multihome a router and provide multihomed connection that way. ID's based > > on EUI64 aren't possible with this mechanism if there is only one > > interface on end-nodes (you could just make up the other ID, I suppose, > > but that would be .. dirty, and no effective means of tracking them unless > > using some mapping function to generate them). The fact remains that this > > mechanism does not seem to be fit for real multihoming. > > I don't think I understand what you mean by "ID's based on EUI64 > aren't possible with this mechanism if there is only one > interface on end-nodes", can you clarify? What I mean is that here, your "address" is derived from MAC address of your network interface. If you have two, you obviously have two addresses. This is apparently what was designed -- everyone using this mechanism would be multihomed as a single node, not network. I also see a possible usage scenario (I'm not sure if this would be really applicable/useful there though!), where a regular router provides two network prefixes, and the LIN6 node would only have one NIC with two prefixes (even "rapid renumbering" if you may). In this kind of scheme, LIN6 would be used to gain "provider independent prefix", non-breaking connections when active prefix changes and static ipsec associations, among others. However, now as there is only one NIC, there is only one address. How do you derive the second address? > > Does ICMP Unreachable trigger you to retry connection using a different > > destination address? IIRC ICMP unreaches are soft errors, and affect > > nothing. > > Our implementation has a hook to handle ICMP unreach messages. > With this hook, the LIN6 node can refresh the opponent's > mapping, so strictly speaking the ICMP message does not trigger > a direct change of the destination address. > When a node does become unreachable due to a temporary routing > error and its mapping does not change, its destination address > will not change. Ok. Placing externally available (if it is so) hook there might trigger some additional security considerations too ("I just managed to spoof DNS cache for a few seconds, get the wrong new address now!"). -- 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 Aug 22 10:09:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09002 for ; Wed, 22 Aug 2001 10:08:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZYfT-000Nk0-00 for multi6-data@psg.com; Wed, 22 Aug 2001 07:07:39 -0700 Received: from fwns2d.raleigh.ibm.com ([204.146.167.236] helo=fwns2.raleigh.ibm.com) by psg.com with esmtp (Exim 3.33 #1) id 15ZYfS-000Nju-00 for multi6@ops.ietf.org; Wed, 22 Aug 2001 07:07:38 -0700 Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA25086 for ; Wed, 22 Aug 2001 10:06:23 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA25550; Wed, 22 Aug 2001 10:07:35 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id KAA27092; Wed, 22 Aug 2001 10:04:38 -0400 Message-Id: <200108221404.KAA27092@rotala.raleigh.ibm.com> To: Brian E Carpenter cc: multi6@ops.ietf.org Subject: Re: draft minutes from London multi6 session In-Reply-To: Message from Brian E Carpenter of "Tue, 21 Aug 2001 19:33:32 CDT." <3B82FDDC.29ACA5A0@hursley.ibm.com> Date: Wed, 22 Aug 2001 10:04:37 -0400 From: Thomas Narten Sender: owner-multi6@ops.ietf.org Precedence: bulk Brian E Carpenter writes: > I don't quite understand from the minutes whether there was decision > to merge the multi6 requirements darft with Howard's. Could someone > clarify? The decision was not made to merge to merge the two. Indeed, my sense of the discussion is that there was quite a bit of concern with doing a merge, as that would broaden the focus of the requirements document quite a lot beyond what the group has so far been discussing. I believe it would make more sense to extract those aspects in draft-berkowitz-multireq-02.txt that relate directly to IP connectivity issues when a site connects to multiple ISPs. It would be good for someone (Howard?) to summarize to the list what those requirements would be. Thomas From owner-multi6@ops.ietf.org Wed Aug 22 10:15:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09475 for ; Wed, 22 Aug 2001 10:15:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZYnK-000OGB-00 for multi6-data@psg.com; Wed, 22 Aug 2001 07:15:46 -0700 Received: from buddha-nexxia.automagic.org ([207.61.141.34] helo=buddha.automagic.org) by psg.com with smtp (Exim 3.33 #1) id 15ZYnJ-000OG5-00 for multi6@ops.ietf.org; Wed, 22 Aug 2001 07:15:45 -0700 Received: (qmail 527 invoked by uid 100); 22 Aug 2001 14:15:43 -0000 Date: Wed, 22 Aug 2001 10:15:42 -0400 From: Joe Abley To: Ramakrishna Gummadi Cc: multi6@ops.ietf.org Subject: Re: Requirements draft status Message-ID: <20010822101540.I9464@buddha.home.automagic.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, Aug 16, 2001 at 11:20:30PM -0700, Ramakrishna Gummadi wrote: > 1) Can someone tell me what the current status of the multi6 > requirements draft is? Was any consensus reached during the ietf meeting? > (It would be great if someone could send out the minutes.) > > 2) Is there any requirement on multicast with respect to multihoming? I > think a host-level solution will make achieving scalable multihoming very > hard... I was unable to attend the meeting, but I followed the list traffic shortly afterwards, and I think we have a well-known set of changes to negotiate before the requirements draft are ready for some kind of last call. The "current practices" draft was waiting from text from a number of people (and still is). I will take a stab at it if none of the other volunteers have spare cycles. I am behind on this (I have been held up by all manner of other things) and I apologise for the woefully slow progress made with these docs of late. I hope to free up some time within the next week; if anybody else feels like collating the changes proposed over the past few weeks (and particularly suggesting new text to the list to effect those changes) that would be spectacularly handy. Joe From owner-multi6@ops.ietf.org Wed Aug 22 11:43:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14129 for ; Wed, 22 Aug 2001 11:43:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZaB0-00044h-00 for multi6-data@psg.com; Wed, 22 Aug 2001 08:44:18 -0700 Received: from ren-2.cais.net ([205.252.14.77]) by psg.com with esmtp (Exim 3.33 #1) id 15ZaAz-000440-00 for multi6@ops.ietf.org; Wed, 22 Aug 2001 08:44:17 -0700 Received: from [205.252.61.37] (dynamic93.cl7.cais.net [205.177.20.93] (may be forged)) by ren-2.cais.net (8.11.1/8.11.1) with ESMTP id f7MFiAE23726; Wed, 22 Aug 2001 11:44:11 -0400 (EDT) Mime-Version: 1.0 X-Sender: hcb@pop3.clark.net Message-Id: In-Reply-To: <200108221404.KAA27092@rotala.raleigh.ibm.com> References: <200108221404.KAA27092@rotala.raleigh.ibm.com> Date: Wed, 22 Aug 2001 11:42:36 -0400 To: Thomas Narten , Brian E Carpenter From: "Howard C. Berkowitz" Subject: Re: draft minutes from London multi6 session Cc: multi6@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 10:04 AM -0400 8/22/01, Thomas Narten wrote: >Brian E Carpenter writes: > >> I don't quite understand from the minutes whether there was decision >> to merge the multi6 requirements darft with Howard's. Could someone >> clarify? > >The decision was not made to merge to merge the two. Indeed, my sense >of the discussion is that there was quite a bit of concern with doing >a merge, as that would broaden the focus of the requirements document >quite a lot beyond what the group has so far been discussing. > >I believe it would make more sense to extract those aspects in >draft-berkowitz-multireq-02.txt that relate directly to IP >connectivity issues when a site connects to multiple ISPs. It would be >good for someone (Howard?) to summarize to the list what those >requirements would be. I certainly can do that. My sense is that the issues are slightly broader than connecting to multiple ISPs. Scenarios (e.g., RFC 1998) where one AS has BGP connectivity to multiple POPs of the same ISP, I believe, are within scope. Such scenarios vary in V4 depending on whether the address space is PA or PI, which might not be a V6 issue. A brief note on the evolving discussions of aggregation-by-community (several proposals) might also be in order. Of course, simply as individual authors, we'd greatly appreciate comments on the document as a whole. I'd like a reality check if it would be worth advancing to Informational in its present form. Since there are many multihoming -- whatever that is :-) -- experts on this list, I'd also like to get a sense of whether it's time for a BOF on the broader area of general multihoming, presumably in the ops area. > >Thomas From owner-multi6@ops.ietf.org Wed Aug 22 14:58:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20578 for ; Wed, 22 Aug 2001 14:58:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZdB3-000Dvp-00 for multi6-data@psg.com; Wed, 22 Aug 2001 11:56:33 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 15ZdB2-000Dvj-00 for multi6@ops.ietf.org; Wed, 22 Aug 2001 11:56:32 -0700 Subject: draft-berkowitz-multireq-02.txt Date: Wed, 22 Aug 2001 11:56:28 -0700 Message-ID: <2B81403386729140A3A899A8B39B046403AD43@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: draft-berkowitz-multireq-02.txt content-class: urn:content-classes:message Thread-Index: AcErPCYXr1nuaPTvT22aw6kwc0zKvg== From: "Michel Py" To: Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA20578 Although this document is not really targeted at protocol developpers, it could be used as a base for all drafts to use the same language. As an example, one sentence I recently added to the MHTP draft is: 'The "home" of MHTP is an IPv6 address'. I think that things like a clear definition of what the "home" of a multihoming protocol is should be requirements for future drafts. Howard's draft does a good job at defining terms and different "flavors" of multihoming. I wish there was a model that MHTP can relate to, though. Michel. From owner-multi6@ops.ietf.org Wed Aug 22 15:52:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22294 for ; Wed, 22 Aug 2001 15:52:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Ze2S-000Fyf-00 for multi6-data@psg.com; Wed, 22 Aug 2001 12:51:44 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 15Ze2R-000FyW-00 for multi6@ops.ietf.org; Wed, 22 Aug 2001 12:51:43 -0700 Received: from mosquito.inet.org (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id 4C6C08266F; Wed, 22 Aug 2001 15:51:23 -0400 (EDT) Message-Id: <5.1.0.14.2.20010822154440.00aa8580@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 22 Aug 2001 15:45:55 -0400 To: "Michel Py" From: RJ Atkinson Subject: Re: draft-berkowitz-multireq-02.txt Cc: multi6@ops.ietf.org In-Reply-To: <2B81403386729140A3A899A8B39B046403AD43@server2000.arneill- py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 14:56 22/08/01, you wrote: >Although this document is not really targeted at protocol developpers, >it could be used as a base for all drafts to use the same language. As >an example, one sentence I recently added to the MHTP draft is: 'The >"home" of MHTP is an IPv6 address'. I think that things like a clear >definition of what the "home" of a multihoming protocol is should be >requirements for future drafts. Howard's draft does a good job at >defining terms and different "flavors" of multihoming. I wish there was >a model that MHTP can relate to, though. I'd suggest that most users want a given host to have the multi-homed property and don't really care whether that means 1 IP address per host or more than 1 IP address per host. So defining "home" to be a single IP address seems unduly restrictive of the potential solution space for this issue. Ran From owner-multi6@ops.ietf.org Thu Aug 23 06:32:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21536 for ; Thu, 23 Aug 2001 06:32:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Zrl1-0008A5-00 for multi6-data@psg.com; Thu, 23 Aug 2001 03:30:39 -0700 Received: from sh.wide.ad.jp ([203.178.137.85]) by psg.com with esmtp (Exim 3.33 #1) id 15Zrl0-00089z-00 for multi6@ops.ietf.org; Thu, 23 Aug 2001 03:30:38 -0700 Received: from halberd.wide.ad.jp (localhost [127.0.0.1]) by sh.wide.ad.jp (8.11.1+3.4W/8.11.0) with ESMTP id f7NAUSc21115; Thu, 23 Aug 2001 19:30:28 +0900 (JST) Date: Thu, 23 Aug 2001 19:30:07 +0900 Message-ID: From: Masahiro Ishiyama To: Pekka Savola Cc: Subject: Re: LIN6 and multihoming (+sec) In-Reply-To: References: User-Agent: Wanderlust/2.7.1 (Too Funky) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (powerpc-apple-darwin1.3.7) MULE/4.0 (HANANOEN) Organization: WIDE Project./Toshiba Corp. R&D Center. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 49 Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> On Wed, 22 Aug 2001 16:18:49 +0300 (EEST), Pekka Savola said: > What I mean is that here, your "address" is derived from MAC address of > your network interface. If you have two, you obviously have two > addresses. In LIN6, addresses (locators) that are assigned to ifs are derived from the unique LIN6 ID (64 bit node identifier) assigned to the node and a prefix, not from the MAC address of the network interface. > I also see a possible usage scenario (I'm not sure if this would be really > applicable/useful there though!), where a regular router provides two > network prefixes, and the LIN6 node would only have one NIC with two > prefixes (even "rapid renumbering" if you may). In this kind of scheme, > LIN6 would be used to gain "provider independent prefix", non-breaking > connections when active prefix changes and static ipsec associations, > among others. However, now as there is only one NIC, there is only one > address. How do you derive the second address? As you know, in IPv6, a node may be assigned multiple global addresses to an interface. (Prefix Pa) Path_A -----\ | \ | Node_2 --- R ... R--+ (Px:I2) / | Pa:I1 -----/ |-----Node_1(LIN6 ID=I1) Path_B | Pb:I1 (Prefix Pb) Node_1 has one interface and two addresses(locators) are assigned: Pa:I1 and Pb:I1. Let us consider the case when Node_1 uses Pa:I1 as the current locator. Assume that Path_A crashes, and Node_1 changes its current locator to Pb:I1 and updates its mapping. When Node_2 refreshes the mapping of Node_1, the destination address of packets to Node_1 will be changed to Pb:Ib. However, the established connections between Node_1 and Node_2 remain undisturbed even after the path changes because the connections are established between LIN6_P(LIN6 Prefix)+I1 and LIN6_P+I2, independent of the locators: Pa:I1, Pb:I1. LIN6_P is a well-known constant. masahiro From owner-multi6@ops.ietf.org Sun Aug 26 14:38:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14851 for ; Sun, 26 Aug 2001 14:38:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15b4kB-000KAS-00 for multi6-data@psg.com; Sun, 26 Aug 2001 11:34:47 -0700 Received: from h-135-207-4-81.research.att.com ([135.207.4.81] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15b4k9-000KAL-00 for multi6@ops.ietf.org; Sun, 26 Aug 2001 11:34:46 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15b3DN-0003ji-00; Sun, 26 Aug 2001 09:56:49 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Margaret Wasserman , Brian Haberman Cc: multi6@ops.ietf.org Subject: Re: Fwd: Re: note from the iesg plenary References: <4.2.2.20010810223354.00a87100@mail.windriver.com> Message-Id: Date: Sun, 26 Aug 2001 09:56:49 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > (3) IPv6 anycast is substantially different from the anycast hacks > currently used in IPv4. this is not generally appreciated, in both senses of the word. > One big difference: a global IPv6 anycast address would (probably?) not > appear to be inside of anyone's AS. this part i missed. or by 'AS' do you mean OSPF area? in this gang, 'AS' is a bgp thing. > And, despite the fact that we are specifying the use of site-local > anycast addresses in documents (like Dave Thaler's DNS stuff), we > don't actually know what a site-local anycast would look like. why would those of us who want an anycast interface to appear to the world as no different from a unicast interface not think it should be the same as a site local unicast anycast address? > However, the IPv4 stuff has only been tried with BGP. not true at all. > Do we know for sure that the OSPF tree will converge if it thinks that > one host is actually located at two different places in the topology? hmmm. i will admit to not having checked the multi-area issue. > I'm glad that someone was listening... :-). my apologies for not listening well enough. > You and Steve resolved this case by stating that a site must be > "convex", and I am sure that the text explaining this will be in the next > version of the document -- I do understand what it means, and I agree > that it will solve the problem. > > However, this does place several constraints on the concept of a site. > For example, consider two office of the same company, both connected to > the Internet, that are connected by a high-cost link (higher cost than > traversing the Internet between the two locations). These two > locations could not be configured as a single site, although they > would probably cross-pollinate their global addresses (for redundancy) > and might be treated as a single routing AS. This adds some complexity > for routing purposes, as it clearly decouples the concept of sites > (which must be convex) and routing ASes (which do not have that > restriction). i think things are getting very crufty here, and we will regret trying to create these complex little sub-definitions of site etc. > Just for the record, I think that I know the answers to many of the > questions that I have posed. I'm sure that several of you know the > answers as well. But, do we know the same answers? and, as you say, have these questions and their answers been clearly and simply spelled out in the published specs? From: "Brian Haberman" > From discussions I have had, I don't think there is much interest > in global anycast. The proposals I have heard have been for using > anycast within domains, so that the anycast address gets aggregated > into the global prefix for that domain. aiiiii!!!!! global v4 anycast is used significantly. let's not further break v6 anycast, please. > In your scenario, if the sites had a cheaper connection via the Internet, > I would not even consider putting them in one site. what is 'putting them in one site'? do you mean considering them as a site in terms of things such as site-local addressing/routing? or are you starting to mandate operational restrictions? > If it was necessary to have both locations in the same site, it would > still be possible with the use of IPSec tunnels and some tweaked routing > parameters. please explain. randy From owner-multi6@ops.ietf.org Mon Aug 27 17:27:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01091 for ; Mon, 27 Aug 2001 17:27:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bTuA-000HaW-00 for multi6-data@psg.com; Mon, 27 Aug 2001 14:26:46 -0700 Received: from [210.61.172.63] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15bTu9-000HaJ-00 for multi6@ops.ietf.org; Mon, 27 Aug 2001 14:26:46 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15bTu5-0004Jb-00; Tue, 28 Aug 2001 05:26:41 +0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian Haberman" Cc: multi6@ops.ietf.org Subject: Re: Fwd: Re: note from the iesg plenary References: <4.2.2.20010810223354.00a87100@mail.windriver.com> <3B8A33AA.1DC0B53D@americasm06.nt.com> Message-Id: Date: Tue, 28 Aug 2001 05:26:41 +0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > First, no one that I have talked to on the subject of anycast feels > that global anycast is all that useful. can't help the limits of your circle of friends, but since you say "no one" and i am disagreeing, the problem may be on the receiving, not the sending, end . > someone can't offer a global anycast-based service, as long as > the servers are all based out of that network's prefix so that the > anycast address gets aggregated in the global routing table. you may want to look at the aroot experiments. > Second, can you describe the current v4 use of anycast where anycast > servers are using globally routable anycast addresses from outside > their administrative domains? ibid randy From owner-multi6@ops.ietf.org Mon Aug 27 18:23:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02950 for ; Mon, 27 Aug 2001 18:23:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bUnC-000IS1-00 for multi6-data@psg.com; Mon, 27 Aug 2001 15:23:38 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15bUnB-000IRu-00 for multi6@ops.ietf.org; Mon, 27 Aug 2001 15:23:37 -0700 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7RMNDp08876 for ; Mon, 27 Aug 2001 18:23:13 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Mon, 27 Aug 2001 18:23:20 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RTKW0GL4; Mon, 27 Aug 2001 18:23:10 -0400 Received: from americasm06.nt.com (abl6t0f9.us.nortel.com [47.16.4.73]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87RX6D; Mon, 27 Aug 2001 18:23:14 -0400 Message-ID: <3B8AC853.AF725F70@americasm06.nt.com> Date: Mon, 27 Aug 2001 18:23:15 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: multi6@ops.ietf.org Subject: Re: Fwd: Re: note from the iesg plenary References: <4.2.2.20010810223354.00a87100@mail.windriver.com> <3B8A33AA.1DC0B53D@americasm06.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy, Randy Bush wrote: > > > First, no one that I have talked to on the subject of anycast feels > > that global anycast is all that useful. > > can't help the limits of your circle of friends, but since you say "no one" > and i am disagreeing, the problem may be on the receiving, not the sending, > end . Not at all. I was just pointing out that you are the first person who has expressed much of an interest in generic, global anycast support. > > > someone can't offer a global anycast-based service, as long as > > the servers are all based out of that network's prefix so that the > > anycast address gets aggregated in the global routing table. > > you may want to look at the aroot experiments. So, has this been actually deployed in an operational network? I recall seeing the slides on experimentation, but have not heard any results of those experiments nor heard of operational use. The aroot mailing list archive seems to be unreachable at this time. > > > Second, can you describe the current v4 use of anycast where anycast > > servers are using globally routable anycast addresses from outside > > their administrative domains? > > ibid Would that be the PolyVision whiteboard product? There is no info on their website as to how they utilize IP anycast. Brian From owner-multi6@ops.ietf.org Mon Aug 27 19:52:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04499 for ; Mon, 27 Aug 2001 19:52:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bWAw-000Jgq-00 for multi6-data@psg.com; Mon, 27 Aug 2001 16:52:14 -0700 Received: from [210.61.172.63] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15bWAv-000Jgk-00 for multi6@ops.ietf.org; Mon, 27 Aug 2001 16:52:13 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15bWAn-0004PE-00; Tue, 28 Aug 2001 07:52:05 +0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian Haberman" Cc: multi6@ops.ietf.org Subject: Re: Fwd: Re: note from the iesg plenary References: <4.2.2.20010810223354.00a87100@mail.windriver.com> <3B8A33AA.1DC0B53D@americasm06.nt.com> <3B8AC853.AF725F70@americasm06.nt.com> Message-Id: Date: Tue, 28 Aug 2001 07:52:05 +0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> you may want to look at the aroot experiments. > So, has this been actually deployed in an operational network? yup, for a year or so now, and is about to expand. > I recall seeing the slides on experimentation, but have not heard > any results of those experiments nor heard of operational use. works boringly well. > The aroot mailing list archive seems to be unreachable at this time. ohhh? what url did you try? randy From owner-multi6@ops.ietf.org Tue Aug 28 09:16:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09393 for ; Tue, 28 Aug 2001 09:16:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bihp-0006gr-00 for multi6-data@psg.com; Tue, 28 Aug 2001 06:15:01 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15biho-0006gi-00 for multi6@ops.ietf.org; Tue, 28 Aug 2001 06:15:00 -0700 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7SDEap13366 for ; Tue, 28 Aug 2001 09:14:36 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Tue, 28 Aug 2001 09:14:51 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RTKW0GZC; Tue, 28 Aug 2001 09:14:41 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87RX0W; Tue, 28 Aug 2001 09:14:44 -0400 Message-ID: <3B8B9947.26C986B6@americasm06.nt.com> Date: Tue, 28 Aug 2001 09:14:47 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: multi6@ops.ietf.org Subject: Re: Fwd: Re: note from the iesg plenary References: <4.2.2.20010810223354.00a87100@mail.windriver.com> <3B8A33AA.1DC0B53D@americasm06.nt.com> <3B8AC853.AF725F70@americasm06.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy, Randy Bush wrote: > > > I recall seeing the slides on experimentation, but have not heard > > any results of those experiments nor heard of operational use. > > works boringly well. Can you give me a definition of works boringly well? Would that entail no calls to the NOC as the measuring stick? > > > The aroot mailing list archive seems to be unreachable at this time. > > ohhh? what url did you try? www.psg.com/lists/aroot/ I was consistently getting a DNS resolution error last night. It seems to work this morning. So now that you have given me a use of global anycast services, do you expect that injecting 128-bit host routes into the global route table, that can't be aggregated, is going to scale? Brian From owner-multi6@ops.ietf.org Tue Aug 28 13:11:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16150 for ; Tue, 28 Aug 2001 13:11:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bmOv-000BGi-00 for multi6-data@psg.com; Tue, 28 Aug 2001 10:11:45 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15bmOu-000BGb-00 for multi6@ops.ietf.org; Tue, 28 Aug 2001 10:11:44 -0700 Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7SHBGp19725 for ; Tue, 28 Aug 2001 13:11:16 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Tue, 28 Aug 2001 13:11:28 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RZ8L07MZ; Tue, 28 Aug 2001 13:11:16 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87RYG2; Tue, 28 Aug 2001 13:11:20 -0400 Message-ID: <3B8BD0BA.E3C9701D@americasm06.nt.com> Date: Tue, 28 Aug 2001 13:11:23 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Eliot Lear CC: Randy Bush , multi6@ops.ietf.org Subject: Re: Fwd: Re: note from the iesg plenary References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot, Yes, I am well aware that DNS is an ideal use of anycast. That is part of the reason why v6 anycast is of interest to people. However, my point has been to find out if anyone thinks that having 128-bit host routes in the global routing table is going to scale. Or, would you think that anycast DNS deployed within a domain/site/admin scope region is a better solution? Brian Eliot Lear wrote: > > On Tue, 28 Aug 2001, Brian Haberman wrote: > > Can you give me a definition of works boringly well? Would that > > entail no calls to the NOC as the measuring stick? > > Because nearly all DNS requests are single packet exchanges AND > connectionless, there are no adverse consequences for a routing shift, and > thus DNS is ideal for anycast. More robustness is needed for connection > oriented anycast. From owner-multi6@ops.ietf.org Tue Aug 28 14:11:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17544 for ; Tue, 28 Aug 2001 14:11:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bnLc-000Cht-00 for multi6-data@psg.com; Tue, 28 Aug 2001 11:12:24 -0700 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.33 #1) id 15bnLb-000Chc-00; Tue, 28 Aug 2001 11:12:23 -0700 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7SIAMV13046; Tue, 28 Aug 2001 11:10:22 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f7SICFi22044; Tue, 28 Aug 2001 11:12:15 -0700 (PDT) Message-ID: <3B8BDEFD.349C5F90@cisco.com> Date: Tue, 28 Aug 2001 11:12:13 -0700 From: Eliot Lear Reply-To: lear@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Haberman CC: Eliot Lear , Randy Bush , multi6@ops.ietf.org Subject: Re: Fwd: Re: note from the iesg plenary References: <3B8BD0BA.E3C9701D@americasm06.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Not clear you want to have host routes in the global routing system, but that doesn't eliminate anycast use. It means that the routing exchange on those /128s has to be limited to IGPs. Brian Haberman wrote: > Eliot, > Yes, I am well aware that DNS is an ideal use of anycast. That is > part of the reason why v6 anycast is of interest to people. However, > my point has been to find out if anyone thinks that having 128-bit host > routes in the global routing table is going to scale. Or, would you > think that anycast DNS deployed within a domain/site/admin scope > region is a better solution? > > Brian -- Eliot Lear lear@cisco.com From owner-multi6@ops.ietf.org Tue Aug 28 15:18:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19203 for ; Tue, 28 Aug 2001 15:18:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15boJi-000E4w-00 for multi6-data@psg.com; Tue, 28 Aug 2001 12:14:30 -0700 Received: from h157s242a129n47.user.nortelnetworks.com ([47.129.242.157] helo=zcars0m9.ca.nortel.com) by psg.com with esmtp (Exim 3.33 #1) id 15boJi-000E4q-00 for multi6@ops.ietf.org; Tue, 28 Aug 2001 12:14:30 -0700 Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7SJE3p08734 for ; Tue, 28 Aug 2001 15:14:06 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 28 Aug 2001 15:14:12 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RSACC9KK; Tue, 28 Aug 2001 15:14:08 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87RYKB; Tue, 28 Aug 2001 15:14:06 -0400 Message-ID: <3B8BED80.6F0EC682@americasm06.nt.com> Date: Tue, 28 Aug 2001 15:14:09 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: lear@cisco.com CC: Eliot Lear , Randy Bush , multi6@ops.ietf.org Subject: Re: Fwd: Re: note from the iesg plenary References: <3B8BD0BA.E3C9701D@americasm06.nt.com> <3B8BDEFD.349C5F90@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot, Eliot Lear wrote: > > Not clear you want to have host routes in the global routing system, but > that doesn't eliminate anycast use. It means that the routing exchange on > those /128s has to be limited to IGPs. Exactly. That means the anycast addresses being advertised have to be allocated out of the "domain's" prefix, thus being aggregatable. Users within an IGP would be able to use anycast to do (e.g.) DNS, but the anycast route gets aggregated within BGP. Users outside the domain COULD send to the anycast address and get a response since the anycast address's prefix would be advertised via BGP. Brian > > Brian Haberman wrote: > > Eliot, > > Yes, I am well aware that DNS is an ideal use of anycast. That is > > part of the reason why v6 anycast is of interest to people. However, > > my point has been to find out if anyone thinks that having 128-bit host > > routes in the global routing table is going to scale. Or, would you > > think that anycast DNS deployed within a domain/site/admin scope > > region is a better solution? > > > > Brian > -- > Eliot Lear > lear@cisco.com From owner-multi6@ops.ietf.org Tue Aug 28 19:51:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24081 for ; Tue, 28 Aug 2001 19:51:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bscT-000K8i-00 for multi6-data@psg.com; Tue, 28 Aug 2001 16:50:09 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15bscS-000K8c-00 for multi6@ops.ietf.org; Tue, 28 Aug 2001 16:50:08 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15bscN-0004n1-00; Wed, 29 Aug 2001 07:50:03 +0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian Haberman" Cc: multi6@ops.ietf.org Subject: Re: Fwd: Re: note from the iesg plenary References: <4.2.2.20010810223354.00a87100@mail.windriver.com> <3B8A33AA.1DC0B53D@americasm06.nt.com> <3B8AC853.AF725F70@americasm06.nt.com> <3B8B9947.26C986B6@americasm06.nt.com> Message-Id: Date: Wed, 29 Aug 2001 07:50:03 +0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> I recall seeing the slides on experimentation, but have not heard >>> any results of those experiments nor heard of operational use. >> works boringly well. > Can you give me a definition of works boringly well? Would that > entail no calls to the NOC as the measuring stick? that's one. also had measurements. >> ohhh? what url did you try? > www.psg.com/lists/aroot/ dunno where you made up that url. but try > So now that you have given me a use of global anycast services, do > you expect that injecting 128-bit host routes into the global route > table, that can't be aggregated, is going to scale? i would offer my abject apologies for suggesting that, except i didn't. randy From owner-multi6@ops.ietf.org Tue Aug 28 21:54:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26411 for ; Tue, 28 Aug 2001 21:54:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15buYl-000N1Q-00 for multi6-data@psg.com; Tue, 28 Aug 2001 18:54:27 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15buYk-000N1G-00 for multi6@ops.ietf.org; Tue, 28 Aug 2001 18:54:26 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15buYc-0004t1-00; Wed, 29 Aug 2001 09:54:18 +0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brian Haberman" Cc: Eliot Lear , multi6@ops.ietf.org Subject: Re: Fwd: Re: note from the iesg plenary References: <3B8BD0BA.E3C9701D@americasm06.nt.com> Message-Id: Date: Wed, 29 Aug 2001 09:54:18 +0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > my point has been to find out if anyone thinks that having 128-bit host > routes in the global routing table is going to scale. exactly as well as /32s for dns servers scale in the v4 internet randy From owner-multi6@ops.ietf.org Fri Aug 31 11:38:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08049 for ; Fri, 31 Aug 2001 11:38:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15cqJo-000PLM-00 for multi6-data@psg.com; Fri, 31 Aug 2001 08:34:52 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15cqJn-000PLG-00 for multi6@ops.ietf.org; Fri, 31 Aug 2001 08:34:51 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id IAA20229 for ; Fri, 31 Aug 2001 08:34:46 -0700 (PDT) Date: Fri, 31 Aug 2001 08:34:46 -0700 (PDT) From: Ramakrishna Gummadi To: Subject: Multihoming draft available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi all, I finished a draft that describes one way of doing scalable multihoming. http://www.cs.berkeley.edu/~ramki/draft-ramki-multi6-nlmp-00.txt Comments are highly appreciated. I plan to submit this as an internet draft soon. The abstract is below: This document proposes two extensions to BGP4+ to provide scalable multihoming in IPv6. The first is a new well-known and mandatory "TunneL (TL)" BGP path attribute that allows a multihomed enterprise to maintain global connectivity in the presence of network outages within a direct provider Autonomous System (AS) without adding any global forwarding overhead. The second is a new well-known and mandatory "Selective Announcement (SA)" BGP community attribute that allows the multihomed enterprise to recover from failures in distant AS's by explicitly specifying the list of AS's to which the site's reachability must be advertised. These two extensions form the core of the "Network Layer Multihoming Protocol (NLMP)" described in this draft. NLMP is designed to be used by both multihomed providers and multihomed enterprises. thanks, ramki From owner-multi6@ops.ietf.org Fri Aug 31 15:47:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14943 for ; Fri, 31 Aug 2001 15:47:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15cuFn-0003OY-00 for multi6-data@psg.com; Fri, 31 Aug 2001 12:46:59 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.33 #1) id 15cuFm-0003OS-00 for multi6@ops.ietf.org; Fri, 31 Aug 2001 12:46:58 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f7VJkGd11638; Fri, 31 Aug 2001 22:46:17 +0300 Date: Fri, 31 Aug 2001 22:46:16 +0300 (EEST) From: Pekka Savola To: Ramakrishna Gummadi cc: Subject: Re: Multihoming draft available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 31 Aug 2001, Ramakrishna Gummadi wrote: > Hi all, > I finished a draft that describes one way of doing scalable multihoming. > > http://www.cs.berkeley.edu/~ramki/draft-ramki-multi6-nlmp-00.txt > > Comments are highly appreciated. I plan to submit this as an internet > draft soon. The abstract is below: The draft implies only one EBR. More often than not, it's customer's box that breaks, and at least some folks require enterprise to have two exit routers in order to get real high availibility. Well, I guess EBR's could be easily duplicated and routes exchanged with e.g. route reflectors to keep databases in sync. Tunneling mechanism seems to be aiming to automate: IPv6 multihoming support at site exit routers draft-ietf-ipngwg-ipv6-2260-02.txt (at pseudo wg last call) I have some doubts about Selective Announcements. Has there been any research on how big 'set difference between the prefixes heard from the two providers' might be? Somehow I have a gut feeling, this could vary a lot even though there is nothing special going on. Nonetheless, there's also a worry about the scalability of this -- if this was ever applied to IPv4, or a lot of prefixes. That is, if a prominent transit breaks, it could be that 1,000 or 5,000 or even 10,000 prefixes would have to be readvertised _in a very fine-grained fashion to specific neighbours_ using this mechanism? That is, a big load of advertisements would have to go "upstream" hop-by-hop checking AS-PATH list, modifying it and selectively advertising prefixes. To me this at least _sounds_ like an awfully heavy task; current global advertisements are plain and simple. If this method _could_ be heavy, it would also reflect on the convergence times, and if it takes too long, the whole might become moot if connections might practically break anyway. (naturally, this wouldn't be a big worry with very aggregated DFZ such as IPv6 currently is). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-multi6@ops.ietf.org Fri Aug 31 16:02:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15090 for ; Fri, 31 Aug 2001 16:02:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15cuV2-0003dQ-00 for multi6-data@psg.com; Fri, 31 Aug 2001 13:02:44 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.33 #1) id 15cuV1-0003dK-00 for multi6@ops.ietf.org; Fri, 31 Aug 2001 13:02:43 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id NAA27769; Fri, 31 Aug 2001 13:02:39 -0700 (PDT) Date: Fri, 31 Aug 2001 13:02:39 -0700 (PDT) From: Ramakrishna Gummadi To: Pekka Savola cc: Subject: Re: Multihoming draft available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Thanks, Pekka, for your prompt comments. > The draft implies only one EBR. More often than not, it's customer's box > that breaks, and at least some folks require enterprise to have two exit > routers in order to get real high availibility. Well, I guess EBR's could > be easily duplicated and routes exchanged with e.g. route reflectors to > keep databases in sync. That is correct; I did not explicitly describe how to make EBR highly available, but this is one possible approach. > Tunneling mechanism seems to be aiming to automate: > > IPv6 multihoming support at site exit routers > draft-ietf-ipngwg-ipv6-2260-02.txt > > (at pseudo wg last call) Both automate and expand the set of failures that can be tolerated, in my opinion. The main drawback of RFC2260 is that it only provides limited redundancy. However, the goal is to show that tunneling, as a primitive, is sufficiently powerful to provide resiliency even against provider-wide failures. > I have some doubts about Selective Announcements. Has there been any > research on how big 'set difference between the prefixes heard from the > two providers' might be? Somehow I have a gut feeling, this could vary a > lot even though there is nothing special going on. Unfortunately, I don't have any first-hand data. However, I have heard at SIGCOMM two days ago that there have been a couple of internet drafts that describe selective announcements, possibly in a different context. I am trying to get the exact pointers to these drafts. > > Nonetheless, there's also a worry about the scalability of this -- if this > was ever applied to IPv4, or a lot of prefixes. That is, if a prominent > transit breaks, it could be that 1,000 or 5,000 or even 10,000 prefixes > would have to be readvertised _in a very fine-grained fashion to specific > neighbours_ using this mechanism? That is, a big load of advertisements > would have to go "upstream" hop-by-hop checking AS-PATH list, modifying it > and selectively advertising prefixes. To me this at least _sounds_ like > an awfully heavy task; current global advertisements are plain and simple. Correct; under worst-case scenario (many backbone providers simultaneously break), selective advertisement can be as bad as polluting the DFZ with every multihomed prefix as today. However, the average case is hopefully much better, both because of space-time scoping of announcements, and because tunneling can always be used as the first line of defense. > If this method _could_ be heavy, it would also reflect on the convergence > times, and if it takes too long, the whole might become moot if > connections might practically break anyway. > > (naturally, this wouldn't be a big worry with very aggregated DFZ such as > IPv6 currently is). With IPv6, this should not be much of a problem, like you say. -ramki > -- > 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 > >