From owner-multi6@ops.ietf.org Fri Jan 9 12:01:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14040 for ; Fri, 9 Jan 2004 12:01:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Aezxw-000P3X-RN for multi6-data@psg.com; Fri, 09 Jan 2004 16:58:32 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aezxf-000OyZ-Hz for multi6@ops.ietf.org; Fri, 09 Jan 2004 16:58:15 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i09GwDRT065674; Fri, 9 Jan 2004 16:58:13 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i09GwCNa257300; Fri, 9 Jan 2004 17:58:12 +0100 Received: from zurich.ibm.com (dyn-9-13-127-142.ge.ch.ibm.com [9.13.127.142]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA23024; Fri, 9 Jan 2004 17:58:10 +0100 Message-ID: <3FFEDD62.B4CB180F@zurich.ibm.com> Date: Fri, 09 Jan 2004 17:57:06 +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: Margaret Wasserman CC: Tony Li , multi6@ops.ietf.org Subject: Re: Consensus on identifier/locator split? References: <5.1.0.14.2.20040109052803.0422c2c8@ms101.mail1.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret Wasserman wrote: > > Hi Tony, > > >I'd just like to get a sense from the group about where > >we are so far. Do we have consensus about splitting > >the address into locators and identifiers? Note that > >I'm NOT asking about specifics, like "how big", "what > >mappings exist", "is it secure", etc. Do we agree that > >we want to go down this path? > > Is it good enough to say that I think we should explore > options in this area? > > I have two reservations about making a sweeping statement > that this is the right solution to site multihoming in > IPv6: > > (1) It isn't 100% well-defined. The NOID proposal, for > example, doesn't really split the ID and locator into > separate fields -- the same value serves different > functions at different layers. True, but conceptually the split is still quite clear (as it is in LIN6 and HIP if you look at them the right way) > > (2) We don't have a completely worked example. So, we > can't be sure that this type of approach will meet > the requirements with an acceptable impact on the > other layers of the system, acceptable performance, > etc. True. But we have a lot of specifics, e.g. in the LIN6 and HIP drafts. Brian From owner-multi6@ops.ietf.org Fri Jan 9 12:41:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17578 for ; Fri, 9 Jan 2004 12:41:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af0cQ-0003cN-HB for multi6-data@psg.com; Fri, 09 Jan 2004 17:40:22 +0000 Received: from [198.137.194.222] (helo=challah.msrl.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af0c5-0003a4-Rl for multi6@ops.ietf.org; Fri, 09 Jan 2004 17:40:01 +0000 Received: (qmail 4063 invoked by uid 1021); 9 Jan 2004 17:39:59 -0000 Date: Fri, 9 Jan 2004 17:39:58 +0000 From: vijay gill To: Noel Chiappa Cc: multi6@ops.ietf.org Subject: Re: Draft of updated WG charter Message-ID: <20040109173958.GA2042@vijaygill.com> References: <20040109135818.58C73872D0@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040109135818.58C73872D0@mercury.lcs.mit.edu> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jan 09, 2004 at 08:58:18AM -0500, Noel Chiappa wrote: > If the WG as a whole agrees with you (and this is an important point to nail > down - my guess would be that they do not), then you've basically eliminated > all solutions to the problem other than recycling Mobile-IPv6 mechanisms > (since the charter rules out "let the routing do it", which means it has to > be done via use of multiple addresses). > > I'm curious as to why you want to rule out any changes to the end-hosts. I > note that Mobile-IPv6 didn't restrict themselves in this way. Significant amount of users that are multihomed have a setup that accepts defaults from two providers, and anounces their blocks to both upstreams. They receive no more information than the fact that their connection is up. No routing tables, no prefixes, just a quadzero. (users defined as an enterprise, not the invididual computer user obviously) The end user system is often nat'd, and run through a stateful firewall and all the information _they_ have is an ip address of the gateway via dhcp. Any end-host updating solution must work through this gobbledegook. /vijay From owner-multi6@ops.ietf.org Fri Jan 9 14:37:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28191 for ; Fri, 9 Jan 2004 14:37:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af2Pq-000HNo-Pl for multi6-data@psg.com; Fri, 09 Jan 2004 19:35:30 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af2Pb-000HMt-Np for multi6@ops.ietf.org; Fri, 09 Jan 2004 19:35:15 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id i09LewOt030029; Fri, 9 Jan 2004 13:40:58 -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 i09JYlYB011921; Fri, 9 Jan 2004 11:34: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Draft of updated WG charter Date: Fri, 9 Jan 2004 11:34:47 -0800 Message-ID: Thread-Topic: Draft of updated WG charter Thread-Index: AcPW2Ldv1To4XnBYQiuLNKfpxwR19wADt0Vg From: "Tony Li" To: "vijay gill" , "Noel Chiappa" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Vijay, Would you accept changes to the NAT box? Would you allow the insertion of a NAT layer in the end host stack? Tony | -----Original Message----- | From: vijay gill [mailto:vgill@vijaygill.com]=20 | Sent: Friday, January 09, 2004 9:40 AM | To: Noel Chiappa | Cc: multi6@ops.ietf.org | Subject: Re: Draft of updated WG charter | =20 | =20 | On Fri, Jan 09, 2004 at 08:58:18AM -0500, Noel Chiappa wrote: | =20 | > If the WG as a whole agrees with you (and this is an=20 | important point to nail | > down - my guess would be that they do not), then you've=20 | basically eliminated | > all solutions to the problem other than recycling=20 | Mobile-IPv6 mechanisms | > (since the charter rules out "let the routing do it",=20 | which means it has to | > be done via use of multiple addresses). | >=20 | > I'm curious as to why you want to rule out any changes to=20 | the end-hosts. I | > note that Mobile-IPv6 didn't restrict themselves in this way. | =20 | Significant amount of users that are multihomed have a setup that | accepts defaults from two providers, and anounces their blocks to | both upstreams. They receive no more information than the fact | that their connection is up. No routing tables, no prefixes, just | a quadzero. | =20 | (users defined as an enterprise, not the invididual computer user | obviously) | =20 | The end user system is often nat'd, and run through a stateful | firewall and all the information _they_ have is an ip address | of the gateway via dhcp. | =20 | Any end-host updating solution must work through this gobbledegook. | =20 | /vijay | =20 | =20 From owner-multi6@ops.ietf.org Fri Jan 9 14:46:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29085 for ; Fri, 9 Jan 2004 14:46:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af2Zx-000J20-5Z for multi6-data@psg.com; Fri, 09 Jan 2004 19:45:57 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af2Zj-000J0k-8g for multi6@ops.ietf.org; Fri, 09 Jan 2004 19:45:43 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i09JjWZN028788; Fri, 9 Jan 2004 20:45:32 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <67DE1D65-42DC-11D8-815B-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: "Multi6 List" From: Iljitsch van Beijnum Subject: Re: evaluation of draft-van-beijnum-multi6-odt-00.txt Date: Fri, 9 Jan 2004 20:45:41 +0100 To: X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9-jan-04, at 15:40, marcelo bagnulo wrote: > This with the address verification that you also use, would be > similar to > the return routability procedure of MIPv6, right? I'm not sure. >> If there is no encryption of the actual data over an insecure link, >> then I don't see how the data is sufficiently sensitive that the >> redirection attack that is possible with clear-text keys is a show >> stopper. > Well, if you consider mipv6 route optimization security design, > current IP > provides an intermediate level of security, where traffic is not > encrypted > but communications cannot be so easily redirected. I think this is the > goal > for multihoming security: not to do worse than current ip security. I > am > afraid that the security of this draft is worse than current ip > security. In theory, you're right. But in practice, things are different. I see three classes of traffic over insecure links: 1. Sensitive data that is encrypted using IPsec/SSL/SSH or what have you 2. Sensitive data that isn't encrypted 3. Non-sensitive data 1. already solves the PKI problem in some way or another. If we can find a way to tap in to that solution and use it to create session keys we have bullet proof redirection protection. So I think this situation is addressed. 2. is insane; trying to salvage anything here is useless. So that leaves 3. An attacker can redirect traffic to another address for which he can see the traffic (so not to arbitrary addresses) which is a bad thing, but for the "real" client the effect is pretty much the same as when the attacker had sent a TCP RST: the real client doesn't see any data anymore. The fact that the dat is now delivered to the attacker isn't of great importance due to the non-sensitive nature of the data. > Put it in another way: the security of this solution would be similar > than > using MIPv6 with inifinity BCE lifetime. MIP has an additional benefit > that > it is already standarized and code is available, so why deploy a > solution > tha has similar limitations? But MIPv6 also has some huge disadvantages, for instance the 24 byte per packet overhead. We've already concluded that using MIPv6 for multihoming without any changes won't fly. If your point is that using MIP interactions is easier and no less effective and efficient than designing something new then that's certainly something we can explore, as long as we have a very clear picture of where we want to go. Just diving into MIPv6 with the idea that it can solve multihoming with some tweaks would be a very bad idea. The two facts that MIPv6 still isn't an RFC and that the draft is 172 pages speak for themselves. Anyone any idea whether MIPv6 (with route optimization) can be implemented in a middlebox? From owner-multi6@ops.ietf.org Fri Jan 9 15:38:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12895 for ; Fri, 9 Jan 2004 15:38:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af3M4-00012p-BO for multi6-data@psg.com; Fri, 09 Jan 2004 20:35:40 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af3Lo-00011T-Pv for multi6@ops.ietf.org; Fri, 09 Jan 2004 20:35:24 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 1Af3Lk-0005As-00; Fri, 09 Jan 2004 14:35:21 -0600 Date: Fri, 9 Jan 2004 14:35:20 -0600 (CST) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: vijay gill cc: Multi6 Subject: Re: Draft of updated WG charter In-Reply-To: <20040109072034.GA25008@vijaygill.com> Message-ID: References: <3FFD700F.FC504B8A@zurich.ibm.com> <20040108152529.GA15512@vijaygill.com> <3225E60A-4201-11D8-A574-000A95928574@kurtis.pp.se> <20040109072034.GA25008@vijaygill.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 9 Jan 2004, vijay gill wrote: > Routing update validation should be orthogonal to the multihoming > solution. Also, I am going out on a limb here and say that any > m-homing solution that requires end-host updates is a non-starter > from the get-go. I'll go further out on that limb & say that any multi-homing solution which requires substantially more intelligence in end systems than is currently required for multi-homed IPv4 is bound to fail, even if you somehow get it deployed. This is really the heart of the IPv6 scalability issue. I've never understood the argument that multi-homing for IPv6 ought not be done the way it's done for IPv4 (single address per end system, multi-path routing) on the basis that the network can't tolerate the increase in routing table size/complexity. My objection is that the alternative (shoving the complexity to the end systems) is much worse because: o as evidenced by worm attacks..., the end systems are the worst managed pieces in the whole puzzle run by users who don't (& I'd say shouldn't be expected to) understand the workings of the network; predicating routing-type functionality on that platform is asking for trouble o there are at least 3 (4? 5?) orders of magnitude more end systems than there are routers, so embedding significant pieces of networking functionality in end systems greatly increases the likelihood of trouble & even more greatly decreases the chance of consistent operation over time Consider the current difficulty in deploying changes to other technologies due to system-level inertia (e.g., ASM->SSM for multicast). Those are relatively upper-level things which for the most part don't affect the basic ability to get packets delivered. Moving routing-type burden to the end systems creates such inertia for basic packet delivery, making the network as a whole even less upgradable than it is now. I advocate keeping the end systems as simple as possible & dealing with the routing support required to make multi-homing work close to the way it works for IPv4. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Fri Jan 9 15:56:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14939 for ; Fri, 9 Jan 2004 15:56:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af3fd-0005Pa-HC for multi6-data@psg.com; Fri, 09 Jan 2004 20:55:53 +0000 Received: from [198.137.194.222] (helo=challah.msrl.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af3fJ-0005MM-7k for multi6@ops.ietf.org; Fri, 09 Jan 2004 20:55:33 +0000 Received: (qmail 19481 invoked by uid 1021); 9 Jan 2004 20:55:32 -0000 Date: Fri, 9 Jan 2004 20:55:32 +0000 From: vijay gill To: Tony Li Cc: Noel Chiappa , multi6@ops.ietf.org Subject: Re: Draft of updated WG charter Message-ID: <20040109205532.GA18604@vijaygill.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jan 09, 2004 at 11:34:47AM -0800, Tony Li wrote: > > Vijay, > > Would you accept changes to the NAT box? > > Would you allow the insertion of a NAT layer in the end host stack? > > Tony _I'd_ accept a lot of things. However, I am not planning to go around upgrading multiple millions of linksys wifi/cable/dsl gateways, netscreens, pixes, and toshiba/motorola cable boxes. Jay Ford captured what I was trying to say in a much more eloquently. These are things we really need to pay attention to if we are not to spend another 2 years working on a brilliantly engineered, elegant solution that is used by no one. /vijay From owner-multi6@ops.ietf.org Fri Jan 9 16:39:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18202 for ; Fri, 9 Jan 2004 16:39:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af4KE-000DXt-VA for multi6-data@psg.com; Fri, 09 Jan 2004 21:37:50 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af4Jz-000DUp-O3 for multi6@ops.ietf.org; Fri, 09 Jan 2004 21:37:35 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id i09NhMOt031574; Fri, 9 Jan 2004 15:43:22 -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 i09LbOYB016506; Fri, 9 Jan 2004 13:37:28 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Draft of updated WG charter Date: Fri, 9 Jan 2004 13:37:24 -0800 Message-ID: Thread-Topic: Draft of updated WG charter Thread-Index: AcPW8vBbE9aAEGmTR4WOaByQZ38DTQABYfsQ From: "Tony Li" To: "vijay gill" Cc: "Noel Chiappa" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Well, then I would pose to you the obvious question: what is it that you want multihoming to do? If the end host behavior does not change, then all you are left with changing is the routing subsystem. And the only thing that you can now do is to declare all multihomed prefixes global or do an absurd amount of tunneling to repair the topology. For obvious reasons, I hope we agree that both of those alternatives are even less pleasant. Tony | -----Original Message----- | From: vijay gill [mailto:vgill@vijaygill.com]=20 | Sent: Friday, January 09, 2004 12:56 PM | To: Tony Li | Cc: Noel Chiappa; multi6@ops.ietf.org | Subject: Re: Draft of updated WG charter | =20 | =20 | On Fri, Jan 09, 2004 at 11:34:47AM -0800, Tony Li wrote: | >=20 | > Vijay, | >=20 | > Would you accept changes to the NAT box? | >=20 | > Would you allow the insertion of a NAT layer in the end host stack? | >=20 | > Tony | =20 | _I'd_ accept a lot of things. However, I am not planning to go around | upgrading multiple millions of linksys wifi/cable/dsl gateways, | netscreens, pixes, and toshiba/motorola cable boxes. | =20 | Jay Ford captured what I was trying to say in a much more eloquently. | =20 | These are things we really need to pay attention to if we are not to | spend another 2 years working on a brilliantly engineered, elegant | solution that is used by no one. | =20 | /vijay | =20 From owner-multi6@ops.ietf.org Fri Jan 9 16:43:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18312 for ; Fri, 9 Jan 2004 16:43:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af4Pm-000Epv-Mz for multi6-data@psg.com; Fri, 09 Jan 2004 21:43:34 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af4PZ-000Ep7-8I for multi6@ops.ietf.org; Fri, 09 Jan 2004 21:43:21 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DABAA872DE; Fri, 9 Jan 2004 16:43:20 -0500 (EST) To: multi6@ops.ietf.org Subject: Re: Draft of updated WG charter Cc: jnc@mercury.lcs.mit.edu Message-Id: <20040109214320.DABAA872DE@mercury.lcs.mit.edu> Date: Fri, 9 Jan 2004 16:43:20 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Jay Ford > I'll go further out on that limb & say that any multi-homing solution > which requires substantially more intelligence in end systems than is > currently required for multi-homed IPv4 is bound to fail .. I've heard this argument before, and I'm sorry but it's totally incorrect. If your basic concept (smart network, stupid endsystems) was true, we'd never have made the jump from NCP to TCP - because in that jump, congestion avoidance functionality was moved from the network to the end-systems - and trust me, congestion avoidance is a much more complex technical problem than path selection. Heck, every day a large cross-section of average humans tackle complex path selection problems - to get to work. And I'll remind you that half the population has an IQ of less than 100... Picking an end-system address is a troublesome problem for this WG only because the architectural environment in which it is currently operating is so impoverished. IPv4, for understandable reasons, started out with a extremely cartoonish routing architecture, one totally unsuited to use in a global uniqiuitous network. IPv6, for reasons which pass my understanding, elected not to tackle this problem. However, Rome wasn't built in a day, and you have to start somewhere. > This is really the heart of the IPv6 scalability issue. I've never > understood the argument that multi-homing for IPv6 ought not be done > the way it's done for IPv4 (single address per end system, multi-path > routing) on the basis that the network can't tolerate the increase in > routing table size/complexity. This argument is done and over with. The proposed WG charter correctly captures the rough consensus worked out on this WG mailing list a long time ago. Also, if you think about it a little bit, this is exactly the same issue as "why do people have to have connectivity-dependant addresses". [The politically-focussed continue to call them "provider dependent", but I prefer to use a term which bring the underlying technical point to the fore.] And the viewpoint which preferred user ease over routing viability lost that one too. > My objection is that the alternative (shoving the complexity to the end > systems) is much worse because: > as evidenced by worm attacks..., the end systems are the worst managed > pieces in the whole puzzle run by users who don't (& I'd say shouldn't > be expected to) understand the workings of the network; predicating > routing-type functionality on that platform is asking for trouble See comments above. Also, DoS attacks are causing problems for end-system based congestion control, but we're not proposing getting rid of end-system based congestion control because of it. > there are at least 3 (4? 5?) orders of magnitude more end systems than > there are routers, so embedding significant pieces of networking > functionality in end systems greatly increases the likelihood of > trouble & even more greatly decreases the chance of consistent > operation over time If this argument was valid, it would equally apply to congestion control. Clearly, it doesn't, so there's something wrong with it. > Consider the current difficulty in deploying changes to other > technologies due to system-level inertia ... Moving routing-type burden > to the end systems creates such inertia for basic packet delivery, > making the network as a whole even less upgradable than it is now. On the contrary - if we had a decent routing architecture, one in which path selection had been moved into the end-systems (which I concede we don't, efforts to the contrary over the last 15 years notwithstanding) *as it ought to be*, a lot of routing functionality problems we are suffering with would be far easier to solve *because we'd have a lot more flexibility, and the ability to easily upgrade path selection algorithms*. Path selection is basically *not* upgradeable *at all* at the moment precisely *because* the current system does centralize it in the routers. > I advocate keeping the end systems as simple as possible & dealing with > the routing support required to make multi-homing work close to the way > it works for IPv4. Lots of people would disagree with your claim that it "works" in IPv4. And as for simplicity, you can maximize simplicity by using a dial phone. Noel From owner-multi6@ops.ietf.org Fri Jan 9 16:48:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18472 for ; Fri, 9 Jan 2004 16:48:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af4U2-000FYb-Ie for multi6-data@psg.com; Fri, 09 Jan 2004 21:47:58 +0000 Received: from [198.137.194.222] (helo=challah.msrl.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af4Tq-000FVl-HW for multi6@ops.ietf.org; Fri, 09 Jan 2004 21:47:46 +0000 Received: (qmail 23385 invoked by uid 1021); 9 Jan 2004 21:47:44 -0000 Date: Fri, 9 Jan 2004 21:47:44 +0000 From: vijay gill To: Tony Li Cc: Noel Chiappa , multi6@ops.ietf.org Subject: Re: Draft of updated WG charter Message-ID: <20040109214744.GC18604@vijaygill.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jan 09, 2004 at 01:37:24PM -0800, Tony Li wrote: > > > Well, then I would pose to you the obvious question: what is > it that you want multihoming to do? If the end host behavior > does not change, then all you are left with changing is the > routing subsystem. And the only thing that you can now do > is to declare all multihomed prefixes global or do an absurd > amount of tunneling to repair the topology. For obvious reasons, > I hope we agree that both of those alternatives are even less > pleasant. Tony, if it was an easy answer, we wouldn't be having this discussion. Whatever solution we come up with must somehow account for the realities on the ground. I can see there being multiple methods in use, with people hiding deep inside networks willing to accept the fact that their sessions may not survive rehoming. IFF we can get a solution working as transparently as say, tcp/ip congestion control or dns, then we have a shot I'd think. /vijay From owner-multi6@ops.ietf.org Fri Jan 9 17:31:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24313 for ; Fri, 9 Jan 2004 17:31:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af59U-0000im-3t for multi6-data@psg.com; Fri, 09 Jan 2004 22:30:48 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af59F-0000g0-1S for multi6@ops.ietf.org; Fri, 09 Jan 2004 22:30:33 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 1Af59D-0008Hi-00; Fri, 09 Jan 2004 16:30:31 -0600 Date: Fri, 9 Jan 2004 16:30:31 -0600 (CST) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: Noel Chiappa cc: multi6@ops.ietf.org Subject: Re: Draft of updated WG charter In-Reply-To: <20040109214320.DABAA872DE@mercury.lcs.mit.edu> Message-ID: References: <20040109214320.DABAA872DE@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 9 Jan 2004, Noel Chiappa wrote: > > I'll go further out on that limb & say that any multi-homing solution > > which requires substantially more intelligence in end systems than is > > currently required for multi-homed IPv4 is bound to fail .. > > I've heard this argument before, and I'm sorry but it's totally incorrect. > If your basic concept (smart network, stupid endsystems) was true, we'd never > have made the jump from NCP to TCP - because in that jump, congestion > avoidance functionality was moved from the network to the end-systems - and > trust me, congestion avoidance is a much more complex technical problem than > path selection. I'm not sure I accept the analogy: o IP source address selection... is a layer lower than TCP, so you're making the host responsible for more detailed network functionality o TCP congestion avoidance is end-to-end, so the end systems should be involved; address & path selection are single-end or per-hop, so shouldn't necessarily require end system intelligence > Heck, every day a large cross-section of average humans tackle complex path > selection problems - to get to work. And I'll remind you that half the > population has an IQ of less than 100... Path selection is only part of the multi-homing problem, & perhaps the easier one. In my realm of experience, most end systems have only a single path out, so there is no path selection required. The nastier problem is source & destination address selection. In the case of multiple addresses per host, the host is forced to make the selection but the implications have to be handled in the rest of the network (anti-spoof filtering, routing policy...). > Picking an end-system address is a troublesome problem for this WG only > because the architectural environment in which it is currently operating is > so impoverished. IPv4, for understandable reasons, started out with a > extremely cartoonish routing architecture, one totally unsuited to use in a > global uniqiuitous network. IPv6, for reasons which pass my understanding, > elected not to tackle this problem. However, Rome wasn't built in a day, and > you have to start somewhere. You lost me there, but then, I've never been to Rome. ;^) > > This is really the heart of the IPv6 scalability issue. I've never > > understood the argument that multi-homing for IPv6 ought not be done > > the way it's done for IPv4 (single address per end system, multi-path > > routing) on the basis that the network can't tolerate the increase in > > routing table size/complexity. > > This argument is done and over with. The proposed WG charter correctly > captures the rough consensus worked out on this WG mailing list a long time > ago. Bummer. > Also, if you think about it a little bit, this is exactly the same issue as > "why do people have to have connectivity-dependant addresses". [The > politically-focussed continue to call them "provider dependent", but I > prefer to use a term which bring the underlying technical point to the > fore.] And the viewpoint which preferred user ease over routing viability > lost that one too. I like the "connectivity-dependent" term. > > My objection is that the alternative (shoving the complexity to the end > > systems) is much worse because: > > as evidenced by worm attacks..., the end systems are the worst managed > > pieces in the whole puzzle run by users who don't (& I'd say shouldn't > > be expected to) understand the workings of the network; predicating > > routing-type functionality on that platform is asking for trouble > > See comments above. Also, DoS attacks are causing problems for end-system > based congestion control, but we're not proposing getting rid of end-system > based congestion control because of it. > > > there are at least 3 (4? 5?) orders of magnitude more end systems than > > there are routers, so embedding significant pieces of networking > > functionality in end systems greatly increases the likelihood of > > trouble & even more greatly decreases the chance of consistent > > operation over time > > If this argument was valid, it would equally apply to congestion control. > Clearly, it doesn't, so there's something wrong with it. See end-to-end & layer comments above. > > Consider the current difficulty in deploying changes to other > > technologies due to system-level inertia ... Moving routing-type burden > > to the end systems creates such inertia for basic packet delivery, > > making the network as a whole even less upgradable than it is now. > > On the contrary - if we had a decent routing architecture, one in which > path selection had been moved into the end-systems (which I concede we > don't, efforts to the contrary over the last 15 years notwithstanding) *as > it ought to be*, a lot of routing functionality problems we are suffering > with would be far easier to solve *because we'd have a lot more > flexibility, and the ability to easily upgrade path selection algorithms*. > > Path selection is basically *not* upgradeable *at all* at the moment > precisely *because* the current system does centralize it in the routers. As I said, I don't think path selection is a big issue for the end systems. It's address selection, which doesn't exist for most end systems for IPv4. It's a new thing which IPv6 brings which the end systems are not up to dealing with in a sustainable way. > > I advocate keeping the end systems as simple as possible & dealing with > > the routing support required to make multi-homing work close to the way > > it works for IPv4. > > Lots of people would disagree with your claim that it "works" in IPv4. And as > for simplicity, you can maximize simplicity by using a dial phone. Yeah, I figured I'd get that answer. IPv4 works for my net, though, & it's a bit more complicated than a dial phone. I'm not claiming that end systems should be completely stupid & the network should do everything. We might just disagree on where the functionality dividing line should be. I think address selection & path selection shouldn't be on the end system side of the line, so an architecture which causes every end system in every multi-homed network to do those jobs seems broken to me. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Fri Jan 9 17:32:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24374 for ; Fri, 9 Jan 2004 17:31:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af5AM-0000x8-0f for multi6-data@psg.com; Fri, 09 Jan 2004 22:31:42 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af5A9-0000qL-M0 for multi6@ops.ietf.org; Fri, 09 Jan 2004 22:31:29 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i09MVGZN031076; Fri, 9 Jan 2004 23:31:16 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <20040109173958.GA2042@vijaygill.com> References: <20040109135818.58C73872D0@mercury.lcs.mit.edu> <20040109173958.GA2042@vijaygill.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8EE038EC-42F3-11D8-815B-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Draft of updated WG charter Date: Fri, 9 Jan 2004 23:31:24 +0100 To: vijay gill X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9-jan-04, at 18:39, vijay gill wrote: > Significant amount of users that are multihomed have a setup that > accepts defaults from two providers, and anounces their blocks to > both upstreams. They receive no more information than the fact > that their connection is up. No routing tables, no prefixes, just > a quadzero. That's not very smart. > The end user system is often nat'd, and run through a stateful > firewall and all the information _they_ have is an ip address > of the gateway via dhcp. > Any end-host updating solution must work through this gobbledegook. NAT in IPv6 is of course unacceptable. Firewalls also have the potential to be harmful. Having said this, I think we should recognize that the need to keep end systems simple is a legitimate one. That's why I think any non-router solutions should be implementable in middleboxes. This allows both the smart host, dumb network world view by running the multihoming solution on the hosts themselves, and the dumb host, smart network approach by having "the network" (= middleboxes) handle multihoming. From owner-multi6@ops.ietf.org Fri Jan 9 17:49:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25472 for ; Fri, 9 Jan 2004 17:49:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af5Qt-0005pe-5Y for multi6-data@psg.com; Fri, 09 Jan 2004 22:48:47 +0000 Received: from [198.137.194.222] (helo=challah.msrl.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af5Qg-0005lZ-V3 for multi6@ops.ietf.org; Fri, 09 Jan 2004 22:48:35 +0000 Received: (qmail 28220 invoked by uid 1021); 9 Jan 2004 22:48:34 -0000 Date: Fri, 9 Jan 2004 22:48:34 +0000 From: vijay gill To: Iljitsch van Beijnum Cc: Multi6 List Subject: Re: Draft of updated WG charter Message-ID: <20040109224834.GD18604@vijaygill.com> References: <20040109135818.58C73872D0@mercury.lcs.mit.edu> <20040109173958.GA2042@vijaygill.com> <8EE038EC-42F3-11D8-815B-000A95CD987A@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8EE038EC-42F3-11D8-815B-000A95CD987A@muada.com> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jan 09, 2004 at 11:31:24PM +0100, Iljitsch van Beijnum wrote: > On 9-jan-04, at 18:39, vijay gill wrote: > > >Significant amount of users that are multihomed have a setup that > >accepts defaults from two providers, and anounces their blocks to > >both upstreams. They receive no more information than the fact > >that their connection is up. No routing tables, no prefixes, just > >a quadzero. > > That's not very smart. Telling customers that they must spend several thousands of dollars extra in capital so the IETF thinks they are smart, is not going to win me much business. > NAT in IPv6 is of course unacceptable. Firewalls also have the > potential to be harmful. So far, it doesn't appear to have stopped promising local enterpises from deploying large amounts of firewalls. We must be on guard against this sort of thinking. Real world meets powerpoints and wins. Every time. /vijay From owner-multi6@ops.ietf.org Fri Jan 9 18:32:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28883 for ; Fri, 9 Jan 2004 18:32:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af66b-000HLJ-Tg for multi6-data@psg.com; Fri, 09 Jan 2004 23:31:53 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af668-000HAl-Gy for multi6@ops.ietf.org; Fri, 09 Jan 2004 23:31:24 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i09Ncrc08226; Fri, 9 Jan 2004 15:38:53 -0800 From: Dave Crocker To: , vijay gill CC: Multi6 X-Mailer: PocoMail 3.03 (1740) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Date: Fri, 9 Jan 2004 15:31:09 -0800 Message-ID: <20041915319.419406@bbprime> In-Reply-To: Subject: Re: Re: Draft of updated WG charter Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jay, > On Fri, 9 Jan 2004, vijay gill wrote: > > Routing update validation should be orthogonal to the multihoming > > solution. Also, I am going out on a limb here and say that any > > m-homing solution that requires end-host updates is a non-starter > > from the get-go. > > I'll go further out on that limb & say that any multi-homing solution which > requires substantially more intelligence in end systems than is currently > required for multi-homed IPv4 is bound to fail, even if you somehow get it > deployed. These two forays into limb-walking seem important enough to warrant explicit descriptions of their baseline references. If I missed these on the list, please point me to them. For example, by "end host updates" do you mean that end hosts should hold no state about multihoming but that, instead, it must be done entirely in the routing infrastructure? This is not a small point. There is a line of thinking which suggests that the routing/router infrastructure should not be changed at all -- the basic packet transfer service works too well to mess up -- so that multihoming is strictly a value-added function done strictly in the end hosts. (Small concession: organization gateway routers, for site multihoming, are certainly distinct from end hosts, but they are also distinct from the general infrastructure. Yet they are a good candidate for implementing multihoming. And what is the summary description of the intelligence currently required for v4 multihoming? > This is really the heart of the IPv6 scalability issue. I've never > understood the argument that multi-homing for IPv6 ought not be done the > way it's done for IPv4 (single address per end system, multi-path routing) on > the basis that the network can't tolerate the increase in routing table > size/complexity. Well, one argument is that it requires an entirely new type of addressing, since pure topology no longer dictates the address. And that level of change to the infrastructure is one worth trying to avoid except under extreme duress. > My objection is that the alternative (shoving the > complexity to the end systems) is much worse because: > o as evidenced by worm attacks..., the end systems are the worst managed > pieces in the whole puzzle run by users who don't (& I'd say shouldn't > be expected to) understand the workings of the network; predicating > routing-type functionality on that platform is asking for trouble It depends on the nature and degree of the routing work done by the end host, and how much administration is required for it. > o there are at least 3 (4? 5?) orders of magnitude more end systems than > there are routers, so embedding significant pieces of networking > functionality in end systems greatly increases the likelihood of > trouble And requiring the infrastructure to change before a function is useful tends to require 3 (4? 5?) orders of magnitude more delay. > I advocate keeping the end systems as simple as possible & dealing with the > routing support required to make multi-homing work close to the way it > works > for IPv4. Hmmm. Simple end system components, complex network components. Isn't that the phone system approach, and rather pointedly divergent from the historical Internet approach? d/ -- Dave Crocker Brandenburg InternetWorking From owner-multi6@ops.ietf.org Fri Jan 9 18:36:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29047 for ; Fri, 9 Jan 2004 18:36:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af6AG-000IIo-0k for multi6-data@psg.com; Fri, 09 Jan 2004 23:35:40 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af6A3-000IDc-1E for multi6@ops.ietf.org; Fri, 09 Jan 2004 23:35:27 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i09NZGZN031943; Sat, 10 Jan 2004 00:35:17 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <20040109224834.GD18604@vijaygill.com> References: <20040109135818.58C73872D0@mercury.lcs.mit.edu> <20040109173958.GA2042@vijaygill.com> <8EE038EC-42F3-11D8-815B-000A95CD987A@muada.com> <20040109224834.GD18604@vijaygill.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7FF18EC5-42FC-11D8-815B-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Draft of updated WG charter Date: Sat, 10 Jan 2004 00:35:25 +0100 To: vijay gill X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9-jan-04, at 23:48, vijay gill wrote: >>> Significant amount of users that are multihomed have a setup that >>> accepts defaults from two providers, and anounces their blocks to >>> both upstreams. They receive no more information than the fact >>> that their connection is up. No routing tables, no prefixes, just >>> a quadzero. >> That's not very smart. > Telling customers that they must spend several thousands of dollars > extra in capital so the IETF thinks they are smart, is not going to > win me much business. If a customer of mine were to consider such a setup I would explain to them that this way, they're not protecting themselves against a large class of potential failures. Maybe two views of the full 130000 entry global routing table is too much, but certainly just two defaults is too little. There is middle ground here. >> NAT in IPv6 is of course unacceptable. Firewalls also have the >> potential to be harmful. > So far, it doesn't appear to have stopped promising local enterpises > from deploying large amounts of firewalls. > We must be on guard against this sort of thinking. Real world meets > powerpoints and wins. Every time. Another form of dangerous thinking is that just because a lot of people buy a certain product that provides certain functionality in a certain way, we must automatically support this particular method of providing said functionality in the future. Getting rid of old stuff is just as important as implementing new stuff if we want to make progress. From owner-multi6@ops.ietf.org Fri Jan 9 18:47:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29555 for ; Fri, 9 Jan 2004 18:47:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af6LN-000LlE-HE for multi6-data@psg.com; Fri, 09 Jan 2004 23:47:09 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af6LB-000Lks-Aq for multi6@ops.ietf.org; Fri, 09 Jan 2004 23:46:57 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i09NkiZN032102; Sat, 10 Jan 2004 00:46:46 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <20040109214320.DABAA872DE@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <19EF589C-42FE-11D8-815B-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Draft of updated WG charter Date: Sat, 10 Jan 2004 00:46:53 +0100 To: Jay Ford X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9-jan-04, at 23:30, Jay Ford wrote: > Path selection is only part of the multi-homing problem, & perhaps the > easier one. In my realm of experience, most end systems have only a > single path out, so there is no path selection required. > The nastier problem is source & destination address selection. In the > case > of multiple addresses per host, the host is forced to make the > selection but > the implications have to be handled in the rest of the network > (anti-spoof > filtering, routing policy...). I'm not sure what you mean by "path" if you say that a host only has one. I think for the purpose of discussing multiaddress multihoming, a good definition of a path would be a combination of source and destination addresses. The good part is that as soon as we implement mechanisms that allow transport sessions to jump addresses, the address selection problem isn't really a huge deal anymore: if you find yourself using unfortunate addresses, you simply jump to something more suitable. > I'm not claiming that end systems should be completely stupid & the > network > should do everything. We might just disagree on where the > functionality > dividing line should be. I think address selection & path selection > shouldn't be on the end system side of the line, so an architecture > which > causes every end system in every multi-homed network to do those jobs > seems > broken to me. So what about having special boxes that sit between the hosts and the routers and handle multihoming? Obviously anything that can be implemented in an external box can also be integrated into a host when desired, so unless the drawbacks of allowing this functionality to be implemented in an external box are huge, this shouldn't take anything away from the people who actually like their hosts to handle this autonomously. From owner-multi6@ops.ietf.org Fri Jan 9 19:27:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01324 for ; Fri, 9 Jan 2004 19:27:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af6xO-0007VW-GU for multi6-data@psg.com; Sat, 10 Jan 2004 00:26:26 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af6xB-0007V1-UV for multi6@ops.ietf.org; Sat, 10 Jan 2004 00:26:14 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i0A0Xpc11363 for ; Fri, 9 Jan 2004 16:33:51 -0800 From: Dave Crocker To: X-Mailer: PocoMail 3.03 (1740) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Date: Fri, 9 Jan 2004 16:26:06 -0800 Message-ID: <20041916266.885810@bbprime> In-Reply-To: <5.1.0.14.2.20040109052803.0422c2c8@ms101.mail1.com> Subject: Re: Consensus on identifier/locator split? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, > > Do we have consensus about splitting > > the address into locators and identifiers? Note that > > I'm NOT asking about specifics, like "how big", "what > > mappings exist", "is it secure", etc. Do we agree that > > we want to go down this path? > > Is it good enough to say that I think we should explore > options in this area? ... > But, I do think that this solution space is promising > enough to be worth investigating further. Is that close > enough? "Splitting the address"? No. Carefully distinguishing the role of identifier from the role of locator? Yes. My point is that there are quite a number of ways to satisfy that distinction and only some of them involve messing with IP Addresses. For others, the public uses of IP Addresses are mostly restricted to locator. -- Dave Crocker Brandenburg InternetWorking From owner-multi6@ops.ietf.org Fri Jan 9 20:18:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03864 for ; Fri, 9 Jan 2004 20:18:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af7lI-000Q0l-HN for multi6-data@psg.com; Sat, 10 Jan 2004 01:18:00 +0000 Received: from [134.193.143.167] (helo=kc-msxproto1.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af7l6-000Pm5-IT for multi6@ops.ietf.org; Sat, 10 Jan 2004 01:17:48 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Jan 2004 19:17:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Draft of updated WG charter Date: Fri, 9 Jan 2004 19:17:47 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108212@KC-MAIL4.kc.umkc.edu> Thread-Topic: Draft of updated WG charter Thread-Index: AcPXAU6i1Wz4tfZsTXe5bxUh7hKxrAAFBKRU From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Jay Ford" , "Noel Chiappa" Cc: X-OriginalArrivalTime: 10 Jan 2004 01:17:47.0775 (UTC) FILETIME=[8EDFB0F0:01C3D717] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > I think address selection & path selection shouldn't be on the end=20 > system side of the line, so an architecture which causes every end=20 > system in every multi-homed network to do those jobs seems broken=20 > to me =20 you mean the folks who are selling/using the route control products[1] (which allows to select the first hop of the best route) are stupids?=20 I was of the thought that *provider* selection (or path/address selection) should be done by users and not *providers*.=20 =20 [1] http://www.nanog.org/mtg-0206/smart.html From owner-multi6@ops.ietf.org Fri Jan 9 22:51:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07939 for ; Fri, 9 Jan 2004 22:51:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfA7u-0003o9-5a for multi6-data@psg.com; Sat, 10 Jan 2004 03:49:30 +0000 Received: from [129.186.140.13] (helo=mailhub-3.iastate.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfA7h-0003nu-HH for multi6@ops.ietf.org; Sat, 10 Jan 2004 03:49:17 +0000 Received: from mailout-1.iastate.edu (mailout-1.iastate.edu [129.186.140.1]) by mailhub-3.iastate.edu (8.12.10/8.12.10) with SMTP id i0A3nGI5010128 for ; Fri, 9 Jan 2004 21:49:16 -0600 Received: from netview.ait.iastate.edu(129.186.6.240) by mailout-1.iastate.edu via csmap id 332dc646_4320_11d8_858a_003048290bef_11657; Fri, 09 Jan 2004 21:50:58 -0600 (CST) Received: from localhost (grpjl@localhost) by netview.ait.iastate.edu (8.8.8/8.8.5) with SMTP id VAA30831 for ; Fri, 9 Jan 2004 21:49:16 -0600 (CST) Message-Id: <200401100349.VAA30831@netview.ait.iastate.edu> To: multi6@ops.ietf.org Subject: Re: Draft of updated WG charter Date: Fri, 09 Jan 2004 21:49:16 CST From: Paul Lustgraaf X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > =20 > > I think address selection & path selection shouldn't be on the end=20 > > system side of the line, so an architecture which causes every end=20 > > system in every multi-homed network to do those jobs seems broken=20 > > to me > =20 > you mean the folks who are selling/using the route control products[1] > (which allows to select the first hop of the best route) are stupids?=20 > I was of the thought that *provider* selection (or path/address > selection) should be done by users and not *providers*.=20 > =20 > [1] http://www.nanog.org/mtg-0206/smart.html Those are routers, not end systems. In order to do their job, they need to have routing information. End systems should never have to deal with such information. Any architecture that requires the 20,000+ end systems on my campus to make routing decisions is broken. Path selection is the definition of routing. Address selection is dependent on path selection most of the time. Routers should route. End systems should run applications. Paul Lustgraaf "Change is inevitable. Progress is not." Manager of Network Services Iowa State University Academic Information Technologies grpjl@iastate.edu Ames, IA 50011 515-294-0324 From owner-multi6@ops.ietf.org Sat Jan 10 00:16:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09941 for ; Sat, 10 Jan 2004 00:16:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfBSj-000DWq-MC for multi6-data@psg.com; Sat, 10 Jan 2004 05:15:05 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfBST-000DGc-Iy for multi6@ops.ietf.org; Sat, 10 Jan 2004 05:14:49 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 1AfBSR-0001jd-00; Fri, 09 Jan 2004 23:14:47 -0600 Date: Fri, 9 Jan 2004 23:14:47 -0600 (CST) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: Dave Crocker cc: Multi6 Subject: Re: Re: Draft of updated WG charter In-Reply-To: <20041915319.419406@bbprime> Message-ID: References: <20041915319.419406@bbprime> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 9 Jan 2004, Dave Crocker wrote: > These two forays into limb-walking seem important enough to warrant explicit > descriptions of their baseline references. If I missed these on the list, > please point me to them. > > For example, by "end host updates" do you mean that end hosts should hold no > state about multihoming but that, instead, it must be done entirely in the > routing infrastructure? Pretty much. If hosts have a single address (as most do in IPv4), they don't need to even know that they're multi-homed. I view *sites* as multi-homed, not hosts. Therefore, I view the problem of how to make multi-homing work at the site (usually AS) boundary with other entities (ASes), not how to make the individual hosts do it. (Granted, some individual hosts are multi-homed, within a single site or even among multiple sites, but I suspect that they are the exception & could be handled as one-off cases. Such hosts already have to be aware of networking to choose the next IPv4 hop, so they could choose the next IPv6 hop in a similar fashion. Regardless, they are not the vast majority which are single-homed within a single site.) > This is not a small point. There is a line of thinking which suggests that the > routing/router infrastructure should not be changed at all -- the basic packet > transfer service works too well to mess up -- so that multihoming is strictly a > value-added function done strictly in the end hosts. (Small concession: > organization gateway routers, for site multihoming, are certainly distinct from > end hosts, but they are also distinct from the general infrastructure. Yet they > are a good candidate for implementing multihoming. I guess I'm closer to the other end of the spectrum. The routing infrastructure should deal with most of the burden of getting packets to destinations as efficiently as possible. The hosts shouldn't be expected to do that job, because they are ill-equipped to do so. They should focus on layer 4 & up. > And what is the summary description of the intelligence currently required for > v4 multihoming? In the common case where the site (not the host) is multi-homed, the host needs to know very little. It usually has a single source address & a single next hop router to which it sends all packets. The destination address is chosen by some means (DNS...), but the host doesn't try to figure out which destination address is "best". It also doesn't have to choose a source address because it has only 1. > > This is really the heart of the IPv6 scalability issue. I've never > > understood the argument that multi-homing for IPv6 ought not be done the > > way it's done for IPv4 (single address per end system, multi-path routing) on > > the basis that the network can't tolerate the increase in routing table > > size/complexity. > > Well, one argument is that it requires an entirely new type of addressing, since > pure topology no longer dictates the address. And that level of change to the > infrastructure is one worth trying to avoid except under extreme duress. For many sites, topology doesn't dictate the address in IPv4. I have 2 /16s which I announce to those with whom I connect. The topology is dictated by the links & the routing announced on them, not by the numeric value of my addresses. I realize that cranking the dial up from 32 to 128 raises serious concerns about the ability of the routing infrastructure to handle non-connectivity-dependent or non-provider-based addressing. However the discussions I've seen about IPv6 address usage lead me to believe that there won't be anywhere near 2^128 routed prefixes. With common prefixes of /64 & shorter for "sites" (university campus nets, corporate nets, ISP clouds...) & the loss of a few "formatting" bits, we're probably talking 2^60 as an upper bound. I'm not saying that 2^60 isn't a huge number, but it's closer to surmountable than 2^128, and with gradual roll out we probably wouldn't see more than a small fraction of those for a long time. I'd prefer to try to tackle routing for 2^60 prefixes than to predicate the operation of the IPv6 Internet on how well hosts choose source/destination addresses => paths through the network. > > My objection is that the alternative (shoving the > > complexity to the end systems) is much worse because: > > o as evidenced by worm attacks..., the end systems are the worst managed > > pieces in the whole puzzle run by users who don't (& I'd say shouldn't > > be expected to) understand the workings of the network; predicating > > routing-type functionality on that platform is asking for trouble > > It depends on the nature and degree of the routing work done by the end host, > and how much administration is required for it. Based on what I've seen of how poorly hosts are defaulted & administered, any increase in complexity & responsibility placed there is a bad thing. > > o there are at least 3 (4? 5?) orders of magnitude more end systems than > > there are routers, so embedding significant pieces of networking > > functionality in end systems greatly increases the likelihood of > > trouble > > And requiring the infrastructure to change before a function is useful tends to > require 3 (4? 5?) orders of magnitude more delay. Really? It seems that I could upgrade my O(10) routers before any significant fraction of the O(10k) hosts on my campus could get upgraded. > > I advocate keeping the end systems as simple as possible & dealing with the > > routing support required to make multi-homing work close to the way it > > works > > for IPv4. > > Hmmm. Simple end system components, complex network components. > > Isn't that the phone system approach, and rather pointedly divergent from the > historical Internet approach? I think it depends on where you divide the responsibility. My division is that the complexity of layer 3 (IPv4 & IPv6) ought to be in the network, & the complexity of layer 4 & up ought to be in the hosts. Sliding that line down to make the hosts responsible for layer 3 seems like a recipe for disaster. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Sat Jan 10 00:40:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10697 for ; Sat, 10 Jan 2004 00:40:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfBqY-000Nip-ED for multi6-data@psg.com; Sat, 10 Jan 2004 05:39:42 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfBqD-000Ngf-HT for multi6@ops.ietf.org; Sat, 10 Jan 2004 05:39:21 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 1AfBqB-0002TC-00; Fri, 09 Jan 2004 23:39:19 -0600 Date: Fri, 9 Jan 2004 23:39:19 -0600 (CST) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: Iljitsch van Beijnum cc: Multi6 List Subject: Re: Draft of updated WG charter In-Reply-To: <19EF589C-42FE-11D8-815B-000A95CD987A@muada.com> Message-ID: References: <20040109214320.DABAA872DE@mercury.lcs.mit.edu> <19EF589C-42FE-11D8-815B-000A95CD987A@muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 10 Jan 2004, Iljitsch van Beijnum wrote: > > Path selection is only part of the multi-homing problem, & perhaps the > > easier one. In my realm of experience, most end systems have only a > > single path out, so there is no path selection required. > > > The nastier problem is source & destination address selection. In the > > case of multiple addresses per host, the host is forced to make the > > selection but the implications have to be handled in the rest of the > > network (anti-spoof filtering, routing policy...). > > I'm not sure what you mean by "path" if you say that a host only has > one. I think for the purpose of discussing multiaddress multihoming, a > good definition of a path would be a combination of source and > destination addresses. From the host perspective, I mean "next hop", which is usually a single router to which all packets get sent. I shudder at the notion of host address selection dictating an end-to-end path. > The good part is that as soon as we implement mechanisms that allow > transport sessions to jump addresses, the address selection problem > isn't really a huge deal anymore: if you find yourself using > unfortunate addresses, you simply jump to something more suitable. More shuddering... > > I'm not claiming that end systems should be completely stupid & the > > network should do everything. We might just disagree on where the > > functionality dividing line should be. I think address selection & path > > selection shouldn't be on the end system side of the line, so an > > architecture which causes every end system in every multi-homed network > > to do those jobs seems broken to me. > > So what about having special boxes that sit between the hosts and the > routers and handle multihoming? Obviously anything that can be > implemented in an external box can also be integrated into a host when > desired, so unless the drawbacks of allowing this functionality to be > implemented in an external box are huge, this shouldn't take anything > away from the people who actually like their hosts to handle this > autonomously. That sounds dangerously close to NAT, which I think most people would like to avoid & eradicate. For me, almost the entire IPv6 thing boils down to the issue of hosts having multiple addresses. That decision precipitated the rest of this mess. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Sat Jan 10 00:53:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11193 for ; Sat, 10 Jan 2004 00:53:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfC3J-0003go-SW for multi6-data@psg.com; Sat, 10 Jan 2004 05:52:53 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfC37-0003dO-98 for multi6@ops.ietf.org; Sat, 10 Jan 2004 05:52:41 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 1AfC36-0002TQ-00; Fri, 09 Jan 2004 23:52:40 -0600 Date: Fri, 9 Jan 2004 23:52:40 -0600 (CST) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: "Ayyasamy, Senthilkumar (UMKC-Student)" cc: multi6@ops.ietf.org Subject: RE: Draft of updated WG charter In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B01108212@KC-MAIL4.kc.umkc.edu> Message-ID: References: <5EF7D95E17BDAD4A968C812E5ABC390B01108212@KC-MAIL4.kc.umkc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 9 Jan 2004, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > > I think address selection & path selection shouldn't be on the end > > system side of the line, so an architecture which causes every end > > system in every multi-homed network to do those jobs seems broken > > to me > > you mean the folks who are selling/using the route control products[1] > (which allows to select the first hop of the best route) are stupids? > I was of the thought that *provider* selection (or path/address > selection) should be done by users and not *providers*. The meaning of "user" & "provider" apparently vary with context. Here's the structure in my piece of the net: host: end system with associated end user(s); knowledge of general Internet: almost none core routers: routers inside my AS which directly connect to user nets & to border routers; knowledge of general Internet: subset of whole net, subject to border routers border routers: routers at boundary of my AS, talking to core routers inside & other ASes outside; knowledge of general Internet: as much as my BGP peers tell them modulo the policy I impose based on what I know about links, providers... The hosts & associated end users are not up to the job of doing anything resembling intelligent path selection. A scheme in which the source/destination addresses selected by a host dictates a path seems unlikely to work well. The core routers know enough to make a good choice among the border routers. The border routers know the correct next hop for all destinations. This is a good split of complexity & responsibility, with the hosts not having to do any of it. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Sat Jan 10 01:04:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11459 for ; Sat, 10 Jan 2004 01:04:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfCEA-0008gX-N4 for multi6-data@psg.com; Sat, 10 Jan 2004 06:04:06 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfCDx-0008ft-SD for multi6@ops.ietf.org; Sat, 10 Jan 2004 06:03:53 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 1AfCDx-0002u2-00; Sat, 10 Jan 2004 00:03:53 -0600 Date: Sat, 10 Jan 2004 00:03:53 -0600 (CST) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: "Ayyasamy, Senthilkumar (UMKC-Student)" cc: Multi6 Subject: RE: Draft of updated WG charter In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B01108213@KC-MAIL4.kc.umkc.edu> Message-ID: References: <5EF7D95E17BDAD4A968C812E5ABC390B01108213@KC-MAIL4.kc.umkc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 9 Jan 2004, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > >I'll go further out on that limb & say that any multi-homing solution which > >requires substantially more intelligence in end systems than is currently > >required for multi-homed IPv4 is bound to fail, even if you somehow get it > >deployed. > > disagree. For example, the way I use multi-homing from school is to have a > f5 system which load balance between the main connection (morenet, Internet2) > and my wireless connection. I also know that the whole LCS building at MIT > has a web proxy system which allows to do a kind of Load sharing between > MIT and a 100Mbps cogent connection. Given this is a *site* multi-homing > WG, it is a known fact that many enterprise networks use load balancing > products for connecting to multiple providers. I can even argue that > end-site can achieve a equivalent reliability by load sharing among multiple > inexpensive broadband connections in addition to a single dedicated line. > In short, we are moving from a phase where availability is increased not > only by network level redundancy but also end site level redundancy. Fine. Each site has a single prefix. The links & routing establish the topology, even with load balancers, traffic directors.... No problem. > > o as evidenced by worm attacks..., the end systems are the worst managed > > pieces in the whole puzzle run by users who don't (& I'd say shouldn't > > be expected to) understand the workings of the network; predicating > > routing-type functionality on that platform is asking for trouble > > come on... who is accountable for the multiple failures, accidental/stupid > misconfigurations, black lists, unwanted rate limitations(have you read the > recent IAB concern regarding port filtering.)? Ultimately: the managers of the hosts, which are mostly end users who aren't up to the job. The filtering... was only put in place to protect the broken systems because they couldn't deal with it themselves. This is further justification for not laying more networking responsibility on the hosts. > > o there are at least 3 (4? 5?) orders of magnitude more end systems than > > there are routers, so embedding significant pieces of networking > > functionality in end systems greatly increases the likelihood of > > trouble & even more greatly decreases the chance of consistent > > operation over time > > on the other hand, who has the incentive to deploy? It is only the > end-sites. So, we have: hosts: large number; direct incentive, but no will or ability routers: small number; indirect incentive & real ability I'll take the routers. > In short, if we go by your suggestion, we can close this WG and standardize > a simple BCP in idr WG (which will detail how IPv4 site-multihoming is > applicable for IPv6.) Cool. That was easy. :^) > I think this WG is not taking that path. Again, bummer. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Sat Jan 10 01:08:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11568 for ; Sat, 10 Jan 2004 01:08:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfCHf-000Abw-Ub for multi6-data@psg.com; Sat, 10 Jan 2004 06:07:43 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfCHT-000AbZ-HB for multi6@ops.ietf.org; Sat, 10 Jan 2004 06:07:31 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 1AfCHS-0002u7-00; Sat, 10 Jan 2004 00:07:30 -0600 Date: Sat, 10 Jan 2004 00:07:30 -0600 (CST) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: Paul Lustgraaf cc: multi6@ops.ietf.org Subject: Re: Draft of updated WG charter In-Reply-To: <200401100349.VAA30831@netview.ait.iastate.edu> Message-ID: References: <200401100349.VAA30831@netview.ait.iastate.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 9 Jan 2004, Paul Lustgraaf wrote: > > > I think address selection & path selection shouldn't be on the end > > > system side of the line, so an architecture which causes every end > > > system in every multi-homed network to do those jobs seems broken > > > to me > > > > you mean the folks who are selling/using the route control products[1] > > (which allows to select the first hop of the best route) are stupids? > > I was of the thought that *provider* selection (or path/address > > selection) should be done by users and not *providers*. > > Those are routers, not end systems. In order to do their job, they > need to have routing information. End systems should never have to > deal with such information. Any architecture that requires the 20,000+ > end systems on my campus to make routing decisions is broken. Yep. > Path selection is the definition of routing. Address selection is > dependent on path selection most of the time. Routers should route. > End systems should run applications. You left out layers 4-6, but they still reside in the host. How about: Routers should do layer 3. Hosts should do layers 4 & up. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From owner-multi6@ops.ietf.org Sat Jan 10 04:58:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00899 for ; Sat, 10 Jan 2004 04:58:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfFrH-000MsU-Ka for multi6-data@psg.com; Sat, 10 Jan 2004 09:56:43 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfFr5-000MqV-62 for multi6@ops.ietf.org; Sat, 10 Jan 2004 09:56:31 +0000 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id i0AC23Ot038549; Sat, 10 Jan 2004 04:02:03 -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 i0A9u8YB008434; Sat, 10 Jan 2004 01:56:09 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Draft of updated WG charter Date: Sat, 10 Jan 2004 01:56:08 -0800 Message-ID: Thread-Topic: Draft of updated WG charter Thread-Index: AcPXQMZbjFPoHwxySOKOg6nRw6r8hQAHuwIQ From: "Tony Li" To: "Jay Ford" , "Paul Lustgraaf" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I find myself becoming rapidly depressed by this conversation. I was under the impression that we had a requirements document already on the table. I thought that we were a good bit past this. I'm going to tune out now. Please wake me if folks decide that they actually want to fix this problem. Tony From owner-multi6@ops.ietf.org Sat Jan 10 08:34:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04812 for ; Sat, 10 Jan 2004 08:34:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfJCG-000Kk4-4V for multi6-data@psg.com; Sat, 10 Jan 2004 13:30:36 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfJC3-000KeQ-Mb for multi6@ops.ietf.org; Sat, 10 Jan 2004 13:30:23 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0ADUCZN043201; Sat, 10 Jan 2004 14:30:13 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <5EF7D95E17BDAD4A968C812E5ABC390B01108212@KC-MAIL4.kc.umkc.edu> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <238A4278-4371-11D8-815B-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Draft of updated WG charter Date: Sat, 10 Jan 2004 14:30:21 +0100 To: Jay Ford X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 10-jan-04, at 6:52, Jay Ford wrote: > The hosts & associated end users are not up to the job of doing > anything > resembling intelligent path selection. A scheme in which the > source/destination addresses selected by a host dictates a path seems > unlikely to work well. > The core routers know enough to make a good choice among the border > routers. > The border routers know the correct next hop for all destinations. I'm sorry, but I have to disagree. The only thing that border routers know, is that _if_ something is reachable, what the next hop is. Whether or not something is indeed reachable is burried beneath layers of aggregation. Even if we can make the information for all sites available without aggregation (which I don't think we can, re the need for route flap dampening in the late 1990s when we already had aggregation), there is no way we can make routers keep track of the reachability status of individual hosts. However, it shouldn't be too hard to make hosts keep track of the reachability status of (the different addresses of) the hosts they're actively communicating with. TCP already does this in single-address fashion for the purpose of congestion control. > This is a good split of complexity & responsibility, with the hosts not > having to do any of it. I'm sure this model can accommodate some situations, such as carefully managed networks. However, many networks aren't managed to any noticeable degree (home networks), or the network only consists of a number of hosts that happen to be in each other's vicinity for a while. In these cases, hosts must step up to the challenge. It occurs to me that IPsec tunneling in VPN boxes vs running SSL on the end-hosts has many similarities to what we're discussing here. Is there anything we can learn here? From owner-multi6@ops.ietf.org Sat Jan 10 09:07:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06026 for ; Sat, 10 Jan 2004 09:07:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfJki-000IJQ-Rz for multi6-data@psg.com; Sat, 10 Jan 2004 14:06:12 +0000 Received: from [134.193.143.160] (helo=kc-msxproto3.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfJkW-000IEe-GS for multi6@ops.ietf.org; Sat, 10 Jan 2004 14:06:00 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Sat, 10 Jan 2004 08:05:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: deja vu again... Date: Sat, 10 Jan 2004 08:05:58 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108215@KC-MAIL4.kc.umkc.edu> Thread-Topic: deja vu again... Thread-Index: AcPXPfXvmaqnInwXT1yqwO8aKJpAmwAQ3IKI From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: X-OriginalArrivalTime: 10 Jan 2004 14:05:59.0519 (UTC) FILETIME=[DFB1AEF0:01C3D782] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > The meaning of "user" & "provider" apparently vary with context. > [...] > This is a good split of complexity & responsibility, with the=20 > hosts not having to do any of it. =20 FYI: all end-system LB products has a measurement system which=20 checks for end to end availability. It is either probe-based or have some heuristics to get the topology details.=20 =20 This discussion is a rat-hole; We are not going to agree on anything. The current charter will allow more discussions=20 of this sort. I thought the chairs are of the opinion that=20 all solutions should by submitted by february( I only follow mailining list discussions.) But, I see an updated charter=20 which has no place for solutions.=20 =20 From owner-multi6@ops.ietf.org Sat Jan 10 09:13:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06143 for ; Sat, 10 Jan 2004 09:13:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfJqx-000NC1-9j for multi6-data@psg.com; Sat, 10 Jan 2004 14:12:39 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfJqd-000NAw-Ez for multi6@ops.ietf.org; Sat, 10 Jan 2004 14:12:19 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D3C29872DC; Sat, 10 Jan 2004 09:12:18 -0500 (EST) To: multi6@ops.ietf.org Subject: Re: Draft of updated WG charter Cc: jnc@mercury.lcs.mit.edu Message-Id: <20040110141218.D3C29872DC@mercury.lcs.mit.edu> Date: Sat, 10 Jan 2004 09:12:18 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Paul Lustgraaf > Any architecture that requires the 20,000+ end systems on my campus to > make routing decisions is broken. Why? A large fraction of all the humans on the planet make routing decisions every day (and half of them have IQ's of less than 100 :-). Every end system on your campus includes complex and sophisticated algorithms to do congestion avoidance. Why should routing be treated differently? Noel From owner-multi6@ops.ietf.org Sat Jan 10 09:26:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06283 for ; Sat, 10 Jan 2004 09:26:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfK3y-0005fS-OS for multi6-data@psg.com; Sat, 10 Jan 2004 14:26:06 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfK3n-0005ad-1i for multi6@ops.ietf.org; Sat, 10 Jan 2004 14:25:55 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id ACFF3872DB; Sat, 10 Jan 2004 09:25:54 -0500 (EST) To: multi6@ops.ietf.org Subject: Re: Re: Draft of updated WG charter Cc: jnc@mercury.lcs.mit.edu Message-Id: <20040110142554.ACFF3872DB@mercury.lcs.mit.edu> Date: Sat, 10 Jan 2004 09:25:54 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Jay Ford > If hosts have a single address ... they don't need to even know that > they're multi-homed. > I view *sites* as multi-homed, not hosts. If you handle the issue of scaling the routing overhead by using overlapping naming abstractions, then end-systems have multiple addresses - end of story. All that's left now for us is figuring out how to deal with that. There are some other approaches to handling the routing scaling, but they are even more radical, and require support from an advanced routing architecture that we don't possess yet (e.g. "route fragments" or "topologoy fragments", which require ubiquitous source routing or a Map-Distribution routing architecture). Noel PS: If you didn't understand the "overlapping naming abstractions" stuff, you need to go away and get familiar with that, and why it's the only realistic option from the point of view of the routing part of the problem, before commenting further, since as the above makes plain (I hope), hosts at multi-homed sites having multiple addresses is the absolutely inherent result of that approach. From owner-multi6@ops.ietf.org Sat Jan 10 09:50:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06981 for ; Sat, 10 Jan 2004 09:50:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfKQf-000LAa-Lp for multi6-data@psg.com; Sat, 10 Jan 2004 14:49:33 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfKQT-000KrN-FA for multi6@ops.ietf.org; Sat, 10 Jan 2004 14:49:21 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 07DB7872DB; Sat, 10 Jan 2004 09:49:20 -0500 (EST) To: multi6@ops.ietf.org Subject: RE: Draft of updated WG charter Cc: jnc@mercury.lcs.mit.edu Message-Id: <20040110144920.07DB7872DB@mercury.lcs.mit.edu> Date: Sat, 10 Jan 2004 09:49:20 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Tony Li" > I find myself becoming rapidly depressed by this conversation. I was > under the impression that we had a requirements document already on the > table. I thought that we were a good bit past this. Tony, no need to get bummed - what's going on is the same thing that went on with the introduction of aggregation and connectivity- (a.k.a. provider-) dependent addresses - which is that people poorly understand the roots of the issue in fundamental routing mechanics, and don't yet follow the unavoidable logical path which leads from those to the engineering details they don't like. My sense is that most people who've been here for a while do understand both the roots, and the logical path which they force us down, and as in the latter stages over the debate on portable addresses, it's only a few newcomers (and the terminally clueless :-) who are still trying to go back to the past. Noel From owner-multi6@ops.ietf.org Sat Jan 10 09:57:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07109 for ; Sat, 10 Jan 2004 09:57:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfKYD-0001as-Ei for multi6-data@psg.com; Sat, 10 Jan 2004 14:57:21 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfKY1-0001Gu-Gr for multi6@ops.ietf.org; Sat, 10 Jan 2004 14:57:09 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 156F4872DB; Sat, 10 Jan 2004 09:57:09 -0500 (EST) To: multi6@ops.ietf.org Subject: Re: Draft of updated WG charter Cc: jnc@mercury.lcs.mit.edu Message-Id: <20040110145709.156F4872DB@mercury.lcs.mit.edu> Date: Sat, 10 Jan 2004 09:57:09 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Jay Ford > boils down to the issue of hosts having multiple addresses. That > decision precipitated the rest of this Exactly! An excellent summary, couldn't have put it better myself. Now, all you need to do is understand why multiple addresses are an inevitable consequence of the fact that we can't realistically call for the deployment of an entire new routing architecture as part of the Multi6 solution. Failing that, the only workable approach *within the current routing architecture* is overlapping naming abstractions, which are (looked at from the direction of the hosts, as opposed to from the routing) multiple addresses. Noel From owner-multi6@ops.ietf.org Sat Jan 10 10:20:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08591 for ; Sat, 10 Jan 2004 10:20:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfKtp-000Gnj-Ta for multi6-data@psg.com; Sat, 10 Jan 2004 15:19:41 +0000 Received: from [198.137.194.222] (helo=challah.msrl.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfKtN-000GGk-Sh for multi6@ops.ietf.org; Sat, 10 Jan 2004 15:19:13 +0000 Received: (qmail 22758 invoked by uid 1021); 10 Jan 2004 15:19:12 -0000 Date: Sat, 10 Jan 2004 15:19:12 +0000 From: vijay gill To: Tony Li Cc: Jay Ford , Paul Lustgraaf , multi6@ops.ietf.org Subject: Re: Draft of updated WG charter Message-ID: <20040110151912.GA20460@vijaygill.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, Jan 10, 2004 at 01:56:08AM -0800, Tony Li wrote: > > > I find myself becoming rapidly depressed by this conversation. I was > under the impression that we had a requirements document already on > the table. I thought that we were a good bit past this. > > I'm going to tune out now. Please wake me if folks decide that > they actually want to fix this problem. Tony, I don't think this discussion should be viewed as discouraging, as much as it should be viewed as setting the baseline for the end system reality that any solution must account for. End systems can be changed, but any solution we come up with must be "easy" to set up and work with. /vijay From owner-multi6@ops.ietf.org Sat Jan 10 10:24:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08645 for ; Sat, 10 Jan 2004 10:24:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfKy3-000JKu-2f for multi6-data@psg.com; Sat, 10 Jan 2004 15:24:03 +0000 Received: from [198.137.194.222] (helo=challah.msrl.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfKxr-000JHp-9R for multi6@ops.ietf.org; Sat, 10 Jan 2004 15:23:51 +0000 Received: (qmail 22992 invoked by uid 1021); 10 Jan 2004 15:23:50 -0000 Date: Sat, 10 Jan 2004 15:23:50 +0000 From: vijay gill To: Noel Chiappa Cc: multi6@ops.ietf.org Subject: Re: Draft of updated WG charter Message-ID: <20040110152350.GB20460@vijaygill.com> References: <20040110144920.07DB7872DB@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040110144920.07DB7872DB@mercury.lcs.mit.edu> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, Jan 10, 2004 at 09:49:20AM -0500, Noel Chiappa wrote: > My sense is that most people who've been here for a while do understand both > the roots, and the logical path which they force us down, and as in the > latter stages over the debate on portable addresses, it's only a few > newcomers (and the terminally clueless :-) who are still trying to go back to > the past. We (the terminally clueless) eagerly await deployable solutions that can be transparently rolled out to my desktops. The not-terminally clueless perhaps need to come out with more compelling arguments and less bombast. /vijay From owner-multi6@ops.ietf.org Sat Jan 10 10:36:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08962 for ; Sat, 10 Jan 2004 10:36:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfL8y-00017p-Bd for multi6-data@psg.com; Sat, 10 Jan 2004 15:35:20 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfL8m-0000t5-HP for multi6@ops.ietf.org; Sat, 10 Jan 2004 15:35:08 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1166D872DB; Sat, 10 Jan 2004 10:35:07 -0500 (EST) To: multi6@ops.ietf.org Subject: Re: Draft of updated WG charter\ Cc: jnc@mercury.lcs.mit.edu Message-Id: <20040110153507.1166D872DB@mercury.lcs.mit.edu> Date: Sat, 10 Jan 2004 10:35:07 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: vijay gill > We .. eagerly await deployable solutions that can be transparently > rolled out to my desktops. TANSTAAFL. Multi-homing is done because there's a benefit - more reliability, principally. However, you never get a benefit without a cost - and the cost is more complexity. > perhaps need to come out with more compelling arguments Funny, I thought we spent the last couple of years doing just that - establishing *why* multiple addresses were the only feasible alternative. Noel From owner-multi6@ops.ietf.org Sat Jan 10 11:53:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10316 for ; Sat, 10 Jan 2004 11:53:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfMKs-0005vs-Sv for multi6-data@psg.com; Sat, 10 Jan 2004 16:51:42 +0000 Received: from [198.137.194.222] (helo=challah.msrl.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfMKg-0005eV-Kh for multi6@ops.ietf.org; Sat, 10 Jan 2004 16:51:30 +0000 Received: (qmail 28567 invoked by uid 1021); 10 Jan 2004 16:51:30 -0000 Date: Sat, 10 Jan 2004 16:51:29 +0000 From: vijay gill To: Noel Chiappa Cc: multi6@ops.ietf.org Subject: Re: Draft of updated WG charter Message-ID: <20040110165129.GA28090@vijaygill.com> References: <20040110153507.1166D872DB@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040110153507.1166D872DB@mercury.lcs.mit.edu> User-Agent: Mutt/1.3.28i Organization: vijay gill global logistics X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, Jan 10, 2004 at 10:35:07AM -0500, Noel Chiappa wrote: > > From: vijay gill > > > We .. eagerly await deployable solutions that can be transparently > > rolled out to my desktops. > > TANSTAAFL. > Multi-homing is done because there's a benefit - more reliability, > principally. However, you never get a benefit without a cost - and the cost > is more complexity. Yes. However, see below. > > > perhaps need to come out with more compelling arguments > > Funny, I thought we spent the last couple of years doing just that - > establishing *why* multiple addresses were the only feasible alternative. I do not believe that this is the sticking point. I will reiterate however, that whatever solution is proposed, if it is ever to be widely deployed, the mechanisms to enable it to work must be nearly or at least around the ball-park of transparency as DNS or congestion control. I.e. most people aren't even aware of what is happening underneath the deck so to speak, said he, mixing metaphors. /vijay From owner-multi6@ops.ietf.org Sat Jan 10 15:05:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16215 for ; Sat, 10 Jan 2004 15:05:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfPJp-0005UI-2p for multi6-data@psg.com; Sat, 10 Jan 2004 20:02:49 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfPJX-0005E8-MJ for multi6@ops.ietf.org; Sat, 10 Jan 2004 20:02:31 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i0AKA3c01646; Sat, 10 Jan 2004 12:10:03 -0800 From: Dave Crocker To: CC: Multi6 X-Mailer: PocoMail 3.03 (1740) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Date: Sat, 10 Jan 2004 12:02:18 -0800 Message-ID: <200411012218.733891@bbprime> In-Reply-To: Subject: Re: Re: Re: Draft of updated WG charter Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jay, > I view *sites* as multi-homed, not hosts. Therefore, I view the problem of > how to make multi-homing work at the site (usually AS) boundary with other > entities (ASes), not how to make the individual hosts do it. Certainly your are right about the _placement_ of additional connectivity. However, this does not automatically mean that the mechanism to integrate _use_ of the alternative connections must be implemented at the site gateway. Of course, we need to know the type of multiaddressing use that is desired, to be able to figure out the tradeoffs for where to place the mechanism. In the most simple, failover use of multiple access links, the additional links would go unused. To do any sort of load-balancing requires either blind round-robin or quite a bit of knowledge about the traffic flows. None of these choices strike me as a very good idea. On the other hand, how will an endpoint know that it has multiple locators, if the attachments are at site gateways? There needs to be a way to propagate the information back to the endpoints. As tempting as it is to make the paradigm choice immediately, and based on one or another core principal, the existence of quite a few interestingly different, detailed proposals suggests that the choice is not at all obvious. This is clearly something that has significant trade-offs in utility, design complexity and operations costs. > The routing > infrastructure should deal with most of the burden of getting packets to > destinations as efficiently as possible. I completely agree. It should deliver packets. It does this quite well. The effort to get it to that point of performance has been considerable. For all that, the capabilities of the basic delivery service are pretty limited. (QOS comes to mind as the major example of an enhancement that certainly cannot be done elsewhere in the architecture, and still has a long way to go.) So I believe this means that focusing on the delivery of individual packets is what the infrastructure should do. Integrating alternatives across a stream of packets should be done in endpoints or, perhaps, site gateways, so that the rest of the net infrastructure does not have to incur the cost of that integration. It also happens that this permits treating mobility and multihoming together, with a single mechanism. > The hosts shouldn't be expected to > do that job, because they are ill-equipped to do so. They should focus on > layer 4 & up. Oh. So I guess we should not have hosts distinguish between the hosts on the local net versus remote destinations? I suspect there are a few other functions we need to remove from the current Host IP layer. Certainly IPsec needs to be deprecated. In other words, perhaps this topic is a tad more complicated? > > And what is the summary description of the intelligence currently > > required for v4 multihoming? > > In the common case where the site (not the host) is multi-homed, the host > needs to know very little. OK. Now I understand. And there is no arguing that that sounds very appealing. There is one small problem. You are talking about taking a model that has been worked on for what? 10 years? Yet has gained virtually no adoption. And let's impose that model on the future architecture? (Sorry. I know that's harsh, but this topic needs to take note of realities.) > I realize that cranking the dial up from 32 to 128 raises serious concerns > about the ability of the routing infrastructure to handle > non-connectivity-dependent or non-provider-based addressing. However the > discussions I've seen about IPv6 address usage lead me to believe that > there > won't be anywhere near 2^128 routed prefixes. The IETF has done an impressively bad job of predicting the future. (To be fair, so has pretty much everyone else.) For example, note that during the CIDR work, efforts to predict when we would reach a serious crunch on IP Address allocation were confidently offered as being roughly around the year 2020, or maybe 2015. At any rate they also completely dismissed all concerns about the effect of multihoming on the routing tables, because it was not particularly popular at the time. Tony chaired the CIDR Deployment wg and might remember these discussions. So a different view of your prediction is that you want to rely on a theoretical prediction to ensure the safety of what is probably the most critical, most fragile and most problematic architectural component of the Internet. I'd rather not do that. > > It depends on the nature and degree of the routing work done by the end > > host, and how much administration is required for it. > > Based on what I've seen of how poorly hosts are defaulted & administered, > any increase in complexity & responsibility placed there is a bad thing. As correct as your assessment of the history, it leads to the thinking that says a salesman's (or customer service representative's) job would be far easier if it weren't for those pesky customers. Besides, the history of the infrastructure has had its own downsides. > > And requiring the infrastructure to change before a function is useful > > tends to require 3 (4? 5?) orders of magnitude more delay. > > Really? It seems that I could upgrade my O(10) routers before any > significant fraction of the O(10k) hosts on my campus could get upgraded. Ahh. This probably gets to the nugget of the difference in perspective. You said "my". However a change to the infrastructure requires coordinated effort by lots of independent "my"s. Adoption of features that have multi-hop dependencies across independent administrations has proved to have a rather high latency before reaching a critical mass of utility. > > Hmmm. Simple end system components, complex network components. > > > > Isn't that the phone system approach, and rather pointedly divergent > > from the historical Internet approach? > > I think it depends on where you divide the responsibility. My division is > that the complexity of layer 3 (IPv4 & IPv6) ought to be in the network, & > the complexity of layer 4 & up ought to be in the hosts. Too late. Host Layer 3 already has some pretty interesting complexity. However it happens that my personal view is towards agreeing with you, somewhat. The difference is that I believe we are creating other need for a layer between 3 and 4, which I'm tending to call Endpoint IP, distinct from Relay IP. This is a generalization of the shim/wedge model that some multiaddressing proposals are pursuing. d/ -- Dave Crocker Brandenburg InternetWorking From owner-multi6@ops.ietf.org Sat Jan 10 16:09:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19650 for ; Sat, 10 Jan 2004 16:09:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfQKd-00072E-PI for multi6-data@psg.com; Sat, 10 Jan 2004 21:07:43 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfQKR-0006jE-QQ for multi6@ops.ietf.org; Sat, 10 Jan 2004 21:07:31 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i0ALF9c04560; Sat, 10 Jan 2004 13:15:09 -0800 From: Dave Crocker To: CC: X-Mailer: PocoMail 3.03 (1740) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Date: Sat, 10 Jan 2004 13:07:24 -0800 Message-ID: <200411013724.251549@bbprime> In-Reply-To: <20040110145709.156F4872DB@mercury.lcs.mit.edu> Subject: Re: Re: Draft of updated WG charter Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Noel, ]> Now, all you need to do is understand why multiple addresses are an > inevitable consequence of the fact that we can't realistically call for the > deployment of an entire new routing architecture as part of the Multi6 > solution. yup. > Failing that, the only workable approach *within the current routing > architecture* is overlapping naming abstractions, which are (looked at from > the direction of the hosts, as opposed to from the routing) multiple > addresses. Among the HIP, LIN6, MAST, NOID, TCP-MH, SCTP, DCCP, etc. schemes, which do you count as having overlapping naming abstractions and which do you not? d/ -- Dave Crocker Brandenburg InternetWorking From owner-multi6@ops.ietf.org Sat Jan 10 21:09:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29326 for ; Sat, 10 Jan 2004 21:09:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfUzv-000AX4-46 for multi6-data@psg.com; Sun, 11 Jan 2004 02:06:39 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfUzd-000AAc-Lg for multi6@ops.ietf.org; Sun, 11 Jan 2004 02:06:21 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 1AfUzc-0008A8-00; Sat, 10 Jan 2004 20:06:20 -0600 Date: Sat, 10 Jan 2004 20:06:20 -0600 (CST) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: Noel Chiappa cc: multi6@ops.ietf.org Subject: Re: Draft of updated WG charter In-Reply-To: <20040110141218.D3C29872DC@mercury.lcs.mit.edu> Message-ID: References: <20040110141218.D3C29872DC@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 10 Jan 2004, Noel Chiappa wrote: > > From: Paul Lustgraaf > > > Any architecture that requires the 20,000+ end systems on my campus to > > make routing decisions is broken. > > Why? A large fraction of all the humans on the planet make routing decisions > every day (and half of them have IQ's of less than 100 :-). Yeah, but do they make *good* routing decisions? ;^) > Every end system > on your campus includes complex and sophisticated algorithms to do congestion > avoidance. Why should routing be treated differently? Maybe it shouldn't. My concern is that the hosts won't do it well due to poor administration. Jay From owner-multi6@ops.ietf.org Sun Jan 11 09:17:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29124 for ; Sun, 11 Jan 2004 09:17:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfgMR-000K31-KA for multi6-data@psg.com; Sun, 11 Jan 2004 14:14:39 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfgM0-000JPA-C2 for multi6@ops.ietf.org; Sun, 11 Jan 2004 14:14:12 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0BEEAHI140742; Sun, 11 Jan 2004 14:14:10 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0BEEAKd184072; Sun, 11 Jan 2004 15:14:10 +0100 Received: from zurich.ibm.com ([9.145.231.7]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA23502; Sun, 11 Jan 2004 15:14:07 +0100 Message-ID: <400159EE.D33C111B@zurich.ibm.com> Date: Sun, 11 Jan 2004 15:13:02 +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: "Ayyasamy, Senthilkumar (UMKC-Student)" CC: multi6@ops.ietf.org Subject: Re: deja vu again... References: <5EF7D95E17BDAD4A968C812E5ABC390B01108215@KC-MAIL4.kc.umkc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Ayyasamy, Senthilkumar (UMKC-Student)" wrote: > > > The meaning of "user" & "provider" apparently vary with context. > > [...] > > This is a good split of complexity & responsibility, with the > > hosts not having to do any of it. > > FYI: all end-system LB products has a measurement system which > checks for end to end availability. It is either probe-based > or have some heuristics to get the topology details. > > This discussion is a rat-hole; We are not going to agree on > anything. The current charter will allow more discussions > of this sort. I thought the chairs are of the opinion that > all solutions should by submitted by february( I only follow > mailining list discussions.) But, I see an updated charter > which has no place for solutions. Not true. It just does not include actually developing a specific solution on the standards track - that is left for the next stage. Brian From owner-multi6@ops.ietf.org Sun Jan 11 09:18:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29143 for ; Sun, 11 Jan 2004 09:18:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfgPY-000OdU-NO for multi6-data@psg.com; Sun, 11 Jan 2004 14:17:52 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfgPD-000O8s-Se for multi6@ops.ietf.org; Sun, 11 Jan 2004 14:17:32 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0BEHUe2131076 for ; Sun, 11 Jan 2004 14:17:30 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0BEHT8l235222 for ; Sun, 11 Jan 2004 15:17:30 +0100 Received: from zurich.ibm.com ([9.145.231.7]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA24896 for ; Sun, 11 Jan 2004 15:17:27 +0100 Message-ID: <40015AB6.BCFF5616@zurich.ibm.com> Date: Sun, 11 Jan 2004 15:16:22 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Please be relevant [Re: Draft of updated WG charter] References: <20040110153507.1166D872DB@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Everybody, This discussion has got WAY off its subject, which is the draft charter. If you want to discuss XYZ please change the subject of your message to XYZ. Can we please limit this thread to for specific suggestions for changes to the draft charter? Thanks Brian co-chair From owner-multi6@ops.ietf.org Sun Jan 11 09:21:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29226 for ; Sun, 11 Jan 2004 09:21:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfgSd-0002jz-1D for multi6-data@psg.com; Sun, 11 Jan 2004 14:21:03 +0000 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfgSJ-0002MI-U9 for multi6@ops.ietf.org; Sun, 11 Jan 2004 14:20:44 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0BEKgJW083254 for ; Sun, 11 Jan 2004 14:20:42 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0BEKgKd267096 for ; Sun, 11 Jan 2004 15:20:42 +0100 Received: from zurich.ibm.com ([9.145.231.7]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA31414 for ; Sun, 11 Jan 2004 15:20:39 +0100 Message-ID: <40015B77.15AA3332@zurich.ibm.com> Date: Sun, 11 Jan 2004 15:19:35 +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 CC: Multi6 Subject: intelligence in end systems [was Re: Draft of updated WG charter References: <3FFD700F.FC504B8A@zurich.ibm.com> <20040108152529.GA15512@vijaygill.com> <3225E60A-4201-11D8-A574-000A95928574@kurtis.pp.se> <20040109072034.GA25008@vijaygill.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This was discussed during the work on RFC 3582 and our goal in this area is stated in that RFC. Please do not re-open old debates; we are trying to make progress, not repeat previous work. Brian co-chair Jay Ford wrote: > > On Fri, 9 Jan 2004, vijay gill wrote: > > Routing update validation should be orthogonal to the multihoming > > solution. Also, I am going out on a limb here and say that any > > m-homing solution that requires end-host updates is a non-starter > > from the get-go. > > I'll go further out on that limb & say that any multi-homing solution which > requires substantially more intelligence in end systems than is currently > required for multi-homed IPv4 is bound to fail, even if you somehow get it > deployed. > > This is really the heart of the IPv6 scalability issue. I've never > understood the argument that multi-homing for IPv6 ought not be done the way > it's done for IPv4 (single address per end system, multi-path routing) on the > basis that the network can't tolerate the increase in routing table > size/complexity. My objection is that the alternative (shoving the > complexity to the end systems) is much worse because: > o as evidenced by worm attacks..., the end systems are the worst managed > pieces in the whole puzzle run by users who don't (& I'd say shouldn't > be expected to) understand the workings of the network; predicating > routing-type functionality on that platform is asking for trouble > o there are at least 3 (4? 5?) orders of magnitude more end systems than > there are routers, so embedding significant pieces of networking > functionality in end systems greatly increases the likelihood of > trouble & even more greatly decreases the chance of consistent > operation over time > > Consider the current difficulty in deploying changes to other technologies > due to system-level inertia (e.g., ASM->SSM for multicast). Those are > relatively upper-level things which for the most part don't affect the basic > ability to get packets delivered. Moving routing-type burden to the end > systems creates such inertia for basic packet delivery, making the network as > a whole even less upgradable than it is now. > > I advocate keeping the end systems as simple as possible & dealing with the > routing support required to make multi-homing work close to the way it works > for IPv4. > > ________________________________________________________________________ > Jay Ford, Network Engineering Group, Information Technology Services > University of Iowa, Iowa City, IA 52242 > email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-multi6@ops.ietf.org Sun Jan 11 09:23:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29272 for ; Sun, 11 Jan 2004 09:23:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfgUw-0005vv-6J for multi6-data@psg.com; Sun, 11 Jan 2004 14:23:26 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfgUf-0005Z2-VQ for multi6@ops.ietf.org; Sun, 11 Jan 2004 14:23:10 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0BEN6RT111214; Sun, 11 Jan 2004 14:23:06 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0BEMuKd216558; Sun, 11 Jan 2004 15:22:56 +0100 Received: from zurich.ibm.com ([9.145.231.7]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA49648; Sun, 11 Jan 2004 15:22:41 +0100 Message-ID: <40015BF0.3D4F1C2F@zurich.ibm.com> Date: Sun, 11 Jan 2004 15:21:36 +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: vijay gill CC: Noel Chiappa , multi6@ops.ietf.org Subject: border devices [was Re: Draft of updated WG charter] References: <20040109135818.58C73872D0@mercury.lcs.mit.edu> <20040109173958.GA2042@vijaygill.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Vijay, We are not designing for an IPv6 network already ruined by NATs. It is true that firewalls will still exist, but any IPv6 firewall will have to deal with multiple addresses per host in any case. Brian vijay gill wrote: > > On Fri, Jan 09, 2004 at 08:58:18AM -0500, Noel Chiappa wrote: > > > If the WG as a whole agrees with you (and this is an important point to nail > > down - my guess would be that they do not), then you've basically eliminated > > all solutions to the problem other than recycling Mobile-IPv6 mechanisms > > (since the charter rules out "let the routing do it", which means it has to > > be done via use of multiple addresses). > > > > I'm curious as to why you want to rule out any changes to the end-hosts. I > > note that Mobile-IPv6 didn't restrict themselves in this way. > > Significant amount of users that are multihomed have a setup that > accepts defaults from two providers, and anounces their blocks to > both upstreams. They receive no more information than the fact > that their connection is up. No routing tables, no prefixes, just > a quadzero. > > (users defined as an enterprise, not the invididual computer user > obviously) > > The end user system is often nat'd, and run through a stateful > firewall and all the information _they_ have is an ip address > of the gateway via dhcp. > > Any end-host updating solution must work through this gobbledegook. > > /vijay -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-multi6@ops.ietf.org Sun Jan 11 09:33:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29430 for ; Sun, 11 Jan 2004 09:33:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Afge3-000GEt-TO for multi6-data@psg.com; Sun, 11 Jan 2004 14:32:51 +0000 Received: from [195.212.29.156] (helo=mtagate7.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Afgdo-000Fwh-EP for multi6@ops.ietf.org; Sun, 11 Jan 2004 14:32:36 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0BEWXRm088970; Sun, 11 Jan 2004 14:32:33 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0BEWWKd240718; Sun, 11 Jan 2004 15:32:33 +0100 Received: from zurich.ibm.com ([9.145.231.7]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA23318; Sun, 11 Jan 2004 15:32:30 +0100 Message-ID: <40015E3D.E7CB7F45@zurich.ibm.com> Date: Sun, 11 Jan 2004 15:31:25 +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: Noel Chiappa CC: multi6@ops.ietf.org Subject: Routing based proposals [Re: Draft of updated WG charter] References: <20040110145709.156F4872DB@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit So far, nobody has come to multi6 with a proposal based on changes to inter-domain routing. Absent any such proposal, we won't be working on this approach. So the challenge to people who think there is an IDR-based option is clear. Until then, I suggest we don't waste our time discussing it. Actually, we don't have any proposals based on any kind of change to routing algorithms, as far as I can see. So let's discuss the proposals we do have, not those we don't have, OK? Brian co-chair Noel Chiappa wrote: > > > From: Jay Ford > > > boils down to the issue of hosts having multiple addresses. That > > decision precipitated the rest of this > > Exactly! An excellent summary, couldn't have put it better myself. > > Now, all you need to do is understand why multiple addresses are an > inevitable consequence of the fact that we can't realistically call for the > deployment of an entire new routing architecture as part of the Multi6 > solution. > > Failing that, the only workable approach *within the current routing > architecture* is overlapping naming abstractions, which are (looked at from > the direction of the hosts, as opposed to from the routing) multiple > addresses. > > Noel -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-multi6@ops.ietf.org Sun Jan 11 09:38:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29537 for ; Sun, 11 Jan 2004 09:38:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfgjN-000O6Z-0L for multi6-data@psg.com; Sun, 11 Jan 2004 14:38:21 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Afgiu-000NRN-Fm for multi6@ops.ietf.org; Sun, 11 Jan 2004 14:37:52 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0BEbpHI107196 for ; Sun, 11 Jan 2004 14:37:51 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0BEbo8l242944 for ; Sun, 11 Jan 2004 15:37:50 +0100 Received: from zurich.ibm.com ([9.145.231.7]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA47114 for ; Sun, 11 Jan 2004 15:37:48 +0100 Message-ID: <40015F7B.9B3D01E@zurich.ibm.com> Date: Sun, 11 Jan 2004 15:36:43 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Subject: Reminder - multi6 drafts due this month Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once again: we want all revised and new solution outlines published as I-Ds this month without fail, including analysis with respect to RFC 3582, so that we can make progress. Responding to a comment in the LIN6 draft, the goal "3.2.7. Multiple Solutions" in that draft means (IMHO): Does your solution work for *all* cases, or does it only solve a subset of cases, meaning that multiple solutions are needed? Brian co-chair From owner-multi6@ops.ietf.org Sun Jan 11 09:51:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29677 for ; Sun, 11 Jan 2004 09:51:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Afgv2-000El1-EA for multi6-data@psg.com; Sun, 11 Jan 2004 14:50:24 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Afgug-000EKG-FF for multi6@ops.ietf.org; Sun, 11 Jan 2004 14:50:02 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0BEo0JX091802 for ; Sun, 11 Jan 2004 14:50:00 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0BEo0Kd261014 for ; Sun, 11 Jan 2004 15:50:00 +0100 Received: from zurich.ibm.com ([9.145.231.7]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA25044 for ; Sun, 11 Jan 2004 15:49:58 +0100 Message-ID: <40016255.3BBB41C0@zurich.ibm.com> Date: Sun, 11 Jan 2004 15:48:53 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Subject: [Fwd: I-D ACTION:draft-teraoka-multi6-lin6-00.txt] Content-Type: multipart/mixed; boundary="------------1F000AB7CB333A6022E7F20B" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------1F000AB7CB333A6022E7F20B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-teraoka-multi6-lin6-00.txt Date: Fri, 09 Jan 2004 16:26:03 -0500 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LIN6: A Solution to Multihoming and Mobility in IPv6 Author(s) : F. Teraoka Filename : draft-teraoka-multi6-lin6-00.txt Pages : 25 Date : 2004-1-9 LIN6 is a protocol supporting multihoming and mobility in IPv6. LIN6 introduces the node id, not the interface id, for each node. Each node can be identified by its node id no matter where the node is connected and no matter how many interfaces the node has. In the IPv6 layer, 64-bit node id called LIN6 ID is used while 128-bit node-id called LIN6 generalized ID is used above the Transport layer. TCP connections and security associations can be preserved even if the node moves to another subnet or the node changes the using interface in a multihoming environment without modifying TCP or IPsec. In comparison with Mobile IPv6, LIN6 has several advantages in terms of header overhead and fault tolerance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-teraoka-multi6-lin6-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-teraoka-multi6-lin6-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-teraoka-multi6-lin6-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------1F000AB7CB333A6022E7F20B Content-Type: Message/External-body; name="draft-teraoka-multi6-lin6-00.txt" Content-Disposition: inline; filename="draft-teraoka-multi6-lin6-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-1-9164559.I-D@ietf.org> --------------1F000AB7CB333A6022E7F20B-- From owner-multi6@ops.ietf.org Sun Jan 11 11:10:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03395 for ; Sun, 11 Jan 2004 11:10:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Afi9M-000Egb-0Z for multi6-data@psg.com; Sun, 11 Jan 2004 16:09:16 +0000 Received: from [134.193.143.167] (helo=kc-msxproto1.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af8h7-000Ks1-3Z for multi6@ops.ietf.org; Sat, 10 Jan 2004 02:17:45 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Jan 2004 20:17:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Draft of updated WG charter Date: Fri, 9 Jan 2004 20:14:01 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108213@KC-MAIL4.kc.umkc.edu> Thread-Topic: Draft of updated WG charter Thread-Index: AcPW8S7ujgu0tb2BSpWBfeF7XOGJhgALjqcO From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Jay Ford" , "vijay gill" Cc: "Multi6" X-OriginalArrivalTime: 10 Jan 2004 02:17:44.0501 (UTC) FILETIME=[EEB08650:01C3D71F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >I'll go further out on that limb & say that any multi-homing solution = which >requires substantially more intelligence in end systems than is = currently >required for multi-homed IPv4 is bound to fail, even if you somehow get = it >deployed. =20 disagree. For example, the way I use multi-homing from school is to have = a f5 system which load balance between the main connection (morenet, = Internet2) and my wireless connection. I also know that the whole LCS building at = MIT=20 has a web proxy system which allows to do a kind of Load sharing between = MIT and a 100Mbps cogent connection. Given this is a *site* multi-homing WG, it is a known fact that many enterprise networks use load balancing=20 products for connecting to multiple providers. I can even argue that=20 end-site can achieve a equivalent reliability by load sharing among = multiple=20 inexpensive broadband connections in addition to a single dedicated = line.=20 In short, we are moving from a phase where availability is increased not = only by network level redundancy but also end site level redundancy.=20 =20 > o as evidenced by worm attacks..., the end systems are the worst = managed > pieces in the whole puzzle run by users who don't (& I'd say = shouldn't > be expected to) understand the workings of the network; = predicating > routing-type functionality on that platform is asking for trouble =20 come on... who is accountable for the multiple failures, = accidental/stupid misconfigurations, black lists, unwanted rate limitations(have you read = the recent IAB concern regarding port filtering.)? > o there are at least 3 (4? 5?) orders of magnitude more end systems = than > there are routers, so embedding significant pieces of networking > functionality in end systems greatly increases the likelihood of > trouble & even more greatly decreases the chance of consistent > operation over time =20 on the other hand, who has the incentive to deploy? It is only the=20 end-sites.=20 =20 > Consider the current difficulty in deploying changes to other = technologies > due to system-level inertia (e.g., ASM->SSM for multicast). Those are > relatively upper-level things which for the most part don't affect the = > basic ability to get packets delivered.=20 talking of network level deployment, I don't see any change in backbone past 5 years except plumbing.=20 In short, if we go by your suggestion, we can close this WG and = standardize a simple BCP in idr WG (which will detail how IPv4 site-multihoming is=20 applicable for IPv6.) I think this WG is not taking that path. =20 From owner-multi6@ops.ietf.org Sun Jan 11 12:31:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07601 for ; Sun, 11 Jan 2004 12:31:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfjPG-000Ig0-Ls for multi6-data@psg.com; Sun, 11 Jan 2004 17:29:46 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfjP3-000INf-OX for multi6@ops.ietf.org; Sun, 11 Jan 2004 17:29:33 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0BHTKZN065282; Sun, 11 Jan 2004 18:29:20 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <40015E3D.E7CB7F45@zurich.ibm.com> References: <20040110145709.156F4872DB@mercury.lcs.mit.edu> <40015E3D.E7CB7F45@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Routing based proposals [Re: Draft of updated WG charter] Date: Sun, 11 Jan 2004 18:29:29 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 11-jan-04, at 15:31, Brian E Carpenter wrote: > So far, nobody has come to multi6 with a proposal based on changes to > inter-domain routing. Absent any such proposal, we won't be working > on this approach. So the challenge to people who think there is an > IDR-based option is clear. Until then, I suggest we don't waste our > time discussing it. > Actually, we don't have any proposals based on any kind of change to > routing algorithms, as far as I can see. I proposed aggregation based on geography inside service provider networks a while ago. I still think this is a useful approach, but I observed a decided lack of consensus in this area... The draft just expired but it's still available at http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-isp-int- aggr-01.txt for those interested. From owner-multi6@ops.ietf.org Sun Jan 11 12:33:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07654 for ; Sun, 11 Jan 2004 12:33:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfjSt-000NvN-LB for multi6-data@psg.com; Sun, 11 Jan 2004 17:33:31 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfjSg-000NdH-Uz for multi6@ops.ietf.org; Sun, 11 Jan 2004 17:33:19 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 1AfjSf-0006bQ-00; Sun, 11 Jan 2004 11:33:17 -0600 Date: Sun, 11 Jan 2004 11:33:17 -0600 (CST) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: Tony Li cc: multi6@ops.ietf.org Subject: getting depressed (was: Draft of updated WG charter) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 10 Jan 2004, Tony Li wrote: > I find myself becoming rapidly depressed by this conversation. I was > under the impression that we had a requirements document already on > the table. I thought that we were a good bit past this. Tony: I think I understand your perspective, but try not to get bummed. Discussions such as this indicate interest & willingness to be involved. You should be more discouraged if people in positions such as mine (operator of a fairly large university network) tuned out & vowed never to deploy IPv6. > I'm going to tune out now. Please wake me if folks decide that > they actually want to fix this problem. Wake up, then. Based on Noel Chiappa's browbeating & Brian Carpenter's relevance admonishment, I'm accepting the multi-address thing (on faith until I can rationalize it) & focusing on the effort as currently defined. I apologize for the diversion, though I assure you that it was well intended. Jay From owner-multi6@ops.ietf.org Sun Jan 11 14:05:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10818 for ; Sun, 11 Jan 2004 14:05:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfksX-000Fxr-Ca for multi6-data@psg.com; Sun, 11 Jan 2004 19:04:05 +0000 Received: from [128.255.204.16] (helo=seatpost.its.uiowa.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Afkpa-000DC0-6V for multi6@ops.ietf.org; Sun, 11 Jan 2004 19:01:02 +0000 Received: from jnford (helo=localhost) by seatpost.its.uiowa.edu with local-esmtp (Exim 3.36 #1 (Debian)) id 1AfkpY-0000QL-00; Sun, 11 Jan 2004 13:01:00 -0600 Date: Sun, 11 Jan 2004 13:01:00 -0600 (CST) From: Jay Ford X-X-Sender: jnford@seatpost.its.uiowa.edu Reply-To: Jay Ford To: Dave Crocker cc: Multi6 Subject: layering wrt hosts & routers (was: Draft of updated WG charter) In-Reply-To: <200411012218.733891@bbprime> Message-ID: References: <200411012218.733891@bbprime> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 10 Jan 2004, Dave Crocker wrote: > > I view *sites* as multi-homed, not hosts. Therefore, I view the problem of > > how to make multi-homing work at the site (usually AS) boundary with other > > entities (ASes), not how to make the individual hosts do it. > > Certainly your are right about the _placement_ of additional connectivity. > However, this does not automatically mean that the mechanism to integrate _use_ > of the alternative connections must be implemented at the site gateway. Of > course, we need to know the type of multiaddressing use that is desired, to be > able to figure out the tradeoffs for where to place the mechanism. > > In the most simple, failover use of multiple access links, the additional links > would go unused. To do any sort of load-balancing requires either blind > round-robin or quite a bit of knowledge about the traffic flows. None of these > choices strike me as a very good idea. There is another type of load balancing which occurs. c a large variety of (src,dst) tuples results in traffic for some of these interactions traversing some links & traffic for others traversing other links. For some routing arrangements, this results in balancing of the load, although perhaps with less determinism than some would like. > On the other hand, how will an endpoint know that it has multiple locators, if > the attachments are at site gateways? There needs to be a way to propagate the > information back to the endpoints. I think a similar question arises for host-based address/path selection. That is, how will hosts know how to intelligently choose among the matrix of (src,dst) tuples it has? I've read some of the work on that topic, but it seems that more effort is required to get a sustainable solution. Clearly, that's one of the major points of this WG. > As tempting as it is to make the paradigm choice immediately, and based on one > or another core principal, the existence of quite a few interestingly different, > detailed proposals suggests that the choice is not at all obvious. This is > clearly something that has significant trade-offs in utility, design complexity > and operations costs. No argument there. > > The routing > > infrastructure should deal with most of the burden of getting packets to > > destinations as efficiently as possible. > > I completely agree. It should deliver packets. It does this quite well. The > effort to get it to that point of performance has been considerable. For all > that, the capabilities of the basic delivery service are pretty limited. (QOS > comes to mind as the major example of an enhancement that certainly cannot be > done elsewhere in the architecture, and still has a long way to go.) > > So I believe this means that focusing on the delivery of individual packets is > what the infrastructure should do. Integrating alternatives across a stream of > packets should be done in endpoints or, perhaps, site gateways, so that the rest > of the net infrastructure does not have to incur the cost of that integration. > > It also happens that this permits treating mobility and multihoming together, > with a single mechanism. OK. > > The hosts shouldn't be expected to > > do that job, because they are ill-equipped to do so. They should focus on > > layer 4 & up. > > Oh. So I guess we should not have hosts distinguish between the hosts on the > local net versus remote destinations? I suspect there are a few other functions > we need to remove from the current Host IP layer. Certainly IPsec needs to be > deprecated. OK, I made a (slight ;^) over-generalization. Obviously hosts have a layer-3 implementation. I'm just questioning whether the host should have full Internet-scope responsibility as opposed to mainly first-hop responsibility. But as I said in another note a few minutes ago, I'm prepared to go forward on the former premise & see where it leads. > In other words, perhaps this topic is a tad more complicated? Indeed. If I didn't think it was complicated I wouldn't be concerned about implementing it in hosts. > > > And what is the summary description of the intelligence currently > > > required for v4 multihoming? > > > > In the common case where the site (not the host) is multi-homed, the host > > needs to know very little. > > OK. Now I understand. And there is no arguing that that sounds very appealing. > > There is one small problem. You are talking about taking a model that has been > worked on for what? 10 years? Yet has gained virtually no adoption. And let's > impose that model on the future architecture? > > (Sorry. I know that's harsh, but this topic needs to take note of realities.) It's realities which cause me to question the viability of host-based multi-homing, but, onward... > > I realize that cranking the dial up from 32 to 128 raises serious concerns > > about the ability of the routing infrastructure to handle > > non-connectivity-dependent or non-provider-based addressing. However the > > discussions I've seen about IPv6 address usage lead me to believe that > > there > > won't be anywhere near 2^128 routed prefixes. > > The IETF has done an impressively bad job of predicting the future. (To be > fair, so has pretty much everyone else.) > > For example, note that during the CIDR work, efforts to predict when we would > reach a serious crunch on IP Address allocation were confidently offered as > being roughly around the year 2020, or maybe 2015. At any rate they also > completely dismissed all concerns about the effect of multihoming on the routing > tables, because it was not particularly popular at the time. Tony chaired the > CIDR Deployment wg and might remember these discussions. > > So a different view of your prediction is that you want to rely on a theoretical > prediction to ensure the safety of what is probably the most critical, most > fragile and most problematic architectural component of the Internet. > > I'd rather not do that. Very good points. > > > It depends on the nature and degree of the routing work done by the end > > > host, and how much administration is required for it. > > > > Based on what I've seen of how poorly hosts are defaulted & administered, > > any increase in complexity & responsibility placed there is a bad thing. > > As correct as your assessment of the history, it leads to the thinking that says > a salesman's (or customer service representative's) job would be far easier if > it weren't for those pesky customers. Besides, the history of the > infrastructure has had its own downsides. The local version is that it would be a lot easier to run things around here (at the university) without all those pesky students. ;^) > > > And requiring the infrastructure to change before a function is useful > > > tends to require 3 (4? 5?) orders of magnitude more delay. > > > > Really? It seems that I could upgrade my O(10) routers before any > > significant fraction of the O(10k) hosts on my campus could get upgraded. > > Ahh. This probably gets to the nugget of the difference in perspective. > > You said "my". However a change to the infrastructure requires coordinated > effort by lots of independent "my"s. Adoption of features that have multi-hop > dependencies across independent administrations has proved to have a rather high > latency before reaching a critical mass of utility. True, but the interaction & interdependency chain of the n router sets (something like O(10^^n)?) seems easier to deal with than that for the host sets (O(10k^^n)?). My orders are probably bogus, but you get the idea. > > > Hmmm. Simple end system components, complex network components. > > > > > > Isn't that the phone system approach, and rather pointedly divergent > > > from the historical Internet approach? > > > > I think it depends on where you divide the responsibility. My division is > > that the complexity of layer 3 (IPv4 & IPv6) ought to be in the network, & > > the complexity of layer 4 & up ought to be in the hosts. > > Too late. Host Layer 3 already has some pretty interesting complexity. > > However it happens that my personal view is towards agreeing with you, somewhat. > The difference is that I believe we are creating other need for a layer between > 3 and 4, which I'm tending to call Endpoint IP, distinct from Relay IP. > > This is a generalization of the shim/wedge model that some multiaddressing > proposals are pursuing. OK. Let's see where this leads. Jay From owner-multi6@ops.ietf.org Sun Jan 11 15:44:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16206 for ; Sun, 11 Jan 2004 15:44:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfmOw-000NDA-6Q for multi6-data@psg.com; Sun, 11 Jan 2004 20:41:38 +0000 Received: from [192.11.223.163] (helo=auemail2.firewall.lucent.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfmOZ-000Mp8-D8 for multi6@ops.ietf.org; Sun, 11 Jan 2004 20:41:15 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0BKeri17531 for ; Sun, 11 Jan 2004 14:41:24 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 11 Jan 2004 21:39:24 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155033D3C6A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kurt Erik Lindqvist , mbagnulo@ing.uc3m.es Cc: Brian E Carpenter , Multi6 Subject: RE: Draft of updated WG charter Date: Sun, 11 Jan 2004 21:39:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > On 2004-01-08, at 19.10, marcelo bagnulo wrote: > > > Hi Brian, Kurtis > > > > I don't understand the reason for including: > > > >> Development of specific solutions will require approval of the IESG > >> (e.g., a recharter). > > > > I mean, why is not enough that the wg defines the solution or set of > > solutions to be developed and then do it? > > Without having discussed with Brian or Bert.... > > There have always been a comment along these lines in the charter. Even > if we where to develop a solution here, we would need to add new > milestones, and update the charter. To the best of my knowledge, that > still has to go through the IESG. So this is merely stating a fact of > the process. > Exactly. Bert From owner-multi6@ops.ietf.org Mon Jan 12 01:53:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02820 for ; Mon, 12 Jan 2004 01:53:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfvvC-000CxQ-Iu for multi6-data@psg.com; Mon, 12 Jan 2004 06:51:34 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Afvv0-000Cae-60 for multi6@ops.ietf.org; Mon, 12 Jan 2004 06:51:22 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id AD678247A20 for ; Mon, 12 Jan 2004 07:51:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: <40015E3D.E7CB7F45@zurich.ibm.com> References: <20040110145709.156F4872DB@mercury.lcs.mit.edu> <40015E3D.E7CB7F45@zurich.ibm.com> Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <2864ADA4-4470-11D8-8035-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: Routing based proposals [Re: Draft of updated WG charter] Date: Sun, 11 Jan 2004 20:55:51 +0100 To: Multi6 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-01-11, at 15.31, Brian E Carpenter wrote: > So far, nobody has come to multi6 with a proposal based on changes to > inter-domain routing. Absent any such proposal, we won't be working > on this approach. So the challenge to people who think there is an > IDR-based option is clear. Until then, I suggest we don't waste our > time discussing it. > > Actually, we don't have any proposals based on any kind of change to > routing algorithms, as far as I can see. > > So let's discuss the proposals we do have, not those we don't have, OK? Actually to underline what Brian said in his mail after this. If you have more ideas on a solution, this is the time to submit the -00 draft. Not to reopen discussions.... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQAGqSaarNKXTPFCVEQKw/ACfac4tVmHBfzy3X7tIb5cHRD3yJ8sAn38J SQHbSciEsheBWAqW+MJkmSnm =crxu -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jan 12 02:34:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16490 for ; Mon, 12 Jan 2004 02:34:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Afwa0-000IeR-MO for multi6-data@psg.com; Mon, 12 Jan 2004 07:33:44 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfwZn-000IL3-P7 for multi6@ops.ietf.org; Mon, 12 Jan 2004 07:33:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0C7XQg25876; Mon, 12 Jan 2004 09:33:29 +0200 Date: Mon, 12 Jan 2004 09:33:26 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: multi6@ops.ietf.org Subject: Re: Routing based proposals [Re: Draft of updated WG charter] In-Reply-To: <40015E3D.E7CB7F45@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_00,DRASTIC_REDUCED autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 11 Jan 2004, Brian E Carpenter wrote: > So far, nobody has come to multi6 with a proposal based on changes to > inter-domain routing. Absent any such proposal, we won't be working > on this approach. So the challenge to people who think there is an > IDR-based option is clear. Until then, I suggest we don't waste our > time discussing it. > > Actually, we don't have any proposals based on any kind of change to > routing algorithms, as far as I can see. There have been a few, but they typically propose changes to the policy, rather than the algorithms. Michel Py's MHAP deploys a new inter-domain mapping/rewriting system. This has been stale for a while. Masataka Ohta's, e2e architecture calls for a drastic reduction of DFZ size, requiring policy changes. My ASN-PI document (which I'm not sure is the right thing to do) proposes a method for bigger and older organizations to get PI space. The first one is probably a routing-based solution, by all definitions. The rest may also be. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Jan 12 03:53:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18080 for ; Mon, 12 Jan 2004 03:53:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Afxnb-000IPC-Jj for multi6-data@psg.com; Mon, 12 Jan 2004 08:51:51 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfxnO-000I7S-0M for multi6@ops.ietf.org; Mon, 12 Jan 2004 08:51:38 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0C8paJX027916 for ; Mon, 12 Jan 2004 08:51:36 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0C8pZbl219178 for ; Mon, 12 Jan 2004 09:51:36 +0100 Received: from zurich.ibm.com ([9.145.231.163]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA38664 for ; Mon, 12 Jan 2004 09:51:33 +0100 Message-ID: <40025FD5.462984F@zurich.ibm.com> Date: Mon, 12 Jan 2004 09:50:29 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Subject: FYI: Multi6 mail archive Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The official multi6 mail archive is at http://ops.ietf.org/lists/multi6/ and is in good condition. However, there was a recent operational glitch in the Secretariat's archive at ftp://ftp.ietf.org/ietf-mail-archive/multi6 It has a gap between approximately Dec. 22, 2003 and Jan. 9, 2004. Brian From owner-multi6@ops.ietf.org Mon Jan 12 04:02:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18514 for ; Mon, 12 Jan 2004 04:02:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfxxU-0006qd-T8 for multi6-data@psg.com; Mon, 12 Jan 2004 09:02:04 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfxxH-0006a6-7A for multi6@ops.ietf.org; Mon, 12 Jan 2004 09:01:51 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 212662488C3; Mon, 12 Jan 2004 10:01:50 +0100 (CET) In-Reply-To: References: <20040110145709.156F4872DB@mercury.lcs.mit.edu> <40015E3D.E7CB7F45@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List , Brian E Carpenter From: Kurt Erik Lindqvist Subject: Re: Routing based proposals [Re: Draft of updated WG charter] Date: Mon, 12 Jan 2004 10:01:47 +0100 To: Iljitsch van Beijnum X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-01-11, at 18.29, Iljitsch van Beijnum wrote: > On 11-jan-04, at 15:31, Brian E Carpenter wrote: > >> So far, nobody has come to multi6 with a proposal based on changes to >> inter-domain routing. Absent any such proposal, we won't be working >> on this approach. So the challenge to people who think there is an >> IDR-based option is clear. Until then, I suggest we don't waste our >> time discussing it. > >> Actually, we don't have any proposals based on any kind of change to >> routing algorithms, as far as I can see. > > I proposed aggregation based on geography inside service provider > networks a while ago. I still think this is a useful approach, but I > observed a decided lack of consensus in this area... this is hardly a change of the routing algorithms though. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQAJifKarNKXTPFCVEQKtwQCfQg+NgVVSzcJwQ6n10KRElUtzEgEAoNbQ hH17oniLhmb/nvocdKNPWFCV =TNLY -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jan 12 04:05:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18650 for ; Mon, 12 Jan 2004 04:05:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Afy0B-000Atm-F3 for multi6-data@psg.com; Mon, 12 Jan 2004 09:04:51 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Afxzy-000AZE-Ne for multi6@ops.ietf.org; Mon, 12 Jan 2004 09:04:38 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id AB2992488E4 for ; Mon, 12 Jan 2004 10:04:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <575C31BB-44DE-11D8-8035-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Updated charter Date: Mon, 12 Jan 2004 10:04:34 +0100 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please send comments/suggestions on the proposed charter by Jan 22th. If we don't receive more (substantial) comments by then, we will send it to Bert/IESG. Kurtis & Brian -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQAJjJKarNKXTPFCVEQJqKQCdHinoT6zm0Ajdo1kcNaXVMU6ON9AAoJgH olAAi2bCpsuDB0RX1dSSXjqh =l610 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jan 12 04:09:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18877 for ; Mon, 12 Jan 2004 04:09:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Afy3d-000FRA-Na for multi6-data@psg.com; Mon, 12 Jan 2004 09:08:25 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Afy3F-000F2g-Mg for multi6@ops.ietf.org; Mon, 12 Jan 2004 09:08:01 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0C97rJX090370; Mon, 12 Jan 2004 09:07:53 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0C97pbl285990; Mon, 12 Jan 2004 10:07:53 +0100 Received: from zurich.ibm.com ([9.145.231.163]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA61108; Mon, 12 Jan 2004 10:07:49 +0100 Message-ID: <400263A4.CDDBA629@zurich.ibm.com> Date: Mon, 12 Jan 2004 10:06:44 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Savola CC: multi6@ops.ietf.org Subject: Re: Routing based proposals [Re: Draft of updated WG charter] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_00,DRASTIC_REDUCED autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Right, but I specifically mentioned routing algorithms, not policy, or local changes in edge routers. Anyway, as Kurtis said, it's time for drafts. Brian Pekka Savola wrote: > > On Sun, 11 Jan 2004, Brian E Carpenter wrote: > > So far, nobody has come to multi6 with a proposal based on changes to > > inter-domain routing. Absent any such proposal, we won't be working > > on this approach. So the challenge to people who think there is an > > IDR-based option is clear. Until then, I suggest we don't waste our > > time discussing it. > > > > Actually, we don't have any proposals based on any kind of change to > > routing algorithms, as far as I can see. > > There have been a few, but they typically propose changes to the > policy, rather than the algorithms. > > Michel Py's MHAP deploys a new inter-domain mapping/rewriting system. > This has been stale for a while. > > Masataka Ohta's, e2e architecture calls for a drastic reduction of DFZ > size, requiring policy changes. > > My ASN-PI document (which I'm not sure is the right thing to do) > proposes a method for bigger and older organizations to get PI space. > > The first one is probably a routing-based solution, by all > definitions. The rest may also be. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Jan 12 04:12:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18996 for ; Mon, 12 Jan 2004 04:12:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Afy7W-000KTf-Au for multi6-data@psg.com; Mon, 12 Jan 2004 09:12:26 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Afy7I-000K9u-TP for multi6@ops.ietf.org; Mon, 12 Jan 2004 09:12:13 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0C9AfZN077637; Mon, 12 Jan 2004 10:10:41 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <20040110145709.156F4872DB@mercury.lcs.mit.edu> <40015E3D.E7CB7F45@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <37921A16-44DF-11D8-815B-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Routing based proposals [Re: Draft of updated WG charter] Date: Mon, 12 Jan 2004 10:10:50 +0100 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 12-jan-04, at 10:01, Kurt Erik Lindqvist wrote: >> I proposed aggregation based on geography inside service provider >> networks a while ago. I still think this is a useful approach, but I >> observed a decided lack of consensus in this area... > this is hardly a change of the routing algorithms though. Isn't it? BGP doesn't have a set algorithm. My proposal certainly changes the way in which BGP routers handle routing information, even though it does so through the use of filters and policy hooks rather than by changing code. Iljitsch From owner-multi6@ops.ietf.org Mon Jan 12 04:14:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19093 for ; Mon, 12 Jan 2004 04:14:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Afy90-000MYj-9F for multi6-data@psg.com; Mon, 12 Jan 2004 09:13:58 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Afy8l-000MCy-Jj for multi6@ops.ietf.org; Mon, 12 Jan 2004 09:13:43 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 3F6C8248910; Mon, 12 Jan 2004 10:13:42 +0100 (CET) In-Reply-To: References: <200411012218.733891@bbprime> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <9A340678-44DF-11D8-8035-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 , Dave Crocker From: Kurt Erik Lindqvist Subject: Re: layering wrt hosts & routers (was: Draft of updated WG charter) Date: Mon, 12 Jan 2004 10:13:36 +0100 To: Jay Ford X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-01-11, at 20.01, Jay Ford wrote: > >> On the other hand, how will an endpoint know that it has multiple >> locators, if >> the attachments are at site gateways? There needs to be a way to >> propagate the >> information back to the endpoints. > > I think a similar question arises for host-based address/path > selection. > That is, how will hosts know how to intelligently choose among the > matrix of > (src,dst) tuples it has? I've read some of the work on that topic, > but it > seems that more effort is required to get a sustainable solution. > Clearly, > that's one of the major points of this WG. > Be careful here. Most (many) of the proposals around id/loc separation introduces a shim layer. For the ULPs there is still the possibility for a address-selection problem, but that is not different from what we already have and that problem does not really belong here. That issue has been beaten to death in the scoping discussions. As for how a "locator" is chosen, and verified to be working - that is what this entire WG is here for. But I would not call that address selection (for the risk of confusion). And how that is handled, is for each proposal to come up with. There are proposals that work differently as well. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQAJlQqarNKXTPFCVEQLEwwCfd9i+8X8Ya9HFPbqWrNVES2vHTQQAnRJA wEHRRuFGUxTuqkTaxs3GiG+J =0Ar/ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jan 12 04:16:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19151 for ; Mon, 12 Jan 2004 04:16:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfyAp-000Ojs-0E for multi6-data@psg.com; Mon, 12 Jan 2004 09:15:51 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfyAb-000OVI-NW for multi6@ops.ietf.org; Mon, 12 Jan 2004 09:15:37 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id A2192248920; Mon, 12 Jan 2004 10:15:36 +0100 (CET) In-Reply-To: <37921A16-44DF-11D8-815B-000A95CD987A@muada.com> References: <20040110145709.156F4872DB@mercury.lcs.mit.edu> <40015E3D.E7CB7F45@zurich.ibm.com> <37921A16-44DF-11D8-815B-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: Routing based proposals [Re: Draft of updated WG charter] Date: Mon, 12 Jan 2004 10:15:34 +0100 To: Iljitsch van Beijnum X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-01-12, at 10.10, Iljitsch van Beijnum wrote: > On 12-jan-04, at 10:01, Kurt Erik Lindqvist wrote: > >>> I proposed aggregation based on geography inside service provider >>> networks a while ago. I still think this is a useful approach, but I >>> observed a decided lack of consensus in this area... > >> this is hardly a change of the routing algorithms though. > > Isn't it? BGP doesn't have a set algorithm. My proposal certainly > changes the way in which BGP routers handle routing information, even > though it does so through the use of filters and policy hooks rather > than by changing code. I think we are drifting a bit of topic :-) When I read Brians mail I took at as meaning a new algorithm, or doing something else than path-vector, etc. In that sense geo based routing is no change. But let's leave it here, or take it private. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQAJluKarNKXTPFCVEQKJjwCghulh7I8hZtaEK3NdukzA2DvgnTkAoOmg ippjhHcKc8g70yinwFL9Lg1n =twf7 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jan 12 04:26:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19420 for ; Mon, 12 Jan 2004 04:26:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfyKQ-000BzB-Gw for multi6-data@psg.com; Mon, 12 Jan 2004 09:25:46 +0000 Received: from [134.193.143.167] (helo=kc-msxproto1.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfyJx-000BNy-8o for multi6@ops.ietf.org; Mon, 12 Jan 2004 09:25:17 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Mon, 12 Jan 2004 03:25:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Routing based proposals [Re: Draft of updated WG charter] Date: Mon, 12 Jan 2004 03:21:15 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B0110821D@KC-MAIL4.kc.umkc.edu> Thread-Topic: Routing based proposals [Re: Draft of updated WG charter] Thread-Index: AcPY7QYJyZPv1uVoQqenJksLYQE/JAAAGegt From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Iljitsch van Beijnum" , "Kurt Erik Lindqvist" Cc: "Multi6 List" X-OriginalArrivalTime: 12 Jan 2004 09:25:12.0105 (UTC) FILETIME=[FAADD190:01C3D8ED] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 >>> I proposed aggregation based on geography inside service provider >>> networks a while ago. I still think this is a useful approach, but I >>> observed a decided lack of consensus in this area... > >> this is hardly a change of the routing algorithms though. > > Isn't it? BGP doesn't have a set algorithm. My proposal certainly > changes the way in which BGP routers handle routing information, even > though it does so through the use of filters and policy hooks rather > than by changing code. it is addressing related. Actually, we had many addressing related work (metro-based, landmark, geographic, hierarchy and many different dynamic addressing scheme) but only few routing related (like NIMROD.) But, yes address allocation does have impact on routing policies and routing = table size. From owner-multi6@ops.ietf.org Mon Jan 12 04:34:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19704 for ; Mon, 12 Jan 2004 04:34:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AfySe-000NZq-Qs for multi6-data@psg.com; Mon, 12 Jan 2004 09:34:16 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AfySQ-000NFy-71 for multi6@ops.ietf.org; Mon, 12 Jan 2004 09:34:02 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0C9WZZN077965; Mon, 12 Jan 2004 10:32:35 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <20040110145709.156F4872DB@mercury.lcs.mit.edu> <40015E3D.E7CB7F45@zurich.ibm.com> <37921A16-44DF-11D8-815B-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <46D5BE1C-44E2-11D8-815B-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Routing based proposals [Re: Draft of updated WG charter] Date: Mon, 12 Jan 2004 10:32:44 +0100 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 12-jan-04, at 10:15, Kurt Erik Lindqvist wrote: > I think we are drifting a bit of topic :-) Wow, that has never happened before! > When I read Brians mail I > took at as meaning a new algorithm, or doing something else than > path-vector, etc. In that sense geo based routing is no change. But > let's leave it here, or take it private. As there was no support for this proposal and we discussed it extensively a while ago, I'm not going to submit it again unless there are others who think I should. In the mean time, I'll be happy to answer questions about this in private email. Iljitsch From owner-multi6@ops.ietf.org Mon Jan 12 09:54:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28578 for ; Mon, 12 Jan 2004 09:54:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ag3QL-0007aG-JC for multi6-data@psg.com; Mon, 12 Jan 2004 14:52:13 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ag3Pz-00075f-Pr for multi6@ops.ietf.org; Mon, 12 Jan 2004 14:51:52 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0CEpBpS112298; Mon, 12 Jan 2004 14:51:11 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0CEp5bl279848; Mon, 12 Jan 2004 15:51:10 +0100 Received: from zurich.ibm.com (dyn-9-13-127-142.ge.ch.ibm.com [9.13.127.142]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA61186; Mon, 12 Jan 2004 15:51:03 +0100 Message-ID: <4002B416.C7DA00F7@zurich.ibm.com> Date: Mon, 12 Jan 2004 15:49:58 +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: Fumio Teraoka CC: multi6@ops.ietf.org Subject: Re: LIN6 i-d for multihoming and mobility support References: <5.1.1.9.2.20031230221750.05bab0b8@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a few questions about LIN6 > LIN6 ID: > The LIN6 ID is assigned to the node and uniquely identifies the > node in the Internet. It is 64 bits in length. How is this unique number assigned and how is it guaranteed unique? > the distinct MA. The MA also has packet forwarding function. If > a non-LIN6 node sends a packet to a LIN6 node, the packet reaches > the MA of the LIN6 node first because the AAAA record of the LIN6 > node specifies the network prefix of the MA of the LIN6 node. > When the MA receives such a packet, the MA forward the packet to > the LIN6 node by IP-in-IP tunneling. What is the impact of this on MTU size issues? How does this scale? For example, if half the network is on LIN6 and the other half on normal IPv6, doesn't this means that about 50% of all packets will be forced through an MA? > > aggregatable +--+------+---+------+------+--------------------------+ > global unicast |FP|TLA ID|res|NLA ID|SLA ID| Interface ID | > address +--+------+---+------+------+--------------------------+ > > Figure 1: The LIN6 generalized ID and the LIN6 address The FP/TLA/MLA structure is obsolete. Why mention it? > 3.3. Distinction between the LIN6 Address and the Normal IPv6 Address > > As shown on the right side of Figure 2, the receiving node must > distinguish the LIN6 address from the normal IPv6 address to decide > whether address conversion must be done. From address format viewpoint, > however, the LIN6 address is indistinguishable from the normal IPv6 > address, i.e., LIN6 is fully compatible with IPv6. There are some > methods to distinguish the two address types. As a temporary solution, > LIN6 employs a special value as a part of the LIN6 ID. To distinguish > the LIN6 address, Keio University obtained the OUI value 0x00-0C-21 of > EUI-64[EUI64]. According to the IPv6 addressing scheme, the > Universal/Local bit of EUI-64 must be reversed in the global IPv6 > address. Thus, if the upper 24 bits of the lower 64 bits of the IPv6 > address is 0x02-0C-21, the IPv6 address is the LIN6 address. This only allows 40 variable bits - and 2**40 is not really enough for IPng's goals. So what is the permanent solution? > 3.9. Multihoming Support ... > When Node-A sends a LIN6 packet to Node-B, the transport layer of Node-A > can choose the source and the destination network prefixes by indicating > them explicitly to the network layer. Upon receiving a LIN6 packet on > Node-B, the network layer passes the source and the destination prefixes > to the transport layer in addition to the source and the destination > LIN6 generalized IDs. Thus, the transport layer of Node-B can know the > source and the destination network prefixes of the received packet. It's unclear to me why this has to happen in the transport layer. Why can't it happen inside the socket at network layer? Brian Fumio Teraoka wrote: > > Hi all, > > I have just submitted draft-teraoka-multi6-lin6-00.txt that describes > multihoming and mobility support based on LIN6. Sec.8 discusses > the features of LIN6 based on RFC3582. > > The draft is available from the following URL: > > http://www.tera.ics.keio.ac.jp/person/tera/multi6/draft-teraoka-multi6-lin6-00.txt > > Comments are welcome. > > Fumio Teraoka From owner-multi6@ops.ietf.org Mon Jan 12 10:18:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01838 for ; Mon, 12 Jan 2004 10:18:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ag3p6-000Cu9-JV for multi6-data@psg.com; Mon, 12 Jan 2004 15:17:48 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ag3op-000CeQ-Dd for multi6@ops.ietf.org; Mon, 12 Jan 2004 15:17:31 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0CFHJHI136644; Mon, 12 Jan 2004 15:17:19 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0CFHIXi278976; Mon, 12 Jan 2004 16:17:18 +0100 Received: from zurich.ibm.com (dyn-9-13-127-142.ge.ch.ibm.com [9.13.127.142]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA61862; Mon, 12 Jan 2004 16:17:16 +0100 Message-ID: <4002BA3B.5107C3E4@zurich.ibm.com> Date: Mon, 12 Jan 2004 16:16:11 +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: jari.arkko@piuha.net, Pekka Nikander CC: multi6@ops.ietf.org Subject: Re: [Hipsec] RE: Updated HIP mobility & multi-homing draft References: <3FF5576D.9020506@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just a few questions and comments (Hipsec list not copied)... > 1. Introduction > > This document specifies an extension to the Host Identity Protocol > [3] (HIP). The extension provides a simple and efficient means for > hosts to keep their communications on-going while having multiple IP > addresses, either at the same time or one after another. That is, > the extension provides basic support for multi-homing, mobility, and > simultaneous multi-homing and mobility. Additionally, the extension > allows communications to continue even when multi-homing or mobility > causes a change of the IP version that is available in the network; > that is, if one of the communicating hosts has both IPv4 and IPv6 > connectivity, either directly or through a proxy,the other host can > alternate between IPv4 and IPv6 without any effects on the upper > layer protocols. The last phrase isn't strictly true IMHO. If a change of path changes the MTU or the QoS, this can have an effect on the ULP, especially for real time applications. > 4.1 End-host mobility ... > The upper > layer protocols need to know about the address and connectivity > change only for QoS and other similar purposes. Not necessarily. The QoS management system may need to know, depending on the QoS mechanisms in use - and that is a control plane, not a ULP. > 5.1 Informing the peer about multiple or changed address(es) > > This document specifies a new HIP protocol parameter, the REA > parameter (see Section 7.1), that allows the hosts to exchange > information about their IP address(es), and any changes in their > address(es). The logical structure created with REA parameters has > three levels: hosts, interfaces, and addresses. This is illustrated > in Figure 1. > > address11 > / > interface1 - address12 > / > / address21 > host -- interface2 < > \ address22 > \ > interface3 - address31 > \ > address32 > > Figure 1 Hmm. I find the whole treatment of "interfaces" confusing. As you describe them, they don't correspond to physical interfaces or to virtual interfaces such as tunnel end points. They are only collections of addresses, which you choose to group for SPI purposes. That may or may not be a useful thing, but it would be much less confusing to use a different word instead of overloading "interface." ... > Note, > however, that especially in the case of site multi-homing one of the > addresses may become unreachablewhile the other one still works. In > the typical case, however, this does not require the host to inform > its peers about the situation, since even the non-working address > still logically exists. It's just as well you don't require this notification. The last node to know that an address is unreachable is the node that address belongs to. Unreachability is discovered at the other end of the multihomed session. > 6. Protocol overview > > The readdressing protocol is designed to be piggybacked on a number > of existing HIP exchanges. The main packets on which the REA > parameters are expected to be carried on are New SPI (NES) packets. > However, some implementations may want to experiment with sending REA > parameters also on other packets, such as R1 and I2. > > The protocol is an asymmetric protcool where one host, called the > Mobile Host, informs another host, called the Peer host, about > changes of IP addresses on one of its interfaces. That doesn't help with multihoming, since the host doesn't know about its own address changes due to sudden unreachability. Brian From owner-multi6@ops.ietf.org Mon Jan 12 11:23:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04326 for ; Mon, 12 Jan 2004 11:23:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ag4oW-0006gk-02 for multi6-data@psg.com; Mon, 12 Jan 2004 16:21:16 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ag4oG-0006fs-IL for multi6@ops.ietf.org; Mon, 12 Jan 2004 16:21:00 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9102B7AA5; Mon, 12 Jan 2004 17:20:59 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id F1746765D; Mon, 12 Jan 2004 17:20:57 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" Cc: "Multi6 List" Subject: RE: evaluation of draft-van-beijnum-multi6-odt-00.txt Date: Mon, 12 Jan 2004 17:13:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <67DE1D65-42DC-11D8-815B-000A95CD987A@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In theory, you're right. But in practice, things are different. I see > three classes of traffic over insecure links: > > 1. Sensitive data that is encrypted using IPsec/SSL/SSH or what have you > 2. Sensitive data that isn't encrypted > 3. Non-sensitive data > > 1. already solves the PKI problem in some way or another. If we can > find a way to tap in to that solution and use it to create session keys > we have bullet proof redirection protection. So I think this situation > is addressed. > > 2. is insane; trying to salvage anything here is useless. > > So that leaves 3. An attacker can redirect traffic to another address > for which he can see the traffic (so not to arbitrary addresses) which > is a bad thing, but for the "real" client the effect is pretty much the > same as when the attacker had sent a TCP RST: the real client doesn't > see any data anymore. The fact that the dat is now delivered to the > attacker isn't of great importance due to the non-sensitive nature of > the data. Well, actually the attacker could do the oposite. The attacker could generate some malicious state in the victims machine so that when the victim wants to initiate a communication will send the traffic to the attacker. So now the attacker can impersonate the server and send back modified answers for instance. For example, you have a host A that is running ODP. The host is not communicationg with anyone. Supose now that there is a very well known server, that A usually connects to, for instance a newspaper web page, that have address B. Supose that there is an attacker that has an address C During an inactivity period, the Attacker initates the communication with A and pretends to have address B (receiving packets containing keys sent from A to B, the attacker can achieve that if he is in the same lan than A). Now it generates some ODT state in A mapping the address B (of the server) to its own address C. Now the attacker leaves the place and goes to its usual address C, where he waits Considering that the state mapping B to C is indefinite, later on when the user of arrives and tries to contact B it will be actually sending packets to C. Would this attack be possible with ODP? If so, don't you think this is security risk? > > > Put it in another way: the security of this solution would be similar > > than > > using MIPv6 with inifinity BCE lifetime. MIP has an additional benefit > > that > > it is already standarized and code is available, so why deploy a > > solution > > tha has similar limitations? > > But MIPv6 also has some huge disadvantages, for instance the 24 byte > per packet overhead. We've already concluded that using MIPv6 for > multihoming without any changes won't fly. If your point is that using > MIP interactions is easier and no less effective and efficient than > designing something new then that's certainly something we can explore, > as long as we have a very clear picture of where we want to go. Just > diving into MIPv6 with the idea that it can solve multihoming with some > tweaks would be a very bad idea. The two facts that MIPv6 still isn't > an RFC and that the draft is 172 pages speak for themselves. > My personal opinion about MIPv6 is that it is unsuitable for multihoming support becuase the required modifications would introduce inacceptable security risks as the one described above. However, i folks think that those security risks are acceptable, i think it would be interesting to consider it, because the available code and implementations. But for now, i would focus the discussion on which is the desired level of security. IMHO a multihoming solution shouldn't introduce new security issues to the internet that is it should be as secure as fixed single homed ip Regards, marcelo > Anyone any idea whether MIPv6 (with route optimization) can be > implemented in a middlebox? > > From owner-multi6@ops.ietf.org Mon Jan 12 13:00:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08361 for ; Mon, 12 Jan 2004 13:00:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ag6Jq-000FjU-V4 for multi6-data@psg.com; Mon, 12 Jan 2004 17:57:42 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ag6Jc-000FPD-1r for multi6@ops.ietf.org; Mon, 12 Jan 2004 17:57:28 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0CHvBZN084684; Mon, 12 Jan 2004 18:57:12 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Multi6 List" From: Iljitsch van Beijnum Subject: Re: evaluation of draft-van-beijnum-multi6-odt-00.txt Date: Mon, 12 Jan 2004 18:57:21 +0100 To: X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 12-jan-04, at 17:13, marcelo bagnulo wrote: > The attacker could generate some malicious state in the victims > machine so > that when the victim wants to initiate a communication will send the > traffic > to the attacker. So now the attacker can impersonate the server and > send > back modified answers for instance. Ok. It took me a while to realize we're not talking about attacks that are possible because of insecure links anymore. > For example, you have a host A that is running ODP. The host is not > communicationg with anyone. > Supose now that there is a very well known server, that A usually > connects > to, for instance a newspaper web page, that have address B. > Supose that there is an attacker that has an address C Ok. > During an inactivity period, the Attacker initates the communication > with A > and pretends to have address B Hm, but in this case A must accept an incoming connection of some type. Also, the attacker must know A's address in the first place. This isn't as trivial in IPv6 as it is in IPv4. > (receiving packets containing keys sent from > A to B, the attacker can achieve that if he is in the same lan than > A). Now > it generates some ODT state in A mapping the address B (of the server) > to > its own address C. Note that the mapping state is passive in ODT: the attacker also has to get the victim to failover from the regular address to the fake one. > Considering that the state mapping B to C is indefinite, By "indefinite" I don't mean "lasts forever", but rather that there isn't a fixed timeout. Obviously implementations will want to remove this state at some point, with a logical moment being shortly after the last session that matched the mapping entry has stopped. (I should probably explain this in the draft.) However, this doesn't effect the possibility of an attack much as an attacker can simply keep the state fresh by sending packets from time to time. [Aside: a similar attack is possible if the atacker is present on the victim's subnet: the attacker can advertise the address block of the server it wants to impersonate as on-link and then simply answer neighbor solicitations. Not even any sniffing capability necessary in this case.] > later on when the user of arrives and tries to contact B it will be > actually sending packets to C. > Would this attack be possible with ODP? It depends on whether the attacker can make the victim failover to the negotiated backup addresses. This could be remedied by sending a probe to the "real" address after a while and/or when a new session is initiated. The real host will then send back an error since the state referenced in the probe doesn't match its own state. If the real address isn't reachable, then the attacking host still gets to play dice, but that's possible today too (in many cases): it can fake replies from the real host without having to worry about the real host getting in the way. Or we could separate the state for outgoing sessions from the state for incoming sessions. But this leads to interesting conundrums when host X contacts Y and then Y sets up a new session back to X. > If so, don't you think this is security risk? Sure. > My personal opinion about MIPv6 is that it is unsuitable for > multihoming > support becuase the required modifications would introduce inacceptable > security risks as the one described above. > However, i folks think that those security risks are acceptable, i > think it > would be interesting to consider it, because the available code and > implementations. It's unfortunate that we haven't been able to get a dialog going with any mobility people because there is substantial overlap here, which can be very good (reuse of (semi-)existing stuff) or very bad (multihoming and mobility solutions getting in each other's way). > But for now, i would focus the discussion on which is the > desired level of security. IMHO a multihoming solution shouldn't > introduce > new security issues to the internet that is it should be as secure as > fixed > single homed ip While it would be insane to defend the opposite, I think this is a trap we should avoid falling into. The safety features that are appropriate for an airplane aren't automatically justified in a car, or the other way around. Let's focus on the level of protection that is appropriate for what we're trying to build here, now and in the forseeable future, regardless of whether a certain class of attack is possible with single homed IP. Iljitsch From owner-multi6@ops.ietf.org Mon Jan 12 13:32:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09861 for ; Mon, 12 Jan 2004 13:32:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ag6r0-0003Ax-RZ for multi6-data@psg.com; Mon, 12 Jan 2004 18:31:58 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ag6qk-0002vM-P2 for multi6@ops.ietf.org; Mon, 12 Jan 2004 18:31:42 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C8A0B71E1; Mon, 12 Jan 2004 19:31:41 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id A1A5371D8; Mon, 12 Jan 2004 19:31:41 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" Cc: "Multi6 List" Subject: RE: evaluation of draft-van-beijnum-multi6-odt-00.txt Date: Mon, 12 Jan 2004 19:24:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > During an inactivity period, the Attacker initates the communication > > with A > > and pretends to have address B > > Hm, but in this case A must accept an incoming connection of some type. How does the ODT mechanism knows about existent connections? I mean, ODT is a IP layer mechanism right, so it is not aware if there is a communication or if packets are just echo requests. To be more precise, wouldn't a ping do the trick? > Also, the attacker must know A's address in the first place. This isn't > as trivial in IPv6 as it is in IPv4. ok. > > > (receiving packets containing keys sent from > > A to B, the attacker can achieve that if he is in the same lan than > > A). Now > > it generates some ODT state in A mapping the address B (of the server) > > to > > its own address C. > > Note that the mapping state is passive in ODT: the attacker also has to > get the victim to failover from the regular address to the fake one. > Perhaps i am not understanding this correctly. what happens if the attacker continues to send pings, from time to time with the source address set to C? The general question is how does the ODT end knows which is the actual address that it has to use? > > Considering that the state mapping B to C is indefinite, > > By "indefinite" I don't mean "lasts forever", but rather that there > isn't a fixed timeout. Obviously implementations will want to remove > this state at some point, with a logical moment being shortly after the > last session that matched the mapping entry has stopped. (I should > probably explain this in the draft.) > > However, this doesn't effect the possibility of an attack much as an > attacker can simply keep the state fresh by sending packets from time > to time. Yes. > > [Aside: a similar attack is possible if the atacker is present on the > victim's subnet: the attacker can advertise the address block of the > server it wants to impersonate as on-link and then simply answer > neighbor solicitations. Not even any sniffing capability necessary in > this case.] > yes (but this is a problem for the send guys) BEsides, the problem here is that the attacker may leave the subnet and continue with the attack. This is aproblem because it is probably easier to access to a physical media for a short time of period than staying there for a while. > > later on when the user of arrives and tries to contact B it will be > > actually sending packets to C. > > > Would this attack be possible with ODP? > > It depends on whether the attacker can make the victim failover to the > negotiated backup addresses. This could be remedied by sending a probe > to the "real" address after a while and/or when a new session is > initiated. The real host will then send back an error since the state > referenced in the probe doesn't match its own state. > Yes, i porposed the same solution for mip :-) But Pekka N. didn't like it (as far as i remember), becuase the security of the host is based on the fact that the error message is not filtered. Considering the wide adoption of ICMP filtering this may be a a problem. Then i proposed that the state is renewed if when the client send a state refresh request, the client obtains an ICMP unreachable message as reply , meaning that the path is down (so there is no attack going on). The problem here is that the fault tolerance of your solution depends on ICMP messages, which i didn't really liked. But if you accept that the security or the fault tolerance of the solution depends on periodic exchange of signaling messages, this could work. Also keep in mind that there are other attacks that may also be interesting to consider like stealing an unused IP address from a certain subnet. (i don't know if this is important) > If the real address isn't reachable, then the attacking host still gets > to play dice, but that's possible today too (in many cases): it can > fake replies from the real host without having to worry about the real > host getting in the way. > > Or we could separate the state for outgoing sessions from the state for > incoming sessions. But this leads to interesting conundrums when host X > contacts Y and then Y sets up a new session back to X. > > > If so, don't you think this is security risk? > > Sure. > > > My personal opinion about MIPv6 is that it is unsuitable for > > multihoming > > support becuase the required modifications would introduce inacceptable > > security risks as the one described above. > > However, i folks think that those security risks are acceptable, i > > think it > > would be interesting to consider it, because the available code and > > implementations. > > It's unfortunate that we haven't been able to get a dialog going with > any mobility people because there is substantial overlap here, which > can be very good (reuse of (semi-)existing stuff) or very bad > (multihoming and mobility solutions getting in each other's way). > > > But for now, i would focus the discussion on which is the > > desired level of security. IMHO a multihoming solution shouldn't > > introduce > > new security issues to the internet that is it should be as secure as > > fixed > > single homed ip > > While it would be insane to defend the opposite, I think this is a trap > we should avoid falling into. The safety features that are appropriate > for an airplane aren't automatically justified in a car, or the other > way around. Let's focus on the level of protection that is appropriate > for what we're trying to build here, now and in the forseeable future, > regardless of whether a certain class of attack is possible with single > homed IP. > Just to clarify this, I am not claiming that we shouldn't provide additional security if we can, but that we shouldn't provide less. > Iljitsch > From owner-multi6@ops.ietf.org Wed Jan 14 03:52:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05809 for ; Wed, 14 Jan 2004 03:52:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Agggk-000MY7-TO for multi6-data@psg.com; Wed, 14 Jan 2004 08:47:46 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgggS-000MVP-AP for multi6@ops.ietf.org; Wed, 14 Jan 2004 08:47:28 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0E8lQRT132902 for ; Wed, 14 Jan 2004 08:47:26 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0E8lQNA235312 for ; Wed, 14 Jan 2004 09:47:26 +0100 Received: from zurich.ibm.com (sig-9-145-225-15.de.ibm.com [9.145.225.15]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA23296 for ; Wed, 14 Jan 2004 09:47:23 +0100 Message-ID: <4004E7E2.87AED19A@zurich.ibm.com> Date: Wed, 14 Jan 2004 07:55:30 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Subject: Re: I-D ACTION:draft-van-beijnum-multi6-odt-00.txt References: <200401122104.QAA19034@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Two comments. 1. It seems to me that if you ignore the way each of them is described, there is actually a very strong resemblance between ODT and NOID. In effect they both treat the first address used for a session as the ID, and dynamically switch to using alternative addresses as the locator, with a stateful shim concealing the switch from upper layer protocols. Am I confused? The only real difference is that NOID turns out to need a rewrite OK/Not OK flag in the IP header and ODT doesn't, but it does need an ODT protocol exchange. (Which has the consequence that ODT claims to work for IPv4 too.) If NOID didn't include the case of a router doing the rewrite in flight, it wouldn't need that flag anyway. So the crude description of ODT is as a degenerate case of NOID. I think the security issues are therefore very similar too. In fact the discussion between Iljitsch and Marcelo would largely apply to NOID. 2. One remark that I really don't understand: > 8 Tunnel Creation ... > 1. Host A announces its addresses to host B > > The addresses may be of different address families. Each address is > accompanied by preference information. In order to not unnecessarily > trigger NAT incompatibility, a "current source address" address > family is used to refer to the source address in the IP packet, > which may have been rewritten. Firstly, we aren't designing for IPv6 NATs, so this would only apply to the IPv4 case, right? But in any case, I don't see how it helps. You can't tell by looking at an address whether it's been rewritten, so you can't tell if it's OK for checksum purposes. So the fact that you know an address *might* have been rewritten is no use, as far as I can see. The only useful information is to know for sure what the address was at the source, without even caring whether it has been rewritten in the active IP header. And in ODT (as in NOID) that information is in local state at the destination. Brian From owner-multi6@ops.ietf.org Wed Jan 14 07:50:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15913 for ; Wed, 14 Jan 2004 07:50:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgkRz-000FMk-Eu for multi6-data@psg.com; Wed, 14 Jan 2004 12:48:47 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgkRm-000FM2-2d for multi6@ops.ietf.org; Wed, 14 Jan 2004 12:48:34 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0ECmJZN019226; Wed, 14 Jan 2004 13:48:20 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Multi6 List" From: Iljitsch van Beijnum Subject: Re: evaluation of draft-van-beijnum-multi6-odt-00.txt Date: Wed, 14 Jan 2004 13:48:30 +0100 To: X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 12-jan-04, at 19:24, marcelo bagnulo wrote: > How does the ODT mechanism knows about existent connections? I mean, > ODT is > a IP layer mechanism right, so it is not aware if there is a > communication > or if packets are just echo requests. To be more precise, wouldn't a > ping do > the trick? Depends on the implementation, I guess. I think in a host implementation, the ODT state would be coupled with the transport state because there is overlap here (when to failover and so on). It would be possible to implement ODT without looking below IP at all, but that could have negative side effects. For instance, I believe it makes sense to leave ICMP alone and not tunnel it. >> Note that the mapping state is passive in ODT: the attacker also has >> to >> get the victim to failover from the regular address to the fake one. > Perhaps i am not understanding this correctly. what happens if the > attacker > continues to send pings, from time to time with the source address set > to C? In other proposals the idea was to use the source address in incoming packets as a strong hint for the destination address in outgoing packets. Since ODT requires that all addresses be verified before use, such a hint isn't required so the attacker must come out as the best choice in the verification procedure. But during this verification procedure, the fact that the host sitting at the original address sends back errors should make this attack non-trivial. > The general question is how does the ODT end knows which is the actual > address that it has to use? Send packets to all destination addresses (possibly from all source addresses, creating a "ping bomb" of significant size) and see what comes back and how soon. >> It depends on whether the attacker can make the victim failover to the >> negotiated backup addresses. This could be remedied by sending a probe >> to the "real" address after a while and/or when a new session is >> initiated. The real host will then send back an error since the state >> referenced in the probe doesn't match its own state. > Yes, i porposed the same solution for mip :-) Well it must be a good idea then. (-: > But Pekka N. didn't like it (as far as i remember), becuase the > security of > the host is based on the fact that the error message is not filtered. > Considering the wide adoption of ICMP filtering this may be a a > problem. Ok. I had a very nice rebuttal here, namely that all ODT interactions (including errors) use the ODT extension header so this shouldn't be an issue. (Problems are of course possible when either all packets containing the ODT header or packets containing the ODT header but not any ULP are filtered.) Unfortunately, this doesn't solve the problem, since the host that is impersonated may not implement ODT so error messsages aren't forthcoming. I think this means that the only way to be secure is for all new sessions to use the "real" address for at least a few packets. This of course makes initiating new sessions after a failure problematic, especially in cases where the full set of remote addresses is no longer available, such as after a referral. >> While it would be insane to defend the opposite, I think this is a >> trap >> we should avoid falling into. The safety features that are appropriate >> for an airplane aren't automatically justified in a car, or the other >> way around. Let's focus on the level of protection that is appropriate >> for what we're trying to build here, now and in the forseeable future, >> regardless of whether a certain class of attack is possible with >> single >> homed IP. > Just to clarify this, I am not claiming that we shouldn't provide > additional > security if we can, but that we shouldn't provide less. Redirection attacks at the IP level aren't possible in current IP. Any kind of rehoming allows for the possibility of redirection attacks. If we mandate that mobility/multihoming must not allow any new attacks, this means the countermeasures against these attacks must be bullet proof. I think this is raising the bar too high: if people are stupid enough to use insecure links without crypto AND enable protocols that break current expectations, they shouldn't be surprised if they see new attacks. Obviously such attacks shouldn't be possible when using reasonably secure links or IPsec. In other words: we accept that we have to use plastic knives when eating our in-flight meals, but just because metal knives are unacceptable in airplanes, doesn't mean they shouldn't be available elsewhere. From owner-multi6@ops.ietf.org Wed Jan 14 08:07:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16191 for ; Wed, 14 Jan 2004 08:07:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Agkja-000HWp-4b for multi6-data@psg.com; Wed, 14 Jan 2004 13:06:58 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgkjN-000HW4-70 for multi6@ops.ietf.org; Wed, 14 Jan 2004 13:06:45 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0ED6WZN019496; Wed, 14 Jan 2004 14:06:32 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4004E7E2.87AED19A@zurich.ibm.com> References: <200401122104.QAA19034@ietf.org> <4004E7E2.87AED19A@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7F8E9C12-4692-11D8-815B-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: I-D ACTION:draft-van-beijnum-multi6-odt-00.txt Date: Wed, 14 Jan 2004 14:06:42 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 14-jan-04, at 7:55, Brian E Carpenter wrote: > 1. It seems to me that if you ignore the way each of them is > described, there is actually a very strong resemblance between ODT and > NOID. In effect they both treat the first address used for a session > as the ID, and dynamically switch to using alternative addresses as > the locator, with a stateful shim concealing the switch from upper > layer protocols. Am I confused? Yes, this part is the same. However, I wouldn't say that > the crude description of ODT is as a degenerate case of NOID. The shim idea wasn't new in NOID either. I didn't include address rewriting in routers in ODT because although the idea is very interesting, I don't think the potential gain is big enough to justify all the additional trouble. Also, NOID uses a three-way handshake while ODT uses a model where each end announces information to the other end that may or may not be ignored. > 2. One remark that I really don't understand: >> 8 Tunnel Creation > ... >> 1. Host A announces its addresses to host B >> The addresses may be of different address families. Each address >> is >> accompanied by preference information. In order to not >> unnecessarily >> trigger NAT incompatibility, a "current source address" address >> family is used to refer to the source address in the IP packet, >> which may have been rewritten. > Firstly, we aren't designing for IPv6 NATs, so this would only apply > to the IPv4 case, right? I hope so. :-) > But in any case, I don't see how it helps. You > can't tell by looking at an address whether it's been rewritten, so > you can't tell if it's OK for checksum purposes. Which checksum do you mean here? Iljitsch From owner-multi6@ops.ietf.org Wed Jan 14 12:02:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28153 for ; Wed, 14 Jan 2004 12:02:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgoMz-000DQA-P3 for multi6-data@psg.com; Wed, 14 Jan 2004 16:59:53 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgoMl-000DPX-Tt for multi6@ops.ietf.org; Wed, 14 Jan 2004 16:59:40 +0000 Received: from [127.0.0.1] (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 176101C; Wed, 14 Jan 2004 19:12:29 +0200 (EET) In-Reply-To: <4002BA3B.5107C3E4@zurich.ibm.com> References: <3FF5576D.9020506@piuha.net> <4002BA3B.5107C3E4@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0827D266-46B3-11D8-86DC-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org, jari.arkko@piuha.net From: Pekka Nikander Subject: Re: [Hipsec] RE: Updated HIP mobility & multi-homing draft Date: Wed, 14 Jan 2004 17:59:35 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, Thanks a lot on your comments. >> ... the other host can >> alternate between IPv4 and IPv6 without any effects on the upper >> layer protocols. > > The last phrase isn't strictly true IMHO. If a change of path changes > the MTU or the QoS, this can have an effect on the ULP, especially for > real time applications. I changed this to read: ... the other host can alternate between IPv4 and IPv6, without needing to tear down and re-establish upper layer protocol connections or associations. In other words, the way upper layer protocols need to react to cross-IP-version handovers does not differ from the way they needs to react intra-IP-version handovers. Better? > >> 4.1 End-host mobility > ... >> The upper >> layer protocols need to know about the address and connectivity >> change only for QoS and other similar purposes. > > Not necessarily. The QoS management system may need to know, depending > on the QoS mechanisms in use - and that is a control plane, not a > ULP. I'm afraid I don't quite understand your comment. Anyway, I changed the text to read The upper layer protocols do not need to know about the address and connectivity change but perhaps to react to changed QoS, MTU, or for other similar purposes. In most cases, they do not need to know. Any better? > Hmm. I find the whole treatment of "interfaces" confusing. As you > describe > them, they don't correspond to physical interfaces or to virtual > interfaces > such as tunnel end points. They are only collections of addresses, > which > you choose to group for SPI purposes. That may or may not be a useful > thing, > but it would be much less confusing to use a different word instead > of overloading "interface." I changed the term to "Address Group", and updated the rest of the spec accordingly. >> Note, >> however, that especially in the case of site multi-homing one of >> the >> addresses may become unreachablewhile the other one still works. >> In >> the typical case, however, this does not require the host to inform >> its peers about the situation, since even the non-working address >> still logically exists. > > It's just as well you don't require this notification. The last node to > know that an address is unreachable is the node that address belongs > to. > Unreachability is discovered at the other end of the multihomed > session. Thanks. I'll try to note this in the other draft; I don't see how this would be formulated here. >> The readdressing protocol is designed to be piggybacked on a number >> of existing HIP exchanges. ... >> >> The protocol is an asymmetric protcool where one host, called the >> Mobile Host, informs another host, called the Peer host, about >> changes of IP addresses on one of its interfaces. > > That doesn't help with multihoming, since the host doesn't know about > its own address changes due to sudden unreachability. While I agree with your comment, I'm afraid I don't quite see the point. The assumption is that the HIP hosts announce their multi-homing situation as soon as they create HIP associations, modulo possible privacy and policy concerns. Hence, when a host becomes unreachable through one of its addresses, its peers already know about the other potential addresses. Should I discuss this in the forthcoming -nikander-multi6-hip- draft? Section 8.4 Changing the preferred address mentions that: > A host MAY want to change the preferred outgoing address for many > reasons, e.g., because traffic information or ICMP error messages > indicate that the currently used preferred address may have become That is meant to cover the case where ULP information, such as TCP timeouts, indicate that the preferred address needs to be changed. But maybe the term "traffic information" is inaccurate and should be replaced with something better. Any suggestions? --Pekka From owner-multi6@ops.ietf.org Wed Jan 14 12:03:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28174 for ; Wed, 14 Jan 2004 12:03:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgoMM-000DLW-RN for multi6-data@psg.com; Wed, 14 Jan 2004 16:59:14 +0000 Received: from [131.113.100.3] (helo=smtp.tera.ics.keio.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AgoM8-000DJL-64 for multi6@ops.ietf.org; Wed, 14 Jan 2004 16:59:00 +0000 Received: (qmail 50339 invoked from network); 15 Jan 2004 01:58:57 +0900 X-Authentication: tera was authenticated by maro.tera.ics.keio.ac.jp at 15 Jan 2004 01:58:57 +0900 Received: from unknown (HELO hotaka.ics.keio.ac.jp) (131.113.100.3) by maro.tera.ics.keio.ac.jp with SMTP; 15 Jan 2004 01:58:57 +0900 Message-Id: <5.1.1.9.2.20040115012038.06a7f8d8@127.0.0.1> X-Sender: tera@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr4 Date: Thu, 15 Jan 2004 01:58:38 +0900 To: Brian E Carpenter From: Fumio Teraoka Subject: Re: LIN6 i-d for multihoming and mobility support Cc: multi6@ops.ietf.org In-Reply-To: <4002B416.C7DA00F7@zurich.ibm.com> References: <5.1.1.9.2.20031230221750.05bab0b8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Brian, At 04/01/12 15:49 +0100, Brian E Carpenter wrote: >Hi, I have a few questions about LIN6 > >> LIN6 ID: >> The LIN6 ID is assigned to the node and uniquely identifies the >> node in the Internet. It is 64 bits in length. > >How is this unique number assigned and how is it guaranteed unique? We assume that EUI-64 is used as the LIN6 ID (64 bits). By definition, each EUI-64 number is globally unique. LIN6 IDs can be assigned in a hierarchical manner like IPv6 address assignment. Or computer vendors can assign a LIN6 ID to their computer like Ethernet MAC address. >> the distinct MA. The MA also has packet forwarding function. If >> a non-LIN6 node sends a packet to a LIN6 node, the packet reaches >> the MA of the LIN6 node first because the AAAA record of the LIN6 >> node specifies the network prefix of the MA of the LIN6 node. >> When the MA receives such a packet, the MA forward the packet to >> the LIN6 node by IP-in-IP tunneling. > >What is the impact of this on MTU size issues? The same problem in IP-in-IP tunneling in MIPv6 arises. That is, if non-LIN6 node sends a MTU-size packet, it is fragmented at MA before MA forwards it. >How does this scale? For example, if half the network is on LIN6 and >the other half on normal IPv6, doesn't this means that about 50% of all >packets will be forced through an MA? Each network can have a distinct MA. Packet forwarding does not concentrate at an MA. >> aggregatable +--+------+---+------+------+--------------------------+ >> global unicast |FP|TLA ID|res|NLA ID|SLA ID| Interface ID | >> address +--+------+---+------+------+--------------------------+ >> >> Figure 1: The LIN6 generalized ID and the LIN6 address > >The FP/TLA/MLA structure is obsolete. Why mention it? This is a mistake. We will fix it in the next version. >> 3.3. Distinction between the LIN6 Address and the Normal IPv6 Address >> >> As shown on the right side of Figure 2, the receiving node must >> distinguish the LIN6 address from the normal IPv6 address to decide >> whether address conversion must be done. From address format viewpoint, >> however, the LIN6 address is indistinguishable from the normal IPv6 >> address, i.e., LIN6 is fully compatible with IPv6. There are some >> methods to distinguish the two address types. As a temporary solution, >> LIN6 employs a special value as a part of the LIN6 ID. To distinguish >> the LIN6 address, Keio University obtained the OUI value 0x00-0C-21 of >> EUI-64[EUI64]. According to the IPv6 addressing scheme, the >> Universal/Local bit of EUI-64 must be reversed in the global IPv6 >> address. Thus, if the upper 24 bits of the lower 64 bits of the IPv6 >> address is 0x02-0C-21, the IPv6 address is the LIN6 address. > >This only allows 40 variable bits - and 2**40 is not really enough for >IPng's goals. So what is the permanent solution? Currently, only one EUI-64 is used for our test operation of LIN6. Multiple EUI-64 numbers can be used as LIN6 ID. Basically, 62 bits can be used as LIN6 ID (2 bits in EUI-64 have special meanings.) >> 3.9. Multihoming Support >... >> When Node-A sends a LIN6 packet to Node-B, the transport layer of Node-A >> can choose the source and the destination network prefixes by indicating >> them explicitly to the network layer. Upon receiving a LIN6 packet on >> Node-B, the network layer passes the source and the destination prefixes >> to the transport layer in addition to the source and the destination >> LIN6 generalized IDs. Thus, the transport layer of Node-B can know the >> source and the destination network prefixes of the received packet. > >It's unclear to me why this has to happen in the transport layer. Why can't >it happen inside the socket at network layer? In our design principle, the network layer should obey the policy of upper layers. In other words, the source and the destination locator should be selected in the transport layer or the application layer. Fumio Teraoka > Brian > >Fumio Teraoka wrote: >> >> Hi all, >> >> I have just submitted draft-teraoka-multi6-lin6-00.txt that describes >> multihoming and mobility support based on LIN6. Sec.8 discusses >> the features of LIN6 based on RFC3582. >> >> The draft is available from the following URL: >> >> http://www.tera.ics.keio.ac.jp/person/tera/multi6/draft-teraoka-multi6-lin6-00.txt >> >> Comments are welcome. >> >> Fumio Teraoka From owner-multi6@ops.ietf.org Wed Jan 14 15:42:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10392 for ; Wed, 14 Jan 2004 15:42:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Agroo-0006t4-Na for multi6-data@psg.com; Wed, 14 Jan 2004 20:40:50 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AgroW-0006ry-4S for multi6@ops.ietf.org; Wed, 14 Jan 2004 20:40:32 +0000 Received: (qmail 49417 invoked from network); 14 Jan 2004 20:47:50 -0000 Received: from h219-110-033-046.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.46) by necom830.hpcl.titech.ac.jp with SMTP; 14 Jan 2004 20:47:50 -0000 Message-ID: <4005A971.1090109@necom830.hpcl.titech.ac.jp> Date: Thu, 15 Jan 2004 05:41:21 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: to be draft-ohta-multi6-8plus8-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=BAYES_00,RCVD_IN_SORBS, THE_FOLLOWING_FORM autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all; Attached is a completed multihoming proposal of mine. It is submitted as an ID and will soon appear as such. Masataka Ohta -- INTERNET DRAFT M. Ohta draft-ohta-multi6-8plus8-00.txt Tokyo Institute of Technology January 2004 8+8 Addressing for IPv6 End to End Multihoming Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo describes 8+8 address format, which is an IPv6 address format with locator/ID separation useful for end to end multihoming. A 16 byte address of an end is separated into two 8 byte fields: locator, which is used to route packets to a link to which the end is attached, and ID, which is used to globally identify the end. Locators are assigned from (top level) ISPs to sites (and lower level ISPs) in hierarchical and aggregatable manner that a multihomed site (and ISPs) receive multiple locators from upstream ISPs. A usual host in a multihomed site (or a singly homed site under a multihomed ISP) is expected to have an ID and multiple locators and transport layer protocols are expected to handle multiple locators of the host and its peer. 1. Introduction & Terminologies This memo describes 8+8 address format, which is an IPv6 address format with locator/ID separation useful for end to end multihoming [ARCH]. A 16 byte address of an end is separated into two 8 byte fields: locator, which is used to route packets to a link to which the end is attached, and ID, which is used to globally identify the end. Locators are assigned from (top level) ISPs to sites (and lower level ISPs) in hierarchical and aggregatable manner that a multihomed site (and ISPs) receive multiple locators from upstream ISPs. M. Ohta Expires on July 15, 2004 [Page 1] INTERNET DRAFT 8+8 Addressing Janurary 2004 A usual host in a multihomed site (or a singly homed site under a multihomed ISP) is expected to have an ID and multiple locators and transport layer protocols are expected to handle multiple locators of the host and its peer. Multicast is not considered in this memo. Anycast is treated identically to unicast. The followings are terminologies used in this memo: 8+8 Address An address composed of an 8 byte locator and an 8 byte ID. Address 16 byte information to identify and locate an end. An end may have multiple addresses. Destination ID ID of a destination address Destination Locator Locator of a destination address End The primary unit, of the end to end principle [ARCHINTERNET], also called "end point" in [SALTZER]. ID 8 byte information to identify an end. An end may have multiple IDs. Locator 8 byte information to locate an end. An end may have multiple locators. Source ID ID of a source address Source Locator Locator of a source address 2. Address Format An 8+8 address format is identical to that of the existing IPv6 unicast address [ADDRARCH, UNIADDR] derived from EUI-64, except that it uses unused part of the IPv6 unicast address space. 2.1 Locator Format Locator format is identical to the upper 8 bytes of existing IPv6 unicast address [ADDRARCH, UNIADDR]. That is, as defined in [UNIADDR], a locator of an end have the M. Ohta Expires on July 15, 2004 [Page 2] INTERNET DRAFT 8+8 Addressing Janurary 2004 following format: | 3 | 45 bits | 16 bits | +---+---------------------+-----------+ |001|global routing prefix| subnet id | +---+---------------------+-----------+ 2.2 ID Format ID format is identical to the lower 8 bytes of existing EUI-64 based IPv6 unicast address [ADDRARCH, UNIADDR]. However, when an 8+8 address is viewed as an EUI-64 based address, individual/group bit of EUI-64 is turned on, which is not a case with a real EUI-64 based address. As a globally unique IEEE EUI-64 identifier has the following form: |0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |ccccccugcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+ and existing IPv6 interface identifier has the following form ("U" bit is a inversion of "u" bit): |0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |ccccccU0cccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+ an ID of an 8+8 address has the following form: |0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |ccccccU1cccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+ "U" bit is reserved and should be, for the time being, filled with 0 though either 0 or 1 should be accepted. See "3.1 Mobility Consideration" for possible use of the bit. 2.3 ID scope and semantics An ID is expected to be globally unique. An ID is to identify an end. As such, all the interfaces of an end share an ID(s) of the end, as if an EUI-64 address corresponding to the ID is shared by all the interfaces, which is consistent with [ADDRARCH, UNIADDR]. M. Ohta Expires on July 15, 2004 [Page 3] INTERNET DRAFT 8+8 Addressing Janurary 2004 2.4 ID Space Structure An ID of an end is structured to have hierarchical mapping by DNS from ID to DNS name of the end, just as IPv4 addresses under in- addr.arpa. If such mapping does not configured or wrongly configured, DNS-based confirmation of association between addresses and hostnames will not be available, which is the case of IPv4 addresses. 2.4.1 Locator Derived ID To ease initial assignment of IDs to ends, IDs may be derived from locators allocated to sites. An ID is a locator derived ID, if its first bit is 1. With a locator with the following format: | 3 | 45 bits | 16 bits | +---+---------------------+-----------+ |001|global routing prefix| subnet id | +---+---------------------+-----------+ or |0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |001rrrrrrrrrrrrr|rrrrrrrrrrrrrrrr|rrrrrrrrrrrrrrrr|ssssssssssssssss| +----------------+----------------+----------------+----------------+ a locator derived ID has the following format: |0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |1rrrrrU1rrrrrrrr|rrrrrrrrrrrrrrrr|rrrrrrrrrrrrrrrr|ssssssssssssssss| +----------------+----------------+----------------+----------------+ Reverse mapping of a locator derived ID of an end is performed under ipv6.arpa. domain, using locator format corresponding to the ID [IPV6DNS], though only 64 bits of the locator format are used to reach an PTR record corresponding to the locator format. That is, a site is assured to have 65,536 IDs assigned, though the locator nature of the ID makes IDs not stable against site renumbering. Note that ID assignment within a site can be arbitrary and will not be consistent of intra site link structure. That is, an end with a locator derived ID including a certain subnet id may be located anywhere in the site, not necessarily in the subnet corresponding to the subnet id. If one want to hide its privacy in ID, one should use locator derived M. Ohta Expires on July 15, 2004 [Page 4] INTERNET DRAFT 8+8 Addressing Janurary 2004 ID for one's ends. 2.4.2 Location Independent ID Location independent ID is introduced to overcome the difficulties of locator derived IDs, that locator derived IDs are location dependent a site can not be assigned IDs a lot more than 65,536. Location independent ID is, just like DNS names, assigned with logical structure independent of network topology, including site structure. That is, location independent IDs are assigned to organizations and individuals. As location independent ID space does not incur inefficiency due to route aggregation, entities equivalent to site is expected to be able to receive a lot more than 65536 IDs. An ID is a location independent ID, if its first bit is 0 and has the following structure. |0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |0cccccU1cccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+ Further details of operations and management of location independent IDs are TBD, though they should be almost identical to those for domain names, except that there is no trademark issues expected for 16 hexadecimal digits, which is not expected to be visible with most user interface. 3. Internetworking Layer Protocol At the Internetworking layer, an 8+8 address has no special meaning and packets containing 8+8 addresses in their IP headers is treated as a normal IPv6 packets for all the processing, including, but not limited to, forwarding by routers and ICMP [ICMPv6]. As is discussed in [ARCH], the Internetworking layer, having no notion of connection nor time out, has little to do with multihoming, except that IP addresses are part of transport layer identifiers. However, following subsections give some considerations for performance enhancements. 3.1 Mobility Considerations While [MIPV6] should work with 8+8 addressing as is, 8+8 addressing offers chance to have better mobility protocol. One is that DAD, which is the primary cause of delay of [MIPV6] is not seriously M. Ohta Expires on July 15, 2004 [Page 5] INTERNET DRAFT 8+8 Addressing Janurary 2004 unnecessary for globally unique ID. The other is that tunneling and associate MTU change of [MIPV6] can be eliminated if locators can be rewritten. [LIN6MOBI] is expected to exploit such possibilities. To mark a mobile end as mobile without first communicating with the end, "U" bit may be used. Further discussion on mobility is out of scope of site multihoming. 3.2 Destination Locator Selection A problem with end to end multihoming is that an end have multiple locators and proper locator must be chosen to reach the end. While [ADDRSELECT] tries to define some guideline for destination address (locator) selection, it is not very useful to select one from multiple global unicast addresses. If an end has no idea on what is the best destination address, selection should be at random. However, if an end have routing information, it can use it to determine which locator is unreachable and which locator have least metric (such as type 2 metric of OSPF) [ARCH]. To obtain metric information of external routes of IGP, BGP AS path length may be used as the metric. Or BGP administrators may adjust IGP metric more finely to control load of outgoing traffic. As end to end multihoming is expected to remove the only reason to bloat global routing table size, save laziness of assignment authorities, the global routing table of IPv6 should be kept small and all hosts should have default free full routing table for efficient selection of destination addresses. Note that an end should receive, but may not necessarily generate, routing information. While the Internetworking layer gives information on preference of locators, the Internetworking layer does not perform retransmission. Thus, if some locator fails, it is detected by a transport or an application layer and the layer takes care of retransmission with next best destination locator candidates. Implementations are encouraged to let upper layers look at the routing table for efficiency, which is not a layering violation. 3.3 Source Locator Selection While [ADDRSELECT] tries to define some guideline for source address (locator) selection, it is not very useful to select one from multiple global unicast addresses. Given highly asymmetric nature of Internet routing, a host basically has no knowledge on what is the best destination locator used by its M. Ohta Expires on July 15, 2004 [Page 6] INTERNET DRAFT 8+8 Addressing Janurary 2004 peer for reply. In this sense, source locator selection is not necessary and source locator can be chosen randomly. However, source locator selection becomes important for ingress filtering on source addresses, in which case, proper source locator corresponding to a destination locator must be chosen. Otherwise, most packets will be filtered and a lot of time is wasted for a transport or an application protocol retransmit and find the proper source locator. As is discussed in [ARCH], such corresponding can be best obtained from proper routing protocol. For example, with OSPFv6, locator part of forwarding address field of AS-external-LSA can designate the locator for the LSA. When routing protocols supply source locator, source locator selection is performed purely by the Internetworking layer without involving inefficient retransmission by a transport or an application layer. 4. Transport and Application Layer Protocols For backward compatibility, if either a source or a destination address is not an 8+8 address, transport and application layer protocols behave as if it is a legacy end. Otherwise, that is, if both source and destination address are 8+8 addresses, transport layer protocols ignore source and destination locators, except for security and performance enhancement. That is, transport layer protocols does not use the locators for checksum and identify their connections using IDs only. As is discussed in the previous section, a transport or an application protocol is responsible for selection of destination locator and associated retransmission. However, as is discussed in [ARCH], such retransmission dependent on the nature of applications that no generic mechanism can be discussed in this memo. Each application has different notion of connection or loss of it that it is not meaningful to give a generic time out value. Nevertheless, as is discussed in [ARCH], TCP has defact default timeout values. So, it is possible to have generic TCP with default behavior for locator selection and retransmission. It should be noted that most applications over the Internet works over TCP and that such applications can run with end to end multihoming without modifying application programs. In addition, as DNS is a basic infrastructure and has its own timeout values, it is necessary to investigate possible modifications to DNS with end to end multihoming. M. Ohta Expires on July 15, 2004 [Page 7] INTERNET DRAFT 8+8 Addressing Janurary 2004 4.1 Modification to TCP A new TCP option, Multi Address option, is introduced. +--------+--------+---------+ |????????|00000011| # of LOC| +--------+--------+---------+ Kind=? Length=3 Kind is to be assigned by IANA. The option has one argument, the number of locators, value of which must be between 1 and 9. If the option appears in a TCP header, data field just after the TCP header contains, with network byte order, locators of the source host, the number of which is specified by the argument. It is expected that 9 locators are enough for most ends, as a site of the end can be multihomed to three lower level ISPs each multihomed to 3 top level ISPs. However, if an end has more than 9 locators, which is a case with routers with more than 9 interfaces, TCP or upper layer modules should be responsible to select 9 or less locators to be used for the TCP connection. All TCP modules of ends supporting 8+8 addressing must recognize the Multi Address option. TCP modules memorize current most source locators of its peer and reject TCP packets with unknown source locators. TCP modules should have interface to application modules to let the application modules check whether the set of locators supplied by the Multi Address option is valid or not. Multi Address options must be used by packets for the initial three way handshaking and may appear in any other TCP packet. Multi address option is also useful for performance reasons. Note that, as route of the Internet is highly asymmetric, a source locator of a packet, which is chosen for ingress filtering, may not work for reply that it is essential to provide all the candidate locators for the reply. In addition, when SYN times out, TCP should retry with new destination locators. When SYN ACK times out, TCP should retry with new destination locators contained in a set of locators provided by Multi Address option of SYN packet. Thus, with N locators, it is expected that O(N), not O(N*N), attempt is enough to find a working pair of source and destination locators. If TCP modules detect SYN flood attack, they do not have to allocate state for SYN packets to memorize the set of locators in the Multi Address option of the packets. Instead, it should randomly choose one from the Multi Address option of the SYN packet. M. Ohta Expires on July 15, 2004 [Page 8] INTERNET DRAFT 8+8 Addressing Janurary 2004 4.2 Modification to DNS As is discussed in [ARCH], DNS tries all the addresses of name servers that it is already an application with end to end multihoming. A problem is that unlike TCP, DNS servers do not expect acknowledgment and do not retransmit. So, if a client can not get a response, it should retry with alternative destination locators of a server with corresponding source locators. But, even if the server somehow knows all the locators of the client, the server send just one reply and does not try all of them. Thus, with N locators and in the worst case, O(N*N) attempt is necessary to find a working pair of locators. But, the problem is not serious, because usual clients of DNS today, gives up with small number of attempts and because there are multiple servers are provided for each zone. 4.3 8+8 Adaptation Layers for Applications over TCP and DNS The 8+8 adaptation layers make end to end multihoming invisible to applications over TCP and DNS, that is, applications using TCP transport only without hard coded IP addresses. Some multihoming proposals try to introduce an adaptation layer in the Internetworking layer to hide locator changes. However, this attempt does not make sense. As demonstrated by NAT, rewriting of addresses is, in general, not transparent to transport and application protocols. For example, transport layer checksum computation involves IP addresses and is different for each transport protocol that address rewriting can not be confined in the Internetworking layer. Insertion or deletion of IP headers affects MTU, which is also visible to the transport layer. Applications like FTP transmit raw addresses in application data streams. However, it is possible to confine modifications in 4.1 in TCP and let applications get a fixed locator (LIN6 locator) [LIN6ARCH]. In addition, it is possible to modify DNS library to let such applications get addresses with the LIN6 locator. Then, it is possible to make end to end multihoming invisible from applications over TCP and DNS, including applications transmit raw addresses in application data streams. 5. Assessment Against RFC3582 Redundancy Fully supported. That is, ends should be able to keep communicating against all failure modes of locators as long as a pair of working source and destination locators exists, though details are transport and application layer dependent. Load Sharing, Performance M. Ohta Expires on July 15, 2004 [Page 9] INTERNET DRAFT 8+8 Addressing Janurary 2004 Fully supported. That is, if site administrators elaborate on BGP configuration, they have as much control as possible with BGP. Site administrators, instead, can just rely on ASpathlen, in which case, there will be no configuration effort. Policy Fully supported. If a site is multihomed to ISP A and B and an end has locators of ISP A only, all traffic to the end will be through ISP A. Traffic from the end can be controlled by policy of accepting route. Simplicity As for deployment, the proposal fully interoperate with legacy systems. Applications over TCP and DNS does not need any coding changes. As for operation, as long as IDs may change with rehoming, it is as simple as the current IPv4 multihoming practices. Transport-Layer Survivability Fully supported, though details are transport layer specific, of course. Impact on DNS The proposal is fully compatible with the observed dynamics of the current DNS. Packet Filtering The proposal is compatible with packet filtering on source addresses. Scalability Fully scales. That is, the number of multihomed site does not affect the number of routing table entries. Impact on Routers Nothing, except that routers may have 8+8 addresses and behave accordingly. Impact on Hosts Communications with legacy hosts is kept unchanged, though most, if not all, the benefit of multihoming will be lost. API of applications using TCP and DNS remain unchanged and the applications can still enjoy full multihoming support. Applications over UDP, where all the packets can and must be controlled by "user", need changes, if it want transport-layer survivability (even the meaning of "transport-layer survivability" is defined by the "user"). Otherwise, the current transport-layer protocol may be used as is. Interaction with Hosts and Routing System. Ends expect to passively receive routing information from the routing system, which is simple, scalable and securable. M. Ohta Expires on July 15, 2004 [Page 10] INTERNET DRAFT 8+8 Addressing Janurary 2004 Operations and Management Site's multihoming system, with the proposal, is site's routing system that it is possible for staff responsible for the operation of a site to monitor and configure it. Cooperation between Transit Providers No cooperations are required. Multiple Solutions Proposal contains a single solution only. Security Considerations Multihomed sites and ends are not more valunerable to traditional IPv4-multihomed sites and ends. Routing practice change to carry source locator does not affect security of non multihomed site. 6. References [ADDRARCH] R. Hinden, S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC3513, April 2003. [ADDRSELECT] R. Draves, "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC3484, February 2003. [ARCH] M. Ohta, "The Architecture of End to End Multihoming", Work in Progress as , June 2003. [ARCHINTERNET] B. Carpenter, Ed., "Architectural Principles of the Internet", RFC1958, June 1996. [ICMPv6] A. Conta, S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998. [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [IPV6DNS] S. Thomson, C. Huitema, V. Ksinant, M. Souissi, "DNS Extensions to Support IP Version 6", RFC3596, October 2003. [LIN6ARCH] [LIN6MOBI] [UNIADDR] R. Hinden, S. Deering, E. Nordmark, "IPv6 Global Unicast Address Format", RFC3587, August 2003. 7. Security Considerations The Internetworking is identical to the legacy IPv6 that there is no new security concern. The transport layer is modified that there is possibility of wrongly M. Ohta Expires on July 15, 2004 [Page 11] INTERNET DRAFT 8+8 Addressing Janurary 2004 recognized source locator and transmit a lot of packets to wrong places. While details of source locator authentication and packet retransmissions are transport and application dependent, there can be some guideline to prevent the problem. When a packet arrives with a source locator, the validity of the locator can be confirmed with reasonable security with three way handshaking or cookies. When a packet arrives with multiple locators, the validity of one of a locator can still be confirmed with reasonable security with three way handshaking or cookies. As long as all the locators are contained in a single packet, it is reasonable to treat the set of the locators have reasonable security. As the destination locator of reply packet is chosen by the replying host and retransmission is expected to be infrequent, DoS attack using the multiple locators for reply is only as efficient as DoS attack with single locators. TCP modification in 4.3 is expected to work this way. However, to avoid interference between connections, each connection module should maintain the set of locators separately even if several connections exists to a single ID. 8. Author's Address Masataka Ohta Graduate School of Information Science and Engineering Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3299 EMail: mohta@necom830.hpcl.titech.ac.jp M. Ohta Expires on July 15, 2004 [Page 12] From owner-multi6@ops.ietf.org Thu Jan 15 01:32:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02575 for ; Thu, 15 Jan 2004 01:32:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ah120-000F2B-1k for multi6-data@psg.com; Thu, 15 Jan 2004 06:31:04 +0000 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ah11k-000F0s-3U for multi6@ops.ietf.org; Thu, 15 Jan 2004 06:30:48 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0F6UeJW072572; Thu, 15 Jan 2004 06:30:40 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0F6UdNA198620; Thu, 15 Jan 2004 07:30:40 +0100 Received: from zurich.ibm.com ([9.145.246.84]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id HAA27990; Thu, 15 Jan 2004 07:30:34 +0100 Message-ID: <4005AF5D.E80C103@zurich.ibm.com> Date: Wed, 14 Jan 2004 22:06:37 +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 Subject: Re: I-D ACTION:draft-van-beijnum-multi6-odt-00.txt References: <200401122104.QAA19034@ietf.org> <4004E7E2.87AED19A@zurich.ibm.com> <7F8E9C12-4692-11D8-815B-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On 14-jan-04, at 7:55, Brian E Carpenter wrote: > > > 1. It seems to me that if you ignore the way each of them is > > described, there is actually a very strong resemblance between ODT and > > NOID. In effect they both treat the first address used for a session > > as the ID, and dynamically switch to using alternative addresses as > > the locator, with a stateful shim concealing the switch from upper > > layer protocols. Am I confused? > > Yes, this part is the same. However, I wouldn't say that > > > the crude description of ODT is as a degenerate case of NOID. No, I didn't think you would say that :-) But I think when we start the architectural analysis, ODT and NOID will come out very similar. > > The shim idea wasn't new in NOID either. > Certainly not. > I didn't include address rewriting in routers in ODT because although > the idea is very interesting, I don't think the potential gain is big > enough to justify all the additional trouble. And that is an architectural choice the WG may have to make at some point. > Also, NOID uses a > three-way handshake while ODT uses a model where each end announces > information to the other end that may or may not be ignored. Yes, so the state machines are a bit different too. > > > 2. One remark that I really don't understand: > > >> 8 Tunnel Creation > > ... > >> 1. Host A announces its addresses to host B > > >> The addresses may be of different address families. Each address > >> is > >> accompanied by preference information. In order to not > >> unnecessarily > >> trigger NAT incompatibility, a "current source address" address > >> family is used to refer to the source address in the IP packet, > >> which may have been rewritten. > > > Firstly, we aren't designing for IPv6 NATs, so this would only apply > > to the IPv4 case, right? > > I hope so. :-) > > > But in any case, I don't see how it helps. You > > can't tell by looking at an address whether it's been rewritten, so > > you can't tell if it's OK for checksum purposes. > > Which checksum do you mean here? Any, really. We use addresses in TCP checksums or crypto checksums, and when they get NATted things break unless somebody knows to recreate the checksum. Brian From owner-multi6@ops.ietf.org Thu Jan 15 01:32:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02593 for ; Thu, 15 Jan 2004 01:32:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ah12F-000F3E-WB for multi6-data@psg.com; Thu, 15 Jan 2004 06:31:19 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ah122-000F2H-7i for multi6@ops.ietf.org; Thu, 15 Jan 2004 06:31:06 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0F6Uue2085160; Thu, 15 Jan 2004 06:30:56 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0F6UtoA240862; Thu, 15 Jan 2004 07:30:55 +0100 Received: from zurich.ibm.com ([9.145.246.84]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id HAA52946; Thu, 15 Jan 2004 07:30:47 +0100 Message-ID: <4005B2EC.43CC2B4A@zurich.ibm.com> Date: Wed, 14 Jan 2004 22:21:48 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Nikander CC: multi6@ops.ietf.org, jari.arkko@piuha.net Subject: Re: [Hipsec] RE: Updated HIP mobility & multi-homing draft References: <3FF5576D.9020506@piuha.net> <4002BA3B.5107C3E4@zurich.ibm.com> <0827D266-46B3-11D8-86DC-000393CE1E8C@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Pekka Nikander wrote: > > Brian, > > Thanks a lot on your comments. > > >> ... the other host can > >> alternate between IPv4 and IPv6 without any effects on the upper > >> layer protocols. > > > > The last phrase isn't strictly true IMHO. If a change of path changes > > the MTU or the QoS, this can have an effect on the ULP, especially for > > real time applications. > > I changed this to read: > > ... the other host can alternate > between IPv4 and IPv6, without needing to tear down and > re-establish upper layer protocol connections or associations. > In other words, the way upper layer protocols need to react to > cross-IP-version handovers does not differ from the way they > needs to react intra-IP-version handovers. > > Better? Fine, thanks > > > > >> 4.1 End-host mobility > > ... > >> The upper > >> layer protocols need to know about the address and connectivity > >> change only for QoS and other similar purposes. > > > > Not necessarily. The QoS management system may need to know, depending > > on the QoS mechanisms in use - and that is a control plane, not a > > ULP. > > I'm afraid I don't quite understand your comment. Anyway, I changed > the text to read > > The upper layer protocols do not > need to know about the address and connectivity change > but perhaps to react to changed QoS, MTU, or for other > similar purposes. In most cases, they do not need to > know. > > Any better? That is fine. What I meant is that in many implementations of diffserv QOS, the socket user knows nothing about it - a QOS manager of some kind is strapped onto the side of the IP stack and directs the IP stack to apply different diffserv treatments to different sockets. And actually when the path changes the QOS manager may well care (because different paths may have different QOS capabilities). > > > Hmm. I find the whole treatment of "interfaces" confusing. As you > > describe > > them, they don't correspond to physical interfaces or to virtual > > interfaces > > such as tunnel end points. They are only collections of addresses, > > which > > you choose to group for SPI purposes. That may or may not be a useful > > thing, > > but it would be much less confusing to use a different word instead > > of overloading "interface." > > I changed the term to "Address Group", and updated the rest of the > spec accordingly. Yes, I really find that much clearer. > > >> Note, > >> however, that especially in the case of site multi-homing one of > >> the > >> addresses may become unreachablewhile the other one still works. > >> In > >> the typical case, however, this does not require the host to inform > >> its peers about the situation, since even the non-working address > >> still logically exists. > > > > It's just as well you don't require this notification. The last node to > > know that an address is unreachable is the node that address belongs > > to. > > Unreachability is discovered at the other end of the multihomed > > session. > > Thanks. I'll try to note this in the other draft; I don't see how > this would be formulated here. > > >> The readdressing protocol is designed to be piggybacked on a number > >> of existing HIP exchanges. ... > >> > >> The protocol is an asymmetric protcool where one host, called the > >> Mobile Host, informs another host, called the Peer host, about > >> changes of IP addresses on one of its interfaces. > > > > That doesn't help with multihoming, since the host doesn't know about > > its own address changes due to sudden unreachability. > > While I agree with your comment, I'm afraid I don't quite see the > point. The assumption is that the HIP hosts announce their > multi-homing situation as soon as they create HIP associations, > modulo possible privacy and policy concerns. Hence, when a host > becomes unreachable through one of its addresses, its peers already > know about the other potential addresses. OK, maybe I read your text too quickly. In general multi6 needs to think a bit about what actually triggers a multihoming switch. > > Should I discuss this in the forthcoming -nikander-multi6-hip- > draft? Yes, I think it fits there. > > Section 8.4 Changing the preferred address mentions that: > > > A host MAY want to change the preferred outgoing address for many > > reasons, e.g., because traffic information or ICMP error messages > > indicate that the currently used preferred address may have become > > That is meant to cover the case where ULP information, such as TCP > timeouts, indicate that the preferred address needs to be changed. > But maybe the term "traffic information" is inaccurate and should be > replaced with something better. Any suggestions? At this stage I would stick to something quite general. This is going to be a question for all solutions, I think. Regards Brian From owner-multi6@ops.ietf.org Thu Jan 15 04:52:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22019 for ; Thu, 15 Jan 2004 04:52:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ah47Q-0009B4-2i for multi6-data@psg.com; Thu, 15 Jan 2004 09:48:52 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ah47B-00099P-6W for multi6@ops.ietf.org; Thu, 15 Jan 2004 09:48:37 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0F9mLkw036195; Thu, 15 Jan 2004 10:48:21 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4005AF5D.E80C103@zurich.ibm.com> References: <200401122104.QAA19034@ietf.org> <4004E7E2.87AED19A@zurich.ibm.com> <7F8E9C12-4692-11D8-815B-000A95CD987A@muada.com> <4005AF5D.E80C103@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: I-D ACTION:draft-van-beijnum-multi6-odt-00.txt Date: Thu, 15 Jan 2004 10:48:32 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 14-jan-04, at 22:06, Brian E Carpenter wrote: >> I didn't include address rewriting in routers in ODT because although >> the idea is very interesting, I don't think the potential gain is big >> enough to justify all the additional trouble. > And that is an architectural choice the WG may have to make at some > point. Yes. I think it helps to have non-too-dissimilar approaches that do and don't include this to be able to see what the consequences of including it are. >>> But in any case, I don't see how it helps. You >>> can't tell by looking at an address whether it's been rewritten, so >>> you can't tell if it's OK for checksum purposes. >> Which checksum do you mean here? > Any, really. We use addresses in TCP checksums or crypto checksums, > and when > they get NATted things break unless somebody knows to recreate the > checksum. I thought I was reasonably clear about this... In order to maintain compatibility with most hardware checksum calculation offload mechanisms, the TCP and UDP checksums are always recomputed such that each TCP or UDP packet has a valid checksum as computed using the addresses present in the packet. Non-TCP and -UDP packets aren't changed because in this case the ODT implementation would have to be aware of *every* upper layer protocol. The ODT hash/checksum is only calculated over the ODT header, so the addresses are irrelevant here. IPsec authentication information isn't changed by ODT, but IPsec processing at the receiver happens after ODT has replaced the outer / locator addresses with the inner / identifier addresses so this doesn't affect regular IPsec operation. Obviously someone in the middle who does know the keys but isn't aware of ODT will see IPsec AH packets with invalid hashes. As for NAT+ODT+IPsec, this isn't going to be easy. If the initial session is NATed, then IPsec won't really work but that's old news. So let's assume the initial session uses public addresses and only the backup address for one host is NATed. So: - host A has initial (public) address A1 and backup (NATed) address A2 which B sees as X - host B has initial (public) address B1 and backup (public) address B2 When ODT kicks in, B announces B2 to A1 and A announces A2 as an implicit address to B1, so B sees X. (Aside: will the NAT box do its thing for sessions for which it hasn't seen the initial SYN?) A checks out B by sending A1 -> B1, A1 -> B2, A2 -> B1, A2 -> B2. B replies with B1 -> A1, B2 -> A1, B1 -> X, B2 -> X. (Hm, rethink this, maybe all the replies shoud be B1 -> A1.) Then B initiates the same thing the other way around. So after 18 packets have been sent A knows which addresses of B it can reach from which of its own addresses, and which source/destination combos B is prepared to handle. The same the other way around. If A and B are now communicating using IPsec but A1 -> B1 stops working, A may try A2 -> B2. So the TCP layer on A generates a packet with an A1, B1 TCP checksum, and an A1, B1 IPsec AH hash. The ODT layer picks up this packet and slaps on the addresses A2, B2. If the packet is encrypted using IPsec ESP, that's the end of it as the resulting packet isn't TCP or UDP (anymore). However, if only IPsec AH is used, the TCP header is still visible so the TCP checksum is recalculated with A2, B2 in the pseudo header. The packet is transmitted and then ends up in the NAT box. The NAT box replaces A2 with X and also recalculates the TCP checksum. Then the packet is received by B. If B employs checksum offload in the NIC, the NIC sees a valid X, B2 checksum. The ODT layer recognizes the X, B2 address pair and remaps this to A1, B1. The TCP checksum is updated to reflect the address change. Then the packet is handed off to the IPsec layer. IPsec AH is done over the packet and succeeds because all the fields defined as immutable that were in fact mutated were changed back to their original values. From owner-multi6@ops.ietf.org Thu Jan 15 10:08:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09912 for ; Thu, 15 Jan 2004 10:08:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ah948-000FWw-J8 for multi6-data@psg.com; Thu, 15 Jan 2004 15:05:48 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ah93u-000FSd-8Z for multi6@ops.ietf.org; Thu, 15 Jan 2004 15:05:34 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 08CA87498; Thu, 15 Jan 2004 16:05:33 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id E82DC74A1; Thu, 15 Jan 2004 16:05:32 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Brian E Carpenter" , "Multi6" Subject: RE: I-D ACTION:draft-van-beijnum-multi6-odt-00.txt Date: Thu, 15 Jan 2004 15:58:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4004E7E2.87AED19A@zurich.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Brian, > 1. It seems to me that if you ignore the way each of them is > described, there > is actually a very strong resemblance between ODT and NOID. In > effect they both > treat the first address used for a session as the ID, and > dynamically switch > to using alternative addresses as the locator, with a stateful > shim concealing > the switch from upper layer protocols. Am I confused? > > The only real difference is that NOID turns out to need a rewrite > OK/Not OK flag > in the IP header and ODT doesn't, but it does need an ODT > protocol exchange. > (Which has the consequence that ODT claims to work for IPv4 too.) > > If NOID didn't include the case of a router doing the rewrite in > flight, it > wouldn't need that flag anyway. So the crude description of ODT is as a > degenerate case of NOID. > > I think the security issues are therefore very similar too. In fact > the discussion between Iljitsch and Marcelo would largely apply to > NOID. I am not sure about this NOID ODT similarity... IMHO the big difference is the mechanism to validate addresses to be used in a communication. ODT by design beleives the addresses that the other end of the communication claims to have as its own addresses. Moreover, an add address mesage can be sent and accepted if properly validated by a return routability like procedure. NOID is IMHO conceptually very different (perhaps in practice the difference it is not so big, i'll come back later) In NOID, the valid addresses of an endpoint are obtained from a trusted third prty i.e. the DNS So a NOID endpoint doesn't has to beleive what the other endpoint is claiming to have as available addresses, but it contacts the third party and obtains the addresses from it. (Note that even when the "server" node (lack of a better way to call it) also verifies the addresses from the "client" node against the DNS through a reverse+direct lookup) That is, IMHO, the trust model is completely different. However, the DNS is also susceptible to time shifted attacks. i.e. if you fake the DNS query you can store malicious state in a host. But, this is already here now in fixed IPv4 internet, so not a new attack here. Besides, NOID allows that when secure DNS is available the security of the solution improves. In summary, IMHO the concepts are quite different and the trust model is quite different. In practice, the real attacks can be similar. I find ODT much more similar to a MIP style solution, where all the nodes are peers and you have to trust to all the nodes that you talk with. Regards, marcelo > > 2. One remark that I really don't understand: > > > 8 Tunnel Creation > ... > > 1. Host A announces its addresses to host B > > > > The addresses may be of different address families. Each address is > > accompanied by preference information. In order to not unnecessarily > > trigger NAT incompatibility, a "current source address" address > > family is used to refer to the source address in the IP packet, > > which may have been rewritten. > > Firstly, we aren't designing for IPv6 NATs, so this would only apply > to the IPv4 case, right? But in any case, I don't see how it helps. You > can't tell by looking at an address whether it's been rewritten, so > you can't tell if it's OK for checksum purposes. So the fact that you > know an address *might* have been rewritten is no use, as far as > I can see. > The only useful information is to know for sure what the address was at > the source, without even caring whether it has been rewritten in the > active IP header. And in ODT (as in NOID) that information is in local > state at the destination. > > Brian > > > From owner-multi6@ops.ietf.org Fri Jan 16 16:42:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00932 for ; Fri, 16 Jan 2004 16:42:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ahbhk-0004Eu-6r for multi6-data@psg.com; Fri, 16 Jan 2004 21:40:36 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AhbhW-0004E2-8K for multi6@ops.ietf.org; Fri, 16 Jan 2004 21:40:22 +0000 Received: (qmail 58604 invoked from network); 16 Jan 2004 21:48:18 -0000 Received: from h219-110-033-052.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.52) by necom830.hpcl.titech.ac.jp with SMTP; 16 Jan 2004 21:48:18 -0000 Message-ID: <40085A7B.30202@necom830.hpcl.titech.ac.jp> Date: Sat, 17 Jan 2004 06:41:15 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Multi6 List Subject: threats ID Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Below is a threats analysis draft ID. Masataka Ohta -- INTERNET DRAFT M. Ohta draft-ohta-multi6-threats-00.txt Tokyo Institute of Technology January 2004 Threats Relating to Transport Layer Protocols Handling Multiple Addresses Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document lists security threats related to IPv6 multihoming solutions, transport layer protocols of which are expected to handle multiple addresses of a host and an identity of the host is recognized not necessarily by a single address. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure than the current Internet, without studying any proposed solution but instead looking at threats that are inherent in the problem itself. 1. Security Considerations With the current Internet, most transport layer protocols identifies a host with a single address. However, for scalable multihoming, transport layer protocols are expected to handle multiple addresses of a host and an identity of the host is recognized not necessarily by a single address. Then, there are four new possibility of security threats. Connection Hijacking with False Peer Address hosts in multihomed sites may be supplied a false peer address from an attacker, which redirect existing connection to a wrong location. New DDoS Opportunity with False Source Information M. Ohta Expires on July 15, 2004 [Page 1] INTERNET DRAFT Security Threats January 2004 hosts may be used for distributed DoS to damage the rest of the Internet New DoS Opportunity on Identification depending on a way to identify a host, the host may be subject to DoS Privacy on Identification depending on a way to identify a host, hosts may not be able to hide its privacy The following subsections analyze the threats with or without MITM (Man in the Middle). 1.1. Connection Hijacking with False Peer Address If a host has connected communicating with a peer, and if a transport layer protocol allows dynamic address set change during a connection, an attacker may be able to supply false information on source address of the peer to the host to hijack the connection. On the current Internet, where connections are identified by a pair of addresses, which is fixed during connection, this kind of attack is not possible at the transport layer. However, similar attack is possible at upper layers. For example, an attacker may rewrite URLs in HTML text over HTTP over TCP to hijack a web browsing session. Or, an attacker may rewrite DNS reply of IP addresses during URL resolution or at the initiating phase of an application layer connection. As a protection against such attacks, transport and/or upper layer protocols use cookie or cookie like information, such as randomized port number, TCP sequence number, DNS message id and so on. Without assuming MITM, existing transport and/or upper layer protocols using cookie or cookie like information can be naturally extended as a reasonable protection against connection hijacking by false source information. Of course, cookie is powerless against MITM and once a forged source address, URL or DNS answer is supplied by MITM, the effect will be persistent even after the MITM goes away. If transport layer protocols handling multiple addresses of a host does not have cookie or cookie like mechanism at least as strong as that of TCP and still allow dynamic address set change during connection, there will be a new security threat of connection hijacking. 1.2. New DDoS Opportunity with False Source Information On the current Internet, an attacker can send a packet with forged source address expecting that a reply packet is sent to host of the source address, as DDoS attack to the host. There often is some amplification possible. For example, DNS reply is often a lot longer M. Ohta Expires on July 15, 2004 [Page 2] INTERNET DRAFT Security Threats January 2004 than query. The attacked host has no way to know the location of the attacker from the attacking packets, sender of which often does not even have logging. Transport layer protocols handling multiple addresses of a host is subject to similar attack. If transport layer protocols handling multiple addresses of a host has DoS amplification property worse than the current Internet hosts, there will be the existing security threat of DDoS will be more serious. 1.3. New DoS Opportunity on Identification If a host has an identification involves computationally expensive security mechanism, it can be used for DoS attack to the host. On the current Internet, cookie is exchanged before performing the computationally expensive process, though mere holding of cookie information can be expensive operation as exemplified by TCP SYN flooding. Cookie protection, of course, is powerless against MITM. If transport layer protocols having new connection identification mechanism does not support initial cookie exchange, there will be a new security threat of DoS. 1.4. Privacy on Identification If transport layer protocols having new connection identification requires hosts having persisting identification information, it will be used to track the identify of the host, which is a new security threat. 2. Author's Address Masataka Ohta Graduate School of Information Science and Engineering Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3299 EMail: mohta@necom830.hpcl.titech.ac.jp M. Ohta Expires on July 15, 2004 [Page 3] From owner-multi6@ops.ietf.org Mon Jan 19 08:29:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15869 for ; Mon, 19 Jan 2004 08:29:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AiZOi-000G0A-AW for multi6-data@psg.com; Mon, 19 Jan 2004 13:24:56 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AiZOL-000Fyf-QQ for multi6@ops.ietf.org; Mon, 19 Jan 2004 13:24:34 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0JDNupS082188; Mon, 19 Jan 2004 13:23:56 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0JDNsmx095008; Mon, 19 Jan 2004 14:23:55 +0100 Received: from zurich.ibm.com ([9.145.148.182]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA25100; Mon, 19 Jan 2004 14:23:50 +0100 Message-ID: <400BDA22.B2CFED56@zurich.ibm.com> Date: Mon, 19 Jan 2004 14:22:42 +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: Masataka Ohta CC: Multi6 List Subject: Re: threats ID References: <40085A7B.30202@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks. Since this is fairly short, I hope we can integrate it in draft-nordmark-multi6-threats-00.txt if people agree with your analysis. Brian Masataka Ohta wrote: > > Below is a threats analysis draft ID. > > Masataka Ohta > -- From owner-multi6@ops.ietf.org Mon Jan 19 13:06:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00136 for ; Mon, 19 Jan 2004 13:06:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AidkR-000I19-GN for multi6-data@psg.com; Mon, 19 Jan 2004 18:03:39 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aidk5-000Hwo-UK for multi6@ops.ietf.org; Mon, 19 Jan 2004 18:03:18 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CD0DF61E9; Mon, 19 Jan 2004 19:03:16 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp03.uc3m.es (Postfix) with SMTP id B7B9161BC; Mon, 19 Jan 2004 19:03:16 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Brian E Carpenter" , "Masataka Ohta" Cc: "Multi6 List" Subject: RE: threats ID Date: Mon, 19 Jan 2004 18:55:40 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <400BDA22.B2CFED56@zurich.ibm.com> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, IMHO both drafts complement themselves pretty well because Erik & Tony's draft essentially analyze the threats from a IP layer perspective and Masataka's draft analize the threats from a transport layer perspective. After some mail exchanges with Pekka N., my understanding is that that there is an important distinction to be made between these two cases when considering the hijacking attack. The point is that in transport layer solutions, the hijcack attack is limited to the existent established connection while in the IP layer (shim layer also) solutions the attack applies to the complete endnode. Because the attack applies to the endnode, the attacker can do things like establishing aconnection creating some state so that futuer communications initated by the victim are also redirected. That is in IP layer solutions the complete identity of the victim is hijacked for all the applications and for all the communications, pre-establihed or future communications (as long as the malicous state exists in the victim) This implies that the risk is very different in one case than in the other one and different security solutions are required. So I guess that i agree with Masataka that a return routability check with a cookie is enough to redirect a connection but IMHO this is not enough to redirect a complete identity at the IP layer level. I mean time shifting attacks may be acceptable as long they can only affect a connection. Regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Brian E Carpenter > Enviado el: lunes, 19 de enero de 2004 14:23 > Para: Masataka Ohta > CC: Multi6 List > Asunto: Re: threats ID > > > Thanks. Since this is fairly short, I hope we can integrate > it in draft-nordmark-multi6-threats-00.txt if people agree > with your analysis. > > Brian > > Masataka Ohta wrote: > > > > Below is a threats analysis draft ID. > > > > Masataka Ohta > > -- > > > From owner-multi6@ops.ietf.org Mon Jan 19 19:43:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20174 for ; Mon, 19 Jan 2004 19:43:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AijxS-0005C5-Ap for multi6-data@psg.com; Tue, 20 Jan 2004 00:41:30 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AijxF-0005BF-Lm for multi6@ops.ietf.org; Tue, 20 Jan 2004 00:41:17 +0000 Received: (qmail 71462 invoked from network); 20 Jan 2004 00:50:12 -0000 Received: from h219-110-033-058.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.58) by necom830.hpcl.titech.ac.jp with SMTP; 20 Jan 2004 00:50:12 -0000 Message-ID: <400C796A.8070905@necom830.hpcl.titech.ac.jp> Date: Tue, 20 Jan 2004 09:42:18 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Brian E Carpenter , Multi6 List Subject: Re: threats ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marcelo; > IMHO both drafts complement themselves pretty well because Erik & Tony's > draft essentially analyze the threats from a IP layer perspective and > Masataka's draft analize the threats from a transport layer perspective. The problem for Erik and Tony, then, is that IP layer of multi6 is no different from the current one. > After some mail exchanges with Pekka N., my understanding is that that there > is an important distinction to be made between these two cases when > considering the hijacking attack. Good. Can you answer the following simple question? What, do you think, is being hijacked? Connections? Note that, unless you extensibly modify IP layer, there is no connections there. > The point is that in transport layer > solutions, the hijcack attack is limited to the existent established > connection while in the IP layer (shim layer also) solutions the attack > applies to the complete endnode. Wrong. Attack is always applied to the end. > Because the attack applies to the endnode, > the attacker can do things like establishing aconnection creating some state > so that futuer communications initated by the victim are also redirected. Establishing a connection is a functionality of the transport layer. > That is in IP layer solutions the complete identity of the victim There is no IP layer solutions. Just like NAT operates not only at the IP layer but also at the transport and applicaiton layers, shim layers are not only at the IP layer. > So I guess that i agree with Masataka that a return routability check with a > cookie is enough to redirect a connection but IMHO this is not enough to > redirect a complete identity at the IP layer level. > I mean time shifting attacks may be acceptable as long they can only affect > a connection. "Time shifting attack" is meaningful if only there is persistent relationship, that is connection, that it is not at the connectionless layer. Masataka Ohta From owner-multi6@ops.ietf.org Mon Jan 19 19:44:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20327 for ; Mon, 19 Jan 2004 19:44:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AijzT-0005Ud-LM for multi6-data@psg.com; Tue, 20 Jan 2004 00:43:35 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AijzG-0005Rb-L0 for multi6@ops.ietf.org; Tue, 20 Jan 2004 00:43:22 +0000 Received: (qmail 71472 invoked from network); 20 Jan 2004 00:52:17 -0000 Received: from h219-110-033-058.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.58) by necom830.hpcl.titech.ac.jp with SMTP; 20 Jan 2004 00:52:17 -0000 Message-ID: <400C79E8.1000404@necom830.hpcl.titech.ac.jp> Date: Tue, 20 Jan 2004 09:44:24 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 List Subject: Re: threats ID References: <40085A7B.30202@necom830.hpcl.titech.ac.jp> <400BDA22.B2CFED56@zurich.ibm.com> In-Reply-To: <400BDA22.B2CFED56@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > Thanks. Since this is fairly short, I hope we can integrate > it in draft-nordmark-multi6-threats-00.txt if people agree > with your analysis. My draft, IMHO, is not only short but also denies most, if not all, of the points of "draft-nordmark-multi6-threats-00.txt", that simple replacement is just enough. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 20 00:26:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02160 for ; Tue, 20 Jan 2004 00:26:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AioMx-0004ke-6c for multi6-data@psg.com; Tue, 20 Jan 2004 05:24:07 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AioMk-0004k1-CT for multi6@ops.ietf.org; Tue, 20 Jan 2004 05:23:54 +0000 Received: from [IPv6:::1] (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 685591C; Tue, 20 Jan 2004 07:36:43 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Brian E Carpenter" , "Masataka Ohta" , "Multi6 List" From: Pekka Nikander Subject: Re: threats ID Date: Tue, 20 Jan 2004 07:23:57 +0200 To: X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marcelo, On Jan 19, 2004, at 19:55, marcelo bagnulo wrote: > After some mail exchanges with Pekka N., my understanding is that that > there > is an important distinction to be made between these two cases when > considering the hijacking attack. The point is that in transport layer > solutions, the hijcack attack is limited to the existent established > connection while in the IP layer (shim layer also) solutions the attack > applies to the complete endnode. Thank you. A very good explanation. This also relates somewhat to performance. If you have per-connection state, then you have to create the state separately for each connection. If you have per-host state, then you create the state on first connection, and then share it with the other ones that are created during the lifetime of the state. Whether a per-host state (in addition to the per-connection state) is a good idea is an architectural issue. In my opinion, many of the shim approaches do create a kind of a new layer, say layer 3.5, which contains a per-host state, potentially shared by multiple transport layer connections. > Because the attack applies to the endnode, > the attacker can do things like establishing a connection creating > some state > so that future communications initated by the victim are also > redirected. > That is, in IP layer solutions, the complete identity of the victim is > hijacked for all the applications and for all the communications, > pre-establihed or future communications (as long as the malicous state > exists in the victim) Right. > This implies that the risk is very different in one case than in the > other > one and different security solutions are required. Well, I might not call the risks "very" different, but they are different. > So I guess that i agree with Masataka that a return routability check > with a > cookie is enough to redirect a connection but IMHO this is not enough > to > redirect a complete identity at the IP layer level. If I understand Ohta-san correctly, he perceives that an architectural change that creates a per-host state at the end-hosts in the IP layer, or one that creates a new layer between IP and transport, are abhorrent and should not be considered. Hence, my perhaps faulty understanding of his thoughts is that the concept of location-independent IP layer identity does not exist. But maybe I understand his thoughts wrong. I, on the the other hand, certainly believe that adding location-independent IP layer identity would be good for the Internet. While (if) there is such a large disagreement between Ohta-san and me, it may be impossible to agree on security. --Pekka Nikander From owner-multi6@ops.ietf.org Tue Jan 20 02:53:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17828 for ; Tue, 20 Jan 2004 02:53:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AiqeI-000J79-2F for multi6-data@psg.com; Tue, 20 Jan 2004 07:50:10 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aiqe3-000J5R-E9 for multi6@ops.ietf.org; Tue, 20 Jan 2004 07:49:55 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id C5D3D265B1F; Tue, 20 Jan 2004 08:49:52 +0100 (CET) In-Reply-To: <400C796A.8070905@necom830.hpcl.titech.ac.jp> References: <400C796A.8070905@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <37CCCD00-4B1D-11D8-BCF8-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List , mbagnulo@ing.uc3m.es, Brian E Carpenter From: Kurt Erik Lindqvist Subject: Re: threats ID Date: Tue, 20 Jan 2004 08:49:46 +0100 To: Masataka Ohta X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ohta-san, On 2004-01-20, at 01.42, Masataka Ohta wrote: > >> IMHO both drafts complement themselves pretty well because Erik & >> Tony's >> draft essentially analyze the threats from a IP layer perspective and >> Masataka's draft analize the threats from a transport layer >> perspective. > > The problem for Erik and Tony, then, is that IP layer of > multi6 is no different from the current one. I am not really following what you are arguing for. Do you mean to say that a) Eriks draft is incorrect? b) Eriks draft is not complete? c) Eriks draft adds security that is not relevant? (I.e does not increase security) d) Eriks draft adds security beyond what we have today (but perhaps at too high cost)? e) Something else? Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQAzdn6arNKXTPFCVEQKzHQCeLF20H/oT+QSwIKUN8Q3MFtD3ov4AoKqx ujyIDtpPyj/cmjUbp/gd87gI =Xl/I -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jan 20 04:28:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20303 for ; Tue, 20 Jan 2004 04:28:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ais9b-0001uc-4v for multi6-data@psg.com; Tue, 20 Jan 2004 09:26:35 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ais9F-0001u6-Fj for multi6@ops.ietf.org; Tue, 20 Jan 2004 09:26:13 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 549821D11; Tue, 20 Jan 2004 10:26:12 +0100 (CET) Received: from lolo (lolo.lab.it.uc3m.es [163.117.144.254]) by smtp01.uc3m.es (Postfix) with SMTP id 061A21CF1; Tue, 20 Jan 2004 10:26:12 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" Cc: "Brian E Carpenter" , "Multi6 List" Subject: RE: threats ID Date: Tue, 20 Jan 2004 10:18:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <400C796A.8070905@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Masataka, please consider the differences between performing a hijack attack on MIP (layer 3 solution) or performing a hijack attack on SCTP (transport layer solution) in the first case the complete end node is hijacked (that is its IP address that is its identifier) and in the second case only a given connection is hijacked threats are different and security required is different ( i am really tring to agree with your draft here :-) regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Masataka Ohta > Enviado el: martes, 20 de enero de 2004 1:42 > Para: mbagnulo@ing.uc3m.es > CC: Brian E Carpenter; Multi6 List > Asunto: Re: threats ID > > > Marcelo; > > > IMHO both drafts complement themselves pretty well because Erik & Tony's > > draft essentially analyze the threats from a IP layer perspective and > > Masataka's draft analize the threats from a transport layer perspective. > > The problem for Erik and Tony, then, is that IP layer of > multi6 is no different from the current one. > > > After some mail exchanges with Pekka N., my understanding is > that that there > > is an important distinction to be made between these two cases when > > considering the hijacking attack. > > Good. > > Can you answer the following simple question? > > What, do you think, is being hijacked? > > Connections? > > Note that, unless you extensibly modify IP layer, there is no > connections there. > > > The point is that in transport layer > > solutions, the hijcack attack is limited to the existent established > > connection while in the IP layer (shim layer also) solutions the attack > > applies to the complete endnode. > > Wrong. Attack is always applied to the end. > > > Because the attack applies to the endnode, > > the attacker can do things like establishing aconnection > creating some state > > so that futuer communications initated by the victim are also > redirected. > > Establishing a connection is a functionality of the transport > layer. > > > That is in IP layer solutions the complete identity of the victim > > There is no IP layer solutions. > > Just like NAT operates not only at the IP layer but also at the > transport and applicaiton layers, shim layers are not only at > the IP layer. > > > So I guess that i agree with Masataka that a return routability > check with a > > cookie is enough to redirect a connection but IMHO this is not enough to > > redirect a complete identity at the IP layer level. > > I mean time shifting attacks may be acceptable as long they can > only affect > > a connection. > > "Time shifting attack" is meaningful if only there is persistent > relationship, that is connection, that it is not at the > connectionless layer. > > Masataka Ohta > > > From owner-multi6@ops.ietf.org Tue Jan 20 05:37:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23789 for ; Tue, 20 Jan 2004 05:37:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AitEN-0008vC-9u for multi6-data@psg.com; Tue, 20 Jan 2004 10:35:35 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AitEA-0008uL-75 for multi6@ops.ietf.org; Tue, 20 Jan 2004 10:35:22 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0KAZbLS014486; Tue, 20 Jan 2004 11:35:38 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <40085A7B.30202@necom830.hpcl.titech.ac.jp> References: <40085A7B.30202@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: threats ID Date: Tue, 20 Jan 2004 09:59:05 +0100 To: Masataka Ohta X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 16-jan-04, at 22:41, Masataka Ohta wrote: > 1. Security Considerations :-) > Without assuming MITM, existing transport and/or upper layer > protocols using cookie or cookie like information can be naturally > extended as a reasonable protection against connection hijacking by > false source information. That's not quite true. Obviously when there is a man in the middle all bets are off. However, when protection consists of cookies then a "man" doesn't have to be "in the middle": being on the sidelines is good enough. For instance, the attacker may be on a shared subnet (such as a wireless lan) with one of the victims, allowing him to intercept the cookie and subsequently inject false packets into the communication between the victims. Under some circumstances, this may be enough to steal a session. From owner-multi6@ops.ietf.org Tue Jan 20 06:15:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24613 for ; Tue, 20 Jan 2004 06:15:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aitph-000D0Z-AA for multi6-data@psg.com; Tue, 20 Jan 2004 11:14:09 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AitpR-000Cys-71 for multi6@ops.ietf.org; Tue, 20 Jan 2004 11:13:53 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0KBDKHI087632; Tue, 20 Jan 2004 11:13:20 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0KBDKro287280; Tue, 20 Jan 2004 12:13:20 +0100 Received: from zurich.ibm.com (sig-9-145-140-235.de.ibm.com [9.145.140.235]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA43492; Tue, 20 Jan 2004 12:13:17 +0100 Message-ID: <400D0CDD.81950E0C@zurich.ibm.com> Date: Tue, 20 Jan 2004 12:11:25 +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: mbagnulo@ing.uc3m.es CC: Masataka Ohta , Multi6 List Subject: Re: threats ID References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If a network-layer mh solution uses multiple identifiers, then what gets hijacked is an individual identifier, not the node. Thus what is hijacked is the subset of sessions in the node using the same identifier. Transport-layer solutions can claim that they reduce that set of sessions to one at a time. Nevertheless I find it surprising for Matasaka to assert that most of the threats in draft-nordmark-multi6-threats-00.txt only apply to network layer solutions. Do people have an opinion about that? In any case this does not prevent combining the two drafts, which will be much easier for readers, e.g.: Part 1: threats that only affect network layer solutions Part 2: threats that affect both network and transport layer solutions Part 3: threats that only affect transport layer solutions Brian marcelo bagnulo wrote: > > Hi Masataka, > > please consider the differences between performing a hijack attack on MIP > (layer 3 solution) or performing a hijack attack on SCTP (transport layer > solution) > > in the first case the complete end node is hijacked (that is its IP address > that is its identifier) and in the second case only a given connection is > hijacked > > threats are different and security required is different > > ( i am really tring to agree with your draft here :-) > > regards, marcelo > > > -----Mensaje original----- > > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > > nombre de Masataka Ohta > > Enviado el: martes, 20 de enero de 2004 1:42 > > Para: mbagnulo@ing.uc3m.es > > CC: Brian E Carpenter; Multi6 List > > Asunto: Re: threats ID > > > > > > Marcelo; > > > > > IMHO both drafts complement themselves pretty well because Erik & Tony's > > > draft essentially analyze the threats from a IP layer perspective and > > > Masataka's draft analize the threats from a transport layer perspective. > > > > The problem for Erik and Tony, then, is that IP layer of > > multi6 is no different from the current one. > > > > > After some mail exchanges with Pekka N., my understanding is > > that that there > > > is an important distinction to be made between these two cases when > > > considering the hijacking attack. > > > > Good. > > > > Can you answer the following simple question? > > > > What, do you think, is being hijacked? > > > > Connections? > > > > Note that, unless you extensibly modify IP layer, there is no > > connections there. > > > > > The point is that in transport layer > > > solutions, the hijcack attack is limited to the existent established > > > connection while in the IP layer (shim layer also) solutions the attack > > > applies to the complete endnode. > > > > Wrong. Attack is always applied to the end. > > > > > Because the attack applies to the endnode, > > > the attacker can do things like establishing aconnection > > creating some state > > > so that futuer communications initated by the victim are also > > redirected. > > > > Establishing a connection is a functionality of the transport > > layer. > > > > > That is in IP layer solutions the complete identity of the victim > > > > There is no IP layer solutions. > > > > Just like NAT operates not only at the IP layer but also at the > > transport and applicaiton layers, shim layers are not only at > > the IP layer. > > > > > So I guess that i agree with Masataka that a return routability > > check with a > > > cookie is enough to redirect a connection but IMHO this is not enough to > > > redirect a complete identity at the IP layer level. > > > I mean time shifting attacks may be acceptable as long they can > > only affect > > > a connection. > > > > "Time shifting attack" is meaningful if only there is persistent > > relationship, that is connection, that it is not at the > > connectionless layer. > > > > Masataka Ohta > > > > > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Tue Jan 20 06:18:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24703 for ; Tue, 20 Jan 2004 06:18:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aitsq-000DHI-7f for multi6-data@psg.com; Tue, 20 Jan 2004 11:17:24 +0000 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AitsN-000DFY-Pw for multi6@ops.ietf.org; Tue, 20 Jan 2004 11:16:56 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0KBGsJW118590 for ; Tue, 20 Jan 2004 11:16:54 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0KBGrI1276926 for ; Tue, 20 Jan 2004 12:16:53 +0100 Received: from zurich.ibm.com (sig-9-145-140-235.de.ibm.com [9.145.140.235]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA57940 for ; Tue, 20 Jan 2004 12:16:51 +0100 Message-ID: <400D0DB0.5DB3FEF@zurich.ibm.com> Date: Tue, 20 Jan 2004 12:14:56 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Subject: Comment on draft-ohta-multi6-threats-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 1.4. Privacy on Identification > > If transport layer protocols having new connection identification > requires hosts having persisting identification information, it will > be used to track the identify of the host, which is a new security > threat. What is the persistency of the identifier? For a single session, for a single reboot, or indefinite? If the identifier is created per session or per reboot, the privacy threat seems unimportant. Brian From owner-multi6@ops.ietf.org Tue Jan 20 06:34:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25014 for ; Tue, 20 Jan 2004 06:34:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aiu88-000EhY-21 for multi6-data@psg.com; Tue, 20 Jan 2004 11:33:12 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aiu7t-000Ego-Up for multi6@ops.ietf.org; Tue, 20 Jan 2004 11:32:58 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F3B264D59; Tue, 20 Jan 2004 12:32:56 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id DDAAF49C7; Tue, 20 Jan 2004 12:32:56 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Brian E Carpenter" Cc: "Masataka Ohta" , "Multi6 List" Subject: RE: threats ID Date: Tue, 20 Jan 2004 12:25:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <400D0CDD.81950E0C@zurich.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If a network-layer mh solution uses multiple identifiers, then what gets > hijacked is an individual identifier, not the node. Thus what is hijacked > is the subset of sessions in the node using the same identifier. good point > Transport-layer solutions can claim that they reduce that set of sessions > to one at a time. > > Nevertheless I find it surprising for Matasaka to assert that most of > the threats in draft-nordmark-multi6-threats-00.txt only apply to > network layer solutions. Do people have an opinion about that? > well, i may have induced also this perception... I haven't really made an analysis about if the threats mentioned in Erik's draft only apply to IP layer solution, but it is just that i have always asumed that this draft had these type of solutions in mind, so that its analysis applied to this type of solution. Sorry if i generated some confusion here. OTOH, Masataka's draft states clearly in the tittle that it is considering the thransport layer solutions. > In any case this does not prevent combining the two drafts, which will > be much easier for readers, e.g.: > > Part 1: threats that only affect network layer solutions > Part 2: threats that affect both network and transport layer solutions > Part 3: threats that only affect transport layer solutions > Yes, or other option is to make an analysis for IP layer solutions and another for transport layer, but in any case IMHO we should clearly undestand the differences between the two cases. regards, marcelo > Brian > > marcelo bagnulo wrote: > > > > Hi Masataka, > > > > please consider the differences between performing a hijack > attack on MIP > > (layer 3 solution) or performing a hijack attack on SCTP > (transport layer > > solution) > > > > in the first case the complete end node is hijacked (that is > its IP address > > that is its identifier) and in the second case only a given > connection is > > hijacked > > > > threats are different and security required is different > > > > ( i am really tring to agree with your draft here :-) > > > > regards, marcelo > > > > > -----Mensaje original----- > > > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > > > nombre de Masataka Ohta > > > Enviado el: martes, 20 de enero de 2004 1:42 > > > Para: mbagnulo@ing.uc3m.es > > > CC: Brian E Carpenter; Multi6 List > > > Asunto: Re: threats ID > > > > > > > > > Marcelo; > > > > > > > IMHO both drafts complement themselves pretty well because > Erik & Tony's > > > > draft essentially analyze the threats from a IP layer > perspective and > > > > Masataka's draft analize the threats from a transport layer > perspective. > > > > > > The problem for Erik and Tony, then, is that IP layer of > > > multi6 is no different from the current one. > > > > > > > After some mail exchanges with Pekka N., my understanding is > > > that that there > > > > is an important distinction to be made between these two cases when > > > > considering the hijacking attack. > > > > > > Good. > > > > > > Can you answer the following simple question? > > > > > > What, do you think, is being hijacked? > > > > > > Connections? > > > > > > Note that, unless you extensibly modify IP layer, there is no > > > connections there. > > > > > > > The point is that in transport layer > > > > solutions, the hijcack attack is limited to the existent established > > > > connection while in the IP layer (shim layer also) > solutions the attack > > > > applies to the complete endnode. > > > > > > Wrong. Attack is always applied to the end. > > > > > > > Because the attack applies to the endnode, > > > > the attacker can do things like establishing aconnection > > > creating some state > > > > so that futuer communications initated by the victim are also > > > redirected. > > > > > > Establishing a connection is a functionality of the transport > > > layer. > > > > > > > That is in IP layer solutions the complete identity of the victim > > > > > > There is no IP layer solutions. > > > > > > Just like NAT operates not only at the IP layer but also at the > > > transport and applicaiton layers, shim layers are not only at > > > the IP layer. > > > > > > > So I guess that i agree with Masataka that a return routability > > > check with a > > > > cookie is enough to redirect a connection but IMHO this is > not enough to > > > > redirect a complete identity at the IP layer level. > > > > I mean time shifting attacks may be acceptable as long they can > > > only affect > > > > a connection. > > > > > > "Time shifting attack" is meaningful if only there is persistent > > > relationship, that is connection, that it is not at the > > > connectionless layer. > > > > > > Masataka Ohta > > > > > > > > > > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Tue Jan 20 07:37:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26544 for ; Tue, 20 Jan 2004 07:37:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aiv5E-000KSx-75 for multi6-data@psg.com; Tue, 20 Jan 2004 12:34:16 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Aiv51-000KRw-BG for multi6@ops.ietf.org; Tue, 20 Jan 2004 12:34:03 +0000 Received: (qmail 73760 invoked from network); 20 Jan 2004 12:43:04 -0000 Received: from h219-110-033-058.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.58) by necom830.hpcl.titech.ac.jp with SMTP; 20 Jan 2004 12:43:04 -0000 Message-ID: <400D2075.8040207@necom830.hpcl.titech.ac.jp> Date: Tue, 20 Jan 2004 21:35:01 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Pekka Nikander CC: mbagnulo@ing.uc3m.es, Brian E Carpenter , Multi6 List Subject: Re: threats ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Nikander; >> After some mail exchanges with Pekka N., my understanding is that that >> there >> is an important distinction to be made between these two cases when >> considering the hijacking attack. The point is that in transport layer >> solutions, the hijcack attack is limited to the existent established >> connection while in the IP layer (shim layer also) solutions the attack >> applies to the complete endnode. > > > Thank you. A very good explanation. > > This also relates somewhat to performance. If you have per-connection > state, You always have per-connection state, though half established connection may have state only at one end, for example, as a protection against TCP SYM flood. > If you > have per-host state, then you create the state on first connection, and > then share it with the other ones that are created during the lifetime > of the state. Some application, such as DNS, may have per-host state. However, IP layer does not have any state of a connection, because it is connectionless. State of MIP binding is not of a connection but of a binding between two addresses of a single end. Several connections may share states, though it introduces new security threats without any meaningful benefit. > In my opinion, many of the shim approaches > do create a kind of a new layer, say layer 3.5, which contains a per-host > state, potentially shared by multiple transport layer connections. All the shim layers are working at least at layer 4 that there is no point to say layer 3.5 They depend on layer 4 details such as how TCP calculates its check sum. MTU change creates another dependency with layer 4 and above. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 20 07:38:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26597 for ; Tue, 20 Jan 2004 07:38:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aiv8G-000KuH-9G for multi6-data@psg.com; Tue, 20 Jan 2004 12:37:24 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Aiv80-000Kt8-Jt for multi6@ops.ietf.org; Tue, 20 Jan 2004 12:37:09 +0000 Received: (qmail 73782 invoked from network); 20 Jan 2004 12:46:12 -0000 Received: from h219-110-033-058.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.58) by necom830.hpcl.titech.ac.jp with SMTP; 20 Jan 2004 12:46:12 -0000 Message-ID: <400D2132.2010607@necom830.hpcl.titech.ac.jp> Date: Tue, 20 Jan 2004 21:38:10 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Multi6 List , mbagnulo@ing.uc3m.es, Brian E Carpenter Subject: Re: threats ID References: <400C796A.8070905@necom830.hpcl.titech.ac.jp> <37CCCD00-4B1D-11D8-BCF8-000A95928574@kurtis.pp.se> In-Reply-To: <37CCCD00-4B1D-11D8-BCF8-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt; >>>IMHO both drafts complement themselves pretty well because Erik & >>>Tony's >>>draft essentially analyze the threats from a IP layer perspective and >>>Masataka's draft analize the threats from a transport layer >>>perspective. >> >>The problem for Erik and Tony, then, is that IP layer of >>multi6 is no different from the current one. > > > I am not really following what you are arguing for. Do you mean to say > that I mean there is no threats introduced at the IP layer of multi6 because the IP layer of multi6 is no different from the current one. It's not me who said: Erik & Tony's draft essentially analyze the threats from a IP layer perspective Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 20 07:49:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26812 for ; Tue, 20 Jan 2004 07:49:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AivIb-000MHI-La for multi6-data@psg.com; Tue, 20 Jan 2004 12:48:05 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AivI9-000MD1-6Y for multi6@ops.ietf.org; Tue, 20 Jan 2004 12:47:37 +0000 Received: (qmail 73834 invoked from network); 20 Jan 2004 12:56:41 -0000 Received: from h219-110-033-058.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.58) by necom830.hpcl.titech.ac.jp with SMTP; 20 Jan 2004 12:56:41 -0000 Message-ID: <400D23A7.4090502@necom830.hpcl.titech.ac.jp> Date: Tue, 20 Jan 2004 21:48:39 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 List Subject: Re: threats ID References: <40085A7B.30202@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; >> 1. Security Considerations > :-) It should be leagal. :-) >> Without assuming MITM, existing transport and/or upper layer >> protocols using cookie or cookie like information can be naturally >> extended as a reasonable protection against connection hijacking by >> false source information. > That's not quite true. Obviously when there is a man in the middle all > bets are off. However, when protection consists of cookies then a "man" > doesn't have to be "in the middle": being on the sidelines is good > enough. For instance, the attacker may be on a shared subnet (such as a > wireless lan) with one of the victims, allowing him to intercept the > cookie and subsequently inject false packets into the communication > between the victims. Under some circumstances, this may be enough to > steal a session. MITM means someone who can snoop, erase and modify packets of victims. It is not necessary that victims and MITM are separated by routers. It is not even necessary that victims and MITM are separated by L2 switches or L1 hubs. Even if two victims are directly connected by a pair of fiber, MITM can exist by cutting the pair and inserting itself in between. Silimar attack is much easier if physical media is wireless lan. I think I gave you an example of how easy to create MITM with wireless lan. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 20 07:56:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26984 for ; Tue, 20 Jan 2004 07:56:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AivPa-000NK1-Nn for multi6-data@psg.com; Tue, 20 Jan 2004 12:55:18 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AivPO-000NIw-HJ for multi6@ops.ietf.org; Tue, 20 Jan 2004 12:55:06 +0000 Received: (qmail 73867 invoked from network); 20 Jan 2004 13:04:10 -0000 Received: from h219-110-033-058.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.58) by necom830.hpcl.titech.ac.jp with SMTP; 20 Jan 2004 13:04:10 -0000 Message-ID: <400D2568.4070803@necom830.hpcl.titech.ac.jp> Date: Tue, 20 Jan 2004 21:56:08 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Brian E Carpenter , Multi6 List Subject: Re: threats ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marcelo; > please consider the differences between performing a hijack attack on MIP > (layer 3 solution) or performing a hijack attack on SCTP (transport layer > solution) Sure. While MIP has its own security threat, it has nothing to do with M6. As I repeatedly point it out, there is no reasonable timeout value shared between MIP and M6 that there is no point mixing MIP binding and M6 connection. MIP timeout is determined by expected size of cell divided by expected movement speed of hosts, while M6 timeout is determined by transport and application protcols. > in the first case the complete end node is hijacked (that is its IP address > that is its identifier) and in the second case only a given connection is > hijacked In the first case, what is hijacked is binding between home and care of addresses, which is not a connection. You can still call it a connection, but its meaning is totally different from connection of TCP or SCTP. > threats are different and security required is different > > ( i am really tring to agree with your draft here :-) Thanks. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 20 08:05:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27151 for ; Tue, 20 Jan 2004 08:05:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AivXs-000Oe2-Dg for multi6-data@psg.com; Tue, 20 Jan 2004 13:03:52 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AivXf-000OaP-Mz for multi6@ops.ietf.org; Tue, 20 Jan 2004 13:03:39 +0000 Received: (qmail 73901 invoked from network); 20 Jan 2004 13:12:44 -0000 Received: from h219-110-033-058.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.58) by necom830.hpcl.titech.ac.jp with SMTP; 20 Jan 2004 13:12:44 -0000 Message-ID: <400D2769.5050303@necom830.hpcl.titech.ac.jp> Date: Tue, 20 Jan 2004 22:04:41 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 Subject: Re: Comment on draft-ohta-multi6-threats-00.txt References: <400D0DB0.5DB3FEF@zurich.ibm.com> In-Reply-To: <400D0DB0.5DB3FEF@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; >>1.4. Privacy on Identification >> >> If transport layer protocols having new connection identification >> requires hosts having persisting identification information, it will >> be used to track the identify of the host, which is a new security >> threat. > > > What is the persistency of the identifier? For a single session, for a single > reboot, or indefinite? It depens on proposals, though I think per session ID is rather temporary than persistent. > If the identifier is created per session or per reboot, the privacy > threat seems unimportant. Per session privacy is, of course, unimportant. Another case where privacy is unimportant is per location change, because you don't have location privacy. But, if you use Unix, you should expect reboot once in every several monthes or years that per reboot is very long. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 20 08:08:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27269 for ; Tue, 20 Jan 2004 08:08:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AivbH-000PBQ-PP for multi6-data@psg.com; Tue, 20 Jan 2004 13:07:23 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Aivb5-000PAN-I5 for multi6@ops.ietf.org; Tue, 20 Jan 2004 13:07:11 +0000 Received: (qmail 73913 invoked from network); 20 Jan 2004 13:16:15 -0000 Received: from h219-110-033-058.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.58) by necom830.hpcl.titech.ac.jp with SMTP; 20 Jan 2004 13:16:15 -0000 Message-ID: <400D283D.8070607@necom830.hpcl.titech.ac.jp> Date: Tue, 20 Jan 2004 22:08:13 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: mbagnulo@ing.uc3m.es, Multi6 List Subject: Re: threats ID References: <400D0CDD.81950E0C@zurich.ibm.com> In-Reply-To: <400D0CDD.81950E0C@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > Nevertheless I find it surprising for Matasaka to assert that most of > the threats in draft-nordmark-multi6-threats-00.txt only apply to > network layer solutions. Do people have an opinion about that? It's marcelo who wrote: Erik & Tony's draft essentially analyze the threats from a IP layer perspective I myself do not think so called network layer solutions ever exist. Read my architectural draft on why there can't be. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 20 08:11:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27324 for ; Tue, 20 Jan 2004 08:11:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AiveG-000PWC-DM for multi6-data@psg.com; Tue, 20 Jan 2004 13:10:28 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aive1-000PTP-I0 for multi6@ops.ietf.org; Tue, 20 Jan 2004 13:10:13 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C95585AB0; Tue, 20 Jan 2004 14:10:12 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id B33C85A08; Tue, 20 Jan 2004 14:10:12 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" Cc: "Brian E Carpenter" , "Multi6 List" Subject: RE: threats ID Date: Tue, 20 Jan 2004 14:02:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <400D2568.4070803@necom830.hpcl.titech.ac.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In the first case, what is hijacked is binding between home and care > of addresses, which is not a connection. Exactly, it is state that concerns the node as a unit, so the complete identity of the node is affected > You can still call it a > connection, but its meaning is totally different from connection > of TCP or SCTP. > Exaclty, this is why i am saying that threats are different. One case is when the layer 3 identifier is hijacked and a different thing is when a tcp connection is hijacked So, what Brian is proposing AFAIU is to analyze the threats concerning these two different cases and compare them in a the threats draft regards, marcelo > > threats are different and security required is different > > > > ( i am really tring to agree with your draft here :-) > > Thanks. > > Masataka Ohta > > > From owner-multi6@ops.ietf.org Tue Jan 20 08:19:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27486 for ; Tue, 20 Jan 2004 08:19:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aivli-0000BR-RS for multi6-data@psg.com; Tue, 20 Jan 2004 13:18:10 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AivlU-0000AV-FB for multi6@ops.ietf.org; Tue, 20 Jan 2004 13:17:56 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0KDHsJX109720 for ; Tue, 20 Jan 2004 13:17:54 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0KDHsI1283410 for ; Tue, 20 Jan 2004 14:17:54 +0100 Received: from zurich.ibm.com (sig-9-145-171-126.de.ibm.com [9.145.171.126]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA44372 for ; Tue, 20 Jan 2004 14:17:52 +0100 Message-ID: <400D2A3C.5D985B42@zurich.ibm.com> Date: Tue, 20 Jan 2004 14:16:44 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Subject: Comments on draft-ohta-multi6-8plus8-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 1. Introduction & Terminologies > > This memo describes 8+8 address format, There should be an acknowledgement here to Mike O'Dell, who invented both the name and the original 8+8 proposal. Technically the current proposal is different, but it is unfair not to give Mike the credit. > 2.4.1 Locator Derived ID ... > That is, a site is assured to have 65,536 IDs assigned, though the > locator nature of the ID makes IDs not stable against site > renumbering. There are three major problems with this: 1. 65k ids is not enough. If I take the example of my own company, we would certainly want to appear as a single "site" for multihoming (at many different ISP attachment points) but 65k hosts is nothing like enough. In fact, with the massive scaling of devices that we expect with IPv6, 65k hosts won't be enough for companies with a few thousand employees. 2. As I understand it, each host burns up a subnet number. But in large systems people expect to use toplogically significant subnet numbering, and the numbering plan must survive any amount of moving of computers from one building to another. That is incompatible with tying a subnet number to a host. 3. As noted in the draft, renumbering breaks these IDs so they cannot be regarded as having long term stability. > Note that ID assignment within a site can be arbitrary and will not > be consistent of intra site link structure. That is, an end with a > locator derived ID including a certain subnet id may be located > anywhere in the site, not necessarily in the subnet corresponding to > the subnet id. This seems entirely inconsistent. It seems to say that when a host is moved, its ID can no longer be derived from its locator. So what was the purpose of deriving it that way in the first place? This doesn't solve the problem of being limited to 65k IDs or to the problem of burning one subnet ID per host. We might just as well use sequential allocation of the last 16 bits of the ID. > If one want to hide its privacy in ID, one should use locator derived > ID for one's ends. I see no privacy enhancement here. These IDs are just numbers, and they are persistent (at least until the site is renumbered). If you want to enhance privacy, the last 16 bits would need to be a temporary pseudo- random value. I think that only the location independent IDs of section 2.4.2 are really interesting, but as we have discussed often, it is not obvious that a 64 bit space will really work for this. These are old arguments from when we discussed the original 8+8 proposal a few years ago. > 4.1 Modification to TCP > > A new TCP option, Multi Address option, is introduced. How are SCTP, UDP, and DCCP handled? ... > It is expected that 9 locators are enough for most ends, as a site of > the end can be multihomed to three lower level ISPs each multihomed > to 3 top level ISPs. However, if an end has more than 9 locators, > which is a case with routers with more than 9 interfaces, TCP or > upper layer modules should be responsible to select 9 or less > locators to be used for the TCP connection. It seems very doubtful architecturally to have a hard limit on the number of addresses and to throw yet more address selection problems onto every transport layer implementation. Yes, 9 addresses may cover most cases, but the code will have to cover *every* case. > 4.3 8+8 Adaptation Layers for Applications over TCP and DNS > > The 8+8 adaptation layers make end to end multihoming invisible to > applications over TCP and DNS, that is, applications using TCP > transport only without hard coded IP addresses. > > Some multihoming proposals try to introduce an adaptation layer in > the Internetworking layer to hide locator changes. However, this > attempt does not make sense. As demonstrated by NAT, rewriting of > addresses is, in general, not transparent to transport and > application protocols. But *reversible* rewriting, as originally proposed by Mike O'Dell and found also in NOID for example, *is* transparent to IPSEC, transport, and application protocols. > ... For example, transport layer checksum > computation involves IP addresses and is different for each transport > protocol that address rewriting can not be confined in the > Internetworking layer. Yes it can, if it is reversible. > ... Insertion or deletion of IP headers affects > MTU, which is also visible to the transport layer. Correct. > ... Applications like > FTP transmit raw addresses in application data streams And this works just fine if the rewriting is reversible. From an architectural point of view, NOID, ODT, and their brothers keep state in the two ends at layer 3 to allow the address to be restored to its original value. The current proposal, like LIN6, forces the state up into the transport layer. The original O'Dell 8+8 forced the state down into the border routers. The common feature is that state is needed somewhere, and it consists of a set of addresses, one of which is tagged "in use as locator" and one (perhaps the same one) is tagged "in use as identifier". Brian From owner-multi6@ops.ietf.org Tue Jan 20 08:20:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27512 for ; Tue, 20 Jan 2004 08:20:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aivmw-0000JB-TR for multi6-data@psg.com; Tue, 20 Jan 2004 13:19:26 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Aivmk-0000IT-Cu for multi6@ops.ietf.org; Tue, 20 Jan 2004 13:19:14 +0000 Received: (qmail 73972 invoked from network); 20 Jan 2004 13:28:19 -0000 Received: from h219-110-033-058.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.58) by necom830.hpcl.titech.ac.jp with SMTP; 20 Jan 2004 13:28:19 -0000 Message-ID: <400D2B10.3050209@necom830.hpcl.titech.ac.jp> Date: Tue, 20 Jan 2004 22:20:16 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Brian E Carpenter , Multi6 List Subject: Re: threats ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; > One case is when the layer 3 identifier is hijacked and a different thing is > when a tcp connection is hijacked Why do you think layer 3 identifier can ever be hijacked specifically with M6? I do understand that layer 3 identifier stored in an application of DNS can be hijacked. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 20 09:47:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01318 for ; Tue, 20 Jan 2004 09:47:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aix6g-0008lC-NL for multi6-data@psg.com; Tue, 20 Jan 2004 14:43:54 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Aix6K-0008k3-Ub for multi6@ops.ietf.org; Tue, 20 Jan 2004 14:43:33 +0000 Received: (qmail 74359 invoked from network); 20 Jan 2004 14:52:38 -0000 Received: from h219-110-033-058.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.58) by necom830.hpcl.titech.ac.jp with SMTP; 20 Jan 2004 14:52:38 -0000 Message-ID: <400D3ED2.3030709@necom830.hpcl.titech.ac.jp> Date: Tue, 20 Jan 2004 23:44:34 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 Subject: Re: Comments on draft-ohta-multi6-8plus8-00.txt References: <400D2A3C.5D985B42@zurich.ibm.com> In-Reply-To: <400D2A3C.5D985B42@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > There should be an acknowledgement here to Mike O'Dell, who invented both > the name and the original 8+8 proposal. Technically the current proposal > is different, but it is unfair not to give Mike the credit. 8+8 is a generic terminology. It was used at least in 1994 in big-internet ML. Note that Mike O'Dell, you and I were members of the ML atthat time. Maybe, Mike O'Dell was the first person to use the terminology "8+8" somewhere else. But, Mike O'Dell and others used it as a generic terminology. Archive of big-internet can be found at: ftp://munnari.oz.au/big-internet/list-archive Later, Mike O'Dell made a proposal. It was named GSE. My architectural draft made it clear from the beginning: Note that 8+8 proposal must not be confused by latter proposal of routing goof (GSE) 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. Read the draft. >>2.4.1 Locator Derived ID > > ... > >> That is, a site is assured to have 65,536 IDs assigned, though the >> locator nature of the ID makes IDs not stable against site >> renumbering. > > > There are three major problems with this: > > 1. 65k ids is not enough. I never said 64K ID enough and the draft describes how the problem can be solved. However, you are too pessimisitic. > If I take the example of my own company, we > would certainly want to appear as a single "site" for multihoming (at > many different ISP attachment points) but 65k hosts is nothing like enough. If your company has so many external connections, your company has a lot more than 64K locator derived IDs that your company don't have any problem. BTW, it is unwise that your company appears as a single "site" for multihoming, because it makes your company valunerable to internal link failures. > 2. As I understand it, each host burns up a subnet number. But in large > systems people expect to use toplogically significant subnet numbering, > and the numbering plan must survive any amount of moving of computers from > one building to another. That is incompatible with tying a subnet number > to a host. There is no tying. My draft says: Note that ID assignment within a site can be arbitrary and will not be consistent of intra site link structure. That is, an end with a locator derived ID including a certain subnet id may be located anywhere in the site, not necessarily in the subnet corresponding to the subnet id. > 3. As noted in the draft, renumbering breaks these IDs so they cannot be > regarded as having long term stability. Of course, not. But, it should be noted that the longevity is expected to be longer than that of hash of public keys, because security sensitive people change keys more frequently than ISPs. Those who need even better longevity are taken care of by the draft. >> Note that ID assignment within a site can be arbitrary and will not >> be consistent of intra site link structure. That is, an end with a >> locator derived ID including a certain subnet id may be located >> anywhere in the site, not necessarily in the subnet corresponding to >> the subnet id. > > > This seems entirely inconsistent. It seems to say that when a host is > moved, its ID can no longer be derived from its locator. No. The draft says: IDs may be derived from locators allocated to sites. not ID may be derived from a locator allocated to an end. But, I try to further improve the explanation. >> If one want to hide its privacy in ID, one should use locator derived >> ID for one's ends. > I see no privacy enhancement here. These IDs are just numbers, and they > are persistent (at least until the site is renumbered). If you want to > enhance privacy, the last 16 bits would need to be a temporary pseudo- > random value. Wrong. Your locator is persistent and is known by your peers that there is no point of hiding it. > I think that only the location independent IDs of section 2.4.2 > are really interesting, but as we have discussed often, it is not > obvious that a 64 bit space will really work for this. These > are old arguments from when we discussed the original 8+8 proposal a > few years ago. It is an older argument positive answers to which can be found in bigi archive. >>4.1 Modification to TCP >> >> A new TCP option, Multi Address option, is introduced. > > > How are SCTP, UDP, and DCCP handled? Read the draft. >> It is expected that 9 locators are enough for most ends, as a site of >> the end can be multihomed to three lower level ISPs each multihomed >> to 3 top level ISPs. However, if an end has more than 9 locators, >> which is a case with routers with more than 9 interfaces, TCP or >> upper layer modules should be responsible to select 9 or less >> locators to be used for the TCP connection. > > > It seems very doubtful architecturally to have a hard limit on the > number of addresses and to throw yet more address selection problems > onto every transport layer implementation. Yes, 9 addresses may cover > most cases, but the code will have to cover *every* case. 9 is not a hard limit. Read the draft. >>4.3 8+8 Adaptation Layers for Applications over TCP and DNS >> >> The 8+8 adaptation layers make end to end multihoming invisible to >> applications over TCP and DNS, that is, applications using TCP >> transport only without hard coded IP addresses. >> >> Some multihoming proposals try to introduce an adaptation layer in >> the Internetworking layer to hide locator changes. However, this >> attempt does not make sense. As demonstrated by NAT, rewriting of >> addresses is, in general, not transparent to transport and >> application protocols. > > > But *reversible* rewriting, as originally proposed by Mike O'Dell and > found also in NOID for example, *is* transparent to IPSEC, transport, > and application protocols. Mike O'Dell imitated existing 8+8 proposals to modify TCP and other transport layer protocols not to include locator part for checksuming and IPSEC calculation, which is a modification to the transport layer protocols. Of course, it is not transparent to application protocols like FTP. GSE draft says: One immediate result is that upper-layer protocols must use only the ESD for purposes such as pseudo-header checksums and the like. > The original O'Dell 8+8 forced the state down into the border > routers. That's why only way to make it transparent to IPSEC and transport is not to protect locator by IPSEC nor transport checksums. You should not rely on your memory and check appropriate references when you want to say something in the past. I do check them. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 20 11:19:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09173 for ; Tue, 20 Jan 2004 11:19:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AiyXZ-000Iq5-CX for multi6-data@psg.com; Tue, 20 Jan 2004 16:15:45 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AiyXN-000Ioy-4I for multi6@ops.ietf.org; Tue, 20 Jan 2004 16:15:33 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id AB1B687316; Tue, 20 Jan 2004 11:15:32 -0500 (EST) To: multi6@ops.ietf.org Subject: Re: Comments on draft-ohta-multi6-8plus8-00.txt Cc: jnc@mercury.lcs.mit.edu Message-Id: <20040120161532.AB1B687316@mercury.lcs.mit.edu> Date: Tue, 20 Jan 2004 11:15:32 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Brian E Carpenter > There should be an acknowledgement here to Mike O'Dell, who invented > both the name and the original 8+8 proposal. My memory may be failing here, but IIRC it was Dave Clark (in a long email message to some mailing list - the IPv6 or Big-I lists, maybe?) who first came up with the concept of splitting the IPv6 address field into two halves, for location and identity. I think the main think Mike added, in coming up with GSE, was the concept that the border routers would fill in the high order parts of the locator portion. Noel From owner-multi6@ops.ietf.org Tue Jan 20 11:42:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11477 for ; Tue, 20 Jan 2004 11:42:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AiyvN-000LV6-M2 for multi6-data@psg.com; Tue, 20 Jan 2004 16:40:21 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AiyvB-000LU3-DY for multi6@ops.ietf.org; Tue, 20 Jan 2004 16:40:09 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 Jan 2004 08:44:03 +0000 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i0KGe6J0014670; Tue, 20 Jan 2004 08:40:07 -0800 (PST) Received: from cisco.com (sjc-vpn3-450.cisco.com [10.21.65.194]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA19501; Tue, 20 Jan 2004 08:40:06 -0800 (PST) Message-ID: <400D59E6.6090904@cisco.com> Date: Tue, 20 Jan 2004 08:40:06 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Noel Chiappa CC: multi6@ops.ietf.org Subject: Re: Comments on draft-ohta-multi6-8plus8-00.txt References: <20040120161532.AB1B687316@mercury.lcs.mit.edu> In-Reply-To: <20040120161532.AB1B687316@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think Noel's right. I remember Dave discussing something like this in Amsterdam in '93. Eliot Noel Chiappa wrote: > > From: Brian E Carpenter > > > There should be an acknowledgement here to Mike O'Dell, who invented > > both the name and the original 8+8 proposal. > > My memory may be failing here, but IIRC it was Dave Clark (in a long email > message to some mailing list - the IPv6 or Big-I lists, maybe?) who first came > up with the concept of splitting the IPv6 address field into two halves, for > location and identity. > > I think the main think Mike added, in coming up with GSE, was the concept that > the border routers would fill in the high order parts of the locator portion. > > Noel > > > From owner-multi6@ops.ietf.org Tue Jan 20 11:47:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11753 for ; Tue, 20 Jan 2004 11:47:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aiz18-000MCS-A4 for multi6-data@psg.com; Tue, 20 Jan 2004 16:46:18 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aiz0v-000MBS-Nz for multi6@ops.ietf.org; Tue, 20 Jan 2004 16:46:05 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 20 Jan 2004 08:46:56 -0800 Received: from cisco.com (sjc-vpn2-62.cisco.com [10.21.112.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id i0KGk2jQ010119 for ; Tue, 20 Jan 2004 08:46:03 -0800 (PST) Received: by cisco.com (sSMTP sendmail emulation); Tue, d Jan 2004 11:45:56 Date: Tue, 20 Jan 2004 11:45:56 -0500 From: Scott W Brim To: multi6@ops.ietf.org Subject: Re: Comments on draft-ohta-multi6-8plus8-00.txt Message-ID: <20040120164556.GI2000@sbrim-w2k01> Mail-Followup-To: Scott W Brim , multi6@ops.ietf.org References: <20040120161532.AB1B687316@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040120161532.AB1B687316@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, Jan 20, 2004 11:15:32AM -0500, Noel Chiappa allegedly wrote: > My memory may be failing here, but IIRC it was Dave Clark (in a long email > message to some mailing list - the IPv6 or Big-I lists, maybe?) who first came > up with the concept of splitting the IPv6 address field into two halves, for > location and identity. Copying what was done with NSAPs? I don't think anyone could lay claim to this idea in the last 20 years. However, > I think the main think Mike added, in coming up with GSE, was the > concept that the border routers would fill in the high order parts of > the locator portion. I think so too. We could ask him. From owner-multi6@ops.ietf.org Tue Jan 20 15:57:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22313 for ; Tue, 20 Jan 2004 15:57:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj2u2-000Oa2-Gb for multi6-data@psg.com; Tue, 20 Jan 2004 20:55:14 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aj2tn-000OSt-Mq for multi6@ops.ietf.org; Tue, 20 Jan 2004 20:54:59 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0KKtJLS022935; Tue, 20 Jan 2004 21:55:20 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <400D2075.8040207@necom830.hpcl.titech.ac.jp> References: <400D2075.8040207@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: threats ID Date: Tue, 20 Jan 2004 21:54:52 +0100 To: Masataka Ohta X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 20-jan-04, at 13:35, Masataka Ohta wrote: > However, IP layer does not have any state of a connection, That's not true. The routing table is state, as is per-destination path MTU information. I'm not even going to mention IPsec. > because it is connectionless. For a connection you need per-connection matching state in at least two places, the source and the destination. For IP you still need state, but it's per IP address or even per prefix, and it doesn't have to match on both ends. But it's still state. >> In my opinion, many of the shim approaches >> do create a kind of a new layer, say layer 3.5, which contains a >> per-host >> state, potentially shared by multiple transport layer connections. > All the shim layers are working at least at layer 4 that there > is no point to say layer 3.5 I believe NOID and certainly ODT allow layer 4 to work without changes, and the changes they make to layer 3 are such that they can easily be thought of as a layer between 3 and 4, as those changes only apply to the endpoints and not to what happens in routers (ok, except for address rewriting). So "layer 3.5" makes sense to me. BTW, my point about man in the middle was that an attacker can still do damage without having full man in the middle capabilities, for instance by intercepting packets and injecting falsified ones, without necessarily being able to stop the flow of traffic between the endpoints. This is important, because true man in the middle capability isn't something that is easily achieved, while "man on the sideline", where the attacker can observe data and inject his own, but not stop the real data from flowing, is fairly trivial to achieve in many situations. From owner-multi6@ops.ietf.org Tue Jan 20 16:08:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23541 for ; Tue, 20 Jan 2004 16:08:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj35I-0000Rl-BM for multi6-data@psg.com; Tue, 20 Jan 2004 21:06:52 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aj354-0000Om-QC for multi6@ops.ietf.org; Tue, 20 Jan 2004 21:06:39 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0KL72LS023121; Tue, 20 Jan 2004 22:07:03 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <87FABA0B-4B8C-11D8-9871-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: threats ID Date: Tue, 20 Jan 2004 22:06:35 +0100 To: X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 20-jan-04, at 12:25, marcelo bagnulo wrote: >> In any case this does not prevent combining the two drafts, which will >> be much easier for readers, e.g.: >> Part 1: threats that only affect network layer solutions >> Part 2: threats that affect both network and transport layer solutions >> Part 3: threats that only affect transport layer solutions > Yes, or other option is to make an analysis for IP layer solutions and > another for transport layer, but in any case IMHO we should clearly > undestand the differences between the two cases. I think it's an important observation that working per identifier pair or working per session have some very different security aspects. Which of course begs the question: which is the better approach? I'm not much in favor of having to do a time consuming negotiation for each TCP or UDP "session", as many sessions have a lifetime of only a few packets. (On the other hand this could finally make HTTP implementers clean up their act and not start upwards of 10 TCP sessions per second...) On the other hand, "fool me once, redirect my traffic forever" isn't all that appealing either. I think there is some middle ground here, where sessions can be grouped in such that an optimal tradeoff between increased risk and decreased performance is found. However, this probably means the MH layer needs to know more than a few intimate details of what the transport protocols are up to. From owner-multi6@ops.ietf.org Tue Jan 20 17:41:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28966 for ; Tue, 20 Jan 2004 17:41:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj4WH-0009pP-BE for multi6-data@psg.com; Tue, 20 Jan 2004 22:38:49 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aj4W4-0009o8-Q1 for multi6@ops.ietf.org; Tue, 20 Jan 2004 22:38:36 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i0KMcYj4012115; Tue, 20 Jan 2004 14:38:34 -0800 (PST) Received: from d-mpk17-89-235.SFBay.Sun.COM (d-mpk17-89-235.SFBay.Sun.COM [129.146.89.235]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id i0KMcWQ24951; Tue, 20 Jan 2004 23:38:32 +0100 (MET) Subject: Re: threats ID From: Erik Nordmark To: Brian E Carpenter Cc: erik.nordmark@sun.com, Multi6 List In-Reply-To: <400D0CDD.81950E0C@zurich.ibm.com> References: <400D0CDD.81950E0C@zurich.ibm.com> Content-Type: text/plain Message-Id: <1074638317.18060.9.camel@bobo.sfbay.sun.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 20 Jan 2004 14:38:37 -0800 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2004-01-20 at 03:11, Brian E Carpenter wrote: > If a network-layer mh solution uses multiple identifiers, then what gets > hijacked is an individual identifier, not the node. Thus what is hijacked > is the subset of sessions in the node using the same identifier. > Transport-layer solutions can claim that they reduce that set of sessions > to one at a time. It is probably true in general that if normal traffic needs to do X amounts of work per transport connection, than a redirection attacker needs to do some work proportional to X per transport connection. Thus the ability to aggregate the signaling needed for rehoming for multiple transport connections would affect legitimate traffic just as much as it would affect an attacker. > Nevertheless I find it surprising for Matasaka to assert that most of > the threats in draft-nordmark-multi6-threats-00.txt only apply to > network layer solutions. Do people have an opinion about that? It might depend on the details of the transport layer solutions. Taking the premeditated redirection attack as an example. If an attacker can guess that port A on node B will talk to port C on node D in the near future, then premediated redirection attacks can be launched on a transport solution which identifies the "redirectable unit" by the 5-tuple. But if the transport solution uses some hard to guess random component (an SCTP verification tag is an example; another example would be some emphemeral IDs) to identify the redirectable unit, then it would be much harder to perform a premediated redirection attack. My take on this is that the threats exist in all cases. Different approaches, and in particular different bindings with transport level mechanisms, can provide rather different ways of handling the threats. Should it come to comparing transport vs. layer 3.5 approaches I think the hardest thing for a transport level approach is for UDP traffic; preventing the various threats for UDP isn't much different than preventing them for IP. Erik From owner-multi6@ops.ietf.org Tue Jan 20 18:02:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29584 for ; Tue, 20 Jan 2004 18:02:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj4rg-000CqJ-GN for multi6-data@psg.com; Tue, 20 Jan 2004 23:00:56 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Aj4rS-000CjF-Ub for multi6@ops.ietf.org; Tue, 20 Jan 2004 23:00:43 +0000 Received: (qmail 76259 invoked from network); 20 Jan 2004 23:09:54 -0000 Received: from h219-110-033-058.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.58) by necom830.hpcl.titech.ac.jp with SMTP; 20 Jan 2004 23:09:54 -0000 Message-ID: <400DB358.3030204@necom830.hpcl.titech.ac.jp> Date: Wed, 21 Jan 2004 08:01:44 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Scott W Brim CC: multi6@ops.ietf.org Subject: Re: Comments on draft-ohta-multi6-8plus8-00.txt References: <20040120161532.AB1B687316@mercury.lcs.mit.edu> <20040120164556.GI2000@sbrim-w2k01> In-Reply-To: <20040120164556.GI2000@sbrim-w2k01> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott W Brim; >>My memory may be failing here, but IIRC it was Dave Clark (in a long email >>message to some mailing list - the IPv6 or Big-I lists, maybe?) who first came >>up with the concept of splitting the IPv6 address field into two halves, for >>location and identity. > Copying what was done with NSAPs? XNS. However, the important difference to old proposals is existence of scalable reverse mapping from structured ID, which is common practice with IPv4 addresses and DNS, which may be attributed to someone in ISI, perhaps PVM. But, it is one thing to map from address to domain name and another to map from ID (to domain name and then) to locators. >>I think the main think Mike added, in coming up with GSE, was the >>concept that the border routers would fill in the high order parts of >>the locator portion. GSE mostly concentrate on source address spoofing and it mostly proposes rewriting of source locator portion. > I think so too. We could ask him. You may ask him. But, rewriting by the border routers is a bad idea w.r.t. the end to end principle that my 8+8 proposal does not use it. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 20 18:18:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29985 for ; Tue, 20 Jan 2004 18:18:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj57a-000Ef8-4B for multi6-data@psg.com; Tue, 20 Jan 2004 23:17:22 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Aj57N-000EdL-Sj for multi6@ops.ietf.org; Tue, 20 Jan 2004 23:17:10 +0000 Received: (qmail 76319 invoked from network); 20 Jan 2004 23:26:21 -0000 Received: from h219-110-033-058.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.58) by necom830.hpcl.titech.ac.jp with SMTP; 20 Jan 2004 23:26:21 -0000 Message-ID: <400DB734.8000307@necom830.hpcl.titech.ac.jp> Date: Wed, 21 Jan 2004 08:18:12 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 List Subject: Re: threats ID References: <400D2075.8040207@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; >> However, IP layer does not have any state of a connection, > That's not true. The routing table is state, It is not state of a connection. > as is per-destination path > MTU information. It is a wrong understanding of PMTUD issues. PMTUD is an issue of connections. A few years ago, transport people finally recognized it and had a BoF or WG to do PMTUD at the transport layer. I haven't traced the activity, because I think PMTUD is a bad idea even if it is implemented at the transport layer. > I'm not even going to mention IPsec. SPI is, effectively, is a transport layer identifier just as port numbers, which is one of a reason why design of IPsec is poor. >> because it is connectionless. > For a connection you need per-connection matching state in at least two > places, the source and the destination. For IP you still need state, but > it's per IP address or even per prefix, and it doesn't have to match on > both ends. But it's still state. See the first line of this mail. >> All the shim layers are working at least at layer 4 that there >> is no point to say layer 3.5 > I believe NOID and certainly ODT allow layer 4 to work without changes, You can believe so, just as you can believe NAT allow layer 4 to work without changes. > BTW, my point about man in the middle was that an attacker can still do > damage without having full man in the middle capabilities, for instance > by intercepting packets and injecting falsified ones, without > necessarily being able to stop the flow of traffic between the > endpoints. Sure. For example, on the Internet today without M6, you can modify DNS result by sending false answer before the real one is returned. > This is important, because true man in the middle capability > isn't something that is easily achieved, while "man on the sideline", > where the attacker can observe data and inject his own, but not stop the > real data from flowing, is fairly trivial to achieve in many situations. Maybe. But, it has nothing to do with M6. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 20 18:39:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01362 for ; Tue, 20 Jan 2004 18:39:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj5RV-000GoN-N8 for multi6-data@psg.com; Tue, 20 Jan 2004 23:37:57 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aj5RI-000Gjl-SN for multi6@ops.ietf.org; Tue, 20 Jan 2004 23:37:45 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0KNc4LS025161; Wed, 21 Jan 2004 00:38:04 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <400DB734.8000307@necom830.hpcl.titech.ac.jp> References: <400D2075.8040207@necom830.hpcl.titech.ac.jp> <400DB734.8000307@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: threats ID Date: Wed, 21 Jan 2004 00:37:38 +0100 To: Masataka Ohta X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 21-jan-04, at 0:18, Masataka Ohta wrote: >>> However, IP layer does not have any state of a connection, >> That's not true. The routing table is state, > It is not state of a connection. Ok. >> as is per-destination path MTU information. > It is a wrong understanding of PMTUD issues. > PMTUD is an issue of connections. > A few years ago, transport people finally recognized it and > had a BoF or WG to do PMTUD at the transport layer. I haven't > traced the activity, because I think PMTUD is a bad idea even > if it is implemented at the transport layer. In IPv4 PMTUD is mostly a TCP thing: UDP and other non-TCP packets are generally transmitted with the DF bit set to zero. However, this isn't possible in IPv6: if a router returns a "packet too big" ICMP message, the source is required to start fragmenting subsequent packets. So in IPv6, PMTUD is very much an IP layer issue, even if the transport layer is also aware of it. >> I believe NOID and certainly ODT allow layer 4 to work without >> changes, > You can believe so, just as you can believe NAT allow layer 4 to work > without changes. :-) The real problems start at layers above 4 with NAT... Fortunately none the MH mechanisms that have been proposed here use NAT (as far as I can remember, at least). >> This is important, because true man in the middle capability isn't >> something that is easily achieved, while "man on the sideline", where >> the attacker can observe data and inject his own, but not stop the >> real data from flowing, is fairly trivial to achieve in many >> situations. > Maybe. But, it has nothing to do with M6. I tend to agree but I don't think we can entirely dismiss the potential attacsk that go beyond what's possible today when attackers have this capability. From owner-multi6@ops.ietf.org Tue Jan 20 23:26:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09701 for ; Tue, 20 Jan 2004 23:26:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj9uI-000Hk2-3N for multi6-data@psg.com; Wed, 21 Jan 2004 04:23:58 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Aj9td-000Hi5-QD for multi6@ops.ietf.org; Wed, 21 Jan 2004 04:23:18 +0000 Received: (qmail 77110 invoked from network); 21 Jan 2004 04:32:31 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jan 2004 04:32:31 -0000 Message-ID: <400DFEF3.5040604@necom830.hpcl.titech.ac.jp> Date: Wed, 21 Jan 2004 13:24:19 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 List Subject: Re: threats ID References: <400D2075.8040207@necom830.hpcl.titech.ac.jp> <400DB734.8000307@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; >> A few years ago, transport people finally recognized it and >> had a BoF or WG to do PMTUD at the transport layer. I haven't >> traced the activity, because I think PMTUD is a bad idea even >> if it is implemented at the transport layer. > > > In IPv4 PMTUD is mostly a TCP thing: Whether PMTUD is a TCP thing or not is independent of IP layer. > UDP and other non-TCP packets are > generally transmitted with the DF bit set to zero. It is because minimum MTU of IPv4 is too small. > However, this isn't > possible in IPv6: if a router returns a "packet too big" ICMP message, > the source is required to start fragmenting subsequent packets. So in > IPv6, PMTUD is very much an IP layer issue, even if the transport layer > is also aware of it. Just send 1280 bytes. Given that all the protocols are required to operate with MTU of 1280 anyway, that most link will have MTU of 1500 forever, that no multicast protocols can perform PMTUD and that each transport and application layer protocol must be modified to accomodate PMTUD, there is no point to be bothered to have PMTUD. It is very good design of IPv6 to outlaw fragmentation. Even better is to make minimum MTU 1280. The best could have been to make minimum MTU 1500 to outlaw dialup protocol of PPP over Ethernet, though. > Fortunately none the MH mechanisms that have been proposed here use NAT > (as far as I can remember, at least). I'm not sure what do you mean "proposed" but Dave Crocker explicitely admit his proposal essentially NAT. >>> This is important, because true man in the middle capability isn't >>> something that is easily achieved, while "man on the sideline", where >>> the attacker can observe data and inject his own, but not stop the >>> real data from flowing, is fairly trivial to achieve in many situations. > > >> Maybe. But, it has nothing to do with M6. > > > I tend to agree but I don't think we can entirely dismiss the potential > attacsk that go beyond what's possible today when attackers have this > capability. I have shown, with DNS, that what's possible today is connection hijacking, which means it is already worst. Masataka Ohta From owner-multi6@ops.ietf.org Wed Jan 21 02:54:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10975 for ; Wed, 21 Jan 2004 02:54:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjDAJ-0005wO-45 for multi6-data@psg.com; Wed, 21 Jan 2004 07:52:43 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjD9k-0005ub-MR for multi6@ops.ietf.org; Wed, 21 Jan 2004 07:52:08 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0L7q6JX115994 for ; Wed, 21 Jan 2004 07:52:07 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0L7q6Ze233006 for ; Wed, 21 Jan 2004 08:52:06 +0100 Received: from zurich.ibm.com (sig-9-145-173-134.de.ibm.com [9.145.173.134]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA63432 for ; Wed, 21 Jan 2004 08:52:04 +0100 Message-ID: <400D73BF.2FA7FEB6@zurich.ibm.com> Date: Tue, 20 Jan 2004 19:30:23 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Subject: Re: Comments on draft-ohta-multi6-8plus8-00.txt References: <400D2A3C.5D985B42@zurich.ibm.com> <400D3ED2.3030709@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Factually, Mike first published a pure 8+8 proposal in draft-odell-8+8-00.txt in October 1996. GSE came later, in draft-ietf-ipngwg-gseaddr-00.txt in February 1997. Apart from that, I am aware of the history and I did read the current draft before making my comments. Brian Masataka Ohta wrote: > > Brian; > > > There should be an acknowledgement here to Mike O'Dell, who invented both > > the name and the original 8+8 proposal. Technically the current proposal > > is different, but it is unfair not to give Mike the credit. > > 8+8 is a generic terminology. It was used at least in 1994 in > big-internet ML. Note that Mike O'Dell, you and I were members > of the ML atthat time. Maybe, Mike O'Dell was the first person > to use the terminology "8+8" somewhere else. But, Mike O'Dell > and others used it as a generic terminology. > > Archive of big-internet can be found at: > > ftp://munnari.oz.au/big-internet/list-archive > > Later, Mike O'Dell made a proposal. It was named GSE. > > My architectural draft made it clear from the beginning: > > Note that 8+8 proposal must not be confused by latter proposal of > routing goof (GSE) 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. > > Read the draft. > > >>2.4.1 Locator Derived ID > > > > ... > > > >> That is, a site is assured to have 65,536 IDs assigned, though the > >> locator nature of the ID makes IDs not stable against site > >> renumbering. > > > > > > There are three major problems with this: > > > > 1. 65k ids is not enough. > > I never said 64K ID enough and the draft describes how the problem > can be solved. > > However, you are too pessimisitic. > > > If I take the example of my own company, we > > would certainly want to appear as a single "site" for multihoming (at > > many different ISP attachment points) but 65k hosts is nothing like enough. > > If your company has so many external connections, your company has > a lot more than 64K locator derived IDs that your company don't > have any problem. > > BTW, it is unwise that your company appears as a single "site" > for multihoming, because it makes your company valunerable to > internal link failures. > > > 2. As I understand it, each host burns up a subnet number. But in large > > systems people expect to use toplogically significant subnet numbering, > > and the numbering plan must survive any amount of moving of computers from > > one building to another. That is incompatible with tying a subnet number > > to a host. > > There is no tying. My draft says: > > Note that ID assignment within a site can be arbitrary and will > not be consistent of intra site link structure. That is, an end > with a locator derived ID including a certain subnet id > may be located anywhere in the site, not necessarily in the > subnet corresponding to the subnet id. > > > 3. As noted in the draft, renumbering breaks these IDs so they cannot be > > regarded as having long term stability. > > Of course, not. > > But, it should be noted that the longevity is expected to be > longer than that of hash of public keys, because security > sensitive people change keys more frequently than ISPs. > > Those who need even better longevity are taken care of by > the draft. > > >> Note that ID assignment within a site can be arbitrary and will not > >> be consistent of intra site link structure. That is, an end with a > >> locator derived ID including a certain subnet id may be located > >> anywhere in the site, not necessarily in the subnet corresponding to > >> the subnet id. > > > > > > This seems entirely inconsistent. It seems to say that when a host is > > moved, its ID can no longer be derived from its locator. > > No. > > The draft says: > > IDs may be derived from locators allocated to sites. > > not > > ID may be derived from a locator allocated to an end. > > But, I try to further improve the explanation. > > >> If one want to hide its privacy in ID, one should use locator derived > >> ID for one's ends. > > > I see no privacy enhancement here. These IDs are just numbers, and they > > are persistent (at least until the site is renumbered). If you want to > > enhance privacy, the last 16 bits would need to be a temporary pseudo- > > random value. > > Wrong. Your locator is persistent and is known by your peers > that there is no point of hiding it. > > > I think that only the location independent IDs of section 2.4.2 > > are really interesting, but as we have discussed often, it is not > > obvious that a 64 bit space will really work for this. These > > are old arguments from when we discussed the original 8+8 proposal a > > few years ago. > > It is an older argument positive answers to which can be found in > bigi archive. > > >>4.1 Modification to TCP > >> > >> A new TCP option, Multi Address option, is introduced. > > > > > > How are SCTP, UDP, and DCCP handled? > > Read the draft. > > >> It is expected that 9 locators are enough for most ends, as a site of > >> the end can be multihomed to three lower level ISPs each multihomed > >> to 3 top level ISPs. However, if an end has more than 9 locators, > >> which is a case with routers with more than 9 interfaces, TCP or > >> upper layer modules should be responsible to select 9 or less > >> locators to be used for the TCP connection. > > > > > > It seems very doubtful architecturally to have a hard limit on the > > number of addresses and to throw yet more address selection problems > > onto every transport layer implementation. Yes, 9 addresses may cover > > most cases, but the code will have to cover *every* case. > > 9 is not a hard limit. Read the draft. > > >>4.3 8+8 Adaptation Layers for Applications over TCP and DNS > >> > >> The 8+8 adaptation layers make end to end multihoming invisible to > >> applications over TCP and DNS, that is, applications using TCP > >> transport only without hard coded IP addresses. > >> > >> Some multihoming proposals try to introduce an adaptation layer in > >> the Internetworking layer to hide locator changes. However, this > >> attempt does not make sense. As demonstrated by NAT, rewriting of > >> addresses is, in general, not transparent to transport and > >> application protocols. > > > > > > But *reversible* rewriting, as originally proposed by Mike O'Dell and > > found also in NOID for example, *is* transparent to IPSEC, transport, > > and application protocols. > > Mike O'Dell imitated existing 8+8 proposals to modify TCP and > other transport layer protocols not to include locator > part for checksuming and IPSEC calculation, which is a > modification to the transport layer protocols. Of course, it is > not transparent to application protocols like FTP. > > GSE draft says: > > One immediate result is that upper-layer protocols must use only the > ESD for purposes such as pseudo-header checksums and the like. > > > The original O'Dell 8+8 forced the state down into the border > > routers. > > That's why only way to make it transparent to IPSEC and transport > is not to protect locator by IPSEC nor transport checksums. > > You should not rely on your memory and check appropriate references > when you want to say something in the past. I do check them. > > Masataka Ohta -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Wed Jan 21 02:55:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10993 for ; Wed, 21 Jan 2004 02:55:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjDA2-0005vK-6S for multi6-data@psg.com; Wed, 21 Jan 2004 07:52:26 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjD9n-0005uj-V3 for multi6@ops.ietf.org; Wed, 21 Jan 2004 07:52:12 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0L7qAJX070516 for ; Wed, 21 Jan 2004 07:52:10 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0L7qAgZ246204 for ; Wed, 21 Jan 2004 08:52:10 +0100 Received: from zurich.ibm.com (sig-9-145-173-134.de.ibm.com [9.145.173.134]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA66976 for ; Wed, 21 Jan 2004 08:52:08 +0100 Message-ID: <400D752A.21CAA9ED@zurich.ibm.com> Date: Tue, 20 Jan 2004 19:36:26 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Reminder re multi6 drafts References: <3FD594B6.FC368986@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It's getting very close to the end of January. We are still hoping for HIP and SCTP based drafts this month, so that they can be thoroughly analyzed before the IETF. Brian Brian E Carpenter wrote: > > Folks, > > Just a reminder that we'd like all updated or new drafts describing > possible approaches to solutions for multi6 to be submitted in the > near future. We originally suggested a hard deadline of the end > of December, but since people found that too rigid, let's try for > having all the I-Ds available by mid-January at the latest. > In addition to the existing proposals discussed in Minneapolis, > we are at least expecting HIP and SCTP based contributions. > > We do ask that each draft includes a *short* self-assessment against the > goals in RFC 3582. For convenience, please name them as > draft-AUTHOR-multi6-... > > Please remember that one of our objectives is to identify architectural > components that occur in the various proposals. > > The co-chairs are acutely aware that the published charter for this > WG is out of date. We do plan to fix that. > > Brian > multi6 co-chair > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Wed Jan 21 02:55:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11011 for ; Wed, 21 Jan 2004 02:55:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjDAY-0005xB-4l for multi6-data@psg.com; Wed, 21 Jan 2004 07:52:58 +0000 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjDAJ-0005wN-JU for multi6@ops.ietf.org; Wed, 21 Jan 2004 07:52:43 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0L7q9JW074670; Wed, 21 Jan 2004 07:52:09 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0L7q8gZ268752; Wed, 21 Jan 2004 08:52:08 +0100 Received: from zurich.ibm.com (sig-9-145-173-134.de.ibm.com [9.145.173.134]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA66974; Wed, 21 Jan 2004 08:52:06 +0100 Message-ID: <400D74B6.2F3275C5@zurich.ibm.com> Date: Tue, 20 Jan 2004 19:34:30 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Masataka Ohta CC: mbagnulo@ing.uc3m.es, Multi6 List Subject: Re: threats ID References: <400D0CDD.81950E0C@zurich.ibm.com> <400D283D.8070607@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: > > Brian; > > > Nevertheless I find it surprising for Matasaka to assert that most of > > the threats in draft-nordmark-multi6-threats-00.txt only apply to > > network layer solutions. Do people have an opinion about that? > > It's marcelo who wrote: > > Erik & Tony's draft essentially analyze the threats from > a IP layer perspective > > I myself do not think so called network layer solutions ever exist. > > Read my architectural draft on why there can't be. The WG will be tackling architectural analysis as its next major effort. I think there will be people who have a different opinion from you. Brian From owner-multi6@ops.ietf.org Wed Jan 21 04:06:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12962 for ; Wed, 21 Jan 2004 04:06:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjEHe-000CSy-0J for multi6-data@psg.com; Wed, 21 Jan 2004 09:04:22 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AjEHR-000CRi-P7 for multi6@ops.ietf.org; Wed, 21 Jan 2004 09:04:09 +0000 Received: (qmail 77937 invoked from network); 21 Jan 2004 09:13:28 -0000 Received: from h219-110-034-155.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.34.155) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jan 2004 09:13:28 -0000 Message-ID: <400E40C8.6000104@necom830.hpcl.titech.ac.jp> Date: Wed, 21 Jan 2004 18:05:12 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: multi6@ops.ietf.org Subject: Re: Reminder re multi6 drafts References: <3FD594B6.FC368986@zurich.ibm.com> <400D752A.21CAA9ED@zurich.ibm.com> In-Reply-To: <400D752A.21CAA9ED@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > It's getting very close to the end of January. We are still > hoping for HIP and SCTP based drafts this month, so that they can > be thoroughly analyzed before the IETF. I'm afraid you wrote: >>having all the I-Ds available by mid-January at the latest. Masataka Ohta From owner-multi6@ops.ietf.org Wed Jan 21 04:10:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13047 for ; Wed, 21 Jan 2004 04:10:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjEMU-000Cog-9R for multi6-data@psg.com; Wed, 21 Jan 2004 09:09:22 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AjEMI-000Cny-4G for multi6@ops.ietf.org; Wed, 21 Jan 2004 09:09:10 +0000 Received: (qmail 77955 invoked from network); 21 Jan 2004 09:18:29 -0000 Received: from h219-110-034-155.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.34.155) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jan 2004 09:18:29 -0000 Message-ID: <400E41F5.8060005@necom830.hpcl.titech.ac.jp> Date: Wed, 21 Jan 2004 18:10:13 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: mbagnulo@ing.uc3m.es, Multi6 List Subject: Re: threats ID References: <400D0CDD.81950E0C@zurich.ibm.com> <400D283D.8070607@necom830.hpcl.titech.ac.jp> <400D74B6.2F3275C5@zurich.ibm.com> In-Reply-To: <400D74B6.2F3275C5@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; >>>Nevertheless I find it surprising for Matasaka to assert that most of >>>the threats in draft-nordmark-multi6-threats-00.txt only apply to >>>network layer solutions. Do people have an opinion about that? >> >>It's marcelo who wrote: >> >> Erik & Tony's draft essentially analyze the threats from >> a IP layer perspective >> >>I myself do not think so called network layer solutions ever exist. >> >>Read my architectural draft on why there can't be. > > > The WG will be tackling architectural analysis as its next major effort. > I think there will be people who have a different opinion from you. If you have a different opinion from me, post it with technical reasons, or better, write a draft. If you don't, don't expect others do. Never say others might do something. Others can take care of themselves. That is the constructive way of discussion. Masataka Ohta From owner-multi6@ops.ietf.org Wed Jan 21 04:25:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13515 for ; Wed, 21 Jan 2004 04:25:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjEaz-000E0b-Kv for multi6-data@psg.com; Wed, 21 Jan 2004 09:24:21 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AjEan-000Dzn-8v for multi6@ops.ietf.org; Wed, 21 Jan 2004 09:24:09 +0000 Received: (qmail 78031 invoked from network); 21 Jan 2004 09:33:28 -0000 Received: from h219-110-034-155.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.34.155) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jan 2004 09:33:28 -0000 Message-ID: <400E4579.7030307@necom830.hpcl.titech.ac.jp> Date: Wed, 21 Jan 2004 18:25:13 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 Subject: Re: Comments on draft-ohta-multi6-8plus8-00.txt References: <400D2A3C.5D985B42@zurich.ibm.com> <400D3ED2.3030709@necom830.hpcl.titech.ac.jp> <400D73BF.2FA7FEB6@zurich.ibm.com> In-Reply-To: <400D73BF.2FA7FEB6@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Factually, Mike first published a pure 8+8 proposal in > draft-odell-8+8-00.txt in October 1996. If you say ID "published", I published a pure 8+8 proposal in draft-ohta-ipv6-addr-arch-00.txt in March 1995, though I'm not sure it was the first one of mine. The draft, for example, says: By separating a 128 bit IPv6 address into 64 bit ILOC (Internet LOCator), first 4 bytes of which is flat routable provider part and the rest 4 bytes of which is hierarchical intra-provider part, and 64 bit IID (Internet ID), which is not routable but globally unique, it is possible to preserve some of the provider independence of IPv4. Other people were publishing their own 8+8 proposals then. > Apart from that, I am aware of the history and I did read > the current draft before making my comments. You should read the past draft, because you made request directly involving them. In draft-odell-8+8-00.txt, it is written The addressing model proposed here is called "8+8" to distinguish it from the existing proposals which are called "Flat-16" in this document. but such addressing model can be found in XNS and the model has been discussed in big-internet ML before 1994 that there is no originality. Moreover, there are other drafts, including mine, on the idea which predate Mike's. Masataka Ohta From owner-multi6@ops.ietf.org Wed Jan 21 07:09:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17378 for ; Wed, 21 Jan 2004 07:09:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjH9P-0003ne-Op for multi6-data@psg.com; Wed, 21 Jan 2004 12:08:03 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjH9A-0003mx-Jq for multi6@ops.ietf.org; Wed, 21 Jan 2004 12:07:48 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0LC7Ie2058870; Wed, 21 Jan 2004 12:07:18 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0LC7IZe212662; Wed, 21 Jan 2004 13:07:18 +0100 Received: from zurich.ibm.com (sig-9-145-173-134.de.ibm.com [9.145.173.134]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA36706; Wed, 21 Jan 2004 13:07:13 +0100 Message-ID: <400E6B29.E84AA429@zurich.ibm.com> Date: Wed, 21 Jan 2004 13:06:01 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Masataka Ohta CC: multi6@ops.ietf.org Subject: Re: Reminder re multi6 drafts References: <3FD594B6.FC368986@zurich.ibm.com> <400D752A.21CAA9ED@zurich.ibm.com> <400E40C8.6000104@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: > > Brian; > > > It's getting very close to the end of January. We are still > > hoping for HIP and SCTP based drafts this month, so that they can > > be thoroughly analyzed before the IETF. > > I'm afraid you wrote: > > >>having all the I-Ds available by mid-January at the latest. True. But since we didn't get all the expected drafts by then, we are still *hoping*, as I wrote. Please interpret my words as carefully as you expect other people to interpret yours. Brian From owner-multi6@ops.ietf.org Wed Jan 21 07:25:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17807 for ; Wed, 21 Jan 2004 07:25:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjHPA-00055p-MN for multi6-data@psg.com; Wed, 21 Jan 2004 12:24:20 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AjHOy-00055D-8j for multi6@ops.ietf.org; Wed, 21 Jan 2004 12:24:08 +0000 Received: (qmail 78544 invoked from network); 21 Jan 2004 12:33:30 -0000 Received: from h219-110-034-155.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.34.155) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jan 2004 12:33:30 -0000 Message-ID: <400E6FA7.3000104@necom830.hpcl.titech.ac.jp> Date: Wed, 21 Jan 2004 21:25:11 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: multi6@ops.ietf.org Subject: Re: Reminder re multi6 drafts References: <3FD594B6.FC368986@zurich.ibm.com> <400D752A.21CAA9ED@zurich.ibm.com> <400E40C8.6000104@necom830.hpcl.titech.ac.jp> <400E6B29.E84AA429@zurich.ibm.com> In-Reply-To: <400E6B29.E84AA429@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; >>>>having all the I-Ds available by mid-January at the latest. > > > True. But since we didn't get all the expected drafts by then, > we are still *hoping*, as I wrote. Then, what is the new deadline "at the latest"? > Please interpret my words as carefully as you expect other > people to interpret yours. It is of course for me to interpret someone's words carefully. However, careful interpretation of your words has shown that you seems to have changed the deadline for some proposal you prefer but you are careless enough not to annouce the change to give other proposals equal chance. In short, BE FAIR. Masataka Ohta From owner-multi6@ops.ietf.org Wed Jan 21 08:17:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19259 for ; Wed, 21 Jan 2004 08:17:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjICt-0009Rt-Pi for multi6-data@psg.com; Wed, 21 Jan 2004 13:15:43 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjICg-0009QX-LV for multi6@ops.ietf.org; Wed, 21 Jan 2004 13:15:30 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0LDEwJX116236; Wed, 21 Jan 2004 13:14:58 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0LDEwZe203770; Wed, 21 Jan 2004 14:14:58 +0100 Received: from zurich.ibm.com (sig-9-145-173-134.de.ibm.com [9.145.173.134]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA53492; Wed, 21 Jan 2004 14:14:52 +0100 Message-ID: <400E7B07.352C1A2@zurich.ibm.com> Date: Wed, 21 Jan 2004 14:13:43 +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: Masataka Ohta CC: multi6@ops.ietf.org Subject: Re: Reminder re multi6 drafts References: <3FD594B6.FC368986@zurich.ibm.com> <400D752A.21CAA9ED@zurich.ibm.com> <400E40C8.6000104@necom830.hpcl.titech.ac.jp> <400E6B29.E84AA429@zurich.ibm.com> <400E6FA7.3000104@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The flexible deadline is the same for everybody, obviously. Brian Masataka Ohta wrote: > > Brian; > > >>>>having all the I-Ds available by mid-January at the latest. > > > > > > True. But since we didn't get all the expected drafts by then, > > we are still *hoping*, as I wrote. > > Then, what is the new deadline "at the latest"? > > > Please interpret my words as carefully as you expect other > > people to interpret yours. > > It is of course for me to interpret someone's words carefully. > > However, careful interpretation of your words has shown that > you seems to have changed the deadline for some proposal > you prefer but you are careless enough not to annouce the > change to give other proposals equal chance. > > In short, BE FAIR. > > Masataka Ohta -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Wed Jan 21 21:02:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21492 for ; Wed, 21 Jan 2004 21:02:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjU80-000IOb-Cd for multi6-data@psg.com; Thu, 22 Jan 2004 01:59:28 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AjU7o-000IO5-40 for multi6@ops.ietf.org; Thu, 22 Jan 2004 01:59:16 +0000 Received: (qmail 81049 invoked from network); 22 Jan 2004 02:08:48 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 22 Jan 2004 02:08:48 -0000 Message-ID: <400F2EB5.2040705@necom830.hpcl.titech.ac.jp> Date: Thu, 22 Jan 2004 11:00:21 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: multi6@ops.ietf.org Subject: Re: Reminder re multi6 drafts References: <3FD594B6.FC368986@zurich.ibm.com> <400D752A.21CAA9ED@zurich.ibm.com> <400E40C8.6000104@necom830.hpcl.titech.ac.jp> <400E6B29.E84AA429@zurich.ibm.com> <400E6FA7.3000104@necom830.hpcl.titech.ac.jp> <400E7B07.352C1A2@zurich.ibm.com> In-Reply-To: <400E7B07.352C1A2@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > The flexible deadline is the same for everybody, obviously. The current announcement on deadline is: > We originally suggested a hard deadline of the end > of December, but since people found that too rigid, let's try for > having all the I-Ds available by mid-January at the latest. that the deadline is at "the end of December" with the maximum flexibility of "mid-January at the latest". If you have changed it, announce it well before the real final absolute deadline. We also expect that the announcement is accompanied with explanation on why we have much time to analyze proposals with the shortened period. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jan 22 15:00:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06922 for ; Thu, 22 Jan 2004 15:00:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ajkxv-0002LC-RA for multi6-data@psg.com; Thu, 22 Jan 2004 19:58:11 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ajkxi-0002Ix-SH for multi6@ops.ietf.org; Thu, 22 Jan 2004 19:57:58 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 31E5FFA48; Thu, 22 Jan 2004 14:57:58 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Jan 2004 14:57:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Reminder re multi6 drafts Date: Thu, 22 Jan 2004 14:57:52 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05836BAF@tayexc13.americas.cpqcorp.net> Thread-Topic: Reminder re multi6 drafts Thread-Index: AcPf9HobOz9sXY5zQU2WsJ/CEqD1rABLXwnA From: "Bound, Jim" To: "Brian E Carpenter" , X-OriginalArrivalTime: 22 Jan 2004 19:57:57.0865 (UTC) FILETIME=[082A8D90:01C3E122] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable SCTP will not happen before this month. Randy, Yanick, and I cannot get it done. Sorry. /jim > -----Original Message----- > From: owner-multi6@ops.ietf.org=20 > [mailto:owner-multi6@ops.ietf.org] On Behalf Of Brian E Carpenter > Sent: Tuesday, January 20, 2004 1:36 PM > To: multi6@ops.ietf.org > Subject: Re: Reminder re multi6 drafts >=20 >=20 > It's getting very close to the end of January. We are still > hoping for HIP and SCTP based drafts this month, so that they can=20 > be thoroughly analyzed before the IETF. >=20 > Brian >=20 > Brian E Carpenter wrote: > >=20 > > Folks, > >=20 > > Just a reminder that we'd like all updated or new drafts describing > > possible approaches to solutions for multi6 to be submitted in the > > near future. We originally suggested a hard deadline of the end > > of December, but since people found that too rigid, let's try for > > having all the I-Ds available by mid-January at the latest. > > In addition to the existing proposals discussed in Minneapolis, > > we are at least expecting HIP and SCTP based contributions. > >=20 > > We do ask that each draft includes a *short*=20 > self-assessment against the > > goals in RFC 3582. For convenience, please name them as > > draft-AUTHOR-multi6-... > >=20 > > Please remember that one of our objectives is to identify=20 > architectural > > components that occur in the various proposals. > >=20 > > The co-chairs are acutely aware that the published charter for this > > WG is out of date. We do plan to fix that. > >=20 > > Brian > > multi6 co-chair > > -- > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Brian E Carpenter > > Distinguished Engineer, Internet Standards & Technology, IBM > >=20 > > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK >=20 > --=20 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter=20 > Distinguished Engineer, Internet Standards & Technology, IBM >=20 >=20 >=20 From owner-multi6@ops.ietf.org Fri Jan 23 01:12:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01668 for ; Fri, 23 Jan 2004 01:12:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjuVH-000I0E-Fo for multi6-data@psg.com; Fri, 23 Jan 2004 06:09:15 +0000 Received: from [194.23.29.183] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjuV3-000HyY-EU for multi6@ops.ietf.org; Fri, 23 Jan 2004 06:09:01 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id A6525271162; Fri, 23 Jan 2004 07:09:00 +0100 (CET) In-Reply-To: <400DB734.8000307@necom830.hpcl.titech.ac.jp> References: <400D2075.8040207@necom830.hpcl.titech.ac.jp> <400DB734.8000307@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List , Iljitsch van Beijnum From: Kurt Erik Lindqvist Subject: Re: threats ID Date: Fri, 23 Jan 2004 07:08:55 +0100 To: Masataka Ohta X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-01-21, at 00.18, Masataka Ohta wrote: > >>> All the shim layers are working at least at layer 4 that there >>> is no point to say layer 3.5 > >> I believe NOID and certainly ODT allow layer 4 to work without >> changes, > > You can believe so, just as you can believe NAT allow layer 4 to work > without changes. I think there is a notable difference. In my reading you are using NAT very loose for all forms of address rewrite. NAT to me does static rewrites, with no form of signaling. Especially breaking referrals by hiding the "true" address to the outside world. Most (if not all) id/loc proposals here (claims) that referrals do work. There is a hugh difference, referrals is a crucial component of any multi6 solution. This was also pointed out in the comments by Patrick. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQBC6e6arNKXTPFCVEQImvwCcDoBM5177jO1C6WQ++TucSj1pEDAAoNTG 1svbaU1MeroTte30Y61qcmfD =aO7Q -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Fri Jan 23 01:51:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02656 for ; Fri, 23 Jan 2004 01:51:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ajv9J-000LwS-HI for multi6-data@psg.com; Fri, 23 Jan 2004 06:50:37 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Ajv94-000Lua-9x for multi6@ops.ietf.org; Fri, 23 Jan 2004 06:50:22 +0000 Received: (qmail 86355 invoked from network); 23 Jan 2004 07:00:16 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 23 Jan 2004 07:00:16 -0000 Message-ID: <4010C470.7010606@necom830.hpcl.titech.ac.jp> Date: Fri, 23 Jan 2004 15:51:28 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Multi6 List , Iljitsch van Beijnum Subject: Re: threats ID References: <400D2075.8040207@necom830.hpcl.titech.ac.jp> <400DB734.8000307@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt; >>>I believe NOID and certainly ODT allow layer 4 to work without >>>changes, >> >>You can believe so, just as you can believe NAT allow layer 4 to work >>without changes. > > > I think there is a notable difference. In my reading you are using NAT > very loose for all forms of address rewrite. NAT to me does static > rewrites, with no form of signaling. Wrong. Rewriting is not the essential problem. Right. The problem is lack of signaling OF *CONNECTIONS*. As you might know, there is no connections and signaling at the IP layer. Thus, the only thing NAT and other layer 3 things can do is guessing the connection state by a lack of communication for certain period of time, though, sometimes, you can detect TCP SYN and FIN. However, that you observe no traffic over a connection does not necessarily mean that the connection is broken. That there is no response for a UDP packet may mean that an reply ack is lost, that no reply is required by the protocol above UDP or that the packet is an ack. There is no signaling unless layer 4 and above are involved, though guessing may work for TCP. > Especially breaking referrals by > hiding the "true" address to the outside world. Most (if not all) > id/loc proposals here (claims) that referrals do work. There is a hugh > difference, referrals is a crucial component of any multi6 solution. > This was also pointed out in the comments by Patrick. NAT rewriting is transparent to applicaitons, if the applications relies on TCP and DNS and DNS is modified to reflect the rewriting. So are other proposals, including mine, as is explained in my proposal. However, TCP is not IP, which is the point of my presentation at Vienna. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jan 23 05:03:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22623 for ; Fri, 23 Jan 2004 05:03:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ajy7O-000DiP-Kv for multi6-data@psg.com; Fri, 23 Jan 2004 10:00:50 +0000 Received: from [195.212.29.156] (helo=mtagate7.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ajy76-000Dgk-Lp for multi6@ops.ietf.org; Fri, 23 Jan 2004 10:00:32 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0NA0URm104358 for ; Fri, 23 Jan 2004 10:00:30 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0NA0UNu274400 for ; Fri, 23 Jan 2004 11:00:30 +0100 Received: from zurich.ibm.com (sig-9-145-174-249.de.ibm.com [9.145.174.249]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA63560 for ; Fri, 23 Jan 2004 11:00:27 +0100 Message-ID: <4010F077.AF929268@zurich.ibm.com> Date: Fri, 23 Jan 2004 10:59:19 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Subject: Comments needed on a few multi6 drafts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In our draft revised charter we have three aggressive milestones: MAR 04 Submit informational I-D to IESG on how multihoming is done today MAR 04 Submit informational I-D to IESG on practical questions MAR 04 Submit informational I-D to IESG on security threats Could everybody who has further comments on the following drafts please send them promptly, so that we can ask the various document authors/editors to prepare new versions for WG Last Call very soon: draft-ietf-multi6-v4-multihoming-00 (very expired, but you can find it at http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-multi6-v4-multihoming-00.txt) draft-lear-multi6-things-to-think-about-00.txt draft-nordmark-multi6-threats-00.txt draft-ohta-multi6-threats-00.txt (The last two should, for consistency with the draft charter, become a single WG draft). Thanks Brian + Kurtis From owner-multi6@ops.ietf.org Fri Jan 23 05:47:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23878 for ; Fri, 23 Jan 2004 05:47:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjypL-000Hto-VW for multi6-data@psg.com; Fri, 23 Jan 2004 10:46:15 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ajyp8-000HsJ-9D for multi6@ops.ietf.org; Fri, 23 Jan 2004 10:46:02 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0NAjje2052702; Fri, 23 Jan 2004 10:45:45 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0NAjiFi264046; Fri, 23 Jan 2004 11:45:44 +0100 Received: from zurich.ibm.com (sig-9-145-174-249.de.ibm.com [9.145.174.249]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA59202; Fri, 23 Jan 2004 11:45:42 +0100 Message-ID: <4010FB11.A2E07714@zurich.ibm.com> Date: Fri, 23 Jan 2004 11:44:33 +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: "Bound, Jim" CC: multi6@ops.ietf.org Subject: Re: Reminder re multi6 drafts References: <9C422444DE99BC46B3AD3C6EAFC9711B05836BAF@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim, We understand of course that there are only 168 hours a week. The WG will have to take an architectural decision at some point whether to pursue transport layer solution(s). Without the SCTP case being on the table, we will be handicapped. If anybody else feels like doing even a superficial job on SCTP in the next few days, that would be very helpful. Brian "Bound, Jim" wrote: > > SCTP will not happen before this month. Randy, Yanick, and I cannot get > it done. Sorry. > /jim > > > -----Original Message----- > > From: owner-multi6@ops.ietf.org > > [mailto:owner-multi6@ops.ietf.org] On Behalf Of Brian E Carpenter > > Sent: Tuesday, January 20, 2004 1:36 PM > > To: multi6@ops.ietf.org > > Subject: Re: Reminder re multi6 drafts > > > > > > It's getting very close to the end of January. We are still > > hoping for HIP and SCTP based drafts this month, so that they can > > be thoroughly analyzed before the IETF. > > > > Brian > > > > Brian E Carpenter wrote: > > > > > > Folks, > > > > > > Just a reminder that we'd like all updated or new drafts describing > > > possible approaches to solutions for multi6 to be submitted in the > > > near future. We originally suggested a hard deadline of the end > > > of December, but since people found that too rigid, let's try for > > > having all the I-Ds available by mid-January at the latest. > > > In addition to the existing proposals discussed in Minneapolis, > > > we are at least expecting HIP and SCTP based contributions. > > > > > > We do ask that each draft includes a *short* > > self-assessment against the > > > goals in RFC 3582. For convenience, please name them as > > > draft-AUTHOR-multi6-... > > > > > > Please remember that one of our objectives is to identify > > architectural > > > components that occur in the various proposals. > > > > > > The co-chairs are acutely aware that the published charter for this > > > WG is out of date. We do plan to fix that. > > > > > > Brian > > > multi6 co-chair > > > -- From owner-multi6@ops.ietf.org Fri Jan 23 05:52:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23983 for ; Fri, 23 Jan 2004 05:52:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ajyu3-000IWQ-PS for multi6-data@psg.com; Fri, 23 Jan 2004 10:51:07 +0000 Received: from [195.212.29.156] (helo=mtagate7.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ajytm-000IVW-Rc for multi6@ops.ietf.org; Fri, 23 Jan 2004 10:50:51 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0NAonRm031436 for ; Fri, 23 Jan 2004 10:50:49 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0NAonNu243158 for ; Fri, 23 Jan 2004 11:50:49 +0100 Received: from zurich.ibm.com (sig-9-145-174-249.de.ibm.com [9.145.174.249]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA55680 for ; Fri, 23 Jan 2004 11:50:48 +0100 Message-ID: <4010FC42.20CD4732@zurich.ibm.com> Date: Fri, 23 Jan 2004 11:49:38 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Subject: [Fwd: Submitting the multi6 charter] Content-Type: multipart/mixed; boundary="------------E2A2795498F58238F0D9DCCC" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------E2A2795498F58238F0D9DCCC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Submitting the multi6 charter Date: Fri, 23 Jan 2004 11:48:55 +0100 From: Brian E Carpenter Organization: IBM To: Bert Wijnen ,David Kessens CC: Kurt Erik Lindqvist Bert, David, This is the updated multi6 charter which we would like approved and posted. It has been updated according to comments from the WG. Brian --------------E2A2795498F58238F0D9DCCC Content-Type: text/plain; charset=us-ascii; name="multi6-charter-0104.txt" Content-Disposition: inline; filename="multi6-charter-0104.txt" Content-Transfer-Encoding: 7bit Description of Working Group: ============================= A multihomed site is a site that has more than one connection to the public internet with those connections through either the same or different ISPs. Sites choose to multihome for several reasons, especially to improve fault tolerance, perform load balancing, etc. Multihoming today is done largely by having a site obtain a dedicated block of address space and then advertising a route for its prefix through each of its ISP connections. The address block may be from the so-called provider independent space, or may be a sub-allocation from one of its ISPs. A site's ISPs in turn advertise the prefix to some or all of their upstream connections and the route for the prefix may propagate to all of the routers connected to the default-free zone (DFZ). As the number of sites multihoming in this manner increase, the number of routes propagated throughout the DFZ increases and overall routing stability decreases because of the burden on convergence time. This WG will seek alternative approaches with better scaling properties. Specifically, the WG will prefer multihoming solutions that tend to minimise adverse impacts on the end-to-end routing system and limit the number of prefixes that need to be advertised in the Default-Free Zone (DFZ). Part of these solutions might be a phased introduction, i.e. solutions that address the site-wide problem per host. In the course of this work, the WG may also study the deeper underlying questions of identity and location of services, hosts and sites as they directly affect multihoming. However, the working group is not chartered to make significant changes to the nature of IP addresses or to inter-domain routing. This WG will consider the problem of how to multihome sites in IPv6. The multihoming approaches currently used in IPv4 can of course be used in IPv6, but IPv6 represents an opportunity for more scalable approaches. IPv6 differs from IPv4 in ways that may allow for different approaches to multihoming that are not immediately applicable to IPv4. For example, IPv6 has larger addresses, hosts support multiple addresses per interface, and relatively few IPv6 address blocks have been given out (i.e., there are no issues with legacy allocations as in IPv4). Also, IPv6 deployment is at an early stage, so modest enhancements to IPv6 could still be proposed. The WG has already produced a document, RFC 3582, on goals for IPv6 site multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented there. The WG will take on the following tasks: ======================================== Produce a document describing how multihoming is done today in IPv4, including an explanation of both the advantages and limitations of the approaches. Produce a document outlining practical questions to be considered when evaluating proposals meeting the RFC 3582 goals, including questions concerning upper layer protocols. Produce a document describing the security threats to be addressed by multihoming solutions. Solicit and evaluate specific proposals to multihoming in IPv6 (both existing and new), extract and analyse common architectural features, and select one or a small number of proposals for further development. The architectural analysis will include applications layer considerations as well as lower layer issues. Development of specific solutions will require approval of the IESG (e.g., a recharter). Goals and Milestones: JUN 03 Goals for a multihoming solution as RFC - done DEC 03 Final solicitation of proposals - done FEB 04 Begin architectural evaluation of proposals MAR 04 Submit informational I-D to IESG on how multihoming is done today MAR 04 Submit informational I-D to IESG on practical questions MAR 04 Submit informational I-D to IESG on security threats APR 04 First draft of architectural evaluation AUG 04 Submit informational I-D to IESG on architectural evaluation SEP 04 Identify proposal(s) for further development, recharter if needed --------------E2A2795498F58238F0D9DCCC-- From owner-multi6@ops.ietf.org Fri Jan 23 06:01:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24254 for ; Fri, 23 Jan 2004 06:01:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ajz2i-000Jtp-54 for multi6-data@psg.com; Fri, 23 Jan 2004 11:00:04 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ajz2R-000Jq5-I3 for multi6@ops.ietf.org; Fri, 23 Jan 2004 10:59:47 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0NAxke2058722 for ; Fri, 23 Jan 2004 10:59:46 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0NAxjFi246416 for ; Fri, 23 Jan 2004 11:59:46 +0100 Received: from zurich.ibm.com (sig-9-145-174-249.de.ibm.com [9.145.174.249]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA27594 for ; Fri, 23 Jan 2004 11:59:44 +0100 Message-ID: <4010FE5B.CC87E40@zurich.ibm.com> Date: Fri, 23 Jan 2004 11:58:35 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 List Subject: Re: threats ID References: <400D2075.8040207@necom830.hpcl.titech.ac.jp> <400DB734.8000307@necom830.hpcl.titech.ac.jp> <4010C470.7010606@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka, you conclude by saying > However, TCP is not IP, which is the point of my presentation > at Vienna. We can hardly disagree. But TCP is not SCTP, UDP, DCCP or ICMP either. The systems level argument for a layer 3.5 solution is that it can cover all cases, including ones we have not invented yet. You are correct that a layer 3.5 solution requires cached state, probably with timeouts due to the lack of disconnect signalling. There is a classical solution to that, which is for the ULP to send a keepalive signal to prevent the cache from timing out. That would indeed be a ULP enhancement, but a very minor one and not essential. Brian Masataka Ohta wrote: > > Kurt; > > >>>I believe NOID and certainly ODT allow layer 4 to work without > >>>changes, > >> > >>You can believe so, just as you can believe NAT allow layer 4 to work > >>without changes. > > > > > > I think there is a notable difference. In my reading you are using NAT > > very loose for all forms of address rewrite. NAT to me does static > > rewrites, with no form of signaling. > > Wrong. Rewriting is not the essential problem. > > Right. The problem is lack of signaling OF *CONNECTIONS*. > > As you might know, there is no connections and signaling at > the IP layer. > > Thus, the only thing NAT and other layer 3 things can do is > guessing the connection state by a lack of communication > for certain period of time, though, sometimes, you can detect > TCP SYN and FIN. > > However, that you observe no traffic over a connection does > not necessarily mean that the connection is broken. > > That there is no response for a UDP packet may mean that an > reply ack is lost, that no reply is required by the protocol > above UDP or that the packet is an ack. > > There is no signaling unless layer 4 and above are involved, > though guessing may work for TCP. > > > Especially breaking referrals by > > hiding the "true" address to the outside world. Most (if not all) > > id/loc proposals here (claims) that referrals do work. There is a hugh > > difference, referrals is a crucial component of any multi6 solution. > > This was also pointed out in the comments by Patrick. > > NAT rewriting is transparent to applicaitons, if the applications > relies on TCP and DNS and DNS is modified to reflect the rewriting. > > So are other proposals, including mine, as is explained in > my proposal. > > However, TCP is not IP, which is the point of my presentation > at Vienna. > > Masataka Ohta From owner-multi6@ops.ietf.org Fri Jan 23 06:23:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24692 for ; Fri, 23 Jan 2004 06:23:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjzO7-000LmR-CQ for multi6-data@psg.com; Fri, 23 Jan 2004 11:22:11 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjzNu-000LlR-VB for multi6@ops.ietf.org; Fri, 23 Jan 2004 11:21:59 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0NBMJLS073235; Fri, 23 Jan 2004 12:22:21 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4010FB11.A2E07714@zurich.ibm.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B05836BAF@tayexc13.americas.cpqcorp.net> <4010FB11.A2E07714@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5AF2A43A-4D96-11D8-9871-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Reminder re multi6 drafts Date: Fri, 23 Jan 2004 12:21:57 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 23-jan-04, at 11:44, Brian E Carpenter wrote: > The WG will have to take an architectural decision at some point > whether to pursue transport layer solution(s). Without the SCTP > case being on the table, we will be handicapped. If anybody else > feels like doing even a superficial job on SCTP in the next few > days, that would be very helpful. What would have to be in this draft? From owner-multi6@ops.ietf.org Fri Jan 23 06:26:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24789 for ; Fri, 23 Jan 2004 06:26:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjzRV-000M0f-HN for multi6-data@psg.com; Fri, 23 Jan 2004 11:25:41 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AjzRJ-000LzS-2h for multi6@ops.ietf.org; Fri, 23 Jan 2004 11:25:29 +0000 Received: (qmail 87101 invoked from network); 23 Jan 2004 11:28:46 -0000 Received: from h219-110-033-119.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.119) by necom830.hpcl.titech.ac.jp with SMTP; 23 Jan 2004 11:28:46 -0000 Message-ID: <4011035C.5010406@necom830.hpcl.titech.ac.jp> Date: Fri, 23 Jan 2004 20:19:56 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 List Subject: Re: threats ID References: <400D2075.8040207@necom830.hpcl.titech.ac.jp> <400DB734.8000307@necom830.hpcl.titech.ac.jp> <4010C470.7010606@necom830.hpcl.titech.ac.jp> <4010FE5B.CC87E40@zurich.ibm.com> In-Reply-To: <4010FE5B.CC87E40@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > Masataka, you conclude by saying > > >>However, TCP is not IP, which is the point of my presentation >>at Vienna. > > > We can hardly disagree. But TCP is not SCTP, UDP, DCCP or ICMP either. That's why TCP is not IP. > The systems level argument for a layer 3.5 solution There is no such thing as layer 3.5. Network layer solutions are at layer 3, transport layer solutions are at layer 4. PERIOD. > is that it can cover > all cases, including ones we have not invented yet. UDP, which we already invented, can not be covered by network layer solutions. > You are correct that a layer 3.5 solution requires cached state, probably > with timeouts Anything with wrongly guessed timeout is no solution. > There is a classical > solution to that, which is for the ULP to send a keepalive signal to prevent > the cache from timing out. That is a modification to the ULP, including application ones and is substantial. That you must modify something above layer 4 gives a very convincing evidence, even for those who don't understand layering enough to dream of layer 3.5, that layer 3.5 is a fallacy. > That would indeed be a ULP enhancement, but a very > minor one and not essential. That is a well known argument for NAT. However, it is not an enhancement but a restriction. It is the essential reason why NAT is not acceptable. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jan 23 07:45:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28278 for ; Fri, 23 Jan 2004 07:45:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak0f4-0002Mi-47 for multi6-data@psg.com; Fri, 23 Jan 2004 12:43:46 +0000 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak0er-0002MJ-Gz for multi6@ops.ietf.org; Fri, 23 Jan 2004 12:43:33 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0NChPJW089784; Fri, 23 Jan 2004 12:43:25 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0NChPNu207424; Fri, 23 Jan 2004 13:43:25 +0100 Received: from zurich.ibm.com (sig-9-145-174-249.de.ibm.com [9.145.174.249]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA42468; Fri, 23 Jan 2004 13:43:23 +0100 Message-ID: <401116A5.A7C43E13@zurich.ibm.com> Date: Fri, 23 Jan 2004 13:42:13 +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 List Subject: Re: Reminder re multi6 drafts References: <9C422444DE99BC46B3AD3C6EAFC9711B05836BAF@tayexc13.americas.cpqcorp.net> <4010FB11.A2E07714@zurich.ibm.com> <5AF2A43A-4D96-11D8-9871-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On 23-jan-04, at 11:44, Brian E Carpenter wrote: > > > The WG will have to take an architectural decision at some point > > whether to pursue transport layer solution(s). Without the SCTP > > case being on the table, we will be handicapped. If anybody else > > feels like doing even a superficial job on SCTP in the next few > > days, that would be very helpful. > > What would have to be in this draft? If I knew that, would I be asking?-) I think my question is: can part of SCTP be extracted to make a generic layer 4 (or 3.9, or whatever) mh solution? At least in principle? Brian From owner-multi6@ops.ietf.org Fri Jan 23 07:52:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28398 for ; Fri, 23 Jan 2004 07:52:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak0m4-0002x9-O6 for multi6-data@psg.com; Fri, 23 Jan 2004 12:51:00 +0000 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak0lq-0002vg-Sn for multi6@ops.ietf.org; Fri, 23 Jan 2004 12:50:47 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0NCo9JW081132; Fri, 23 Jan 2004 12:50:09 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0NCo8Fi260626; Fri, 23 Jan 2004 13:50:09 +0100 Received: from zurich.ibm.com (sig-9-145-174-249.de.ibm.com [9.145.174.249]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA38676; Fri, 23 Jan 2004 13:50:07 +0100 Message-ID: <4011183A.3FD86FBB@zurich.ibm.com> Date: Fri, 23 Jan 2004 13:48:58 +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: Masataka Ohta CC: Multi6 List Subject: architected shim layers [was Re: threats ID] References: <400D2075.8040207@necom830.hpcl.titech.ac.jp> <400DB734.8000307@necom830.hpcl.titech.ac.jp> <4010C470.7010606@necom830.hpcl.titech.ac.jp> <4010FE5B.CC87E40@zurich.ibm.com> <4011035C.5010406@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka, please moderate your language. I understand layering well enough to know that the layers in the OSI model are very abitrary choices, and a better model would have been a recursive one, with no predefined number of layers. Since that's not the model the industry chose to adopt, we can approximate it by inserting shim layers when we need to. NAT is indeed a defective shim layer, but what this WG has been mainly talking about is architecturally designed shims. Brian Masataka Ohta wrote: > > Brian; > > > Masataka, you conclude by saying > > > > > >>However, TCP is not IP, which is the point of my presentation > >>at Vienna. > > > > > > We can hardly disagree. But TCP is not SCTP, UDP, DCCP or ICMP either. > > That's why TCP is not IP. > > > The systems level argument for a layer 3.5 solution > > There is no such thing as layer 3.5. > > Network layer solutions are at layer 3, transport layer solutions are > at layer 4. PERIOD. > > > is that it can cover > > all cases, including ones we have not invented yet. > > UDP, which we already invented, can not be covered by network > layer solutions. > > > You are correct that a layer 3.5 solution requires cached state, probably > > with timeouts > > Anything with wrongly guessed timeout is no solution. > > > There is a classical > > solution to that, which is for the ULP to send a keepalive signal to prevent > > the cache from timing out. > > That is a modification to the ULP, including application ones and > is substantial. > > That you must modify something above layer 4 gives a very convincing > evidence, even for those who don't understand layering enough to dream > of layer 3.5, that layer 3.5 is a fallacy. > > > That would indeed be a ULP enhancement, but a very > > minor one and not essential. > > That is a well known argument for NAT. > > However, it is not an enhancement but a restriction. > > It is the essential reason why NAT is not acceptable. > > Masataka Ohta From owner-multi6@ops.ietf.org Fri Jan 23 10:42:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06081 for ; Fri, 23 Jan 2004 10:42:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak3Pr-000Ips-FM for multi6-data@psg.com; Fri, 23 Jan 2004 15:40:15 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak3PT-000Ily-FB for multi6@ops.ietf.org; Fri, 23 Jan 2004 15:39:51 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8BB9B58EC; Fri, 23 Jan 2004 16:39:50 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp02.uc3m.es (Postfix) with SMTP id 74A575865; Fri, 23 Jan 2004 16:39:50 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Brian E Carpenter" , "Bound, Jim" Cc: Subject: RE: Reminder re multi6 drafts Date: Fri, 23 Jan 2004 16:32:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4010FB11.A2E07714@zurich.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There was a draft by Lode submited a while ago about multihoming issues and sctp http://www.ietf.org/internet-drafts/draft-coene-sctp-multihome-04.txt Perhaps this could be a starting point? Regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Brian E Carpenter > Enviado el: viernes, 23 de enero de 2004 11:45 > Para: Bound, Jim > CC: multi6@ops.ietf.org > Asunto: Re: Reminder re multi6 drafts > > > Jim, > > We understand of course that there are only 168 hours a week. > > The WG will have to take an architectural decision at some point > whether to pursue transport layer solution(s). Without the SCTP > case being on the table, we will be handicapped. If anybody else > feels like doing even a superficial job on SCTP in the next few > days, that would be very helpful. > > Brian > > "Bound, Jim" wrote: > > > > SCTP will not happen before this month. Randy, Yanick, and I cannot get > > it done. Sorry. > > /jim > > > > > -----Original Message----- > > > From: owner-multi6@ops.ietf.org > > > [mailto:owner-multi6@ops.ietf.org] On Behalf Of Brian E Carpenter > > > Sent: Tuesday, January 20, 2004 1:36 PM > > > To: multi6@ops.ietf.org > > > Subject: Re: Reminder re multi6 drafts > > > > > > > > > It's getting very close to the end of January. We are still > > > hoping for HIP and SCTP based drafts this month, so that they can > > > be thoroughly analyzed before the IETF. > > > > > > Brian > > > > > > Brian E Carpenter wrote: > > > > > > > > Folks, > > > > > > > > Just a reminder that we'd like all updated or new drafts describing > > > > possible approaches to solutions for multi6 to be submitted in the > > > > near future. We originally suggested a hard deadline of the end > > > > of December, but since people found that too rigid, let's try for > > > > having all the I-Ds available by mid-January at the latest. > > > > In addition to the existing proposals discussed in Minneapolis, > > > > we are at least expecting HIP and SCTP based contributions. > > > > > > > > We do ask that each draft includes a *short* > > > self-assessment against the > > > > goals in RFC 3582. For convenience, please name them as > > > > draft-AUTHOR-multi6-... > > > > > > > > Please remember that one of our objectives is to identify > > > architectural > > > > components that occur in the various proposals. > > > > > > > > The co-chairs are acutely aware that the published charter for this > > > > WG is out of date. We do plan to fix that. > > > > > > > > Brian > > > > multi6 co-chair > > > > -- > From owner-multi6@ops.ietf.org Fri Jan 23 11:07:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08060 for ; Fri, 23 Jan 2004 11:07:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak3oZ-000L7a-U9 for multi6-data@psg.com; Fri, 23 Jan 2004 16:05:47 +0000 Received: from [66.92.66.146] (helo=alva.home) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak3oN-000L6r-F6 for multi6@ops.ietf.org; Fri, 23 Jan 2004 16:05:35 +0000 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1Ak3np-0000Np-00; Fri, 23 Jan 2004 11:05:01 -0500 From: Tim Shepard To: Masataka Ohta cc: Multi6 List Subject: Re: threats ID In-reply-to: Your message of Fri, 23 Jan 2004 20:19:56 +0900. <4011035C.5010406@necom830.hpcl.titech.ac.jp> Date: Fri, 23 Jan 2004 11:05:01 -0500 Message-Id: X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk > There is no such thing as layer 3.5. > > Network layer solutions are at layer 3, transport layer solutions are > at layer 4. PERIOD. > As far as I am aware, the IETF has never reached a consensus on how the layers are to be numbered or what layers should exist. Clearly the number of layers varies depending on exactly what you are doing. Note that IPSEC adds a layer, increasing the number of layers below TCP by one. (I would say that IPSEC looks like it is quite a bit more than half a layer, and it certainly appears to be thicker than many other things which are allowed to occupy a full unit of layering in our minds.) I know that many people are aware of the layer numbering convention that was developed for the OSI suite of compter networking protocols, but I know of no reason to take that particular numbering of layers seriously. I have trouble keeping straight which layer is which number, so I would appreciate it if layers would be refered to by some meaningful name and not just a bare number. What layer number you are at depends on where you start counting and how many things you have stuck between you and there. -Tim Shepard shep@alum.mit.edu From owner-multi6@ops.ietf.org Fri Jan 23 11:43:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10932 for ; Fri, 23 Jan 2004 11:43:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak4NB-000Nff-Im for multi6-data@psg.com; Fri, 23 Jan 2004 16:41:33 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak4MI-000NbH-Au for multi6@ops.ietf.org; Fri, 23 Jan 2004 16:40:38 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i0NGmQE15135; Fri, 23 Jan 2004 08:48:27 -0800 Date: Fri, 23 Jan 2004 08:40:25 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <177537880.20040123084025@brandenburg.com> To: Brian E Carpenter CC: Multi6 List Subject: Re: architected shim layers [was Re: threats ID] In-Reply-To: <4011183A.3FD86FBB@zurich.ibm.com> References: <400D2075.8040207@necom830.hpcl.titech.ac.jp> <400DB734.8000307@necom830.hpcl.titech.ac.jp> <4010C470.7010606@necom830.hpcl.titech.ac.jp> <4010FE5B.CC87E40@zurich.ibm.com> <4011035C.5010406@necom830.hpcl.titech.ac.jp> <4011183A.3FD86FBB@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, BEC> a better model would have been a recursive BEC> one, with no predefined number of layers. Since that's not the BEC> model the industry chose to adopt, we can approximate it by BEC> inserting shim layers when we need to. I believe there are two things that can make your point more palatable. The first might sound like quibbling, but I believe it really does help us think and talk about these types of enhancements. 1. Sub-layers. These are entirely comfortable in the OSI model, and frankly we have always had them in the Internet model. Notably the network layer is actually 3 sub-layers. Namely, Convergence, Network, Inter-network. IP-over-* is the convergence layer. We have not really had a "network" layer in IP, I think. But the possibility of adding this new module to the architecture is pretty natural. 2. Enhancement vs. hack. I've increasingly come to believe that the addition we are talking about is a legitimate architecture enhancement, rather than a special-case hack. The distinction should be between IP that is in every node along the path, versus IP that is only (or almost only) in the endpoints. What is nice is that the multiaddressing work is not the first example of this distinction. Any practical implementation of IP has always made that distinction. In case folks disagree, then we can fall back to IPSec. So, the Internet Model can get: Transport Network Host Transit Media Convergence (IP-over-*) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Fri Jan 23 12:37:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12702 for ; Fri, 23 Jan 2004 12:37:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak5Dk-0001zD-AY for multi6-data@psg.com; Fri, 23 Jan 2004 17:35:52 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak5DX-0001ye-SK for multi6@ops.ietf.org; Fri, 23 Jan 2004 17:35:39 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Jan 2004 09:34:48 -0800 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 23 Jan 2004 09:35:39 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 23 Jan 2004 09:35:39 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 23 Jan 2004 09:34:43 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 23 Jan 2004 09:35:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7150.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: threats ID Date: Fri, 23 Jan 2004 09:35:42 -0800 Message-ID: Thread-Topic: threats ID thread-index: AcPhoKoEPbBQcYkIS4yGZXgFWd1H6wANainw From: "Christian Huitema" To: "Brian E Carpenter" Cc: "Multi6 List" X-OriginalArrivalTime: 23 Jan 2004 17:35:38.0115 (UTC) FILETIME=[507DDD30:01C3E1D7] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > However, TCP is not IP, which is the point of my presentation > > at Vienna. > We can hardly disagree. But TCP is not SCTP, UDP, DCCP or ICMP either. > The systems level argument for a layer 3.5 solution is that it can cover > all cases, including ones we have not invented yet. The flip side of that argument is that different transport layers have different ways of coping with multiple paths between two nodes. Currently, TCP does not; SCTP has an integrated support for multi-path; UDP is a pass-through layer and leaves multi-path handling to the application; and ICMP just does not care. If multi-path support becomes important, the transports will evolve, and develop different algorithms that fit different usage model. It is not hard to see how transports could use per path RTT measurements and congestion windows to arbitrage between load balancing, resiliency, and re-sequencing. By imposing a "3.5" layer, you make an early decision to forestall this evolution. -- Christian Huitema From owner-multi6@ops.ietf.org Fri Jan 23 12:48:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13153 for ; Fri, 23 Jan 2004 12:48:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak5OI-00033o-8K for multi6-data@psg.com; Fri, 23 Jan 2004 17:46:46 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak5Ns-00032r-Kp for multi6@ops.ietf.org; Fri, 23 Jan 2004 17:46:20 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D385C7460; Fri, 23 Jan 2004 18:46:19 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id AC5017459; Fri, 23 Jan 2004 18:46:19 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" , Subject: RE: to be draft-ohta-multi6-8plus8-00.txt Date: Fri, 23 Jan 2004 18:38:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4005A971.1090109@necom830.hpcl.titech.ac.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,THE_FOLLOWING_FORM autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi Masataka, If i understand correctly, you basically propose to: - Perform destiantion locator selection by injecting full global routing table into the hosts so that they have the required info to know which destiantions are reachable - Use OSPFv6 options to let the hosts to detect which cource address to use and so overcome the ingress filtering problems - Add an option to tcp so it can hanlde multiple addresses in a single connection - Use transport layer information to trigger a rehoming event (path failure detection) My question is what do you need the 8+8 format to do this? I mean, wouldn't be possible to exactly the same using regular addresses and selecting one of them as identifiers to the transport and upper layers? In other words, as your architectural draft explains, your solutions is completelly end to end, so the ends can have the information about what locators are linked to an identifier and which is the identifier to be used for each connection, so why is required to reflect this loc/id split in the address itself? Regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Masataka Ohta > Enviado el: miercoles, 14 de enero de 2004 21:41 > Para: multi6@ops.ietf.org > Asunto: to be draft-ohta-multi6-8plus8-00.txt > > > Dear all; > > Attached is a completed multihoming proposal of mine. > > It is submitted as an ID and will soon appear as such. > > Masataka Ohta > -- > > > > > > INTERNET DRAFT M. Ohta > draft-ohta-multi6-8plus8-00.txt Tokyo Institute of Technology > January 2004 > > 8+8 Addressing for IPv6 End to End Multihoming > > Status of this Memo > > This document is an Internet-Draft and is subject to all provisions > of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet- Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/1id-abstracts.html The list of Internet-Draft > Shadow Directories can be accessed at http://www.ietf.org/shadow.html > > Abstract > > This memo describes 8+8 address format, which is an IPv6 address > format with locator/ID separation useful for end to end multihoming. > A 16 byte address of an end is separated into two 8 byte fields: > locator, which is used to route packets to a link to which the end is > attached, and ID, which is used to globally identify the end. > > Locators are assigned from (top level) ISPs to sites (and lower level > ISPs) in hierarchical and aggregatable manner that a multihomed site > (and ISPs) receive multiple locators from upstream ISPs. > > A usual host in a multihomed site (or a singly homed site under a > multihomed ISP) is expected to have an ID and multiple locators and > transport layer protocols are expected to handle multiple locators of > the host and its peer. > > 1. Introduction & Terminologies > > This memo describes 8+8 address format, which is an IPv6 address > format with locator/ID separation useful for end to end multihoming > [ARCH]. A 16 byte address of an end is separated into two 8 byte > fields: locator, which is used to route packets to a link to which > the end is attached, and ID, which is used to globally identify the > end. > > Locators are assigned from (top level) ISPs to sites (and lower level > ISPs) in hierarchical and aggregatable manner that a multihomed site > (and ISPs) receive multiple locators from upstream ISPs. > > > > M. Ohta Expires on July 15, 2004 [Page 1] > > > INTERNET DRAFT 8+8 Addressing Janurary 2004 > > > A usual host in a multihomed site (or a singly homed site under a > multihomed ISP) is expected to have an ID and multiple locators and > transport layer protocols are expected to handle multiple locators of > the host and its peer. > > Multicast is not considered in this memo. > > Anycast is treated identically to unicast. > > The followings are terminologies used in this memo: > > 8+8 Address > An address composed of an 8 byte locator and an 8 byte ID. > > Address > 16 byte information to identify and locate an end. An end may > have multiple addresses. > > Destination ID > ID of a destination address > > Destination Locator > Locator of a destination address > > End > The primary unit, of the end to end principle [ARCHINTERNET], > also called "end point" in [SALTZER]. > > ID > 8 byte information to identify an end. An end may have > multiple IDs. > > Locator > 8 byte information to locate an end. An end may have multiple > locators. > > Source ID > ID of a source address > > Source Locator > Locator of a source address > > 2. Address Format > > An 8+8 address format is identical to that of the existing IPv6 > unicast address [ADDRARCH, UNIADDR] derived from EUI-64, except that > it uses unused part of the IPv6 unicast address space. > > 2.1 Locator Format > > Locator format is identical to the upper 8 bytes of existing IPv6 > unicast address [ADDRARCH, UNIADDR]. > > That is, as defined in [UNIADDR], a locator of an end have the > > > > M. Ohta Expires on July 15, 2004 [Page 2] > > > INTERNET DRAFT 8+8 Addressing Janurary 2004 > > > following format: > > | 3 | 45 bits | 16 bits | > +---+---------------------+-----------+ > |001|global routing prefix| subnet id | > +---+---------------------+-----------+ > > 2.2 ID Format > > ID format is identical to the lower 8 bytes of existing EUI-64 based > IPv6 unicast address [ADDRARCH, UNIADDR]. > > However, when an 8+8 address is viewed as an EUI-64 based address, > individual/group bit of EUI-64 is turned on, which is not a case with > a real EUI-64 based address. > > As a globally unique IEEE EUI-64 identifier has the following form: > > |0 1|1 3|3 4|4 6| > |0 5|6 1|2 7|8 3| > +----------------+----------------+----------------+----------------+ > |ccccccugcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| > +----------------+----------------+----------------+----------------+ > > and existing IPv6 interface identifier has the following form ("U" > bit is a inversion of "u" bit): > > |0 1|1 3|3 4|4 6| > |0 5|6 1|2 7|8 3| > +----------------+----------------+----------------+----------------+ > |ccccccU0cccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| > +----------------+----------------+----------------+----------------+ > > an ID of an 8+8 address has the following form: > > |0 1|1 3|3 4|4 6| > |0 5|6 1|2 7|8 3| > +----------------+----------------+----------------+----------------+ > |ccccccU1cccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| > +----------------+----------------+----------------+----------------+ > > "U" bit is reserved and should be, for the time being, filled with 0 > though either 0 or 1 should be accepted. See "3.1 Mobility > Consideration" for possible use of the bit. > > 2.3 ID scope and semantics > > An ID is expected to be globally unique. > > An ID is to identify an end. > > As such, all the interfaces of an end share an ID(s) of the end, as > if an EUI-64 address corresponding to the ID is shared by all the > interfaces, which is consistent with [ADDRARCH, UNIADDR]. > > > > M. Ohta Expires on July 15, 2004 [Page 3] > > > INTERNET DRAFT 8+8 Addressing Janurary 2004 > > > 2.4 ID Space Structure > > An ID of an end is structured to have hierarchical mapping by DNS > from ID to DNS name of the end, just as IPv4 addresses under in- > addr.arpa. If such mapping does not configured or wrongly configured, > DNS-based confirmation of association between addresses and hostnames > will not be available, which is the case of IPv4 addresses. > > 2.4.1 Locator Derived ID > > To ease initial assignment of IDs to ends, IDs may be derived from > locators allocated to sites. > > An ID is a locator derived ID, if its first bit is 1. > > With a locator with the following format: > > | 3 | 45 bits | 16 bits | > +---+---------------------+-----------+ > |001|global routing prefix| subnet id | > +---+---------------------+-----------+ > > or > > |0 1|1 3|3 4|4 6| > |0 5|6 1|2 7|8 3| > +----------------+----------------+----------------+----------------+ > |001rrrrrrrrrrrrr|rrrrrrrrrrrrrrrr|rrrrrrrrrrrrrrrr|ssssssssssssssss| > +----------------+----------------+----------------+----------------+ > > a locator derived ID has the following format: > > |0 1|1 3|3 4|4 6| > |0 5|6 1|2 7|8 3| > +----------------+----------------+----------------+----------------+ > |1rrrrrU1rrrrrrrr|rrrrrrrrrrrrrrrr|rrrrrrrrrrrrrrrr|ssssssssssssssss| > +----------------+----------------+----------------+----------------+ > > Reverse mapping of a locator derived ID of an end is performed under > ipv6.arpa. domain, using locator format corresponding to the ID > [IPV6DNS], though only 64 bits of the locator format are used to > reach an PTR record corresponding to the locator format. > > That is, a site is assured to have 65,536 IDs assigned, though the > locator nature of the ID makes IDs not stable against site > renumbering. > > Note that ID assignment within a site can be arbitrary and will not > be consistent of intra site link structure. That is, an end with a > locator derived ID including a certain subnet id may be located > anywhere in the site, not necessarily in the subnet corresponding to > the subnet id. > > If one want to hide its privacy in ID, one should use locator derived > > > > M. Ohta Expires on July 15, 2004 [Page 4] > > > INTERNET DRAFT 8+8 Addressing Janurary 2004 > > > ID for one's ends. > > 2.4.2 Location Independent ID > > Location independent ID is introduced to overcome the difficulties of > locator derived IDs, that > > locator derived IDs are location dependent > > a site can not be assigned IDs a lot more than 65,536. > > Location independent ID is, just like DNS names, assigned with > logical structure independent of network topology, including site > structure. That is, location independent IDs are assigned to > organizations and individuals. > > As location independent ID space does not incur inefficiency due to > route aggregation, entities equivalent to site is expected to be able > to receive a lot more than 65536 IDs. > > An ID is a location independent ID, if its first bit is 0 and has the > following structure. > > |0 1|1 3|3 4|4 6| > |0 5|6 1|2 7|8 3| > +----------------+----------------+----------------+----------------+ > |0cccccU1cccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| > +----------------+----------------+----------------+----------------+ > > Further details of operations and management of location independent > IDs are TBD, though they should be almost identical to those for > domain names, except that there is no trademark issues expected for > 16 hexadecimal digits, which is not expected to be visible with most > user interface. > > 3. Internetworking Layer Protocol > > At the Internetworking layer, an 8+8 address has no special meaning > and packets containing 8+8 addresses in their IP headers is treated > as a normal IPv6 packets for all the processing, including, but not > limited to, forwarding by routers and ICMP [ICMPv6]. > > As is discussed in [ARCH], the Internetworking layer, having no > notion of connection nor time out, has little to do with multihoming, > except that IP addresses are part of transport layer identifiers. > > However, following subsections give some considerations for > performance enhancements. > > 3.1 Mobility Considerations > > While [MIPV6] should work with 8+8 addressing as is, 8+8 addressing > offers chance to have better mobility protocol. One is that DAD, > which is the primary cause of delay of [MIPV6] is not seriously > > > > M. Ohta Expires on July 15, 2004 [Page 5] > > > INTERNET DRAFT 8+8 Addressing Janurary 2004 > > > unnecessary for globally unique ID. The other is that tunneling and > associate MTU change of [MIPV6] can be eliminated if locators can be > rewritten. > > [LIN6MOBI] is expected to exploit such possibilities. > > To mark a mobile end as mobile without first communicating with the > end, "U" bit may be used. > > Further discussion on mobility is out of scope of site multihoming. > > 3.2 Destination Locator Selection > > A problem with end to end multihoming is that an end have multiple > locators and proper locator must be chosen to reach the end. > > While [ADDRSELECT] tries to define some guideline for destination > address (locator) selection, it is not very useful to select one from > multiple global unicast addresses. > > If an end has no idea on what is the best destination address, > selection should be at random. > > However, if an end have routing information, it can use it to > determine which locator is unreachable and which locator have least > metric (such as type 2 metric of OSPF) [ARCH]. > > To obtain metric information of external routes of IGP, BGP AS path > length may be used as the metric. Or BGP administrators may adjust > IGP metric more finely to control load of outgoing traffic. > > As end to end multihoming is expected to remove the only reason to > bloat global routing table size, save laziness of assignment > authorities, the global routing table of IPv6 should be kept small > and all hosts should have default free full routing table for > efficient selection of destination addresses. Note that an end should > receive, but may not necessarily generate, routing information. > > While the Internetworking layer gives information on preference of > locators, the Internetworking layer does not perform retransmission. > Thus, if some locator fails, it is detected by a transport or an > application layer and the layer takes care of retransmission with > next best destination locator candidates. Implementations are > encouraged to let upper layers look at the routing table for > efficiency, which is not a layering violation. > > 3.3 Source Locator Selection > > While [ADDRSELECT] tries to define some guideline for source address > (locator) selection, it is not very useful to select one from > multiple global unicast addresses. > > Given highly asymmetric nature of Internet routing, a host basically > has no knowledge on what is the best destination locator used by its > > > > M. Ohta Expires on July 15, 2004 [Page 6] > > > INTERNET DRAFT 8+8 Addressing Janurary 2004 > > > peer for reply. In this sense, source locator selection is not > necessary and source locator can be chosen randomly. > > However, source locator selection becomes important for ingress > filtering on source addresses, in which case, proper source locator > corresponding to a destination locator must be chosen. Otherwise, > most packets will be filtered and a lot of time is wasted for a > transport or an application protocol retransmit and find the proper > source locator. > > As is discussed in [ARCH], such corresponding can be best obtained > from proper routing protocol. For example, with OSPFv6, locator part > of forwarding address field of AS-external-LSA can designate the > locator for the LSA. > > When routing protocols supply source locator, source locator > selection is performed purely by the Internetworking layer without > involving inefficient retransmission by a transport or an application > layer. > > 4. Transport and Application Layer Protocols > > For backward compatibility, if either a source or a destination > address is not an 8+8 address, transport and application layer > protocols behave as if it is a legacy end. > > Otherwise, that is, if both source and destination address are 8+8 > addresses, transport layer protocols ignore source and destination > locators, except for security and performance enhancement. That is, > transport layer protocols does not use the locators for checksum and > identify their connections using IDs only. > > As is discussed in the previous section, a transport or an > application protocol is responsible for selection of destination > locator and associated retransmission. > > However, as is discussed in [ARCH], such retransmission dependent on > the nature of applications that no generic mechanism can be discussed > in this memo. Each application has different notion of connection or > loss of it that it is not meaningful to give a generic time out > value. > > Nevertheless, as is discussed in [ARCH], TCP has defact default > timeout values. So, it is possible to have generic TCP with default > behavior for locator selection and retransmission. > > It should be noted that most applications over the Internet works > over TCP and that such applications can run with end to end > multihoming without modifying application programs. > > In addition, as DNS is a basic infrastructure and has its own timeout > values, it is necessary to investigate possible modifications to DNS > with end to end multihoming. > > > > > M. Ohta Expires on July 15, 2004 [Page 7] > > > INTERNET DRAFT 8+8 Addressing Janurary 2004 > > > 4.1 Modification to TCP > > A new TCP option, Multi Address option, is introduced. > > +--------+--------+---------+ > |????????|00000011| # of LOC| > +--------+--------+---------+ > Kind=? Length=3 > > Kind is to be assigned by IANA. > > The option has one argument, the number of locators, value of which > must be between 1 and 9. If the option appears in a TCP header, data > field just after the TCP header contains, with network byte order, > locators of the source host, the number of which is specified by the > argument. > > It is expected that 9 locators are enough for most ends, as a site of > the end can be multihomed to three lower level ISPs each multihomed > to 3 top level ISPs. However, if an end has more than 9 locators, > which is a case with routers with more than 9 interfaces, TCP or > upper layer modules should be responsible to select 9 or less > locators to be used for the TCP connection. > > All TCP modules of ends supporting 8+8 addressing must recognize the > Multi Address option. > > TCP modules memorize current most source locators of its peer and > reject TCP packets with unknown source locators. > > TCP modules should have interface to application modules to let the > application modules check whether the set of locators supplied by the > Multi Address option is valid or not. > > Multi Address options must be used by packets for the initial three > way handshaking and may appear in any other TCP packet. > > Multi address option is also useful for performance reasons. > > Note that, as route of the Internet is highly asymmetric, a source > locator of a packet, which is chosen for ingress filtering, may not > work for reply that it is essential to provide all the candidate > locators for the reply. > > In addition, when SYN times out, TCP should retry with new > destination locators. When SYN ACK times out, TCP should retry with > new destination locators contained in a set of locators provided by > Multi Address option of SYN packet. Thus, with N locators, it is > expected that O(N), not O(N*N), attempt is enough to find a working > pair of source and destination locators. If TCP modules detect SYN > flood attack, they do not have to allocate state for SYN packets to > memorize the set of locators in the Multi Address option of the > packets. Instead, it should randomly choose one from the Multi > Address option of the SYN packet. > > > > M. Ohta Expires on July 15, 2004 [Page 8] > > > INTERNET DRAFT 8+8 Addressing Janurary 2004 > > > 4.2 Modification to DNS > > As is discussed in [ARCH], DNS tries all the addresses of name > servers that it is already an application with end to end > multihoming. > > A problem is that unlike TCP, DNS servers do not expect > acknowledgment and do not retransmit. So, if a client can not get a > response, it should retry with alternative destination locators of a > server with corresponding source locators. But, even if the server > somehow knows all the locators of the client, the server send just > one reply and does not try all of them. Thus, with N locators and in > the worst case, O(N*N) attempt is necessary to find a working pair of > locators. > > But, the problem is not serious, because usual clients of DNS today, > gives up with small number of attempts and because there are multiple > servers are provided for each zone. > > 4.3 8+8 Adaptation Layers for Applications over TCP and DNS > > The 8+8 adaptation layers make end to end multihoming invisible to > applications over TCP and DNS, that is, applications using TCP > transport only without hard coded IP addresses. > > Some multihoming proposals try to introduce an adaptation layer in > the Internetworking layer to hide locator changes. However, this > attempt does not make sense. As demonstrated by NAT, rewriting of > addresses is, in general, not transparent to transport and > application protocols. For example, transport layer checksum > computation involves IP addresses and is different for each transport > protocol that address rewriting can not be confined in the > Internetworking layer. Insertion or deletion of IP headers affects > MTU, which is also visible to the transport layer. Applications like > FTP transmit raw addresses in application data streams. > > However, it is possible to confine modifications in 4.1 in TCP and > let applications get a fixed locator (LIN6 locator) [LIN6ARCH]. In > addition, it is possible to modify DNS library to let such > applications get addresses with the LIN6 locator. > > Then, it is possible to make end to end multihoming invisible from > applications over TCP and DNS, including applications transmit raw > addresses in application data streams. > > 5. Assessment Against RFC3582 > > Redundancy > Fully supported. That is, ends should be able to keep > communicating against all failure modes of locators as long as > a pair of working source and destination locators exists, > though details are transport and application layer dependent. > > Load Sharing, Performance > > > > M. Ohta Expires on July 15, 2004 [Page 9] > > > INTERNET DRAFT 8+8 Addressing Janurary 2004 > > > Fully supported. That is, if site administrators elaborate on > BGP configuration, they have as much control as possible with > BGP. Site administrators, instead, can just rely on ASpathlen, > in which case, there will be no configuration effort. > > Policy > Fully supported. If a site is multihomed to ISP A and B and an > end has locators of ISP A only, all traffic to the end will be > through ISP A. Traffic from the end can be controlled by > policy of accepting route. > > Simplicity > As for deployment, the proposal fully interoperate with legacy > systems. Applications over TCP and DNS does not need any > coding changes. As for operation, as long as IDs may change > with rehoming, it is as simple as the current IPv4 multihoming > practices. > > Transport-Layer Survivability > Fully supported, though details are transport layer specific, > of course. > > Impact on DNS > The proposal is fully compatible with the observed dynamics of > the current DNS. > > Packet Filtering > The proposal is compatible with packet filtering on source > addresses. > > Scalability > Fully scales. That is, the number of multihomed site does not > affect the number of routing table entries. > > Impact on Routers > Nothing, except that routers may have 8+8 addresses and behave > accordingly. > > Impact on Hosts > Communications with legacy hosts is kept unchanged, though > most, if not all, the benefit of multihoming will be lost. > > API of applications using TCP and DNS remain unchanged and the > applications can still enjoy full multihoming support. > > Applications over UDP, where all the packets can and must be > controlled by "user", need changes, if it want transport-layer > survivability (even the meaning of "transport-layer > survivability" is defined by the "user"). Otherwise, the > current transport-layer protocol may be used as is. > > Interaction with Hosts and Routing System. > Ends expect to passively receive routing information from the > routing system, which is simple, scalable and securable. > > > > M. Ohta Expires on July 15, 2004 [Page 10] > > > INTERNET DRAFT 8+8 Addressing Janurary 2004 > > > Operations and Management > Site's multihoming system, with the proposal, is site's routing > system that it is possible for staff responsible for the > operation of a site to monitor and configure it. > > Cooperation between Transit Providers > No cooperations are required. > > Multiple Solutions > Proposal contains a single solution only. > > Security Considerations > Multihomed sites and ends are not more valunerable to > traditional IPv4-multihomed sites and ends. > > Routing practice change to carry source locator does not affect > security of non multihomed site. > > 6. References > > [ADDRARCH] R. Hinden, S. Deering, "Internet Protocol Version 6 (IPv6) > Addressing Architecture", RFC3513, April 2003. > > [ADDRSELECT] R. Draves, "Default Address Selection for Internet > Protocol version 6 (IPv6)", RFC3484, February 2003. > > [ARCH] M. Ohta, "The Architecture of End to End Multihoming", Work in > Progress as , June 2003. > > [ARCHINTERNET] B. Carpenter, Ed., "Architectural Principles of the > Internet", RFC1958, June 1996. > > [ICMPv6] A. Conta, S. Deering, "ICMP for the Internet Protocol > Version 6 (IPv6)", RFC 2463, December 1998. > > [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) > Specification", RFC 2460, December 1998. > > [IPV6DNS] S. Thomson, C. Huitema, V. Ksinant, M. Souissi, "DNS > Extensions to Support IP Version 6", RFC3596, October 2003. > > [LIN6ARCH] > > [LIN6MOBI] > > [UNIADDR] R. Hinden, S. Deering, E. Nordmark, "IPv6 Global Unicast > Address Format", RFC3587, August 2003. > > 7. Security Considerations > > The Internetworking is identical to the legacy IPv6 that there is no > new security concern. > > The transport layer is modified that there is possibility of wrongly > > > > M. Ohta Expires on July 15, 2004 [Page 11] > > > INTERNET DRAFT 8+8 Addressing Janurary 2004 > > > recognized source locator and transmit a lot of packets to wrong > places. > > While details of source locator authentication and packet > retransmissions are transport and application dependent, there can be > some guideline to prevent the problem. > > When a packet arrives with a source locator, the validity of the > locator can be confirmed with reasonable security with three way > handshaking or cookies. > > When a packet arrives with multiple locators, the validity of one of > a locator can still be confirmed with reasonable security with three > way handshaking or cookies. As long as all the locators are contained > in a single packet, it is reasonable to treat the set of the locators > have reasonable security. As the destination locator of reply packet > is chosen by the replying host and retransmission is expected to be > infrequent, DoS attack using the multiple locators for reply is only > as efficient as DoS attack with single locators. > > TCP modification in 4.3 is expected to work this way. > > However, to avoid interference between connections, each connection > module should maintain the set of locators separately even if several > connections exists to a single ID. > > 8. Author's Address > > Masataka Ohta > Graduate School of Information Science and Engineering > Tokyo Institute of Technology > 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN > > Phone: +81-3-5734-3299 > Fax: +81-3-5734-3299 > EMail: mohta@necom830.hpcl.titech.ac.jp > > > > > > > > > > > > > > > > > > > > > > M. Ohta Expires on July 15, 2004 [Page 12] > > > > From owner-multi6@ops.ietf.org Fri Jan 23 13:03:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13816 for ; Fri, 23 Jan 2004 13:03:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak5dI-0004Vu-8q for multi6-data@psg.com; Fri, 23 Jan 2004 18:02:16 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak5cy-0004UB-0w for multi6@ops.ietf.org; Fri, 23 Jan 2004 18:01:56 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0NI2O2g004794; Fri, 23 Jan 2004 19:02:24 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3BBCCB40-4DCE-11D8-9871-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: threats ID Date: Fri, 23 Jan 2004 19:01:56 +0100 To: "Christian Huitema" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 23-jan-04, at 18:35, Christian Huitema wrote: > It is not hard to see how transports > could use per path RTT measurements and congestion windows to arbitrage > between load balancing, resiliency, and re-sequencing. By imposing a > "3.5" layer, you make an early decision to forestall this evolution. There are two main aspects to this problem: finding addresses and binding them to a session, and switching between the addresses that are available for a session. I agree that transport protocols are in the best position to do the latter, so we should make sure they are allowed to do so by any new mechanisms we create. At the same time, we can provide a simple mechanism for this that allows unmodified transport protocols to work over multiple addresses. But finding and binding addresses is something that has many repercussions that fall outside the competence of transport protocols and that would benefit from being implemented just once rather than separately for each transport protocol. From owner-multi6@ops.ietf.org Fri Jan 23 16:27:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25366 for ; Fri, 23 Jan 2004 16:27:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak8nR-000K4M-D5 for multi6-data@psg.com; Fri, 23 Jan 2004 21:24:57 +0000 Received: from [134.193.143.167] (helo=kc-msxproto1.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak8nE-000K3U-Ox for multi6@ops.ietf.org; Fri, 23 Jan 2004 21:24:44 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Jan 2004 15:24:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: threats ID Date: Fri, 23 Jan 2004 15:20:13 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108247@KC-MAIL4.kc.umkc.edu> Thread-Topic: threats ID Thread-Index: AcPhoKoEPbBQcYkIS4yGZXgFWd1H6wANainwAAgXba0= From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Christian Huitema" , "Brian E Carpenter" Cc: "Multi6 List" X-OriginalArrivalTime: 23 Jan 2004 21:24:44.0040 (UTC) FILETIME=[51B39080:01C3E1F7] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > SCTP has an integrated support for multi-path =20 SCTP by itself allow only fail-over; not load=20 balancing across multi-paths.=20 From owner-multi6@ops.ietf.org Fri Jan 23 18:11:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01288 for ; Fri, 23 Jan 2004 18:11:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkAQl-0002X4-4C for multi6-data@psg.com; Fri, 23 Jan 2004 23:09:39 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AkAOz-0002Mr-Kj for multi6@ops.ietf.org; Fri, 23 Jan 2004 23:07:50 +0000 Received: (qmail 89740 invoked from network); 23 Jan 2004 23:17:55 -0000 Received: from h219-110-032-237.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.237) by necom830.hpcl.titech.ac.jp with SMTP; 23 Jan 2004 23:17:55 -0000 Message-ID: <4011A989.3070000@necom830.hpcl.titech.ac.jp> Date: Sat, 24 Jan 2004 08:08:57 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 List Subject: Re: architected shim layers [was Re: threats ID] References: <400D2075.8040207@necom830.hpcl.titech.ac.jp> <400DB734.8000307@necom830.hpcl.titech.ac.jp> <4010C470.7010606@necom830.hpcl.titech.ac.jp> <4010FE5B.CC87E40@zurich.ibm.com> <4011035C.5010406@necom830.hpcl.titech.ac.jp> <4011183A.3FD86FBB@zurich.ibm.com> In-Reply-To: <4011183A.3FD86FBB@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > Masataka, please moderate your language. Moderate your language and never say layer 3.5 again. > I understand layering > well enough to know that the layers in the OSI model are very > abitrary choices, I never say anything on OSI model. In the Internet, layer 3 is connectionless whereas layer 4 maybe connection oriented. > and a better model would have been a recursive > one, with no predefined number of layers. If you understand layering correctly, you should know that internal of a layer is not visible from the adjacent layers. Recursive means some layer may have internal structure, which, because of layering, is not visible from outside. > NAT is indeed a defective shim layer, but what this WG has been > mainly talking about is architecturally designed shims. What some of the WG member has been talking about was architecturally designed NAT. It failed, of course. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jan 23 18:22:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02060 for ; Fri, 23 Jan 2004 18:21:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkAbT-0003HJ-Ue for multi6-data@psg.com; Fri, 23 Jan 2004 23:20:43 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AkAbF-0003G7-QA for multi6@ops.ietf.org; Fri, 23 Jan 2004 23:20:30 +0000 Received: (qmail 89795 invoked from network); 23 Jan 2004 23:30:36 -0000 Received: from h219-110-032-237.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.237) by necom830.hpcl.titech.ac.jp with SMTP; 23 Jan 2004 23:30:36 -0000 Message-ID: <4011AC82.2000207@necom830.hpcl.titech.ac.jp> Date: Sat, 24 Jan 2004 08:21:38 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Tim Shepard CC: Multi6 List Subject: Re: threats ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Shepard; >>There is no such thing as layer 3.5. > As far as I am aware, the IETF has never reached a consensus on how > the layers are to be numbered or what layers should exist. Thank you for agreeing with me that layer 3.5 is an improper terminology. However, > Note that IPSEC adds a layer, increasing the number of layers below > TCP by one. it is clearly stated in RFC2401 "Security Architecture for the Internet Protocol", which defines IPSEC architecture, that: The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. It should also be noted that that Brian said layer 3.5 means he thought IP layer layer 3 and transport layer layer 4, on which I have no objection. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jan 23 18:32:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02627 for ; Fri, 23 Jan 2004 18:32:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkAlN-0004CW-Iz for multi6-data@psg.com; Fri, 23 Jan 2004 23:30:57 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AkAlB-0004C8-K3 for multi6@ops.ietf.org; Fri, 23 Jan 2004 23:30:45 +0000 Received: (qmail 89830 invoked from network); 23 Jan 2004 23:40:52 -0000 Received: from h219-110-032-237.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.237) by necom830.hpcl.titech.ac.jp with SMTP; 23 Jan 2004 23:40:52 -0000 Message-ID: <4011AEE9.8050303@necom830.hpcl.titech.ac.jp> Date: Sat, 24 Jan 2004 08:31:53 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Brian E Carpenter , Multi6 List Subject: Re: threats ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian; >>>However, TCP is not IP, which is the point of my presentation >>>at Vienna. >> >>We can hardly disagree. But TCP is not SCTP, UDP, DCCP or ICMP either. >>The systems level argument for a layer 3.5 solution is that it can cover >>all cases, including ones we have not invented yet. To deny such a sweeping argument of Brian, a counter example is just enough. > The flip side of that argument is that different transport layers have > different ways of coping with multiple paths between two nodes. > Currently, TCP does not; SCTP has an integrated support for multi-path; > UDP is a pass-through layer and leaves multi-path handling to the > application; Thus, UDP is a counter example. NAT can not properly handle UDP. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jan 23 18:52:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03397 for ; Fri, 23 Jan 2004 18:52:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkB4X-0005ym-6o for multi6-data@psg.com; Fri, 23 Jan 2004 23:50:45 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AkB3n-0005to-Dq for multi6@ops.ietf.org; Fri, 23 Jan 2004 23:49:59 +0000 Received: (qmail 89903 invoked from network); 24 Jan 2004 00:00:06 -0000 Received: from h219-110-032-237.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.237) by necom830.hpcl.titech.ac.jp with SMTP; 24 Jan 2004 00:00:06 -0000 Message-ID: <4011B36B.90300@necom830.hpcl.titech.ac.jp> Date: Sat, 24 Jan 2004 08:51:07 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: multi6@ops.ietf.org Subject: Re: to be draft-ohta-multi6-8plus8-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marcelo; > If i understand correctly, you basically propose to: > > - Perform destiantion locator selection by injecting full global routing > table into the hosts so that they have the required info to know which > destiantions are reachable > - Use OSPFv6 options to let the hosts to detect which cource address to use > and so overcome the ingress filtering problems > - Add an option to tcp so it can hanlde multiple addresses in a single > connection > - Use transport layer information to trigger a rehoming event (path failure > detection) Mostly so, though I think there can be RIPv6M6 and SCTPM6. > My question is what do you need the 8+8 format to do this? 8+8 format is to let 8+8 transport layers disntinguish 8+8 addresses and leagacy addresses, to let transport layers mostly ignore locators, to have location independent IDs and to remove some IP layer tunneling by simply rewriting locator part. > I mean, wouldn't be possible to exactly the same using regular addresses and > selecting one of them as identifiers to the transport and upper layers? How can transport layer protocols detect that an end or its peer is capable of M6? How can you make IDs survive ISP changes? How can you be sure to rewrite addresses at the IP layer, if you are not sure that all the transport layer protocols can still identify an end? > In other words, as your architectural draft explains, your solutions is > completelly end to end, so the ends can have the information about what > locators are linked to an identifier and which is the identifier to be used > for each connection, so why is required to reflect this loc/id split in the > address itself? There are elegant and not so elegant ways to implement an architecture. Have I answered your question? Masataka Ohta From owner-multi6@ops.ietf.org Fri Jan 23 19:04:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03727 for ; Fri, 23 Jan 2004 19:04:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkBGS-00070P-Vi for multi6-data@psg.com; Sat, 24 Jan 2004 00:03:04 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkBGB-0006z8-IM for multi6@ops.ietf.org; Sat, 24 Jan 2004 00:02:47 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Jan 2004 16:07:21 +0000 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0O02iff017939; Fri, 23 Jan 2004 16:02:44 -0800 (PST) Received: from cisco.com (sjc-vpn1-218.cisco.com [10.21.96.218]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA23277; Fri, 23 Jan 2004 16:02:43 -0800 (PST) Message-ID: <4011B622.7030308@cisco.com> Date: Fri, 23 Jan 2004 16:02:42 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masataka Ohta CC: Christian Huitema , Brian E Carpenter , Multi6 List Subject: Re: threats ID References: <4011AEE9.8050303@necom830.hpcl.titech.ac.jp> In-Reply-To: <4011AEE9.8050303@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Thus, UDP is a counter example. > > NAT can not properly handle UDP. Name service queries have worked PROPERLY with NAT since day 1. Similarly, NTP will work perfectly fine for client services. This is demonstrated by the fact that Apple Computer actually specifies a default of time.apple.com as a time server (brave souls). Not that this is an advertisement for NAT, mind you. There are lots of things with it that break, like your sweeping statement. What's really too bad is that when you make such sweeping statements you lose credibility, and that would be just fine with me except that every now and again you actually say something that advances the discussion. Eliot From owner-multi6@ops.ietf.org Fri Jan 23 22:00:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08972 for ; Fri, 23 Jan 2004 22:00:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkDzA-000KAx-H0 for multi6-data@psg.com; Sat, 24 Jan 2004 02:57:24 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AkDyS-000K9h-Gy for multi6@ops.ietf.org; Sat, 24 Jan 2004 02:56:40 +0000 Received: (qmail 90420 invoked from network); 24 Jan 2004 03:06:50 -0000 Received: from h219-110-032-237.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.237) by necom830.hpcl.titech.ac.jp with SMTP; 24 Jan 2004 03:06:50 -0000 Message-ID: <4011DF2D.7030202@necom830.hpcl.titech.ac.jp> Date: Sat, 24 Jan 2004 11:57:49 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Multi6 List Subject: Re: threats ID References: <4011AEE9.8050303@necom830.hpcl.titech.ac.jp> <4011B622.7030308@cisco.com> In-Reply-To: <4011B622.7030308@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear; >> Thus, UDP is a counter example. >> >> NAT can not properly handle UDP. > Name service queries have worked PROPERLY with NAT since day 1. Similarly, NTP will work perfectly fine for client services. That some application over UDP works over NAT does not deny that UDP is a counter example. NAT can not properly handle UDP. > like your sweeping statement. Your misunderstanding is that you thought a counter example must be sweeping. However, an example, by definition, is merely required to be an example. Masataka Ohta From owner-multi6@ops.ietf.org Sat Jan 24 04:52:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02337 for ; Sat, 24 Jan 2004 04:52:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkKOh-0005Vi-6d for multi6-data@psg.com; Sat, 24 Jan 2004 09:48:11 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkKOU-0005VK-MM for multi6@ops.ietf.org; Sat, 24 Jan 2004 09:47:58 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8A0907D70; Sat, 24 Jan 2004 10:47:57 +0100 (CET) Received: from lolo (unknown [163.117.252.59]) by smtp01.uc3m.es (Postfix) with SMTP id 797AB7D6F; Sat, 24 Jan 2004 10:47:56 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" Cc: Subject: RE: to be draft-ohta-multi6-8plus8-00.txt Date: Sat, 24 Jan 2004 10:40:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4011B36B.90300@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > How can transport layer protocols detect that an end or its peer > is capable of M6? As far as i understand, in order to support 8+8 you have to change transport protocols, right? So just add an option that means that you supprt address agile version of the transport protocol. > > How can you make IDs survive ISP changes? Well, this is a plus but it is not the problem that we are trying to solve here, right? this is a problem about changing isps, so we could have a multihoming solution that don't provide this (though i agree that i would be good to solve this problem too) > > How can you be sure to rewrite addresses at the IP layer, if > you are not sure that all the transport layer protocols can > still identify an end? No, i was thinking in something like TCP-MH > > > In other words, as your architectural draft explains, your solutions is > > completelly end to end, so the ends can have the information about what > > locators are linked to an identifier and which is the > identifier to be used > > for each connection, so why is required to reflect this loc/id > split in the > > address itself? > > There are elegant and not so elegant ways to implement an > architecture. > > Have I answered your question? I think so, thanks, marcelo > > Masataka Ohta > > > From owner-multi6@ops.ietf.org Sat Jan 24 07:13:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06816 for ; Sat, 24 Jan 2004 07:13:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkMcK-000HkT-8G for multi6-data@psg.com; Sat, 24 Jan 2004 12:10:24 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkMc7-000Hjj-RC for multi6@ops.ietf.org; Sat, 24 Jan 2004 12:10:11 +0000 Received: from BBFUJIP (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with SMTP id i0OCI0E09903; Sat, 24 Jan 2004 04:18:01 -0800 From: Dave Crocker To: , CC: Multi6 List X-Mailer: PocoMail 3.01 (1661) - EVALUATION VERSION X-URL: http://www.pocomail.com/ Reply-To: dcrocker@brandenburg.com Date: Sat, 24 Jan 2004 06:40:15 +0900 Message-ID: <200412464015.275974@BBFUJIP> In-Reply-To: <87FABA0B-4B8C-11D8-9871-000A95CD987A@muada.com> Subject: Re: threats ID Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 20 Jan 2004 22:06:35 +0100, Iljitsch van Beijnum wrote: > I think there is some middle ground here, where sessions can be grouped > in such that an optimal tradeoff between increased risk and decreased > performance is found. However, this probably means the MH layer needs > to know more than a few intimate details of what the transport > protocols are up to. Thinking about the role of a "shared" pool of address, as with SLAP, I realized that one kind of multiaddress set is limited to a single association, and that the sharing only works when multiple associations have some referential properties that are the same, but not others. Originally, I thought that the shared pool would only be at the granularity of host-to-host. John Wroclawski suggested distinguishing sets of locators by additional parameters (eg, quality of service). I believe this is exactly in line with your suggestion. The idea of creating subsets in order to reduce risk from an individual compromise was not in the discussion, but I believe it is solved by the same mechanism. Define a pooling mechanism. Permit an extensible set of parameters to define subsets of the pool (or at least to label individual address sets.) The details for choosing and using particuler parameters can come later. d/ From owner-multi6@ops.ietf.org Sat Jan 24 07:14:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06834 for ; Sat, 24 Jan 2004 07:14:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkMe0-000Ht7-7H for multi6-data@psg.com; Sat, 24 Jan 2004 12:12:08 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkMdm-000Hrs-V0 for multi6@ops.ietf.org; Sat, 24 Jan 2004 12:11:55 +0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0OCBrV25349 for ; Sat, 24 Jan 2004 14:11:53 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 24 Jan 2004 14:11:51 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 24 Jan 2004 14:11:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: threats ID Date: Sat, 24 Jan 2004 14:11:52 +0200 Message-ID: Thread-Topic: threats ID Thread-Index: AcPhyy+4tF4V7yDnQ9qw7urWQu9DnAAp/+Tw From: To: , Cc: X-OriginalArrivalTime: 24 Jan 2004 12:11:53.0345 (UTC) FILETIME=[40D6EF10:01C3E273] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Tim, I agree & I also wonder if this debate is really achieving anything. thanks, John =20 > > There is no such thing as layer 3.5. > >=20 > > Network layer solutions are at layer 3, transport layer=20 > solutions are > > at layer 4. PERIOD. > >=20 >=20 > As far as I am aware, the IETF has never reached a consensus on how > the layers are to be numbered or what layers should exist. Clearly > the number of layers varies depending on exactly what you are doing. > Note that IPSEC adds a layer, increasing the number of layers below > TCP by one. (I would say that IPSEC looks like it is quite a bit more > than half a layer, and it certainly appears to be thicker than many > other things which are allowed to occupy a full unit of layering in > our minds.) >=20 > I know that many people are aware of the layer numbering convention > that was developed for the OSI suite of compter networking protocols, > but I know of no reason to take that particular numbering of layers > seriously. I have trouble keeping straight which layer is which > number, so I would appreciate it if layers would be refered to by some > meaningful name and not just a bare number. >=20 > What layer number you are at depends on where you start counting and > how many things you have stuck between you and there. >=20 > -Tim Shepard > shep@alum.mit.edu >=20 >=20 From owner-multi6@ops.ietf.org Sat Jan 24 07:25:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07077 for ; Sat, 24 Jan 2004 07:25:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkMpb-000Igq-76 for multi6-data@psg.com; Sat, 24 Jan 2004 12:24:07 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AkMpO-000IfV-Mz for multi6@ops.ietf.org; Sat, 24 Jan 2004 12:23:54 +0000 Received: (qmail 91986 invoked from network); 24 Jan 2004 12:34:10 -0000 Received: from h219-110-032-237.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.237) by necom830.hpcl.titech.ac.jp with SMTP; 24 Jan 2004 12:34:10 -0000 Message-ID: <4012641E.70004@necom830.hpcl.titech.ac.jp> Date: Sat, 24 Jan 2004 21:25:02 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: multi6@ops.ietf.org Subject: Re: to be draft-ohta-multi6-8plus8-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; >>How can transport layer protocols detect that an end or its peer >>is capable of M6? > As far as i understand, in order to support 8+8 you have to change transport > protocols, right? Yes, but... > So just add an option that means that you supprt address agile version of > the transport protocol. The problem is that the modified transport layer can not interoperate with legacy one, unless legacy and 8+8 ones are distinguished easily. >>How can you make IDs survive ISP changes? > Well, this is a plus but it is not the problem that we are trying to solve > here, right? I explain why I proposed the current proposal, part of which may not because it is required by M6. Right? > this is a problem about changing isps, so we could have a multihoming > solution that don't provide this (though i agree that i would be good to > solve this problem too) Brian also showed his concern on instability of IDs. >>How can you be sure to rewrite addresses at the IP layer, if >>you are not sure that all the transport layer protocols can >>still identify an end? > No, i was thinking in something like TCP-MH That some transport layer protocol negotiate with its peer that some locators are valid does not mean IP layer locator change (such as that by mobility) can be notified to the transport layer in time. However, I am recognizing that there is a complex interaction of IP and transport layer locator changes w.r.t. security. Masataka Ohta From owner-multi6@ops.ietf.org Sat Jan 24 07:45:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07474 for ; Sat, 24 Jan 2004 07:45:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkN8p-000Jtv-CT for multi6-data@psg.com; Sat, 24 Jan 2004 12:43:59 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AkN8d-000JqA-Da for multi6@ops.ietf.org; Sat, 24 Jan 2004 12:43:47 +0000 Received: (qmail 92035 invoked from network); 24 Jan 2004 12:54:04 -0000 Received: from h219-110-032-237.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.237) by necom830.hpcl.titech.ac.jp with SMTP; 24 Jan 2004 12:54:04 -0000 Message-ID: <401268C7.4060108@necom830.hpcl.titech.ac.jp> Date: Sat, 24 Jan 2004 21:44:55 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: shep@alum.mit.edu, multi6@ops.ietf.org Subject: Re: threats ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Hi Tim, > > I agree & I also wonder if this debate is really achieving anything. As both of you are unaware of the IPSEC architectural RFC, debates related to IPSEC architecture with you is assured not to achieve anything. So? Masataka Ohta From owner-multi6@ops.ietf.org Sat Jan 24 07:52:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07644 for ; Sat, 24 Jan 2004 07:52:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkNFh-000KSm-GB for multi6-data@psg.com; Sat, 24 Jan 2004 12:51:05 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkNFV-000KSJ-GL for multi6@ops.ietf.org; Sat, 24 Jan 2004 12:50:53 +0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0OCoqV21633 for ; Sat, 24 Jan 2004 14:50:52 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 24 Jan 2004 14:50:51 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sat, 24 Jan 2004 14:50:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: threats ID Date: Sat, 24 Jan 2004 14:50:48 +0200 Message-ID: Thread-Topic: threats ID Thread-Index: AcPid7ittppm1aEbTDW3H+ppgS0bjwAAJ+gQ From: To: Cc: , X-OriginalArrivalTime: 24 Jan 2004 12:50:51.0423 (UTC) FILETIME=[B27152F0:01C3E278] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable My comment is that, as far as I know, there is no specified layering architecture endorsed by the IETF. When you look at the collection of protocols, including things like MPLS, to IPsec, TLS, RTP, etc., it seems rather pointless to come up with a strict interpretation of Internet protocol layering. If there is a real reason for this debate, I would be be happy to be enlightened. thanks, John > -----Original Message----- > From: ext Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: 24 January, 2004 14:45 > To: Loughney John (Nokia-NRC/Helsinki) > Cc: shep@alum.mit.edu; multi6@ops.ietf.org > Subject: Re: threats ID >=20 >=20 > john.loughney@nokia.com wrote: >=20 > > Hi Tim, > >=20 > > I agree & I also wonder if this debate is really achieving anything. >=20 > As both of you are unaware of the IPSEC architectural RFC, debates > related to IPSEC architecture with you is assured not to achieve > anything. >=20 > So? >=20 > Masataka Ohta >=20 >=20 >=20 From owner-multi6@ops.ietf.org Sat Jan 24 08:24:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08331 for ; Sat, 24 Jan 2004 08:24:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkNkG-000N8I-Ah for multi6-data@psg.com; Sat, 24 Jan 2004 13:22:40 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkNk3-000N7V-O8 for multi6@ops.ietf.org; Sat, 24 Jan 2004 13:22:27 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3AADB86AE3; Sat, 24 Jan 2004 08:22:27 -0500 (EST) To: multi6@ops.ietf.org Subject: RE: to be draft-ohta-multi6-8plus8-00.txt Cc: jnc@mercury.lcs.mit.edu Message-Id: <20040124132227.3AADB86AE3@mercury.lcs.mit.edu> Date: Sat, 24 Jan 2004 08:22:27 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "marcelo bagnulo" >> How can you make IDs survive ISP changes? > Well, this is a plus but it is not the problem that we are trying to > solve here, right? > .. we could have a multihoming solution that don't provide this Not that I'm arguing *against* doing this, but I'm just curious as to what the perceived need is (for having the identity not change if you stop buying service from your old ISP and switch to a new one). Let me devil's advocate for a second... I mean, when you change ISP's, if you expect any incoming connections (i.e. if you're in a directory database with some fixed name) then you have to go into the database(s) (DNE, etc) and update it to show your new location. So what's the issue if you have to change the identity field too? I guess the answer is two-fold - and both parts assume that when you change your location, you don't need to do anything manual to get the new location into the computer which moved. First, iff you don't expect any incoming connections, then if your identity stays the same there is nothing to change in the moved computer. (If your identity changed, you'd have to get that into the computer after it moved. Not impossible, but an extra problem.) If you do expect incoming connections, you still don't have to change anything in the computer, just the DNS/etc record(s) - and if one day we get secure DNS with secure updates, presumably the moved computer could update the DNS automatically. Did I miss anything? Noel From owner-multi6@ops.ietf.org Sat Jan 24 18:22:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29065 for ; Sat, 24 Jan 2004 18:22:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkX3J-000GsD-TW for multi6-data@psg.com; Sat, 24 Jan 2004 23:18:57 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AkX2u-000Gqq-SX for multi6@ops.ietf.org; Sat, 24 Jan 2004 23:18:33 +0000 Received: (qmail 94026 invoked from network); 24 Jan 2004 23:28:57 -0000 Received: from h219-110-032-093.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.93) by necom830.hpcl.titech.ac.jp with SMTP; 24 Jan 2004 23:28:57 -0000 Message-ID: <4012FD8B.909@necom830.hpcl.titech.ac.jp> Date: Sun, 25 Jan 2004 08:19:39 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: shep@alum.mit.edu, multi6@ops.ietf.org Subject: Re: threats ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney; > My comment is that, as far as I know, there is no specified layering > architecture endorsed by the IETF. When you look at the collection > of protocols, including things like MPLS, to IPsec, TLS, RTP, etc., > it seems rather pointless to come up with a strict interpretation of > Internet protocol layering. As is evidenced by the IPSEC RFC, there is a concret consensus on the IP layer. MPLS, as I originally proposed, was an attempt to relate connection oriented L2 and connection oriented L4. Later, some people attemptted to combine it with connection oriented IP layer and failed. Sub-IP layer is nothing more than layer 2. As for upper layers, as I discussed in Vienna, threre is no point to distinguish transport and applicaiton layers, which is a separation internal to an end unrelated and invisible to the network, unless the network support QoS (not ToS but real one). As there is no M6 proposal based on poor MPLS, just say Layer 3 and Layer 4. > If there is a real reason for this debate, I would be be happy to > be enlightened. The most important point you should be enlightend is that the IP layer is connectionless, which I already made clear in response to Brian. Masataka Ohta From owner-multi6@ops.ietf.org Sat Jan 24 18:28:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29156 for ; Sat, 24 Jan 2004 18:28:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkXBz-000Hcy-Ef for multi6-data@psg.com; Sat, 24 Jan 2004 23:27:55 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AkXBn-000Hbb-Dk for multi6@ops.ietf.org; Sat, 24 Jan 2004 23:27:43 +0000 Received: (qmail 94070 invoked from network); 24 Jan 2004 23:38:08 -0000 Received: from h219-110-032-093.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.93) by necom830.hpcl.titech.ac.jp with SMTP; 24 Jan 2004 23:38:08 -0000 Message-ID: <4012FFB3.9030104@necom830.hpcl.titech.ac.jp> Date: Sun, 25 Jan 2004 08:28:51 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Noel Chiappa CC: multi6@ops.ietf.org Subject: Re: to be draft-ohta-multi6-8plus8-00.txt References: <20040124132227.3AADB86AE3@mercury.lcs.mit.edu> In-Reply-To: <20040124132227.3AADB86AE3@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Noel; > > Well, this is a plus but it is not the problem that we are trying to > > solve here, right? > > .. we could have a multihoming solution that don't provide this > > Not that I'm arguing *against* doing this, but I'm just curious as to what the > perceived need is (for having the identity not change if you stop buying > service from your old ISP and switch to a new one). Please be aware that we buy service from multiple ISPs, some of which may change. > I mean, when you change ISP's, if you expect any incoming connections (i.e. if > you're in a directory database with some fixed name) then you have to go into > the database(s) (DNE, etc) and update it to show your new location. So what's > the issue if you have to change the identity field too? With ISP independent ID, you don't have to change ID hardcoded in some file such as domain_name<->ID mapping. > If you do expect incoming connections, you still don't have to change anything > in the computer, just the DNS/etc record(s) - and if one day we get secure DNS > with secure updates, presumably the moved computer could update the DNS > automatically. It is a classic misunderstanding on possibility of automatic renumbering ignoring DNS glue, which is too subtle to understand without much expertise in DNS. Masataka Ohta From owner-multi6@ops.ietf.org Sun Jan 25 01:01:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07581 for ; Sun, 25 Jan 2004 01:01:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkdIc-000NgB-O9 for multi6-data@psg.com; Sun, 25 Jan 2004 05:59:10 +0000 Received: from [66.92.66.146] (helo=alva.home) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkdIQ-000Nfe-6Y for multi6@ops.ietf.org; Sun, 25 Jan 2004 05:58:58 +0000 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1AkdHx-0000pD-00; Sun, 25 Jan 2004 00:58:29 -0500 From: Tim Shepard To: Masataka Ohta cc: Multi6 List Subject: Re: threats ID In-reply-to: Your message of Sat, 24 Jan 2004 08:21:38 +0900. <4011AC82.2000207@necom830.hpcl.titech.ac.jp> Date: Sun, 25 Jan 2004 00:58:29 -0500 Message-Id: X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > Note that IPSEC adds a layer, increasing the number of layers below > > TCP by one. > > it is clearly stated in RFC2401 "Security Architecture for the > Internet Protocol", which defines IPSEC architecture, that: > > The goal of the architecture is to provide various security > services for traffic at the IP layer, in both the IPv4 and IPv6 > environments. Interesting that the draft says that. Note though that despite the draft saying that IPSEC provides it "at" the IP layer, it in fact does all of its communication sitting on top of unmodified IP. For example, the routers don't need to be upgraded to allow IPSEC to run over them. So in some meaningful sense, IPSEC is above the IP layer, even if there is a document telling us that we're not supposed to think about it that way. -Tim Shepard shep@alum.mit.edu From owner-multi6@ops.ietf.org Sun Jan 25 03:35:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24786 for ; Sun, 25 Jan 2004 03:35:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkfjY-000CJL-PA for multi6-data@psg.com; Sun, 25 Jan 2004 08:35:08 +0000 Received: from [217.174.67.68] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkfjF-000CGb-0N for multi6@ops.ietf.org; Sun, 25 Jan 2004 08:34:56 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 6AAEF273C0C for ; Sun, 25 Jan 2004 09:34:31 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <82520BD9-4E47-11D8-BCF8-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Draft agenda for IETF59 Date: Sat, 24 Jan 2004 09:30:04 +0100 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Draft agenda so far 1. Agenda bashing 5 2. Charter review 15 3. Short intros to NEW drafts 20 4. draft-lear-multi6-things-to-think-about-00.txt 30 Authors of _NEW_ drafts, please send slot requests to me and Brian. Kurtis + Brian -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQBItDqarNKXTPFCVEQLR9gCaAxvzoCrKFucemeWstytqNbE9vN8An05W aAWRB67zSeuWyc031z46NdFn =kmrK -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Jan 25 03:35:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24820 for ; Sun, 25 Jan 2004 03:35:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Akfip-000CFq-93 for multi6-data@psg.com; Sun, 25 Jan 2004 08:34:23 +0000 Received: from [217.174.67.68] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkfiP-000C5Y-Sh for multi6@ops.ietf.org; Sun, 25 Jan 2004 08:34:01 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id D4A01273BFB; Sun, 25 Jan 2004 09:33:46 +0100 (CET) In-Reply-To: <4010C470.7010606@necom830.hpcl.titech.ac.jp> References: <400D2075.8040207@necom830.hpcl.titech.ac.jp> <400DB734.8000307@necom830.hpcl.titech.ac.jp> <4010C470.7010606@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <72848B4C-4E45-11D8-BCF8-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List , Iljitsch van Beijnum From: Kurt Erik Lindqvist Subject: Re: threats ID Date: Sat, 24 Jan 2004 09:15:18 +0100 To: Masataka Ohta X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> I believe NOID and certainly ODT allow layer 4 to work without >>>> changes, >>> >>> You can believe so, just as you can believe NAT allow layer 4 to work >>> without changes. >> I think there is a notable difference. In my reading you are using >> NAT very loose for all forms of address rewrite. NAT to me does >> static rewrites, with no form of signaling. > > Wrong. Rewriting is not the essential problem. > > Right. The problem is lack of signaling OF *CONNECTIONS*. > > As you might know, there is no connections and signaling at > the IP layer. Right, but along the same lines of reasoning - NAT won't break anything at the _IP_ layer. It might break things at the ULPs though. > Thus, the only thing NAT and other layer 3 things can do is > guessing the connection state by a lack of communication > for certain period of time, though, sometimes, you can detect > TCP SYN and FIN. I would say that this is the difference between (most) of the proposals in multi6 and NAT. The proposals have provided mechanisms to let ULPs handle referrals, even when there is rewriting. Something that NAT does not provide. > However, that you observe no traffic over a connection does > not necessarily mean that the connection is broken. True. Which is also the topic of a long thread here some time ago. > There is no signaling unless layer 4 and above are involved, > though guessing may work for TCP. The mechanisms to allow address rewrite will have to a) Leave to the ULPs to handle connection state and connection verification. An aid in doing this might be to create a middle layer (the 3.5) which functions as a recording mechanism on state. b) Provide a means to the ULPs to handle referrals transparently. Again, this can be done with a shim layer, or in other ways. >> Especially breaking referrals by hiding the "true" address to the >> outside world. Most (if not all) id/loc proposals here (claims) that >> referrals do work. There is a hugh difference, referrals is a crucial >> component of any multi6 solution. This was also pointed out in the >> comments by Patrick. > > NAT rewriting is transparent to applicaitons, if the applications > relies on TCP and DNS and DNS is modified to reflect the rewriting. > > So are other proposals, including mine, as is explained in > my proposal. To dive into semantics, part of the problem/difference between multi6 proposals and NAT is the fact that NAT _is_ transparent to the ULPs and that no state is recorded at the end-nodes. And now we are close to drifting into the point that Vijay raised on if this is good or not. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQBIpmaarNKXTPFCVEQLaGACfXY9uwf8F71Af8t7LFLMq7W2hkGsAn3SY +EJNc3q2PZPCTZrch8BPVshq =8ASM -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Jan 25 03:36:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24869 for ; Sun, 25 Jan 2004 03:36:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Akfj4-000CGY-8r for multi6-data@psg.com; Sun, 25 Jan 2004 08:34:38 +0000 Received: from [217.174.67.68] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Akfih-000CFC-3D for multi6@ops.ietf.org; Sun, 25 Jan 2004 08:34:17 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id CA6C2273BFE; Sun, 25 Jan 2004 09:34:01 +0100 (CET) In-Reply-To: <4010FB11.A2E07714@zurich.ibm.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B05836BAF@tayexc13.americas.cpqcorp.net> <4010FB11.A2E07714@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org, "Bound, Jim" From: Kurt Erik Lindqvist Subject: Re: Reminder re multi6 drafts Date: Sat, 24 Jan 2004 09:16:43 +0100 To: Brian E Carpenter X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To echo Brian. If someone could at least write up an email to the list, I think is a good starting point. But again, there is only 24h a day... - - kurtis - On 2004-01-23, at 11.44, Brian E Carpenter wrote: > Jim, > > We understand of course that there are only 168 hours a week. > > The WG will have to take an architectural decision at some point > whether to pursue transport layer solution(s). Without the SCTP > case being on the table, we will be handicapped. If anybody else > feels like doing even a superficial job on SCTP in the next few > days, that would be very helpful. > > Brian > > "Bound, Jim" wrote: >> >> SCTP will not happen before this month. Randy, Yanick, and I cannot >> get >> it done. Sorry. >> /jim >> >>> -----Original Message----- >>> From: owner-multi6@ops.ietf.org >>> [mailto:owner-multi6@ops.ietf.org] On Behalf Of Brian E Carpenter >>> Sent: Tuesday, January 20, 2004 1:36 PM >>> To: multi6@ops.ietf.org >>> Subject: Re: Reminder re multi6 drafts >>> >>> >>> It's getting very close to the end of January. We are still >>> hoping for HIP and SCTP based drafts this month, so that they can >>> be thoroughly analyzed before the IETF. >>> >>> Brian >>> >>> Brian E Carpenter wrote: >>>> >>>> Folks, >>>> >>>> Just a reminder that we'd like all updated or new drafts describing >>>> possible approaches to solutions for multi6 to be submitted in the >>>> near future. We originally suggested a hard deadline of the end >>>> of December, but since people found that too rigid, let's try for >>>> having all the I-Ds available by mid-January at the latest. >>>> In addition to the existing proposals discussed in Minneapolis, >>>> we are at least expecting HIP and SCTP based contributions. >>>> >>>> We do ask that each draft includes a *short* >>> self-assessment against the >>>> goals in RFC 3582. For convenience, please name them as >>>> draft-AUTHOR-multi6-... >>>> >>>> Please remember that one of our objectives is to identify >>> architectural >>>> components that occur in the various proposals. >>>> >>>> The co-chairs are acutely aware that the published charter for this >>>> WG is out of date. We do plan to fix that. >>>> >>>> Brian >>>> multi6 co-chair >>>> -- > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQBIp7aarNKXTPFCVEQLc2gCfXfueNEYxITCYI+lhtsxb7yZECLsAoOm2 0qPb80wZ53UZl/LLT1otOwru =NfHW -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Jan 25 03:36:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24895 for ; Sun, 25 Jan 2004 03:36:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Akfic-000CFG-9V for multi6-data@psg.com; Sun, 25 Jan 2004 08:34:10 +0000 Received: from [217.174.67.68] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkfiG-000C5O-LG for multi6@ops.ietf.org; Sun, 25 Jan 2004 08:33:54 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id F2E44273BF8 for ; Sun, 25 Jan 2004 09:33:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <3210C00A-4E44-11D8-BCF8-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Mailinglist maintenance Date: Sat, 24 Jan 2004 09:06:21 +0100 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, the following recipients have generated enough bounces to the list mgmt address that I will desubscribe them in a week unless someone objects or have idea of how to contact them : andy@advsys.com (generated from multi6-data@psg.com) Operation timed out: retry timeout exceeded ikkim@cclab.chungnam.ac.kr (generated from multi6-data@psg.com) SMTP error from remote mailer after RCPT TO:: host cclab.chungnam.ac.kr [168.188.129.51]: 550 5.7.1 ... Relaying denied yhchoi@cclab.chungnam.ac.kr (generated from multi6-data@psg.com) SMTP error from remote mailer after RCPT TO:: host cclab.chungnam.ac.kr [168.188.129.51]: 550 5.7.1 ... Relaying denied kikim@cclab.chungnam.ac.kr (generated from multi6-data@psg.com) SMTP error from remote mailer after RCPT TO:: host cclab.chungnam.ac.kr [168.188.129.51]: 550 5.7.1 ... Relaying denied input@ietfwatch.kgbinternet.com (generated from multi6-data@psg.com) SMTP error from remote mailer after RCPT TO:: host smtp.kgbinternet.com [24.72.41.199]: 550 5.1.1 ... User unknown In addition, the Nokia mail-server more or less regularly behaves wired and produces variations of problem reports like below : vijayd@iprg.nokia.com (generated from multi6-data@psg.com) SMTP error from remote mailer after end of data: host mailrelay.iprg.nokia.com [205.226.0.201]: 509 Header field too long ftemplin@IPRG.nokia.com (generated from multi6-data@psg.com) SMTP error from remote mailer after end of data: host mailrelay.iprg.nokia.com [205.226.0.201]: 509 Header field too long david@IPRG.nokia.com (generated from multi6-data@psg.com) SMTP error from remote mailer after end of data: host mailrelay.iprg.nokia.com [205.226.0.201]: 509 Header field too long hinden@IPRG.nokia.com (generated from multi6-data@psg.com) SMTP error from remote mailer after end of data: host mailrelay.iprg.nokia.com [205.226.0.201]: 509 Header field too long Maybe someone at Nokia could talk to their sysadmins. I guess it's a benefit if the ADs get the mails of their WGs :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQBIngaarNKXTPFCVEQLC0QCgrYexTlA+J/zH+mp6eCwFBmPLca8AoLTo 3Tjh3zVTJTyG2UT/a/OMcGOi =D1MQ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Jan 25 03:56:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25492 for ; Sun, 25 Jan 2004 03:56:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Akg3z-000EZw-UB for multi6-data@psg.com; Sun, 25 Jan 2004 08:56:15 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Akg3n-000EZ2-8m for multi6@ops.ietf.org; Sun, 25 Jan 2004 08:56:03 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0P8u1Y00019 for ; Sun, 25 Jan 2004 10:56:02 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 25 Jan 2004 10:56:01 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 25 Jan 2004 10:56:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Reminder re multi6 drafts Date: Sun, 25 Jan 2004 10:56:00 +0200 Message-ID: Thread-Topic: Reminder re multi6 drafts Thread-Index: AcPjHmv/x5CnOK5JSRyBcQsOtKCoUwAAlMuQ From: To: , Cc: , X-OriginalArrivalTime: 25 Jan 2004 08:56:00.0669 (UTC) FILETIME=[0E1CA4D0:01C3E321] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Kurt, > To echo Brian. If someone could at least write up an email to=20 > the list,=20 > I think is a good starting point. But again, there is only=20 > 24h a day... I helped Lode on the SCTP multihoming draft. I think I know enough of what is going on to write something up. I wasn't planning on doing this, but I could take a stab. If I submit it by Friday, would that be OK? If anyone else wants to help out on this, I'd be more than happy. If someone else has planned to take care of this already, than it is no problem - but I could provide input if input is needed. thanks, John From owner-multi6@ops.ietf.org Sun Jan 25 04:10:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25845 for ; Sun, 25 Jan 2004 04:10:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkgHE-000Frs-Lo for multi6-data@psg.com; Sun, 25 Jan 2004 09:09:56 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AkgH2-000Frb-N6 for multi6@ops.ietf.org; Sun, 25 Jan 2004 09:09:44 +0000 Received: (qmail 95668 invoked from network); 25 Jan 2004 09:20:16 -0000 Received: from h219-110-032-093.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.93) by necom830.hpcl.titech.ac.jp with SMTP; 25 Jan 2004 09:20:16 -0000 Message-ID: <4013881C.8000505@necom830.hpcl.titech.ac.jp> Date: Sun, 25 Jan 2004 18:10:52 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Tim Shepard CC: Multi6 List Subject: Re: threats ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Shepard; >>>Note that IPSEC adds a layer, increasing the number of layers below >>>TCP by one. >> >>it is clearly stated in RFC2401 "Security Architecture for the >>Internet Protocol", which defines IPSEC architecture, that: >> >> The goal of the architecture is to provide various security >> services for traffic at the IP layer, in both the IPv4 and IPv6 >> environments. > Interesting that the draft says that. Note though that despite the > draft saying that IPSEC provides it "at" the IP layer, it in fact does > all of its communication sitting on top of unmodified IP. It is not a draft but the architectural RFC of IPSEC. > For > example, the routers don't need to be upgraded to allow IPSEC to run > over them. For example, the routers don't need to be upgraded to allow fragmentation of IPv6 and reassembly of IPv4 and IPv6. So? > So in some meaningful sense, IPSEC is above the IP layer, > even if there is a document telling us that we're not supposed to > think about it that way. Hugh? Your point was not technical but lack of IETF consensus. But, if you want to know technical points, see above. Though IPSEC is poorly designed, its architecture is OK. Masataka Ohta From owner-multi6@ops.ietf.org Sun Jan 25 04:26:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26164 for ; Sun, 25 Jan 2004 04:26:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkgWd-000H1t-MB for multi6-data@psg.com; Sun, 25 Jan 2004 09:25:51 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AkgWR-000H15-KB for multi6@ops.ietf.org; Sun, 25 Jan 2004 09:25:39 +0000 Received: (qmail 95739 invoked from network); 25 Jan 2004 09:36:12 -0000 Received: from h219-110-032-093.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.93) by necom830.hpcl.titech.ac.jp with SMTP; 25 Jan 2004 09:36:12 -0000 Message-ID: <40138BD7.30003@necom830.hpcl.titech.ac.jp> Date: Sun, 25 Jan 2004 18:26:47 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Multi6 List , Iljitsch van Beijnum Subject: Re: threats ID References: <400D2075.8040207@necom830.hpcl.titech.ac.jp> <400DB734.8000307@necom830.hpcl.titech.ac.jp> <4010C470.7010606@necom830.hpcl.titech.ac.jp> <72848B4C-4E45-11D8-BCF8-000A95928574@kurtis.pp.se> In-Reply-To: <72848B4C-4E45-11D8-BCF8-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt; >>>I think there is a notable difference. In my reading you are using >>>NAT very loose for all forms of address rewrite. NAT to me does >>>static rewrites, with no form of signaling. >> >>Wrong. Rewriting is not the essential problem. >> >>Right. The problem is lack of signaling OF *CONNECTIONS*. >> >>As you might know, there is no connections and signaling at >>the IP layer. > Right, but along the same lines of reasoning - NAT won't break > anything at the _IP_ layer. It might break things at the ULPs though. And the brokne ULPs need repairing, which means ULPs are modified. >>Thus, the only thing NAT and other layer 3 things can do is >>guessing the connection state by a lack of communication >>for certain period of time, though, sometimes, you can detect >>TCP SYN and FIN. > I would say that this is the difference between (most) of the proposals > in multi6 and NAT. The proposals have provided mechanisms to let ULPs > handle referrals, even when there is rewriting. Something that NAT does > not provide. Are you saying ULP modification necessary or not? >>However, that you observe no traffic over a connection does >>not necessarily mean that the connection is broken. > True. Which is also the topic of a long thread here some time ago. It is an obvious evidence that NAT is a bad idea, which does not worth a long thread. >>There is no signaling unless layer 4 and above are involved, >>though guessing may work for TCP. > > > The mechanisms to allow address rewrite will have to > > a) Leave to the ULPs to handle connection state and connection > verification. An aid in doing this might be to create a middle layer > (the 3.5) which functions as a recording mechanism on state. As there can be no such thing under UDP. such a middle layer, if any, becomes layer 4 protocol specific and is a part of the layer 4 protocol. So, call it modified layer 4. > b) Provide a means to the ULPs to handle referrals transparently. > Again, this can be done with a shim layer, or in other ways. Are you saying you modify ULPs or not? > To dive into semantics, part of the problem/difference between multi6 > proposals and NAT is the fact that NAT _is_ transparent to the ULPs and > that no state is recorded at the end-nodes. You misunderstand NAT. NAT (including so called IP layer multi6 proposals) is no transparent. NAT does not have correct knowledge on information recorded at the ULPs of the end that NAT can not properly interoperate with them. Masataka Ohta From owner-multi6@ops.ietf.org Sun Jan 25 04:28:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26226 for ; Sun, 25 Jan 2004 04:28:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkgYj-000HBt-Cc for multi6-data@psg.com; Sun, 25 Jan 2004 09:28:01 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AkgYX-000HAR-Au for multi6@ops.ietf.org; Sun, 25 Jan 2004 09:27:49 +0000 Received: (qmail 95749 invoked from network); 25 Jan 2004 09:38:22 -0000 Received: from h219-110-032-093.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.93) by necom830.hpcl.titech.ac.jp with SMTP; 25 Jan 2004 09:38:22 -0000 Message-ID: <40138C58.50500@necom830.hpcl.titech.ac.jp> Date: Sun, 25 Jan 2004 18:28:56 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Brian E Carpenter , multi6@ops.ietf.org, "Bound, Jim" Subject: Re: Reminder re multi6 drafts References: <9C422444DE99BC46B3AD3C6EAFC9711B05836BAF@tayexc13.americas.cpqcorp.net> <4010FB11.A2E07714@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt; When is the deadline to write up the email for SCTP based and other proposals? Masataka Ohta > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > To echo Brian. If someone could at least write up an email to the list, > I think is a good starting point. But again, there is only 24h a day... > > - - kurtis - > > On 2004-01-23, at 11.44, Brian E Carpenter wrote: > > >>Jim, >> >>We understand of course that there are only 168 hours a week. >> >>The WG will have to take an architectural decision at some point >>whether to pursue transport layer solution(s). Without the SCTP >>case being on the table, we will be handicapped. If anybody else >>feels like doing even a superficial job on SCTP in the next few >>days, that would be very helpful. >> >> Brian >> >>"Bound, Jim" wrote: >> >>>SCTP will not happen before this month. Randy, Yanick, and I cannot >>>get >>>it done. Sorry. >>>/jim >>> >>> >>>>-----Original Message----- >>>>From: owner-multi6@ops.ietf.org >>>>[mailto:owner-multi6@ops.ietf.org] On Behalf Of Brian E Carpenter >>>>Sent: Tuesday, January 20, 2004 1:36 PM >>>>To: multi6@ops.ietf.org >>>>Subject: Re: Reminder re multi6 drafts >>>> >>>> >>>>It's getting very close to the end of January. We are still >>>>hoping for HIP and SCTP based drafts this month, so that they can >>>>be thoroughly analyzed before the IETF. >>>> >>>> Brian >>>> >>>>Brian E Carpenter wrote: >>>> >>>>>Folks, >>>>> >>>>>Just a reminder that we'd like all updated or new drafts describing >>>>>possible approaches to solutions for multi6 to be submitted in the >>>>>near future. We originally suggested a hard deadline of the end >>>>>of December, but since people found that too rigid, let's try for >>>>>having all the I-Ds available by mid-January at the latest. >>>>>In addition to the existing proposals discussed in Minneapolis, >>>>>we are at least expecting HIP and SCTP based contributions. >>>>> >>>>>We do ask that each draft includes a *short* >>>> >>>>self-assessment against the >>>> >>>>>goals in RFC 3582. For convenience, please name them as >>>>> draft-AUTHOR-multi6-... >>>>> >>>>>Please remember that one of our objectives is to identify >>>> >>>>architectural >>>> >>>>>components that occur in the various proposals. >>>>> >>>>>The co-chairs are acutely aware that the published charter for this >>>>>WG is out of date. We do plan to fix that. >>>>> >>>>> Brian >>>>> multi6 co-chair >>>>>-- >> > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.3 > > iQA/AwUBQBIp7aarNKXTPFCVEQLc2gCfXfueNEYxITCYI+lhtsxb7yZECLsAoOm2 > 0qPb80wZ53UZl/LLT1otOwru > =NfHW > -----END PGP SIGNATURE----- > > > > From owner-multi6@ops.ietf.org Sun Jan 25 05:12:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27054 for ; Sun, 25 Jan 2004 05:12:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkhDq-000Kuw-0M for multi6-data@psg.com; Sun, 25 Jan 2004 10:10:30 +0000 Received: from [134.193.143.160] (helo=kc-msxproto3.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkhDe-000Ktv-6m for multi6@ops.ietf.org; Sun, 25 Jan 2004 10:10:18 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jan 2004 04:10:16 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: threats ID Date: Sun, 25 Jan 2004 04:10:15 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B0110824F@KC-MAIL4.kc.umkc.edu> Thread-Topic: threats ID Thread-Index: AcPjHuePHf3Km8GqTXqsohG3ReTOsQACzOb/ From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Kurt Erik Lindqvist" , "Masataka Ohta" Cc: "Multi6 List" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 25 Jan 2004 10:10:16.0981 (UTC) FILETIME=[6E47E450:01C3E32B] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I would say that this is the difference between (most) of the = proposals > in multi6 and NAT. The proposals have provided mechanisms to let ULPs > handle referrals, even when there is rewriting. Something that NAT = does > not provide. =20 what about 4+4? It is a NAT based proposal which handle referral service pretty well. Also,if FQDNs can handle referral task, NAT can be extended = to provide a scalable site-multihoming solution( Paul Francis IPNL is=20 an example.) =20 btw, I know that NAT, IPv4 and FQDNs have problems. From owner-multi6@ops.ietf.org Sun Jan 25 05:27:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27252 for ; Sun, 25 Jan 2004 05:27:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkhU4-000Ltc-B1 for multi6-data@psg.com; Sun, 25 Jan 2004 10:27:16 +0000 Received: from [134.193.143.160] (helo=kc-msxproto3.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkhTU-000LqX-HJ for multi6@ops.ietf.org; Sun, 25 Jan 2004 10:26:40 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jan 2004 04:26:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: threats ID Date: Sun, 25 Jan 2004 04:26:38 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108250@KC-MAIL4.kc.umkc.edu> Thread-Topic: threats ID Thread-Index: AcPjI7p2gPx8HXS7RgG+OAkA1rQjwgACAOLO From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Masataka Ohta" , "Tim Shepard" Cc: "Multi6 List" X-OriginalArrivalTime: 25 Jan 2004 10:26:39.0428 (UTC) FILETIME=[B7DD6840:01C3E32D] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >> So in some meaningful sense, IPSEC is above the IP layer, >> even if there is a document telling us that we're not supposed to >> think about it that way. > > Hugh? Your point was not technical but lack of IETF consensus. =20 ok. Can you provide a citation (RFC) which illustrates your=20 statement: =20 > There is no such thing as layer 3.5. > Network layer solutions are at layer 3,=20 > transport layer solutions are at layer 4.=20 > PERIOD =20 =20 As another example, transport advertises that it is ECN enabled but congestion notification is given by the routers at network level. =20 =20 =20 From owner-multi6@ops.ietf.org Sun Jan 25 05:34:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27365 for ; Sun, 25 Jan 2004 05:34:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkhaT-000MSs-K6 for multi6-data@psg.com; Sun, 25 Jan 2004 10:33:53 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AkhaH-000MRP-2m for multi6@ops.ietf.org; Sun, 25 Jan 2004 10:33:41 +0000 Received: (qmail 95984 invoked from network); 25 Jan 2004 10:44:14 -0000 Received: from h219-110-032-093.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.93) by necom830.hpcl.titech.ac.jp with SMTP; 25 Jan 2004 10:44:14 -0000 Message-ID: <40139BC8.6000408@necom830.hpcl.titech.ac.jp> Date: Sun, 25 Jan 2004 19:34:48 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: "Ayyasamy, Senthilkumar \(UMKC-Student\)" CC: Tim Shepard , Multi6 List Subject: Re: threats ID References: <5EF7D95E17BDAD4A968C812E5ABC390B01108250@KC-MAIL4.kc.umkc.edu> In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B01108250@KC-MAIL4.kc.umkc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ayyasamy, Senthilkumar; >>>So in some meaningful sense, IPSEC is above the IP layer, >>>even if there is a document telling us that we're not supposed to >>>think about it that way. >> >>Hugh? Your point was not technical but lack of IETF consensus. > ok. So, you are wrong, completely. > Can you provide a citation (RFC) which illustrates your > statement: > > > There is no such thing as layer 3.5. > > Network layer solutions are at layer 3, > > transport layer solutions are at layer 4. > > PERIOD You should ask it Brian, because he said 3.5 first. But, I recommend you do it privately. No carbon copying to me is necessary. > As another example, transport advertises that it is ECN enabled > but congestion notification is given by the routers at network > level. That's perfectly fine layering. Are you saying so, or are you saying you are not sure? Masataka Ohta From owner-multi6@ops.ietf.org Sun Jan 25 05:40:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27524 for ; Sun, 25 Jan 2004 05:40:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkhgS-000NCt-Tw for multi6-data@psg.com; Sun, 25 Jan 2004 10:40:04 +0000 Received: from [134.193.143.167] (helo=kc-msxproto1.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkhgF-000NAQ-AD for multi6@ops.ietf.org; Sun, 25 Jan 2004 10:39:51 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jan 2004 04:39:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: threats ID Date: Sun, 25 Jan 2004 04:39:49 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108251@KC-MAIL4.kc.umkc.edu> Thread-Topic: threats ID Thread-Index: AcPidDlRRud/WsrGTOKuqHSGEdA++AAuZq6v From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: , , Cc: "Multi6 List" X-OriginalArrivalTime: 25 Jan 2004 10:39:50.0717 (UTC) FILETIME=[8F8286D0:01C3E32F] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > Thinking about the role of a "shared" pool of address, as with SLAP,=20 > I realized that one kind of multiaddress set is limited to a single=20 > association, and that the sharing only works when multiple=20 > associations have some referential properties that are the same,=20 > but not others. =20 =20 while SLAP and TCP-MH etc proposals sounds interesting at *architectural level*, what effect they have on e2e cc algorithms? I am curious because neither SCTP nor DCCP support multi-paths(SCTP use multiaddress for=20 reliability whereas DCCP for mobility.) I presume, it will surely=20 have impact on re-ordering and the related fast retransmit algorithms. =20 =20 =20 From owner-multi6@ops.ietf.org Sun Jan 25 06:27:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28434 for ; Sun, 25 Jan 2004 06:27:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkiPe-0000qV-2t for multi6-data@psg.com; Sun, 25 Jan 2004 11:26:46 +0000 Received: from [134.193.143.155] (helo=kc-msxproto2.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkiPS-0000q0-BD for multi6@ops.ietf.org; Sun, 25 Jan 2004 11:26:34 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jan 2004 05:26:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: threats ID Date: Sun, 25 Jan 2004 05:26:32 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108253@KC-MAIL4.kc.umkc.edu> Thread-Topic: threats ID Thread-Index: AcPjLrYULOsb8bXDR865UAcOKHR63AABBaKH From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: X-OriginalArrivalTime: 25 Jan 2004 11:26:33.0796 (UTC) FILETIME=[16467040:01C3E336] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >> Can you provide a citation (RFC) which illustrates your >> statement: >>=20 >> > There is no such thing as layer 3.5. >> > Network layer solutions are at layer 3, >> > transport layer solutions are at layer 4. >> > PERIOD =20 > >You should ask it Brian, because he said 3.5 first. =20 OTOH, you stated explicitly that "Network layer=20 solutions are at layer 3. transport layer solutions=20 are at layer 4." Please provide a citation for this=20 one... =20 >> As another example, transport advertises that it is ECN enabled >> but congestion notification is given by the routers at network >> level. > >That's perfectly fine layering. =20 But, it also points out that ECN and IPsec negates your=20 sweeping statement "Network layer solutions are at layer 3.=20 transport layer solutions are at layer 4." =20 =20 >> So, you are wrong, completely. =20 so, I am correct. =20 I suggest you read: =20 D. Clark and D. Tennenhouse.=20 Architectural Considerations for a New Generation of protocols ACM SIGCOMM 1990. =20 =20 From owner-multi6@ops.ietf.org Sun Jan 25 06:37:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28640 for ; Sun, 25 Jan 2004 06:37:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkiZv-0001Wc-FN for multi6-data@psg.com; Sun, 25 Jan 2004 11:37:23 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkiZi-0001VJ-QH for multi6@ops.ietf.org; Sun, 25 Jan 2004 11:37:10 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1714F82AC; Sun, 25 Jan 2004 12:37:10 +0100 (CET) Received: from lolo (vpn-252-75.uc3m.es [163.117.252.75]) by smtp01.uc3m.es (Postfix) with SMTP id 77B9B82A8; Sun, 25 Jan 2004 12:37:08 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Noel Chiappa" , Subject: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt) Date: Sun, 25 Jan 2004 12:29:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20040124132227.3AADB86AE3@mercury.lcs.mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Noel, Well, i think that providing stable ids (independent of the provider) is a good approach not really becuase today things may be simpler but because we can benefit from it in the future. I mean, i guess we agree that renmbering when changing ISP is a must and so obtaining a simple and cheap renumbering process is good. Probably locators will be hardcoded in less places than today, so they will be simpler to renumber and IDs will be hardcoded in some of the places that ip are used today and perhaps in many others, since they will be used for recognizing endpoints in apps and filters, acls and so on So renumbering locators maybe simpler than renumbering IPs today, but renumbering IDs may be quite complex since it may require lots of manual configuration IMHO, stable ids are good Does this makes sense to you? Regards, marcelo > Not that I'm arguing *against* doing this, but I'm just curious > as to what the perceived need is (for having the > identity not change if you stop buying > service from your old ISP and switch to a new one). Let me > devil's advocate for a second... > > I mean, when you change ISP's, if you expect any incoming > connections (i.e. if > you're in a directory database with some fixed name) then you > have to go into > the database(s) (DNE, etc) and update it to show your new > location. So what's > the issue if you have to change the identity field too? > > > I guess the answer is two-fold - and both parts assume that when > you change > your location, you don't need to do anything manual to get the > new location > into the computer which moved. > > First, iff you don't expect any incoming connections, then if > your identity > stays the same there is nothing to change in the moved computer. (If your > identity changed, you'd have to get that into the computer after > it moved. Not > impossible, but an extra problem.) > > If you do expect incoming connections, you still don't have to > change anything > in the computer, just the DNS/etc record(s) - and if one day we > get secure DNS > with secure updates, presumably the moved computer could update the DNS > automatically. > > > Did I miss anything? > > Noel > From owner-multi6@ops.ietf.org Sun Jan 25 07:22:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00031 for ; Sun, 25 Jan 2004 07:22:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkjG0-0004f4-6j for multi6-data@psg.com; Sun, 25 Jan 2004 12:20:52 +0000 Received: from [134.193.143.167] (helo=kc-msxproto1.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkjFn-0004ea-U0 for multi6@ops.ietf.org; Sun, 25 Jan 2004 12:20:40 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jan 2004 06:20:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt) Date: Sun, 25 Jan 2004 06:20:38 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108254@KC-MAIL4.kc.umkc.edu> Thread-Topic: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt) Thread-Index: AcPjOFeBGDtIMQseS4apVgVLrAneugAAG/P2 From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: , "Noel Chiappa" , X-OriginalArrivalTime: 25 Jan 2004 12:20:39.0291 (UTC) FILETIME=[A4BDACB0:01C3E33D] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Probably locators will be hardcoded in less places than today, so they = will > be simpler to renumber and IDs will be hardcoded in some of the places = that > ip are used today and perhaps in many others, since they will be used = for > recognizing endpoints in apps and filters, acls and so on =20 If so,it's good. But, for example, SIP hardcodes locators instead of DNS = names. As per discussions in ietf-aulli, apps folks attributes it to = lack=20 of access to naming service and reduced delay (in terms of lookup = latency.) So, in future, we can expect more such locator hardcoding at ULP. =20 > So renumbering locators maybe simpler than renumbering IPs today, but > renumbering IDs may be quite complex since it may require lots of = manual > configuration =20 it looks simple as i read baker-ipv6-renumbering. But, yaa...reading is=20 different than practical deployment ;-)=20 =20 > IMHO, stable ids are good =20 Other than the renumbering reason, stable ID helps in solving the=20 address ownership problem. HIP like stable IDs can be used to avoid address hijacks and origin misconfigurations; as it provides self verifying capability (i.e. we don't need to depend on costly PKI or CA to authorize the origin prefix.) The assumption being ID and locator=20 mapping is secure. =20 =20 From owner-multi6@ops.ietf.org Sun Jan 25 10:02:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06293 for ; Sun, 25 Jan 2004 10:02:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aklky-000Ize-Cl for multi6-data@psg.com; Sun, 25 Jan 2004 15:01:00 +0000 Received: from [81.13.211.213] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aklkl-000Ixy-FP for multi6@ops.ietf.org; Sun, 25 Jan 2004 15:00:47 +0000 Received: from localhost (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id AC9CB27479B for ; Sun, 25 Jan 2004 16:00:50 +0100 (CET) Date: Sun, 25 Jan 2004 16:00:48 +0100 (CET) From: Kurtis Lindqvist X-X-Sender: kurtis@laptop2-kurtis-pp-se.local To: multi6@ops.ietf.org Subject: BOUNCE multi6@ops.ietf.org: Non-member submission from [Coene Lode ] (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk From Lode.Coene@siemens.com Fri Jan 23 16:15:33 2004 Received: from [194.78.143.102] (helo=hrtades9.atea.be) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak3y0-000Loz-Eq for multi6@ops.ietf.org; Fri, 23 Jan 2004 16:15:32 +0000 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Z1WT2J5T; Fri, 23 Jan 2004 17:15:30 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Jan 2004 17:15:28 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195A7F490@hrtades7.atea.be> From: Coene Lode To: "'mbagnulo@ing.uc3m.es'" , Brian E Carpenter , "Bound, Jim" Cc: multi6@ops.ietf.org Subject: RE: Reminder re multi6 drafts Date: Fri, 23 Jan 2004 17:15:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 The draft mentioned is just to point out how multihoming works in SCTP and what are the pitfalls and how to avoid them. I'm in the process of producing a draft which hopefully answer the questions Eliot Lear draft put up in december(The MULTI6 solution questionaire...) Concerning the draft coming from Jim, Randy and Yanick, that was something along the lines of trying to fit SCTP on top of HIP/NOID/...fill in you favorite 3.5 layer idea or the other way around. I have some ideas concerning that but it isn't baked yet and might turn out to be a clear layer 3 protocol. But it won't come out before Seoul.(that is my draft...) ... Back to having fun at the weekend.... Yours sincerely, Lode From: marcelo bagnulo [mailto:mbagnulo@ing.uc3m.es] Sent: vrijdag 23 januari 2004 16:32 To: Brian E Carpenter; Bound, Jim Cc: multi6@ops.ietf.org Subject: RE: Reminder re multi6 drafts There was a draft by Lode submited a while ago about multihoming issues and sctp http://www.ietf.org/internet-drafts/draft-coene-sctp-multihome-04.txt Perhaps this could be a starting point? Regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Brian E Carpenter > Enviado el: viernes, 23 de enero de 2004 11:45 > Para: Bound, Jim > CC: multi6@ops.ietf.org > Asunto: Re: Reminder re multi6 drafts > > > Jim, > > We understand of course that there are only 168 hours a week. > > The WG will have to take an architectural decision at some point > whether to pursue transport layer solution(s). Without the SCTP > case being on the table, we will be handicapped. If anybody else > feels like doing even a superficial job on SCTP in the next few > days, that would be very helpful. > > Brian > > "Bound, Jim" wrote: > > > > SCTP will not happen before this month. Randy, Yanick, and I cannot get > > it done. Sorry. > > /jim > > > > > -----Original Message----- > > > From: owner-multi6@ops.ietf.org > > > [mailto:owner-multi6@ops.ietf.org] On Behalf Of Brian E Carpenter > > > Sent: Tuesday, January 20, 2004 1:36 PM > > > To: multi6@ops.ietf.org > > > Subject: Re: Reminder re multi6 drafts > > > > > > > > > It's getting very close to the end of January. We are still > > > hoping for HIP and SCTP based drafts this month, so that they can > > > be thoroughly analyzed before the IETF. > > > > > > Brian > > > > > > Brian E Carpenter wrote: > > > > > > > > Folks, > > > > > > > > Just a reminder that we'd like all updated or new drafts describing > > > > possible approaches to solutions for multi6 to be submitted in the > > > > near future. We originally suggested a hard deadline of the end > > > > of December, but since people found that too rigid, let's try for > > > > having all the I-Ds available by mid-January at the latest. > > > > In addition to the existing proposals discussed in Minneapolis, > > > > we are at least expecting HIP and SCTP based contributions. > > > > > > > > We do ask that each draft includes a *short* > > > self-assessment against the > > > > goals in RFC 3582. For convenience, please name them as > > > > draft-AUTHOR-multi6-... > > > > > > > > Please remember that one of our objectives is to identify > > > architectural > > > > components that occur in the various proposals. > > > > > > > > The co-chairs are acutely aware that the published charter for this > > > > WG is out of date. We do plan to fix that. > > > > > > > > Brian > > > > multi6 co-chair > > > > -- > From owner-multi6@ops.ietf.org Sun Jan 25 11:03:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08923 for ; Sun, 25 Jan 2004 11:03:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Akmi1-000OKo-Jg for multi6-data@psg.com; Sun, 25 Jan 2004 16:02:01 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Akmgs-000OCc-Tt for multi6@ops.ietf.org; Sun, 25 Jan 2004 16:00:51 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0PG0ne2061880 for ; Sun, 25 Jan 2004 16:00:49 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0PG0nsY267178 for ; Sun, 25 Jan 2004 17:00:49 +0100 Received: from zurich.ibm.com (sig-9-145-137-59.de.ibm.com [9.145.137.59]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA62230 for ; Sun, 25 Jan 2004 17:00:46 +0100 Message-ID: <4013E7E9.12F9D87A@zurich.ibm.com> Date: Sun, 25 Jan 2004 16:59:37 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Subject: [Fwd: I-D ACTION:draft-nikander-multi6-hip-00.txt] Content-Type: multipart/mixed; boundary="------------95B5344FCE0321545B41A12B" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------95B5344FCE0321545B41A12B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-nikander-multi6-hip-00.txt Date: Fri, 23 Jan 2004 15:59:31 -0500 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : draft-nikander-multi6-hip-00 Author(s) : P. Nikander Filename : draft-nikander-multi6-hip-00.txt Pages : 28 Date : 2004-1-23 The Host Identity Protocol implements the identifier locator separation by introduing a new name space and a new layer to the IP stack. The new structure insulates the transport layer protocols from the internetworking layer, thereby allowing transport sessions to remain unaffected even if the underlying IP addresses change. That, in turn, seems to make it easier to solve the so called site multi-homing problem than without introducing such an indirection layer. This document discusses how the proposed HIP mobility and multi-homing solution, described separately, would fit to the IETF multi6 working group requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nikander-multi6-hip-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nikander-multi6-hip-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------95B5344FCE0321545B41A12B Content-Type: Message/External-body; name="draft-nikander-multi6-hip-00.txt" Content-Disposition: inline; filename="draft-nikander-multi6-hip-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-1-23161827.I-D@ietf.org> --------------95B5344FCE0321545B41A12B-- From owner-multi6@ops.ietf.org Sun Jan 25 17:45:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20458 for ; Sun, 25 Jan 2004 17:45:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkszI-0008FS-PL for multi6-data@psg.com; Sun, 25 Jan 2004 22:44:16 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aksz3-0008D3-0X for multi6@ops.ietf.org; Sun, 25 Jan 2004 22:44:03 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jan 2004 14:43:06 -0800 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 25 Jan 2004 14:43:33 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jan 2004 14:43:17 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 25 Jan 2004 14:43:34 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 25 Jan 2004 14:43:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7150.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt) Date: Sun, 25 Jan 2004 14:43:14 -0800 Message-ID: Thread-Topic: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt) thread-index: AcPjOFeBGDtIMQseS4apVgVLrAneugAAG/P2ABaR5UA= From: "Christian Huitema" To: "Ayyasamy, Senthilkumar \(UMKC-Student\)" , , "Noel Chiappa" , X-OriginalArrivalTime: 25 Jan 2004 22:43:15.0966 (UTC) FILETIME=[9F0DE9E0:01C3E394] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > Probably locators will be hardcoded in less places than today, so they > will > > be simpler to renumber and IDs will be hardcoded in some of the places > that > > ip are used today and perhaps in many others, since they will be used > for > > recognizing endpoints in apps and filters, acls and so on >=20 > If so,it's good. But, for example, SIP hardcodes locators instead of DNS > names. As per discussions in ietf-aulli, apps folks attributes it to lack > of access to naming service and reduced delay (in terms of lookup > latency.) > So, in future, we can expect more such locator hardcoding at ULP. It is not exactly "hardcoding". SIP payloads carry the IP addresses to be used for initiating media sessions, but the protocol also has provisions for changing these addresses if the SIP agent's location happens to change. It is much easier to move a session to a new location by telling the peer about the new location than by updating a name service and hoping that the peer will find out. It is also much more in line with end-to-end argument. In any case, there is more than performance at stake. We must also to consider privacy. A SIP agent will only reveal its current location to the peers with whom it agrees to establish a session. This is very different from publishing a mapping between identifier and location in a globally accessible name service. Not to say that SIP has got everything right. The payload format only allows for one IP address per media stream, which is problematic when the host is multi-homed or multi-addressed.=20 -- Christian Huitema From owner-multi6@ops.ietf.org Sun Jan 25 18:05:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21213 for ; Sun, 25 Jan 2004 18:05:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AktJ0-000AtG-JO for multi6-data@psg.com; Sun, 25 Jan 2004 23:04:38 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AktIo-000Apz-0T for multi6@ops.ietf.org; Sun, 25 Jan 2004 23:04:26 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0PN4s2g046593; Mon, 26 Jan 2004 00:04:54 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B0110824F@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B0110824F@KC-MAIL4.kc.umkc.edu> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: threats ID Date: Mon, 26 Jan 2004 00:04:30 +0100 To: "Ayyasamy, Senthilkumar \(UMKC-Student\)" X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 25-jan-04, at 11:10, Ayyasamy, Senthilkumar ((UMKC-Student)) wrote: > Also,if FQDNs can handle referral task, Not really, as a single FQDN can map to more than one host and the reference may need to point to one of them rather than the group. > NAT can be extended to provide a scalable site-multihoming solution Yeah right. I'll believe it when 1000000000 people are running this and it turns out to 1. work and 2. be scalable. > ( Paul Francis IPNL is an example.) Reference? From owner-multi6@ops.ietf.org Sun Jan 25 19:01:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23912 for ; Sun, 25 Jan 2004 19:01:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aku9r-000EsN-Lr for multi6-data@psg.com; Sun, 25 Jan 2004 23:59:15 +0000 Received: from [134.193.143.167] (helo=kc-msxproto1.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aku9f-000EqF-0k for multi6@ops.ietf.org; Sun, 25 Jan 2004 23:59:03 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jan 2004 17:59:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt) Date: Sun, 25 Jan 2004 17:59:01 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108256@KC-MAIL4.kc.umkc.edu> Thread-Topic: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt) Thread-Index: AcPjOFeBGDtIMQseS4apVgVLrAneugAAG/P2ABaR5UAAAOjtBA== From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Christian Huitema" , , "Noel Chiappa" , X-OriginalArrivalTime: 25 Jan 2004 23:59:02.0142 (UTC) FILETIME=[34C951E0:01C3E39F] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 >It is not exactly "hardcoding". SIP payloads carry the IP addresses to >be used for initiating media sessions, but the protocol also has >provisions for changing these addresses if the SIP agent's location >happens to change. It is much easier to move a session to a new = location >by telling the peer about the new location than by updating a name >service and hoping that the peer will find out.=20 =20 But, the bottleneck is shifted to STUN/Teredo servers instead of name servers (with the caveat that it doesn't allow all types of=20 traversal through NAT. esp TCP.) >In any case, there is more than performance at stake. We must also to >consider privacy. A SIP agent will only reveal its current location to >the peers with whom it agrees to establish a session. This is very >different from publishing a mapping between identifier and location in = a >globally accessible name service. =20 we can still maintain privacy in such a global mapping service. It=20 depends on the design of the id/loc mapping service (but it depends on the type of identifier; HIT/HIP can provide anonymity.) Also, privacy can further be enhanced by having a stack of identifiers=20 to route packets. In any case, a HIP related RG will concentrate on these issues. =20 But, I would very much like the id/loc mapping to mirror SIP=20 like design; rather than new overlay infrastrcuture (DHT seems costly from a management perspective.) >Not to say that SIP has got everything right. The payload format only >allows for one IP address per media stream, which is problematic when >the host is multi-homed or multi-addressed. =20 so, we need a new SDP description? From owner-multi6@ops.ietf.org Sun Jan 25 19:11:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24367 for ; Sun, 25 Jan 2004 19:11:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkuLD-000FoZ-3V for multi6-data@psg.com; Mon, 26 Jan 2004 00:10:59 +0000 Received: from [134.193.143.167] (helo=kc-msxproto1.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkuL0-000FnU-U2 for multi6@ops.ietf.org; Mon, 26 Jan 2004 00:10:47 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jan 2004 18:10:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: threats ID Date: Sun, 25 Jan 2004 18:10:45 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108257@KC-MAIL4.kc.umkc.edu> Thread-Topic: threats ID Thread-Index: AcPjl5dZTIfaSeetSkWi6cbLGZsnhwAB7mwZ From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Iljitsch van Beijnum" Cc: "Multi6 List" X-OriginalArrivalTime: 26 Jan 2004 00:10:46.0296 (UTC) FILETIME=[D87EB180:01C3E3A0] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >> NAT can be extended to provide a scalable site-multihoming solution > >Yeah right. I'll believe it when 1000000000 people are running this and = =20 so, you mean, this is true for IPv6?=20 >it turns out to 1. work and 2. be scalable.=20 >> ( Paul Francis IPNL is an example.) >=20 > Reference? =20 P. Francis and R. Gummadi=20 IPNL: A NAT-Extended Internet Architecture=20 ACM SIGCOMM 2001 http://www.acm.org/sigcomm/sigcomm2001/p6.html =20 =20 =20 =20 From owner-multi6@ops.ietf.org Sun Jan 25 19:43:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25353 for ; Sun, 25 Jan 2004 19:43:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Akupr-000I2v-Gc for multi6-data@psg.com; Mon, 26 Jan 2004 00:42:39 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Akupf-000I29-K4 for multi6@ops.ietf.org; Mon, 26 Jan 2004 00:42:27 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 25 Jan 2004 16:47:25 +0000 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0Q0gONM023850; Sun, 25 Jan 2004 16:42:24 -0800 (PST) Received: from cisco.com (sjc-vpn1-609.cisco.com [10.21.98.97]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA29128; Sun, 25 Jan 2004 16:42:24 -0800 (PST) Message-ID: <40146270.3090800@cisco.com> Date: Sun, 25 Jan 2004 16:42:24 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: "Ayyasamy, Senthilkumar \(UMKC-Student\)" , mbagnulo@ing.uc3m.es, Noel Chiappa , multi6@ops.ietf.org Subject: Re: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian, How does SIP differ conceptually at the application layer from what MIPv6 does at the IP layer? Eliot From owner-multi6@ops.ietf.org Sun Jan 25 20:24:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28829 for ; Sun, 25 Jan 2004 20:24:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkvTE-000KgB-DO for multi6-data@psg.com; Mon, 26 Jan 2004 01:23:20 +0000 Received: from [134.193.143.167] (helo=kc-msxproto1.kc.umkc.edu) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkvT2-000Ke3-33 for multi6@ops.ietf.org; Mon, 26 Jan 2004 01:23:08 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jan 2004 19:23:07 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt) Date: Sun, 25 Jan 2004 19:23:06 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108258@KC-MAIL4.kc.umkc.edu> Thread-Topic: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt) Thread-Index: AcPjpUnByUU4Zi4lTmaro0JDPbzeGgAA+tO6 From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Eliot Lear" , "Christian Huitema" Cc: , "Noel Chiappa" , X-OriginalArrivalTime: 26 Jan 2004 01:23:07.0404 (UTC) FILETIME=[F3FF34C0:01C3E3AA] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Christian, =20 I am not christian ;-) =20 > How does SIP differ conceptually at the application=20 > layer from what MIPv6 does at the IP layer? =20 SIP, not just provides terminal mobility like MIP,=20 but also session and service mobility. then, it=20 also supports presence etc. In terms of terminal=20 mobility,MIP is better when compared to SIP ( as=20 SIP targets IP telephony and not suitable for=20 TCP-based applications.) From owner-multi6@ops.ietf.org Sun Jan 25 20:57:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29722 for ; Sun, 25 Jan 2004 20:57:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkvzE-000N8Q-Fn for multi6-data@psg.com; Mon, 26 Jan 2004 01:56:24 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Akvz1-000N7l-Qh for multi6@ops.ietf.org; Mon, 26 Jan 2004 01:56:11 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jan 2004 17:56:24 -0800 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 25 Jan 2004 17:56:11 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 25 Jan 2004 17:56:21 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 25 Jan 2004 17:56:09 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 25 Jan 2004 17:56:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7150.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt) Date: Sun, 25 Jan 2004 17:54:58 -0800 Message-ID: Thread-Topic: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt) thread-index: AcPjpTgDNP5jRq0kQR+06iCadM5IKQACFs9A From: "Christian Huitema" To: "Eliot Lear" Cc: X-OriginalArrivalTime: 26 Jan 2004 01:56:08.0575 (UTC) FILETIME=[90DDE8F0:01C3E3AF] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Christian, >=20 > How does SIP differ conceptually at the application layer from what > MIPv6 does at the IP layer? >=20 > Eliot SIP separates signaling from media transmission. I will invite you to a session, the signaling traffic will pass through the system of SIP servers, but the media should flow directly between the two "end points". In contrast, MIPV6 handles just one kind of traffic; packets may flow directly between the current locations, or it may remain "non optimized" and flow through the home agents. SIP separates the logical identity from the media endpoints. It is perfectly reasonable to have a session between two logical identities, say Alice and Bob, but to have the media flow between different pairs of cameras and screens, mikes and speakers, etc. The choice of the media endpoint is based on the application, e.g. choose between headset on my mobile phone and loud speakers on my stereo. In contrast, MIPv6 assumes that the COA is 'equivalent' to the HA, and that any choice is based purely on connectivity considerations. SIP includes an explicit negotiation of the session parameters. The negotiation is mostly based on the capacities of the end points, such as the medias and codecs supported by the end point, but it may also take into account transmission issues, e.g. what is the available bandwidth. In contrast, MIPV6 does not perform any such negotiation. -- Christian Huitema From owner-multi6@ops.ietf.org Mon Jan 26 04:57:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27487 for ; Mon, 26 Jan 2004 04:57:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al3SN-000Nvz-Tf for multi6-data@psg.com; Mon, 26 Jan 2004 09:54:59 +0000 Received: from [195.212.29.156] (helo=mtagate7.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al3SA-000Nuu-NR for multi6@ops.ietf.org; Mon, 26 Jan 2004 09:54:46 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0Q9s5Rm074890; Mon, 26 Jan 2004 09:54:05 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0Q9s2NJ235710; Mon, 26 Jan 2004 10:54:03 +0100 Received: from zurich.ibm.com (dhcp222-22.zurich.ibm.com [9.4.222.22]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA38056; Mon, 26 Jan 2004 10:54:00 +0100 Message-ID: <4014D27B.C9047107@zurich.ibm.com> Date: Mon, 26 Jan 2004 09:40:27 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Masataka Ohta CC: "Ayyasamy, Senthilkumar (UMKC-Student)" , Tim Shepard , Multi6 List Subject: Re: threats ID References: <5EF7D95E17BDAD4A968C812E5ABC390B01108250@KC-MAIL4.kc.umkc.edu> <40139BC8.6000408@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Can everybody please close this thread, because it is not advancing our WG's business? Thanks Brian Masataka Ohta wrote: > > Ayyasamy, Senthilkumar; > > >>>So in some meaningful sense, IPSEC is above the IP layer, > >>>even if there is a document telling us that we're not supposed to > >>>think about it that way. > >> > >>Hugh? Your point was not technical but lack of IETF consensus. > > > ok. > > So, you are wrong, completely. > > > Can you provide a citation (RFC) which illustrates your > > statement: > > > > > There is no such thing as layer 3.5. > > > Network layer solutions are at layer 3, > > > transport layer solutions are at layer 4. > > > PERIOD > > You should ask it Brian, because he said 3.5 first. > > But, I recommend you do it privately. No carbon copying to me > is necessary. > > > As another example, transport advertises that it is ECN enabled > > but congestion notification is given by the routers at network > > level. > > That's perfectly fine layering. > > Are you saying so, or are you saying you are not sure? > > Masataka Ohta -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Mon Jan 26 04:57:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27543 for ; Mon, 26 Jan 2004 04:57:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al3SA-000Nuv-6l for multi6-data@psg.com; Mon, 26 Jan 2004 09:54:46 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al3Rw-000Ntc-OY for multi6@ops.ietf.org; Mon, 26 Jan 2004 09:54:32 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0Q9s2pS136448; Mon, 26 Jan 2004 09:54:02 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0Q9s1NJ242966; Mon, 26 Jan 2004 10:54:01 +0100 Received: from zurich.ibm.com (dhcp222-22.zurich.ibm.com [9.4.222.22]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA38054; Mon, 26 Jan 2004 10:53:58 +0100 Message-ID: <4014D100.1199B19@zurich.ibm.com> Date: Mon, 26 Jan 2004 09:34: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: john.loughney@nokia.com CC: kurtis@kurtis.pp.se, multi6@ops.ietf.org, jim.bound@hp.com Subject: Re: Reminder re multi6 drafts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Go for it. I think something this week will be useful. Thanks Brian john.loughney@nokia.com wrote: > > Hi Kurt, > > > To echo Brian. If someone could at least write up an email to > > the list, > > I think is a good starting point. But again, there is only > > 24h a day... > > I helped Lode on the SCTP multihoming draft. I think I know enough > of what is going on to write something up. I wasn't planning > on doing this, but I could take a stab. If I submit it by Friday, > would that be OK? If anyone else wants to help out on this, > I'd be more than happy. If someone else has planned to take care > of this already, than it is no problem - but I could provide input > if input is needed. > > thanks, > John -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Mon Jan 26 05:25:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29415 for ; Mon, 26 Jan 2004 05:25:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al3tp-0000My-Pl for multi6-data@psg.com; Mon, 26 Jan 2004 10:23:21 +0000 Received: from [194.78.143.102] (helo=hrtades9.atea.be) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al3tc-0000M7-O7 for multi6@ops.ietf.org; Mon, 26 Jan 2004 10:23:08 +0000 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id Z1WT2R8F; Mon, 26 Jan 2004 11:23:07 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Jan 2004 11:23:07 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195A7F495@hrtades7.atea.be> From: Coene Lode To: "'Brian E Carpenter'" , john.loughney@nokia.com Cc: kurtis@kurtis.pp.se, multi6@ops.ietf.org, jim.bound@hp.com Subject: RE: Reminder re multi6 drafts Date: Mon, 26 Jan 2004 11:23:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Sorry fir the fuss... Had some mail address trouble... John: I am busy doing a draft concerning SCTP with answers to the questions posed in Elliot Lears draft. I'll send it to you by Wednesday, so we'll be able to send it out on Friday.... Concerning the SCTP over HIP/NOID/..whatever.., that is a completely different ballgame... And I'll first talk with folks concerned what is truly meant by this. I've got a nagging feeling that we not talking about the same thing here... Yours sincerely, Lode -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com] Sent: maandag 26 januari 2004 9:34 To: john.loughney@nokia.com Cc: kurtis@kurtis.pp.se; multi6@ops.ietf.org; jim.bound@hp.com Subject: Re: Reminder re multi6 drafts Go for it. I think something this week will be useful. Thanks Brian john.loughney@nokia.com wrote: > > Hi Kurt, > > > To echo Brian. If someone could at least write up an email to > > the list, > > I think is a good starting point. But again, there is only > > 24h a day... > > I helped Lode on the SCTP multihoming draft. I think I know enough > of what is going on to write something up. I wasn't planning > on doing this, but I could take a stab. If I submit it by Friday, > would that be OK? If anyone else wants to help out on this, > I'd be more than happy. If someone else has planned to take care > of this already, than it is no problem - but I could provide input > if input is needed. > > thanks, > John -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM From owner-multi6@ops.ietf.org Mon Jan 26 05:29:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29476 for ; Mon, 26 Jan 2004 05:29:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al3ya-0000pg-A7 for multi6-data@psg.com; Mon, 26 Jan 2004 10:28:16 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al3yO-0000ok-2t for multi6@ops.ietf.org; Mon, 26 Jan 2004 10:28:04 +0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0QAS2Y22334 for ; Mon, 26 Jan 2004 12:28:02 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 26 Jan 2004 12:28:02 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 12:28:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Reminder re multi6 drafts Date: Mon, 26 Jan 2004 12:27:12 +0200 Message-ID: Thread-Topic: Reminder re multi6 drafts Thread-Index: AcPj9mwcABjTEN+qTSG0F1CmS86GWwAADThw From: To: , Cc: , , X-OriginalArrivalTime: 26 Jan 2004 10:28:02.0138 (UTC) FILETIME=[1393B3A0:01C3E3F7] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Lode, > Sorry fir the fuss... Had some mail address trouble... >=20 > John: > I am busy doing a draft concerning SCTP with answers to the=20 > questions posed in Elliot Lears draft. I'll send it to you by=20 > Wednesday, so we'll be able to send it out on Friday.... Sounds good. I think we should talk about SCTP (including=20 PR-SCTP & SCTP+Add IP) and its applicability for solving multihoming. We should explain how SCTP can provide multihoming for protocols running on top of SCTP and we should also discuss the limitation of SCTP, for example, not supporting applications running over UDP, etc. =20 > Concerning the SCTP over HIP/NOID/..whatever.., that is a completely > different ballgame... And I'll first talk with folks concerned what is = > truly meant by this. I've got a nagging feeling that we not talking=20 > about the same thing here... My feeling is that this is orthoganal to the draft at hand. Don't worry about HIP/NOID/etc. thanks, John From owner-multi6@ops.ietf.org Mon Jan 26 06:46:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03329 for ; Mon, 26 Jan 2004 06:46:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al5AN-0006qy-87 for multi6-data@psg.com; Mon, 26 Jan 2004 11:44:31 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Al5AB-0006py-20 for multi6@ops.ietf.org; Mon, 26 Jan 2004 11:44:19 +0000 Received: (qmail 951 invoked from network); 26 Jan 2004 11:55:11 -0000 Received: from h219-110-032-093.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.93) by necom830.hpcl.titech.ac.jp with SMTP; 26 Jan 2004 11:55:11 -0000 Message-ID: <4014FDD7.90301@necom830.hpcl.titech.ac.jp> Date: Mon, 26 Jan 2004 20:45:27 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: john.loughney@nokia.com, kurtis@kurtis.pp.se, multi6@ops.ietf.org, jim.bound@hp.com Subject: Re: Reminder re multi6 drafts References: <4014D100.1199B19@zurich.ibm.com> In-Reply-To: <4014D100.1199B19@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: Brian; > Go for it. I think something this week will be useful. No, I don't think so. Masataka Ohta From owner-multi6@ops.ietf.org Mon Jan 26 08:55:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06071 for ; Mon, 26 Jan 2004 08:55:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al7AG-000JX8-M0 for multi6-data@psg.com; Mon, 26 Jan 2004 13:52:32 +0000 Received: from [195.212.29.156] (helo=mtagate7.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al7A3-000JWZ-FH for multi6@ops.ietf.org; Mon, 26 Jan 2004 13:52:19 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0QDqHRm134412 for ; Mon, 26 Jan 2004 13:52:17 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0QDqH44261560 for ; Mon, 26 Jan 2004 14:52:17 +0100 Received: from zurich.ibm.com (dhcp21-96.zurich.ibm.com [9.4.21.96]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA50312 for ; Mon, 26 Jan 2004 14:52:15 +0100 Message-ID: <40151B48.FAA884@zurich.ibm.com> Date: Mon, 26 Jan 2004 14:51:04 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: PReserving ids when changing providers (was:RE: to be draft-ohta-multi6-8plus8-00.txt) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: ... > SIP payloads carry the IP addresses to > be used for initiating media sessions, I note that with an mh solution within the network layer (such as NOID) this would work just fine. > , but the protocol also has > provisions for changing these addresses if the SIP agent's location > happens to change. and this sounds as if it would work just fine with an mh solution requiring the transport layer to be aware of multiple addresses. Brian From owner-multi6@ops.ietf.org Mon Jan 26 12:04:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12989 for ; Mon, 26 Jan 2004 12:04:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlA7h-000ESk-4r for multi6-data@psg.com; Mon, 26 Jan 2004 17:02:05 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlA7M-000EQS-LN for multi6@ops.ietf.org; Mon, 26 Jan 2004 17:01:44 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9DEF276DA for ; Mon, 26 Jan 2004 18:01:43 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 80A917642 for ; Mon, 26 Jan 2004 18:01:43 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: Subject: Host Centric Multi-Homing Date: Mon, 26 Jan 2004 17:53:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, We would like to submit this new version of the Host Centric Multi-Homing draft for the WG consideration http://www.it.uc3m.es/marcelo/draft-huitema-multi6-hosts-02.txt Coments are welcome, Tahnks, marcelo From owner-multi6@ops.ietf.org Mon Jan 26 13:19:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14889 for ; Mon, 26 Jan 2004 13:19:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlBIN-000MOo-Lh for multi6-data@psg.com; Mon, 26 Jan 2004 18:17:11 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlBI8-000MNV-Pz for multi6@ops.ietf.org; Mon, 26 Jan 2004 18:16:56 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0QIHO6R062141 for ; Mon, 26 Jan 2004 19:17:24 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 List From: Iljitsch van Beijnum Subject: Layer 3.5 considered useful Date: Mon, 26 Jan 2004 19:16:54 +0100 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [About the "layer 3.5": yes, this is arbitrary and not exactly well-defined. But to the extend that just 9 characters bring to mind the concept of something sitting between IP and the protocols that provide transport functionality, it is a very useful term.] If we consider transport protocols such as TCP (UDP being a special case as it provides almost none of the functionality traditionally associated with transport protocols) it is fairly obvious that each transport session lives in a universe of its own, with little or no regard for the possible existence of other sessions. In many cases, this isn't a good thing. For example, even to this day most HTTP interaction happens over a large number of concurrent TCP sessions, rather than over a single session. Another problem comes up when a single host "reflects" some data over a somewhat large number of TCP sessions, which can lead to catastrophic momentary congestion caused synchronization of the TCP session slow start state. Then there is multiaddress multihoming. The simplest way to do this would be to associate the multihoming state with a pair of source and destination addresses. This isn't satisfactory because it can lead to fairly serious security problems. Similar risks make it necessary to have a good deal of negotiation between the two hosts involved, something that would be problematic if it had to be done for each individual TCP session used to retrieve a web page and the pictures embeded init. These considerations alone make a layer that sits between IP on one side and TCP and similar protocols on the other side: such a new layer would make it possible to aggregate individual sessions to a comfortable level somewhere between the TCP view where every session is unique and independent, and IP where only the destination address counts. Another good reason to introduce a new layer is that it allows continued use of both unmodified TCP and other transport protocols and even UDP, and unmodified IP. However, we probably do want to change TCP (or switch to something different, such as SCTP) at some point in the future. So we should avoid painting ourselves into a corner by focussing on supporting unmodified upper layer protocols exclusively. In this regard it makes sense to analyze proposals that boil down to introducing a "layer 3.5" and see what functionality can be accomplished on one end (ie, one end has the new layer and unmodified TCP, the other also the new layer but a new TCP that is aware of the layer 3.5 functions and wants to have a say in how these functions are perfomed) and which require cooperation between both ends. Functions that can be performed on one end should NOT be a layer. So our new layer 3.5 would consists of mechanisms that work end-to-end and it would have a private interface that provides hooks to future versions of transport protocols. That would be useful. From owner-multi6@ops.ietf.org Mon Jan 26 16:06:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20300 for ; Mon, 26 Jan 2004 16:06:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlDuL-000FuX-9m for multi6-data@psg.com; Mon, 26 Jan 2004 21:04:33 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlDu4-000Fst-0U for multi6@ops.ietf.org; Mon, 26 Jan 2004 21:04:16 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0QL4DJX096842; Mon, 26 Jan 2004 21:04:13 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0QL4DNJ213962; Mon, 26 Jan 2004 22:04:13 +0100 Received: from zurich.ibm.com (sig-9-145-240-215.de.ibm.com [9.145.240.215]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA31034; Mon, 26 Jan 2004 22:04:08 +0100 Message-ID: <40155728.41CF119F@zurich.ibm.com> Date: Mon, 26 Jan 2004 19:06:32 +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: Coene Lode CC: multi6@ops.ietf.org Subject: Comment on draft-coene-sctp-multihome-04.txt References: <57FD2C3A246F76438CA6FDAD8FE9F195A7F495@hrtades7.atea.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Lode, You state that: > Under the assumption that every IP address will have a different, > seperate path towards the remote endpoint, (this is the > responsibility of the routing protocols or of manual configuration) > , if the transport to one of the IP addresses (= 1 particular path) > fails then the traffic can migrate to the other remaining IP address > (= other paths) within the SCTP association. Now in the original context that SCTP was designed for, you might have that much control over the routing environment. But it seems to be a very dangerous assumption for the general case of two systems communicating over the whole Internet. I actually think this points to an important component of any solution that we haven't really talked about much, except when NAROS was discussed a few months ago - how does one determine the existence or absence of connectivity between two locators? For SCTP or any other solution, it's only when connectivity exists between an address pair that they are any use. By the way, you also say > > As a practical matter, it is recommended that IP addresses in a > multihomed endpoint be assigned IP endpoints from different TLA's to > ensure against network failure. The term "TLA" no longer exists in IPv6 and in any case, it is a false assumption that two different high-order network prefixes imply two different paths. They might, but they might not. Brian From owner-multi6@ops.ietf.org Mon Jan 26 17:28:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22146 for ; Mon, 26 Jan 2004 17:28:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlFBj-000Pyg-Ko for multi6-data@psg.com; Mon, 26 Jan 2004 22:26:35 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AlFBW-000PxX-GZ for multi6@ops.ietf.org; Mon, 26 Jan 2004 22:26:22 +0000 Received: (qmail 3547 invoked from network); 26 Jan 2004 22:37:23 -0000 Received: from h219-110-032-093.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.93) by necom830.hpcl.titech.ac.jp with SMTP; 26 Jan 2004 22:37:23 -0000 Message-ID: <40159453.6030406@necom830.hpcl.titech.ac.jp> Date: Tue, 27 Jan 2004 07:27:31 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 List Subject: Layer 3.5 is actually layer 4 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; The fallacy of layer 3.5 is introduced to assert that layer 3 solutions had existed, which is why Brian wrote a sweeping definition: > We can hardly disagree. But TCP is not SCTP, UDP, DCCP or ICMP either. > The systems level argument for a layer 3.5 solution is that it can cover > all cases, including ones we have not invented yet. As you modify Brian's definition of layer 3.5 that: UDP being a special case there will be other special cases for non-TCP protocols including ones we have not invented yet that there is no reason to insist on the fallacy. So, your reduced requirement is merely that: The systems level argument for a layer 3.5 solution is that it can cover a TCP case. which is a TCP specific layer 4 solution. That is, there is no such thing as layer 3 solutions. Note that layer 4 protocols can and will share some function calls to control M6, just as TCP and UDP can share a function call to compute check sum that it is an issue independent of layering. We don't have to make transport layer check summing layer 3.5, only to let TCP and UDP share some function calls. Masataka Ohta From owner-multi6@ops.ietf.org Mon Jan 26 17:46:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22515 for ; Mon, 26 Jan 2004 17:46:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlFUN-0002QV-IG for multi6-data@psg.com; Mon, 26 Jan 2004 22:45:51 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlFU9-0002O9-TF for multi6@ops.ietf.org; Mon, 26 Jan 2004 22:45:38 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0QMk06R065708; Mon, 26 Jan 2004 23:46:01 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <40159453.6030406@necom830.hpcl.titech.ac.jp> References: <40159453.6030406@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5863CE26-5051-11D8-9B69-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Layer 3.5 is actually layer 4 Date: Mon, 26 Jan 2004 23:45:31 +0100 To: Masataka Ohta X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 26-jan-04, at 23:27, Masataka Ohta wrote: > UDP being a special case > there will be other special cases for non-TCP protocols including > ones we have not invented yet UDP is a special case because it doesn't provide reliability or congestion control. There is no reason why UDP should necessarily be a special case for multihoming. The only reason to make it a special case would be because UDP interactions are often very short-lived. And yes, there will always be special cases, the world is a complex place. > that there is no reason to insist on the fallacy. Which fallacy? > So, your reduced requirement is merely that: > The systems level argument for a layer 3.5 solution is > that it can cover a TCP case. > which is a TCP specific layer 4 solution. I don't see any reason why a solution that sits between IP and upper layers couldn't work with all upper layers, first and foremost TCP, but also UDP and the real-time protocols built on top of UDP. > Note that layer 4 protocols can and will share some function > calls to control M6, just as TCP and UDP can share a function > call to compute check sum that it is an issue independent of > layering. We don't have to make transport layer check summing > layer 3.5, only to let TCP and UDP share some function calls. If you prefer to look at it this way, I have no problem with that. Different people have different outlooks. One man's waves are another man's particles... Iljitsch From owner-multi6@ops.ietf.org Mon Jan 26 18:09:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23697 for ; Mon, 26 Jan 2004 18:09:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlFqY-0005DZ-42 for multi6-data@psg.com; Mon, 26 Jan 2004 23:08:46 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AlFqA-00057A-RD for multi6@ops.ietf.org; Mon, 26 Jan 2004 23:08:23 +0000 Received: (qmail 3709 invoked from network); 26 Jan 2004 23:19:24 -0000 Received: from h219-110-032-093.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.93) by necom830.hpcl.titech.ac.jp with SMTP; 26 Jan 2004 23:19:24 -0000 Message-ID: <40159E2B.2050007@necom830.hpcl.titech.ac.jp> Date: Tue, 27 Jan 2004 08:09:31 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 List Subject: Re: Layer 3.5 is actually layer 4 References: <40159453.6030406@necom830.hpcl.titech.ac.jp> <5863CE26-5051-11D8-9B69-000A95CD987A@muada.com> In-Reply-To: <5863CE26-5051-11D8-9B69-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; > And yes, there will always be special cases, the world is a complex place. > >> that there is no reason to insist on the fallacy. > Which fallacy? Layer 3.5 with the definition of: it can cover all cases, including ones we have not invented yet. >> So, your reduced requirement is merely that: > > >> The systems level argument for a layer 3.5 solution is >> that it can cover a TCP case. >> which is a TCP specific layer 4 solution. > I don't see any reason why a solution that sits between IP and upper > layers couldn't work with all upper layers, first and foremost TCP, but > also UDP and the real-time protocols built on top of UDP. You are confusing layering of protocols and structure of implementations. See below. >> Note that layer 4 protocols can and will share some function >> calls to control M6, just as TCP and UDP can share a function >> call to compute check sum that it is an issue independent of >> layering. We don't have to make transport layer check summing >> layer 3.5, only to let TCP and UDP share some function calls. > If you prefer to look at it this way, I have no problem with that. > Different people have different outlooks. One man's waves are another > man's particles... TO enlighten you, quantums are neither waves nor particles but are distributions. It is not a problem of outlook. That some implementation share some function calls does not mean others must also share them. That you have some function calls in some layer 4 but not in others means that the functionality is at layer 4. Masataka Ohta From owner-multi6@ops.ietf.org Mon Jan 26 19:40:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26609 for ; Mon, 26 Jan 2004 19:40:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlHFR-000GMM-P9 for multi6-data@psg.com; Tue, 27 Jan 2004 00:38:33 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlHEw-000GHR-OA for multi6@ops.ietf.org; Tue, 27 Jan 2004 00:38:02 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jan 2004 16:38:01 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Jan 2004 16:38:01 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jan 2004 16:37:55 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 26 Jan 2004 16:37:59 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 26 Jan 2004 16:38:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7150.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Layer 3.5 is actually layer 4 Date: Mon, 26 Jan 2004 16:37:57 -0800 Message-ID: Thread-Topic: Layer 3.5 is actually layer 4 thread-index: AcPkXvVur4SndLcGRRm7HwXoDTS2FwADlGCQ From: "Christian Huitema" To: "Iljitsch van Beijnum" , "Masataka Ohta" Cc: "Multi6 List" X-OriginalArrivalTime: 27 Jan 2004 00:38:01.0602 (UTC) FILETIME=[D1A05620:01C3E46D] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > UDP being a special case > > there will be other special cases for non-TCP protocols including > > ones we have not invented yet >=20 > UDP is a special case because it doesn't provide reliability or > congestion control. There is no reason why UDP should necessarily be a > special case for multihoming. The only reason to make it a special case > would be because UDP interactions are often very short-lived. Thinking of UDP as a transport protocol is misleading. UDP is not really a transport protocol, it is a pass-through. It only performs one of the classic TP functions: multiplexing. The idea is to provide the application with a "raw" service from the network. Transport functions such as reliability are commonly provided as part of the application, or a layer inside the application (e.g. RPC, RTP). In a multi-homed environment, the application will also handle multi-homing. -- Christian Huitema=20 From owner-multi6@ops.ietf.org Mon Jan 26 20:02:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27142 for ; Mon, 26 Jan 2004 20:02:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlHcD-000J0u-JM for multi6-data@psg.com; Tue, 27 Jan 2004 01:02:05 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AlHc0-000Izf-W2 for multi6@ops.ietf.org; Tue, 27 Jan 2004 01:01:53 +0000 Received: (qmail 4206 invoked from network); 27 Jan 2004 01:12:56 -0000 Received: from h219-110-032-093.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.93) by necom830.hpcl.titech.ac.jp with SMTP; 27 Jan 2004 01:12:56 -0000 Message-ID: <4015B8C5.4040308@necom830.hpcl.titech.ac.jp> Date: Tue, 27 Jan 2004 10:03:01 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Iljitsch van Beijnum , Multi6 List Subject: Re: Layer 3.5 is actually layer 4 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian; > Thinking of UDP as a transport protocol is misleading. UDP is not really > a transport protocol, it is a pass-through. It only performs one of the > classic TP functions: multiplexing. We can be fine to say UDP is a transport layer protocol to pass-through. OTOH, if you implement TCP in a way that kernel does multiplexing only and all the other TCP functionality (connection management, congention avoidance, retransmission and so on) is performed in user space, it is no different from UDP doing similar things in user space. So, we can also be fine to say TCP is a combination of a transport layer protocol to pass-through and an application layer protocol to do other things. Note that there are OSes where kernel and user spaces are not separated. That is, debate on what funcitonality is of transport and what else is of application is not meaningful, because the difference is internal implementation one not visible from the network. There can be a difference when the network support port number based QoS assurance, as is the case with networks with RSVP, where we can definitely say that the multiplexing functionality does belong to the transport layer. Anyway, that > In a multi-homed > environment, the application will also handle multi-homing. is enough to deny 3.5 fallacy and UDP is not the only special case. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 27 03:24:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24442 for ; Tue, 27 Jan 2004 03:24:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlOU6-000PGO-Du for multi6-data@psg.com; Tue, 27 Jan 2004 08:22:10 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlOTp-000PE3-MZ for multi6@ops.ietf.org; Tue, 27 Jan 2004 08:21:53 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0R8LDRT089418; Tue, 27 Jan 2004 08:21:13 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0R8LCEg242522; Tue, 27 Jan 2004 09:21:12 +0100 Received: from zurich.ibm.com (gsine10.us.sine.ibm.com [9.14.6.40]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id JAA42258; Tue, 27 Jan 2004 09:21:08 +0100 Message-ID: <40161F2D.3CB99C71@zurich.ibm.com> Date: Tue, 27 Jan 2004 09:19:57 +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: Masataka Ohta CC: Christian Huitema , Iljitsch van Beijnum , Multi6 List Subject: Re: Layer 3.5 is actually layer 4 References: <4015B8C5.4040308@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka, You have made your point repeatedly. Some people disagree with you, and at this point, more repeating will not change that. So could we please close this discussion? Of course, the architectural analysis to be developed in and following Seoul will have to take this discussion into account. Thanks Brian Masataka Ohta wrote: > > Christian; > > > Thinking of UDP as a transport protocol is misleading. UDP is not really > > a transport protocol, it is a pass-through. It only performs one of the > > classic TP functions: multiplexing. > > We can be fine to say UDP is a transport layer protocol to > pass-through. > > OTOH, if you implement TCP in a way that kernel does multiplexing > only and all the other TCP functionality (connection management, > congention avoidance, retransmission and so on) is performed in > user space, it is no different from UDP doing similar things in > user space. > > So, we can also be fine to say TCP is a combination of a transport > layer protocol to pass-through and an application layer protocol > to do other things. > > Note that there are OSes where kernel and user spaces are not > separated. > > That is, debate on what funcitonality is of transport and what > else is of application is not meaningful, because the difference > is internal implementation one not visible from the network. > > There can be a difference when the network support port number > based QoS assurance, as is the case with networks with RSVP, > where we can definitely say that the multiplexing functionality > does belong to the transport layer. > > Anyway, that > > > In a multi-homed > > environment, the application will also handle multi-homing. > > is enough to deny 3.5 fallacy and UDP is not the only special > case. > > Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 27 05:51:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28902 for ; Tue, 27 Jan 2004 05:51:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlQm1-000Ilg-3H for multi6-data@psg.com; Tue, 27 Jan 2004 10:48:49 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AlQlo-000IkK-Cz for multi6@ops.ietf.org; Tue, 27 Jan 2004 10:48:36 +0000 Received: (qmail 7803 invoked from network); 27 Jan 2004 10:59:44 -0000 Received: from h219-110-032-187.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.187) by necom830.hpcl.titech.ac.jp with SMTP; 27 Jan 2004 10:59:44 -0000 Message-ID: <4016424C.6010104@necom830.hpcl.titech.ac.jp> Date: Tue, 27 Jan 2004 19:49:48 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Christian Huitema , Iljitsch van Beijnum , Multi6 List Subject: Re: Layer 3.5 is actually layer 4 References: <4015B8C5.4040308@necom830.hpcl.titech.ac.jp> <40161F2D.3CB99C71@zurich.ibm.com> In-Reply-To: <40161F2D.3CB99C71@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > You have made your point repeatedly. Some people disagree with you, > and at this point, more repeating will not change that. So could > we please close this discussion? I repeat my point repeatedly and others are agreeing with me more and more that the discussion has almost converged. It should be noted that, during the discussion, no one have give any support for your sweeping statement that: The systems level argument for a layer 3.5 solution is that it can cover all cases, including ones we have not invented yet. So, it is simply that you withdraw your fallacy of layer 3.5 and the discussion is closed. To save bandwidth, you can do so silently by not responding this mail. > Of course, the architectural analysis to be developed in and > following Seoul will have to take this discussion into account. The architectural analysis is already developed by me before the WG was formed and we have seen any input not denied yet to change it. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 27 06:02:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29421 for ; Tue, 27 Jan 2004 06:02:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlQy9-000KZ5-Is for multi6-data@psg.com; Tue, 27 Jan 2004 11:01:21 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlQxw-000KWl-Kl for multi6@ops.ietf.org; Tue, 27 Jan 2004 11:01:08 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C3ACA828E; Tue, 27 Jan 2004 12:01:07 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id AD59B8281; Tue, 27 Jan 2004 12:01:07 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Brian E Carpenter" , "Coene Lode" Cc: Subject: RE: Comment on draft-coene-sctp-multihome-04.txt Date: Tue, 27 Jan 2004 11:53:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <40155728.41CF119F@zurich.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I actually think this points to an important component of any solution > that we haven't really talked about much, except when NAROS was discussed > a few months ago - how does one determine the existence or absence of > connectivity between two locators? Fully agree, this is complex and important. We have tried to discuss this point in the Host Centric draft There are two different scenarios IMHO. - how to discover reachability when initating a communication - how to discover reachability (or unreachability) during a communication (in order to preserve it) We have basically discused the first case in the draft. The second case have been discused some times in the ml, regarding some ideas like ULP hints, source address of incoming packets as a strong hint about which path is working and so on We wanted to also include such discussion in our draft but we couldn't make it on time, but it will probably be included in the next version. regards, marcelo For SCTP or any other solution, > it's only when connectivity exists between an address pair that they > are any use. > > By the way, you also say > > > > > As a practical matter, it is recommended that IP addresses in a > > multihomed endpoint be assigned IP endpoints from different TLA's to > > ensure against network failure. > > The term "TLA" no longer exists in IPv6 and in any case, it is a false > assumption that two different high-order network prefixes imply > two different paths. They might, but they might not. > > Brian > > From owner-multi6@ops.ietf.org Tue Jan 27 06:12:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29716 for ; Tue, 27 Jan 2004 06:12:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlR7i-000Leu-MD for multi6-data@psg.com; Tue, 27 Jan 2004 11:11:14 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlR7W-000LdV-BA for multi6@ops.ietf.org; Tue, 27 Jan 2004 11:11:02 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8DA39829C; Tue, 27 Jan 2004 12:11:01 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 7772B8296; Tue, 27 Jan 2004 12:11:01 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" , "Brian E Carpenter" Cc: "Multi6 List" Subject: RE: Layer 3.5 is actually layer 4 Date: Tue, 27 Jan 2004 12:03:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4016424C.6010104@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Masataka, > It should be noted that, during the discussion, no one have > give any support for your sweeping statement that: > > The systems level argument for a layer 3.5 solution is that > it can cover all cases, including ones we have not > invented yet. Just to state the obvious, I agree with this statement, and i guess that the authors of the several so called 3.5 layer solution do too (some of them have stated it clearly in some mails). > > So, it is simply that you withdraw your fallacy of layer 3.5 and > the discussion is closed. > > To save bandwidth, you can do so silently by not responding this > mail. Please do not assume that silence means that people agree with you, assume that people are just tired to continue endless discussions Regards, marcelo From owner-multi6@ops.ietf.org Tue Jan 27 06:13:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29758 for ; Tue, 27 Jan 2004 06:13:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlR8l-000Ljy-0d for multi6-data@psg.com; Tue, 27 Jan 2004 11:12:19 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlR8W-000Lhy-NQ for multi6@ops.ietf.org; Tue, 27 Jan 2004 11:12:04 +0000 Received: from descartes.info.ucl.ac.be (descartes [130.104.229.82]) by info.ucl.ac.be (8.12.10/8.12.8) with ESMTP id i0RBC379023257; Tue, 27 Jan 2004 12:12:03 +0100 (MET) Subject: Re: Host Centric Multi-Homing From: Cedric de Launois To: mbagnulo@ing.uc3m.es Cc: multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1075201611.899.2.camel@descartes> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 27 Jan 2004 12:06:51 +0100 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > We would like to submit this new version of the Host Centric Multi-Homing > draft for the WG consideration > > http://www.it.uc3m.es/marcelo/draft-huitema-multi6-hosts-02.txt > > Coments are welcome, Hi Marcelo, Thanks for the new draft ! Here are some comments : Section 3.3 Your example seems broken. You wrote : "To communicate with Y, X [...] will choose the source address [...] A:X" and then : "If the chosen exit router at Site X is RXB, the packet will flow freely" Substitute RXB by RXA ? Moreover, in your example, which address is used to contact Y : C:Y or D:Y ? I understand the problem but please, correct and/or clarify the example. Section 4 Three components interacts in the multiaddress multihoming problem : the source address, the ingress filters and the intradomain routing. Essentially, I would divide the solutions into three categories, depending on which component is adapted in order to solve the problem : a) Honor source address and routing, adapt filtering b) Honor source address and filtering, adapt routing c) Honor routing and filtering, adapt source address Your section 4.1 is equivalent to a). Your section 4.2 is equivalent to b) and section 4.3 to c), but I would move the "exit router discovery" procedure from c) to b). I explain : in this case, we don't adapt the source address. Instead, we use tunnels to force the routing system to convey the packet to where the host wants. That is : we adapt the routing and honor source address selection and filtering. Note that I'm not sure about the "exit router discovery" procedure being superior to the source address discovery. The use of tunnels reduces the MTU. While this is acceptable for e.g. particular QoS applications, we should not impose this mechanism for the general case. Section 4.4 The case described in this section appears to me as a special case of : c) Honor routing and filtering, adapt source address That is : we just adapt the source address on the fly, at the site exit router. 7. Proposed solution "In this section, we will present the recommended ways to solve the site exit issue and how to trigger rapid reactions to local failures." What do you mean by "local failures" ? Failures that occur inside the mh site ? Link failures between the mh site and an ISP ? Failure of an ISP of the mh site ? Section 7.1 Multihoming solution for big sites Only relaxing the source address check does not completely solve the IPv6 multihoming problem. Remember that to preserve scalability the site advertises prefix PA only to ISP A. If ISP A is down, we must prevent the use of prefix PA since BGP doesn't know that it can route packets with destination prefix PA to another ISP of the mh site, say ISP B. Thus we also need a mechanism for big sites to manage wich prefixes can be used and which cannot. 7.2.2.2.2 Reaction to other failures modes "the proposed mechanism to identify available paths will be based on the trial and error procedure." This is probably the base generic mechanism. All others mechanisms described (router renumbering, router advertisement, ...) only give hints about which prefix should be tried first. The base mechanism of trial and error is always needed, e.g. when a host doesn't get a response because the return path is broken somewhere in the Internet. So I suggest to present it as the base mechanism, and present others as optimizations. Section 8.1.2 What about outbound traffic engineering ? Even the simplest mh site might want to balance its traffic between e.g. its DSL and Wireless lines. Pure editorial notes : Section 8.1.3 "Performance enhancements can be obtained by appropriate development if destination address selection and source address selection algorithms." s/if/of/ Section 8.1.4 "The Policy table defined in [15] allows to preffer" s/preffer/prefer/ "the policy table allows to express the preffered exit path" s/preffered/preferred/ Thanks, Cedric From owner-multi6@ops.ietf.org Tue Jan 27 07:12:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01510 for ; Tue, 27 Jan 2004 07:12:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlS2f-0001TQ-C0 for multi6-data@psg.com; Tue, 27 Jan 2004 12:10:05 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AlS2R-0001SE-80 for multi6@ops.ietf.org; Tue, 27 Jan 2004 12:09:51 +0000 Received: (qmail 8412 invoked from network); 27 Jan 2004 12:21:02 -0000 Received: from h219-110-032-187.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.187) by necom830.hpcl.titech.ac.jp with SMTP; 27 Jan 2004 12:21:02 -0000 Message-ID: <4016555A.6050201@necom830.hpcl.titech.ac.jp> Date: Tue, 27 Jan 2004 21:11:06 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Brian E Carpenter , Multi6 List Subject: Re: Layer 3.5 is actually layer 4 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; >>It should be noted that, during the discussion, no one have >>give any support for your sweeping statement that: >> >> The systems level argument for a layer 3.5 solution is that >> it can cover all cases, including ones we have not >> invented yet. > > > Just to state the obvious, I agree with this statement, and i guess that the > authors of the several so called 3.5 layer solution do too (some of them > have stated it clearly in some mails). Thank you agreeing with my statement. However, as Brian said So could we please close this discussion? it is too late for Brian to make your support valid. Your statement is invalid also because you give any technical points at all. You should be also aware that if authors of the several so called layer 3 solutions agree with the fallacy, they should have stated so cleary. But, they didn't. It is not your job to speak for them. > Please do not assume that silence means that people agree with you, assume > that people are just tired to continue endless discussions Which is why raising new technical points is important, though it is poor couter argument if the points raised are already denied by the existing argument. A simple fact is that: TCP is not IP. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 27 08:16:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04016 for ; Tue, 27 Jan 2004 08:16:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlT1X-000AfP-OJ for multi6-data@psg.com; Tue, 27 Jan 2004 13:12:59 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlT1K-000Adq-Sr for multi6@ops.ietf.org; Tue, 27 Jan 2004 13:12:47 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id i0RDCje2060820 for ; Tue, 27 Jan 2004 13:12:45 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0RDCiEg235672 for ; Tue, 27 Jan 2004 14:12:44 +0100 Received: from zurich.ibm.com (gsine10.us.sine.ibm.com [9.14.6.40]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with SMTP id OAA38600 for ; Tue, 27 Jan 2004 14:12:41 +0100 Message-ID: <40166381.15F3E56A@zurich.ibm.com> Date: Tue, 27 Jan 2004 14:11:29 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 List Subject: So could we please close this discussion [Re: Layer 3.5 is actually layer 4] References: <4016555A.6050201@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit So could we please close this discussion? Brian From owner-multi6@ops.ietf.org Tue Jan 27 08:28:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04319 for ; Tue, 27 Jan 2004 08:28:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlTFI-000CQ6-TJ for multi6-data@psg.com; Tue, 27 Jan 2004 13:27:12 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AlTF6-000COr-Lx for multi6@ops.ietf.org; Tue, 27 Jan 2004 13:27:00 +0000 Received: (qmail 9027 invoked from network); 27 Jan 2004 13:38:13 -0000 Received: from h219-110-032-187.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.187) by necom830.hpcl.titech.ac.jp with SMTP; 27 Jan 2004 13:38:13 -0000 Message-ID: <4016676F.705@necom830.hpcl.titech.ac.jp> Date: Tue, 27 Jan 2004 22:28:15 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 List Subject: Re: So could we please close this discussion [Re: Layer 3.5 is actually layer 4] References: <4016555A.6050201@necom830.hpcl.titech.ac.jp> <40166381.15F3E56A@zurich.ibm.com> In-Reply-To: <40166381.15F3E56A@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > So could we please close this discussion? As I wrote, you can, as all the people participated with reasons admit against you that there are special cases. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 27 11:31:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12108 for ; Tue, 27 Jan 2004 11:31:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlW4j-000BFp-P6 for multi6-data@psg.com; Tue, 27 Jan 2004 16:28:29 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlW3U-000B4S-8o for multi6@ops.ietf.org; Tue, 27 Jan 2004 16:27:12 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4767C82CB; Tue, 27 Jan 2004 17:27:11 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 331D682BF; Tue, 27 Jan 2004 17:27:11 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Cedric de Launois" Cc: Subject: RE: Host Centric Multi-Homing Date: Tue, 27 Jan 2004 17:19:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1075201611.899.2.camel@descartes> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Cedric, thank you very much for your comments, some answers online... I have already updated the draft with some of your comments, you can check it at the same location: http://www.it.uc3m.es/marcelo/draft-huitema-multi6-hosts-02.txt > Section 3.3 > > Your example seems broken. > You wrote : > "To communicate with Y, X [...] will choose the source address [...] > A:X" > > and then : > "If the chosen exit router at Site X is RXB, the packet will flow > freely" > > Substitute RXB by RXA ? > Moreover, in your example, which address is used to contact Y : C:Y or > D:Y ? > > I understand the problem but please, correct and/or clarify the example. I am sure you do :-) I have already corrected it in the new version > > > Section 4 > > Three components interacts in the multiaddress multihoming problem : > the source address, the ingress filters and the intradomain routing. > Essentially, I would divide the solutions into three categories, > depending on which component is adapted in order to solve the problem : > > a) Honor source address and routing, adapt filtering > b) Honor source address and filtering, adapt routing > c) Honor routing and filtering, adapt source address > > Your section 4.1 is equivalent to a). Your section 4.2 is equivalent > to b) and section 4.3 to c), but I would move the "exit router > discovery" procedure from c) to b). Yes, i have considered this option since it makes sense to me too. However, this approach is basically focused on who actually has to deal with the problem. In the first case you simply relax address checks, in the second case you modify the oruting system in order to deal with the problem, in the third case, the hosts solves the problem, either forcing the source address or forcing the exit router. I mean, there are multiple different ways to classify the different approaches and some people would probably see one approach more natural of the others, but this will vary with people. As i said earlier, i like also what you are proposing but i also find the presented approach valid. > I explain : in this case, we don't > adapt the source address. Instead, we use tunnels to force the routing > system to convey the packet to where the host wants. That is : we adapt > the routing and honor source address selection and filtering. > > Note that I'm not sure about the "exit router discovery" procedure being > superior to the source address discovery. The use of tunnels reduces > the MTU. While this is acceptable for e.g. particular QoS applications, > we should not impose this mechanism for the general case. The problem with source address discovery is what to do with the first packet. I mean, with site exit discovery, the first packet can be tunneled towards the appropriate exit, while with source address discovery you probably have to discard it. So as solution for the site exit issue seems inferior. However, for reacting to topological changes it is suitable, since the selected source address cannot be used. > > > Section 4.4 > > The case described in this section appears to me as a special case of : > c) Honor routing and filtering, adapt source address > That is : we just adapt the source address on the fly, at the site > exit router. > > > 7. Proposed solution > > "In this section, > we will present the recommended ways to solve the site exit issue and > how to trigger rapid reactions to local failures." > > What do you mean by "local failures" ? Failures that occur inside the > mh site ? Link failures between the mh site and an ISP ? Failure of > an ISP of the mh site ? yes this is not clear. I have dropped the "local" > > Section 7.1 Multihoming solution for big sites > > Only relaxing the source address check does not completely solve > the IPv6 multihoming problem. Remember that to preserve scalability > the site advertises prefix PA only to ISP A. If ISP A is down, we must > prevent the use of prefix PA since BGP doesn't know that it can route > packets with destination prefix PA to another ISP of the mh site, > say ISP B. > Thus we also need a mechanism for big sites to manage wich prefixes > can be used and which cannot. > You are right, of course. The idea is to use a similar but simpler mechanism to the one proposed for medium sites. > 7.2.2.2.2 Reaction to other failures modes > > "the proposed mechanism to > identify available paths will be based on the trial and error > procedure." > > This is probably the base generic mechanism. All others mechanisms > described (router renumbering, router advertisement, ...) only give > hints about which prefix should be tried first. The base mechanism > of trial and error is always needed, e.g. when a host > doesn't get a response because the return path is broken somewhere > in the Internet. > So I suggest to present it as the base mechanism, and present > others as optimizations. > The presented approach is incremental. Using Radv to deprecate a prefix can be implemented with legacy hosts while the trial and error procedure requires updating the hosts. So the proposed approach is incremental, and the first steps are those that don't impose much changes. Then the next steps provide a more general solution but impose more changes. > Section 8.1.2 > > What about outbound traffic engineering ? Even > the simplest mh site might want to balance its traffic between > e.g. its DSL and Wireless lines. > The policy table of the default address selection mechanism can provide some of the stuff that you need, but we should inlcude it in the text i guess. > Pure editorial notes : > fixed. From owner-multi6@ops.ietf.org Wed Jan 28 00:35:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17190 for ; Wed, 28 Jan 2004 00:35:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AliKx-000LEA-0x for multi6-data@psg.com; Wed, 28 Jan 2004 05:34:03 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AliKj-000LCW-Fo for multi6@ops.ietf.org; Wed, 28 Jan 2004 05:33:49 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id CCD2013A00; Wed, 28 Jan 2004 00:33:48 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 28 Jan 2004 00:33:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Reminder re multi6 drafts Date: Wed, 28 Jan 2004 00:33:47 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA480@tayexc13.americas.cpqcorp.net> Thread-Topic: Reminder re multi6 drafts Thread-Index: AcPj9mwcABjTEN+qTSG0F1CmS86GWwAADThwAFnTnUA= From: "Bound, Jim" To: , , Cc: , X-OriginalArrivalTime: 28 Jan 2004 05:33:48.0024 (UTC) FILETIME=[4DBB2F80:01C3E560] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable John and all. Sorry I cannot get this done but I suggest we could be missing the point of SCTP for multihoming and John's mail I think puts it back on track. Comments below. By the way I have to do this now soon anyway as it will be used for test bed and have some folks that are willing to do the code and want to have it in U.S. ISPs for testing hopefully in Oct 2004 for testing. So whether it happens here or not there will be a draft at some point. Taking a transport protocol fix for multihoming off the table because of a seoul deadline is not wise is my input. But I understand the need to move on. But I still don't see that but it is better. > Hi Lode, >=20 > > Sorry fir the fuss... Had some mail address trouble... > >=20 > > John: > > I am busy doing a draft concerning SCTP with answers to the=20 > > questions posed in Elliot Lears draft. I'll send it to you by=20 > > Wednesday, so we'll be able to send it out on Friday.... That will be useful to see. >=20 > Sounds good. I think we should talk about SCTP (including=20 > PR-SCTP & SCTP+Add IP) and its applicability for solving > multihoming. We should explain how SCTP can provide > multihoming for protocols running on top of SCTP and we > should also discuss the limitation of SCTP, for example, > not supporting applications running over UDP, etc. I agree but last sentence needs to be more clear. It is not a limitation of SCTP because it does not support other transports, but that existing applications need a solution until they report to use SCTP Protocol Parameter to the Socket (as one example) as opposed to TCP or UDP. One thing we wanted to put in our draft then we do it is a means to build an implementation shim that would permit an SCTP association below the applications layer. SCTP configuration for the transport associations et al would be done through configuration module based on the parameters passed from the application context for TCP or UDP. To permit use of add-ip and other extensions for SCTP that would be configuration module that would support all applications such as making sure the SCTP transport association would support multiple IP addresses for an association and then permitting those addresses on a node to even be different interfaces. This is the hint of the extension we would need for SCTP and quite easy to do as single draft to support multi6. > =20 > > Concerning the SCTP over HIP/NOID/..whatever.., that is a completely > > different ballgame... And I'll first talk with folks=20 > concerned what is=20 > > truly meant by this. I've got a nagging feeling that we not talking=20 > > about the same thing here... Exactly Lode. >=20 > My feeling is that this is orthoganal to the draft at hand. Don't > worry about HIP/NOID/etc. Agree The benefit of SCTP is it completely eliminates the need for the end system to worry about the problem at that point in the network for the multi6 problem. If a connection fails another one in the association is used so routes do not have to be kept at all because of end nodes having to send to same address to another provider. Its very simple. This does not solve the loc+ID issue at all or the appropriate spatial routing algortihm for a Metro where prefixes are congested. =20 As far as hacking up yet another 3.5 or I would argue 4.5 layer/shim that is simply absurd architecturally and will never see the light of day from product implemenation at all widely across vendors. SCTP does the job. Mobility. This has nothing to do with multi6 and should not be part of this effort and there are plent of mobility WGs to go extend what MIPv6 has done. =20 /jim /jim >=20 > thanks, > John >=20 >=20 From owner-multi6@ops.ietf.org Wed Jan 28 08:08:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29228 for ; Wed, 28 Jan 2004 08:08:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlpP0-000KsO-JE for multi6-data@psg.com; Wed, 28 Jan 2004 13:06:42 +0000 Received: from [194.78.143.102] (helo=hrtades9.atea.be) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlpOn-000KrM-1G for multi6@ops.ietf.org; Wed, 28 Jan 2004 13:06:29 +0000 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D54V448J; Wed, 28 Jan 2004 14:06:31 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Jan 2004 14:06:25 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195A7F49A@hrtades7.atea.be> From: Coene Lode To: "'Brian E Carpenter'" , Coene Lode Cc: multi6@ops.ietf.org Subject: RE: Comment on draft-coene-sctp-multihome-04.txt Date: Wed, 28 Jan 2004 14:06:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk < Snip...> You state that: > Under the assumption that every IP address will have a different, > seperate path towards the remote endpoint, (this is the > responsibility of the routing protocols or of manual configuration) > , if the transport to one of the IP addresses (= 1 particular path) > fails then the traffic can migrate to the other remaining IP address > (= other paths) within the SCTP association. Now in the original context that SCTP was designed for, you might have that much control over the routing environment. But it seems to be a very dangerous assumption for the general case of two systems communicating over the whole Internet. <...snip> It is indeed true that this particular assumption will NOT be true in the general case. The general case would be that along the paths present, some or all of them will share some routers and/or links between them. SCTP is not able to detect this and can therefore do nothing to enforce it. Therefore it is an assumption which can be true: but then things outside the scope of SCTP have to do something.... Or the assumption can be false: then SCTP will work(just as in the first case) but then weird things could happen..(example 2 links from host -> only one is ever carrying traffic, the other one always sits idle due to the routing table in the host.. See draft: it should be beter explained there...) I actually think this points to an important component of any solution that we haven't really talked about much, except when NAROS was discussed a few months ago - how does one determine the existence or absence of connectivity between two locators? For SCTP or any other solution, it's only when connectivity exists between an address pair that they are any use. <...snip> That is where the heartbeat comes in... Address exchange alone doesn't solve the problem. (Heart)Beating the addresses(sory for the pun...) gives you a idea of it reachability... By the way, you also say > > As a practical matter, it is recommended that IP addresses in a > multihomed endpoint be assigned IP endpoints from different TLA's to > ensure against network failure. The term "TLA" no longer exists in IPv6 and in any case, it is a false assumption that two different high-order network prefixes imply two different paths. They might, but they might not. Brian <....snip> I better then remove the sentence... Replacing them by provider seems to limit the choice as multihoming can also occur using only a single provider.. But it is easier to demonstrate this when talking about 2 or more providers. 2 different prefixes can still take the same outgoing link from the host.. That is not what we really wanted... Thanks for the comments.. And if there are more, let them come... Yours sincerely, Lode From owner-multi6@ops.ietf.org Wed Jan 28 10:21:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04412 for ; Wed, 28 Jan 2004 10:21:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlrSw-000Eqi-A1 for multi6-data@psg.com; Wed, 28 Jan 2004 15:18:54 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlrSh-000Epf-OJ for multi6@ops.ietf.org; Wed, 28 Jan 2004 15:18:39 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A0C0085A1; Wed, 28 Jan 2004 16:18:38 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 8A864856D; Wed, 28 Jan 2004 16:18:38 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , "Multi6" Subject: RE: [Fwd: I-D ACTION:draft-nikander-multi6-hip-00.txt] Date: Wed, 28 Jan 2004 16:10:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4013E7E9.12F9D87A@zurich.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, A question about section 3.2: what do you mean by "update the state" when the Recipient wants to open a connection in the reverse direction. I think i understand the attack that you are trying to prevent here, however, i am not sure that i really understand what do you mean by update the state. The attack, as i understand it could be the following An attacker A wants to steal the identity of a Server S in a certain victim B. Since the identity for the transport layer is the HIT, A wants to pretend to be HITS in the eyes of B. So, A initiates a communication with B, and A uses HITS as HIT and IPA as address. Since they are using LHIP, no validation about HITS is performed by A. This is not really a problem I think because it is A who started the communication, so it is hard to perform an attack. The problem is when B wants to contact S, since if B accept the binding between HITS and IPA, then it will be initiating a communication with A thinking that it is communicating with S.(this is why you mention in your draft that when the recipient wants to initiate a communication in the reverse sense it has to be careful, right?) Now, you state that the recipient in this case B has to update the state, what does this means? - Does it means that it has to obtains the IP addresses of the HIT again, for instance from the DNS? and then it can use LHIP - Does this means that it can initiate the reverse communication but it has to perform the 4 way handshake validating the HIT? This would mean that LHIP cannot be used in reverse communications, right? - something else? BTW i couldn't find draft-yitalo-multi6-hc, i guess it is not submitted yet. A question about mobility: does the rendez vous server described in section 5.2.1.2.1 forwards packets to mobile hosts, like the Home Agent of mobileip, or it just informs about the current address of the mobile node? question about 5.2.2.3: hosts MUST verify reachability of an address before start using it? i understood from recent mail exchanges at the HIP ml that this was optional. about 5.3.1.4- policy How would the adoption of hip impact current default address selection mechanism? IMHO, hip would apply rfc 3484 to select addresses, right? then you could use the policy table defined in rfc 3484 to express policy, i think about 5.3.1.8 - ingress filtering I am not sure that what is stated in the draft in completely accurate... Other multiaddress solutions propose concrete approaches to deal with ingress filtering, for instance SIM uses source address rewriting by exit routers. To support this they require a rewrite OK bit in the header, in order to inform the exit router if this packet can be rewritten. AFAIK, hip does not define something like this, and i am not sure if HIP would work if all the source address of all packets is rewritten. In particular, interaction with IPsec comes to my mind, and interaction with legacy hosts. Perhaps with some modifications hip could support this, but i don't really know that. There are other approaches to deal with ingress filtering that probably could be directly supported by HIP, such as the ones presented in draft-huitema-multi6-hosts. regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Brian E Carpenter > Enviado el: domingo, 25 de enero de 2004 17:00 > Para: Multi6 > Asunto: [Fwd: I-D ACTION:draft-nikander-multi6-hip-00.txt] > > > > > -------- Original Message -------- > Subject: I-D ACTION:draft-nikander-multi6-hip-00.txt > Date: Fri, 23 Jan 2004 15:59:31 -0500 > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > To: IETF-Announce: ; > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : draft-nikander-multi6-hip-00 > Author(s) : P. Nikander > Filename : draft-nikander-multi6-hip-00.txt > Pages : 28 > Date : 2004-1-23 > > The Host Identity Protocol implements the identifier locator > separation by introduing a new name space and a new layer to the IP > stack. The new structure insulates the transport layer protocols > from the internetworking layer, thereby allowing transport sessions > to remain unaffected even if the underlying IP addresses change. > That, in turn, seems to make it easier to solve the so called site > multi-homing problem than without introducing such an indirection > layer. > > This document discusses how the proposed HIP mobility and > multi-homing solution, described separately, would fit to the IETF > multi6 working group requirements. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of > the message. > > Internet-Drafts are also available by anonymous FTP. Login with > the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-nikander-multi6-hip-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-nikander-multi6-hip-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From owner-multi6@ops.ietf.org Wed Jan 28 11:02:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05923 for ; Wed, 28 Jan 2004 11:02:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Als8G-000M5G-42 for multi6-data@psg.com; Wed, 28 Jan 2004 16:01:36 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Als82-000M3N-DE for multi6@ops.ietf.org; Wed, 28 Jan 2004 16:01:22 +0000 Received: from nomadiclab.com (n45.nomadiclab.com [131.160.193.45]) by n2.nomadiclab.com (Postfix) with ESMTP id 127F8212C9A; Wed, 28 Jan 2004 18:01:21 +0200 (EET) Message-ID: <4017DBF3.1070704@nomadiclab.com> Date: Wed, 28 Jan 2004 17:57:39 +0200 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20040114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Cc: "Vesa Torvinen (JO/LMF)" , Erik Nordmark , Pekka Nikander , jari.arkko@ericsson.com Subject: New multi6 draft: WIMP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, We have submitted a new multi6 draft to I-D directory. The draft defines a Weak Identifier Multihoming Protocol (WIMP), and we wrote it in order to see how opportunistic/weak authentication methods could be used to sove the multi6 problem. WIMP is one of those protocols that introduce a new protocol layer between IP and upper layers. Our approach uses some very basic cryptographic functions (reverse hash chains and secret splitting) in order to have light and (hopefully) simple solution. The protocol is not bullet proof from security point of view, however, it intends to be "secure enough", and easy to implement. It was interesting exercise, and we hope it will stimulate discussion on various solutions to multi6 problem. See more details from the drafts itself, available in: http://www.hip4inter.net/multi6/draft-ylitalo-multi6-wimp-00.txt br, Jukka Ylitalo -- Jukka Ylitalo Ericsson Research Nomadiclab From owner-multi6@ops.ietf.org Thu Jan 29 04:14:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09157 for ; Thu, 29 Jan 2004 04:14:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Am8E4-000POS-7I for multi6-data@psg.com; Thu, 29 Jan 2004 09:12:40 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Am8Dr-000PNZ-Ue for multi6@ops.ietf.org; Thu, 29 Jan 2004 09:12:28 +0000 Received: from nomadiclab.com (n45.nomadiclab.com [131.160.193.45]) by n2.nomadiclab.com (Postfix) with ESMTP id 81A97212C99 for ; Thu, 29 Jan 2004 11:12:26 +0200 (EET) Message-ID: <4018CD98.6050103@nomadiclab.com> Date: Thu, 29 Jan 2004 11:08:40 +0200 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20040114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: New multi6 draft: WIMP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (uh oh, the previous email was incorrectly aligned) Hi, We have submitted a new multi6 draft to I-D directory. The draft defines a Weak Identifier Multihoming Protocol (WIMP), and we wrote it in order to see how opportunistic/weak authentication methods could be used to solve the multi6 problem. WIMP is one of those protocols that introduce a new protocol layer between IP and upper layers. Our approach uses some very basic cryptograpahic funtions (reverse hash chains and secret splitting) in order to have light and (hopefully) simple solution. The protocol is not buller broof from security point of view, however, it intends to be secure enough and easy to implement. We hope it will stimulate discussion on various solution to multi6 problem. See more details from the draft itself, available in: http://www.hip4inter.net/multi6/draft-ylitalo-multi6-wimp-00.txt Thanks, Jukka Ylitalo From owner-multi6@ops.ietf.org Fri Jan 30 13:39:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07454 for ; Fri, 30 Jan 2004 13:39:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmdVK-000NNA-MN for multi6-data@psg.com; Fri, 30 Jan 2004 18:36:34 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmdV6-000NM7-Dh for multi6@ops.ietf.org; Fri, 30 Jan 2004 18:36:20 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8726D8B8E; Fri, 30 Jan 2004 19:36:19 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 70FBA8B8C; Fri, 30 Jan 2004 19:36:19 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Jukka Ylitalo" , Subject: RE: New multi6 draft: WIMP Date: Fri, 30 Jan 2004 19:35:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4018CD98.6050103@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jukka, I am trying to understand your draft, and i have some questions about some points that you perhaps can help me with. 1. About the Context establishement exchange (section 3.4) I fail to see what you mean when you state that the responder remains stateless. I mean, the responder has to generate the temrporary hash chain. This hash chain has to be specific to this particular host pair context, right? (this is what it is stated in section 3.3 about generating reverse hash chains) So, this means that when the responder receives an INIT message it has to generate a new hash chain (or reserve a pre computed hash chain for this initiated context establishement), would this be correct?. If so, the responder has to at least store a state that is that this hash chain is reserved and cannot be used for a future INIT, right? If so, wouldn't this imply that an attacker sending INIT messages could force the responder to gnerate hash chains, sort of DoS attack? I ask this because, if i understand correctly, this is what you are trying to prevent, but i just fail to see how you actually prevent it :-( The you state that: "The initiator replies to the CC message with a context check reply message (CCR) and proves that it was reachable at the specific location by disclosing the anchor value." I don't really agree with this... I think that the initiator can prove that he is reachable by inlcuding the HMAC_CC value in the CCR message, and not by disclosing the anchor value. I mean, the anchor value would prove that the initiator is the same that the one who sent the INIT message, but if the RESPONDER is stateless, the responder has no information about the INIT message received, . I guess that the important is to inlude the HMAC_CC and since the responder has the H0_R it can verify that the HMAC__CC was generated by himself (the responder) (i am probably missing something here....) after you mention that: "The anchor value of the initiator hash chain binds the INIT and CCR messages together, and in this way the responder is able to verify that messages are coming from the same host. " again if the responder is stateless, he has no knowledge about the INIT message by the time he receives the CCR message, so what does it means that it can verify that both messages come from the same host? 2. Re-addressing exchange First, a simple question: the re-addressing exchange can be initiated by the responder? (i think so, but i couldn't find it stated clearly in the draft) Second, i am really having a hard time to understand how the key masks and the key pieces work and how you can verify which of the locators are reachable. I guess that part of the reasons is because my own comprehension problems, but the fact that part of the explanation is contained in section 3.5 and that the rest is contained in section 6.12, where the packet format is explained, is not helping me much :-( Could you provide me a simpel example, with for instance a REA message conatining 3 new locators, and detail which would be the AC1, AC2 and AC3 messages, how they are generated and which would be the ACR message (and its generation)? Sorry to ask this, but i am really stuck here... 3. After that a REA message is received, and some of the locators are verified, which locator is used for following packets? Do you use the address contained in the source address field of last received packets? Thanks, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Jukka Ylitalo > Enviado el: jueves, 29 de enero de 2004 10:09 > Para: multi6@ops.ietf.org > Asunto: New multi6 draft: WIMP > > > (uh oh, the previous email was incorrectly aligned) > > Hi, > > We have submitted a new multi6 draft to I-D directory. The draft > defines a Weak Identifier Multihoming Protocol (WIMP), and we > wrote it in order to see how opportunistic/weak authentication > methods could > be used to solve the multi6 problem. > > WIMP is one of those protocols that introduce a new protocol layer > between IP and upper layers. Our approach uses some very basic > cryptograpahic funtions (reverse hash chains and secret splitting) in > order to have light and (hopefully) simple solution. The protocol > is not buller broof from security point of view, however, it intends > to be secure enough and easy to implement. > > We hope it will stimulate discussion on various solution to > multi6 problem. > > See more details from the draft itself, available in: > > http://www.hip4inter.net/multi6/draft-ylitalo-multi6-wimp-00.txt > > Thanks, Jukka Ylitalo > > > From owner-multi6@ops.ietf.org Sat Jan 31 02:39:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11699 for ; Sat, 31 Jan 2004 02:39:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ampfs-0005jw-Rb for multi6-data@psg.com; Sat, 31 Jan 2004 07:36:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmpfP-0005d0-F3 for multi6@ops.ietf.org; Sat, 31 Jan 2004 07:35:47 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0V7ZkP09863 for ; Sat, 31 Jan 2004 09:35:46 +0200 Date: Sat, 31 Jan 2004 09:35:46 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: draft-savola-multi6-asn-pi-01.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, FWIW, even though I don't think this one partial solution I described a year ago is worth too much energy, I've updated it to relate to the multihoming goals and the questionnaire. I've sent it to be published to the I-D secretariat, and in the meantime is available at: http://www.netcore.fi/pekkas/ietf/draft-savola-multi6-asn-pi-01.txt BTW: looking at how other folks have filled in the goal/questionnaire analysis, it seems they have had a lot of trouble understanding what the real issues really are, answering to the real question, or making unbiased statements (big surprise). They should only be taken with a HUGE amount of salt :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sat Jan 31 03:27:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13164 for ; Sat, 31 Jan 2004 03:27:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmqSE-000DwI-0D for multi6-data@psg.com; Sat, 31 Jan 2004 08:26:14 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmqS0-000Dur-AW for multi6@ops.ietf.org; Sat, 31 Jan 2004 08:26:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0V8Pu310798 for ; Sat, 31 Jan 2004 10:25:56 +0200 Date: Sat, 31 Jan 2004 10:25:56 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: comments on draft-ietf-multi6-v4-multihoming-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk substantial ----------- 3. Motivations for Multihoming ==> this section should be removed completely, as it is duplicated in the multihoming goals document now. 4. Features of IPv4 Multihoming ==> this document assumes a prior knowledge of what "*THE* IPv4 multihoming solution" is. This has not been described anywhere. So, I'd propose to add a new section to replace sect 3 to describe a few common ways of doing it. There should be enough meat here, as I had 16 pages of analysis of current methods in my thesis about site multihoming. basically, I think you can divide the IPv4 multihoming techniques to about five different types: 1) multihoming using your own AS number and your own prefix, advertising them through multiple providers. 2) multihoming using your own AS number, but advertising a more specific prefix from one of your ISPs. Some of these are multihomers (the backup is through the ISP which announces the aggregate), some have just bought the prefix when they changed ISP. 3) multihoming with your own prefix, but without your own (public) AS number. As the cost of the AS is low, this is rather rare. The customer uses private AS numbers or the ISP proxy-advertises the prefixes. Nondistinguishable from "origin theft" as multiple AS's seem to be originating the same prefix. 4) multi-attaching multiple times to an ISP, even though not strictly multihoming, is also popular. This is a very simple operation, and often the tradeoffs (unless you want independence as a multihoming motivation) are acceptable if you pick the right provider. 5) employing NAT-based or RFC2260 -like solutions (you could also separate these two) to achieve at least some multihoming benefits. Typically you cannot get everything, but for some, this has been enough. In section 4, you've analyzed only 1). This may be OK, as the characteristics are similar with the other major method, 2). But this needs to be spelled out. Another way would be analyzing each of these in turn, or the like. ==> you should also include the analysis of the "additional features" of the multihoming goals document wrt IPv4 multihoming, I guess? ==> the lists are also not up-to-date, as you don't list e.g. DNS or packet filtering. 6. Security Considerations Security considerations are not discussed in this draft. ==> this must be a flame-bait :), so replace it with something like: This memo analyzes the IPv4 multihoming practices. This analysis only includes the description of the mechanisms and partially how they affect the availability of the site deploying the IPv4 multihoming mechanism. Other security properties of the IPv4 multihoming mechanisms are not analyzed. 5. Limitations of IPv4 Multihoming 5.1 Scalability ==> I'd also add here something like: These mechanisms also add to the consumption of public AS number resources, when small sites wishing to multihome obtain an AS number specifically for only that purpose. Using a different mechanism would help to conserve the 16-bit AS number space, and avoid the move to 32-bit AS numbers. editorial --------- ==> throughout the document, one uses "enterprises" rather than "sites" -- is this intentional? Abstract Multihoming is an essential component of service for enterprises [3] which are part of the Internet. This draft describes some of the motivations, practices and limitations of multihoming as it is achieved in the IPv4 world today. The context for this discussion is the requirements analysis for site multihoming in IPv6, which is described in a companion draft [1]. ==> the abstract must not include references 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. ==> these terms can be removed, they shouldn't be used in a document like this anyway. References ==> references need to split to informative and normative. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sat Jan 31 14:10:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01215 for ; Sat, 31 Jan 2004 14:10:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1An0Ry-000Cw3-30 for multi6-data@psg.com; Sat, 31 Jan 2004 19:06:38 +0000 Received: from [130.54.9.41] (helo=shield.kudpc.kyoto-u.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1An0RU-000Cuq-7u for multi6@ops.ietf.org; Sat, 31 Jan 2004 19:06:08 +0000 Received: by shield.kudpc.kyoto-u.ac.jp; id EAA20271; Sun, 1 Feb 2004 04:06:05 +0900 Received: from localhost(127.0.0.1) by shield.kudpc.kyoto-u.ac.jp via csmap (V4.1) id srcAAANxaGLN; Sun, 1 Feb 04 04:06:05 +0900 Received: from mbox.kudpc.kyoto-u.ac.jp (mbox.kudpc.kyoto-u.ac.jp [130.54.9.32]) by shield.kudpc.kyoto-u.ac.jp (8.11.3/8.11.3) with ESMTP id i0VJ64020257 for ; Sun, 1 Feb 2004 04:06:04 +0900 (JST) Received: from blackpearl.arifumi.net (p622171.kyotac00.ap.so-net.ne.jp [219.98.33.113]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mbox.kudpc.kyoto-u.ac.jp (Postfix) with ESMTP id DF83048C097 for ; Sun, 1 Feb 2004 04:06:04 +0900 (JST) Date: Sun, 1 Feb 2004 04:05:16 +0900 From: arifumi To: multi6@ops.ietf.org Subject: New I-D: draft-arifumi-multi6-tlc-fm-00.txt Message-Id: <20040201040516.04dfadf6@blackpearl.arifumi.net> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_SORBS, RCVD_IN_SORBS_SMTP autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Resend with a subscribed address. :-( -- Hi all, I submitted the following Internet-Draft today. TLC-FM : Transport Layer Common Framework for Multihoming http://www.rd.miako.net/~arifumi/ietf/draft-arifumi-multi6-tlc-fm-00.txt This is a transport layer based multihoming solution targeted for all the transport protocols. This includes some new ideas that can be used for host based approaches and some architectural analyses before at end of this document. Any questions and comments are welcome. -- /arifumi From owner-multi6@ops.ietf.org Sat Jan 31 16:48:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06935 for ; Sat, 31 Jan 2004 16:48:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1An2iv-0002nR-H8 for multi6-data@psg.com; Sat, 31 Jan 2004 21:32:17 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1An2Qy-0000em-OG for multi6@ops.ietf.org; Sat, 31 Jan 2004 21:13:44 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i0VLEKGe027353 for ; Sat, 31 Jan 2004 22:14:21 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <5B31A7D4-5432-11D8-98F9-000A95CD987A@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 List From: Iljitsch van Beijnum Subject: crypto based host identifiers draft Date: Sat, 31 Jan 2004 22:13:46 +0100 X-Mailer: Apple Mail (2.612) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Here is a proper draft on crypto based host identifiers that I just submitted: http://www.muada.com/drafts/draft-van-beijnum-multi6-cbhi-00.txt It's not all that different from the non-draft I wrote up before Minneapolis. (Now going back to hanging on the couch half-passed out because a severe cold, RIPE meetings apparently don't agree with me.) Iljitsch