From owner-multi6@ops.ietf.org Wed Oct 1 03:18:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01003 for ; Wed, 1 Oct 2003 03:18:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4bAa-0006sW-42 for multi6-data@psg.com; Wed, 01 Oct 2003 07:13:08 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.22) id 1A4b91-0006o6-0c for multi6@ops.ietf.org; Wed, 01 Oct 2003 07:11:31 +0000 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 2CB611C; Wed, 1 Oct 2003 10:24:48 +0300 (EEST) Message-ID: <3F7A7E27.2030005@nomadiclab.com> Date: Wed, 01 Oct 2003 10:11:35 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es Cc: Dave Crocker , Multi6 WG Subject: Re: Security requirements for identification References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marcelo, >> In my opinion, strongly protecting the adding mechanism is really >> the most important point. It may be also useful to include a >> check whenever you start to use a locator after a long period of >> inactivity, even if the locator is already in the pool. >> >> Arranging an attack where you use a given address and stop using >> it just before your victim arrives and starts to use it seems >> to be very hard, and probably not worth worrying about. > > Well, then why don't we just extend mip BCE maximum lifetime then? > If i understand correctly, this is exaclty the type of attack that the > maximum BCE lifetime bound prevents. Well, the MIPv6 RO case is more complicated, since the home address is used as the identifier, too. In my statement above, I was merely referring to IP addresses that are used as locators. If you use an address as an identifier, there are additional complications. The biggest burden is probably that all new connections will use an existing BCE binding. Hence, if you have once managed to convince a node that a given *identifier* (home address) is reachable at a given *locator* (care-of address), you could launch attacks based on that unless the binding is periodically checked. Consequently, we would not need the periodic checks on the care-of address. However, it is much simpler to just use the base mechanism and check both care-of and home addresses periodically than to have a separate mechanism that only checks reachability through the home address. --Pekka Nikander From owner-multi6@ops.ietf.org Wed Oct 1 03:31:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01340 for ; Wed, 1 Oct 2003 03:31:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4bPa-00082A-J0 for multi6-data@psg.com; Wed, 01 Oct 2003 07:28:38 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.22) id 1A4bP1-0007xy-MY for multi6@ops.ietf.org; Wed, 01 Oct 2003 07:28:03 +0000 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 3A4001C; Wed, 1 Oct 2003 10:41:21 +0300 (EEST) Message-ID: <3F7A8208.6030607@nomadiclab.com> Date: Wed, 01 Oct 2003 10:28:08 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li Cc: Kurt Erik Lindqvist , Randy Bush , Christian Huitema , Multi6 WG Subject: Properties for identifiers (was Re: Security requirements for identification) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Dropping HIP ML since this does not concern HIP any more, and fixing the subject.] Tony Li wrote: > Ok, let me see if I can give a taxonomy of possible > identifier properties: > > 1. Syntax > 2. Global Semantics > 3. Local Semantics > 3. Generation In my humble opinion, we should most probably first have some kind of idea of the semantics, before starting to consider syntax or generation. On the other hand, all the four issues are intertwined, and therefore considering pure semantics before syntax or generation may be pretty hard. What comes to semantics, I don't see much value in any *long* *term* solution where the identifiers have *considerably* different local and global semantics. (The only difference I possibly see is that an ID may be globally anonymous or pseudonymous while locally well known and linkable to the real world.) Personally, I don't mcy want to consider short term solutions, since I am lacking both interest and expertese in that area. From my long term point of view, I also don't believe in identifiers that are have any kind of topological semantics. From my point of view, one of the most important aspects of the id/loc split is to leave topology to the locators, and free identifiers from the burden of topology. I do admit that topologically linked identifiers may make sense if we consider just multi-homing and not mobility or the other potential goals of id/loc split. Hence, it may make sense to have such identifiers as a part of a short term solution. Finally, there were two dimensions that you did not mention in the property list at all: 1. Security, or the level of assurance of identification that one can gain through using the identifier. Note that we get a fair level of assurance from the routing system today. 2. Privacy, or the easyness/hardness of linking an identifier to a real world entity (node or user). Note that we do have some level of privacy today, due to NAT, dynamic address allocation in dial up servers, etc. There are certainly others, but these two came to my mind. --Pekka Nikander From owner-multi6@ops.ietf.org Wed Oct 1 06:09:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06424 for ; Wed, 1 Oct 2003 06:09:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4dpb-000Kdr-A8 for multi6-data@psg.com; Wed, 01 Oct 2003 10:03:39 +0000 Received: from [163.117.136.123] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.22) id 1A4dp5-000KZh-Bb for multi6@ops.ietf.org; Wed, 01 Oct 2003 10:03:07 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 9E0AE4342D; Wed, 1 Oct 2003 12:03:06 +0200 (CEST) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp03.uc3m.es (Postfix) with ESMTP id 3A7B02B671; Wed, 1 Oct 2003 12:03:06 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: Erik Nordmark , mbagnulo@ing.uc3m.es Subject: Re: Security requirements for identification Date: Wed, 1 Oct 2003 12:03:05 +0200 User-Agent: KMail/1.5 Cc: Erik Nordmark , Pekka Nikander , Multi6 WG , hipsec@honor.trusecure.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310011203.07689.jrh@it.uc3m.es> X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 01 October 2003 00:31, Erik Nordmark wrote: > > As you mention, there are multiple times that i don't really need to know > > the identifier of the end-point that i want to communicate to, but what i > > want is the identifier of the service that i want to contact (is this > > what you meant?) > > Yep. Hello, I'm trying to follow this thread, which seems very interesting, but I'm surprised with this statement. IMO when you make a DNS query you want to get the identifier of the end-point, to be able to start the communication. Although it's true that the name usually gives hints about the service, this isn't always true. If you need "www.google.com", you already know that the service will be "HTTP". You don't ask the DNS for the service, what you really need to know is the address of "google" to start the HTTP transfer. Don't you agree with this ? Cheers. -- JFRH From owner-multi6@ops.ietf.org Wed Oct 1 10:27:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15125 for ; Wed, 1 Oct 2003 10:27:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4hpA-000DQk-JX for multi6-data@psg.com; Wed, 01 Oct 2003 14:19:28 +0000 Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.22) id 1A4hoe-000DNm-EX for multi6@ops.ietf.org; Wed, 01 Oct 2003 14:18:56 +0000 Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (sccrmhc11) with SMTP id <2003100114185501100p9klpe> (Authid: sdawkins@comcast.net); Wed, 1 Oct 2003 14:18:55 +0000 Message-ID: <04a701c38826$f3c64d20$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Multi6 WG" , References: <200310011203.07689.jrh@it.uc3m.es> Subject: Re: Security requirements for identification Date: Wed, 1 Oct 2003 09:18:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-0.4 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Juan, I'm also a little confused by the discussion, but I had assumed that we had a service name and were using DNS SRV records, which also include port numbers, etc. Not sure how a computer knows www.google.com is HTTP - or how travel.yahoo.com is also HTTP, if you're keying off the name... But somebody can tell us what they REALLY meant now. Spencer ----- Original Message ----- From: "Juan Rodriguez Hervella" To: "Erik Nordmark" ; Cc: "Erik Nordmark" ; "Pekka Nikander" ; "Multi6 WG" ; Sent: Wednesday, October 01, 2003 5:03 AM Subject: Re: Security requirements for identification > Hello, > > I'm trying to follow this thread, which seems very interesting, but I'm > surprised with this statement. IMO when you make a DNS query > you want to get the identifier of the end-point, to be able to start > the communication. Although it's true that the name usually > gives hints about the service, this isn't always true. If you > need "www.google.com", you already know that the service will > be "HTTP". You don't ask the DNS for the service, what you really > need to know is the address of "google" to start the HTTP transfer. > > Don't you agree with this ? > > Cheers. > > -- > JFRH > From owner-multi6@ops.ietf.org Wed Oct 1 12:05:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21090 for ; Wed, 1 Oct 2003 12:05:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4jPD-000NCB-5S for multi6-data@psg.com; Wed, 01 Oct 2003 16:00:47 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.22) id 1A4jOe-000N64-Tt for multi6@ops.ietf.org; Wed, 01 Oct 2003 16:00:13 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 0785243173; Wed, 1 Oct 2003 18:00:12 +0200 (CEST) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp01.uc3m.es (Postfix) with ESMTP id 6534C99EB1; Wed, 1 Oct 2003 18:00:11 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: "Spencer Dawkins" , "Multi6 WG" , Subject: Re: Security requirements for identification Date: Wed, 1 Oct 2003 18:00:10 +0200 User-Agent: KMail/1.5 References: <200310011203.07689.jrh@it.uc3m.es> <04a701c38826$f3c64d20$0400a8c0@DFNJGL21> In-Reply-To: <04a701c38826$f3c64d20$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310011800.12550.jrh@it.uc3m.es> X-Spam-Status: No, hits=-0.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 01 October 2003 16:18, Spencer Dawkins wrote: > Dear Juan, > > I'm also a little confused by the discussion, but I had assumed that > we had a service name and were using DNS SRV records, which also > include port numbers, etc. Not sure how a computer knows > www.google.com is HTTP - or how travel.yahoo.com is also HTTP, if > you're keying off the name... Uh I didn't realize of the existence of DNS SRV records... they might be talking about that. I was thinking about human-machine interaction which is what most users daily do with computers, i. e, they open IExplore, they usually type a name and everything ends up well... IExplore knows the service because it reads the URL. IMO applications know in advance the service that has to be used (service = port), so they only need to find the "remote end-point" to start the communication with. Not 100% of the applications behave like this, I know, but what I wanted to note is that the DNS is used mainly for identification/location purposes, it is *not* a service lookup.... Anyway, I think this talk is to be "off topic" in this thread. What I really would like to know is what they REALLY meant, cause I'm not understanding a thing (lol) Cheers ^--^ > But somebody can tell us what they REALLY meant now. > > Spencer > > ----- Original Message ----- > From: "Juan Rodriguez Hervella" > To: "Erik Nordmark" ; > Cc: "Erik Nordmark" ; "Pekka Nikander" > ; "Multi6 WG" ; > > Sent: Wednesday, October 01, 2003 5:03 AM > Subject: Re: Security requirements for identification > >>> As you mention, there are multiple times that i don't really need to know >>> the identifier of the end-point that i want to communicate to, but what i >>> want is the identifier of the service that i want to contact (is this >>> what you meant?) >> >> Yep. > Hello, > > I'm trying to follow this thread, which seems very interesting, but > > I'm > > surprised with this statement. IMO when you make a DNS query > you want to get the identifier of the end-point, to be able to start > the communication. Although it's true that the name usually > gives hints about the service, this isn't always true. If you > need "www.google.com", you already know that the service will > be "HTTP". You don't ask the DNS for the service, what you really > need to know is the address of "google" to start the HTTP transfer. > > Don't you agree with this ? > > Cheers. > > -- > JFRH -- JFRH From owner-multi6@ops.ietf.org Wed Oct 1 18:40:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08895 for ; Wed, 1 Oct 2003 18:40:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4pYe-0003hC-PN for multi6-data@psg.com; Wed, 01 Oct 2003 22:34:56 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.22) id 1A4pY6-0003ef-SL for multi6@ops.ietf.org; Wed, 01 Oct 2003 22:34:22 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h91MY7is025686; Wed, 1 Oct 2003 15:34:08 -0700 (PDT) Received: from lillen (d-mpk17-89-167.Eng.Sun.COM [129.146.89.167]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h91MY5Q25415; Thu, 2 Oct 2003 00:34:06 +0200 (MEST) Date: Thu, 2 Oct 2003 00:28:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Terminology To: Pekka Nikander Cc: Dave Crocker , Multi6 WG In-Reply-To: "Your message with ID" <3F794A96.70205@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > We clearly need two different words for two different actions: > > 1. Handing over an "identifier" from one end-point to another, > with the intention of the receiving end-point being able to > contact the "identified" end-point in the future. > > 2. Handing over an end of an (active) association from one > end-point to another. > > I was using the term "referral" in the first sense, while you > seem to be using in the second sense. FWIW I've been thinking of #2 as "rehoming" while calling #1 "referral". I think there is also overlapping terminology around "rendez-vous". I've seen Keith More use this term for the case when applications on node A and B communicate for a while, and A ends by saying "please contact me at A when done". At some later point in time B will use this to get back to A. But we are also using it to describe the process where one host finds another; there are clearly elements of this more general finding which could instead be described as "lookup". Erik From owner-multi6@ops.ietf.org Wed Oct 1 19:04:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09712 for ; Wed, 1 Oct 2003 19:04:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4pz9-0005r5-SZ for multi6-data@psg.com; Wed, 01 Oct 2003 23:02:19 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.22) id 1A4pyW-0005oQ-Uz for multi6@ops.ietf.org; Wed, 01 Oct 2003 23:01:40 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h91N1LVo018215; Wed, 1 Oct 2003 16:01:22 -0700 (PDT) Received: from lillen (d-mpk17-89-167.Eng.Sun.COM [129.146.89.167]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h91N1JQ27298; Thu, 2 Oct 2003 01:01:19 +0200 (MEST) Date: Thu, 2 Oct 2003 00:56:02 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Security requirements for identification To: Juan Rodriguez Hervella Cc: Erik Nordmark , mbagnulo@ing.uc3m.es, Pekka Nikander , Multi6 WG , hipsec@honor.trusecure.com In-Reply-To: "Your message with ID" <200310011203.07689.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > I'm trying to follow this thread, which seems very interesting, but I'm > surprised with this statement. IMO when you make a DNS query > you want to get the identifier of the end-point, to be able to start > the communication. Although it's true that the name usually > gives hints about the service, this isn't always true. If you > need "www.google.com", you already know that the service will > be "HTTP". You don't ask the DNS for the service, what you really > need to know is the address of "google" to start the HTTP transfer. Perhaps the "service" vs. "hostname" is confusing. It isn't about the upper layer protocols in any case. The issue is that today when you ask for A (or AAAA) records for a given fqdn you might get back multiple answers, but it isn't clear whether the multiple answers are - multiple IP address for the same host/endpoints (i.e. the entity which holds the TCP and application state), - multiple IP addresses for the service but implemented by different endpoints - some combination (6 IP addresses for 3 hosts which each have 2 IP addresses) This distinction is important for multi6, since you don't want to try to failover your TCP/application communication to an endpoint which doesn't have the TCP/application state. Is that more clear? Erik From owner-multi6@ops.ietf.org Thu Oct 2 02:05:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26756 for ; Thu, 2 Oct 2003 02:05:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4wV7-0009RX-C6 for multi6-data@psg.com; Thu, 02 Oct 2003 05:59:45 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.22) id 1A4wUc-0009NJ-1h for multi6@ops.ietf.org; Thu, 02 Oct 2003 05:59:14 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id A203C1C; Thu, 2 Oct 2003 09:12:30 +0300 (EEST) Message-ID: <3F7BB288.7060102@nomadiclab.com> Date: Thu, 02 Oct 2003 08:07:20 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: Dave Crocker , Multi6 WG Subject: Re: Terminology References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>We clearly need two different words for two different actions: >> >> 1. Handing over an "identifier" from one end-point to another, >> with the intention of the receiving end-point being able to >> contact the "identified" end-point in the future. >> >> 2. Handing over an end of an (active) association from one >> end-point to another. >> >>I was using the term "referral" in the first sense, while you >>seem to be using in the second sense. > > FWIW I've been thinking of #2 as "rehoming" while calling #1 "referral". Oh well. English seems to be hard language. I think that we have at least three different scenarios here. 1) Node A has an A-B session with node B. A sends an identifier of node C over the A-B session, allowing B to start a new session with C. This is what I originally thought that referral means. This is what seems to happen in FTP when you use a PORT command that refers to a third host. 2) Node A has an A-B session with node B. A starts a new A-C session with node C, and hands over its (A's) end of the active A-B session to C, so that the A-B session now becomes a C-B session, allowing B and C can communicate directly. A is no more involved in communication. According to my poor understanding this is what Dave meant with referral, but I am probably wrong. Erik seems to call this rehoming. I don't have a name for this, since I have never seen this in real life. 3) Node A has a session with node B. A sends one of its own, application level identifiers, say A_app, and the corresponding "identity" to node B, allowing node B to appear as A_app in the future. I would call this rehoming, since now the (application level) entity Aapp that was earlier located at node A is now located at node B. --Pekka Nikander From owner-multi6@ops.ietf.org Thu Oct 2 23:21:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06621 for ; Thu, 2 Oct 2003 23:21:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5GPY-000CwB-Pc for multi6-data@psg.com; Fri, 03 Oct 2003 03:15:20 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.22) id 1A5GOe-000Crt-Ae for multi6@ops.ietf.org; Fri, 03 Oct 2003 03:14:24 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h933Jif27048; Thu, 2 Oct 2003 20:19:44 -0700 Date: Thu, 2 Oct 2003 15:13:17 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1784609428.20031002151317@brandenburg.com> To: Pekka Nikander CC: Erik Nordmark , Multi6 WG Subject: Re: Terminology In-Reply-To: <3F7BB288.7060102@nomadiclab.com> References: <3F7BB288.7060102@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, PN> Oh well. English seems to be hard language. I think that we PN> have at least three different scenarios here. Unfortunately, I think that the problem is not with the language we are using. I do not think that any of this would go more smoothly in spanish, japanese or tamil. Rather, I think we have been using non-technical terms without defining their technical use. Consequently the use has not been precise. Although I'd like the words to have a "natural" meaning that is reasonable, I am more concerned with having precise terms used consistently. Unfortunately, the way to deal with a pattern of imprecise use is not to re-define existing terms, but to throw them away. As Erik notes, we should mostly not use "address" but should instead use "locator" and (perhaps) identifier. We need to do the same thing for these other terms. So let's stop using _Rendezvous_. PN> 1) Node A has an A-B session with node B. A sends an identifier PN> of node C over the A-B session, allowing B to start a new PN> session with C. I think this is consistent with Erik's usage. So, yes, it seems like calling this _Referral_ is ok. In other words, A is referring B over to C. The referral is stateless, with respect to the A-B association. PN> 2) Node A has an A-B session with node B. A starts a new A-C PN> session with node C, and hands over its (A's) end of the PN> active A-B session to C, so that the A-B session now becomes PN> a C-B session, allowing B and C can communicate directly. PN> A is no more involved in communication. The essential part of this is that A hands its part of an association over to C. The detail of 'starts a new A-C session' is not essential to the activity. This sounds like _Rehoming_ in the way that Erik was suggesting. Yes? PN> According to my poor understanding this is what Dave meant PN> with referral, but I am probably wrong. I think your understanding was/is just fine. I also think my usage was bad. Calling this rehoming strikes me as better. For both words, I think the usages are closer to their 'natural' meanings. PN> 3) Node A has a session with node B. A sends one of its own, PN> application level identifiers, say A_app, and the corresponding PN> "identity" to node B, allowing node B to appear as A_app in the PN> future. PN> I would call this rehoming, since now the (application level) PN> entity Aapp that was earlier located at node A is now located PN> at node B. Oh my goodness. Yes, this is an interesting scenario. And I think that, yes, 2 and 3 are variations on the concept of rehoming. But I also think that #3 is beyond anything we currently need to deal with. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Fri Oct 3 13:42:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17918 for ; Fri, 3 Oct 2003 13:42:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5Tt4-000IMk-2z for multi6-data@psg.com; Fri, 03 Oct 2003 17:38:42 +0000 Received: from [195.43.225.70] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.22) id 1A5TsQ-000IKi-L5 for multi6@ops.ietf.org; Fri, 03 Oct 2003 17:38:02 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by kurtis-lindqvists-computer.local (8.12.9/8.10.2) with ESMTP id h93Hc1dV002327 for ; Fri, 3 Oct 2003 19:38:02 +0200 (CEST) Date: Fri, 3 Oct 2003 19:37:55 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Subject: Fwd: Internet-Draft Cutoff Dates for Minneapolis, MN, USA From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <52794465-F5C8-11D7-B967-0003936663F8@kurtis.pp.se> X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-3.6 required=5.0 tests=BAYES_30,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 More FYI. - - kurtis - Begin forwarded message: > From: Internet-Drafts Administrator > Date: fre okt 3, 2003 13:30:42 Europe/Stockholm > To: IETF-Announce: ; > Subject: Internet-Draft Cutoff Dates for Minneapolis, MN, USA > > > NOTE: There are two (2) Internet-Draft Cutoff dates > > October 20th: Cutoff for Initial Submissions (new documents) > > All initial submissions(-00) must be submitted by Monday, October 20th, > at 09:00 ET. Initial submissions received after this time will NOT be > made available in the Internet-Drafts directory, and will have to be > resubmitted. > > As before, all initial submissions (-00.txt) with a filename beginning > with a draft-ietf MUST be approved by the appropriate WG Chair prior to > processing and announcing. WG Chair approval must be received by > Monday, October 13th. > > Please do NOT wait until the last minute to submit. > > Be advised: NO placeholders. Updates to initial submissions received > the week of October 20th will NOT be accepted. > > October 27th: FINAL Internet-Draft Cutoff > > All revised Internet-Draft submissions must be submitted by Monday, > October 27th, 2003 at 09:00 ET. Internet-Drafts received after this > time will NOT be announced NOR made available in the Internet-Drafts > Directories. > > We will begin accepting Internet-Draft submissions the week of the > meeting, though announcements will NOT be sent until the IETF meeting > is over. > > Thank you for your understanding and cooperation. Please do not > hesitate > to contact us if you have any questions or concenrs. > > FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_58.html > > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP32z9qarNKXTPFCVEQKQagCeJgwiGVUXZKG39DsE/+YeEPuJ7xAAoK52 ojnDd1dl4Ofw28vTthC2BnQw =aqb+ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Fri Oct 3 13:43:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17952 for ; Fri, 3 Oct 2003 13:43:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5Trx-000IHX-ED for multi6-data@psg.com; Fri, 03 Oct 2003 17:37:33 +0000 Received: from [195.43.225.70] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.22) id 1A5TrR-000IEw-Aa for multi6@ops.ietf.org; Fri, 03 Oct 2003 17:37:01 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by kurtis-lindqvists-computer.local (8.12.9/8.10.2) with ESMTP id h93HaxdV002324 for ; Fri, 3 Oct 2003 19:37:00 +0200 (CEST) Date: Fri, 3 Oct 2003 19:36:53 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Subject: Fwd: To the attention of all WG Chairs From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <2D9CD6C5-F5C8-11D7-B967-0003936663F8@kurtis.pp.se> X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-3.6 required=5.0 tests=BAYES_30,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If you haven't seen this. - - kurtis - Begin forwarded message: > From: Internet-Drafts Administrator > Date: fre okt 3, 2003 13:30:24 Europe/Stockholm > To: IETF-Announce: ; > Subject: To the attention of all WG Chairs > > > In order to process the many version 00 I-Ds that are received > before an IETF meeting in a timely manner, we ask that you send a LIST > OF > THE NAMES of the drafts you expect to have submitted and have approved > for > publication as WG documents to internet-drafts@ietf.org no later than > five > (5) business days prior to the cutoff date for the meeting. > > Please include the word "Permission" in the Subject field. > > This procedure will expedite the posting of version 00 I-Ds, > allowing > more time for review by the public. > > Thank you you for your cooperation in this matter. > > The IETF Secretariat > > FYI: All significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_58.html > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP32zuaarNKXTPFCVEQIhRwCgnztUbGe97rHngj/MB9BJUgOPKEcAoPBg izxo5jCsiH/DN6S9rPInF3nZ =yRnH -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Oct 9 13:04:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29506 for ; Thu, 9 Oct 2003 13:04:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7e3z-0000cv-Kj for multi6-data@psg.com; Thu, 09 Oct 2003 16:54:55 +0000 Received: from [130.79.44.193] (helo=dpt-info.u-strasbg.fr) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7e3Z-0000bn-JS for multi6@ops.ietf.org; Thu, 09 Oct 2003 16:54:29 +0000 Received: from clarinet.u-strasbg.fr (pichnet.u-strasbg.fr [130.79.90.171]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.6) with ESMTP id h99H49nu031505; Thu, 9 Oct 2003 19:04:10 +0200 Message-ID: <3F8592BA.1010608@clarinet.u-strasbg.fr> Date: Thu, 09 Oct 2003 18:54:18 +0200 From: montavont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030727 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org, mobile-ip@sunroof.eng.sun.com, nemo@ietf.org, multi6@ops.ietf.org Subject: New I-D on multi-homing Content-Type: multipart/mixed; boundary="------------030708080606030603080409" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------030708080606030603080409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, Just to inform you that we have submitted a new I-D on multihoming. Lot of people have already work on multihoming in individual submissions. We tried to write a problem statement for multihomed MN in this I-D and hope that this I-D will initiate some discussions on this topic. Here is the abstact of the I-D: Individual solutions have been proposed to extend Mobile IPv6 in order to allow mobile nodes to be multihomed, but all issues have not been addressed by a single document. In this document, we thus propose a taxonomy to classify the situations where a mobile node may be multihomed. This taxonomy is then used to describe all multihomed scenarios. Issues preventing mobile nodes to be multihomed while operating Mobile IPv6 are highlighted. This document doesn't aim at proposing solutions, however, it is expected to raise discussion in order to make sure forthcoming solutions will address all the issues. Nicolas --------------030708080606030603080409 Content-Type: text/plain; name="draft-montavont-mobileip-multihoming-pb-statement-00.txt" Content-Disposition: inline; filename="draft-montavont-mobileip-multihoming-pb-statement-00.txt" Content-Transfer-Encoding: 8bit IETF Mobile IP Working Group N. Montavont Internet-Draft LSIIT Expires: April 9, 2004 R. Wakikawa T. Ernst WIDE at Keio University T. Noel LSIIT October 10, 2003 Problem Statement for multihomed Mobile Nodes draft-montavont-mobileip-multihoming-pb-statement-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 9, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Individual solutions have been proposed to extend Mobile IPv6 in order to allow mobile nodes to be multihomed, but all issues have not been addressed by a single document. In this document, we thus propose a taxonomy to classify the situations where a mobile node may be multihomed. This taxonomy is then used to describe all multihomed scenarios. Issues preventing mobile nodes to be multihomed while operating Mobile IPv6 are highlighted. This document doesn't aim at Montavont, et al. Expires April 9, 2004 [Page 1] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 proposing solutions, however, it is expected to raise discussion in order to make sure forthcoming solutions will address all the issues. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Multihoming Scenarios . . . . . . . . . . . . . . . . . . . . 6 4.1 Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3 MN connected to home link . . . . . . . . . . . . . . . . . . 8 5. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Montavont, et al. Expires April 9, 2004 [Page 2] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 1. Introduction New mobile nodes often integrate several wireless technologies. The main purpose of this integration is to federate all means of communications in order to have an ubiquitous mobile node which can be used to access to the Internet everywhere and at any time. Permanent Internet connectivity is required by some applications while a mobile node moves across several access networks (i.e. ISPs, hotspots, etc). For example, it is desirable to maintain the Internet connectivity while an automobile running on a freeway receives voice or video streaming data from different access networks. Unfortunately, there is no network interfaces assuring global scale connectivity. Therefore, a mobile node should use various type of network interfaces to obtain wide area network connectivity [11]. In addition, each network interface has different cost, performance, bandwidth, access range, and reliability. Users should thus be able to select the most appropriate set of network interface(s) depending on a visiting network environment, since wireless networks are mutable and less reliable than wired networks. Users should also be able to select the most appropriate interface per communication type. For example, TCP communication is best transmitted over wireless interface, while UDP communication is sent over a wired interface to avoid disturbing TCP connections. Mobile IPv6 [1] is being designed to allow a mobile node to maintain its IPv6 communications while moving between IPv6 subnets. However, the current specification does not give any hints nor requirements to deal with mobile nodes with several points of attachement, i.e. a multihomed mobile node. We propose to evaluate the behavior of standard Mobile IPv6 on a multihomed mobile node, and we will try to identify if modifications or enhancements are required in the specification. This document has two goals. The first goal is to define a taxonomy which helps to represent the different cases of multihoming. Then we describe scenarios where mobile nodes are multihomed. These scenarios show the configuration a mobile node may have (number of interfaces, number of home addresses or number of careof addresses). We also give a concrete illustration for each scenario. The second goal of this document is to define the requirements needed to manage multihomed mobile nodes. Different issues will be raised in order to provide full support of multihomed mobile nodes in MIPv6. The potentially needed solutions to support new features will be described in a separate document. Montavont, et al. Expires April 9, 2004 [Page 3] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 2. Terminology In this section we define the terms needed to analyse mobile node with mulitple points of attachment. Some definition are taken from [1], while other are completed or only defined in this document. Interface (from [7]) A node's attachment to a link Multihomed mobile node A mobile node is said multihomed when it has several IPv6 addresses to choose between. A mobile node has several IPv6 addresses to choose between in the following cases: multi-prefixed: multiple prefixes are advertised on the link(s) the mobile node is connected to. multi-interfaced: multiple interfaces to choose between, on the same link or not. multi-linked: multiple links to choose between (just like multi-interfaced but all interfaces are NOT connected to the same link) multi-sited: when using IPv6 site-local address and attached to different sites Montavont, et al. Expires April 9, 2004 [Page 4] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 3. Benefits Several benefits of multihoming can be envisioned: o Ubiquitous Computing: to provide an extended coverage area. Multiple interfaces bound to distinct technologies can then be used to ensure a permanent connectivity is offered. o Redundancy: to act upon failure of one point of attachment. o Load Balancing: to balance load between multiple point of attachments (simultaneously active or not). o Preference settings: to provide the user or the application the ability to choose the prefered transmission technology or access network for reasons of cost, politics, bandwidth requirement, delay, etc. Montavont, et al. Expires April 9, 2004 [Page 5] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 4. Multihoming Scenarios Different scenarios may lead to the fact that a mobile node may be multihomed. In this section are listed all the configurations where a mobile node may have multiple points of attachment. 4.1 Taxonomy To help to refer to a specific scenario, we define the following scheme: Scenario (x,y,z) where o x = number of home addresses (HoAs) o y = number of careof addresses (CoAs) o z = number of active interfaces The value of each identifier can be 1 if there is only one parameter, or n if there are several. The value n does not specify any number, but indicate that there are more than one parameters. An illustration of this taxonomy is given in Figure 1. Mobile Node HoA1 HoA2 ... HoAn --> Mobile IP layer (x) | | | +-----+--------+ | | | | | | | CoA1 +--CoA2 +---CoA3 ... CoAn --> IP layer (y) | | | | Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *) | | | | +-----+----+ | | | | | IF1 IF2 ... IFn --> Physical layer (z) (z = the number of active interface) HoA1 ::= {CoA1, 2, 3} [IF1 and IF2] HoA2 ::= {CoA3} [IF2] Mobile Node(x = 2, y = 3, z = 2) Figure 1. Illustration of the chosen taxonomy Montavont, et al. Expires April 9, 2004 [Page 6] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 * because number of IPv6 link is equal to the number of CoAs, equal to y The variable x indicates the number of HoAs allocated to a MN. A MN may have multiple HoAs (x=n) when either: o The MN has only one home link, and all its HoAs are based on the same IPv6 prefix (e.g. the MN may have multiple interfaces). o The MN has only one home link, and several home addresses with distinct prefixes because there are several IPv6 prefixes advertised on the home link. o The MN has several home links, and thus has at least two HoAs with different IPv6 prefixes. 4.2 scenario 1. One HoA, one CoA, one interface (1,1,1) The MN is not multihomed. The MN has only one interface, with one HoA and is currently away from its home link. 2. Several HoAs, one CoA, one interface (n,1,1) The MN is multihomed, since it has several home addresses. Once the MN is connected to a visited IPv6 subnet, it gets one CoA and remains simulteneously reachable through all its HoAs. 3. Several HoAs, several CoAs, one interface (n,n,1) The MN is multihomed, since it has multiple addresses to choose between. In this case, the MN can be either connected to different IPv6 links at the same time, with the same interface, or it can be attached to a single link where several IPv6 prefixes are advertised. In the latter case, it configures a CoA for each prefix. Then, it may register several of them with distant nodes to benefit from its multihoming properties. 4. Several HoAs, several CoAs, several interfaces (n,n,n) The MN is multihomed. Many scenarios may lead to this case. For example, consider a MN with three interfaces, two of them connected to their home link(two different home addresses) and the last one connected to a visited link where two IPv6 prefixes are advertised. Montavont, et al. Expires April 9, 2004 [Page 7] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 5. One HoA, several CoAs, one interface (1,n,1) The MN is multihomed (several CoAs). The case (1,n,1) occurs when a MN is connected to different IPv6 links with the same interface: either there are several IPv6 prefixes advertised on the link, or the interface allows the MN to be connected to different access point in different IPv6 subnets. 6. One HoA, several CoAs, several interfaces (1,n,n) The MN is multihomed: the MN has several addresses to choose between. For example, assume a MN with several interfaces, each connected to an IPv6 network (the same or not). Then at least one IPv6 address is configured on each interface. The MN has only one home link, and only one home agent. 7. One HoA, one CoA, several interfaces (1,1,n) The MN may be multihomed: if the MN has two interfaces, one connected to its home link (using its home address) and the other connected to a visted link (using a careof address), the MN is multihomed. If the MN is connected to a visited link with one interface and has no IPv6 connectivity with the other interfaces (not in the range of an access point or no IPv6 prefix forwarded on a Layer 2 link), the MN is not multihomed. 4.3 MN connected to home link When a MN is multihomed, some of its interfaces may be connected to its home link(s), at any point of time. In all multihoming scenarii listed in the previous subsection, the MN may be directly connected to a home link. Sometimes, when a MN is connected to a home link, it may have an impact on the multihoming management. For example, in the case (n,n,n), a MN may be connected to its home link(s) with some interface(s). If we consider the case where a MN has three interfaces, three HoAs and two CoAs (connected to two visited IPv6 subnets), the CoAs can not be registered with the home agent serving to MN on the home link it is connected to. This case has to be considered when defining the management of multihoming. Otherwise, the case (n,n,n) can translate into either case (n,1,n) or (n,0,n) according to the way the MN is connected to the Internet. Case (n,1,n) only happens when the MN is connected to a visited link with only one interface and obtain only one CoA. Other interfaces are connected to the home link(s). Montavont, et al. Expires April 9, 2004 [Page 8] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 In the case (n,0,n), i.e. several HoAs, no CoA, and several interfaces, all interfaces of the MN is connected to a home link. If home links have different prefixes, a HoA can be a CoA regarding another HoA. Such considerations must be taken into account in a document which presents a solution for multihomed MN since some MIPv6 features can not be used when the MN is connected to the same link as its home agent (e.g. home registration). So the fact that a multihomed MN is connected to a home link must be considered. Montavont, et al. Expires April 9, 2004 [Page 9] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 5. Open issues In this section we highlight different points which have to be taken into account to handle a multihomed MN using Mobile IPv6. These items constitute the requirements for a Mobile IPv6 node to benefit from its multihomed configuration in an optimized fashion. Some of them do not require more processing than those defined in [1] but management operation, while other requires changes in [1]. Only the needed requirements are given in this document, the solutions to meet these requirements will be defined in a separate document. Issues related to the Mobile IPv6 protocol are the following: 1. How to define a relation between HoAs and CoAs. When a MN has several HoAs and obtain a new CoA, to which HoA the new CoA will be bound to ? Moreover, a HoA may be considered as CoA regarding another home link of the MN. 2. How to identify an entry in the Binding Cache: several CoAs can be simultaneously used by a mobile node when it has multiple points of attachments. These CoAs can be bound to the same HoA on any distant node, such as the home agent whih manages this mobile node for this particular HoA. Therefore both distant node and the mobile node need a way to identify an entry in the Binding Cache. 3. How to manage multiple CoAs bound to a single HoA: a multihomed MN may have multiple Care-of addresses. The MN must be able to register all CoAs with a single HoA on a distant node (Correspondant node or HA). Issues non-related to the Mobile IPv6 protocol are the following: 1. How to allow a mobile node to simultaneously use several interfaces: this will be the global purpose of such a solution to support multiple interfaces on a mobile node. The solution should bring support to allow a MN, or even a fixed multihomed MN to simultaneously use several interfaces, whatever the number of HoAs, of CoAs the mobile node may have and whatever the network configuration the mobile node is connected to. 2. How to manage multiple HoAs: a mobile node may have several HoAs. As the taxonomy suggests, the fact that the mobile node has several HoAs is independant from the fact that the mobile has multiple interfaces. By the way, the fact that the mobile node has multiple interfaces does not imply that it has multiple HoAs and vice-versa. A mechanism should thus be defined to detail how to bind HoAs to a MN. Montavont, et al. Expires April 9, 2004 [Page 10] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 3. How a mobile node may redirect flows from one interface to another, in the different scenarios presented in section 3: this functionality would allow a mobile node to pursue any communication began on an interface while this interface becomes down and another one is available. 4. When a MN has several interfaces, it may want to use each interface differently. According to some policies and preferences, a multihomed MN may want to independantly manage each flow, in order to define which flow would be mapped to which interface and/or which flow can not use a determined interface. In order to optimize the global connectivity of a multihomed MN, a solution may be defined to allow multihomed MN to set filters on flow on distant nodes, such as mechanisms proposed by [10], [5] and [4]. Montavont, et al. Expires April 9, 2004 [Page 11] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 References [1] Perkins, C. and J. Arko, "Mobility Support in IPv6", I-D draft-ietf-mobileip-ipv6-24.txt, June 2003. [2] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to protect Mobile IPv6 signaling between Mobile Nodes and Home Agents", I-D draft-ietf-mobileip-mipv6-ha-ipsec-06.txt, June 2003. [3] Montavont, N., Noel, T. and M. Kassi, "MIPv6 for Multiple Interfaces", I-D draft-montavont-mobileip-mmi-01.txt, October 2003. [4] Koojana, K., Fikouras, N., Koensgen, A. and C. Goerg, "Filters for Mobile IPv6 Bindings (NOMADv6)", I-D draft-nomadv6-mobileip-filters-00.txt, July 2003. [5] Montavont, N. and T. Noel, "Home Agent Filtering For Mobile IPv6", I-D draft-montavont-mobileip-ha-filtering-v6-00.txt, July 2003. [6] Wakikawa, R., Uehara, K., Ernst, T. and K. Nagami, "Multiple careof Address Registration on Mobile IPv6", I-D draft-wakikawa-mobileip-multiplecoa-02.txt, September 2003. [7] Manner, J. and M. Kojo, "Mobility Related Terminology", I-D draft-ietf-seamoby-mobility-terminology-04.txt, April 2003. [8] Fikouras, N., Udugama, A., Koensgen, A., Goerg, C., Zirwas, W. and J. Eichinger, "Filters for Mobile IPv6 Bindings (NOMADv6)", I-D draft-nomad-mobileip-v6-filters-00.txt, July 2003. [9] Ernst, T., "Network Mobility Support Terminology", I-D draft-ietf-nemo-terminology-00.txt, May 2003. [10] Soliman, H., Elmalki, K. and C. Castelluccia, "Flow Movement in Mobile IPv6", I-D draft-soliman-mobileip-flow-move-03.txt, June 2003. [11] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay Networks", Journal Mobile Networks and Applications, vol. 3, number 4, pages 335-350, 1998. Montavont, et al. Expires April 9, 2004 [Page 12] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 Authors' Addresses Nicolas Montavont LSIIT - Univerity Louis Pasteur Ple API, bureau C444 Boulevard Sebastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 87 EMail: montavont@dpt-info.u-strasbg.fr URI: http://www-r2.u-strasbg.fr/~montavont/ Ryuji Wakikawa Jun Murai Lab., Keio University 5322 Endo Fujiwasa Kanagawa 252-8520 Japan Phone: +81-466-49-1394 EMail: ryuji@sfc.wide.ad.jp URI: http://www.mobileip.jp/ Thierry Ernst Jun Murai Lab. Keio University K2 Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki Kanagawa 212-0054 Japan Phone: +81-44-580-1600 EMail: ernst@sfc.wide.ad.jp URI: htpp://www.sfc.wide.ad.jp/~ernst Thomas Noel LSIIT - Univerity Louis Pasteur Ple API, bureau C444 Boulevard Sébastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 92 EMail: noel@dpt-info.u-strasbg.fr URI: http://www-r2.u-strasbg.fr/~noel/ Montavont, et al. Expires April 9, 2004 [Page 13] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Montavont, et al. Expires April 9, 2004 [Page 14] Internet-Draft Problem statement for multihomed Mobile Nodes October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Montavont, et al. Expires April 9, 2004 [Page 15] --------------030708080606030603080409-- From owner-multi6@ops.ietf.org Thu Oct 9 16:33:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09775 for ; Thu, 9 Oct 2003 16:33:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7hQb-000AXz-J5 for multi6-data@psg.com; Thu, 09 Oct 2003 20:30:29 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7hQT-000AXL-QG for multi6@ops.ietf.org; Thu, 09 Oct 2003 20:30:22 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06648; Thu, 9 Oct 2003 15:38:29 -0400 (EDT) Message-Id: <200310091938.PAA06648@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Cc: ipsec@lists.tislabs.com, multi6@ops.ietf.org, mip6@ietf.org, mip4@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nikander-esp-beet-mode-00.txt Date: Thu, 09 Oct 2003 15:38:28 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.7 required=5.0 tests=BAYES_40,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Bound End-to-End Tunnel (BEET) mode for ESP Author(s) : P. Nikander Filename : draft-nikander-esp-beet-mode-00.txt Pages : 28 Date : 2003-10-9 This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nikander-esp-beet-mode-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-nikander-esp-beet-mode-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: <2003-10-9142307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nikander-esp-beet-mode-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nikander-esp-beet-mode-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-9142307.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Fri Oct 10 04:31:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13976 for ; Fri, 10 Oct 2003 04:31:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7sdI-000ACQ-V9 for multi6-data@psg.com; Fri, 10 Oct 2003 08:28:20 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7sd3-000ABq-Fr for multi6@ops.ietf.org; Fri, 10 Oct 2003 08:28:05 +0000 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 63B1B1C; Fri, 10 Oct 2003 11:41:20 +0300 (EEST) Message-ID: <3F866D9C.6050807@nomadiclab.com> Date: Fri, 10 Oct 2003 11:28:12 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@honor.trusecure.com Cc: Multi6 WG , IPV6 WG , MIP6 WG , IPsec WG Subject: An official HIP BOF request has been sent Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_44 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Apologies for cross-posting. Please trim the CC: on replies.] Folks, I sent an official BOF request for a Host Identity Protocol BOF a few moments ago. Based on the discussions with the INT area ADs, it looks fairly probable that a BOF will be scheduled. The latest version of the proposed BOF agenda is available at http://www.tml.hut.fi/~pnr/HIP/hipbof.txt The latest version of the proposed WG charter is available at http://www.tml.hut.fi/~pnr/HIP/hip_charter_proposal.txt Note to the IPsec WG: The charter proposal suggest that the new WG would specify a small addition to ESP, basing on draft-nikander-esp-beet-mode-00.txt. Folks at the IPsec WG may have strong opinions on this. The most appropiate place to discuss the BOF and charter proposals is the hipsec mailing list. See the bof agenda and/or charter proposal for details on how to join to the mailing list. The list policy requires non-member postings to be explicitly approved by the list admins. --Pekka Nikander From owner-multi6@ops.ietf.org Sun Oct 12 06:20:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14003 for ; Sun, 12 Oct 2003 06:20:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8dHc-000A3s-FT for multi6-data@psg.com; Sun, 12 Oct 2003 10:17:04 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8dHV-000A3S-DG for multi6@ops.ietf.org; Sun, 12 Oct 2003 10:16:57 +0000 Received: (qmail 28212 invoked from network); 12 Oct 2003 10:14:58 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 12 Oct 2003 10:14:58 -0000 Message-ID: <3F892A4B.3030108@necom830.hpcl.titech.ac.jp> Date: Sun, 12 Oct 2003 19:17:47 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Routing table size? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all; How, do you think, will the size of global routing table be? As I raised the question before Vienna, Brian said it should be proportional to logarithm of the network size. Is it agreeable? If so, the next question is on the base of the logarithm. Masataka Ohta From owner-multi6@ops.ietf.org Sun Oct 12 07:02:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14590 for ; Sun, 12 Oct 2003 07:02:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8dyK-000C2E-Nr for multi6-data@psg.com; Sun, 12 Oct 2003 11:01:12 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8dy9-000C1q-6B for multi6@ops.ietf.org; Sun, 12 Oct 2003 11:01:01 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9CB0Ced036747; Sun, 12 Oct 2003 13:00:12 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 12 Oct 2003 13:00:08 +0200 Subject: Re: Routing table size? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: masataka ohta From: Iljitsch van Beijnum In-Reply-To: <3F892A4B.3030108@necom830.hpcl.titech.ac.jp> Message-Id: <3E6E7B14-FCA3-11D7-B291-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_44 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, okt 12, 2003, at 12:17 Europe/Amsterdam, masataka ohta wrote: > How, do you think, will the size of global routing table be? When? > As I raised the question before Vienna, Brian said it should > be proportional to logarithm of the network size. Not if the RIRs don't change their policies. They give out /32s so there is a linear relationship between the number of /64s / /48s in use and the number of distinct entries in the global IPv6 routing table. I vote we fire the RIRs as soon as v4 is obsolete because they just don't get it. (And they're costing the community way too much money to boot.) Assuming we'll see significant v6 deployment, my guess is 15k - 60k by 2010 (depending on the success of our efforts here), at which point the v4 table will be around 200k. From owner-multi6@ops.ietf.org Sun Oct 12 07:16:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14912 for ; Sun, 12 Oct 2003 07:16:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8eBu-000Cic-3E for multi6-data@psg.com; Sun, 12 Oct 2003 11:15:14 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8eBi-000Cgk-3K for multi6@ops.ietf.org; Sun, 12 Oct 2003 11:15:02 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id B02F38D9; Sun, 12 Oct 2003 07:15:00 -0400 (EDT) Received: from ops.arin.net (ops [192.149.252.141]) by smtp2.arin.net (Postfix) with ESMTP id 421A68CA for ; Sun, 12 Oct 2003 07:15:00 -0400 (EDT) Received: from ano2 ([192.136.136.105]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id HAA03783 for ; Sun, 12 Oct 2003 07:14:58 -0400 (EDT) From: "Ray Plzak" To: Subject: RE: Routing table size? Date: Sun, 12 Oct 2003 07:14:57 -0400 Message-ID: <002401c390b2$12d82740$698888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3E6E7B14-FCA3-11D7-B291-00039388672E@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-multi6@ops.ietf.org > [mailto:owner-multi6@ops.ietf.org] On Behalf Of Iljitsch van Beijnum > Sent: Sunday, October 12, 2003 7:00 AM > To: masataka ohta > Cc: multi6@ops.ietf.org > Subject: Re: Routing table size? > > > Not if the RIRs don't change their policies. Policies in the RIR service regions are made by the operators and users of the Internet as well as anyone else that is interested in IP addressing, routing, and related issues, not by RIR staffs or their Boards. If you feel that a particular allocation policy is not correct, then I suggest that you participate in the RIR forum in the area where you are located. Mail lists are open, there is no qualification to join. > I vote we fire the RIRs as soon as v4 is obsolete because they just > don't get it. (And they're costing the community way too much > money to > boot.) You should start by firing yourself, because if you are not actively involved in the policy process then you have only yourself to blame for the policies as they exist. Become involved. Ray From owner-multi6@ops.ietf.org Sun Oct 12 08:10:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15969 for ; Sun, 12 Oct 2003 08:10:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8f0x-000EtJ-Jx for multi6-data@psg.com; Sun, 12 Oct 2003 12:07:59 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8f0q-000Esp-2D for multi6@ops.ietf.org; Sun, 12 Oct 2003 12:07:52 +0000 Received: (qmail 28552 invoked from network); 12 Oct 2003 12:05:55 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 12 Oct 2003 12:05:55 -0000 Message-ID: <3F89444A.6020106@necom830.hpcl.titech.ac.jp> Date: Sun, 12 Oct 2003 21:08:42 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: Routing table size? References: <3E6E7B14-FCA3-11D7-B291-00039388672E@muada.com> In-Reply-To: <3E6E7B14-FCA3-11D7-B291-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; > On zondag, okt 12, 2003, at 12:17 Europe/Amsterdam, masataka ohta wrote: > >> How, do you think, will the size of global routing table be? > > > When? For the lifetime of IPv6 or, at least, multi6. >> As I raised the question before Vienna, Brian said it should >> be proportional to logarithm of the network size. > Assuming we'll see significant v6 deployment, my guess is 15k - 60k by > 2010 (depending on the success of our efforts here), at which point the > v4 table will be around 200k. Such an unfounded statements is not an input for constructive discussion. Masataka Ohta From owner-multi6@ops.ietf.org Sun Oct 12 08:14:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16037 for ; Sun, 12 Oct 2003 08:14:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8f6r-000F9e-6d for multi6-data@psg.com; Sun, 12 Oct 2003 12:14:05 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8f6m-000F9G-R5 for multi6@ops.ietf.org; Sun, 12 Oct 2003 12:14:01 +0000 Received: (qmail 28580 invoked from network); 12 Oct 2003 12:12:04 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 12 Oct 2003 12:12:04 -0000 Message-ID: <3F8945BB.7090301@necom830.hpcl.titech.ac.jp> Date: Sun, 12 Oct 2003 21:14:51 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Ray Plzak CC: multi6@ops.ietf.org Subject: Re: Routing table size? References: <002401c390b2$12d82740$698888c0@arin.net> In-Reply-To: <002401c390b2$12d82740$698888c0@arin.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ray; >>Not if the RIRs don't change their policies. > > Policies in the RIR service regions are made by the operators and users > of the Internet as well as anyone else that is interested in IP > addressing, routing, and related issues, not by RIR staffs or their > Boards. If you feel that a particular allocation policy is not correct, > then I suggest that you participate in the RIR forum in the area where > you are located. Mail lists are open, there is no qualification to > join. Should we join mailing lists of all the RIRs and expect their policies become magically consistent? Or can we expect some central place (if ICANN is hopeless, RIPE is fine for me) for the discussion? Masataka Ohta From owner-multi6@ops.ietf.org Sun Oct 12 08:43:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16493 for ; Sun, 12 Oct 2003 08:43:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8fX0-000GGM-DE for multi6-data@psg.com; Sun, 12 Oct 2003 12:41:06 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8fWt-000GG4-0h for multi6@ops.ietf.org; Sun, 12 Oct 2003 12:40:59 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9CCeJed037804; Sun, 12 Oct 2003 14:40:19 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 12 Oct 2003 14:40:17 +0200 Subject: Re: Routing table size? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: masataka ohta From: Iljitsch van Beijnum In-Reply-To: <3F89444A.6020106@necom830.hpcl.titech.ac.jp> Message-Id: <3BEF97D8-FCB1-11D7-B291-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, okt 12, 2003, at 14:08 Europe/Amsterdam, masataka ohta wrote: >> When? > For the lifetime of IPv6 or, at least, multi6. So how long is that going to be? >> assuming we'll see significant v6 deployment, my guess is 15k - 60k >> by 2010 (depending on the success of our efforts here), at which >> point the v4 table will be around 200k. > Such an unfounded statements is not an input for constructive > discussion. We're all familiar with the underlying data, so why repeat it here? From owner-multi6@ops.ietf.org Sun Oct 12 08:48:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16561 for ; Sun, 12 Oct 2003 08:48:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8fdW-000Ga9-LE for multi6-data@psg.com; Sun, 12 Oct 2003 12:47:50 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8fdU-000GZq-0P for multi6@ops.ietf.org; Sun, 12 Oct 2003 12:47:48 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9CCkjed037886; Sun, 12 Oct 2003 14:46:45 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 12 Oct 2003 14:46:43 +0200 Subject: Re: RIR bashing, was: Routing table size? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Ray Plzak" From: Iljitsch van Beijnum In-Reply-To: <002401c390b2$12d82740$698888c0@arin.net> Message-Id: <2204C402-FCB2-11D7-B291-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_44 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, okt 12, 2003, at 13:14 Europe/Amsterdam, Ray Plzak wrote: >> I vote we fire the RIRs as soon as v4 is obsolete because they just >> don't get it. (And they're costing the community way too much >> money to boot.) > You should start by firing yourself, because if you are not actively > involved in the policy process then you have only yourself to blame for > the policies as they exist. Become involved. Hm, yes, firing myself would work out well as being involved in the entire I* family is a full time job in itself. Or maybe people can learn to take constructive criticism (which I agree not all of what I said was) to heart rather than play procedural games. Giving out /32s ONLY in IPv6 and /20s mostly in IPv4 isn't a good policy. Sometimes people need to be globally visible without the need for such a large block, and the largest ISPs burn through them fast enough to warrant giving them much larger blocks. From owner-multi6@ops.ietf.org Sun Oct 12 08:51:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16600 for ; Sun, 12 Oct 2003 08:51:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8fgL-000Gla-QL for multi6-data@psg.com; Sun, 12 Oct 2003 12:50:45 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8fgH-000GlI-BH for multi6@ops.ietf.org; Sun, 12 Oct 2003 12:50:41 +0000 Received: (qmail 28710 invoked from network); 12 Oct 2003 12:48:45 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 12 Oct 2003 12:48:45 -0000 Message-ID: <3F894E54.2000100@necom830.hpcl.titech.ac.jp> Date: Sun, 12 Oct 2003 21:51:32 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: Routing table size? References: <3BEF97D8-FCB1-11D7-B291-00039388672E@muada.com> In-Reply-To: <3BEF97D8-FCB1-11D7-B291-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; >>> When? >> For the lifetime of IPv6 or, at least, multi6. > So how long is that going to be? It will be long before, if ever, there are 2^128 hosts or 2^64 subnets. >>> assuming we'll see significant v6 deployment, my guess is 15k - 60k >>> by 2010 (depending on the success of our efforts here), at which >>> point the v4 table will be around 200k. >> Such an unfounded statements is not an input for constructive discussion. > We're all familiar with the underlying data, so why repeat it here? The only meaningful underlying data is that the global routing table size of IPv6 is *SMALL*. Masataka Ohta From owner-multi6@ops.ietf.org Sun Oct 12 09:00:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16725 for ; Sun, 12 Oct 2003 09:00:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8fok-000HHw-Sz for multi6-data@psg.com; Sun, 12 Oct 2003 12:59:26 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8foi-000HHe-JW for multi6@ops.ietf.org; Sun, 12 Oct 2003 12:59:24 +0000 Received: (qmail 28740 invoked from network); 12 Oct 2003 12:57:28 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 12 Oct 2003 12:57:28 -0000 Message-ID: <3F89505F.5030204@necom830.hpcl.titech.ac.jp> Date: Sun, 12 Oct 2003 22:00:15 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Ray Plzak , multi6@ops.ietf.org Subject: Re: RIR bashing, was: Routing table size? References: <2204C402-FCB2-11D7-B291-00039388672E@muada.com> In-Reply-To: <2204C402-FCB2-11D7-B291-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; > Giving out /32s ONLY in IPv6 and /20s mostly in IPv4 isn't a good > policy. Sometimes people need to be globally visible without the need > for such a large block, and the largest ISPs burn through them fast > enough to warrant giving them much larger blocks. Large? How large? The only real requirement is global visibility and, with IPv4 today, it is granted to an ISP with multiple external connectivities, which is not necessarily the case with multi6. Masataka Ohta From owner-multi6@ops.ietf.org Sun Oct 12 09:29:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17265 for ; Sun, 12 Oct 2003 09:29:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8gG2-000Idu-Vx for multi6-data@psg.com; Sun, 12 Oct 2003 13:27:38 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8gFx-000Ide-NY for multi6@ops.ietf.org; Sun, 12 Oct 2003 13:27:33 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9CDQred038332; Sun, 12 Oct 2003 15:26:54 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 12 Oct 2003 15:26:51 +0200 Subject: Re: RIR bashing, was: Routing table size? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: masataka ohta From: Iljitsch van Beijnum In-Reply-To: <3F89505F.5030204@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, okt 12, 2003, at 15:00 Europe/Amsterdam, masataka ohta wrote: >> Giving out /32s ONLY in IPv6 and /20s mostly in IPv4 isn't a good >> policy. Sometimes people need to be globally visible without the need >> for such a large block, and the largest ISPs burn through them fast >> enough to warrant giving them much larger blocks. > Large? How large? Double the size of each next block? Probably want to stop doing that at some point, though... > The only real requirement is global visibility and, with IPv4 today, > it is granted to an ISP with multiple external connectivities, which > is not necessarily the case with multi6. Actually it doesn't work like that in IPv4 either. You can get an AS number if you multihome, but for your own address block you need to show immediate use for a /22 (in the RIPE region). As for the IPv6 routing table: yes, of course it is small. IPv6 deployment is small. The Empire State Building was small too the first week of construction. It seems reasonable that everyone with an AS number will want to have an IPv6 address block at some point. That's nearly 30k at this moment. From owner-multi6@ops.ietf.org Sun Oct 12 09:52:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17561 for ; Sun, 12 Oct 2003 09:52:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8gcM-000Jga-H0 for multi6-data@psg.com; Sun, 12 Oct 2003 13:50:42 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8gcH-000Jg6-Pb for multi6@ops.ietf.org; Sun, 12 Oct 2003 13:50:38 +0000 Received: (qmail 28901 invoked from network); 12 Oct 2003 13:48:42 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 12 Oct 2003 13:48:42 -0000 Message-ID: <3F895C60.1030305@necom830.hpcl.titech.ac.jp> Date: Sun, 12 Oct 2003 22:51:28 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: RIR bashing, was: Routing table size? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; >>> Giving out /32s ONLY in IPv6 and /20s mostly in IPv4 isn't a good >>> policy. Sometimes people need to be globally visible without the need >>> for such a large block, and the largest ISPs burn through them fast >>> enough to warrant giving them much larger blocks. > > >> Large? How large? > > > Double the size of each next block? Probably want to stop doing that at > some point, though... Huh? Next block? Double? > Actually it doesn't work like that in IPv4 either. Though I can't understand you, you should fight in some RIR on IPv4 issues, first. > It seems reasonable that everyone with an AS number will want to have an > IPv6 address block at some point. That's nearly 30k at this moment. That's fine. Masataka Ohta From owner-multi6@ops.ietf.org Sun Oct 12 09:55:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17650 for ; Sun, 12 Oct 2003 09:55:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8ggB-000JyN-0c for multi6-data@psg.com; Sun, 12 Oct 2003 13:54:39 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8gg1-000Jxn-GY for multi6@ops.ietf.org; Sun, 12 Oct 2003 13:54:29 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 2C035609; Sun, 12 Oct 2003 09:54:29 -0400 (EDT) Received: from ops.arin.net (ops [192.149.252.141]) by smtp2.arin.net (Postfix) with ESMTP id B04102B7 for ; Sun, 12 Oct 2003 09:54:28 -0400 (EDT) Received: from ano2 ([192.136.136.85]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA16163 for ; Sun, 12 Oct 2003 09:54:26 -0400 (EDT) From: "Ray Plzak" To: Subject: RE: Routing table size? Date: Sun, 12 Oct 2003 09:54:21 -0400 Message-ID: <000601c390c8$59f3e180$558888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3F8945BB.7090301@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There is a global ipv6 policy dicussion list hosted by APNIC. http://www.apnic.net/community/lists/index.html Ray > -----Original Message----- > From: masataka ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Sunday, October 12, 2003 8:15 AM > To: Ray Plzak > Cc: multi6@ops.ietf.org > Subject: Re: Routing table size? > > > Ray; > > >>Not if the RIRs don't change their policies. > > > > Policies in the RIR service regions are made by the > operators and users > > of the Internet as well as anyone else that is interested in IP > > addressing, routing, and related issues, not by RIR staffs or their > > Boards. If you feel that a particular allocation policy is > not correct, > > then I suggest that you participate in the RIR forum in the > area where > > you are located. Mail lists are open, there is no qualification to > > join. > > Should we join mailing lists of all the RIRs and expect their > policies become magically consistent? > > Or can we expect some central place (if ICANN is hopeless, RIPE is > fine for me) for the discussion? > > Masataka Ohta > From owner-multi6@ops.ietf.org Sun Oct 12 09:56:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17677 for ; Sun, 12 Oct 2003 09:56:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8ght-000K7M-C7 for multi6-data@psg.com; Sun, 12 Oct 2003 13:56:25 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8ghc-000K5m-40 for multi6@ops.ietf.org; Sun, 12 Oct 2003 13:56:08 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 2FB3B830F; Sun, 12 Oct 2003 15:56:01 +0200 (CEST) From: "Jeroen Massar" To: "'masataka ohta'" Cc: Subject: RE: Routing table size? Date: Sun, 12 Oct 2003 15:54:25 +0200 Organization: Unfix Message-ID: <001801c390c8$5a266330$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3F894E54.2000100@necom830.hpcl.titech.ac.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- masataka ohta wrote: > > We're all familiar with the underlying data, so why repeat it here? > > The only meaningful underlying data is that the global routing table > size of IPv6 is *SMALL*. Currently 400 real TLA's and some ISP's have a max of 500 prefixes. So that is indeed small. There is to wonder though why some ISP's don't aggregate their own routes, especially when they have the same ASPaths. I do get why people announce more specifics though because of 'multihoming'. I have my own thought about that though. Btw as can be read on the following URL Marc Binderberger made a "policy based routing' patch for FreeBSD 4.8: http://www.sixxs.net/forum/?msg=setup-52946 Allowing multiple upstream prefixes but correct routing of packets. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP4ldECmqKFIzPnwjEQKLLgCgr8TIV4ur7sUPohJSsMu5e83vYSYAn39/ z8X72PaEVL5IbHJDZKEmeB6R =CGtR -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Oct 12 09:57:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17693 for ; Sun, 12 Oct 2003 09:57:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8giG-000KAJ-Ve for multi6-data@psg.com; Sun, 12 Oct 2003 13:56:48 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8giE-000K9j-22 for multi6@ops.ietf.org; Sun, 12 Oct 2003 13:56:46 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id A3A6F73A; Sun, 12 Oct 2003 09:56:45 -0400 (EDT) Received: from ops.arin.net (ops [192.149.252.141]) by smtp2.arin.net (Postfix) with ESMTP id 3FA11301; Sun, 12 Oct 2003 09:56:45 -0400 (EDT) Received: from ano2 ([192.136.136.85]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA16228; Sun, 12 Oct 2003 09:56:42 -0400 (EDT) From: "Ray Plzak" To: "'Iljitsch van Beijnum'" Cc: Subject: RE: RIR bashing, was: Routing table size? Date: Sun, 12 Oct 2003 09:56:37 -0400 Message-ID: <000701c390c8$ab63cfd0$558888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <2204C402-FCB2-11D7-B291-00039388672E@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-multi6@ops.ietf.org > [mailto:owner-multi6@ops.ietf.org] On Behalf Of Iljitsch van Beijnum > Sent: Sunday, October 12, 2003 8:47 AM > To: Ray Plzak > Cc: multi6@ops.ietf.org > Subject: Re: RIR bashing, was: Routing table size? > > Giving out /32s ONLY in IPv6 and /20s mostly in IPv4 isn't a good > policy. Sometimes people need to be globally visible without the need > for such a large block, and the largest ISPs burn through them fast > enough to warrant giving them much larger blocks. I suggest that you subscribe to the global IPv6 policy list http://www.apnic.net/community/lists/index.html and post this thought there. Ray From owner-multi6@ops.ietf.org Sun Oct 12 10:04:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17964 for ; Sun, 12 Oct 2003 10:04:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8gp2-000Kox-FD for multi6-data@psg.com; Sun, 12 Oct 2003 14:03:48 +0000 Received: from [68.78.82.25] (helo=monet.titania.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8gon-000KoJ-3q for multi6@ops.ietf.org; Sun, 12 Oct 2003 14:03:33 +0000 Received: from titania.net (morisot.titania.net [192.133.102.10]) by monet.titania.net (8.12.9p2/8.12.9) with ESMTP id h9CE3INu034518 for ; Sun, 12 Oct 2003 14:03:18 GMT (envelope-from jtk@titania.net) Date: Sun, 12 Oct 2003 09:02:55 -0500 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: regionalized addresses, RIRs, and table size From: "Joseph T. Klein" To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_44 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit IMHO - The concept of geographic based, or regionalized addresses recently mentioned seems to merit some review in light of recent other discussions. Possible positive impacts of geographic based IPv6 addresses are: * Ability to have smaller allocations within a region without bloating the global rout table. * It compliments regional peering. * It tends to aggregate globally. Negative * Impact of networks without extra regional topologies In gross terms the RIRs provide Continental regionalization. The inefficencies of shifting the aggregation level down to a metro region size may be offset by the gains in allowing small allocation for local multi-homed sites, the need to bloat ones allocation requirement to get a globally routable block being irrelevant under this scheme. All the tricks required to do multihoming under the current address architecture seem to inject new complexities into routing and possibly the interface at the application layer. Point: All the multi-homed proposals seem a lot more of a problem than geographic based address allocation. Why not apply the analog of Occam's Razor to this problem. If geographic allocations provide the simple solution, why not reevaluate? -- Joseph T. Klein "Perfect is the enemy of good enough." -- Admiral S.G. Gorshkov PSTN: +1 414 961 1690 VoIP: +1 414 431 4231 Mobile: +1 414 628 3380 From owner-multi6@ops.ietf.org Sun Oct 12 10:12:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18703 for ; Sun, 12 Oct 2003 10:12:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8gx7-000LHy-Nq for multi6-data@psg.com; Sun, 12 Oct 2003 14:12:09 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8gx3-000LHS-0b for multi6@ops.ietf.org; Sun, 12 Oct 2003 14:12:05 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 22C8C830F; Sun, 12 Oct 2003 16:12:00 +0200 (CEST) From: "Jeroen Massar" To: "'Iljitsch van Beijnum'" Cc: Subject: RE: RIR bashing, was: Routing table size? Date: Sun, 12 Oct 2003 16:10:20 +0200 Organization: Unfix Message-ID: <002b01c390ca$92922270$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <2204C402-FCB2-11D7-B291-00039388672E@muada.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Iljitsch van Beijnum wrote: > Giving out /32s ONLY in IPv6 and /20s mostly in IPv4 isn't a good > policy. Sometimes people need to be globally visible without the need > for such a large block, and the largest ISPs burn through them fast > enough to warrant giving them much larger blocks. http://www.sixxs.net/tools/grh/tla/all/ shows amongst others: 2001:d70::/30 NTTWEST-IPv6-JPNIC-JP-20030912 2001:1600::/31 NL-LIBERTEL-20030902 So getting them is certainly possible. If you want to be 'visible' with a smaller block you are an enduser and at the moment you are out of luck. But then again I don't know any enduser type people having the connectivity nor the need for their own routing. That's why I pay my upstreams so they can handle all that stuff for me and I can sleep fine :) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP4lgyimqKFIzPnwjEQKONQCgqG8DFRAHuWt3S4Wa1lDOqYAbVB0Anjew Ldzi33KIq0IK7m56CAUJQd11 =09M8 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Oct 12 10:24:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19359 for ; Sun, 12 Oct 2003 10:24:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8h8N-000M30-Kb for multi6-data@psg.com; Sun, 12 Oct 2003 14:23:47 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8h8G-000M2L-6o for multi6@ops.ietf.org; Sun, 12 Oct 2003 14:23:40 +0000 Received: (qmail 29024 invoked from network); 12 Oct 2003 14:21:44 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 12 Oct 2003 14:21:44 -0000 Message-ID: <3F89641E.4050806@necom830.hpcl.titech.ac.jp> Date: Sun, 12 Oct 2003 23:24:30 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: "Joseph T. Klein" CC: multi6@ops.ietf.org Subject: Re: regionalized addresses, RIRs, and table size References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joseph; > All the tricks required to do multihoming under the current > address architecture seem to inject new complexities into > routing and possibly the interface at the application layer. That's why I proposed multihoming end to end. > In gross terms the RIRs provide Continental regionalization. The regionalization is an unnecessary complexity in routing. Masataka Ohta From owner-multi6@ops.ietf.org Sun Oct 12 10:31:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19661 for ; Sun, 12 Oct 2003 10:31:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8hEL-000MUU-Gb for multi6-data@psg.com; Sun, 12 Oct 2003 14:29:57 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8hEE-000MTu-BS for multi6@ops.ietf.org; Sun, 12 Oct 2003 14:29:50 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9CESmed039036; Sun, 12 Oct 2003 16:28:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 12 Oct 2003 16:28:46 +0200 Subject: Re: RIR bashing, was: Routing table size? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Jeroen Massar" From: Iljitsch van Beijnum In-Reply-To: <002b01c390ca$92922270$210d640a@unfix.org> Message-Id: <63BC18C1-FCC0-11D7-B291-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, okt 12, 2003, at 16:10 Europe/Amsterdam, Jeroen Massar wrote: > -----BEGIN PGP SIGNED MESSAGE----- Signature still doesn't work... > http://www.sixxs.net/tools/grh/tla/all/ shows amongst others: > 2001:d70::/30 NTTWEST-IPv6-JPNIC-JP-20030912 > 2001:1600::/31 NL-LIBERTEL-20030902 > So getting them is certainly possible. Ok, that's good. In IPv4 people received /16s in the past but these days I see huge numbers of consecutive /20s in the global routing table. In this case the RIRs did at least _something_ right but unfortunately it got lost in the translation somewhere. This may be because the RIRs give out consecutive /20s one at a time rather than a /16 at once, but the network in question doesn't want to install new aggregates remove existing more specifics because (as everyone who has been in IPv6 operations the past years knows) this leads to a fairly long period (minutes) of instability. > If you want to be 'visible' with a smaller block you are an > enduser Or a root nameserver... > and at the moment you are out of luck. But then again > I don't know any enduser type people having the connectivity > nor the need for their own routing. That's why I pay my upstreams > so they can handle all that stuff for me and I can sleep fine :) Ok then we can terminate this working group. Actually you do know such an enduser: me. I have two lines coming into my home and I run IPv6 over both of them. In fact the server that is colocated with one ISP is reachable (over IPv6) through the other ISP, my home network and the link to the colo ISP. (Do some traces for www.bgpexpert.com.) From owner-multi6@ops.ietf.org Sun Oct 12 11:06:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20264 for ; Sun, 12 Oct 2003 11:06:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8hlT-000OY6-Fa for multi6-data@psg.com; Sun, 12 Oct 2003 15:04:11 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8hlL-000OXc-L3 for multi6@ops.ietf.org; Sun, 12 Oct 2003 15:04:03 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id E3CB9830F; Sun, 12 Oct 2003 17:03:59 +0200 (CEST) From: "Jeroen Massar" To: "'Iljitsch van Beijnum'" Cc: Subject: RE: RIR bashing, was: Routing table size? Date: Sun, 12 Oct 2003 17:02:18 +0200 Organization: Unfix Message-ID: <005401c390d1$d4eea4c0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <63BC18C1-FCC0-11D7-B291-00039388672E@muada.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Iljitsch van Beijnum [mailto:iljitsch@muada.com] wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Signature still doesn't work... [OT] They fixed it in gpg, so apparently it wasn't my prob afterall :) But gpg also has problems with multiple subkeys which have been fixed in the latest tree too... > > If you want to be 'visible' with a smaller block you are an > > enduser > > Or a root nameserver... Which get /32's too but for an obvious reason. But that is critical infra and I don't think (m)any people will argue against rootservers being crititical. TLD servers though can do with upstream IP's > > and at the moment you are out of luck. But then again > > I don't know any enduser type people having the connectivity > > nor the need for their own routing. That's why I pay my upstreams > > so they can handle all that stuff for me and I can sleep fine :) > > Ok then we can terminate this working group. > > Actually you do know such an enduser: me. I have two lines > coming into my home and I run IPv6 over both of them. > In fact the server that is colocated with one ISP is reachable > (over IPv6) through the other ISP, my home network and the > link to the colo ISP. (Do some traces for www.bgpexpert.com.) traceroute6 2001:888:1DDE:2:0:0:0:1 7 ipv6tb.xs4all.nl (2001:888:0:3::4242) 11.033 ms 10.373 ms 10.962 ms 8 tunnel3550.ipv6.xs4all.nl (2001:888:10:dde::2) 35.457 ms 43.098 ms 35.897 ms 9 3ffe:2500:310:1:200:cff:fe3e:6052 (3ffe:2500:310:1:200:cff:fe3e:6052) 36.448 ms 35.899 ms * 10 sequoia.muada.com (2001:888:1dde:2::1) 57.616 ms 50.246 ms 56.188 ms I wonder where hop 9's packets came from and how the flow to me. 3 ams-ix.sara.xs4all.net (2001:7f8:1::a500:3265:1) 5.099 ms 4.124 ms 4.654 ms 4 e0.6b2.ams7.alter.net (2001:7f8:1::a501:2702:1) 6.661 ms * 4.357 ms 5 sequoia.muada.com (2001:888:1dde:2::1) 50.087 ms 48.297 ms 39.151 ms 6 3ffe:2500:310:1:200:cff:fe3e:6052 (3ffe:2500:310:1:200:cff:fe3e:6052) 39.342 ms * 42.977 ms But indeed this is a case of multiple independent links even though they are going over the same physical IPv4 path and are being tunneled. I personally see the situation where I would get two independent ISP's, eg a cable and ADSL provider. They don't have to know anything about eachother. The only thing they do is that they each route a prefix from and to me as delegated out of their TLA. My boxes thus would get 2 prefixes. For routing packets they will pick either prefix and send out packets. Now if one link goes down TCP connections terminate. If there would be a server type application on the box it would then not be reachable. Conclusion we need a way of notifying with some trust/authentication that the IP of a certain host changed. IMHO the best solution would be a id/loc seperation thus only using the ISP's prefixes in transit, the hosts would use the ID prefixes and never know anything about the routing prefixes. But that probably all has been told and documented a lot of times already... if someone has space for an intern to dive into this I volunteer myself to take that place and implement such a scheme... Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP4ls+imqKFIzPnwjEQJKbgCfQIzIcYf98Alq67lP8KhWVYBWG1EAoKCI +Wju+fhgVCnWPQiLluUJ3xED =mzBp -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Oct 12 11:22:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20715 for ; Sun, 12 Oct 2003 11:22:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8i1t-000Pgq-Nw for multi6-data@psg.com; Sun, 12 Oct 2003 15:21:09 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8i1o-000PgY-Lm for multi6@ops.ietf.org; Sun, 12 Oct 2003 15:21:04 +0000 Received: (qmail 29209 invoked from network); 12 Oct 2003 15:19:10 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 12 Oct 2003 15:19:10 -0000 Message-ID: <3F897194.80402@necom830.hpcl.titech.ac.jp> Date: Mon, 13 Oct 2003 00:21:56 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Ray Plzak CC: multi6@ops.ietf.org Subject: Re: Routing table size? References: <000601c390c8$59f3e180$558888c0@arin.net> In-Reply-To: <000601c390c8$59f3e180$558888c0@arin.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ray; > There is a global ipv6 policy dicussion list hosted by APNIC. > > http://www.apnic.net/community/lists/index.html Thanks for the pointer. But, having read recent posts to the ML, I have got an impression that the mailing list is for discussion on the current IPv6 specification as is, thus ignoring the problem of routing table size. Or, is the mailing list an appropriate place to discuss how to modify IPv6 or, at least, ask opinions on possible modifications on IPv6? Masataka Ohta > > Ray > > >>-----Original Message----- >>From: masataka ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] >>Sent: Sunday, October 12, 2003 8:15 AM >>To: Ray Plzak >>Cc: multi6@ops.ietf.org >>Subject: Re: Routing table size? >> >> >>Ray; >> >> >>>>Not if the RIRs don't change their policies. >>> >>>Policies in the RIR service regions are made by the >> >>operators and users >> >>>of the Internet as well as anyone else that is interested in IP >>>addressing, routing, and related issues, not by RIR staffs or their >>>Boards. If you feel that a particular allocation policy is >> >>not correct, >> >>>then I suggest that you participate in the RIR forum in the >> >>area where >> >>>you are located. Mail lists are open, there is no qualification to >>>join. >> >>Should we join mailing lists of all the RIRs and expect their >>policies become magically consistent? >> >>Or can we expect some central place (if ICANN is hopeless, RIPE is >>fine for me) for the discussion? >> >> Masataka Ohta >> > > > > > From owner-multi6@ops.ietf.org Sun Oct 12 11:24:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20762 for ; Sun, 12 Oct 2003 11:24:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8i43-000Pnx-8U for multi6-data@psg.com; Sun, 12 Oct 2003 15:23:23 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8i3r-000Pms-Gi for multi6@ops.ietf.org; Sun, 12 Oct 2003 15:23:11 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 279CA874; Sun, 12 Oct 2003 11:23:11 -0400 (EDT) Received: from ops.arin.net (ops [192.149.252.141]) by smtp2.arin.net (Postfix) with ESMTP id 9A8F484D for ; Sun, 12 Oct 2003 11:23:10 -0400 (EDT) Received: from ano2 ([192.136.136.30]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA23020 for ; Sun, 12 Oct 2003 11:23:08 -0400 (EDT) From: "Ray Plzak" To: Subject: RE: regionalized addresses, RIRs, and table size Date: Sun, 12 Oct 2003 11:23:08 -0400 Message-ID: <000401c390d4$be7dae40$1e8888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This has been discussed in regard to the minimum allocation from the IANA to the RIRs in all the regions. There has been no conclusion reached in regards to a policy, which by the way would be a global policy and would have to pass through the ASO Address Council and the ICANN Board. Ray > -----Original Message----- > From: owner-multi6@ops.ietf.org > [mailto:owner-multi6@ops.ietf.org] On Behalf Of Joseph T. Klein > Sent: Sunday, October 12, 2003 10:03 AM > To: multi6@ops.ietf.org > Subject: regionalized addresses, RIRs, and table size > > > IMHO - The concept of geographic based, or regionalized addresses > recently mentioned seems to merit some review in light of recent > other discussions. > > Possible positive impacts of geographic based IPv6 addresses are: > > * Ability to have smaller allocations within a region without > bloating the global rout table. > > * It compliments regional peering. > > * It tends to aggregate globally. > > Negative > > * Impact of networks without extra regional topologies > > In gross terms the RIRs provide Continental regionalization. > The inefficencies of shifting the aggregation level down to a > metro region size may be offset by the gains in allowing small > allocation for local multi-homed sites, the need to bloat > ones allocation requirement to get a globally routable block > being irrelevant under this scheme. > > All the tricks required to do multihoming under the current > address architecture seem to inject new complexities into > routing and possibly the interface at the application layer. > > Point: > > All the multi-homed proposals seem a lot more of a problem > than geographic based address allocation. Why not apply > the analog of Occam's Razor to this problem. If geographic > allocations provide the simple solution, why not reevaluate? > -- > Joseph T. Klein > "Perfect is the enemy of good enough." > -- Admiral S.G. Gorshkov > PSTN: +1 414 961 1690 VoIP: +1 414 431 4231 Mobile: +1 414 628 3380 > From owner-multi6@ops.ietf.org Sun Oct 12 11:27:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20837 for ; Sun, 12 Oct 2003 11:27:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8i7Q-00008J-Vu for multi6-data@psg.com; Sun, 12 Oct 2003 15:26:52 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8i7O-00007i-Gp for multi6@ops.ietf.org; Sun, 12 Oct 2003 15:26:50 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id CBD3B874; Sun, 12 Oct 2003 11:26:48 -0400 (EDT) Received: from ops.arin.net (ops [192.149.252.141]) by smtp2.arin.net (Postfix) with ESMTP id 4B255873 for ; Sun, 12 Oct 2003 11:26:48 -0400 (EDT) Received: from ano2 ([192.136.136.30]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA23146 for ; Sun, 12 Oct 2003 11:26:46 -0400 (EDT) From: "Ray Plzak" To: Subject: RE: Routing table size? Date: Sun, 12 Oct 2003 11:26:46 -0400 Message-ID: <000501c390d5$40674790$1e8888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F897194.80402@necom830.hpcl.titech.ac.jp> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ohta-san, This list is the appropriate place to ask questions about current policy as well as suggest changes to existing policy or even propose new policy. Ray > -----Original Message----- > From: masataka ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Sunday, October 12, 2003 11:22 AM > To: Ray Plzak > Cc: multi6@ops.ietf.org > Subject: Re: Routing table size? > > > Ray; > > > There is a global ipv6 policy dicussion list hosted by APNIC. > > > > http://www.apnic.net/community/lists/index.html > > Thanks for the pointer. > > But, having read recent posts to the ML, I have got an impression > that the mailing list is for discussion on the current IPv6 > specification as is, thus ignoring the problem of routing table > size. > > Or, is the mailing list an appropriate place to discuss how to > modify IPv6 or, at least, ask opinions on possible modifications > on IPv6? > > Masataka Ohta > > > > Ray > > > > > >>-----Original Message----- > >>From: masataka ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > >>Sent: Sunday, October 12, 2003 8:15 AM > >>To: Ray Plzak > >>Cc: multi6@ops.ietf.org > >>Subject: Re: Routing table size? > >> > >> > >>Ray; > >> > >> > >>>>Not if the RIRs don't change their policies. > >>> > >>>Policies in the RIR service regions are made by the > >> > >>operators and users > >> > >>>of the Internet as well as anyone else that is interested in IP > >>>addressing, routing, and related issues, not by RIR staffs or their > >>>Boards. If you feel that a particular allocation policy is > >> > >>not correct, > >> > >>>then I suggest that you participate in the RIR forum in the > >> > >>area where > >> > >>>you are located. Mail lists are open, there is no qualification to > >>>join. > >> > >>Should we join mailing lists of all the RIRs and expect their > >>policies become magically consistent? > >> > >>Or can we expect some central place (if ICANN is hopeless, RIPE is > >>fine for me) for the discussion? > >> > >> Masataka Ohta > >> > > > > > > > > > > > From owner-multi6@ops.ietf.org Sun Oct 12 11:36:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21020 for ; Sun, 12 Oct 2003 11:36:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8iEf-0000js-Ng for multi6-data@psg.com; Sun, 12 Oct 2003 15:34:21 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8iEb-0000jc-9S for multi6@ops.ietf.org; Sun, 12 Oct 2003 15:34:17 +0000 Received: (qmail 29260 invoked from network); 12 Oct 2003 15:32:23 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 12 Oct 2003 15:32:23 -0000 Message-ID: <3F8974AC.6070001@necom830.hpcl.titech.ac.jp> Date: Mon, 13 Oct 2003 00:35:08 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Jeroen Massar CC: "'Iljitsch van Beijnum'" , multi6@ops.ietf.org Subject: Re: RIR bashing, was: Routing table size? References: <005401c390d1$d4eea4c0$210d640a@unfix.org> In-Reply-To: <005401c390d1$d4eea4c0$210d640a@unfix.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jeroen; > I personally see the situation where I would get two > independent ISP's, eg a cable and ADSL provider. They don't > have to know anything about eachother. The only thing they do > is that they each route a prefix from and to me as delegated out > of their TLA. My boxes thus would get 2 prefixes. And, you want to have 2 exit routers, if you want to avoid a single point of failure. Then, you want to have full route in your site to choose the best exit router for each destination. Or, you may develop a complex protocol on hosts and exit routers that a host first query exit routers (multiple ones, of course) to choose a source address and routers between the host and the exit routers perform source address based routing (or, the host may use tunneling to the exit routers), even in which case, the exit routers must have a global routing table. This is why the global routing table should be reasonably small. Masataka Ohta From owner-multi6@ops.ietf.org Sun Oct 12 11:40:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21098 for ; Sun, 12 Oct 2003 11:40:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8iJo-00013X-3w for multi6-data@psg.com; Sun, 12 Oct 2003 15:39:40 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8iJl-00013D-Vi for multi6@ops.ietf.org; Sun, 12 Oct 2003 15:39:38 +0000 Received: (qmail 29288 invoked from network); 12 Oct 2003 15:37:44 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 12 Oct 2003 15:37:44 -0000 Message-ID: <3F8975ED.8010002@necom830.hpcl.titech.ac.jp> Date: Mon, 13 Oct 2003 00:40:29 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Ray Plzak CC: multi6@ops.ietf.org Subject: Re: Routing table size? References: <000501c390d5$40674790$1e8888c0@arin.net> In-Reply-To: <000501c390d5$40674790$1e8888c0@arin.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ray; > This list is the appropriate place to ask questions about current policy > as well as suggest changes to existing policy or even propose new > policy. Propose new policy based on which specification? Can the specification not necessarily the current IPv6 as is? Masataka Ohta From owner-multi6@ops.ietf.org Sun Oct 12 16:26:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27811 for ; Sun, 12 Oct 2003 16:26:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8mk2-000Gf7-VC for multi6-data@psg.com; Sun, 12 Oct 2003 20:23:02 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8mjv-000Gee-IE for multi6@ops.ietf.org; Sun, 12 Oct 2003 20:22:55 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9CKMGed042822; Sun, 12 Oct 2003 22:22:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 12 Oct 2003 22:22:14 +0200 Subject: Re: regionalized addresses, RIRs, and table size Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Ray Plzak" From: Iljitsch van Beijnum In-Reply-To: <000401c390d4$be7dae40$1e8888c0@arin.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, okt 12, 2003, at 17:23 Europe/Amsterdam, Ray Plzak wrote: [geographic addressing] > This has been discussed in regard to the minimum allocation from the > IANA to the RIRs in all the regions. There has been no conclusion > reached in regards to a policy, which by the way would be a global > policy and would have to pass through the ASO Address Council and the > ICANN Board. I'm unaware of what has been discussed in that forum, but geographic addressing only makes sense if it enables geographic aggregation, which isn't an entirely trivial excercise. Geographic addressing has been discussed extensively on a non-IETF mailinglist about multihoming in IPv6 and our conclusion was that a /16 for geographic addressing where the allocation of addresses is based on population would work well. The minimum "allocation" would be a /32 for a region with around 350.000 inhabitants, but since such a region isn't an addressable entity in network terms these blocks wouldn't be allocated in the current sense; this type of address space would have to be held by the RIRs and be directly assigned to end-users based on their location. (Obviously the "paper work" could still be done by an intermediary such as an ISP so the RIR part could be fully automated.) A /24 (presumably out of 6bone space) could be used in a field experiment, but /48s would run out fairly quick in network-intensive areas such as Silicon Valley with not much more than one /48 per 2500 inhabitants while the current usage of AS numbers is around one in 30000 for Europe and the US. More than a /16 would be unworkable as presumably flat routing would be needed in cities and even with a /16 that means flat routing for millions of /48s in the largest metropolitan areas. From owner-multi6@ops.ietf.org Sun Oct 12 17:06:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29405 for ; Sun, 12 Oct 2003 17:06:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8nOR-000K2o-DE for multi6-data@psg.com; Sun, 12 Oct 2003 21:04:47 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8nOL-000K25-8J for multi6@ops.ietf.org; Sun, 12 Oct 2003 21:04:41 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9CL43ed043280; Sun, 12 Oct 2003 23:04:04 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 12 Oct 2003 23:04:00 +0200 Subject: Re: RIR bashing, was: Routing table size? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Jeroen Massar" From: Iljitsch van Beijnum In-Reply-To: <005401c390d1$d4eea4c0$210d640a@unfix.org> Message-Id: <9A45099C-FCF7-11D7-B291-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, okt 12, 2003, at 17:02 Europe/Amsterdam, Jeroen Massar wrote: >>> If you want to be 'visible' with a smaller block you are an >>> enduser >> Or a root nameserver... > Which get /32's too but for an obvious reason. Not so obvious... They need one address. What are the other 79228162514264337593543950335 for? It's a shame really that people as a rule still don't get it. In the old days, the root servers had an address, and we used the named.root file (wasn't it called something else back then or am I confused with named.boot?) to find them. But we're doing so many routing tricks with these addresses now that it makes much more sense to group all the address blocks for all the roots together in a special range. Bonus: we get to hardcode the root addresses now too, as we're now no longer modifying the root addresses when something changes, but keep the addresses and change the routing. >> (Do some traces for www.bgpexpert.com.) > traceroute6 2001:888:1DDE:2:0:0:0:1 > 7 ipv6tb.xs4all.nl (2001:888:0:3::4242) 11.033 ms 10.373 ms > 10.962 ms > 8 tunnel3550.ipv6.xs4all.nl (2001:888:10:dde::2) 35.457 ms 43.098 > ms 35.897 ms > 9 3ffe:2500:310:1:200:cff:fe3e:6052 > (3ffe:2500:310:1:200:cff:fe3e:6052) 36.448 ms 35.899 ms * > 10 sequoia.muada.com (2001:888:1dde:2::1) 57.616 ms 50.246 ms > 56.188 ms > I wonder where hop 9's packets came from and how the flow to me. gw#trace Protocol [ip]: ipv6 Target IPv6 address: 3ffe:8114:2000:240:290:27ff:fe24:c19f 1 2001:888:1DDE:1:204:27FF:FEFE:249F 4 msec 4 msec 4 msec 2 2001:888:0:3::4242 36 msec 36 msec 48 msec [...] And: gw#trace Protocol [ip]: Target IP address: www.unfix.org 1 loopback.rhadamanthus.pine.nl (213.156.3.144) 12 msec 12 msec 8 msec 2 fa0-0.rtr0002.asmr.pine.nl (213.156.0.29) 12 msec 12 msec 12 msec 3 fa3-0-4-asd8ro2.enertel.nl (195.7.144.85) 16 msec 16 msec 16 msec 4 fa0-0-0-asd8ro1.enertel.nl (195.7.144.149) 12 msec 12 msec 20 msec 5 po11-1-0-asd7ro1.enertel.nl (195.7.144.2) 16 msec 12 msec 16 msec 6 ams-ix.intouch.net (195.69.144.93) 16 msec 12 msec 20 msec 7 217.8.101.250 16 msec 12 msec 16 msec But this is a bit confusing as this router connects to ISP#1, which is also where its IPv4 default points to but its IPv6 default points to the router that connects to ISP#2, which has both its v4 and v6 defaults point to ISP#2 (I also have box that has a full v6 table but never mind (and I gave this router a 6bone address that belongs to the tunnel over ISP#1 to see if RIPng works if two routers don't share a subnet)): hpromatem#trace Protocol [ip]: Target IP address: www.unfix.org 1 195.190.241.114 188 msec 96 msec 116 msec 2 32.ge-0-0-0.xr2.pbw.xs4all.net (194.109.5.201) 20 msec 160 msec 28 msec 3 0.ge-1-3-0.xr1.tc2.xs4all.net (194.109.5.6) 36 msec 12 msec 120 msec 4 telecity.ams-ix.intouch.net (195.69.144.175) 300 msec 276 msec 236 msec 5 217.8.101.250 244 msec 116 msec 156 msec > But indeed this is a case of multiple independent links > even though they are going over the same physical IPv4 path Nope. One is over a "dark copper" pair with "vooroorlogse" 144 kbps baseband modems, the other over ADSL. > and are being tunneled. Yup, in both cases the router terminating the line at the other side doesn't grok v6. > I personally see the situation where I would get two > independent ISP's, eg a cable and ADSL provider. They don't > have to know anything about eachother. The only thing they do > is that they each route a prefix from and to me as delegated out > of their TLA. My boxes thus would get 2 prefixes. That's my current setup for my box in the colo room at ISP#1. It has a tunnel over the regular ISP#1 v4 connectivity (which is of course multihomed in its own right) and one to my house and then to ISP#2 over ADSL. > For routing > packets they will pick either prefix and send out packets. > Now if one link goes down TCP connections terminate. If there > would be a server type application on the box it would then > not be reachable. Actually for incoming traffic this wouldn't be a huge problem as clients retry until they hit a working address (this actually works fairly well today). The trouble is the source address selection, and in the case of tunnels, seeing which one works and which one doesn't. And even when all of this works it still breaks existing connections. > Conclusion we need a way of notifying with > some trust/authentication that the IP of a certain host changed. Actually that's not the hard part. Finding out the new address (assuming the internet protocol remains the same...) in such a way that an attacker can't get in the middle is harder. > IMHO the best solution would be a id/loc seperation thus only > using the ISP's prefixes in transit, the hosts would use the > ID prefixes and never know anything about the routing prefixes. Hm, yes, not so simple... From owner-multi6@ops.ietf.org Sun Oct 12 17:42:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00392 for ; Sun, 12 Oct 2003 17:42:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8nvI-000Msu-MM for multi6-data@psg.com; Sun, 12 Oct 2003 21:38:44 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8nv9-000Ms4-Kj for multi6@ops.ietf.org; Sun, 12 Oct 2003 21:38:35 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id E323893D; Sun, 12 Oct 2003 17:38:34 -0400 (EDT) Received: from ops.arin.net (ops [192.149.252.141]) by smtp2.arin.net (Postfix) with ESMTP id 3C7C194A for ; Sun, 12 Oct 2003 17:38:34 -0400 (EDT) Received: from ano2 ([192.136.136.39]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA21485 for ; Sun, 12 Oct 2003 17:38:31 -0400 (EDT) From: "Ray Plzak" To: Subject: RE: regionalized addresses, RIRs, and table size Date: Sun, 12 Oct 2003 17:38:26 -0400 Message-ID: <002a01c39109$2f4833a0$278888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The idea of geographic addressing based on population was briefly discussed in the RIPE region. The primary discussion has been between two proposals - the IANA allocates a /3 to the RIRs to jointly administer on a global basis versus the IANA allocates sufficiently large prefixes to each RIR for regional allocation. Ray > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Sunday, October 12, 2003 4:22 PM > To: Ray Plzak > Cc: multi6@ops.ietf.org > Subject: Re: regionalized addresses, RIRs, and table size > > > On zondag, okt 12, 2003, at 17:23 Europe/Amsterdam, Ray Plzak wrote: > > [geographic addressing] > > > This has been discussed in regard to the minimum allocation from the > > IANA to the RIRs in all the regions. There has been no conclusion > > reached in regards to a policy, which by the way would be a global > > policy and would have to pass through the ASO Address > Council and the > > ICANN Board. > > I'm unaware of what has been discussed in that forum, but geographic > addressing only makes sense if it enables geographic > aggregation, which > isn't an entirely trivial excercise. > > Geographic addressing has been discussed extensively on a non-IETF > mailinglist about multihoming in IPv6 and our conclusion was > that a /16 > for geographic addressing where the allocation of addresses > is based on > population would work well. The minimum "allocation" would be > a /32 for > a region with around 350.000 inhabitants, but since such a > region isn't > an addressable entity in network terms these blocks wouldn't be > allocated in the current sense; this type of address space would have > to be held by the RIRs and be directly assigned to end-users based on > their location. (Obviously the "paper work" could still be done by an > intermediary such as an ISP so the RIR part could be fully automated.) > > A /24 (presumably out of 6bone space) could be used in a field > experiment, but /48s would run out fairly quick in network-intensive > areas such as Silicon Valley with not much more than one /48 per 2500 > inhabitants while the current usage of AS numbers is around one in > 30000 for Europe and the US. > > More than a /16 would be unworkable as presumably flat > routing would be > needed in cities and even with a /16 that means flat routing for > millions of /48s in the largest metropolitan areas. > From owner-multi6@ops.ietf.org Sun Oct 12 18:37:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02504 for ; Sun, 12 Oct 2003 18:37:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8ooL-0001dp-C9 for multi6-data@psg.com; Sun, 12 Oct 2003 22:35:37 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8ooE-0001dD-9w for multi6@ops.ietf.org; Sun, 12 Oct 2003 22:35:30 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9CMYOed044227; Mon, 13 Oct 2003 00:34:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 13 Oct 2003 00:34:23 +0200 Subject: Re: regionalized addresses, RIRs, and table size Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Ray Plzak" From: Iljitsch van Beijnum In-Reply-To: <002a01c39109$2f4833a0$278888c0@arin.net> Message-Id: <3A4FEFF0-FD04-11D7-B291-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, okt 12, 2003, at 23:38 Europe/Amsterdam, Ray Plzak wrote: > The idea of geographic addressing based on population was briefly > discussed in the RIPE region. Strange. I presented my geographical addressing/aggregation/multihoming draft at RIPE44 and RIPE46 but nobody told me about this. What was the outcome of this discussion? From owner-multi6@ops.ietf.org Sun Oct 12 18:50:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02692 for ; Sun, 12 Oct 2003 18:50:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8ozz-0002pI-A4 for multi6-data@psg.com; Sun, 12 Oct 2003 22:47:39 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8ozm-0002oO-Ml for multi6@ops.ietf.org; Sun, 12 Oct 2003 22:47:26 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 2250A724; Sun, 12 Oct 2003 18:47:26 -0400 (EDT) Received: from ops.arin.net (ops [192.149.252.141]) by smtp2.arin.net (Postfix) with ESMTP id 9F00866B for ; Sun, 12 Oct 2003 18:47:25 -0400 (EDT) Received: from ano2 ([192.136.136.114]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA26814 for ; Sun, 12 Oct 2003 18:47:24 -0400 (EDT) From: "Ray Plzak" To: Subject: RE: regionalized addresses, RIRs, and table size Date: Sun, 12 Oct 2003 18:47:23 -0400 Message-ID: <000501c39112$ce4ce2d0$728888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3A4FEFF0-FD04-11D7-B291-00039388672E@muada.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As I recall it was discussed on the old LIR WG list. The thread died. Ray > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Sunday, October 12, 2003 6:34 PM > To: Ray Plzak > Cc: multi6@ops.ietf.org > Subject: Re: regionalized addresses, RIRs, and table size > > > On zondag, okt 12, 2003, at 23:38 Europe/Amsterdam, Ray Plzak wrote: > > > The idea of geographic addressing based on population was briefly > > discussed in the RIPE region. > > Strange. I presented my geographical > addressing/aggregation/multihoming > draft at RIPE44 and RIPE46 but nobody told me about this. > > What was the outcome of this discussion? > From owner-multi6@ops.ietf.org Sun Oct 12 19:38:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03455 for ; Sun, 12 Oct 2003 19:38:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8pjs-0006pk-0N for multi6-data@psg.com; Sun, 12 Oct 2003 23:35:04 +0000 Received: from [134.193.143.160] (helo=kc-msxproto3.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8pjk-0006oc-Up for multi6@ops.ietf.org; Sun, 12 Oct 2003 23:34:57 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Sun, 12 Oct 2003 18:34:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Routing table size? Date: Sun, 12 Oct 2003 18:34:54 -0500 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390BAA7849@KC-MAIL4.kc.umkc.edu> Thread-Topic: Routing table size? Thread-Index: AcOQsRIxB4I8BHIRRCSjlnQS7yjaHgAaFmhg From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Iljitsch van Beijnum" , "masataka ohta" Cc: X-OriginalArrivalTime: 12 Oct 2003 23:34:52.0610 (UTC) FILETIME=[6F6C8A20:01C39119] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=1.0 required=5.0 tests=BAYES_44,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable http://www.cidr-report.org/v6/ From owner-multi6@ops.ietf.org Mon Oct 13 00:11:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09985 for ; Mon, 13 Oct 2003 00:11:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8tyR-0003gN-JH for multi6-data@psg.com; Mon, 13 Oct 2003 04:06:23 +0000 Received: from [68.49.139.245] (helo=mail.krioukov.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8tyK-0003fh-Dj for multi6@ops.ietf.org; Mon, 13 Oct 2003 04:06:16 +0000 Received: from DIMA1 (dhcp-host-017.pcp744791pcs.reston01.va.comcast.net [192.168.1.17]) by mail.krioukov.net (8.11.6/8.11.6) with SMTP id h9D45qp04113; Mon, 13 Oct 2003 00:05:52 -0400 From: "Dmitri Krioukov" To: "masataka ohta" Cc: Subject: RE: Routing table size? Date: Mon, 13 Oct 2003 00:05:47 -0400 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.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <3F892A4B.3030108@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Level: * X-Spam-Status: No, hits=1.8 required=5.0 tests=BAYES_30,RCVD_IN_DYNABLOCK, RCVD_IN_RFCI autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka, One of the latest model for the routing table size (growth) explicitly including allocation policies was presented at the last SIGCOMM, http://www.acm.org/sigcomm/sigcomm2003/papers.html#p125-narayan -- dima. http://www.krioukov.net/~dima/ > -----Original Message----- > From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On > Behalf Of masataka ohta > Sent: Sunday, October 12, 2003 6:18 AM > To: multi6@ops.ietf.org > Subject: Routing table size? > > > Dear all; > > How, do you think, will the size of global routing table be? > > As I raised the question before Vienna, Brian said it should > be proportional to logarithm of the network size. > > Is it agreeable? > > If so, the next question is on the base of the logarithm. > > Masataka Ohta > From owner-multi6@ops.ietf.org Mon Oct 13 01:47:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11404 for ; Mon, 13 Oct 2003 01:47:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8vUl-000Bb4-S5 for multi6-data@psg.com; Mon, 13 Oct 2003 05:43:51 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8vUb-000Ba8-Ff for multi6@ops.ietf.org; Mon, 13 Oct 2003 05:43:41 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9D5h0v09906; Mon, 13 Oct 2003 08:43:00 +0300 Date: Mon, 13 Oct 2003 08:42:59 +0300 (EEST) From: Pekka Savola To: masataka ohta cc: Jeroen Massar , "'Iljitsch van Beijnum'" , Subject: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] In-Reply-To: <3F8974AC.6070001@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Let's change the subject as there seems to need some discussion.. On Mon, 13 Oct 2003, masataka ohta wrote: > > I personally see the situation where I would get two > > independent ISP's, eg a cable and ADSL provider. They don't > > have to know anything about eachother. The only thing they do > > is that they each route a prefix from and to me as delegated out > > of their TLA. My boxes thus would get 2 prefixes. > > And, you want to have 2 exit routers, if you want to avoid a single > point of failure. > > Then, you want to have full route in your site to choose the best > exit router for each destination. > > Or, you may develop a complex protocol on hosts and exit routers > that a host first query exit routers (multiple ones, of course) > to choose a source address and routers between the host and > the exit routers perform source address based routing (or, > the host may use tunneling to the exit routers), even in which > case, the exit routers must have a global routing table. > > This is why the global routing table should be reasonably small. I fail to see a strict *requirement* for the global routing table even at border routers. A typical customer (at least the kind of I imagine using something like this) would be one connecting to two operators operating in the same region. The global connectivity would be more or less the same. Sure, there could be differences and optimizations of dozens of milliseconds, but that wouldn't be a major problem. More likely than not, having just two default routes would be "good enough". If one wanted more granularity than that, adding the prefixes directly connected to each ISPs to be explicitly preferred through that ISP could optimize the scenarios quite a bit. Remember -- the ISPs *do* inter-connect locally these days, except in some developing areas. And in that case, the choice of the ISP for outbound packets really don't matter much at all, as long as it just works.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Oct 13 02:08:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20648 for ; Mon, 13 Oct 2003 02:08:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8vrr-000Dhx-Px for multi6-data@psg.com; Mon, 13 Oct 2003 06:07:43 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8vrh-000Dgi-19 for multi6@ops.ietf.org; Mon, 13 Oct 2003 06:07:33 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 56C034E420; Mon, 13 Oct 2003 08:05:11 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 049344E01C for ; Mon, 13 Oct 2003 08:05:11 +0200 (CEST) Received: from ripe.net (guest187.ripe.net [193.0.0.187]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id h9D65AVZ014823 for ; Mon, 13 Oct 2003 08:05:10 +0200 Message-ID: Date: Mon, 13 Oct 2003 08:03:36 +0200 To: multi6@ops.ietf.org From: leo vegoda Subject: Re: RIR bashing, was: Routing table size? References: <3F89505F.5030204@necom830.hpcl.titech.ac.jp> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed User-Agent: Turnpike/6.02-U (<7BiAomRdj8KB0L6Vd08o5SzdCI>) X-RIPE-Spam-Status: N 0.003129 X-RIPE-Signature: cb9e069382a46d97cc1b403cae1ce798 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch van Beijnum wrote: [...] >> The only real requirement is global visibility and, with IPv4 today, >> it is granted to an ISP with multiple external connectivities, which >> is not necessarily the case with multi6. > >Actually it doesn't work like that in IPv4 either. You can get an AS >number if you multihome, but for your own address block you need to >show immediate use for a /22 (in the RIPE region). That's not quite right. If you just want IPv4 address space for yourself then you can get whatever you'll use efficiently. If you need a /29 then that's what you'll get. If you need a /15 then that's what you'll get. Only if you want to assign address space to your customers do you have to show usage of a /22 (for you an all your customers combined). Of course, the policy can be changed if people want it to be. Regards, -- leo vegoda RIPE NCC Registration Services Manager From owner-multi6@ops.ietf.org Mon Oct 13 04:53:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26885 for ; Mon, 13 Oct 2003 04:53:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8yOx-0003xC-Fh for multi6-data@psg.com; Mon, 13 Oct 2003 08:50:03 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8yOg-0003vf-Qf for multi6@ops.ietf.org; Mon, 13 Oct 2003 08:49:47 +0000 Received: (qmail 32446 invoked from network); 13 Oct 2003 08:48:04 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 13 Oct 2003 08:48:04 -0000 Message-ID: <3F8A675E.2060503@necom830.hpcl.titech.ac.jp> Date: Mon, 13 Oct 2003 17:50:38 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Jeroen Massar , "'Iljitsch van Beijnum'" , multi6@ops.ietf.org Subject: Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka; > A typical customer (at least the kind of I imagine using something like > this) would be one connecting to two operators operating in the same > region. The global connectivity would be more or less the same. Sure, > there could be differences and optimizations of dozens of milliseconds, > but that wouldn't be a major problem. You are saying there were geographical aggregation. There is not. Otherwise, go with geographic aggregation. It should also be noted that, like geographic aggregation, your scheme will make some local peeing a single point of failure. > Remember -- the ISPs *do* inter-connect locally these days, except in > some developing areas. And in that case, the choice of the ISP for > outbound packets really don't matter much at all, as long as it just > works.. If only it had worked. The reality is that partially broken ISP is paritally broken. Masataka Ohta From owner-multi6@ops.ietf.org Mon Oct 13 05:02:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27182 for ; Mon, 13 Oct 2003 05:01:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8yZM-0004po-0N for multi6-data@psg.com; Mon, 13 Oct 2003 09:00:48 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8yZD-0004ob-VL for multi6@ops.ietf.org; Mon, 13 Oct 2003 09:00:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9D8xxU11991; Mon, 13 Oct 2003 11:59:59 +0300 Date: Mon, 13 Oct 2003 11:59:58 +0300 (EEST) From: Pekka Savola To: masataka ohta cc: Jeroen Massar , "'Iljitsch van Beijnum'" , Subject: Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] In-Reply-To: <3F8A675E.2060503@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 13 Oct 2003, masataka ohta wrote: > > A typical customer (at least the kind of I imagine using something like > > this) would be one connecting to two operators operating in the same > > region. The global connectivity would be more or less the same. Sure, > > there could be differences and optimizations of dozens of milliseconds, > > but that wouldn't be a major problem. > > You are saying there were geographical aggregation. > > There is not. > > Otherwise, go with geographic aggregation. > > It should also be noted that, like geographic aggregation, your > scheme will make some local peeing a single point of failure. I don't think I'm implying that there is geographical aggregation. Perhaps my wording "the global connectivity would be more or less the same" was confusing. What I meant is that it really doesn't matter much whether your ISP happens to use e.g. Sprint, Level3, or Telia for its upstream transit connectivity.. and in consequence, I'd fail to see how adding BGP at your site edge router would dramatically help the situation. There IMHO, as you said, is not geographical aggregation in the sense that one single point would be providing aggregated global connectivity. > > Remember -- the ISPs *do* inter-connect locally these days, except in > > some developing areas. And in that case, the choice of the ISP for > > outbound packets really don't matter much at all, as long as it just > > works.. > > If only it had worked. > > The reality is that partially broken ISP is paritally broken. I'm not sure which kind of brokenness you're referring to -- sometimes, the ISPs are broken in such a way that even having the full BGP feed at your site would not help (routing OK but packets get dropped). It's possible to remove the default route for the other ISP if it's broken, or to add more specifics to point to the working ISP if necessary. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Oct 13 05:19:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27772 for ; Mon, 13 Oct 2003 05:19:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8ypX-0006MH-Pc for multi6-data@psg.com; Mon, 13 Oct 2003 09:17:31 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8ypT-0006Lc-0v for multi6@ops.ietf.org; Mon, 13 Oct 2003 09:17:27 +0000 Received: (qmail 32553 invoked from network); 13 Oct 2003 09:15:46 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 13 Oct 2003 09:15:46 -0000 Message-ID: <3F8A6DDA.9050005@necom830.hpcl.titech.ac.jp> Date: Mon, 13 Oct 2003 18:18:18 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Jeroen Massar , "'Iljitsch van Beijnum'" , multi6@ops.ietf.org Subject: Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka; > It's possible to remove the default route for the other ISP if it's > broken, or to add more specifics to point to the working ISP if necessary. Exactly. And the easiest way to do so is to have full route. If you are not convinced, here is a reality check. How many of multihomed (non-transit) entities today are using the default-only approach? Masataka Ohta From owner-multi6@ops.ietf.org Mon Oct 13 05:29:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28073 for ; Mon, 13 Oct 2003 05:29:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8yzs-0007Hf-5F for multi6-data@psg.com; Mon, 13 Oct 2003 09:28:12 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8yzf-0007Gv-8t for multi6@ops.ietf.org; Mon, 13 Oct 2003 09:27:59 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 89017433B9; Mon, 13 Oct 2003 11:27:58 +0200 (CEST) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp02.uc3m.es (Postfix) with ESMTP id 7900399FF9; Mon, 13 Oct 2003 11:27:55 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: Iljitsch van Beijnum , "Jeroen Massar" Subject: Re: RIR bashing, was: Routing table size? Date: Mon, 13 Oct 2003 11:27:53 +0200 User-Agent: KMail/1.5 Cc: References: <63BC18C1-FCC0-11D7-B291-00039388672E@muada.com> In-Reply-To: <63BC18C1-FCC0-11D7-B291-00039388672E@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310131127.55096.jrh@it.uc3m.es> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday 12 October 2003 16:28, Iljitsch van Beijnum wrote: > > and at the moment you are out of luck. But then again > > I don't know any enduser type people having the connectivity > > nor the need for their own routing. That's why I pay my upstreams > > so they can handle all that stuff for me and I can sleep fine :) > > Ok then we can terminate this working group. > > Actually you do know such an enduser: me. I have two lines coming into > my home and I run IPv6 over both of them. In fact the server that is > colocated with one ISP is reachable (over IPv6) through the other ISP, > my home network and the link to the colo ISP. (Do some traces for > www.bgpexpert.com.) Then....What's the matter ? I didn't quite catch what you need. to set up this topology. Do you need a higher block of IPv6 addresses ? or it's that you need to manage your own routing ? -- JFRH From owner-multi6@ops.ietf.org Mon Oct 13 05:30:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28096 for ; Mon, 13 Oct 2003 05:30:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8z0d-0007Kk-HM for multi6-data@psg.com; Mon, 13 Oct 2003 09:28:59 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8z0Y-0007Jm-TW for multi6@ops.ietf.org; Mon, 13 Oct 2003 09:28:55 +0000 Received: (qmail 32585 invoked from network); 13 Oct 2003 09:27:14 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 13 Oct 2003 09:27:14 -0000 Message-ID: <3F8A708A.5030405@necom830.hpcl.titech.ac.jp> Date: Mon, 13 Oct 2003 18:29:46 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Bash IETF, not RIRs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all; When IETF produces a broken protocol, don't bash RIRs that they don't set good policy to operate the protocol. They can't. Current IPv6, with no insight on routing table scalability problem, is broken. IETF and its IPv6 WG, if any, should be bashed, as the problem was known to exist even before the WG was created. Masataka Ohta From owner-multi6@ops.ietf.org Mon Oct 13 05:41:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28253 for ; Mon, 13 Oct 2003 05:41:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8zAS-00089M-R4 for multi6-data@psg.com; Mon, 13 Oct 2003 09:39:08 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8zAN-00088g-Qb for multi6@ops.ietf.org; Mon, 13 Oct 2003 09:39:03 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 26E0B4339E; Mon, 13 Oct 2003 11:39:03 +0200 (CEST) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp02.uc3m.es (Postfix) with ESMTP id 0056399FCE; Mon, 13 Oct 2003 11:39:00 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: masataka ohta , Jeroen Massar Subject: Re: RIR bashing, was: Routing table size? Date: Mon, 13 Oct 2003 11:38:59 +0200 User-Agent: KMail/1.5 Cc: "'Iljitsch van Beijnum'" , multi6@ops.ietf.org References: <005401c390d1$d4eea4c0$210d640a@unfix.org> <3F8974AC.6070001@necom830.hpcl.titech.ac.jp> In-Reply-To: <3F8974AC.6070001@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310131139.00574.jrh@it.uc3m.es> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday 12 October 2003 17:35, masataka ohta wrote: > Jeroen; > > > I personally see the situation where I would get two > > independent ISP's, eg a cable and ADSL provider. They don't > > have to know anything about eachother. The only thing they do > > is that they each route a prefix from and to me as delegated out > > of their TLA. My boxes thus would get 2 prefixes. > > And, you want to have 2 exit routers, if you want to avoid a single > point of failure. IMO, you don't have to have a global routing table to do this. > > Then, you want to have full route in your site to choose the best > exit router for each destination. > The same here. > Or, you may develop a complex protocol on hosts and exit routers > that a host first query exit routers (multiple ones, of course) > to choose a source address and routers between the host and > the exit routers perform source address based routing (or, > the host may use tunneling to the exit routers), even in which > case, the exit routers must have a global routing table. > Do you need to have a global routing table to make "source based routing" ? (I thought it was just the opposite, you should need a global routing table to make "destination based routing") Cheers. > This is why the global routing table should be reasonably small. > > Masataka Ohta -- JFRH From owner-multi6@ops.ietf.org Mon Oct 13 05:46:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28364 for ; Mon, 13 Oct 2003 05:46:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8zH3-0008i5-9w for multi6-data@psg.com; Mon, 13 Oct 2003 09:45:57 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8zGv-0008gp-Bk for multi6@ops.ietf.org; Mon, 13 Oct 2003 09:45:50 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9D9jNb12493; Mon, 13 Oct 2003 12:45:23 +0300 Date: Mon, 13 Oct 2003 12:45:22 +0300 (EEST) From: Pekka Savola To: masataka ohta cc: Jeroen Massar , "'Iljitsch van Beijnum'" , Subject: Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] In-Reply-To: <3F8A6DDA.9050005@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 13 Oct 2003, masataka ohta wrote: > > It's possible to remove the default route for the other ISP if it's > > broken, or to add more specifics to point to the working ISP if necessary. > > Exactly. And the easiest way to do so is to have full route. > > If you are not convinced, here is a reality check. > > How many of multihomed (non-transit) entities today are using the > default-only approach? Uhh, quite many? There are a lot more ways to "multihome" than just getting an AS, prefix, and BGP feed from two ISPs. I think many actually use solutions like FatPipe WARP (http://www.fatpipeinc.com/), or LinkProof to get a subset of multihoming benefits. Perhaps there is a partial mismatch of assumptions. For me, the home or small office users could want to start want multihoming too. For them, BGP-like mechanisms and full routing tables seem like an overkill. For midsize enterprises I would like to say the same, unless they insist otherwise. For really big enterprises, it seems fighting against them seems like a battle against the windmill. What we need is a set of rather simple and workable multihoming procedures which don't need (global) routing protocols, public AS numbers or provider independent addresses. But that procedure need not be exclusive, "the only way". For e.g. bigger organizations, there could be different methods. Maybe you're mostly concerned on those (big) folks who multihome today, with known mechanisms. Maybe multiaddressing fits to some of their objectives, maybe not. But even if it does, they should be able to handle a pretty large routing table because .. well.. they already do it today. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Oct 13 05:56:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28584 for ; Mon, 13 Oct 2003 05:56:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8zQK-0009eO-6I for multi6-data@psg.com; Mon, 13 Oct 2003 09:55:32 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8zQF-0009ds-TW for multi6@ops.ietf.org; Mon, 13 Oct 2003 09:55:28 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 381D64316C; Mon, 13 Oct 2003 11:55:27 +0200 (CEST) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp02.uc3m.es (Postfix) with ESMTP id C50EE99FDD; Mon, 13 Oct 2003 11:55:24 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: masataka ohta , Pekka Savola Subject: Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] Date: Mon, 13 Oct 2003 11:55:23 +0200 User-Agent: KMail/1.5 Cc: Jeroen Massar , "'Iljitsch van Beijnum'" , multi6@ops.ietf.org References: <3F8A6DDA.9050005@necom830.hpcl.titech.ac.jp> In-Reply-To: <3F8A6DDA.9050005@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310131155.24334.jrh@it.uc3m.es> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 13 October 2003 11:18, masataka ohta wrote: > Pekka; > > > It's possible to remove the default route for the other ISP if it's > > broken, or to add more specifics to point to the working ISP if > > necessary. > > Exactly. And the easiest way to do so is to have full route. Hello Ohta :) Now I see your point. I think it is the easiest way because BGP takes care of broken paths automatically. On the other hand, there are other possibilites which doesn't imply the need of full routing. E. g, you could check connectivity with your upstream provider and realise when that is broken to divert traffic to the other exit router.... > If you are not convinced, here is a reality check. > > How many of multihomed (non-transit) entities today are using the > default-only approach? > > Masataka Ohta Good point, though I don't think the IPv4-way of doing multihomed things should be the example to follow for IPv6-multihomed sites... Have fun ! -- JFRH From owner-multi6@ops.ietf.org Mon Oct 13 06:26:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29277 for ; Mon, 13 Oct 2003 06:26:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8zso-000C7f-5m for multi6-data@psg.com; Mon, 13 Oct 2003 10:24:58 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A8zsi-000C76-Jc for multi6@ops.ietf.org; Mon, 13 Oct 2003 10:24:53 +0000 Received: (qmail 32808 invoked from network); 13 Oct 2003 10:23:12 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 13 Oct 2003 10:23:12 -0000 Message-ID: <3F8A7DA7.7050207@necom830.hpcl.titech.ac.jp> Date: Mon, 13 Oct 2003 19:25:43 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Juan Rodriguez Hervella CC: Jeroen Massar , "'Iljitsch van Beijnum'" , multi6@ops.ietf.org Subject: Re: RIR bashing, was: Routing table size? References: <005401c390d1$d4eea4c0$210d640a@unfix.org> <3F8974AC.6070001@necom830.hpcl.titech.ac.jp> <200310131139.00574.jrh@it.uc3m.es> In-Reply-To: <200310131139.00574.jrh@it.uc3m.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juan Rodriguez Hervella; >>>I personally see the situation where I would get two >>>independent ISP's, eg a cable and ADSL provider. They don't >>>have to know anything about eachother. The only thing they do >>>is that they each route a prefix from and to me as delegated out >>>of their TLA. My boxes thus would get 2 prefixes. >> >>And, you want to have 2 exit routers, if you want to avoid a single >>point of failure. > IMO, you don't have to have a global routing table to do this. No, of course. >>Then, you want to have full route in your site to choose the best >>exit router for each destination. > The same here. Wrong. >>Or, you may develop a complex protocol on hosts and exit routers >>that a host first query exit routers (multiple ones, of course) >>to choose a source address and routers between the host and >>the exit routers perform source address based routing (or, >>the host may use tunneling to the exit routers), even in which >>case, the exit routers must have a global routing table. > Do you need to have a global routing table to make "source based routing" ? No, not at all. Masataka Ohta From owner-multi6@ops.ietf.org Mon Oct 13 06:33:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29496 for ; Mon, 13 Oct 2003 06:33:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A900K-000Cme-VT for multi6-data@psg.com; Mon, 13 Oct 2003 10:32:44 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A900I-000CmJ-1H for multi6@ops.ietf.org; Mon, 13 Oct 2003 10:32:42 +0000 Received: (qmail 32838 invoked from network); 13 Oct 2003 10:31:01 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 13 Oct 2003 10:31:01 -0000 Message-ID: <3F8A7F7A.8010408@necom830.hpcl.titech.ac.jp> Date: Mon, 13 Oct 2003 19:33:30 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Jeroen Massar , "'Iljitsch van Beijnum'" , multi6@ops.ietf.org Subject: Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka; >>>It's possible to remove the default route for the other ISP if it's >>>broken, or to add more specifics to point to the working ISP if necessary. >> >>Exactly. And the easiest way to do so is to have full route. >> >>If you are not convinced, here is a reality check. >> >>How many of multihomed (non-transit) entities today are using the >>default-only approach? > > > Uhh, quite many? There are a lot more ways to "multihome" than just > getting an AS, prefix, and BGP feed from two ISPs. I think many actually > use solutions like FatPipe WARP (http://www.fatpipeinc.com/), or > LinkProof to get a subset of multihoming benefits. If you think they are "multihome", feel free to use it with IPv6. Or, accept the reality. > Perhaps there is a partial mismatch of assumptions. Between assumptions of yours, yes. > For me, the home or small office users could want to start want > multihoming too. For them, BGP-like mechanisms and full routing tables > seem like an overkill. For midsize enterprises I would like to say the > same, unless they insist otherwise. For really big enterprises, it seems > fighting against them seems like a battle against the windmill. Your wrong assumption here is that full routing table is large. > What we need is a set of rather simple and workable multihoming procedures > which don't need (global) routing protocols, public AS numbers or provider > independent addresses. But that procedure need not be exclusive, "the > only way". For e.g. bigger organizations, there could be different > methods. What we need is a workable multihoming solution. > Maybe you're mostly concerned on those (big) folks who multihome today, > with known mechanisms. That is your mistake. > Maybe multiaddressing fits to some of their > objectives, maybe not. But even if it does, they should be able to handle > a pretty large routing table because .. well.. they already do it today. That's why full routing table should be small. Masataka Ohta From owner-multi6@ops.ietf.org Mon Oct 13 07:55:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01253 for ; Mon, 13 Oct 2003 07:55:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A91Fa-000I91-G7 for multi6-data@psg.com; Mon, 13 Oct 2003 11:52:34 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A91FR-000I82-3l for multi6@ops.ietf.org; Mon, 13 Oct 2003 11:52:25 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 63B868A0; Mon, 13 Oct 2003 07:52:24 -0400 (EDT) Received: from ops.arin.net (ops [192.149.252.141]) by smtp2.arin.net (Postfix) with ESMTP id F1E6288C; Mon, 13 Oct 2003 07:52:23 -0400 (EDT) Received: from ano2 ([192.136.136.114]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id HAA09139; Mon, 13 Oct 2003 07:52:23 -0400 (EDT) From: "Ray Plzak" To: "'masataka ohta'" Cc: Subject: RE: Routing table size? Date: Mon, 13 Oct 2003 07:52:22 -0400 Message-ID: <000401c39180$76ad34d0$728888c0@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3F8975ED.8010002@necom830.hpcl.titech.ac.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ohta-san, The policy can only be for existing protocols/technology. It doesn't hurt to consider what an allocation policy should be when considering a new or revised protocol. Ray > -----Original Message----- > From: masataka ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Sunday, October 12, 2003 11:40 AM > To: Ray Plzak > Cc: multi6@ops.ietf.org > Subject: Re: Routing table size? > > > Ray; > > > This list is the appropriate place to ask questions about > current policy > > as well as suggest changes to existing policy or even propose new > > policy. > > Propose new policy based on which specification? > > Can the specification not necessarily the current IPv6 as is? > > Masataka Ohta > From owner-multi6@ops.ietf.org Mon Oct 13 09:19:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03180 for ; Mon, 13 Oct 2003 09:19:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A92Yi-000Nbl-9J for multi6-data@psg.com; Mon, 13 Oct 2003 13:16:24 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A92YH-000NZ5-3J for multi6@ops.ietf.org; Mon, 13 Oct 2003 13:15:57 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9DDF8ed053717; Mon, 13 Oct 2003 15:15:08 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 13 Oct 2003 12:13:12 +0200 Subject: Re: RIR bashing, was: Routing table size? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Juan Rodriguez Hervella From: Iljitsch van Beijnum In-Reply-To: <200310131127.55096.jrh@it.uc3m.es> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On maandag, okt 13, 2003, at 11:27 Europe/Amsterdam, Juan Rodriguez Hervella wrote: >> Actually you do know such an enduser: me. I have two lines coming into >> my home and I run IPv6 over both of them. In fact the server that is >> colocated with one ISP is reachable (over IPv6) through the other ISP, >> my home network and the link to the colo ISP. (Do some traces for >> www.bgpexpert.com.) > Then....What's the matter ? I didn't quite catch what you need. > to set up this topology. Do you need a higher block of IPv6 addresses ? > or it's that you need to manage your own routing ? There are two problems. The first is that I have no way to keep the source address and outgoing ISP consistent. Fortunately, the ISP I point my default to doesn't bother with any ingress filtering for IPv6. (Hm, I should try and see if they don't do it for v4 either.) Source address based routing would help some here, but it doesn't really fix the problem. And of course when something bad happens my sessions break because those are tied to a single pair of source/dest addresses. From owner-multi6@ops.ietf.org Mon Oct 13 09:19:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03199 for ; Mon, 13 Oct 2003 09:19:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A92Yd-000NbN-1Z for multi6-data@psg.com; Mon, 13 Oct 2003 13:16:19 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A92YH-000NZ7-3T for multi6@ops.ietf.org; Mon, 13 Oct 2003 13:15:57 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9DDFAed053725; Mon, 13 Oct 2003 15:15:10 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 13 Oct 2003 12:31:48 +0200 Subject: Re: RIR bashing, was: Routing table size? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: leo vegoda From: Iljitsch van Beijnum In-Reply-To: Message-Id: <738E7756-FD68-11D7-B291-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On maandag, okt 13, 2003, at 08:03 Europe/Amsterdam, leo vegoda wrote: >> Actually it doesn't work like that in IPv4 either. You can get an AS >> number if you multihome, but for your own address block you need to >> show immediate use for a /22 (in the RIPE region). > That's not quite right. If you just want IPv4 address space for > yourself then you can get whatever you'll use efficiently. If you need > a /29 then that's what you'll get. If you need a /15 then that's what > you'll get. Only if you want to assign address space to your customers > do you have to show usage of a /22 (for you an all your customers > combined). With "your own address block" I mean either a PI block or a PA block, NOT an assignment out of someone else's PA block. So are you saying that I can get a PI /29 if I want to? Many people would be ecstatic if they could get PI /24s or /23s as those are reasonably routable and 24 or 23 bits is much easier to qualify for than 22, or even 20 as I gather ARIN requires. From owner-multi6@ops.ietf.org Mon Oct 13 09:19:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03231 for ; Mon, 13 Oct 2003 09:19:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A92YS-000NaR-TB for multi6-data@psg.com; Mon, 13 Oct 2003 13:16:08 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A92YH-000NZ6-2l for multi6@ops.ietf.org; Mon, 13 Oct 2003 13:15:57 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9DDF9ed053722; Mon, 13 Oct 2003 15:15:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 13 Oct 2003 12:23:09 +0200 Subject: Re: Bash IETF, not RIRs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: masataka ohta From: Iljitsch van Beijnum In-Reply-To: <3F8A708A.5030405@necom830.hpcl.titech.ac.jp> Message-Id: <3E44672F-FD67-11D7-B291-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On maandag, okt 13, 2003, at 11:29 Europe/Amsterdam, masataka ohta wrote: > When IETF produces a broken protocol, don't bash RIRs that > they don't set good policy to operate the protocol. They > can't. Disagree. A good policy would be making the best of the situation we're in today. The current RIR IPv6 allocation policy doesn't do that as it allows for a routing table of 520 million /32 entries, which is more than what we can realistically expect routers to handle in the future. > IETF and its IPv6 WG, if any, should be bashed, as the problem > was known to exist even before the WG was created. At least we're trying to fix one part of the problem in this working group... Back to your idea of having a full routing table in each host. We've talked about this and things haven't changed in the mean time. Without aggregation, this makes sense, as a host then knows what's reachable and what isn't, and maybe even gets to determine which path to a certain destination is shorter. But all this very useful information is hidden behind aggregation. For instance, if you want to determine whether you want to reach me through my 3ffe:2500:310::/48 or my 2001:888:1dde::/48 prefix, you're not going to be able to see whether those are reachable, as the /48s aren't going to be in the global routing table, just 3ffe:2500::/32 and 2001:888::/32. From owner-multi6@ops.ietf.org Mon Oct 13 09:32:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04136 for ; Mon, 13 Oct 2003 09:32:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A92n2-000Oyw-HK for multi6-data@psg.com; Mon, 13 Oct 2003 13:31:12 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A92mu-000Oy5-2M for multi6@ops.ietf.org; Mon, 13 Oct 2003 13:31:04 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 7B9A54E3AC; Mon, 13 Oct 2003 15:31:03 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 0F9234E0D3; Mon, 13 Oct 2003 15:31:03 +0200 (CEST) Received: from ripe.net (guest187.ripe.net [193.0.0.187]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id h9DDV2VZ021302; Mon, 13 Oct 2003 15:31:03 +0200 Message-ID: Date: Mon, 13 Oct 2003 15:29:51 +0200 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org From: leo vegoda Subject: Re: RIR bashing, was: Routing table size? References: <738E7756-FD68-11D7-B291-00039388672E@muada.com> In-Reply-To: <738E7756-FD68-11D7-B291-00039388672E@muada.com> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed User-Agent: Turnpike/6.02-U (<7BiAomRdj8KB0L6Vd08o5SzdCI>) X-RIPE-Spam-Status: N 0.091250 X-RIPE-Signature: b217b9153d0693cf0cd2507c5bbaee77 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi Iljitsch, Iljitsch van Beijnum wrote: >On maandag, okt 13, 2003, at 08:03 Europe/Amsterdam, leo vegoda wrote: > >>> Actually it doesn't work like that in IPv4 either. You can get an AS >>>number if you multihome, but for your own address block you need to >>>show immediate use for a /22 (in the RIPE region). > >> That's not quite right. If you just want IPv4 address space for >>yourself then you can get whatever you'll use efficiently. If you need >>a /29 then that's what you'll get. If you need a /15 then that's what >>you'll get. Only if you want to assign address space to your customers >>do you have to show usage of a /22 (for you an all your customers combined). > >With "your own address block" I mean either a PI block or a PA block, >NOT an assignment out of someone else's PA block. > >So are you saying that I can get a PI /29 if I want to? You can if you'll use the /29 efficiently. >Many people would be ecstatic if they could get PI /24s or /23s as >those are reasonably routable and 24 or 23 bits is much easier to >qualify for than 22, or even 20 as I gather ARIN requires. They can get a /24 or a /23 (or more - or less) if they'll use the address space efficiently. It is worth noting that there is currently a Task Force looking at possible changes to this policy. You can join the list at: and review the archives at: Best regards, -- leo vegoda RIPE NCC Registration Services Manager From owner-multi6@ops.ietf.org Mon Oct 13 09:50:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04912 for ; Mon, 13 Oct 2003 09:50:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9344-0000Qo-AR for multi6-data@psg.com; Mon, 13 Oct 2003 13:48:48 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A933w-0000Pt-RO for multi6@ops.ietf.org; Mon, 13 Oct 2003 13:48:41 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 2F14443141; Mon, 13 Oct 2003 15:48:40 +0200 (CEST) Received: from lolo (unknown [163.117.139.245]) by smtp02.uc3m.es (Postfix) with SMTP id 1D7BE99FDF; Mon, 13 Oct 2003 15:48:40 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" Cc: Subject: RE: Bash IETF, not RIRs Date: Mon, 13 Oct 2003 15:43:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3E44672F-FD67-11D7-B291-00039388672E@muada.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, > Disagree. A good policy would be making the best of the situation we're > in today. The current RIR IPv6 allocation policy doesn't do that as it > allows for a routing table of 520 million /32 entries, which is more > than what we can realistically expect routers to handle in the future. I don't understand what you are suggesting, could you be more explicit about what do you consider that the IPv6 allocation policy should be? (Sorry if this is OT, perhaps we could move the thread to globalv6, chairs?) The way that i can think of how to reduce this, would be not to assign a PA block to all isps, and impose them to obtain a block from a bigger ISP, is that what you are suggesting? If this is so, i am not sure how isp multi-homing would work for instance... The lower isps that are multi-homed would have multiple prefixes, one per provider, as it is proposed for sites today? Thanks, marcelo From owner-multi6@ops.ietf.org Mon Oct 13 10:13:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06751 for ; Mon, 13 Oct 2003 10:13:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A93PV-0002DF-1v for multi6-data@psg.com; Mon, 13 Oct 2003 14:10:57 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A93PQ-0002Cf-RA for multi6@ops.ietf.org; Mon, 13 Oct 2003 14:10:53 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A93PP-000BS4-Qc for multi6@ops.ietf.org; Mon, 13 Oct 2003 16:10:51 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Content-Transfer-Encoding: 7bit Message-Id: Date: Mon, 13 Oct 2003 14:44:32 +0200 Subject: Call for agenda items From: Kurt Erik Lindqvist To: multi6@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a reminder for the call for agenda items for the 58th IETF in Minneapolis. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP4qeMaarNKXTPFCVEQL3NwCfQKmZeeRZhtCacdQ8zReWjV0KiPoAmgKF QgUTAR9GBsJsFLczTbZ4l9mA =REsw -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Oct 13 10:40:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08662 for ; Mon, 13 Oct 2003 10:40:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A93ot-0004LW-7W for multi6-data@psg.com; Mon, 13 Oct 2003 14:37:11 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A93om-0004Ko-Jb for multi6@ops.ietf.org; Mon, 13 Oct 2003 14:37:04 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id DFC8F4315A; Mon, 13 Oct 2003 16:37:03 +0200 (CEST) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp02.uc3m.es (Postfix) with ESMTP id CA29799FDE; Mon, 13 Oct 2003 16:37:03 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: Iljitsch van Beijnum Subject: Re: RIR bashing, was: Routing table size? Date: Mon, 13 Oct 2003 16:37:02 +0200 User-Agent: KMail/1.5 Cc: multi6@ops.ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310131637.03180.jrh@it.uc3m.es> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday 13 October 2003 12:13, Iljitsch van Beijnum wrote: > On maandag, okt 13, 2003, at 11:27 Europe/Amsterdam, Juan Rodriguez > > Hervella wrote: > >> Actually you do know such an enduser: me. I have two lines coming into > >> my home and I run IPv6 over both of them. In fact the server that is > >> colocated with one ISP is reachable (over IPv6) through the other ISP, > >> my home network and the link to the colo ISP. (Do some traces for > >> www.bgpexpert.com.) > > > > Then....What's the matter ? I didn't quite catch what you need. > > to set up this topology. Do you need a higher block of IPv6 addresses ? > > or it's that you need to manage your own routing ? > > There are two problems. The first is that I have no way to keep the > source address and outgoing ISP consistent. Fortunately, the ISP I > point my default to doesn't bother with any ingress filtering for IPv6. > (Hm, I should try and see if they don't do it for v4 either.) Source > address based routing would help some here, but it doesn't really fix > the problem. Hi again :) About the first problem, I think that "source based routing" can help a lot. You only have to read the source address of the packets and re-route those that are not consistent with the prefix of the exit border router they've been sent to. > > And of course when something bad happens my sessions break because > those are tied to a single pair of source/dest addresses. I completely agree with you on this problem. Is there any other workaround but putting forward the id/loc separation model ? PS: The subject line doesn't look like what we're discussing, should we start a new thread ? I don't come up with a new one yet ^--^ Thanks for your time! -- JFRH From owner-multi6@ops.ietf.org Tue Oct 14 04:27:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29848 for ; Tue, 14 Oct 2003 04:27:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9KOY-0001sC-37 for multi6-data@psg.com; Tue, 14 Oct 2003 08:19:06 +0000 Received: from [209.226.175.16] (helo=toq3-srv.bellnexxia.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9KOQ-0001rb-TO for multi6@ops.ietf.org; Tue, 14 Oct 2003 08:18:58 +0000 Received: from yahoo.com ([65.93.190.160]) by tomts6-srv.bellnexxia.net (InterMail vM.5.01.06.04 201-253-122-130-104-20030726) with ESMTP id <20031014073552.CMHI25655.tomts6-srv.bellnexxia.net@yahoo.com>; Tue, 14 Oct 2003 03:35:52 -0400 Date: Tue, 14 Oct 2003 03:35:52 -0400 Subject: Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: Pekka Savola From: Simon Woodside In-Reply-To: Message-Id: <09CFCF33-FE19-11D7-AEFF-000A9573F104@yahoo.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Level: ** X-Spam-Status: No, hits=2.5 required=5.0 tests=BAYES_44,FORGED_YAHOO_RCVD, RCVD_FAKE_HELO_DOTCOM autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, October 13, 2003, at 01:42 AM, Pekka Savola wrote: > Remember -- the ISPs *do* inter-connect locally these days, except in > some developing areas. Even in developing areas they are doing it too.... IXPs are cropping up everywhere in Africa, etc. as people realize they are getting totally screwed by the transit providers. An interest of mine. simon -- www.simonwoodside.com :: www.openict.net :: www.semacode.org 99% Devil, 1% Angel From owner-multi6@ops.ietf.org Tue Oct 14 04:51:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00424 for ; Tue, 14 Oct 2003 04:51:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9KsG-0003Mh-Tr for multi6-data@psg.com; Tue, 14 Oct 2003 08:49:48 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9Kry-0003M0-CI for multi6@ops.ietf.org; Tue, 14 Oct 2003 08:49:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9E8nH230378; Tue, 14 Oct 2003 11:49:17 +0300 Date: Tue, 14 Oct 2003 11:49:16 +0300 (EEST) From: Pekka Savola To: Simon Woodside cc: multi6@ops.ietf.org Subject: Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] In-Reply-To: <09CFCF33-FE19-11D7-AEFF-000A9573F104@yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 14 Oct 2003, Simon Woodside wrote: > On Monday, October 13, 2003, at 01:42 AM, Pekka Savola wrote: > > Remember -- the ISPs *do* inter-connect locally these days, except in > > some developing areas. > > Even in developing areas they are doing it too.... IXPs are cropping up > everywhere in Africa, etc. as people realize they are getting totally > screwed by the transit providers. > > An interest of mine. Sure, but it has been pointed out (in context of geographically assigned addresses) multiple times as an argument that in some areas that just isn't done as well as one could hope. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue Oct 14 05:46:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01605 for ; Tue, 14 Oct 2003 05:46:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9Lhz-0005tU-1J for multi6-data@psg.com; Tue, 14 Oct 2003 09:43:15 +0000 Received: from [193.247.235.145] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9Lhp-0005sS-0A for multi6@ops.ietf.org; Tue, 14 Oct 2003 09:43:05 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h9E9ggwr002440; Tue, 14 Oct 2003 11:42:48 +0200 (CEST) Date: Mon, 13 Oct 2003 21:49:05 +0200 Subject: Re: RIR bashing, was: Routing table size? Content-Type: text/plain; charset=ISO-8859-1; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Jeroen Massar" , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <63BC18C1-FCC0-11D7-B291-00039388672E@muada.com> Message-Id: <4D45CBDC-FDB6-11D7-A99B-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: quoted-printable X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24, UPPERCASE_25_50 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On s=F6ndag, okt 12, 2003, at 16:28 Europe/Stockholm, Iljitsch van=20 Beijnum wrote: > >> If you want to be 'visible' with a smaller block you are an >> enduser > > Or a root nameserver... > Root-servers have addresses allocated to them in IPv6. Not an issue for=20= any of the current root-servers... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP4sBtaarNKXTPFCVEQLKhACgt26HG9eNiLh5GoOK2/5CaqX526sAoPYf 1I6UNgIQpgic/5dkRijtGODW =3Dwryd -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Oct 14 05:47:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01642 for ; Tue, 14 Oct 2003 05:47:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9Li0-0005ti-Vd for multi6-data@psg.com; Tue, 14 Oct 2003 09:43:16 +0000 Received: from [193.247.235.145] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9Lhq-0005sg-SP for multi6@ops.ietf.org; Tue, 14 Oct 2003 09:43:07 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h9E9h2wr002446; Tue, 14 Oct 2003 11:43:03 +0200 (CEST) Date: Mon, 13 Oct 2003 21:58:34 +0200 Subject: Re: RIR bashing, was: Routing table size? Content-Type: text/plain; charset=ISO-8859-1; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Jeroen Massar" , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <9A45099C-FCF7-11D7-B291-00039388672E@muada.com> Message-Id: Content-Transfer-Encoding: quoted-printable X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On s=F6ndag, okt 12, 2003, at 23:04 Europe/Stockholm, Iljitsch van=20 Beijnum wrote: > >> Which get /32's too but for an obvious reason. > > Not so obvious... They need one address. What are the other=20 > 79228162514264337593543950335 for? > > It's a shame really that people as a rule still don't get it. In the=20= > old days, the root servers had an address, and we used the named.root=20= > file (wasn't it called something else back then or am I confused with=20= > named.boot?) to find them. But we're doing so many routing tricks with=20= > these addresses now that it makes much more sense to group all the=20 > address blocks for all the roots together in a special range. Bonus:=20= > we get to hardcode the root addresses now too, as we're now no longer=20= > modifying the root addresses when something changes, but keep the=20 > addresses and change the routing. > I am not following this at all. I both IPv4 and IPv6 the root-servers use only a single address.... We need a block of some sort of size to get that that address. Most of=20= the root-servers have been there so long that the address they use is=20 in a /16 block or larger. That /16 might include a lot more than=20 root-servers.... The root-servers addresses of today are no more hardcoded than before.=20= Root-servers do change addresses, although very seldom. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP4sD8qarNKXTPFCVEQK/WgCg78FY/DHyHwwwX4XZa0/24F7OLesAnimk Uz1RccHBoRcldtAoVE4Mqkpc =3D7mmq -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Oct 14 05:47:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01667 for ; Tue, 14 Oct 2003 05:47:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9Lhw-0005tA-1V for multi6-data@psg.com; Tue, 14 Oct 2003 09:43:12 +0000 Received: from [193.247.235.145] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9Lhm-0005s2-CD for multi6@ops.ietf.org; Tue, 14 Oct 2003 09:43:02 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h9E9gswr002443; Tue, 14 Oct 2003 11:42:54 +0200 (CEST) Date: Mon, 13 Oct 2003 21:54:40 +0200 Subject: Re: regionalized addresses, RIRs, and table size Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: "Joseph T. Klein" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <154C95D3-FDB7-11D7-A99B-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > IMHO - The concept of geographic based, or regionalized addresses > recently mentioned seems to merit some review in light of recent > other discussions. > > Possible positive impacts of geographic based IPv6 addresses are: > > * Ability to have smaller allocations within a region without > bloating the global rout table. > > * It compliments regional peering. > > * It tends to aggregate globally. > > Negative > > * Impact of networks without extra regional topologies You forgot "does not fit current topology". This has been discussed here before. I still think this is a larger problem that people assume. > All the multi-homed proposals seem a lot more of a problem > than geographic based address allocation. Why not apply > the analog of Occam's Razor to this problem. If geographic > allocations provide the simple solution, why not reevaluate? There is more to aggregation than just routing table growth. Currently this is also to a large extent the expression of a providers' routing policy. This is normally an expression of their business plan. There are enough Tier-1/Providers with worldwide coverage in here - opinions? There is more to this than meets the eye. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP4sDBaarNKXTPFCVEQKS9gCePoGJzYfZfdyJgqvi6SrSo3b54JAAoOUb ozjJRWqeG2Sg0s2fZ4tBFsTy =8oc/ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Oct 14 07:23:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04005 for ; Tue, 14 Oct 2003 07:23:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9NC2-000BsM-So for multi6-data@psg.com; Tue, 14 Oct 2003 11:18:22 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9NBq-000BrT-GL for multi6@ops.ietf.org; Tue, 14 Oct 2003 11:18:10 +0000 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9EBHTed068423; Tue, 14 Oct 2003 13:17:30 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 14 Oct 2003 13:17:27 +0200 Subject: Re: RIR bashing, was: Routing table size? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On maandag, okt 13, 2003, at 21:58 Europe/Amsterdam, Kurt Erik Lindqvist wrote: >> It's a shame really that people as a rule still don't get it. In the >> old days, the root servers had an address, and we used the named.root >> file (wasn't it called something else back then or am I confused with >> named.boot?) to find them. But we're doing so many routing tricks with >> these addresses now that it makes much more sense to group all the >> address blocks for all the roots together in a special range. Bonus: >> we get to hardcode the root addresses now too, as we're now no longer >> modifying the root addresses when something changes, but keep the >> addresses and change the routing. > am not following this at all. > I both IPv4 and IPv6 the root-servers use only a single address.... > We need a block of some sort of size to get that that address. Most of > the root-servers have been there so long that the address they use is > in a /16 block or larger. Actually I think many of them use /23s. (I was going to write "in IPv4" but then it would seem there are actually root servers in IPv6, but we're still waiting for those.) > The root-servers addresses of today are no more hardcoded than before. > Root-servers do change addresses, although very seldom. You are describing today. I'm interested in doing things differently tomorrow. It makes more sense to make the root addresses fixed and move the address to the server, rather than take whatever address the server happens to have and then publish it in the list of root server addresses. See my next message on the IPv6 wg mailinglist, btw. Iljitsch From owner-multi6@ops.ietf.org Tue Oct 14 17:07:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02568 for ; Tue, 14 Oct 2003 17:07:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9WKQ-0009qN-83 for multi6-data@psg.com; Tue, 14 Oct 2003 21:03:38 +0000 Received: from [195.43.225.73] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9WK7-0009oP-8x for multi6@ops.ietf.org; Tue, 14 Oct 2003 21:03:19 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h9EL3Awr002758; Tue, 14 Oct 2003 23:03:11 +0200 (CEST) Date: Tue, 14 Oct 2003 18:04:03 +0200 Subject: Re: Bash IETF, not RIRs Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Iljitsch van Beijnum" , To: From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <07C00E10-FE60-11D7-8B4F-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Disagree. A good policy would be making the best of the situation >> we're >> in today. The current RIR IPv6 allocation policy doesn't do that as it >> allows for a routing table of 520 million /32 entries, which is more >> than what we can realistically expect routers to handle in the future. > > I don't understand what you are suggesting, could you be more explicit > about > what do you consider that the IPv6 allocation policy should be? > > (Sorry if this is OT, perhaps we could move the thread to globalv6, > chairs?) Well, the discussion that the RIRs have come up with a faulty policy should. As Ray pointed out, the RIRs crates no policy. It's created on globalv6 and should go there. Mostly as feedback to the people discussing the policy. As for the routing table size discussion, I think that is ok. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP4weeKarNKXTPFCVEQLsqwCfYN38zWjRhQdHW51QB0JuiKqpEAUAoMfi ERveu7aTK0NtdEMUiMx+rbQt =qNob -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Oct 15 02:25:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08110 for ; Wed, 15 Oct 2003 02:25:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9f0P-000ELL-F4 for multi6-data@psg.com; Wed, 15 Oct 2003 06:19:33 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9f0H-000EKv-SD for multi6@ops.ietf.org; Wed, 15 Oct 2003 06:19:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9F6JDX15820; Wed, 15 Oct 2003 09:19:13 +0300 Date: Wed, 15 Oct 2003 09:19:12 +0300 (EEST) From: Pekka Savola To: Kurt Erik Lindqvist cc: mbagnulo@ing.uc3m.es, Iljitsch van Beijnum , Subject: Re: Bash IETF, not RIRs In-Reply-To: <07C00E10-FE60-11D7-8B4F-000A9598A184@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 14 Oct 2003, Kurt Erik Lindqvist wrote: > Well, the discussion that the RIRs have come up with a faulty policy > should. As Ray pointed out, the RIRs crates no policy. It's created on > globalv6 and should go there. Mostly as feedback to the people > discussing the policy. As for the routing table size discussion, I > think that is ok. Well, as a matter of fact, many RIRs *do* create their own ad-hoc additional policies (e.g., special PI allocations to "critical infrastructure"), with little regard to globalv6, so this view is not entirely accurate. For "high-level" policy discussions, globalv6 is probably the best place to have them. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Oct 15 02:38:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16466 for ; Wed, 15 Oct 2003 02:38:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9fHL-000FRr-KU for multi6-data@psg.com; Wed, 15 Oct 2003 06:37:03 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9fHG-000FRO-37 for multi6@ops.ietf.org; Wed, 15 Oct 2003 06:36:58 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h9F6amwr002921; Wed, 15 Oct 2003 08:36:49 +0200 (CEST) Date: Wed, 15 Oct 2003 08:36:45 +0200 Subject: Re: Bash IETF, not RIRs Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: mbagnulo@ing.uc3m.es, Iljitsch van Beijnum , To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On onsdag, okt 15, 2003, at 08:19 Europe/Stockholm, Pekka Savola wrote: > On Tue, 14 Oct 2003, Kurt Erik Lindqvist wrote: >> Well, the discussion that the RIRs have come up with a faulty policy >> should. As Ray pointed out, the RIRs crates no policy. It's created on >> globalv6 and should go there. Mostly as feedback to the people >> discussing the policy. As for the routing table size discussion, I >> think that is ok. > > Well, as a matter of fact, many RIRs *do* create their own ad-hoc > additional policies (e.g., special PI allocations to "critical > infrastructure"), with little regard to globalv6, so this view is not > entirely accurate. > > For "high-level" policy discussions, globalv6 is probably the best > place > to have them. > Even those policies are not created by the RIRs. By the RIR community perhaps, but not by RIRs. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP4zq/6arNKXTPFCVEQKUDwCg4dS8RSgYo6F7nB1BWC6lbNF6rIoAn0BS mBsGtVn7UUiiA4+tkmuhGd26 =o20X -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Oct 15 11:45:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05468 for ; Wed, 15 Oct 2003 11:45:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9njZ-000Ny8-0k for multi6-data@psg.com; Wed, 15 Oct 2003 15:38:45 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A9njL-000NwQ-BT for multi6@ops.ietf.org; Wed, 15 Oct 2003 15:38:31 +0000 Received: (qmail 42563 invoked from network); 15 Oct 2003 15:37:30 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 15 Oct 2003 15:37:30 -0000 Message-ID: <3F8D6A2F.10301@necom830.hpcl.titech.ac.jp> Date: Thu, 16 Oct 2003 00:39:27 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Juan Rodriguez Hervella CC: Pekka Savola , Jeroen Massar , "'Iljitsch van Beijnum'" , multi6@ops.ietf.org Subject: Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] References: <3F8A6DDA.9050005@necom830.hpcl.titech.ac.jp> <200310131155.24334.jrh@it.uc3m.es> In-Reply-To: <200310131155.24334.jrh@it.uc3m.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juan Rodriguez Hervella; >>>It's possible to remove the default route for the other ISP if it's >>>broken, or to add more specifics to point to the working ISP if >>>necessary. >> >>Exactly. And the easiest way to do so is to have full route. > > > Hello Ohta :) Hello. > Now I see your point. I think it is the easiest way because > BGP takes care of broken paths automatically. Routing protocols are the protocls to automatically care (lack of) connectivity. > On the other > hand, there are other possibilites which doesn't imply the need > of full routing. E. g, you could check connectivity with your upstream > provider and realise when that is broken to divert traffic to the > other exit router.... What end users CAN NOT accept is complex configuration. A proposal to force end users some action is NO acceptable. With BGP configuration effort of an end user is variable and, if most end users can just use AS-path-len, it can be a default of most routers. Or, some end users may change weight on length of AS-path depending on its incoming interface. Very few will want more advanced control >>If you are not convinced, here is a reality check. >> >>How many of multihomed (non-transit) entities today are using the >>default-only approach? > Good point, It is phychologically unacceptable for operator of a multhomed site that paid connection to some ISP will NEVER be used. > though I don't think the IPv4-way of doing multihomed things > should be the example to follow for IPv6-multihomed sites... which is what RIRs are doing. > Have fun ! > > From owner-multi6@ops.ietf.org Wed Oct 15 13:42:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12501 for ; Wed, 15 Oct 2003 13:42:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9pbI-00076P-QP for multi6-data@psg.com; Wed, 15 Oct 2003 17:38:20 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9pb3-00074v-F5 for multi6@ops.ietf.org; Wed, 15 Oct 2003 17:38:05 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id AF17043504; Wed, 15 Oct 2003 19:38:04 +0200 (CEST) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp01.uc3m.es (Postfix) with ESMTP id 9925199EDC; Wed, 15 Oct 2003 19:37:58 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: masataka ohta , Pekka Savola Subject: Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] Date: Wed, 15 Oct 2003 19:37:55 +0200 User-Agent: KMail/1.5 Cc: multi6@ops.ietf.org References: <200310131155.24334.jrh@it.uc3m.es> <3F8D6A2F.10301@necom830.hpcl.titech.ac.jp> In-Reply-To: <3F8D6A2F.10301@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310151937.56876.jrh@it.uc3m.es> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 15 October 2003 17:39, masataka ohta wrote: [snipped] > > On the other > > hand, there are other possibilites which doesn't imply the need > > of full routing. E. g, you could check connectivity with your upstream > > provider and realise when that is broken to divert traffic to the > > other exit router.... > > What end users CAN NOT accept is complex configuration. The idea might be as complex as you want to, as long as the implementation makes it easy for end-users. I'm just giving ideas. You can think of it like this: mh-router-shell (config)> ipv6 multihomed up Do you think that's difficult for end-users ? > > A proposal to force end users some action is NO acceptable. > So it should be better to let the end-user deal with the full IPv6 routing table, I think he/she will have a lot of fun seeing a lot of prefixes on the screen when he/she can not reach some host. This is just a funny comment, cause I totally agree with you on this point. > With BGP configuration effort of an end user is variable and, > if most end users can just use AS-path-len, it can be a default > of most routers. As Pekka told in a previous mail on this thread, I think that making a BGP solution for SOHO users seems a bit overkilled. Therefore, I would like to see other possible choices. We should also deploy other alternatives, so that end users could get what they think best fits them. Besides, I would like to see what requirements do you need to build up your solution. Have you come up with some of them ? I think that one of the problems (problems = requirements for end-users) of your solution is that you will have to have ASNs for every multihomed-user. And I guess this is only the beginning. I can not comment without further info. Will you make a requirements-draft so we can start making some comments on it ? > >>If you are not convinced, here is a reality check. > >> > >>How many of multihomed (non-transit) entities today are using the > >>default-only approach? > > > > Good point, > > It is phychologically unacceptable for operator of a multhomed > site that paid connection to some ISP will NEVER be used. "Money for nothing" is not a good deal, that's clear. Just I don't understand why you say "it will NEVER be used". It's our duty to develop mechanisms in a proper way so things get to be used, is not it ? > > though I don't think the IPv4-way of doing multihomed things > > should be the example to follow for IPv6-multihomed sites... > > which is what RIRs are doing. Omg, I'm at least I'm on my last comment.... *wink* I dunno if that's already been said, what should the RIRs be doing ? -- JFRH From owner-multi6@ops.ietf.org Wed Oct 15 18:35:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28097 for ; Wed, 15 Oct 2003 18:35:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9uBD-0003t8-NC for multi6-data@psg.com; Wed, 15 Oct 2003 22:31:43 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1A9uB7-0003sZ-LG for multi6@ops.ietf.org; Wed, 15 Oct 2003 22:31:37 +0000 Received: (qmail 44409 invoked from network); 15 Oct 2003 22:30:41 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 15 Oct 2003 22:30:41 -0000 Message-ID: <3F8DCB01.4030500@necom830.hpcl.titech.ac.jp> Date: Thu, 16 Oct 2003 07:32:33 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Juan Rodriguez Hervella CC: Pekka Savola , multi6@ops.ietf.org Subject: Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] References: <200310131155.24334.jrh@it.uc3m.es> <3F8D6A2F.10301@necom830.hpcl.titech.ac.jp> <200310151937.56876.jrh@it.uc3m.es> In-Reply-To: <200310151937.56876.jrh@it.uc3m.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juan Rodriguez Hervella; >>What end users CAN NOT accept is complex configuration. >>A proposal to force end users some action is NO acceptable. > So it should be better to let the end-user deal with the full IPv6 > routing table, I think he/she will have a lot of fun seeing a lot > of prefixes on the screen when he/she can not reach some host. > This is just a funny comment, cause I totally agree with you on this > point. That is Pekka> It's possible to remove the default route for the other ISP if it's Pekka> broken, or to add more specifics to point to the working ISP if Pekka> necessary. can not be an option for end users. >>With BGP configuration effort of an end user is variable and, >>if most end users can just use AS-path-len, it can be a default >>of most routers. > > > As Pekka told in a previous mail on this thread, I think > that making a BGP solution for SOHO users seems > a bit overkilled. Pekka eventually said, don't rely on routing protocols and use static routing, which is the overkill. Non-BGP solution for SOHO users is the overkill. End users can swallow full routing table, if the size is reasonable and inexpensive routers can accept by default. Your example; > mh-router-shell (config)> ipv6 multihomed up is unnecessarily complex. That is, router comfiguration should be same, regardless of whether you are multihomed or not and the factory default should work in all cases. > Besides, I would like to see what requirements do you need > to build up your solution. Have you come up with some of them ? I already suggested one: > > With BGP configuration effort of an end user is variable and, > > if most end users can just use AS-path-len, it can be a default > > of most routers. > I think that one of the problems (problems = requirements for end-users) > of your solution is that you will have to have ASNs for every multihomed-user. > And I guess this is only the beginning. Not at all. As the end users do not offer transit, they don't really have to have ASNs. The end users accept all the route and generate none. So, we can modify BGP. Or, keep BGP as is and have a psuedo ASN shared by all the end users. BGP daemons on border routers of ISPs should filter out any information from the end users that the psuedo ASN won't be visible. > I can not comment without further info. Will you make a requirements-draft > so we can start making some comments on it ? The requirement is to make routing table reasonably small. Have you read: draft-ohta-multihomed-isps-00.txt >>>>How many of multihomed (non-transit) entities today are using the >>>>default-only approach? >>> >>>Good point, >> >>It is phychologically unacceptable for operator of a multhomed >>site that paid connection to some ISP will NEVER be used. > "Money for nothing" is not a good deal, that's clear. > > Just I don't understand why you say "it will NEVER be used". > It's our duty to develop mechanisms in a proper way so things get to > be used, is not it ? Oops, I mean "NEVER unless the default ISP is completly down". I won't request (outgoing) load be fully distributed over all the external links. But, if you are triply homed, and if the third link is not used for outgoing traffic unless the first and the second ISPs are down, it is not acceptable. >>>though I don't think the IPv4-way of doing multihomed things >>>should be the example to follow for IPv6-multihomed sites... >> >>which is what RIRs are doing. > > > Omg, I'm at least I'm on my last comment.... *wink* > > I dunno if that's already been said, what should the RIRs be doing ? We can't expect much on RIRs for protocol development. Masataka Ohta From owner-multi6@ops.ietf.org Thu Oct 16 04:31:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24688 for ; Thu, 16 Oct 2003 04:31:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AA3R3-0007cH-Em for multi6-data@psg.com; Thu, 16 Oct 2003 08:24:41 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AA3Qs-0007bn-Sm for multi6@ops.ietf.org; Thu, 16 Oct 2003 08:24:31 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 324AC431F7; Thu, 16 Oct 2003 10:24:30 +0200 (CEST) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp02.uc3m.es (Postfix) with ESMTP id E766999FF8; Thu, 16 Oct 2003 10:24:29 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: masataka ohta Subject: Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] Date: Thu, 16 Oct 2003 10:24:25 +0200 User-Agent: KMail/1.5 Cc: Pekka Savola , multi6@ops.ietf.org References: <200310151937.56876.jrh@it.uc3m.es> <3F8DCB01.4030500@necom830.hpcl.titech.ac.jp> In-Reply-To: <3F8DCB01.4030500@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310161024.27950.jrh@it.uc3m.es> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Ohta, I'm really enjoying the discussion, so please go on, keep you up and see my comments below ^--^ On Thursday 16 October 2003 00:32, masataka ohta wrote: > Juan Rodriguez Hervella; > > >>What end users CAN NOT accept is complex configuration. > >> > >>A proposal to force end users some action is NO acceptable. > > > > So it should be better to let the end-user deal with the full IPv6 > > routing table, I think he/she will have a lot of fun seeing a lot > > of prefixes on the screen when he/she can not reach some host. > > This is just a funny comment, cause I totally agree with you on this > > point. > > That is > > Pekka> It's possible to remove the default route for the other ISP if it's > Pekka> broken, or to add more specifics to point to the working ISP if > Pekka> necessary. > > can not be an option for end users. I'm sorry to say I can not agree with you. I still don't see why it must be only one solution, specially for SOHO users. If we are able to make an alternative solution which remains bounded to what the end-user can use *now*, I think it will be easier than making the ISPs talk BGP with their SOHO costumers. We've got room for other possibilities, at least in the short term. After reading your draft, do you think it's feasible to keep a small set of TLAs ? This is a requirement for the whole IPv6 policy, which is worse than a requirement for the end-user, IMHO. > End users can swallow full routing table, if the size is > reasonable and inexpensive routers can accept by default. > > Your example; > > > mh-router-shell (config)> ipv6 multihomed up > > is unnecessarily complex. That is, router comfiguration should > be same, regardless of whether you are multihomed or not and > the factory default should work in all cases. What about this example ? I hope you will like it more. **** mh-router booting IPv6 IOS..... **** mh-router booting finished at 2020/10/16. (console)> PS: If this resembles cisco, it's just a matter of chance. Cheers -- JFRH From owner-multi6@ops.ietf.org Thu Oct 16 10:06:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03846 for ; Thu, 16 Oct 2003 10:06:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AA8ji-000OJh-Uv for multi6-data@psg.com; Thu, 16 Oct 2003 14:04:18 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AA8jY-000OJ7-V9 for multi6@ops.ietf.org; Thu, 16 Oct 2003 14:04:09 +0000 Received: (qmail 47155 invoked from network); 16 Oct 2003 14:03:25 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 16 Oct 2003 14:03:25 -0000 Message-ID: <3F8EA592.3080201@necom830.hpcl.titech.ac.jp> Date: Thu, 16 Oct 2003 23:05:06 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: RIR bashing, was: Routing table size? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit JFRH; > > That is > > > > Pekka> It's possible to remove the default route for the other ISP if it's > > Pekka> broken, or to add more specifics to point to the working ISP if > > Pekka> necessary. > > > > can not be an option for end users. > I'm sorry to say I can not agree with you. I still don't see > why it must be only one solution, specially for SOHO users. I already gave a generic proof: : And, you want to have 2 exit routers, if you want to avoid a single : point of failure. : : Then, you want to have full route in your site to choose the best : exit router for each destination. Routers forward packets based on routing table and nothing else. If you can not rely on routing protocols to automatically generate the table, you MUST configure it by hand, which is not acceptable to end users. > If we are able to make an alternative solution which remains > bounded to what the end-user can use *now*, I think it will > be easier than making the ISPs talk BGP with their SOHO > costumers. We've got room for other possibilities, at least in > the short term. Pekka tried and failed. > After reading your draft, do you think it's feasible > to keep a small set of TLAs ? Yes, of course. > This is a requirement > for the whole IPv6 policy, which is worse than a requirement > for the end-user, IMHO. The absolute requirement is to make the set of TLAs bounded, which is the requirement for the whole IPv6 policy. Otherwise, we should have infinitely many sites with IPv4 style multihoming and disband the mult6 WG. It is an additional minor requirement to make the bound reasonably small. > What about this example ? I hope you will like it more. > > **** mh-router booting IPv6 IOS..... > **** mh-router booting finished at 2020/10/16. > (console)> I like the following better: **** router booting IPv6 zebra..... **** router booting finished at 2003/10/16. Masataka Ohta From owner-multi6@ops.ietf.org Wed Oct 22 21:44:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12888 for ; Wed, 22 Oct 2003 21:44:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACURU-000OyQ-OX for multi6-data@psg.com; Thu, 23 Oct 2003 01:39:12 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACURM-000Oy2-Qo for multi6@ops.ietf.org; Thu, 23 Oct 2003 01:39:04 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9N1iwf04366 for ; Wed, 22 Oct 2003 18:44:59 -0700 Date: Wed, 22 Oct 2003 18:38:59 -0700 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <14209033153.20031022183859@brandenburg.com> To: multi6@ops.ietf.org Subject: Fwd: I-D ACTION:draft-crocker-mast-analysis-01.txt In-Reply-To: <200310222234.SAA02302@ietf.org> References: <200310222234.SAA02302@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Grist for the mobility/multihoming discussion mill. The new version is a substantial revision, with much of the enhancement coming from Marcelo Bagnulo. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA ===== Forwarded Message ===== From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: Date: Wednesday, October 22, 2003, 3:34:39 PM Subject: I-D ACTION:draft-crocker-mast-analysis-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CHOICES FOR MULTIADDRESSING Author(s) : D. Crocker Filename : draft-crocker-mast-analysis-01.txt Pages : 0 Date : 2003-10-22 An IP Address serves the dual roles as references to a 'place' on the Internet and to a host on the Internet, labeled 'locator' and 'identifier', respectively. Systems that use IP Addresses as identifiers cannot support dynamic changes in the mapping between the identifier and the locator. For a system to use a different IP Address pair, participants must initiate a new exchange. In the case of TCP, this means a new connection. In recent years, there have been efforts to overcome this limitation, through different approaches at different places in the Internet architecture. This paper reviews the basic requirements for support of multiaddressing (mobility and multihoming), and the efforts to support them. Barriers to adoption, administrative overhead, and operational efficiency are of particular concern. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crocker-mast-analysis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-crocker-mast-analysis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-crocker-mast-analysis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ===== End of Forwarded Message ===== From owner-multi6@ops.ietf.org Thu Oct 23 05:51:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10657 for ; Thu, 23 Oct 2003 05:51:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACc3i-0006re-RY for multi6-data@psg.com; Thu, 23 Oct 2003 09:47:10 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACc3Z-0006qp-Rs for multi6@ops.ietf.org; Thu, 23 Oct 2003 09:47:02 +0000 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id A63F41C; Thu, 23 Oct 2003 13:00:13 +0300 (EEST) Message-ID: <3F97A396.5040300@nomadiclab.com> Date: Thu, 23 Oct 2003 12:47:02 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF Discuss , Multi6 WG , Mobile IPv6 WG , Mobile IPv4 WG , IPsec WG Cc: hipsec@honor.trusecure.com, hipsec@honor.trusecure.com Subject: Host Identity Protocol Architecture and BOF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, The Host Identity Protocol, first discussed after the the MALLOC meeting at 43th IETF in Orlando and again at BOFs during the 50th IETF in Minneapolis and 51st in London, is surfacing again. The HIP work has proceeded at the side of the IETF, without any formal organization, to a level where the HIP Architecture document is ready to be published as an Informational RFC. The actual protocol specification is also quite mature, and there there are at least six implementations, four of which have been tested for interoperability. To complete the remaining work on infrastructure so that it would be possible to experiment with HIP on a wide scale, we have requested a BOF for the next IETF in Minneapolis. While the BOF is still pending formal approval from the ADs, it does appear at the preliminary agenda. The architecture specification, draft-moskowitz-hip-arch-05.txt, is on its way to the archives. The plan is to submit it directly to the RFC Editor on Monday, October 27th, following the procedure of RFC2026 Section 4.2.3. It would be very valuable if people would read the draft either before Oct27th or soon afterwards, allowing possible comments to be considered before publishing the document. The comments should be sent either directly to the authors or to the hipsec mailing list. Since it may take some time before the draft appears in the repository, it is currently also available at the following URLs: http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.txt http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.html http://www.tml.hut.fi/~pnr/HIP/draft-moskowitz-hip-arch-05.xml The corresponding protocol specification, draft-moskowitz-hip-08.txt, will be heading to the repository later today. It will also be available at URLs similar to the ones above. An announcement will be sent to the hipsec mailing list. The BOF is currently scheduled for Thursday, Nov 13, at 1300-1500, but as the agenda is still much in flux, it may be moved. The BOF description is available at http://www.ietf.org/ietf/03nov/hipbof.txt At this stage I want to thank the large number of people that have contributed to HIP during these years, allowing it to proceed this far. You know who you are. Without your work it would not have been possible to get even here. HIP has been a community effort, and will continue as such. This announcement was sent to the Multi6, Mobile IPv4, Mobile IPv6, and IPsec WGs, in addition to the IETF Discuss mailing lists. The reason for this is that HIP, if adopted, may have effects on IPsec based security, IP layer mobility, and multi-address multi-homing. The HIP architecture and protocol should be discussed at the hipsec mailing list; see the BOF description for details on how to subscribe. --Pekka Nikander From owner-multi6@ops.ietf.org Thu Oct 23 09:25:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18234 for ; Thu, 23 Oct 2003 09:25:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACfR2-000Nd9-7J for multi6-data@psg.com; Thu, 23 Oct 2003 13:23:28 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACfQv-000Nbw-Vp for multi6@ops.ietf.org; Thu, 23 Oct 2003 13:23:22 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18065; Thu, 23 Oct 2003 09:23:06 -0400 (EDT) Message-Id: <200310231323.JAA18065@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-nordmark-multi6-sim-00.txt Date: Thu, 23 Oct 2003 09:23:06 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Strong Identity Multihoming using 128 bit Identifiers (SIM/CBID128) Author(s) : E. Nordmark Filename : draft-nordmark-multi6-sim-00.txt Pages : 25 Date : 2003-10-22 This document contains a rough outline of a potential solution to IPv6 multihoming in order to stimulate discussion. This proposed solution uses 126 bit identifiers which are hashes of public keys (know as Cryptographically-based Identifiers) which are created in an autonomous fashion by every node. When there is a need to verify whether a new locator should be used with an identifier than a public-key based challenge-response is used. The proposal allows locator rewriting by (border) routers, and ensures that the upper layer protocols can operate unmodified in a multihomed setting using the stable identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nordmark-multi6-sim-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nordmark-multi6-sim-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-nordmark-multi6-sim-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: <2003-10-22183722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nordmark-multi6-sim-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nordmark-multi6-sim-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22183722.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Thu Oct 23 09:26:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18284 for ; Thu, 23 Oct 2003 09:26:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACfTN-000Np6-GA for multi6-data@psg.com; Thu, 23 Oct 2003 13:25:53 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACfTK-000Nom-Gh for multi6@ops.ietf.org; Thu, 23 Oct 2003 13:25:50 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18255; Thu, 23 Oct 2003 09:25:40 -0400 (EDT) Message-Id: <200310231325.JAA18255@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-nordmark-multi6-threats-00.txt Date: Thu, 23 Oct 2003 09:25:40 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Threats relating to IPv6 multihoming solutions Author(s) : E. Nordmark, T. Li Filename : draft-nordmark-multi6-threats-00.txt Pages : 16 Date : 2003-10-22 This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure than the current Internet, without studying any proposed solution but instead looking at threats that are inherent in the problem itself. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nordmark-multi6-threats-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-nordmark-multi6-threats-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: <2003-10-22183756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nordmark-multi6-threats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nordmark-multi6-threats-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22183756.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Thu Oct 23 11:39:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00162 for ; Thu, 23 Oct 2003 11:39:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AChWL-000AbF-C6 for multi6-data@psg.com; Thu, 23 Oct 2003 15:37:05 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AChWI-000AaZ-AN for multi6@ops.ietf.org; Thu, 23 Oct 2003 15:37:02 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29899; Thu, 23 Oct 2003 11:36:51 -0400 (EDT) Message-Id: <200310231536.LAA29899@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-nordmark-multi6-noid-00.txt Date: Thu, 23 Oct 2003 11:36:50 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multihoming without IP Identifiers Author(s) : E. Nordmark Filename : draft-nordmark-multi6-noid-00.txt Pages : 23 Date : 2003-10-23 This document outlines a potential solution to IPv6 multihoming in order to stimulate discussion. This proposed solution relies on verification using the existing DNS to prevent redirection attacks, while allowing locator rewriting by (border) routers, with no per-packet overhead. The solution does not introduce a A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nordmark-multi6-noid-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nordmark-multi6-noid-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-nordmark-multi6-noid-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: <2003-10-23113013.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nordmark-multi6-noid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nordmark-multi6-noid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-23113013.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Sat Oct 25 13:47:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10593 for ; Sat, 25 Oct 2003 13:47:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADSTe-000Buj-HH for multi6-data@psg.com; Sat, 25 Oct 2003 17:45:26 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADSTZ-000Bu8-IA for multi6@ops.ietf.org; Sat, 25 Oct 2003 17:45:21 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id CBD574329C; Sat, 25 Oct 2003 19:45:20 +0200 (CEST) Received: from lolo (vpn-252-77.uc3m.es [163.117.252.77]) by smtp01.uc3m.es (Postfix) with SMTP id E5AD299F0E; Sat, 25 Oct 2003 19:45:18 +0200 (CEST) Reply-To: From: "marcelo bagnulo" To: Cc: Subject: about draft-nordmark-multi6-noid-00 Date: Sat, 25 Oct 2003 19:39:49 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Erik, After an initial reading of the noid draft, i have a couple of questions: - Are you assuming that the multi-homed site runs bgp with each of its direct providers and that it obtains a full bgp feed from each of them? - I understand that ingress filtering compatibility is guaranteed by source address rewriting, is that ok? if so, how do handle ingress filtering issues when sending initial packets whose source address cannot be rewritten? (rewrite ok bit not set) Thanks, marcelo From owner-multi6@ops.ietf.org Sat Oct 25 17:23:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16147 for ; Sat, 25 Oct 2003 17:23:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADVqH-000LDz-BV for multi6-data@psg.com; Sat, 25 Oct 2003 21:21:01 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADVp6-000LB8-Pf for multi6@ops.ietf.org; Sat, 25 Oct 2003 21:19:48 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9PLJiUP028362; Sat, 25 Oct 2003 14:19:44 -0700 (PDT) Received: from lillen (vpn-129-156-96-38.EMEA.Sun.COM [129.156.96.38]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9PLJgS25937; Sat, 25 Oct 2003 23:19:42 +0200 (MEST) Date: Sat, 25 Oct 2003 23:19:32 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: about draft-nordmark-multi6-noid-00 To: mbagnulo@ing.uc3m.es Cc: Erik.Nordmark@sun.com, multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > - Are you assuming that the multi-homed site runs bgp with each of its > direct providers and that it obtains a full bgp feed from each of them? Not required. You need routing to work for all of the sites locators. And for border router rewriting of the source locator to be a useful way to detect the working path the site's border routers need to have enough information to tell which outbound path to use. Depending on the failures you are concerned about this could be as simple as the border routers being able to tell whether the link to the ISP is up or down, or it could depend on the site receiving each ISPs routing table to see which prefixes appear to be reachable over which ISP/link. I don't think even in the latter case it is necessary to run BGP; if the ISP could redistribute a its view of reachable prefixes using a separate instance of an IGP running across the border that should suffice. (Not that I know if configuring that is much simpler than configuring BGP). But there is no need for the site to advertise anything to its ISPs; each ISP only need to know which prefix it has delegated to the site. > - I understand that ingress filtering compatibility is guaranteed by source > address rewriting, is that ok? if so, how do handle ingress filtering issues > when sending initial packets whose source address cannot be rewritten? > (rewrite ok bit not set) I don't think ingress filtering can be made strictly better any time soon even if we adopt some multihoming proposal; if an attacker would want to exploit holes in IPv6 ingress filtering the attacker could just use non-multihoming packets (e.g., TCP over IPv6 as currently defined). Having said that, if the multihoming protocol performs explicit initiator-driven state creation (draft-nordmark-multi6-sim-00.txt is an example) instead of having a data packet cause responder state creation actions as in noid, then one can make the state creation work with "rewrite ok" enabled. Erik From owner-multi6@ops.ietf.org Sat Oct 25 18:36:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18890 for ; Sat, 25 Oct 2003 18:36:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADWzk-000Ns7-4H for multi6-data@psg.com; Sat, 25 Oct 2003 22:34:52 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADWze-000Nrr-Ju for multi6@ops.ietf.org; Sat, 25 Oct 2003 22:34:46 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 47-md50000000055.tmp for ; Sun, 26 Oct 2003 00:38:40 +0200 Message-ID: <148401c39b48$7e49eb30$9402a8c0@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: draft-nordmark-multi6-sim-00.txt Date: Sun, 26 Oct 2003 00:36:50 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Sun, 26 Oct 2003 00:38:40 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: multi6@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Regarding your draft draft-nordmark-multi6-sim-00.txt, I'm interested to know if you are considered the implications of using the next header field ?. Let me explain. When we met several times in the Atlanta IETF for the "multi6 rebel's WG", one of the solutions that we have been discussing was the one from Marcelo. The main inconvenient was the lack of support from the vendors to any option that means using next headers to support multi6 solutions. In fact I believe you were on a couple of the 7-8 meetings that we had, right ? This question is not only for you, but also for the router manufacturers that have already implemented IPv6 support in hardware (most of them actually !). I'm sure they are on this mailing list ... I understand that this can be implemented in software, as most probably, most of the multihoming applications will not be "performance critical" to create a constrain with the current generations of IPv6 hardware implementations. In fact this is a general problem for the usage of next header in the case of routers ... but this is probably a discussion to be done in the IPv6 WG. This question is somehow valid also for the draft-nordmark-multi6-noid-00.txt. Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-multi6@ops.ietf.org Sun Oct 26 06:19:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14888 for ; Sun, 26 Oct 2003 06:19:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADiuF-000Oa1-Nq for multi6-data@psg.com; Sun, 26 Oct 2003 11:17:59 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADiuA-000OZk-Ci for multi6@ops.ietf.org; Sun, 26 Oct 2003 11:17:54 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 93AC343210; Sun, 26 Oct 2003 12:17:53 +0100 (CET) Received: from lolo (vpn-252-68.uc3m.es [163.117.252.68]) by smtp01.uc3m.es (Postfix) with SMTP id 1418299F15; Sun, 26 Oct 2003 12:17:48 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: Subject: RE: about draft-nordmark-multi6-noid-00 Date: Sun, 26 Oct 2003 12:12:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Let's consider the following scenario. Let's suppose that all ISPs are performing ingress filtering Also that hosts inside mh sites have assigned one prefix per provider +----+ ----|ISPA|_ +----+ / +----+ \_+------+ _|ISPC|_ +----+ | |_/ +----+ \__+----+ | mh1| _| | _| mh2| +----+ +----+_/ | |_ / +----+ \____|ISPB| +------+ \_+----+_/ +----+ |ISPD| +----+ There are two different situations to be considered when addressing locator reachability issues: initial contact and preservation of the established communications. i.) Initial contact i.i) Initiator's perspective i.i.i) No failure has occurred Suppose that mh1 initiates a communication with mh2, so mh1 selects PA:mh1 as initial source address i.e. initial locator and AID1, and also selects PC:mh2 as destination address and AID2. The initial packet must be sent with the "rewrite ok" bit not set. Suppose now that the internal routing of the site mh1 is such that packets sent to PC:: are forwarded through ISPB. This means that the packet generated by mh1 described above will be discarded by ingress filtering in ISPB because its source address is incompatible and cannot not be rewritten. The question is then, how do you deal with this case? (a tunnel between exit routers, so that the packet is forwarded through the appropriate isp, an icmp back to the initiator?) i.i.ii) A failure has occurred in the link between ISPB and its upstream provider. Suppose now that the packet generated by mh1 has PB:mh1 as source address and PC:mh2 as destination address. Now, since the internal routing system has information about prefix reachability through the different ISPs (as you explained, mh1 obtains such information through some routing protocol), the internal routing system knows that it has to forward the packet through ISPA, since there is no route available through ISPB. However, the actual packet has PB:mh1 as source address, making the packet incompatible with ingress filtering. The packet then will be dropped. Note that retrying from the application running in mh1 with alternative address is not good since the problem is not related to the destination address but it is related to the source address. So, how do you address this issue? (a new ICMP message back to the initiator host?) i.i.iii) A failure occurred in the link between ISPC and mh2 mh1 sends a packet to destination address PC:mh2 and any of the source addresses PC:mh2 is not reachable and this is not visible by the routing system. Since it is the initial packet, no feedback from the source address rewriting mechanism can be obtained. I guess the only option here is to wait a timeout and let the application at the initiator to retry. My point is that the routing system will not be able to deal with all the failure scenarios. i.ii) Target perspective Question: the first reply that the target sends back to the initiator, is the "rewrite ok" bit set or not? ii) Preserving established communications Suppose that there is communication established between mh1 and mh2. Suppose that all the locators are working and that all of them were verified so they acceptable to be used as valid locators in the communication. Currently the communication is using PA:mh1 and PC:mh2 as locators. Suddenly a failure in the link between ISPA and its upstream provider occurs. The idea then is that ISPA detects the situation and then it announces the event to mh1. The internal routing system reconverges and packets are no longer routed through ISPA but they are routed through ISPB. Since the "rewrite ok" would be set at this moment of the communication, then packets that are originated by mh1 with PA:mh1 as source address are rewritten by the exit router so that PB:mh1 is included as source address. Now mh2 learns that it has to use PB:mh1 as destination address because this is the address contained in the packets that it is receiving. Is that ok? Now my question is how long does this mechanism takes to react? i.e. the response time. In order to preserve established communications, the interruption shouldn't be too long. The problem here is that intradomain routing is pretty slow detecting outages. Suppose that ISPA is running BGP with its upstream provider, then if i am correct, the value recommended in the BGP spec to detect an outage between peers is 90 seconds. This means that the interruption in the communication will be longer than 90 seconds. IMHO this is not good enough to preserve established communications. Am i missing something? My point is that the usage of the routing system to determine which locator to use and to preserve established communication is not a good option because: - It is pretty expensive, since you need to inject the reachability of all prefixes from the ISPs to the multi-homed site. This may be ok for medium to big sites, but i am not so sure in the case of a very small site with CATV and ADSL - Some failures have to be handled by the host itself, since not all failures are visible from the routing system because of aggregation issues. see point i.i.iii - The main drawback is that the time required by the routing system to detect outages is simply incompatible with preserving established communications. This IMHO is a fundamental incompatibility since it is caused by design choices. I mean, the intra-domain routing system prefers a bit outdated but stable view of the topology rather than an very accurate but unstable view of the topology. this implies that the time required by the routing system to accept a change in the topology will be long, at least longer that what it is acceptable to preserve an established communication. It is then my conclusion that path outage detection and locator selection has to be performed by the end-host themselves and not by the routing system. Sorry if this was too long, but thanks for reading so far. Regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Erik Nordmark > Enviado el: sabado, 25 de octubre de 2003 23:20 > Para: mbagnulo@ing.uc3m.es > CC: Erik.Nordmark@sun.com; multi6@ops.ietf.org > Asunto: Re: about draft-nordmark-multi6-noid-00 > > > > - Are you assuming that the multi-homed site runs bgp with each of its > > direct providers and that it obtains a full bgp feed from each of them? > > Not required. > You need routing to work for all of the sites locators. > And for border router rewriting of the source locator to be a useful way > to detect the working path the site's border routers need to have enough > information to tell which outbound path to use. Depending on the failures > you are concerned about this could be as simple as the border routers > being able to tell whether the link to the ISP is up or down, or it > could depend on the site receiving each ISPs routing table to see which > prefixes appear to be reachable over which ISP/link. > > I don't think even in the latter case it is necessary to run BGP; if the > ISP could redistribute a its view of reachable prefixes using a separate > instance of an IGP running across the border that should suffice. > (Not that I know if configuring that is much simpler than > configuring BGP). > > But there is no need for the site to advertise anything to its ISPs; each > ISP only need to know which prefix it has delegated to the site. > > > - I understand that ingress filtering compatibility is > guaranteed by source > > address rewriting, is that ok? if so, how do handle ingress > filtering issues > > when sending initial packets whose source address cannot be rewritten? > > (rewrite ok bit not set) > > I don't think ingress filtering can be made strictly better any time soon > even if we adopt some multihoming proposal; if an attacker would want to > exploit holes in IPv6 ingress filtering the attacker could just use > non-multihoming packets (e.g., TCP over IPv6 as currently defined). > > Having said that, if the multihoming protocol performs explicit > initiator-driven state creation (draft-nordmark-multi6-sim-00.txt is an > example) instead of having a data packet cause responder state creation > actions as in noid, then one can make the state creation work > with "rewrite > ok" enabled. > > Erik > > > From owner-multi6@ops.ietf.org Sun Oct 26 08:17:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16966 for ; Sun, 26 Oct 2003 08:17:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADkkE-0003UZ-Hp for multi6-data@psg.com; Sun, 26 Oct 2003 13:15:46 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ADkkB-0003UA-HB for multi6@ops.ietf.org; Sun, 26 Oct 2003 13:15:43 +0000 Received: (qmail 89625 invoked from network); 26 Oct 2003 13:17:59 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 26 Oct 2003 13:17:59 -0000 Message-ID: <3F9BC947.90603@necom830.hpcl.titech.ac.jp> Date: Sun, 26 Oct 2003 22:16:55 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: mbagnulo@ing.uc3m.es, multi6@ops.ietf.org Subject: Re: about draft-nordmark-multi6-noid-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik; Red herring. Encapsulation and notification formats are a merely minor issue of multihoming. An essential problem of multiaddress multihoming is when to try alternative addresses, which involves transport/application layers, as the IP layer has no notion of time (save TTL limitation of 255 of IPv4). However, your draft says that > The solution does not > introduce a "stack name" type of identifier, instead it ensures that > all upper layer protocols can operate unmodified in a multihomed > setting while still seeing a stable IPv6 address. it does not address the problem and is, like Dave's MAST, totally meaningless. It should also be noted that changes on host identification (from IP address to something else such as FQDN) means a protocol change at upper (at least at the transport) layers that "all upper layer protocols can operate unmodified" is a false statement. Masataka Ohta PS It is really a wast of bandwidth to read poor proposals not understanding requirements described in my drafts long ago. Do read the drafts. From owner-multi6@ops.ietf.org Sun Oct 26 08:23:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17065 for ; Sun, 26 Oct 2003 08:23:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADkrW-0003se-P5 for multi6-data@psg.com; Sun, 26 Oct 2003 13:23:18 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ADkrS-0003sD-IS for multi6@ops.ietf.org; Sun, 26 Oct 2003 13:23:14 +0000 Received: (qmail 89662 invoked from network); 26 Oct 2003 13:25:30 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 26 Oct 2003 13:25:30 -0000 Message-ID: <3F9BCB0A.5050307@necom830.hpcl.titech.ac.jp> Date: Sun, 26 Oct 2003 22:24:26 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: masataka ohta CC: multi6@ops.ietf.org Subject: Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size? References: <3F8EA592.3080201@necom830.hpcl.titech.ac.jp> In-Reply-To: <3F8EA592.3080201@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sorry, I posted a mail with a wrongly pasted subject of Re: RIR bashing, was: Routing table size? instead of Re: Full routes needed at sites? [Re: RIR bashing, was: Routing table size?] Below is the content of the mail with a proper subject. > JFRH; > > >>>That is >>> >>>Pekka> It's possible to remove the default route for the other ISP if it's >>>Pekka> broken, or to add more specifics to point to the working ISP if >>>Pekka> necessary. >>> >>>can not be an option for end users. > > >>I'm sorry to say I can not agree with you. I still don't see >>why it must be only one solution, specially for SOHO users. > > > I already gave a generic proof: > > : And, you want to have 2 exit routers, if you want to avoid a single > : point of failure. > : > : Then, you want to have full route in your site to choose the best > : exit router for each destination. > > Routers forward packets based on routing table and nothing else. > > If you can not rely on routing protocols to automatically generate > the table, you MUST configure it by hand, which is not acceptable > to end users. > > >>If we are able to make an alternative solution which remains >>bounded to what the end-user can use *now*, I think it will >>be easier than making the ISPs talk BGP with their SOHO >>costumers. We've got room for other possibilities, at least in >>the short term. > > > Pekka tried and failed. > > >>After reading your draft, do you think it's feasible >>to keep a small set of TLAs ? > > > Yes, of course. > > >>This is a requirement >>for the whole IPv6 policy, which is worse than a requirement >>for the end-user, IMHO. > > > The absolute requirement is to make the set of TLAs bounded, which > is the requirement for the whole IPv6 policy. > > Otherwise, we should have infinitely many sites with IPv4 style > multihoming and disband the mult6 WG. > > It is an additional minor requirement to make the bound reasonably > small. > > >>What about this example ? I hope you will like it more. >> >>**** mh-router booting IPv6 IOS..... >>**** mh-router booting finished at 2020/10/16. >>(console)> > > > I like the following better: > > **** router booting IPv6 zebra..... > **** router booting finished at 2003/10/16. > > Masataka Ohta > > > > > > From owner-multi6@ops.ietf.org Sun Oct 26 11:10:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20895 for ; Sun, 26 Oct 2003 11:10:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADnQp-000Ama-Mv for multi6-data@psg.com; Sun, 26 Oct 2003 16:07:55 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADnQm-000AmA-Lz for multi6@ops.ietf.org; Sun, 26 Oct 2003 16:07:53 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9QG7ded065820; Sun, 26 Oct 2003 17:07:41 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <148401c39b48$7e49eb30$9402a8c0@consulintel.es> References: <148401c39b48$7e49eb30$9402a8c0@consulintel.es> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6ACEE302-07CE-11D8-95B0-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: From: Iljitsch van Beijnum Subject: Re: draft-nordmark-multi6-sim-00.txt Date: Sun, 26 Oct 2003 17:06:54 +0100 To: "JORDI PALET MARTINEZ" X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 26 okt 2003, at 0:36, JORDI PALET MARTINEZ wrote: > Regarding your draft draft-nordmark-multi6-sim-00.txt, I'm interested > to know if you are considered the implications of using the > next header field ?. Let me explain. [doing special header processing is expensive in routers with hardware IPv6 support] Yes, this is a good point. I like the idea of using the 6 bit diffserv field for this. This field is modifyable in transit and doesn't impact any processing at the receiving end or in routers that don't support diffserv or type of service processing. There is a slight disadvantage that this field is only 6 bits, but I don't think it's necessary to populate all possible combinations of service levels and yes/no on the rewriting, so in practice this shouldn't have to be a huge problem. From owner-multi6@ops.ietf.org Sun Oct 26 13:59:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24502 for ; Sun, 26 Oct 2003 13:59:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADq4q-000IuI-CJ for multi6-data@psg.com; Sun, 26 Oct 2003 18:57:24 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADq4n-000Iu5-D0 for multi6@ops.ietf.org; Sun, 26 Oct 2003 18:57:21 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9QIvDed067692 for ; Sun, 26 Oct 2003 19:57:13 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v604) Content-Transfer-Encoding: 7bit Message-Id: <39E93830-07E6-11D8-95B0-00039388672E@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: New drafts Date: Sun, 26 Oct 2003 19:57:20 +0100 X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, A couple more drafts are available from my server: cryptoid.txt: (This one didn't make it before the draft cutoff so it won't show up using regular channels before Minneapolis.) Abstract Recently there have been many discussions on separating the locator and identifier functions of IP addresses in order to facilitate scalable multihoming, mobility and address stability. This document describes a way to incorporate a 64 bit identifier in IPv6 addresses without getting in the way of regular IPv6 operation, and the related mechanisms to verify the authenticity of the identifier used by a correspondent. The intent is to foster further discussion within the multi6 design team and elswere, not to provide a complete specification. http://www.muada.com/drafts/cryptoid.txt draft-nordmark-multi6-cb64-00.txt: Abstract This document outlines a potential solution to IPv6 multihoming in order to stimulate discussion. This proposal is a middle ground between the NOID and CB128 proposals. This proposed solution relies on verification the crypto-based identifier properties (using public-key crypto during uncommon operations), while allowing locator rewriting by (border) routers, with no per-packet overhead. The solution does have something which could be viewed as a "stack name" type of identifier, but this isn't exposed to upper layer protocols. Instead it ensures that all upper layer protocols can operate unmodified in a multihomed setting while still seeing a stable IPv6 address, even though the address internally consists of 64-bits worth of subnet locator plus 64-bits of crypto-based identifier. This solution (and this draft) is remarkably similar to draft- nordmark-multi6-noid-00.txt; only issues related to prevention of redirection attacks differ. DISCLAIMER: This work has been discussed in a design team. The design team is still exploring multiple approaches and this is an attempt to capture one such approach on paper. Because of this and due to lack of time to review the document one can not say that this is a product of the DT; errors and confusions should be attributed to the scribe and not to the DT. http://www.muada.com/drafts/draft-nordmark-multi6-cb64-00.txt From owner-multi6@ops.ietf.org Sun Oct 26 17:07:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29538 for ; Sun, 26 Oct 2003 17:07:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADt0q-0002WD-Bw for multi6-data@psg.com; Sun, 26 Oct 2003 22:05:28 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADt0k-0002Vp-Mo for multi6@ops.ietf.org; Sun, 26 Oct 2003 22:05:23 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9QM5Aed069683; Sun, 26 Oct 2003 23:05:10 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7AEC36F1-0800-11D8-95B0-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: "" From: Iljitsch van Beijnum Subject: Re: about draft-nordmark-multi6-noid-00 Date: Sun, 26 Oct 2003 23:05:16 +0100 To: X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 26 okt 2003, at 12:12, marcelo bagnulo wrote: > Suppose that mh1 initiates a communication with mh2, so mh1 selects > PA:mh1 > as initial source address i.e. initial locator and AID1, and also > selects > PC:mh2 as destination address and AID2. > The initial packet must be sent with the "rewrite ok" bit not set. > Suppose now that the internal routing of the site mh1 is such that > packets > sent to PC:: are forwarded through ISPB. This means that the packet > generated by mh1 described above will be discarded by ingress > filtering in > ISPB because its source address is incompatible and cannot not be > rewritten. There are solutions possible that allow rewriting all packets. However, IPv6 as we know it today does not. So we need to solve this problem anyway. I think source address dependent routing makes the most sense here. > the internal routing system > knows that it has to forward the packet through ISPA, since there is no > route available through ISPB. However, the actual packet has PB:mh1 as > source address, making the packet incompatible with ingress filtering. > The > packet then will be dropped. When an ISP fails, it is of course extremely important to have traffic rerouted over the other one. Today, we do this using BGP. We can still do that, but it has the disadvantage that packets for every destination only flow over one ISP. If that ISP is incapable of delivering the packets, there is trouble (although this should be rare if we do BGP rather than just a default). Less important, but still annoying: we have to depend on BGP's limited best path selection capabilities. If we do source address dependent routing on the other hand, a host can utilize both ISP links for the same destination at the same time. Since the destination address in the packet is then no longer relevant, we don't need to run BGP either. Of course now the multihoming system in the host must detect unreachability and initiate a rehoming event when there is a problem in the path over one ISP. > The internal routing system reconverges and packets are no > longer routed through ISPA but they are routed through ISPB. Since the > "rewrite ok" would be set at this moment of the communication, then > packets > that are originated by mh1 with PA:mh1 as source address are rewritten > by > the exit router so that PB:mh1 is included as source address. Now mh2 > learns that it has to use PB:mh1 as destination address because this > is the address contained in the packets that it is receiving. Is that > ok? The source address used by the other side is a good hint when there is no real preference as to which destination address for the other side is preferred. However, each side must be able to jump destination addresses as it is possible that failures occur somewhere along the way where neither side knows that something is wrong so there is no change of source address. Also, there is the case of asymmetric reachability, where there are two links that only work in one direction so packets from A to B must use different addresses than packets from B to A. This can happen with radio links, or a weaker case where there is still symmetric connectivity but the asymmetric connectivity is of a higher bandwidth, is common with one way satellite links. > Now my question is how long does this mechanism takes to react? i.e. > the > response time. In order to preserve established communications, the > interruption shouldn't be too long. We probably want to monitor transport layer events to see whether rehoming is needed. This could be pretty fast in most cases. > The problem here is that intradomain routing is pretty slow detecting > outages. Yes, the worst case is pretty pathetic. Fortunately, the worst case isn't the most common one. > Suppose that ISPA is running BGP > with its upstream provider, then if i am correct, the value > recommended in > the BGP spec to detect an outage between peers is 90 seconds. Correct, but Cisco in their infinite wisdom doubled this to 180 seconds. But you can set this much lower. I used to recommend 15 seconds but some BGP implementations are too braindead to work well with that. Not many problems with 30 seconds, though. Note that in many cases, the sessions will go down much faster because BGP monitors the interface the session runs over. > This means that the interruption in the communication will be longer > than 90 seconds. IMHO this is not good enough to preserve established > communications. Am i missing something? Isn't the TCP timeout 240 seconds? Sessions should survive, not sure if the user is this patient, though. > My point is that the usage of the routing system to determine which > locator > to use and to preserve established communication is not a good option > because: I agree with your points here. > It is then my conclusion that path outage detection and locator > selection > has to be performed by the end-host themselves and not by the routing > system. Indeed. Iljitsch From owner-multi6@ops.ietf.org Sun Oct 26 18:29:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04664 for ; Sun, 26 Oct 2003 18:29:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADuJ8-0005aO-As for multi6-data@psg.com; Sun, 26 Oct 2003 23:28:26 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADuJ6-0005aA-6n for multi6@ops.ietf.org; Sun, 26 Oct 2003 23:28:24 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9QNSFPh012892; Sun, 26 Oct 2003 16:28:16 -0700 (MST) Received: from lillen (vpn-129-156-96-20.EMEA.Sun.COM [129.156.96.20]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9QNSDS09546; Mon, 27 Oct 2003 00:28:13 +0100 (MET) Date: Mon, 27 Oct 2003 00:28:01 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-nordmark-multi6-sim-00.txt To: JORDI PALET MARTINEZ Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <148401c39b48$7e49eb30$9402a8c0@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > When we met several times in the Atlanta IETF for the "multi6 rebel's WG", > one of the solutions that we have been discussing was the one from Marcelo. > > The main inconvenient was the lack of support from the vendors to any option > that means using next headers to support multi6 solutions. > > In fact I believe you were on a couple of the 7-8 meetings that we had, > right ? I don't recall such a discussion so I might not have been in the room. Was the concern based on the routers doing packet classification (based on e.g. port numbers), or something else? Erik From owner-multi6@ops.ietf.org Sun Oct 26 18:46:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05069 for ; Sun, 26 Oct 2003 18:46:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADua4-0006Ig-W9 for multi6-data@psg.com; Sun, 26 Oct 2003 23:45:56 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADua1-0006IS-Rs for multi6@ops.ietf.org; Sun, 26 Oct 2003 23:45:54 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 49-md50000000003.tmp for ; Mon, 27 Oct 2003 00:45:50 +0100 Message-ID: <1f5501c39c1b$97da1dd0$9402a8c0@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: draft-nordmark-multi6-sim-00.txt Date: Mon, 27 Oct 2003 00:48:00 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 27 Oct 2003 00:45:50 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: multi6@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Erik, Yes, I'm sure you participated, but may be not in the complete meeting. The concern was regarding the hardware already in the factory, which took a long time to be designed, not considering extension headers, so if we use them, it should be a firmware process, instead of hardware based, with the consequent lower performance. Regards, Jordi ----- Original Message ----- From: "Erik Nordmark" To: "JORDI PALET MARTINEZ" Cc: Sent: Monday, October 27, 2003 12:28 AM Subject: Re: draft-nordmark-multi6-sim-00.txt > > When we met several times in the Atlanta IETF for the "multi6 rebel's WG", > > one of the solutions that we have been discussing was the one from Marcelo. > > > > The main inconvenient was the lack of support from the vendors to any option > > that means using next headers to support multi6 solutions. > > > > In fact I believe you were on a couple of the 7-8 meetings that we had, > > right ? > > I don't recall such a discussion so I might not have been in the room. > > Was the concern based on the routers doing packet classification (based > on e.g. port numbers), or something else? > > Erik > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-multi6@ops.ietf.org Sun Oct 26 18:59:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05468 for ; Sun, 26 Oct 2003 18:59:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADumn-0006tN-LD for multi6-data@psg.com; Sun, 26 Oct 2003 23:59:05 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADumj-0006t2-Ez for multi6@ops.ietf.org; Sun, 26 Oct 2003 23:59:01 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9QNwv5u003969; Sun, 26 Oct 2003 16:58:58 -0700 (MST) Received: from lillen (vpn-129-156-96-20.EMEA.Sun.COM [129.156.96.20]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9QNwsS14122; Mon, 27 Oct 2003 00:58:54 +0100 (MET) Date: Mon, 27 Oct 2003 00:58:43 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: about draft-nordmark-multi6-noid-00 To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > The initial packet must be sent with the "rewrite ok" bit not set. > Suppose now that the internal routing of the site mh1 is such that packets > sent to PC:: are forwarded through ISPB. This means that the packet > generated by mh1 described above will be discarded by ingress filtering in > ISPB because its source address is incompatible and cannot not be rewritten. > The question is then, how do you deal with this case? (a tunnel between exit > routers, so that the packet is forwarded through the appropriate isp, an > icmp back to the initiator?) One could deal with it any number of ways; same as what has already been discussed by Christian and others. I think the easiest way to *avoid* it is to, instead of the setup being triggered by a data packet as in NOID, have an explicit setup from the sender (as in SIM) (with ULP packet piggybacked on the setup if need be). That way the context creation packets can carry the AIDs in the payload and allow router rewriting of the locators. In this case of NOID one would have to think carefully about the verification issues in such a case (since the AID could be different than the source locator). > i.ii) Target perspective > > Question: the first reply that the target sends back to the initiator, is > the "rewrite ok" bit set or not? For data packets "rewrite ok" can not be set until the context confirm has been sent. The context request (which might be the first packet the target sends back) I think rewrite ok can be set. > ii) Preserving established communications > > Suppose that there is communication established between mh1 and mh2. > Suppose that all the locators are working and that all of them were verified > so they acceptable to be used as valid locators in the communication. > Currently the communication is using PA:mh1 and PC:mh2 as locators. > Suddenly a failure in the link between ISPA and its upstream provider > occurs. > The idea then is that ISPA detects the situation and then it announces the > event to mh1. The internal routing system reconverges and packets are no > longer routed through ISPA but they are routed through ISPB. Since the > "rewrite ok" would be set at this moment of the communication, then packets > that are originated by mh1 with PA:mh1 as source address are rewritten by > the exit router so that PB:mh1 is included as source address. Now mh2 learns > that it has to use PB:mh1 as destination address because this is the address > contained in the packets that it is receiving. Is that ok? ok > Now my question is how long does this mechanism takes to react? i.e. the > response time. There are two factors: how quickly the site border routers detect that a path through an ISP isn't working, and how quickly after that the peer is aware of the change. The first factor is independent of any multihoming solution AFAIK; has to do with stuff like how routes are propagated, routing protocol hello timers, etc. In NOID the second factor depends on the ULP; if the ULP is sending frequently enough the peer will notice quite quickly. If the ULP is patiently sitting waiting for the peer to transmit and not sending anything then the peer never notices anything using this mechanism and instead has to rely on ULP hints about retransmissions. I think this is also rather independent of the multihoming approach; locator rewriting provides an efficient mechanism when it works. The only alternative I know is to have all hosts continuosly "ping" eachother every 10 or so seconds, which is rather inefficient. > The problem here is that intradomain > routing is pretty slow detecting outages. Suppose that ISPA is running BGP > with its upstream provider, then if i am correct, the value recommended in > the BGP spec to detect an outage between peers is 90 seconds. This means > that the interruption in the communication will be longer than 90 seconds. > IMHO this is not good enough to preserve established communications. Am i > missing something? > > My point is that the usage of the routing system to determine which locator > to use and to preserve established communication is not a good option > because: The routing system seems to be good enough for this purpose when sites are not multihomed. Why does multihoming make the routing system behave worse in this respect? > - It is pretty expensive, since you need to inject the reachability of all > prefixes from the ISPs to the multi-homed site. Things are a bit less black and white than that. Depending on what failures you are concerned about you may not need anything but a default route from each ISP. For example, - the link to the ISP failing - just a default handles that - the ISPs peerings with other ISPs fail and the ISP has no alternate path; maybe you assume that the ISP knows how to handle this. If not you might need the ISP to give you the whole routing table. - internal failures in the ISP e.g. cutting off your PoP; perhaps just a default route can handle this if the routers in the PoP base advertising the default on hearing IGP routes from other parts of the ISP's network - the ISP having a broken setup where the BGP routes they offer to you don't get withdrawn even if they've lost all upstream connectivity 3 days ago. Oops - even receiving the full BGP table from then doesn't handle that type of failure. > It is then my conclusion that path outage detection and locator selection > has to be performed by the end-host themselves and not by the routing > system. This means that every host-pair that communicate (have an existing ULP connection/association - btw I don't know how to tell this for associations implemented on top of UDP) have to exchange end-to-end hello packets every 10 seconds or so. If you want to do VoIP you need to do them about every 100 milliseconds. Imagine 100 Billion hosts or so communicating across the Internet doing such e2e hello's. Couldn't that be another form of scaling problem? Erik From owner-multi6@ops.ietf.org Mon Oct 27 03:35:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01199 for ; Mon, 27 Oct 2003 03:35:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE2pG-000P70-P5 for multi6-data@psg.com; Mon, 27 Oct 2003 08:34:10 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE2pD-000P6k-Cx for multi6@ops.ietf.org; Mon, 27 Oct 2003 08:34:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9R8Y4r06590; Mon, 27 Oct 2003 10:34:05 +0200 Date: Mon, 27 Oct 2003 10:34:04 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org cc: fred@cisco.com Subject: I-D ACTION:draft-savola-bcp38-multihoming-update-01.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk FYI, This document has passed the IETF Last Call for Best Current Practice, and has been significantly revised based on the comments. I'll be on the IESG agenda in a couple of weeks. Feedback and comments is still sought (especially, I'd like to reword the title to be more generic, but couldn't figure out anything :-). Sending them off-list would probably be the most appropriate choice. Thanks, Pekka & Fred ---------- Forwarded message ---------- Date: Fri, 24 Oct 2003 10:35:41 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-savola-bcp38-multihoming-update-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Ingress Filtering for Multihomed Networks Author(s) : F. Baker, P. Savola Filename : draft-savola-bcp38-multihoming-update-01.txt Pages : 19 Date : 2003-10-23 RFC 2827, BCP 38, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. However, it causes problems of its own. This document addresses the issues and proposes several possible solutions. This memo updates RFC 2827. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-bcp38-multihoming-update-01.txt From owner-multi6@ops.ietf.org Mon Oct 27 04:39:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03585 for ; Mon, 27 Oct 2003 04:39:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE3pP-0001aq-VY for multi6-data@psg.com; Mon, 27 Oct 2003 09:38:23 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE3pG-0001aP-1j for multi6@ops.ietf.org; Mon, 27 Oct 2003 09:38:14 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9R9c8xA006367; Mon, 27 Oct 2003 01:38:09 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9R9c7S12022; Mon, 27 Oct 2003 10:38:07 +0100 (MET) Date: Mon, 27 Oct 2003 10:37:55 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-nordmark-multi6-sim-00.txt To: JORDI PALET MARTINEZ Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <1f5501c39c1b$97da1dd0$9402a8c0@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > The concern was regarding the hardware already in the factory, which took a > long time to be designed, not considering extension headers, so if we use > them, it should be a firmware process, instead of hardware based, with the > consequent lower performance. Yes, but routers don't look at any extension headers (except the hop-by-hop header) in the forwarding path. Thus the only issues I can think of here is the desire to do QoS classification or (firewall) filtering on ULP header fields. I don't know what classes of routers support such things at wire-speed today. Are there other issues? Erik From owner-multi6@ops.ietf.org Mon Oct 27 04:45:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03757 for ; Mon, 27 Oct 2003 04:45:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE3vp-0001pj-9z for multi6-data@psg.com; Mon, 27 Oct 2003 09:45:01 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE3vl-0001p1-QC for multi6@ops.ietf.org; Mon, 27 Oct 2003 09:44:57 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9R9in5u022240; Mon, 27 Oct 2003 02:44:50 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9R9imS12673; Mon, 27 Oct 2003 10:44:49 +0100 (MET) Date: Mon, 27 Oct 2003 10:44:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: about draft-nordmark-multi6-noid-00 To: masataka ohta Cc: Erik Nordmark , mbagnulo@ing.uc3m.es, multi6@ops.ietf.org In-Reply-To: "Your message with ID" <3F9BC947.90603@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Red herring. > > Encapsulation and notification formats are a merely minor issue > of multihoming. Thanks for sharing, but being able to do this without making security worse than in the current Internet is a challenge. See draft-nordmark-multi6-threats for an initial cut at the threats that we need to be concerned about. You might believe that security is a minor issue that can be added as an afterthought but experience has shown that this is not the most efficient and expedient way to design secure enough protocols. > It should also be noted that changes on host identification > (from IP address to something else such as FQDN) means a > protocol change at upper (at least at the transport) layers > that "all upper layer protocols can operate unmodified" is > a false statement. I honestly disagree. > It is really a wast of bandwidth to read poor proposals not > understanding requirements described in my drafts long ago. The tone of your note in general and this sentence in particular makes me wonder what you want to accomplish in this working group. Can we please have a civil discussion!!! > Do read the drafts. I did. And I understood them I think. But they didn't seem to address key important issues like redirection attacks - saying "cookie-based weak security for a host authorize changes of locators of its peer." is missing all the details of the complexity of providing this without introducing new (DoS) attacks, and is probably too weak since it would make redirection attacks much easier to perform and harder to detect than in today's Internet. Erik From owner-multi6@ops.ietf.org Mon Oct 27 04:53:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04283 for ; Mon, 27 Oct 2003 04:53:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE43b-0002Ke-Vo for multi6-data@psg.com; Mon, 27 Oct 2003 09:53:03 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE43Y-0002KE-UH for multi6@ops.ietf.org; Mon, 27 Oct 2003 09:53:01 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 55-md50000000011.tmp for ; Mon, 27 Oct 2003 10:52:59 +0100 Message-ID: <250401c39c70$68020960$9402a8c0@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: draft-nordmark-multi6-sim-00.txt Date: Mon, 27 Oct 2003 10:55:07 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 27 Oct 2003 10:52:59 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: multi6@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I need to read the document again then ... I understood that the routers rewrite but the information is in the extension header ... Anyway, its a question that probably requires the answers from the router manufacturers, to see if this is viable. Regards, Jordi ----- Original Message ----- From: "Erik Nordmark" To: "JORDI PALET MARTINEZ" Cc: Sent: Monday, October 27, 2003 10:37 AM Subject: Re: draft-nordmark-multi6-sim-00.txt > > The concern was regarding the hardware already in the factory, which took a > > long time to be designed, not considering extension headers, so if we use > > them, it should be a firmware process, instead of hardware based, with the > > consequent lower performance. > > Yes, but routers don't look at any extension headers (except the hop-by-hop > header) in the forwarding path. > > Thus the only issues I can think of here is the desire to do > QoS classification or (firewall) filtering on ULP header fields. > I don't know what classes of routers support such things at wire-speed > today. > Are there other issues? > > Erik > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-multi6@ops.ietf.org Mon Oct 27 06:01:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06295 for ; Mon, 27 Oct 2003 06:01:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE56j-000544-Ss for multi6-data@psg.com; Mon, 27 Oct 2003 11:00:21 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE56g-00053r-Ek for multi6@ops.ietf.org; Mon, 27 Oct 2003 11:00:18 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8A2DD35A; Mon, 27 Oct 2003 12:00:17 +0100 (CET) Received: from lolo (unknown [163.117.139.245]) by smtp03.uc3m.es (Postfix) with SMTP id 737A4355; Mon, 27 Oct 2003 12:00:17 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , Cc: Subject: RV: (ipv6mh) hardware support for extension headers Date: Mon, 27 Oct 2003 11:54:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Erik, Jordi, This is a message where Tony Hain explained why it is difficult to support new extension headers in all packets, This message was sent to ipv6mh list a while ago... Hope this helps to explain Jordi's concerns. Regards, marcelo > -----Mensaje original----- > De: Tony Hain [mailto:alh-ietf@tndh.net] > Enviado el: miércoles, 27 de noviembre de 2002 1:59 > Para: 'marcelo bagnulo'; 'Michel Py'; 'Ole Troan' > CC: 'Jordi Palet Martinez'; 'ipv6mh'; 'Vladimir Ksinant'; 'Yoshifumi > Atarashi'; 'Suzuki Shinsuke'; 'Kazuaki Tsuchiya'; 'Elwyn Daview' > Asunto: RE: (ipv6mh) hardware support for extension headers > > > Marcelo, > > The basic problem is that network operators have been told that the > proper thing to do is filter on the L4 port. This means that all > hardware implementations that are expected to be deployed on a network > boundary have to be able to parse the L4 port. Since everyone has a > different definition of what router class is needed at a boundary, this > effectively means all routers have to support finding the L4 port in > hardware. This is required even though most of the deployed routers > never look at the extension headers or the L4 port. The result is that > any new extension header that will be carried along with the current > common set, will cause packets to drop off the fast path. Yes, border > specific routers could be developed, but the market for them would be so > small, and the extra hardware necessary would be so much greater that > the result would be so expensive that nobody would ever buy them. > > Tony > > > > -----Original Message----- > > From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] > > Sent: Monday, November 25, 2002 1:04 PM > > To: Michel Py; Ole Troan > > Cc: Jordi Palet Martinez; ipv6mh; Vladimir Ksinant; Yoshifumi > > Atarashi; Suzuki Shinsuke; Kazuaki Tsuchiya; Elwyn Daview > > Subject: RE: (ipv6mh) hardware support for extension headers > > > > > > Michel, > > > > if you don´t mind, i would split the question in two: > > > > - How would you rate the changes needed in routers in order > > to forward packets carrying the extesnion header WITHOUT > > PORCESSING it? > > > > - How would you rate the changes needed in routers in order > > to forward packets carrying the extesnion header and also > > process the extension header? > > > > Note that most routers will only forward packets containing > > the extesnion header without processing it. > > > > Thanks, marcelo > > > > > -----Mensaje original----- > > > De: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > > > Enviado el: domingo, 24 de noviembre de 2002 23:48 > > > Para: Ole Troan > > > CC: Marcelo Bagnulo; Jordi Palet Martinez; ipv6mh; Vladimir > > Ksinant; > > > Yoshifumi Atarashi; Suzuki Shinsuke; Kazuaki Tsuchiya; Elwyn Daview > > > Asunto: RE: (ipv6mh) hardware support for extension headers > > > > > > > > > > Ole Troan wrote: > > > > the more serious issue with Marcelo's draft is that > > todays routers > > > > aren't built to send ICMP errors (or forward the packet > > in Marcelo's > > > > case), for every packet to an unknown destination. > > > > > > Dumb question for all router vendors: > > > Assuming that all political hurdles have been cleared, if > > you had to > > > implement (in silicon, for those of who that have hardware-assisted > > > routers) what Marcelo's draft requires, how would you rate > > the work it > > > would take? > > > > > > a) Piece of cake, just needs to be decided and would be in the next > > > version of the chips. > > > b) About the same as any other extension header. > > > c) Much more difficult than other extension headers you > > already have > > > implemented. > > > > > > Thanks > > > Michel. > > > > > > > > > From owner-multi6@ops.ietf.org Mon Oct 27 06:52:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08044 for ; Mon, 27 Oct 2003 06:52:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE5u3-0007nj-69 for multi6-data@psg.com; Mon, 27 Oct 2003 11:51:19 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE5u0-0007nS-Sg for multi6@ops.ietf.org; Mon, 27 Oct 2003 11:51:16 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9RBpBPh022695; Mon, 27 Oct 2003 04:51:12 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9RBpBS29211; Mon, 27 Oct 2003 12:51:11 +0100 (MET) Date: Mon, 27 Oct 2003 12:50:55 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-nordmark-multi6-sim-00.txt To: JORDI PALET MARTINEZ Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <250401c39c70$68020960$9402a8c0@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I understood that the routers rewrite but the information is in the > extension header ... The information that is it ok to rewrite the locators is in the IPv6 nextheader field - a designated value should be allocated for the M6 protocol in SIM to have this semantics (in addition to indentifying to the endnode that the this is a multihoming packet) . The information that gets rewritten is the IPv6 source field. Thus there is no need to parse additional extension headers to do the rewriting. If hop-by-hop options are used the HBH header would need to be looked at to see whether its nextheader value says "rewrite ok". Presumably a routing header could also be placed before the M6 header thus the nextheader field in the routing header would need to be inspected. But other extension headers (destination options, ESP, AH, fragment) are placed after the M6 header. FWIW NOID and CB64 take the same approach except that in order to avoid a shim M6 header in every packet the router need to look for a nextheader value in a range of 8 values to mean "rewrite ok". Erik Erik From owner-multi6@ops.ietf.org Mon Oct 27 07:33:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09637 for ; Mon, 27 Oct 2003 07:33:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE6Wx-000AA8-Kh for multi6-data@psg.com; Mon, 27 Oct 2003 12:31:31 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE6Wt-000A9k-Mn for multi6@ops.ietf.org; Mon, 27 Oct 2003 12:31:27 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B250C128; Mon, 27 Oct 2003 13:31:22 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp03.uc3m.es (Postfix) with SMTP id 2050EE2; Mon, 27 Oct 2003 13:31:19 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: Subject: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Mon, 27 Oct 2003 13:25:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, I will address the issues concerning the preservation of the established session here and i will consider the issues related to ingress filtering is a different thread. > > > > My point is that the usage of the routing system to determine which locator > > to use and to preserve established communication is not a good option > > because: > > The routing system seems to be good enough for this purpose when sites are > not multihomed. Well, i am not sure about this. Current studies of bgp convergence time are talking about up to 15 minutes of BGP convergence when a route is withdrawn. Established communications clearly don't survive this. As i mentioned, bgp outage detection timer is recommended to be set to 90 secs, and as Iljistch mentioned, the default value in some commercial routers is the double of that. Additionally, you have to add to this the time required to reconverge, which can be even higher than that. So, currently available intradomain routing does not always preserve established seesions when an outage occurs. This is ok, since i guess that this was not a requirement imposed to the desing of routing system (i mean the preservation of the established sessions). Now, this is a requirement to the multi-homing solution. Moreover, it is a very difficult requirement. I mean, the goal of all this loc/id separation is the preservation of established communications, since most of the remaining requirements don't need this and could be addressed with alternative (more conventional) mechanisms. So, we are evaluating modifying all the hosts in the Internet to support this feature, and it is ok. The problem is that outage detection will be performed by bgp and it will take 2 minutes. So we have build this loc/id split in all hosts but the resulting solution is not useful to preserve established communications of most apps (since i guess most apps need a better response time than this). I don't know if it is worth it, what do you think? > > > - It is pretty expensive, since you need to inject the > > reachability of all prefixes from the ISPs to the multi-homed site. > > Things are a bit less black and white than that. Depending on what failures > you are concerned about you may not need anything but a default > route from each ISP. For example, > > - the link to the ISP failing - just a default handles that Yes, also RFC3178 supports that and it is much simpler, since it doesn't require the modification of all hosts to support it. > - the ISPs peerings with other ISPs fail and the ISP has no alternate path; > maybe you assume that the ISP knows how to handle this. How would the isp know how to handle this situation? i mean, the ISP has no alternate path, so the only path is through the alternative isp of the multi-homed site. This is the relevenat case, imho, since is the case not covered by rfc3178. So i would say that anyone implementing a solution other than rfc3178 would want to be tolerant to this type of failure. > If not you might need the ISP to give you the whole routing table. Yes, this is it. > - internal failures in the ISP e.g. cutting off your PoP; perhaps just a > default route can handle this if the routers in the PoP base advertising > the default on hearing IGP routes from other parts of the ISP's network > - the ISP having a broken setup where the BGP routes they offer to you > don't get withdrawn even if they've lost all upstream > connectivity 3 days > ago. > Oops - even receiving the full BGP table from then doesn't handle that > type of failure. Right, but end-to end failure detection protect you from it > > > It is then my conclusion that path outage detection and locator selection > > has to be performed by the end-host themselves and not by the routing > > system. > > This means that every host-pair that communicate (have an existing ULP > connection/association - btw I don't know how to tell this for associations > implemented on top of UDP) Well, an option would be to have a cache of host that the node is communicating with, so that it can ping them periodically until the cache expires. The cache lifetime is extended everytime a packet from/to that destiantion flows. > have to exchange end-to-end hello packets every 10 > seconds or so. If you want to do VoIP you need to do them about every 100 > milliseconds. Imagine 100 Billion hosts or so communicating across the Internet > doing such e2e hello's. Couldn't that be another form of scaling problem? > :-) Well, som additional cosndierations about this. First, many existing ULP already exchange this type of messages, TCP ack for instance, so hellos can be piggybacked into this messages. This would require some tuning, though. Another way of considering this point is that hosts already exchange millions of ack. Second, the response time obtained is directly related to the cost. So, i agree that preserving a VoIP requires exchanges every 100ms (even every 20 ms), but this is the cost of preserving this type of communication uninterrupted. You could exchange hellos every 2 seconds, and the communication would be preserved, but an interruption of a couple of seconds will be perceived when an outage occurs. Nothe that the response time of this solution is still a couple of orders of magnitude better than the bgp based solution. Moreover, the exchange frequency can be negotiated by the end-hosts, so that they can establish which performance and which cost they are willing to accept. Finally, the demands of such a solution is in terms of bandwidth, where i guess that improvement is expected and scalability doesn't seems to be so diffcult (as routing table growth, for instance) Regards, marcelo > Erik > > From owner-multi6@ops.ietf.org Mon Oct 27 07:56:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10735 for ; Mon, 27 Oct 2003 07:56:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE6ub-000BQg-Bm for multi6-data@psg.com; Mon, 27 Oct 2003 12:55:57 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE6uV-000BQM-6v for multi6@ops.ietf.org; Mon, 27 Oct 2003 12:55:52 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9RCtW009699; Mon, 27 Oct 2003 14:55:32 +0200 Date: Mon, 27 Oct 2003 14:55:31 +0200 (EET) From: Pekka Savola To: marcelo bagnulo cc: Erik.Nordmark@sun.com, , Subject: Re: RV: (ipv6mh) hardware support for extension headers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT On Mon, 27 Oct 2003, marcelo bagnulo wrote: > This is a message where Tony Hain explained why it is difficult to support > new extension headers in all packets, > This message was sent to ipv6mh list a while ago... > Hope this helps to explain Jordi's concerns. Please check out draft-savola-v6ops-firewalling-02.txt. This should cover this case as well. As identified in the draft, there are a few possible ways forward: - never do any new extension headers - specify that new extension headers must be done in TLV format, making them more easily extensible (AND skippable!) - specify new things as destination or hop-by-hop options instead. HTH > > -----Mensaje original----- > > De: Tony Hain [mailto:alh-ietf@tndh.net] > > Enviado el: miércoles, 27 de noviembre de 2002 1:59 > > Para: 'marcelo bagnulo'; 'Michel Py'; 'Ole Troan' > > CC: 'Jordi Palet Martinez'; 'ipv6mh'; 'Vladimir Ksinant'; 'Yoshifumi > > Atarashi'; 'Suzuki Shinsuke'; 'Kazuaki Tsuchiya'; 'Elwyn Daview' > > Asunto: RE: (ipv6mh) hardware support for extension headers > > > > > > Marcelo, > > > > The basic problem is that network operators have been told that the > > proper thing to do is filter on the L4 port. This means that all > > hardware implementations that are expected to be deployed on a network > > boundary have to be able to parse the L4 port. Since everyone has a > > different definition of what router class is needed at a boundary, this > > effectively means all routers have to support finding the L4 port in > > hardware. This is required even though most of the deployed routers > > never look at the extension headers or the L4 port. The result is that > > any new extension header that will be carried along with the current > > common set, will cause packets to drop off the fast path. Yes, border > > specific routers could be developed, but the market for them would be so > > small, and the extra hardware necessary would be so much greater that > > the result would be so expensive that nobody would ever buy them. > > > > Tony > > > > > > > -----Original Message----- > > > From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] > > > Sent: Monday, November 25, 2002 1:04 PM > > > To: Michel Py; Ole Troan > > > Cc: Jordi Palet Martinez; ipv6mh; Vladimir Ksinant; Yoshifumi > > > Atarashi; Suzuki Shinsuke; Kazuaki Tsuchiya; Elwyn Daview > > > Subject: RE: (ipv6mh) hardware support for extension headers > > > > > > > > > Michel, > > > > > > if you don´t mind, i would split the question in two: > > > > > > - How would you rate the changes needed in routers in order > > > to forward packets carrying the extesnion header WITHOUT > > > PORCESSING it? > > > > > > - How would you rate the changes needed in routers in order > > > to forward packets carrying the extesnion header and also > > > process the extension header? > > > > > > Note that most routers will only forward packets containing > > > the extesnion header without processing it. > > > > > > Thanks, marcelo > > > > > > > -----Mensaje original----- > > > > De: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > > > > Enviado el: domingo, 24 de noviembre de 2002 23:48 > > > > Para: Ole Troan > > > > CC: Marcelo Bagnulo; Jordi Palet Martinez; ipv6mh; Vladimir > > > Ksinant; > > > > Yoshifumi Atarashi; Suzuki Shinsuke; Kazuaki Tsuchiya; Elwyn Daview > > > > Asunto: RE: (ipv6mh) hardware support for extension headers > > > > > > > > > > > > > Ole Troan wrote: > > > > > the more serious issue with Marcelo's draft is that > > > todays routers > > > > > aren't built to send ICMP errors (or forward the packet > > > in Marcelo's > > > > > case), for every packet to an unknown destination. > > > > > > > > Dumb question for all router vendors: > > > > Assuming that all political hurdles have been cleared, if > > > you had to > > > > implement (in silicon, for those of who that have hardware-assisted > > > > routers) what Marcelo's draft requires, how would you rate > > > the work it > > > > would take? > > > > > > > > a) Piece of cake, just needs to be decided and would be in the next > > > > version of the chips. > > > > b) About the same as any other extension header. > > > > c) Much more difficult than other extension headers you > > > already have > > > > implemented. > > > > > > > > Thanks > > > > Michel. > > > > > > > > > > > > > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Oct 27 08:27:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11707 for ; Mon, 27 Oct 2003 08:27:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE7Ol-000D0w-BS for multi6-data@psg.com; Mon, 27 Oct 2003 13:27:07 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE7Oi-000D0e-1U for multi6@ops.ietf.org; Mon, 27 Oct 2003 13:27:04 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9RDR05u000210; Mon, 27 Oct 2003 06:27:01 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9RDQxS08707; Mon, 27 Oct 2003 14:26:59 +0100 (MET) Date: Mon, 27 Oct 2003 14:26:45 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > The routing system seems to be good enough for this purpose when sites are > > not multihomed. > > Well, i am not sure about this. > Current studies of bgp convergence time are talking about up to 15 minutes > of BGP convergence when a route is withdrawn. Established communications > clearly don't survive this. OK, but fixing the BGP convergence time isn't in scope for this WG. My logic is to try to find where multihoming makes things different. The fact that BGP convergence time in the currrent Internet is worse than desired is something that should be addressed independently of multihoming, right? If not, shouldn't multihoming fix other pressing problems like world hunger? > Now, this is a requirement to the multi-homing solution. Moreover, it is a > very difficult requirement. I mean, the goal of all this loc/id separation > is the preservation of established communications, since most of the > remaining requirements don't need this and could be addressed with > alternative (more conventional) mechanisms. I would state the goal differently: taking advantage of the multiple attachments to the Internet to make the availability of the communication better than with a single Internet attachment. Whether the result would be good enough to - make the ftp connection stay alive - make the user wait at the web browser or abandon and try another site (order 10 seconds according to some studies I think) - make VoIP survive without a click in the phone is a different aspect of the goal which we haven't talked much about. > > - the ISPs peerings with other ISPs fail and the ISP has no alternate > path; > > maybe you assume that the ISP knows how to handle this. > > How would the isp know how to handle this situation? i mean, the ISP has no > alternate path, so the only path is through the alternative isp of the > multi-homed site. > This is the relevenat case, imho, since is the case not covered by rfc3178. > So i would say that anyone implementing a solution other than rfc3178 would > want to be tolerant to this type of failure. Actually, in my mind but not in my writing, there are two subcases. 1) the ISP looses one peering and there is no alternate path to reach certain destinations (due to the policy for the other peerings the ISP has) If there are alternatives then the ISP can still reach all destinations hence there is no observable failure. 2) the ISP looses peering(s) so that it can no longer reach any destination The second case can be handled without passing all routes to the site. How common is the first case? It depends on how the ISPs handle their own redundancy. I don't do operations thus I'd be interested in folks with operational experience commenting on the common and likely failures that a site should worry about. What I've heard of are failures due to links being cut between sites and their ISP, backbone links back-hoed (but don't understand what actual impact they had on each ISPs network), and ISPs going bankrupt. > Well, an option would be to have a cache of host that the node is > communicating with, so that it can ping them periodically until the cache > expires. The cache lifetime is extended everytime a packet from/to that > destiantion flows. Yes, but what is the lifetime of the cache entry after the last packet? How can you pick a value without knowing the actual behavior of the (UDP) application? Finally, any simulation data on how many peridical pings would be added to the Internet when everybody implements such a scheme? > Well, som additional cosndierations about this. > First, many existing ULP already exchange this type of messages, TCP ack for > instance, so hellos can be piggybacked into this messages. The TCP ssh connection I've had open for the last 4 days have not exchanged any packets as far as I know. (Well, perhaps there are the keepalive packets every 2 hours or so, but they wouldn't be sufficient to ensure that once I type something there is indeed a rapid response.) And we are not considering a TCP-only solution, are we? My take is that we should make the multihoming solution improve the availability of sites with multiple Internet attachments without requiring or assuming e2e periodic pings to quickly detect failures. Some applications/upper layer protocols might want to use such mechanisms in addition to the rehoming support in the multihoming solution for quicker failures (For instance, SCTP already has such a mechanism; heartbeats.) Thus I'm advocating not assuming that every ULP connection/session/assocatin has hearbeats when solving rehoming since we know of neither the performance implications of this on a large scale, nor the benefits that applications in general will derive from it. Erik From owner-multi6@ops.ietf.org Mon Oct 27 09:52:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17008 for ; Mon, 27 Oct 2003 09:52:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE8hl-000JHI-33 for multi6-data@psg.com; Mon, 27 Oct 2003 14:50:49 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE8hb-000JGR-7M for multi6@ops.ietf.org; Mon, 27 Oct 2003 14:50:39 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 65D6C35D; Mon, 27 Oct 2003 15:50:38 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp03.uc3m.es (Postfix) with SMTP id 44AC235A; Mon, 27 Oct 2003 15:50:38 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Mon, 27 Oct 2003 15:45:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit About the goals of the multi-homing solution: > > > The routing system seems to be good enough for this purpose > > > when sites are not multihomed. > > > > Well, i am not sure about this. > > Current studies of bgp convergence time are talking about up to 15 minutes > > of BGP convergence when a route is withdrawn. Established communications > > clearly don't survive this. > > OK, but fixing the BGP convergence time isn't in scope for this WG. > > My logic is to try to find where multihoming makes things different. > The fact that BGP convergence time in the currrent Internet is worse than > desired is something that should be addressed independently of > multihoming, > right? > > If not, shouldn't multihoming fix other pressing problems like > world hunger? > > > Now, this is a requirement to the multi-homing solution. Moreover, it is a > > very difficult requirement. I mean, the goal of all this loc/id separation > > is the preservation of established communications, since most of the > > remaining requirements don't need this and could be addressed with > > alternative (more conventional) mechanisms. > > I would state the goal differently: taking advantage of the multiple > attachments to the Internet to make the availability of the communication > better than with a single Internet attachment. > The goal as stated in RFC 3582 is that: 3.1.6. Transport-Layer Survivability Multihoming solutions should provide re-homing transparency for transport-layer sessions; i.e., exchange of data between devices on the multihomed site and devices elsewhere on the Internet may proceed with no greater interruption than that associated with the transient packet loss during the re-homing event. New transport-layer sessions should be able to be created following a re-homing event. Transport-layer sessions include those involving transport-layer protocols such as TCP, UDP and SCTP over IP. Applications which communicate over raw IP and other network-layer protocols may also enjoy re-homing transparency. So the question is: do current BGP responses times good enough to achieve this goal? IMHO, the problem is not whether we have to fix bgp or not, since i guess we agree that don't have to fix it (or at least that it is not within the wg scope) I guess that the question is whehter we can base a solution that have to provide transport layer suvivability on the current bgp capabilities. Perhaps the answer is yes and there is no problem, maybe the answer is no and we have to workaround and build a solution that don't use bgp. The other point that you mention is that current non-multi-homed communication already rely on bgp to be preserved through outages and so that letting multi-homed communications rely on bgp for surviving outages should be ok. Well i don't fully agree with this pov. We want to provide a solution that provides transport layer survivability, that is the point of all this. Currently single homed communication probably don't survive outages, even if there is an alternative path, becuase bgp detection and reconvergence time is too long. We are providing a new capability here, that is not available in non multi-homed communications. So the tranport layer suvivability is one of the things that is different in multi-homing, and in order to support this we may need not to base our solution in bgp. > Whether the result would be good enough to > - make the ftp connection stay alive > - make the user wait at the web browser or abandon and try another site > (order 10 seconds according to some studies I think) > - make VoIP survive without a click in the phone > is a different aspect of the goal which we haven't talked much about. > Yes. we should discuss this. I would say that allowing the user to define what he wants would be the best case... I mean, a solution that allows the adaptation of the failure detection to need of the actual established communication, what do you think? I guess that the other relevant question would be what are the expected capabilities in terms of response time for bgp in the IPv6 internet? [...] > Actually, in my mind but not in my writing, there are two subcases. > 1) the ISP looses one peering and there is no alternate path to > reach certain > destinations (due to the policy for the other peerings the ISP has) > If there are alternatives then the ISP can still reach all destinations > hence there is no observable failure. > 2) the ISP looses peering(s) so that it can no longer reach any > destination > I actually think that there is a middle ground situation where things are a bit more complex the following example for instance: +---------+ |Internet | +---------+ / \ outage-> = \ / \ +---------+ +---------+ | ISP1 | | ISP2 | +---------+ +---------+ | | | | _____________| | | | / ______| | | / / | | +---+ +---+ +---------+ |S1 | ... |Sn | | mhsite | +---+ +---+ +---------+ In this case, mhsite can reach all the customers of ISP1 through ISP1 and all the rest through ISP2. I have always considered the general case, where after an outage some destiantions can only be reachable through one of the ISPs and a disjoint set of destiantions can only be reached through the other isp. Do you think we should start considering a simplified scenario? > The second case can be handled without passing all routes to the site. > How common is the first case? > It depends on how the ISPs handle their own redundancy. > > I don't do operations thus I'd be interested in folks with operational > experience commenting on the common and likely failures that a site should > worry about. Yes, i would like that too. What I've heard of are failures due to links being cut between > sites and their ISP, backbone links back-hoed (but don't understand what actual impact > they had on each ISPs network), and ISPs going bankrupt. > > > Well, an option would be to have a cache of host that the node is > > communicating with, so that it can ping them periodically until > the cache > > expires. The cache lifetime is extended everytime a packet from/to that > > destiantion flows. > > Yes, but what is the lifetime of the cache entry after the last packet? > How can you pick a value without knowing the actual behavior of the (UDP) > application? YEs this is complex, perhaps we could do something like an exponential backoff? i guess that i would be more acceptable a delay when trying to transmit after an interuption of a long period than interrupting a communication that it is exchanging packets continiously, but that's just a guess. > Finally, any simulation data on how many peridical pings would be > added to the Internet when everybody implements such a scheme? > No :-) But i do have some simulation about how would the bgp detection mechanism would affect an ongoing voip communication ;-) Considering a sample every 20 msec, that would be 3000 samples lost. > > Well, som additional cosndierations about this. > > First, many existing ULP already exchange this type of > messages, TCP ack for > > instance, so hellos can be piggybacked into this messages. > > The TCP ssh connection I've had open for the last 4 days have not > exchanged > any packets as far as I know. (Well, perhaps there are the > keepalive packets > every 2 hours or so, but they wouldn't be sufficient to ensure that > once I type something there is indeed a rapid response.) > > And we are not considering a TCP-only solution, are we? > > > My take is that we should make the multihoming solution improve the > availability of sites with multiple Internet attachments without > requiring or > assuming e2e periodic pings to quickly detect failures. > Some applications/upper layer protocols might want to use such mechanisms > in addition to the rehoming support in the multihoming solution > for quicker > failures (For instance, SCTP already has such a mechanism; heartbeats.) > Thus I'm advocating not assuming that every ULP > connection/session/assocatin > has hearbeats when solving rehoming since we know of neither the > performance > implications of this on a large scale, nor the benefits that applications > in general will derive from it. > I don't know. My concern is that: All the proposed solutions to preserve established communications require a major update in the installed base, since they require modifications in both nodes involved in a communication. (in brief big cost) Agree? However,if we use bgp to detect outages, the benefit obtained will only be partial, since the failure detection will take a long time in the general case. This basically means that in multiple scenarios, established communications will not be preserved. Agree? Now if this is the cost and this is the benefit i don't know if this solution is interesting. really high cost and reduced benefits. Other arguments are that: A loc/id solution provides a basic capability required to preserve established communication, but the solution doesn't provide all what it is needed. Additional stuff needed, such a failure detection mechanism will be provided by the upper layer. My answer to that is then why don't we just let the upper layer handle all the problem then? I mean, you mention SCTP, well sctp provides heartbeat, allright but it also manages multiple addresses in a connection, so the loc/id solution doesn't provides anything useful to sctp. The same thing could be done with TCP and also with application protocols Another argument is that the loc/is split solution provides an high level solution that can be also used to satisfy other needs, and not only for multi-homing, so it should be adopted not becuase it is great for preserving established communications in multi-homed environments, but because it is architecturally sound. Well, i may agree with this, but in this case a wider view is required to uderstand if such a solution is good for all other requirements imposed, so we shouldn't be doing this in this wg (or only in this wg at least) BTW, if the argument to accept a solution is the last one, this would discard solution without a strong loc/id separation that doesn't provides good response times (noid for instance), right? Regards, marcelo > Erik > > From owner-multi6@ops.ietf.org Mon Oct 27 10:13:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18896 for ; Mon, 27 Oct 2003 10:13:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE92T-000KgC-Dj for multi6-data@psg.com; Mon, 27 Oct 2003 15:12:13 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE92G-000KfX-HA for multi6@ops.ietf.org; Mon, 27 Oct 2003 15:12:00 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AB021366; Mon, 27 Oct 2003 16:11:59 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp03.uc3m.es (Postfix) with SMTP id 94A41364; Mon, 27 Oct 2003 16:11:59 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Pekka Savola" Cc: , , Subject: RE: RV: (ipv6mh) hardware support for extension headers Date: Mon, 27 Oct 2003 16:06:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit So this means that in the current situation, a solution based on using extension headers would impose that packets carrying those new extension headers would be diverted through the slow path of every router they go through. Is that correct? The solution for this would be to change all routers (besides all hosts to understand the extension header) or to suffer the performance penalty, is this correct? If this is so, i don't know if a solution that uses an extension header in every packet would be acceptable. I think that a solution that only uses extension headers in a few selected packets of a communication would be ok. What's your opinion? Thanks, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Pekka Savola > Enviado el: lunes, 27 de octubre de 2003 13:56 > Para: marcelo bagnulo > CC: Erik.Nordmark@sun.com; jordi.palet@consulintel.es; > multi6@ops.ietf.org > Asunto: Re: RV: (ipv6mh) hardware support for extension headers > > > On Mon, 27 Oct 2003, marcelo bagnulo wrote: > > This is a message where Tony Hain explained why it is difficult > to support > > new extension headers in all packets, > > This message was sent to ipv6mh list a while ago... > > Hope this helps to explain Jordi's concerns. > > Please check out draft-savola-v6ops-firewalling-02.txt. This > should cover > this case as well. As identified in the draft, there are a few possible > ways forward: > > - never do any new extension headers > - specify that new extension headers must be done in TLV format, making > them more easily extensible (AND skippable!) > - specify new things as destination or hop-by-hop options instead. > > HTH > > > > -----Mensaje original----- > > > De: Tony Hain [mailto:alh-ietf@tndh.net] > > > Enviado el: miércoles, 27 de noviembre de 2002 1:59 > > > Para: 'marcelo bagnulo'; 'Michel Py'; 'Ole Troan' > > > CC: 'Jordi Palet Martinez'; 'ipv6mh'; 'Vladimir Ksinant'; 'Yoshifumi > > > Atarashi'; 'Suzuki Shinsuke'; 'Kazuaki Tsuchiya'; 'Elwyn Daview' > > > Asunto: RE: (ipv6mh) hardware support for extension headers > > > > > > > > > Marcelo, > > > > > > The basic problem is that network operators have been told that the > > > proper thing to do is filter on the L4 port. This means that all > > > hardware implementations that are expected to be deployed on a network > > > boundary have to be able to parse the L4 port. Since everyone has a > > > different definition of what router class is needed at a > boundary, this > > > effectively means all routers have to support finding the L4 port in > > > hardware. This is required even though most of the deployed routers > > > never look at the extension headers or the L4 port. The result is that > > > any new extension header that will be carried along with the current > > > common set, will cause packets to drop off the fast path. Yes, border > > > specific routers could be developed, but the market for them > would be so > > > small, and the extra hardware necessary would be so much greater that > > > the result would be so expensive that nobody would ever buy them. > > > > > > Tony > > > > > > > > > > -----Original Message----- > > > > From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] > > > > Sent: Monday, November 25, 2002 1:04 PM > > > > To: Michel Py; Ole Troan > > > > Cc: Jordi Palet Martinez; ipv6mh; Vladimir Ksinant; Yoshifumi > > > > Atarashi; Suzuki Shinsuke; Kazuaki Tsuchiya; Elwyn Daview > > > > Subject: RE: (ipv6mh) hardware support for extension headers > > > > > > > > > > > > Michel, > > > > > > > > if you don´t mind, i would split the question in two: > > > > > > > > - How would you rate the changes needed in routers in order > > > > to forward packets carrying the extesnion header WITHOUT > > > > PORCESSING it? > > > > > > > > - How would you rate the changes needed in routers in order > > > > to forward packets carrying the extesnion header and also > > > > process the extension header? > > > > > > > > Note that most routers will only forward packets containing > > > > the extesnion header without processing it. > > > > > > > > Thanks, marcelo > > > > > > > > > -----Mensaje original----- > > > > > De: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > > > > > Enviado el: domingo, 24 de noviembre de 2002 23:48 > > > > > Para: Ole Troan > > > > > CC: Marcelo Bagnulo; Jordi Palet Martinez; ipv6mh; Vladimir > > > > Ksinant; > > > > > Yoshifumi Atarashi; Suzuki Shinsuke; Kazuaki Tsuchiya; > Elwyn Daview > > > > > Asunto: RE: (ipv6mh) hardware support for extension headers > > > > > > > > > > > > > > > > Ole Troan wrote: > > > > > > the more serious issue with Marcelo's draft is that > > > > todays routers > > > > > > aren't built to send ICMP errors (or forward the packet > > > > in Marcelo's > > > > > > case), for every packet to an unknown destination. > > > > > > > > > > Dumb question for all router vendors: > > > > > Assuming that all political hurdles have been cleared, if > > > > you had to > > > > > implement (in silicon, for those of who that have > hardware-assisted > > > > > routers) what Marcelo's draft requires, how would you rate > > > > the work it > > > > > would take? > > > > > > > > > > a) Piece of cake, just needs to be decided and would be > in the next > > > > > version of the chips. > > > > > b) About the same as any other extension header. > > > > > c) Much more difficult than other extension headers you > > > > already have > > > > > implemented. > > > > > > > > > > Thanks > > > > > Michel. > > > > > > > > > > > > > > > > > > > > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > From owner-multi6@ops.ietf.org Mon Oct 27 11:40:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24196 for ; Mon, 27 Oct 2003 11:40:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEAOi-00008A-Vj for multi6-data@psg.com; Mon, 27 Oct 2003 16:39:16 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEAOb-000076-IM for multi6@ops.ietf.org; Mon, 27 Oct 2003 16:39:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9RGd2212798; Mon, 27 Oct 2003 18:39:02 +0200 Date: Mon, 27 Oct 2003 18:39:02 +0200 (EET) From: Pekka Savola To: marcelo bagnulo cc: Erik.Nordmark@sun.com, , Subject: RE: RV: (ipv6mh) hardware support for extension headers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 27 Oct 2003, marcelo bagnulo wrote: > So this means that in the current situation, a solution based on using > extension headers would impose that packets carrying those new extension > headers would be diverted through the slow path of every router they go > through. Is that correct? Not precisely.. only those routers which have to go through the packets with these extension headers via an L4 ACL (most ACLs are like that..). > The solution for this would be to change all routers (besides all hosts to > understand the extension header) or to suffer the performance penalty, is > this correct? Modulo above, yes. > If this is so, i don't know if a solution that uses an extension header in > every packet would be acceptable. > I think that a solution that only uses extension headers in a few selected > packets of a communication would be ok. IMHO, extension headers *could* be OK, as long as they'd be done in TLV format, and we specify in IPv6 WG that all the future extension headers would be done in TLV format, so the implementors could add this to their ACL code. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Oct 27 12:24:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26328 for ; Mon, 27 Oct 2003 12:24:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEB5l-0003BY-MI for multi6-data@psg.com; Mon, 27 Oct 2003 17:23:45 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEB5d-0003A1-3G for multi6@ops.ietf.org; Mon, 27 Oct 2003 17:23:37 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9RHNX5u018002; Mon, 27 Oct 2003 10:23:34 -0700 (MST) Received: from lillen (vpn-129-156-96-113.EMEA.Sun.COM [129.156.96.113]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9RHNUS14340; Mon, 27 Oct 2003 18:23:30 +0100 (MET) Date: Mon, 27 Oct 2003 18:23:15 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > IMHO, the problem is not whether we have to fix bgp or not, since i guess we > agree that don't have to fix it (or at least that it is not within the wg > scope) > > I guess that the question is whehter we can base a solution that have to > provide transport layer suvivability on the current bgp capabilities. > > Perhaps the answer is yes and there is no problem, maybe the answer is no > and we have to workaround and build a solution that don't use bgp. Perhaps the transport surviability statement in the goals document is a bit off the mark. Building a solution which assumes that routing basically works i.e. only handling the fact that a multihomed site will have multiple locators and need to have able to "rehome" communication between those locators seems to make sense to me. Assuming that routing is broken and making multi6 a general purpose overlay which works over broken routing doesn't seem like a useful approach - if routing doesn't work how can you reach the root DNS servers? Oh - just reimplement DNS as part of the overlay. I think with those assumptions you end up doing a complete overlay the same way that P2P systems build a complete overlay (with their own directory, application layer routing, etc) But perhaps we started off the wrong foot here. The concern you expressed was about BGP convergece time. But if something happens in ISP A that will only affect traffic using the locator containing the A prefix. Thus the site doesn't need BGP to converge about routing for A's prefix (which is the convergence time issue); the site would just like to receive some indication from A (or detect that the link to A is down) that something is not working well for A. That could be sufficient to have the site border routers start using the path through ISP B. > I actually think that there is a middle ground situation where things are a > bit more complex > the following example for instance: > > +---------+ > |Internet | > +---------+ > / \ > outage-> = \ > / \ > +---------+ +---------+ > | ISP1 | | ISP2 | > +---------+ +---------+ > | | | | > _____________| | | | > / ______| | | > / / | | > +---+ +---+ +---------+ > |S1 | ... |Sn | | mhsite | > +---+ +---+ +---------+ > > In this case, mhsite can reach all the customers of ISP1 through ISP1 and > all the rest through ISP2. > I have always considered the general case, where after an outage some > destiantions can only be reachable through one of the ISPs and a disjoint > set of destiantions can only be reached through the other isp. > Do you think we should start considering a simplified scenario? The above is another case to consider. > YEs this is complex, perhaps we could do something like an exponential > backoff? i guess that i would be more acceptable a delay when trying to > transmit after an interuption of a long period than interrupting a > communication that it is exchanging packets continiously, but that's just a > guess. That is an interesting idea. But it doesn't actually provide transport survivability. For example, a TCP connection with TCP keepalive enabled and no data traffic exchanged for the last few hours expects a response in a few minutes (the regular time). Same for using VoIP to listen to a presentation - after having been quiet for 40 minutes I want to ask a question and want the transmission of that question to be reliable. Thus I think in general it isn't possible to infer how quickly failover needs to happen for a ULP based when the ULP last sent/received packets. > All the proposed solutions to preserve established communications require a > major update in the installed base, since they require modifications in both > nodes involved in a communication. (in brief big cost) Agree? I think you can do multihoming proxies so that a site can transition to using multi6 even though the endnodes do not yet support it. Basically the multi6 shim layer gets implemented in the proxy. But yes, solving multihoming without changing code somewhere in the system isn't feasible. No free lunch etc. I think you must have incremental deployment i.e. allow a host or site to introduce multihoming support and at least take advantage of that when communicating with other upgraded hosts/sites. > However,if we use bgp to detect outages, the benefit obtained will only be > partial, since the failure detection will take a long time in the general > case. This basically means that in multiple scenarios, established > communications will not be preserved. Agree? I've seen papers on bgp convergence time. Are there studies on the time it takes to infer that "something is problematic" in bgp? ("something is problematic" might mean a lot of churn in the routing table) If both ISPs pass their "bgp churn rate" to the site would that be enough information to start using the other locator? > Now if this is the cost and this is the benefit i don't know if this > solution is interesting. really high cost and reduced benefits. > > Other arguments are that: > > A loc/id solution provides a basic capability required to preserve > established communication, but the solution doesn't provide all what it is > needed. Additional stuff needed, such a failure detection mechanism will be > provided by the upper layer. That isn't what I've been saying. ULPs that have very specific time constraints and are willing to pay the packet overhead, might want to consider their own e2e heartbeats. The precense of these heartbeats will aid the multi6 layer to detect locator failures faster than the multi6 layer can do independently. But not all ULPs need such heartbeats. > My answer to that is then why don't we just let the upper layer handle all > the problem then? I mean, you mention SCTP, well sctp provides heartbeat, > allright but it also manages multiple addresses in a connection, so the > loc/id solution doesn't provides anything useful to sctp. The same thing > could be done with TCP and also with application protocols Yes, but the number of such ULPs is larger than 1; with a common multi6 shim you only need to build this in one place instead of N. With per-ULP solutions your deployment concern doesn't go away. So I don't see an argument for implementing this N times is better than implementing it one time, > Another argument is that the loc/is split solution provides an high level > solution that can be also used to satisfy other needs, and not only for > multi-homing, so it should be adopted not becuase it is great for preserving > established communications in multi-homed environments, but because it is > architecturally sound. Well, i may agree with this, but in this case a wider > view is required to uderstand if such a solution is good for all other > requirements imposed, so we shouldn't be doing this in this wg (or only in > this wg at least) > > BTW, if the argument to accept a solution is the last one, this would > discard solution without a strong loc/id separation that doesn't provides > good response times (noid for instance), right? Presumably this wider view would require that it there is a system which can lookup identifiers e.g. to find the locators. While one can speculate about such systems (see the future work section in the SIM draft for an example of such speculation) with desirable properties, it would take some time to understand what properties are needed, design, and then deploy such a system. And it isn't clear to me that there is sufficient impetus for such a system, even if we had it all specified and implemented today, would actually get deployed. But in general I think whether this group decides to take the narrower multihoming view or the broader "id/loc separation in its own right" view, it needs to be understood by the broader IETF community to avoid any late surprises. Erik From owner-multi6@ops.ietf.org Mon Oct 27 13:36:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29024 for ; Mon, 27 Oct 2003 13:36:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AECCF-00078j-9J for multi6-data@psg.com; Mon, 27 Oct 2003 18:34:31 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AECC6-00078K-1j for multi6@ops.ietf.org; Mon, 27 Oct 2003 18:34:22 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9RIYBed083066; Mon, 27 Oct 2003 19:34:12 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Mon, 27 Oct 2003 18:19:39 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 27 okt 2003, at 14:26, Erik Nordmark wrote: > I don't do operations thus I'd be interested in folks with operational > experience commenting on the common and likely failures that a site > should > worry about. > What I've heard of are failures due to links being cut between sites > and their > ISP, backbone links back-hoed (but don't understand what actual impact > they had on each ISPs network), and ISPs going bankrupt. Don't forget power outages. The result is always the same: one or more links go down. If these are attached to (real) routers on both ends, the failover happens pretty quickly as rerouting is triggered by the interface going down. If there there is layer 2 gook in the middle, it takes longer as BGP sessions must time out. But even in these cases failover is usually fast enough so that when the user experiences a problem, the problem is already gone when they investigate or retry. (10 seconds - 1 minute.) The real fun starts when a large network has routing problems. > My take is that we should make the multihoming solution improve the > availability of sites with multiple Internet attachments without > requiring or > assuming e2e periodic pings to quickly detect failures. Agree, but note that there are ways to optimize these so they're not as evil as they could be if done using some kind of proxy. > Some applications/upper layer protocols might want to use such > mechanisms > in addition to the rehoming support in the multihoming solution for > quicker > failures (For instance, SCTP already has such a mechanism; heartbeats.) > Thus I'm advocating not assuming that every ULP > connection/session/assocatin > has hearbeats when solving rehoming since we know of neither the > performance > implications of this on a large scale, nor the benefits that > applications > in general will derive from it. Layer 4 already needs to receive acknowledgements from the other end in order to be sure it can continue to send. It's not much of a stretch to have a layer 4 protocol send a message back to the mh layer saying "you may want to trigger rehoming" when there are no ACKs for a while. From owner-multi6@ops.ietf.org Mon Oct 27 13:36:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29106 for ; Mon, 27 Oct 2003 13:36:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AECCM-00079E-Qc for multi6-data@psg.com; Mon, 27 Oct 2003 18:34:38 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AECCJ-00078v-6g for multi6@ops.ietf.org; Mon, 27 Oct 2003 18:34:35 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9RIYBef083066; Mon, 27 Oct 2003 19:34:22 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "" From: Iljitsch van Beijnum Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Mon, 27 Oct 2003 19:24:15 +0100 To: X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 27 okt 2003, at 13:25, marcelo bagnulo wrote: > Current studies of bgp convergence time are talking about up to 15 > minutes > of BGP convergence when a route is withdrawn. Established > communications > clearly don't survive this. Ok, but answer me this: how does established communication survive the fact that the route to one of the endpoints is withdrawn in the first place? No route means no connectivity. (Un)fortunately these researchers often don't really understand BGP so they model it in the wrong way. If you build a huge network, infuse it with instability and then revoke a route, you could perhaps end up with a 15 minute wait before the route has really disappeared everywhere. However in practice it isn't this bad. I've done some tests a while ago and what I saw pretty consistently was two minutes. But apart from that revoking a route at the source isn't a very typical condition or one that we need to survive. What we need is to detect a broken link and reroute. The first part can take up to three minutes because of Cisco's unbelievable default hold time, but it doesn't have to: if one end sets a lower hold time, that one is used, and routers are by default configured to immediately tear down BGP sessions when the associated interface goes down. Rerouting is a matter of seconds in the absense of prior instability, or 30 seconds otherwise. So many outages don't even lead to a noticable interruption, a good number make TCP sessions hang for a relatively long time (30 - 180 seconds) but don't break them, and only under very unfortunate circumstances rerouting takes longer than a TCP timeout. Note that there are efforts underway to detect a dead neighbor very quickly. This should take the edge off of these problems by eliminating the 180 second timeout. See http://www.ietf.org/internet-drafts/draft-katz-ward-bfd-01.txt >> have to exchange end-to-end hello packets every 10 >> seconds or so. If you want to do VoIP you need to do them about every >> 100 >> milliseconds. Imagine 100 Billion hosts or so communicating across >> the Internet doing such e2e hello's. Couldn't that be another form of >> scaling problem? > :-) > Well, som additional cosndierations about this. > First, many existing ULP already exchange this type of messages, TCP > ack for > instance, so hellos can be piggybacked into this messages. If you get an ACK, you know you have reachability so no need to piggyback anything. I think it would be a very good idea to dump the job of detecting _potential_ failures in the lap of layer 4 (which for many real time protocols means the application). TCP has a very good idea of how reachable the other end is. For real time protocols, it's probably either impossible or too expensive to make rehoming seamless. But why would we have to? A short hiccup in the audio/video would be bad, but not as bad as 1. sending ACKs ever 100 ms and 2. rehoming every time a single packet is lost. It's not like there are outages so rehoming is necessary every few minutes. From owner-multi6@ops.ietf.org Mon Oct 27 13:43:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29552 for ; Mon, 27 Oct 2003 13:43:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AECKZ-0007bK-H8 for multi6-data@psg.com; Mon, 27 Oct 2003 18:43:07 +0000 Received: from [195.43.225.73] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AECKV-0007av-Oe for multi6@ops.ietf.org; Mon, 27 Oct 2003 18:43:04 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9RIgkPk001170; Mon, 27 Oct 2003 19:42:50 +0100 (CET) Date: Mon, 27 Oct 2003 19:42:42 +0100 Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Content-Type: text/plain; charset=ISO-8859-1; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: mbagnulo@ing.uc3m.es, multi6@ops.ietf.org To: Erik Nordmark From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <5932DACA-08AD-11D8-B7E7-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: quoted-printable X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On m=E5ndag, okt 27, 2003, at 14:26 Europe/Stockholm, Erik Nordmark = wrote: > ply-To: Erik Nordmark > >>> The routing system seems to be good enough for this purpose when=20 >>> sites are >>> not multihomed. >> >> Well, i am not sure about this. >> Current studies of bgp convergence time are talking about up to 15=20 >> minutes >> of BGP convergence when a route is withdrawn. Established=20 >> communications >> clearly don't survive this. > > OK, but fixing the BGP convergence time isn't in scope for this WG. > > My logic is to try to find where multihoming makes things different. > The fact that BGP convergence time in the currrent Internet is worse=20= > than > desired is something that should be addressed independently of=20 > multihoming, > right? Agreed with Erik. There is also no need to use BGP as we know it=20 forever. > If not, shouldn't multihoming fix other pressing problems like world=20= > hunger? Now that you mention it....;-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP51nJKarNKXTPFCVEQK+hACdGMIZVNs7sZ3xC5mvHLUSowBMfZIAoI/f IPS8ji6qQnux9HKDaiZViuTE =3DxXwc -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Oct 27 14:52:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03692 for ; Mon, 27 Oct 2003 14:52:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEDOB-000B8U-Cb for multi6-data@psg.com; Mon, 27 Oct 2003 19:50:55 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEDO5-000B7r-8E for multi6@ops.ietf.org; Mon, 27 Oct 2003 19:50:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9RJo8N16326; Mon, 27 Oct 2003 21:50:09 +0200 Date: Mon, 27 Oct 2003 21:50:08 +0200 (EET) From: Pekka Savola To: kikim@cclab.cnu.ac.kr cc: multi6@ops.ietf.org Subject: about draft-kim-bgp-community-site-multihoming-00 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, I had a very brief look at the document draft-kim-bgp-community-site-multihoming-00: An Application of the BGP Extended Community Attribute for Distributed IPv6 Site Multihoming .. however, it introduces a number of big problems: 1) it does not outright spell out which problems it tries to solve, and it does not really explain why these things are actual problems in RFC 3178 (the site exit routers RFC). Most of these seem to be confusing, misguided or wrong to begin with, making it difficult to assess whether the mechanism itself is needed or not, or based on the right assumptions. These definitely need to be spelled out more. 2) a new "multihoming community" is introduced which appears to be totally bogus, trying to replace a BGP route advertisement with an option which conveys where to forward the packets instead (unless I misunderstood something) 3) these models depend on the operation of rest of the internet for multihoming. What incentive would they have to do anything like that? 4) use of this kind of special community has significant security concerns, despite what's described in the memo. Couldn't anyone hijack anyone else's traffic by adding this community to any prefix? In short, I think the document needs a lot more clarity on what it's trying to achive and how. But in the end, I believe (unless I misunderstood something about the design choices) there will probably be only little usefulness. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Oct 27 17:53:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25209 for ; Mon, 27 Oct 2003 17:53:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEGDG-000KgD-Bz for multi6-data@psg.com; Mon, 27 Oct 2003 22:51:50 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEGDC-000Kfl-So for multi6@ops.ietf.org; Mon, 27 Oct 2003 22:51:47 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9RMpXed086119; Mon, 27 Oct 2003 23:51:33 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <203C3035-08D0-11D8-AD90-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: "" From: Iljitsch van Beijnum Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Mon, 27 Oct 2003 23:51:39 +0100 To: X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 27 okt 2003, at 15:45, marcelo bagnulo wrote: > But i do have some simulation about how would the bgp detection > mechanism > would affect an ongoing voip communication ;-) > Considering a sample every 20 msec, that would be 3000 samples lost. If we assume for a few moments that we can't make failover seamless, what would be an acceptable delay for VoIP? Applications such as streaming media have the interesting property that the arrival of new data is extremely predictable. This makes it possible to use negative acknowledgements to trigger failover rather than the lack of regular acknowledgements, which is what TCP does. If you expect a sample every 20 ms and you didn't get one for 100 ms, you can be pretty sure that something bad is happening, so it might be a good idea to signal the other side to try another address. This should give you failover within a fraction of a second without having to send any packets during regular communication. (Note that you still need ACKs in order to detect a correspondent going away altogether so you're not firing off packets into a black hole.) From owner-multi6@ops.ietf.org Mon Oct 27 18:18:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27547 for ; Mon, 27 Oct 2003 18:18:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEGcj-000Lqn-EN for multi6-data@psg.com; Mon, 27 Oct 2003 23:18:09 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEGcf-000Lpw-9F for multi6@ops.ietf.org; Mon, 27 Oct 2003 23:18:05 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9RNFOed086376; Tue, 28 Oct 2003 00:15:25 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <75CB05AB-08D3-11D8-AD90-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org, kikim@cclab.cnu.ac.kr From: Iljitsch van Beijnum Subject: Re: about draft-kim-bgp-community-site-multihoming-00 Date: Tue, 28 Oct 2003 00:15:31 +0100 To: Pekka Savola X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 27 okt 2003, at 20:50, Pekka Savola wrote: > I had a very brief look at the document > draft-kim-bgp-community-site-multihoming-00: Would it be possible to quote the full URL for drafts? That's much easier than having to search for the all over the place. > An Application of the BGP Extended Community Attribute for > Distributed IPv6 Site Multihoming > .. however, it introduces a number of big problems: Yes. I don't really understand the whole thing, but it does seem to depend on propagating per-multihomed site information throughout the network using BGP. If we could do this we wouldn't be here trying to come up with all this complicated stuff in the first place. But we can't because propagating this information doesn't scale, so we are. From owner-multi6@ops.ietf.org Mon Oct 27 23:02:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06297 for ; Mon, 27 Oct 2003 23:02:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEL0n-00099e-IB for multi6-data@psg.com; Tue, 28 Oct 2003 03:59:17 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEL0Z-000994-I4 for multi6@ops.ietf.org; Tue, 28 Oct 2003 03:59:03 +0000 Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (rwcrmhc13) with SMTP id <2003102803585901500q6ma4e> (Authid: sdawkins@comcast.net); Tue, 28 Oct 2003 03:59:00 +0000 Message-ID: <09b801c39d07$db69c5e0$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Multi6 Mailing List" Subject: Notes on draft-crocker-mast-analysis-01.txt Date: Mon, 27 Oct 2003 21:59:15 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_09B5_01C39CD5.904D7BB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_44 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_09B5_01C39CD5.904D7BB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit My notes from a quick look-through of the MAST-ANALYSIS draft are attached. Although I suggest plenty of changes, I'm very pleased with the structure and contents of the document. I'm rearranging in many cases. Dave, thanks for all your hard work. Sorry it's taking me so long to read drafts these days! Spencer ------=_NextPart_000_09B5_01C39CD5.904D7BB0 Content-Type: text/plain; name="draft-crocker-mast-analysis-01(SD).txt" Content-Disposition: attachment; filename="draft-crocker-mast-analysis-01(SD).txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Crocker Internet Draft Brandenburg draft-crocker-mast-analysis-01.txt October 19, 2003 Expires: <4-04> =20 =20 =20 =20 CHOICES FOR MULTIADDRESSESING S: my apologies for starting with such a lame observation, but this = seems like a really odd title!=20 Is it more like "choices for evaluating multiaddressing proposals"? =20 =20 ABSTRACT =20 An IP Address serves the dual roles as references to a "place" on the Internet and to a host on the Internet, labeled "locator" and "identifier", respectively. Systems that use IP Addresses as identifiers cannot support dynamic changes in the mapping between the identifier and the locator. For a system to use a different IP Address pair, participants must initiate a new exchange. In the case of TCP, this means a new connection. In recent years, there have been efforts to overcome this limitation, through different approaches at different places in the Internet architecture. This paper reviews the basic requirements for support of multiaddressing (mobility and multihoming), and the efforts to support them. Barriers to adoption, administrative overhead, and operational efficiency are of particular concern. =20 =20 =20 =20 CONTENTS =20 1. Introduction 1.1. Scenarios 1.2. IETF Background 1.3. Discussion Venue 1.4. Document History =20 2. Terminology 2.1. Recommended 2.2. Deprecated =20 3. Considerations 3.1. Mobility 3.2. Multihoming 3.3. Security 3.4. Implementation 3.5. Deployment and Use 3.6. Matters of State 3.7. Endpoint Identifiers 3.8. Signaling 3.9. Operation Through NATs =20 4. Internet Stack Placement Proposals 4.1. IP Infrastructure 4.2. Transport-Level 4.3. Session-Level 4.4. Application-Level 4.5. IP Endpoint =20 5. Security Considerations =20 Appendix A.1. Acknowledgements A.2. References A.3. Author's Adress A.4. Full Copyright Statement 1. INTRODUCTION =20 "We need a way for sites to be internally stable even when their relationship to the world around them changes for whatever reason." -- E. Lear S: for good reasons, you're proposing significant changes to terminology = later in the paper.=20 The reader doesn't know this yet, but the re-reader, or the reader who = has seen list traffic=20 on this topic, may be confused by this section. It would have helped me = a lot if the following=20 paragraph started "In today's terminology, ...". =20 An IP Address serves as references to a "place" on the Internet and to a host on the Internet. These two roles are generally labeled "locator" and "identifier", respectively. Systems that use IP Addresses as identifiers typically cannot support dynamic changes in the mapping between the identifier and the locator. For example, TCP includes a single source/destination IP Address pair in its definition of a connection. Hence its transport association is tied to that pair. This is problematic for hosts S: "that pair of addresses" that are multihomed or mobile. Both have access to multiple IP S: "that are "multiaddressed" - either multihomed or mobile. These types = of hosts have access" Addresses, but they are prevented from using more than one within an existing context, because the context is named by that pair. S: "that pair of addresses" For a system to use a different IP Address pair, participants S: "For a pair of systems to use different IP Addresses, they" must initiate a new exchange. In the case of TCP, this means a new connection. S: "connection, interrupting the application running over that = connection" =20 In recent years, there have been efforts to overcome this limitation, through different approaches at different places in the Internet architecture. Some approaches modify the IP infrastructure, with embedded redirection services. Some define transport enhancements to support a set of locators directly, and some define a layer between classic IP and classic transport. The S: I'd do a paragraph break before "The". primary goal of these multiaddressing efforts is to preserve established connections when an IP Address changes. Each of the existing proposals has notable limitations in functionality, implementation, deployment or use. =20 This paper reviews the basic requirements for support of multiaddressing (mobility and multihoming), and the efforts to S: I tried to do a more formal definition of multiaddressing previously, = so I'd drop the parenthetical here. support them. Barriers to adoption, administrative overhead, and operational efficiency are of particular concern. In addition, S: You know you want to say here that these are the low-tech obstacles = that will cripple proposals no matter how technically brilliant. Go = ahead and say it! the analysis considers enhanced functionality that is possible from the use of multiaddressing, such as performance-based load- sharing, across the different locators available to a multihomed host. 1.1. Scenarios =20 What are the situations and concerns that affect design and use of a mechanism for the support of multiaddressing? =20 Section 3 of [MOBMH], has an excellent discussion of these issues. It is included here by reference without section 3.2. Section 3.2 covers an interesting topic that appears to be independent of multiaddressing. The included text comprises the following sub- sections: =20 3. Usage scenarios 3.1 End-host mobility 3.2 Location privacy =85 3.3 End-host multi-homing 3.4 Site multi-homing 3.5 Combined mobility and multi-homing 3.6 Network renumbering 3.7 Combined all 1.2. IETF Background S: Whew. "Historically, IETF work on multiaddressing has been tilted = toward mobility,=20 with little focus on multihoming outside the routing area. Within = mobility, the work has been split between providing initial mobility into an otherwise static environment (ex. = DHCP) and providing ongoing mobility via forwarding mechanisms (ex: Mobile IP). More recent efforts are = pursuing direct enhancements to transport or insertion of a mapping layer between IP and transport." I totally = lost the last sentence of the paragraph! =20 Historically, IETF focus on mobility has split between initial attachment configurations, into an otherwise static environment such as by using DHCP, versus forwarding mechanisms, such as by modifying the IP infrastructure with Mobile IP. Multihoming has largely been ignored, except in routing protocol work. Recent efforts are pursuing direct enhancements to transport or insertion of a mapping layer between IP and transport. There has also been adjunct activity, relevant to this topic. =20 The following summary of IETF activities draws on text from the Abstracts of documents for those activities. In addition, there is a useful analysis of the different architectural and protocol efforts is in Section 3, "Internet Stack Placement" in [NSRG]. Specification efforts are discussed in more detail in Section S: this sentence just ends (sort of) - needs at least a section number. S: I understand that you're stealing text that's not as gifted as = anything you or I would turn out (smirk!), but I just can't stand the result. = Please let me suggest text, and if you get improvements from anyone smarter = than I am about a specific proposal, that would be lovely, too. =20 The Name Space Research Group [NSRG] considered modifications to the Internet architecture, including whether an additional level of naming is needed, above layer 3 but below the application layer. Purpose-Built Keys [PBK] S: there's a missing paragraph split before "Purpose", isn't there? specifies a template for the use of specially generated public/private key pairs, to provide assurance that successive messages in the communication come from the same source. This is accomplished without the use of external certification authorities. Hence it ensures authentic S: "Although PBK does not provide global or absolute authentication, it does ensure that a session continuing from another IP Address is=20 authentic." S: You know what? I'm having a hard time thinking of PBK as a proposal = for multiaddressing - more like a necessary component of any proposal that transfers a TCP connection to a different five-tuple. It would be just as interesting for a connection that closes and reopens later (same IP addresses but different port numbers). continuity during a session, but does not provide "global" or "absolute" authentication. S: "Stream Control Transmission Protocol [SCTP] is a reliable transport = protocol for multiplexed data streams,=20 and includes a mechanism for the use of multiple IP Addresses at either, = or both, hosts on a single connection. This approach has been adapted for TCP in [TCP-HM]." Then a paragraph = break, then the sentence on DCCP. =20 Stream Control Transmission Protocol [SCTP] is a reliable transport protocol for multiplexed data streams. It includes modern mechanisms for safe initiation of a connection, as well as the necessary tools for reliability and congestion control. It also has a mechanism for communication access to multiple IP Addresses between the participation host pair. [TCP-MH] uses TCP options to support multihoming. Datagram Congestion Control Protocol [DCCP] is a proposal for a network-friendly, unreliable transport-level datagram delivery service. S: Add "This proposal includes a "DCCP-Move" mechanism to provide = rudimentary multiaddressing." =20 Mobile IP work has divided between IPv4 and IPv6. [MIP4] and [MIP6] allow a node to continue using its "permanent" home address as it moves around the internet. S: "Mobile IP ([MIP4], [MIP6]) allows a node to continue using its = "permanent" home address as it moves around the Internet, by adding network infrastructure that forwards = packets from the home address to a current address." =20 Host Identity Protocol [HIP] is used to establish a rapid authentication between two hosts and to provide continuity of communications between those hosts independent of the networking layer. The [LIN6] protocol defines a layer that supports multiple locators, between IPv6 and transport. Multiple Address Service for Transport [MAST] supports association of multiple IP Addresses during the life of any transport instantiation, by defining a layer between IP and transport. It operates only in the endpoints and works with IPv4 and IPv6. S: I understand why you're putting these proposals together, but the = result is a furball. "Host Identity Protocol [HIP], Location Independent Networking for IPv6 = [LIN6], and Multiple Address Service for Transport [MAST] all define a (logical) = layer between IP and transport. These proposals differ in services provided but all operate only in = endpoint hosts, with=20 no new infrastructure required." Is this actually true? 1.3. Discussion Venue =20 Discussion and commentary are encouraged about the topics presented in this document. The preferred forum is the mailing list, for which archives and subscription information are available at . =20 NOTE: The early drafts of a review document, like this, are certain to have significant errors. The author strongly requests guidance for clarifying and correcting any problematic text. =20 In particular, those working on the proposals and specifications discussed here are encouraged to provide corrections and additional text, to ensure accuracy. 1.4. Document History =20 -00 Derived from draft-crocker-mast-proposal-00. Extended discussions about alternative proposals and architectural issues, separated from the - proposal- draft. =20 -01 Substantial revisions to all sections. More complete review of efforts. More extensive terminology definitions. Section 3 renamed to "Considerations". Material that evaluates proposals is moved out of it, to the next section. =20 Later versions need cleaner separation of = topics, such as requirements and definition of what = multi- addressing support really means in different situations. =20 Need to add a chart that compares the proposals. =20 Need to incorporate the remainder of Marcelo's suggested changes. =20 Need to discuss enhancements made possible by multiaddressing support. =20 =20 NOTE: D. Crocker has put forward the MAST proposal. That may have colored the perspectives in this discussion paper. 2. TERMINOLOGY =20 This paper discusses requirements and methods for enabling an endpoint to use multiple locators during single application associations. This topic does not yet have a stable, core set of S: "Multiaddressing does not yet" terms in general use. The following definitions are intended to remedy that deficiency; they are taken from existing definitions, when available. Work on multiaddress enhances existing S: "multiaddressing" infrastructure capabilities. This work is uncovering ambiguities S: "in terms that have been widely used for decades."=20 to terms that have been used. For multiaddressing, it is therefore confusing to use some common terms, notably "address". Hence they SHOULD NOT be used. 2.1. Recommended S: Is this "Recommended Terminology"? =20 Agent refers to a third-party that is handling something on behalf of one or more other parties. The term indicates the separateness of the entity, as well as its key relationship to the other entities. In multiaddressing, it refers to an intermediary service that represents an endpoint, for the purposes of referral and/or relaying. S: I found myself wondering what the relationship between an agent and a = proxy might be...=20 You don't have to define the relationship between each term and all = other terms in computer networking, of course. =20 Association refers to an established communication context between endpoints, such as a TCP connection. =20 Endpoint refers to "the fundamental agent of end-end S: You don't mean "Agent" here, do you? communication" [EID]. It is an end-system that participates in an association. Endpoints are distinguished from intermediate, infrastructure nodes and hosts. S: You're headed toward someplace slippery, and probably greasy, with = "and hosts" in this definition. =20 Identifier refers to a unique label for an endpoint. The label is used simply for distinguishing one endpoint from another. Because a locator is usually globally unique, it might be able to S: "A locator is conceptually able to serve as an identifier in many = situations, if it is globally unique. However..." serve as an identifier. However this use will often suffer administrative and referential limitations as a global identifier for mobile endpoints. This is exemplified by the current problems experienced with the dual role of IP Addresses. S: "Addresses as both Identifiers and Locators" - I'm finding = inconsistent capitalization=20 (of locator, for instance) to be confusing. =20 Initiator refers to an endpoint that initiates contact with a target endpoint. In client/server architecture it is the client. S: "the client is the Initiator" =20 IP Address specifies a topological network access point. The term is usually considered to specify an endpoint interface. However discussions about mobility are notably clarified by viewing the value as belonging to the network (interface) rather than to the endpoint. =20 Locator refers to a "the name of a network attachment point" [SALT], usually in terms of the network's topology. Locators typically facilitate mapping into routes, such as by indicating a topological hierarchy. IP Addresses specify a topological network access point. They usually are considered to S: I would drop the rest of this definition as duplicating the end of IP = Address. specify an endpoint interface. However discussions about mobility are enhanced by viewing the value as belonging to the network (interface) rather than to the endpoint. S: Dave, the point you're making about mobility morphing into = multihoming and vice versa=20 is too important to hide in the definitions section, spread over the = next three definitions. =20 Mobility refers to an endpoint's having different locators over time. This may even include discontinuities, during which an endpoint has no valid locators. In addition, the nature of a transition from one locator to another may include overlapping availability of locators. Interestingly, this looks the same as multihoming. Mobility may be for a single endpoint or for the subnetwork to which the endpoint is attached. In the latter case, the endpoint connection is stable, with respect to its sub-network, but the sub-network propogates connectivity change information to the endpoint. =20 Multiaddressing refers to an endpoint's having more than one locator available, over the lifetime of an association. It encompasses both multihoming and mobility. The core requirement for multiaddressing is preservation of established communications, across the use of different locators. =20 Multihoming refers to the availability of multiple endpoint locators at the same endpoint, simultaneously. It is typically used to refer to multiple network attachments for a host, but works equally well for multiple upstream network attachments by the local network, when the different upstream locators are visible to the host. Interestingly, multihomed environments often must support dynamic changes, such as when adding a new upstream provider. Therefore, multihoming can include mobility features and mobility can include multihoming features. When needing to renumber a network, due to changes in up- stream service, the process can be operated as dynamic multihoming. S: This term stinks, if you're marketing to TSV guys.=20 They already know what Path MTU Discovery is, and it's nothing like = this. My suggestion would be something like Interface Discovery, except that you also allowed the "I have one interface, but I can see both of my network homing points from where I am" case. =20 Path discovery provides a sender with the means for learning about the locators from which they can send. S: Now, this term is fine (it actually looks like a TSV Path). =20 Path selection is required when more than one locator is available to the sender. Although the sender is limited to specifying an locator, rather than a path, it appears that thinking of it as path selection aids consideration of solutions. In effect, it formulates the selection task as being similar to the job of routers. Route formulation is mature technology, so that this aspect of multiaddress processing will be tractable, if not straightforward. =20 Referral permits an initiator to obtain a locator for a target, such as a client being referred to a server. A third-party process is required for referral, in the absence of an association. For existing associations, participating endpoints might be able to supply their own referrals. The primary Internet mechanism for referral has been the Domain Name Service (DNS). The DNS uses long, variable-length strings (names) and is tailored for large-scale referral with identifiers and locators (mappings) that change infrequently. =20 Referral Agent refers to the function that maintains the mapping between a mobile node's identifier and its locator(s). [LIN6] calls this a Mapping Agent. =20 Rehoming refers to an endpoint's changing an association from one locator to another, S: (Rehoming ends with a comma) =20 Relaying refers to the redirection of packets, on S: "refers to an endpoint forwarding packets on behalf of another = endpoint". "Redirection" seems different in both HTTP and ICMP, and that's a bad sign. And I understand the challenge you = have in explaining why this isn't routing. behalf of an endpoint. Other endpoints see a stable locator for the endpoint obtaining the relaying service. =20 Relaying Agent refers to an agent that performs packet forwarding (relaying) on behalf of an endpoint. The Relaying Agent thereby persents a stable locator to the Internet, for the endpoint. For mobility, the agent resides on an endpoint's "home" network and relays datagrams to the endpoint's actual location on the Internet. The endpoint is modified to support this forwarding technique. S: Not sure what to say, except that Rendezvous needs help! =20 Rendezvous refers to one endpoint making contact with an explicitly identified other endpoint. =20 Target refers to an endpoint that receives contact from an Initiator endpoint. In a client/server architecture, this is the server. =20 =20 2.2. Deprecated S: "Deprecated Terminology" =20 Address Refers to "the name of some network attachment point." [SALT] The term has become a problematic because addresses often are used for two, distinct functions. Hence the term should not be used by itself, for these discussions, except with reference to particular protocol specifications, such as "IP Address". Instead, use "identifer" and "locator", as appropriate. =20 Connection A state of association between two endpoints. Because the term is typically used for to refer to transport-layer state, discussions about multiaddressing should use the more general term "association", except with reference to particular protocol specification, such as "TCP Connection". S: I'm surprised that there are so few deprecated terms :-}=20 I suspect that this means people working in the space don't know enough = history to misuse more terms :-O 3. CONSIDERATIONS =20 The core requirement for multiaddressing is continuity of access within an association. However applications having this as a compelling requirement have not yet been evident on the Internet. Hence there ius some risk that proposed mechanisms to solve the S: "there is some" requirement will not correctly ancitipate the details of the S: "anticipate" requirement. =20 This section is a general discussion of requirements, constraints and concerns. It does not attempt to offer a formal set of requirements or recommendations. 3.1. Mobility =20 Mobility is time-varying access to multiple locators for the same endpoint. Key parameters to mobility are scope of change, rate of change and source(s) of the change. Over what portion of the Internet topology might a change take place; how often will changes occur; and which of the participants will change their locators? =20 =20 3.1.1. Rapid, Local Initiators =20 It is generally accepted that rapid, local changes should be S: Is it worth saying why? "below IP to minimize impact on IP routing = and routing convergence"? handled by a layer below IP. These changes are therefore invisible to IP and above, so that associations are automatically preserved across change. =20 =20 3.1.2. Rare, Distant Initiators =20 For initiator endpoints that are subject to occasional detachment and eventual reconnection, the current set of technologies is probably sufficient. These require reconfiguration, such as S: "sufficient in many cases". The problem, of course, is that our world = works perfectly for people=20 who turn their laptops off to get on planes and turn them back on when = they land, but that's not the=20 only reason hosts exhibit this connectivity pattern, and that's why DTN = is a RG... :-} through DHCP, and establishing new associations. Applications wishing to retain association state, across these transitions, do so above the transport layer. They are capable of establishing new transport associations, as needed. =20 =20 3.1.3. Periodic, Moderate =20 What is missing from the operational Internet is support for initiator and target systems that move over the course of minutes or hours and need to maintain existing transport associations or need to maintain their availability for new associations. S: good scope discussion. Why SHOULD you have to reestablish all your = connections after you drive through the chunnel? =20 The difference between mobility prior to initial contact and mobility during an existing association is significant. In the latter case, the mobile host can use the association state when needing to inform the other endpoint about the change. Prior to an association -- or when both endpoints are mutually mobile -- an independent referral service is required. S: You know, the document hasn't really distinguished between a mobile = endpoint with one locator and a mobile endpoint with two locators having different characteristics (GPRS and WLAN, for = instance). Does it make any difference if you=20 need to communicate movement when your single interface stabilizes, vs. = communicate movement over your "other, stable"=20 interface? =20 The difference between initiator mobility and target mobility is also significant, with respect to initial contact. In particular the initiator needs to be able to obtain a valid locator for the target. Again, this requires a referral mechanism, such as having the routing system map from identifiers to routes, rather than locators to routes. Either it must be provided implicitly within the network or there must be an external "referral" mechanism. For static servers, the DNS already provides this referral quite well. However current DNS use does not support frequent locator changes over short periods. Hence enhancements are needed to support referral with a mobile target. 3.2. Multihoming =20 The Internet already supports a number of types of "indirect" multihoming. =20 =20 3.2.1. Infrastructure =20 The core of dynamic packet-switched routing entails exploitation of alternative routes, so that the path between endpoints might vary considerable over the course of an association. s: It may be worth explicitly observing that we do multiaddressing of networks SO much more effectively than we do multiaddressing of = endpoints... =20 =20 3.2.2. Site =20 For networks with multiple attachments to a backbone, external routing technology already permits propagation of alternate routing information. However it does not make these alternatives visible to endpoints. =20 Further a domain name may have multiple locator records that point to the same network. However there is no indication whether the same records are, instead, pointing to different, redundant systems; on the other hand the importance of this ambiguity is not clear. S: It SHOULDN'T matter, because (since if you ask for www.yahoo.com and get nine IP addresses, there's not much telling you how to pick one) theoretically the "different" systems are equivalent. Anycast is the extreme case. But if you're using a stateful application, this=20 equivalence starts to unravel. =20 =20 3.2.3. Endpoint =20 What is notably missing is a means for an existing association to directly use multiple paths, in particular when the paths S: This is slightly confused. It seems to me that you're saying = something like "An existing association between two Internet endpoints can easily use multiple paths, as long as neither = endpoint terminates the last hop of=20 more than one path." I think. terminate at one of the endpoints. Here, the fact that classic Internet transport services rely on single, specific IP Addresses is the barrier. S: "classic Internet transport associations rely on a single pair of IP Addresses is the barrier". =20 Endpoint support of multihoming can be useful for robustness and throughput. The former makes loss of a path transparent to the association. The latter increases the effective bandwidth for an association. In general, the former goal is dominating current work. At the least, using multiple paths for increased bandwidth ensures a high degree of out-of-order arrivals. This usually reduces target endpoint performance, rather than increasing it. S: This is an important observation - from BCP on down, we don't know = how to utilize bandwidth on parallel paths unless someone does traffic engineering using route pinning. 3.3. Security S: I can't think of any improvements here - wow... =20 The level of security built into IP is minimal. Some would say it is non-existent. However, classic transport services rely on having a significant degree of correlation between the IP Address in the source field of an IP datagram and the likelihood that the IP datagram came from that locator. The context of repeated exchanges between source and destination locators is taken as a validation of this correlation. Permitting the IP Address of a source to vary during an association is an invitation to connection hijacking, and related attacks. Hence, any support for multiple locators within an association must contain a strong anti-hijacking mechanism. =20 All other security concerns are independent of multiaddressing. They may already be handled by additional mechanisms, such as [IPSec] and [TLS]. There is no indication that any of these other mechanisms need to be changed, to support multiaddressing. Once there is an effort to design protection against hijacking, it is easy to consider adding more protections, such as privacy or, perhaps, other kinds of authentication. Although such mechanisms obviously would be useful, they are not essential to the basic requirements of multiaddressing. Further, they might be redundant with mechanisms provided elsewhere in the architecture. =20 Any effort related to multiaddress support, which goes beyond preventing hijacking, needs to have explicit discussion about its relationship to other security mechanisms and the need for attaching these additional capabilities to multiaddress support. As with any opportunity for adding features to a design effort, there should be concern about causing unnecessary design complexity, delays to the specification effort, and difficulty in implementation. 3.4. Implementation S: You might make mention of how many years it took for us to move TCP = beyond initial cwnd=3D1 segment as=20 a proof of the complexity and risk people see when they change a = widely-deployed transport protocol. The dates are "Experimental in 1998, Proposed Standard in 2002". =20 The software that supports IP and classic transport services is mature. Usually it is highly tuned and highly robust. Often it is also complex. Hence it can be risky to introduce modifications to one or more of these modules. On the other hand, attempting to introduce multiaddress support through additional modules runs the risk of being awkward and inefficient. 3.5. Deployment and Use =20 However difficult it is to have vendors make major modifications to mature software, it is far more difficult to deploy the changes to a global, installed base of hundreds of millions of platforms. Changes to support multiaddressing need to consider S: Proposals to support multiaddressing barriers to adoption by users and operators, both ISPs and enterprises. S: I prefer a numbered list for this next paragraph (I can't even count the number of questions at a glance!) =20 What is the effort needed to deploy the changes? What is the effort needed to use it? How broad must the adoption be before users can obtain benefit? What dependencies do the changes have on existing or new services? =20 Making one new service depend upon the reliable performance of another new service greatly increases the riskiness of the effort. Making a change require modification to the Internet's infrastructure typically creates a long delay before it is useful. In particular, early adopters of the mechanism gain no immediate benefit from their efforts; this acts as a disincentive for adoption. Everyone waits for others to take the first step. 3.6. Matters of State =20 Support for multiple locators requires adding a conceptual layer of referential indirection. Beyond simple use of the DNS, endpoints currently use individual endpoint locators within an association. In order to use multiple locators, to refer to the same endpoint, some type of aggregation and mapping mechanism must be added. The mechanism defines a relationship between the referenced endpoint and a set of locators. Where should this state information be placed in the Internet architecture? =20 If the major lesson of the Internet is scaling, the major embodiment of that lesson is to place complexity in the edges, rather than the infrastructure. Generally, this does not mean that there is a balanced debate between the choices. Rather, there is an assumption that a change should be made to the edges rather than the infrastructure. It is made in the infrastructure only when there is a clear agreement that doing otherwise will seriously reduce the utility of the change. S: Smirk. I think you could use the current state of v6 migration = mechanisms to prove that we don't even try to do new versions of IP in infrastructure these days (stick a tunnel broker on an = endpoint, it's SO much easier!) =20 This methodology can even be applied to some infrastructure changes. A change that will clearly have an infrastructure impact might be introduced incrementally, via endpoint modifications. Two major examples of this are DNS and MIME. Both were added to operational, infrastructure services -- the IP Internet and the Internet Mail service, respectively -- but were added in a fashion that made no immediate changes to existing services. Rather, edge systems independently chose to adopt the changes. Any two endpoints wishing to exploit the change, for interacting with each other, immediately benefited from the adoption. Over time, adoption became sufficiently broad-based to make the change effectively part of the infrastructure service. Although the IP network works well without the DNS, end-user utility of the Internet, without the DNS, would be nil. Similarly the ability to use attachments has become a fundamental part of the Internet Mail experience. =20 Addition of support for multiaddressing faces a similar type of choice. Should the change be made above the transport layer, in the transport layer, in the IP layer, or perhaps between IP and transport? How is the aggregation established and how is it maintained? Do IP (or TCP, or...) packets contain the mappings or are they maintained in the endpoints or, perhaps, in the IP S: "the mappings maintained" infrastructure? =20 The answers to these questions need to be determined by their effect on barriers to adoption, operational overhead, and administrative convenience. 3.7. Endpoint Identifiers =20 Historically, IP Addresses have served the dual role of network interface locator and endpoint identifier (EID). Adding support for multiaddressing serves to highlight the need for splitting S: A LOT of present tense in one sentence...=20 "Proposals to support multiaddressing highlight the need to split these = two roles." these two roles. IP Addresses work quite well as network interface locators. However their topological dependence makes them work poorly as identifiers, in the richer world of multiaddressing. S: Again, I prefer numbered lists for quest-agraphs like the following. =20 Does an EID need to be assigned by a registry or can it be dynamically computed? Does it need to be publicly visible across the Internet or can it be kept private to individual associations? Does it need to be used frequently, such as in every datagram, or is it needed only for specific transactions, such as initiating or recovering an association? =20 It is appealing to define an EID to be publicly registered and carried in every datagram. This provides the maximum amount of decoupling from locatoring and appears to offer an especially clean modification to the transport layer interface. Transport header calculation "merely" needs to switch to use of the EID, rather than the locator. With sufficiently strong protection against hijacking, this approach probably will make the locator irrelevant to the transport layer. =20 However there still must be a mapping between EID and locators, so the IP service knows where to send the datagram. Hence, the state information of an EID/locator "routing table" must reside somewhere. Unless the IP infrastructure is modified to support EIDs directly, this state information is most probably in the endpoints. =20 Having a public EID means that a new, global registration service must be developed and operated. Some believe network operators will not mind this additional work; others disagree. S: The extent to which such additional work is attractive probably has a = lot to do with the extent to which the result looks like/does not look like per-host routing at the EID level. This is = actually one of the things I wonder about in some multiaddressing proposals... =20 Having an EID in every datagram means that the string must be as short as possible. Even then it will add significant overhead to datagram header size. However given the need to process multiaddressing, having the EID in every datagram probably will not alter datagram processing overhead, in the endpoints, from any other approach to using EIDs. =20 If an EID is used only occasionally, one candidate is a domain name. Domain names already have an administrative structure, and they are well engrained into Internet use. Their length is not a problem, when they are need only periodically. One objection to using domain names is that they are already used in a number of ways that do not suit the role of EID. It is unclear how the fact that domain names serve multiple roles prevents their serving the role of EID. One observation is that the ability of a domain name to map to multiple IP Addresses makes it problematic to ensure that the name will later map to the same IP Address as was initially selected. At the least, resolution of this concern requires careful specification and even more careful administration. 3.8. Signaling =20 How does an endpoint learn its own locators, so that it can inform another endpoint, during an association? The notable challenge is when a NAT modifies the locator an endpoint uses directly, to a different locator that is visible to the rest of the network. =20 How does an endpoint communicate that available set of locators to another endpoint? =20 DNS is currently useful for registering essentially static sets. More dynamic or tailored communication requires a signaling exchange between endpoints. This can be done through a distinct signaling protocol, such as is done with [MAST], or inline -- that is, as a sub-exchange -- within an existing protocol, such as is done with [TCP-MH]. 3.9. Operation Through NATs =20 A Network Locator Translation [NAT] device maps between one set of locators, and another. In typical cases, locators from the interior of a network are mapped to different ports on a single, public locator on the outside of the network. This mapping task must be performed with knowledge of transport protocol details because it must adjust transport headers, as well as IP-level locators. Stateless NATs are likely to work with most multihoming solutions and some mobility solutions. The NAT will simply do its usual task of replacing IP Addresses and adjusting dependent headers of common transport protocols, accordingly. =20 However, there is the basic question of whether a multiaddressed initiator correctly knows its own locators. Typically it will S: "Typically" is probably a little bleak, even on today's Internet. "In = many cases"? not. Given the prevalence of NATs, a solution to multiaddressing needs to deal with this scenario. Some solutions require that NATs be upgraded to support the solution. This is another example of an infrastructure dependency. S: And a particularly unfortunate one, since the functionality of NATs = wasn't documented widely until NATs were already in common use - how to upgrade functionality that's informally = specified? S: Ya know, I'm also thinking about firewalls that drop packets for TCP = connections they haven't seen SYN/SYN-ACKs for, wondering how they would react to a TCP packet from a host that has just = rehomed... 4. INTERNET STACK PLACEMENT PROPOSALS =20 From a purely technical standpoint, multiAddressesing can be supported through a number of different mechanisms. This section discusses the possible venues within the Internet stack, and existing efforts that are pursuing these choices. =20 The current architecture for transport use of IP Addresses makes a direct linkage to a specific IP Addresses pair: =20 Connection (IP.a, Port.l, IP.y, Port.r) +-------------------+ | Port.l | Port.r +---+---+ +---+---+ | TCP | | TCP | +---+---+ +---+---+ | IP.a | IP.y +---+---+ +---+---+ | IP | | IP | +-+---+-+ +-+---+-+ | | | | IP.a IP.f IP.q IP.y =20 This example shows each host being multihomed. However a given association must choose a single IP Addresses, at each end, and bind the connection to it. 4.1. IP Infrastructure =20 In the classic Internet infrastructure model, a datagram contains topological references to the source and destination network interfaces. The network knows nothing about higher-level issues, such as whether two interfaces are attached to the same endpoint. This design derives from the explicit desire to keep the Internet infrastructure as simple as possible, by putting as much functionality as possible into the endpoints rather than in the Internet's switching devices. =20 Connection (IP.f, Port.l, IP.q, Port.r) +--------------------------+ | Port.l | Port.r +---+---+ +---+---+ | TCP | | TCP | +---+---+ +---+---+ | IP.f | +---+---+ | | IP-ES | | +---+---+ | IP.a| | +---+---+ +-------+ +---+---+ | IP-IS | | Agent | | IP-IS | +---+---+ +---+---+ +---+---+ | | | +------------+-------------+ IP.a IP.f IP.q =20 =20 4.1.1. Dynamic DNS =20 For maintaining target availability during an association, DNS dynamic update [DNSDYN] is a plausible mechanism to obtain new locator information. Although this would probably not be helpful for transitions during an association, it could suffice for referrals to establish initial rendezvous. However it is not widely deployed and the typical DNS record lifetime settings and client caching behaviors suggest that existing DNS use is better tailored for changes over days, rather than hours. Separately the core role of DNS for Internet infrastructure operations suggests avoiding major changes to its operational model. Supporting potentially high volumes of rapid changes probably require very different software and administration than are used for the current DNS. S: Isn't there also an ugly dependence on a non-deployed PKI, if you want DNS updates from individual endpoints? =20 =20 4.1.2. MIP =20 The Mobile IP [MIP4, MIP6] efforts provide an encapsulation-based forwarding service. A "home" relaying agent intercepts datagrams using an original destination IP Addresses, and then forwards the datagram to the target's current IP Addresses. An optimization supported in the IPv6 version permits direct transmission to the new venue, if initial use of the home agent. The encapsulation S: "if initial use of the home agent"? tunnels the original IP datagram inside a new one. Direct exchanges carry both locator and endpoint identifier values. [HOWIE] provides an interesting discussion of MIPv6 adoption and use issues. =20 A major benefit to this approach is that use of the home agent requires no direct support by the non-mobile endpoint. A multiaddressed endpoint must be modified to support this capability, but the other side of an association need not be modified. This places the requirement for change onto systems with the incentive to use it. =20 Conceptually, the biggest problem with this approach is that it attempts to take topology-related information -- the IP Addresses -- and use it as the basis for contacting an endpoint non- topologically. Operationally, the biggest problems with this approach are that it requires adoption by an infrastructure service, and forwarding services are inefficient and often complex. S: If you like multihoming, a multihomed home agent has the same = problems as any other multihomed endpoint, right? We just moved the problem from the endpoint to the agent... =20 This approach changes the infrastructure and changes the IP datagram. Hence it changes multiple, different aspects of the Internet architecture, with each change potentially constituting a significant barrier to adoption, reliability or efficiency. 4.2. Transport-Level =20 Recent transport protocols, such as [SCTP], [TCP-MH] and the proposal for [DCCP], use multiple IP Addresess directly in the transport association. These efforts have primarily focused on multihoming, with the time-varying nature of mobility being ignored or retrofitted.TCP-MH notably uses TCP options for inline signaling of multihoming information between the endpoints; its current specification appears to have weak protection against hijacking but this can be remedied. S: Could somebody smarter than I am compare TCP-MH and TCP-MIGRATE for = hijack-resistence? =20 A transport-level approach has the benefit of placing the necessary functionality only in end-systems and avoiding possible locators translation problems. It also has the considerable benefit of leaving the IP infrastructure unchanged. Given the complexity and robustness of that infrastructure, as well as the considerable time and effort that was needed to achieve its stability, any design that avoids changing the infrastructure is S: "avoids infrastructure changes" to be commended. =20 Connection (IP.?, Port.l, IP.?, Port.r) +--------------------------+ | Port.l | Port.r +- --+----+ +-- -+----+ | TCP | | TCP | +---+-+---+ +---+-+---+ IP.a | | IP.f IP.q | | IP.y +---+-+---+ +---+-+---+ | IP | | IP | +--+---+--+ +--+---+--+ | | | | | | | | IP.a IP.f IP.q IP.y =20 The fact that the functionality is applicable across all transport services suggests that there might be benefit in having IP multiAddressesing functionality reside in a single S: "multiaddressing"? architectural module, separate from any specific transport service. In any case these new transport protocol efforts cannot affect the considerable installed base of services using older transport protocols, such as TCP and UDP. =20 Given that multiAddressesing is directly visible to the transport level, it is not clear how to formally define a connection. Are "virtual" locators used? Is one of the locators used? Is a separate, formal "identifier" used? =20 =20 4.2.1. SCTP =20 Stream Control Transmission Protocol (SCTP) provides reliable delivery of multiple message streams. It supports multihoming, with the exchange of multiple locators for each SCTP association endpoint, at the start of the association. Current specification use the additional locators to provide reliability if the primary locator ceases to be useful. Enhancements are being discussed to support mobility. =20 Basic security for SCTP control exchange relies on the usual reliability of mapping a locator to an Internet route. An ephemeral association identifier is also used, to prevent "blind" attacks on the association. =20 =20 4.2.2. TCP-MH =20 TCP-MH uses a TCP option to support multihoming, by specifying multiple IPv4 and/or IPv6 locator pairs that can be used during the same TCP connection. A simple transaction serial number is used to prevent hijacking. TCP-MH manages its pool of locators with individual locator add/delete operations. This style of exchange can lose synchronization between the copies of locator lists maintained by the two endpoints. =20 =20 4.2.3. DCCP =20 Datagram Congestion Control Protocol (DCCP) establishes an transport connection for the unreliable delivery of datagrams. It has an option to support multihoming. An ephemeral identifier is used to prevent hijacking. 4.3. Session-Level =20 The session layer provides functionality above transport and below the application. In effect it is a way of institutionalizing application-level support. The merit of placing multiAddressesing support at the session layer is that it S: apparently "multiAddressesing" is a blown global change... can use multiple transport services. =20 +---------+ +---------+ | App | | App | +----+----+ +----+----+ | | +----+----+ +----+----+ | Session | | Session | +---+-+---+ +---+-+---+ IP.a | | IP.f IP.q | | IP.y +---+-+---+ +---+-+---+ | TCP | | TCP | +---+-+---+ +---+-+---+ IP.a | | IP.f IP.q | | IP.y +---+-+---+ +---+-+---+ | IP | | IP | +--+---+--+ +--+---+--+ | | | | | | | | IP.a IP.f IP.q IP.y =20 The problem with this approach is that a full session layer typically replicates substantial portions of the transport service, in order to ensure reliability and in-order data S: This is the usual list, I guess. Shouldn't the need for session layers to also perform per-path bandwidth probing, etc. be mentioned as further duplication? sequencing. This makes the session-level approach notably complicated and inefficient. 4.4. Application-Level =20 Applications often provide themselves with enhanced infrastructure support services, to compensate for limitations in the lower protocol, or to optimize functionality and performance according to the peculiarities of the specific application. A typical example is with reliable data transfer, when using an unreliable datagram service. The obvious difficulty with this approach is that it burdens each new application with re-creating these (common) underlying services. =20 +-------+ +-------+ | App | | App | +--+-+--+ +--+-+--+ CP.1 | | TCP.2 TCP.1 | | TCP.2 +--+-+--+ +--+-+--+ | TCP | | TCP | +--+-+--+ +--+-+--+ IP.a | | IP.f IP.q | | IP.y +--+-+--+ +--+-+--+ | IP | | IP | +-+---+-+ +-+---+-+ | | | | | | | | IP.a IP.f IP.q IP.y =20 There well might be some benefit in permitting applications to discover details about multiaddressing capabilities, and possibly in permitting them to specify some details of their use, through an enhanced API. However the prevalence of multiAddressesing dictates its support in lower layers. 4.5. IP Endpoint =20 A recent approach to multiAddressesing defines a new "convergence" layer that exists only in the endpoint systems (hosts) and operates between classic IP and the transport layer. Hence these capabilities are invisible to the IP relaying infrastructure and can be invisible to the transport layer. However they may specify new or modified adjunct infrastructure services, especially to obtain full rendezvous capabilities. =20 This type of approach can be viewed as using a "shim" or "wedge" partial-layer, between IP and transport, or it can be viewed as partitioning IP, between a lower, relaying module that is common to all IP nodes, versus an upper module that performs IP-related functions specific to endpoints. =20 The remainder of this sub-section considers these architectural views and then discusses the three IP Endpoint proposals. =20 =20 4.5.1. Choosing an IP Endpoint Model =20 =20 4.5.1.1 Shim Model =20 For the Shim, or wedge, approach, a portion of functionality is intercepted and modified by the shim module: =20 Connection (IP.a, Port.l, IP.y, Port.r) +--------------------------+ | Port.l | Port.r +---+---+ +---+---+ | TCP | | TCP | +---+---+ +---+---+ IP.a | | IP.y /--+--\ /--+--\ < shim > < shim > \-+-+-/ \-+-+-/ IP.a | | IP.f IP.q | | IP.y +--+-+--+ +--+-+--+ | IP | | IP | +-+---+-+ +-+---+-+ | | | | IP.a IP.f IP.q IP.y =20 =20 The transport layer is presented with the same service -- including the same apparent "addressing" model -- as previously. However the address is actually used as an identifier that maps to a set of locators. In the shim model, the identifier may be one of the valid locators. =20 =20 4.5.1.2 IP/Transport Convergence Layer Model =20 Rather than viewing this type of service as being ad hoc, it can be seen as an example of IP-level services that reside only in the endpoint. That is, there is a distinction between the relaying activities in every "intermediate" system (IP-IS), versus IP functions that are needed only in the end-systems at the endpoints (IP-ES). For multiAddressesing, the architectural impact is embodied by using an Endpoint IDentifier [EID] in the interface between IP-ES and the transport layer, rather than using an endpoint locators. Significantly, the EID might be private to the endpoint(s), rather than needing to be globally registered. =20 IPSec is another example of and IP-ES service. Note that this S: "an IP-ES" architectural change also must affect the upper-layer access to DNS, since DNS Address records must be converted to EIDs. =20 Connection (IP.eid1, Port.l, IP.eid2, Port.r) +-------------------------+ | Port.l | Port.r +-------+ +-------+ | TCP | | TCP | +---+---+ +---+---+ | IP.eid1 IP.eid2 | +---+---+ +---+---+ | IP-ES | | IP-ES | +--+-+--+ +--+-+--+ IP.a | | IP.f IP.q | | IP.y +--+-+--+ +-------+ +--+-+--+ | IP-IS | | IP-IS | | IP-IS | +-+---+-+ +-+---+-+ +-+---+-+ | | | | | | | +--------+ +---------+ | IP.a IP.f IP.q IP.y =20 =20 4.5.2. Host Identity Protocol (HIP) =20 HIP works with IPv4 and IPv6. Also, it: * Creates a new, globally unique name space * Uses strong, cryptographically based protocol details, overloading some HIP functionality with security=20 functionality * Is tied significantly to [IPSEC] * Creates a new DNS RR entry S: Do you understand how many RR entries are required for general = deployment? I'm still trying to understand the answer. * Requires a Rendezvous (referral) server for mobility=20 support * Requires that NATs be aware of HIP =20 Many of the HIP features are appealing, such as the cleanliness of the architectural model depicted in Section 4 of the HIP architecture document. Were the Internet stack being created now, HIP well might be an excellent approach. However retrofitting this approach into the existing, deployed Internet entails serious barriers to adoption, such as its dependence on IPSec. =20 In general, addition of a DNS SRV record can be useful for achieving efficient rendezvous, with or without mobility. It permits participants to know whether a service is supported by its partner, without requiring a probe packet. While beneficial, this enhancement to DNS data structures is not required for multihoming or client (initiator) mobility. =20 =20 4.5.3. LIN6 =20 LIN6 defines a clean separation between identifier and locator, all within an IPv6 Address format. It defines a new, globally unique 64-bit endpoint identifier that is used by upper layers. This is then mapped to one or more IPv6 IP-layer locators. =20 The LIN6 specification also provides for the referral function (mapping agent), using DNS for basic name resolution and a separate, dynamically updated service to provide accurate information about rapidly changing locators. =20 LIN6 differs from HIP in that it: =20 * Is limited to IPv6 but integrates into IPv6 numbering * Adds a transient "presence" service to DNS lookup, for=20 dynamic locator mapping =20 =20 4.5.4. MAST =20 MAST is a control protocol for the exchange of IP Addresses notification and authorization, to use additional IP Addresses in a given host-pair context. S: The following bullet list seems oddly formatted, not sure what it's = saying... =20 The primary MAST exchange transmits: =20 * A list of current IP Addresses supported by the sender Support exchanges: =20 * Establish a host-pair context * Establish relevant authentication between the pair =20 MAST takes a more modest approach than HIP or LIN6. It does not define a new identifier space, has a simpler specification, permits easier implementation and adoption, and works equally with IPv4 and IPv6. MAST has the unusual characteristic of permitting its application to a transport association to begin after the association is underway. =20 Referral to a mobile target is provided as an adjunct function. Initial referral and rendezvous identification reliy on domain names. For mobile endpoints, dynamic locator information is obtain through an associated presence service. New locator information is communicted during an association by the control protocol; security relies on use of a statistically unique, emphemeral identifier. =20 MAST differs from the list of HIP requirements in that it: S: Are these requirements or attributes? Same question for LIN6 below. =20 * Uses a name space that is transient and local to the=20 host-pair * Treats referral as an adjunct requirement and has no=20 special requirements on DNS, in the base service * Is transparent to NATs =20 MAST differs from LIN6 requirements in that it: =20 * Uses a name space that is transient and local to the=20 host-pair * Treats referral as an adjunct requirement * Works with IPv4, as well as IPv6 5. SECURITY CONSIDERATIONS =20 This is a discussion paper and specifies no actions. Hence it has no security impact, except in terms of generally discussing security issues for the IP architecture. S: Yah, but you're inciting to riot. Fess up. =20 An excellent discussion about the types of attacks that are relevant to multiaddressing mechanisms is contained in [WEAK]. Notably it discusses the use of association-specific ephemeral keys, without needing a global certificate service. APPENDIX A.1. Acknowledgements =20 Funding for the RFC Editor function is currently provided by the Internet Society. =20 Marcelo Bagnulo has contributed extensively to this draft. He would be listed as a co-author, but he was not given an opportunity to review it, due to the impending IETF I-D deadline. =20 Commenters on this text include: Marcelo Bagnulo, Fred Baker, Iljitsch van Beijnum, Vint Cerf, Spencer Dawkins, Robert Honore, James Kempf , Eugene Kim, Eliot Lear, Pekka Nikander, Erik Nordmark, Tim Shepard, Randall R. Stewart, Fumio Teraoka, and Bob Hinden. =20 Networking history scholars may note that some terms used in the paper echo from the ancient times of OSI. Apologies are offered. Alas, that effort produced some useful architectural references and terminology, in spite of its problematic protocol specification work. Use of those terms, here, is a matter of pragmatics, not religion. The Internet community lacks broad use of some necessary terminology. Those objecting to any of the terms used here are encouraged to offer others, and to get community support for them. A.2. References Non-Normative =20 [DCCP] Kohler, E., M. Handley, S. Floyd, J. Padhye, "Datagram Congestion Control Protocol (DCCP)", draft-ietf-dccp-spec-04.txt, 30 June 2003 =20 [DNSDYN] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC2136, April 1997 =20 Wellington , B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000 =20 [EID] Chiappa, J.N., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", , 1999 =20 [ETCP] Zhang, B., Zhang, B., Wu, I., "Extended Transmission Control Protocol (ETCP) Project-- Extension to TCP for Mobile IP Support", =20 [HIP] Moskowitz, R., "Host Identity Protocol Architecture", < http://www.ietf.org/internet- drafts/draft-moskowitz-hip-arch-03.txt > =20 Moskowitz, R., "Host Identity Protocol", =20 [HOWIE] Howie, D., "Consequences of using MIPv6 to Achieve Mobile Ubiquitous Multimedia", http://www.mediateam.oulu.fi/publications/pdf/38 4.pdf =20 [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998 =20 [LIN6] Teraoka, F., Ishiyama, M., Kunishi, M., "LIN6: A Solution to Mobility and Multi-Homing in IPv6", draft-teraoka-ipng-lin6-02.txt, 24 June 2003 =20 [MOBMH] Nikander, P., "End-Host Mobility and Multi- Homing with Host Identity Protocol", < http://www.ietf.org/internet-drafts/draft- nikander-hip-mm-00.txt> =20 [NAT] Egevang, K., and P. Francis, "The IP Network Locators Translator (NAT)", RFC1631, May 1994 =20 [NSRG] Lear, E., Droms, R., "What's In A Name: Thoughts from the NSRG", draft-irtf-nsrg-report-10.txt, September 2003 =20 [MAST] Crocker, D., "Multiple Locators Service for Transport (MAST): An Extended Proposal", draft-crocker-mast- proposal-00.txt, September 13,2003 =20 [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002 =20 MIP4 Working Group, < http://www.ietf.org/html.charters/mip4- charter.html> =20 [MIP6] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", draft-ietf-mobileip-ipv6- 24.txt, June 30, 2003 =20 Bagnulo, M., Garcia-Martinez, A., Soto, I., "Application of the MIPv6 protocol to the multi- homing problem", draft-bagnulo-multi6-mnm-00, February 25, 2003 =20 MIP6 Working Group, < http://www.ietf.org/html.charters/mip6- charter.html> =20 [PBK] Bradner, S., Mankin, AS., Schiller, J., "A Framework for Purpose-Built Keys (PBK)", draft- bradner-pbk-frame-06.txt, June 2003 =20 [SALT] Saltzer, J., " On the Naming and Binding of Network Destinations", RFC 1498, A ugust 1993 =20 [SCTP] L. Ong, and J. Yoakum "An Introduction to the Stream Control Transmission Protocol (SCTP)", RFC 3286, May 2002 =20 R. Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., Paxson, V., "Stream Control Transmission Protocol", RFC 2960, October 2000 =20 R. Stewart, et al, "Stream Control Transmission Protocol (SCTP) Dynamic Locators Reconfiguration", draft-ietf-tsvwg-addip-sctp- 07.txt, February 26, 2003 =20 [TCP-MH] Matsumoto, A. Kozuka, M., Fujikawa, K., Okabe, Y., "TCP Multi-Home Options", draft-arifumi-tcp- mh-00.txt, 10 Sep 2003 S: The actual date for tcp-mh is 7 Oct - there was a bogus .tx.txt draft = submitted previously. =20 [TLS] Dierks, T., C. Allen , "The TLS Protocol Version 1.0", RFC 2246, January 1999. =20 [WEAK] Arko, J., Nikander, P., "Weak Authentication: How to Authenticate Unknown Principals without Trusted Third Parties", , A.3. Author's Adress =20 Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA =20 tel: +1.408.246.8253 dcrocker@brandenburg.com A.4. Full Copyright Statement =20 Copyright (C) The Internet Society (2003). All Rights Reserved. =20 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. =20 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. =20 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ------=_NextPart_000_09B5_01C39CD5.904D7BB0-- From owner-multi6@ops.ietf.org Tue Oct 28 02:30:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03686 for ; Tue, 28 Oct 2003 02:30:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEOHx-000ICy-Hi for multi6-data@psg.com; Tue, 28 Oct 2003 07:29:13 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEOHu-000ICZ-7r for multi6@ops.ietf.org; Tue, 28 Oct 2003 07:29:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9S7SEn28308; Tue, 28 Oct 2003 09:28:44 +0200 Date: Tue, 28 Oct 2003 09:27:58 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org, Subject: Re: about draft-kim-bgp-community-site-multihoming-00 In-Reply-To: <75CB05AB-08D3-11D8-AD90-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 28 Oct 2003, Iljitsch van Beijnum wrote: > On 27 okt 2003, at 20:50, Pekka Savola wrote: > > > I had a very brief look at the document > > draft-kim-bgp-community-site-multihoming-00: > > Would it be possible to quote the full URL for drafts? That's much > easier than having to search for the all over the place. Unless otherwise stated, prepend them with "www.ietf.org/internet-drafts", and you're done :-) > > An Application of the BGP Extended Community Attribute for > > Distributed IPv6 Site Multihoming > > > .. however, it introduces a number of big problems: > > Yes. I don't really understand the whole thing, My perception as wel.. :-) > but it does seem to > depend on propagating per-multihomed site information throughout the > network using BGP. If we could do this we wouldn't be here trying to > come up with all this complicated stuff in the first place. But we > can't because propagating this information doesn't scale, so we are. Exactly.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue Oct 28 03:37:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08887 for ; Tue, 28 Oct 2003 03:37:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEPK2-000LjX-Pa for multi6-data@psg.com; Tue, 28 Oct 2003 08:35:26 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEPJy-000Lj7-4I for multi6@ops.ietf.org; Tue, 28 Oct 2003 08:35:22 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9S8ZKxA021515 for ; Tue, 28 Oct 2003 00:35:21 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9S8ZJS02839 for ; Tue, 28 Oct 2003 09:35:19 +0100 (MET) Date: Tue, 28 Oct 2003 09:35:03 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: I-D ACTION:draft-nordmark-multi6-sim-01.txt (Fwd) To: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <200310272146.QAA15161@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Don't know why this wasn't cc'ed to the list. Erik ----------------Begin Forwarded Message----------------< Date: Mon, 27 Oct 2003 16:46:20 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nordmark-multi6-sim-01.txt To: IETF-Announce@, @ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Strong Identity Multihoming using 128 bit Identifiers (SIM/CBID128) Author(s) : E. Nordmark Filename : draft-nordmark-multi6-sim-01.txt Pages : 25 Date : 2003-10-27 This document contains a rough outline of a potential solution to IPv6 multihoming in order to stimulate discussion. This proposed solution uses 126 bit identifiers which are hashes of public keys (know as Cryptographically-based Identifiers) which are created in an autonomous fashion by every node. When there is a need to verify whether a new locator should be used with an identifier than a public-key based challenge-response is used. The proposal allows locator rewriting by (border) routers, and ensures that the upper layer protocols can operate unmodified in a multihomed setting using the stable identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nordmark-multi6-sim-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nordmark-multi6-sim-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nordmark-multi6-sim-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. >----------------End Forwarded Message----------------< From owner-multi6@ops.ietf.org Tue Oct 28 03:37:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08903 for ; Tue, 28 Oct 2003 03:37:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEPKA-000Lk3-27 for multi6-data@psg.com; Tue, 28 Oct 2003 08:35:34 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEPJz-000LjI-El for multi6@ops.ietf.org; Tue, 28 Oct 2003 08:35:23 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9S8ZLPh016285 for ; Tue, 28 Oct 2003 01:35:22 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9S8ZKS02845 for ; Tue, 28 Oct 2003 09:35:20 +0100 (MET) Date: Tue, 28 Oct 2003 09:35:05 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: I-D ACTION:draft-nordmark-multi6-noid-01.txt (Fwd) To: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <200310272113.QAA10671@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Don't know why this wasn't cc'ed to the list. Erik >----------------Begin Forwarded Message----------------< Date: Mon, 27 Oct 2003 16:13:54 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nordmark-multi6-noid-01.txt To: IETF-Announce@, @ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multihoming without IP Identifiers Author(s) : E. Nordmark Filename : draft-nordmark-multi6-noid-01.txt Pages : 23 Date : 2003-10-27 This document outlines a potential solution to IPv6 multihoming in order to stimulate discussion. This proposed solution relies on verification using the existing DNS to prevent redirection attacks, while allowing locator rewriting by (border) routers, with no per-packet overhead. The solution does not introduce a A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nordmark-multi6-noid-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nordmark-multi6-noid-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nordmark-multi6-noid-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. >----------------End Forwarded Message----------------< From owner-multi6@ops.ietf.org Tue Oct 28 04:06:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10757 for ; Tue, 28 Oct 2003 04:06:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEPnO-000NUs-1V for multi6-data@psg.com; Tue, 28 Oct 2003 09:05:46 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEPnL-000NUW-UI for multi6@ops.ietf.org; Tue, 28 Oct 2003 09:05:43 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9S95YUP021853; Tue, 28 Oct 2003 01:05:35 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9S95YS05422; Tue, 28 Oct 2003 10:05:34 +0100 (MET) Date: Tue, 28 Oct 2003 10:05:18 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Layer 4 already needs to receive acknowledgements from the other end in > order to be sure it can continue to send. It's not much of a stretch to > have a layer 4 protocol send a message back to the mh layer saying "you > may want to trigger rehoming" when there are no ACKs for a while. Yes. In general one would also need to be concerned about the end sending the acknowledgements when the reverse path is broken since the layer 4 sender of the ACKs don't observe any problems (other than seeing retransmissions from the other end). However, one of the interesting aspects of being able to use the source locator in the receive packets as the best destination locator for responses coupled with locator rewriting by routers is that the ACKing end will not need to do anything special; it is sufficient that the retransmitting end give the above type of advice to the multihoming layer. Erik From owner-multi6@ops.ietf.org Tue Oct 28 06:47:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17008 for ; Tue, 28 Oct 2003 06:47:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AESHu-0004yt-3X for multi6-data@psg.com; Tue, 28 Oct 2003 11:45:26 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AESHp-0004yJ-4T for multi6@ops.ietf.org; Tue, 28 Oct 2003 11:45:21 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4CAF2251; Tue, 28 Oct 2003 12:45:20 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp03.uc3m.es (Postfix) with SMTP id 384B5239; Tue, 28 Oct 2003 12:45:20 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" , Cc: Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Tue, 28 Oct 2003 12:39:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Iljistch, About the transport survivability: > Perhaps the transport survivability statement in the goals > document is a bitoff the mark. > Well, i don't know. It is the closest to a consensus that we could get in those issues. We could reconsider it, i guess. But imho we should agree on what we are looking for. But what i really think is that we should be aware of the capabilities and limitations of the solutions. We should not believe that we are making a big effort to provide established communications survivability when what we actually are providing is a limited solution that will only preserve some communications but not the general case. IMO, we should try to satisfy this requirement, or at least provide some tools to allow to achieve this functionality, even if additional mechanisms are required to do it. About the broken routing system: > Building a solution which assumes that routing basically works > i.e. only handling the fact that a multihomed site will have multiple > locators and need to have able to "rehome" communication between > those locators seems to make sense to me. > Assuming that routing is broken Actually i don't think that the routing is broken. IMHO is a bit more complex than that. I think that the constraints imposed to a large routing system are incompatible with the requirements of preserving established communications. I mean, a global routing system must be stable. this means that changes on the topology of short duration cannot be propagated to all the network. The system has to filter the changes with high frequency in order to obtain stability. OTOH, applications are susceptible to this short cuts, essentially this means that what is not significant for the routing system to propagate it is significant for the application. This doesn't mean that the routing system is broken, it just means that the transistorizes of the routing system to reach a stable view are filtered and that during that transistorizes the view of the topology by the routing system will not be accurate during that period. this means that the routing system is useful to provide the view of the network in stationary state and that high frequency changes will not be reflected IMHO this is ok The problem is that you cannot ask the routing system to react fast enough when changes occur (actually you don't want that) So, in a few words, the routing system has some inherent constraints that limit its response time. The resulting response time may be ok for some apps but it may not be ok for other apps. So, one approach is to accept that the routing system response is limited, and let the apps that require additional functionality to build their own stuff. > and making multi6 a general purpose overlay you can see it that way, you can also consider it as the host selecting the path since he is the only one who can do it in a proper way. > which works over broken routing doesn't seem like a useful approach - > if routing doesn't work how can you reach the root DNS servers? Well, DNS already have their own fault tolerance support, don't they? I mean if a root server is not available because bgp is reconverging for 15 minutes, i don't wait 15 minutes, i just pick the next one on the list. About keepalives: > But perhaps we started off the wrong foot here. > FWIW i don't like keepalives more than you do. It is just that i don't think that the routing system can provide the capabilities imposed by the preserving established communications requirement, and i can't think any better solution But let's explore alternatives, we can always come back to this if we don't find anything better. Moving forward: The routing system has a limited response time that may not be suitable for some apps. agree? We have then two approaches to improve this (that may be complementary) - Obtain hints from the routing system that something is wrong As you proposed: > But if something happens in ISP A that will only affect traffic using > the locator containing the A prefix. Thus the site doesn't need > BGP to converge > about routing for A's prefix (which is the convergence time > issue); the site > would just like to receive some indication from A (or detect that > the link to > A is down) that something is not working well for A. That could > be sufficient > to have the site border routers start using the path through ISP B. > I like that idea, especially the churn rate idea, i think we should study it more in depth. The benefits resulting from this approach is that the response time obtained using information from the routing system is improved. I guess that some apps will need better response time anyway, so the complementary approach is using some ULP hints (as Iljistch been proposing for several years by now) This means that if the ULP protocol detects something wrong it would notify to the shim layer and the shim layer would act accordingly changing locators. Some potentials problems that i can think of: My first concern is about the interaction of this two mechanisms. I mean, in the routing system based mechanism the knowledge of which locator is better resides in the routing system, So, since the routing system knows which locator is better, routers are enabled to rewrite locators, since they can choose the best one. In the other mechanism, the one who knows which is the bests locator is the host itself, so it forces the selection of the ISP to be used by selecting the appropriate locators (both source and destination) Now my concern is how these two mechanism interact, i mean the host selects one locator because it has an upper layer hint that something is going wrong and then the routing system that still haven't detected anything yet, just rewrites the locator. Let's suppose that we have two hosts A and B and both of them reside in multi-homed hosts, so A has two addresses P1:A and P2:A and B also has two addresses P3:B and P4:B Now they have a TCP connection established using P1:A and P3:B. Suddenly, A detects that it has to retransmit and sends this hint to his own shim layer. Now what does the shim layer in A does? It can change the Source locator and/or the destination locator. Changing the source locator is not very useful since it will be rewritten by the border router, and perhaps changing only the destination locator doesn't solve the problem Perhaps if the rewrite ok bit is not set, this would mean that the packets has to be routed through the isp that is compatible with the source address contained in the packet, so that the host can force the isp selection. I know this is just speculation, and that we should see the details with a more concrete proposal. My second concern is about ULP hints implementation. Right now ULP protocols don't do this. so this would imply modification, not only in all the hosts to support the new shim layer, but also in all the ULP that want to obtain the improved service. Regards, marcelo From owner-multi6@ops.ietf.org Tue Oct 28 07:33:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18324 for ; Tue, 28 Oct 2003 07:33:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AET1t-0007QK-3P for multi6-data@psg.com; Tue, 28 Oct 2003 12:32:57 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AET1o-0007Pz-Oy for multi6@ops.ietf.org; Tue, 28 Oct 2003 12:32:52 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9SCWk5u020393; Tue, 28 Oct 2003 05:32:47 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9SCWjS04021; Tue, 28 Oct 2003 13:32:45 +0100 (MET) Date: Tue, 28 Oct 2003 13:32:30 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , iljitsch@muada.com, multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > Perhaps the transport survivability statement in the goals > > document is a bitoff the mark. > > > > Well, i don't know. It is the closest to a consensus that we could get in > those issues. But if I don't misremember the discussion that lead to the transport survivability there was a question whether it was considered sufficient to select a working set of addresses/locators when new communication was established (e.g., as part of the application + TCP trying all the addresses returned from the DNS) and the concensus was that this was insufficient. Thus the goal is to provide rehoming of already established communication. This is expressed in the document as "transport survivability" but I don't think we discussed whether this also implied a failover in any particular time. As we've discussed different transports have radically different time constraints. > We could reconsider it, i guess. But imho we should agree on what we are > looking for. Agreed. > But what i really think is that we should be aware of the capabilities and > limitations of the solutions. We should not believe that we are making a big > effort to provide established communications survivability when what we > actually are providing is a limited solution that will only preserve some > communications but not the general case. But there is no useful general case; I can concoct an application + transport over UDP that requires failover in one microsecond. I don't think we can use the existence of such a thing as a guage to say that multihoming should try to accomplish failover in one microsecond. And how useful it is to only assume that the time before TCP gives up (a few minutes) matters when users in front of web browsers give up a lot sooner (10 seconds?)? In terms of the time to failover I think all we know is that the shorter it can be the better, but we don't know how much we are willing to "pay" to reach any particular time limit (for different types of failures which occur with different probabilities). > IMO, we should try to satisfy this requirement, or at least provide some > tools to allow to achieve this functionality, even if additional mechanisms > are required to do it. But I don't even know what it means to satisfy "transport survivability" - for my microsecond transport? For common TCP implementations timeout (since the TCP standard doesn't say when TCP should given up; the assumption by some protocol designers was "never" - keep trying). > I think that the constraints imposed to a large routing system are > incompatible with the requirements of preserving established communications. > I mean, a global routing system must be stable. this means that changes on > the topology of short duration cannot be propagated to all the network. The > system has to filter the changes with high frequency in order to obtain > stability. OTOH, applications are susceptible to this short cuts, > essentially this means that what is not significant for the routing system > to propagate it is significant for the application. I don't think it is that black and white. The routing system could propagate bad news faster than good news; what needs to be limited is the amount of flapping. If bad news travel fast then multihoming can provide choices between different paths taking the bad news into account. > This doesn't mean that the routing system is broken, it just means that the > transistorizes of the routing system to reach a stable view are filtered and > that during that transistorizes the view of the topology by the routing > system will not be accurate during that period. What do you mean by "transistorizes"? Dictionaries say: Date: circa 1952 : to equip (a device) with transistors but that doesn't make sense in this context. > FWIW i don't like keepalives more than you do. > It is just that i don't think that the routing system can provide the > capabilities imposed by the preserving established communications > requirement, and i can't think any better solution And I think you're just too quick to draw that conclusion which is why I try to push back a bit. > Moving forward: > > The routing system has a limited response time that may not be suitable for > some apps. agree? Let me suggest that the routing system of today has evolved in an environment where the endpoints are not agile (in switching between locators) hence there hasn't been any incentive to extract and/or propagate information that agile endpoints/sites can use. > - Obtain hints from the routing system that something is wrong The need might actually be weaker than that; being able to make some qantitative comparison between routing (flaps, stability, etc) between two possible ISPs/paths might be sufficient. Doesn't mean that one of them have to make a statement that "something is wrong". Another possibility to investigate is to make bad news travel faster than good news through the routing system. > My first concern is about the interaction of this two mechanisms. > I mean, in the routing system based mechanism the knowledge of which locator > is better resides in the routing system, So, since the routing system knows > which locator is better, routers are enabled to rewrite locators, since they > can choose the best one. > In the other mechanism, the one who knows which is the bests locator is the > host itself, so it forces the selection of the ISP to be used by selecting > the appropriate locators (both source and destination) Conceptually it would make sense to view it as the host/ULP observing the need to try a different locator, but the routing system (through feedback mechanisms like locator rewriting and perhaps others) influence the order in which locators are tried. > Now my concern is how these two mechanism interact, i mean the host selects > one locator because it has an upper layer hint that something is going wrong > and then the routing system that still haven't detected anything yet, just > rewrites the locator. Host would try a different destination locator and routing system would rewrite the source locator hence they would be complimentary I think. > My second concern is about ULP hints implementation. > Right now ULP protocols don't do this. so this would imply modification, not > only in all the hosts to support the new shim layer, but also in all the ULP > that want to obtain the improved service. FWIW RFC 2461 recommends ULP hints "all is good" to avoid performing neighbor unreachability detection probes. Perhaps the same hints can be used to have the multi6 layer stay with the same locator? Or perhaps we need both those positive hints and negative hints for multi6? Erik From owner-multi6@ops.ietf.org Tue Oct 28 10:19:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29123 for ; Tue, 28 Oct 2003 10:19:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEVc6-000Gjf-Fg for multi6-data@psg.com; Tue, 28 Oct 2003 15:18:30 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEVc3-000GjK-HH for multi6@ops.ietf.org; Tue, 28 Oct 2003 15:18:27 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id C3DA7431DE for ; Tue, 28 Oct 2003 16:18:26 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp02.uc3m.es (Postfix) with ESMTP id B2DB299FF4 for ; Tue, 28 Oct 2003 16:18:26 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: multi6@ops.ietf.org Subject: Question about draft-nordmark-multi6-noid-01.txt Date: Tue, 28 Oct 2003 16:18:24 +0100 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200310281618.26500.jrh@it.uc3m.es> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello multi6'ers: I've just read NOID draft (may be I've read it too fast ) and I haven't found anywhere how to re-write the source address. If the packet doesn't have any extra option/extension header to carry the additional prefix(es), how can the router make this rewriting ? Thanks! -- JFRH From owner-multi6@ops.ietf.org Tue Oct 28 10:25:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29400 for ; Tue, 28 Oct 2003 10:25:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEVig-000HHH-LS for multi6-data@psg.com; Tue, 28 Oct 2003 15:25:18 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEVic-000HGx-Re for multi6@ops.ietf.org; Tue, 28 Oct 2003 15:25:14 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9SFPAxA017500; Tue, 28 Oct 2003 07:25:11 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9SFP9S27568; Tue, 28 Oct 2003 16:25:09 +0100 (MET) Date: Tue, 28 Oct 2003 16:24:53 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Question about draft-nordmark-multi6-noid-01.txt To: Juan Rodriguez Hervella Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <200310281618.26500.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I've just read NOID draft (may be I've read it too fast ) and > I haven't found anywhere how to re-write the source > address. If the packet doesn't have any extra > option/extension header to carry the additional prefix(es), > how can the router make this rewriting ? The border router checks whether rewriting is allowed by looking at the nexthdr field in the IPv6 header. If it is between P1 and P1+7 (a to be defined range of "protocol values") then rewriting is ok. The source address field is then modified to have high-order bits (high-order 48 bits in many cases) which corresponds to the exit the border router is using. For instance, if it is sending a packet to an ISP who was delegated prefix 2000:1:2::/48 then it will place that value in the top 48 bits of the source address. Thus the router doesn't need to have a list of prefixes to choose between as part of the packet. Erik From owner-multi6@ops.ietf.org Tue Oct 28 11:06:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03728 for ; Tue, 28 Oct 2003 11:06:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEWLx-000K9A-W9 for multi6-data@psg.com; Tue, 28 Oct 2003 16:05:53 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEWLt-000K8P-0c for multi6@ops.ietf.org; Tue, 28 Oct 2003 16:05:49 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 280CD2AD; Tue, 28 Oct 2003 17:05:48 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp03.uc3m.es (Postfix) with SMTP id 112462AC; Tue, 28 Oct 2003 17:05:48 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: , Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Tue, 28 Oct 2003 17:00:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In terms of the time to failover I think all we know is that the shorter > it can be the better, but we don't know how much we are willing to "pay" to > reach any particular time limit (for different types of failures which > occur with different probabilities). Yes, agree, this is the question that we have to answer I guess that the approach could be to see how much could be achieved with the different solutions and then see if it is worth it. > I don't think it is that black and white. The routing system > could propagate bad news faster than good news I am not sure if this is true... I am no routing expert, but i think that withdrawing a route is inherently slower than advertising a new route, at least in path vector algorithms. The problem is that to detect that there is no route to a certain, all the alternative routes with increasing AS path are tried, which is inherently slow. This would be similar to the count to infinity problem, but with different AS path. This implies that the time to converge is proportional to the number of ASes in the network. At least that is what i understood from the Labovitz paper, but i may be misunderstanding some issues here. However, i guess that when the system is looking for a new route, (i.e. reconverging) multiple routes with increasing AS path length are advertised, which can be used as a hint to infer that something may wrong (which i guess was you proposal about the churn rate detection, right?) > > This doesn't mean that the routing system is broken, it just means that the > > transistorizes of the routing system to reach a stable view are filtered and > > that during that transistorizes the view of the topology by the routing > > system will not be accurate during that period. > > What do you mean by "transistorizes"? Dictionaries say: > Date: circa 1952 > : to equip (a device) with transistors oops... sometimes the spell checker do some funny things. I meant transitory, but never mind, i guess you already see what i meant. ULP hints: > Conceptually it would make sense to view it as the host/ULP observing the need > to try a different locator, but the routing system (through feedback mechanisms > like locator rewriting and perhaps others) influence the order in which > locators are tried. [...] > > Host would try a different destination locator and routing system would > rewrite the source locator hence they would be complimentary I think. > Well, i still don't see this very clear. Let's try with an example. Recycling an old figure, we have: +----+ ----|ISPA|_ +----+ / +----+ \_+------+ _|ISPC|_ +----+ | |_/ +----+ \__+----+ | mh1| _| | _| mh2| +----+ +----+_/ | |_ / +----+ \____|ISPB| +------+ \_+----+_/ +----+ |ISPD| +----+ We are using packet rewriting at site border routers. This means that the site exit router connection a multihomed site with ISPX will rewrite source address of packets and it will replace the contained prefix with PX::. Is this correct? Suppose that mh1 has an established tcp connection with mh2. They are currently using PA:mh1 and PC:mh2 as locators and the communication flows through ISPA and ISPC. The link between ISPC and the internet breaks It takes 180 seconds to bgp to detect the outage, so routing remains unchanged during that period i.e. packets flowing from the mhsite2 to an address containing PA are forwarded through ISPC. There are two cases to consider here, one is when the internal routing of mh2 routes packets sent to PB:: through ISPC and when it routes them through ISPD. I guess that the problematic case is the first one, so let's assume that packets flowing from mh2 to PB: are carried also through ISPC. Now when the outage occurs, one or both of the communicating nodes can start to retransmit. Let's consider that mh1 is the one whose TCP timeouts and that starts to do some retransmissions. Then TCP at mh1 communicates the shim layer at mh1 that something wrong is happening. Then the shim layer changes the destination address that is being used in the communication from PC::mh2 to PD::mh2. In this way the communication is rerouted to the alternative ISP. Good! Now, suppose that mh2 also obtains a hint that something is wrong (this could be because TCP at mh2 timeout or because packets start arriving with a different source address (this last case cannot be guaranteed because it depends on the internal routing in mh1)). So, mh2 shim layer start using an alternative destination address, so it switches from PA:mh1 to PB:mh1. However, this does not solve the problem, since packets addressed to PB:: are also routed through ISPC. The problem here is that TCP detects the problem but it has no means to communicate the problem to the mh2's routing system, who still believes that a route through ISPC is still available. I guess that if we decide to place a failure detection mechanism in the hosts themselves, we have to provide means to let the host force the routing system to select the path, or at least the exit router. This could be achieved with source address based routing.. the problem here is that this is not compatible with source address rewriting by exit routers, i mean or whether the source address is fixed and the exit isp is determined by it or the exit isp is fixed and the source address is rewritten to make it coherent with the isp selected, but not both. One option would be that for packets with the rewrite ok bit not set, source address based routing is applied and when the rewrite ok bit is not set then destination address based routing is used. (Another hint can be the reception of ICMP error messages.) This is simple example, since no interaction with routing based mechanism (churn level detector and so) are supposed. maybe we can try with a more complex the next round :-) regards, marcelo From owner-multi6@ops.ietf.org Tue Oct 28 15:41:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24849 for ; Tue, 28 Oct 2003 15:41:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEadc-0009Rl-5T for multi6-data@psg.com; Tue, 28 Oct 2003 20:40:24 +0000 Received: from [62.189.30.6] (helo=tortoise.webcentre.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEadY-0009RN-8V for multi6@ops.ietf.org; Tue, 28 Oct 2003 20:40:21 +0000 Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by tortoise.webcentre.net (8.9.3/8.9.3) with ESMTP id UAA01960 for ; Tue, 28 Oct 2003 20:40:13 GMT Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA00363 for ; Tue, 28 Oct 2003 20:40:12 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA02188 for ; Tue, 28 Oct 2003 20:40:11 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h9SKeBq18023 for multi6@ops.ietf.org; Tue, 28 Oct 2003 20:40:11 GMT Date: Tue, 28 Oct 2003 20:40:11 +0000 From: Tim Chown To: multi6@ops.ietf.org Subject: Multi6 session in Minneapolis? Message-ID: <20031028204011.GL12272@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk So we have a session booked, yes? Just making sure, as the deadline is soon :) Tim From owner-multi6@ops.ietf.org Tue Oct 28 16:01:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26501 for ; Tue, 28 Oct 2003 16:01:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEaxt-000AjN-9i for multi6-data@psg.com; Tue, 28 Oct 2003 21:01:21 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEaxn-000AiO-Nv for multi6@ops.ietf.org; Tue, 28 Oct 2003 21:01:16 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 8-md50000000040.tmp for ; Tue, 28 Oct 2003 22:01:08 +0100 Message-ID: <0c5c01c39d96$9a299ee0$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20031028204011.GL12272@login.ecs.soton.ac.uk> Subject: Re: Multi6 session in Minneapolis? Date: Tue, 28 Oct 2003 22:01:03 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Tue, 28 Oct 2003 22:01:08 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: multi6@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Yes, there is one already in the draft agenda: THURSDAY, November 13, 2003 1530-1730 Afternoon Sessions II OPSmulti6Site Multihoming in IPv6 WG Regards, Jordi ----- Original Message ----- From: "Tim Chown" To: Sent: Tuesday, October 28, 2003 9:40 PM Subject: Multi6 session in Minneapolis? > So we have a session booked, yes? > > Just making sure, as the deadline is soon :) > > Tim > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-multi6@ops.ietf.org Wed Oct 29 00:19:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25198 for ; Wed, 29 Oct 2003 00:19:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEih4-000Eb0-1S for multi6-data@psg.com; Wed, 29 Oct 2003 05:16:30 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEigy-000EaV-Si for multi6@ops.ietf.org; Wed, 29 Oct 2003 05:16:24 +0000 Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (rwcrmhc13) with SMTP id <2003102905162301500i45efe> (Authid: sdawkins@comcast.net); Wed, 29 Oct 2003 05:16:23 +0000 Message-ID: <0a7c01c39ddb$d68b2df0$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Multi6 Mailing List" References: <09b801c39d07$db69c5e0$0400a8c0@DFNJGL21> <182931539.20031028134545@brandenburg.com> Subject: Re: Notes on draft-crocker-mast-analysis-01.txt Date: Tue, 28 Oct 2003 23:16:41 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Dave, A couple of (what I hope are) clarifications, but the e-mail is getting an order of magnitude shorter on each cycle... Spencer ----- Original Message ----- From: "Dave Crocker" To: "Spencer Dawkins" Cc: "Multi6 Mailing List" Sent: Tuesday, October 28, 2003 3:45 PM Subject: Re: Notes on draft-crocker-mast-analysis-01.txt > SD> This paper reviews the basic requirements for support of > SD> multiaddressing (mobility and multihoming), and the efforts to > SD> support them. Barriers to adoption, administrative overhead, and > SD> operational efficiency are of particular concern. In addition, > SD> > SD> S: You know you want to say here that these are the low-tech obstacles > SD> that will cripple proposals no matter how technically brilliant. Go ahead > SD> and say it! > > I think the issue is more serious and substantive than that. > > Adoption and Administration hassles are fundamental concerns for everything we > do in the IETF, and I think they frequently get too little attention. I see > them as co-equal factors in IETF success. In fact, neither of them is simple, > minor, low-tech, or any other condescension, though it is easy to think as if > they were... Until they later pop up and bite us. Could not agree more. > SD> Host Identity Protocol [HIP] is used to establish a rapid > SD> authentication between two hosts and to provide continuity > SD> of communications between those hosts independent of the > SD> networking layer. The [LIN6] protocol defines a layer that > SD> supports multiple locators, between IPv6 and transport. > SD> Multiple Address Service for Transport [MAST] supports > SD> association of multiple IP Addresses during the life of any > SD> transport instantiation, by defining a layer between IP and > SD> transport. It operates only in the endpoints and works with > SD> IPv4 and IPv6. > SD> > SD> "...These proposals differ in services provided but all operate only in > SD> endpoint hosts, with no new infrastructure required." Is this actually > SD> true? > > hmmm. I certainly thought so. I know it is true for MAST. LIN6 and HIP do > specify a third-party assistant service, so maybe they are closer to mIP4? Mumble. It seemed like there were various flavors of "infrastructure" - - A home agent (in the MIP6 sense), - A foreign agent (in the MIP4 sense, or - Changes to the routing infrastructure, each being a higher hurdle than the previous flavor. > > > SD> S: Dave, the point you're making about mobility morphing into multihoming and vice versa > SD> is too important to hide in the definitions section, spread over the next three definitions. > > Ummmm. ok. Any suggestions for text or where/how to do that? Maybe in its own section, immediately following the terminology section ("An Aside on Multihoming and Mobility")? You already have the text, strewn through the last half of each definition! It just needs to be a lot more obviously visible. > > > SD> S: This term stinks, if you're marketing to TSV guys. > SD> They already know what Path MTU Discovery is, and it's nothing like this. > SD> My suggestion would be something like Interface Discovery, except that > SD> you also allowed the "I have one interface, but I can see both of my > SD> network homing points from where I am" case. > SD> > SD> Path discovery provides a sender with the means for learning > SD> about the locators from which they can send. > > 1. I did not choose the terminology framework. Some of the other proposals > used the term 'path'. In fact I originally disliked it, because it trod on > the IP-level routing world. On further thought, I came to like the reference > quite a lot, because it helps us to try to re-use routing-world ideas. > > 2. I think that 'discovery' and 'selection' should be based on the same core > term. > > I notice that you suggest 'interface' -- which I dislike -- and then point out > the problem of using it. That is, I notice you do not suggest an alternative. > Unfortunately, I'm not having any success coming up with a new one. "Locator Discovery"? Duh, sorry, I was apparently an idiot to not suggest this in the first place. > > > SD> S: Not sure what to say, except that Rendezvous needs help! > SD> > SD> Rendezvous refers to one endpoint making contact with an > SD> explicitly identified other endpoint. > > Feel free to elaborate... I kept typing and deleting... But I wasn't sure what seemed to need help. At the very least, "rendezvous" conjures up the notion of two endpoints making contact with each other, for me, anyway. > > SD> The difference between mobility prior to initial contact and > SD> mobility during an existing association is significant. In the > SD> latter case, the mobile host can use the association state when > SD> needing to inform the other endpoint about the change. Prior to > SD> an association -- or when both endpoints are mutually mobile -- > SD> an independent referral service is required. > SD> > SD> S: You know, the document hasn't really distinguished between a mobile endpoint with one locator > SD> and a mobile endpoint > SD> with two locators having different characteristics (GPRS and WLAN, for instance). Does it make any > SD> difference if you > SD> need to communicate movement when your single interface stabilizes, vs. communicate movement over > SD> your "other, stable" > SD> interface? > > This strikes me as a very important and rather dangerous question. > > I'm a fan of having stuff above IP know nothing about the attributes of the > lower layer. I see this as one of the very, very big wins in the design and > use of OP. > > It's often important to know about actual performance, but I think we get > distracted by classing these in terms of media. So, yes, knowing that one path > has ping times of days (IP over avian carrier) and that another seems to have > infinite bandwidth (giga-foo) is useful. Knowing GPRS vs. WLAN vs. gigafoo) > strikes me as the wrong way to label and use these differences. OK, you understood what I meant to say - it's not that it's GPRS and WLAN and gigafoo, it's that it's two or three locators with dramantically different attributes. I spent some time on X.25-ish Multi Link Protocol (MLP) in the late 80s - would love to see TCP running over three gig-E interfaces, but not if it's sensitive to out-of-order delivery. The GPRS/WLAN deal was basically to say that if you have two interfaces, and one is an order of magnitude higher bandwidth than the other, it's tempting to just forget the slower one, but life doesn't have to be that way. At my last two jobs, I had 100BASE-T at my desk and 802.11 wandering around the building - again, an order of magnitude difference, and easier to simply ignore 802.11 when I was at my desk, but it didn't have to be that way. > > > SD> 3.2.2. Site > SD> > SD> For networks with multiple attachments to a backbone, external > SD> routing technology already permits propagation of alternate > SD> routing information. However it does not make these alternatives > SD> visible to endpoints. > SD> > SD> Further a domain name may have multiple locator records that > SD> point to the same network. However there is no indication whether > SD> the same records are, instead, pointing to different, redundant > SD> systems; on the other hand the importance of this ambiguity is > SD> not clear. > SD> > SD> S: It SHOULDN'T matter, because (since if you ask for www.yahoo.com > SD> and get nine IP addresses, there's not much telling you how to pick one) > SD> theoretically the "different" systems are equivalent. Anycast is the > SD> extreme case. But if you're using a stateful application, this > SD> equivalence starts to unravel. > > Some offline discussions are leading to my seeing this as needing two > different identifiers. > > One is for initial rendezvous. The initiator is selecting from an > undifferentiated set of locators to use. Whether they go do the same endpoint > or different ones is none of the initiator's business. > > After there is context, the requirements are different. The initiator _must_ > get back to the same endpoint. In my current thinking, the endpoint therefore > needs a different identifier than the one that may have referred to a _set_ of > endpoints. > > So, this is a good example of the significant difference between initial > rendezvous and rehoming rendezvous. > > > SD> 3.2.3. Endpoint > SD> > SD> What is notably missing is a means for an existing association to > SD> directly use multiple paths, in particular when the paths > SD> > SD> S: This is slightly confused. It seems to me that you're saying something like "An existing > SD> association between two > SD> Internet endpoints can easily use multiple paths, as long as neither endpoint terminates the last > SD> hop of > SD> more than one path." I think. > > Sorry, but I am not understanding the text you are offering. (I'm shocked, NOT.) What I was trying to say was that an existing association can easily use multiple paths, via routing, as long as each endpoint has only one (active?) locator, so neither endpoint sees path changes on its first hop link(s). If one of the endpoints has more than one locator, we have the problem you're trying to analyse in this draft. > > > SD> Having a public EID means that a new, global registration service > SD> must be developed and operated. Some believe network operators > SD> will not mind this additional work; others disagree. > SD> > SD> S: The extent to which such additional work is attractive probably has a lot to do with the extent > SD> to which the result > SD> looks like/does not look like per-host routing at the EID level. This is actually one of the things > SD> I wonder about in > SD> some multiaddressing proposals... > SD> > SD> Having an EID in every datagram means that the string must be as > SD> short as possible. Even then it will add significant overhead to > SD> datagram header size. However given the need to process > SD> multiaddressing, having the EID in every datagram probably will > SD> not alter datagram processing overhead, in the endpoints, from > SD> any other approach to using EIDs. > > In my experience, operators do not care about abstract architectures. They > care about the effort to administer and operate it. Extra administration > sucks. Extra components suck (unless there is a strong, counterbalancing > reduction.) Per-host routing tables, without hierarchy/aggregation, suck. Sorry for being unclear. > > > SD> 4.1.1. Dynamic DNS > SD> > SD> For maintaining target availability during an association, DNS > SD> dynamic update [DNSDYN] is a plausible mechanism to obtain new > SD> locator information. Although this would probably not be helpful > SD> for transitions during an association, it could suffice for > ... > SD> S: Isn't there also an ugly dependence on a non-deployed PKI, if you > SD> want DNS updates from individual endpoints? > > Not sure what change you are suggesting to the text, or whether it is > essential for this discussion. Please clarify. If you think Joe Random Host on the Internet will be updating the DNS dynamically, you're relying on widely-deployed PKI, aren't you? If so, I'm not sure DNSDYN is all that plausible. Sorry for being vaguee. > SD> 4.5.2. Host Identity Protocol (HIP) > SD> HIP works with IPv4 and IPv6. Also, it: > ... > SD> * Creates a new DNS RR entry > SD> > SD> S: Do you understand how many RR entries are required for general deployment? I'm still trying to > SD> understand the answer. > > I have assumed one per target. No? That Would Be Unfortunate. I understand that no single DNS needs RRs for every conceivable endpoint, but this still sounds like a lot of RRs being added to the DNS. > > > SD> 4.5.4. MAST > SD> > SD> MAST is a control protocol for the exchange of IP Addresses > SD> notification and authorization, to use additional IP Addresses in > SD> a given host-pair context. > SD> > SD> S: The following bullet list seems oddly formatted, not sure what it's saying... > > It's two lists. The first has one bullet. Yes, that's odd, but the other > bullets got dropped during revisions. Besides, the idea is to match the > other, bulleted lists in this section. It just confused me - it didn't seem possible that you would have a one-item bullet list... > > SD> [TCP-MH] Matsumoto, A. Kozuka, M., Fujikawa, K., Okabe, > SD> Y., "TCP Multi-Home Options", draft-arifumi-tcp- > SD> mh-00.txt, 10 Sep 2003 > SD> > SD> S: The actual date for tcp-mh is 7 Oct - there was a bogus .tx.txt draft submitted previously. > > Good grief. That level of careful, detailed reading is really scary, > Spencer... Heh, heh, heh... From owner-multi6@ops.ietf.org Wed Oct 29 04:42:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00336 for ; Wed, 29 Oct 2003 04:42:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEmo8-000CNP-Ev for multi6-data@psg.com; Wed, 29 Oct 2003 09:40:04 +0000 Received: from [192.71.80.74] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEmnt-000CLS-Bi for multi6@ops.ietf.org; Wed, 29 Oct 2003 09:39:49 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9T9dTPk001993; Wed, 29 Oct 2003 10:39:29 +0100 (CET) Date: Wed, 29 Oct 2003 10:39:25 +0100 Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Erik Nordmark" , , To: From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On tisdag, okt 28, 2003, at 12:39 Europe/Stockholm, marcelo bagnulo wrote: > About the transport survivability: > >> Perhaps the transport survivability statement in the goals >> document is a bitoff the mark. >> > > Well, i don't know. It is the closest to a consensus that we could get > in > those issues. > We could reconsider it, i guess. But imho we should agree on what we > are > looking for. > > But what i really think is that we should be aware of the capabilities > and > limitations of the solutions. We should not believe that we are making > a big > effort to provide established communications survivability when what we > actually are providing is a limited solution that will only preserve > some > communications but not the general case. > > IMO, we should try to satisfy this requirement, or at least provide > some > tools to allow to achieve this functionality, even if additional > mechanisms > are required to do it. Isn't this simply expectation management? The reason we changed the requirements into goals was because the items in the document where either contradictory; we realized that we couldn't get it all so make it all requirements wasn't an option; and we couldn't decide on what issues where needed more than others; ? I think that connection survivability is a nice to have, but wether a connection will survive or not will also be highly dependent on the ULP as Erik points out. I think this is best handled by simply documenting what this solution offers, and what the alternatives for the ULPs are. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP5+Kz6arNKXTPFCVEQIaxwCbB5ewA/4zu16tdtI2mnJ+ulmIIGAAoM2h rTRBa0ZhVpaNvQlmfglBMmol =jevU -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Oct 29 04:50:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00695 for ; Wed, 29 Oct 2003 04:50:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEmxb-000DNb-RQ for multi6-data@psg.com; Wed, 29 Oct 2003 09:49:51 +0000 Received: from [192.71.80.74] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEmxX-000DMf-IT for multi6@ops.ietf.org; Wed, 29 Oct 2003 09:49:47 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9T9nbPk001997; Wed, 29 Oct 2003 10:49:37 +0100 (CET) Date: Wed, 29 Oct 2003 10:49:32 +0100 Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: mbagnulo@ing.uc3m.es, iljitsch@muada.com, multi6@ops.ietf.org To: Erik Nordmark From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <326611FE-09F5-11D8-AB34-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On tisdag, okt 28, 2003, at 13:32 Europe/Stockholm, Erik Nordmark wrote: > This is expressed in the document as "transport survivability" but I > don't > think we discussed whether this also implied a failover in any > particular > time. As we've discussed different transports have radically different > time constraints. > To some extent I wonder how much of this is really a multi6 problem. As you point out, we will never know how long ULP will continue to try before giving up. This might render ULP hints useless in that particular case. We also don't know what failure detection is in use for the ULPs. More, if there is also a rerouting event causing distribution of bad news, and perhaps a new set of locators, or the signaling to move to new locators, this might trigger a "race-like" condition, depending in what order the priorities are set and in which order they arrive where, and then actually making the case worse - no? Would it not be better to simply say that survivability and "restoration" time is due to these X factors, they can be influenced by this - but they are not an issue per se for the multi6 layer. They might depend on ULP signaling, BGP convergence, etc. But that is another issue. Am I making my life to easy here? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP5+NMKarNKXTPFCVEQLuTQCg8NTn1V0mniEDuTYQCybs3cyLFnUAoIq+ 6m1xmITLki2bShj/JcERogDm =DI3I -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Oct 29 05:56:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02707 for ; Wed, 29 Oct 2003 05:56:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEnzD-000IZw-DF for multi6-data@psg.com; Wed, 29 Oct 2003 10:55:35 +0000 Received: from [192.71.80.74] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEnzA-000IZZ-Mm for multi6@ops.ietf.org; Wed, 29 Oct 2003 10:55:32 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9TAtMPk002024; Wed, 29 Oct 2003 11:55:22 +0100 (CET) Date: Wed, 29 Oct 2003 11:55:16 +0100 Subject: Re: Multi6 session in Minneapolis? Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "JORDI PALET MARTINEZ" From: Kurt Erik Lindqvist In-Reply-To: <0c5c01c39d96$9a299ee0$870a0a0a@consulintel.es> Message-Id: <616EDC42-09FE-11D8-AB34-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Yes, there is one already in the draft agenda: > > THURSDAY, November 13, 2003 > > 1530-1730 Afternoon Sessions II > OPSmulti6Site Multihoming in IPv6 WG Hmm. Actually there should be two. At there was two last time I checked, but there is only one there now. Let me check. I will try and get the agenda out ASAP. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP5+cmaarNKXTPFCVEQIHbgCg1piX+cJAo96IbpNHAzMGivZwf84AoLpI xndl8NcwqFLw61fr5CqNnoMS =xuCQ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Oct 29 07:55:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05547 for ; Wed, 29 Oct 2003 07:55:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEppP-0001Mz-UF for multi6-data@psg.com; Wed, 29 Oct 2003 12:53:35 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEppN-0001Mf-57 for multi6@ops.ietf.org; Wed, 29 Oct 2003 12:53:33 +0000 Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250]) by comcast.net (rwcrmhc13) with SMTP id <2003102912533201500lfd75e> (Authid: sdawkins@comcast.net); Wed, 29 Oct 2003 12:53:32 +0000 Message-ID: <0b3301c39e1b$b41f6d90$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Wed, 29 Oct 2003 06:53:51 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is actually a pretty helpful discussion. A couple of points... Spencer > Moving forward: > > The routing system has a limited response time that may not be suitable for > some apps. agree? Agreed, but I'm not sure everyone else in the IETF agrees. It Would Be Lovely to pick a target (TCP survivability, HTTP survivability, VoIP survivability being three rough possibilities) and agree on it. > Now what does the shim layer in A does? > It can change the Source locator and/or the destination locator. > Changing the source locator is not very useful since it will be rewritten by > the border router, and perhaps changing only the destination locator doesn't > solve the problem > Perhaps if the rewrite ok bit is not set, this would mean that the packets > has to be routed through the isp that is compatible with the source address > contained in the packet, so that the host can force the isp selection. And it seems to me that the extent to which this happens has a profound effect on mobile/multihomed applications and users in the coming years. I was the one standing up in the IAB workshop saying (I am summarizing) if we get a lot of applications that WANT to handle their own path selection, while we "solve the multihoming problem", they'll STILL WANT to handle their own path selection after we "solve the multihoming problem". If we pick a target (see previous), we can at least tell some applications developers that they can ignore path selection (multihoming happens automatically for them). Spencer From owner-multi6@ops.ietf.org Wed Oct 29 09:43:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09558 for ; Wed, 29 Oct 2003 09:43:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AErVj-0009rq-Ja for multi6-data@psg.com; Wed, 29 Oct 2003 14:41:23 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AErVe-0009rK-Sy for multi6@ops.ietf.org; Wed, 29 Oct 2003 14:41:18 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9TEf05u020875; Wed, 29 Oct 2003 07:41:01 -0700 (MST) Received: from lillen (vpn-129-156-96-136.EMEA.Sun.COM [129.156.96.136]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9TEeuS08063; Wed, 29 Oct 2003 15:40:56 +0100 (MET) Date: Wed, 29 Oct 2003 15:40:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , iljitsch@muada.com, multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > +----+ > ----|ISPA|_ +----+ > / +----+ \_+------+ _|ISPC|_ > +----+ | |_/ +----+ \__+----+ > | mh1| _| | _| mh2| > +----+ +----+_/ | |_ / +----+ > \____|ISPB| +------+ \_+----+_/ > +----+ |ISPD| > +----+ > > We are using packet rewriting at site border routers. This means that the > site exit router connection a multihomed site with ISPX will rewrite source > address of packets and it will replace the contained prefix with PX::. Is > this correct? Correct. > Now when the outage occurs, one or both of the communicating nodes can start > to retransmit. > Let's consider that mh1 is the one whose TCP timeouts and that starts to do > some retransmissions. Then TCP at mh1 communicates the shim layer at mh1 > that something wrong is happening. > Then the shim layer changes the destination address that is being used in > the communication from PC::mh2 to PD::mh2. In this way the communication is > rerouted to the alternative ISP. Good! > > Now, suppose that mh2 also obtains a hint that something is wrong (this > could be because TCP at mh2 timeout or because packets start arriving with a > different source address (this last case cannot be guaranteed because it > depends on the internal routing in mh1)). So, mh2 shim layer start using an > alternative destination address, so it switches from PA:mh1 to PB:mh1. > However, this does not solve the problem, since packets addressed to PB:: > are also routed through ISPC. > The problem here is that TCP detects the problem but it has no means to > communicate the problem to the mh2's routing system, who still believes that > a route through ISPC is still available. I thought you expressed concern about potential destructive interference between the endpoints trying different locators and the routing system finding a new path. But in the above example I don't find such destructive interference. (Sure, the worst case performance might not be better than the worst case routing convergence time, but that is a different topic.) So do you see any destructive interference? If not folks can work separately on the multi6 rehoming and improving the convergence time as well as information (such as churn rate) in BGP. > This could be achieved with source address based routing.. the problem here Source address based routing seems like a fair amount of added complications; impacts the hardware/firmware in the routers and what else? It might be easier to work on BGP convergence time. > (Another hint can be the reception of ICMP error messages.) I'm concerned about the threats in that case since the host has no way to assertain whether the ICMP error was generated by a router in the path or some off-path spoofer. Erik From owner-multi6@ops.ietf.org Wed Oct 29 10:43:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14566 for ; Wed, 29 Oct 2003 10:43:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEsSt-000FKC-Gc for multi6-data@psg.com; Wed, 29 Oct 2003 15:42:31 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEsSh-000FJ4-RU for multi6@ops.ietf.org; Wed, 29 Oct 2003 15:42:19 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9TFgAPh023497; Wed, 29 Oct 2003 08:42:11 -0700 (MST) Received: from lillen (vpn-129-156-96-136.EMEA.Sun.COM [129.156.96.136]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9TFg7S18418; Wed, 29 Oct 2003 16:42:08 +0100 (MET) Date: Wed, 29 Oct 2003 16:41:48 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: Kurt Erik Lindqvist Cc: Erik Nordmark , mbagnulo@ing.uc3m.es, iljitsch@muada.com, multi6@ops.ietf.org In-Reply-To: "Your message with ID" <326611FE-09F5-11D8-AB34-000A9598A184@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > To some extent I wonder how much of this is really a multi6 problem. As > you point out, we will never know how long ULP will continue to try > before giving up. This might render ULP hints useless in that > particular case. We also don't know what failure detection is in use > for the ULPs. More, if there is also a rerouting event causing > distribution of bad news, and perhaps a new set of locators, or the > signaling to move to new locators, this might trigger a "race-like" > condition, depending in what order the priorities are set and in which > order they arrive where, and then actually making the case worse - no? I think it makes sense to look for potential destructive interference. It might be that we have to restrict some mechanisms (such as ULP retransmit hints) from affecting the destination locator and others to affect the source locator, and perhaps also specify a preference between the different hints (for instance, the source locator in a received packet might be a stronger indication of what to use in destination packets than the ULP suggesting to use a particular destination locator, or it might be the other way around). But these types of policy considerations for selecting locators is independent of the actual rehoming mechanisms I think. > Would it not be better to simply say that survivability and > "restoration" time is due to these X factors, they can be influenced by > this - but they are not an issue per se for the multi6 layer. They > might depend on ULP signaling, BGP convergence, etc. But that is > another issue. > > Am I making my life to easy here? Perhaps a bit; but the policies can be worked on separately from the mechanisms and the policies can evolve at a different rate in the future. Erik From owner-multi6@ops.ietf.org Wed Oct 29 10:54:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15522 for ; Wed, 29 Oct 2003 10:54:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEse5-000GXk-PR for multi6-data@psg.com; Wed, 29 Oct 2003 15:54:05 +0000 Received: from [194.196.100.238] (helo=d12lmsgate.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEse0-000GX8-Jo for multi6@ops.ietf.org; Wed, 29 Oct 2003 15:54:00 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9TFraNb040062; Wed, 29 Oct 2003 16:53:38 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9TFnWZp227478; Wed, 29 Oct 2003 16:49:32 +0100 Received: from zurich.ibm.com ([9.145.229.81]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA48888; Wed, 29 Oct 2003 16:49:30 +0100 Message-ID: <3F9FDAA3.9BB9656D@zurich.ibm.com> Date: Wed, 29 Oct 2003 16:20:03 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Savola CC: marcelo bagnulo , Erik.Nordmark@sun.com, jordi.palet@consulintel.es, multi6@ops.ietf.org Subject: Re: RV: (ipv6mh) hardware support for extension headers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Actually this depends on which hw designers you talk to, and how carefully they read the IPv6 spec before pouring silicon. But fundamentally, yes, the more rigid the extension header format, the better chance that new ones can be handled on the fast path. Also please remember we are designing for fifty years at least. Today's hw is not the end of the story. Brian Pekka Savola wrote: > > On Mon, 27 Oct 2003, marcelo bagnulo wrote: > > So this means that in the current situation, a solution based on using > > extension headers would impose that packets carrying those new extension > > headers would be diverted through the slow path of every router they go > > through. Is that correct? > > Not precisely.. only those routers which have to go through the packets > with these extension headers via an L4 ACL (most ACLs are like that..). > > > The solution for this would be to change all routers (besides all hosts to > > understand the extension header) or to suffer the performance penalty, is > > this correct? > > Modulo above, yes. > > > If this is so, i don't know if a solution that uses an extension header in > > every packet would be acceptable. > > I think that a solution that only uses extension headers in a few selected > > packets of a communication would be ok. > > IMHO, extension headers *could* be OK, as long as they'd be done in TLV > format, and we specify in IPv6 WG that all the future extension headers > would be done in TLV format, so the implementors could add this to their > ACL code. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-multi6@ops.ietf.org Wed Oct 29 12:23:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21428 for ; Wed, 29 Oct 2003 12:23:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEu1H-000OTg-Oj for multi6-data@psg.com; Wed, 29 Oct 2003 17:22:07 +0000 Received: from [194.196.100.238] (helo=d12lmsgate.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEu1D-000OTA-BM for multi6@ops.ietf.org; Wed, 29 Oct 2003 17:22:03 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9THM2Nb047544 for ; Wed, 29 Oct 2003 18:22:02 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9THM1Zp127994 for ; Wed, 29 Oct 2003 18:22:01 +0100 Received: from zurich.ibm.com ([9.145.174.1]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA24970 for ; Wed, 29 Oct 2003 18:22:00 +0100 Message-ID: <3F9FF717.F93E3384@zurich.ibm.com> Date: Wed, 29 Oct 2003 18:21:27 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: draft-nordmark-multi6-sim-00.txt References: <148401c39b48$7e49eb30$9402a8c0@consulintel.es> <6ACEE302-07CE-11D8-95B0-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Er, the diffserv field isn't available for that... we use it for diffserv... And I wish people would think about routers that will be shipped ten or fifty years from now. If the solution is sub-optimal for today's hardware, that should not in itself be a show-stopper. Brian Iljitsch van Beijnum wrote: > > On 26 okt 2003, at 0:36, JORDI PALET MARTINEZ wrote: > > > Regarding your draft draft-nordmark-multi6-sim-00.txt, I'm interested > > to know if you are considered the implications of using the > > next header field ?. Let me explain. > > [doing special header processing is expensive in routers with hardware > IPv6 support] > > Yes, this is a good point. I like the idea of using the 6 bit diffserv > field for this. This field is modifyable in transit and doesn't impact > any processing at the receiving end or in routers that don't support > diffserv or type of service processing. > > There is a slight disadvantage that this field is only 6 bits, but I > don't think it's necessary to populate all possible combinations of > service levels and yes/no on the rewriting, so in practice this > shouldn't have to be a huge problem. From owner-multi6@ops.ietf.org Wed Oct 29 14:42:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00669 for ; Wed, 29 Oct 2003 14:42:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEwBQ-000Ams-7f for multi6-data@psg.com; Wed, 29 Oct 2003 19:40:44 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEwBL-000Am2-Ji for multi6@ops.ietf.org; Wed, 29 Oct 2003 19:40:39 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 91C6122F; Wed, 29 Oct 2003 20:40:38 +0100 (CET) Received: from shem.uc3m.es (shem.uc3m.es [163.117.136.124]) by smtp03.uc3m.es (Postfix) with SMTP id 7F63E228; Wed, 29 Oct 2003 20:40:38 +0100 (CET) From: To: Erik.Nordmark@sun.com Cc: multi6@ops.ietf.org Subject: About carring information in the next header value Date: Wed, 29 Oct 2003 20:40:38 +0100 (CET) X-Real-Sender: mbagnulo@ing.uc3m.es X-Mailer: Postman 1.12rev.uc3m1 Message-ID: <2882972311mbagnulo@ing.uc3m.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=BAYES_00, NEW_DOMAIN_EXTENSIONS,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable SIM uses two new next header values The next header format for these two values is the same, since the=20 different values are only=20 used to encode the rewrite ok bit, is this correct? Question, where is this next header placed in the chain of extension=20 headers? I guess that since routers must look for it when deciding whehter to=20 rewrite or=20 not a source address it would make it more efficient to place it in the=20 first place, even before=20 hop by hop options. But if this is so, wouldn't this be a problem to=20 process hop by hop options? The other options would be to place next to destination option header,=20 where i guess is the=20 right place for it, but in this case, the site exit routers would have=20 to look over the=20 extension header to find out whehter they should rewrite a source=20 address or not. The other issue with new extension headers is that host must discard=20 unknown extension headers. This may be a problem for the interaction between M6 hosts and legacy=20 hosts, since the=20 first packet would be discarded, and the way to find this out is the=20 recpetiuon of icmp packet.=20 Considering the potential wide deployment of ICMP filtering, this may=20 lead to importat delay=20 when establishing communications between m6 hosts and legacy hosts. Perhaps an option would be to use a Destination option instead of an=20 extension header. This would allow to define the way the detination option would be=20 processed by the legacy host,=20 for instance, it can be defined that the host shoudl process the packet=20 and just skip the=20 unknown option. This would allow to process the initial packet and also=20 to obtain a more=20 reliable feedback of the capabilities of the target host. The problem with this aproach is that it is not possible to encode the=20 rewrite ok=20 in the main IPv6 header using destiantion options. However, this could=20 be encoded inside=20 the destiantion option itself. Note that if only the destiantion option is present in the packet, the=20 bit encoding rewrite=20 ok is in a fixed location and while it is not in the main ipv6 header,=20 it should be easy to=20 find by the exit routers, i guess. If there are more extension headers in the packet, router will have to=20 parse the extension=20 header chain in both cases is guess, so i don't see much benefits in=20 this case. The other option is could be the following (i am not sure this would=20 work though, i still don't understand SIM very well:-( Use a destiantion option in initial packets. If i understand correctly,=20 initial packets=20 are those whose source address cannot be rewritten. Also those iniotial=20 packets are the one that are used to define if the target node supports M6 or not Then if the target node supports M6 and once that the context has been=20 created, start using=20 the new extension header. This extension header means that the rewrite=20 ok bit is set. So this option has most of the benefits i guess: It allows the detection of M6 support at the target node without=20 discarding the first packet and obtaining a reliable answer (no icmp involved) It allows a easy access to rewrite ok bit by the site exit routers when=20 it is needed (not the inital=20 packets) It don't wastes two next header values Anyway, i guess the most efficient option is the one presented in noid,=20 that uses the nextheader=20 and the flow label fields to carry the inforamtion in data packets. I have a doubt about how the next header values are defined. My first question is: do you define 2 values of next header for the =20 every ulp protocol,=20 covering the rewrite ok set and the rewrite ok not set, is this correct? So you are not defining two values for the values of next header that=20 define an extension header, like routing header, hop by hop, etc. why is that, is becasue there are=20 not enough next=20 header values? the problem with doing so, is that when an extension header is=20 included, the site exit routers=20 will have to parse all the extension headers until they find the ulp=20 next header. Wouldn't this=20 be a problem for efficiency? Perhaps this is not a very common case,=20 though.=20 Addtionally, I guess that you would like to preserve the values=20 currently defined for ulp, at=20 least fot compatibility with legacy hosts, but i am not sure if this is=20 accomplished now as=20 currently defined in section 6 of the noid doc. I guess it would make more sense to define currently assigned ULP=20 values to the case when=20 the rewrite bit is not set, since legacy host would not recognize=20 packets with modifed locators. So my conclusion is that in order to ensure bacward compatibility and=20 efficiency: Initial packets should carry M6 information in a new destination option. Initial packets carry next headers values for ULP as currenlty defined following packets that use the M6 protocol carry the tag information in=20 the flow label value and encode the rewrite bit in newly defined ULP next header values (and no=20 extension header) Does this makes sense? =20 Thanks, marcelo From owner-multi6@ops.ietf.org Wed Oct 29 14:43:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00804 for ; Wed, 29 Oct 2003 14:43:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEwDc-000Ayr-Bv for multi6-data@psg.com; Wed, 29 Oct 2003 19:43:00 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEwDV-000Axg-Ob for multi6@ops.ietf.org; Wed, 29 Oct 2003 19:42:53 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8D05023E; Wed, 29 Oct 2003 20:42:52 +0100 (CET) Received: from shem.uc3m.es (shem.uc3m.es [163.117.136.124]) by smtp03.uc3m.es (Postfix) with SMTP id 5FF2923C; Wed, 29 Oct 2003 20:42:52 +0100 (CET) From: To: iljitsch@muada.com Cc: multi6@ops.ietf.org Subject: Crypto-based host identifiers Date: Wed, 29 Oct 2003 20:42:52 +0100 (CET) X-Real-Sender: mbagnulo@ing.uc3m.es X-Mailer: Postman 1.12rev.uc3m1 Message-ID: <3297252547mbagnulo@ing.uc3m.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I have some questions about this psposal: Why do you set the group bit to "group"? i mean, it is not a multi-cast=20 address, right? I still don't understand the need for a new public registry. You also mention the need to use the DNS, wouldn't be enough to use=20 only the DNS? If i understnd correctly, you need the new registry, because in order=20 to avoid collisions, right? But a collision means that someone else has the private key that=20 matches the hash of=20 someone else's public key. This situation by itself it is a=20 vulnerability=20 to the solution isn't it?, since if it has such a private key it can=20 impersonate=20 the original holder, right? So, in order to overcome this, you propose the usage of the DNS, is=20 this correct? My question is then, why don't you use only the DNS and avoid the new=20 registry? The new public registry may not be so simple than just a list of=20 allocted site prefixes,=20 i mean, you have to protect from several type of attacks, for instance=20 depletion attacks,=20 where a malicious part starts registering site prefixes in a bulk=20 fashion. You can address this charging a fee, but as you see things get more=20 complicated. Another question, how do you generate the host part of the CBHI? i=20 can't find it in=20 the document. I guess it would be a hash of its own public key. My question then is why do you want a site key and a host key? i don't=20 see any benefit of=20 its usage in the current document. Why don't you just use a host key,=20 just a regular CGA? Another issue related to this, what is the benefit of using 64 bits=20 long identifiers. I mean, TCP and other ULP use 128 bit long identifiers so you will have to=20 complete the 128 bits or=20 modify the ULP. I guess that you will complete the 128 bits, so why=20 don't you just use them all to contain a key. I guess that the benefit would be that you can carry=20 both the locator and=20 the identifier in the address field of the IPv6 packet and that you can=20 obtain them in a regular DNS AAAA query, but i don't know how important is this. First you don't=20 really need to carry the identifier in all packets, once that the context is set up, you=20 just carry the locators=20 and things should work, i guess. Second, storing the 128 bit long in=20 the DNS as a new RR=20 wouldn't be complex, and it could be used to distinguish host that=20 support the new mechanism=20 form those who don't.=20 Besides, using 64 bit only for the id really introduces some=20 limitations as the ones mentioned=20 above, so i still don't see clearly why this is a good option. Another issue is related to section 6 turning site id into prefixes. Why don't you use a Hinden Haberman local scope address prefix insted=20 of asking for=20 a new address range for this usage? About the addres authentication section. I don't understand some parts of the procedure, for instance in step 7=20 (the 7th -) you say that B also looks up B's site identifier in the DNS, shouldn' B already know=20 its own site id? or is that B looks A's site identifier in the DNS? the same question=20 about the next sub-step (*) about B checking B's public keys. As a final observation, this proposal uses public key crypto and DNS=20 querys to provide security,=20 (and if i understand correctly, it imposes a DNS query to the target=20 node (B) which is not=20 currently needed in a communication i.e. it is like imposing that A=20 performs a DNS query,=20 which would mean that when A performs the regular AAAA query it would=20 also obtain additioanl info,=20 such as a new RR), besides it also requires a new public registry. So in brief this seems lika a pretty expensive mechanism to me,=20 couldn't you provide some similar=20 level of security using just one of them, for instance just public key=20 crypto like HIP?=20 In other words, what are the benefits obtaine after incurring in all=20 these additional costs?=20 Thanks, marcelo From owner-multi6@ops.ietf.org Wed Oct 29 16:05:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06219 for ; Wed, 29 Oct 2003 16:05:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AExT8-000Ifu-Dd for multi6-data@psg.com; Wed, 29 Oct 2003 21:03:06 +0000 Received: from [195.43.225.73] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AExT4-000IfK-T0 for multi6@ops.ietf.org; Wed, 29 Oct 2003 21:03:03 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9TL2nPk002216; Wed, 29 Oct 2003 22:02:49 +0100 (CET) Date: Wed, 29 Oct 2003 22:02:40 +0100 Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: mbagnulo@ing.uc3m.es, iljitsch@muada.com, multi6@ops.ietf.org To: Erik Nordmark From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <3B729725-0A53-11D8-AB34-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On onsdag, okt 29, 2003, at 16:41 Europe/Stockholm, Erik Nordmark wrote: > > But these types of policy considerations for selecting locators is > independent of the actual rehoming mechanisms I think. Agreed. >> Would it not be better to simply say that survivability and >> "restoration" time is due to these X factors, they can be influenced >> by >> this - but they are not an issue per se for the multi6 layer. They >> might depend on ULP signaling, BGP convergence, etc. But that is >> another issue. >> >> Am I making my life to easy here? > > Perhaps a bit; but the policies can be worked on separately from the > mechanisms and the policies can evolve at a different rate in the > future. > Would it make sense to add that into the next version of the draft? Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP6Aq9qarNKXTPFCVEQLwjACfcYbGX9ST9+BTBlYCbIWbm9KF3ucAoNJT 4GXUlmRfWOoDaJOad5BynVLO =/+Ez -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Oct 29 16:26:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07070 for ; Wed, 29 Oct 2003 16:26:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AExoZ-000KbA-Tc for multi6-data@psg.com; Wed, 29 Oct 2003 21:25:15 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AExoT-000KaB-DI for multi6@ops.ietf.org; Wed, 29 Oct 2003 21:25:09 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9TLOxed019413; Wed, 29 Oct 2003 22:24:59 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5E11E466-0A56-11D8-A0C6-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Wed, 29 Oct 2003 22:25:06 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 29 okt 2003, at 15:40, Erik Nordmark wrote: >> This could be achieved with source address based routing.. the >> problem here > Source address based routing seems like a fair amount of added > complications; impacts the hardware/firmware in the routers and what > else? Many routers already support policy routing in hardware. Source address based routing is a subset of full policy routing. I don't see much of a problem in the long run. > It might be easier to work on BGP convergence time. I actually have an idea for avoiding the BGP version of the count to infinity problem... Is this on topic now for this wg? :-) From owner-multi6@ops.ietf.org Wed Oct 29 16:31:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07777 for ; Wed, 29 Oct 2003 16:31:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AExtv-000L74-TH for multi6-data@psg.com; Wed, 29 Oct 2003 21:30:47 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AExtt-000L6A-2B for multi6@ops.ietf.org; Wed, 29 Oct 2003 21:30:45 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9TLUZed019478; Wed, 29 Oct 2003 22:30:35 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3F9FF717.F93E3384@zurich.ibm.com> References: <148401c39b48$7e49eb30$9402a8c0@consulintel.es> <6ACEE302-07CE-11D8-95B0-00039388672E@muada.com> <3F9FF717.F93E3384@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <269A8BFA-0A57-11D8-A0C6-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: draft-nordmark-multi6-sim-00.txt Date: Wed, 29 Oct 2003 22:30:43 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 29 okt 2003, at 18:21, Brian E Carpenter wrote: > Er, the diffserv field isn't available for that... we use it > for diffserv... Using diffserv for signalling whether rewriting is allowed doesn't get too much in the way of regular diffserv use. (Hm, didn't we have a very similar discussion just recently?) Worst case, twice the number of code points would be needed: one for service level x without rewriting and one for service level x with rewriting, one for service level y without rewriting... Best case, only a single DSCP would be used up: default without rewriting, in addition to default with rewriting and all other service levels with rewriting. > And I wish people would think about routers that will be shipped ten > or fifty > years from now. If the solution is sub-optimal for today's hardware, > that > should not in itself be a show-stopper. Interesting point. I sort of agree. I don't think it applies here, though. Using the diffserv bits is the most logical and cleanest choice if we can make it work, and I believe we can. From owner-multi6@ops.ietf.org Wed Oct 29 16:58:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09097 for ; Wed, 29 Oct 2003 16:58:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEyJD-000N1P-Bq for multi6-data@psg.com; Wed, 29 Oct 2003 21:56:55 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEyJ9-000N0v-68 for multi6@ops.ietf.org; Wed, 29 Oct 2003 21:56:51 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9TLuaed019788; Wed, 29 Oct 2003 22:56:36 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3297252547mbagnulo@ing.uc3m.es> References: <3297252547mbagnulo@ing.uc3m.es> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Crypto-based host identifiers Date: Wed, 29 Oct 2003 22:56:44 +0100 To: X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 29 okt 2003, at 20:42, wrote: > Why do you set the group bit to "group"? i mean, it is not a multi-cast > address, right? Nope. It's just that this gives us the largest block of unused EUI-64 space. All potential values with the u/l bit set to "local" may be used by RFC 3041, while all values with the u/l bit set to "universal" and the group bit unset are governed by the IEEE and a good number of these values are in use. In theory this also goes for the universal + group=yes values (see Radia Perlman's discussion of MAC addresses in "routers and switches" (first edition, not sure if it's in the second one)) but in practice I don't see how this could be an issue. > I still don't understand the need for a new public registry. To quickly discover colliding hashes. > You also mention the need to use the DNS, wouldn't be enough to use > only the DNS? The problem with the DNS is that there are some organizations that seem to think they have authority over what's in it. That's not what we want for this. So sure, put a copy of the data in the DNS, but don't make the DNS the authorative source of this information. > If i understnd correctly, you need the new registry, because in order > to avoid collisions, right? But a collision means that someone else > has the private key that matches the hash of someone else's public > key. This situation by itself it is a vulnerability to the solution > isn't it?, since if it has such a private key it can impersonate the > original holder, right? Yes. Fortunately it isn't as bad as it sounds. Suppose you're making a 44 bit has and there are already 2^24 hashes in use. You then have a 1 in 2^20 chance of colliding with an existing hash. However, the chance that you're going to collide with Google, Microsoft or the White House is significantly smaller than the chance you're going to collide with a grocery store in Milan, a home office in New Jersy or a cell phone in Osaka, which aren't nearly as much fun to impersonate. Also, as soon as you use your fake hash and someone detects it, you're found out and the holder of the original hash is going to abandon it. So you have to make the first time that you're going to abuse the colliding hash count real good because it's likely it's your only chance. > So, in order to overcome this, you propose the usage of the DNS, is > this correct? Yes, DNS or some other way of distributing the full public keys can be used to add extra security. > My question is then, why don't you use only the DNS and avoid the new > registry? I don't see the new registry as a huge problem. Could be as simple as a bunch of PGP key servers. > The new public registry may not be so simple than just a list of > allocted site prefixes, Why not? > i mean, you have to protect from several type of attacks, for instance > depletion attacks, where a malicious part starts registering site > prefixes in a bulk fashion. If people generate these keys I would rather have them registered than kept secret... Not much we can do if people are inclined to do this. > Another question, how do you generate the host part of the CBHI? i > can't find it in the document. I guess it would be a hash of its own > public key. It isn't generated, just a simple number, start at 0, increase for each new host... > My question then is why do you want a site key and a host key? i don't > see any benefit of its usage in the current document. Why don't you > just use a host key, just a regular CGA? Host keys don't have internal structure so they can't be put in the DNS in large enough numbers. With the site as an intermediate step there should be enough hierarchical structure to be able to put them in the DNS. > Another issue related to this, what is the benefit of using 64 bits > long identifiers. I mean, TCP and other ULP use 128 bit long > identifiers so you will have to complete the 128 bits or modify the > ULP. I guess that you will complete the 128 bits, so why don't you > just use them all to contain a key. I guess that the benefit would be > that you can carry > both the locator and the identifier in the address field of the IPv6 > packet and that you can obtain them in a regular DNS AAAA query, but i > don't know how important is this. I'm not too interested in the AAAA query. What I want to accomplish is that the identifier remains the same and visible in each packet even though the locator prefix changes. > Another issue is related to section 6 turning site id into prefixes. > Why don't you use a Hinden Haberman local scope address prefix insted > of asking for a new address range for this usage? Basically what I'm doing is taking GSE/8+8 and modifying it a bit to make it compatible with current IPv6 implementations. On the wire, the top 64 bits (the locator part) can change while only the lower 64 bits (the identifier) remains the same end-to-end. However, current protocols don't understand this. Rather than change routers to route based on the low 64 bits, change TCP and UDP checksums and so on, we do some magic and suddenly we have something that looks enough like a regular prefix to be used by existing hosts and routers. The multihoming can then be done by a proxy multihoming box. > About the addres authentication section. > I don't understand some parts of the procedure, for instance in step 7 > (the 7th -) you say that B also looks up B's site identifier in the > DNS, shouldn' B already know its own site id? or is that B looks A's > site identifier in the DNS? the same question about the next sub-step > (*) about B checking B's public keys. Correct, it should be A. Sorry... > As a final observation, this proposal uses public key crypto and DNS > querys to provide security, (and if i understand correctly, it > imposes a DNS query to the target node (B) which is not currently > needed in a communication Use of the DNS isn't required for regular operation, only when additional security is desired. However, the same results can be achieved without using the DNS. For instance, a site could periodically download all known public keys and store them locally. Iljitsch From owner-multi6@ops.ietf.org Thu Oct 30 04:36:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15067 for ; Thu, 30 Oct 2003 04:36:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AF9BD-0004Lh-Ih for multi6-data@psg.com; Thu, 30 Oct 2003 09:33:23 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AF9B8-0004LS-NG for multi6@ops.ietf.org; Thu, 30 Oct 2003 09:33:18 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id DD00B431DA; Thu, 30 Oct 2003 10:33:17 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp02.uc3m.es (Postfix) with ESMTP id E49E89A030; Thu, 30 Oct 2003 10:33:16 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: , Erik.Nordmark@sun.com Subject: Re: About carring information in the next header value Date: Thu, 30 Oct 2003 10:33:14 +0100 User-Agent: KMail/1.5.4 Cc: multi6@ops.ietf.org References: <2882972311mbagnulo@ing.uc3m.es> In-Reply-To: <2882972311mbagnulo@ing.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310301033.14821.jrh@it.uc3m.es> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 29 October 2003 20:40, mbagnulo@ing.uc3m.es wrote: [snipped] > Anyway, i guess the most efficient option is the one presented in noid, > that uses the nextheader > and the flow label fields to carry the inforamtion in data packets. > I have a doubt about how the next header values are defined. > My first question is: do you define 2 values of next header for the > every ulp protocol, > covering the rewrite ok set and the rewrite ok not set, is this correct? I think so, but only for the well-known UPL protocols and the others are managed using a cuople of values + an extra extension header which carries the actual UPL value. > So you are not defining two values for the values of next header that > define an extension header, > like routing header, hop by hop, etc. why is that, is becasue there are > not enough next > header values? I don't think so, I think that it is because it's only interesting to define new values for the well-known upper layer values. If you define new values for hop by hop, routing header, etc, routers already in the market won't be able to process this new values and they will throw away the packets. > the problem with doing so, is that when an extension header is > included, the site exit routers > will have to parse all the extension headers until they find the ulp > next header. Wouldn't this > be a problem for efficiency? Perhaps this is not a very common case, > though. It's not going to be the common case, I agree with you. RFC 2460 specifies that: "extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node" There is an exception, the hop-by-hop header. So I agree with you that this should be more elaborated. > Addtionally, I guess that you would like to preserve the values > currently defined for ulp, at > least fot compatibility with legacy hosts, There is no compatibility problem with legacy host. If hosts implement NOID, they will interact perfectly. On the other hand, if a host doesn't implement NOID, it will send and receive "normal" packets. It will send normal packets because it doesn't know anything about NOID, and it will receive normal packets because the peer demultiplexes on wheter a packet is an M6 packet. >but i am not sure if this is > accomplished now as > currently defined in section 6 of the noid doc. > I guess it would make more sense to define currently assigned ULP > values to the case when > the rewrite bit is not set, since legacy host would not recognize > packets with modifed locators. That's not possible, because the new protocols values are used for two reasons: 1. To still know what's up the IP layer (the normal use of the next protocol field) 2. To know if the peer has NOID capabilities. You can not find out if the peer knows about NOID when the rewrite bit isn't set, if you use what you're telling. [snipped] Erik, I like your draft but I think this is useful once both peers have already obtained the state. I don't know if somebody else has asked you this, but I think this draft is weak on the stablishment of the states, because until you aren't able to re-write, you still have all the problems the muli6 WG is trying to solve. Cheers! -- JFRH From owner-multi6@ops.ietf.org Thu Oct 30 04:42:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15256 for ; Thu, 30 Oct 2003 04:42:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AF9K7-0004hK-B4 for multi6-data@psg.com; Thu, 30 Oct 2003 09:42:35 +0000 Received: from [194.196.100.238] (helo=d12lmsgate.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AF9Jw-0004h0-Au for multi6@ops.ietf.org; Thu, 30 Oct 2003 09:42:24 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9U9gENb099110; Thu, 30 Oct 2003 10:42:14 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9U9gDLh273906; Thu, 30 Oct 2003 10:42:14 +0100 Received: from zurich.ibm.com (sig-9-145-139-104.de.ibm.com [9.145.139.104]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA67132; Thu, 30 Oct 2003 10:42:12 +0100 Message-ID: <3FA0DCD4.B0FDD247@zurich.ibm.com> Date: Thu, 30 Oct 2003 10:41:40 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: multi6@ops.ietf.org Subject: Re: draft-nordmark-multi6-sim-00.txt References: <148401c39b48$7e49eb30$9402a8c0@consulintel.es> <6ACEE302-07CE-11D8-95B0-00039388672E@muada.com> <3F9FF717.F93E3384@zurich.ibm.com> <269A8BFA-0A57-11D8-A0C6-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On 29 okt 2003, at 18:21, Brian E Carpenter wrote: > > > Er, the diffserv field isn't available for that... we use it > > for diffserv... > > Using diffserv for signalling whether rewriting is allowed doesn't get > too much in the way of regular diffserv use. (Hm, didn't we have a very > similar discussion just recently?) I think it does. There are moves afoot to define recommended service classes and recommended DSCP mappings (for example draft-baker-diffserv-basic-classes-**.txt) and overloading these bits within a mere 6 bit code space seems to me to be one bridge too far. I'd much rather look at using two different flow labels, where we have a much larger code space and no suggestion of pre-existing semantics. > > Worst case, twice the number of code points would be needed: one for > service level x without rewriting and one for service level x with > rewriting, one for service level y without rewriting... Best case, only > a single DSCP would be used up: default without rewriting, in addition > to default with rewriting and all other service levels with rewriting. > > > And I wish people would think about routers that will be shipped ten > > or fifty > > years from now. If the solution is sub-optimal for today's hardware, > > that > > should not in itself be a show-stopper. > > Interesting point. I sort of agree. I don't think it applies here, > though. Using the diffserv bits is the most logical and cleanest choice > if we can make it work, and I believe we can. My point is that even if people think it is slow to look at an extra header today, this is probably irrelevant in the long term. Brian From owner-multi6@ops.ietf.org Thu Oct 30 06:36:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18326 for ; Thu, 30 Oct 2003 06:36:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFB4U-0008ua-Gs for multi6-data@psg.com; Thu, 30 Oct 2003 11:34:34 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFB4R-0008uL-Nb for multi6@ops.ietf.org; Thu, 30 Oct 2003 11:34:32 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9UBYHed028751; Thu, 30 Oct 2003 12:34:17 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3FA0DCD4.B0FDD247@zurich.ibm.com> References: <148401c39b48$7e49eb30$9402a8c0@consulintel.es> <6ACEE302-07CE-11D8-95B0-00039388672E@muada.com> <3F9FF717.F93E3384@zurich.ibm.com> <269A8BFA-0A57-11D8-A0C6-00039388672E@muada.com> <3FA0DCD4.B0FDD247@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <033B7F0A-0ACD-11D8-A0C6-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: draft-nordmark-multi6-sim-00.txt Date: Thu, 30 Oct 2003 12:34:24 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 30 okt 2003, at 10:41, Brian E Carpenter wrote: >> Using diffserv for signalling whether rewriting is allowed doesn't get >> too much in the way of regular diffserv use. > I think it does. There are moves afoot to define recommended service > classes and recommended DSCP mappings (for example > draft-baker-diffserv-basic-classes-**.txt) Why??? I'm continously amazed by what the IETF does and does not find useful work. > and overloading these bits within > a mere 6 bit code space seems to me to be one bridge too far. Maybe we should hear from people who are using diffserv operationally. > I'd much rather > look at using two different flow labels, where we have a much larger > code > space and no suggestion of pre-existing semantics. Except that you're not supposed to change the flow label for a packet / session, and the fact that many existing hosts come up with random flow labels so it's impossible to set aside values. >>> And I wish people would think about routers that will be shipped ten >>> or fifty years from now. If the solution is sub-optimal for today's >>> hardware, that should not in itself be a show-stopper. >> Interesting point. I sort of agree. I don't think it applies here, >> though. Using the diffserv bits is the most logical and cleanest >> choice >> if we can make it work, and I believe we can. > My point is that even if people think it is slow to look at an extra > header > today, this is probably irrelevant in the long term. And my point was that using the diffserv field is the logical choice, irrespective of the performance of other candidates. So the question is whether there is a reason that invalidates overloading diffserv. This is where we disagree. However, the meta-question is whether we can come up with something that can ALWAYS work, or if we have to create several alternatives that cater to different needs. I think using the next header field isn't going to to be popular with the firewall crowd. DSCP and flow label may have similar problems. From owner-multi6@ops.ietf.org Thu Oct 30 09:05:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22596 for ; Thu, 30 Oct 2003 09:05:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFDNa-000EYb-Td for multi6-data@psg.com; Thu, 30 Oct 2003 14:02:26 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFDNX-000EY5-5C for multi6@ops.ietf.org; Thu, 30 Oct 2003 14:02:23 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 14FBF313; Thu, 30 Oct 2003 15:02:22 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp03.uc3m.es (Postfix) with SMTP id 8C22330F; Thu, 30 Oct 2003 15:02:21 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , Cc: Subject: RE: About carring information in the next header value Date: Thu, 30 Oct 2003 14:56:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <2882972311mbagnulo@ing.uc3m.es> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I apologize for the format of this email (i was using a different email client and things went wrong, sorry) I send it again with a better format (i hope) Regards, marcelo SIM uses two new next header values The next header format for these two values is the same, since the different values are only used to encode the rewrite ok bit, is this correct? Question, where is this next header placed in the chain of extension headers? I guess that since routers must look for it when deciding whehter to rewrite or not a source address it would make it more efficient to place it in the first place, even before hop by hop options. But if this is so, wouldn't this be a problem to process hop by hop options? The other options would be to place next to destination option header, where i guess is the right place for it, but in this case, the site exit routers would have to look over the extension header to find out whehter they should rewrite a source address or not. The other issue with new extension headers is that host must discard unknown extension headers. This may be a problem for the interaction between M6 hosts and legacy hosts, since the first packet would be discarded, and the way to find this out is the recpetiuon of icmp packet. Considering the potential wide deployment of ICMP filtering, this may lead to importat delay when establishing communications between m6 hosts and legacy hosts. Perhaps an option would be to use a Destination option instead of an extension header. This would allow to define the way the detination option would be processed by the legacy host, for instance, it can be defined that the host shoudl process the packet and just skip the unknown option. This would allow to process the initial packet and also to obtain a more reliable feedback of the capabilities of the target host. The problem with this aproach is that it is not possible to encode the rewrite ok in the main IPv6 header using destiantion options. However, this could be encoded inside the destiantion option itself. Note that if only the destiantion option is present in the packet, the bit encoding rewrite ok is in a fixed location and while it is not in the main ipv6 header, it should be easy to find by the exit routers, i guess. If there are more extension headers in the packet, router will have to parse the extension header chain in both cases is guess, so i don't see much benefits in this case. The other option is could be the following (i am not sure this would work though, i still don't understand SIM very well:-( Use a destiantion option in initial packets. If i understand correctly, initial packets are those whose source address cannot be rewritten. Also those iniotial packets are the one that are used to define if the target node supports M6 or not Then if the target node supports M6 and once that the context has been created, start using the new extension header. This extension header means that the rewrite ok bit is set. So this option has most of the benefits i guess: It allows the detection of M6 support at the target node without discarding the first packet and obtaining a reliable answer (no icmp involved) It allows a easy access to rewrite ok bit by the site exit routers when it is needed (not the inital packets) It don't wastes two next header values Anyway, i guess the most efficient option is the one presented in noid, that uses the nextheader and the flow label fields to carry the inforamtion in data packets. I have a doubt about how the next header values are defined. My first question is: do you define 2 values of next header for the every ulp protocol, covering the rewrite ok set and the rewrite ok not set, is this correct? So you are not defining two values for the values of next header that define an extension header, like routing header, hop by hop, etc. why is that, is becasue there are not enough next header values? the problem with doing so, is that when an extension header is included, the site exit routers will have to parse all the extension headers until they find the ulp next header. Wouldn't this be a problem for efficiency? Perhaps this is not a very common case, though. Addtionally, I guess that you would like to preserve the values currently defined for ulp, at least fot compatibility with legacy hosts, but i am not sure if this is accomplished now as currently defined in section 6 of the noid doc. I guess it would make more sense to define currently assigned ULP values to the case when the rewrite bit is not set, since legacy host would not recognize packets with modifed locators. So my conclusion is that in order to ensure bacward compatibility and efficiency: Initial packets should carry M6 information in a new destination option. Initial packets carry next headers values for ULP as currenlty defined following packets that use the M6 protocol carry the tag information in the flow label value and encode the rewrite bit in newly defined ULP next header values (and no extension header) Does this makes sense? Thanks, marcelo From owner-multi6@ops.ietf.org Thu Oct 30 10:03:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24414 for ; Thu, 30 Oct 2003 10:03:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFEJr-000HBy-Kw for multi6-data@psg.com; Thu, 30 Oct 2003 15:02:39 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFEJm-000HAx-M6 for multi6@ops.ietf.org; Thu, 30 Oct 2003 15:02:34 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C2939334; Thu, 30 Oct 2003 16:02:33 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp03.uc3m.es (Postfix) with SMTP id A4EEB32F; Thu, 30 Oct 2003 16:02:33 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Spencer Dawkins" , Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Thu, 30 Oct 2003 15:56:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <0b3301c39e1b$b41f6d90$0400a8c0@DFNJGL21> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Spencer, > Agreed, but I'm not sure everyone else in the IETF agrees. It Would Be > Lovely to pick a target (TCP survivability, HTTP survivability, VoIP > survivability being three rough possibilities) and agree on it. What do you mean? That the M6 layer should provide 3 types of service, TCP HTTP and VoIP like services and that the app can select it? Or perhaps an automatic selection based in the port/protocol combination that is being used? Or just that we should have theses 3 services as reference? Regards, marcelo From owner-multi6@ops.ietf.org Thu Oct 30 10:29:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26688 for ; Thu, 30 Oct 2003 10:29:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFEj7-000IOW-Pn for multi6-data@psg.com; Thu, 30 Oct 2003 15:28:45 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFEj4-000IOJ-Ch for multi6@ops.ietf.org; Thu, 30 Oct 2003 15:28:42 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A547B331; Thu, 30 Oct 2003 16:02:33 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp03.uc3m.es (Postfix) with SMTP id 8F65632A; Thu, 30 Oct 2003 16:02:33 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Kurt Erik Lindqvist" , "Erik Nordmark" Cc: , Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Thu, 30 Oct 2003 15:56:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <326611FE-09F5-11D8-AB34-000A9598A184@kurtis.pp.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kurtis, I am including answers to both of your emails referring this topic in this one. Kurtis wrote: > Isn't this simply expectation management? The reason we changed the > requirements into goals was because the items in the document where > either contradictory; we realized that we couldn't get it all so make > it all requirements wasn't an option; and we couldn't decide on what > issues where needed more than others; ? > Well i am not sure this the case of session survivability, at least right now. I mean, i don't think that providing transport session survivability is contradictory with another of the requirements, it is just that providing it is expensive. > I think that connection survivability is a nice to have, IMHO is more than that. It is the main problem that we have. I mean, all other aspects of multihoming are simpler to solve than this one i guess. The preservation of established sessions is the only requirements that its support imposes modifications of both sites of the communication. this implies that hosts *outside* the multihomed site will need to be upgraded in order to support this feature of the multi-homing solution. This is IMHO a great effort with a really important cost. This cost is justified only if it is an important feature, i guess. If session preservation is a nce to have feature, we could just don't provide it and provide a multi-homing solution that only imposes modifications to the multi-homed site. Such a solution would be more easily accepted and deployed, since only the ones that obtain a direct benefit has to upgrade their systems. But I would say that this is not the case, people have been saying that the preservation of established communication is important. > but wether a > connection will survive or not will also be highly dependent on the ULP > as Erik points out. I think this is best handled by simply documenting > what this solution offers, and what the alternatives for the ULPs are. > I think that we can do a bit more than that. I guess that we can provide some ways to allow M6 compatible ULP to obtain an enhaced service. I mean: Different ULP have different needs, so it seems expensive (and perhaps useless) to provide a general solution that satisfies the more demanding needs. So the approach that is proposed would be: The general M6 layer provides a general service, for instance based in current bgp response times Also, the M6 accepts hints from modified ULP that have more demanding requirements. This would enable that if an ULP is capable of detecting outages more quickly than the generic M6 layer it can signal it to the M6 layer so that it can react somehow This presents some potential difficulties like the ones you point out: > More, if there is also a rerouting event causing > distribution of bad news, and perhaps a new set of locators, or the > signaling to move to new locators, this might trigger a "race-like" > condition, depending in what order the priorities are set and in which > order they arrive where, and then actually making the case worse - no? I guess that we should try to see if it is possible to design a solution that a avoids that. > Would it not be better to simply say that survivability and > "restoration" time is due to these X factors, they can be influenced by > this - but they are not an issue per se for the multi6 layer. Yes, but IMHO we should define those potential hints and also define the interaction among them. Do you agree? Regards, marcelo > They > might depend on ULP signaling, BGP convergence, etc. But that is > another issue. > > Am I making my life to easy here? > > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.2 > > iQA/AwUBP5+NMKarNKXTPFCVEQLuTQCg8NTn1V0mniEDuTYQCybs3cyLFnUAoIq+ > 6m1xmITLki2bShj/JcERogDm > =DI3I > -----END PGP SIGNATURE----- > > From owner-multi6@ops.ietf.org Thu Oct 30 10:33:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26950 for ; Thu, 30 Oct 2003 10:33:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFEn3-000Iba-D9 for multi6-data@psg.com; Thu, 30 Oct 2003 15:32:49 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFEmz-000Ib5-77 for multi6@ops.ietf.org; Thu, 30 Oct 2003 15:32:45 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9DEE8317; Thu, 30 Oct 2003 16:32:43 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp03.uc3m.es (Postfix) with SMTP id 8896F316; Thu, 30 Oct 2003 16:32:43 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: , Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Thu, 30 Oct 2003 16:27:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > +----+ > > ----|ISPA|_ +----+ > > / +----+ \_+------+ _|ISPC|_ > > +----+ | |_/ +----+ \__+----+ > > | mh1| _| | _| mh2| > > +----+ +----+_/ | |_ / +----+ > > \____|ISPB| +------+ \_+----+_/ > > +----+ |ISPD| > > +----+ > > [...] > > > > Now, suppose that mh2 also obtains a hint that something is wrong (this > > could be because TCP at mh2 timeout or because packets start > > > arriving with a different source address (this last case cannot > > be guaranteed because it depends on the internal routing in mh1)). > > > So, mh2 shim layer start using an alternative destination address, > > so it switches from PA:mh1 to PB:mh1. However, this does not solve > > the problem, since packets addressed to PB:: are also routed through ISPC. > > The problem here is that TCP detects the problem but it has no means to > > communicate the problem to the mh2's routing system, who still > > believes that a route through ISPC is still available. > > I thought you expressed concern about potential destructive interference > between the endpoints trying different locators and the routing system > finding a new path. But in the above example I don't find such destructive > interference. > (Sure, the worst case performance might not be better than the worst case > routing convergence time, but that is a different topic.) > Well, i think that the ULP hint mechanism is not working for this particular case, so i would say that a different interaction than letting the ULP hints set the destination locator and the routing system to determine the source locator is needed. In this case we may detect some desturctive interference IMHO, we should try to define a ULP hints mechanism that properly uses all hints and that improves the routing system response time. > So do you see any destructive interference? > > If not folks can work separately on the multi6 rehoming and improving the > convergence time as well as information (such as churn rate) in BGP. > > > This could be achieved with source address based routing.. the > problem here > > Source address based routing seems like a fair amount of added > complications; impacts the hardware/firmware in the routers and what else? > It might be easier to work on BGP convergence time. > Well, i am not really agree with the evolution of the reasoning here. Let me see if i do a brief summary: - In order to provide ULP established session, we propose a solution that implies the modification of all the hosts in the IPv6 Internet. IMHO, it's ok - However, if we base our solution only in BGP recovery features, the solution won't be usefull to preserve the established sessions of a number of applications. - One option to address this concern is to use keepalives, but a general solution based in keepalives exchanges seems inefficient and expensive. IMHO agree - Since every ULP has different needs we can use ULP hints to detect if something is wrong. IMHO good - Now the problem is that the host cannot force the routing system when it detects a problem based in the ULP hint - A proposed solution is to use source address based routing - But now you say that it would be better to work in BGP convergence, which is clearly out of the scope of the wg The result is that the solution than will not provide ULP session surviavility for a number of cases. Is this the evolution of the discussion? If so, i don't agree with the last steps. IMHO we will propose an expensive solution and it should better provide good capabilities and this inlcudes the preservation of the ULP sessions. I don't think it is a good approach to tell that someone else will solve the BGP convergence problem, so that we will just wait for that. I think that the ULP hint approach has possibilties and we should try to work it out, if it is not source address based routing, it may a routing hea der or something else. So my proposal is let's try to solve the problem above. What do you think? > > (Another hint can be the reception of ICMP error messages.) > > I'm concerned about the threats in that case since the host has no way > to assertain whether the ICMP error was generated by a router in the path > or some off-path spoofer. > Agree, however, this could be a low priority hint perhaps? Regards, marcelo > Erik > > From owner-multi6@ops.ietf.org Thu Oct 30 11:05:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28501 for ; Thu, 30 Oct 2003 11:05:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFFHg-000K0g-Lj for multi6-data@psg.com; Thu, 30 Oct 2003 16:04:28 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFFHV-000Jzk-GD for multi6@ops.ietf.org; Thu, 30 Oct 2003 16:04:17 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9UG43ed031752; Thu, 30 Oct 2003 17:04:03 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <0a7c01c39ddb$d68b2df0$0400a8c0@DFNJGL21> References: <09b801c39d07$db69c5e0$0400a8c0@DFNJGL21> <182931539.20031028134545@brandenburg.com> <0a7c01c39ddb$d68b2df0$0400a8c0@DFNJGL21> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Multi6 Mailing List" From: Iljitsch van Beijnum Subject: Re: Notes on draft-crocker-mast-analysis-01.txt Date: Thu, 30 Oct 2003 17:04:10 +0100 To: "Spencer Dawkins" X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 29 okt 2003, at 6:16, Spencer Dawkins wrote: > I spent some time on X.25-ish > Multi Link Protocol (MLP) in the late 80s - would love to see TCP > running over three gig-E interfaces, but not if it's sensitive to > out-of-order delivery. What is sensitive to out of order delivery? The GE interfaces or TCP? As soon as you start using multiple links in parallel, you're going to see out of order packets, that's pretty much guaranteed. (Consider the case where an application sends 1800 bytes worth of data, so a 1500 byte packet is transmitted over link A and a 300 byte packet over link B. The second packet will get to the other side first because it's shorter.) If TCP has problems with out of order packets, then it hasn't been implemented terribly well. I have no doubt that as soon as we have mechanisms for multiaddress multihoming, we'll see people trying to load share across the different addresses. This could be very useful. From owner-multi6@ops.ietf.org Thu Oct 30 11:20:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29163 for ; Thu, 30 Oct 2003 11:20:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFFWl-000KlL-U9 for multi6-data@psg.com; Thu, 30 Oct 2003 16:20:03 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFFWf-000KkY-KV for multi6@ops.ietf.org; Thu, 30 Oct 2003 16:19:58 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9UGJked031917; Thu, 30 Oct 2003 17:19:47 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Thu, 30 Oct 2003 17:19:53 +0100 To: X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 28 okt 2003, at 17:00, marcelo bagnulo wrote: >> I don't think it is that black and white. The routing system >> could propagate bad news faster than good news > I am not sure if this is true... > I am no routing expert, but i think that withdrawing a route is > inherently > slower than advertising a new route, at least in path vector > algorithms. There was a time that interdomain routing was under threat from instability caused by frequent up-down and down-up transitions. The solution was to implement "flap dampening": if you flap (down-up transition) too many times within a certain timespan, your route is ignored for some time, saving some expensive BGP and route table operations on the router in question, but more importantly in routers further upstream. Note that not propagating good news, so that a route seems to be down when in fact it is up, isn't too harmful as there are presumably other paths available so the destination is still reachable. Failing to propagate bad news on the other hand would be catastrophic, as packets continue to flow to a place where they can't be delivered. Avoiding this situation is the number one concern when running BGP. > The problem is that to detect that there is no route to a certain, all > the > alternative routes with increasing AS path are tried, which is > inherently > slow. Only if there are no alternatives. If there are, the path for those is probably not that long so they show up pretty quickly. Only when the last/only path goes down you'll see the following problem: > This would be similar to the count to infinity problem, but with > different AS path. But we usually don't care since when our last/only path goes down we're unreachable anyway. > This implies that the time to converge is proportional to > the number of ASes in the network. No, the number of possible paths (= interconnection exists) where the ASes to the left provide transit for our viewpoint and the ASes to the right provide transit for the source AS. This number increases exponentially with the number of transit links ASes have. So more multihoming actually hurts here. :-) From owner-multi6@ops.ietf.org Thu Oct 30 15:13:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09097 for ; Thu, 30 Oct 2003 15:13:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFJ80-0006hI-0y for multi6-data@psg.com; Thu, 30 Oct 2003 20:10:44 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AFJ7v-0006gX-B3 for multi6@ops.ietf.org; Thu, 30 Oct 2003 20:10:39 +0000 Received: (qmail 9998 invoked from network); 30 Oct 2003 20:14:11 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 30 Oct 2003 20:14:11 -0000 Message-ID: <3FA1708E.9070406@necom830.hpcl.titech.ac.jp> Date: Fri, 31 Oct 2003 05:11:58 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: mbagnulo@ing.uc3m.es, multi6@ops.ietf.org Subject: Re: about draft-nordmark-multi6-noid-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik; >>Red herring. >> >>Encapsulation and notification formats are a merely minor issue >>of multihoming. > Thanks for sharing, but being able to do this without making security > worse than in the current Internet is a challenge. See > draft-nordmark-multi6-threats for an initial cut at the threats that we > need to be concerned about. The threat ID is an abstract nonsense. The only thing to be secured w.r.t. multi6 is a set of locators of a peer. That is, all that is required is to share a cookie at the start of the communication, to be used later to authenticate locator set changes. Note that when the set is stable, no new mechanism is necessary. For example, that SMTP clients today try all the addresses of all the servers of a domain is a form of end to end multihoming, which is no security threat. In addition, it is, of course, necessary, not to make a protocol a DOS amplifier, but it is a generic requirement to all the protocols and is not multi6 specific. > You might believe that security is a minor issue that can be added > as an afterthought but experience has shown that this > is not the most efficient and expedient way to design secure enough protocols. Security is a minor issue to be taken care of easily from the beginning. >>It should also be noted that changes on host identification >>(from IP address to something else such as FQDN) means a >>protocol change at upper (at least at the transport) layers >>that "all upper layer protocols can operate unmodified" is >>a false statement. > I honestly disagree. Protocol is defined by the packet content on the wire, not by API. That a packet of a protocol is modified within a host is a host internal implementation issue having nothing to do with the protocol. You preserve API, not the protocol. >>It is really a wast of bandwidth to read poor proposals not >>understanding requirements described in my drafts long ago. > > > The tone of your note in general and this sentence in particular makes > me wonder what you want to accomplish in this working group. > Can we please have a civil discussion!!! I wonder what you want to accomplish in this working group. It is no useful to have a harmonized discussion to reach a peaceful compromise on a set of useless drafts. >>Do read the drafts. > I did. And I understood them I think. But they didn't seem to address key > important issues like redirection attacks - saying "cookie-based weak security > for a host authorize changes of locators of its peer." is missing all the > details of the complexity of providing this without introducing new (DoS) > attacks, and is probably too weak since it would make redirection attacks much > easier to perform and harder to detect than in today's Internet. I'm afraid you merely underestimate the security threats in today's Internet. In your threat ID, you wrote: : Any system that is along the path from the source to the destination : host can be compromised and used to redirect traffic. Systems may be : added to the best path to accomplish this. Further, even systems : that are on multi-access links that do not provide security can also : be used to redirect traffic off of the normal path. and the cookie approach do not give protection against attacks from hosts on the path, which is no worse. The Internet today is not so secure. Under certain assumption, redirection attacks are easy and hard to detect. Masataka Ohta From owner-multi6@ops.ietf.org Thu Oct 30 16:09:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11721 for ; Thu, 30 Oct 2003 16:09:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFK0p-0009LF-Cx for multi6-data@psg.com; Thu, 30 Oct 2003 21:07:23 +0000 Received: from [195.43.225.73] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFK0l-0009KK-KH for multi6@ops.ietf.org; Thu, 30 Oct 2003 21:07:19 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9UL74Pk002744; Thu, 30 Oct 2003 22:07:04 +0100 (CET) Date: Thu, 30 Oct 2003 22:07:00 +0100 Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Erik Nordmark , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <5E11E466-0A56-11D8-A0C6-00039388672E@muada.com> Message-Id: <00ED49EF-0B1D-11D8-ADF8-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On onsdag, okt 29, 2003, at 22:25 Europe/Stockholm, Iljitsch van Beijnum wrote: > Is this on topic now for this wg? :-) > Maybe we should solve the M6 problem first...:-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP6F9dqarNKXTPFCVEQLnzgCgitADtp/j5Mr54bOaXOGF3SUKEcwAn28Q PfFGneFvIW3vXPaem2ULmrOo =+cfZ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Oct 30 16:23:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12289 for ; Thu, 30 Oct 2003 16:23:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFKEj-000AKf-Gv for multi6-data@psg.com; Thu, 30 Oct 2003 21:21:45 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFKEe-000AJs-Uo for multi6@ops.ietf.org; Thu, 30 Oct 2003 21:21:41 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9UKWaed034725 for ; Thu, 30 Oct 2003 21:32:36 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v604) Content-Transfer-Encoding: 7bit Message-Id: <374A7DE6-0B18-11D8-A0C6-00039388672E@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 Mailing List From: Iljitsch van Beijnum Subject: survivability, rewriting Date: Thu, 30 Oct 2003 21:32:44 +0100 X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit About the session survivability: I think Kurtis is right that we must not let ourselves get caught up in unrealistic expectations. I believe a useful lower limit would be five seconds. This gives just over two round trips when both parties are using GSM/GPRS and/or satellite, a few more for more reasonable link technologies. And two missed acks is the absolute minimum we must require before even considering a rehoming event, as a single missed ack can very easily happen for many reasons that don't warrant rehoming. So if an application can't handle a 5 second gap in the communication, it shouldn't count on general multihoming mechanisms to provide failover. I don't think this is too unreasonable. Many people have mentioned VoIP, often in the same sentence with extremely unrealistic failover expectations. I believe 5 seconds is workable for VoIP: this is certainly close to the time a user will continue to shout "hello, are you still there?" when using a cell phone with less than perfect reception. I maintain that having the transport layer provide hints to the multihoming layer about when a rehoming would be desired is the right approach. Yes, this will give us some trouble in the beginning, as existing upper layer protocols don't provide these hints yet. So we implement additional heuristics so the multihoming layer can rehome on its own. But this is never going to be as efficient as having the transport layer do it, as transport protocols have very good knowledge about what's happening end-to-end. TCP for instance goes through great lengths to be able to determine when to retransmit and whether only a single packet was lost or more. Streaming protocols on the other hand have a pretty good idea when new data should be arriving, so here the receiver is in a good position to send nacks or hints. One thing we haven't discussed so far: if upper layers provide us with a hint, what exactly does the multihoming layer do after receiving such a hint? It would make sense to peform some kind of check to see what kind of reachability exists, but this means we need some kind of ping-like functionality. Is it reasonable to depend on such a mechanism in this age of ICMP paranoia? About the rewriting: why again are we making life difficult for ourselves? The obvious place to put an indication that the address may be rewritten is... in the address. Is there any reason why we can't have one or more special prefixes that indicate that a router should fill in the source address? However, this doesn't solve what we should do when rewriting isn't permitted. Obviously we could come up with a multihoming mechanism where rewriting is always allowed, trading off complexity in this area against complexity in recognizing a correspondent and accepting some types of spoofed packets. But "legacy" IPv6 also doesn't permit rewriting, so we must be prepared to handle this. The obvious solution is source address based routing, but it doesn't seem like everyone is convinced. I don't really see any workable alternatives, though. Even if we can do ICMP or NAROS magic to make sure that new sessions magically use the right source address so initially they're able to pass ingress filtering, it's always possible that halfway through the session is rerouted over another ISP and the source address is filtered. This means we can't reroute traffic based on changes in BGP the way we're used to, the ultimate consequence of which is that we must hardcode all routing decisions. In practice this probably means using one ISP as a primary and the other one only as a backup. Another problem is that if we depend on BGP to determine which ISP provides the shortest path to a destination, this effectively blocks us from using the other ISP to reach the same destination. For instance, if X has ISPs A and B, and Y has ISPs C and D, then it's entirely possible that X will use ISP A to reach both Y(C) and Y(D), so that when something bad happens with ISP A both of Y's addresses become unreachable. With source address based routing this isn't an issue as X can reach each of Y(C) and Y(D) over both A and B by simply using a different source address. I do agree that source address based routing (which is in effect a limited form of source routing) doesn't mesh well with our hop by hop forwarding paradigm, but again: I don't see any alternatives. From owner-multi6@ops.ietf.org Thu Oct 30 20:37:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24304 for ; Thu, 30 Oct 2003 20:37:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFOBq-0000RJ-L2 for multi6-data@psg.com; Fri, 31 Oct 2003 01:35:02 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFOBk-0000Qf-DK for multi6@ops.ietf.org; Fri, 31 Oct 2003 01:34:56 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9V0Mmf12189; Thu, 30 Oct 2003 16:22:48 -0800 Date: Thu, 30 Oct 2003 16:16:37 -0800 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <35173384263.20031030161637@brandenburg.com> To: Iljitsch van Beijnum CC: "Spencer Dawkins" , "Multi6 Mailing List" Subject: Re: Notes on draft-crocker-mast-analysis-01.txt In-Reply-To: References: <09b801c39d07$db69c5e0$0400a8c0@DFNJGL21> <182931539.20031028134545@brandenburg.com> <0a7c01c39ddb$d68b2df0$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch, IvB> What is sensitive to out of order delivery? The GE interfaces or TCP? TCP and IP. Having packets arrive out of order hurts fast-path performance. the inherent requirement is to take a packet and put it into a holding position until it becomes 'in order'. The required checking and holding and retrieving hurt performance. IvB> If TCP has problems with out of order packets, then it hasn't been IvB> implemented terribly well. If you know of a TCP implementation that does not take a performance hit with out-of-order packets, please cite the data d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Thu Oct 30 22:40:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27212 for ; Thu, 30 Oct 2003 22:40:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFQ6v-0007Fr-LX for multi6-data@psg.com; Fri, 31 Oct 2003 03:38:05 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFQ6j-0007Er-QR for multi6@ops.ietf.org; Fri, 31 Oct 2003 03:37:53 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc13) with SMTP id <20031031033752015008icl0e> (Authid: sdawkins@comcast.net); Fri, 31 Oct 2003 03:37:52 +0000 Message-ID: <0d1f01c39f60$6ae1b700$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Multi6 Mailing List" Cc: "Mark Allman" References: <09b801c39d07$db69c5e0$0400a8c0@DFNJGL21> <182931539.20031028134545@brandenburg.com> <0a7c01c39ddb$d68b2df0$0400a8c0@DFNJGL21> <35173384263.20031030161637@brandenburg.com> Subject: Re: Notes on draft-crocker-mast-analysis-01.txt Date: Thu, 30 Oct 2003 21:38:14 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,ORDER_NOW autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Iljitsch, What Dave said, at least re: TCP. If I send a segment that arrives out of order at the recipient, the recipient decides that the "hole" may be a lost packet and begins sending duplicate ACKs every time it receives a segment, until the hole is filled in. When the sender receives the third duplicate ACK, it says "oops, must be a lost packet", performs Fast Retransmit, and then cuts its congestion window in half (Fast Recovery). This does not make TCP run faster, since increases are additive (one additional segment per RTT, building back up to a full congestion window) while decreases are multiplicative (if you cut the congestion window in half, have a couple of good RTTs, and then have another out-of-order Fast Retransmit/Fast Recovery, the sender cuts the congestion window in half AGAIN). If your out-of-order-delivery problem is only one or two packets before the hole is filled in, that's OK, but in the general case, deployed TCPs don't handle much out-of-order-delivery before you start seeing performance hits. There are experimental proposals to make the Fast Retransmit/Fast Recovery threshold adaptable, but they are not standardized or deployed. Spencer p.s. Mark Allman - am I still telling the truth? ----- Original Message ----- From: "Dave Crocker" To: "Iljitsch van Beijnum" Cc: "Spencer Dawkins" ; "Multi6 Mailing List" Sent: Thursday, October 30, 2003 6:16 PM Subject: Re: Notes on draft-crocker-mast-analysis-01.txt > Iljitsch, > > IvB> What is sensitive to out of order delivery? The GE interfaces or TCP? > > TCP and IP. Having packets arrive out of order hurts fast-path performance. > the inherent requirement is to take a packet and put it into a holding > position until it becomes 'in order'. The required checking and holding and > retrieving hurt performance. > > > IvB> If TCP has problems with out of order packets, then it hasn't been > IvB> implemented terribly well. > > If you know of a TCP implementation that does not take a performance hit with > out-of-order packets, please cite the data From owner-multi6@ops.ietf.org Thu Oct 30 22:46:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27303 for ; Thu, 30 Oct 2003 22:46:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFQEg-0007lz-I2 for multi6-data@psg.com; Fri, 31 Oct 2003 03:46:06 +0000 Received: from [216.148.227.85] (helo=rwcrmhc12.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFQEd-0007lj-1y for multi6@ops.ietf.org; Fri, 31 Oct 2003 03:46:03 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc12) with SMTP id <2003103103460201400hqjrce> (Authid: sdawkins@comcast.net); Fri, 31 Oct 2003 03:46:02 +0000 Message-ID: <0d3201c39f61$8eb3d4a0$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Thu, 30 Oct 2003 21:46:24 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My apologies for not being clearer. What I meant was, multi6 should pick a targer for survivability, whether measured in tens of minutes (TCP), tens of seconds (HTTP with a human in the loop) or hundreds of milliseconds (VoIP). By doing so, communities can consider their needs vis-a-vis the target. If your needs are met by the target, you can rely on multi6 for survivability, and if not, you can start working on special-purpose survivability mechanisms. Spencer ----- Original Message ----- From: "marcelo bagnulo" To: "Spencer Dawkins" ; Sent: Thursday, October 30, 2003 8:56 AM Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) > Hi Spencer, > > > Agreed, but I'm not sure everyone else in the IETF agrees. It Would Be > > Lovely to pick a target (TCP survivability, HTTP survivability, VoIP > > survivability being three rough possibilities) and agree on it. > > What do you mean? > That the M6 layer should provide 3 types of service, TCP HTTP and VoIP like > services and that the app can select it? Or perhaps an automatic selection > based in the port/protocol combination that is being used? > Or just that we should have theses 3 services as reference? > > Regards, marcelo > From owner-multi6@ops.ietf.org Fri Oct 31 05:23:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20163 for ; Fri, 31 Oct 2003 05:23:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFWPZ-0002EW-HL for multi6-data@psg.com; Fri, 31 Oct 2003 10:21:45 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFWPW-0002EE-5q for multi6@ops.ietf.org; Fri, 31 Oct 2003 10:21:42 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9V9t8ed043452; Fri, 31 Oct 2003 10:55:08 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <0d1f01c39f60$6ae1b700$0400a8c0@DFNJGL21> References: <09b801c39d07$db69c5e0$0400a8c0@DFNJGL21> <182931539.20031028134545@brandenburg.com> <0a7c01c39ddb$d68b2df0$0400a8c0@DFNJGL21> <35173384263.20031030161637@brandenburg.com> <0d1f01c39f60$6ae1b700$0400a8c0@DFNJGL21> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <54A12F2C-0B88-11D8-A2FF-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: "Mark Allman" , "Multi6 Mailing List" From: Iljitsch van Beijnum Subject: Re: Notes on draft-crocker-mast-analysis-01.txt Date: Fri, 31 Oct 2003 10:55:17 +0100 To: "Spencer Dawkins" X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 31 okt 2003, at 4:38, Spencer Dawkins wrote: > If I send a segment that arrives out of order at the recipient, the > recipient decides that the "hole" may be a lost packet and begins > sending duplicate ACKs every time it receives a segment, until the > hole is filled in. When the sender receives the third duplicate ACK, > it says "oops, must be a lost packet", performs Fast Retransmit, and > then cuts its congestion window in half (Fast Recovery). Yes, this is all in RFC 2001. Note that in the case of two identical pipes being used side by side, you're not going to see that that many successive duplicate acks because generally only one packet will pass another. Obviously with gigabit ethernet alongside with GPRS things are going to be somewhat different. My point is that there are no fundamental properties that make it impossible for TCP to perform well in the presence of reordering. For instance, if additional memcopies would be required, that would be a big problem. But the design of the TCP/IP family of protocols and the way our kernels work is such that there must always be a copy cycle anyway, so no problems there. In my experience, the measures taken to avoid reordering have been much more harmful than reordering itself ever was to begin with. Implementations just need to change a bit to avoid unnecessary fast retransmits if they want to support using parallel links. I don't think this is a huge deal. One thing that bothers me about TCP and that also doesn't do us any favors here is that it sends packet trains back-to-back all the time. This can at times be very harmful as it unnecessarily increases burstiness. Especially cheap switches that must convert between different ethernet speeds don't have the buffering to handle this properly. From owner-multi6@ops.ietf.org Fri Oct 31 05:57:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21226 for ; Fri, 31 Oct 2003 05:57:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFWy1-0003m1-AR for multi6-data@psg.com; Fri, 31 Oct 2003 10:57:21 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFWxw-0003ll-Lz for multi6@ops.ietf.org; Fri, 31 Oct 2003 10:57:16 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id h9VApqlC014220 for ; Fri, 31 Oct 2003 10:51:52 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9VApqQf257390 for ; Fri, 31 Oct 2003 11:51:52 +0100 Received: from zurich.ibm.com ([9.145.230.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA51998 for ; Fri, 31 Oct 2003 11:51:51 +0100 Message-ID: <3FA23EA5.26A563AD@zurich.ibm.com> Date: Fri, 31 Oct 2003 11:51:17 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Mailing List Subject: Re: survivability, rewriting References: <374A7DE6-0B18-11D8-A0C6-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with this, and I'd add that many applications can survive much longer glitches than 5 seconds, and even TCP resets, by putting some fairly trivial retry logic in the right place. In the VoIP case, the limit is indeed the social one; there is no technical reason a VoIP solution can't keep trying to reconnect indefinitely. However, I suspect that this whole discussion belongs in a future working group called multi6-ops. Once we get a basic mechanism agreed, there will be many operational and implementation issues to be followed up. Should we concentrate now on the basic mechanism? Brian Iljitsch van Beijnum wrote: > > About the session survivability: I think Kurtis is right that we must > not let ourselves get caught up in unrealistic expectations. I believe > a useful lower limit would be five seconds. This gives just over two > round trips when both parties are using GSM/GPRS and/or satellite, a > few more for more reasonable link technologies. And two missed acks is > the absolute minimum we must require before even considering a rehoming > event, as a single missed ack can very easily happen for many reasons > that don't warrant rehoming. So if an application can't handle a 5 > second gap in the communication, it shouldn't count on general > multihoming mechanisms to provide failover. > > I don't think this is too unreasonable. Many people have mentioned > VoIP, often in the same sentence with extremely unrealistic failover > expectations. I believe 5 seconds is workable for VoIP: this is > certainly close to the time a user will continue to shout "hello, are > you still there?" when using a cell phone with less than perfect > reception. > > I maintain that having the transport layer provide hints to the > multihoming layer about when a rehoming would be desired is the right > approach. Yes, this will give us some trouble in the beginning, as > existing upper layer protocols don't provide these hints yet. So we > implement additional heuristics so the multihoming layer can rehome on > its own. But this is never going to be as efficient as having the > transport layer do it, as transport protocols have very good knowledge > about what's happening end-to-end. TCP for instance goes through great > lengths to be able to determine when to retransmit and whether only a > single packet was lost or more. Streaming protocols on the other hand > have a pretty good idea when new data should be arriving, so here the > receiver is in a good position to send nacks or hints. > > One thing we haven't discussed so far: if upper layers provide us with > a hint, what exactly does the multihoming layer do after receiving such > a hint? It would make sense to peform some kind of check to see what > kind of reachability exists, but this means we need some kind of > ping-like functionality. Is it reasonable to depend on such a mechanism > in this age of ICMP paranoia? > > About the rewriting: why again are we making life difficult for > ourselves? The obvious place to put an indication that the address may > be rewritten is... in the address. Is there any reason why we can't > have one or more special prefixes that indicate that a router should > fill in the source address? > > However, this doesn't solve what we should do when rewriting isn't > permitted. Obviously we could come up with a multihoming mechanism > where rewriting is always allowed, trading off complexity in this area > against complexity in recognizing a correspondent and accepting some > types of spoofed packets. But "legacy" IPv6 also doesn't permit > rewriting, so we must be prepared to handle this. The obvious solution > is source address based routing, but it doesn't seem like everyone is > convinced. > > I don't really see any workable alternatives, though. Even if we can do > ICMP or NAROS magic to make sure that new sessions magically use the > right source address so initially they're able to pass ingress > filtering, it's always possible that halfway through the session is > rerouted over another ISP and the source address is filtered. This > means we can't reroute traffic based on changes in BGP the way we're > used to, the ultimate consequence of which is that we must hardcode all > routing decisions. In practice this probably means using one ISP as a > primary and the other one only as a backup. > > Another problem is that if we depend on BGP to determine which ISP > provides the shortest path to a destination, this effectively blocks us > from using the other ISP to reach the same destination. For instance, > if X has ISPs A and B, and Y has ISPs C and D, then it's entirely > possible that X will use ISP A to reach both Y(C) and Y(D), so that > when something bad happens with ISP A both of Y's addresses become > unreachable. With source address based routing this isn't an issue as X > can reach each of Y(C) and Y(D) over both A and B by simply using a > different source address. > > I do agree that source address based routing (which is in effect a > limited form of source routing) doesn't mesh well with our hop by hop > forwarding paradigm, but again: I don't see any alternatives. From owner-multi6@ops.ietf.org Fri Oct 31 06:05:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21454 for ; Fri, 31 Oct 2003 06:05:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFX63-00049s-Ne for multi6-data@psg.com; Fri, 31 Oct 2003 11:05:39 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFX60-00049b-4M for multi6@ops.ietf.org; Fri, 31 Oct 2003 11:05:36 +0000 Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id EFA4A1C; Fri, 31 Oct 2003 13:18:45 +0200 (EET) Message-ID: <3FA241FF.5080902@nomadiclab.com> Date: Fri, 31 Oct 2003 13:05:35 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: Multi6 Mailing List Subject: Re: rewriting References: <374A7DE6-0B18-11D8-A0C6-00039388672E@muada.com> In-Reply-To: <374A7DE6-0B18-11D8-A0C6-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > About the rewriting: why again are we making life difficult for > ourselves? The obvious place to put an indication that the address may > be rewritten is... in the address. Is there any reason why we can't have > one or more special prefixes that indicate that a router should fill in > the source address? I think this is an excellent (but by no means new :-) idea. In general, I think that we need a generic way of expressing that the site border routers may rewrite the source address in the packet. There are cases where that would work already now. For example, the revised IPsec specifications allow IPsec SAs to be set up so that the source address is ignored when the packet is received. If I understand correctly, the main reason why this idea was rejected earlier was that it breaks upper layer pseudo header checksums. However, in the cases that we are dealing with now, that isn't true any more (IPsec tunnel mode, the proposed IPsec BEET mode, HIP, NOID, SIM, and probably others). Hence, I really think that we should go for standardizing a prefix that asks the first capable/so configured router to fill it in. --Pekka Nikander From owner-multi6@ops.ietf.org Fri Oct 31 07:14:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22931 for ; Fri, 31 Oct 2003 07:14:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFY8e-0007TV-KP for multi6-data@psg.com; Fri, 31 Oct 2003 12:12:24 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFY8b-0007T7-Do for multi6@ops.ietf.org; Fri, 31 Oct 2003 12:12:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9VBGkw04675; Fri, 31 Oct 2003 13:16:47 +0200 Date: Fri, 31 Oct 2003 13:16:46 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Multi6 Mailing List Subject: Re: survivability, rewriting In-Reply-To: <3FA23EA5.26A563AD@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 31 Oct 2003, Brian E Carpenter wrote: > I agree with this, and I'd add that many applications can survive much > longer glitches than 5 seconds, and even TCP resets, by putting some fairly > trivial retry logic in the right place. [...] (I'm pretty sure you agree here, but playing the devil's advocate to bring up an important point here..) Is it the business of the applications to put in this retry logic? No. If *every* application has to do this, we've failed. If such adding such logic is deemed the best approach, it needs to be put somewhere else. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Fri Oct 31 07:21:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23111 for ; Fri, 31 Oct 2003 07:21:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFYGz-00086l-Ne for multi6-data@psg.com; Fri, 31 Oct 2003 12:21:01 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFYGw-00086P-VU for multi6@ops.ietf.org; Fri, 31 Oct 2003 12:20:59 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9VCKtPh028542; Fri, 31 Oct 2003 05:20:55 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9VCKsS16627; Fri, 31 Oct 2003 13:20:54 +0100 (MET) Date: Fri, 31 Oct 2003 13:20:33 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: About carring information in the next header value To: mbagnulo@ing.uc3m.es Cc: Erik.Nordmark@sun.com, multi6@ops.ietf.org In-Reply-To: "Your message with ID" <2882972311mbagnulo@ing.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > SIM uses two new next header values > The next header format for these two values is the same, since the > different values are only > used to encode the rewrite ok bit, is this correct? That is what the draft says. But in SIM the "no rewrite" value might only be needed for the "no context" error message (to ensure that the locators used in the error match the locators in the offending packet). And it might even be possible to avoid this. > Question, where is this next header placed in the chain of extension > headers? The draft says immediately after any hbh or routing header. For compability with existing IPv6 routers I don't see how the header can be placed before those headers. > The other issue with new extension headers is that host must discard > unknown extension headers. > This may be a problem for the interaction between M6 hosts and legacy > hosts, Not an issue as the draft is written. Only destinations which have one of the new "ID" records in the DNS would receive M6 headers. And for the responding end which didn't do a DNS lookup, it will only send M6 packets if it has received an M6 packet from the peer. > Anyway, i guess the most efficient option is the one presented in noid, > that uses the nextheader > and the flow label fields to carry the inforamtion in data packets. > I have a doubt about how the next header values are defined. > My first question is: do you define 2 values of next header for the > every ulp protocol, > covering the rewrite ok set and the rewrite ok not set, is this correct? Two for each common protocol that is likely to benefit from/use multihoming support. > So you are not defining two values for the values of next header that > define an extension header, > like routing header, hop by hop, etc. why is that, is becasue there are > not enough next > header values? > the problem with doing so, is that when an extension header is > included, the site exit routers > will have to parse all the extension headers until they find the ulp > next header. Wouldn't this > be a problem for efficiency? Perhaps this is not a very common case, > though. Folks can argue whether such inefficiency is better or worse than the inefficiency in SIM of including an extra 8 byte header in every packet. That is one piece of the tradeoffs. > Addtionally, I guess that you would like to preserve the values > currently defined for ulp, at > least fot compatibility with legacy hosts, but i am not sure if this is > accomplished now as > currently defined in section 6 of the noid doc. NOID doesn't redefine e.g. the nexthdr value for TCP. It does define two new values for TCP over M6 with rewrite ok TCP over M6 without rewrite ok > I guess it would make more sense to define currently assigned ULP > values to the case when > the rewrite bit is not set, since legacy host would not recognize > packets with modifed locators. That isn't sufficient since you need to carry not only the "rewrite ok" logical bit in the packet but also the "packet is using M6". Thus to encode this in the nexthdr field you need the existing protocol number assignment plus two more values for each common protocol. > So my conclusion is that in order to ensure bacward compatibility and > efficiency: > Initial packets should carry M6 information in a new destination option. Makes no sense to me since there is another mechanism to tell whether the peer supports M6 - the DNS record. > Initial packets carry next headers values for ULP as currenlty defined > following packets that use the M6 protocol carry the tag information in > the flow label value and > encode the rewrite bit in newly defined ULP next header values (and no > extension header) That doesn't tell the receiver whether the sender supports the M6 protocol. Thus the receiver would end up triggering M6 processing (sending a context request in NOID etc) even if the sender doesn't support M6. Erik From owner-multi6@ops.ietf.org Fri Oct 31 07:43:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25341 for ; Fri, 31 Oct 2003 07:43:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFYbg-0009aE-6Y for multi6-data@psg.com; Fri, 31 Oct 2003 12:42:24 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFYbd-0009Zs-BO for multi6@ops.ietf.org; Fri, 31 Oct 2003 12:42:21 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9VCfwUP022119; Fri, 31 Oct 2003 04:41:59 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9VCfvS22462; Fri, 31 Oct 2003 13:41:57 +0100 (MET) Date: Fri, 31 Oct 2003 13:41:34 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: Kurt Erik Lindqvist Cc: Erik Nordmark , mbagnulo@ing.uc3m.es, iljitsch@muada.com, multi6@ops.ietf.org In-Reply-To: "Your message with ID" <3B729725-0A53-11D8-AB34-000A9598A184@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > Perhaps a bit; but the policies can be worked on separately from the > > mechanisms and the policies can evolve at a different rate in the > > future. > > > > Would it make sense to add that into the next version of the draft? I can add that into 02 (since while nobody was looking a generated 01 versions of NOID and SIM - I'd forgotten to discuss at least the premeditated redirection attacks in 00). Erik From owner-multi6@ops.ietf.org Fri Oct 31 07:43:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25412 for ; Fri, 31 Oct 2003 07:43:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFYcG-0009co-Pe for multi6-data@psg.com; Fri, 31 Oct 2003 12:43:00 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFYcD-0009cP-2y for multi6@ops.ietf.org; Fri, 31 Oct 2003 12:42:57 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc13) with SMTP id <20031031124256015000al84e> (Authid: sdawkins@comcast.net); Fri, 31 Oct 2003 12:42:56 +0000 Message-ID: <0dcd01c39fac$9058b5f0$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Multi6 Mailing List" References: Subject: Re: survivability, rewriting Date: Fri, 31 Oct 2003 06:43:19 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ummm, exactly. While I would *never* utter the word "r_quirement" on the multi6 mailing list, it might be useful to think about success criteria. It's blindingly obvious to me that multi6 can't meet the needs of every application (for the same reason general-purpose security mechanisms might not meet the needs of the most extremely paranoid), and it's blindingly obvious to Pekka that multi6 has to meet the needs of at least some applications (and I agree). Neither of these are controversial positions. What's the success criteria, really, between these two extremes? Spencer ----- Original Message ----- From: "Pekka Savola" To: "Brian E Carpenter" Cc: "Multi6 Mailing List" Sent: Friday, October 31, 2003 5:16 AM Subject: Re: survivability, rewriting > On Fri, 31 Oct 2003, Brian E Carpenter wrote: > > I agree with this, and I'd add that many applications can survive much > > longer glitches than 5 seconds, and even TCP resets, by putting some fairly > > trivial retry logic in the right place. [...] > > (I'm pretty sure you agree here, but playing the devil's advocate to bring > up an important point here..) > > Is it the business of the applications to put in this retry logic? > > No. > > If *every* application has to do this, we've failed. If such adding such > logic is deemed the best approach, it needs to be put somewhere else. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > From owner-multi6@ops.ietf.org Fri Oct 31 07:45:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25441 for ; Fri, 31 Oct 2003 07:45:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFYeD-0009lr-GO for multi6-data@psg.com; Fri, 31 Oct 2003 12:45:01 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFYe3-0009kR-4Q for multi6@ops.ietf.org; Fri, 31 Oct 2003 12:44:51 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9VCilPh006738; Fri, 31 Oct 2003 05:44:48 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9VCikS22634; Fri, 31 Oct 2003 13:44:46 +0100 (MET) Date: Fri, 31 Oct 2003 13:44:23 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <5E11E466-0A56-11D8-A0C6-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Many routers already support policy routing in hardware. Source address > based routing is a subset of full policy routing. I don't see much of a > problem in the long run. Is it really a subset? Can existing routers and routing protocols convey, for different source prefixes, different nexthops for the same destination? I thought source routing merely implied that a route might only be applicable for certain source prefixes, not that there could be multiple routes for a given destination address/prefix that get applied based on the source address in the packet. Erik From owner-multi6@ops.ietf.org Fri Oct 31 07:50:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26033 for ; Fri, 31 Oct 2003 07:50:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFYjS-000AAt-9f for multi6-data@psg.com; Fri, 31 Oct 2003 12:50:26 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFYjO-000AAM-Cl for multi6@ops.ietf.org; Fri, 31 Oct 2003 12:50:22 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9VCoHPh008755; Fri, 31 Oct 2003 05:50:18 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9VCoGS23324; Fri, 31 Oct 2003 13:50:16 +0100 (MET) Date: Fri, 31 Oct 2003 13:49:53 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Crypto-based host identifiers To: Iljitsch van Beijnum Cc: mbagnulo@ing.uc3m.es, multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > If i understnd correctly, you need the new registry, because in order > > to avoid collisions, right? But a collision means that someone else > > has the private key that matches the hash of someone else's public > > key. This situation by itself it is a vulnerability to the solution > > isn't it?, since if it has such a private key it can impersonate the > > original holder, right? > > Yes. Fortunately it isn't as bad as it sounds. Suppose you're making a > 44 bit has and there are already 2^24 hashes in use. You then have a 1 > in 2^20 chance of colliding with an existing hash. However, the chance > that you're going to collide with Google, Microsoft or the White House > is significantly smaller than the chance you're going to collide with a > grocery store in Milan, a home office in New Jersy or a cell phone in > Osaka, which aren't nearly as much fun to impersonate. Also, as soon as > you use your fake hash and someone detects it, you're found out and the > holder of the original hash is going to abandon it. So you have to make > the first time that you're going to abuse the colliding hash count real > good because it's likely it's your only chance. Another mechanism to limit the exposure by short hashes is that the first time a host performs the PK challenge with the peer it records the actual public key. Later if somebody tries to redirect the traffic it can verify not only that the ID=hash matches, but also that it is the identical public key. This doesn't provide for strong "ownership" of the actual ID, but it does prevent redirection attacks. Erik From owner-multi6@ops.ietf.org Fri Oct 31 07:52:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26138 for ; Fri, 31 Oct 2003 07:52:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFYlJ-000AN0-4w for multi6-data@psg.com; Fri, 31 Oct 2003 12:52:21 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFYl6-000ALo-MY for multi6@ops.ietf.org; Fri, 31 Oct 2003 12:52:08 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id h9VCq7lC024004 for ; Fri, 31 Oct 2003 12:52:07 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9VCq7Qf277948 for ; Fri, 31 Oct 2003 13:52:07 +0100 Received: from zurich.ibm.com ([9.145.230.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA38756 for ; Fri, 31 Oct 2003 13:52:05 +0100 Message-ID: <3FA25AD2.32398CB5@zurich.ibm.com> Date: Fri, 31 Oct 2003 13:51:30 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Mailing List Subject: Re: survivability, rewriting References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > On Fri, 31 Oct 2003, Brian E Carpenter wrote: > > I agree with this, and I'd add that many applications can survive much > > longer glitches than 5 seconds, and even TCP resets, by putting some fairly > > trivial retry logic in the right place. [...] > > (I'm pretty sure you agree here, but playing the devil's advocate to bring > up an important point here..) > > Is it the business of the applications to put in this retry logic? > > No. > > If *every* application has to do this, we've failed. If such adding such > logic is deemed the best approach, it needs to be put somewhere else. That is what I would have said a few years ago. But the fact of life is that TCP resets do occur, and if you are building a business class application you will *not* allow that to cause an applications level failure. So all the business class applications that I know already have retry logic, and it was put there by programmers who wouldn't know a multihoming event if it hit them in the face. Actually it's just an extension of the fate sharing argument. If the host hasn't actually crashed and burned, it should try again at successively higher levels of the stack until things work again. That's why I've always rated transport survivability as only "nice to have" in multihoming. Brian From owner-multi6@ops.ietf.org Fri Oct 31 08:19:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27176 for ; Fri, 31 Oct 2003 08:19:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFZA6-000CNa-96 for multi6-data@psg.com; Fri, 31 Oct 2003 13:17:58 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFZA2-000CNF-Ry for multi6@ops.ietf.org; Fri, 31 Oct 2003 13:17:55 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h9VDHhed045711; Fri, 31 Oct 2003 14:17:43 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Fri, 31 Oct 2003 14:17:52 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 31 okt 2003, at 13:44, Erik Nordmark wrote: >> Many routers already support policy routing in hardware. Source >> address >> based routing is a subset of full policy routing. I don't see much of >> a >> problem in the long run. > Is it really a subset? Source address based routing basically boils down to a set of "if source address == a then next hop = x" clauses. On a Cisco router, this can be implemented using the more general policy routing mechanism that can also look at many other fields in the headers and some other stuff. I gather that Cisco and some other vendors support doing this in hardware and/or the fast path. > Can existing routers and routing protocols convey, for different source > prefixes, different nexthops for the same destination? It is possible that IDPR supports this, but since IDPR has been dead for a decade we can safely assume "no". However, modifying routing protocols, while not exactly a trivial excercise, isn't as bad as modifying ASICs. Also, I'm not sure if routing protocols are really required here. A static setup should be enough. > I thought source routing merely implied that a route might only be > applicable > for certain source prefixes, not that there could be multiple routes > for a given destination address/prefix that get applied based on the > source > address in the packet. Please don't use "source routing" in this context as the confusion with actual source routing will never end. There are different ways to approach this. A very general one would be to combine header fields (lets assume source and destination for now, but it could be more) and the next hop and attach a preference value to every such combination. Then routing becomes the process of looking up all header/next hop combinations where the header fields match for the packet in questgion, select the one with the highest preference and forward the packet according to the listed next hop. There is the slight issue that the cartesion product of the full sets of destination prefixes, source prefixes and next hops could get out of hand, but that's a question of optimization. But we don't have to go this far. We know that if a source address tied to ISP A is used, there is no use in forwarding the packet to ISP B, and the other way around. So there is no need to even check whether the destination is even reachable through the ISP indicated by the source address as there is no alternative course of action to forwarding the packet to that ISP and hope for the best. So essentially we're just taking default routes. From owner-multi6@ops.ietf.org Fri Oct 31 08:39:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27845 for ; Fri, 31 Oct 2003 08:39:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFZU3-000Dkl-C8 for multi6-data@psg.com; Fri, 31 Oct 2003 13:38:35 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFZU0-000DkS-Kj for multi6@ops.ietf.org; Fri, 31 Oct 2003 13:38:33 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9VCvdxA002943; Fri, 31 Oct 2003 04:57:40 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9VCvcS23892; Fri, 31 Oct 2003 13:57:39 +0100 (MET) Date: Fri, 31 Oct 2003 13:57:15 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: About carring information in the next header value To: Juan Rodriguez Hervella Cc: mbagnulo@ing.uc3m.es, Erik.Nordmark@Sun.COM, multi6@ops.ietf.org In-Reply-To: "Your message with ID" <200310301033.14821.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Erik, I like your draft which one of the four :-) > but I think this is useful once both > peers have already obtained the state. I don't know if somebody else > has asked you this, but I think this draft is weak on the stablishment > of the states, because until you aren't able to re-write, you still have > all the problems the muli6 WG is trying to solve. Not so because the behavior is transparent to the ULP. Thus the ULP is operating using some AID and underneath it the M6 layer will, until state has been establishes, try different locators for the peer. In NOID and CB64 there are probably some scenarious related to locator failures that need some more thought (and the specifications don't state which end is responsible for retransmitting). In SIM (or any approach which has the initiator explicitly starting the context creation exchange) I think locator rewriting can be enabled during that exchange, with perhaps the need for a challenge if the locators actually change during the exchange. FWIW the optimization to not perform the challenge immediately when a host-pair context is created does add some complications. But I think this optimization is important to not incur public key operations for every context that is created. Erik From owner-multi6@ops.ietf.org Fri Oct 31 08:44:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27982 for ; Fri, 31 Oct 2003 08:44:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFZZN-000E63-SH for multi6-data@psg.com; Fri, 31 Oct 2003 13:44:05 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFZZI-000E5O-4t for multi6@ops.ietf.org; Fri, 31 Oct 2003 13:44:00 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 6ABD243160; Fri, 31 Oct 2003 14:43:59 +0100 (CET) Received: from lolo (vpn-252-71.uc3m.es [163.117.252.71]) by smtp02.uc3m.es (Postfix) with SMTP id 7B89A9A02D; Fri, 31 Oct 2003 14:43:57 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" , "Multi6 Mailing List" Subject: RE: survivability, rewriting Date: Fri, 31 Oct 2003 14:38:19 +0100 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.4522.1200 In-Reply-To: <374A7DE6-0B18-11D8-A0C6-00039388672E@muada.com> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, I very much agree with you here. Some comments below... > > I maintain that having the transport layer provide hints to the > multihoming layer about when a rehoming would be desired is the right > approach. At least we should explore what we can achieve following this path. > Yes, this will give us some trouble in the beginning, as > existing upper layer protocols don't provide these hints yet. So we > implement additional heuristics so the multihoming layer can rehome on > its own. But this is never going to be as efficient as having the > transport layer do it, as transport protocols have very good knowledge > about what's happening end-to-end. Agree > One thing we haven't discussed so far: if upper layers provide us with > a hint, what exactly does the multihoming layer do after receiving such > a hint? I thought this was what we were discussing with Erik in the Preserving established sessiones thread :-) It would make sense to peform some kind of check to see what > kind of reachability exists, but this means we need some kind of > ping-like functionality. Is it reasonable to depend on such a mechanism > in this age of ICMP paranoia? > IMHO, i would like to explore alternative approaches first. What about when recieving a ULP hint that there is a problem, change both source and destiantion locators and send the packet with rewrite ok bit not set? A more aggresive option would be to send multiple packets in paralel, each one with a different combination of source and destiantion address, and see which reply comes first. > About the rewriting: why again are we making life difficult for > ourselves? The obvious place to put an indication that the address may > be rewritten is... in the address. Is there any reason why we can't > have one or more special prefixes that indicate that a router should > fill in the source address? > > However, this doesn't solve what we should do when rewriting isn't > permitted. Obviously we could come up with a multihoming mechanism > where rewriting is always allowed, I don't see how. I mean, we are going to have two mechanisms, one based on bgp + rewriting and the other one is based on ULP hints. Now it is expected that the ULP hints mechanism will be have a better response time i.e. it will detect problems faster, right? However, the ULP hints mechanism works in the host itself and the bgp+rewrite mechanism is in the routers. This means that even if the ULP hint mechanism has detected a problem and changed the locator, if the final word about this belongs to the routing system, the bgp+rewriting mechanism will overrule the decisions made by the ULP hint mechanism which is exaclty what we don?t want, since the ULP hint mech is faster) So we need a mechanism to force the routing system to accept choices made by the host, since the host is better detecting problems in the path. Such a mechanism seems to require the capability to express that rewriting is not permited. Note that only the ULP hints mechanism is not enough, since for a while we will have ULP that don`t provide hints, so we need a fallback mechanism trading off complexity in this area > against complexity in recognizing a correspondent and accepting some > types of spoofed packets. But "legacy" IPv6 also doesn't permit > rewriting, so we must be prepared to handle this. The obvious solution > is source address based routing, but it doesn't seem like everyone is > convinced. > > I don't really see any workable alternatives, though. Well, we could use a routing header. Even we could define a routing headers that is elimated by the exit routers, in order to addresss the MTU reduction problem. > Even if we can do > ICMP or NAROS magic to make sure that new sessions magically use the > right source address so initially they're able to pass ingress > filtering, it's always possible that halfway through the session is > rerouted over another ISP and the source address is filtered. This > means we can't reroute traffic based on changes in BGP the way we're > used to, the ultimate consequence of which is that we must hardcode all > routing decisions. In practice this probably means using one ISP as a > primary and the other one only as a backup. > agree > Another problem is that if we depend on BGP to determine which ISP > provides the shortest path to a destination, this effectively blocks us > from using the other ISP to reach the same destination. For instance, > if X has ISPs A and B, and Y has ISPs C and D, then it's entirely > possible that X will use ISP A to reach both Y(C) and Y(D), so that > when something bad happens with ISP A both of Y's addresses become > unreachable. With source address based routing this isn't an issue as X > can reach each of Y(C) and Y(D) over both A and B by simply using a > different source address. > agree (again) > I do agree that source address based routing (which is in effect a > limited form of source routing) doesn't mesh well with our hop by hop > forwarding paradigm, but again: I don't see any alternatives. > An obvious comment about source address based routing is that source address based routing only has to be implemented within the multihomed site. Thanks, marcelo > From owner-multi6@ops.ietf.org Fri Oct 31 08:45:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28022 for ; Fri, 31 Oct 2003 08:45:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFZZV-000E6k-RG for multi6-data@psg.com; Fri, 31 Oct 2003 13:44:13 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFZZK-000E5p-Mu for multi6@ops.ietf.org; Fri, 31 Oct 2003 13:44:02 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id F23EA43169; Fri, 31 Oct 2003 14:44:01 +0100 (CET) Received: from lolo (vpn-252-71.uc3m.es [163.117.252.71]) by smtp02.uc3m.es (Postfix) with SMTP id 3F4819A02D; Fri, 31 Oct 2003 14:44:00 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Spencer Dawkins" , Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Fri, 31 Oct 2003 14:38:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <0d3201c39f61$8eb3d4a0$0400a8c0@DFNJGL21> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > My apologies for not being clearer. What I meant was, multi6 should > pick a targer for survivability, whether measured in tens of minutes > (TCP), tens of seconds (HTTP with a human in the loop) or hundreds of > milliseconds (VoIP). > > By doing so, communities can consider their needs vis-a-vis the > target. If your needs are met by the target, you can rely on multi6 > for survivability, and if not, you can start working on > special-purpose survivability mechanisms. > My reading of the thread is that the approach is somehow different: The solution will provide a basic capability based on routing system path outage detection. Such mechanism won't provide a defined response time, since its response time depends on the situation and the worst case can be very bad. Additionally, the solution would accept hints from the ULP that can be used as failure detection mechanism. This is better than leting the apps start working on their own special purpose survivability mechanism, since they don't need to discover alternative locators and provide proper security and so on, they just need to provide hints to facilitate outage detection The general mechanism would be used by ULP that don't require such a good response time and also by legacy ULP that don't implement the hint mechanism. Does this sound good to you? Thanks, marcelo > Spencer > > ----- Original Message ----- > From: "marcelo bagnulo" > To: "Spencer Dawkins" ; > Sent: Thursday, October 30, 2003 8:56 AM > Subject: RE: Preserving established communications (was RE: about > draft-nordmark-multi6-noid-00) > > > > Hi Spencer, > > > > > Agreed, but I'm not sure everyone else in the IETF agrees. It > Would Be > > > Lovely to pick a target (TCP survivability, HTTP survivability, > VoIP > > > survivability being three rough possibilities) and agree on it. > > > > What do you mean? > > That the M6 layer should provide 3 types of service, TCP HTTP and > VoIP like > > services and that the app can select it? Or perhaps an automatic > selection > > based in the port/protocol combination that is being used? > > Or just that we should have theses 3 services as reference? > > > > Regards, marcelo > > > > From owner-multi6@ops.ietf.org Fri Oct 31 09:05:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28734 for ; Fri, 31 Oct 2003 09:05:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFZtR-000Ffe-Fh for multi6-data@psg.com; Fri, 31 Oct 2003 14:04:49 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFZtP-000Fes-37 for multi6@ops.ietf.org; Fri, 31 Oct 2003 14:04:47 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 0B4CA43160; Fri, 31 Oct 2003 14:44:34 +0100 (CET) Received: from lolo (vpn-252-71.uc3m.es [163.117.252.71]) by smtp02.uc3m.es (Postfix) with SMTP id B0F459A035; Fri, 31 Oct 2003 14:44:32 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" Cc: "Multi6 Mailing List" Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Fri, 31 Oct 2003 14:38:54 +0100 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.4522.1200 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > The problem is that to detect that there is no route to a certain, all > > the > > alternative routes with increasing AS path are tried, which is > > inherently > > slow. > > Only if there are no alternatives. If there are, the path for those is > probably not that long so they show up pretty quickly. Only when the > last/only path goes down you'll see the following problem: Ok, but this is the case that we care, right? From ISPA prespective, there is no longer a route to the destiantion, so the multi-homed site detects that and tries the alternative ISP (ISPB). So the case that we care is the reconvergence of BGP within the portin of the network where a route to the destiantion address no longer exist > > > This would be similar to the count to infinity problem, but with > > different AS path. > > But we usually don't care since when our last/only path goes down we're > unreachable anyway. I don't see it that way, i mean, the destiantion *is* unreachable through one of the providers. The route is withdrawn from that part of the network. Then once that the route has been withdrwan from that part of the network, the multihomed site detect the problem and tries with the alternative ISP. Anyway, i guess that the reconvergence time is only part of the problem. Another part of the problem is the time required to detect the outage. Only this factor would render the solution inacceptable for many applications. Regards, marcelo From owner-multi6@ops.ietf.org Fri Oct 31 09:08:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28850 for ; Fri, 31 Oct 2003 09:08:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFZwe-000Fuu-NY for multi6-data@psg.com; Fri, 31 Oct 2003 14:08:08 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFZwZ-000FuP-5z for multi6@ops.ietf.org; Fri, 31 Oct 2003 14:08:03 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 5F7584315F; Fri, 31 Oct 2003 15:08:02 +0100 (CET) Received: from lolo (vpn-252-65.uc3m.es [163.117.252.65]) by smtp01.uc3m.es (Postfix) with SMTP id F2D9799F03; Fri, 31 Oct 2003 15:08:00 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Brian E Carpenter" , "Multi6 Mailing List" Subject: RE: survivability, rewriting Date: Fri, 31 Oct 2003 15:02:22 +0100 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.4522.1200 In-Reply-To: <3FA25AD2.32398CB5@zurich.ibm.com> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There is middle ground between letting the application to deal with the preservation of the established communications (handling locator discovery, security) and letting all this to be performed by the multi-homing layer. Some parts seem to be pretty common to all apps, locator discovery, security Some parts seem to be very different such as failure detection. So the common parts should be provided by the common multi-homing layer and the different parts should be ULP specific. IMHO, the issue is how to make the interaction of those mechanisms Regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Brian E Carpenter > Enviado el: viernes, 31 de octubre de 2003 13:52 > Para: Multi6 Mailing List > Asunto: Re: survivability, rewriting > > > Pekka Savola wrote: > > > > On Fri, 31 Oct 2003, Brian E Carpenter wrote: > > > I agree with this, and I'd add that many applications can survive much > > > longer glitches than 5 seconds, and even TCP resets, by > putting some fairly > > > trivial retry logic in the right place. [...] > > > > (I'm pretty sure you agree here, but playing the devil's > advocate to bring > > up an important point here..) > > > > Is it the business of the applications to put in this retry logic? > > > > No. > > > > If *every* application has to do this, we've failed. If such > adding such > > logic is deemed the best approach, it needs to be put somewhere else. > > That is what I would have said a few years ago. But the fact of life is > that TCP resets do occur, and if you are building a business class > application you will *not* allow that to cause an applications level > failure. So all the business class applications that I know already > have retry logic, and it was put there by programmers who wouldn't know > a multihoming event if it hit them in the face. > > Actually it's just an extension of the fate sharing argument. If the host > hasn't actually crashed and burned, it should try again at successively > higher levels of the stack until things work again. > > That's why I've always rated transport survivability as only > "nice to have" > in multihoming. > > Brian > From owner-multi6@ops.ietf.org Fri Oct 31 09:25:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29207 for ; Fri, 31 Oct 2003 09:25:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFaCa-000HBt-1t for multi6-data@psg.com; Fri, 31 Oct 2003 14:24:36 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFaCX-000HBW-97 for multi6@ops.ietf.org; Fri, 31 Oct 2003 14:24:33 +0000 Received: from descartes.info.ucl.ac.be (descartes [130.104.229.82]) by info.ucl.ac.be (8.12.10/8.12.8) with ESMTP id h9VEOMKD027047; Fri, 31 Oct 2003 15:24:22 +0100 (MET) Subject: RE: survivability, rewriting From: Cedric de Launois To: mbagnulo@ing.uc3m.es Cc: Iljitsch van Beijnum , Multi6 Mailing List In-Reply-To: References: Content-Type: text/plain Message-Id: <1067610345.21207.51.camel@descartes> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 31 Oct 2003 15:25:45 +0100 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-10-31 at 14:38, marcelo bagnulo wrote: > IVB> I do agree that source address based routing (which is in effect a > IVB> limited form of source routing) doesn't mesh well with our hop by hop > IVB> forwarding paradigm, but again: I don't see any alternatives. > > An obvious comment about source address based routing is that source address > based routing only has to be implemented within the multihomed site. Note that source address based routing also provides these advantages : - since the path (and the ISP) taken by an outgoing packet is determined by its source address, a host can easily select its preferred path by simply choosing the corresponding source address. We can thus imagine a p2p application that could explicitly load-balance its traffic on all its available paths. This is an interesting feature (I think). - routing inside the multihomed site can be simpler since it doesn't longer depends on the destination address but only on the few site prefixes delegated to the site. - More importantly : source address based routing enables better failure detection and recovery that the use of bgp since all this stuff can be performed end-to-end (I agree with Marcelo) Cedric From owner-multi6@ops.ietf.org Fri Oct 31 09:47:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00326 for ; Fri, 31 Oct 2003 09:47:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFaYY-000JCw-5t for multi6-data@psg.com; Fri, 31 Oct 2003 14:47:18 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFaYN-000JAF-IT for multi6@ops.ietf.org; Fri, 31 Oct 2003 14:47:07 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9VEku5u029474; Fri, 31 Oct 2003 07:46:56 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9VEktS09648; Fri, 31 Oct 2003 15:46:55 +0100 (MET) Date: Fri, 31 Oct 2003 15:46:32 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , iljitsch@muada.com, multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > - But now you say that it would be better to work in BGP convergence, which > is clearly out of the scope of the wg FWIW I didn't suggest that this WG should work on improving BGP convergence time. But it is something that perhaps an other WG could do in combination with operators and vendors. > The result is that the solution than will not provide ULP session > surviavility for a number of cases. Since we haven't defined what session surviability actually means there is a simple approach; use a multi6 solution with existing BGP and set the time when TCP gives up to inifinite i.e. TCP will keep on trying forever. That provides session suvivability. While that might not be that useful, it does illustrate that the discussion is really about the timelyness of failure recovery and not about whether failure recovery is possible. Perhaps having optional M6-layer heartbeat messages that the ULP can enable by stating "I'd like failure recovery in 17 seconds" would make sense. As your examples point out this might still run into BGP convergence time issues if all of the peer's locator prefixes are routed out the same failed link/ISP. But it might still be a step in the right direction in terms of abstracting the "failure recovery" service offered by an M6 layer. Erik From owner-multi6@ops.ietf.org Fri Oct 31 09:56:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00746 for ; Fri, 31 Oct 2003 09:56:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFahS-000K08-GY for multi6-data@psg.com; Fri, 31 Oct 2003 14:56:30 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFahQ-000Jzq-80 for multi6@ops.ietf.org; Fri, 31 Oct 2003 14:56:28 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9VEuFUP020889; Fri, 31 Oct 2003 06:56:16 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9VEuES10605; Fri, 31 Oct 2003 15:56:14 +0100 (MET) Date: Fri, 31 Oct 2003 15:55:51 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: survivability, rewriting To: Iljitsch van Beijnum Cc: Multi6 Mailing List In-Reply-To: "Your message with ID" <374A7DE6-0B18-11D8-A0C6-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > About the rewriting: why again are we making life difficult for > ourselves? The obvious place to put an indication that the address may > be rewritten is... in the address. Is there any reason why we can't > have one or more special prefixes that indicate that a router should > fill in the source address? Two answers: 1. The ULPs need to know the addresses of the node itself to be able to perform certain forms of referal. But that doesn't prevent the node to issue IP packets with a source locator that doesn't include the upper bits of the address *as long as* the host knows that there is a rewriting router along the path. 2. Having a designated prefix in the source locator to indicate "rewrite ok" prevents hiearchical rewriting; this is when e.g. your border router rewrites the prefix and your ISPs border towards its upstream can also rewrite. Erik From owner-multi6@ops.ietf.org Fri Oct 31 10:01:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00969 for ; Fri, 31 Oct 2003 10:01:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFamL-000KVd-3g for multi6-data@psg.com; Fri, 31 Oct 2003 15:01:33 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFamG-000KV6-EZ for multi6@ops.ietf.org; Fri, 31 Oct 2003 15:01:28 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id A0B0A43158; Fri, 31 Oct 2003 15:08:00 +0100 (CET) Received: from lolo (vpn-252-65.uc3m.es [163.117.252.65]) by smtp01.uc3m.es (Postfix) with SMTP id 6C85A99F03; Fri, 31 Oct 2003 15:07:55 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Brian E Carpenter" , "Multi6 Mailing List" Subject: RE: survivability, rewriting Date: Fri, 31 Oct 2003 15:02:17 +0100 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.4522.1200 In-Reply-To: <3FA23EA5.26A563AD@zurich.ibm.com> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Brian, > However, I suspect that this whole discussion belongs in a future > working group called multi6-ops. Once we get a basic mechanism agreed, > there will be many operational and implementation issues to be > followed up. Should we concentrate now on the basic mechanism? The problem is that perhaps the basic mechanism (for example one based on source address rewriting) won't allow future optimizations if they are not considered in the initial design. So i guess that we should decide which type of future optimizations will be supported and then ensure compatibility with the basic solution and let the tunning of the optimizations for later. Regards, marcelo > > Brian > > Iljitsch van Beijnum wrote: > > > > About the session survivability: I think Kurtis is right that we must > > not let ourselves get caught up in unrealistic expectations. I believe > > a useful lower limit would be five seconds. This gives just over two > > round trips when both parties are using GSM/GPRS and/or satellite, a > > few more for more reasonable link technologies. And two missed acks is > > the absolute minimum we must require before even considering a rehoming > > event, as a single missed ack can very easily happen for many reasons > > that don't warrant rehoming. So if an application can't handle a 5 > > second gap in the communication, it shouldn't count on general > > multihoming mechanisms to provide failover. > > > > I don't think this is too unreasonable. Many people have mentioned > > VoIP, often in the same sentence with extremely unrealistic failover > > expectations. I believe 5 seconds is workable for VoIP: this is > > certainly close to the time a user will continue to shout "hello, are > > you still there?" when using a cell phone with less than perfect > > reception. > > > > I maintain that having the transport layer provide hints to the > > multihoming layer about when a rehoming would be desired is the right > > approach. Yes, this will give us some trouble in the beginning, as > > existing upper layer protocols don't provide these hints yet. So we > > implement additional heuristics so the multihoming layer can rehome on > > its own. But this is never going to be as efficient as having the > > transport layer do it, as transport protocols have very good knowledge > > about what's happening end-to-end. TCP for instance goes through great > > lengths to be able to determine when to retransmit and whether only a > > single packet was lost or more. Streaming protocols on the other hand > > have a pretty good idea when new data should be arriving, so here the > > receiver is in a good position to send nacks or hints. > > > > One thing we haven't discussed so far: if upper layers provide us with > > a hint, what exactly does the multihoming layer do after receiving such > > a hint? It would make sense to peform some kind of check to see what > > kind of reachability exists, but this means we need some kind of > > ping-like functionality. Is it reasonable to depend on such a mechanism > > in this age of ICMP paranoia? > > > > About the rewriting: why again are we making life difficult for > > ourselves? The obvious place to put an indication that the address may > > be rewritten is... in the address. Is there any reason why we can't > > have one or more special prefixes that indicate that a router should > > fill in the source address? > > > > However, this doesn't solve what we should do when rewriting isn't > > permitted. Obviously we could come up with a multihoming mechanism > > where rewriting is always allowed, trading off complexity in this area > > against complexity in recognizing a correspondent and accepting some > > types of spoofed packets. But "legacy" IPv6 also doesn't permit > > rewriting, so we must be prepared to handle this. The obvious solution > > is source address based routing, but it doesn't seem like everyone is > > convinced. > > > > I don't really see any workable alternatives, though. Even if we can do > > ICMP or NAROS magic to make sure that new sessions magically use the > > right source address so initially they're able to pass ingress > > filtering, it's always possible that halfway through the session is > > rerouted over another ISP and the source address is filtered. This > > means we can't reroute traffic based on changes in BGP the way we're > > used to, the ultimate consequence of which is that we must hardcode all > > routing decisions. In practice this probably means using one ISP as a > > primary and the other one only as a backup. > > > > Another problem is that if we depend on BGP to determine which ISP > > provides the shortest path to a destination, this effectively blocks us > > from using the other ISP to reach the same destination. For instance, > > if X has ISPs A and B, and Y has ISPs C and D, then it's entirely > > possible that X will use ISP A to reach both Y(C) and Y(D), so that > > when something bad happens with ISP A both of Y's addresses become > > unreachable. With source address based routing this isn't an issue as X > > can reach each of Y(C) and Y(D) over both A and B by simply using a > > different source address. > > > > I do agree that source address based routing (which is in effect a > > limited form of source routing) doesn't mesh well with our hop by hop > > forwarding paradigm, but again: I don't see any alternatives. > From owner-multi6@ops.ietf.org Fri Oct 31 10:05:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01228 for ; Fri, 31 Oct 2003 10:05:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFapa-000KqU-Qj for multi6-data@psg.com; Fri, 31 Oct 2003 15:04:54 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFapY-000Kq6-Em for multi6@ops.ietf.org; Fri, 31 Oct 2003 15:04:52 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9VF4hxA022354; Fri, 31 Oct 2003 07:04:44 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9VF4hS11429; Fri, 31 Oct 2003 16:04:43 +0100 (MET) Date: Fri, 31 Oct 2003 16:04:20 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > But we don't have to go this far. We know that if a source address tied > to ISP A is used, there is no use in forwarding the packet to ISP B, > and the other way around. So there is no need to even check whether the > destination is even reachable through the ISP indicated by the source > address as there is no alternative course of action to forwarding the > packet to that ISP and hope for the best. So essentially we're just > taking default routes. But to solve Macelo's example where packets to destination PC:X and PD:X both exit Y's site over the same link/ISP (and it takes a long time to discover that that link/ISP has failed), you would actually need something stronger. For instance something along the lines of being able to configure the routers so that packets with the source prefix PA all-other-things-being-equal(?) exit via ISP A and source prefix PB exit via ISP B. That way the sender can explore the two ISPs by changing the source locator. Erik From owner-multi6@ops.ietf.org Fri Oct 31 10:59:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04863 for ; Fri, 31 Oct 2003 10:59:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFbfY-000Opf-Ds for multi6-data@psg.com; Fri, 31 Oct 2003 15:58:36 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFbfU-000OpB-SX for multi6@ops.ietf.org; Fri, 31 Oct 2003 15:58:33 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9VF8cUP027270; Fri, 31 Oct 2003 07:08:39 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h9VF8bS12301; Fri, 31 Oct 2003 16:08:38 +0100 (MET) Date: Fri, 31 Oct 2003 16:08:15 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: survivability, rewriting To: mbagnulo@ing.uc3m.es Cc: Iljitsch van Beijnum , Multi6 Mailing List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > An obvious comment about source address based routing is that source address > based routing only has to be implemented within the multihomed site. Is that true when you have a tree of reseller ISPs? For instance DFZ / | \ ISP1 ISP2 ISP3 / \ / \ / \ ISPA ISPB ISPC ISPD \ / my site Erik From owner-multi6@ops.ietf.org Fri Oct 31 12:07:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08631 for ; Fri, 31 Oct 2003 12:07:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFcjD-000425-OX for multi6-data@psg.com; Fri, 31 Oct 2003 17:06:27 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFcjA-00041P-Gz for multi6@ops.ietf.org; Fri, 31 Oct 2003 17:06:24 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id BB1AD43191; Fri, 31 Oct 2003 18:06:23 +0100 (CET) Received: from lolo (vpn-252-80.uc3m.es [163.117.252.80]) by smtp02.uc3m.es (Postfix) with SMTP id 6D11A9A022; Fri, 31 Oct 2003 18:06:22 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: "Iljitsch van Beijnum" , "Multi6 Mailing List" Subject: RE: survivability, rewriting Date: Fri, 31 Oct 2003 18:00:44 +0100 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.4522.1200 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > An obvious comment about source address based routing is that > > source address based routing only has to be implemented > > within the multihomed site. > > Is that true when you have a tree of reseller ISPs? > > For instance > > DFZ > / | \ > ISP1 ISP2 ISP3 > / \ / \ / \ > ISPA ISPB ISPC ISPD > \ / > my site > > Good question IMHO... I guess this depends on how do you expect that provider multi-homing will be. I assume that in your example above you are considering the case where ISPA obtains addresses form ISP1 and ISPB from (ISP1 and ISP2), and ISPC from (ISP2 and ISP3), right? This implies that my site has 4 prefixes and in that case source address based routing is also required in ISPB and ISPC, correct? But IMHO this is not how provider multihoming will be. IMHO ISPs will be able to get a /32 each one, especially those ISP that are multi-homed to multilpe upstream providers. I guess that sub allocation will only make sense to isps that have a single upstream provider. I mean, i don't see signs that multihomed isps will have to obtain their IPv6 address range from their upstream providerS, implying that those isps will have several prefixes in their networks. (reducing the need of source address based routing to the end sites only) What is your view about this provider multihoming issue? Regards, marcelo Erik > From owner-multi6@ops.ietf.org Fri Oct 31 12:08:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08664 for ; Fri, 31 Oct 2003 12:08:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFcjF-00042O-Oe for multi6-data@psg.com; Fri, 31 Oct 2003 17:06:29 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFcjC-00041j-VC for multi6@ops.ietf.org; Fri, 31 Oct 2003 17:06:27 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id C132543191; Fri, 31 Oct 2003 18:06:25 +0100 (CET) Received: from lolo (vpn-252-80.uc3m.es [163.117.252.80]) by smtp02.uc3m.es (Postfix) with SMTP id 15A8A9A022; Fri, 31 Oct 2003 18:06:24 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" , "Iljitsch van Beijnum" Cc: "Multi6 Mailing List" Subject: RE: survivability, rewriting Date: Fri, 31 Oct 2003 18:00:45 +0100 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.4522.1200 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > About the rewriting: why again are we making life difficult for > > ourselves? The obvious place to put an indication that the address may > > be rewritten is... in the address. Is there any reason why we can't > > have one or more special prefixes that indicate that a router should > > fill in the source address? > > Two answers: > 1. The ULPs need to know the addresses of the node itself to be able > to perform certain forms of referal. But that doesn't prevent > the node to issue IP packets with a source locator that doesn't > include the upper bits of the address *as long as* the host knows > that there is a rewriting router along the path. > I am sorry, Erik, but i don't understand this argument. Those rewritable addresses wouldn't be passed for referrals purposes, they are just an artifact to let the M6 layer to notify the border router that they should complete with a real prefix. The application would only be aware of the AID. The referals would contain real locators. I guess i am missing your point here :-( > 2. Having a designated prefix in the source locator to indicate > "rewrite ok" > prevents hiearchical rewriting; this is when e.g. your border router > rewrites the prefix and your ISPs border towards its upstream can also > rewrite. > In what situation do you think that hierarchical rewriting would be needed? I guess you are considering the small multi-homed provider that obtains multiple prefixes, right? Again, i don't believe this would be the way provider multi-homing will be Regards, marcelo > Erik > > From owner-multi6@ops.ietf.org Fri Oct 31 12:08:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08682 for ; Fri, 31 Oct 2003 12:08:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFcix-00040S-DR for multi6-data@psg.com; Fri, 31 Oct 2003 17:06:11 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFcis-0003zi-IB for multi6@ops.ietf.org; Fri, 31 Oct 2003 17:06:06 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id C5AB843169; Fri, 31 Oct 2003 18:06:05 +0100 (CET) Received: from lolo (vpn-252-80.uc3m.es [163.117.252.80]) by smtp02.uc3m.es (Postfix) with SMTP id DF4BC9A022; Fri, 31 Oct 2003 18:06:03 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" , "Iljitsch van Beijnum" Cc: Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Fri, 31 Oct 2003 18:00:25 +0100 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.4522.1200 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > But we don't have to go this far. We know that if a source address tied > > to ISP A is used, there is no use in forwarding the packet to ISP B, > > and the other way around. So there is no need to even check whether the > > destination is even reachable through the ISP indicated by the source > > address as there is no alternative course of action to forwarding the > > packet to that ISP and hope for the best. So essentially we're just > > taking default routes. > > But to solve Macelo's example where packets to destination PC:X and PD:X > both exit Y's site over the same link/ISP (and it takes a long time to > discover that that link/ISP has failed), you would actually > need something stronger. For instance something along the lines > of being able to configure the routers so > that packets with the source prefix PA > all-other-things-being-equal(?) exit > via ISP A and source prefix PB exit via ISP B. That > way the sender can explore the two ISPs by changing the source locator. IMHO You would want to use the source address based routing when you don't want to use source address rewriting. There are some situations where you don't want the rewrite to take place and you want source address based routing. I can think of the following: - The external host don't support M6 - The M6 context has not been established yet - An ULP hint made the M6 layer to select a different path, so you want to let the host select the ISP and not the routing system Note that source address routing means that the host selects the exit ISP and source address rewriting means that the routing system selects the exit ISP. So a possible approach would be that if the rewrite ok bit is set, then you perform destination address routing and if the rewrite ok bit is not set you do source address based routing. Does this makes sense? Regards, marcelo > > Erik > > From owner-multi6@ops.ietf.org Fri Oct 31 12:26:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09351 for ; Fri, 31 Oct 2003 12:26:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFd1q-0005pN-DS for multi6-data@psg.com; Fri, 31 Oct 2003 17:25:42 +0000 Received: from [171.68.223.137] (helo=sj-core-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFd1o-0005oy-6p for multi6@ops.ietf.org; Fri, 31 Oct 2003 17:25:40 +0000 Received: from cisco.com (sjc-vpn4-900.cisco.com [10.21.83.131]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9VHPUKg015049; Fri, 31 Oct 2003 09:25:31 -0800 (PST) Message-ID: <3FA29B0A.8050003@cisco.com> Date: Fri, 31 Oct 2003 09:25:30 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I thought source routing merely implied that a route might only be applicable > for certain source prefixes, not that there could be multiple routes > for a given destination address/prefix that get applied based on the source > address in the packet. There are ways to do this, particularly with MPLS-TE. This allows for redundant paths based on all sorts of criteria. But I don't think this is what you had in mind. Eliot