From owner-multi6@ops.ietf.org Fri Nov 1 01:12:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29541 for ; Fri, 1 Nov 2002 01:12:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187V3x-000JoT-00 for multi6-data@psg.com; Thu, 31 Oct 2002 22:13:45 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 187V3w-000JoF-00 for multi6@ops.ietf.org; Thu, 31 Oct 2002 22:13:44 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 187V3w-000KtM-00; Thu, 31 Oct 2002 22:13:44 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Tony Hain Cc: Tony Li , Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] References: <013b01c28141$fe3838f0$237ba8c0@eagleswings> Message-Id: Date: Thu, 31 Oct 2002 22:13:44 -0800 X-Spam-Status: No, hits=-5.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> We need to decide which is more important: the scalability and durability >> of the routing subsystem or the convenience of non-connection based >> addressing. When we have consensus on this point, then all else will >> follow. > The answer to the question depends on which side of the table you are > sitting on. there is little doubt in my mind which side i sit on. interesting that tli seems to be on the same side. but then he always kinda groked the operational issues. randy From owner-multi6@ops.ietf.org Fri Nov 1 02:04:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04319 for ; Fri, 1 Nov 2002 02:04:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187VtH-000Nke-00 for multi6-data@psg.com; Thu, 31 Oct 2002 23:06:47 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 187VtF-000NkS-00 for multi6@ops.ietf.org; Thu, 31 Oct 2002 23:06:45 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 31 Oct 2002 23:06:51 -0800 Reply-To: From: "Tony Hain" To: "'Randy Bush'" Cc: "'Tony Li'" , Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Thu, 31 Oct 2002 23:06:42 -0800 Message-ID: <015601c28175$3b644920$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-4.3 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA04319 Randy Bush wrote: > > >> We need to decide which is more important: the scalability and > >> durability of the routing subsystem or the convenience of > >> non-connection based addressing. When we have consensus on this > >> point, then all else will follow. > > The answer to the question depends on which side of the > table you are > > sitting on. > > there is little doubt in my mind which side i sit on. > interesting that tli seems to be on the same side. but then > he always kinda groked the operational issues. Operational issues in the ISP space have always favored restricting topology or the knowledge about unaggregated parts thereof. At the same time, operational issues in the edge enterprise space favor provider independence for maximum flexibility. We have representative voices for the ISP issues, where are the comparable voices for the enterprise issues? The ISP focus carried round 1, so the allocation policy only allows for strict aggregation via provider blocks. The enterprise demand for multi-homing is the fundamental issue this WG is supposed to address, but the primary voices are those insisting on maximal aggregation for the ISP routing system. It is hard to believe this will end up with a well balanced result that considers all the requirements. Speaking of, we have a requirements doc that needs to get published. Tony From owner-multi6@ops.ietf.org Fri Nov 1 03:24:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01057 for ; Fri, 1 Nov 2002 03:24:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187X7P-0003WP-00 for multi6-data@psg.com; Fri, 01 Nov 2002 00:25:27 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 187X7N-0003WC-00; Fri, 01 Nov 2002 00:25:25 -0800 From: Masataka Ohta Message-Id: <200211010814.RAA15835@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA15835; Fri, 1 Nov 2002 17:14:05 +0900 Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: from Randy Bush at "Oct 31, 2002 10:13:44 pm" To: Randy Bush Date: Fri, 1 Nov 2002 17:14:04 +0859 () CC: Tony Hain , Tony Li , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Randy; > > >> We need to decide which is more important: the scalability and durability > >> of the routing subsystem or the convenience of non-connection based > >> addressing. When we have consensus on this point, then all else will > >> follow. > > The answer to the question depends on which side of the table you are > > sitting on. > > there is little doubt in my mind which side i sit on. Which? Routing subsystem is for single homing only that there is no table. Masataka Ohta From owner-multi6@ops.ietf.org Fri Nov 1 03:36:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01158 for ; Fri, 1 Nov 2002 03:36:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187XJg-0004FI-00 for multi6-data@psg.com; Fri, 01 Nov 2002 00:38:08 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 187XJd-0004CB-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 00:38:05 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 91B443442A; Fri, 1 Nov 2002 00:46:36 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gA18bYiI020437; Fri, 1 Nov 2002 00:37:35 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Fri, 1 Nov 2002 00:37:34 -0800 Message-ID: Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcKBdUSyI9bOCh0LR1qQHB9pD5OpDQACUIaQ From: "Tony Li" To: , "Randy Bush" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA01158 Tony, This is blatantly unfair. As an "arms merchant", I fully want to sell gear to all interested parties, both ISPs and enterprise alike. And, as a certain AD is fond of reminding me, the enterprise is a very big market. Why would I want to torque the enterprise? Instead, I want to help all parties by growing the net in a reasonable and scalable way. That should be what we're all trying to do here. The operation issues that I know of NEVER favor restricting topology. In fact, restricting topology is the result of geographic aggregation as it forces providers to interconnect within the aggregation boundary. Operational issues instead favor a haphazard, need driven, cost optimized topology. Yes, ok it's chaotic, but it's the result of capitalism at its finest. Provider independence isn't necessarily helped only by PI space. There are other ways. The real point is to avoid the pain and anguish of renumbering. If we were to go down the GSE path, for example, changing providers simply means changing the "routing gorp". The host identifier remains the same. You reconfigure your border router(s) and you're done. Infinitely less painful than dealing with the boring things like acutally bringing up a new tail circuit. ;-) You are also assuming that aggregation and multihoming are somehow at odds. They are not. All you have to do is to disconnect the locator and the identifier as GSE does and aggregate only the locators. Each host in a multihomed domain has a single identifier, but multiple locators. No deaggregation happens because the locators are bound to the provider and thus we have good topological 'addressing'. The enterprise doesn't lose because we tweak the transport to base the pseudoheader on the host identifier and then let the locator be free to be replaced by border routers. Connections flip back and forth between locators easily. How does this not solve the (non-ideological) issues at hand? Tony | -----Original Message----- | From: Tony Hain [mailto:alh-ietf@tndh.net] | Sent: Thursday, October 31, 2002 11:07 PM | To: 'Randy Bush' | Cc: Tony Li; multi6@ops.ietf.org | Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming | development] | | | Randy Bush wrote: | > | > >> We need to decide which is more important: the scalability and | > >> durability of the routing subsystem or the convenience of | > >> non-connection based addressing. When we have | consensus on this | > >> point, then all else will follow. | > > The answer to the question depends on which side of the | > table you are | > > sitting on. | > | > there is little doubt in my mind which side i sit on. | > interesting that tli seems to be on the same side. but then | > he always kinda groked the operational issues. | | Operational issues in the ISP space have always favored restricting | topology or the knowledge about unaggregated parts thereof. | At the same | time, operational issues in the edge enterprise space favor provider | independence for maximum flexibility. We have | representative voices for | the ISP issues, where are the comparable voices for the enterprise | issues? The ISP focus carried round 1, so the allocation policy only | allows for strict aggregation via provider blocks. The | enterprise demand | for multi-homing is the fundamental issue this WG is supposed to | address, but the primary voices are those insisting on maximal | aggregation for the ISP routing system. It is hard to | believe this will | end up with a well balanced result that considers all the | requirements. | | Speaking of, we have a requirements doc that needs to get | published. | | Tony | | From owner-multi6@ops.ietf.org Fri Nov 1 04:33:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02046 for ; Fri, 1 Nov 2002 04:33:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187YDE-0007Tj-00 for multi6-data@psg.com; Fri, 01 Nov 2002 01:35:32 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 187YDC-0007TW-00; Fri, 01 Nov 2002 01:35:30 -0800 From: Masataka Ohta Message-Id: <200211010932.SAA16928@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA16928; Fri, 1 Nov 2002 18:32:09 +0900 Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: from Tony Li at "Nov 1, 2002 00:37:34 am" To: Tony Li Date: Fri, 1 Nov 2002 18:32:08 +0859 () CC: alh-ietf@tndh.net, Randy Bush , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony Li; > This is blatantly unfair. As an "arms merchant", I fully want > to sell gear to all interested parties, both ISPs and enterprise > alike. And, as a certain AD is fond of reminding me, the enterprise > is a very big market. Why would I want to torque the enterprise? As a person who is involved in design and operation of a nation wide 10Gbps backbone of a commercial ISP, I can say that TE is to have more bandwidth. Others may have different diffinition. But, those with high cost definition such as MPLS will, or has already, bankrupt. It's called fair competition and is applicable to non-ISP enterprises. Make routers dumb and cheap. > If we were to go down the GSE path, for > example, : Note that 8+8 proposal must not be confused by latter proposal of : routing goof by Mike O'dell, which is a proposal to use intelligent : routers to rewrite source addresses to prevent source address : spoofing and to tunnel between intelligent routers for pseudo : multihoming, both of which are against the end to end principle and, : thus, lacks robustness and/or scalability. Masataka Ohta From owner-multi6@ops.ietf.org Fri Nov 1 06:16:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03524 for ; Fri, 1 Nov 2002 06:16:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187ZoW-000DR3-00 for multi6-data@psg.com; Fri, 01 Nov 2002 03:18:08 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 187ZoU-000DQr-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 03:18:06 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA1BHh343696 for ; Fri, 1 Nov 2002 12:17:43 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 1 Nov 2002 12:17:42 +0100 (CET) From: Iljitsch van Beijnum To: Subject: GSE Message-ID: <20021101111609.G42553-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk There has been some talk about GSE in the past few days. Before anyone gets too excited about this, let me point out some of the numerous prolems with this approach: - GSE doesn't provide any failover mechanisms but depends on tunnels to repair dead customer<->ISP links. This could be done just as easily with regular PA space. - It is very unclear how GSE is supposed to work in a single host environment. Do hosts that don't sit behind a GSE-capable border router the GSE processing themselves or is this done by the ISP? - It needs changes to transport protocols and possibly to intra-site routing and address discovery. - The flat part of the identifier space makes locator discovery hard. That being said, I think GSE could be a subset of a more general approach. If you're going to map identifiers to locators one form of these identifiers could have the first 48 bits set to 0, if the identifier to locator discovery service is willing to go the extra mile and provide mappings for individual 128 bit identifiers. Or you could have 127 bit hashes as required by HIP. Or use an IPv4 or OSI NET identifier with an IPv6 locator... Being agnostic about the structure of the identifier is a good thing for future extensibility. However, using identifiers with regular IPv6 unicast semantics will make the transition a lot easier as it allows interoperability between multihoming-aware and non-multihoming aware systems and/or providing the multihoming support in separate boxes. From owner-multi6@ops.ietf.org Fri Nov 1 08:02:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05433 for ; Fri, 1 Nov 2002 08:02:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187bSC-000Jsi-00 for multi6-data@psg.com; Fri, 01 Nov 2002 05:03:12 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 187bS9-000JsW-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 05:03:09 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA1D2kS43811 for ; Fri, 1 Nov 2002 14:02:46 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 1 Nov 2002 14:02:45 +0100 (CET) From: Iljitsch van Beijnum To: Subject: Re: GSE In-Reply-To: <20021101111609.G42553-100000@sequoia.muada.com> Message-ID: <20021101134500.Y42553-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 1 Nov 2002, Iljitsch van Beijnum wrote: > Being agnostic about the structure of the identifier is a good thing for > future extensibility. However, using identifiers with regular IPv6 > unicast semantics will make the transition a lot easier Question: would it be a desireable or even required property of an identifier to be identifiable as such by all? Obviously, the destination site or host would know whether one of its addresses is an identifier or a locator. But would it be important for others to be able to make this distinction? It might be good to avoid trying to map a locator to a new locator. On the other hand, this means identifiers have to come from a separate block of IPv6 address space (assuming they look like IPv6 unicast addresses). This isn't (very) compatible with an extra address negotiation solution or with interoperation with non-multihoming aware systems. From owner-multi6@ops.ietf.org Fri Nov 1 08:43:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06391 for ; Fri, 1 Nov 2002 08:43:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187c6o-000MWq-00 for multi6-data@psg.com; Fri, 01 Nov 2002 05:45:10 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #2) id 187c6l-000MQn-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 05:45:08 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gA1DiOBe044288; Fri, 1 Nov 2002 14:44:29 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gA1DiNb7066212; Fri, 1 Nov 2002 14:44:23 +0100 Received: from dhcp22-101.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58238 from ; Fri, 1 Nov 2002 14:44:21 +0100 Message-Id: <3DC28528.F6F56BDD@hursley.ibm.com> Date: Fri, 01 Nov 2002 14:44:08 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] References: <20021030224927.X39291-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On Wed, 30 Oct 2002, RJ Atkinson wrote: > > > > Very few non-ISP organizations do this, as it requires them to move > > > traffic over their internal network which costs money, while receiving > > > the traffic where it eventually needs to be usually doesn't cost more > > > than receiving it at any other location. > > > Our samples spaces must be different. I think that many non-ISP > > organisations > > multi-home via different providers on either sides of North America. > > It is certainly possible we're seeing different things from the places > we're sitting. But the real question isn't whether they _connect_ on > opposite ends of a continent or ocean, but whether they need to announce > a globally visible route in both locations. This is only absolutely > necessary if they prefer traffic to flow over their internal network > rather than over an ISP network. It is also desireable for backup > purposes but I feel this isn't an important enough reason to allow it. Sorry, but that's not acceptable. Failover/backup is exactly why such enterprises need this. As somebody else said, there aren't that many multicontinental megacompanies that giving them unique prefixes is going to significantly inflate the default table. The case we need to worry about is hundreds of thousands of smaller, more local enterprises that nevertheless need failover; we can't afford each of them to add a prefix. But at current course and speed, that's where we're headed. Brian From owner-multi6@ops.ietf.org Fri Nov 1 08:53:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06994 for ; Fri, 1 Nov 2002 08:53:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187cGr-000NFD-00 for multi6-data@psg.com; Fri, 01 Nov 2002 05:55:33 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 187cGp-000NF0-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 05:55:31 -0800 From: Masataka Ohta Message-Id: <200211011344.WAA18127@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA18127; Fri, 1 Nov 2002 22:44:35 +0900 Subject: Re: GSE In-Reply-To: <20021101111609.G42553-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Nov 1, 2002 12:17:42 pm" To: Iljitsch van Beijnum Date: Fri, 1 Nov 2002 22:44:35 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > There has been some talk about GSE in the past few days. Hugh? Really? > Before anyone > gets too excited about this, let me point out some of the numerous > prolems with this approach: GSE is an approach with intelligent routers and hopeless that please refrain from wasting bandwith on it. > That being said, I think GSE could be a subset of a more general > approach. Wrong. Any approach containing GSE as a subset is worse than GSE. > However, using identifiers with regular IPv6 > unicast semantics will make the transition a lot easier as it allows > interoperability between multihoming-aware and non-multihoming aware > systems and/or providing the multihoming support in separate boxes. Transition from what? IPv4? OSI? Or? Our 8+8 code interoperates with leagacy v6 one, but does it make any sense? Masataka Ohta From owner-multi6@ops.ietf.org Fri Nov 1 08:55:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07078 for ; Fri, 1 Nov 2002 08:55:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187cIy-000NNx-00 for multi6-data@psg.com; Fri, 01 Nov 2002 05:57:44 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #2) id 187cIv-000NLw-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 05:57:42 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gA1Dv1Be056100; Fri, 1 Nov 2002 14:57:06 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gA1Dv07N079690; Fri, 1 Nov 2002 14:57:00 +0100 Received: from dhcp22-101.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58298 from ; Fri, 1 Nov 2002 14:56:59 +0100 Message-Id: <3DC2881E.DA400A8D@hursley.ibm.com> Date: Fri, 01 Nov 2002 14:56:46 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: RJ Atkinson Cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-04.txt References: <64FC98B6-EC77-11D6-A53C-00039357A82A@extremenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit RJ Atkinson wrote: > > On Wednesday, Oct 30, 2002, at 19:48 America/Montreal, Masataka Ohta > wrote: > > The problem is that the draft already contains mutually > > exclusive requirements. > > It would be helpful if you would list any that you find > so any that exist can be resolved. Details help. I suspect you'll find that in the list archives. But I don't think it's the point right now; I think we just need the document off our plate, with lower or UPPER case, basically I don't care, so that we can start exploring the solution space in a serious way. We could waste a lot of time making the requirements document perfect. Brian From owner-multi6@ops.ietf.org Fri Nov 1 08:56:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07117 for ; Fri, 1 Nov 2002 08:56:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187cJs-000NR8-00 for multi6-data@psg.com; Fri, 01 Nov 2002 05:58:40 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 187cJq-000NQR-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 05:58:38 -0800 Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 628CE67103; Fri, 1 Nov 2002 05:17:46 -0500 (EST) Date: Fri, 1 Nov 2002 08:57:54 -0500 Subject: Re: GSE Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20021101111609.G42553-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think that Iljitsch's note is a fine reminder that different folks have very different understandings of what the term "GSE" means. A point by point refutation seems pointless since it is clear he has a different definition of the term than some other folks on this list. Rather than have the group continue to wedge by using different definitions for that term, it would be helpful if folks avoided that term, and instead talked a bit more precisely about *their* intended meaning. For my part, I agree with tli, jnc, and others that the best architectural approach to supporting multi-homing while not hosing the operational routers in the DFZ is to separate host identity from routing goop. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Fri Nov 1 09:04:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07720 for ; Fri, 1 Nov 2002 09:04:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187cQv-000Nyc-00 for multi6-data@psg.com; Fri, 01 Nov 2002 06:05:57 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 187cQt-000NxP-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 06:05:55 -0800 Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 9451167103; Fri, 1 Nov 2002 05:25:15 -0500 (EST) Date: Fri, 1 Nov 2002 09:05:23 -0500 Subject: Re: GSE Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20021101134500.Y42553-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A reasonable approach is to say that the low order 64 bits of an IPv6 unicast address identify a host within a subnet and that the high-order 64-bits of an IPv6 unicast address identify the subnet itself. This would both support tli's proposal and not be wildly inconsistent with existing IPv6 specs. Ran On Friday, Nov 1, 2002, at 08:02 America/Montreal, Iljitsch van Beijnum wrote: > Question: would it be a desireable or even required property of an > identifier to be identifiable as such by all? > > Obviously, the destination site or host would know whether one of its > addresses is an identifier or a locator. But would it be important for > others to be able to make this distinction? It might be good to avoid > trying to map a locator to a new locator. On the other hand, this means > identifiers have to come from a separate block of IPv6 address space > (assuming they look like IPv6 unicast addresses). This isn't (very) > compatible with an extra address negotiation solution or with > interoperation with non-multihoming aware systems. > From owner-multi6@ops.ietf.org Fri Nov 1 09:10:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08581 for ; Fri, 1 Nov 2002 09:10:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187cXA-000OXv-00 for multi6-data@psg.com; Fri, 01 Nov 2002 06:12:24 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #2) id 187cX8-000OVV-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 06:12:22 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gA1EBQ6Q017244; Fri, 1 Nov 2002 15:11:27 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gA1EBNb7045072; Fri, 1 Nov 2002 15:11:23 +0100 Received: from dhcp22-101.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA35814 from ; Fri, 1 Nov 2002 15:11:22 +0100 Message-Id: <3DC28B7D.84ED9B8E@hursley.ibm.com> Date: Fri, 01 Nov 2002 15:11:09 +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: RJ Atkinson , multi6@ops.ietf.org Subject: Re: The state of IPv6 multihoming development References: <20021030223459.X39291-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On Wed, 30 Oct 2002, RJ Atkinson wrote: > > > I think it is important to understand what the deployed reality is > > today. > > That impacts how widely useful some solutions might be, particularly > > in the case of so-called "geographic addressing". I also think it > > is important to understand when a given solution will not work with > > some/all deployed networks. Financial realities mean that an IETF > > document standardising a solution that requires more interconnection > > probably will not lead to firms changing their topologies anytime soon > > to meet such a requirement. > > Nobody is proposing a solution that needs more exchanges in order to be > useful. You may not think so, but I find it hard to believe. > Just to be safe I've included a statement to this effect in the > abstract of draft-van-beijnum-multi6-isp-int-aggr-00.txt. This statement will not impress business managers who see an opportunity to create exchanges. > New exchanges > would only be necessary if this solution were to be used much longer > than intended, I assume that whatever gets deployed will be around for 20 or 30 years minimum. > but as we approach one multihomer in 10 people even flat > routing for a single city such as New York, Tokio or Mexico City will be > problematic. I wouldn't expect domestic users to be MH, so I don't expect to see a million MH sites in those cities. > > > > Granted the logical circuit topology is not limited > > > to that, but again, how many real exceptions will exist, and how many > > > of those will exist despite every attempt to prevent them? > > > A fair number of exceptions exist today. > > But then what's common today may be tomorrow's exception and the other > way around. For instance, someone with ADSL doing BGP routing with IPv6 > and a "real" AS number is very rare today, while the number of > organizations connecting to the internet in far apart locations is > something that regularly happens (although I suspect the actual number > isn't all that high). In the future, this will very likely be different. > It could even be argued that existing cases are of no importance to > routing scalability and it's enough to make new cases scalable. > > Also note that as of today, NO end-user networks are multihomed in IPv6. Just wait until we are running real production needing 99.9% up time. Brian From owner-multi6@ops.ietf.org Fri Nov 1 09:10:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08678 for ; Fri, 1 Nov 2002 09:10:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187cXc-000OZ1-00 for multi6-data@psg.com; Fri, 01 Nov 2002 06:12:52 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 187cXa-000OYp-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 06:12:50 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA1ECPZ43955; Fri, 1 Nov 2002 15:12:25 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 1 Nov 2002 15:12:24 +0100 (CET) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: Re: GSE In-Reply-To: Message-ID: <20021101150913.O43861-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 1 Nov 2002, RJ Atkinson wrote: > I think that Iljitsch's note is a fine reminder that different folks > have very different understandings of what the term "GSE" means. A > point by point refutation seems pointless since it is clear he has > a different definition of the term than some other folks on this list. I based my comments on "GSE - An Alternate Addressing Architecture for IPv6" , available at: http://arneill-py.sacramento.ca.us/ipv6mh/draft-ipng-gseaddr-00.txt From owner-multi6@ops.ietf.org Fri Nov 1 09:33:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11399 for ; Fri, 1 Nov 2002 09:33:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187cu0-0000AJ-00 for multi6-data@psg.com; Fri, 01 Nov 2002 06:36:00 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 187ctx-0000A7-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 06:35:57 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA1EZXd44009; Fri, 1 Nov 2002 15:35:33 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 1 Nov 2002 15:35:33 +0100 (CET) From: Iljitsch van Beijnum To: Brian E Carpenter cc: Subject: Re: The state of IPv6 multihoming development In-Reply-To: <3DC28B7D.84ED9B8E@hursley.ibm.com> Message-ID: <20021101151439.S43861-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 1 Nov 2002, Brian E Carpenter wrote: > > Nobody is proposing a solution that needs more exchanges in order to be > > useful. > You may not think so, but I find it hard to believe. What my geo proposal needs is many routers that interconnect with routers from oether networks. Where they are located isn't important in itself, but using geo at gives the _potential_ to have optimized routing. Whether this potential is realized depends on the actual topology. A different aggregation hierarchy doesn't provide the potential for optimized routing by itself so it needs a level of indirection to do this. This will scale better, but (unlike my geo proposal) it can't be deployed in the very short term as it requires new code. > > Just to be safe I've included a statement to this effect in the > > abstract of draft-van-beijnum-multi6-isp-int-aggr-00.txt. > This statement will not impress business managers who see an > opportunity to create exchanges. Which is a good thing irrespective of the solutions adopted. > > New exchanges > > would only be necessary if this solution were to be used much longer > > than intended, > I assume that whatever gets deployed will be around for 20 or 30 years > minimum. There is considerable consensus here that a multi-address/locator scheme will solve the long-term problem. This solution or set of solutions will be around in 20 or 30 years. If my draft is implemented and not superseded by something better in 20 years we obviously haven't been able to agree on the requirements by then... > > but as we approach one multihomer in 10 people even flat > > routing for a single city such as New York, Tokio or Mexico City will be > > problematic. > I wouldn't expect domestic users to be MH, so I don't expect to see > a million MH sites in those cities. 1G was the lowest figure that wasn't challenged on this list as being too optimistic. 1G = 1:10 in ~2050. > > Also note that as of today, NO end-user networks are multihomed in IPv6. > Just wait until we are running real production needing 99.9% up time. It's not the need that's lacking, but the means. The RIRs won't assign you PI space, and the ISPs won't route it. From owner-multi6@ops.ietf.org Fri Nov 1 09:40:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12235 for ; Fri, 1 Nov 2002 09:40:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187d0n-0000lU-00 for multi6-data@psg.com; Fri, 01 Nov 2002 06:43:01 -0800 Received: from elle.sprintlink.net ([199.0.234.34] helo=iscserv1.res.sprintlink.net) by psg.com with esmtp (Exim 3.36 #2) id 187d0l-0000lG-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 06:42:59 -0800 Received: from localhost (rrockell@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id JAA00935 for ; Fri, 1 Nov 2002 09:44:44 -0500 (EST) X-Authentication-Warning: iscserv1.res.sprintlink.net: rrockell owned process doing -bs Date: Fri, 1 Nov 2002 09:44:44 -0500 (EST) From: "Robert J. Rockell" X-X-Sender: To: Subject: Re: GSE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_PINE,X_AUTH_WARNING version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk ->For my part, I agree with tli, jnc, and others that the best ->architectural ->approach to supporting multi-homing while not hosing the operational ->routers ->in the DFZ is to separate host identity from routing goop. Agree fully. -> ->Ran ->rja@extremenetworks.com -> -> From owner-multi6@ops.ietf.org Fri Nov 1 10:05:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15167 for ; Fri, 1 Nov 2002 10:05:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187dNl-0002Sw-00 for multi6-data@psg.com; Fri, 01 Nov 2002 07:06:45 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 187dNj-0002Sh-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 07:06:43 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 187dNh-0007tm-00; Fri, 01 Nov 2002 07:06:41 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Tony Hain" Cc: "'Tony Li'" , Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] References: <015601c28175$3b644920$237ba8c0@eagleswings> Message-Id: Date: Fri, 01 Nov 2002 07:06:41 -0800 X-Spam-Status: No, hits=-6.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Operational issues in the ISP space have always favored restricting > topology or the knowledge about unaggregated parts thereof. not at all. they have merely been focused on maintaining the knowledge of topology by keeping routers from melting down. and this is not theory, we lived it. that most schemes folk have for new topologies have not been realistic in terms of routing table expansion, should not be taken as isps wanting to suppress information. that you can't holiday on mars this weekend is not my fault. information reduction has been is the only tool the isps have to deal with routing bloat and weak vendor hardware. if you would care to suggest others, i am all ears. randy From owner-multi6@ops.ietf.org Fri Nov 1 11:21:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20398 for ; Fri, 1 Nov 2002 11:21:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187eZa-00082m-00 for multi6-data@psg.com; Fri, 01 Nov 2002 08:23:02 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 187eZY-00081p-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 08:23:01 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id LAA07641; Fri, 1 Nov 2002 11:22:58 -0500 Date: Fri, 1 Nov 2002 11:22:58 -0500 From: "J. Noel Chiappa" Message-Id: <200211011622.LAA07641@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Hain" >> We need to decide which is more important: the scalability and >> durability of the routing subsystem or the convenience of >> non-connection based addressing. When we have consensus on this point, >> then all else will follow. > The answer to the question depends on which side of the table you are > sitting on. Really? How much use will someone's non-connection based addresses be when the routing is no longer working, which means that nobody's packets are getting anywhere? Noel From owner-multi6@ops.ietf.org Fri Nov 1 11:43:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21587 for ; Fri, 1 Nov 2002 11:43:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187ev6-0009kg-00 for multi6-data@psg.com; Fri, 01 Nov 2002 08:45:16 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 187ev4-0009kU-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 08:45:14 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id LAA07767; Fri, 1 Nov 2002 11:45:13 -0500 Date: Fri, 1 Nov 2002 11:45:13 -0500 From: "J. Noel Chiappa" Message-Id: <200211011645.LAA07767@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Hain" > operational issues in the edge enterprise space favor provider > independence for maximum flexibility. No doubt operational issues in the edge enterprise space would favor perpetual motion machines - if they existed. Noel From owner-multi6@ops.ietf.org Fri Nov 1 12:02:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22631 for ; Fri, 1 Nov 2002 12:02:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187fDd-000B7X-00 for multi6-data@psg.com; Fri, 01 Nov 2002 09:04:25 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.36 #2) id 187fDb-000B50-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 09:04:23 -0800 Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA1H3pPP011642; Fri, 1 Nov 2002 09:03:51 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA1H3or4026790; Fri, 1 Nov 2002 09:03:51 -0800 (PST) Received: from dhcp1205.nanog26.merit.net (sjc-vpn1-31.cisco.com [10.21.96.31]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA26329; Fri, 1 Nov 2002 09:03:49 -0800 (PST) Date: Fri, 1 Nov 2002 11:03:51 -0600 (Central Standard Time) From: "Craig A. Huegen" To: "J. Noel Chiappa" cc: multi6@ops.ietf.org Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: <200211011645.LAA07767@ginger.lcs.mit.edu> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 1 Nov 2002, J. Noel Chiappa wrote: > > operational issues in the edge enterprise space favor provider > > independence for maximum flexibility. > > No doubt operational issues in the edge enterprise space would favor > perpetual motion machines - if they existed. As would operational issues in the ISP space. Can we please quit the bickering? The point that Tony H. is trying to make (I think, correct me if I'm wrong here) is that the multi-PA solution makes life very easy for ISP's while throwing all of the operational issues of supporting such a solution on the end-sites. As an operator of an enterprise network with tens of thousands of segments, I fully agree with that statement. Many other enterprises I've spoken to also concur with that statement, and are holding back on IPv6 deployment for that reason. With that said, let's find some solutions. I also agree with the idea of separating router goop from identities; however, I also am a pragmatist and am concerned with the existing applications that would break with this. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Fri Nov 1 12:04:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22792 for ; Fri, 1 Nov 2002 12:04:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187fGD-000BLk-00 for multi6-data@psg.com; Fri, 01 Nov 2002 09:07:05 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #2) id 187fFi-000BHI-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 09:06:34 -0800 content-class: urn:content-classes:message Subject: RE: draft-ietf-multi6-multihoming-requirements-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Nov 2002 09:06:38 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3EA@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: draft-ietf-multi6-multihoming-requirements-04.txt Thread-Index: AcKBr2DARJ+7rwbpThOJ/dL+j379kgAGKv+g From: "Michel Py" To: "Brian E Carpenter" Cc: X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA22792 Brian, > Brian E Carpenter wrote: > I think we just need the document off our plate, with lower > or UPPER case, basically I don't care, so that we can start > exploring the solution space in a serious way. > We could waste a lot of time making the requirements > document perfect. This was exactly my point a year ago. Trouble is: 1. We don't need this document to explore the solution space, as we are going to ignore it in certain situations, and as the charter says. 2. Shipping this document as-is is not going to attract protocol developers, because it's a powerful weapon to cancel any solution that anybody does not like. Writing a protocol is a lot of work, and there is little point doing it if the work is going to fall into the oblivion of unrealistic requirements anyway. Michel. From owner-multi6@ops.ietf.org Fri Nov 1 12:12:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23169 for ; Fri, 1 Nov 2002 12:12:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187fN7-000BwP-00 for multi6-data@psg.com; Fri, 01 Nov 2002 09:14:13 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 187fN5-000BwC-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 09:14:11 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA1HDeq44394; Fri, 1 Nov 2002 18:13:40 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 1 Nov 2002 18:13:39 +0100 (CET) From: Iljitsch van Beijnum To: Masataka Ohta cc: Subject: Re: GSE In-Reply-To: <200211011344.WAA18127@necom830.hpcl.titech.ac.jp> Message-ID: <20021101180759.R43861-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 1 Nov 2002, Masataka Ohta wrote: > > That being said, I think GSE could be a subset of a more general > > approach. > Wrong. Any approach containing GSE as a subset is worse than GSE. With a solution that can work with any kind of structure for the identifier it would be easy to implement GSE for those who still want it, without betting all our cards on one horse or a cliche of similar sentiment. > > However, using identifiers with regular IPv6 > > unicast semantics will make the transition a lot easier as it allows > > interoperability between multihoming-aware and non-multihoming aware > > systems and/or providing the multihoming support in separate boxes. > Transition from what? IPv4? OSI? Or? Transition from existing v6. From owner-multi6@ops.ietf.org Fri Nov 1 12:32:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24402 for ; Fri, 1 Nov 2002 12:32:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187fgs-000DXH-00 for multi6-data@psg.com; Fri, 01 Nov 2002 09:34:38 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 187fgq-000DWc-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 09:34:36 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA1HY7S44441; Fri, 1 Nov 2002 18:34:08 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 1 Nov 2002 18:34:07 +0100 (CET) From: Iljitsch van Beijnum To: "Craig A. Huegen" cc: Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: Message-ID: <20021101182137.A43861-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 1 Nov 2002, Craig A. Huegen wrote: > The point that Tony H. is trying to make (I think, correct me if I'm > wrong here) is that the multi-PA solution makes life very easy for ISP's > while throwing all of the operational issues of supporting such a solution > on the end-sites. Craig, I've been looking at your messages to this list from the past week or so to see what exactly your position on identifier/locator solutions are, but I've been unable to distill anything definitive. So lat me ask you if a solution with the following properties is acceptable to you: As far as your own hosts, the DNS and remote hosts are concerned, hosts in your network have a single address. However, at the edges of your network you need boxes that do some address magic so your packets get to pass through backbone networks as if you were using regular PA. Traffic engineering is still possible as before, or can be done with finer granularity, at or very close to the edges but requires more effort (ie extra hardware, or more processing on existing hardware) to do. You have a choice between being reachable without any multihoming benefits for people who do not implement the new scheme, but you have to use PA addresses, or you can use PI but no interoperation with hosts that don't implement the new multihoming solution(s) or sit behind a box that handles this for them. I'm not saying this is exactly what a solution will look like (hopefully we can improve on this) but I'm pretty confident a more advanced multi-address solution can meet the above description. Iljitsch From owner-multi6@ops.ietf.org Fri Nov 1 12:37:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24537 for ; Fri, 1 Nov 2002 12:37:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187flf-000Dva-00 for multi6-data@psg.com; Fri, 01 Nov 2002 09:39:35 -0800 Received: from dhcp3217.nanog26.merit.net ([192.35.167.217] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 187fld-000DvO-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 09:39:33 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gA1Hdpwc001149; Fri, 1 Nov 2002 18:39:51 +0100 (CET) Date: Fri, 1 Nov 2002 18:39:51 +0100 Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20021030120513.A36604-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > meeting the fact that the exchange couldn't get provider independent > IPv6 address space was debated at length, RIPE has similar problems and > As an exchange operator in the RIPE region - just to be clear, the exchanges can get provider independent space for the actual exchanges, but not for the services. I have had this discussion and been convinced that that is not a problem. What might be a problem is certain services that might be hosted at the exchanges such as TLD slave servers. But that is an issue with services, not with exchanges. - kurtis - From owner-multi6@ops.ietf.org Fri Nov 1 13:06:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26484 for ; Fri, 1 Nov 2002 13:06:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187gDi-000GDw-00 for multi6-data@psg.com; Fri, 01 Nov 2002 10:08:34 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 187gDf-000GD8-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 10:08:31 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Nov 2002 10:08:34 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , "'Randy Bush'" Cc: Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Fri, 1 Nov 2002 10:08:23 -0800 Message-ID: <023001c281d1$aafb7770$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-5.0 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA26484 Tony Li wrote: > Tony, > > This is blatantly unfair. As an "arms merchant", I fully > want to sell gear to all interested parties, both ISPs and > enterprise alike. And, as a certain AD is fond of reminding > me, the enterprise is a very big market. Why would I want to > torque the enterprise? I think you read more into that note than was there. It was not an attack on anyone, I was simply observing that the recent discussion was focused on core routing issues. > > Instead, I want to help all parties by growing the net in a > reasonable and scalable way. That should be what we're all > trying to do here. I believe it is, I was just asking if we have the appropriate representation to make a balanced choice when the hard trade-offs start being made. > > The operation issues that I know of NEVER favor restricting > topology. Favoring is not the same as enforcing. > In fact, restricting topology is the result of > geographic aggregation as it forces providers to interconnect > within the aggregation boundary. I am not trying to promote any particular solution, just make sure the requirements of the edge are represented. > Operational issues instead > favor a haphazard, need driven, cost optimized topology. > Yes, ok it's chaotic, but it's the result of capitalism at its finest. It is the 'cost optimized' part that makes the difference. Which pockets are we talking about protecting? I am not saying we should favor any particular pocket, just asking if we are doing it unintentionally by the representatives around the table. > > Provider independence isn't necessarily helped only by PI > space. There are other ways. The real point is to avoid the > pain and anguish of renumbering. That is one reason; simply being in control of your own destiny is another. > If we were to go down the > GSE path, for example, changing providers simply means > changing the "routing gorp". The host identifier remains the > same. You reconfigure your border > router(s) and you're done. Infinitely less painful than > dealing with the boring things like acutally bringing up a > new tail circuit. ;-) This argument is continually shot at using the multi-prefix model as not workable because there are too many static tables inside enterprises that 'need' to carry the real address for access control. I am not arguing it is valid or correct, just that the viewpoint exists. > > You are also assuming that aggregation and multihoming are somehow > at odds. They are not. All you have to do is to disconnect > the locator and the identifier as GSE does and aggregate only the > locators. Each host in a multihomed domain has a single > identifier, but multiple locators. No deaggregation happens > because the locators are bound to the provider and thus we > have good topological 'addressing'. The enterprise doesn't > lose because we tweak the transport to base the pseudoheader > on the host identifier and then let the locator be free to be > replaced by border routers. Connections flip back and forth > between locators easily. This model was probably possible 4 years ago, but at this point I doubt tweaking the pseudoheader can even be on the table. Also, 'freely replaced' usually sets off the alarm bells of the spoof-sensitive security types. That does not mean we GSE is hopeless, just that we will probably have to use something like MIPv6 to mask the label swapping. In the abstract, there is not much difference between GSE and a Care-of Address. So for routing & packet forwarding, if the CoA had finer grained pattern replacement happening the end systems would not be aware of it. The missing link would be letting the host know what the current publicly visible address is so it could pass that to the CN. Tony > > How does this not solve the (non-ideological) issues at hand? > > Tony > > | -----Original Message----- > | From: Tony Hain [mailto:alh-ietf@tndh.net] > | Sent: Thursday, October 31, 2002 11:07 PM > | To: 'Randy Bush' > | Cc: Tony Li; multi6@ops.ietf.org > | Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming > | development] > | > | > | Randy Bush wrote: > | > > | > >> We need to decide which is more important: the > scalability and > | > >> durability of the routing subsystem or the convenience of > | > >> non-connection based addressing. When we have > | consensus on this > | > >> point, then all else will follow. > | > > The answer to the question depends on which side of the > | > table you are > | > > sitting on. > | > > | > there is little doubt in my mind which side i sit on. > | > interesting that tli seems to be on the same side. but then > | > he always kinda groked the operational issues. > | > | Operational issues in the ISP space have always favored > restricting > | topology or the knowledge about unaggregated parts thereof. > | At the same > | time, operational issues in the edge enterprise space > favor provider > | independence for maximum flexibility. We have > | representative voices for > | the ISP issues, where are the comparable voices for the enterprise > | issues? The ISP focus carried round 1, so the allocation > policy only > | allows for strict aggregation via provider blocks. The > | enterprise demand > | for multi-homing is the fundamental issue this WG is supposed to > | address, but the primary voices are those insisting on maximal > | aggregation for the ISP routing system. It is hard to > | believe this will > | end up with a well balanced result that considers all the > | requirements. > | > | Speaking of, we have a requirements doc that needs to get > | published. > | > | Tony > | > | > From owner-multi6@ops.ietf.org Fri Nov 1 13:24:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27450 for ; Fri, 1 Nov 2002 13:24:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187gV0-000HbP-00 for multi6-data@psg.com; Fri, 01 Nov 2002 10:26:26 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 187gUy-000HQA-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 10:26:24 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id EE54623C42; Thu, 31 Oct 2002 13:32:30 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gA1IPqiI018366; Fri, 1 Nov 2002 10:25:53 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: The state of IPv6 multihoming development Date: Fri, 1 Nov 2002 10:25:52 -0800 Message-ID: Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcKBsSU04be1oC2GSzW86imhSXgQRQAIDJhw From: "Tony Li" To: "Brian E Carpenter" , "Iljitsch van Beijnum" Cc: "RJ Atkinson" , X-Spam-Status: No, hits=0.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA27450 | I wouldn't expect domestic users to be MH, so I don't expect to see | a million MH sites in those cities. Brian, I would ask that you sit and rethink this for a moment. While being MH right now is beyond the needs and costs of most people, I can see a future in which this is not true. With many folks attempting to solve the last mile problem, I can see high speed bandwidth available via fiber, cable, wireless and DSL in the next few years. The competition will drive down cost. And those folks who find net access to be a requirement for their daily lives, such as telecommuters, may well decide to MH. We see this already with certain netgeeks today. Also, small businesses are also candidates for MH. We already see gas stations with satellite dishes. Other folks are already putting IP addresses on their cars. Given all of this and the fact that we want an architecture that lasts, we should have the flexibility to accomodate this future. This level of MH has an interesting impact. We need to be able to support millions of MH sites in a "metro" area. The operational reality here is that flat routing at this level is probably not a good idea. This implies that if we were going down the geo path, we would really want to do this at finer granularity. I'd suggest that we need to be at something like CO granularity. Of course, multiple levels of hierarchy would be beneficial, so this is in addition to metro aggregation. Make sense? Tony From owner-multi6@ops.ietf.org Fri Nov 1 13:25:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27495 for ; Fri, 1 Nov 2002 13:25:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187gW3-000HkD-00 for multi6-data@psg.com; Fri, 01 Nov 2002 10:27:31 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 187gW1-000Hjx-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 10:27:29 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Nov 2002 10:27:37 -0800 Reply-To: From: "Tony Hain" To: "'Randy Bush'" Cc: "'Tony Li'" , Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Fri, 1 Nov 2002 10:27:25 -0800 Message-ID: <023301c281d4$544d30f0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-4.8 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA27495 Randy Bush wrote: > > > > Operational issues in the ISP space have always favored restricting > > topology or the knowledge about unaggregated parts thereof. > > not at all. they have merely been focused on maintaining the > knowledge of topology by keeping routers from melting down. > and this is not theory, we lived it. We are in violent agreement here... Keeping the routers from melting down leads to favoring approaches that keep the topology or knowledge bounded. > > that most schemes folk have for new topologies have not been > realistic in terms of routing table expansion, should not be > taken as isps wanting to suppress information. that you > can't holiday on mars this weekend is not my fault. I am not arguing that the ISP is wrong for wanting to cost optimize, or simply stay afloat, just that there are reasons behind the demand for the 'unrealistic topologies' and those reasons are just as valid even if the proposed topologies are not. > > information reduction has been is the only tool the isps have > to deal with routing bloat and weak vendor hardware. if you > would care to suggest others, i am all ears. I am not attacking ISPs or their motives. I was asking the simple question, do we have the representative voices that can tell us the cost to the edges of that information reduction? Yes it is the only hammer we have, but we can choose to tap lightly, swing hard, or something in between to achieve a balance that keeps the routing system intact while also allowing the edges to get their job done. Tony > > randy > From owner-multi6@ops.ietf.org Fri Nov 1 13:29:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27711 for ; Fri, 1 Nov 2002 13:29:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187gZx-000Hxc-00 for multi6-data@psg.com; Fri, 01 Nov 2002 10:31:33 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 187gZw-000HxQ-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 10:31:32 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 187gZw-000DWD-00; Fri, 01 Nov 2002 10:31:32 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Tony Hain" Cc: multi6@ops.ietf.org Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] References: <023301c281d4$544d30f0$237ba8c0@eagleswings> Message-Id: Date: Fri, 01 Nov 2002 10:31:32 -0800 X-Spam-Status: No, hits=-6.9 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> that most schemes folk have for new topologies have not been >> realistic in terms of routing table expansion, should not be >> taken as isps wanting to suppress information. that you >> can't holiday on mars this weekend is not my fault. > I am not arguing that the ISP is wrong for wanting to cost > optimize, or simply stay afloat i said nothing about cost, staying afloat, ... i did not go above layer four. > just that there are reasons behind the demand for the > 'unrealistic topologies' and those reasons are just as valid even > if the proposed topologies are not. that's nice. but this is the internet ENGINEERING task force. we have the sad problems of dealing with reality. randy From owner-multi6@ops.ietf.org Fri Nov 1 13:39:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28087 for ; Fri, 1 Nov 2002 13:39:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187gix-000ImV-00 for multi6-data@psg.com; Fri, 01 Nov 2002 10:40:51 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 187giv-000ImI-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 10:40:49 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Nov 2002 10:40:57 -0800 Reply-To: From: "Tony Hain" To: "'Iljitsch van Beijnum'" , "'Craig A. Huegen'" Cc: Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Fri, 1 Nov 2002 10:40:45 -0800 Message-ID: <023401c281d6$30ded6d0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <20021101182137.A43861-100000@sequoia.muada.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-4.8 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA28087 Iljitsch, You raise a point here that I think gets lost in the mapping proposals. 'As far as your own hosts, the DNS and remote hosts are concerned, hosts in your network have a single address.' If the upper 48 bits are constant in DNS, but continually changing in the routing system, there needs to be a way to pass the possible set of topologically appropriate replacement values between the CPE routers. Since this protocol would inherently have to be run between organizations that have no trust relationship, how that be deployable? If it were run between the PE routers, trust is managable to a point, but what would prevent something like the POTS practice of slamming? Tony > -----Original Message----- > From: owner-multi6@ops.ietf.org > [mailto:owner-multi6@ops.ietf.org] On Behalf Of Iljitsch van Beijnum > Sent: Friday, November 01, 2002 9:34 AM > To: Craig A. Huegen > Cc: multi6@ops.ietf.org > Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming > development] > > > On Fri, 1 Nov 2002, Craig A. Huegen wrote: > > > The point that Tony H. is trying to make (I think, correct > me if I'm > > wrong here) is that the multi-PA solution makes life very easy for > > ISP's while throwing all of the operational issues of > supporting such > > a solution on the end-sites. > > Craig, I've been looking at your messages to this list from > the past week or so to see what exactly your position on > identifier/locator solutions are, but I've been unable to > distill anything definitive. So lat me ask you if a solution > with the following properties is acceptable to you: > > As far as your own hosts, the DNS and remote hosts are > concerned, hosts in your network have a single address. > However, at the edges of your network you need boxes that do > some address magic so your packets get to pass through > backbone networks as if you were using regular PA. Traffic > engineering is still possible as before, or can be done with > finer granularity, at or very close to the edges but requires > more effort (ie extra hardware, or more processing on > existing hardware) to do. > > You have a choice between being reachable without any > multihoming benefits for people who do not implement the new > scheme, but you have to use PA addresses, or you can use PI > but no interoperation with hosts that don't implement the new > multihoming solution(s) or sit behind a box that handles this > for them. > > I'm not saying this is exactly what a solution will look like > (hopefully we can improve on this) but I'm pretty confident a > more advanced multi-address solution can meet the above description. > > Iljitsch > > From owner-multi6@ops.ietf.org Fri Nov 1 13:53:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28604 for ; Fri, 1 Nov 2002 13:53:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187gwS-000JyZ-00 for multi6-data@psg.com; Fri, 01 Nov 2002 10:54:48 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 187gwQ-000Jxg-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 10:54:46 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 03BC423C42; Thu, 31 Oct 2002 14:00:50 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gA1IsBiI020246; Fri, 1 Nov 2002 10:54:11 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: GSE Date: Fri, 1 Nov 2002 10:54:11 -0800 Message-ID: Thread-Topic: GSE Thread-Index: AcKBp/o21nhQxbBWRMC3i9KBDGbJfgAL6dmQ From: "Tony Li" To: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA28604 | > Being agnostic about the structure of the identifier is a | good thing for | > future extensibility. However, using identifiers with regular IPv6 | > unicast semantics will make the transition a lot easier If only have current IPv6 unicast semantics, then we don't get to change the architecture. | Question: would it be a desireable or even required property of an | identifier to be identifiable as such by all? Yes, I think that there should be a common well known location for the identifier in the packet header. Ran's suggestion of 64 bits would be fine with me. We can talk about identification allocation separately. For the moment, I'm going to refer to this proposal as 16+16, for obvious reasons. | Obviously, the destination site or host would know whether | one of its | addresses is an identifier or a locator. But would it be | important for | others to be able to make this distinction? It might be | good to avoid | trying to map a locator to a new locator. On the other | hand, this means | identifiers have to come from a separate block of IPv6 address space | (assuming they look like IPv6 unicast addresses). This isn't (very) | compatible with an extra address negotiation solution or with | interoperation with non-multihoming aware systems. I would suggest that we take a cue from 8+8 and make the two number spaces completely orthogonal. This avoids the confusion. Tony From owner-multi6@ops.ietf.org Fri Nov 1 13:54:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28671 for ; Fri, 1 Nov 2002 13:54:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187gyU-000KBT-00 for multi6-data@psg.com; Fri, 01 Nov 2002 10:56:54 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 187gyS-000KBB-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 10:56:52 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Nov 2002 10:57:00 -0800 Reply-To: From: "Tony Hain" To: "'Randy Bush'" Cc: Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Fri, 1 Nov 2002 10:56:49 -0800 Message-ID: <023501c281d8$6f4a1400$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-5.6 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush wrote: > >> that most schemes folk have for new topologies have not been > >> realistic in terms of routing table expansion, should not be > >> taken as isps wanting to suppress information. that you > >> can't holiday on mars this weekend is not my fault. > > I am not arguing that the ISP is wrong for wanting to cost > optimize, > > or simply stay afloat > > i said nothing about cost, staying afloat, ... i did not go > above layer four. I don't know where you thought I was going, but I was talking about staying afloat in the same sense as keeping the routers from melting down, and cost optimization is a fundemental aspect of engineering. > > > just that there are reasons behind the demand for the 'unrealistic > > topologies' and those reasons are just as valid even if the > proposed > > topologies are not. > > that's nice. but this is the internet ENGINEERING task > force. we have the sad problems of dealing with reality. My point was that the requirements of the edge sites are reality. Ignoring them may make it easier to accomplish something, but is the result useful? Tony > > randy > > From owner-multi6@ops.ietf.org Fri Nov 1 13:58:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28877 for ; Fri, 1 Nov 2002 13:58:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187h22-000KUL-00 for multi6-data@psg.com; Fri, 01 Nov 2002 11:00:34 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 187h21-000KTB-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 11:00:33 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id E01AD23C38; Thu, 31 Oct 2002 14:06:40 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gA1J02iI020661; Fri, 1 Nov 2002 11:00:02 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: GSE Date: Fri, 1 Nov 2002 11:00:02 -0800 Message-ID: Thread-Topic: GSE Thread-Index: AcKBmTTdOq7UfxVmTSSiF4Cg9koxTwAPuUBQ From: "Tony Li" To: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA28877 Let me suggest some ways that 16+16 might work: | - GSE doesn't provide any failover mechanisms but depends | on tunnels to | repair dead customer<->ISP links. This could be done just | as easily | with regular PA space. Each host needs to advertise its locator to correspondent hosts. Whether this happens via DNS or via a mobile IP type solution is more detailed than we need to be right now, but basically, the correspondent can get multiple locators for any MH host. Failover in this case is simply changing the locator in the packet and does not require tunneling. | - It is very unclear how GSE is supposed to work in a single host | environment. Do hosts that don't sit behind a GSE-capable border | router the GSE processing themselves or is this done by the ISP? It seems to me that either is a viable solution at this point. Both may even be necessary. | - It needs changes to transport protocols and possibly to intra-site | routing and address discovery. It certainly requires changes to the transport protocols. I don't see any changes to intra-site routing unless one wants to be MH within the site between IGP areas. | - The flat part of the identifier space makes locator | discovery hard. Identifiers need not be flat. They could be hierarchically assigned administrative entities. Tony From owner-multi6@ops.ietf.org Fri Nov 1 14:16:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29678 for ; Fri, 1 Nov 2002 14:16:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187hIx-000M3e-00 for multi6-data@psg.com; Fri, 01 Nov 2002 11:18:03 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #2) id 187hIu-000M3I-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 11:18:00 -0800 Received: from [192.35.165.17] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E360F137F0B; Fri, 1 Nov 2002 11:17:59 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 01 Nov 2002 11:20:08 -0800 Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] From: David Conrad To: , "'Iljitsch van Beijnum'" , "'Craig A. Huegen'" Cc: multi6 Message-ID: In-Reply-To: <023401c281d6$30ded6d0$237ba8c0@eagleswings> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-8.9 required=5.0 tests=EMAIL_ATTRIBUTION,INVALID_MSGID,IN_REP_TO, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_ENTOURAGE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony, On 11/1/02 10:40 AM, "Tony Hain" wrote: > If the upper 48 bits are constant in DNS, but continually changing in > the routing system, there needs to be a way to pass the possible set of > topologically appropriate replacement values between the CPE routers. > Since this protocol would inherently have to be run between > organizations that have no trust relationship, how that be deployable? > If it were run between the PE routers, trust is managable to a point, > but what would prevent something like the POTS practice of slamming? Quarter-baked idea. How about: .route.arpa AAAA <8-n bits routing locator> DNSSEC signed, with the globally unique identifier "owner" holding the KEY? Multihoming could be implemented by: .route.arpa AAAA <8-n bits routing locator> AAAA AAAA ... SIG The border router/tunnel end point does the lookup, chooses the routing locator to prepend to the identifier. Hmmm. It'd be nice if the transport layer only looked at the identifier for checksums. Rgds, -drc From owner-multi6@ops.ietf.org Fri Nov 1 14:49:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00934 for ; Fri, 1 Nov 2002 14:49:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187ho4-000Ocy-00 for multi6-data@psg.com; Fri, 01 Nov 2002 11:50:12 -0800 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.36 #2) id 187ho0-000OTn-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 11:50:08 -0800 Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id OAA29119; Fri, 1 Nov 2002 14:49:44 -0500 (EST) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id OAA19993; Fri, 1 Nov 2002 14:49:35 -0500 (EST) Date: Fri, 1 Nov 2002 14:49:35 -0500 (EST) From: Greg Maxwell To: Tony Li cc: Iljitsch van Beijnum , Subject: RE: GSE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 1 Nov 2002, Tony Li wrote: > | - It needs changes to transport protocols and possibly to intra-site > | routing and address discovery. > > It certainly requires changes to the transport protocols. I don't see > any changes to intra-site routing unless one wants to be MH within the > site between IGP areas. Within an IGP area I would suggest that we flood routes like on today's networks (classic multihoming). It's global where the aggregation is a concern. If any single network becomes large enough for it to be a problem, then you break it up and confine the routes of each portion to that portion. In any case, the cost and instability caused by having routes is carried only by those creating the routes. From owner-multi6@ops.ietf.org Fri Nov 1 14:57:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01154 for ; Fri, 1 Nov 2002 14:57:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187hwJ-000PI7-00 for multi6-data@psg.com; Fri, 01 Nov 2002 11:58:43 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 187hwG-000PHS-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 11:58:40 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 859DF3443B; Fri, 1 Nov 2002 12:07:10 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gA1Jw9iI025544; Fri, 1 Nov 2002 11:58:10 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: GSE Date: Fri, 1 Nov 2002 11:58:09 -0800 Message-ID: Thread-Topic: GSE Thread-Index: AcKB3+1iBaepAaaKRW2GJOm15RumbAAAOo9A From: "Tony Li" To: "Greg Maxwell" Cc: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA01154 | In any case, the cost and instability caused by having | routes is carried | only by those creating the routes. Umm.... this isn't ever true, for any proposal that I've ever seen. The cost and instability is borne by those that carry the routes. Tony From owner-multi6@ops.ietf.org Fri Nov 1 15:00:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01243 for ; Fri, 1 Nov 2002 15:00:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187hzw-000PdT-00 for multi6-data@psg.com; Fri, 01 Nov 2002 12:02:28 -0800 Received: from mochila.martin.fl.us ([198.136.32.118]) by psg.com with esmtp (Exim 3.36 #2) id 187hzu-000PYS-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 12:02:26 -0800 Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id PAA29480; Fri, 1 Nov 2002 15:02:03 -0500 (EST) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id PAA21488; Fri, 1 Nov 2002 15:01:54 -0500 (EST) Date: Fri, 1 Nov 2002 15:01:54 -0500 (EST) From: Greg Maxwell To: Tony Li cc: Iljitsch van Beijnum , Subject: RE: GSE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 1 Nov 2002, Tony Li wrote: > | In any case, the cost and instability caused by having > | routes is carried > | only by those creating the routes. > > > Umm.... this isn't ever true, for any proposal that > I've ever seen. The cost and instability is borne by > those that carry the routes. I'm saying it's okay to be promiscious in carring routes within an IGP because the cost of that excess route carrying stays with the operators of that network and doesn't impact the entire world. From owner-multi6@ops.ietf.org Fri Nov 1 16:19:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04650 for ; Fri, 1 Nov 2002 16:19:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187jDH-0006F7-00 for multi6-data@psg.com; Fri, 01 Nov 2002 13:20:19 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 187jD6-000655-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 13:20:08 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 369863443E; Fri, 1 Nov 2002 13:28:39 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gA1LJbiI000467; Fri, 1 Nov 2002 13:19:37 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: GSE Date: Fri, 1 Nov 2002 13:19:36 -0800 Message-ID: Thread-Topic: GSE Thread-Index: AcKB4aEwZB6qTSrqTui5/0PgxDWpbQACqx9A From: "Tony Li" To: "Greg Maxwell" Cc: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA04650 | I'm saying it's okay to be promiscious in carring routes | within an IGP | because the cost of that excess route carrying stays with | the operators of | that network and doesn't impact the entire world. Ah, my bad. Yes, I certainly agree with anything that stays in the IGP. Tony From owner-multi6@ops.ietf.org Fri Nov 1 16:25:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04983 for ; Fri, 1 Nov 2002 16:25:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187jJg-0006lW-00 for multi6-data@psg.com; Fri, 01 Nov 2002 13:26:56 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 187jJe-0006kN-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 13:26:54 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA1LQSs44883; Fri, 1 Nov 2002 22:26:28 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 1 Nov 2002 22:26:28 +0100 (CET) From: Iljitsch van Beijnum To: Tony Li cc: Subject: RE: GSE In-Reply-To: Message-ID: <20021101220914.T43861-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 1 Nov 2002, Tony Li wrote: > | - GSE doesn't provide any failover mechanisms but depends > | on tunnels to > | repair dead customer<->ISP links. This could be done just > | as easily > | with regular PA space. > Each host needs to advertise its locator to correspondent hosts. Whether > this happens via DNS or via a mobile IP type solution is more detailed > than we need to be right now, but basically, the correspondent can > get multiple locators for any MH host. Failover in this case is simply > changing the locator in the packet and does not require tunneling. Yes, switching to a different locator is what we want to do when a failure occurs. However, the GSE draft doesn't. Determining when to change locators isn't an altogether trivial exercise. This is where we can use the help from TCP, since it knows about timeouts and retransmissions, the IP layer has no idea about any of this stuff. > | - The flat part of the identifier space makes locator > | discovery hard. > Identifiers need not be flat. They could be hierarchically assigned > administrative entities. EUI-64 identifiers don't have a hierarchy that is of use to us. Using anything else means autoconfiguration has to be changed. None of this is impossible, but what exactly is it about the 6+2+8 thing that makes it worth going through all this trouble? If you simply assign people a PI /48 you can use this address block as identifiers and replace the first six bytes to make locators. The only "problem" with this is that you have to replace the first six bytes in the address with the original ones at some point, but it's much easier to make that happen than having transport protocols only look at the bottom 64 bits. If only because some box at the edge can do this. From owner-multi6@ops.ietf.org Fri Nov 1 17:36:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07157 for ; Fri, 1 Nov 2002 17:36:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187kQv-000CwH-00 for multi6-data@psg.com; Fri, 01 Nov 2002 14:38:29 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 187kQt-000Cvb-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 14:38:27 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 254833443F; Fri, 1 Nov 2002 14:46:57 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gA1MbuiI005761; Fri, 1 Nov 2002 14:37:56 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Fri, 1 Nov 2002 14:37:56 -0800 Message-ID: Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcKB0bCkl0HMJ3udT+i7feFsDiW8MAAJBn1g From: "Tony Li" To: , "Randy Bush" Cc: X-Spam-Status: No, hits=0.7 required=5.0 tests=SPAM_PHRASE_05_08 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA07157 Tony, | > Instead, I want to help all parties by growing the net in a | > reasonable and scalable way. That should be what we're all | > trying to do here. | | I believe it is, I was just asking if we have the appropriate | representation to make a balanced choice when the hard | trade-offs start being made. I appreciate that you're trying to do this as fairly as possible, but technical decisions should not be made by a democratic process. Yes, we all need to understand the issues that our users will face, but for those users to in turn understand the details of inter-domain routing is asking a bit much, don't you think? | > Operational issues instead | > favor a haphazard, need driven, cost optimized topology. | > Yes, ok it's chaotic, but it's the result of capitalism | at its finest. | | It is the 'cost optimized' part that makes the difference. | Which pockets | are we talking about protecting? I am not saying we should favor any | particular pocket, just asking if we are doing it | unintentionally by the | representatives around the table. Ultimately, it is always going to come down to the end user. The ISP, as a business, is always going to pass costs along to the end user. If we raise ISP link costs to minimize renumbering costs, the end user will pay for those links. If we minimize link costs and force people to renumber, then the end user pays directly and in proportion to their address space utilization. Note that under the 16+16 proposal, you get the situation where renumbering is cheap and easy AND the link costs are minimized. | > Provider independence isn't necessarily helped only by PI | > space. There are other ways. The real point is to avoid the | > pain and anguish of renumbering. | | That is one reason; simply being in control of your own destiny is | another. Specifically what are you referring to? I am not in control of my phone number. If the area code splits, mine changes without my control. The freeways that I drive on go where some traffic engineer says that they should go, not where I want. The end user is going to have a prefix that reflects their topology, even in the single homed case. If we can do the renumbering only at the border and reduce renumbering costs that way, does the end user still care what his prefix is? | This argument is continually shot at using the multi-prefix | model as not | workable because there are too many static tables inside enterprises | that 'need' to carry the real address for access control. I am not | arguing it is valid or correct, just that the viewpoint exists. I'm glad that you're not agreeing. I'd argue that if you wanted to do access control, you care about the identifier, not the locator. | > You are also assuming that aggregation and multihoming | are somehow | > at odds. They are not. All you have to do is to disconnect | > the locator and the identifier as GSE does and aggregate only the | > locators. Each host in a multihomed domain has a single | > identifier, but multiple locators. No deaggregation happens | > because the locators are bound to the provider and thus we | > have good topological 'addressing'. The enterprise doesn't | > lose because we tweak the transport to base the pseudoheader | > on the host identifier and then let the locator be free to be | > replaced by border routers. Connections flip back and forth | > between locators easily. | | This model was probably possible 4 years ago, but at this | point I doubt | tweaking the pseudoheader can even be on the table. Why? | Also, 'freely | replaced' usually sets off the alarm bells of the spoof-sensitive | security types. If that was the entire address, I would agree. However, as long as the identifier is stable, I don't see their point. Tony From owner-multi6@ops.ietf.org Fri Nov 1 17:39:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07191 for ; Fri, 1 Nov 2002 17:39:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187kTE-000D8y-00 for multi6-data@psg.com; Fri, 01 Nov 2002 14:40:52 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #2) id 187kTC-000D8l-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 14:40:50 -0800 content-class: urn:content-classes:message Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Nov 2002 14:40:54 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3F2@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcKB1/2h5cTcnA5JQACC2FFxZFsZ8QAHbv+Q From: "Michel Py" To: , "Iljitsch van Beijnum" , "Craig A. Huegen" Cc: X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA07191 Tony, > Tony Hain wrote: > You raise a point here that I think gets lost in the > mapping proposals. 'As far as your own hosts, the DNS > and remote hosts are concerned, hosts in your network > have a single address.' If the upper 48 bits are constant > in DNS, but continually changing in the routing system, > there needs to be a way to pass the possible set of > topologically appropriate replacement values between the > CPE routers. Since this protocol would inherently have to > be run between organizations that have no trust > relationship, how that be deployable? If it were run > between the PE routers, trust is managable to a point, > but what would prevent something like the POTS practice > of slamming? I'm not sure I understand your question correctly. Slamming as I understand it is make the customer switch to another (yours!) long distance company in order to get the money. We are talking about multihomed sites here, so a provider that wants to slam would either: a) Try to reduce the traffic on their customer's link by providing routes that have crappy metrics (if the customers pays a flat fee). b) Try to increase the traffic on their customer's link by providing routes that have very good metrics, which will eventually push the customer towards a bigger, more expensive pipe. Both of these are practiced today with IPv4. I'm not saying it's a good practice, and one better have a good explanation if caught, but it does happen. Are we looking at a solution that *also* solves this problem? Michel. From owner-multi6@ops.ietf.org Fri Nov 1 18:08:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07950 for ; Fri, 1 Nov 2002 18:08:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187kwG-000Fv3-00 for multi6-data@psg.com; Fri, 01 Nov 2002 15:10:52 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #2) id 187kwE-000Fuh-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 15:10:50 -0800 content-class: urn:content-classes:message Subject: RE: The state of IPv6 multihoming development MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Nov 2002 15:10:56 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3F3@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: The state of IPv6 multihoming development Thread-Index: AcKBsSU04be1oC2GSzW86imhSXgQRQAIDJhwAAo5p2A= From: "Michel Py" To: "Tony Li" Cc: X-Spam-Status: No, hits=-0.7 required=5.0 tests=SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA07950 > Tony Li wrote: > The competition will drive down cost. And those folks > who find net access to be a requirement for their daily > lives, such as telecommuters, may well decide to MH. > We see this already with certain netgeeks today. I could not agree more. Although I get very good DSL service, I would spend another $30 or $40 a month if there was a solution. > Also, small businesses are also candidates for MH. I have installed several small businesses that now process their credit card transactions over the web. What we do for these is typically a cable or dsl to backup the T1, egress only; it's only a matter of time before these guys need a real multihoming solution too. > Make sense? To me, completely. Michel. From owner-multi6@ops.ietf.org Fri Nov 1 18:42:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08819 for ; Fri, 1 Nov 2002 18:42:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187lRn-000Ipu-00 for multi6-data@psg.com; Fri, 01 Nov 2002 15:43:27 -0800 Received: from mh2dmz1.bloomberg.com ([199.172.169.37]) by psg.com with esmtp (Exim 3.36 #2) id 187lRk-000Ipi-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 15:43:24 -0800 Received: from ns2.bloomberg.com by mh2dmz1.bloomberg.com with ESMTP for multi6@ops.ietf.org; Fri, 1 Nov 2002 18:43:10 -0500 Received: from ny11012205a (aisaac-pc1 [160.43.2.152]) by ns2.bloomberg.com (8.9.3/8.9.3) with SMTP id SAA20588 for ; Fri, 1 Nov 2002 18:43:10 -0500 (EST) From: "Aldrin Isaac" To: Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Fri, 1 Nov 2002 18:44:07 -0500 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) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Status: No, hits=-3.7 required=5.0 tests=GAPPY_TEXT,IN_REP_TO,SPAM_PHRASE_01_02,USER_AGENT_OUTLOOK version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit hi all, i've been following this thread for several days, and i have some comments (part 1) as well as an approach (part 2) towards resolving some operational issues with multi-homed hosts. i hope i can provide a different perspective by offering some representation from the non-isp, non-vendor community. part 1: with regards to transport session continuity, a long term goal in the form of SCTP or a similar more secure transport protocols seems neccessary. but for now, people will work-in application level recovery if they really need it. that's what the smart ones do now, especially since even current ipv4 multi-homing practices don't guarantee protection from all failure modes. if a developer has to write an application that is misson-critical, s/he's definitely going to have to figure out how to make it recover if an interface, network, system or datacenter fails. people who provide mission critical applications are willing to pay a price to make sure their applications recover regardless of failure mode (either by operational procedures or automatically). for applications that absolutely cannot accept discontinuity for established layer-7 try this: connect using SSL transport, create and pass a temporary layer-7 session identifier with an "in-active lifetime" (say one minute),.. and if your SSL transport session gets disconnected, both ends maintain state for that layer-7 session for one minute, re-establish a new SSL transport connection within one minute, send your layer-7 session key and resume layer-7 session. or wait for SCTP or a better-than-SCTP protocol. or face the fact that there are no layer-3 guarantees today so don't expect them tomorrow. (this is a half baked) i believe that, if the v6 TCP stack would provide enhanced options to allow a developer to ask the stack to "from the list of addresses for a name try an address then skip to the next address if there is a failure to connect after 3 attempts spaced at 10 second intervals or if a destination unreachable is received, etc and repeat till end of list" it may make it easier on developers to deal with multiple addresses. i.e. a configurable auto-select and connect call. something like this would allow those who are familiar with how the net works to provide a foundation for others to stand on. providing a standard interface across platforms would be a bonus. functionality like this available "by default" in every system may be sufficient to satisfy those 11,000 sites that announce their prefixes into the IPv4 DFZ such that they instead announce multiple addresses per host to the DNS. I'm much more concerned about the operations aspect of multi-homed hosts. As has been pointed out before, the current multi-homing makes the life of ISPs much easier, but it makes the life of certain other organizations no easier. in the end the internet may have to carry less routes than a very large organization. the state of the internet routing table is critical to those who have wares to sell to the general public (like connectivity, merchandise, nude pictures, etc), but the internet protocol is also heavily used by those who interconnect privately as well. i.e. operations is critical to all - not just ISPs. part 2: - another quarter baked idea in order to simplify the operations of routing multi-homed hosts, i have been thinking about an approach that may satisfy the operations needs of some of us. this approach is geared for enterprises. this approach: (1) eliminates requiring having to support multi-interface hosts as a means of site-exit backup (2) eliminates the advertisement of prefixes (3) reduces the number of routes to manage inside the site (4) avoids having to do source-based forwarding to the appropriate site exit in order to avoid having ISPs drop packets where the source address prefix doesn't belong to them. (5) simplifies the life of private network providers by eliminating the requirement that you must provide transit to the DFZ to get a global-prefix. (6) ?? [obviously most of the above imply one another.] it appears that this appoach will not reduce the security or resilience of connections that we can have today. the short version of the approach is as follows: assume that a site: (1) uses site-border and internal routers that are capable of intra-site routing using only the SLA portion of the IPv6 destination address. this obviously means a max of 2^16 subnets per site. assume hosts in that site: (2) have one site-local address for outgoing connections: (3) host performs a "forward site-exit-discovery" for site-external destinations. the forward site-exit-discovery response would return <1> a prefix that matches the site-external destination address <2> AND a global-prefix (source-prefix) associated to that site-exit + next-hop ISP <3> AND a reachable anycast or unicast site-local address of that site-exit (site-border) router. NOTE: the site-exit router could also be configured to <1> return a "::/0" destination-prefix along with the global-prefix and site-exit address, i.e. a "default route" associated to the global-prefix <2> or if the router is running an EGP, the destination-prefix could be the longest match prefix for the destination address <3> or if multiple site-exit routers peer using IBGP, than the site-exit router can additionally return the site-exit address and the global-prefix of the best site-exit (this may require some new MBGP knobs). (4) the host would insert this source-prefix, destination-prefix and site-exit address in a special "site-external" routing table. these route entries are special route entries used to allow the host to select the appropriate global source-prefix to communicate with a site-external address and to source-route via the appropriate site-exit. site-exit discovery would be repeated if any destination associated to that source-destination-prefix pair becomes unreachable. (5) for the initial packet sent to a site-external destination, use the source-prefix associated to the best matching site-external destination route entry. packets sent to the site-external destination would include a routing header where the associated site-exit address would be the first destination of the packets. all connections that are "in-progress" would be routed based on site-external route entries that match both source and destination prefixes, i.e. only the initial localhost-originated packet can route purely by best matching destination-prefix. the host could probably create a temporary pseudo-interface with that source-prefix for the duration of all connections that use it. for incoming connections: (6) accept any prefix so long as the SLA and interface portion belong to the host. the host could also create a temporary psuedo-interface to handle the connection. (7) perform a "reverse site-exit-discovery" against the incoming global-prefix (i.e. destination address field of incoming packet) to discover what the ingress site-exit of the incoming packet was. the site-exit-router would return the same results as in (4) but without any IBGP optimizations. (8) traffic sent to site-external address would work as in (5) additionally: (9) the site-exit-discovery and "site-external" routing table approach can be used for both temporary global "pseudo-interfaces" described above as well as standard global interfaces that are configured today using router-advertisements. this approach OBVIOUSLY implies that the site-border (site-exit) routers are TRUSTED and only attract traffic with global-prefixes that have been assigned to the site. most enterprises fit this mold. i'm sure this approach is chock-full-of-holes since it's a half-baked idea. but i figure it may give a fresh perspective to some of the problems. -- aldrin p.s. sorry about the run-on sentences. % -----Original Message----- % From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On % Behalf Of Craig A. Huegen % Sent: Friday, November 01, 2002 12:04 PM % To: J. Noel Chiappa % Cc: multi6@ops.ietf.org % Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming % development] % % % On Fri, 1 Nov 2002, J. Noel Chiappa wrote: % % > > operational issues in the edge enterprise space favor provider % > > independence for maximum flexibility. % > % > No doubt operational issues in the edge enterprise space would favor % > perpetual motion machines - if they existed. % % As would operational issues in the ISP space. Can we please quit the % bickering? % % The point that Tony H. is trying to make (I think, correct me if I'm % wrong here) is that the multi-PA solution makes life very easy for ISP's % while throwing all of the operational issues of supporting such a solution % on the end-sites. % % As an operator of an enterprise network with tens of thousands of % segments, I fully agree with that statement. Many other enterprises I've % spoken to also concur with that statement, and are holding back on IPv6 % deployment for that reason. % % With that said, let's find some solutions. I also agree with the idea of % separating router goop from identities; however, I also am a pragmatist % and am concerned with the existing applications that would break with % this. % % /cah % % --- % Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s % IT Transport, Network Technology & Design || || % Cisco Systems, Inc., 400 East Tasman Drive || || % San Jose, CA 95134, (408) 526-8104 |||| |||| % email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. % % % From owner-multi6@ops.ietf.org Fri Nov 1 18:59:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09423 for ; Fri, 1 Nov 2002 18:59:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187liu-000Kfr-00 for multi6-data@psg.com; Fri, 01 Nov 2002 16:01:08 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 187lir-000Kfd-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 16:01:05 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Nov 2002 16:01:09 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , "'Randy Bush'" Cc: Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Fri, 1 Nov 2002 16:00:57 -0800 Message-ID: <025c01c28202$eb9018f0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-4.8 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA09423 Tony Li wrote: > Tony, > > | > Instead, I want to help all parties by growing the net in a > | > reasonable and scalable way. That should be what we're all > | > trying to do here. > | > | I believe it is, I was just asking if we have the appropriate > | representation to make a balanced choice when the hard > | trade-offs start being made. > > > I appreciate that you're trying to do this as fairly as > possible, but technical decisions should not be made by a democratic > process. The IETF consensus process != democratic, and rarely comes close. The point was more to make sure there is someone that can give a first-hand defense of the requirements so they are not easily dismissed by those with other priorities. > Yes, we all need to understand the issues that our > users will face, but for those users to in turn understand > the details of inter-domain routing is asking a bit much, > don't you think? I don't expect them to understand inter-domain routing details any more than I expect inter-domain routing experts to understand the business & policy decisions that result in the unrealistic topologies. > > > | > Operational issues instead > | > favor a haphazard, need driven, cost optimized topology. > | > Yes, ok it's chaotic, but it's the result of capitalism > | at its finest. > | > | It is the 'cost optimized' part that makes the difference. > | Which pockets > | are we talking about protecting? I am not saying we > should favor any > | particular pocket, just asking if we are doing it > | unintentionally by the > | representatives around the table. > > > Ultimately, it is always going to come down to the end user. > The ISP, as a business, is always going to pass costs along to the > end user. If we raise ISP link costs to minimize renumbering > costs, the end user will pay for those links. If we minimize > link costs and force people to renumber, then the end user > pays directly and in proportion to their address space utilization. There are additional costs to the renumbering plans like, increased difficulty in diagnosing problem reports, increased effort for applications to deal with dynamic locators, churn in name resolution, or the edge mapping systems that restore the dns values, etc ... > > Note that under the 16+16 proposal, you get the situation > where renumbering is cheap and easy AND the link costs are minimized. Just keep in mind we are squeezing on a balloon here, and if one aspect is minimized, another has just been expanded, and frequently disproportionately so. A group that is intensely focused on inter-domain routing is unlikely to appreciate the ramifications on the application development community, or those who have to operate at layer 8 or 9. Yes, we are here to focus on layer 3 scaling, but we can't loose sight of the wider impact. > > > | > Provider independence isn't necessarily helped only by PI > | > space. There are other ways. The real point is to avoid the > | > pain and anguish of renumbering. > | > | That is one reason; simply being in control of your own destiny is > | another. > > > Specifically what are you referring to? I am not in control of > my phone number. If the area code splits, mine changes without > my control. You are if you subscribe to a vanity 800 number; and since those are portable the system appears to flat route underneath you. > The freeways that I drive on go where some traffic > engineer says that they should go, not where I want. If the traffic engineer has done his job though, they go where the majority of your neighbors have shown they want to go. If not, congestion will persist alongside an empty freeway. > The end > user is going to have a prefix that reflects their topology, > even in the single homed case. If we can do the renumbering > only at the border and reduce renumbering costs that way, does > the end user still care what his prefix is? That question deserves a firsthand answer from a current enterprise network manager. > > > | This argument is continually shot at using the multi-prefix > | model as not > | workable because there are too many static tables inside > enterprises > | that 'need' to carry the real address for access control. I am not > | arguing it is valid or correct, just that the viewpoint exists. > > > I'm glad that you're not agreeing. I'd argue that if you wanted > to do access control, you care about the identifier, not the locator. But since there is no way to ensure that an identifier is globally unique, the only way to accomplish the goal is to couple them to describe 'this identifier at this location'. If the location is not stable, the static description is not stable. > > > | > You are also assuming that aggregation and multihoming > | are somehow > | > at odds. They are not. All you have to do is to disconnect > | > the locator and the identifier as GSE does and > aggregate only the > | > locators. Each host in a multihomed domain has a single > | > identifier, but multiple locators. No deaggregation happens > | > because the locators are bound to the provider and thus we > | > have good topological 'addressing'. The enterprise doesn't > | > lose because we tweak the transport to base the pseudoheader > | > on the host identifier and then let the locator be free to be > | > replaced by border routers. Connections flip back and forth > | > between locators easily. > | > | This model was probably possible 4 years ago, but at this > | point I doubt > | tweaking the pseudoheader can even be on the table. > > > Why? Shipped code is hard to change. For something as significant as this, it takes two years from the point of agreement to get new code shipped, then it takes an additional 3-7 years to get the prior code retired. We will need a multi-homing solution well before that, so we need to find something that is incremental. > > > | Also, 'freely > | replaced' usually sets off the alarm bells of the spoof-sensitive > | security types. > > > If that was the entire address, I would agree. However, as long as > the identifier is stable, I don't see their point. Because the identifier is not stable & globally unique, and even if we had a way to ensure that, the privacy advocate's alarms would be going off. Despite the desire to avoid it, the current reality is that to create a globally unique identifier we bound the problem by coupling it with its locator. Tony > > Tony > From owner-multi6@ops.ietf.org Fri Nov 1 19:08:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09852 for ; Fri, 1 Nov 2002 19:08:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187lrg-000LS6-00 for multi6-data@psg.com; Fri, 01 Nov 2002 16:10:12 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 187lre-000LRn-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 16:10:10 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 01 Nov 2002 16:10:18 -0800 Reply-To: From: "Tony Hain" To: "'Michel Py'" , "'Iljitsch van Beijnum'" , "'Craig A. Huegen'" Cc: Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Fri, 1 Nov 2002 16:10:06 -0800 Message-ID: <025d01c28204$3344eb70$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <2B81403386729140A3A899A8B39B046405E3F2@server2000> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-4.3 required=5.0 tests=INVALID_MSGID,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA09852 Michel Py wrote: > ... > I'm not sure I understand your question correctly. Slamming > as I understand it is make the customer switch to another > (yours!) long distance company in order to get the money. > > We are talking about multihomed sites here, so a provider > that wants to slam would either: > > a) Try to reduce the traffic on their customer's link by > providing routes that have crappy metrics (if the customers > pays a flat fee). > > b) Try to increase the traffic on their customer's link by > providing routes that have very good metrics, which will > eventually push the customer towards a bigger, more expensive pipe. > > Both of these are practiced today with IPv4. I'm not saying > it's a good practice, and one better have a good explanation > if caught, but it does happen. Are we looking at a solution > that *also* solves this problem? I don't expect to solve it, but if we are talking about a system to distribute mapping tables to align with current topology at the ingress and restore the original values at the egress, we should make sure the process does not make it easy to quietly influence which provider carries the traffic. The obvious method to prevent this would be for the site being mapped to sign its preferences, but that brings along its own operational and scaling issues. Tony From owner-multi6@ops.ietf.org Fri Nov 1 20:47:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12046 for ; Fri, 1 Nov 2002 20:47:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187nOB-0004La-00 for multi6-data@psg.com; Fri, 01 Nov 2002 17:47:51 -0800 Received: from pa-monroeville1b-61.pit.adelphia.net ([24.53.182.61] helo=localhost) by psg.com with esmtp (Exim 3.36 #2) id 187nO9-0004KX-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 17:47:49 -0800 Received: from [192.168.1.100] (localhost [127.0.0.1]) by localhost (8.12.2/8.12.2) with ESMTP id gA21lL2O010165; Fri, 1 Nov 2002 20:47:22 -0500 (EST) Date: Fri, 01 Nov 2002 20:47:20 -0500 From: "Michael H. Lambert" To: Aldrin Isaac cc: multi6@ops.ietf.org Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Message-ID: <43291318.1036183640@[192.168.1.100]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Friday, 1 November 2002 18:44 -0500 Aldrin Isaac wrote: [...] > assume hosts in that site: > > (2) have one site-local address [...] That should be one site-local address per interface... Which leads to the observation that, although this WG is chartered with tackling the problem of SITE multihoming, a site MH solution which is also applicable to the enterprise interior is probably better than one which doesn't. Michael +-----------------------------------------------------------------------+ | Michael H. Lambert, Network Engineer Phone: +1 412 268-4960 | | Pittsburgh Supercomputing Center FAX: +1 412 268-8200 | | 4400 Fifth Avenue, Pittsburgh, PA 15213 lambert@psc.edu | +-----------------------------------------------------------------------+ From owner-multi6@ops.ietf.org Fri Nov 1 21:33:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13507 for ; Fri, 1 Nov 2002 21:33:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187o89-0008xu-00 for multi6-data@psg.com; Fri, 01 Nov 2002 18:35:21 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 187o86-0008xZ-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 18:35:19 -0800 From: Masataka Ohta Message-Id: <200211020143.KAA02605@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA02605; Sat, 2 Nov 2002 10:43:27 +0900 Subject: Re: GSE In-Reply-To: <20021101180759.R43861-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Nov 1, 2002 06:13:39 pm" To: Iljitsch van Beijnum Date: Sat, 2 Nov 2002 10:43:26 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > > > That being said, I think GSE could be a subset of a more general > > > approach. > > > Wrong. Any approach containing GSE as a subset is worse than GSE. > > With a solution that can work with any kind of structure for the > identifier it would be easy to implement GSE for those who still want > it, Wrong. GSE is impossible to implement, not because of its structure for the identifier but because of its ignorance of the end to end principle. > without betting all our cards on one horse or a cliche of similar > sentiment. GSE was a dead horse from the beginning. It has been harmful for healthy horses. > > > However, using identifiers with regular IPv6 > > > unicast semantics will make the transition a lot easier as it allows > > > interoperability between multihoming-aware and non-multihoming aware > > > systems and/or providing the multihoming support in separate boxes. > > > Transition from what? IPv4? OSI? Or? > > Transition from existing v6. An interesting theory. Masataka Ohta From owner-multi6@ops.ietf.org Fri Nov 1 21:34:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13588 for ; Fri, 1 Nov 2002 21:34:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187o8A-0008xy-00 for multi6-data@psg.com; Fri, 01 Nov 2002 18:35:22 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 187o88-0008xZ-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 18:35:20 -0800 From: Masataka Ohta Message-Id: <200211020138.KAA02563@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA02563; Sat, 2 Nov 2002 10:38:12 +0900 Subject: 8+8 and locator based approaches In-Reply-To: from RJ Atkinson at "Nov 1, 2002 08:57:54 am" To: RJ Atkinson Date: Sat, 2 Nov 2002 10:38:11 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-4.9 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_05_08 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Ran; > I think that Iljitsch's note is a fine reminder that different folks > have very different understandings of what the term "GSE" means. GSE is defined clearly with no different understandings except for that you just invented. Thank you for your creativity. > For my part, I agree with tli, jnc, and others that the best > architectural > approach to supporting multi-homing while not hosing the operational > routers > in the DFZ is to separate host identity from routing goop. There are several such proposals found in big internet mailing list. Call them 8+8 or 6+2+8 but not GSE. Also, say "locator", not "routing goop". As for GSE, it appeared much later but is hopeless. GSE, for example, leaves dependency betwen identifier and locators. Masataka Ohta From owner-multi6@ops.ietf.org Fri Nov 1 22:02:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14539 for ; Fri, 1 Nov 2002 22:02:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187oZj-000B1i-00 for multi6-data@psg.com; Fri, 01 Nov 2002 19:03:51 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 187oZh-000B1H-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 19:03:49 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id WAA11691; Fri, 1 Nov 2002 22:03:47 -0500 Date: Fri, 1 Nov 2002 22:03:47 -0500 From: "J. Noel Chiappa" Message-Id: <200211020303.WAA11691@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: GSE Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: RJ Atkinson > I agree with tli, jnc, and others that the best architectural approach > to supporting multi-homing while not hosing the operational routers in > the DFZ is to separate host identity from routing goop. Ummm, I think you're somewhat overstating my enthusiasm for separation *as a solution to multi-homing issues*. Having said that, part of the problem with discussion of separate host identification from routing-names has always been that people always seem to look at the tradeoffs in the context of a single issue: one of the early rounds of discussion focussed on mobile processes, for example. I do remain completely convinced that we *do* need to separate host identification from routing-names, but my enthusiasm comes from a broad architectural perspective, not a particular case (such as multi-homing). When I look at multi-homing, as laid out in: http://ana-3.lcs.mit.edu/~jnc/tech/nsrg/multihoming_points.txt I see a very complex cross-product set of goals, and corresponding to that (and not laid out fully in that note) there are a large range of potential mechanisms. (There's also an axis in the problem-space which I forgot to mention, which is "is the 'base address' (a la MIPv6) still online, or is the rendezvous point unavailable.) For some goals, (e.g. multi-homing Google) it might indeed make sense to have the routing do it. For others (e.g. multi-homing a single machine) it's clear that the routing can't do it. Whether "one size will fit all", I really don't know. We might wind up with a couple of different mechanisms, each tuned to a separate part of the problem space. So, perhaps my comment about "overstating my enthusiasm for separation *as a solution to multi-homing issues*" now has a little more depth to it. Separation would indeed be a useful building block in some of the solutions, I think, but that's all it is - a useful building block in some solutions. Noel From owner-multi6@ops.ietf.org Fri Nov 1 23:27:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16379 for ; Fri, 1 Nov 2002 23:27:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187ptV-000Gb0-00 for multi6-data@psg.com; Fri, 01 Nov 2002 20:28:21 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #2) id 187ptT-000Gao-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 20:28:19 -0800 content-class: urn:content-classes:message Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Nov 2002 20:28:22 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3FC@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcKCBE9Vpp7ye4O0RVqzo4UJM3YfYQAIuGDg From: "Michel Py" To: , "Iljitsch van Beijnum" , "Craig A. Huegen" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA16379 Tony, > Tony Hain wrote: > I don't expect to solve it, but if we are talking about a > system to distribute mapping tables to align with current > topology at the ingress and restore the original values at > the egress, we should make sure the process does not make > it easy to quietly influence which provider carries the > traffic. The obvious method to prevent this would be for > the site being mapped to sign its preferences, but that > brings along its own operational and scaling issues. In other words, let's say that when the two CPE routers negotiate the best path and use, say, RTT, your concern is that the carrier might try to slam by traffic-shapping so RTT has high priority, thus making its own link more appealing to the decision process. And this would be a lot more difficult to detect than someone that prepends or manipulates the AS-PATH. Did I get this part right? Would you have these concerns if the choice among the multiple addresses was based on the AS-PATH instead of some glorified RTT thing? Michel. From owner-multi6@ops.ietf.org Fri Nov 1 23:34:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16549 for ; Fri, 1 Nov 2002 23:34:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187q1M-000HBw-00 for multi6-data@psg.com; Fri, 01 Nov 2002 20:36:28 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #2) id 187q1K-000HBj-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 20:36:26 -0800 content-class: urn:content-classes:message Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Nov 2002 20:36:33 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B046405E3FD@server2000> Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcKCAbVHlkFy1jEUSk6viSNakLaIcQAJsrKw From: "Michel Py" To: "Aldrin Isaac" , X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA16549 Aldrin, > Aldrin Isaac > or face the fact that there are no layer-3 guarantees > today so don't expect them tomorrow. (this is a half baked) This is not baked at all. There are some layer-3 only protocols currently designed that guarantee survivability of open sessions. Regarding your "part 2: - another quarter baked idea", this sounds interesting at the first read, is there a draft of this? Michel. From owner-multi6@ops.ietf.org Sat Nov 2 02:54:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29348 for ; Sat, 2 Nov 2002 02:54:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187t7s-0005nk-00 for multi6-data@psg.com; Fri, 01 Nov 2002 23:55:24 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 187t7q-0005iW-00 for multi6@ops.ietf.org; Fri, 01 Nov 2002 23:55:23 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 314E63443B; Sat, 2 Nov 2002 00:03:53 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gA27spiI007350; Fri, 1 Nov 2002 23:54:51 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: GSE Date: Fri, 1 Nov 2002 23:54:51 -0800 Message-ID: Thread-Topic: GSE Thread-Index: AcKCHVHHP/IIcZsITX2+Q9UoOX8RzQAJcdWQ From: "Tony Li" To: "J. Noel Chiappa" , X-Spam-Status: No, hits=0.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA29348 Noel, | For some goals, (e.g. multi-homing Google) it might indeed | make sense to have | the routing do it. For others (e.g. multi-homing a single | machine) it's clear | that the routing can't do it. Whether "one size will fit | all", I really don't | know. We might wind up with a couple of different | mechanisms, each tuned to a | separate part of the problem space. | | So, perhaps my comment about "overstating my enthusiasm for | separation *as a | solution to multi-homing issues*" now has a little more depth to it. | Separation would indeed be a useful building block in some | of the solutions, I | think, but that's all it is - a useful building block in | some solutions. I respect your position and I'm sure that Ran didn't mean to paint you into a corner that you wouldn't want to defend. I agree completely that separation of the locator is a good thing. In fact, I believe that we agreed to this long ago in San Diego. ;-) and I agree with your analysis that there may be many different mechanisms that we end up with the locator. It occurs to me that there are different mechanisms that we would want given differences in (a) the rate at which locators change, (b) the policy associated with the distribution of locators, and (c) the overhead to the organization. I have no problem with this. But I will go farther than you on one point: I believe that separating the locator is _absolutely necessary_ to a scalable, workable solution. I have no mathematical proof of this, but the combination of the constraints involved and the aesthetics make it compelling to me. Tony From owner-multi6@ops.ietf.org Sat Nov 2 03:10:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29497 for ; Sat, 2 Nov 2002 03:10:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187tOB-0007Bf-00 for multi6-data@psg.com; Sat, 02 Nov 2002 00:12:15 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 187tO9-00079S-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 00:12:13 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id EECBD3443B; Sat, 2 Nov 2002 00:20:44 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gA28BgiI008441; Sat, 2 Nov 2002 00:11:42 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: GSE Date: Sat, 2 Nov 2002 00:11:41 -0800 Message-ID: Thread-Topic: GSE Thread-Index: AcKB7WwabFVEYxcCSKiePl7ZPEyG5wAWPDhQ From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=0.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA29497 Iljitsch, | > Each host needs to advertise its locator to correspondent | hosts. Whether | > this happens via DNS or via a mobile IP type solution is | more detailed | > than we need to be right now, but basically, the correspondent can | > get multiple locators for any MH host. Failover in this | case is simply | > changing the locator in the packet and does not require tunneling. | | Yes, switching to a different locator is what we want to do when a | failure occurs. However, the GSE draft doesn't. Fine, as I said, I'm looking at what we would like to do, not just what GSE currently does. Again, please see previous mail on 16+16. | Determining when to change locators isn't an altogether trivial | exercise. This is where we can use the help from TCP, since it knows | about timeouts and retransmissions, the IP layer has no | idea about any | of this stuff. Yes, exactly. | > | - The flat part of the identifier space makes locator | > | discovery hard. | | > Identifiers need not be flat. They could be | hierarchically assigned | > administrative entities. | | EUI-64 identifiers don't have a hierarchy that is of use to | us. Using | anything else means autoconfiguration has to be changed. There are enough issues around EUI-64 that I thought it was good to get away from those anyway. In any case, I'm not convinced that there's a LOT of need to have an identifier to locator mapping. You need a hostname to identifier and locator mapping, but when would you go from identifier to locator without the hostname? In any case, if we were to really want this, yes, autoconfiguration would have to change. The identifier space could have hierarchy, but need not be tied to the topology. Further, it wouldn't need to aggregate except to make entry into DNS palatable. The autoconfiguration would assign an identifier upon recognizing the host based on the range of identifiers available to that particular subnet. | None of this is impossible, but what exactly is it about | the 6+2+8 thing | that makes it worth going through all this trouble? If you | simply assign | people a PI /48 you can use this address block as identifiers and | replace the first six bytes to make locators. The only | "problem" with | this is that you have to replace the first six bytes in the | address with | the original ones at some point, but it's much easier to make that | happen than having transport protocols only look at the | bottom 64 bits. | If only because some box at the edge can do this. Why is it hard to make the transport protocols only look at the bottom N bits? Ok, yes, you have to feed them into the checksum algorithm separately, but this is NOT rocket science. Tony From owner-multi6@ops.ietf.org Sat Nov 2 04:38:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00781 for ; Sat, 2 Nov 2002 04:38:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187ulF-000CoI-00 for multi6-data@psg.com; Sat, 02 Nov 2002 01:40:09 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 187ulC-000Co6-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 01:40:07 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA29deX48315; Sat, 2 Nov 2002 10:39:41 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 2 Nov 2002 10:39:40 +0100 (CET) From: Iljitsch van Beijnum To: Tony Li cc: Subject: RE: GSE In-Reply-To: Message-ID: <20021102102149.U43861-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 2 Nov 2002, Tony Li wrote: > | EUI-64 identifiers don't have a hierarchy that is of use to > | us. Using anything else means autoconfiguration has to be changed. > There are enough issues around EUI-64 that I thought it was > good to get away from those anyway. Good. That means we can reclaim a good number of those 64 bits. If we use 16 bits on the local subnet, 16 bits for subnetting, 48 bits for the routing goop or whatever it's called these days that leaves us with 48 bits for the organization identifier, which is enough to have a good hierarchy. Although I wouldn't know how to number ogranizations hierarchically... > In any case, I'm not convinced that there's a LOT of need to > have an identifier to locator mapping. You need a hostname to > identifier and locator mapping, but when would you go from > identifier to locator without the hostname? Good question. Obviously there will be many times you'd want to do this for debugging and so on, but that doesn't have to be very fast or 100% reliable. Sometimes it's useful to connect to an IP address directly, but if people really want this they can connect to three IP addresses as well so this also isn't a very strong case. Apart from that the only way you'd need this is for backward compatibility with existing code, I think. > autoconfiguration would assign an identifier upon recognizing the > host based on the range of identifiers available to that particular > subnet. If we kill EUI-64 we could do this right this time and base the host address for autoconfiguration on the hostname. > | this is that you have to replace the first six bytes in the > | address with the original ones at some point, but it's much > | easier to make that happen than having transport protocols only > | look at the bottom 64 bits. > | If only because some box at the edge can do this. > Why is it hard to make the transport protocols only look at the > bottom N bits? Ok, yes, you have to feed them into the > checksum algorithm separately, but this is NOT rocket science. The hard part isn't changing the stacks, but getting them out to everyone who has an existing v6 implementation. A comprimise would be to set the top 128 - n bits to 0 before calculating the checksum. Then a host with an existing IPv6 stack can interoperate to some degree with a modified one if a border router sets the top 6 bytes (or whatever value we arrive at) to 0. Obviously such a host would have to be configured with an address manually or maybe with DHCP if DHCP knows about subnet sizes. From owner-multi6@ops.ietf.org Sat Nov 2 04:41:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00821 for ; Sat, 2 Nov 2002 04:41:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187uoc-000Cyu-00 for multi6-data@psg.com; Sat, 02 Nov 2002 01:43:38 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 187uoZ-000Cxf-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 01:43:35 -0800 Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id B39591C for ; Sat, 2 Nov 2002 11:49:39 +0200 (EET) Message-ID: <3DC39E25.9080404@nomadiclab.com> Date: Sat, 02 Nov 2002 11:43:01 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Notes about identifier - locator separator Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.1 required=5.0 tests=DISCLAIMER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [During the last couple of days there have been quite a lot of comments, by various people, on the ideas of separating identifiers and locators (see the end of this message for some quotations). Based on our experience on Mobile IPv6, the late Homeless Mobile IPv6 suggestion, and our current work on Mobile IPv6 security and HIP, I'd like to present a few observations. Disclaimer: I am far from being a routing expert, so take your usual grain of salt.] I think that there are a number of dimensions that we have to keep in mind when discussing separating identifiers from locators. Furthermore, I think that it is important first to understand these issues and only once we really understand the dimensions to start take positions on specific solutions. Maybe this is no news to you, but writing this has certainly helped my own thinking :-) The immediate issues that I see are the following: 1. Architectural "structure" of the identifiers. 2. Where to perform identifier->locator and/or locator->locator translations. 3. Identifer -> locator resolution (+ reverse resolution for ops) 4. Backwards compatibility a) application level backwards compatibility b) routing level backwards compatibility 5. Security & Privacy issues 6. Issuing and uniqueness of identifiers There are most probably others, but I think these six might work as a starting point. 1. Architectural "structure" of the identifiers From my point of view, there are two different basic approaches: a) make the end-point identifiers a completely separate name space b) divide the IPv6 address space into locator and identifier space Due to the chartering of this working group, I think it is natural that people here tend to look at solutions from the b) category. However, I personally think that a completely separate name space might be better. Furthermore, if we create a completely new name space, that would leave the IP address space more or less intact, allowing routing technogy to be developed independently of end-host mobility and end-host multi-homing issues. (I do realise that network level mobility and multi-homing are different. They probably require changes on the routing level too, and end-point identifiers might just act as a helping tool.) 2. Translations Once the end-point identifiers have been separated from locators, we need to translate the identifiers to locators at some point, and it also becomes possible to translate between locators. That is, the apps will only know the identifiers, not locators. Thus, at some point, the identifiers must be translated into locators so that the packets can be routed to their destination. Here I see two basic solutions, again: a) perform the identifier -> locator translation at the end-host so that all packets leaving the end-host have a proper locator, b) allow the identifiers to leave the end-host without locators, and perform the translation within the the network, e.g., at a site border router. Independent of that, it will be possible to translate locators to locators within the network, as long as the end-points are able to determine the identifiers either implicitly (based on state), explicitly (based on information carried in the packet), or bt a combination of state & per-packet information. 3. Resolution Apparently there must also be some way of finding the locators based on the identifier or a name. Apparently there is a huge number of possible solutions to this. One of the most obvious ones is to store both identifiers and locators into the DNS, and make the name resolution library to fetch both. 4. Backwards compatibility The basic issue here is to keep the semantics of the fields in the application level data structures and the address fields in IPv6 header sufficiently intact. However, we must understand that the address semantics are different from the application point-of-view and from the routing point-of-view. a) application level backwards compatibility For application level compatibility, the identifiers must *look* like IP addresses. That is, the current name resolution fuctions (getaddrinfo) must return something that looks enough like an address, and the kernel must be able to understand these. However, if the identifier name space is separate from the locator space, and if the translation is performed at the end-host, these identifiers might never leave the end-host in the IP address fields. Thus, it is possible to *separate* application level and routing level backwards compatibility b) routing level backwards compatibility I'm fraid I can't say much intelligent here. You folks know this subject much better than I do. 5. Security and privacy I might as well write a separate message about this. (Would a draft be useful?) However, briefly: From the security point of view, there are two concerns: a) We want to make sure that the multi-homing mechanism cannot be used to "steal" addresses or connections. That is, the solution must make sure that the end-points talking to each other remain the same even if the underlying locators are changed. b) We want to make sure that the multi-homing mechanism cannot be used as a vehicle in DoS attacks. This is the "flooding" attack problem that I've described in other messages. From the privacy point of view, it would be a definite plus if the actual, long lasting identifiers would not be visible in packets. There are techniques how identifiers could be cryptographically masked in a way that still allows middle boxes (such as firewalls) and end-points to still recognize valid identifiers but make it hard for outsiders to track them. However, these naturally require that the identifiers are completely separated from locators, i.e., that they are not being used for routing. 6. Issuing and uniqueness of identifiers Here we once more seem to have two possibilities: a) The identifiers are issued hierarchically b) The identifiers are issued by a random number generator and are long enough so that the probability of collision is low enough. I know that there are doubts against b). However, if the identifiers are long enough, the chance of collision by change can be so low that it really can be ignored, since a collision would be likely to happen less often than there are atoms in our universe. (The quality of random number generators would still be an issue, though.) ---- Those are the dimensions as I see them. There are probably others. Apparently, my personal position is that I'd like to see that - identifiers are completely different from IP addresses, and IP addresses gradually become pure locators, - identifiers are translated into locators at the end-hosts, and the network performs locator-locator translations if needed e.g. for traffic engineering, - both identifiers and locators are stored in the DNS; additionally there might be dynamic locator->locator translation services to help mobility, - the application level and routing level compatibility issues are separated, - identifiers are cryptographic in nature so that it becomes easier to solve the security problems, - identifiers are usually not carried in the packets, just locators; this helps privacy and keeps the header size from growing, - it is *possible* to generate totally random identifiers; if some people want to use hierarchically assigned identifiers, I have nothing against it. ---- Some related quotations from the discussion in the last two days. Apologies to those occasions where I haven't got the attribution right. Tony Hain wrote: > I have not been opposed to GSE, but I think the time has passed for it > to be adopted without coupling it with something like MIPv6 to provide a > stable identifier to the psuedo-header calculation and multi-party apps > that insist on refering addresses rather than name strings. Craig A. Huegen wrote: > With that said, let's find some solutions. I also agree with the idea of > separating router goop from identities; however, I also am a pragmatist > and am concerned with the existing applications that would break with > this. Tony Li wrote: >> You are also assuming that aggregation and multihoming are somehow >> at odds. They are not. All you have to do is to disconnect >> the locator and the identifier as GSE does and aggregate only the >> locators. Each host in a multihomed domain has a single >> identifier, but multiple locators. No deaggregation happens >> because the locators are bound to the provider and thus we >> have good topological 'addressing'. The enterprise doesn't >> lose because we tweak the transport to base the pseudoheader >> on the host identifier and then let the locator be free to be >> replaced by border routers. Connections flip back and forth >> between locators easily. To which Tony Hain replied: > This model was probably possible 4 years ago, but at this point I doubt > tweaking the pseudoheader can even be on the table. Also, 'freely > replaced' usually sets off the alarm bells of the spoof-sensitive > security types. That does not mean we GSE is hopeless, just that we will > probably have to use something like MIPv6 to mask the label swapping. In > the abstract, there is not much difference between GSE and a Care-of > Address. So for routing & packet forwarding, if the CoA had finer > grained pattern replacement happening the end systems would not be aware > of it. The missing link would be letting the host know what the current > publicly visible address is so it could pass that to the CN. In a later message, Tony Hain wrote: > But since there is no way to ensure that an identifier is globally > unique, the only way to accomplish the goal is to couple them to > describe 'this identifier at this location'. If the location is not > stable, the static description is not stable. ... > Because the identifier is not stable & globally unique, and even if we > had a way to ensure that, the privacy advocate's alarms would be going > off. Despite the desire to avoid it, the current reality is that to > create a globally unique identifier we bound the problem by coupling it > with its locator. From owner-multi6@ops.ietf.org Sat Nov 2 06:22:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02250 for ; Sat, 2 Nov 2002 06:22:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187wNZ-000IYu-00 for multi6-data@psg.com; Sat, 02 Nov 2002 03:23:49 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 187wNW-000IYi-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 03:23:46 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 187wNW-000D50-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 03:23:46 -0800 Message-ID: <20021102084211.R43861-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sat, 2 Nov 2002 08:49:42 +0100 (CET) From: Iljitsch van Beijnum To: Subject: Get together in Atlanta X-Spam-Status: No, hits=-1.2 required=5.0 tests=RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, As of yesterday, there is nothing on the Atlanta agenda for multi6. Maybe it would be useful to discuss some of this stuff face to face. At the very least it would be nice to say hi and see which faces go with which opinions. What I'm thinking is getting together during the monday lunch break and take it from there, unless someone has a better suggestion. Please mail me privately if you're interested and I'll get back later with details such as a meeting place. This would also be an excellent opportunity to bring people who aren't on this list up to speed with what's happening here, so if you know someone who might be interested, bring them. Iljitsch From owner-multi6@ops.ietf.org Sat Nov 2 07:15:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03157 for ; Sat, 2 Nov 2002 07:15:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187xDH-000LKo-00 for multi6-data@psg.com; Sat, 02 Nov 2002 04:17:15 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 187xDA-000LFh-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 04:17:08 -0800 Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 3986667103; Sat, 2 Nov 2002 03:36:34 -0500 (EST) Date: Sat, 2 Nov 2002 07:16:34 -0500 Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: Randy Bush From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-0.1 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Nov 1, 2002, at 10:06 America/Montreal, Randy Bush wrote: > information reduction has been is the only tool the isps have to > deal with routing bloat and weak vendor hardware. if you would > care to suggest others, i am all ears. Agree, and some few of us suspect there might be a convergence time wall not very far in front of us in IPv4-land, that is not due to "weak vendor hardware", but instead due to inherent issues in the current Path Vector algorithms behind BGP. This kind of suspicion is part of why the IRTF RRG is examining the broader topic of IP routing -- though that level of research is outside the charter for this list.... Ran From owner-multi6@ops.ietf.org Sat Nov 2 07:27:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03341 for ; Sat, 2 Nov 2002 07:27:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187xPE-000M1L-00 for multi6-data@psg.com; Sat, 02 Nov 2002 04:29:36 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 187xOn-000Lw6-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 04:29:09 -0800 Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 1DC2A67103; Sat, 2 Nov 2002 03:48:38 -0500 (EST) Date: Sat, 2 Nov 2002 07:28:38 -0500 Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: From: RJ Atkinson In-Reply-To: <023001c281d1$aafb7770$237ba8c0@eagleswings> Message-Id: <9D445F66-EE5E-11D6-9F10-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-Spam-Status: No, hits=-0.1 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Nov 1, 2002, at 13:08 America/Montreal, Tony Hain wrote: > It is the 'cost optimized' part that makes the difference. Which > pockets > are we talking about protecting? I am not saying we should favor any > particular pocket, just asking if we are doing it unintentionally by > the > representatives around the table. All the pockets. Trying to shift costs onto ISPs just means they are forced to raise rates and shift them back to customers. Terribly sorry, but that's how the economics work in this case. And the part I strongly dislike is that those raised rates propogate much more widely than the subset of sites that cause the ISP costs -- and harm the general growth and health of the global Internet. > This model was probably possible 4 years ago, but at this point I doubt > tweaking the pseudoheader can even be on the table. If router vendors had a knob that enabled separation of location/identity and the IDR infrastructure was compatible with that, I bet a whole lot of enterprise users would enable that knob eagerly in order to obtain multi-homing and backup and other things they desire. It might be interesting to run that experiment, though obviously the implementation specifics would need to be worked out first. > Also, 'freely > replaced' usually sets off the alarm bells of the spoof-sensitive > security types. I've been accused of Internet paranoia in the past. Please note that I disagree with the assertion that such paranoia is reasonable in the case of separating location from identity. Unreasonable paranoia exists no matter what one does, so ought not be a variable in the decision process. > That does not mean we GSE is hopeless, just that we will > probably have to use something like MIPv6 to mask the label swapping. > In the abstract, there is not much difference between GSE and a Care-of > Address. So for routing & packet forwarding, if the CoA had finer > grained pattern replacement happening the end systems would not be > aware > of it. The missing link would be letting the host know what the current > publicly visible address is so it could pass that to the CN. I'm happy to discuss whichever implementation details. I just think that from an architectural perspective, we need to separate location and identity to make any significant headway here. Ran From owner-multi6@ops.ietf.org Sat Nov 2 08:33:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04718 for ; Sat, 2 Nov 2002 08:33:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187yQk-000PbK-00 for multi6-data@psg.com; Sat, 02 Nov 2002 05:35:14 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 187yQi-000Pas-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 05:35:12 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA2DYfa48521; Sat, 2 Nov 2002 14:34:42 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 2 Nov 2002 14:34:41 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Nikander cc: Subject: Re: Notes about identifier - locator separator In-Reply-To: <3DC39E25.9080404@nomadiclab.com> Message-ID: <20021102135406.Q43861-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 2 Nov 2002, Pekka Nikander wrote: > 1. Architectural "structure" of the identifiers > From my point of view, there are two different basic > approaches: > a) make the end-point identifiers a completely > separate name space > b) divide the IPv6 address space into locator > and identifier space > Due to the chartering of this working group, I think it is > natural that people here tend to look at solutions from the > b) category. However, I personally think that a completely > separate name space might be better. Furthermore, if we > create a completely new name space, that would leave > the IP address space more or less intact, allowing routing > technogy to be developed independently of end-host mobility > and end-host multi-homing issues. As it seems to be open season on all aspects of the TCP/IP architecture, let's follow this reasoning to its logical conclusion and make the identifier the full host name. Let's go with this for a moment. Now obviously IP will be unable to route based on hostnames, so the whole thing must be done at the transport layer. Retrofitting TCP is probably not worth it, so we make a new transport protocol. As I've said before, doing multihoming at the transport layer has many drawbacks compatibility-wise, but if we're going to do some major architectural work, we may as well go the full nine yards and solve everything once and for all. Since the identifiers aren't carried in IP and we need extra locators, there must be some serious session establishment. Doing this in UDP defeats the purpose. So apps that use straight UDP must either live with the fact that they are not multihomed (which may be ok for something like syslog) or implement their own multihoming mechanisms (such as the DNS already does). However, many applications don't use UDP as-is but use a UDP-based real-time transport protocol. As long as we're building a new transport protocol, we may as well address this need too and implement an unreliable and possibly as semi-reliable (for multicast?) mode in addition to the regular TCP-like reliable mode. A nice addition would be having a better checksum for the new protocol. If we replace the TCP checksum by an MD5 hash or part thereof that is calculated over the packet contents, assorted transport layer fields such as the sequence number, the identifier and some kind of magic cookie, it becomes pretty hard for someone to steal a session without having seen the intial identifier/cookie exchange. Obviously more extensive mechanisms can be negotiated as well if desired. Since we now have all the functionality we'll ever need in our new transportzilla protocol, there is no need to change IP or routing. Also, the network layer is now completely hidden from the application. So moving from IPv4 to IPv6 to IPv6 multihomed to IPv7 and IPv9 (skipping IPv8) will be a breeze. Most application builders will love this since they can finally stop worrying about resolving domain names in their applications. (Although the fact that they have to change their apps in itself may not be greeted with much enthusiasm for those who already did the v6 work, but most are still v4-only anyway.) > - identifiers are translated into locators > at the end-hosts, and the network performs > locator-locator translations if needed > e.g. for traffic engineering, A good way to do traffic engineering if the hosts are in charge of the identifier->locator substitution would be a way to add preference information to each locator. To be crude: the DNS looks in the BGP table to see which locators are better connected and includes this information in the replies. BTW, in order to do this right (traffic engineering incoming traffic) we also need to make the host ask for advice on which source address it should use. Iljitsch From owner-multi6@ops.ietf.org Sat Nov 2 08:41:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04798 for ; Sat, 2 Nov 2002 08:41:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187yYo-000075-00 for multi6-data@psg.com; Sat, 02 Nov 2002 05:43:34 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 187yYm-00006t-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 05:43:32 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA2Dh6B48535; Sat, 2 Nov 2002 14:43:07 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 2 Nov 2002 14:43:06 +0100 (CET) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: Message-ID: <20021102143500.M43861-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 2 Nov 2002, RJ Atkinson wrote: > and some few of us suspect there might be a convergence time wall > not very far in front of us in IPv4-land, that is not due to "weak > vendor hardware", but instead due to inherent issues in the current > Path Vector algorithms behind BGP. This kind of suspicion is part > of why the IRTF RRG is examining the broader topic of IP routing -- > though that level of research is outside the charter for this > list.... Doing this ourselves would be stretch charter-wise, but it would be good to be aware of what's going on, otherwise we may come up with the perfect solution that will last three months until BGP goes down the crapper. In other words: any information you have on this will be appreciated. And what I'd like to know: we're rapidly approaching the moment when routing information about the entire internet is too much to be present at a single point in space and time, even with provider aggregation in place. So how will this work with a link state protocol? The advantage of a distance path protocol is that it also works when the routing information isn't fully converged. From owner-multi6@ops.ietf.org Sat Nov 2 16:29:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12635 for ; Sat, 2 Nov 2002 16:29:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1885qp-0001OV-00 for multi6-data@psg.com; Sat, 02 Nov 2002 13:30:39 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 1885ql-0001LQ-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 13:30:36 -0800 Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id EB0161C; Sat, 2 Nov 2002 23:36:40 +0200 (EET) Message-ID: <3DC443DA.3070207@nomadiclab.com> Date: Sat, 02 Nov 2002 23:30:02 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: Notes about identifier - locator separator References: <20021102135406.Q43861-100000@sequoia.muada.com> In-Reply-To: <20021102135406.Q43861-100000@sequoia.muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-9.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit >On Sat, 2 Nov 2002, Pekka Nikander wrote: >>1. Architectural "structure" of the identifiers >> >> From my point of view, there are two different basic >> approaches: >> >> a) make the end-point identifiers a completely >> separate name space >> >> b) divide the IPv6 address space into locator >> and identifier space Iljitsch van Beijnum wrote: > As it seems to be open season on all aspects of the TCP/IP architecture, > let's follow this reasoning to its logical conclusion and make the > identifier the full host name. I like this approach, but I don't agree with your conclusions. Let's see why. > Let's go with this for a moment. Now obviously IP will be unable to > route based on hostnames, so the whole thing must be done at the > transport layer. Already here you make a statement that I don't sign. As of today, IP has also other functions but routing. Routing is the main function of IP from the router point of view, true. But from a host or application point of view, IP *also* provides a name space for end-points. If you separate locators completely from end-point identifiers, the logical conclusion is NOT to move the function to the transport layer but to split the IP layer into two halves: - A "lower" IP that routers packets much as today, and uses IP addresses as locators. - An "upper" IP that provides end-point identifiers to the transport protocols and eventually to the hosted applications, and maps these identifiers to locators before passing them to the "lower" IP. Or that's at least I see HIP. :-) If you want to, you can give the "upper" IP some other name, like "Host Layer" or "Common Lower Transport Layer" or whatever. The point is that it is completely underneath current transport protocols. (And optional, as I discuss below.) > Retrofitting TCP is probably not worth it, so we make a > new transport protocol. As I've said before, doing multihoming at the > transport layer has many drawbacks compatibility-wise, but if we're > going to do some major architectural work, we may as well go the full > nine yards and solve everything once and for all. If we take the position that multi-homing needs to be implemented at the transport layer, I by and large agree with you. And we already have SCTP. One possible way that I see is to implement compatibility "shims" so that you can run legacy TCP and UDP applications over SCTP. (I think Brian mentioned this a while back.) However, based on my limited understanding, I think that splitting IP into two sub-layers would *probably* be better. The reasons are related to security, signalling overhead, and architectural "beaty". I definitely don't mean that a solution based on SCTP would not work or be viable. I just want to say that I do find the idea of separate end-point identifiers and a separate layer for them better. > Since the identifiers aren't carried in IP and we need extra locators, > there must be some serious session establishment. Agreed. There are also security issues involved, requiring session establishment. However, some of these security issues would be present even if the locators and identifiers are separated "within" the IP address space á la 8+8. > Doing this in UDP > defeats the purpose. So apps that use straight UDP must either live with > the fact that they are not multihomed (which may be ok for something > like syslog) or implement their own multihoming mechanisms (such as the > DNS already does). If we split the IP layer into two sub-layers, I think that it should still be possible to use TCP/UDP either with the additional services provided by the "end-host identifier" layer or without it. When used without, the "new" services like multi-homing would not be available. However, this would be perfectly fine for short term request-response services. Architectural flexibility seems like a key issue here. [Some comments clipped since I didnt' find them relevant, even though they certainly were amusing :-) ] >> - identifiers are translated into locators >> at the end-hosts, and the network performs >> locator-locator translations if needed >> e.g. for traffic engineering, > > A good way to do traffic engineering if the hosts are in charge of the > identifier->locator substitution would be a way to add preference > information to each locator. To be crude: the DNS looks in the BGP > table to see which locators are better connected and includes this > information in the replies. Would you please clarify? I didn't quite understand. > BTW, in order to do this right (traffic engineering incoming traffic) we > also need to make the host ask for advice on which source address it > should use. Well, if you separate identifiers from locators, the semantics of the source address also change, at least potentially. We wrote a tongue-in-the-cheek paper about that to a local security conference (Nordsec) last year. It was titled "IPv6 source addresses considered harmful." For a couple of chuckles, see http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf BTW, my co-auther presented it and according to her most of the audience didn't get it while a couple had difficulties in keeping on their chairs and not rolling on the ground. :-) :-) --Pekka From owner-multi6@ops.ietf.org Sat Nov 2 16:56:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13227 for ; Sat, 2 Nov 2002 16:56:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1886Hb-00032k-00 for multi6-data@psg.com; Sat, 02 Nov 2002 13:58:19 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #2) id 1886HZ-00032W-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 13:58:17 -0800 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gA2Lw9G14898 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sat, 2 Nov 2002 16:58:16 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA2Lw8NE021580 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Sat, 2 Nov 2002 16:58:09 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA2Lw7ij021576 for ; Sat, 2 Nov 2002 16:58:08 -0500 Message-Id: <200211022158.gA2Lw7ij021576@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: Notes about identifier - locator separator In-reply-to: Your message of "Sat, 02 Nov 2002 11:43:01 +0200." <3DC39E25.9080404@nomadiclab.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 02 Nov 2002 16:58:07 -0500 From: Michael Richardson X-Spam-Status: No, hits=-6.4 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pekka" == Pekka Nikander writes: Pekka> 1. Architectural "structure" of the identifiers Pekka> From my point of view, there are two different basic Pekka> approaches: Pekka> a) make the end-point identifiers a completely Pekka> separate name space To me, this is trivially done by either extension headers, or layers of IP/IP. The later has the advantage that it naturally fits into IPsec. Pekka> 2. Translations Pekka> Here I see two basic solutions, again: Pekka> a) perform the identifier -> locator translation at Pekka> the end-host so that all packets leaving the end-host Pekka> have a proper locator, Pekka> b) allow the identifiers to leave the end-host without Pekka> locators, and perform the translation within the Pekka> the network, e.g., at a site border router. IPsec-type processing permits either. This is just gateway vs host. We also can do bump-in-the-stack/wire, but I hope we won't. Pekka> 4. Backwards compatibility This is equivalent to saying that one will permit cleartext traffic to single-homed boxes whose locator = end-point identifier. Pekka> 5. Security and privacy We have solutions to this problem. Pekka> From the privacy point of view, it would be a Pekka> definite plus if the actual, long lasting identifiers Pekka> would not be visible in packets. There are It would even better if the whole data contents were private. If the "cost" of being multihomed is that you have to strongly authenticate and/or encrypt your data... well... I'll be pushing everyone to become multihomed! ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPcRKbYqHRg3pndX9AQGO4wP+MCBNd+dHXPMjrOaCJlMj2oYsuYCJji4g ch4SGUMWh/Phh+cBrW4Xga4x8bo5+goCznUUlMmE5saFKI1REwwbZAOBU5wCQ2Ck lt9eYYjdjbjQ1df7VC0CzonBGjii33zZdGYtXl/gCIVEPAgUA1Ozx3PlpAryc8aR z+r0upumpxs= =ixLi -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sat Nov 2 17:02:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13443 for ; Sat, 2 Nov 2002 17:02:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1886NP-0003Nn-00 for multi6-data@psg.com; Sat, 02 Nov 2002 14:04:19 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #2) id 1886NN-0003Nb-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 14:04:18 -0800 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gA2M4AG14913 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sat, 2 Nov 2002 17:04:17 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA2M49NE021693 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Sat, 2 Nov 2002 17:04:10 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA2M49lH021688 for ; Sat, 2 Nov 2002 17:04:09 -0500 Message-Id: <200211022204.gA2M49lH021688@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: Notes about identifier - locator separator In-reply-to: Your message of "Sat, 02 Nov 2002 23:30:02 +0200." <3DC443DA.3070207@nomadiclab.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 02 Nov 2002 17:04:08 -0500 From: Michael Richardson X-Spam-Status: No, hits=-6.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> "Pekka" == Pekka Nikander writes: Pekka> If we take the position that multi-homing needs to be implemented Pekka> at the transport layer, I by and large agree with you. And we Pekka> already have SCTP. One possible way that I see is to implement Pekka> compatibility "shims" so that you can run legacy TCP and UDP Pekka> applications over SCTP. (I think Brian mentioned this a while Pekka> back.) My understanding from talking to Randall is that the SCTP API already permits three ways to interact with SCTP: - a SOCK_DGRAM (aka UDP) compatible way - a SOCK_STREAM (aka TCP) compatible way - and an SCTP specific way that gives you visibility into the ordered and unordered pieces, and the multiple addresses. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-multi6@ops.ietf.org Sat Nov 2 17:21:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13627 for ; Sat, 2 Nov 2002 17:21:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1886gK-0004X5-00 for multi6-data@psg.com; Sat, 02 Nov 2002 14:23:52 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 1886gG-0004Wj-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 14:23:48 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA2MNNM49037; Sat, 2 Nov 2002 23:23:23 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 2 Nov 2002 23:23:23 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Nikander cc: Subject: Re: Notes about identifier - locator separator In-Reply-To: <3DC443DA.3070207@nomadiclab.com> Message-ID: <20021102225251.V43861-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 2 Nov 2002, Pekka Nikander wrote: > > As it seems to be open season on all aspects of the TCP/IP architecture, > > let's follow this reasoning to its logical conclusion and make the > > identifier the full host name. > I like this approach, but I don't agree with your conclusions. > Let's see why. Ok... > > Let's go with this for a moment. Now obviously IP will be unable to > > route based on hostnames, so the whole thing must be done at the > > transport layer. > Already here you make a statement that I don't sign. As of today, > IP has also other functions but routing. Routing is the main > function of IP from the router point of view, true. But from a > host or application point of view, IP *also* provides a name space > for end-points. I don't understand. > If you separate locators completely from end-point identifiers, > the logical conclusion is NOT to move the function to the > transport layer but to split the IP layer into two halves: > - A "lower" IP that routers packets much as today, and uses > IP addresses as locators. > - An "upper" IP that provides end-point identifiers to the > transport protocols and eventually to the hosted applications, > and maps these identifiers to locators before passing them > to the "lower" IP. Ok, that makes some sense. I believe the IEEE slices a single OSI layer at least three ways so two is modest. However, what will the interaction with the upper layer be like? Either this has to be done using the new identifiers, which isn't good. I'm not completely sure how much of the inefficiencies of string handling (as compared to working with a fixed length machine word size aligned value) modern processors can optimize away, but I doubt it's the entire thing. This would get pretty bad in machines with very many sessions. Alternatively, there must be some kind of state. That's contrary to the IP (as in IP layer, not TCP/IP as a whole) philosophy. > > Retrofitting TCP is probably not worth it, so we make a > > new transport protocol. As I've said before, doing multihoming at the > > transport layer has many drawbacks compatibility-wise, but if we're > > going to do some major architectural work, we may as well go the full > > nine yards and solve everything once and for all. > If we take the position that multi-homing needs to be implemented > at the transport layer, I by and large agree with you. A reason to not want this is that it requires big changes to existing code. But many of the things we've been discussing lately do this anyway. Apart from that my main gripe with doing it at the transport layer is that we can't offload the processing to a box external to the end host. On the other hand the big plus is that the tranport layer knows when to switch locators. > And we already have SCTP. I'm not fully familiar with SCTP, but it's never intended to fully solve the multihoming problem, and I'm not convinced it is as advanced as TCP with regard to congestion issues. (Although I believe we can improve on TCP in that regard, but at least its track record is proven and well-known.) > One possible way that I see is to implement > compatibility "shims" so that you can run legacy TCP and UDP > applications over SCTP. (I think Brian mentioned this a while > back.) You mean intercept the old APIs and translate them to new stuff. I guess this could work. Still, IPv6 deployment isn't that huge so if we can make something that is really very good, people will want it and we shouldn't have to deal with much legacy stuff. About UDP: this is intended to be a light weight protocol. Running it on top of a heavy weight protocol defeats the purpose. Also, you'll get into trouble if you end up doing name server request over the multihomed transport as this new transport needs to go to the DNS itself. > However, based on my limited understanding, I think that splitting > IP into two sub-layers would *probably* be better. Tell us more about how this works and what it solves. > > A good way to do traffic engineering if the hosts are in charge of the > > identifier->locator substitution would be a way to add preference > > information to each locator. To be crude: the DNS looks in the BGP > > table to see which locators are better connected and includes this > > information in the replies. > Would you please clarify? I didn't quite understand. You open a connection to blah.com. The new transport protocol looks up the locators associated with blah.com. Suppose they are abc::1 and def::1. Today, the DNS/resolver library either presents the addresses to the application in the order they were received or orders them semi-randomly (round robin) to achieve some load balancing. The DNS and/or resolver could look in the routing tables and sort the addresses according to their routing metric (suppose abc::/32 is 3 AS hops away and def::/32 1 AS hop, def::1 would be first and abc::1 second) but it would be better to list an explicit preference value (for instance, abc::1 pref = 33, def::1 pref = 100). > > BTW, in order to do this right (traffic engineering incoming traffic) we > > also need to make the host ask for advice on which source address it > > should use. > Well, if you separate identifiers from locators, the semantics of > the source address also change, at least potentially. We wrote > a tongue-in-the-cheek paper about that to a local security conference > (Nordsec) last year. It was titled "IPv6 source addresses considered > harmful." For a couple of chuckles, see > http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf I didn't read the whole thing but it seemed at least somewhat serious... Leaving out source addresses means you can't protect yourself against DoS attacks. Iljitsch From owner-multi6@ops.ietf.org Sat Nov 2 18:53:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15079 for ; Sat, 2 Nov 2002 18:53:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18886x-000A9d-00 for multi6-data@psg.com; Sat, 02 Nov 2002 15:55:27 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 18886v-000A9R-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 15:55:26 -0800 From: Masataka Ohta Message-Id: <200211022350.IAA08319@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA08319; Sun, 3 Nov 2002 08:49:48 +0859 Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development] In-Reply-To: <9D445F66-EE5E-11D6-9F10-00039357A82A@extremenetworks.com> from RJ Atkinson at "Nov 2, 2002 07:28:38 am" To: RJ Atkinson Date: Sun, 3 Nov 2002 08:49:47 +0859 () CC: alh-ietf@tndh.net, multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Ran; > If router vendors had a knob that enabled separation of > location/identity Separation of locatioin/identity itself does not require any modification on routers. Poor GSE does. Masataka Ohta From owner-multi6@ops.ietf.org Sat Nov 2 19:33:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15809 for ; Sat, 2 Nov 2002 19:33:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1888jt-000CVo-00 for multi6-data@psg.com; Sat, 02 Nov 2002 16:35:41 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 1888jr-000CVc-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 16:35:39 -0800 From: Masataka Ohta Message-Id: <200211030023.JAA08641@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA08641; Sun, 3 Nov 2002 09:23:39 +0900 Subject: Re: Notes about identifier - locator separator In-Reply-To: <3DC39E25.9080404@nomadiclab.com> from Pekka Nikander at "Nov 2, 2002 11:43:01 am" To: Pekka Nikander Date: Sun, 3 Nov 2002 09:23:38 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.6 required=5.0 tests=DISCLAIMER,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2, QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > [During the last couple of days there have been quite a lot > of comments, by various people, on the ideas of separating > identifiers and locators (see the end of this message for > some quotations). Based on our experience on Mobile IPv6, > the late Homeless Mobile IPv6 suggestion, and our current > work on Mobile IPv6 security and HIP, I'd like to present > a few observations. Disclaimer: I am far from being a > routing expert, so take your usual grain of salt.] You are mostly correct. However, you made mistakes on security, DNS and mobility. > From the privacy point of view, it would be a > definite plus if the actual, long lasting identifiers > would not be visible in packets. Your privacy concern is caused by long lasting IDs by itself and has nothing to do with visibility in packets. No one think it a problem that their phone numbers are visible in SS7 packets. Long lasting IDs weaken privacy because it is used as a key to merge multiple databases. > There are > techniques how identifiers could be cryptographically > masked in a way that still allows middle boxes > (such as firewalls) and end-points to still recognize > valid identifiers but make it hard for outsiders > to track them. As long as the end-points, which hold the databases, can recognize the ID, the end-points can merge their databases. You might think that, the concern can be avoided with short-lived ID. However, long lasting database entries needs long lasting IDs. The solution is to accept the reality. Those who mind can change their IDs as frequently as they want or can use multiple IDs at once. > 3. Resolution > > Apparently there must also be some way of finding the > locators based on the identifier or a name. Apparently > there is a huge number of possible solutions to this. > One of the most obvious ones is to store both identifiers > and locators into the DNS, and make the name resolution > library to fetch both. You seems to be thinking of inverse query, leagacy feature found in RFC103[45] replaced by in-addr.arpa. However, it does not work. If you rely on DNS, you must make DNS work in multihomed environment. In addition, you can't force DNS act quickly enough for mobility. Masataka Ohta From owner-multi6@ops.ietf.org Sun Nov 3 02:23:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01246 for ; Sun, 3 Nov 2002 02:23:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188F7i-000EBu-00 for multi6-data@psg.com; Sat, 02 Nov 2002 23:24:42 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 188F7f-000E8E-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 23:24:39 -0800 Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id 86DBD1C; Sun, 3 Nov 2002 09:30:44 +0200 (EET) Message-ID: <3DC4CF17.7030409@nomadiclab.com> Date: Sun, 03 Nov 2002 09:24:07 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta Cc: multi6@ops.ietf.org Subject: Re: Notes about identifier - locator separator References: <200211030023.JAA08641@necom830.hpcl.titech.ac.jp> In-Reply-To: <200211030023.JAA08641@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ohta-san, Masataka Ohta wrote: > However, you made mistakes on security, DNS and mobility. I am always eager to learn more. Thank you for providing this opportunity. I wrote: >> From the privacy point of view, it would be a >> definite plus if the actual, long lasting identifiers >> would not be visible in packets. To which you replied: > Your privacy concern is caused by long lasting IDs by itself and > has nothing to do with visibility in packets. No one think it a > problem that their phone numbers are visible in SS7 packets. > > Long lasting IDs weaken privacy because it is used as a key to > merge multiple databases. Well, let me both agree and disagree with you. From my point of view, the situation is not as simple as you seem to say. But maybe we are just talking about the same thing with different words. Firstly, if we want to build long lasting relationships, we need long lasting identifiers. There we seem to agree. However, the long lasting identifiers are no business to those outside of that relationship. The relationship may be binary, in which case the IDs are relevant only to the two communicating parties. Or it may have higher arity, in which case there are also other parties that have legitimite access to the identifiers. Secondly, given a single packet travelling in the network, the long lasting IDs may be presented in clear text, or alternatively they may be either implied or encrypted. If they are not present in clear text, most parties that see the packet have no access to the IDs. On the other hand, the receiver of the packet, and perhaps also some middle boxes (such as a corporate firewall) do need to have access to the IDs. The key here is state. If the middle box or the receiver has state (e.g. a cryptographic key or a communication context), it can check that the arriving packet indeed contains or implies a known long lasting identifier, and act accordingly. However, parties that do not have that state cannot find out the long lasting identifiers. If we want to go to the heavy transactions track, Marianne Winslett in one hand and the KeyNote guys (Bellovin, Blaze, Feigenbaum, Keromytis, JI, and more recently also others) have done quite a lot of work. However, if we want to hide the long lasting IDs but not pay the cost of PK crypto, there seems to be fewer published works. > As long as the end-points, which hold the databases, can > recognize the ID, the end-points can merge their databases. > > You might think that, the concern can be avoided with short-lived > ID. However, long lasting database entries needs long lasting IDs. The issue with database merging is completely different. That can be resolved by having multiple pseudonyms that cannot be easily linked. However, each of the pseudonyms can be long lasting by itself. > The solution is to accept the reality. Of course. I couldn't agree more. And IMHO, the reality also includes parties that attempt to perform traffic analysis on the packets flowing in the wire instead of trying to penetrate to the end-points. Echelon comes to my mind... ----- >>3. Resolution >> >> Apparently there must also be some way of finding the >> locators based on the identifier or a name. Apparently >> there is a huge number of possible solutions to this. >> One of the most obvious ones is to store both identifiers >> and locators into the DNS, and make the name resolution >> library to fetch both. > > > You seems to be thinking of inverse query, leagacy feature found in > RFC103[45] replaced by in-addr.arpa. However, it does not work. Would you please point me to text that explains why the reverse DNS database does not work, and in which way? OTOH, I was mostly thinking about a very simple forward resolution: a.domain.name -> (identifier, locator, locator) For example, a.domain.name. IN AAAA locator1 IN AAAA locator2 IN XXX identifier where XXX would be either a new RR type or, e.g., KEY RR, if public keys were used as identifiers. What comes to identifier -> locator resolution, I don't think there is anything ready. Distributed Hash Tables seem like one possible future technology, but it has a long way to go before it can become a part of the established infrastructure, if ever. Or alternatively the identifiers could be hierarchically assigned. > If you rely on DNS, you must make DNS work in multihomed environment. I agree, and I'd like to learn better the issues around this. > In addition, you can't force DNS act quickly enough for mobility. Yes, I know. For mobility something like Home Agents or LIN6 identifiers are needed. In the HIP architecture, this is called randezvous service. --Pekka Nikander From owner-multi6@ops.ietf.org Sun Nov 3 02:51:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01679 for ; Sun, 3 Nov 2002 02:51:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188Fa8-000GJN-00 for multi6-data@psg.com; Sat, 02 Nov 2002 23:54:04 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 188Fa6-000GJ8-00 for multi6@ops.ietf.org; Sat, 02 Nov 2002 23:54:02 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id F27F623C24; Sat, 2 Nov 2002 03:00:06 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gA37rMiI013330; Sat, 2 Nov 2002 23:53:27 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Sat, 2 Nov 2002 23:53:22 -0800 Message-ID: Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcKB1sO5ErJvwh/fQbCh6hoBehX5yQBNr6sg From: "Tony Li" To: , "Iljitsch van Beijnum" , "Craig A. Huegen" Cc: X-Spam-Status: No, hits=-0.1 required=5.0 tests=SPAM_PHRASE_01_02 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA01679 | You raise a point here that I think gets lost in the | mapping proposals. | 'As far as your own hosts, the DNS and remote hosts are | concerned, hosts | in your network have a single address.' | If the upper 48 bits are constant in DNS, but continually | changing in | the routing system, there needs to be a way to pass the | possible set of | topologically appropriate replacement values between the | CPE routers. | Since this protocol would inherently have to be run between | organizations that have no trust relationship, how that be | deployable? You have no trust relationship today with anyone that provides you a locator. [BTW, for multihomed sites, I would expect that the locators would be advertised in DNS as well. Mobile hosts would require a different mechanism.] Hosts that frequently need to change their locator would need to pass the new locator back to the CN. This could be done reasonably as part of the transport protocol. Tony From owner-multi6@ops.ietf.org Sun Nov 3 03:02:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01828 for ; Sun, 3 Nov 2002 03:02:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188Fjt-000HCJ-00 for multi6-data@psg.com; Sun, 03 Nov 2002 00:04:09 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 188Fjq-000H5y-00 for multi6@ops.ietf.org; Sun, 03 Nov 2002 00:04:07 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id DA67C23C24; Sat, 2 Nov 2002 03:10:10 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gA383aiI014049; Sun, 3 Nov 2002 00:03:36 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming development] Date: Sun, 3 Nov 2002 00:03:35 -0800 Message-ID: Thread-Topic: PI/metro/geo [Re: The state of IPv6 multihoming development] Thread-Index: AcKCAvFcMP5j/B5ITsikGYESFh4MVwBCzKHg From: "Tony Li" To: , "Randy Bush" Cc: X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA01828 Tony, | The IETF consensus process != democratic, and rarely comes | close. The | point was more to make sure there is someone that can give | a first-hand | defense of the requirements so they are not easily | dismissed by those | with other priorities. That is certainly fair and welcome. | Yes, we are here to focus on layer 3 scaling, but we can't | loose sight of the wider impact. Please remember that my interest is the growth of the net as a whole, not just scalability. | > The end | > user is going to have a prefix that reflects their topology, | > even in the single homed case. If we can do the renumbering | > only at the border and reduce renumbering costs that way, does | > the end user still care what his prefix is? | | That question deserves a firsthand answer from a current enterprise | network manager. So it may surprise you to learn that I used to be a network operator some time ago [Los Nettos, 1987-1990] and an enterprise network manager for my company and of course my own home. We happened to recently change providers at my company and, because we are behind a NAT system, found the change to be quite trivial. Of course, we only needed to renumber the NAT box. In a 16+16 environment, where only the border routers are configured with the global locators for the enterprise, renumbering amounts to reconfiguring only one system. | But since there is no way to ensure that an identifier is globally | unique, the only way to accomplish the goal is to couple them to | describe 'this identifier at this location'. If the location is not | stable, the static description is not stable. You can assign an identifier based purely on the administrative hierarchy. We have an existance proof that we can do this, because we've done so already in DNS. | > | This model was probably possible 4 years ago, but at this | > | point I doubt | > | tweaking the pseudoheader can even be on the table. | > | > | > Why? | | Shipped code is hard to change. For something as | significant as this, it | takes two years from the point of agreement to get new code shipped, | then it takes an additional 3-7 years to get the prior code | retired. We | will need a multi-homing solution well before that, so we | need to find | something that is incremental. I submit to you that if folks are unwilling to change to an architecture that scales, then IPv6 is already doomed. | Because the identifier is not stable & globally unique, and | even if we | had a way to ensure that, the privacy advocate's alarms | would be going | off. Despite the desire to avoid it, the current reality is that to | create a globally unique identifier we bound the problem by | coupling it | with its locator. That is certainly true today. However, there is no requirement for that. Consider that host foo.cisco.com already has a globally unique and fixed hostname. We allocated this in a hierarchical fashion that requires no aggregation. We simply do the same for the identifier space. Tony From owner-multi6@ops.ietf.org Sun Nov 3 05:59:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03262 for ; Sun, 3 Nov 2002 05:59:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188ITY-00016j-00 for multi6-data@psg.com; Sun, 03 Nov 2002 02:59:28 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 188ITV-00013J-00 for multi6@ops.ietf.org; Sun, 03 Nov 2002 02:59:26 -0800 Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id 8923D1C; Sun, 3 Nov 2002 13:05:30 +0200 (EET) Message-ID: <3DC5016D.2060907@nomadiclab.com> Date: Sun, 03 Nov 2002 12:58:53 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: Notes about identifier - locator separator References: <20021102225251.V43861-100000@sequoia.muada.com> In-Reply-To: <20021102225251.V43861-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > On Sat, 2 Nov 2002, Pekka Nikander wrote: >> IP has also other functions but routing. Routing is the main >> function of IP from the router point of view, true. But from a >> host or application point of view, IP *also* provides a name space >> for end-points. Iljitsch van Beijnum wrote: > I don't understand. Hmm. I'm not quite sure what you don't understand. :-) Obviously, the text book explanation of IP is that IP provides the packet forwarding service, and needs routing in order to be able to forward packets. But as we all know, there is more in IP. From my point of view, end-point naming is one of the most important "services" IP provides today (in addition to the packet forwarding "service", of course). That is, the TCP and UDP port numbers are qualified by the IP address of the host currently hosting the application. In order words, IP provides a name space for end-points, and the application level entities (sockets) are named by concatenating the IP address and the port number (and in some other cases, like TCP MUX and ONC RPC, also other information). But this should all be trivial; I am unsure why we are discussing this. Well, maybe the reason lies in the fact that the sublayering idea takes explicit advantage of that the packet forwarding "service" and end-point naming "service" need not be so tightly bound as they are today. >>- An "upper" IP that provides end-point identifiers to the >> transport protocols and eventually to the hosted applications, >> and maps these identifiers to locators before passing them >> to the "lower" IP. ... > > However, what will the interaction with the upper layer be like? Either > this has to be done using the new identifiers, which isn't good. I'm not > completely sure how much of the inefficiencies of string handling (as > compared to working with a fixed length machine word size aligned value) > modern processors can optimize away, but I doubt it's the entire thing. > This would get pretty bad in machines with very many sessions. There are two issues here: The "real" nature of the new identifiers, and the representation of the new identifiers in application data structures. For application level backwards compatibility, we obviously want the new identifiers to look (almost) like IP addresses. If they do, they can be stored in existing data structures, and we can provide binary compatibility to (almost) all existing applications. (The only exception are applications that explicitly inspect the IP addresses to determine their properties.) No need for string handling at all. Thus, as long as application level backwards compatibility is an issue, we want the interaction between the "upper" IP layer and the transport layer to look like it looks like today. The syntax would be (almost) the same, just the semantics different. The essence of the semantic difference would be the hiding of the underlying changing IP addresses. Today most programs today do not expect the IP addresses to change, but they do expect the socket to remain connected to the same peer host. Thus, in a way, the semantic change is not much of a change for most of the applications. Most applications are primarily interested on the peer hosts anyway, not their IP addresses. The real nature of the end-point identifiers is then a completely different story. Either they can be something that fits into 128 bits, or they can be something that does not. If they do not, the 128 bits stored in the application data structures would be a "pointer" to the actual end-point identifier. In the HIP case the 128 bit representation is a hash of a public key, while the actual end-point identifier is the public key. > Alternatively, there must be some kind of state. That's contrary to the > IP (as in IP layer, not TCP/IP as a whole) philosophy. Well, there is certainly state at the IP layer. The real question is where and what kind of state. For example, if you look at the *BSD TCP/IP implementation, there is certainly state at the IP layer. It is represented in the form of routing table entries. And part of this state is not related to routing at all, but is essentially end-to-end information, such as PMTU and RTT estimates. >> However, based on my limited understanding, I think that splitting >> IP into two sub-layers would *probably* be better. > > Tell us more about how this works and what it solves. Well, it is hard to tell in detail how it would work, unless we have some very concrete proposal at hand. And if we go into the details of a specific proposal, they will be lenghty. As examples, both HIP and LIN6 have been documented fairly well, I think. Well, what does it solve then? Apparently it helps to separate the identifiers from locators, thereby solving end-host mobility and multi-homing, and perhaps helping with NEMO style mobile networks and site multi-homing. > Leaving out source addresses means you can't protect yourself against > DoS attacks. Source addresses don't help much with DDoS attacks today. I sincerely doubt they ever would. I think that the idea that ingress filtering would effectively cut down DDoS is a fallacy. But some others disagree with me, I know. --Pekka Nikander From owner-multi6@ops.ietf.org Sun Nov 3 07:29:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04343 for ; Sun, 3 Nov 2002 07:29:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188Jt6-0006J9-00 for multi6-data@psg.com; Sun, 03 Nov 2002 04:29:56 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 188Jt4-0006Ix-00 for multi6@ops.ietf.org; Sun, 03 Nov 2002 04:29:54 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA3CTRR50218; Sun, 3 Nov 2002 13:29:27 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 3 Nov 2002 13:29:27 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Nikander cc: Subject: Re: Notes about identifier - locator separator In-Reply-To: <3DC5016D.2060907@nomadiclab.com> Message-ID: <20021103130722.F43861-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 3 Nov 2002, Pekka Nikander wrote: > From my point of view, end-point naming is one of the most > important "services" IP provides today (in addition to > the packet forwarding "service", of course). Ah, I see. > There are two issues here: The "real" nature of the new identifiers, > and the representation of the new identifiers in application data > structures. For application level backwards compatibility, we > obviously want the new identifiers to look (almost) like IP addresses. We should have a new API that makes it possible to use the real identifiers (= the host names). Obviously you can map a 32 or 128 bit value to a name and put this name in the DNS so you can run old applications over the new transport protocol. However, that means you have to sacrifice the old API(s) as you either use them as they are now (= no old programs use the new transport) or reroute them over the new transport (= no programs can use regular IPv4 or IPv6). For IPv6 this would be bad. For IPv4 it would be good if the host doesn't have an IPv4 address. It can then connect to dual-stack IPv6 hosts over IPv6 with the application thinking it's doing IPv4. This would break some stuff if the originating host doesn't have a valid IPv4 address, though. > Thus, as long as application level backwards compatibility is an issue, > we want the interaction between the "upper" IP layer and the transport > layer to look like it looks like today. No, we want a new API so new apps can be clean. Use dirty hacks for the old stuff if we need backward compatibility. > > Leaving out source addresses means you can't protect yourself against > > DoS attacks. > Source addresses don't help much with DDoS attacks today. > I sincerely doubt they ever would. I think that the idea > that ingress filtering would effectively cut down DDoS > is a fallacy. But some others disagree with me, I know. One of them being me. Besides, nobody can predict the future: "640k should be enough for everyone." "There is only a market for five computers world wide: one for each continent." "George Lucas is insane. Who is ever going to download an entire movie over the net?" From owner-multi6@ops.ietf.org Sun Nov 3 07:53:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04923 for ; Sun, 3 Nov 2002 07:53:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188KHq-0007ty-00 for multi6-data@psg.com; Sun, 03 Nov 2002 04:55:30 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 188KHp-0007te-00 for multi6@ops.ietf.org; Sun, 03 Nov 2002 04:55:29 -0800 From: Masataka Ohta Message-Id: <200211031248.VAA15355@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA15355; Sun, 3 Nov 2002 21:48:08 +0900 Subject: Re: Notes about identifier - locator separator In-Reply-To: <3DC5016D.2060907@nomadiclab.com> from Pekka Nikander at "Nov 3, 2002 12:58:53 pm" To: Pekka Nikander Date: Sun, 3 Nov 2002 21:48:07 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,SPAM_PHRASE_00_01 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > From my point of view, end-point naming is one of the most > important "services" IP provides today (in addition to > the packet forwarding "service", of course). That is, > the TCP and UDP port numbers are qualified by the IP > address of the host currently hosting the application. > In order words, IP provides a name space for end-points, > and the application level entities (sockets) are named > by concatenating the IP address and the port number > (and in some other cases, like TCP MUX and ONC RPC, also > other information). That is a transport layer centric view and is wrong. At the transport layer, which is purely within a host, there is no routing that locator aspect of IPv4 addresses is not visible. However, the most important property of the Internet is global connectivity between hosts that the most important service of IP is the global connectivity. Masataka Ohta From owner-multi6@ops.ietf.org Sun Nov 3 08:33:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05422 for ; Sun, 3 Nov 2002 08:33:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188KuT-0009Vv-00 for multi6-data@psg.com; Sun, 03 Nov 2002 05:35:25 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 188KuR-0009Vj-00 for multi6@ops.ietf.org; Sun, 03 Nov 2002 05:35:23 -0800 From: Masataka Ohta Message-Id: <200211031326.WAA15600@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA15600; Sun, 3 Nov 2002 22:26:00 +0900 Subject: Re: Notes about identifier - locator separator In-Reply-To: <3DC4CF17.7030409@nomadiclab.com> from Pekka Nikander at "Nov 3, 2002 09:24:07 am" To: Pekka Nikander Date: Sun, 3 Nov 2002 22:25:59 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-6.3 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > Well, let me both agree and disagree with you. From my point > of view, the situation is not as simple as you seem to say. > But maybe we are just talking about the same thing with > different words. Unfortunately, no. > Secondly, given a single packet travelling in the network, > the long lasting IDs may be presented in clear text, or > alternatively they may be either implied or encrypted. > If they are not present in clear text, most parties > that see the packet have no access to the IDs. On the other > hand, the receiver of the packet, and perhaps also some > middle boxes (such as a corporate firewall) do need to have > access to the IDs. It has nothing to do with whether the ID is long lasting or not. Note also that locaters often act as long lasting IDs. > The key here is state. If the middle box or the receiver > has state (e.g. a cryptographic key or a communication context), > it can check that the arriving packet indeed contains or > implies a known long lasting identifier, and act accordingly. > However, parties that do not have that state cannot find > out the long lasting identifiers. For a receiver to retrieve an appropriate cryptographic key or a communication context for a packet, a long lasting ID in clear text, as an index to the long lasting database of key or context, must be carried by the packet. Once such key or context is retrieved, the following packets of a connection can use locators as a short lasting IDs. But, it does not mean that a long lasting ID is not initially necessary. > If we want to go to the heavy transactions track, Marianne > Winslett in one hand and the KeyNote guys (Bellovin, Blaze, > Feigenbaum, Keromytis, JI, and more recently also others) > have done quite a lot of work. However, if we want to hide > the long lasting IDs but not pay the cost of PK crypto, there > seems to be fewer published works. PK is useless. Crypto works only if you tell your ID, that is, some index information to retrive a cryptographic key or a communication context, in clear text, to the other end. > > The solution is to accept the reality. > > Of course. I couldn't agree more. And IMHO, the reality > also includes parties that attempt to perform traffic > analysis on the packets flowing in the wire instead of > trying to penetrate to the end-points. Echelon comes > to my mind... Proxies are a way aginst Echelon. However, more important aspect of the reality is that if identity of someone is hidden, the network is valunerable to SPAM and other forms of DOS. In your case, as locators act as a long lasting ID, Echelon works fine and SPAMMers can be traced. Cyber terrorists can still use chains of a lot of proxies to make the trace more difficult and the Internet less secure. But that is unavoidable reality. > >> Apparently there must also be some way of finding the > >> locators based on the identifier or a name. Apparently > >> there is a huge number of possible solutions to this. > >> One of the most obvious ones is to store both identifiers > >> and locators into the DNS, and make the name resolution > >> library to fetch both. > > > > > > You seems to be thinking of inverse query, leagacy feature found in > > RFC103[45] replaced by in-addr.arpa. However, it does not work. > > Would you please point me to text that explains why the > reverse DNS database does not work, and in which way? I said "inverse query". See the RFCs. > > If you rely on DNS, you must make DNS work in multihomed environment. > > I agree, and I'd like to learn better the issues around this. There are complex issues. The first step of learning is to read basic RFCs. > > In addition, you can't force DNS act quickly enough for mobility. > > Yes, I know. For mobility something like Home Agents or LIN6 > identifiers are needed. In the HIP architecture, this is > called randezvous service. I feel some difficulty that you call such approach "Homeless". Masataka Ohta From owner-multi6@ops.ietf.org Sun Nov 3 12:08:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10722 for ; Sun, 3 Nov 2002 12:08:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188OFp-000H2E-00 for multi6-data@psg.com; Sun, 03 Nov 2002 09:09:41 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #2) id 188OFl-000Gzp-00 for multi6@ops.ietf.org; Sun, 03 Nov 2002 09:09:38 -0800 Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id CBBBE1C; Sun, 3 Nov 2002 19:15:42 +0200 (EET) Message-ID: <3DC55831.2070703@nomadiclab.com> Date: Sun, 03 Nov 2002 19:09:05 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta Cc: multi6@ops.ietf.org Subject: The cost of privacy (was Re: Notes about identifier - locator separator) References: <200211031326.WAA15600@necom830.hpcl.titech.ac.jp> In-Reply-To: <200211031326.WAA15600@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ohta-san, [Changed the subject to better match the contents. Furthermore, this starts to be off-topic.] Masataka Ohta wrote: > For a receiver to retrieve an appropriate cryptographic key or > a communication context for a packet, a long lasting ID in clear > text, as an index to the long lasting database of key or context, > must be carried by the packet. Not necessarily. Since you don't seem to believe in PK and apparently also not in zero knowledge protocols, let me give a simple example with only hash functions. Let us assume that Alice's long lasting ID is A, and she is contacting Bob. Let the ID space be sparse, i.e., so that there are few IDs compared to the whole space. For the example to make sense in the first place, Alice and Bob must have talked to each other beforehand, and Bob therefore knows A. Now, instead of sending A, Alice generates a random nonce N, and sends , , and perhaps where first(k, A) are the first k bits of A. Note that this message does not carry A, it only carries values derived from A. Bob can now retrieve from his database all IDs whose first k bits match with he knows that he has found the right ID. Unless an attacker possesses exactly the same database as Bob, it has much larger task ahead and in many cases can't be sure about Alice's identifier A even after the search. Thus, with some computational cost at the context setup you can hide the long term identifiers from outsiders. (To be secure against DoS, the context setup must be protected against resource exhausting DoS but that can be easily done with a cookie exchange.) After the context has been set up, it can be indexed with a short term connection ID, as you seem to agree. > Once such key or context is retrieved, the following packets of a > connection can use locators as a short lasting IDs. But, it does not > mean that a long lasting ID is not initially necessary. I think I have countered your claim. There are more complex, and more effective, crypto protocols where you can get even better results. (Sorry, I can't give references out of hand, but I can dig up if you are interested.) > Proxies are a way aginst Echelon. Proxies mean inefficient routing. > However, more important aspect of the reality is that if identity > of someone is hidden, the network is valunerable to SPAM and other > forms of DOS. If the ID is hidden from the network, that doesn't necessarily make the network vulnerable to SPAM or DoS. Firstly, only a recipient is vulnerable to SPAM, not a network. An effective way against SPAM is to impose an artificial computational cost on the sender of a message. An effective way against certain types of DoS is to impose an artificial computational cost on the initiator of a session. If you don't believe me, here I have a number of references ready, if you are interested. You can design a network for privacy, still have it open, and make it DoS resistant. To do so, you have to understand the economics of security. See e.g. Ross Andersson's paper on last year's ACSAC for a fairly good introduction. If you are concerned about terrorism and privacy at the same time, you can design protocols that allow pseudonomity but where the pseudonomity can be broken at a computational cost. That allows NSA with its vast CPU farms to break privacy, but not the (a)typical spying ISP. That is, if you want such a system, you can develop such a system. What comes to me, I don't want my children to ever live in "1984". There is no black and white in security or privacy, even though some security or privacy zealots seem to think in that way. Security engineering is engineering, with conflicting goals, just like any engineering. You don't gain much by throwing away the amount of security and privacy that you can reasonably design in. -------- >> Would you please point me to text that explains why the >> reverse DNS database does not work, and in which way? > > I said "inverse query". See the RFCs. My apologies for misreading your sentence. It's been a while since I last read through the DNS RFCs, and I had forgotten the existense of inverse query. Apparently I seem to forget things that don't work. -------- > I feel some difficulty that you call such approach "Homeless". If you haven't noticed, I abandoned the "Homeless" MIPv6 idea almost two years ago, just a few months after the ID was out. Besides, the name was just a catchy phrase, meant to point out how the MIPv6 home agent is becoming an unnecessary single point of failure. --Pekka Nikander From owner-multi6@ops.ietf.org Sun Nov 3 20:17:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18388 for ; Sun, 3 Nov 2002 20:17:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188VsC-000BZt-00 for multi6-data@psg.com; Sun, 03 Nov 2002 17:17:48 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 188VsA-000BZe-00 for multi6@ops.ietf.org; Sun, 03 Nov 2002 17:17:46 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id UAA28040; Sun, 3 Nov 2002 20:17:44 -0500 Date: Sun, 3 Nov 2002 20:17:44 -0500 From: "J. Noel Chiappa" Message-Id: <200211040117.UAA28040@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: GSE Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=-0.7 required=5.0 tests=SPAM_PHRASE_02_03 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum > using identifiers with regular IPv6 unicast semantics will make the > transition a lot easier as it allows .. providing the multihoming > support in separate boxes. Umm, wouldn't you fall across the connection-hijacking issues that i) prevented use of source route to do mobility in MIPv4, and ii) led to the heavy-duty authentication in MIPv6? In other words, I'm assuming you have a "multihoming support box" (MSB) which is adding an extra layer of wrapping so that the destination address in the inner packet is the "host identifier" of the destination, which never changes, and the outer packet contains the current "locator". This sounds just like MIPv6, and has all the MIPv6 security issues. Or did I mis-understand something? E.g. were you not planning to support keeping connections up when one address stops working? Noel From owner-multi6@ops.ietf.org Sun Nov 3 20:43:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18809 for ; Sun, 3 Nov 2002 20:43:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188WJH-000D34-00 for multi6-data@psg.com; Sun, 03 Nov 2002 17:45:47 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #2) id 188WJE-000D2i-00 for multi6@ops.ietf.org; Sun, 03 Nov 2002 17:45:44 -0800 From: Masataka Ohta Message-Id: <200211040139.KAA25148@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA25148; Mon, 4 Nov 2002 10:39:31 +0900 Subject: Re: The cost of privacy (was Re: Notes about identifier - locator separator) In-Reply-To: <3DC55831.2070703@nomadiclab.com> from Pekka Nikander at "Nov 3, 2002 07:09:05 pm" To: Pekka Nikander Date: Mon, 4 Nov 2002 10:39:30 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.41 Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > Masataka Ohta wrote: > > For a receiver to retrieve an appropriate cryptographic key or > > a communication context for a packet, a long lasting ID in clear > > text, as an index to the long lasting database of key or context, > > must be carried by the packet. > > Not necessarily. Since you don't seem to believe in PK and > apparently also not in zero knowledge protocols, let me give > a simple example with only hash functions. > > Let us assume that Alice's long lasting ID is A, and she > is contacting Bob. Let the ID space be sparse, i.e., so > that there are few IDs compared to the whole space. For > the example to make sense in the first place, Alice and Bob > must have talked to each other beforehand, and Bob therefore > knows A. > > Now, instead of sending A, Alice generates a random nonce N, > and sends And sends just N, as an ID. It is called a cookie. But, your case is even simpler. > Bob can now retrieve from his database all IDs whose first > k bits match with